#ubuntu-devel 2005-02-28
<amu> mxpxpod: letme check, i'll restart
<amu> heh that's also a solution :) 
<Mitario> hi everyone
<sladen> Kamion: after/before the d-i Other Installed OS detection foo, what would need doing to add a ''reinstate grub MBR'' option.  I've answered two in the last 24hours
<Kamion> sladen: that sounds like what rescue mode is for
<sladen> Kamion: rescue more on the CD?
<sladen> Kamion: rescue mode on the CD?
<Kamion> yes, boot with 'rescue'
<Kamion> not particularly documented yet :)
<Kamion> ('rescue' instead of e.g. 'linux')
<Kamion> a "reinstate grub MBR" option in the way you're probably thinking is likely to be extremely hard; I think rescue mode is about the only viable way to do it
<Kamion> so the mini-howto would be: start rescue mode, pick your root partition, run "grub-install '(hd0)'"
<Kamion> or similar
<Kamion> it does LVM, too; not software RAID yet
<sladen> Kamion: excellent, typicall one-step ahead :)
<Kamion> sladen: it does lack documentation though, and there are still a number of plausible UI improvements
* Kamion ponders an LVM-on-RAID test installation
<sladen> is it on the warty CDs, or only on the recent Hoary builds?
<Kamion> only recent hoary
<Kamion> and I made a few UI fixes recently so you really want very recent hoary
<Kamion> elmo: please sync partman-lvm 30
<Kamion> (only translation fixes)
<thully> Hi - I have about 30 reported bugs, however I don't think I'll be testing Hoary anymore (just not enough time, and I want something more stable) - is there anything special I should do on bugzilla?
<Kamion> would probably be a good idea to leave a note about that on any of the bugs that are in state NEEDINFO
<thully> OK
<Kamion> two physical partitions -> RAID1 -> LVM -> {ext3 /, jfs /home}
* Kamion wonders how much more complex an installed system he can construct using hoary and still get it to boot
* lamont back
<Kamion> nope, failed to install lilo :(
<Kamion> Fatal: map file must be on the boot RAID partition
<Kamion> gee thanks
<Kamion> ah, works better if I install to /dev/sda
<bean601> how's the live version run?
<Kamion> haven't tested today's but it's getting fairly good now
<jdub> had a good powerpc install last night
<jdub> though x detection was b0rk
<jdub> oh wait!
<jdub> i have daniels in the living room!
<jdub> MU HA HA!
<daniels> OH NO YOU DON'T
<jdub> i have the keys.
<daniels> yeah, but I can still take a good run and dive off the balcony
<dholbach> jdub: could you please get some neighbours with cameras out on the street, please?
* lamont tries to remember which file it was that forced the MAC<->ifname mapping
<ogra> ifmap
<Kamion> lamont: /etc/iftab
<ogra> oops, sorry
<thom> mjg59: am now
<sladen> Kamion: In the wild, I've seen RAID on RAID and  RAID /on/ LVM+LVM  :
<ludi> What are the reasons why ubuntu ships with firefox instead of epiphany?
<mjg59> thom: What packages do I need to be offered a suspend option from the logout menu?
<dholbach> hi ludi, you can just install epiphany-browser
<ludi> dholbach: yes, but why is firefox the default instead of epiphany?
<thom> mjg59: i wish i knew; i don't have one
<dholbach> ludi: there was a long discussion about that back on the sounder-list, if i recall correctly
<thom> mjg59: certainly powermanagement-interface
<dholbach> ludi: you're free to use whatever you want :-)
<sladen> dholbach: http://lists.ubuntu.com/archives/ubuntu-devel/2005-January/thread.html#3371 for reference
<tritium> thom, is that available in the archives
<tritium> ?
<ludi> debian's gnome sees fit to keep epiphany as the default browser...
<thom> tritium: in universe, yes
<thom> ludi: we chose to use firefox; it's more targetted and known in our target audience
<mjg59> thom: I've got pmi, but no cool logout prompt action (current Hoary)
<tritium> thom, ah, found it.
<mjg59> But mailing list stuff suggests that it ought to be there, so I'm confused
<thom> mjg59: yes
<thom> mjg59: seb is the person to ask
<ludi> that's a big dissapointment for me.
<thom> i just told him how to generate the events
<thom> ludi: why? we support epiphany, it's just not the default
<dholbach> ludi: don't let the choice of others disappoint you - you *still* have the choice
<mjg59> thom: Ok, I'll bitch at him
<HrdwrBoB> ludi: ephiphany is still in supported software
<mjg59> thom: FWIW, PPC kernel with all the crack-tastick patches builds fine on x86. I'm just about to check that it /works/
<thom> mjg59: rockin'
<ludi> yes, but it feels like a rejection
<tritium> So did ubuntu love day fall through?
<thom> ludi: eh? howso? we have to pick something to be standard
<HrdwrBoB> ludi: someone is always going to be rejected
<farruinn> tritium: it's tomorrow, right?
<mdz> it's just begun
<tritium> farruinn, but it's already the 17th in some parts of the world
<farruinn> oh, right
<ludi> firefox wins the popularity contest
<ludi> but epiphany may be technically a better browser in the gnome desktop
<ludi> it's like choosing the "pretty" blonde instead of the charming brunette...
<mjg59> thom: Ok, my crack patches don't prevent x86 from booting
<thom> well, that's a start
* thom boggles idly at ludi
<mjg59> thom: And it suspends to disk fine
<thom> mjg59: good good
<mjg59> Currently resuming...
<mjg59> Fuck, no
<mjg59> No error messages, straight resume
<mjg59> Arse
<mantiena> mjg59, Fuck ? Yes !
<mantiena> ;)
<mjg59> mantiena: You're not currently here, so I'm afraid that's not really an option
<mjg59> Now, why did that fail?
<mantiena> mjg59, but you also are not here, maybe that's an option here ? ;)
<thom> argh, less has taken over */* mime types again
* mjg59 attacks swsusp with a stick
<mjg59> I'm getting very sick of this Vaio BIOS animation
<thom> mjg59: vaio? ew
<ogra> mjg59: switch it off ;)
<mjg59> thom: Dude, my test box has become a Vaio
<mjg59> I couldn't have written the Sony crack otherwise
<thom> mjg59: i suppose it's good that they're useful for something
<mjg59> This one has no removable media, no way to boot off network or USB and has a broken screen hinge
<Mitario> nn all
<mjg59> Arse, resume failed again
<daniels> mjg59: should get an x505
<mjg59> Now I'm actually going to have to debug this
<mjg59> daniels: I was sort of planning on getting Mark to buy me one
<mjg59> Arse.
<daniels> heh :)
<mantiena> I'm going to sleep, bye all
<ogra> night all
<ajmitch> night ogra 
<mantiena> mdz, still online ?
<mantiena> mdz, It seems there are problems in liveCD with USB and other hotpluging hardware - hotplug simply doesn't work when I work in GNOME from liveCD :( 
<mantiena> root@ubuntu:/tmp/mnt/installer # ps aux |grep hot
<mantiena> root     28425  0.0  0.0   3000   716 pts/1    R+   03:02   0:00 grep hot
<dholbac1> re
<mantiena> hotplug even doesn't start if I try to start it from command line :(
<mantiena> root@ubuntu:/tmp/mnt/installer # /etc/init.d/hotplug start
<mantiena>  * Starting hotplug subsystem...                                          [ ok ] 
<mantiena> root@ubuntu:/tmp/mnt/installer # ps aux |grep hot
<mantiena> root     30753  0.0  0.0   2996   720 pts/1    S+   03:04   0:00 grep hot
<mantiena> root@ubuntu:/tmp/mnt/installer #
<dholbach> jdub: how eager are the guys in #ubuntu-love? they surely want to get involved into https://www.ubuntulinux.org/wiki/UniversePythonTransitionTODO :-)
<mantiena> mdz, I really should go to bed, you can answer me, I read IRC log when wake up ;)
<mdz> mantiena: hotplug is not a daemon
<mdz> there are some bugs around automatic mounting of hot-plugged devices, if that's what you're testing
<dholbach> sleep tight everyone, i'm off
<mdz> bye all
<Kamion> dear md5sum, please run faster so that I can go to bed, love Colin
<HrdwrBoB> Dear Colin, your system has crappy I/O throughput. love md5sum
<sivang> Kamion: it's probably around 4:00am there no?
<Kamion> little's not that bad ... just big files
<Kamion> 3am
<sivang> Kamion: eh then we are 2 hours apart
<daniels> Kamion: clearly you should be doing it on CONCORDIA
<Kamion> hm, actually I was unfair to md5sum, it's cp taking eons
<Kamion> thank God we aren't including DVDs in Array releases (yet)
<daniels> Kamion: we'd need a 1TB RAMSAN for that
<HrdwrBoB> oh look.. ramsans.. mmm
<sivang> just for the laugh http://www.linuxworld.com/story/44851.htm
<Kamion> night all
<daniels> Kamion: 'night dude
<lamont> night Kaloz 
<lamont> Kamion, even
<lamont> damn completion
<sivang> night Kamion 
<smurfix> Hmm. The build of console-data failed because it depends on keymapper. Apparently keymapper still needs to get promoted to main. :-/
<smurfix> Who's responsible for that?
<fabbione> morning
<Shaquile> fabbione: morning
<svenl> hi fabbione 
<whiprush> jdub: ping pong
<jdub> whiprush: yo
<whiprush> linked up with mako
<whiprush> gave out a _boatload_ of ubuntu CDs
<whiprush> had beer, talked MOTU stuff.
<jdub> rocking
<whiprush> _awesome_ stuff.
<jdub> lots of love for the ltsp machines, ubuntu cds and gnome livecds?
<whiprush> dude ... blogging now.
<whiprush> the love went far beyond my expectations.
<jdub> sweet :)
<whiprush> unfreakingbelievable.
<dilinger> i need to start reading planet.gnome
<jdub> whiprush: lemme know when you've hit submit, want hot fresh bloggy goodness ;)
<whiprush> k
<schweeb> whiprush: jorge, you done blogging yet
* opi is back
* opi is back
<Treenaks> wb
<opi> man, I hate my job :/
<opi> I didn't do nothing for Ubuntu, or Ubuntu-related since two weeks :/
<Treenaks> urgh
<opi> I'm going to quit from Leader position, I'm now more a slacker than a leader :-)
<toresbe> that's what leaders do :P
<Treenaks> delegate!
<toresbe> exactly. :P
<Mitario> morning
<pitti> Morning
<infinity> pitti!
<infinity> pitti : I need to smack you around a bit.
<pitti> Hey infinity 
<pitti> What's up?
<infinity> pitti : And you need to do another php4 security upload for Ubuntu.
<pitti> *sigh*
<infinity> pitti : Grab the latest copy of 040-curl_open_basedir.patch from the pkg-php4 CVS on alioth.
<infinity> pitti : Your patch was a) not complete, and b) causing segfaults.
<infinity> pitti : So, I rewrote it.  Merry Christmas.
<pitti> infinity: uh, sorry for that...
<infinity> I'm rolling a new upload for Debian right now.
<infinity> The new patch is tested to actually work. :)
<infinity> It a) enforces safe_mode (yours only enforced open_basedir), and b) covers the case where curl_inti() is called with no args, and CURLOPT_URL is set via curt_setopt instead.
<infinity> Oh, and c) covers the case where someone uses a host component in their file:// URL.
<infinity> Your patch was easily bypassed by using file://whatever/etc/passwd
<infinity> pitti : if you have any questions/corrections to the current patch, speak up now, before I upload. :)
<pitti> infinity: what should "whatever" be? ".." ?
<infinity> pitti : Anything.  It's completely ignored.
<pitti> uh
<infinity> pitti : Hence why I just strstr for the next "/"
<infinity> pitti : file:///foo, file://localhost/foo, and file://somethingrandom/foo are all the same URL.
<infinity> ie: The host component is just stripped out.
<infinity> Oh, hrm.  I didn't test if you can use mixed case.. (like "FILE:///foo")
<infinity> Let me test that before I upload.  If so, I need to use an insensitive match. :)
<pitti> infinity: bah, why it makes sense to put a host into a file URL?
<pitti> infinity: anyway, thanks a lot for fixing that
<infinity> Ahh, you can.
<infinity> Hold on while I update the patch again.
<pitti> infinity: mind to give me a full URL? http://alioth.debian.org/ just doesn't work ATM
<infinity> Hrm.  Not sure.  Let me put the patch elsewhere.
<infinity> http://lucifer.0c3.net/~adconrad/040-curl_open_basedir.patch
<infinity> Sorry I didn't get a chance to review it earlier, but better late than never, right?
<Mithrandir> hi pitti, \infty
<infinity> Hey Mithrandir.
<pitti> Hi Mithrandir 
<infinity> pitti : Look sane to yuo?
<infinity> pitti : it compiles and all my testcases come out as expected.
<infinity> pitti : So it can't be that broken. :)
<pitti> infinity: yes, but I don't fully understand all function calls of the second part
<pitti> infinity: I did not see any obvious errors
<infinity> pitti : open_basedir is the basedir check, then PG(safe_mode) is asking if we're running in safe_mode, and if so, we do a uid check (in safe_mode, people can't read files that they don't own)
<pitti> infinity: why there are two parts in the first place?
<pitti> infinity: aren't both cases file:// URLs?
<pitti> infinity: i. e. what does CURLOPT_URL mean?
<infinity> pitti : yes, but curl.c sets CURLOPT_URL in two possible places.  Both need to be covered.
<pitti> ok
<infinity> pitti : You can either do "curl_init('file:///foo')", or you can do "$handle = curl_init(); curl_setopt($handle, CURLOPT_URL, 'file:///')"
<infinity> The second case covers the latter.
<pitti> ah
<pitti> cool
<Mithrandir> elmo: please sync mailman from Debian incoming
<pitti> Mithrandir: what did you fix?
<Mithrandir> SLASH undefined
<pitti> CAN-2005-0202?
<Mithrandir> yes, update for that
<pitti> yes, Hoary already has the fix :-)
<pitti> Mithrandir: erm, we already have 2.1.5-6 ??
<Mithrandir> no, it doesn't.
<Mithrandir> yes, but -7 is in incoming
<pitti> Mithrandir: so is there a new vuln?
<Mithrandir> no
<Mithrandir> wtf, this is weird
<pitti> Mithrandir: ah, ok :.-) just read hte changelog
<pitti> Mithrandir: I did not use SLASH in my patch, I just used '/' :-)
<Mithrandir> +    parts = [x for x in path.split(SLASH) if x not in ('.', '..')] 
<pitti> Mithrandir: right, I remember
<Mithrandir> sure?  I thought I grabbed your patch
<Mithrandir> anyhow, hoary is broken ATM due to that.
<Mithrandir> since it's synced with Debian
<infinity> pitti : Anyhow, it's fairly urgent to get that fixed patch out, IMO.  Not for the security hole (who really cares?), but because your patch caused segfaults when calling curl_init() with no arguments.  A pretty nasty regression.
<pitti> infinity: yes, I'll upload new packages today
<infinity> pitti : Cheers.
* infinity heads to dinner.
<whiprush> jdub: blog up, going to bed. woot.
<pitti> see you later
<jdub> whiprush: night! :)
* ..[topic/#ubuntu-devel:jdub] : 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
<tritium> jdub, I think we've got a handle on polypaudio problems for the most part now
<tritium> jdub, crimsun documented what we tried here: http://lists.ubuntu.com/archives/ubuntu-users/2005-February/022862.html
<tritium> good night
<dholbach> morning
<jdub> yo dholbach 
<ogra> moin
<dholbach> hai ogra!
<mvo> hi dholbach 
<dholbach> hai mvo
<dholbach> mvo: had my first doesnt-built-on-one-arch-package today
<mvo> dholbach: :) what package was it?
<dholbach> mvo: papaya on powerpc
<mvo> dholbach: endian problems?
<ogra> looks rather like a typo...../include/Telnet.h:35: error: parse error before numeric constant
<dholbach> mvo: not sure yet
<fabbione> Unpacking OO.o build tree - [ go make some tea ]  ...
<fabbione> ahah
<HiddenWolf> How many arches does ubuntu support. (un)Officially?
<ogra> yeah, thats british
<ogra> HiddenWolf: 3 officially 2 un....
<HiddenWolf> ogra: any plans to increase that number?
<ogra> heh, i think there is at least one unofficial arch that could get added in hoary+1 (MIPS)
<HiddenWolf> *ugh*
<ogra> ?
<ogra> HiddenWolf: to what else should it increase ?
<HiddenWolf> Ubuntu is still young, not a massive infrastructure yet, I kind of feel that it'd be better to stick to arches that are used the most.
<seb128> mvo: hey. have you read the bugzilla comment about the maximized state for some apps ? I've Cc: you since the guy speak about synaptic
<mvo> seb128: no, not yet (/me checks mail again)
<ogra> HiddenWolf: if there are people that want ubuntu on their alpha station, why shouldnt they port it ?
<seb128> mvo: that's a 2 days old mail 
<ogra> HiddenWolf: ....an if the port is stable and wanted by the audience, why shouldnt it get adopted in the official set
<seb128> mvo: http://bugzilla.ubuntu.com/show_bug.cgi?id=6601
<HiddenWolf> ogra: true, but if you have a few smaller ports that suck in time, or get out of sync with i386, you run into debianish-situations
<jdub> HiddenWolf: number of arches is not regarded as a significant problem among core debian developers
<jdub> there are lots of other things that contribute
<HiddenWolf> Yeah :-S I'm still waiting for sarge. :-)
<mvo> seb128: it's probably a app issue. I save the window size on exit and restore it on restore. I'll have a look what magic gedit does
<opi> HiddenWolf: Sarge, Sarge.. hum.. I think it's some kind of Yeti Distribution ;-)
<mvo> seb128: I wonder why someone would want to open the gaim buddy list in fullscreen :)
<HiddenWolf> mvo: call me style-less :-)
* HiddenWolf is the reporter
<mvo> HiddenWolf: hehe :) 
<HiddenWolf> mvo: Give me a good alternative to gaim and I'll love you. :-)
<seb128> mvo: me too ;)
* mvo uses gaim himself
* mvo would like to add that he hadn't made it fullscreen yet ;)
<dholbach> someone would have to kill this reconnect-ui-logiv
<dholbach> logic
<ogra> yeah
* HiddenWolf thinks mvo has a tiny contact-list then
* mvo chucckles
* dholbach thinks, HiddenWolf shouldnt think about tiny things of others
* HiddenWolf prefers big things of others, but thinks that dholbach shouldn't think about what he should think
* mvo thinks this is getting complicated now
<ogra> lol
<dholbach> hai pitti
<HiddenWolf> Hm. I'm going to get ready to get my butt kicked. 
* HiddenWolf is getting kicked out of a project-group by his team, so he is in a bit of trouble, considering the importance of the course.
<pitti> Hey dholbach 
<enrico> Hello.  Could someone help answer this message that was addressed to mdz, but mdz is currently on vacation?  http://lists.ubuntu.com/archives/ubuntu-doc/2005-February/001218.html
<enrico> Kamion?
<enrico> The guy asking is writing the Hoary Release Notes and needs help with some items
<Mithrandir> enrico: both grepmap and readahead increase the speed of the boot process.
<haggai> does anyone have an amd64 or powerpc box that they could build openoffice.org2 on and then give me access to the build tree?  Both arches are failing in completely different ways to i386
<Mithrandir> haggai: hoary?
<haggai> Mithrandir: yup
<Mithrandir> haggai: drop a signed mail to tfheen@d.o, cc maswan@acc.umu.se; include your ssh key and desired user name.
<HiddenWolf> haggai: is there any ETA for the final oo02?
<haggai> Mithrandir: thanks.  Which arch would that be?
<Mithrandir> amd64
<haggai> HiddenWolf: April
<haggai> Mithrandir: ok thanks
<haggai> anyone with powerpc?
<jdub> haggai: yeah, a slow one
<HiddenWolf> jdub: Give it some lovin' and let it work a while. :-)
<haggai> jdub: it wouldn't matter if it was slow, I just need shell access to a built tree.  I have to run an extra module and examine the output
<jdub> haggai: hrm, shell access hard
<haggai> jdub: ok well if I gave you some extra commands to run could you then send me a dirtree containing that output?
<jdub> man, this is so not the machine you want ooo2 building on
<jdub> it'll take all night
<haggai> I have all week :)
<HiddenWolf> jdub: Imagine the joy that ppc will feel, that it finally gets a real job to chew on. :-)
<haggai> it takes 1/2 day just to do 1 source package, upload, wait for buildds...
<smurfix> Hey Simira 
<Simira> hello there
* Simira is waiting for lecture by Mr. Stallman
<Treenaks> Simira: where? in Norway?
<Simira> Treenaks: yup. It's by the International Student Festival
<Simira> Treenaks: he's even joining us for nerd's pizza afterwards... :D
<Treenaks> Simira: 8)
<Mithrandir> Treenaks: in a couple of hours, so Simira and I are watching irrelevant lectures while grabbing seats.
<Simira> hehe
<Simira> feels kinda nerdish, yes...
<Simira> let's see.. three hours or so? :p
<Mithrandir> pft
<Treenaks> Mithrandir: ah.. I'll probably see him at FOSDEM next week
<Mithrandir> it's not more nerdish than sitting in an airport hacking.
<Mithrandir> Treenaks: oh, he's coming to FOSDEM?
<ogra> opening note i guess
<Treenaks> Mithrandir: second one.. opening is Jimmy Wales (Wikipedia0
<Mithrandir> ok, fun.
<Treenaks> Mithrandir: I sat in the Barcelona airport, ircing, when I went home from Mataro ;)
<Mithrandir> I'll be there.
<Treenaks> Mithrandir: (thank you Intel + HP)
<Mithrandir> yeah :)
* Mithrandir hugs nstx
<dholbach> hi dredg
<dredg> dholbach: good morning
<dredg> thanks for your mail.. I've modified mbot accordingly
<ogra> yeah
<dholbach> dredg: cool - unfortunately i have to go - be back in 2 hours or something
<dredg> no worries :)
<dredg> i have to do that work..job..thing...
<dholbach> dredg: i know how it feels ;-)
<ogra> its a pity
<dholbach> see you later guys
<pitti> Mithrandir: argh, I really used that SLASH thing. Darn, in my first patch I didn't, somehow I messed that up :-(
<Mithrandir> pitti: so the warty fix is broken?
<pitti> Mithrandir: yes, fixing it now. I did it correctly in my test version, but somehow the official patch slipped in
<Mithrandir> ok
<seb128> grumpf, xine doesn't build here :/
<seb128> (xine-lib in fact)
<fabbione> cya guys
<fabbione> have fun
<ogra> have a nice time fabbione
<fabbione> thanks ogra
<ogra> and dont mess with the seals
<fabbione> cya soon
<pitti> fabbione: have nice holidays!
<fabbione> thanks pitti
<pitti> fabbione: no worries, we will mess up your beloved kernel in the meantime :-)
<pitti> fabbione: hey, wait I just received this remote root security bug!
<pitti> fabbione: just kidding :-) Take care!
<ogra> hhehe
<Mithrandir> Keybuk: should I just upload a new pkgconfig with me set as the maintainer or do you want me just to be in uploaders for now?
<Keybuk> just upload it
<Mithrandir> ook
<Mithrandir> what's the procedure for doing new upstream releases?
<thom> Mithrandir: so, do we rename moz-* to * now?
<Mithrandir> thom: yes
<thom> ok, i'll roll up a new firefox tarball
<Mithrandir> we change the source package as well, I guess.
<thom> indeed
<Astharot> bonjour
<ogra> ciao
<amu> daniels: ping
<rburton> so my arch repository has =meta-info/http-blows but isn't http accessible
<rburton> i'm sure it was in the past, is there anything else i should press?
<rburton> (burtonini.com/arch/)
<jdub> lifeless: ping, see rburton's q ^
<jdub> rburton: he's in london if you want to bug him ;)
<lifeless> rburton: run archive-fixup first
<lifeless> i.e. baz archive-fixup -A ross@burtonini.com--2004
<rburton> mwhaaa
<rburton> aaah
<rburton> jdub: now with new improved .listing files
<jdub> yay
<jdub> thanks :)
<jbailey> jdub: sb just told me that you've already looked at xml-rpc in bug-buddy.  Got a sec to tell me what you know?
<jdub> jbailey: no, not i.
<jdub> jbailey: i know that work was done on it; ask fer in #gnome-hackers
<jbailey> On gimpnet?
<jdub> yeah
<jbailey> Thanks. =)
<jbailey> The gnome hackers are in Boston right?  I'm guessing I should wait a couple hours before poking my head in.
<jdub> rburton: haven't mirrored?
<rburton> lifeless: thanks
<jdub> jbailey: they're all around the world :)
<jdub> jbailey: fer is in spain
<rburton> jdub: i'm lame. for me the arch repos is ~/Web/Burtonini/htdocs/arch
<elmo> seb128/kamion/mithrandir: done
<jdub> rburton: ;)
<rburton> i just did an rsync so the web should have the new files
<seb128> elmo: thanks
<seb128> jdub: sorry, I thought you were speaking with fer on #gnome-hackers about xml-rpc some time ago :)
<jdub> seb128: only about its existence, and what bugzilla needed, etc. ;)
<lifeless> rburton: np
<seb128> jdub: k, I thought you were both working on it :)
<jdub> no way dude
<jdub> xml-rpc client from C? yeeeeek!
* jdub hugs python
<seb128> don't be rude with the poor jbailey who is going to work on this
<ajmitch> jbailey: poor poor soul ;)
<Mithrandir> elmo: thanks
<jbailey> ajmitch: You're right.  I wish it were my beloved Corba.  But ah well.
<jdub> oh man
<jdub> dude
<jdub> you are a fan of murky grot, aren't you? :)
<ajmitch> jbailey: btw suspend-to-ram was easy to get going, I just had to read the wiki page ;)
<jbailey> jdub: Dude, I'm hard core. =)
<ajmitch> jdub: he hacks glibc for *fun*
<rburton> urgggh
<thom> hardcore smack addict - sendmail *and* corba
<jdub> and hurdygurdy
<jdub> i think the only reason jbailey enjoys hurd is so he can say, "let me slip into my comfortable OS"
<ajmitch> heh
<thom> jdub: dude, he's a MARTYR for the CAUSE
<jdub> and i'm a doubting thomas-- hold on, that's what you're supposed to be
<Mithrandir> ajmitch: what's wrong about hacking glibc for fun?
<ajmitch> Mithrandir: combine that with his other pursuits & you start to worry
<Mithrandir> I guess I should be considered insane, then
<Mithrandir> since I implement multiarch for fun
<jbailey> Mithrandir: Insanity's not that bad.  It lowers people's expectations of you ;)
<ajmitch> how far did you get on the nx server rewrite, btw?
<Mithrandir> ajmitch: working on it
<smurfix> jbailey: in that case, it actually raises them ...
<jdub> ajmitch: had to do multiarch support so he could run the server in 64bit and the client in 32bit ;-)
<Mithrandir> heh :)
<ajmitch> ok, time for sleep (again)
<ajmitch> night all
<pitti> night ajmitch 
<Mithrandir> sleep tight
<Kamion> elmo: hm, would it be useful to have Requested-By: or something in -changes mails for syncs rather than overwriting Changed-By:? I occasionally wonder "ok, so who actually uploaded that to Debian?"
<pitti> Keybuk: ping
<Keybuk> pitti: ello
<pitti> Keybuk: just debugging pmount
<pitti> Keybuk: EWORKSFORME
<rburton> htm, how do i get baz to show me the locals diffs on a single file
<pitti> Keybuk: do you happen to have two CD-ROM drives?
<Keybuk> nope, just the one
<pitti> Keybuk: I first tried /media/cdrom, but that's a symlink to cdrom0
<pitti> Keybuk: but the CD was in cdrom1
<pitti> Keybuk: you have /media/cdrom -> /media/cdrom0 ?
<mjg59> ajmitch: Suspend worked? Rocking.
<pitti> Keybuk: and it doesn't work for both paths?
<mjg59> thom: My patches for swsusp on PPC currently kill it on x86, for reasons I'm unsure of
<Kamion> rburton: baz diff | filterdiff? :-/
<Kamion> you'd *think* that baz diff -- <whatever> would work, but no ...
<mvo> rburton: dosn't baz diff -- $single_file work ?
<rburton> i'm not 100% keen on the heavy use of --
<rburton> mvo: nope
<rburton> didn't produce anything
<mvo> hrm, right (just checked)
<pitti> Keybuk: btw, you _do_ use pmount >= 0.6, don't you?
<thom> mjg59: ugh.
<smurfix> What's the procedure for moving something universe=>main?
<Keybuk> pitti: whatever's in hoary
<smurfix> keymapper to be exact
<pitti> Keybuk: <pitti> Keybuk: you have /media/cdrom -> /media/cdrom0 ?
<pitti> <pitti> Keybuk: and it doesn't work for both paths?
<pitti> s/both/either/
<Kamion> smurfix: if you've made something build-depend on it, then elmo processes that every so often
<Keybuk> pitti: looks like it; I haven't got time or a CD handy at the moment to play though
<deki_> hallo
<mjg59> thom: Ok, may have found the problem
<deki_> i have horrandous perofmrance with ubuntu kernel 2.6.10-3-k7-preempt
<deki_> the windows are drawed horribly slow
<deki_> i have pci nvidia card
<deki_> when i use mandrake kernel with ubuntu 2.6.3-mdk4
<deki_> then it is ok
<deki_> so how to disable preemption in kernel?
<deki_> bootoptions?
<mjg59> http://www.microsoft.com/athome/security/children/kidtalk.mspx is excellent
<infinity> mjg59 : This is fantastic.
<Kamion> deki_: that doesn't sound like a standard Ubuntu kernel to me
<infinity> (as in "ph34r my l33t skillz")
<Kamion> although actually our kernels do have CONFIG_PREEMPT=y, hmm
<pitti> infinity: the big question: why it is under a path called "security" ? :-)
<Kamion> although only for i386 and ia64
<mjg59> Now I'm horribly confused.
<deki_> Linux deki 2.6.10-3-k7 #1 Tue Feb 15 20:45:29 UTC 2005 i686 GNU/Linux
<bob2> deki is claiming that uid 0 has a special scheduler queue
<infinity> pitti : I'm not sure.  The point seems to be to determine if your child is "dealing in w4r3z" or is a "l33t h4x0r"
<bob2> and that this is an ubuntu-specific patch
<pitti> infinity: probably :-)
<thom> pitti: the mention of w4r3z and intelectual property theft
<infinity> Man, I haven
<deki_> zcat: /proc/config.gz: No such file or directory
<infinity> 't laughed so hard in days.
<infinity> mjg59 : Thanks.
<deki_> CONFIG_PREEMPT=y
<deki_> deki@deki:/boot$ cat config-2.6.10-3-k7 |grep -i PREEMPT
<deki_> CONFIG_PREEMPT=y
<bob2> and is apparently fixated on PREEMPT being the cause of the problem
<deki_> so there is PREEMPTION
* infinity can't imagine why preempt would destroy your X performance, mind you...
<deki_> bob2, yes i do
<deki_> bob2, acpi maybe too
<bob2> I'm not sure why he/she thinks switching to root would change the effect of PREEMPT in any way
<bob2> right, acpi degrades performance for non-root users
<mjg59> thom: D'oh. The kernel is fine, it's the hardware that's knackered. If it's shut down in platform mode, the disk cache is never flushed.
<bob2> it's a special ubuntu patch, too
<mjg59> Reverting to defaults is fine
<deki_> bob2, can you live me alone please?
<Kamion> I'm certainly not convinced preempt would be a good idea on powerpc, but fortunately we don't enable it on powerpc
<deki_> bob2, you give me no information at all
<mjg59> deki_: Why do you think preempt is a problem?
<deki_> bob2, you only talking one thing: fill a bug and this is not a kernel issuse
<bob2> I'm just bemused by your insistence on this, when you have no evidence either way.
<thom> mjg59: bah, that kind of sucks
<deki_> mjg59, cause i have had no such things on systems without preempt
<Kamion> we should really turn CONFIG_IKCONFIG or CONFIG_IKCONFIG_PROC or whatever on for all kernels; although it's in /boot anyway
<deki_> mjg59, look all windows are drowed thery slow
<mjg59> deki_: If you recompile the Mandrake kernel with preempt, do you have problems?
<bob2> deki_: yes, I'm not sure why you think ubuntu has a special kernel patch which degrades performance for non-root and only non-root users with PREEMPT
<elmo> Kamion: why?  as you say it's in /boot and if it's in /proc, doesn't it use memory?
<deki_> bob2, i thihnk root has also slow performance
<deki_> mjg59, i can send you the mandrake kernel config
<mjg59> thom: It's no big deal - just brokenness on this machine
<bob2> 23:11:16          deki_ |  bob2, there is not preemption for root
<Kamion> elmo: hm, true I guess; should be off for all architectures then, not on for some and off for others
<deki_> bob2, you are on ignore
<deki_> ok
<deki_> again i like ubuntu linux very much and i want to fix this issue
<deki_> can you tell me the possible causes for this problem?
<mjg59> deki_: If you have a kernel with preempt that is slow and an otherwise identical kernel without preempt that is fast, then it may well be preempt
<deki_> ok
<deki_> mjg59, i will try to rebuild the kernel
<mjg59> But comparing a kernel that's almost a year old with a current one and then concluding that the problem is preempt is mad
<mjg59> deki_: Ok, please do that
<mjg59> Are you using the same X drivers in both cases?
<deki_> mjg59, i take ubuntu kernel and then cahnge options only step by step
<deki_> mjg59, yes
<deki_> mjg59, 6111
<deki_> mjg59, maybe you are right
<mjg59> With the same X server?
<deki_> mjg59, sure not
<deki_> mjg59, hoary uses xorg
<deki_> mandrake uses moment
<mjg59> Right. It's more likely to be something to do with X than the kernel.
<deki_> ok
<deki_> i think there are problems with pci bus or similar
<deki_> that it does not have good thoughput
<deki_> XFree86-server-4.3-29mdk
<deki_> that is what i have on XFree
<deki_> mjg59, how to find out what is exactly wrong?
<deki_> mjg59, i think lots of things can be wrong
<infinity> deki_ : It you switch from the 'nvidia' driver to the 'nv' driver, does X's behaviour change noticeably?
<deki_> infinity, no
<deki_> infinity, not at all
<deki_> infinity, the funny thing: i have the same problem 
<deki_> with nv and nvidia driver
<deki_> when i open window
<deki_> or similar
<mjg59> deki_: The best thing to do is to file a bug and then have the discussion there
<deki_> it is draw from up to bottom
<deki_> mjg59, hmm
<deki_> mjg59, whatr should i write in a bug?
<infinity> deki_ : Decription of the problem, steps you've taken to diagnose/isolate it (mention that you used both X drivers, for instance, if that's the case), etc.
<deki_> infinity, ok, but i will try to compile custom kernel also and lets see if it would solve it to, maybe :D
<infinity> deki_ : Of course, if you can fiddle with some kernel options and make the problem go away, that information would also be helpful.
<deki_> infinity, ok thx
<infinity> deki_ : I'll give 20-to-1 odds it has nothing to do with preempt, but there could be something else kernel-side that's mucking you up.  Stranger things have happened.
<deki_> infinity, i like ubuntu very much , but all this problems drive me crazy
<deki_> infinity, right
<deki_> infinity, i think the same thing
<deki_> infinity, i have very exotic hardware
<infinity> deki_ : What sort of hardware?
<deki_> infinity, some kind of shuttle pc
<infinity> That's not that exotic.
<deki_> hmm ok
<deki_> moment
<deki_> i look at chipset
<infinity> lspci is helpful there.
<deki_> 0000:00:00.0 Host bridge: Silicon Integrated Systems [SiS]  740 Host (rev 01)
<deki_> #
<deki_> and os on
<deki_> everything is from sis
<deki_> and i am using PCI nvidia card
<infinity> Could be a PCI tuning issue, but given that many (MANY) people run Linux on those tiny systems, it seems unlikely.
<infinity> deki_ : Which nVidia chipset?
<deki_> 0000:00:02.5 IDE interface: Silicon Integrated Systems [SiS]  5513 [IDE] 
<deki_> infinity, geforce 4mx
<infinity> Okay, that should definitely not be the problem, then.
<infinity> The GF2 series (the 4MX is just a refreshed GF2) is probably the best supported anywhere, due to the sheer size of the install base.
<deki_> correct
<deki_> i think there is a problem with acpi <-- > pci bus
<deki_> and similar
<deki_> but i tryed already switch acpi off
<deki_> the interesting thing : the mandrake kernel does not have working acpi for my system
<infinity> Does it show as sharing any IRQs with ACPI turned off?
<deki_> infinity, how to see it?
<infinity> lspci -v
<infinity> Should show you the IRQ of each PCI device.
<deki_> no acpi is turned on
<infinity> Oh, then you'd have to reboot with acpi disabled. :)
<deki_> ok
<deki_> moment
* infinity gets busy learning leetspeak.
<Mithrandir> infinity: oh, php upstream switched to their natural language?
<elmo> ugh, why doesn't apt have "/distro" support for source
<Mithrandir> elmo: because nobody has forced mdz to implement it
<sivang> morning
<deki_> rew
<deki_> hallo
<deki_> how the acpi is switched off
<deki_> same problems are noticeblae
<deki_> mjg59, so what should i look ap again?
<deki_> root@deki:~ # lspci -v
<deki_> 0000:00:00.0 Host bridge: Silicon Integrated Systems [SiS]  740 Host (rev 01)
<deki_>         Flags: bus master, medium devsel, latency 32
<deki_>         Memory at d0000000 (32-bit, non-prefetchable) [size=64M] 
<deki_>         Capabili
<deki_> one lie for example
<deki_> Capabilities: [c0]  AGP version 2.0
<deki_> farewell
<deki_> all the time i live on my alone with the problem
<deki_> when i solve it i will come here and tell what was wrong
<deki_> bye
<infinity> Wow.  How melodramatic.
<jbailey> Sounds like something Roger Waters would write. =)
<zul> hey
<Mithrandir> jdub: the fluendo stuff is fairly easy to get going, but needs a bit more work to Just Work
<smurfix> elmo: promote keymapper? (console-data now depends on it)
<smurfix> build-deps, actually
<sivang> morning mako 
<elmo> smurfix: done
<smurfix> thx
<Mitario> mvo, ping
<smurfix> now console-data needs a build-retry. lamont?
<elmo> that'll happen automatically
<smurfix> ah, good
<mvo> Mitario: pong
<Mitario> mvo, got my e-mails? :)
<mvo> Mitario: yes, didn't answered yet because of other things got in my way
<Mitario> ok, no problem!
<bob2> dear gaim,
<bob2> you suck
<bob2> love,
<bob2> rob
<Mithrandir> bob2: what have you broken now?
<Simira> :)
<bob2> Mithrandir: I love the feature of uselessly refusing to reconnect automatically when my network comes back
<Simira> bob2: oh, that one... wondered about that myself
<bob2> it's much better to throw a dialog up on a random desktop and wait for me to manually click on something
<infinity> That's my favourite feature.
<Mithrandir> bob2: get a real network connection?
<Mithrandir> bob2: and you can certainly have it reconnect.
<Mithrandir> it does for me.
<lifeless> Mithrandir: real network connections come and go
<infinity> "Automatically retry" obviously means "retry once or twice, then throw an error uselessly"
<bob2> what infinity said
<Mithrandir> infinity: then it tries again after a while.
<bob2> it's been sitting here for 3 hours
<infinity> ... a long while? :)
<Mithrandir> yeah
* thom goes try new ia64 installer cd
<rburton> jdub: the wiki is on crack
<Nafallo> missing .torrent for array-5?
<elmo> is gnome-cups-icon really meant to poll every 1-2 seconds?
<Mithrandir> that's how cups work.
<Mithrandir> I think
<infinity> The polling interval seems a bit frequent, though.
<lamont> smurfix: thanks
* lamont looks at f2c
<zul> lamont, did you have a look at t-bone's email?
<thom> w00t, looks like i got an elilo config written
<lamont> not yet
<thom> yay whoever fixed elilo!
<zul> k cool
<lamont> thom: woohooo!
* thom waits for the fucken dhcp server to hand out an ip
<thom> "Configuring the base system"
<thom> laptop-detect on ia64
<Kamion> thom: I unbroke the thing I broke ... ;)
<Kamion> (thanks to T-Bone)
<thom> Kamion: :-)
<Kamion> thom: hm, can we get array-5 torrents?
<thom> yeah, probably
<Kamion> I forgot about those last night
<thom> can i have lunch first? ;-)
<Kamion> the files should all be there though
<Kamion> sure :) we're eating at the moment too
<elmo> Kamion: btw, we should probably either setup a third mirror dir on little for orcadas, or you should tell us you don't want to do that, so we can spec out some more disk for it
<elmo> 'cos atm it doesn't have the space to mirror cdimage.u.c fully, and the byhand-rsyncing is going to get old fast, not to mention being far too reliant on me or thom being awake
<thom> aye
* thom waits boredly for scrollkeeper
<Kamion> elmo: what's orcadas?
<Kamion> I can try to prune cdimage.u.c down some more if that helps
<thom> Kamion: aka torrent.u.c
<Kamion> I could take out old Array releases
<elmo> Kamion: I doubt it'll help given your doing dvd's on there, torrent.u.c only has 72Gb
<Kamion> like 1 and 2
<Kamion> yeah but I only ever keep two DVDs
<thom> hrm, page faults in firefox, lovely
<elmo> Kamion: well, I don't mind either way, I guess that's option (c) - but since (a) and (c) are on you, it's your call
<Kamion> elmo: how much space would I need to free up, roughly?
<mantiena> Kamion, will be language-packs other than en included into Ubuntu live CD ?
<Kamion> oh, does orcadas just need (a) ISOs being torrented and (b) the .torrent files? and does it need them in any particular layout?
<elmo> Kamion: yes, and don't think so for layout
<Kamion> mantiena: that class of issue was discussed at yesterday's tech board meeting; the answer is almost certainly yes, but the exact set is still up for grabs
<elmo> but thom's nominated torrent ho^H^Hexpert
<thom> s/expert/moron/
<elmo> hmm
* Kamion archives off arrays 1 and 2 in the meantime
<elmo> I wonder if we could somehow rsync only stuff that had a .torrent
* lamont groans.
<lamont> how can I have 400 _new_ messages (that didn't get autofiled, even)
<sivang> lamont: obviously you are subscribed to all too many mailing lists? ;-)
<Kamion> elmo: I could cope with the third mirror dir, I guess
<lamont> sivang: mailing lists get auto-filed
<Kamion> elmo: if they can just be hardlinks on little
<spiral> hello
<Kamion> or even symlinks
<elmo> yeah, sure I can do --copy-links or -H on orcadas
<spiral> I asked the question about this on #ubuntu, but it seems to be a devel problem... Why doesn't the ipw2200 module work on hoary since a recent dist-upgrade ?
<smurfix> elmo: keymapper needs yapps2 -- sorry, probably should've mentioned that
<bob2> spiral: that's not a devel problem
<bob2> if it used to work, file a bug
<spiral> bob2: I thought that it was, because it worked fine till recently...
<mantiena> Kamion, what does it mean "grabs" ?
<elmo> smurfix: meh, is someone aware of these late additions and/or are they feature goal related?
<smurfix> elmo: feature goal
<spiral> bob2: So I supposed something had gone wrong with last linux-restricted-modules
<sivang> lamont: spam then?
<Kamion> mantiena: I basically meant "still under discussion"
<sivang> lamont: (although spam should also be auto deleted)
<Kamion> elmo: yeah, the keyboard selector's a feature goal AIUI
<elmo> smurfix: done
<smurfix> elmo: I hope not to need any others. ;-)
<smurfix> elmo: s/hope/am fairly sure/ actually
<mantiena> Kamion, maybe anyone needs my opinion about set of language-packs to be included ? ;)
<Kamion> actually opinions are exactly what we don't need :-) we need a basis on which to be unbiased
<Kamion> mantiena: there's a discussion going on on ubuntu-devel@lists
<mantiena> Kamion, ok, thanks
<Kamion> but ultimately remember that an aim is to make it easy to produce local customised variants of the CDs
<Kamion> so really the only sane metric for what's the default is "how many people will it work for?"
<mantiena> Kamion, I think all language-packs, supported by debian-installer should be included ;)
<rcaskey_> Kamion: We should go by national weight
<rcaskey_> Kamion: Ordered by the weight of the average citizen
* ogra picks his can labelled "malaisian ubuntu love" and sprays around the room
<ogra> oops...wrong room
<Kamion> mantiena: not possible
<Kamion> mantiena: please do the sums :)
<HiddenWolf> kamion: it was a lot easier to boast about a 1cd distro when all those nasty languages wheren't there yet, right? ;)
<mantiena> Kamion, possible without openoffice locales included
<Kamion> HiddenWolf: actually they were ...
<Kamion> just not the language pack thing, which actually bloats stuff out a bit because all of main is in the language packs, not just base+desktop+ship
<Kamion> mantiena: in any case, since the discussion is on ubuntu-devel@lists, please have the discussion there rather than talking to me on IRC; I doubt I will be the one making the decision
<mantiena> Kamion, ok, sotry
<mantiena> s/sotry/sorry
<spiral> bob2: I just posted the bug on bugzilla
<Nafallo> It's not a possibility to package special langpacks with those sections mentioned above just for the cds?
<Kamion> bearing in mind that we want users to be able to install these easily post-installation, I think too much proliferation would be bad
<Kamion> and it would be very complicated to have to say "oh yeah, if you want to install any more packages and have them translated, you have to install this other package that the installer didn't do for you"
<Nafallo> yea, probably to much work.
<ogra> Kamion around ? 
* pitti successfully derooted at :-)
<ogra> i have a collegue on my desk with a partman question...
<ogra> eh, parted
<ogra> he asks if its possible to resize extended dos partitions with it (i neer tried, so i cant answer)
<Kamion> ogra: you mean extended partitions in a PC partition table?
<Kamion> (extended partitions are independent of DOS as such)
<ogra> so its an addition ?
<Kamion> what?
<Kamion> well, I guess they're called DOS partition tables, whatever
<ogra> extended partitions
<Kamion> what do you mean by "addition"?
<ogra> you said they are independent ? 
<Kamion> pretend I didn't say anything, it's obviously confusing you
<Kamion> :)
<ogra> lol, yup
<Kamion> I'm just looking at parted's innards now
* HiddenWolf huggles ogra
<ogra> ok, he just wants to know if its possible to resize them...
<thom> Kamion: you wanna generate them torrents then? :-)
<ogra> even if i'm confused/ing
<Kamion> ogra: anyway, it looks to me as if parted just writes out some extended partition table layout that works, and the user doesn't have to worry about it
<ogra> i shall tell you its a guy from ipswitch asking ;)
<ogra> -t
<Kamion> thom: hm, d'oh
<Kamion> ogra: i.e. you resize the logical partitions to what you want and let parted take care of where the extended partition goes
<ogra> ah, ok... i'll tell him...
<ogra> sorry, was a bit confusing around here with 5 ppl talkig to me simultaneously...on my desk
<seb128> thom: are you going to fix firefox or should I work on it ?
<seb128> thom: using bugzilla is getting really annoying with the jumping cursor
<thom> seb128: i'm doing a firefox build atm
<seb128> k, thanks :)
<amu> daniels: Kamion: todays liveCD, boot with german keyboard and got a 104/US 
<Kamion> amu: architecture?
<Kamion> keyboard type?
<thom> torrents should have love, now
<Kamion> (i.e. AT/USB)
<Kamion> what kind of love?
<amu> Kamion: i386
<thom> Kamion: well, downloadable via BT love
<Kamion> thom: array-5 torrents generated and syncing now
<Kamion> thom: how'd you do that before I created the metafiles?
<amu> Kamion: laptop
<thom> i musta rsynced just after you did them
<Kamion> possibly while I was doing them
<thom> possibly, redone
<Kamion> ta
<sivang> Kamion: Is the stuff you once told me about preseeing the d-i localechooser holds for casper as well?
* mvo leaves to play a bit of hockey, bbl
<pitti> Keybuk: ping again
<Keybuk> ello?
<pitti> I again have a conffile problem/question
<pitti> Keybuk: at currently ships /etc/at.deny as root:root 0600
<pitti> Keybuk: my derooted version ships it as root:daemon 0640
<pitti> Keybuk: however, if I just install the new deb, the permissions aren't changed
<pitti> Keybuk: thus I need to do some postinst magic
<pitti> Keybuk: do you think it is Policy conformant to just chown/chmod if upgrading from an earlier version than the one I currently do?
<Keybuk> yeah, ancient dpkg bug; doesn't change permissions on conffiles
<pitti> Keybuk: or will this interfere/do I have to check for dpkg-statoverride?
<Keybuk> I guess you'd have to check for statoverride
<pitti> Keybuk: I thought so
<pitti> Keybuk: but _if_ there is a statoverride, I must not change it, right?
<Keybuk> right
<pitti> Keybuk: however, at will fail to run then
<pitti> Keybuk: the jobs are still executed, but you can't call at/atq/atrm etc. as user any more
<pitti> Keybuk: thus if there's a statoverride, should the postinst just fail?
<Keybuk> how do you know?  maybe they statoverride to do their own de-rooting
<Keybuk> I'd just silently ignore it
<Keybuk> and if it fails, that's their own fault
<pitti> Keybuk: hmm, okay
<pitti> Keybuk: that won't be the common case anyway
<Keybuk> I'd doubt there's a single case
<pitti> Keybuk: yes, but if I don't check for statoverride, elmo will throw the next "you did not check, dude" bug at me :-)
<Kamion> sivang: see rootskel/src/sbin/env2debconf and the d-i manual for how that stuff works
<sivang> Kamion: k
* thom throws large rocks at bittorrent, idly
* lamont hands thom some cats for good measure
<zul> lamont: im good with what we were talking about in the email kernel policy and such
<zul> hey dilinger 
<lamont> zul: cool
<pitti> Hi dilinger
<jani> ogra, I'm here
<ogra> yup
<jani> so did you build a deb or ran lintian on the source changes file?
<jani> on the source changes both linda  and lintian are quiet for me
<ogra> jani: i ran it through pbuilder which does everything automatially (including lintian)
<jani> ooh, have not use pbuilder so far
<ogra> jani: i always try to behave like the buildd does when building a binary (after i looked at the files indeed)
<jani> will go and see about pbuilder now
<jani> but I suppose you got the warnings on the deb file
<jani> I remember having (and ignoring those)
<jani> so if upstream does not have a manpage should I write it?
<smurfix> lamont: console-data doesn't seem to get retried any more ..?
<jani> and 2) I suppose I'll need to see about quieting 'scripts not executable warings'
<ogra> jani: yup
<ogra> jani: sorry, i'm not that much into ruby to help on details beyond the packaging here :/
<jani> ogra, thanks everything you said so far was helpful :)
<lamont> smurfix: I requeued it once... checking
<jani> ogra: I'll see about fixing it then will return hopefully tonight :)
<smurfix> lamont: keymapper should now be actually installable in main :-/
<ogra> jani: yup, go ahead....;)
<metalikop> ogra: I have a lintian package that you may be able to answer
<metalikop> E: gnome-mud: python-script-but-no-python-dep ./usr/share/gnome/help/gnome-mud/C/monitor.py
<metalikop> I have python2.4-dev in my deps
<FF839> good morning everyone
<metalikop> why would i be reporting this error?
<FF839> is anyone here from the unbuntu laptop team, I have a question about HP laptops, and if any support the the hardware exists yet...
<tseng> FF839: best way to check hardware support is to grab an array5 livecd
<tseng> FF839: the current testing livecds have the same hardware detection as the installer
<lamont> smurfix: kicked yet again
<tseng> FF839: in the future, this is an #ubuntu question.
<FF839> ah ok. I understand. thank you for the help tseng, even if i was asking in the wrong chan.
<ogra> metalikop: erm, what does this file in the gnome help section ?
<metalikop> honestly, I don't know why that's in the help section.
<metalikop> Perhaps that's a question for the upstream packager
<metalikop> ogra: It's a demo script for Gnome-MUD
<ogra> i guess so...
<metalikop> I can't see any other place to drop that other then help
<ogra> did you put it there ?
<metalikop> A demo Python script for Gnome-MUD with PyGTK which adds a hello world button and some input/output filters along with a status display to show health and mana levels for a CD mudlib based LPmud.
<metalikop> ogra: no, that was in the debian/unstable package as well.
<ogra> ah
<rburton> so i'm trying to boot the hoary live cd
<rburton> and it's spinning on scanning for wireless interfaces
<rburton> and not finding my wireless interface
<rburton> dmesg is showing eth0: Association failed
<rburton> which is probably as it's WEPd
<dilinger> pitti, zul: hello
<trukulo> jdub, u there?
<ogra> he is asleep
<elmo> smurfix: I assume this console-keymaps-tree is destined for main too?
<trukulo> ogra, u talking to me ?
<ogra> yup
<ogra> trukulo ^
<trukulo> :) thx olivier
<trukulo> i only wanna ask him about templates in new file in warty
<ogra> trukulo: i'm not french ;) (drop the second i)
<trukulo> ogra, ok, then oliver (benji)
<haggai> oohh!  openoffice.org2_1.9.76-0ubuntu4_20050217-1238-i386-successful
<trukulo> haggai, cool !
<ogra> yay yay yay !!!
<sivang> haggai: woooooooooooo
<tseng> haggai++
<trukulo> ogra, do you know anything about empty templates when you use right button on desktop and new file?
* haggai uploads openoffice.org-debian-files
<haggai> 2
* sivang sees how about 50% of openoffice hebrew localization problem just fade away...
<haggai> sivang: erm, langpack isn't finished yet
<trukulo> sorry, i think is for #ubuntu , but if problem persist would be good to have templates working on hoary
<ogra> trukulo: there is a dir  to put them in....
<trukulo> ogra, can you give me a link to read please?
<sivang> haggai: sure, but the rtl improvements are in the main oo packages I think
<trukulo> i'm looking in google
<ogra> trukulo: got nothing hand  atm...wait
<trukulo> but i think it would be very good to have templates installed by default
<trukulo> that's the thing
<haggai> sivang: ah right, well please let me know if you find problems
<ogra> trukulo: yeah... we need only empty files of a mime type in the templates dir...and they will show up....
<sivang> haggai: as soon as you the pkgs are done for downloading, I will throw some tests :)
<smurfix> elmo: It's an udeb, along with the other console-keymaps-whatever udebs. So ...
* ogra applauds haggai
<trukulo> ogra, so , perhaps we can have tempaltes for writer, calc and impress, at least
<smurfix> Gah, I should know by now that this ppc thing is actually named "powerpc". :-/
<ogra> trukulo: ah, its in the "places" menu in nautilus....
<trukulo> i'm in warty
<trukulo> there's no place menu
<trukulo> sorry about the noise
<ogra> trukulo: if you write a patch for nautilus to have these files there, it will probably get included, ask seb128 if its not to late, he is responsible for the package....
<lamont> smurfix: is this a known error?
<lamont>  /usr/bin/fakeroot debian/rules binary-arch
<lamont> make: *** No rule to make target `decision-tree-powerpc', needed by `decision-tree'.  Stop.
<trukulo> ogra, we only need a package to put emplate files htere, isn't it?
<smurfix> lamont: already uploaded a new version
<lamont> doh
<smurfix> lamont: see my comment ten minutes ago ;-)
<seb128> ogra: no, already discussed that's local's admin decision to provide templates
<ogra> trukulo: see seb128 ....
<lamont> smurfix: heh
<thom> bah. i just turned pango off in firefox and *now* i get the text entry weirdness
<thom> i hate you all!
<trukulo> seb128, but users?
<sivang> thom: eheh, we LOVE you thom :)
<trukulo> at lesat, a package they can install
<smurfix> lamont: Yeah. I figure that if I only make stupid mistakes like this which don't actually hurt anybody, I'll be OK. ;-)
<lamont> lol
<trukulo> then it's admin decission
<sivang> seb128: do you have any idea about the vaugeness of #1369 and #1368 ?
<seb128> trukulo: feel to do whatever on your box if that's the question :p
<seb128> thom: nice :)
<seb128> thom: does it fix it in epiphany ? :p
<sivang> guys, selecting "RC Bugs" in bugzilla is what I need to do to view all release critical bugs?
<seb128> trukulo: creating some templates in your box should be easy, you don't need packages for that
<Kamion> metalikop: is it #!/usr/bin/python or #!/usr/bin/python2.4?
<thom> seb128: nope
<trukulo> seb128, ok, ok, i only ask because users are very dumb
<trukulo> i have no problem about it
<thom> seb128: with the version in unstable, neither epiphany or firefox does it for me
<seb128> :/
<thom> hrm. this is getting weirder by the second
<Kamion> elmo: console-keymaps-tree will be depended on by smurfix' keyboard selector eventually, even if it isn't seeded yet
<thom> just purged and reinstalled ephy, and now firefox doesn't do it but ephy does
<thom> WTF?
<seb128> good question 
<thom> i'm gonna have to binary search all the firefox patches and work out what is causing this
<thom> seb128: guess you'll have to use firefox till i work out what's going on ;-)
<seb128> no way
<seb128> I guess I'll stop using bugzilla till you work you what's going on :)
<seb128> should I reassign my bugs to you during this time ? :p
<sivang> LOL
<thom> i'll just blame gtk and reassign all my firefox bugs to you then ;-P
<seb128> bah
<seb128> since gtk is already reassigned to you by the previous action I don't care :p
<thom> so you're saying you would swap gtk and firefox?
<thom> lets go!
<seb128> no no no, I just offer you gtk 
<seb128> I'm nice, I don't ask any favor/firefox :)
<seb128> you can take it for free
<thom> no, i couldn't
<seb128> bah, I should stop talking and let you fix firefox so :)
* seb128 bbl 
<lamont> 'lo T-Bone 
* lamont tries to remember if it's his turn in the barrel this week
<T-Bone> lamont: howdy buddy! :)
<lamont> prolly
<T-Bone> lamont: as you wish. If you want to upload today it's better you handle it. My set of patch isn't ready yet
<lamont> daniels around?
* T-Bone ^5s Kamion for fixing Array5 ;^)
* T-Bone laughs at lamont's emails :)
* lamont makes a note to go fetch array 5 sometime soon
<lamont> T-Bone: glad to channel irc for you any day, buddy. :-)
<T-Bone> LOL. I owe you some :)
<T-Bone> ok let's go for wiki editing then. I'll do the patch-monkey afterwards
<seb128> elmo: around ?
<mantiena> seb128, you are gnome-panel ubuntu maintainer ?
<seb128> correct
<mantiena> seb128, I have one question - why "Log out" is in System menu (previously named Desktop) while "New Login" is in "Applications"->"System Tools" ?
<seb128> because "log out" is a system feature
<seb128> and "new login" is an application
<seb128> you can argue que "New Login" is a bad title :)
<lamont> t-bone/zul: I'm thinking we'll play the other schedule this weekend...  I'll work on collecting patches over the next 24 hours say, and then try to have a kernel built and maybe even tested somewhat by saturday, then finish testing on monday and be ready to upload then.  Thoughts?
<mantiena> seb128, "New login" is a featue from users view
<zul> sounds good to me i should be home tonight to do some more patches 
<mantiena> "New login" is good title
<mantiena> just in wrong place
<seb128> I don't think so
<mantiena> seb128, Windows XP has same feature
<T-Bone> lamont: fine by me. Most of my processing power will be available starting tomorrow noon. Mind i'll probably have a significant changeset :P
<mantiena> seb128, "Take screenshot..." is also an application
<mantiena> bug from users view is a system feature
<seb128> mantiena: not really
<seb128> right, but "new login" is really an app, it doesn't work as you expect/as winXP
<seb128> ie: how do you switch back to the previous user ?
<seb128> (ctrl-alt-F<n> is not obvious for an user)
<mantiena> seb128, simmilar like in windows XP - just logout from newly logged user and you are back into previous user ;) anyway, I just want to make ubuntu more consistent and user-friendly
<seb128> no
<seb128> you can switch without closing on winXP
<seb128> here if you don't know the ctrl-alt-F<n> you can't
<mantiena> seb128, implementation doesn't matter
<seb128> it does, if that's not ready that should not be exposed
<rburton> wasn't jimbob working on a user switching applet?
* HiddenWolf would love to see that. 
* mantiena too
<seb128> rburton: dunno
<rburton> it was more a retorical question
<rburton> the answer is "yes"
<seb128> yeah, and the dunno is "link ?" :)
<mantiena> ;)
<rburton> i can't find it
<rburton> how annoyin
<lamont> seb128: I still think you should use evolution instead of apache.  :-)
<Nafallo> I've seen mails on -devel about rt2500. is there a status on that mather?
<seb128> lamont: gni ?
<zul> Nafallo: is there a bug open about it?
<lamont> seb128: nm
<Nafallo> zul: probably not.
<zul> Nafallo: can you open one thanks
<Nafallo> zul: my concern is more NOT to have it ;-).
<Nafallo> zul: there is a rebuild of that driver going on...
<zul> gah..ok ill have to check the mailing list then
* lamont giggles
<lamont> smurfix|asleep: 3+1=4
<lamont> ah, and so it does
<Kamion> hmm, I think there may be a lot of drivers that do PCI device detection in non-hotplug-friendly ways
<Kamion> #6681 doesn't seem to be unique judging from the length of modules.pcimap
<T-Bone> Kamion: welcome to my world :^)
<Kamion> heh
<HiddenWolf> T-bone: My thoughts and prayers go with you. Now fix it. ;-)
<mantiena> seb128, btw, I'm not only one, which thinks, that "New login" should be in same place with logout, look at http://bugzilla.gnome.org/show_bug.cgi?id=102707
<Kamion> maybe for hoary we should extend hotplug to support a pci.handmap, and just copy a big pile of stuff from discover1-data
<lamont> "Funeral benefits  (one time only)"
<T-Bone> Kamion: that would certainly ease up a lot of things.
<HiddenWolf> kamion: any side effects? 
<T-Bone> Kamion: it's not likely that all hotplug-unfriendly drivers are gonna be fixed tomorrow... Some of them are very evil toward hotplug-friendlyness
<T-Bone> lamont: heh :)
<seb128> mantiena: no offence but you still find some people wanting the same stuff as you
<Kamion> HiddenWolf: well, that's part of what I'm wondering. I wouldn't think so ...
* HiddenWolf is dumb and equates added code to slower boot, but can't really give it a lot of thought. I've got a bit of a date ;)
* HiddenWolf goes off to powder his nose
<T-Bone> hmm. so my G5 is running 'on battery', heh?
<T-Bone> how comes i can't find the boot messages in the logs :P
* lamont would like to know why his laptop started believeing that the battery is dead all the time, too
<dredg> cos it's a g5 and suffers from apple 'you don't need to know' syndrome, despite the os it's running? :)
<T-Bone> dredg: i doubt that's the problem, alas :P
<zul> because ppc suck?
<Kamion> thpppppppt
<zul> heh
<T-Bone> zul: it's so obviously the remark of some jealous guy not having the extraordinary chance to 0wnZ such a fantastic hardware, I won't say anytning about it :^)
* T-Bone runs away laughing to hell ;D
<zul> This is what I saw:
<zul> T-Bone: blah blah blah :^)
<dholbach> hai
<dredg> T-Bone: or refuses to spend silly amounts of cash on a shiny piece of plastic that reduces masculinity to nil in it's male owners? :)
<Kamion> them's fightin' words
* dredg laughs
<T-Bone> Kamion: no need to fight. Supremacy is overwhelming. All his bases are belong to me now ;^)
<T-Bone> Kamion, lamont : how is it acceptable to make SCSI builtin on ia64?
<T-Bone> actually it's about scsi_mod only, afaict
<lamont> T-Bone: both of my ia64 boxen have scsi
<T-Bone> lamont: yeah. I'm just asking for 'policy' and/or if it may break things in d-i
<T-Bone> if i get a clearance from Kamion I guess that's alright :)
* T-Bone is preparing -20 which will probably be -21 anyway
<lamont> well, if you make it not a module (either always there or always gone, then you have to take itout of the d-i module list, that's for sure...)
<lamont> hrm... move that ) left a few inches
<T-Bone> yeah
<lamont> heh.  my mirror only has 2 more linux-image debs to go, and then it gets to catch up on the other 116 files that were out of date a couple days ago
<lamont> actually, that's as of 16 hours ago.
<T-Bone> hehe
<Kamion> T-Bone: not bothered either way as long as the module list's updated
<T-Bone> Kamion: roger that. Fixing the kernel. Will test array-5 in a minute, then make sure the new kernel works fine
<lamont> T-Bone: testing array 5 on which arch?
<T-Bone> ia64
* T-Bone points lamont at the other window btw ;)
<zul> has anyone tried pearpc with the ubuntu live cd?
<zul> or am i just on crack
<T-Bone> aren't you always? :)
* T-Bone hides!
<zul> shaddup
<T-Bone> hehe
<T-Bone> truth told, i should have said "aren't we always?", to be fair :)
<jani> anybody knows whether lintian's complaints about missing exec bit on scripts with shebang..
<jani> ..are ok for files in /usr/lib ?
<crimsun> they're fine; see the changelog for 1.23.1
<crimsun> they've been demoted to warnings iirc
<jani> I know they're warnings, but I was told elmo does not accept packages with warnings in them :)
<crimsun> + [FL]  Demote executable-in-usr-lib-menu to warning as executables are supported (but seldomly used) (Closes: #254498)
<jani> so is a package with those warnings OK?
<ogra> crimsun: usr-lib-menu
<crimsun> ogra: right, I just noted that.
<jani> oh no, not menu, that's something else.
<jani> I mean having /usr/lib/python/xmlmodule.py (fictive)
<jani> witha shebang line but no exec bit
<jani> I'll look up the reference I saw about it on google.
<zul> mjg59: i made a clean patch of your acpi stuff you sent me yesterday
<sivang> sladen: where would you say would be a good place for the hd swap order page on the wiki?
<jani> http://www.talkaboutsoftware.com/group/linux.debian.maint.python/messages/629.html
<jani> OTOH I saw another post by mdz saying something else
<jani> http://lists.debian.org/debian-mentors/2004/10/msg00277.html
<sivang> seb128: user switching applet? that is in switch a user and stay in gnome-session?
<sivang> seb128: (reading through the backlog)
<ogra> jani: i would go with the latter
<crimsun> agreed.
<jani> ogra:is it ok then to change permission on files, even though those changes are not reflected in the diff?
<ogra> jani: but i dont know enough about ruby to decide if the program still works afterwards :-P
<jani> or do I change them from a script/makefile
<crimsun> that changes will be reflected in debian/rules, no, if one chmods it/them?
<jani> ogra: it's the same as with any shebanged script it can be run with ruby scriptname :)
<ogra> citing mdz: Just make them non-executable and remove
<ogra> any #! line. 
<jani> ok will do that, then reupload them.but now I'll have to go eating :)
<ogra> jani: ok, then do the above.... thanks for the info ;) (i really never saw ruby internals)
<robertj> sivang: I would think user switching is running multiple X sessions on the same box
<sivang> robertj: hmm, can that be achived? I thought that X wouldn't run more then once
<sivang> robertj: (on a given system)
<robertj> sivang: AFAIK it works ok if your video plays friendly, I could be wrong
<rburton> sivang: i do it daily
<rburton> it's trivial
<robertj> I thought Lindows and Xandros was supposed to do it
<ogra> sivang: it can run on different consoles
<sivang> rburton: ok, now you got me interested :) did you write an howto on the wiki ?
<ogra> DISPLAY=0.0 DISPLAY=0.1 etc
<rburton> sivang: default X is on :0. just create another on :1, :2, etc
<rburton> sivang: how else would Apps->System Tools->New Login work?
<sivang> rburton: bah, I probably overlooked that in the menu :)
<sivang> rburton: wow cool!
<sivang> rburton: so, is there a switch user applet on the workd? is it going ot be gnome upstream?
<rburton> i thought there was one
<rburton> but i can't find it anywhere
<tritium> The second user doesn't get sound, though, with New Login
<rburton> tritium: one day when esd is dead it will work fine
<tritium> rburton, that will be excellent
<Kamion> jani: elmo does apply common sense to lintian warnings - some of them are just bogus
<T-Bone> Kamion: ok. Array-5 installed fine except for the usual aptitude error after reboot. ubuntu-desktop is in 'unrecognized tasks'
<Kamion> right, the unrecognized bit is like that on all architectures, I've been meaning to fix that since pre-warty but just haven't got round to it ...
<T-Bone> Kamion: it also complained about unauthentified packages when i tried to install by hand
<rburton> Kamion: are you the man to poke about live cd failures?
<Kamion> T-Bone: hm, there seem to be some random failures in that regard, I haven't got to the bottom of them yet
<Kamion> rburton: for this week while mdz's away, yes
<Kamion> though I'll flounder around for a bit 'cos I only know the live CD in broad outlnie
<Kamion> outline
<rburton> Kamion: i tried it today, but the wireless network detector thing was just spinning
<rburton> this is more a d-i thing though i guess
<rburton> dmesg was reporting some error i can't recall about failing to connect to the wifi network
<rburton> not a surprise, i've got WEP
<rburton> "scanning for networks... " over and over again
<Kamion> rburton: there's a bug open about that; mdz asked me to have a look at network configuration in general in the live CD this week, so I'll probably have a crack at it tomorrow
<Kamion> a DEBCONF_DEBUG=20 syslog trace would be cool though in case I can't reproduce it
<rburton> Kamion: excellent. i've got a copy of the iso on my machine now so if you think it's fixed shout and i can rsync it again
<rburton> i presume i add that to the boot line?  (i.e. linux DEBCONF_DEBUG=20)
<Kamion> no, I wouldn't think it's fixed
<Kamion> 'live DEBCONF_DEBUG=20', but yeah; you then have to figure out how to get /var/log/syslog out with no network
<rburton> hm, pencil and paper i guess
<rburton> fun
<Kamion> yeesh, no, it'll be way too much for that
<Kamion> I'm happy to look at it tomorrow, which might be faster :)
<rburton> i meant shout if you think you found the problem and a new image is built
<rburton> it appears (without a single look at the code) to be not handling the case where there are networks but it cannot connect
<Kamion> ah, ok, I see
<Kamion> basically we preseed part of network configuration to try to make it go through noninteractively where possible
<Kamion> evidently the result of how we've done it is that there's a corner case where it tries to ask a question which is preseeded to something that causes it to try to ask the question again which is preseeded to ...
<rburton> fun
<Kamion> there was a netcfg change upstream recently which may well help with that, if I merge it
<Kamion> but I need to try it out
<rburton> i was looking forward to trying hoary too
<T-Bone> can somebody educate me about how one's supposed to add a fsckin hyperlink to a plone page??
<zul> Uhhh...no
<Kamion> what markup type?
<Kamion> (there's a radio button at the bottom)
<Kamion> http://zwiki.org/Editing is probably a good place to start for help
<T-Bone> Kamion: thx that helped. BTW, finished ubuntu-desktop install. 60Hz screen (while it was better on previous test ISOs I had). A fix in xorg.conf and I'm done ;)
<Kamion> cool
<Kamion> -> daniels :-)
<T-Bone> for the vertrefresh thing? :)
* Kamion makes germinate-pkg-diff actually work when installed from germinate.deb
<Kamion> for anything to do with X, pretty much ...
<T-Bone> ok
<T-Bone> Kamion: remaining fixes are the ubuntu-desktop thing (i guess i can't help there) and the Fusion driver, and I guess we'll be pretty much done with it :)
<T-Bone> Kamion: do you think there's a chance we make it in time for Hoary?
<Kamion> T-Bone: if the fusion driver could be done with pci.handmap or similar, that would help a lot
<Kamion> for the ubuntu-desktop thing, I can work around it given a bit more work on debian-cd
<Kamion> namely make it recreate boot.img with new bootloader arguments rather than just using the one debian-cd ships - and that's needed anyway for other things
<Kamion> actually I got the deps for that installed on little a couple of days ago, should do the work now
<T-Bone> ok
<T-Bone> Kamion: basically i suppose fusion can be done with pci.handmap since discover manages it just fine
<Kamion> ok
<T-Bone> Kamion: but you'd better tell me now, because i'm about to make it builtin the next kernel release :P
<T-Bone> Kamion: and you'd probably want to tell me how that pci.handmap is supposed to work as well :)
<Kamion> T-Bone: ok, how about you save the work you've done so that it isn't lost, and I work on implementing pci.handmap tomorrow?
<Kamion> well see how usb.handmap works
<Kamion> it's stuff for drivers whose IDs the kernel doesn't expose through modutils yet
<trulux> hey
<Kamion> SuSE have a pci.handmap patch apparently ...
<sivang> Kamion: mdz is off for a week from now?
* T-Bone reads SuSE's "coldhotplug" page
<Kamion> sivang: yes
<Kamion> well-deserved holiday
<sivang> ofcourse :)
<dholbach> i currently review metalikop's gnome-mud--package - what would be the appropriate way to resolve "E: gnome-mud: python-script-but-no-python-dep ./usr/share/gnome/help/gnome-mud/C/monitor.py"  (an example script that shouldnt be executed at all)?
<Kamion> dholbach: what is the #! line?
<dholbach> Kamion, #!/usr/bin/env python
<Kamion> and the dependency is on python2.4?
<ogra> its an example script
<Kamion> the python2.4 package does not provide a /usr/bin/python; you need to depend on python to get that
<dholbach> yes
<ogra> in the documentation
<Kamion> yes, but example scripts should still work out of the box
<ogra> ah, that was the logic i was missing :)
<Kamion> either change the example script to python2.4, or change everything else to python and depend on python, or depend on both python2.4 and python
<Kamion> pick one :)
<dholbach> Kamion, thanks a lot
<Kamion> sigh, I wish my link to little were a bit faster
* T-Bone curses gamin
<sivang> thom: any oppinion on #6590, maybe just disabling pango is the workaround? (I've seen everything is pretty well after that)
<T-Bone> that bloody shit is sucking 90% of cpu during kernel builds :P
<Kamion> ok, I think I can work around the ubuntu-desktop thing on ia64 now
<T-Bone> Kamion: cool!
<Kamion> now that I have figured out how to pick boot.img apart far enough to replace the bootloader configuration file
<Kamion> and this will make the live CD work without runes on ia64 too
<T-Bone> yay!
<T-Bone> all hails Kamion, mighty magician of the bootloaders ;)
<Kamion> sometimes I wish there would be just one bootloader
<Kamion> and then I imagine what that bootloader would probably end up looking like
<Kamion> and then I vomit
<Kamion> and then I feel better again
<mjg59> zul: Cool, thanks
<T-Bone> if i may suggest something, i dunno what it's used for, but gamin looks much too me like a real piece of sh*t. As soon as disk intensive stuff happens, the slowdown is doubled by that silly program
<Kamion> talk to jdub about gaim
<Kamion> er, gamin
<T-Bone> will surely do. And remove it from my boxes :P
<T-Bone> Kamion: try not to think too often of bootloaders then, for your own sake :)
* T-Bone goes grabing some food. bbiab
<Kamion> T-Gone: some of the problems gamin's had are due to inotify, which I think has recently been disabled
<Kamion> and gamin has gone back to dnotify, if I remember correctly
<metalikop> Any devels or MOTUs here that can approve a package/me for MOTU status?
<ogra> Kamion: got a second ?
<ogra> for me...not for a review....
<Kamion> ogra: sure
<Mitario> hi everyone
<sivang> mjg59: ping
<mjg59> sivang: Hi
<sivang> hey Mitario 
<sivang> mjg59: what's up? just finally installed new xorg pkgs, and laid off that buggery nvidia proprierity module :)
<sivang> mjg59: so, /etc/acpi/sleep.sh to send my inspirion to sleep?
<mjg59> sivang: Yeah, or fn+escape
<mjg59> (With luck)
<sivang> mjg59: ok, let's try ;-) don't I have to install *anything* ?
<Mitario> jdub, here?
<mjg59> sivang: No, only thing you need to do is enable sleep in /etc/default/acpi-support
<sivang> mjg59: had anyone been working on gmoem integration for this? I'd be interested.
<sivang> s/gmoem/gnome/
<mjg59> sivang: Yup. I thought it ought to work now, but I can't get it to.
<mjg59> I'll hassle seb next time he turns up.
<sivang> mjg59: ok, if there anything you woudl like to get done, or somebody poking at let me know bug numbers or source pkgs to dwelve into. I think it may not be that hard to itnegrate in into the desktop.
<zul> wohoo...22 more minutes and im going home
<mjg59> sivang: The infrastructure exists, it just needs to be hooked up into the ui with gdm support
<mjg59> But nobody's told me what the current state of that is, so.
<sivang> mjg59: ok, it WORKED!
<mjg59> sivang: Rock
<sivang> mjg59: RAWKING!!!!!!!1
<mjg59> I accept payment in money, beer or love
<sivang> mjg59: I can love you and buy you a beer if we meet :)
<mjg59> Hurrah!
<sivang> mjg59: do you need fanboys?
<rburton> mjg59 has plently of fanboys
<mjg59> I have some fanboys already, but I always accept more
<T-Bone> yummy "/bin/sh: line 1: 8259 Illegal instruction   ld -r -o crypto/tea.ko crypto/tea.o crypto/tea.mod.o
<sivang> mjg59: ok, then you can add me to the list 
<T-Bone> Kamion: i'm running -19, obviously this doesn't prevent gamin from screwing me :)
<T-Bone> lamont: you told me you've already seen those?
<sivang> mjg59: btw, it doesn't suspend when I close the lid
<sivang> mjg59: only when I manually execute the sleep.sh script
<mjg59> sivang: Yeah. We don't currently make lid events do suspend.
<lamont> T-Bone: SIGILL on ppc?
<lamont> yeah.  those are "normal".
<lamont> fix that. kthxbye
<mjg59> lamont: What's the timescale for -20?
<lamont> there's a bug in bz for it
<T-Bone> *sigh*
<sivang> mjg59: when I come back from suspend, can the screenserver password dialog be turned off?
<mjg59> sivang: Yeah. /etc/default/acpi-support
<lamont> mjg59: thinking monday-ish unless someone really screams - with the abi event, I want to scrape everything we can for maximum bug-fix winning
<T-Bone> lamont: how am i supposed to resume the build without rebuilding everything then? -nc won't do i suppose?
<sivang> mjg59: ah cool, and the lid thing is just hooking an event right? how would I do that if I wanted to?
<mjg59> lamont: Ok - are you grabbing those PPC sleep patches?
<lamont> T-Bone: in the data center, we just give it back
<mjg59> sivang: Edit /etc/acpi/lid.sh
<lamont> mjg59: certainly
<mjg59> lamont: Sweet
<lamont> will grab them tonight or tomorrow
<mjg59> lamont: If those work, I have another patch for adding suspend to disk for PPC
<T-Bone> lamont: i think zul already had. I was about to grab them but he told me he did
<T-Bone> lamont: i'll revert the Fusion change as well, Kamion has a better idea with pci.handmap
<zul> the powerpc ones?
<T-Bone> zul: yeah
<zul> T-Bone: nope i didnt 
<T-Bone> zul: you told me you did 'a little'
<sivang> mjg59: what does HIBERNATE_MODE=shutdown
<sivang> mjg59: mean?
<zul> the one that mjg59 sent me
<zul> T-Bone: sorry didnt make it clear
<T-Bone> zul: that's already something then. Let's have lamont not do extra unnecessary work :)
<zul> ok
<sivang> mjg59: also is it possilbe to use MODULES="" to include the nvidia module or is it's non acpi compliant nature prevents this?
<mjg59> sivang: It means that when you suspend to disk, it uses the standard Linux shutdown mechanism to power down the machine
<sivang> mjg59: ok, and "platform" means I use acpi's ?
<mjg59> sivang: You might actually be able to get away with the latest propriatory nvidia drivers
<mjg59> Yeah, platform means Use ACPI to cut the power
<mjg59> The other alternative is reboot, which is mostly good for testing
<lamont> zul: were you working on mjg59's sleep patches?
<Kamion> T-Bone,lamont: ok, I think I've made debian-cd fix up ia64 bootloader configuration properly on the fly, so either tomorrow's live CD or the one after that should work without runes
<lamont> Kamion: way cool
<zul> lamont: that is correct..
<Kamion> T-Bone,lamont: also, I've made the ia64 CD use the "ia64-hack.seed" preseed file, which installs the ubuntu-desktop package rather than the ubuntu-desktop task
<lamont> zul: then I won't worry about them.
<zul> lamont, ok fine :)
<Kamion> that should work around the lack of architecture-specific Task: headers for now, although I'd rather this hack went away for hoary
<zul> lamont: this patch -> acpi-20050211-2.6.11-rc4.diff
<lamont> mjg59: and these are different from the tosh acpi driver that edd gave fabbione?
<Kamion> hm, actually I'll build a new live CD now, even though the boot screens will be wrong
<sivang> mjg59: I'll talk to thom and seb about the desktop integration of this, maybe it would be my way to love the patches back some.
<T-Bone> Kamion: cool. Please let me know how you want to integrate the handmap stuff
<Kamion> I'll ponder that overnight
<mjg59> lamont: That patch has nothing to do with the Toshiba driver
<lamont> woot
<T-Bone> Kamion: awesome!. I'll be fully available tomorrow 13 CET ;)
<mjg59> lamont: The acpi- patch fixes stuff on a small number of machines (notably battery detection on the Panasonic R1). The PPC stuff adds sleep support for newer Mac laptops. The Toshiba ACPI stuff makes hotkeys work on some Toshibas.
* T-Bone wonders if that would fix the strange bugs he's seeing on his g5
<mjg59> T-Bone: Mm?
<T-Bone> mjg59: the silly box seems to think it's running on battery. Fsck says 'not fscking: on battery" at boot or something.
<sivang> mjg59: shocked I just read your commentm about the nvidia drivers, did they add acpi compliance?
<T-Bone> the fact is I can't find the boot messages in any logfile, wonder how's that
<Kamion> http://weddell.buildd/%7Ebuildd/livecd/livecd-current.cloop:
<Kamion> 21:20:37 ERROR 403: Forbidden.
<Kamion> lamont?
<mjg59> T-Bone: On a G5 desktop? Mad.
<mjg59> Sounds like a fsck bug.
<T-Bone> mjg59: just as you say :)
<sivang> mjg59: hmm, hibernate seem to not work, do I need to enable it also / other ?
<mjg59> I don't think my stuff will touch that
<mjg59> sivang: You need to edit /etc/mkinitrd/mkinitrd.conf and set RESUME
<T-Bone> mjg59: there are a couple of other weirdness. Sadly. nothing gets logged.
<mjg59> Then rebuild your ramdisk
<mjg59> sivang: if you've got a hibernate button, it's unlikely to work
<T-Bone> is that a policy, do i have to toggle some magic option to get boot scripts message logged?
<sivang> mjg59: no, I tried ./hibernate.sh
<sjoerd> T-Bone: you pmu procfile will show that you've got no ac power and no battery.. the init script probably only looks at the ac field then :)
<T-Bone> sjoerd: good hint ;)
<lamont> Kamion: hrmpf
* lamont checks
<Mithrandir> mjg59: isn't it enough to set resume in menu.lst?
<lamont> Kamion: ew.
<lamont> last successful livecd rootfs build on ia64 was 20050211.3 - and the job to remove old images has removed it...
<Kamion> d'oh
<lamont> choices: use what you already have, or (2) wait while I figure out why it's busted
<sivang> Mithrandir: why do you need to set up resume and menu.lst?
<Kamion> I don't already have anything ...
<Mithrandir> sivang: on the kernel command line?
<Kamion> unless I pick it out of a previous image somehow
<Kamion> unfortunately this breaks powerpc CDs as well due to alphabetical ordering :)
<sivang> Mithrandir: I didn't know it is needed ;-) sorry, this is the way resume is implemented?
<Mithrandir> sivang: I thought so, at least
<lamont> Kamion: fresh build running
<mjg59> Mithrandir: That will also work
<lamont> Kamion: it might even work.
<mjg59> Mithrandir: But setting it in mkinitrd.conf is probably how things will be shipped
<Mithrandir> mjg59: ok
<Kamion> lamont: was it just a dirty chroot? error message suggests that ..
<Kamion> boot script logging> /etc/default/bootlogd
<lamont> uh, yeah
<lamont> machine went disk-full the other day...
* T-Bone wonders how a regular user is supposed to report boot problems with bootlogd disabled bydefault :P
<lamont> and something had /dev open in the chroot
<lamont> s/open/busy/
<T-Bone> bootlogd: ioctl( <blah>|TIO_CONS) failed
<Kamion> lamont: ah, oops
<T-Bone> i suppose this is the issue
<Kamion> er, a regular user can press ctrl-s :P
<sivang> T-Bone: rather phylosophical question :)
<Kamion>   * Do not run bootlogd by default - it's a bit to experimental for
<Kamion>     the "stable" release. Can be turned on manually (closes: #217582)
<lamont> EGRAMMAR
<zul> right ill be back later...going home now
* Kamion wonders whether to wait for the live CD build or go to the pub
<Simira> Kamion: wait for the live CD build at the pub?
<Kamion> well I'd like to kick off my part of it so that somebody can try it out so that I can fix stuff later ...
<Kamion> oof, firefox segfaulted ...
<Kamion> Setting up mozilla-firefox (1.0+dfsg.1-2ubuntu5) ...
<Kamion> Updating mozilla-firefox chrome registry.../usr/sbin/update-mozilla-firefox-chrome: line 95:  3455 Segmentation fault      firefox-bin -register >/dev/null 2>&1
<Kamion> E: Registration process existed with status: 139
<Mithrandir> I'm sure thom loves you for that
<thom> joy
<Kamion> (ia64)
<Mithrandir> I'm sure he loves you even more for that
<thom> really? my ia64 installed firefox ok
<sivang> hey seb128, what's the status of power managment integration in the desktop? I'm interested in giving a hand.
<seb128> what do you mean ?
<sivang> seb128: where are you with it? have you done the patch for the logout menu to offer hibernation/ suspend this kind of stuff.
<seb128> no
<seb128> but afaik there is only the logout dialog to handle
<seb128> that's not a ton of stuff
<sivang> seb128: do we have a bug report about it?
<seb128> but gnome-cups-manager could probably use some hands :)
<seb128> I'm taking care of it, don't bother
<seb128> I know what to do and how to do it
<sivang> seb128: oh sure :) , I just replied to the golks there, I couldn't really understand if they were using a domain controller, what's there setup layout etc.
<sivang> seb128: [taking care of]  you meant the power managment stuff?
<seb128> yeah
<mjg59> seb128: Rock
<seb128> :)
<sivang> seb128: ah ok, cool. I'll see what love can cups-manager use, but it looks harder then doing the power management stuff :p ;-)
<seb128> right, but that would be useful :)
* lamont looks at the clock, runs to get kids
<sivang> seb128: hehe, I can sense you would be comfortable leaving it to the user to call ./sleep.sh on their own, won't you? ;-) (/me hides)
<sivang> seb128: anyway, I'm on the bugzilla.
<seb128> sivang: no, but it'll take me half an hour to hack the logout stuff and update the package
<seb128> sivang: so that's not really an issue
<sivang> seb128: ofcourse :-)
<sivang> seb128: I was just teasing...
<seb128> :)
<mjg59> sivang: It'll end up calling pmi action sleep
<mjg59> But that's another story...
<sivang> mjg59: you mean, not using a shell script?
<mjg59> sivang: pmi is our platform-independent way of initiating sleep
<Kamion> T-Bone: ok, I have the SuSE hotplug pci.handmap patch, I'll look at it tomorrow
<sivang> mjg59: where can I read about it?
<T-Bone> gigantic! :)
<mjg59> sivang: apt-get install powermanagement-interface
<Mitario> nite everyone
<mvo> night Mitario 
<sivang> mjg59: first glance, this still looks like shell scripts :-)
<mjg59> sivang: Heh. Yeah, but it means that gnome doesn't have to know about ACPI
<sivang> mjg59: ah nice, any message busses used stuff like that?
<thom> sivang: not yet
<thom> see PowerManagementInterface in the wiki
<sivang> thom: ok, will do.
<mjg59> thom: Can you get pmi added to the right seed?
<thom> mjg59: aw, shucks
<thom> meant to do that today
<thom> will confirm with colin in the morning
<Kamion> hm, or apparently I should use /etc/hotplug.d/pci/ according to Debian #271843
<Kamion> thom: what's needed?
<thom> Kamion: powermanagement-interface in desktop
<mjg59> Oh, wow
<mjg59> The vte in Hoary has the Draw the top line repeatedly while scrolling backwards bug
<Kamion> ah, secondary goal
<schweeb> what's the status on the Hoary installer?  is it fairly usable?
<toresbe> whoooo, I now have my very own PDP-11!! :)
<Kamion> thom: ok, please add it
<schweeb> considering trying it and making some bugreports, but if it's nonfunctional, I'll pass
<Kamion> schweeb: generally it's been pretty fine for a while
<toresbe> whoops, wrong window
<Kamion> schweeb: there's the odd problem on certain hardware, which we need to know about sooner rather than later
<thom> Kamion: will do
<Kamion> every beta release since Array CD 1 has installed successfully on my hardware though
* ogra throws envious looks in toresbe
<toresbe> ogra: where in he world are you?
<ogra> germany
<thom> it installed on ia64 fine this morning for me, and ppc at the beginning of last week
<schweeb> Kamion: yea, I've been meaning to ask, what does all of this "Array x" stuff signify?
<toresbe> ogra: plenty of PDP-11 collectors in .de, and not rare that a PDP-11 pops up on ebay.de
<ogra> toresbe: pdp-11 was the first big iron i saw in my life..... 
<schweeb> I haven't read anything about it, cept on IRC
<Kamion> schweeb: hoary hedgehog; array is the collective noun for hedgehogs
<Kamion> (so I'm told)
<schweeb> ahhhh
<Kamion> similarly, "a sounder of warthogs"
<Kamion> thom: oh, does the status in HoaryGoals need updating to say that it's been uploaded?
<ogra> toresbe: i think i would go with something more usable and buy a up2000 ;) if i would spend money for it... but currently i have a indigo2 here that wasnt used since  years now :(
<thom> yeah, i'll do that when i tweak the seeds
<Kamion> thom: and what significant known bugs are there?
<thom> Kamion: none that I'm aware of
<toresbe> ogra: bah, heden ;)
<ogra> toresbe: so it would only catch dust....
<Kamion> thom: bonus
<Kamion> guess we'll find out :)
<farruinn> so perky penguins will be flock?
<schweeb> I suppose it doesn't make any sense to update && upgrade when I'm about to blow this system away, hehe
<Kamion> farruinn: guess so, haven't looked ahead :)
<thom> Kamion: *g*
<Kamion> so far jdub has given me the name to use
<thom> farruinn: it's a colony of penguins
<Kamion> Colony CD 1
<Kamion> I like that, pleasing overtones of alien invasions
<Kamion> YOU WILL BE COLONISED
<ogra> hehe
<farruinn> one of the releases should be * crow so we can have "murder-*"
<Kamion> hm. no, wait. that sounds a bit too much like an unpleasant rectal operation.
<thom> hehehe
<thom> an intrigue of kittens
<thom> kitchy kitten
<mjg59> Murder 1
<mjg59> Haha
<thom> i want intrigues
<Kamion> the idea of coincidentally naming CDs after cheesy TV shows does amuse me
<farruinn> this creates a whole new dimension in choosing release names...
<Kamion> anyway, PUB
<thom> Kamion: night dude
<thom> http://everywitchway.net/linguistics/languages/english/collectives.html
<ogra> Kamion: prost ;)
<thom> penguins can also be huddles
<Kamion> that pretentious spelling is very annoying
<thom> wow; a lamentation of swans
<thom> Kamion: yes
<thom> but it's the best list i've found
<sivang> Kamion: don't drink too much :)
<ogra> lol, barracuda battery ?
* thom sleeps, having already pubbed
<schweeb> Kamion: you're the cdimage guy right?  which should I download and test? Array 5 or a daily?
<thom> schweeb: array 5 should work most places
<trulux> oops
* trulux having trouble with coreutils stuff
<trulux> ajmitch: there?
<thom> and it's not exactly a long way of current anyway right now; it's only a day or so old
<schweeb> ah, gotcha
<schweeb> now to remember where my blank CDs are...
<mxpxpod> is there a place to file polypaudio bugs upstream?
#ubuntu-devel 2005-03-01
<tseng> seb128: have you heard anything of f-spot?
<seb128> rocking image viewer according to some comments 
<seb128> why ?
<tseng> seb128: nah we talked about updating it
<seb128> oh
<seb128> noh, I was thinking to do it seems noboby seems to care
<tseng> heard anything on the debian side i wondered
<tseng> hrm.
<seb128> does it work with the current bindings version in debian ?
<tseng> yes, they reverted to gtk-sharp1
<seb128> the maintainer is a gnome-pkg maintainers so I guess I could push an upload
<tseng> there is a 0.0.8 anounced just now.
<tseng> libgphoto2 support
<seb128> yep, I've read the mail
<tseng> of course :)
<seb128> do you have a package for it ?
<tseng> nope.
<seb128> I can probably upload/get it uploaded in debian
<tseng> lets see how gross the current source looks
<seb128> but I'm pretty busy and I don't know a lot about gtk-sharp stuff packaging
<tseng> seb128: ill get back to you in a bit.
<seb128> k, thanks
<seb128> the version in debian is really outdated and has some RC
<seb128> would be nice to fix that soon :)
* mako waves
<mako> lwce has been pretty productive
<ogra> hey mako
<tseng> seb128: this is going to take some futzing to get the internal libgphoto2-sharp into the debian mandated paths
<mako> ogra: hey there
<mako> i think we might get a couple more ubuntu derivs out of this.. :)
<seb128> tseng: k
<daniels> amu: which language did you select?
<amu> daniels: german 
<daniels> amu: wwwwwweeeeeiiiiirrrrrrrdddddddddddddddd
<amu> daniels: :-) 
<ogra> daniels: oh, your keyboard has the sam bug as mine ?
<ogra> same even
<T-Bone> daniels: i've been told to report X-stuff to you:
<daniels>   *"DE"* ) LAYOUT="de" XKBOPTIONS="" ;;
<daniels> ogra: $LANG is de_DE.UTF-8?
<daniels> T-Bone: sure
<ogra> yup
<T-Bone> daniels: on recent intall ISOs, X setups at 60Hz VertRefresh (as it's been reported on the m-l). That does kill eyes :)
<daniels> ogra: argh
<T-Bone> especially on big (19"+) screens :)
<daniels> T-Bone: is you need to put in horizsync/vertrefresh, then either you're using the i810 driver and it's a bug there, or your monitor's lying to us
<amu> daniels: same here, LANG is de_DE.UTF-8 
<T-Bone> daniels: changing HorizSync and VertRefresh to more coherent values in xorg.conf fixes that
<T-Bone> daniels: none of the above
<ogra> daniels: not to be mistaken, i meant the key repitition
<T-Bone> daniels: it worked (tm) and it's no longer working since a couple of daily rolls
<amu> n8 all  
<mvo> n8
<daniels> ogra: ah, heh :)
<daniels> T-Bone: that's bizzare; i haven't touched x in like two weeks
<ogra> daniels: which is a kernel bug i think....
<T-Bone> daniels: two weeks is probably the last time i noticed it was working :)
<daniels> T-Bone: weird
<T-Bone> daniels: heh ;)
<Kamion> schweeb: right, what thom said
<schweeb> Kamion: heh, if I had a proper internet connection at home, I'd already have had the CD burned before you replied :p
<Kamion> T-Bone: hm, I'm thinking that any hand-written hotplug pci map probably needs to be kernel version specific; otherwise we're going to run into problems with module names changing between kernel versions and stuff
<tseng> seb128: got it :)
<Kamion> T-Bone: would you guys be amenable to having the kernel package ship such a file, if I supplied the initial contents?
<T-Bone> Kamion: certainly
<T-Bone> Kamion: we'll have to figure out how to integrate it in the kernel package, but i guess it won't be difficult to handle
* T-Bone has to call it a night. Will be back at 13CET
<tseng> erm, we lost seb =/
<ogra> no, he likes core dumps....
<tseng> heh, but he was about to upload my package
<ogra> ouch
<sivang> tseng: probaly went to do another "patch fo the boog"  ;-))
<tseng> sivang: EZ GTK BOOG!
<sivang> tseng: heheheh
<ogra> tseng: do you think it was your package that crashed him ? :)
<sivang> tseng: him and jdub just ROTFLed me heavily this week with their cross mutual accusations :)
<tseng> ogra: nope, hadnt even posted it yet
<tseng> just finished rsync
<ogra> :)
<sivang> tseng: I think seb should be considered for the most hilarious changlog entries ever contest :)
<tseng> hah
<tseng> I've made some pretty bogus ones to Gentoo
<Evaso> hi guys is there any ubuntu devel here?
<lamont> Evaso: nah, we're all over in #ubuntu. :-)
<sivang> Evaso: what are you looking for?
<ogra> heh
<Evaso> i'm thinkig to close dehs.alioth.debian.org serice, with al the upstream changelog info getted from internet, is any ubuntu developer interessed on this data?
<lamont> lifeless??
<lifeless> dude, midnight, sleep tgime
<lamont> lifeless: what evaso said
<lifeless> so as long as we're quick...
<lifeless> what did he say?
<lamont> <Evaso> i'm thinkig to close dehs.alioth.debian.org serice, with al the upstream changelog info getted from internet, is any ubuntu developer interessed on this data?
<lamont> for some reason, I thought of maybe you.
<lamont> and it's not midnight in .au...
<lifeless> I'm in London
<lamont> you jet-setter you
<lifeless> yeah, kindof interesting though we don't have a scific use for it
<lifeless> *specific*
<lifeless> night
<lamont> g'night then
<sivang> lamont: hrm, what is dehs.a.d.o ?
<lamont> sivang: I imagine it's something alioth-ish...
<lamont> Evaso: ??
<sivang> lamont: heh ok 
<Evaso> dehs is an info system about debian situation against upstream version with upstream changelog where the upstream version is noth in sync with debian one
<Kamion> it uses information from debian/watch
<Kamion> sounds like something that could live in launchpad, I guess
<Kamion> but I suspect Evaso is annoyed because many Debian people who are also upstream or have upstreams that don't release code in conventional ways don't find debian/watch very useful
<Kamion> so we shouldn't expect 100% coverage or anything
<Evaso> kamion: dehs had also generetad already 1588 watch file (for packages that no had one) and has passed uscan test
<Kamion> sure, I should probably add some to a few of my packages
<Evaso> kamion: it must only be puttend in the debian directory of their own packages
<Kamion> yes, I am aware of what the debian/watch file does
<Evaso> and actually i doesn't know any internet service that retrive upstream changelog other than dehs
* Kamion wanders off to dehs to see what it says for him
<jvw> Evaso: I already asked you to not close down the site, I think it's useful for QA purposes in Debian. If the load on alioth is too high, I'm sure some admin will mail you about it, don't worry as long as you don't hear anything
<jvw> I also told you that I'm very likely going to include an 'outdated w.r.t. upstream' warning in the PTS's "todo" based on dehs...
<Evaso> jvw: is PTS more popular that developer.php?
<jvw> Evaso: they are both popular, different use cases
<Evaso> jvw: do u know some lintian developer?
* lamont uses pts, but can't recall using developer.php
<jvw> Evaso: erm, you're talking with one, check the changelog :)
<sivang> Evaso: would appriciate pointer on how to make my package my pkgs dehs compliant :)
<jvw> Evaso: I also nowadays maintain PTS, with still occasional help from the original author
<Kamion> sivang: man uscan
<Evaso> jvw: i doesn't know litian source code but i think fixing this #234202 require 30 sec for a guy that know the source code
<Kamion> ah, uscan --pasv helps
<jvw> Evaso: I agree it'd be easy to fix
<Kamion> #234202 should only be applied to non-native packages at most
<zul> hey
<Kamion> no point in warning for dpkg, say :-)
<jvw> Kamion: what do you think for non-native packages?
<jvw> ppl can override it...
<jvw> I'm a tad unsure
<jvw> Evaso: that's why that isn't yet implemented
<Kamion> jvw: *shrug* - I think a warning's reasonable enough, I guess, not sure
<jvw> my estimate is that it's useful for well over 95% or so, probably more, of the packages
<jvw> non-native ones, that is
<Evaso> dehs already exlude debian native packages: they are not archived/processed in dehs
<jvw> Evaso: this is about the lintian warning, which cannot be aware of dehs
<jvw> Evaso: Kamion is also a lintian maintainer
<Kamion> some of my non-native packages just can't have dehs files, though, db1-compat comes to mind immediately
<Kamion> er, watch files
<lexhider> Having a problem with eject command from right on CD icon, what package do I report a bug against?
<elmo> the last time I looked at the QA pages, the "new upstream version" stuff was a bit crackful for my packages
<jvw> elmo: PTS of DDPO?
<elmo> probably because some of them pre-date the birth of the sun
<jvw> or
<Kamion> it's not native because it wasn't written for Debian, but its source was picked out of an old version of glibc by hand
<elmo> jvw: not sure - the fun one, with a huge table and lots of info ;)
<jvw> elmo: heh, DDPO :)
<Kamion> which is, er, not exactly easily encodable in debian/watch :)
<lexhider> right-click
<jvw> Kamion: there surely are a significant number of valid cases to not have one
<Evaso> Kamion: if there isn't a clear upstream release version watch info had no sense
<Kamion> Evaso: yeah, but we keep appearing on your statistics and you keep sending mails to Debian lists saying how lazy we are :)
<Kamion> maybe there could be some way to say "yes, I have checked and I can't produce a watch file for this package, it's not just that I'm lazy"
<jvw> I'm just a bit uncertain whether there are few enough valid non-watch-possible packages to still warn, and have those people override
<elmo> kamion: echo "WHATEVER" > debian/watch
<elmo> ;)
<jvw> Kamion: or that, yeah
<Kamion> elmo: tempting
<Kamion> jvw: would dehs be able to parse lintian overrides though?
<daniels> elmo: if anyone ever did that, I would hope a large fist came and punched them in the goolies for stupid use of quotes :)
<jvw> Kamion: of course it can be made, but then StevenK needs to start parsing lintian overrides when he catches up copy-catting lintian :)
<Evaso> jvw: nload is genereted and tested from dehs
<jvw> 5611 N   Feb18 01 Planet Debian   (0.6K) Marco d'Itri: Closing bugs feels good!
<Kamion> jvw: yeah, that's kind of why I don't feel that a lintian override is the right place to put that information
<jvw> Kamion: ack
<Kamion> how about a present but empty watch file?
<Kamion> what does that do?
<jvw> Evaso: suggestion for a way to have maintainers say "No, there is no watch file, and it makes sense to not have one"?
<jvw> dunno, could be made to do the right thing of course
<Kamion> daniels: that's rich coming from Mr. '[ "x$RET" = "xtrue" ] '
<jvw> but, seems a bit ugly to me
<Evaso> we could talk to Jdg (actually the defacto maintaier of the watch file format) about introduce antoher state in the watch file
<Evaso> so we colud intoduce status
<Evaso> like
<Kamion> de facto? de jure :-)
<dholbach> sleep tight everyone
<Evaso> for example:
<Evaso> status=1
<jdub> goooooood morning freedom lovers
<jvw> Evaso: is he responsive, Jdg?
<sivang> jdub: morning :)
<Kamion> jvw: fairly
<jvw> oh, ok, seemed to recall some issues, but be outdated on that
<daniels> Kamion: :)
<Evaso> jvw: http://lists.debian.org/debian-policy/2005/02/msg00078.html
<dholbach> hai jdub
<daniels> jdub: try waking up earlier, hippy
<Kamion> I wonder what that bug fix is
<Kamion> daniels: (the x thing definitely isn't needed in busybox sh, and I don't think POSIX sh requires it either, BTW)
<dholbach> jdub: just have a look at the end of http://wiki.ubuntu.com/UniversePythonTransitionTODO - i think it speaks for the ubuntu-love ;-)
<jvw> as nobody (AFAIK) uses uscan itself anyway... maybe we just shouldn't care
<daniels> Kamion: yeah, istr something about "" invalidating need for x
<Kamion> hey, I do use uscan from time to time
<jvw> well, but those that don't, it doesn't matter how their watch file works with uscan like as long as it works for the QA scripts :)
<Evaso> jvw: i had a badly hacked version of uscan for dehs, we want to define own format and rewrite an application on it?
<jvw> err, no, rather not :)
<Kamion> no reason to fork the format, Julian is not that unresponsive; last upload of devscripts 13 January 2005
<jvw> I already looked it up, he used to have key issues
<Evaso> I think that we must to work with Julian, for integrate a dehs command line option in uscan and to expand the uscan format with new features
<jvw> Evaso: I think you're by far the most suited to do so, I think the most important thing is to there be a good way to say "no upstream available"
<Kamion> jvw: fixed a while back I think
<jvw> Kamion: eh, how then?
<jvw> oh, you mean his key issues?
<Kamion> yeah
<jdub> daniels: i am so dead to the world, was up for... 48hrs? :)
<jvw> must be, as he isn't in the official MIA db about that, but was merely in my private list of those, which is quite old by now :)
<daniels> jdub: heh :) i slept most of yesterday after I got back
<jdub> dholbach: :D awesome!
<daniels>  /m jdub so, like ... you still have legoness on your table
<daniels> ah, bleh
<jdub> haha
<jdub> yes, i noticed that yesterday
<jdub> everyone, daniels bought lots of lego for me :)
<daniels> went to grab them before I left, but only realised just then that they were only tied, and couldn't find any duct tape; maybe not so good for checked luggage ;)
<sivang> jdub: leog?
<sivang> lego?
<sivang> can I also have some? ;-)
<daniels> sivang: mindstorm, even
<jdub> daniels: yeah
<daniels> jdub: so yeah, if you want to get them down at some stage, that would be awesome ;)
<sivang> daniels: ah!!!!!1
<sivang> daniels: I'm hooked on mindstorm, I had to previous "version" of these and build a couple of circular motion based vechicles :)
<Evaso> well, there is no relevant news, i tink to leave
<daniels> jdub: and I can pay you for the postage
<Evaso> bye guys
<ogra> bye
<mjg59> Suspend/resume situation is looking quite massively pleasing
<azeem> which reminds me
<lamont> Errors were encountered while processing:
<lamont>  mozilla-firefox
<lamont>  mozilla-firefox-gnome-support
<lamont>  yelp
<lamont>  ubuntu-desktop
<lamont>  mozilla-firefox-locale-en-gb
<lamont> E
* lamont kicks libbonobo
<lamont> Kamion: you have a copy of the "current" livecd-rootfs for ia64, and I'll put it back in the right spot for you to keep fetching it
* azeem updates HoaryPMResults to confirm Suspend-to-Disk works fine on R51
<lamont> Kamion: the alternative is to make the ia64 livecd be just ubuntu-base for the moment.. :-(
<mjg59> azeem: Rock
<mjg59> Suspend to disk ought to work on any machine with enough swap now
<Kamion> lamont: I do?
<tritium> how much is enough swap?  >= memory size?
<lamont> Kamion: sorry - that was an 'if you do'
<lamont> I guess I could just grab it from the last daily, eh>?
<Kamion> I suppose I could pick it out of something, yeah
<lamont> Kamion: I can grab it if you don't have it lying naked somewhere
<lamont> what all do you fetch?  cloop and manifest?
<Kamion> yeah. I can pick out both, one sec
<lamont> if you have it trivially, that'd be great
<Kamion> isoinfo is my friend
* lamont feeds horses while he waits
<Kamion> lamont: chinstrap:~cjwatson/casper-ia64/
<bob2> hm, I should try suspend-to-disk again
<Kamion> will need to be renamed to livecd-current.* of course
<tritium> mjg59, what's the minimum requirement on swap size for suspend to disk?
<lamont> Kamion: wget, or scp?
<lamont> nm
<mjg59> tritium: Larger than RAM
<tritium> thanks
<mjg59> tritium: The technical requirement is that everything current used must fit in RAM, and that must then fit in your swap partition
<tritium> mjg59, that's what I thought.  The automatic partitioner sometimes makes a swap slightly smaller than the amount of RAM.
<smurfix> mjg59: does suspend-to-disk turn of swap entirely, or just the swap partition you're suspending to?
<mjg59> smurfix: Mm?
<mjg59> tritium: Yeah, should be fixed on laptop installs in Hoary
<azeem> smurfix: the swap partition is used to write the memory content to, and gets reused as swap once Ubuntu is resumed
<tritium> mjg59, great!
<smurfix> Mmh, but the stuff that's already swpped out needs to be swapped in forst, right?
<smurfix> first
<mjg59> smurfix: Good question. No idea.
<mjg59> (I try not to read the swsusp code too much, it scares me)
<lamont> Kamion: you're golden
<tritium> I guess I'll reinstall to get enough swap space for suspend to disk
<mjg59> Kamion: Does the installer make big swap partitions on laptops for suspend?
<smurfix> because then it'd actually make sense to have two appropriately-prioritized swap partitions, one for actual swapping and one for suspend.
<smurfix> I'll investigate then
<ogra> argh,my-space-key-stopped-working-in-x...works-on-console-though
<hawke> ogra: lol
<ogra> grrrrrr
<ogra> hmm, gnome keyboard selector seems to fix it
<ogra> actually switching layouts....
* dredg beds while there's still a chance he'll wake up in the morning
<dredg> nightol
<ogra> night dredg, nice first package, thanks
<sivang> night all!
<ogra> night
<Kamion> mjg59: not especially, no
<Kamion> lamont: thanks
<Kamion> lamont: http://weddell.buildd/%7Ebuildd/livecd/livecd-current.cloop:
<Kamion> 01:55:18 ERROR 403: Forbidden.
<lamont> doih
<lamont> EOWNER
<lamont> try it now
<mjg59> Kamion: Hrm. I can't remember who I discussed this with now.
<mjg59> Kamion: We certainly need larger swap by default if we want hibernation support
* mjg59 heads for bed
<Kamion> mjg59: oh, it tries for up to 3 times RAM though
<Kamion> mjg59: it depends what fits, but I think it should be OK by default
<Kamion> lamont: could you give daily-live 20050218.1 ia64 a go, please? it should work without weird boot arguments now
<bob2> oh, wow
<lamont> Kamion: it'll take a while, fetching shortly
<Kamion> np
<lamont> is there a way to tell rsync that if it dies during the middle of the rsync, that it shouldn't truncate the target file?
<Kamion> one option is not to use --partial, but that has other problems ...
<maswan> lamont: as far as I know, only "not use --partial"
<zul> lamont: ping
<zul> doh unping
<YokoZar> http://homepages.paradise.net.nz/dazjw/img_0121.jpg
<tseng> YokoZar: hah, thats cute
<YokoZar> That picture has good public relations written all over it
<jdub> elmo: ping
<mxpxpod> is anyone else having problems with icons on their desktop not showing up properly?
<ari> YokoZar: wow
<mxpxpod> I get the generic icon
<jdub> YokoZar: haha
<jdub> YokoZar: post to sounder :)
<YokoZar> Heh, maybe
<mxpxpod> hmm, seems to be something with the new gnome-icon-theme
<schweeb> Kamion: all went well so far, cept for the bootloader (I'm using XFS /)
<Safari_Al> jdub, around
<Safari_Al> ?
<jdub> yo!
<Safari_Al> Hi there!  Just wondering what that status is of that info you were going to pass along to me?
<jdub> shoulda got it on wednesday
<jdub> is slackzone the most useful address to use?
<Safari_Al> In this case, probably @commander is better.
<jdub> mmm, didn't have that address :)
<jdub> tim.riley?
<Safari_Al> woah
<Safari_Al> I thought I had been using that address for our previous correspondence.
<jdub> whoa is me (haw haw)
<jdub> you had too
<jdub> n/m
<jdub> triley
<Safari_Al> haha
<Safari_Al> That's it.
<Safari_Al> Anyway, slackzone is no problem either.  Whichever you remember first :P
<jdub> i get lbdb to do my remembering
<Safari_Al> with mutt?
<jdub> yeah
<Safari_Al> Nice.
<jdub> so my lbdb database was updated today
<jdub> and i have records going back to 2002
<jdub> 2001 even
<jdub> but no tim riley, corporate style
<Safari_Al> Well, now you've got corporate-tim :)
<jdub> i resent, let me know when you get it
<Safari_Al> Thanks.  I don't remember getting this @slackzone.org.
<jdub> !
<jdub> that is because it is not slackzone.rg!
<Safari_Al> ah!
<jdub> argh
<jdub> sorry
<jdub> not that anyone would get a bounce out of it
<jdub> because they're patently useless now
<Safari_Al> jdub, passing along the appropriate information and my recommendations now.  I'll get back to you once I have something.
<Safari_Al> Thanks again.
<schweeb> thom: you awake?
<ficusplanet> Hey everyone.  Will dbus-0.23.1 make it into hoary anytime soon?  I noticed that the latest beagle requires it?  Also, do the latest hoary kernels have inotify-0.18?
<schweeb> they have inotify, dunno which version
<pitti> Morning
<Mitario> morning!
<dholbach> hai
<d3vic3> hi
<dholbach> morning d3vic3, how are you?
<d3vic3> lo dholbach, me is ok and you ? 
<dholbach> should be sitting in the train already *hectic*
<amu> moins 
<dholbach> have a nice weekend
<dholbach> see you on sunday
<amu> daniels: sended debug
<daniels> amu: thanks a lot
<amu> daniels: it was a T41 if you want another test letme know  
<daniels> amu: ah sorry, could you please put the -x on .config.in, rather than .postinst.in?
<amu> daniels: iso was 20050217 
<amu> daniels: do you want the test with the current iso, rsync just finished
<daniels> amu: whichever is easiest for you -- xorg hasn't changed in a while
<rburton> Kamion: so i've a copy of syslog with debugging if you want it
<YokoZar> good morning again: http://homepages.paradise.net.nz/dazjw/img_0121.jpg
<Treenaks> YokoZar: cool
<seb128> elmo: here ?
<smurfix> seb128: not yet, apparently
<pitti> mvo: ping
<mvo> pitti: pong
<pitti> mvo: in Synaptic's progress dialog, would it be possible to first display the package name and then the URL?
<mvo> pitti: when the details are opened?
<pitti> mvo: currently I only see a long list of "http://archive.ubuntu.com/u..." (unless I resize the dialog)
<pitti> mvo: yes
<mvo> pitti: it's stuff I get from apt that way, I can change it 
<pitti> mvo: another thing
<pitti> mvo: if I open a Ubuntu CD and upgrade, then I still get a Nautilus window
<pitti> mvo: you currently have a HAL script, right?
<pitti> mvo: maybe it would be better to integrate this stuff into gnome-volume-manager
<mvo> pitti: no, it's part of the C code in update-notifier
<pitti> mvo: huh, you detect Ubuntu CDs in u-n?
<pitti> I thought you have a hal callout?
<mvo> pitti: I link against libhal
<pitti> ah
<pitti> hm, somehow we should teach gvm not to open Ubuntu CDs when upgrading from them
<pitti> what do you think?
<mvo> is there a way to tell hal to stop processing the event when I handled it?
<pitti> mvo: no, because it will be executed asynchronously and in parallel
<pitti> mvo: whoever is faster handles it first :-)
<pitti> mvo: that's why I think a gvm integration would be nice
<pitti> mvo: gvm is meant for stuff like that
<Kamion> rburton: yes please
<mvo> pitti: I agree that it's ugly that a nautilus window is opened. but I'm not sure about the integration into g-v-m. 
<seb128> pitti: dunno if that's due to inotify/gamin, but I've a DVD in my drive and totem starts some minutes after the login ... which is kind of weird :p
<rburton> Kamion: email?
<Kamion> cjwatson@ubuntu.com
<rburton> Kamion: sent
<mvo> pitti: we could add it to gvm_device_autorun()
<pitti> mvo: yes, that was the idea
<elmo> seb128: ?
<elmo> jdub: ?
<seb128> elmo: need an ia64 access with the libbonobo build-dep installed to track a ftbfs is that's possible
<pitti> seb128: #6002 ?
<seb128> pitti: kind of, happens just on the system start/login
<seb128> not every single 5 mins
<pitti> seb128: oh, ok. can you please add that to the bug?
<seb128> k
<pitti> thanks
<Mithrandir> Kamion: why does now tar (for instance) get SIGPIPE when piping stuff through ssh?
<pitti> seb128: removable devices automatically get mounted at login
<jdub> elmo: yo
<pitti> seb128: probably this erroneously causes the device to autostart, too
<Kamion> damn, the installer's memory footprint is huge; minimum in lowmem 1 is like 52MB
<Kamion> Mithrandir: dunno
<elmo> seb128: halley.ubuntu.com
<Kamion> don't think anything that might affect that has changed recently
<Mithrandir> Kamion: up-to-date hoary, I see it on both amd64 and i386.
<Mithrandir> Kamion: been that way for a while, probably a few weeks
<elmo> jdub: you pinged 10 hours or so ago?
<Kamion> weird
<seb128> elmo: thanks
<Kamion> Mithrandir: could be the shell or the terminal rather than ssh; that's happened in the past
<jdub> elmo: didn't note down why :)
<Mithrandir> I'm using pterm
<Kamion> Mithrandir: IIRC either the shell or the terminal conventionally ignores SIGPIPE
<Mithrandir> hmm, right, seems to be zsh's fault
<seb128> jdub: hey, do you know what happened to gtk2-engines-dev ?
<mvo> grrr. my system was frozen again :( 
<jdub> seb128: it was a new binary package in my upload
* mvo blames gtk^Winotify
<Kamion> damnit, I can't get the installer's memory footprint below 32MB
<seb128> mvo: boot with "noinotify" :)
<seb128> jdub: ie ? 
<Kamion> even in lowmem mode 2 it's fractionally over that on i386
<seb128> jdub: is gtk-engines-2.pc somewhere atm ?
<Kamion> (and doesn't work properly then 'cos I'm missing the module for my network card)
<jdub> seb128: it should be in gtk2-engines-dev
<jdub> seb128: (gar! so stupid!)
<jdub> $ dpkg -L gtk2-engines-dev | grep pc$
<jdub> /usr/lib/pkgconfig/gtk-engines-2.pc
<seb128> grumpf
<seb128> apparently something screwed my cache
<seb128> jdub: sorry for the noise :)
<seb128> elmo: libglib2.0-0-dbg on halley please :)
<elmo> seb128: done
<seb128> thanks
<bob2> Mithrandir: tell me if you figure out which zsh option is it
<bob2> I get (I think) the same problem with piping stuff to patch
<seb128> jdub: I'm not going to put an epoch on yelp :p
<jdub> seb128: haha :-)
<jdub> seb128: can you check the rawhide panel patches
<seb128> looking for something special ?
<jdub> seb128: they've done the desktop menu changes
<seb128> admin/pref order ?
<jdub> yeah
<seb128> k, thanks
<jdub> and s/Administration/System Settings/
<jdub> etc.
<seb128> do
<seb128> all these strings changes suck
<seb128> (on the translation plan)
<jdub> yes
<jdub> they have them, though ;)
<seb128> s/do/doh/
<jdub> they're also not renaming desktop
<jdub> i'll talk to mark about desktop/system
* seb128 reading the howl thread (the whole discussion just arrived in one shoot in bugzilla)
<jdub> yeah
* HiddenWolf howls
<jdub> seb128: what do you think about that?
<jdub> seb128: i don't really want to ship/support mdnsresponder
<seb128> still reading :)
<HiddenWolf> link?
<seb128> BTW a bug which sucks: debian #295815
<seb128> the gtk icon cache seems to have endian issue, we have updated a gnome-icon-theme using it yesterday and already get 3 bug today saying that all the icons are broken
<HiddenWolf> yuk
<seb128> jdub: hum, we so just drop it ?
<sivang> morning all
<mjg59> thom: Ping?
<thom> mjg59: ack
<pitti> Hi sivang
<mjg59> thom: We need to work out what we're doing about swap sizes in the installer
<mjg59> At the moment, people may end up with swap partitions that are slightly smaller than RAM, which won't work too well with swsusp
<thom> right
<thom> what's the best solution? just add n MB to the size of ram to get the ideal swap size?
<sivang> hey pitti  :)
<mjg59> thom: Something like that. Do we have any idea what Suse 9.2 defaults to for swap size?
<jdub> seb128: well, i need your thoughts on that (and the debian gnome team's).
<thom> mjg59: i've not looked at suse at all, tbh
<seb128> jdub: I don't really care about it, removing it in fine for me
<jdub> seb128: even in debian?
<jdub> seb128: that's a fair amount of uploads, thanks to libtool mess
<seb128> yeah, but there is no real choice
<Kamion> mjg59: did you see my comment last night?
<seb128> jdub: move that to #gnome-debian
<mjg59> Kamion: Nope
<Kamion> 02:05 < Kamion> mjg59: oh, it tries for up to 3 times RAM though
<Kamion> 02:05 < Kamion> mjg59: it depends what fits, but I think it should be OK by default
<elmo> 3 times RAM?  that'd rock on emperor
<thom> yay 36GB swap
<mjg59> Kamion: Is this a change since Warty?
<Kamion> it doesn't force it up to 3x RAM :P
<daniels> elmo: speaking of RAM, when do I get to build xorg in a RAM disk on concordia?
<daniels> that would kick arse
<daniels> disks are slow :P
<Kamion> that's the maximum; minimum 64MB; "priority" (which kind of skews size calculations relative to other partitions) 512MB
<mjg59> Kamion: So given a reasonably sized disk, it'll tend to be larger than RAM?
<Kamion> mjg59: yes, warty had "64 512 512" rather than "64 512 300%"
<Kamion> mjg59: I believe so, though checking wouldn't hurt
<mjg59> Ok, cool
<Kamion> partman-auto (31) unstable; urgency=low
<Kamion>     - limit the maximum size of the swap to 3 times the available RAM but
<Kamion>       not less than 64 MB.  Thanks to Margarita Manterola, closes: #254935
<mjg59> Ah, hang on. My sysadmin's a Suse bigot.
<bradb> Does Ubuntu's Bugzilla grant editbugs to every new user account? I don't want to spam our Bugzilla to verify this. :)
<mjg59> The machine with 4GB of RAM has 4GB of swap
<elmo> bradb: yes
<sivang> does someone know how do I view the channel topic in irssi? (the topic and the top bottom of the screen get's cut due to window width limitations)
<bradb> wow, ok
<elmo> sivang: /topic
<elmo> bradb: dude, Debian doesn't even require accounts; it's entirely wide open for all write access to anyone
<bradb> cool!
<elmo> which would seem insane, but AFAIK hasn't been abused in the last 10-15 years
<elmo> well, seriously abused.  some would say folks like Dan Jacobson are a failing of the Debian system
* bradb takes this into consideration in massively simplifying one of his specs
<daniels> well, it's wide open for everyone who hasn't been blacklisted
<sivang> elmo: tnx :)
<elmo> daniels: the only blacklisting is of control@ access
<Kamion> the only abuse that's happened is spam
<elmo> well, excluding the spam filtering
<Kamion> to my knowledge
<Kamion> there's been some open/close wars and things, but the people involved would've had accounts anyway if it worked that way; no randoms going through and closing all bugs or anything
<Kamion> the system's designed so that all actions are recorded and reversible anyway
<mjg59> Kamion: elmo: With luck, the next kernel ought to suspend to RAM on recent Mac hardware, so would you be willing to test it once it's out?
<elmo> mjg59: sure
<Kamion> mjg59: absolutely
<mjg59> And if that works, then we can try suspend to disk as well...
<mjg59> I think lamont was aiming for Monday
<elmo> oh, I may have < swap than mem.. lemme check
<elmo> Mem:        514308 
<elmo> Swap:       500312   
<elmo> duh
<elmo> I'm sure that was what warty chose for me too
<Kamion> hm, I have 512MB RAM and like 64MB swap
<sivang> mjg59: I will check my swap partition now, on the dell craptop
<mjg59> elmo: May work anyway
* sivang is really happy with the speed the laptop is booting now.
<sivang> mjg59: how can I know for sure if I am using a swap partitoin at all? something is strange here on this laptop..
<Kamion> 'free' will tell you
<sivang> Kamion: tnx
<sivang> Mem:        256620     168028      88592          0       8868      44792
<sivang> -/+ buffers/cache:     114368     142252
<sivang> Swap:            0          0          0
<mjg59> sivang: You have no swap partition enabled, which is odd
<mjg59> Does /etc/fstab have one mentioned?
<sivang> mjg59: yes, that's why I thought I had
<sivang> mjg59: /dev/hda5       none            swap    sw              0       0
* sivang is surprised this machine copes with 3 instances of OOo docs and a couple of moz's without a swap partitoin
<mjg59> sivang: mkswap /dev/hda5; swapon -a
<mjg59> Then try hibernate again
<Kamion> rburton: ok, I think I have a vaguely plausible fix
<sivang> mjg59: ok, thanks
<sivang> mjg59: will try that now
<sivang> mjg59: ok, it worked :-) now let's see how good the machine comes back
<rburton> Kamion: excellent
<sivang> mjg59: well, the resume from hibernate is a regular boot :-/ (slow as a regular boot and looks the same)
<mjg59> sivang: Ok. Is RESUME set in mkinitrd.conf?
<sivang> mjg59: I did RESUME=/dev/hda5 and hibernated again, takes the same time and apart a big delay in boot up (before saying "creating udev entries") nothing changed.
<T-Bone> lamont: ping (for when you're around)
<sivang> guess I'll be using the sleep :-)
<mjg59> sivang: Did you generate a new initrd?
<Kamion> incidentally DEBCONF_DEBUG traces rock
<daniels> Kamion: unless they crap all over your db_progress and just make everything unreadable :P
<T-Bone> Kamion: good you're here! Time to sort out the pci.handmap stuff? :)
<T-Bone> daniels: if i can provide anything that'd help fixing the '60Hz' issue, let me know. FWIW i tested on ia64, but according to the m-l, it's arch-indep
<sivang> mjg59: hrm, no O:-) also it's very strange I my swap partition is not mounted nither set up correctly .
<daniels> T-Bone: if you can solve it, that'd be great ...
<T-Bone> heh
<Kamion> daniels: they're syslogged as standard
<Kamion> T-Bone: yeah, after I've done this netcfg fix
<T-Bone> daniels: actually, why is there a need to add VertRefresh/HorizSync in the default xorg.conf? Can't the driver figure those by itself?
<mjg59> sivang: Yes, that's because it didn't attempt to resume
<mjg59> You'll need to mkswap it again
<T-Bone> Kamion: ok. I'll do some parisc stuff in the meantime. Ping me when you're ready :)
<mjg59> sivang: mkinitrd -o /boot/initrd-whatever and then suspend again
<sivang> mjg59: I wonder how I can fix the non operating swap partiton
<daniels> T-Bone: it shouldn't be adding them unless it really has to ...
<T-Bone> daniels: it did
<daniels> T-Bone: although it will decide that it really has to on amd64 and ia64
<sivang> mjg59: and use this initred for booting the currently booting kernel?
<T-Bone> daniels: they were there when i booted
<mjg59> sivang: Yes
<daniels> T-Bone: since we can't probe the monitor from userspace on either of those two architectures
<T-Bone> daniels: and they were obviously the cause of the mis-setting
<mjg59> sivang: Once you've done that, swap shouldn't be an issue
<daniels> T-Bone: if you can reproduce it on i386 or powerpc, I'm interested; else, it's not solveable for Hoary :\
<sivang> mjg59: ok, so I'll have to replace the current on in menu.lst right?
<T-Bone> daniels: damn. How comes it worked before?
<daniels> T-Bone: because of an accident that broke a whole lot of other crap :)
<mjg59> sivang: No - just do mkinitrd -o (name of your initrd)
<T-Bone> daniels: if the livecd uses the same detection method, i can easily boot one on any of my ppc boxes
<daniels> T-Bone: yep
<T-Bone> daniels: lol :)
<T-Bone> daniels: ok will do
* T-Bone starts downloading the ISO
<Kamion> daniels: is there anything I can help with for xresprobe/amd64? if you give me hints what might be needed, I can do the work
<sivang> mjg59: done, now re enable swap and hibernate
<Kamion> oh, I suppose it's scary evil real mode crap?
<mjg59> sivang: Yup
<T-Bone> hmm. cdimage doesn't perform that well. 440kB/s avg is mean :^)
* T-Bone ducks
<daniels> Kamion: basically, move ddcprobe's real-mode code to vbetool, and then move vbetool from using lrmi to x86emu
<daniels> Kamion: unfortunately this is not hoaryable; i asked about a fortnight ago
<sivang> mjg59: hrm, no go , boot was the same, say, maybe the fact I am using LVM breaks the hibernation?
<Kamion> daniels: ah :(
<Kamion> -m32 doesn't help?
<mjg59> sivang: Argh. Yes, that's quite possible. Are you using LVM for swap?
<sivang> mjg59: no
<mjg59> Hmm. Ought to work, then.
<mjg59> It used the initrd you generated?
<mjg59> sivang: Can you cat /sys/power/resume ?
<sivang> I named it the same and assumed it goes to the right place :) checking again
<daniels> Kamion: nope; vm86.h simply doesn't exist, and the kernel doesn't provide vm86()
<sivang> mjg59: 0:0
<mjg59> amd64 kernels have no vm86 support whatsoever
<mjg59> sivang: Ok, so either the wrong initrd was used, or something is very broken
<sivang> mjg59: retrying...
<mjg59> sivang: The timestamp on /boot/initrd-2.6.10-3-686 (or whatever) ought to be updated after the mkinitrd
<sivang> mjg59: bah, then I suspect it didn't. looked odd me after the second time I created the initrd , but I thought it was neglectable.
<sivang> mjg59: shall I rm -rf it and recreate?
<mjg59> sivang: What command line are you using
<mjg59> You don't need to remove it
<sivang> mjg59: mkinitrd -o initrd.img-2.6.10-3-686
<Kamion> daniels: ah, d'oh
<mjg59> sivang: /boot/initrd.img-2.6.10-3-686
<mjg59> (assuming you're using a 686 kernel)
<sivang> mjg59: well yeah, I was in the /boot dir so I omitted the location prefix
<mjg59> sivang: Ah, right
<mjg59> I've no idea what it does in that situation
<smurfix> mjg59: should work, actually -- check by "ls -l"
<sivang>  mkinitrd -o /boot/initrd.img-2.6.10-3-686
<sivang> File descriptor 3 left open
<sivang> File descriptor 4 left open
<sivang> File descriptor 5 left open
<sivang> File descriptor 6 left open
<sivang> File descriptor 7 left open
<sivang>     Finding all volume groups
<sivang>     Finding volume group "mainpart"
* mjg59 goes off to a meeting
<sivang> mjg59: ok, laterz! :)
<mjg59> sivang: If it still doesn't work, you probably want to hassle jbailey for a bit
<sivang> mjg59: ok, I will :)
<mjg59> And if it /still/ doesn't work, it'll be a kernel issue and I'll produce one with more debugging
<sivang> mjg59: sure, thanks alot 
* jbailey scrolls up.
<sivang> mjg59: it worked!!!
<sivang> mjg59: I rm -rf the initrd, then recreated with your command line, and it workd! RAWK
<Kamion> I should work out what that "File descriptor <n> left open" thing is coming from
<sivang> Kamion: oh yes, this has been botherting for quite some time :)
<jbailey> mjg59: For testing, I also added support for it over the command line.
<Kamion> sivang: it seems to be harmless
<jbailey> mjg59: Of course you have to have at least regenerated it one with that initrd-tools, but after that resume= will override whatever is set in the config file.
<jbailey> Kamion: It's only on lvm support, right?
<sivang> jbailey: strange thing, mkinitrd didn't work untill I told it /boot/initrd.img-blah
<jbailey> sivang: Eh?
<sivang> jbailey: I suspect it working had nothing to do with my rm -rf'ing the old one.
<Kamion> jbailey: yeah, just checked and it's coming from lvm2
<Kamion> ./tools/lvmcmdline.c:990:                       fprintf(stderr, "File descriptor %d left open\n", fd);
<Kamion> the question is whether I care enough to fix it :) I bet those fds are held open by debconf.
<jbailey> Kamion: No, by initrd.
<jbailey> Kamion: Xu likes to play with random file descriptors.
<sivang> anyone has an idea why the swap partiton automagically stopped being created and mounted? how can I put it back to be created automaticall upon each boot?
<Kamion> jbailey: well, no, I see it in d-i.
<jbailey> Kamion: For some reason ">>" isn't good enough.
<Kamion> jbailey: in code that is not descended from anything Xuish :)
<jbailey> A'ight.
<jbailey> sivang's issue is definetly that, though.
<Kamion> ok
<jbailey> I should learn enough about lvm to install one.
<sivang> (the swap partitoin is not on th lvm)
<sivang> jbailey: when I tried the fix my non suspending kernel, it appeared that when using mkinitrd -o initrdfilename it didn't work
<sivang> jbailey: whant I prefixed it with /boot it was ok
<jbailey> sivang: Oh, like it only worked with a fully qualified path?
<sivang> jbailey: that is, mkinitrd -o 
<sivang> jbailey: yes
<sivang> jbailey: I also did an rm -rf for the old one, but I hardly think this voodoo had anything to do with fixing the problem . (though I do that just for good feeling)
<Kamion> elmo: would you mind delaying processing the new debian-installer BYHAND, if possible?
<elmo> Kamion: err, too late, sorry
<Kamion> damn
<Kamion> ok, will work around in cdimage somehow
* sivang would like to note to another interesting fact - when hibernatig the laptop from an ssh login, when the system is in hibernate mode the ssh loging becomes frozen, when I power on the system back - I even get to see the lease happening back on the ssh login after which I can continue working on through it. (!!!)
<Kamion> smurfix: could you please remove all the BitKeeper gunk from the kbd-chooser source package?
<Kamion> I don't want to have to merge that every time :)
<smurfix> Kamion: Sorry -- will do ASAP.
<Kamion> thanks
<Kamion> smurfix: I don't think #6706 should be target milestone hoary?
<Kamion> Indic fonts are apparently really hard to get right
<Kamion> bubulle thinks it'll require a graphical installer
<smurfix> Kamion: Hmm, target milestone => noticed in version, it seems.
<Kamion> yeah, we don't have a field for that in bugzilla AFAIK :/
<smurfix> ah. food. back in a bit.
<T-Bone> daniels: X autodetect works fine on ppc. I was wondering: if autodetect doesn't work on ia64, how comes it works on my box anyway? :)
<Kamion> I bet it asks you a resolution question
<T-Bone> Kamion: correct
<Kamion> that would be autodetection failing
<T-Bone> strangely enough it works afterwards
<daniels> so it asked you a question on powerpc, or on ia64?
<daniels> if it asks you no questions, then autodetection succeeded
<daniels> if it asks you about your resolution, autodetection failed, but we can infer all we need (for 60Hz) from the resolution, so that's all we ask
<HiddenWolf> daniels: How about someone trading monitors, is there any likelyhood of of blowing up a monitor due to an existing x conf?
<T-Bone> daniels: it asked on ia64
<T-Bone> daniels: what i'm saying is that if i increase the value range for vertrefresh and horizsync in xorg.conf, it finds the right freq anyway. I can try completely removing the fields if you want
<sivang> bah, suspend and hibernate won't work with the evil nvidia module.
<sivang> oh well :)
<elmo> HiddenWolf: how's that any more of an issue with or without auto-detect?
<T-Bone> daniels: so i'm asking why not simply either 1) not specify default refresh for ia64. or 2) define a large enough range?
<HiddenWolf> elmo: I have no idea, but it something to think about either way.
<daniels> HiddenWolf: no
<tritium> sivang, I've had pretty good success with nvidia, both suspend and hibernate
<mantiena> Hi all
<daniels> T-Bone: because we have to work out when we configure X if X is capable of working out the monitor's sync ranges by itself
<daniels> T-Bone: our current way of determining this only works for i386/powerpc, and the solution cannot go into hoary this late, apparently
<sivang> tritium: where you using the proprierity nvidia module?
<daniels> T-Bone: so we have to assume that X can't work it out for itself and write out the sync ranges on amd64 and ia64
<tritium> sivang, yes
<daniels> T-Bone: i know this is crap
<Mitario_> hi everyone
<sivang> tritium: did you add it to the modules list in /etc/default/acpi-support ?
<mantiena> amu, tonight I installed ubuntu live CD with my installer module ;)
<tritium> sivang, no, but I did have to comment out video posting
<T-Bone> daniels: what would make X unable to figure out its sync freq?
<sivang> tritium: video posting? ok I'll try that.
<T-Bone> daniels: because the video hardware range on ia64 is pretty much restrained, afaik
<tritium> sivang, yeah, the line that says POST_VIDEO=true.  I commented that out.
<daniels> T-Bone: the monitor can't do DDC, the driver is crap and doesn't do mode validation right on laptops, the video card is incapable of DDC ...
<T-Bone> daniels: you can already skip the last two
<T-Bone> no ia64 laptops ;)
<T-Bone> and all boxes come with ATI cards, or nvidia in some cases
<daniels> T-Bone: i might consider making an exception for ia64, but honestly, the real, real problem we have is amd64
<daniels> and that's unfixable for hoary
<sivang> tritium: thanks, I did that, now let's see if it works.
<T-Bone> daniels: heh. If making an exception for ia64 is easily feasible, it might improve end user's experience :)
<daniels> T-Bone: yeah, but as I said, this kills us badly on amd64, which sucks horribly, but eh, what can you do
<tritium> sivang, hope so...
<T-Bone> daniels: besides, i doubt one would hook a pre-DCC capable monitor to an ia64 machine ;)
<daniels> T-Bone: you'd be surprised
<mantiena> Kamion, are you online ?
<T-Bone> daniels: not much i guess. I don't have amd64 hardware. If you want to sponsor me, you're welcome :^))
<elmo> yeah, I did at my previous job
* daniels looks at the pre-DDC monitor currently hooked up to his amd64.
<T-Bone> daniels: people doing so usually know how to setup X :)
<elmo> to both an RX-2600 and an i2k
<daniels> T-Bone: i have an amd64, and I'm capable of fixing it, but by the time I got to it, feature freeze had slipped, and I had other stuff distracting me for a week, so I couldn't get it in beforehand
<T-Bone> but heh, that's subjective.
<T-Bone> daniels: heh ok
<daniels> so the issue is not people-to-do-it, but people-to-do-it-four-months-ago
<T-Bone> lol
<elmo> sabdfl really needs to get his act together, both the cloning and time machine projects are still showing no signs of any real progress
<T-Bone> rotfl
<daniels> elmo: i hope you're not talking about cloning me; one of me is enough pain inflicted on the world
<amu> mantiena: well done!
<sivang> elmo: wasn't the time machine already done?
<Kamion> *groan*
<azeem> sivang: there were spurious tachyon emmission AFAIK, so it had to be dumped and redoe from scratch
<T-Bone> sivang: well, if it's done in the future, then it's *already* done. Paradox of the time-machine :)
<mantiena> amu, but some other d-i modules should be modified a little for working with live-installer
<amu> mantiena: did you put infos to the wiki? 
<sivang> azeem: hehe
<mantiena> amu, still not, was pretty simple to write live-installer, I used a lot of functions (like check-target or initrd generating) from base-installer ;)
<sivang> tritium: didn't work. any more then just commeting out the VIDEO_POST is it?
<mantiena> Kamion, to which udeb belongs apt-install from d-i ?
<tritium> sivang, no, the only other thing I did was uncomment the line at the top: ACPI_SLEEP=true to actually enable suspend to ram
<Kamion> mantiena: di-utils
<Kamion> why does apt-install need to be changed?
<azeem> when doing suspend-to-disk, does the network on resume get reconfigured based on the state at suspend, or on what's in /etc/network/interfaces?
<sivang> tritium: commented out the line or set POST_VIDEO=false?
<tritium> I commented it out.
<mantiena> Kamion, some d-i modules (for example grub-installer) uses apt-install to install software, for example grub or initrd-tools, but apt-install does not check if this software is already installed and this couses an error :(
<sivang> tritium: well, doens't work for me. crappi dell :)
<tritium> sivang, How is it behaving?  On my Dell (C840), the only thing I haven't resolved is that I have to press the power button 2X to resume.
<pitti> elmo: ping
<Kamion> mantiena: apt-install just calls apt-get install, which should exit without an error if the package is already installed.
<elmo> pitti: ?
<pitti> elmo: is there something like arch.ubuntu.com?
<pitti> elmo: i. e a publicly http/sftp accessible place
<pitti> elmo: where we can store our arch repos and work on them with non-canonical people?
<elmo> pitti: mirror them to rookery is what most people do
<pitti> elmo: currently we use to host our repos on chinstrap
<mantiena> Kamion, problem is, than during live CD install there are no sources.list and no deb packages (if there are no internet access) and apt-get install produces an error
<pitti> elmo: right, but that has to happen manually, right?
<mantiena> s/than/that
<pitti> elmo: since you cannot/should not ssh from chinstrap to rookery without a password
<elmo> Kamion: how do you mirror the seeds?
<mantiena> Kamion, I can patch apt-install for checking if package isn't already installed on /target
<tritium> sivang, I'm using NvAGP, and nvidia module parameters NVreg_EnableAGPFW=1 NVreg_EnableAGPSBA=1
<pitti> elmo: sabdfl seems to like the idea of arch.u.c
<elmo> pitti: IIRC rookery has unrestricted http access to chinstrap
<pitti> elmo: ah, that way round :-)
<elmo> or https or whatever
<pitti> elmo: okay, that's fine
<elmo> the name 'arch.ubuntu.com' is already in use
<elmo> for an entirely different service
<pitti> elmo: would it be possible to update to baz 1.1.1 on rookery?
<elmo> done
<elmo> tho I hope it doesn't break anyone using 1.0 specific stuff
<pitti> huh, thanks :-)
<pitti> elmo: no, I'm just afraid that 1.0 could break when mirroring an 1.1 archive
<Kamion> mantiena: well the former should be fixed, not the latter
<elmo> <random>why do people who are downloading ISOs prefer ftp so much?
<Kamion> mantiena: fix the cause, not the symptoms
<Kamion> elmo: crappy rsync cron job on chinstrap
<Kamion> mantiena: (making apt-install check first would slow regular installs down quite a lot - dpkg -l is not very fast
<Kamion> )
<rcaskey_> does anyone know if the hardware database has been specced out?
<mantiena> Kamion, maybe, then we can fix at least grub-installer
<Kamion> mantiena: huh?
<Kamion> mantiena: no
<Kamion> mantiena: hmm, the no-network case is awkward, but I don't think any of these proposed solutions are quite correct
<mantiena> Kamion, no network case is very usual, especially with live CD
<Kamion> sure
<mantiena> Kamion, it's one line fix in grub installer
<Kamion> but breaking installer error handling is not the answer
<Kamion> it's the wrong place
<mantiena> Kamion, and it doesn't break an install
<Kamion> I am not going to maintain a bunch of little patches to everything that calls apt-install
<mantiena> Kamion, not to everythink
<mantiena> it's nonsense to install same package if it is already installed
<tritium> sivang, and I did blacklist intel_agp in order to use NgAGP
<Kamion> sigh, I have other things to do, sorry :(
<Kamion> mantiena: how about using the -m flag to apt-get install?
<Kamion>               Ignore missing packages; If packages cannot be retrieved or fail
<Kamion>               the  integrity  check after retrieval (corrupted package files),
<Kamion>               hold back those packages and handle the result.
<Kamion> although I'm not sure about that
<Kamion> maybe for speed it would be better to run apt-get install, and *only* if it fails check whether the package is already installed
<mantiena> Kamion, maybe
<Kamion> that would be more efficient, because it would do the work only in error cases
<sireesh> hey does ubuntu have any embedded linux distribution
<mantiena> Kamion, I'm happy with any solution which works ;)
<Kamion> mantiena: I'm not happy with just any solution that works, as you may have gathered; I have to maintain the installer going forward so I want it to stay as simple as possible :)
<mantiena> Kamion, I understand you, so for my it's fine any solution which is fine for you ;)
<zul> heylo
<mantiena> Kamion, I try to install some more times and see if -m helps
<Kamion> I think actually -m is probably wrong
<Kamion> it won't have the right error behaviour if the package is unavailable and not installed
<Kamion> (in that case apt-install needs to return an appropriate error code so that the user can be notified of the error)
<mantiena> Kamion, if package is unavailable and not installed then it's really error for liveCD
<Kamion> indeed so
<Kamion> so you want to know about it
<Kamion> hm, have you no /etc/apt/sources.list at all?
<mantiena> Kamion, liveCD should contain all packages for installing without internet access and it seems now just one - grub is missing in live CD
<Kamion> grub's in base - ah, but debootstrap does not install it, deliberately
<mantiena> Kamion, yes, live CD doesn't need any sources in sources list
<Kamion> I would prefer sources.list to *exist*, even if empty; it makes the change simpler
<mantiena> Kamion, I think sources.list should contain all needed sources like now, just they should be commented out as default
<mantiena> then apt-get install doesn't produce an error ;)
<Kamion> it does
<Kamion> produce an error, I mean
<mantiena> Kamion, why ?
<Kamion> try it
<Kamion> remember to apt-get update
<mantiena> Kamion, I'm talking about situation, when sources.list contains only commented out sources (all lines are begining with # )
<Kamion> yes, I know you are, and I just tested that
<mantiena> root@ubuntu:/etc/apt # apt-get update
<mantiena> Reading Package Lists... Done
<mantiena> no error
<Kamion> now try apt-get install grub
<Kamion> ah, but grub is uninstalled for me, I'm sorry
<Kamion> apt-get install dpkg does exit non-zero
<Kamion> ok, there's your fix :-)
<Kamion> just make sure always to create /target/etc/apt/sources.list and you should be fine
<Kamion> you'll need to arrange for grub.deb to be available for installation on the CD; that is a more generic problem
<Kamion> (along with lilo.deb, yaboot.deb on powerpc, that sort of thing)
<mantiena> Kamion, sources.list is created, but in ubuntu live CD it contains uncommented entries as default :(
<Kamion> ok, maybe apt-setup should be called to test those entries
<mantiena> maybe
<Kamion> at the moment that involves asking the user one question though
<Kamion> the other plausible solution is to have an apt repository on the CD that's always usable and that contains stuff like grub, lilo, yaboot that the live CD installer might need to install
<Kamion> that sounds rather simpler
<Kamion> might need another seed though
<mantiena> Kamion, how to simply check exit value of some program in command line ? (sorry for stupid question)
<Kamion> man bash :)
<pitti> mantiena: <cheat> use $? </cheat> :-)
<Kamion> but make sure to avoid set -e exiting on you
<mantiena> pitti, thanks
<pitti> mantiena: or if you just need to check for success, "if foo; then...; fi
<Kamion> or like read any shell script for examples :)
<Kamion> there is no shortage of them
<mantiena> pitti, I know if, but it's too many to write for testing some commands in terminal
<d3vic3> #6712 is killing me 
<mantiena> daniels, maybe you know why ddcprobe doesn't detect properly my monitor when connected to integrated savage video card, but works fine with same monitor, connected to nvidia video card ?
<daniels> mantiena: because it only works for the primary video card
<elmo> oh dear god
<daniels> elmo: ?
<mantiena> daniels, I have only one video card connected
<elmo> daniels: that bug d3vic3 mentioned
<mantiena> daniels, ddcprobe detect monitor incorrectly on savage video card
* sivang just made his laptop suspend and hibernate with the proprierity nvidia driver :)
<sivang> yay!!
<pitti> sivang: lucky you...
<daniels> mantiena: yes, I know
<daniels> mantiena: but if you have two video devices
<sivang> pitti: you should try that, but the instruction I got from tritium are i386 specific :)
<daniels> mantiena: it will only work for whichever one of those is the primary one, i.e. whichever one the bios shows on
<pitti> sivang: there's currently no sleep support for newer iBook G4's :-(
<sivang> pitti: ah and that nice little machine of yours (which you brought to the conf) is iBook G4 ?
<mantiena> daniels, I have only one device, I simply connect same monitor to different computers
<daniels> mantiena: oh, ok.  is the savage a laptop?
<pitti> sivang: yes
<mantiena> no, both are workstations
<sivang> pitti: oh :-/
<daniels> mantiena: ok, so the savage hardware sucks; not much we can do there, sadly
<mantiena> daniels, on savage video dccprobe shows strange results, I can paste output to  you private irc window if you need
<daniels> mantiena: if you like, but there's not much I can do about it other than suggest you write to S3 and tell them they should stop producing such terrible hardware
<mantiena> daniels, but win98 detect horizontal and vertical freqencies correctly with savage drivers
<daniels> mantiena: yes, but they don't have the same restrictions we do (in order to work across almost every video card, we have to use vbe, the vesa bios extensions; doing per-card stuff in ddcprobe is totally impractical, although I want to see it happen, and have plans to make it so)
<daniels> *blink*, hardware that actually totally mangles ddc results into uselessness while keeping it as a totally valid edid packet
<daniels> WHOOHOO S3!!!
<Treenaks> daniels: well, at least they follow /some/ standards..
<tritium> pitti, if you'd like to try what I did anyway, we can give it a shot
<lamont> daniels: sounds like a lot of work went into that
<tritium> the only i386-specific thing was blacklisting intel_agp
<daniels> lamont: obviously when they said 'make a terrible video card', their employees obviously took it as a challenge, rather than an opportunity to be lazy for months
<lamont> lol
<pitti> tritium: no, there is no iBook G4 sleep support in the kernel
<pitti> tritium: even if I remove all modules, X, etc.
<tritium> pitti, oh, it's in the kernel itself.  Okay, sorry...
<pitti> tritium: Benjamin Herrenschmidt is working on that, but it isn't ready yet :-(
<mantiena> btw, I've read, that savage already has open source DRI and DRM drivers ;) maybe somewhere are some development debs or debianized sources ?
<tritium> Well, hopefully it will be ready soon.  I plan to buy a powerbook in the next few months.
<pitti> tritium: for powerbooks the patch already seems to work
<mantiena> for Xorg
<daniels> mantiena: no, and there won't be for hoary
<daniels> they're still experimental (read: broken)
<pitti> tritium: i. e. Kamion and sjoerd use it regularly (IIRC)
<tritium> pitti, excellent news.  Will that patch be in ubuntu kernels soon?
<pitti> tritium: I doubt, it's too invasive
<pitti> tritium: and believe me, we do bugged fabbione enough about this :-)
<tritium> pitti, okay.  Thanks for the info, though!  Heh :)
<mantiena> daniels, they aren't included into lates Xorg (6.8.2) ?
<pitti> s/do bugged/did bug/
<daniels> mantiena: no, they aren't even in Xorg HEAD
<daniels> it's a combination of latest DRM + Xorg HEAD + DRI HEAD
<mantiena> daniels, hehe, it seems savage users should wait few months ;)
<daniels> mantiena: yeah
<mantiena> daniels, thanks for sad info >:>
<tseng> seb128: mailed you the f-spot sources, ping me with any issues.
<seb128> tseng: I've just replied
<seb128> tseng: need to build-dep of libgphoto2.2-dev
<tseng> hm i was *sure* i did that
<seb128> s/of/on/
<zul> seb128: heh did you have a look #6712 yet?
<seb128> tseng: perhaps you updated debian/control which is replace with debian/control.in on build ?
<tseng> seb128: that must be it.
<seb128> tseng: BTW I'm away for an hour or so, I'll upload it tonight 
<winkle> tseng: could you fix muine while you're at it? :)
<tseng> winkle: someone else "fixed" it, but its FTBFS
<tseng> winkle: something nasty looking about libxine.
<seb128> tseng: xine-lib FTBFS in ffmpeg with asm stuff here
<seb128> perhaps the same issue
<tseng> seb128: reuploading now. thanks
<tseng> hm
<seb128> BTW I'm out for a while, bbl
<tseng> cya
<tseng> winkle: could be solved possibly by syncing with debian, their latest is using gstreamer
<winkle> tseng: yeah, I saw that
<tseng> the muine maintainer still seems hesitant to upload gtk-sharp 1.9.2 to experimental
<tseng> which for some reason makes me less eager to stick it in universe
<tseng> on the other hand, it currently on is used by muine afaik, and is parallel installable
<Kamion> oh, wow
<tseng> cant hurt much.
<Kamion> the Tagalog word for "archive" is "arkibong"
<daniels> Kamion: nice!
<tseng> do I still need to mail mdz/jdub to approve a sync into universe?
<elmo> no
<elmo> you need to be a MOTU tho; I forget if you are or not (sorry)
<tseng> elmo: in that case, can you please sync muine. (I am on the MOTU wiki :)
<Felixjuh> Will Hoary ship Xorg 6.8.1 or 6.8.2? There are some Intel 810/815 problems (refresh problems) in 6.8.1 so the live CD isn't working :(
<tseng> Felixjuh: the current xorg in hoary is 6.8.1 with a huge backport from .2
<Kamion> Felixjuh: current plan is 6.8.2
<daniels> Felixjuh: eh, 6.8.2, but 6.8.1-1ubuntu16 is almost entirely 6.8.2 anyway (it's missing about four patches)
<daniels> the problem you have is actually caused by drivers/i810 from CVS HEAD, so in this case, it's too new rather than too old :P
<Felixjuh> Ah I see :) thanks for the reply, so it's a known problem? or should I still bugzilla it? 
<daniels> Felixjuh: known problem, will chase down the fix one way or another before hoary
<elmo> [NOT Updating - Modified]  muine_0.6.3-5ubuntu1 (vs 0.6.3-6)
<elmo> tseng: ok to override ubuntu changes?
<tseng> elmo: yes.
<Felixjuh> daniels: cool thanks! :)
<tseng> that was meant to be a rebuild against new libflac
<daniels> Felixjuh: no worries
<elmo> tseng: done
<zul> hey t-bone
<T-Bone> hey zul :)
<Mitario_> hello again
<tseng> elmo: thanks.
<sivang> seb128: still here?
<tseng> sivang: left for an hour he says
<T-Bone> Kamion: low-pri ping ;)
<Kamion> T-Bone: sorry I'm not going to manage the pci.handmap stuff today, other stuff has come up
<T-Bone> damn :P
<Kamion> I have to leave for the weekend in about 40 minutes
<T-Bone> Kamion: no way you could send me a draft so that I'd now what to put in there?
<Kamion> T-Bone: haven't got that far sorry
<T-Bone> forget it. Hope we'll make it in time for hoary anyway :)
<T-Bone> i'll deal with zul/lamont for the kernel fixmerge party now :)
<zul> oh yay!
<Kamion> I totally intend to, it will fix a whole lot of regressions from warty
<T-Bone> Kamion: cool!
<mako> have people seen the new http://www.ubuntuitalia.org ?
<sivang> mako: wow
<sivang> mako: what the ? ;-))
<mako> yeah, seriously :)
<zul> mako: i should be getting my key signed today but its my non-gentoo email address
<sivang> mako: is it plone?
<lamont> Kamion/daniels: what's the word on that demo-process?
<mako> zul: i first read that, "non-ghetto" email address ;)
<Kamion> lamont: trying to finish off now
<daniels> lamont: the word is 'fuck'
<T-Bone> lamont: #ubuntu-kernel for kernel work ;)
<lamont> kamion/daniels: IOW, can we break the kernel?
<daniels> but i suspect that's not what you were after
<Kamion> lamont: please wait a bit :)
<lamont> T-Bone: is #ubuntu-kernel logged?
<daniels> lamont: give us an hour or something and we'll let you know
<Kamion> as in, not *right* now ...
<lamont> Kamion: we talking monday, or later?
<T-Bone> lamont: by me. If you want to do it otherwise go ahead :)
<lamont> T-Bone: grumble.
<daniels> lamont: we're talking 'this one should be gold, honest'
<Kamion> lamont: hopefully tonight should be fine
* lamont logs also, but we should help fabbione's logging stuff along before we go start our own channel;
<lamont> Kamion: planning to have things together by monday-ish
<Kamion> oh hell, that'll be more than fine
<zul> mako: same thing ;)
<lamont> T-Bone: IOW, I'd prefer to leave the kernel conversations here until fabbione starts logging #ubuntu-kernel, or I figure out how to do it for him in his absence...
<T-Bone> lamont: i can start an instance of irc2html there
<lamont> T-Bone: let me look at my fabbione mail in a minute
<tseng> argh
* lamont boggles at realizing that fabbione has a non-ipv6-understanding netcat deployed on his home network
* T-Bone tries to figure out how irclog2html is supposed to be used
<thom> T-Bone: you run a client and then feed irclog2html the logs
<lamont> bummer.  sparcbuildd machine is down.
<T-Bone> thom: trying to do that
<lamont> well, that was short. :-(
<thom> quick, fly elmo to denmark!
<T-Bone> irclog2html <xchatlogfile> doesn't seem to produce any output
<tseng> this is retarded.. muine refuses to build any more
<tseng> same version we've had for ages
<T-Bone> bummer. it writes its output to the originating directory
<zul> thom: fly? teleportation is much more efficent
<lamont> thom: on the bright side, he won't waste cycles building things that will be superseded anyway :-)
<T-Bone> lamont: ok logging works and I'll be pleased to upload logs wherever you'd want me to :)
<daniels> thom: fly?  he can drive
<lamont> T-Bone: heh
* lamont clutters his window listing more
<T-Bone> lol
<mako> 
<T-Bone> hey mako!
<mako> T-Bone: yeah
<daniels> mako: trying to kill your window, eh? :)
<mako> daniels: i was trying to kill the line
<daniels> mako: ah
<daniels> with ^A^K?
<mako> i'm so excited.. there's a snowstorm and i am going to go see The Gates covered in snow 
* luis_ kicks mako
<thom> "the gates"?
<thom> oh, as in the building
<thom> right
* luis_ assumes the artwork in central park
<mako> http://www.christojeanneclaude.net/tg.html
<mako> when i saw it, the first thing i thought was "this would look AWESOME in the now"
<mako> is now the snow even
<thom> holy crap
<thom> that's pretty awesome
<sivang> I hope to canvas doesn't tear up under the weight of the snow
<rburton> mvo: do you have a synaptic supporting the pluggable progress window for sid?
<mvo> rburton: wanted to upload it today, not yet
<mako> sivang: the canvas is hung in such a way that this wouldn't be a problem
<sivang> mako: ah ok
<rburton> mvo: i'll apply your patch when i can test it
<rburton> but it looks good
<mvo> rburton: cool, thanks. if you want to test it fast, I can make the synaptic tarball available (with debian/ dir) so that you can build it yourself
<rburton> mvo: i'll wait
<Kamion> Keybuk: how would I use hi_mom.py by hand to merge a Debian change, given all three source packages required for the three-way merge?
<Keybuk> you have them on disk?
<Keybuk> or you want it to fetch them?
<Keybuk> if you have your own checkout, "hi_mom hotplug main" or similar works
<Kamion> I have them on disk
<Kamion> would rather it didn't fetch them
<T-Bone> Kamion: weren't you supposed to leave for the weekend at some point? :^)
<Kamion> yes
<T-Bone> begone then! B-)
<Kamion> Keybuk: anyway, if I could lodge being able to do something like "hi_mom netcfg_1.07.dsc netcfg_1.07ubuntu7.dsc netcfg_1.08.dsc" as a feature request, that'd be cool
<Keybuk> you can do it in the API, import hi_mom and then hi_mom.prepare(...) and hi_mom.merge(.....)
<Keybuk> (after some sifting; it would be handy if there were a one-shot though, yeah)
<Keybuk> though it'd be also handy if there were a config for it so you didn't have to grab stuff from sourcerer and hct to make it run :p
<Kamion> I'll have a go at that early next week then
<Kamion> Keybuk: (also, if you could re-mirror scott@canonical.com--2005/mango-sorbet that'd be good
<Kamion>  MISMATCHED ARCHIVE CHECKSUM
<Kamion>   archive: scott@canonical.com--2005
<Kamion>   revision: mango-sorbet--devel--0--patch-17
<Kamion>   file: mango-sorbet--devel--0--patch-17.patches.tar.gz
<Kamion> )
<Kamion> the baz bug I assume
<Keybuk> yeah
<Kamion> hm, baz doesn't like it if you crash in the middle of 'baz switch'
<Kamion> $ baz update
<Kamion> update: tree has no common history with version
<Kamion>     tree: /home/cjwatson/src/canonical/mango-sorbet/mango-sorbet
<Kamion>     version: scott@canonical.com--2005/mango-sorbet--devel--0
<Kamion> $ baz switch scott@canonical.com--2005/mango-sorbet--devel--0
<Kamion> Specified directory does not exist
<Kamion> Path: scott@canonical.com--2005/mango-sorbet--devel--0--
<Mithrandir> join-branch, then
<Keybuk> he's just going "yeah" at the moment :p
<lifeless> Kamion: baz tree-version <old-version>
<lifeless> Kamion: then switch again.
<Keybuk> like we did last summer...
<lifeless> what baz version btw ?
<lifeless> silbs?
<lifeless> ah, not on this cahnnel :)
<Kamion> mkay
<Kamion> ii  bazaar                                         1.1.1                                          arch revision control system
<lifeless> right, I think thats fixed in 1.2
<Kamion> ok
<Keybuk> Kamion: ok, mango-sorbet remirrored
<pitti> lifeless: btw, is "baz rm" fixed for directories in 1.2, too?
<lifeless> pitti: fixed ?
<pitti> lifeless: 
<pitti> postgresql-8.0-8.0.1/debian$ baz rm po
<pitti> attempt to remove directory po
<pitti> lifeless: po is an empy, but registered directory
<lifeless> uhm, don't think soo
<lifeless> rm -rf will work, fwiw.
<pitti> $ baz rm --help
<pitti> remove a file (or dir, or symlink) and its explicit inventory tag (if any)
<lifeless> I agree that should be fix.
<lifeless> *fixed*
<pitti> help says it can remove dir
<pitti> lifeless: that'd be great
<pitti> lifeless: so just rmdir will work?
<lifeless> yahuh.
<pitti> okay, nice
<pitti> thanks
<thom> seeeeeeeeb!
<sivang> thom: everything's ok?
<thom> sivang: eh?
<thom> no, he's broken yelp :P
<sivang> ah
<sivang> ;-)
<thom> he's going to blame me though
<sivang> well, he'd probably fix it quick no?
<sivang> or maybe, EZ GTK BOOG ?
<thom> no, it's not that simple i think
<sivang> it's working fine here
<sivang> what is the problem?
<thom> try viewing anything that's brought in by doc-base
<sivang> thom: man pages for instance?
<thom> no
<thom> the ESP ghostscript manual, if you have it, is one
<sivang> ok, I'll check
<thom> or applications/programming/dive into python
<sivang> thom: ah that? I got used to seeing that
<sivang> thom: thought it was regular of the development cycle..;-)
<seb128> tseng: here ?
<seb128> thom: http://bugzilla.ubuntu.com/show_bug.cgi?id=6705 ?
<seb128> thom: I've opened a bug upstream, but I'm not sure that's an yelp issue, the documents are not correct according to the dtd
<thom> seb128: ross was saying it doesn't happen with yelp linked to mozilla in sid
<thom> just with ffox in hoary
<rburton> yeah
<rburton> you all suck
<seb128> gni ?
<seb128> debian has 2.6
<seb128> we have 2.9
<rburton> seb128: i've got 2.9 from cvs
<seb128> rburton: have you tried 2.9.3 ?
<seb128> maybe that's fixed in the CVS
<rburton> $ yelp --version
<rburton> Gnome yelp 2.9.3
<rburton> let me try
<seb128> I don't get how the backend would change that
<seb128> trying to open a document with mlview gives the same error
<seb128> the pages don't follow the dtd
<rburton> i'm happily viewing diveintopython
<rburton> what xml parser is giving those errors
<sivang> thom: btw, people told me that #6590 isn't happening on debian, might be worthwhile checking the changed on the ubuntu pkgs?
<seb128> xmllint --valid /usr/share/doc/diveintopython/html/index.html 
<seb128> hum
<seb128> if I try to open it with mlview
<seb128> file:///usr/share/doc/diveintopython/html/index.html:15: parser error : Opening and ending tag mismatch: link line 0 and head
<seb128>    </head>
<rburton> that xml error comes from mozilla
<seb128> hum ?
<seb128> mlview doesn't use mozilla, that's a xml editor :)
<rburton> the one in the bug
<thom> sivang: i know exactly what 6590 is
<rburton> so blame firefox
<seb128> rburton: lemme try to build with mozilla
<sivang> thom: I may try and fix it if you care to explain where, but if it's not RC stuff I'd cotinue to decipher some gnome-cups-manager mumble people have written as bugs :)
<thom> sivang: i'd prefer that you do other stuff, tbh
<sivang> thom: ok :)
<thom> you'll get to have fun testing it since i have no clue if hebrew is backwards forwards or sideways
<sivang> thom: hehe, ok, I personally do mind that much, my folks over the country team however....;-)
<sivang> s/do mind/do not mind/
<thom> heh
<seb128> thom, rburton: same error with the mozilla backend
<rburton> your stupid mozilla shouldn't think it's an xml file
<rburton> its clearly html
<rburton> i've got moz 1.7.5
<sivang> rburton: I thought yelp feeds off docbook xml...isn't dip one such document?
<seb128> ii  mozilla-browse 1.7.5-1ubuntu1 The Mozilla Internet application suite - cor
<seb128> rburton: how do you know than mozilla thinks that's an xml file ? it opens it right here
<seb128> yelp doesn't
<seb128> rburton: ?
<seb128> any hint ?
<rburton> no idea
<rburton> sorry
<seb128> k, no problem
<seb128> I'm just surprised that work on a debian system :)
* mvo leaves to play some hockey
<zul> mako: ping
<rcaskey_> so is the MTA still going to be nixed?
* lamont-away lunches
<tseng> seb128: here now
<seb128> > I have it packages, but I was waiting for testing output (no mono on my
<seb128> computer right now).
<seb128> 
<seb128> reply from the debian maintainer
<seb128> he says that I can go ahead with your package if I want
<tseng> sounds great.
<seb128> do you have changed some tricky part ? Or should I say him to get ahead with his version ?
<tseng> well, i changed a few minor things
<tseng> first, i stopped copying two files into debian/f-spot from debian/ that are now in the main distribution
<tseng> second I added an mv of libgphoto2-sharp from /usr/lib/mono to /usr/share/dotnet/f-spot or so
<seb128> I've asked for his package in fact, I'll diff both
<seb128> k
<tseng> really just cleaning up to the latest version..
<seb128> do you mind to get tours version since you worked on it ?
<tseng> not especially, as long as it works
<seb128> cool, thanks!
<seb128> BTW time for dinner
<tseng> ok.
<robtaylor> hmm, think i might have a clue why ipw2100 isn't working on my box..
<robtaylor> i take it th0: Radio is disabled by RF switch. isn't normal?
<robtaylor> s/th0/eth0
<tseng> robtaylor: do you have a switch or a wireless function key on f2?
<Mitario> anyone who uses ACL permissons on their directories? files?
<tseng> support questions really belong in #ubuntu, dudes.
<Mitario> oh sorry, wrong channel
<Mitario> forgot to press alt f3 :)
<mjg59> robtaylor: Either you have a hardware switch or a software switch that controls it
<mjg59> If there's no physical switch, check rfswitch.sf.net
<robtaylor> mjg59: coolio thanks :)
<robtaylor> i definitly havn't switch anything since it was working with 2.6.9, so :/
<mako> zul: hey there
<zul> mako: willy has my key he just has to sign it should i send you my keyfingerprint now or should i wait?
<mako> zul: upload the key to a keyserver
<mako> i'd prefer keyserver.kjsl.com
<mako> then send me the signed coc
<zul> mako: ok
<mako> and ping me when willy has uploaded the signed key to a keyserver
<zul> great thanks
<robtaylor> tseng: this is a regression from warty, so probably more relevent here..
<tseng> robtaylor: it doesnt sound like a regression
<tseng> it sounds like you accidentally pushed an RF kill switch
<tseng> which I've done myself
<robtaylor> tseng: appears i have a software switch
<tseng> here its Fn+F2, some have a real switch
<robtaylor> ahhh
<tseng> see a little wireless tower icon by chance?
<robtaylor> got it.. 
<robtaylor> *doh*
<tseng> drs appointment, bbl
<Mitario> ok, little question here: should distro names like 'Warty Wharthog' also be localized?
<Mitario> eh Warthog
<mako> Mitario: i'd say no
<mako> Mitario: that would get insane :)
<Mitario> hmm, me either
<Mitario> yeah :)
<Mitario> i would laugh every time I see that name in dutch ;)
<mako> i'm a native english speaker and i didn't even know what "hoary meant :)
<mako> maybe it's more common on the other side of the pond
<Mitario> heh, dunno, i have really no clue what it means
<mako> white..
<mako> like having white hair.. old
<Mitario> ahh
<Mitario> hmm, and what about numbers like '5.04'
<Mitario> i mean is that part of the name
<mako> not to be confused with whorey hedgehot.. which is something else entirely
<Mitario> or actually a version numer
<mako> it's a version number
<mako> it stands for the year and the month
<mako> 2005/04
<Mitario> yeah i know, but would for example a chineese translator want/need to translate it?
<mako> no
<Mitario> So you get like Ubuntu Hoary <some chinese chars> "Hoary Hedgehog"
<Mitario> ok
<Mitario> good ;)
* Mitario is fixing translator annoyances for update-manager
<mako> if it's really more common to write the equivalent of "Five point four" than 5.04, that's fine but i don't know of a language where that would happen
<Mitario> ok
<Mitario> hmm, and for something as 'Debian Stable'? would a translator need/want to translate 'Stable'?
<Mitario> or is that also 'part of the release name'
<pitti> good night everybody
<mako> Mitario: i'm not sure what the convention is there
<mako> Mitario: but stable is a term that people to type into their sources list.. so i would treat it like hoary unless we're using it as an adjective
<Mitario> yeah ok
<whiprush> tseng: ping
<zul> later
<Mitario> hi mvo!
<mvo> hi Mitario 
<Evaso> what is the status of packet writing (udf) support in hoary after the official support in kernel 2.6.10?
<lamont> jdub awake?
<lamont> or mako?
<tseng> whiprush: yes?
<whiprush> I wanted you to check my f-spot package. But nm ...
<whiprush> .8 requires gphoto-sharp
<tseng> gphoto-sharp is part of f-spot
<tseng> i made a package also
<whiprush> oh
<tseng> but the maintainer has one
<whiprush> I wonder what I messed up. :-/
<tseng> you can look at mine
<whiprush> I'd like to
<tseng> http://getsweaaa.com/~tseng/f-spot
<tseng> it works great, but seb talked to the maintainer and is taking his package possibly
<tseng> we assumed the maintainer wasnt interested since he hasnt uploaded a new version since forever
<whiprush> Mine wouldn't build in pbuilder without liblcms1-dev as a build-dep
<tseng> thats a build dep in the original I believe
* tseng looks
<tseng> gar, guess not. it got pulled in on my system from somewhere
<metalikop> what's the cleanest way to resolve a W: cfv: script-not-executable ./usr/lib/python2.4/site-packages/cfv.py
<metalikop> error
<tseng> metalikop: chmod +x cfv.py
<metalikop> that's what I figured, just wanted to make sure that was the clean way to do it
<metalikop> postinst?
<tseng> cleaner would be earlier than that
<tseng> when its still in debian/foopackage/usr/lib/python3.4
<tseng> package im looking at does stuff like that in binary-install
<metalikop> which package would that be?
<tseng> f-spot
* luis_ discovers tseng's muine packages
* luis_ thanks tseng profusely
<tseng> luis_: thank dajobe mostly
<metalikop> I'm looking for docs or something on binary-install.
<tseng> luis_: he picked up one patch from me, i mostly rebuilt his sources
<metalikop> Can you point me in the right location?
<tseng> debhelper docs, um..
<tseng> maybe not.
<metalikop> I checked through that & dh_install
<mako> lamont: yeah
<tseng> luis_: see how well those work for awhile.. id like to stick them in universe
<luis_> tseng: yeah, I'll punish them heavily; muine is the only thing we use for music here and my gf has been asking for a version with shuffle for a while
<luis_> so they'll get heavily used
* luis_ just shuffled 143 hours of music
<tseng> luis_: i seem to remember you blogging about muine on a set top box with xfce
<luis_> yeah
<luis_> though I ended up not bothering with xfce, and just using the standard gnome panel stuff
<tseng> luis_: heh, dajobe has no qualms about us uploading those
<luis_> the muine ones or f-spot?
<tseng> muine
<luis_> in exactly two songs worth of testing they seem to work fine ;)
* luis_ has to test on laptop before upgrading gf's machine
<tseng> yeah I've been using it for weeks.
* luis_ ponders upgrading the gnome liveCD to today's hoary liveCD
<tseng> luis_: add muine !!
<tseng> :)
<luis_> I have
<luis_> well, no, I take that back, I didn't, because of the libflac thing
<luis_> I assume yours depend on libflac6 and not 4?
* lamont goes to fetch kids
<tseng> correct
<tseng> the current one has had fixes uploaded, but they all fail to build =/
<tseng> on libmuine, gst or xine. tis odd, seeing as its the same version we've had forever
<luis_> weird.
<luis_> anyway, I'd definitely love to have muine on the liveCD
<luis_> and I'll probably use your f-spot packages
<luis_> but right at the moment I seem to have screwed up the liveCD badly enough that it is nearly 900 megs
<luis_> so I have to figure out the cause of that and fix it first :)
<whiprush> that used to happen to me.
<whiprush> when I tried putting it back together but everything was still mounted.
<luis_> ah-ha
<mdz> Kamion, here?
<luis_> whiprush: you are wise
<luis_> as usual
<mdz> lamont, here?
* luis_ unmounts, rebuilds
<mdz> jbailey, ?
* luis_ wonders if he should remove ooo 1.1 and put in 1.9.x
<jbailey> mdz: Here.
<mxpxpod> does the icon caching thing mess anyone elses icon themes up?
* T-Bone is getting more and more convinced that the SIGILL bug is a ubuntu-only bug
<T-Bone> (on ppc)
<mxpxpod> T-Bone: what's that?
<T-Bone> mxpxpod: random build kills with SIGILL
<T-Bone> on ppc
<mxpxpod> T-Bone: never had that problem
<T-Bone> with Ubuntu kernels
<T-Bone> mxpxpod: neither did I until i used ubuntu-shipped kernels
<mxpxpod> strange
<T-Bone> mxpxpod: it seems to be a known bug, it happens on ubuntu buildds as well
<mxpxpod> hmm
<mxpxpod> T-Bone: I'm having strange problems with icon themes
<T-Bone> same here since I upgraded 1h ago
<mxpxpod> T-Bone: if I remove all the icon-theme.cache's from my icon themes, everything works fine
<T-Bone> already seen that kind of bug in Debian a long time ago
<T-Bone> mxpxpod: i guess you want to report a bug on bugzilla
<T-Bone> (and note the fix as well :)
<mxpxpod> I'm wondering if gtk-update-icon-cache needs to be run in a certain order on icon theme dirs
<T-Bone> feh. Yet another GTK B00G
* T-Bone wibbles
<mdz> jbailey, never mind, found lamont
* jbailey blinks.
* T-Bone digs into powerpc patches
<mxpxpod> *sigh*
<mxpxpod> if only icon caching actually worked...
<jbailey> mxpxpod: That's already in bugzilla.
<mxpxpod> jbailey: what bug?
<jbailey> mxpxpod: icon caching sucking on ppc.
<jbailey> np237 and I looked at it a bit this morning.  Looks like bad mapping of a hash algorithm to disk.
<mxpxpod> nice
<mxpxpod> endianness?
<jbailey> Probably.  The file gets mmap'd.
<jbailey> Either that or alignment.
<mxpxpod> jbailey: do you have the bug number?
<jbailey> (Actually, more probably alignment, since the file is generated on the local host)
<jbailey> mxpxpod: Nope, but searching bugzilla for 'icon' this morning was enough.
<mxpxpod> jbailey: gnome bz or ubuntu bz?
<jbailey> mxpxpod: Ubuntu.
<jbailey> mxpxpod: It's also in the Debian BTS.   It's not a recent bug, it's just that we've started to use icon caches. =)
<mxpxpod> jbailey: hmm, is it the hicolor-icon-theme one? I don't see anything about icon caching on ppc
<jbailey> Yeah yeah yeah, make me do work why don't you? =)
<mxpxpod> :P
<jbailey> But I was so enjoying reading the CGI spec and debugging Perl. =)
<mxpxpod> just think of this as a fun distraction
<jbailey> https://bugzilla.ubuntu.com/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=icon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=DUPLICATE&resolution=---&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa
<jbailey> _contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
<jbailey> All of the DUPLs at the top. =)
<jbailey> WEll didn't that paste just suck?
<T-Bone> jbailey: as most bugzilla URLs, yeah :)
<jbailey> wtf?
<jbailey> https://bugzilla.ubuntu.com/show_bug.cgi?id=6697 claims that it's a dup of 6715.
<jbailey> Which it's certainly not. =)
<T-Bone> somebody was on crack when editing the bug? :)
<T-Bone> hmm. Seems much easier to reproduce the SIGILL shyte on super fast g5 than on g4...
<jbailey> T-Bone: Yeah.  Take a look.  The original bug and all of the replies have nothing to do with one another: https://bugzilla.ubuntu.com/show_bug.cgi?id=6715
<jbailey> All Debian imported, so I'm not going to fuss with it.
<T-Bone> looks like i'll have vm/pm debugging to do. *sigh*
#ubuntu-devel 2005-03-02
<jbailey> T-Bone: What are you hacking?
<T-Bone> jbailey: i'm whacking, mind you. The ppc kernel :P
<jbailey> Oh nice.  Je te laisses tranquille!
<T-Bone> though i wonder whether that could be some glibc bug
<T-Bone> s/laisses/laisse/ ;)
<jbailey> Mm.  that's right.  conjugated from Je, not te.
<T-Bone> since I built my ppc64 gentoo fine on that very same box...
<T-Bone> s/te/tu/ ;)
<jbailey> No, I had 'te' in the sentence, unless that was wrong?
<mxpxpod> jbailey: you said they're using a mmap in update-icon-cache?
<jbailey> T-Bone: I was playing with the that that our glibc might be the cause of my gij breakage, since I couldn't imagine that noone else was seeing it, but upstream glibc is currently have gcc4-on-ppc issues at the moment.
<T-Bone> jbailey: sorry yeah, i've too hasty :)
<jbailey> mxpxpod: I think so.  I remember seeing that it pulled in mmap and such.
<T-Bone> jbailey: well, that'd make sense. I have no such issues on my pegasos running either debian or gentoo
<mxpxpod> I'll have to go over the source tonite
<jbailey> mxpxpod: It either is trying to mmap and arch-indep file, or it should be in /usr/lib, mind you.
<T-Bone> jbailey: the bugzilla stuff is complete crackpot
<jbailey> T-Bone: We use the same glibc as Debian pretty much, down to the same compiler.
<T-Bone> hmm
<jbailey> T-Bone: If you're seeing a difference between Debian Sid/Sarge and Hoary there, I'd suspect our kernel.
<T-Bone> jbailey: i just tried a pristine kernel from -mm series, had the bug.
<jbailey> Fall back to 2.6.8 maybe?
<T-Bone> so it's either not the kernel or not our kernel
<T-Bone> could try this
<jbailey> Just thinking that we've moved beyond even in releases.
<T-Bone> gentoo is running 2.6.10. And you know how build intensive that shit is. Never got any build kill there...
<T-Bone> but that's a g4 cpu
<T-Bone> and UP
<jbailey> Mm, that's true.  Do try the Debian kernel package, anyway.
<jbailey> It's a a quick enough test.
<T-Bone> i built mplayer under debian pretty fine. I can try loop building glibc/gcc/kernel to check tho
<jbailey> T-Bone: You should be able to also load the Debian glibc onto Ubuntu without any hiccups.
<mxpxpod> jbailey: welp, I'll take a look at the icon cache thing tonite and see if I can see what's wrong... where does gtk+ read the caches?
<jbailey> mxpxpod: ISTR that the file is called gtk-icon-cache.c =)
<mxpxpod> :P
<mxpxpod> I just saw that
<T-Bone> jbailey: fwiw, if you wanna hang out, we've setup a #ubuntu-kernel irc chan for us kernel crackheads ;)
<jbailey> I remember it took me 30 seconds to find it and 2 minutes to read the code. =)
<T-Bone> jbailey: i wonder if building inside a chroot would be a good enough test
<T-Bone> a debian chroot, that is
<mxpxpod> gotta go
<jbailey> T-Bone: I don't know enough about the mechanics of a chroot on Linux.
<T-Bone> it should be enough to isolate glibc
* T-Bone tries
<jbailey> Cool.  Remind me, chroot is a syscall, right?  Not an emulation through the chroot program?
<T-Bone> err
<T-Bone> i'm talking about chrooting myself into a sid jail from my hoary system
<T-Bone> so that i'd end up using a sid environment while running the hoary kernel
<T-Bone> if it goes fine, then the kernel is not to blame
<T-Bone> and thus, most likely the glibc ;)
<T-Bone> if it goes wrong, it proves nothing :)
<jbailey> True.  I think replacing your kernel and rebooting might be less work than that. =)
<T-Bone> jbailey: actually i have a chroot ready :)
<T-Bone> fired a make -j4 loop. Waitandsee
<luis_> hrm
<luis_> oh, nm
<lamont> gpg: Note: This key has expired!
<lamont> bad seb128
<sid77> ciao
<Riddell> if I have a package version 1.2beta3-0ubuntu1  what do I call the final version?  dpkg seems to think 1.2-0ubuntu1 is a downgrade
<crimsun_> it is
<crimsun_> (a downgrade)
<crimsun_> calc suggested doing betas and rcs as, for instance, 1.2~beta3-foo
<zul> hey
<crimsun_> lo
<Riddell> hmm, do I need to up the epoc again?
<crimsun_> that's what I'd do in the last case
<zul> mavo: i just sent you the signed coc
<zul> bleah..mako i just sent you the signed coc
<zul> sorry my bad
<mako> zul: cool
<luis_> tseng: what is the sources.list line for your f-spot and muine packages? (and is there anything else in there?)
<zul> hey jdub 
<rburton> yo yo jdub 
<rburton> jdub: new g-a-i in ubuntu!!! :)
<luis_> g-a-i?
<Mitario> hi jdub
<jdub> morning
* jdub is very grumpy atm
<zul> how come?
<jdub> dunno
<ajmitch> morning jdub 
<jdub> luis_: gnome-app-install, first sweep at doing a really usefully user-centric application installer
<luis_> ah, nice
<ajmitch> luis_: uploading muine & gtk# for tseng in a few min
<Mitario> wow, buildd was fast? michael uploaded a source package about one hour ago
<luis_> ajmitch: ah, cool
<luis_> any idea about f-spot?
<ajmitch> not as yet
<jdub> Mitario: buildds are super speedy and run every half hour :)
<Mitario> jdub, ahh nice :)
<luis_> (this is probably the last liveCD I can build for a bit over a week)
<luis_> hrm
<jdub> luis_: mako tells me you guys hooked up at lwe
<ajmitch> he said he packaged it this morning
<luis_> is there a way to do something like 'dpkg -i http://www.getsweaaa.com/~tseng/f-spot/f-spot_0.0.8-1_i386.deb'
<ari> jdub: it was hot
<luis_> jdub: yeah, we talked for a bit, not long enough :)
<jdub> luis_: wget... ;)
<luis_> jdub: blah, rpm -ivh and rug in can both take URIs ;)
<jdub> yeah, we'll fix apt to do that soon
<jdub> apt-get install <deb> and apt-get install <deb-uri>
<jdub> so we can completely ignore dpkg :-)
<Mitario> jdub, btw, can you do something for me? modifying my pgo feed
<jdub> (that said, it could be smartpm)
<jdub> Mitario: got your mail
<Mitario> ok great
<Mitario> :)
<Mitario> nm me then
<rburton> luis_: g-a-i kicks arse if i do say so myself
<rburton> even more so with mvo's latest patch
<jdub> rburton: good stuff
<jdub> ?
<rburton> jdub: runs synaptic in a thread so the UI doesn't die and embeds the synaptic progress window
<Mitario> rburton, do you think we can integrate your neat .desktop file app icon fetch thingy in update-manager?
<jdub> rburton: haha, rad
<rburton> Mitario: jdub was writing that
<mako> jdub: yeah we had a good time
<rburton> jdub: another new release with that and new desktop files next week i guess
<mako> jdub: i had a good time with the host of the gnome guys actually
<jdub> rburton: yeah, i'll ship a data package probably over the weekend
<rburton> jdub: that would totally rock
<jdub> Mitario: hrm
<jdub> Mitario: that gets kinda backwards on us
<jdub> Mitario: although it's probably doable
<Mitario> jdub, how do you mean?
<Mitario> well, i don't think it's nescesairy or something :) it would just look cool
<jdub> Mitario: you're coming from binary/source names, and want to get .desktop metadata; g-a-i has .desktop metadata and wants binary names (we just add a field in the .desktop file)
<jdub> Mitario: just gotta figure out how to do it ;)
<jdub> and it doesn't cover libraries and so on
<Mitario> no that's allright..
<Mitario> just an app icon for the apps that g-a-i also shows
<jdub> that said, it would be nice to have update-manager only show applications (and libraries only on checkbox, etc)
<Mitario> some sort of filters you mean?
<Mitario> my head's a bit slow atm, probably have to go to bed ;)
<jdub> ;-)
<jdub> nah, something to think about for hoary+1 anyway :)
<Mitario> hehe ok :)
<Mitario> all fine by me
<rburton> jdub: i want to get g-a-i ready for hoary so keep in touch if anything needs to be done
<rburton> i'm off to bed
<Mitario> brb need to restart X
<Mitario> back
<Mitario> ok, this is just like: WOW, I configured X to use hardware accel, started xcompmgr
<Mitario> it almost looks the same like NLD's flash-hack demo now :)
<HrdwrBoB> and it runs so very, very slow
<ajmitch> HrdwrBoB: depending on your hardware, ran fast enough for me
<Mitario> HrdwrBoB, its so fast for me
<Mitario> I have an nvidia card with some options from that gnomedesktop.org article
<Mitario> opening menus with fades + shadows is normal speed
<HrdwrBoB> ajmitch: I tried it on a 440mx and it made a very large performance difference
<Mitario> the only comment I have, is that my nautilus icons fall behind my panel :) and I can slide windows over my panel
<ari> i wonder how hard it would be to re-port xchat's perl plugin support to gaim
<ari> and python
<robertj> has there been general funkyness reporting on ppc recently?
<T-Bone> robertj: what kind?
<ari> i got a really weird bug report on gaim from ppc
<T-Bone> icons? SIGILL?
<robertj> icons
<T-Bone> known bug
<robertj> also I have a supicion that xorg-driver-synaptics doesnt take over for xfree86's synaptics
<daniels> er, it does
<robertj> daniels: it just removed it and I just installed xorg-driver-synaptics
<robertj> let me kill X and see if this is fixed
<robertj> brb
<mjg59> sivang: So everything works now?
<tritium> mjg59, sivang and I got his latitude 8200 suspending/resuming today with nvidia module using NvAGP
<robertj> daniels: it removed it when I installed xorg and I had to reinstall it
<mjg59> tritium: Ah, ok
<mjg59> Is that the default?
<daniels> robertj: so don't uninstall ubuntu-desktop
<tritium> mjg59, are you asking me
<mjg59> tritium: Yeah
<robertj> hrmm, wadda ya know, I didn't notice
<tritium> mjg59, no, if you don't blacklist intel_agp, agpgart will load, despite your xorg.conf setting
<robertj> thanks, sorry about that
<tritium> mjg59, also, had to pass module params for nvidia and disable video posting
<mjg59> tritium: Argh
<mjg59> I've no nvidia stuff to test this on, sadly (thankfully?)
<mjg59> It'd be nice if it could Just Work, but it sounds like it'd be a mess to integrate
<tritium> mjg59, and, even though my GeForce4 440 Go doesn't support SBA, this is the module param combination I need to use: mjg59, in /etc/modules: nvidia NVreg_EnableAGPFW=1 NVreg_EnableAGPSBA=1
<daniels> i have nvidia at hand, but unfortunately not laptops
<tritium> otherwise, it won't seem to work
<tritium> mjg59, send any tests to me, if you like
<mjg59> tritium: But it works fine with nv?
<tritium> mjg59, actually, I haven't really used with nv
<tritium> mjg59, I do have one strange problem.  I have to press power button 2X to resume
<tritium> haven't figured that one out yet
<mjg59> tritium: Yeah, you said. I have no idea whatsoever what could be causing that.
<tritium> Nor I.  Anyway, if you want me to test things out, let me know.
<mjg59> Will do
<tritium> cool
<tritium> mjg59, so what packages am I missing to have suspend an option on logout.  I have powermanagement-interface
<Mitario> guys, what do you think as something like http://geeklog.eyesopened.nl/wp-content/updatealert.png as a 'U have software updates' systray icon?
<mjg59> tritium: The code doesn't seem to be written yet
<tritium> mjg59, okay, thanks
<tseng> luis_: sorry, id gone to dinner
<robertj> Mitario: I would think a red background would be better
<Mitario> robertj, what do you mean?
<Mitario> robertj, i mean, isn't this already red?
<tseng> luis_: deb http://www.getsweaaa.com/~tseng/muine ./
<tseng> luis_: f-spot doesnt  have a Packages.gz
<robertj> Mitario: that icon looks black to me
<tseng> luis_: i can make you one if you are still around.
<Mitario> robertj, well i guess it's pretty darkish yeah :)
<Mitario> robertj, so you think it should be somewhat brighter?
<robertj> it should make your eyes burn
<tseng> ajmitch: oh snap.. muine is accepted before gtk#
<robertj> throbbing would be best
<Mitario> hehe ;)
<tseng> ajmitch: it might get stuck in dep wait
<tseng> ajmitch: was gtk# rejected, or not upped yet?
<luis_> tseng: nah, if it is going to get into universe within the next... well, say, next 7-8 days, don't bother
<tseng> luis_: f-spot was packaged also by the debian maintainer im told. sounds like we'll have that within that time frame hopefully
<tseng> luis_: you asked about other goodies.. my other package there was tomboy and is now in the archive proper
<tseng> so no, nothing else.
<tseng> some older stuff built against warty
<ajmitch> tseng: gtk# will be in NEW
<ajmitch> I uploaded them both at the same time
<luis_> tseng: cool, thanks
<ajmitch> only change I made was changing the distribution in debian/changelog to hoary
<tseng> right.. did you get an accepted mail for gtk#?
<ajmitch> no, but I don't get any mail when I upload normally :)
* ajmitch checks
<tseng> it goes to hoary-changes
<ajmitch> yeah
<Mitario> robertj, still here?
<ajmitch> I had issues uploading it the first time, possilby a partial .orig.tar.gz was uploaded, 2nd time it uploaded with no complaints
<Mitario> ok can anyone else critisize this one? :) http://www.geeklog.eyesopend.nl/wp-content/softupd2.png?
<ari> Mitario: link no work
<Mitario> ehh sorry http://www.geeklog.eyesopened.nl/wp-content/softupd2.png
<jdub> Mitario: our icon designer is going to do Human icons for those, btw.
<Mitario> oooh
<Mitario> ok, nice :)
<jdub> Mitario: might be worth using one of the gnome ones by default though
<tseng> Mitario: eh that second one doesnt seem working either here.
<Mitario> yeah, but which one
<jdub> tseng: strip the www
<Mitario> http://geeklog.eyesopened.nl/wp-content/softupd2.png
<Mitario> right, i really should go to bed
* jdub recalls hearing Mitario say that earlier ;)
<daniels> jdub: word
<tseng> heh.
<Mitario> hmm, really? ;)
<Mitario> i'm awake 20h now :/
<jdub> 11:49 < Mitario> my head's a bit slow atm, probably have to go to bed ;)
<jdub> and it's 13:40 now ;)
<Mitario> oh well,  :p
<Mitario> jdub, is there a schedule for the icons to 'officially' use them as default icon theme?
<jdub> next week or so
<Mitario> ahh ok, nice :)
<Mitario> will it have an 'you have software updates' icon?
<Mitario> a*
<jdub> the first drop might not
<jdub> but we will have one :)
<Mitario> ok
<Mitario> ok great :)
<Mitario> well, current update-notifier icon is also custom
<Mitario> michael suggested to design a new icon if i really had nothing to do anymore :)
<Mitario> and because i'm lazy right now.. and tired, and broke
<jdub> hrm
<jdub> windows is weird
<tseng> ajmitch: I guess we'll figure it out tommorow. thanks
<ajmitch> yeah, sorry about that
<Mitario> woo, finally fixed the bug
<Mitario> now i'm going to bed, good night/day everyone!
<ajmitch> night Mitario 
<tseng> night.
* luis_ burns Yet Another Try At A LiveCD
<luis_> oh, hrm
<luis_> can you not upload files to the ubuntu wiki?
<jdub> hrm
<jdub> dunno
<jdub> no, i think you can
<luis_> I couldn't find a link for it
<jdub> you'll have to search for a link somewhere, might be on the edit page page
<luis_> but maybe I was just failing to grok something obvious
<luis_> yet again
<jdub> no
<luis_> ah
<jdub> there is nothing obvious about zwiki
<jdub> well
<jdub> apart from the huge mole
<jdub> so i can't figure out how to make windows output via the spdif
<luis_> prayer
* luis_ attempts yet again to poke the liveCD into doing 1024x768
<jdub> btw luis_, we're having a party tonight, come over
<luis_> haha
<luis_> sure
* luis_ hails a cab
<daniels> jdub: can you send some pizza around?
<luis_> well, blah, my script is not as loveydovey as I'd hoped
<jdub> btw, are you getting spammed from FOSSTEC?
<luis_> I am not
<luis_> at least not that I've noticed
<luis_> blah, blam seems to have grabbed my keyboard and not let go
<jdub> aha! worked it out
<jdub> oof
<jdub> sounds good
<lamont> daniels: you around?
<lamont> oh! jdub
<daniels> lamont: word
<lamont> daniels: I have a patch for you for xresprobe - wanna see it?
<daniels> lamont: fo'sho
<lamont> daniel.stone@u.c?
<daniels> yahy
<daniels> also, yah
<lamont> makes it into if i386 else if ppc else ...
<daniels> cool
<lamont> Makefile:21: *** extraneous `endif'.  Stop.
<lamont> well.  that was the intent anyway...
<lamont> gimme a minute
<lamont> daniels: better patch mailed - actually works on at least 2 architectures. :-)
* lamont sleeps
<jdub> bad connection fu today
<dilinger> hrm
<dilinger> it's another jdub
<dilinger> #   Signed-off-by: Josh Boyer <jdub@us.ibm.com>
<jdub> spoken to him before, too :-)
<pitti> Morning folks
<lifeless> daniels: ping
<lifeless> someone tell daniels xorg preconf is fuxked
<lifeless> I mean really, I've been asked the 'do you want hw detection' question like 15 times now.
<lifeless> *I've answerd already, now go away kthnxbye*
<lifeless> lamont: ping 
<lifeless> - want a machine-hard-lokcup bug ?
<lifeless> or would you rather I don't share ?
<da_bon_bon> hi all.
<da_bon_bon> is gnome-panel maintainer here ?
<lifeless> thatd be seb128, who isn't
<da_bon_bon> ah, i wanted to make a reuest
<minghua> Hi, I have a question about mp3 support in Ubuntu
<minghua> the FAQ says mp3 is not supported due to patent issues
<minghua> and indeed gstreamer0.8-mad is not included in main (I suppose for exactly this reason)
<minghua> but on the other hand python-hip is included
<minghua> which can decode mp3 using libmp3hip0 (which comes from lame)                   
<minghua> I am perfectly happy with including libmp3hip0
<minghua> I am using it to listen to my mp3s now
<minghua> but I am just curious about the inconsistency here
<minghua> if we can include libmp3hip0, when not just have gstreamer0.8-mad so that we can listen do mp3s from rhythmbox?
<minghua> by the way this is about warty, I haven't looked at hoary yet
<pitti> minghua: hmm, that's a good discovery
<pitti> minghua: I think this deserves to be discussed on the mailing list
<minghua> pitti: are you subscribed to ubuntu-devel?
<pitti> minghua: of course :-)
<minghua> if yes, would you please send one mail for me?
<pitti> minghua: yes, I added it to my todo list
<minghua> I am not subscribed, and last time I sent a mail, it took about two weeks to pass moderation
<minghua> thanks. :-)
<pitti> minghua: send
<pitti> minghua: thanks a lot
<minghua> pitti:  Thank you.  I am probably going to subscribe ubuntu-devel soon. :-)
<pitti> Morning seb128
<seb128> hey
<seb128> pitti: the jail has a good internet connection ?
<seb128> :)
<pitti> seb128: I hope so
<pitti> seb128: to download mp3 w4r3z :-)
<pitti> hehe
<seb128> :)
<lifeless> pitti: you're doing kernel stuff now rightr ?
<pitti> lifeless: oh, I didn't know that up to now :-)
<lifeless> oh, I'm confused then :)
<pitti> lifeless: zul and lamont are core members of the kernel team
<lifeless> I know lamont is  .. ah
<pitti> lifeless: I only collect vulnerabilities :-)
<lifeless> zul ping ?
* pitti is the local security patch dealer
<lifeless> at least you aren't a crack dealer :)
<T-Bone> lifeless: what about kernel?
* T-Bone has a few more patches to merge in
<lifeless> fuse-source needs a patch, fabbione wanted feedback on it, this was while he was handing over to the kernel team.
<T-Bone> pitti: btw, dunno if lamont told you about #ubuntu-kernel :)
<lifeless> also the module control file incorrectly depends on kernel-image not linux-image
<pitti> T-Bone: no, indeed not. thanks
<T-Bone> pitti: well then now you know :)
<pitti> lifeless: btw, if 2.6.11 hangs, boot it with "noinotify"
<pitti> lifeless: that helped for me
<pitti> lifeless: 2.6.11 now ships fuse by default? good crack :-)
<lifeless> during the gnome-login is your hang ?
<pitti> lifeless: exactly
<pitti> lifeless: inotify is the culprit
<lifeless> pitti - no, apt-get install fuse-source + a small aptch
<pitti> lifeless: fabbione added a kernel parameter "noinotify" to disable it
<lifeless> pitti: thanks. someone should add that to the bug :)
<pitti> lifeless: hmm, jdub once told me that fuse will eventually be merged upstream
<Treenaks> pitti: fuse is in some -mm1 patch for the 2.6.11rc series though
<pitti> lifeless: its a s3kr3t :-)
<lifeless> yes
<pitti> lifeless: no, sersiously, it should be added
<lifeless> pitti (was answering treenaks)
<lifeless> cool. fuse working.
<lifeless> heh, that hangs it though :[
<lifeless> it ain't good at reentrancy
<Mitario> hi everyone
<pitti> seb128: I dist-upgraded and now most of my icons are gone
<pitti> seb128: known bug?
<seb128> pitti: ppc ?
<pitti> seb128: indeed
<seb128> iz gtk bug
<tseng> seb128: arg, i lost another build-dep to control.in on f-spot. my bad
<pitti> seb128: I did not upgrade this for maybe two weeks
<seb128> sudo rm -f /usr/share/icons/*/icon-theme.cache
<pitti> and relogin?
<seb128> killall nautilus
<seb128> just restart the apps, nautilus is the most obvious
<pitti> gnome-panel, I suppose
<seb128> if you have the issue on the panel yep
<pitti> yay, they are back
<pitti> seb128: thanks, dude
<seb128> tseng: could you make a 0ubuntu2 ? :)
<seb128> pitti: np
<tseng> seb128: already did.
<seb128> tseng: same location ?
<pitti> seb128: how can an arch-all thing like icons be ppc-specific?
<tseng> seb128: not uploaded yet. 2 mins
<seb128> pitti: that's the icon cache
<seb128> pitti: probably and endian issue
<seb128> s/and/an/
<pitti> hmm
<seb128> pitti: http://bugs.debian.org/295815
<pitti> seb128: btw, "cache" sounds like it should live under /var/cache, not /usr
<pitti> seb128: will that break with a r/o /usr?
<seb128> I've not tried
<T-Bone> jbailey suspespected an endianness/mmap issue
<seb128> possible
<seb128> gtk-update-icon-cache /dir/to/cache
<seb128> to create a cache for a dir
<seb128> that's what is called in the postinsts
<tseng> seb128: 0ubuntu2 in the same place.
<seb128> tseng: thanks!
<tseng> thank you.
* T-Bone rereads himself and considers getting some coffee before typing more :P
* tseng learned his lesson re control.in
<seb128> :)
<tseng> ajmitch: no sign of gtk-sharp-unstable yet.
<tseng> ajmitch: if you dont have a rejected mail we should ask around
<seb128> is that a new package ?
<tseng> yep.
<tseng> do they need extra work?
<seb128> need 2 approvals
<seb128> one before build
<seb128> and one before getting in the archive
<tseng> hm, oh =/
<seb128> when have you uploaded it ?
<tseng> aj uploaded for me last night my time
<tseng> its universe and only used by muine, approval should be no problem.
<seb128> yeah
<seb128> probably waiting on elmo
<tseng> I'd not asked anyones permission other than the debian maint. again.. universe
<tseng> appologies if I missed some proceedure.
<seb128> no, don't worry
<seb128> all the new packages go to NEW
<seb128> and wait for a ftpmaster approval
<seb128> in debian or ubuntu main or universe
<seb128> for everybody
<tseng> fair enough.
<azeem> did you guys consider reintroducing autoconf-doc into the autoconf package?
<winkle> tseng: you did tomboy right? it crashes when trying to make notes here, ideas?
<tseng> winkle: hm, it does now here as well.
<tseng> winkle: thats quite odd, wonder whats changed
<tseng> i doubt it needs rebuilt against a new libpanel-applet..
<seb128> tomboy doesn't work for some time here
<tseng> winkle: hm it needs rebuilt against *some* lib. I built again from source and is working
<tseng> we just need a no-change revision to get built with the latest deps I believe
<winkle> tseng: check, hm, I seem to recall some -cil package being upgraded...
<tseng> winkle: gtk-sharp 1.0.4 yes.
<tseng> but thats a minor release
<tseng> on a stable branch
<winkle> ok
<tseng> winkle: thanks for pointing this out, I dont use tomboy often
<winkle> tseng: np, first time I tried it :P
<tseng> i love how mono is impossible to strace
<da_bon_bon> hi all
<da_bon_bon> seb128: here ?
<da_bon_bon> is the gnome-panel maintainer here, i want to make a small request ?
<seb128> afternoon
<da_bon_bon> seb128: evening :)
<da_bon_bon> seb128: i know that people always demand rebuilds, but can i just ask when is the next rebuild scheduled for ?
<seb128> rebuild for what ?
<da_bon_bon> gnome-panel
<seb128> a rebuild doesn't change anything
<seb128> you mean "update" ?
<seb128> "release" ?
<da_bon_bon> due to a nasty bug i cannot work properly. i reported on bugzilla of gnome
<da_bon_bon> the bug was fixed in cvs
<seb128> what bug ?
<da_bon_bon> thats why i am curious
<da_bon_bon> wait a sec
<seb128> the package is update on upstream releases
<seb128> or to include patches
<da_bon_bon> 167478
<da_bon_bon> bug no. 167478 on gnome bugzilla
<tseng> da_bon_bon: the next release is due by Feb 28th, as you can see at http://gnome.org/start/2.9/
<da_bon_bon> tseng: sorry, mea culpa :)
<tseng> da_bon_bon: if you can get a patch from cvs, and prove why its a major bug, it might get fixed sooner
<da_bon_bon> i thought that ubuntu people compile every night from cvs..
<da_bon_bon> am i wrong ?
<tseng> heh, nope :P
<da_bon_bon> then ?
<seb128> da_bon_bon: yep you are
<tseng> we go by the same 2.9.x prereleases as everyone else gets. plus patches
<seb128> da_bon_bon: we package upstream releases
<seb128> and include patches for some stuff
<da_bon_bon> seb128: if i am right, then is it not fixed or some other problem ?
<seb128> it's fixed in the CVS
<seb128> but there is no new release since then
<da_bon_bon> ok, so u dont compile from cvs ?
<seb128> next one is planned for 28th feb as said by tseng 
<seb128> no
<da_bon_bon> oh, sorry, i didnt know.
<da_bon_bon> sorry for the trouble
<seb128> that would be a lot of work to package every day every module
<da_bon_bon> ok.. so i cant add stuff to gnome panel until 29-30th of feb ?
<da_bon_bon> also, how do i edit menus is hoary ?
<seb128> I can include a patch to the package
<da_bon_bon> *in
<seb128> you don't
<da_bon_bon> seb128: so, patching, but then how do i update it ?
<da_bon_bon> i cant edit menus in hoary ?
<seb128> you can add .desktop file in ~/.local/share/applications/
<seb128> look on /usr/share/applications/
<seb128> right, there is no menu editor for GNOME 2.10
<da_bon_bon> :(
<seb128> they have changed the code to use the freedesktop format
<seb128> but nobody worked on a menu editor yet
<da_bon_bon> but in nautilus, applications:/// doesnt work, so i needed to ask
<seb128> yeah, that's the 2.8 crappy system
<da_bon_bon> ah, ok.. 
<seb128> 2.10 is much better but that's a different code
<seb128> so this need to be rewritten
<da_bon_bon> but not out until 19march :(
<seb128> and nobody has worked on it for the moment
<da_bon_bon> ok..
<seb128> for the patch, just update the gnome-panel package
<da_bon_bon> so, the development team actually packages the software when a release is made ?
<seb128> I'll grab the patch from the CVS
<seb128> correct
<da_bon_bon> seb128: thanks a lot... but then when do i update ? 
<seb128> in 1 or 2 hours
<da_bon_bon> ah, so it /is/ a critical bug ?
<seb128> no
<da_bon_bon> ok..
<seb128> I just do that so you can use your panel
<da_bon_bon> thank you sooo much.
<seb128> no problem :)
<da_bon_bon> but, say, if people like me go on increasing, doesnt your work increase ? for every bug fix people ask you to rebuild..
<da_bon_bon> :)
<seb128> there is not a lot of crasher
<seb128> you are the first to bug me about this one
<da_bon_bon> :)
<seb128> da_bon_bon: panel patched uploaded. It should be in the archive in 1 hour. Let me know if that works and if you have a broken icon in the "add to panel" with it
<da_bon_bon> seb128: why the icon ?
<seb128> because that's probably what's crashing it now
<seb128> a broken icon
<seb128> maybe that's due a package
<da_bon_bon> oh, i didnt realize that
<da_bon_bon> i thought maybe a big bug or somethin
<da_bon_bon> u there for the hour it will take to upload ?
<seb128> yep
<da_bon_bon> ok'
<da_bon_bon> so m i
<da_bon_bon> can u explain why once u have uploaded it takes 'bout an hour, seb128 ?
<seb128> because it needs to be built
<seb128> and then it needs to be synced on the mirror
<da_bon_bon> ok, so u dont build the binary on ur own pc ?
<tseng> da_bon_bon: we dont upload the binaries. just a source package
<seb128> I do, but I upload only the sources
<tseng> da_bon_bon: it gets built by a pbuilder.
<da_bon_bon> whats a pbuilder ?
<tseng> an automated builder daemon
<seb128> buildd
<tseng> or that.
<seb128> (pbuilder is a package)
<HiddenWolf> tseng: what's the hardware on the server-side? :)
<da_bon_bon> oh ok.. what notions i had aobut maintainers, how wrong i was!
<tseng> HiddenWolf: not sure specifically. its big and bad
<da_bon_bon> the moment u upload, it starts building ?
<HiddenWolf> da_bon_bon. I imagine it'll have a queue of packages that need to be build. :)
<da_bon_bon> really ?
<HiddenWolf> da_bon_bon: that server only has limited capacity. So it can't possibly do everything at once. 
<tseng> http://www.ubuntulinux.org/wiki/DeveloperResources
<tseng> there is information on this sort of thing here.
<tseng> read around
<da_bon_bon> are uploaders notfiied when package is built ?
<tseng> no, but they are notified when it is accepted
<tseng> would you mind reading that page, esp BuildDaemons link?
<tseng> i appreciate your curiosity but its getting a bit OT
<da_bon_bon> ot ?
<tseng> off topic.
<da_bon_bon> sorry
<tseng> thanks.
<seb128> tseng: f-spot 0.0.8 in the archive
<tseng> seb128: i see it :)
<seb128> tseng: thanks :)
<tseng> seb128: if you have another free moment today.. could you help me with a no-change upload of tomboy?
<tseng> I really need to sort this gpg stuff soon =/
<seb128> tseng: what's the issue with it ?
<seb128> when I start it here it hangs, no icon in the notify
<seb128> and it return to the console after some min
<tseng> seb128: here it crashes when adding a note, same for winkle 
<tseng> rebuilding it solves the issue.. some lib inconsistancy
<seb128> k
<tseng> seb128: are you using --tray-icon ?
<seb128> no
<tseng> see, its an applet now
<tseng> so you can a) add the applet, or b) call with --tray-icon
<seb128> it breaks working configuration
<seb128> iiiiiiiiiih
<tseng> yeah =/
<tseng> upstream crack, calling it w/ no args should make an icon imo
<seb128> rebuilding now BTW :)
<tseng> you see the crasher?
<seb128> yep
<seb128> #4  0xb74201ca in pthread_cond_timedwait@@GLIBC_2.3.2 ()
<seb128>    from /lib/tls/i686/cmov/libpthread.so.0
<seb128> #5  0xb7f3d256 in mono_method_full_name () from /usr/lib/libmono.so.0
<seb128> #6  0xb7f4bee4 in mono_once () from /usr/lib/libmono.so.0
<seb128> rebuild fix it
<tseng> indeed
<seb128> ABI breakage in a minor update ?
<tseng> looks that way =/
<seb128> not nice
<tseng> ive not seen anything else break.
<seb128> uploaded
<tseng> you rock.
<seb128> thanks :)
<seb128> do you know if 1.1.4 is packaged somewhere ?
<tseng> it is not
<seb128> it needs some packaging changes IIRC
<tseng> if you saw the recent chat in here with miguel
<seb128> nop
<tseng> he raised several issues with the current debian mono policy
<tseng> so updating to 1.1.4 will also involve a new policy
<seb128> k, so not for hoary ?
<tseng> likely not
<tseng> http://wiki.debian.net/?MonoDebianPlan for anyone interested.
<seb128> k
<tseng> latexer@gentoo tells me that most apps are compatible with 1.1.4 from a non-packaging standpoint. he is working on fixing tomboy, believe thats the last
<da_bon_bon> seb128: i need to go. will update later at night and will tell u when we next meet. thanks for the trouble :)
<seb128> da_bon_bon: k, later
<da_bon_bon> seb128: later
<tseng> im off as well, maybe for the rest of the day.
<tseng> many thanks seb128 
<seb128> have a good afternoon :)
<seb128> jdub: where have you seen the rawhide patch for the menus ?
<jdub> seb128: saw seth's desktop sshots ;-)
<jdub> seb128: perhaps ping him
<seb128> k
<seb128> because there is no patch in the current srpm
<jdub> bum
<seb128> jdub: do you know if somebody is working on sabayon packaging ? I'm tempted to start it :p
<jdub> :-)
<jdub> haven't heard so far, no
<seb128> k
<seb128> it looks cool by reading planet :)
<seb128> jdub: an user is asking if we are going to move nautilus-sendto to main or in the desktop. Already considered it ?
<da_bon_bon> seb128: here ?
<seb128> yep
<da_bon_bon> works great now. thanks
<seb128> np
<seb128> do you have a screwed icon ?
<da_bon_bon> where ? all icons are ok.
<da_bon_bon> seb128: thanks, then cya later
<jdub> seb128: yes, i think we should
<seb128> jdub: k. Should I mail -devel or something ?
<jdub> seb128: i'll confirm and add it now ;)
<seb128> cool
<_d4vid> hi all
<jdub> seb128: blame lamont for no nautilus-sendto seed love atm ;)
<seb128> he has a lock on the seed again ? :)
<jdub> seb128: -r--r--r-- ;-)
<unifi> has anyone had ubuntu installation freeze up at setting up xserver?
<unifi> because i have been trying for 2 days to install the thing and It wont budge past this point
<unifi> no one?
<seb128> nop
<unifi> I guess I should just go back to using mepis
<sivang> unifi: or you can go ask around #ubuntu, it's for user issues and trouble.
<unifi> I have... they dont know either
<unifi> I have been at this for 2 days now
<unifi> have installed suse
<unifi> mepis
<unifi> even linspire on this thing trying to find a decent distro
<lifeless> seb128: you know about complete-hangs when you unmount something while a nautilus window is open on it ?
<jdub> lifeless: boot with 'noinotify'
<lifeless> seb128: just happened when I upgraded today, hadn't upgraded for a week or two before
<lifeless> jdub: 2.6.10-3, never had this problem before,
<jdub> lifeless: trust me. :)
<lifeless> jdub: robert.collins@canonical.com--general/bazaar-fuser--0 for fuse module for bazaar
<lifeless> jdub: pybaz is not packaged yet - but on ddaa.net
<lifeless> jdub: ok, I trust you, when will inotify suck less ?
* lifeless -> movie
<seb128> lifeless: as jdub said, inotify bug
<jdub> lifeless: rml is working on a lockless version atm
<jdub> lifeless: go to the odeon! :)
<zul> hey
<jbailey> http://ubuntu.hands.com/releases/4.10/ has "Ubuntu 5.04 (Hoary Hedgehog) as its page title. =)
<T-Bone> lol
<lifeless> wireless rocks my world
<lifeless> jdub: empire - the life fantastic
<lamont> jdub: blame the root cause, not the trigger-man... :-)
<lamont> seb128/jdub: seed archive repaired
<seb128> thanks lamont 
<zul> is the person who is working on accessibility CD-ROM around?
<dholbach> hai
<amu> sync
<amu> argl :)
<lamont> seb128: but I don't know what seed action jdub had planned.
<HWolf> Anyone here?
<T-Bone> no
<azeem> what a strange question
<T-Bone> we're all zombies
<Treenaks> 17:49 -!- Irssi: #ubuntu-devel: Total of 95 nicks
<seb128> lamont: addind nautilus-sendto to the desktop 
<lifeless> jdub: http://www.advogato.org/person/robertc/diary.html?start=30
<HWolf> My internet connection is wacky. Is there anything in today's updates that could mess it up?
<zul> have you tried calling your isp?
<Evaso> is there a way to regenerate fstab as on a new fresh installed ubuntu system?
<HiddenWolf> Evaso: why do you need to do that?
<Evaso> i'm only guessing about it, i had touched an fstab and i want to automatically regenerate one as on installing ubuntu is there a way?
<HiddenWolf> Evaso: not that I know of. But you can just manually edit it, right?
<Evaso> HiddenWolf: Yes i could edit it, but if i want to return to the autmacally generated one of the install time can i do?
<Evaso> HiddenWolf: with new kernel 2.6.10 the support of udf is introduced but i tink that packet cd are not autmatically mounted by pomunt i tink in hoary so i want to verify it without reinstalling
<sid77> ciao
<dholbach> hai ogra
<ogra> hi
<dholbach> ogra, looks good, as far as i understand it
<ogra> heh
<sdfsadf> hello
* LarryT i got a problem with the last rc of hoary live cd : i get an error message about casper udeb :/
* LarryT i trying an seoncd download --> iso may be corruped
<dholbach> bbl
<LarryT> dholbach tobad :)
<HiddenWolf> larryT: how about checking the md5sum first?
<LarryT> :( i didn't :-[ 
<LarryT> that's the reason why i download it again ;)
<LarryT> 25 minutes still :)
<HiddenWolf> LarryT: Why do you delete the iso then? :-P
<LarryT> because i thought about md5 after :-[ :)
<HiddenWolf> LarrtT: sucks
<dholbach> re
<LarryT> Hi dholbach : how are you doing ?
<dholbach> LarryT, thanks... fine :-)
<dholbach> LarryT, what about you?
<LarryT> about more than a week that i have no news from plosr :(
<LarryT> south american is far away :)
<LarryT> but  connection must work there ;)
<dholbach> LarryT, ah, now i recognize you
* dholbach is a bit slow today
<LarryT>  :)
<LarryT> dholbach you better have "ein mass Bier , nicht war ? " :)
<LarryT> "var"
<LarryT> i have succesfully added gparted on the ubuntu live cd
<dholbach> LarryT, wow - cool!
<LarryT> dholbach :but i can't resize any kind of partition :(
<LarryT> dholbach : dunno why
<dholbach> LarryT, any debug messages in the console about it?
<LarryT> dholbach nothing at all. I can resize fat32, create all kind of partition, but i can't resize neither ntfs nor ext :(
<dholbach> LarryT, maybe they're mounted?
<LarryT> dholbach : in that case, gparted shows a lock , isnit ?
<dholbach> LarryT, try   mount   in the console
<LarryT> dholbach, it seems one can resize a partition only if there is nothing after :(
<LarryT> dholbach, yep gonna try : just a while ...
<dholbach> LarryT, yes... i think there must be free space after a partition to resize it
<LarryT> dholbach, you mean : even if you want to reduce it ?
<LarryT> dholbach, ubuntu live larrycustom is running ...
<dholbach> LarryT, i think i read something in some TODO somewhere
<LarryT> dholbach, hmm ...
<LarryT> dholbach, yep this time it works :) 
<LarryT> dholbach, do tou know hwoto resize or delete extended partition ?
<LarryT> dholbach, it is free, absolutly blank :)
<dholbach> LarryT, sorry, i don't know - is there nobody at irc://irc.gnome.org/gparted? :-)
<LarryT> dholbach, no matter . :) cul8r :)
<dholbach> LarryT, see you!
<srbaker> anyone know of a good todo list app for gnome?
<srbaker> with check boxen?
<ari> there's gtodo
<ari> do you want hierarchical?
<srbaker> doesn't need to be hierarchical, but it'd be nice
<ari> there's devtodo, but that's console
<srbaker> no, i want gnome.
<T-Bone> evolution
<T-Bone> check "Tasks"
<srbaker> i don't use evolution for anything else.
<T-Bone> so what's the problem?
<srbaker> T-Bone, if evolution is too bloated and slow for me to read email in, i'm certainly not using it for only task list
<T-Bone> srbaker: you want something nice looking with eye candy, nice integration, you use gnome, and you dare complain about evolution's slowlyness and bloatedness? :P
<srbaker> T-Bone, it's not just the slowness and bloatedness that bothers me :P
<srbaker> gtodo looks like what i want, i think
<jdub> configure:19318: Looking for Python version >= 2.3
<jdub> configure:19338: checking for python
<jdub> configure:19356: found /usr/bin/python
<jdub> configure:19368: result: /usr/bin/python
<jdub> Traceback (most recent call last):
<jdub>   File "<string>", line 7, in ?   File "/usr/lib/python2.4/string.py", line 403, in atoi
<jdub>     return _int(s, base) ValueError: invalid literal for int(): 1a0 
<jdub> 
<dholbach> jdub, debian/control and configure.ac seem not to be in sync at all
<jdub> hrm?
<dholbach> oops
<dholbach> i mistook something for something else ;-)
<jdub> (this is flumotion 0.1.5, it has built previously, i'm just trying to get it to build again)
<dholbach> hi jani, long time no see ;-)
<jani> hello :)
<dholbach> metalikop, cfv looks quite ok... i give it a test build
<kent> It seems that Muin for a long time in Hoary will not install since its linked against libflac4, and libflac4 is not in Hoary. Does the Muin in Hoary need libflac4, or is it just a bug that it tries to compile to the wrong libflac?
<metalikop> thx
<dholbach> jani, metalikop, whiprush: i hope you understand, if i want to hear the opinion of another MOTU for the NEW packages, alright?
<metalikop> sure
<jani> dholbach :absolutely
<whiprush> rock
<dholbach> whiprush, i didnt look at them yet... i just wanted to make clear, i wouldnt decide on them on my own
<whiprush> no problem, I'm not in a rush
<dholbach> metalikop, in cfv: Standards-Version: >=3.6.1 (you should throw out ">=")
<metalikop> k
<metalikop> dholbach: re-uploaded
<dholbach> metalikop, sorry: one more thing, use Build-Depends-Indep instead of Build-Depends to get rid of the last lintian-warning ("lintian -ci cfv_1.18.1-0ubuntu1.dsc" will show you, why)
<dholbach> metalikop, apart from that: nice work - another test build and you'll have another package to tick off :-)
<dholbach> metalikop, duplicity was fine - just uploaded it
<dholbach> whiprush, i'll look after pysol, while metalikop gets cfv sorted
<whiprush> ok.
<whiprush> bbiab
<dholbach> whiprush, you have no .orig.tar.gz - pysol*.dsc tells me something about pysol_4.82.1-2ubuntu1.tar.gz - you should get pysol_4.82.1.orig.tar.gz and   debuild -S   again
<sivang> hey all
<sivang> hi dholbach 
<dholbach> hi sivan!
<sivang> what's up?! ;-)
<dholbach> sivang, reviewing packages ;-)
<sivang> dholbach: an nice :)
<sid77> ciao
<dholbach> hi sid77 
<metalikop> dholbach: new cfv up
<bulio> does Ubuntu have any support for Usb Dsl modems?
<dholbach> metalikop, looks good
<metalikop> great.
<bulio> does Ubuntu have any support for Usb Dsl modems?
<bulio> oops nvm
<metalikop> duplicity is awaiting checkout as well
<metalikop> is waiting to be checked out
<dholbach> bulio, /usr/share/doc/kernel-doc-<kernel-version>/Documentation should tell you
<bulio> well I'm going to use Ubuntu live for the moment
<dholbach> metalikop, already uploaded it, it was good
<metalikop> great
<dholbach> metalikop, katie should get in touch with you :-)
<metalikop> katie?
<dholbach> metalikop, 2 packages to tick off - i wonder how much are still remaining
<sivang> metalikop: katie is elmo's gf, she sends email back to people who uploaded pkgs IIRC :))
<metalikop> ahhh
<metalikop> :)
<dholbach> metalikop: you should get mail from Ubuntu Installer <katie@jackass.warthogs.hbd.com>
<dholbach> :-)
<metalikop> i'll watch for it
<ogra> dholbach: katie only talks to whitelisted guys ;)
<dholbach> ogra, nope... then she's been untrue to you ;-)
<dholbach> ogra, i got mails for "sponsored uploads" as well
<ogra> https://www.ubuntulinux.org/wiki/Uploads
<ogra> The archive scripts will only send mail (e.g. ACCEPT/REJECT notification) to a white-listed address.
<dholbach> ogra, you remember, when you waited for an upload receipt, when you uploaded a package for me? 
<ogra> dholbach: the "sponsored uploads" go to all whitelisted adresses
<dholbach> i meant that mail - katie sends it as well
<dholbach> oh damn... yes - he should be on hoary-changes then
<ogra> dholbach: every MOTU/dev should ;)
<ogra> #its essential
<metalikop> i'm on hoary-changes
* dholbach puts on some sunglasses, pulls out his men-in-black--makes-you-forget--stick, FIZZ and normal life continues...
<ogra> huh ?
<ogra> what happened ? where i my log ?
* dholbach deletes the last 4 minute out of the logs as well :-)
<ogra> is even *G*
<metalikop> dholbach: lfm is waiting for you :)
<ajmitch> dholbach: katie doesn't love me, she never sends me mail..
* dholbach comforts ajmitch a bit
<metalikop> same location dholbach 
<ogra> ajmitch: so you are not whitelisted ?
<ajmitch> ogra: I'm not sure, I use the address that I told elmo to whitelist
<dholbach> metalikop, i give bluefish some loving
<dholbach> metalikop, hope it won't take long
<metalikop> no rush
<ogra> ajmitch: upload@ubuntulinux.org ?
<ajmitch> hm?
<ogra> ajmitch: did you send it there ?
<ajmitch> yep
<ogra> ah, ok
<ajmitch> iirc :)
#ubuntu-devel 2005-03-03
<dholbach> metalikop, nice work on lfm
<metalikop> thanks
<dholbach> metalikop, since seb128 is the maintainer, i'll ask him before i upload it, alright?
<metalikop> sure thing, I already dropped him an email, no response yet
<dholbach> metalikop, he'll be here tomorrow i guess
<metalikop> no worries, maybe he'll check his email before then ;)
<dholbach> metalikop, and he'll give his ok, i'm sure
<metalikop> thanks
<dholbach> metalikop, de rien :-)
<dholbach> whiprush, ping
<whiprush> pong
<whiprush> working on that now.
<dholbach> whiprush, cool
<metalikop> dholbach: imgsizer is ready to be tested
<dholbach> metalikop, right
<metalikop> dholbach: I have a question for you....
<metalikop> I'm working on mma (a midi program)
<dholbach> metalikop, fire away
<metalikop> the debian version is 0.11, a new version exists.  I figured I might as well update to 0.12 as well.
<metalikop> The author has the docs in a seperate .tar.gz file.
<dholbach> you did the same with cfv
<dholbach> ah ok
<metalikop> What's the method for including the mma-docs.tar.gz in to this package?
<dholbach> metalikop, how is the packaging handled atm?
<dholbach> metalikop, does upstreams *-docs.tgz contain this: html  mma-lib.pdf  mma.pdf  mma-tutorial.pdf  README
<dholbach> ?
<metalikop> there's one for pdfs and one for html
<metalikop> so multiple docs tars
<dholbach> *grmbl*
<metalikop> yeah....
<dholbach> then you should better get in touch with the according DD
<metalikop> perhaps he added them all in one .tar file?
<dholbach> that's a really bad thing "guessing how the maintainer compiled '*.orig.tar.gz'"
<metalikop> indeed, I'll contact him
<dholbach> nice - will the python transition be complicated?
<dholbach> metalikop, you could add imgsizer.manpages
<zul> anyone want to try a patch to dpatch?
<dholbach> zul, what is it about?
<zul> colorizes the patch output message result
<dholbach> zul, where can i get it?
<zul> http://zulinux.homelinux.net/ubuntu/dpatch-color.diff
<zul> back up your dpatch though
<T-Bone> lol, indeed a simple patch :)
* T-Bone wonders if it works on any terminal actually
<metalikop> dholbach: what should that file contain?  Just a list of the manpages provided by this app?
<dholbach> yes, like   debian/imgsizer.1
<metalikop> a manpage is already provided
<metalikop> should I move the current imgsizer.1 in the source directory to ${SOURCE}/debian/ ?
<dholbach> no... if it is provided by upstream
<metalikop> it's provided upstream
<metalikop> dh_installman imgsizer.1
<dholbach> you changed debian/rules to say dh_installman -p<blasomething>
<metalikop> that's already in there
<metalikop> without the -p
<dholbach> -       dh_installmanpages
<dholbach> +       dh_installman imgsizer.1
<dholbach> this is, what changed from 2.7-1 to 2.7-1ubuntu1
<metalikop> right, is that correct?  the ubunu1 version
<dholbach> this is why i mentioned you could add debian/imgsizer.manpages
<dholbach> metalikop, it was just a suggestion :-)
<dholbach> how can i close a bug in malone?
<metalikop> is the imgsizer.manpages the preferred method?
<dholbach> metalikop, yes... i think so
<whiprush> dholbach: ok, new stuff uploaded
<dholbach> whiprush, cool
<dholbach> if someone could teach me, how to close https://launchpad.ubuntu.com/malone/tasks/157
<sivang> dholbach: intersting there seems to be no option for this
<sivang> dholbach: talk to bradb
<sivang> dholbach: anyway, I'm out for some weekend fun, ;aterz daniel!
<dholbach> whiprush, in  debian/control  s/python2\.3\-tk/python2\.4\-tk/ 
<dholbach> sivang, what are you going to do?
<whiprush> k
<dholbach> sivang, thanks for the hint to bradb
<sivang> dholbach: watch a dvd movie I brought from the dvd store
<sivang> dholbach: trying to set up ogle right now, since mplayer erros when trying to that :)
<dholbach> sivang, what about totem? doesnt it work?
<dholbach> whiprush, you could also try   Build-Depends-Indep instead of Build-Depends
<sivang> dholbach: I'll try, c'ya!
<whiprush> ok
<dholbach> sivang, bye! :-)
<whiprush> odd, mine shows as Build-Depends-Indep
<whiprush> you're talking in debian/control right?
<dholbach> re
<metalikop> wb
<dholbach> metalikop, whiprush: i think i'm going to bed... drop me a line when you finished the packages and i'll look over them tomorrow, ok?
<dholbach> sleep tight everyone, i'm off to bed
<whiprush> okey
<mjg59> Hmm. If this QEmu accelerator thing is as shit-hot as the author claims, someone should convince Mark to buy the source
<jdub> mjg59: (someone's trying)
<mjg59> Heh
<zul> grrr...inotify
<dholbach> hai
<olivier> greetings
<dholbach> hi olivier 
<crimsun> moin
<dholbach> metalikop, imgsizer looks good now, thanks!
<crimsun> yep. A couple of us helped him straighten them up a couple nights ago.
<dholbach> with jani, dredg, whiprush and metalikop wiki/UniversePythonTransitionTODO will be done in no time ;-)
<dholbach> you guys rock!
<crimsun> :-)
<dholbach> metalikop, uploaded imgsizer
<HostingGeek> I got no reply from nvu or from linex
<HostingGeek> about nvu
<HostingGeek> also now that i have looked at nvu source there is no way it can use an already installed firefox unless tha already install firefox has patches
<HostingGeek> so the best thing to do would be to minamize everything of firefox it uses and package it as it is
<Treenaks> HostingGeek: or just get the source
<Treenaks> HostingGeek: and hack it into using firefox as-is
<dholbach> hi Treenaks 
<HostingGeek> Treenaks: its impossible
<Treenaks> HostingGeek: it can use a patched firefox, right? then it should be possible to hack it into using an unhacked ffox
<HostingGeek> Treenaks: unless you patch the current firefox
<HostingGeek> Treenaks: the who thing is a patched firefox basicly
<Treenaks> HostingGeek: the best solution is using firefox and vim
<HostingGeek> the whole thing is a hacked up fox
<HostingGeek> Treenaks: i use firefox + bluefish
<Treenaks> HostingGeek: than someone should step up and re-write it as an xpi for ffox
<HostingGeek> Treenaks: its very hard
<HostingGeek> Treenaks: have you looked at its source?
<janc> isn't glazman planning to use xulrunner in the future?
<janc> that should be the base for FF 2.0 AFAIK
<HostingGeek> also BeeEmm the debian maintainor said he will happly maintain vhcs for ubuntu
<janc> and TB 2.0
<HostingGeek> but as he only has isdn and before uploading it he want to test it out him self he ordered a cd
<HostingGeek> and now it after the feature freeze so he can't test
<HostingGeek> but this will mean one thing has to move from universe to main
<Treenaks> HostingGeek: why?
<Treenaks> HostingGeek: is it something MOTU can't do?
<HostingGeek> Treenaks: he is the maintainor for debian he only just uploaded it to sid its been in experimental for a while
<HostingGeek> and it depends on php4-mcrypt
<Treenaks> HostingGeek: so? that can be in universe, just like the other packages
<Treenaks> what's wrong with universe
<HostingGeek> and when i was in here last you said that if he maintains it.. it can be in main for a server install
<Treenaks> HostingGeek: main is all about support, not so much about server vs workstation
<HostingGeek> Treenaks: i asked him to join
<HostingGeek> Treenaks: main means its offically support by ubuntu
<HostingGeek> and can be put on a the cd
<Treenaks> HostingGeek: no, main doesn't mean it's on the CD
<Treenaks> HostingGeek: and the CD is quite full already
<HostingGeek> s/cd/dvd
<HostingGeek> or an extra cd
<HostingGeek> or a custem cd for servers
<Treenaks> HostingGeek: still, that doesn't make it "main" instead of universe
<Treenaks> HostingGeek: custom CDs can already contain everything you want.. even custom packages
<HostingGeek> wasn't there going to be an offical custom cd for servers?
<Treenaks> I'm not against it being in main, I'm just asking you te be realistic... if the Ubuntu people won't support it, it won't be in main
<HostingGeek> not for hoary but for 5.10
<Treenaks> HostingGeek: hoary /is/ 5.10
<Treenaks> uh no 5.04
<Treenaks> hoary+1 you mean
<HostingGeek> lol
<Treenaks> still, small chance
<HostingGeek> BeeEmm is still wait for his cds
<Treenaks> BeeEmm: read the CD FAQ then
<HostingGeek> Treenaks: what was this thing about a server cd
<janc> better burn one yourself and send him if it has to be there fast...
<Treenaks> HostingGeek: read the wiki
<HostingGeek> which doesn't include the the desktop
<Treenaks> 10:28 < Treenaks> HostingGeek: read the wiki
<HostingGeek> Treenaks: yes and why can't vhcs be part of this cd? and if it can it must mean it has to be in main
<HostingGeek> ok
<dholbach> HostingGeek, there is no server-cd - when you install, you can take the "custom" route to install a cropped-down amount of packages
<Treenaks> dholbach: he's talking about hoary+1
<dholbach> Treenaks, ah ok
<HostingGeek> dholbach: i know but i remeber here that there was an idea for a server cd  which includes anything server realated in main but not in universe
<dholbach> HostingGeek, well then Treenaks is right: for ideas on this, the wiki will be the best guess
<HostingGeek> also are we going to see in the a search engine by default in the ubuntu build of firefox that searches the ubuntu site?
<dholbach> HostingGeek, you could file a wishlist bug on this
<HostingGeek> but BeeEmm is the _debian_ maintainor and is happy to make debs for ubuntu
<HostingGeek> only thing is i'll like to see them in main
<HostingGeek> i am not sure if BeeEmm cares if they are in main or universe
<HostingGeek> dholbach: you where replying to my fox comment or vhcs?
* mode/#ubuntu-devel [+o daniels]  by ChanServ
* mode/#ubuntu-devel [+b *!*1337@*.48.233.220.exetel.com.au]  by daniels
* HostingGeek was kicked off #ubuntu-devel by daniels (daniels)
* mode/#ubuntu-devel [-o daniels]  by daniels
* mode/#ubuntu-devel [+o daniels]  by ChanServ
* mode/#ubuntu-devel [+b *!*@200.48.233.220.exetel.com.au]  by daniels
* mode/#ubuntu-devel [-o daniels]  by daniels
<dholbach> daniels, may i ask, why you kicked him?
<dholbach> i mean, i didnt really enjoy the conversation
<daniels> dholbach: he has a habit of persistently making #ubuntu-devel absolutely useless by flooding it with total nonsense
<daniels> (there are other bans active on him; he just slipped through them)
<dholbach> oh i see, so he doesn't seem to be impressed by bans in general
<daniels> apparently not
<dholbach> ok... it's alright with me... just wanted to know :-)
<elmo> ogra: ?
<dholbach> what's the most common way to add a .png to a package?
<dholbach> if i do it "right" (not messing with orig.tar.gz), i run into "dpkg-source: cannot represent change to pixmaps/gparted.png: binary file contents changed"
<azeem_> use uuencode/uudecode
<bob2> if you have to add it to the diff, you can uuencode
<bob2> but that sort of thing sounds pretty upstreamy
<dholbach> they have their logo competition still going on :-)
<dholbach> but a menu entry without an icon looks dumb
<azeem> yay for logo competitions
<dholbach> azeem, bob2: thanks for the clue
<dholbach> elmo, you also send the mail to -users?
<dholbach> bbl
<ogra> elmo: ?
<dholbach> morning ogra!
<ogra> hi
<HiddenWolf> seb128?
<seb128> ?
<HiddenWolf> Can it be that the window selector unlocks itself from panel every reboot?
<HiddenWolf> workplace switcher, ugh. 
<seb128> no idea, I don't look on what is locked or not when I start my session
<seb128> right click on the applet
<seb128> and look in the menu
<HiddenWolf> I've found it unlocked a couple of times. Is yours?
<seb128> <seb128> no idea, I don't look on what is locked or not when I start my session
<HiddenWolf> *sigh*
<seb128> I don't even think I've one applet locked
<HiddenWolf> ok
<dholbach> seb128, metalikop worked a bit on  lfm  (python2.4, ..) - and i approved his changes - since you are the maintainer, is it ok, when i upload it?
<dholbach> seb128, i could send you the debdiff in a /query
<seb128> I got a mail about the package
<seb128> you need to version the Build-Depends on python-dev to 2.4
<seb128> out of this that's fine, go for it
<dholbach> seb128, the buildd should resolve the Depends itself, so a rebuild would suffice
<seb128> that's not a reason to do the wrong things
<seb128> you use 2.4 in debian/rules, you should version the Build-Depends
<dholbach> so you would tighten the build-depends and not let it compile with python2.3 anymore?
<seb128> you have 2.4 in debian/rules
<dholbach> oh... yes
<dholbach> oh alright
<seb128> you can change debian/rules to no use a static version
<seb128> or update the Build-Depends
<seb128> but the current situation is wrong
<dholbach> ok... i'll tell him
<seb128> thanks :)
<dholbach> he also fixed 2 lintian warnings, so apart from the python stuff, he did well
* tseng wonders why people send me bug reports via email
<dholbach> hi zul 
<zul> hey dholbach 
<zul> oooh....ahhh 2.6.10-4
<mjg59> zul: Where?
<zul> on my pc
<zul> mjg59: i had to merge a couple of acpi patches though
<daniels> Kamion: ping
<daniels> lamont: ping
<mjg59> zul: Ah, ok
<daniels> hm, sleep time
<sivang> hi all
<dholbach> hi sivan!
<sivang> hi dholbach , still reviewing packages?
<dholbach> sivang, no... finished (until whiprush and metalikop wake up) :-))
<dholbach> sivang, now i'm taking care of mine... and learning how to things properly :-)
<sivang> dholbach: well, it's still sunday, you should go and have some time out :)
<dholbach> sivang, will take murphy for a walk :-)
<sivang> dholbach: my rgrds to her 
<dholbach> cdbs rocks
<dholbach> i'm simply amazed
<sid77> ciao
<dholbach> mc
<dholbach> oops
<dholbach> amu, you're aware of (kdelibs-data: /etc/xdg/menus/applications.menu zu berschreiben, which is in "gnome-menus" as well) already?
<amu> dholbach: yep
<dholbach> amu, good
<dholbach> amu, yes.. i think i just have k3b and another app installed
<sivang> seb128: hi, going over the g-c-m bugs I see most of them are upstream bugs, so basically we don't have too much specific problems local to ubuntu.
<seb128> sivang: right
<dholbach> bbl
<pitti> Hi
<sivang> pitti: Hi Marint!
<sivang> err, Martin
<pitti> Hi Svinag :-)
<sivang> pitti: hehhe
<pitti> sivang: just returned from skiing, was nice today
<zul> hey pitti 
<sivang> pitti: wow, cool
<pitti> Hi zul
<zul> where did you go skiing?
<seb128> afternoon pitti 
<pitti> Hi seb128, how's Luxembourg today? :-)
<pitti> zul: in the vicinity of us, about 5 km away
<zul> cool
<pitti> zul: "Poisenwald" :-)
<seb128> pitti: no idea, usually I stay on the french side of the border :p
<pitti> seb128: oh, ok :-)
<pitti> seb128: ah, you live _near_ the border, but not _within Lux., right?
<seb128> yep, about 20km from the border
<metalikop> morning all
<metalikop> seb128: thanks for your email
<seb128> hi metalikop 
<seb128> np, thank you for working on this :)
<da_bon_bon> anyone here installed vmware from tarball ?
<sivang> is bugzilla down?
<HiddenWolf> sivang: seems to be
<HiddenWolf> sivang: was a notice about it on -devel
<sivang> HiddenWolf: yeah I saw it, tnx.
<zul> sivang: you should read -dev more often ;)
<sivang> zul: I read it , just forgot to do timezone calculations :)
<sivang> zul: it's always open on my mutt :)
<zul>  date --utc :)
<sivang> zul: right :)
* HiddenWolf wonders how long the upgrade will last, considering how ubuntu is exploding in popularity
<HiddenWolf> Can someone here put in the #ubuntu topic that the servers are down for maintenance?
<HiddenWolf> seb128, you here?
<dholbach> re
<HiddenWolf> dholbach, can you change the topic in #ubuntu?
<dholbach> HiddenWolf, i don't think so
<HiddenWolf> *sigh*
<dholbach> HiddenWolf, what's wrong with it?
<HiddenWolf> It's overflowing with concerned users who can't update their warty's
<HiddenWolf> Which was to be expected, seeing that ubuntu.com is down for maintenance
<tseng> HiddenWolf: how many people read the topic? heh.
<dholbach> tseng, you said, what i thought :-)
<HiddenWolf> tseng: read the topic is shorter than explaining the entire thing. :-P
<herzi> amu: ping
<[m0rph] > hi, the new version of kdelibs in hoary overwrites the gnome /etc/xdg/menus/applications.menu
<dholbach> [m0rph] , the problem is known
<[m0rph] > dholbach: oh, good
<dholbach> and a solution worked on
<tseng> anyone have a gphoto2 camera handy?
<ari> yes
<ari> wait, define "gphoto2 camera"
<tseng> a camera that allows you to properly import photos using gphoto2
<ari> ok
<tseng> care do to a bit of testing for me?
<ari> or rather, a camera supported in gphoto2
<ari> sure, do i have to be running ubuntu? :)
<tseng> yep, hoary even
<ari> i suppose i could set up a chroot
<tseng> hm that would take awhile, this is an X app
<ari> probably not that long
<ari> but i guess i should be doing homework instead
<tseng> heh, that comes first certainly
<tseng> if someone has hoary and a camera and wants to test gphoto2 import with f-spot.. ping me
<ari> oh, it's just in f-spot 0.0.8?
<tseng> yep.
<tseng> someone mailed me a bug report saying it does:
<tseng> Unhandled Exception: System.DllNotFoundException: libgphoto2.so
<tseng> in <0x00053> (wrapper managed-to-native)
<tseng> which I'm guessing is because libgphoto2-2 provides /usr/lib/libgphoto2.so.2
<zul> hola
<dholbach> hi zul
<zul> hey dholbach 
<ari> tseng: there are a ton of DllImport("libgphoto2.so")s all over libgphoto2-sharp
<ari> so yes, it's going to fail if libgphoto2-dev isn't installed
<tseng> ari: yep.
<tseng> but the bit in -dev is just a symlink
<ari> right
<tseng> interesting dilema, which package do I fix :P
<ari> f-stop?
<ari> er, f-spot
<tseng> perhaps. I'm wondering how other apps find the right lib if we dont provide a symlink along with the runtime
<tseng> know any other libgphoto2 apps?
<ari> there are no other C# apps that use gphoto2
<ajmitch> tseng: does mono not do some .so mapping?
<tseng> doesnt have to be C# specifically
<ari> regular C apps just link with the library
<ari> and they use the system linker, so they're found correctly
<tseng> of course they do, heh.
<ari> but you want to use .so.2, no .so
<ari> not
<tseng> ajmitch: there are foo.config.exe
<ajmitch>  /etc/mono/config appears to have some mappings there
* ajmitch cannot recall what the procedure is meant to be for libs :)
<tseng> yes, you can make those per .exe as well
<tseng> but im not sure you can for a dll
<ajmitch> anyway, I've got an exam in a few min, will bbl
<tseng> we can certainly patch the source to hardcode .so.2
<tseng> just.. there must be a more portable way I'd imagine.
<ajmitch> that's nasty
<tseng> ill talk to larry about it later.
<tseng> thanks for helping out also, ari 
<marco_g> hi
<pitti> Hai ogra
<ogra> hi pitti
<HiddenWolf> ogra! :)
<Riddell> dholbach: who is working on a solution to the applications.menu issue?
<dholbach> Riddell, talked to amu about it some hours ago
<Riddell> dholbach: what did he say?
<dholbach> Riddell, nothing specific... 
<Riddell> ok
<tseng> ajmitch: ahh, you can have a .dll.config
<tseng> ajmitch: issue solved.
<tseng> seb128: I've just fixed a bug in my f-spot package
<seb128> k
<tseng> its ubuntu3 if you would be so kind as to look at it at some point
<tseng> what was the outcome of your talk with the maintainer?
<dholbach> i'm out running... bbl
<Kamion> daniels: yo
<zul> hey Kamion  how is it going?
<Kamion> not bad, just back from visiting in-laws
* pitti sends the long-awaited PostgreSQL announcement
<Kamion> ... and back to find a PuTTY security advisory. Er, yay.
<zul> putty for windows?
<Kamion> putty runs on Unix too
<zul> bleah...
* Kamion packages
<deki_> hallo
<deki_> i recompiled the kernel to test if the window rebuild gets quicker
<deki_> i think i have found the reason why mandrake's grafikal interface is much quicker then that of ubuntu
<deki_> their's libqt is linked against libgl 
<crimsun> implying that if the user has a hardware-accelerated GL set, then it's faster? I'm not sure how that would make Mandrake's "grafikal interface" faster on my S3 Virge, for instance
<deki_> hmm
<deki_> i don't know why but i say you the result: the windows rebuild is very very slow on ubuntu hoary comapred to mandrake 10.0
<deki_> on same system
<deki_> i have nvidia geforce 4mx
<deki_> the mandrake has some older xfree version
<deki_> something like 4.3.xxx
<deki_> how can you explain it?
<deki_> when i have one window like mozilla firefox
<deki_> then i take xchat
<deki_> and move it on top of mozilla
<deki_> then i see a very big traces
<deki_> moving traces
<deki_> the system does not do anything
<deki_> the cpu is idling
<deki_> i get same effekt only when mandrake is loaded with compiing of something
<deki_> so what could be the cause of it?
<Kamion> this sounds like it ought to be in a bug report or something, not flooded into IRC
<deki_> hmm thx
#ubuntu-devel 2005-03-04
<deki_> Kamion, thx i will do it, but can it be on wrongly compiled gtk lib?
<Kamion> (because whoever knows about it might not be here)
<Kamion> deki_: I haven't a baldie notion
<deki_> ok
* Kamion <- not gtk expert
<Kamion> our gtk maintainer is not currently in this channel
<beatreader> Hi everyone.
<beatreader> I'm having trouble installing plone on hoary, due to missing packages.
<beatreader> Any thoughts?
<bob2> in this channel the reply'll be something along the lines of "patches welcome"
<beatreader> hmmm...can I add a line to my sources list using debian testing, and get the missing packages from there?
<Kamion> very unwise
<Kamion> apt gets upset by the existence of two different packages with the same version number but different md5sums
<doko> beatreader: wait until tomorrow ... we'll have complete plone packages soon.
<beatreader> But then kamion, what are my options?  It`s not realistic for me to build the packages from scratch.
<Kamion> beatreader: we don't suggest that users try to get bugs fixed by random distro-hopping :-)
<Kamion> universe is there so that people don't have to try to mix - if there are bugs in universe they should be fixed in universe. :-)
<zul> hey pitti are you going to have a deb for postgresql jdbc? :)
<pitti> zul: not from my side
<pitti> zul: if you want to care for it, I'm happy to assist you, though :)
<pitti> zul: I'm just not using Java for anything
<zul> pitti: yeah ill see about that :)
<pitti> zul: could be a nice test/use case for pgxs and postgresql-server-dev
<jdub> pitti: postgres stuff sounds rad
<pitti> jdub: thanks :-)
<pitti> jdub: btw, is there something like an experimental counterpart for Ubuntu?
<pitti> jdub: I just uploaded all this crack to Debian/experimental
<pitti> jdub: but it would be nice to have a similar place for Ubuntu, too
<zul> lamont: ping
<jdub> pitti: hoary universe?
<pitti> jdub: I can't put the upgrade transition packages there
<pitti> jdub: they naturally have the same name as the current packages (postgresql, postgresql-client, etc.)
<pitti> jdub: however, having the other packages in universe sounds good
<jdub> yeah
<pitti> jdub: you just lose the upgrade path, but can install them from scratch
<jdub> perhaps put the transition packages in a personal repo
* sivang notes the upgrade path looks cool
<jdub> pitti: when we have derivative stuff going, you could have your own personal buildd area ;)
* pitti looks forward to that
<dholbach> if i'm going to use  DEB_AUTO_UPDATE_AUTOMAKE  and friends in  debian/rules  - i have no alternative but build-depend on specific versions of the autotools, right?
<pitti> dholbach: argh, DON'T do that
<pitti> dholbach: "This way madness lies"
<dholbach> pitti, i wasnt sure if it was considered a common rudeness
<pitti> dholbach: please try to put the changes into the package diff.gz instead
<pitti> dholbach: it's not rude, it's just unstable
<dholbach> i see
<dholbach> ok
<dholbach> i thought it'd be nice to have a clear tarball and a clear diff.gz as well, but i listen to advice :-)
<pitti> dholbach: a clean diff.gz is certainly a good thing :-)
<pitti> dholbach: however, breaking builds because of it is bad
<pitti> dholbach: btw, my favourite build system is cdbs+tarball
<pitti> dholbach: then you can put the autofoo changes into a proper patch
<pitti> elmo_: can I bribe you somehow to give postgresql in experimental/NEW some extra love? :-)
<dholbach> pitti, the "diff.gz > orig.tar.gz"-situation annoyed me that hard, i didn' even try the tarball alternative
<pitti> dholbach: oops :-) for which package?
<dholbach> gparted
<pitti> dholbach: it's not going to be smaller with tarball, just nicer to maintain
<pitti> ah
<pitti> well, with a small orig.tar.gz this happens...
<elmo_> pitti: prod me about it in a couple of days, if I haven't done it - I'm too tired to do new tonnight, sorry
<pitti> elmo_: oh, I wasn't speaking of "now, instantly, yesterday" :-) 
<pitti> elmo_: thanks, will do
<dholbach> elmo, how was the "server maintenance" going?
<elmo_> dholbach: took longer than expected, but it was ok
<dholbach> elmo_, very good! :-)
<ogra> elmo ! :)
<pitti> night everybody
* pitti falls asleep
<ogra> night pitti
<dholbach> sleep tight, pitti
<elmo_> ogra: um, there was a couple of things with hwdb.. 
<ogra> oh, a couple ?
<ogra> elmo: tell me ....
<elmo_> ogra: 'hwdb' isn't expanded anywhere in the description and will be meaningless to most people
<ogra> oh, ok
<elmo_> ogra also, why arch: any and not arch: all?  it seems to be simple python scripts
<ogra> ok, i'll fix that too
<elmo_>   programs for the ubuntu hdwb system to collect device, config,
<elmo_>   log and QA data from ubuntu systems
<elmo_> isn't great, but I'm too tired to suggest anything better really.. "Programs to collect device, config, logs and QA data for the Ubuntu Hardware Database." maybe?
<ogra> at least lintian was happy with that... i'll make it more descriptive
<elmo_> that'd be great, thanks
<ogra> sounds good
<ogra> hmm, wouldnt lintian moan about capital Programs ? 
<elmo_> oh, ignore that lintian thing; I'm not at all convinced by it
<elmo_> err, that specific lintian moan, I mean
<ogra> you should make a list, which warnings are serious and which arent ;)
<elmo_> nah, lintian should be fixed - I think most of the most dubious ones already have been, but after we froze
<ogra> to sad its in main...
<elmo_> there's always hoary+1 :)
<ogra> heh, true :)
<ogra> should i bump ubuntu0 to ubutu1 for the fixes ?
<sivang> night all!
<dholbach> bye sivan!
<elmo_> ogra: please - unless you want me to reject ubuntu0
<sivang> night dholbach 
<ogra> okay
* sivang --> *sleep*
<jvw> elmo_: you have lintian 1.23.6/7? That were not really the best lintian releases... but whatever
<elmo_> jvw: well if you know of any RC level bugs later versions fixed, I could ask for ours to be updated..
<jvw> no RC ones
<jvw> for my definition (Debian's) or RC at least
<jvw> elmo_: do you ahve access to /msg to 'elmo'?
<elmo_> jvw: I can do ..
<jvw> not urgent
<jvw> more urgent one being typed now :)
<elmo_> dude, stop sending messages to the non-live client :P
<jvw> ok ok...
<jvw> you said you had access to it :)
<elmo_> I do - by less(1)-ing the logfile - and that's over a non-great link
<dholbach> how can i "update" the gnome menus? is it gamin/inotify deserving a kick?
<ajmitch> elmo_: what happened with the gtk# 1.9.2 upload that I did? katie doesn't send me mails, so I can't tell :)
<ogra> dholbach: kill the panel
<herzi> dholbach: kill -9 `pidof gnome-panel` :-D
<ogra> (which slays gaim btw)
* dholbach cries a bit, but kills the panel mercilessly
<elmo_> ajmitch: what address do you use in Changed-By ?
<ajmitch> ajmitch@gnu.org
<elmo_> did too send you the REJECT
<ajmitch> ok, it must be getting dropped somewhere
<elmo_> looks like it timedout during the upload
<elmo_> are you uploading from a slow link?
<ajmitch> 128Kbps up
<elmo_> unfortunately there's a bug in our upload daemon that times uploads out after 900s, you might want to try uploading just the orig.tar.gz separately, then the rest
<ajmitch> alright, thanks
<elmo_> or upload it to somewhere with faster uplink, and from there to ubuntu... sorry, it sucks
<dholbach> i'm off to bed
<ogra> night
<ajmitch> night
<ari> who was looking for a todo list the other day?
<ari> oh, srbaker
<lamont> daniels: ??
<lunitik> Does Evince replace Xpdf in 'ubuntu-desktop' yet?
<Safari_Al> lunitik, not yet.
<lunitik> Safari_Al, ahh... k, thank you
<daniels> lamont: !!
<lamont> daniels: wassup?
<daniels> lamont: ah, nothin' :) was wondering how to kick and mirror-sync a custom cd build, but colin got to it
<lamont> ah, good
* lamont tends to not be around much on sunday, if you haven't noticed...
<daniels> lamont: ahr :)
<da_bon_bon> when are we expecting gaim and xserver-xorg updates ?
<ari> as in gaim 1.1.3?
<da_bon_bon> yes
<ari> probably not until the ppc crasher is fixed
<da_bon_bon> what ppc crasher ? gaim 1.1.3 crashes ppc ?
<ari> da_bon_bon: yes
<ari> unless you build with -O0
<da_bon_bon> ari: and what disadvantages does building with -00 have ?>
<ari> no optimization
<ari> and it doesn't address the real problem
<da_bon_bon> oh ok..
<da_bon_bon> ari: u the gaim maintainer ?
<ari> for debian, yes
<ari> well, one of them
<da_bon_bon> :)
<da_bon_bon> not for ubuntu ?
<crimsun> da_bon_bon: because gaim is in main, all the developers "maintain" it.
<da_bon_bon> crimsun: ah, ok..
<da_bon_bon> when r we getting xorg 6.8.2 ?
<dilinger> fabbione and pitti probably aren't around, are they?
<bob2> fabio's won't be back until...some point in the distant future
<dilinger> hrm, ok
<dilinger> i'm looking at http://www.ubuntulinux.org/support/documentation/usn/usn-82-1
<dilinger> i guess i'm misunderstanding pitti's english
<dilinger> <pitti>         "In 2.6.8, the only processes that could lock shared memory segments
<dilinger> <pitti>         were those with CAP_IPC_LOCK.  Unprivileged processes did not get a
<dilinger> <pitti>         look in." so this is 2.6.9
<dilinger> he probably meant it was fixed in 2.6.9
<Mithrandir> daniels: does fd.o's bugzilla have any "pending" state?
<herzi> ari: http://www.blaubeermuffin.de/packages/ there's a gaim-plugin-encyption for hoary, would you sponsor an unstable upload for me?
<pitti> Morning
<doko> morning pitti
<pitti> Morning carlos
<carlos> pitti: morning
<pitti> Kamion, jdub: I'd like to sync awstats 6.3-1 to hoary; it's a new minor upstream version, but fixes a lot of things
<pitti> Kamion, jdub: http://packages.debian.org/changelogs/pool/main/a/awstats/awstats_6.3-1/changelog
<pitti> Kamion, jdub: http://sourceforge.net/forum/forum.php?forum_id=441331
<bob2> dilinger: oi
<d3vic3> doko, ping 
<doko> d3vic3: pong
<dholbach> hai
<dilinger> bob2: we!
<bob2> pitti's back so you can harass him directly
<pitti> bob2: who?
<dilinger> bob2: thanks, already did :)
<bob2> ah, right
<bob2> the best bit about firefox is when it stops redrawing the screen and spins at 100% cpu
<bob2> 195 frames deep, no less
<Treenaks> 195 frames deep?
<bob2> er, the backtrace is
<Treenaks> ah ok
<Treenaks> not the page
<bob2> heh, no
<dholbach> hellas mvo!
<mvo> hi dholbach 
<mvo> morning all 
<dholbach> hi dredg
<dredg> hey
<Kamion> pitti: go ahead
<dholbach> hi seb128 
<seb128> morning
<pitti> elmo_: please sync awstats (new upstream version ack'ed by Kamion), and bidwatcher
<dholbach> could it be that, whatever puts the buildlogs on p.u.c/~lamont deserves some persuasion
<pitti> elmo_: pdns sync, please
<seb128> jdub: the gtk icon cache is so bong
<seb128> totally bong
<jdub> broken bong?
<seb128> yeah
<seb128> if an app install an icon in /usr/share/icons/hicolor/...
<seb128> the app needs to update the timestamp for the basedir (/usr/share/icons/hicolor)
<seb128> or the cache just mask the icon
<seb128> and we have about 350 packages puttings some icons here
<seb128> without updating the timestamp
<seb128> so 350 apps broken
<jdub> oh man
<seb128> some of them crash, some other don't display an icon
<jdub> oh man
<seb128> exactly
<jdub> how's that for an optimisation!
<seb128> and owen's reply is "The icon theme spec requires the toplevel directory mtime to be updated when installing something into a subdir."
<jdub> :-)
<seb128> and NOTABUG so
<seb128> that an the icon cache doesn't work on ppc
<seb128> you only get hicolor icons
<seb128> we are probably dropping gtk-update-icon-cache in deb for the moment
<seb128> I'm curious to know how fedora uses it
<pitti> Hi Astharot 
<Astharot> hi pitti :)
<pitti> Astharot: do you want to provide an updated patch for synaestesia?
<dholbach> bbl
<Mithrandir> jdub: did you see my comments about flumotion on Thursday?
<Astharot-> shit :|
<Astharot> pitti: have you wrote something else? :)
<pitti> Astharot: Joey sent an updated patch to the ML
<Astharot> yes I know...
<Astharot> I'm fixing it
<pitti> thanks
<pitti> mvo: btw, I'm still getting the cron error
<pitti> mvo: Could not open ./pool/universe/f/fireflier/fireflier_1.1.4-3/changelog
<Astharot> did you see other patches ?
<pitti> mvo: this is a dangling symlink to "../changelog" -> please resolve symlinks in your script
<pitti> Astharot: yes, I saw them
<pitti> Astharot: I will process them ASAP
<Astharot> ok perfect ;)
<jdub> Mithrandir: nup
<jdub> Mithrandir: fire away
<Mithrandir> jdub: it's almost there, but it needs to be easier to get started with.
<jdub> yeah
<jdub> there's a bit of zen to grok
<Mithrandir> jdub: currently, it's "fire up those three magic commands, then a flumotion-admin (with the auth info on the command line)", which really sucks.
<Mithrandir> it was easy, but wrong.
<jdub> also, my package makes it a bit harder once you understand it
<jdub> /usr/sbin/flumotion makes it easier
<jdub> but i haven't made an init script for it yet, etc.
<Mithrandir> one shouldn't have to be root to run the streaming server.
<jdub> also, local changes improve generation of default.pem, etc.
<Mithrandir> there's really no reason why one should be.
<jdub> yeah, i don't run it as root
<Mithrandir> we might want to do something like user-level services at some point.
<Mithrandir> where a user can say "when this box boots, run those commands"
<jdub> to make things Just Work, i'm going to add a flumotion user, and add it to audio/video
<jdub> Mithrandir: @reboot in cron :)
<Mithrandir> jdub: why not just parrot on the init script system?
<jdub> i dunno
<jdub> seems a bit cracky ;()
<jdub> :)
<Mithrandir> it's really the same thing.
* thom yawns
<Mithrandir> and you would get stop/start/reload/restart at the same time.
* Mithrandir throws an orange at thom 
* thom ducks
<seb128> hey thom 
<Mithrandir> dude, it's far from .no to .uk, but not that far. :)
<seb128> thom: firefox update today ?
<pitti> thom: <bitch>for warty, too? :-)</bitch>
<thom> Mithrandir: thpppppt
<mvo> pitti: it does resolve symlinks now, is it possible that this is a old entry written before the script was fixed?
<pitti> mvo: oh, right. That's entirely possibl
<pitti> e
<pitti> mvo: thus this will never be fixed?
<pitti> or can you fix it manually?
<seb128> thom: have you read the message about firefox/the pango patch ?
<Astharot> pitti: sent
<pitti> Astharot: I saw it, thanks
<mvo> pitti: I just removed the fireflier changelog dir, it will be recreated (corretly) soon (script runs)
<pitti> mvo: thanks a lot
<thom> seb128: yes, thank you
<mvo> pitti: are there any more packages with broken symlinks that you are aware of? :) 
<pitti> mvo: no, that's the only one
<mvo> pitti: I can ping you when the script has finished (if you want)
<seb128> thom: np
<pitti> mvo: not necessary, it's not urgent
<Sionide> hey i'd just like to say, i installed ubuntu on my laptop yesterday and it went on like a dream...
<Riddell> I'm getting complaints that kvim and vim can't be installed in warty (which means installing kde metapackage removes vim)
<Riddell> kvim depends on vim (= 1:6.3-046+1ubuntu3) but vim has had a security update, any way that can be fixed?
<pitti> Riddell: yes, you need to upload a new kvim as well
<Kamion> kvim is part of the vim source package
<pitti> Riddell: feel free to upload a fixed version
<pitti> Riddell: (but please send me a debdiff before)
<Kamion> no, hold on a second please
<Kamion> (trying to find the bug you need to refer them to)
<pitti> Riddell: oh, it's part of vim source? then please hold on
<Riddell> pitti: looks like it is, I didn't realise that
<Kamion> Riddell: please refer them to bug #3599
<Kamion> comment #2
<pitti> ah, that's the reason
<pitti> thanks Kamion
<Riddell> Kamion: ah hah, 
<Riddell> many thanks
<dholbach> did someone resolve the build/buildlogs-issue, when i wasnt here?
<dholbach> at least what is going wrong
<daniels> Mithrandir: no
<Mithrandir> daniels: bah :/  I'll use [PENDING]  in bug titles or something, then.
<daniels> Mithrandir: if you can fix our setup, or find someone to do the same ... :)
<Mithrandir> daniels: can't you get me drunk and drop me into a root shell when I'm in .au and I can look at it? ;)
<daniels> Mithrandir: root access on fd.o is a very exclusive club
<Mithrandir> yeah, only like 20-30 people or have you cut down on that now?
<thom> Mithrandir: nah, about 2000 people
<thom> jdub: what should i be calling Firefox in the menu? Firefox? Firefox web browser? Your Mum?
<toresbe> heh
<toresbe> "Launch Your Mum"
<Mithrandir> thom: it's just called firefox here.
<daniels> Mithrandir: only 6, and none of us are NOPASSWD
<daniels> oh, and pasc has limited sudo (i.e. /usr/sbin/postfix)
<Mithrandir> daniels: I don't have NOPASSWD on my laptop and I have a 20-ish char passwd. :P
<daniels> heh :) well, no-one had passwords on fd.o before
<daniels> or, we did, but the ldap admin stuff we had was so fucked up that no-one knew what their passwords were
<Mithrandir> everybody knows passwords are overrated anyhow
<daniels> and i think everyone had forgotten the root password
<daniels> so it's kind of lucky that we didn't have any catastrophic failures
* daniels notes that, post-compromise, after he rebuilt the machines, it is now a LOT better.
<thom> Mithrandir: yes, and there's a bug filed about that
<thom> that's why I'm asking :-)
<Mithrandir> thom: ook
<pitti> elmo: typespeed sync, please
<Mithrandir> Keybuk: any suggestions on how to multiarchify libtool?
<Keybuk> shouldn't it happen automatically ?
<Keybuk> it tends to just query gcc for things like include and lib directories
<Mithrandir> hmm, weird.
<Mithrandir> it doesn't seem to here.. or if so, it doesn't get all it should
<Keybuk> oh
<daniels> Kamion: ping
<Kamion> daniels: pong
<thom> elmo: please sync db2latex-xsl
<jbailey> Kamion: Just taking a quick pass through the bugs that mdz assigned to me.  Would you mind taking a look at #3982?  It's about a series of d-i errors with a fix in Debiian already.  I'm wondering if you know that it's generally safe for me to just import the fixes / a new version from Debian (+ Ubuntu changes)?
<thom> seb128: firefox uploaded
<thom> fixes epiphany locally, at any rate
<seb128> rock
<Kamion> jbailey: looking
<Kamion> jbailey: console-data is a package we've locally modified, but it's generally safe to merge it.
<Kamion> jbailey: however, we've already got a version newer than the one reported to fix the bug
<Kamion> jbailey: so I should think it can just be closed (maybe following a test)
<jbailey> Ah, hadn't noticed that.  *sigh*  Sorry for the hassle.  Will test & close.
<mjg59> daniels: Hmm. I'm not having much love with 3D over suspend/resume
<Kamion> no hassle at all :)
<daniels> mjg59: bongtasmic.  i'm just running stock ... 2.6.10-2-686, actually.
<daniels> so it might have regressed.
<mvo> quick poll: is this message to scary: "<big>Warning</big> You are about to install software that can't be <b>authenticated</b>! Doing this could allow a malicious individual to damage or take control of your system."?
<Treenaks> it's not scary enough :)
* mvo chuckles
<Treenaks> mvo: but seriously, I think it's OK
<Kamion> I would do <b>can't be authenticated</b> rather than just bolding authenticated
<Kamion> it reads oddly the way it is
<Treenaks> mvo: it looks like the firefox-for-windows "You downloaded an EXE file" dialog
<mvo> Kamion: good point
<Treenaks> mvo: and that scared my grandmother into not installing spyware twice already :)
<mvo> Treenaks: never seen that one :)
<mjg59> Snow!
<mvo> Treenaks: but it seems to work!
<mvo> Treenaks: your grandmother uses a computer?
<Treenaks> mvo: an old windows-98 based one, but yes
<dholbach> <big>Warning</big> You are about to install software that <b>can't be authenticated</b>! Doing this could allow a malicious individual to damage or take control of your system. <i>In that way modified computers were observed to be browsing porn, riding next door neighbours motorcycles and drinking all the milk on their own accord.</i>
<mvo> Treenaks: how old is she?
<mjg59> daniels: Are you sure you didn't compile the DRM stuff yourself?
<Treenaks> mvo: 76
<daniels> mjg59: ... not entirely
<mvo> Treenaks: nice!
<mjg59> I can't find anything in the patches that would provide it
* mvo chuckles at dholbach 
<mjg59> daniels: Oddly, I can't find them in dri CVS either
<mjg59> Where's the dri tree in the xorg tree?
<daniels> mjg59: /cvs/xorg:xc/extras/drm
<daniels> i can't remember how airlied maintains it; it's probably /cvs/mesa:drm
<mjg59> daniels: Ok, got it
<mjg59> The suspend/resume code is in Xorg CVS, but not in DRI CVS
<mjg59> So we don't have it in the kernel. Gragh.
<daniels> ah yeah
<daniels> /cvs/dri:drm
<daniels> oh yeah, alanh fucked that up horribly :\ committed straight to extras/drm, never sent a patch through
<daniels> and all the drm stuff had changed, so it's a bitch to port over
<daniels> airlied was explaining this last week
<mjg59> Hrngh.
<mjg59> Any chance of getting it into our tree?
<daniels> hmmm, dunno
<daniels> it would mean another ABI change :\
<daniels> aiui
<daniels> actually, no, never mind me
<mjg59> Well, it's either that or we ship without 3D suspend/resume on i830
<mjg59> Which would suck
<daniels> yah
<daniels> i'll talk to zul and lamont about it tomorrow
<daniels> right now, I'm just trying to work out why evdev sucks so much
<mjg59> Haha
<daniels> from cat'ing the event device, mouse presses and release generate unique events
<daniels> yet the xorg evdev driver seems to fire them both off only when buttonrelease is fired
<daniels> i.e. no window draggy-draggy
<Kamion> Riddell: I don't know if anyone's reported this to you already, but could you/someone get kynaptic rebuilt against current apt?
<pitti> Hi elmo_ 
<pitti> elmo_: is it a known problem that the buildds are inactive?
<mjg59> daniels: Ok, if I don't have a chance to look at it tonight I'll let you do it tomorrow
<Riddell> Kamion: will do
<daniels> mjg59: represent
<pitti> elmo_: i. e. are you workign on them?
<Kamion> Riddell: thanks
<Riddell> Kamion: poke me if I forget
<Kamion> ok
<mjg59> Damnit, the sysadmin has stolen my ethernet cable
<HiddenWolf> mjg59: go kick butt
<daniels> huh, what
<elmo_> pitti: no - what's not built?
<elmo_> never mind, I know what it is
<dholbach> elmo_, none of my packages too, although katie sent me nice receipts for every package (since 01:00 UTC)
<mjg59> daniels: Other weirdness - if I suspend/resume, then I can't start X again. The running one works fine, but restarting it gives an error saying that a vm86 call failed.
<mantiena> Hi all
<daniels> mjg59: huh, bong.  are you vbe posting it?
<mjg59> Yeah
<daniels> mjg59: (bearing in mind that i8xx relies on vbe to set modes)
<mjg59> And setting state on restore
<daniels> mjg59: try not doing that, then; i don't need to vbe post when i resume (then again, i have dri around s3), and have no problems
<mjg59> Heh. It /used/ to work, though.
<daniels> bong
<mjg59> I'll look into it when I'm not preparing for a talk
<daniels> heh :) i have my entire lca talk still to write, 'twas due on friday
<daniels> *sigh*
<sivang> Morning all!
<dholbach> hi sivan!
<mjg59> I need to write my FOSDEM talk. And my GUADEC paper.
<tritium> Hi sivang
<daniels> eep
<daniels> what're you talking on?
<ogra> mjg59: you talk at FOSDEM ?
<daniels> my topic is rather handwavey; 'fd.o'
<mantiena> seb128, hi are you online ?
<seb128> afternoon
<mantiena> seb128, I have one question to you regarding to http://bugzilla.gnome.org/show_bug.cgi?id=167941
<elmo_> ok, buildds should be happier now
<mjg59> ogra: In the Debian room
<seb128> mantiena: yeah ?
<dholbach> elmo_, cool
<ogra> mjg59: sat or sun ?
<mjg59> Sunday
<ogra> ah, ok....i'm still not sure which day i'll come (or both?) .... good to know :)
<mantiena> seb128, there is serious policy violation bug reported agains gtk in debian bugzilla, but same bug is considered as not a bug by upsream, so what debian maintainers will do ?
<seb128> mantiena: upstream consider that as not a gtk bug, not "not a bug"
<seb128> mantiena: we probably need to make a dh_something for that and use it
<seb128> mantiena: for the moment we will probably drop the icon cache to get the issue sorted
<mantiena> seb128, some packages, for example OpenOffice.org can't go into sarge because of this bug :(
<Treenaks> openoffice.urgh
<seb128> mantiena: not only openoffice, and that's not only this bug, the cache is broken on ppc too
<seb128> mantiena: BTW we are working to fix that, don't worry
<seb128> and I'm away for ~45min now
<mantiena> seb128, thanks
<jordi> mvo: ping
<jordi> mvo: well, anyway:
<jordi> "-t   Give a alternative main window titel (e.g. hostname with `uname -n)`\n"
<jordi> s/titel/title/ & s/-n)`/-n`)/
<mvo> jordi: fixed some minutes ago in svn :)
<jordi> damn :)
<jordi> mvo: is the synaptic in Debian the one with the package change history stuff?
<jordi> because I don't see it
<mvo> jordi: the version in sid should have it, yes
* mvo checks
<jordi> oh
<jordi> yeah
<jordi> sorry, it's in the File menu.
<jordi> I wonder if thE file menu should the the Package menu, and the file menu an "Actions" menu or whatever.
<jordi> dunno what the HIG says about the first menu at all
<mvo> jordi: do you think it should be moved somewhere else?
<jordi> no, it was probably a wild idea. If I check the HIG and find something that supports it I'll tell you about it.
<jordi> I have this idea that the name of the first menu has the name of the objects the application deals with. For example, sj has "CD", etc.
<jordi> So maybe synaptci could have "Package". But this is probably not sustained in any guideline :)
<jordi> I gotta go, 3PM.
<jordi> laters.
<mvo> jordi: yeah, the file menu does not really fit very well. but it's hard to come up with a better menu I think
<mvo> jordi: bye
<zul> hey
<mantiena> daniels, are there any plans to write Driver "nvidia" instead of "nv" into xorg.conf during xorg autoconfiguration (XORG_FORCE_PROBE=yes dpkg-reconfigure -fpassthrough xserver-xorg) if nvidia-glx and nvidia-kernel packages exist in system ?
<daniels> mantiena: no
<dholbach> hi zul
<zul> hey dholbach 
<mantiena> daniels, I could write a patch if you accept - problem is, that ubuntu-based LiveCD with 3D games reguire to use nvidia driver and with realization of X autoconfiguration there ar no way to do this :(
<daniels> mantiena: i won't take a patch to do it
<daniels> mantiena: the thing is, there's an open source alternative that generally works, and nvidia is known to be broken on some hardware (it will not work with any card below a geforce2; including geforce256, geforce128, tnt2, tnt, riva256, riva128)
<pitti> lamont: ping
<daniels> deploying a binary-only driver is an absolute no-no, and we should only ever even consider it when we have no other choice to get a basic screen up
<mantiena> daniels, you are not right, nvidia works fine with TNT and riva cards
<daniels> mantiena: wrong.  1.0.6629 will produce blank screens.
<daniels> mantiena: it's a 'known issue' upstream, and they will fix that in their 'next release'
<daniels> i don't know when the next release is
<daniels> and dropping support for even just tnt2s is absolutely unacceptable
<mantiena> daniels, I don't tested on 1.0.6629, but on some older version it really work
<daniels> yes, it used to work on 1.0.6111
<daniels> and now it's broken with 1.0.6629
<daniels> and because it's binary-only, no-one has any idea how or why, or how to fix it
<mantiena> daniels, Btw, don't understand me - I don't wanna make proprietary driver default
<daniels> right now, there is only one (one) case where nvidia works and nv doesn't, and that case isn't handled by the standard installer right now anyway
<daniels> but i need sleep, so goodnight
<mantiena> daniels, I just wanna make to write Driver "nvidia" if user had *already* installed proprietary nvidia driver
<daniels> and yeah, it's just not going to happen, sorry.  even giving users the option to install binary drivers is a horrendously bad idea, and will lead to a support nightmare that i'm just not interested in.
<daniels> how would they have already installed it?
<daniels> anyway
<daniels> sleep
<mantiena> daniels, good night, we might to talk about this tomorow
<zul> hey pitti how is it going?
<pitti> Hi zul
<pitti> zul: like every monday - a weekend worth of security fixes :-)
<zul> pitti, say it aint so
<sivang> hi pitti !
<pitti> Hi sivang 
<sivang> seb128: do you have the bug report number where mdz commented about enabling cups web interface?
<pitti> sivang: what about it?
<pitti> sivang: sudo adduser cupsys shadow
<sivang> pitti: ah, and it's done? ;-)
<pitti> you need to restart cups
<sivang> pitti: and then I can connect to the web interface?
<seb128> pitti: ?
<pitti> sivang: but why do you want to do this?
<pitti> seb128: !
<pitti> ;-)
<sivang> pitti: I just wanted to read the bug report, see if I can give a hand there :-)
<seb128> pitti: I'm not sure that you are speaking about the same thing
<pitti> seb128: what do you mean?
* pitti talks about the disabled admin capabilities of the web interface
<seb128> pitti: the bug is about adding something in the gnome-cups-manager UI to activate the web access
<pitti> ah
<pitti> seb128: I don't know that one
<snaggen> seb128: Hi, did you take a look at my nvtv package the other day?
<seb128> snaggen: no yet
<snaggen> ok, just checking... no panik :)
<snaggen> Another thing... I tried openoffice.org2 the other day. What state is it in, or rather: do you want bugreports about it or is it too unstable and you know it?
<seb128> sivang: I don't find the bug now
<sivang> seb128: ok, I'll do a heavy search.
<seb128> http://bugzilla.ubuntu.com/show_bug.cgi?id=2251
<seb128> that's it
<sivang> seb128: _thank_ you :)
<seb128> pitti: and this bug is assigned to you
<seb128> pitti: you should known about the comment :p
<seb128> *g*
<pitti> seb128: oh, THAT one
<pitti> seb128: but that's something entirely different
<pitti> seb128: #2251 talks about enabling broadcasts, sivang talks about enabling the admin stuff on the website
<seb128> pitti: I speak about the comment #13
<sivang> pitti, seb128 : going out for something urget for about 30 minutes, talk after.
<tritium> wasabi, is something wrong with my setup, or are XML parsing errors common with yelp?
<wasabi> me?
* wasabi looks around.
<wasabi> oh hey seb left me as the maintainer.
<pitti> thom: here?
<tritium> wasabi, sorry
<wasabi> tritium, I heard some talk about some bad XML somewhere. =)
<tritium> wasabi, okay, thanks.  So seb128 is the new maintainer?
<wasabi> Not exactly.
<wasabi> Sorta.
<pitti> seb128: "browsing" == automatic cups server detection with broadcast packets
<pitti> seb128: that has got nothing to do with the web interface
<wasabi> You'd be best using bugzilla I imagine.
<tritium> wasabi, ok, thanks.
<wasabi> http://bugzilla.gnome.org/show_bug.cgi?id=167808
<wasabi> In fact...
<seb128> pitti: ups
<tritium> wasabi, that's it exactly
<pitti> seb128: still, your comment as a gnome guru is appreciated :-)
<seb128> k :)
<thom> pitti: yeah
<thom> (was just commenting on the punycode thing)
<elmo_> Kamion: ?
<thom> elmo_: thanks for the sync
<elmo_> thom: screw you
<elmo_> err, I mean no problem
<smurfix> elmo_: was that a Freudian one or did you hit the wrong hotkey? ;-)
<thom> chaaaarming
<elmo_> thom: I just got "On battery, not fscking!" on the live cd on Davis.. is that your fault? :>
<thom> urm, yeah. could be
<thom> how the hell did you manage that?
<elmo_> smurfix: dude, I just tried your keyboard selector thing - it got confused by me trying to use the shift key ("Keycode 54 not expected") - known bug?
<elmo_> thom: what's to manage?  I booted daily live CD :>
<smurfix> elmo_: I probably should implement a list of keycodes of modifier keys
<smurfix> elmo_: or clarify that it asks you to hit the key with that symbol on it, not anything else
<thom> elmo_: lamer.
<thom> :-)
<smurfix> elmo_: anyway why confused? it should just ignore the thing (other than showing the message).
<elmo_> smurfix: yeah, clarification would be good
<elmo_> smurfix: also, it'd be nice if the timer could not appear immeidately; as it is atm, it feels a bit pressured
<elmo_> or if it didn't go down in second increments maybe
<smurfix> elmo: Good idea, ten-second-decrements until one gets into single digits sounds OK, no?
<ogra>  elmo_: still any robs with hwdb ?
<ogra> s/robs/probs
<elmo_> smurfix: sounds great
<elmo_> thom: okay, prob is /proc/apm exists but is garbage
<elmo_> probably because this G5 doesn't have normal PMU 
<thom> davis is g5, right?
<thom> rm, right
<thom> hrm, even
<elmo_> ogra: haven't checked yet, will try and do in a bit
<ogra> ah, great...didnt want to push you :)
<elmo_> thom: yeah, /proc/pmu is SNAFU too - so it's a kernel wishlist thing, NYP
<elmo_> is there anything fun/interesting I can do with the live CD beyond, err, boot it up? :)
<elmo_> thom: http://people.debian.org/~terpstra/message/20050218.043453.b820f5e2.en.html
<thom> ah, heh
<enrico> Kamion: around?  At the docteam we'd like to make a checkpoint of the situation wrt our things and the freeze dates
<dholbach> i'm out with murphy - see you later
<elmo_> ogra: it FTBFS :(
<elmo_> binary needs to depend on binary-indep not binary-arch in debian/rules
<tseng> (Reading database ... dpkg: error processing openoffice.org2 (--remove):
<tseng>  files list file for package `openoffice.org2-core' contains empty filenam
<tseng> where is this file?
<ogra> elmo_: gah.... i'll upload a new one this evening...
<ogra> elmo_: thanks for looking
<Mitario> hi everyone
<mvo> hi Mitario 
<Kamion> elmo_: yo?
<Kamion> elmo_: maybe see if you can do an apt-get upgrade successfully
<Kamion> or install some other packages or something
<Kamion> tseng: /var/lib/dpkg/info/openoffice.org2-core.list
<tseng> Kamion: found that. its binary =/
<Kamion> tseng: corrupt, then; I'd remove it and reinstall the package
<Kamion> enrico: here
<seb128> tseng: hey, new fspot to package :)
<tseng> Kamion: thanks.
<elmo_> Kamion: the yaboot text on the live cd still talks about 'linux' .. but the option it actually wants is (obviously) 'live'.. file a bug?
<tseng> seb128: will do.
<seb128> pitti: are you interested by my log too for the mount a few min after the login ?
<seb128> thanks
<pitti> seb128: sure, by any meams
<pitti> means, even
<pitti> seb128: it does not occur for me
<Kamion> elmo_: fixed, thanks
<enrico> Kamion: hi!  How's the status with the freeze?  Have the docteam packages we made been seen by someone, or mdz went in vacation just before receiving my mail about them?
<seb128> pitti: k
<Kamion> enrico: I haven't seen them or assigned anyone to look at them, so I don't know
<Kamion> enrico: I would say that your packages are pretty low-risk with regard to the freeze, so they could go in late
<enrico> Kamion: http://www.enricozini.org/store/mdz
<Kamion> enrico: I wouldn't sweat it just at the moment, mdz'll be back in a day or two
* Kamion downloads
<enrico> Ok, so we can wait for him.  Also, it'd be important for us to know about other deadlines, such as having the docs ready for review or translation
<elmo_> Kamion: the text could also IMO do with emphasizing Apple's more since I assume they're by far our most commonly used powerpc machine  - I suppose there's no hope of getting rid of the whole subarch selection thing and have it automated - maybe it could be a wishlist thing we could offer a bounty on ?
<sivang> back
<mantiena> guys, maybe someone could tell me which package should load TV card infrared module (ir-kbd-gpio or ir-kbd-i2c, see http://linux.bytesex.org/v4l2/faq.html#ir ) ? bttv module is loaded automatically, but IR module - not :( 
<tseng> seb128: update looks good, uploading
<seb128> tseng: cool
<Kamion> elmo_: we could bounty benh, but IBM might object ;)
<tseng> someone wrote a review of hoary and lamented that f-spot and some other mono stuff wasnt on the livecd, heh
<Kamion> elmo_: yeah, could you file a bug about the Apple emphasis and I'll rethink it?
<elmo_> ok
<elmo_> is the CD meant to appear on the desktop these days?
<tseng> seb128: check that out
<seb128> elmo_: yeah, but that's quite broken by inotify, should be better if you boot in "noinotify"
<tseng> seb128: er wrong revision name
<seb128> I'll fix it before uploading, don't bother
<seb128> thanks
<tseng> np
<elmo_> hey! where did this thing get a configured resolv.conf from?  does it take from a linux fs if it finds it?
<tseng> seb128: if you are still in contact with the debian maintainer you might show him my libgphoto2-sharp.dll.config fix.. the bug isnt obvious if you have libgphoto2-dev installed
<elmo_> seb128: actually it appeared, I just didn't expect it to :)
<seb128> oh, ok :)
<Kamion> elmo_: netcfg probably did it
<Kamion> via DHCP
<elmo_> Kamion: ain't no DHCP server on the LAN
<elmo_> no libgnome2-perl's on the CD so no gnome debconf frontend - or is that feature?
<Kamion> probably bug
<ogra> elmo_: depends on whom you ask ;-p
<Kamion> no idea where else it might have got resolv.conf from
<Mithrandir> elmo_: does the resolv.conf make sense for the lan?
<Mithrandir> elmo_: it might have been copied as part of the cd bootstrapping process, possibly?
<elmo_> Mithrandir: hmm, could be
<thom> my god, it is *throwing* snow down outside
<elmo_> dude, I know, I had to go and get lunch in this weather
<elmo_> would it be too DWIMish to suggest that the live CD be ejected when the user selects "Restart computer"?
<thom> it's settling too. score!
<Mithrandir> elmo_: file bugs! :)
<elmo_> Mithrandir: dude, I've got a very long list, which I'll post later and then file bugs on things that are bugs
<elmo_> I'm just asking now about things I'm not sure about
<Mithrandir> oh, ok.
<Mithrandir> eject should be on the list
<elmo_> crap how is 4pm already.  days have too few hours in them, that should be bug #2
<thom> heh
<Keybuk> yeah, I'm sure Mark would love to solve that one
<Mithrandir> could I file a bug against gcc for taking too long to compile too?
<sivang> hi jinty 
<elmo_> Kamion: do you know off hand which buildds are d-i/live buildds?  or rather which  ones aren't
<jinty> sivang: hey
<elmo_> argh, who killed esound?
<elmo_> alsa is still playing at 1.2x speed on my shinybook :(
<Kamion> elmo_: for d-i I have mcmurdo hooker ross yellow, for live I have terranova weddell adare king
<elmo_> Kamion: cool, tnx
<Kamion> elmo_: it attempts to eject the live CD just before rebooting; AFAIK it can't do it earlier than that
<elmo_> oh - it doesn't seem to have worked on the amd64 box I just tried
<elmo_> and shutdown plain didn't work on the G5
<thom> waaaaaah
<thom> apt-get source foo/warty really needs to work
<Kamion> elmo_: talk to mdz about that one, I don't know how it works
<elmo_> Kamion: yeah
<pitti> seb128: re #2251, do you think that such a browsing checkbox would be easy?
<seb128> probably yep
<sivang> seb128: where should this checkbox be? (when adding a new printer? )
<pitti> sivang: what do you think, shall we do that together?
<pitti> sivang: I think it's a relatively important usability issue, so we should do it soon (for Hoary)
<pitti> sivang: I code the backend with the conffile juggling, you do the gnome stuff?
<sivang> pitti: I am interested in doing it
<pitti> sivang: that'd be nice
<zul> lamont been around today?
<elmo_> hum. on second amd64 box, and the network is failing in a very strange way - I get destination unreachable for anything I ping - I don't THINK it's me being stupid
<elmo_> Kamion: is the live CD meant to modprobe enough for me to be able to see my disks?
<Kamion> elmo_: yes
<elmo_> ok
<Kamion> elmo_: is it not doing so?
<elmo_> nope, mptscsih wasn't auto-loaded for this IBM e325
<elmo_> it got mptbase tho
<elmo_> gar.  I'm so stupid it hurts.  of course the network doesn't work WHEN YOU'RE IN A DMZ.
<thom> *giggle*
<elmo_> is there any point in me trying ia64?
<pitti> Kamion: do you think "feature freeze" also covers things like #2251?
<pitti> Kamion: I'm currently discussing with sivang how to make CUPS network printing easier
<pitti> Kamion: it's relatively unintrusive, but it requires some UI changes and some CUPS modifications
<sivang> Kamion: we've thought about adding a checkbox to the forntend to let the user choose if he wants to listen for printer info
<pitti> sivang: btw, if we only offer "disabled" and "local network" then we should not display the radiobutton if the admin made custom settings in cupsd.conf
<pitti> sivang: i. e. if get_browsing() returns -1, just display a note "manually configured" or similar
<pitti> instead of the checkbox
<Kamion> elmo_: mptscsih is a known bug, see #6786, and also UnhotpluggedDrivers in the wiki
<sivang> pitti: right. the backend cannot cater for every possible setting :)
<elmo_> Kamion: meh, you guys keep fixing bugs before I find them - where's the fun in that?
<Kamion> pitti: I think UI changes are fine, for CUPS modifications might want to ask mdz when he gets back, I don't know much about it ...
<ogra> heh
<Kamion> elmo_: testing of ia64 would be useful, though
<elmo_> ok
<pitti> Kamion: I only want to change the conffile (you have to, to enable Browsing)
<pitti> Kamion: no code changes
<Kamion> pitti: um, can that be done without breaking the security policy?
<pitti> Kamion: but I will ask mdz anyway, of course
<pitti> Kamion: it will be disabled by default
<pitti> Kamion: that's why we need the checkbox in the first place
<pitti> Kamion: mdz quote: "...whether there is a simple way to inform the user
<pitti> that browsing is disabled, and possibly provide a checkbox to enable it (with a
<pitti> warning about the effect on security)"
<Kamion> oh, I see
<pitti> Kamion: the point is to make it easier to enable it
<pitti> Kamion: I won't allow open ports by default *grin*
<Kamion> I don't see a problem with doing that
<pitti> okay, then we can start on it, thanks
<pitti> sivang: hehe: cupsd.conf supports "Include"
<pitti> sivang: so we can put the browsing configuration into a separate file and modify just that
<sivang> pitti: yay!
<sivang> pitti: so you don't have to do loops in the air to write such a complicated backend
<pitti> sivang: right; I will modify the cups package to ship a separate browsing configuration
<pitti> sivang: and Include that in cupsd.conf
<sivang> pitti: cool
<elmo_>  |  | Linux 2.6 [9600 baud serial console]  [Live]  [Text frontend]           |  |
<elmo_>  |  | Linux 2.6 [9600 baud serial console]  [Live]                           |  |
<elmo_> what's the difference? :)
<sivang> elmo_: it's a gtk frontend now? ;-))
<elmo_> over serial console? :P
<pitti> gtk with ASCII backend
<sivang> elmo_: frame buffer maybe? 
<sivang> :))
<pitti> ascii art
<sivang> ascii art RULEZ
<pitti> mplayer -vo aa
<sivang> pitti: this is SO amazing :-)
<sivang> pitti: I dropped jaw when I first saw this _working_ on my machine.
<Kamion> elmo_: newt vs. readline-ish text
<Keybuk> mem
<Keybuk> Totem could not play 'file:///media/IAUDIO/Misc/David Bowie - I Have Not Been To Oxford Town.mp3'.
<Keybuk> Could not open resource for writing.
<Keybuk> why the frak is it trying to open it for _writing_ ?
<elmo_> Kamion: hum - 'No keyboard to configure' -> 'Installation step failed' ?
<Treenaks> Keybuk: is it opening the file for writing, or the audio device?
<sivang> hmm, cannot save files from the web in moz-ff anymore...
<Keybuk> Treenaks: well, I'm guessing the file from the message
<Treenaks> Keybuk: that'd be so wrong
<pitti> lamont: ping
<Keybuk> hmm, no; it can't open the audio device
<Keybuk> esound is broken?
<Treenaks> Keybuk: hoary switched to polypaudio afaik
<elmo_> esound got removed and replace by polypaudio :(
<Keybuk> hmm, I'm getting sound events
<Treenaks> which may or may not be b0rken
<elmo_> aiee
<Keybuk> so why doesn't polypaudio do esound-fu ?
<elmo_> I'm getting full on x prompts
<elmo_> the horror.  I'm getting Debian flashbacks. 
<zul> heh..
<elmo_> haha, whatever trick live cd does to switch to the live session (kexec?) doesn't work too well on ia64, the box just halts at that point
<Keybuk> Feb 21 17:30:27 descent polypaudio[8368] : protocol-esound.c: Warning! Too many connections (10), dropping incoming connection.
* Keybuk stares at jdun
<Keybuk> jdub too
<Keybuk> why the hell does he always recommend software that doesn't even work
<tritium> Keybuk, I get that too :(
<Keybuk> gamin and now polypaudio
<Keybuk> I'm going to add a "did jdub suggest this?  REJECT" step to tech-board deliberations I think
<pitti> Keybuk: in order to keep our jobs :-) if everything worked, we might lose it *hehe*
<pitti> just kidding
<kq> hello; my name is santiago roza and i'm a freelance writer for a latin american tech magazine.  i've been compiling a few (interesting?) suggestions, so i'm trying to contact some ubuntu developers in order to talk about them (if that's possible)
<sivang> kq: send it to the documentation list , ubuntu-doc@lists.ubuntu.com and also to ubuntu-devel@lists.ubuntu.com maybe, sounds very interesting :)
<kq> ok then; thanks a lot
<pitti> sivang, Kamion: argh, problem
<pitti> gnome-cups-manager does not run as root, only with "lpadmin"
<pitti> so the conffile snippet for browsing had to be group writeable for lpadmin
<pitti> i. e. for practically any desktop user
<pitti> and g-c-m can't restart cupsys
<T-Bone> evening
<pitti> Hi T-Bone 
<T-Bone> hi pitti
<kq> maybe i could throw some of the suggestions here, for a little pre-feedback before i face the lions...  :P
<Kamion> elmo_: keyboard> hm, what?
<Kamion> pitti: that sounds like badness
<pitti> Kamion: I don't really want to introduce a setuid wrapper for this
<Kamion> elmo_: casper uses pivot_root, which works or you'd know about it (the installer wouldn't get past init); more likely to be cloop hosage
<kq> or maybe i shouldn't, based on responses (or lack thereof)  :)
<Kamion> kq: well, in general people prefer to be asked straight out rather than to be asked for permission to ask :-) go ahead and see if anyone's up to answering
<Kamion> pitti: no, that feels wrong to me too, at least at this stage in the release
<kq> i wasn't "asking for permission to ask"... i don't know what's the deal here, so i asked if this would be the proper place to discuss that
<pitti> kq: sure, just go ahead
<Kamion> yeah, this channel's fine
<kq> well the first one might sound a little lame for experienced gnu/linux users, but i've seen a lot of people with this problem when test-driving ANY linux livecd...
<kq> the system auto-mounts all their windows partitions, but they're nowhere to be found (unless you know what you're doing, of course)
<kq> so i was thinking it wouldn't be so hard to make links to them, and place those links either on the desktop or "my pc" or any other common place
<Kamion> kq: we don't have an answer to that just yet, and dealing more nicely with Windows partitions is an open bug (right now they aren't automounted at all)
<Kamion> kq: when we do automount them, sticking links on the desktop will probably be a good idea, in particular because it avoids the hardest problems of what to call the mount points
<kq> yeah i've seen they aren't automounted, but i guessed it was on the wishlist
<kq> this other thing, i didn't know
<kq> so i suggested it
<Kamion> pitti: can gnome-volume-manager be made to deal with non-removable devices, or is there some other way to get the links onto the desktop nicely?
<pitti> Kamion: right now it's a policy decision not to mount hard disk partitions with pmount
<kq> and links to windows' "my documents" would be also nice... it's amazing how many people can't browse through their own hdd to find their documents folder
<pitti> kq, Kamion: this _can_ be changed quite easily, but we don't want to mess up hard disk partitions by default
<Kamion> pitti: yeah, absolutely
<kq> the second suggestion would be a little harder to implement imo, but still rather useful... i already talked about it with the developer of zen linux and he liked it
<dholbach> kq, another problem with it is writing on NTFS - people will want to save new files in "their documents"
<pitti> Kamion: btw, this would be the second use case for "whitelist" support
<Kamion> pitti: *nod
<Kamion> *
<pitti> Kamion: another guy asked me to add this feature to mount network block devices with pmount
<pitti> could also be used for windows partitions
<kq> yeah, but i didn't mean "mount ntfs partitions with write access by default"...
<kq> the idea was that they could _find_ their files easily
<pitti> ... which isn't possible anyway ATM...
<kq> but of course they should save them somewhere else
<pitti> kq: but that would be even more surprising
<pitti> users should read and write their documents to one dir, not two :-)
<kq> we're talking about a livecd
<kq> you boot it...
<kq> test-drive it (with your own files preferrably)
<kq> then you might choose to install it
<pitti> ah, hmm
<pitti> thus _always_ mounting win partitions read only?
<kq> that'd be my choice
<Kamion> FAT32 partitions could be mounted read-write
<kq> i'm not a coder, though... but seems like the sanest default
<pitti> yes, but then it shuoldn't be done automatically
<kq> yeah, fat should be read/write i guess
<Kamion> people often create FAT32 partitions for shared use between Windows and GNU/Linux
<pitti> I think it should be either "r/o by default" or "r/w" after explicit configuration
<elmo_> Kamion: I sent mail - that should explain the keyboard thing better
<Kamion> pitti: there's not much opportunity for explicit configuration here - it's not like you go through the partitioner
<pitti> Kamion: I mean, remove the "ro" in fstab
<kq> if it's not too hard to implement, r/w for fat and read-only for ntfs would be optimal...
<pitti> hmm, this is still screwed
<Kamion> r/w is sufficiently sane for FAT32 that we should use it by default, and NTFS should be r/o
<pitti> Kamion: if we do this in the installer, then this breaks when the user changes his partitions (or reformats them with ntfs. etc.)
<kq> it should have a nice clear "you can't write here" error message for ntfs
<kq> something like...
<pitti> Kamion: OTOH, if we do this with pmount, we had to change our pmount policy
<kq> "writing on ntfs partitions from non-windows systems is not 100% safe unless blah..."
<Kamion> pitti: that's why I was asking for some other way to put links on the desktop smoothly; TBH I think I'd rather not use pmount
<Kamion> although I suppose pmount would make the partitions user-writable, which is kind of a necessity
<Kamion> pitti: we're talking live CD here, not installer
<pitti> Kamion: I think if /etc/fstab contained user-mountable partitions, they would be displayed in Places
<pitti> Kamion: hmm, but live and installed system should behave the same
<pitti> at least that's how it should be like IMHO
<pitti> otherwise people will complain that it doesn't work in the installed system
<kq> yeap... seems like the most logical choice
<Kamion> pitti: true
<Kamion> so put them in fstab with the 'user' flag set, and let something in the desktop stack mount them on demand?
<pitti> that would work
<pitti> g-v-m should already support that
<pitti> Kamion: however, I'm still not sure that a static entry in fstab is the right thing
<pitti> this will break as soon as the partitions get changed
<Kamion> that goes for partitions selected for a given mount point in the installer, too
<Kamion> IMHO automounting should be no different to explicit selection
<kq> let me go off-topic for a couple seconds; maybe it's a stupid question (but i couldn't find the answer anywhere): was it _absolutely_ necessary to break 100% compatibility with debian (and its repositories i mean)?
<Kamion> and I think we can live with it that way; most people don't rearrange partitions every day
<Kamion> kq: yes, unfortunately
<Kamion> kq: the alternative was changing every version number of every package
<Kamion> or dropping the requirement that we build everything from source ourselves
<kq> well i'm a newbie when it comes to gnu/linux
<kq> but i've seen zen linux and it's 100% debian
<pitti> Kamion: hmm, right
<kq> although damn easy to use on boot, and very ubuntu-like in many aspects
<Kamion> kq: perhaps they have different underlying constraints; for example they might not have the same flexibility to change everything in their own repository
<kq> so i was just wondering...
<elmo_> any distro that forks packages in a non-trivial way is de facto no longer 100% compatible with Debian
<kq> and ubuntu had to fork packages in a non-trivial way because...?
<Kamion> as I understand it, Zen build straight from the Debian archive; correct me if I'm wrong
<kq> (i'm just asking; i don't know)
<kq> yeap, it was build straight from the debian archive
<Kamion> because we were doing lots of things that meant we couldn't sit around and wait for the Debian maintainer in question, we required the flexibility to make changes ourselves
<elmo_> and there's other things too, like the p4 tuning
<kq> aha... i thought debian had a huge repository, that's why i thought it was enough
<kq> but again, you're the experts  :)
<tseng> kq: not every package is changed from debian
<Kamion> ultimately if you build from the Debian archive you have to play by Debian rules for every package; that's fine for many people, but it *does* impose constraints, and with a six-month release cycle we don't have a lot of space to wait
<Kamion> so instead we compromised
<tseng> kq: as each release cycle opens things are merged from debian to ubuntu taking into account any local changes
<Kamion> we provide 'universe', which has everything in Debian, but rebuilt by us (and, in some cases - but by no means all - with Ubuntu-specific changes)
<Kamion> and we merge regularly from Debian to make sure that we don't diverge forever and either (a) miss out on bug fixes or (b) forget to send our own changes back to Debian where applicable
<Kamion> (the requirement to merge means that we have a positive incentive to send changes back, since then our merge job is simpler)
* pitti tests new kernel, brb
* lamont finally makes it to the computer
<trukulo> hi ppl
<zul> Kamion: for those hotplug bugs all you have to do is add a patch like in #6786
<zul> hey lamont...finally :)
<dholbach> wb ogra 
<ogra> hi
<mjg59> zul: We need to get some DRM stuff from Xorg into the kernel
<Kamion> zul: note that #6786 was by me ;)
<kq> thanks for the explanation, kamion
<trukulo> ogra, what about graveman in hoary? it's version 0.3.2
<trukulo> in sid otavio has 0.3.8
<Kamion> zul: I'm doing patches for the ones that represent installer regressions now
<ogra> trukulo: nah, 0.3.6
<pitti> Kamion: confirmed
<Kamion> which I think is only three drivers
<pitti> Kamion: as soon as tehre is an user-mountable vfat volume in fstab, g-v-m will automatically pick it up
<trukulo> ogra, ah, ok, my fault then
<ogra> trukulo: next week....
<pitti> Kamion: and you have it in places, Computer, and the Desktop
<trukulo> i'm uploading just now to hoary
<Kamion> pitti: oh, cool, thanks!
<trukulo> ogra, k, thanks
<kq> my second suggestion, as i was saying, would be kinda hard to implement, but i'm sure it'd be very useful
<pitti> Kamion: so in theory users would only need to setup their win partitions in the installer
<Kamion> pitti: well, I'd really like this to be taken care of automatically
<trukulo> pitti, that could be cool
<pitti> Kamion: yes, that would certainly rock :-)
<elmo_> hmm.  a big heavy metal slide door held up by a plastic tiewrap
<Kamion> pitti: I can work on that in partman-auto or partman-basicfilesystems or wherever turns out to be appropriate, now that I know what to do
<kq> from what i've seen, a significant % of livecd users don't just boot them once and install (or throw them away); on the other hand they boot a few livecds quite often
<kq> why don't they just install them?  i wouldn't know... but it happens
<pitti> Kamion: maybe vfat partitions can be pre-defined automatically in partmap
<kq> and no matter how hard you optimize it, the boot process takes time
<pitti> Kamion: then users can still tweak it, but have something to build on
<kq> enter my solution  :P
<Kamion> pitti: yeah, indeed
<lamont> zul: it's like a holiday here, you know... :-)
<zul> mjg59: what do you need
<pitti> Kamion: argh, please hold on; I forgot to specify "noauto"
<kq> since users don't change their hardware config every other day, it'd be cool if live distros could save certain autodetected data to a floppy disk, so it could be auto-read on boot (speeding up the process a lot)
<zul> oh yes its presidents day
<kq> like hardware.ubuntu, whatever.ubuntu, hardware.knoppix, etc
<pitti> Kamion: however, enabling this in g-v-m is easy, even if it does not support hd-automounting right now
<zul> Kamion: i was just thinking the advansys driver
<pitti> Kamion: that feature existed once, but Debian disabled it
<trukulo> kq, that's now new, others live-cds does it with usb-devices
<pitti> lamont: oh, you have holiday today?
<Kamion> kq: hardware detection is pretty fast nowadays; I'm not sure that the overhead of reading from a floppy disk (which, BTW, requires hardware detection before you can do it ...) wouldn't overshadow that
<lamont> pitti: yeah
<kq> i didn't mean the home directory
<pitti> lamont: darn, cyrus-sasl doesn't build
<lamont> which means I need to buy hay and such before the snow arrives tonight. :-(
<kq> not the whole home directory at least
<mjg59> zul: I'll try to sort a patch tonight
* lamont feels like he imagines drug addicts feel when their dealer disappears
<zul> mjg59: ok..
<kq> just a couple basic files
<mjg59> Is -20 out yet?
<kq> and you wouldn't need a usb device
<kq> it could be done with one by choice, but not necessarily
<Kamion> kq: to be honest I think the time would be better spent, and more effective, speeding up the existing boot process; however if somebody wanted to prototype your suggestion I don't think we'd object
<zul> mjg59: not yet..lamont is on slacking...er...holiday :)
<Kamion> kq: there is a valid use case for saving user configuration to some kind of persistent medium, though
<kq> well, the zen linux guy is gonna go for it
<mjg59> Haha
<mjg59> It'd be good to get the PPC stuff tested
<kq> so you might wanna take a look when it's done
<Kamion> Zen Linux' live CD is constructed quite differently isn't it? I don't think it uses casper
<kq> and then decide if you like it or not
<mjg59> I don't want to try pushing PPC hibernate support until I know we haven't damaged suspend to RAM
<kq> i wouldn't know about its booting architecture...
<Kamion> where is Zen's source?
<pitti> Kamion: actually, the way I tested right now (without "noauto", i. e. mounted by /etc/init.d/mountall.sh) is not exactly bad
<Kamion> pitti: it doesn't make the filesystems writable by the desktop user, though
<pitti> Kamion: but it should be umask=000 anyway, shouldn't it?
<pitti> Kamion: or do you want to restrict access to the first user who is logged in?
<Kamion> that's horribly bad for something mounted permanently
<Kamion> I want it to be mounted at login, and ideally mounted somewhere that other users can't see it
<elmo_> Kamion: why is i386 live so much smaller than the others?
<kq> i guess you'd have to ask the guy for his sources... it says it's released under the gpl, but the source is nowhere to be found
<pitti> Kamion: hmm, okay. Then let's use g-v-m for this
<Kamion> elmo_: powerpc has three times the number of modules and I guess amd64 just has fatter binaries
<Kamion> kq: hm, not exactly the right spirit :(
<kq> i know i know
<dholbach> lamont, ping
<kq> i never said it was right   :)
<lamont> pitti: I believe that simply telling oo.o-amd64 to build on ia64 should actually fix 6438 :-)
<lamont> dholbach: sup>
<lamont> ?
<pitti> lamont: you mean OO.o does work on ia64?
* mvo is away for  ~1,5h
<dholbach> lamont, could you recompile mplayer?
<elmo_> Kamion: gar, right
<kq> but i talked to him and he didn't seem like the kind of guy who'd do that... so i guess it's just a matter of bandwidth
<dholbach> lamont, i guess i'm not allowed to upload to multiverse
<lamont> pitti: I mean that the underlying libs are built on ia64, and ia64 has an ia32 emulation mode... hence....
<Kamion> somebody should correct the bit in oo.o-amd64's source that refers to ftp.no-name-yet.com, BTW
<lamont> dholbach: what exactly needs to change in mplayer?
<dholbach> lamont, it's because of libavcodec (transition)
<pitti> lamont: nice solution indeed :-)
<dholbach> lamont, just recompiling
<Kamion> kq: if he's just using Debian repositories, then the bandwidth for his source (presumably just the live CD infrastructure and the live CD -> HD installer) ought to be tiny compared to shifting lots of ISO images :-)
<lamont> dholbach: I'll add that to today/tonight's list - I want to verify that it builds first, of course...
<dholbach> lamont, i did it two weeks ago
<Kamion> kq: (I know it isn't your fault)
<dholbach> lamont, but can check too if you like
<kq> i know you know; i was just saying  :)
<kq> http://www.zenlinux.org/drupal/public/releases/ZenLinux_v1.0_Core_pkg_list.txt
<kq> package list for zen 1.0
<kq> (core... they have gnome and kde versions too)
<Kamion> elmo_: could you check /etc/yaboot.conf for video=ofonly? it should've been passed through
<kq> http://www.zenlinux.org/drupal/public/releases/ZenLinux_v1.0_Gnome_pkg_list.txt
<kq> http://www.zenlinux.org/drupal/public/releases/ZenLinux_v1.0_KDE_pkg_list.txt
<kq> no package lists for maintainance releases (up to 1.05 core)
<kq> only a changelog
<kq> http://www.zenlinux.org/drupal/?q=node/35
<Kamion> oof, those files are in a painful format for automatic comparison, dpkg -l cuts off package names
<kq> anyway... maybe it's a question of crappy low-end hardware, but on-boot detection wasn't all that fast in my experiences
<kq> so i still think preloading it from a diskette would be faster (for certain configurations of course)
<kq> and so did this guy, who seemed to have much more of an idea than i do  :)
<kq> so i guess we'll just have to wait (till zen 1.1) and see
<kq> he agreed on leaving the field open for all other live distros willing to implement/copy that feature (using per-distro names like hardware.zen, not _one_ fixed "hardware.blah" for all), which is fair i think
<kq> but you guys don't seem interested in this feature _at all_, so i'll just shut up  :)
<trukulo> kq, that's not gpl
<kq> what's not gpl?
<trukulo> obligation of credit on software
<kq> i didn't say anything about that
<trukulo> ah, sorry
<kq> maybe i didn't express myself well
<trukulo> you mean files
<trukulo> ok
<trukulo> i don't udernstand well
<kq> (english is not my primary language as you might have noticed :) )
<Kamion> we do need to speed up hardware detection, certainly; there's still a good bit of work that can be done on that easily I think
* lamont finds hay.  Now to find a truck
* zenrox hands lamont  the truck
<Kamion> the existing installation infrastructure is a fairly quick conversion of the Debian installer to hotplug, and I think there are quite a few delays that could be eliminated
<kq> can i ask some other stupid question (but only if i promise your names will be credited eternally in some tech mag you'll never read)?  :P
<kq> i can't find detailed info on the ubuntu-gnoppix issue
<kq> it's not a merge it seems
<Kamion> kq: (it's also worth noting that our main live CD guys aren't around at the moment, and haven't been throughout this conversation)
<kq> so i was wondering what it was...  :)
<kq> thanks for the notice
<sivang> pitti: hrm, just read the backlog, then how can we tackle this?
<kq> although i wouldn't know who you guys are... couldn't find a developers list, and even if i had, it wouldn't probably include irc nicknames  :)
<Kamion> gnoppix is based on Ubuntu nowadays; I'm not sure it's a merge as such but they switched over to be based on Ubuntu and contribute development effort to us
<mxpxpod> jbailey: ping
<dholbach> kq,  /whois <nick>  helps most of the time :-)
<kq> yeah i know whois; thank you  :)
<kq> and why didn't they merge?  what are they doing that you're not, or viceversa?
<kq> "doing" in a very broad sense of course
<Kamion> I honestly don't know the details; they have a different established community, so a raw merge might not have been very easy to achieve
<kq> so basically they're not merging just for the sake of having their very own distro  :P
<kq> that, and the (un)cool name  :P
<mantiena> guys, maybe someone could tell me which package should load TV card infrared module (ir-kbd-gpio or ir-kbd-i2c, see http://linux.bytesex.org/v4l2/faq.html#ir ) ? bttv module is loaded automatically, but IR module - not :( 
<kq> have you considered offering "not-so-official" isos with all that (vital) non-free stuff you probably couldn't include in main (java, flash, etc)?
<kq> offering or "facilitating"... pick a word
<trukulo> kq, it' not free software
<kq> yeah i know that
<kq> that's why i said "not-so-official"
<kq> some distros bundle that...
<trukulo> it's not legal, as i know
<kq> depends on the country
<kq> i'm damn sure it's not illegal in (let's pick a random country) argentina  :)
<kq> that's why they can't take down sites like rarewares.org
<Kamion> Canonical is a sufficiently large target to be worth suing
<Kamion> frankly I'd rather its money went into continuing to fund Ubuntu development than into legal fees
<trukulo> i prefer canonical boys working on free software
<trukulo> not in facilitating closed solutions
<kq> which offer not only source but binaries for things which are illegal somewhere else (rarewares is hosted in brazil afaik)
<kq> i didn't say "in the main package"
<Kamion> we're not hosted in Brazil, our master archive is in the UK which is not quite so lenient
<kq> i know
<kq> but ubuntu's not only uk-centered, is it?
<Kamion> we've been asked about this multiple times, and the answer has consistently been "sorry, but no"
<kq> maybe i didn't express myself corrently
<Kamion> if our systems in the datacentre are taken away by the bailiffs, you'll find that it's more UK-centred than you might like to think :-)
<kq> i wasn't asking for a version branded "ubuntu haxor"  :)
<kq> although "ubuntu warez" would sound nicer  :P
<kq> now seriously
<kq> i just meant
<Kamion> in the case of Java, we can't ship Sun Java because if we did so we wouldn't be able to ship free Java. We do have people working on improving the state of Java integration.
<Kamion> there's plenty about all this on the wiki :)
<kq> i know the reason why YOU can't
<kq> i said " offering or "facilitating"... pick a word "
<Kamion> in general, we are working on facilitating people who want to make derivatives of Ubuntu
<kq> that was my question
<Kamion> those derivatives could include pretty much whatever they want, so long as it's legal to distribute al
<Kamion> ... at all
<kq> if a 3rd party offered to bundle and host a derivative which would be illegal in the uk, but not in some other country, would you collaborate or sit around or sue them or what... that was pretty much it
<herzi> seb128: ping
<Kamion> I don't know how it would work if it were illegal in the UK but not elsewhere; that would get "interesting"
<kq> and you've already answered (very precisely indeed); thanks
<kq> well from the examples i know
<kq> there's no way to sue the source
<Kamion> but we'd have to consider that if/when it came up
<kq> i could make arrangements to make it happen; i just needed to know if you were ok with it
<kq> cause if you were gonna sue, well no freaking way i'll even try to pull my strings to get that thing done  :)
<Kamion> I can't give you an authoritative answer, and as a UK resident I would rather not get into the details of things illegal in the UK :-)
<kq> yeah i know
<kq> i wasn't requiring you to sign anything  :)
<Kamion> but Canonical wouldn't be the people with standing to sue, anyway
<kq> well, i picked the wrong word
<kq> change "sue" for "make the 'packer's life miserable"
<Kamion> in general I'm sure we'd be willing to help people who are taking use cases off our back that we can't solve ourselves; to what extent and in what circumstances would probably have to be solved case-by-case, and in any case the infrastructure isn't quite ready yet. :)
<kq> i can guarantee the source is un-sueable (that word can't exist...)
<Kamion> zul: right - I'm doing the advansys patch now
<herzi> kq: think of unbreak and any word can exist :)
<kq> by "help" i just meant "let the guy live"  :)
<Kamion> zul: would you prefer one patch per driver or a combined patch?
<kq> but no one could ever sue you for that
<zul> Kamion: one big chunk would be nice
<Kamion> zul: well, I'll send you the ones that are installer regressions now, the rest I'll worry about later
<kq> it's like... the faac or lame or xvid teams offering the source
<zul> Kamion, ok
<kq> and some other guys taking care of the not-so-legal parts, like compiling it and offering the binaries
<kq> not the same scenario... but just an example
<kq> i'll just make sure they don't brand it "ubuntu uber-warez linux" and that should do  :)
<kq> but from what i've seen, many distros include not-so-legal stuff
<Kamion> basically, we can't stop you *shrug*
<kq> i played a couple mp3 with some test version of hoary... you guys are gangstas  :P
<lamont> dholbach: /usr/lib/libavcodec.a(oggvorbis.o)(.text+0x46): In function `oggvorbis_encode_init':
<lamont> : undefined reference to `vorbis_encode_init'
<lamont> that's what I get...
<trukulo> kq, there are no software patents in europe
<trukulo> nor in uk
<trukulo> by extension
<kq> yes i am aware of that, thanks anyway
<kq> but mp3 is licensed, not only patented
<trukulo> at the moment
<kq> at the moment... as long as poland keeps saving our ass  :)
<trukulo> but players with reversed ingeniery are allowed in europe
<trukulo> not only poland
<kq> yeah i know
<trukulo> spain, i.e. are aginst them too
<kq> but they were the ones with the kodak-moment save  :)
<trukulo> txo times, indeed
<trukulo> teo times, i mean
<trukulo> s/teo/two
<dholbach> lamont, oh damn :-/
<kq> i even wrote an editorial about that... but my audience is mostly newbies, thank god none of you will ever read that   :)
<zul> depends on the article and if its in english :)
<kq> it's in spanish and i wouldn't bother myself if i were you... it's for a completely different audience
<kq> (but someone has to do it... i'd rather dumb stuff down as much as needed, than keep it completely away from the masses)
<kq> anyway... miguel de icaza liked the one about him, so bite me  :P
<Kamion> lamont: are you doing the oo.o-amd64/ia64 thing, or leaving it to somebody else?
<herzi> dholbach: haste mal ne minute fuer mich?
<dholbach> herzi, bin grad am telefon - 10 minuten
<herzi> k
<kq> please don't... or the uninvited guest will start with the spanish, and you'll all ask for redemption  :P
<trukulo> kq, let them work
<kq> well i didn't think that'd be taken seriously...
<kq> since you've been spoiling me so far, i'm gonna add yet another stupid question...
<lamont> Kamion: I'm backed up behind kernel stuff - hoping someone else will care enough to do it.
<kq> the recent hype about ubuntu is just amazing, and i wondered if you could explain the reasons to a certain extent, or just think "it happened"
<dilinger> lamont: oh, if that was the case, my life would be so much easier :P
<kq> i already know it's a great distro, btw  :)
<sivang> pitti: I have two init.d entries for postgres, should there be only one? I have postgresql and postgresql-7.4 
<seb128> herzi: pong
<herzi> seb128: can you take a quick look at 4079?
<lamont> right.   off to get hay.  bbiab
<seb128> herzi: sure
<kq> but... it's apt-based (while rpm was the choice for lsb), gnome-based (while everyone seemed to be loving kde), it breaks debian compatibility (although you already taught me it was absolutely necessari), and it doesn't auto-mount windows partitions...
<kq> *necessary
<kq> so i was wondering if maybe there was a reason for all this hype, maybe some technical reason beyond my reach
<trukulo> kq, maybe lol
<Kamion> it doesn't really break Debian compatibility in the ways that actually count; sure, you can't use Debian repositories, but universe exists so that you don't need to
<kq> tha'ts why i'm asking the experts  :)
<seb128> herzi: we use 0ubuntu1 as version to not conflict with debian -1
<kq> i'm not complaining about the debian thing... i already said i was a newbie
<Kamion> and you can use third-party repositories that were created for use with Debian
<kq> i was just pointing out (arguable) issues
<herzi> seb128: is there a document in the wiki with answers to my questions?
<seb128> herzi: what questions ?
<herzi> how to get packages into ubuntu
<dholbach> herzi, what's up?
<trukulo> helix, how to contribute?
<trukulo> i mean, herzi, not helix
<herzi> trukulo: yepp
* kq said: so i was wondering if maybe there was a reason for all this hype, maybe some technical reason beyond my reach
<seb128> herzi: you want to maintain it in universe ?
<dholbach> herzi, wiki/MOTU is the way to go :-)
<seb128> herzi: http://www.ubuntulinux.org/wiki/MOTURecruitment/
<zul> herzi, or #ubuntu-motu
<Kamion> kq: I could probably come up with lots of reasons, but just consider based on your own arguments: if everybody else is doing RPM and KDE (which wasn't really the case, actually, but let's pretend it was for the moment), then wouldn't that mean that that market was too saturated to allow another player to gain any useful share?
<kq> i'm not trying to start an argument; sorry if i wasn't clear
<Kamion> nor am I, but I think my point is valid :) there was a gaping hole waiting for us to step into it
<kq> i'm just trying to get answers from people who knows (an awful lot) more than i do
<kq> i may be a newbie, but i'd take apt over rpm and gnome over kde any day...
<seb128> herzi: the package looks good. for the copyright you should copy the text (ie: /usr/share/debhelper/dh_make/licenses/gpl) and the cdbs rules is enough :)
<kq> and i never said everyone was using rpm and kde
<kq> i just said rpm was chosen as the standard package format for lsb...
<Kamion> well then, you're a perfect example of why there was a niche open. :)
<kq> so that could be it?  you guys came up with a very good and (reasonably) easy-to-use debian-based apt + gnome distro...
<Kamion> there's a common misconception that LSB mandates that compliant distros have to use RPM themselves - it never did, it just said they had to support RPM. From some points of view it makes sense for them to pick the least capable of the popular formats, so that everyone could support it
<Kamion> kq: that was certainly the intention, yes :)
<Kamion> giving CDs away can't have hurt either, but there was a fair bit of buzz before we started doing that
<kq> that was certainly the intention... ok so i'm a newbie but i'm kinda getting it, finally  :P
<kq> imho the marketing/pr role of the ubuntu "people" is great, and a key factor too... but that's just my opinion
<kq> *marketing/pr performance
<Kamion> I think also we were the first big Debian derivative to actually work with lots of Debian developers
<Kamion> I mean, be worked on by
<pitti> sivang: hmm, that should only be postgresql-7.4
<pitti> sivang: the old "dpkg does not delete conffiles" bug
<pitti> sivang: thanks, I'll fix this
<sivang> pitti: so another bug for the upgrade path?
<kq> and there's the technical reason a newbie could never come up with... there's a reason why i was asking  :)
<sivang> pitti: yay cool, happy to be of service for this wonderful pkgs :)
<pitti> sivang: it does not do any harm, but it should be cleaned up
<pitti> sivang: re gcm, I have no idea
<sivang> pitti: :-/
<Kamion> kq: I'm not sure it's *entirely* a technical reason :)
<kq> yeah, well, "technical"... not the word
<kq> "unavailable for the uninitiate"...?  :)
<kq> browsing through "debian's women"... man i wanna marry hanna wallach  :P
<kq> anyway, now seriously
<kq> if i know this app i'm sure you know it aswell (and better)... do you plan to bundle gparted in ubuntu, by default?
<kq> cause i noticed a disappointing lack of partition management tools in linux livecds
<dredg> apt-cache says: gparted - partition editor for GNOME
<kq> and gparted delivers (unlike some others)
<kq> partition magic replacement is yet another cool use for a livecd i guess
<Kamion> I think gparted's probably a good thing to promote to main post-hoary
<kq> why _post_ hoary (pardon me)?
<kq> would it be hard to add or something?
<Kamion> we're way, way past the deadline for adding major stuff to hoary
<kq> my spider-sense tells me i won't get much love in this channel  :P
<kq> but seriously, i don't wanna be a nag
<Kamion> you're not, I'm just giving the facts :)
<Kamion> the only way to do a six-month release schedule is to be really hard-arsed about deadlines :-)
<kq> i'm just (really really) interested in ubuntu's development, not trying to bother anyone with stupid questions and/or requests...
<kq> btw, what does "ubuntu" mean?  :P
<Kamion> it's a perfectly reasonable question; you might like to check http://www.ubuntulinux.org/wiki/HoaryReleaseSchedule
<kq> (just kidding; don't shoot)
<Kamion> we may well (ab)use the gparted widgets somehow once we do a graphical installer
<kq> yeah but i meant in addition to the install version
<kq> remember i'm into the livecd  :)
<Kamion> sure, I know; it would reach the normal distribution first, if anything
<kq> as a matter of fact i'd like to see them become one
<Kamion> (since the installer piece is much harder to do)
<kq> but i guess it's a major pain
<Kamion> they're very close to one :)
<Kamion> that was what the rearchitecture of the live CD for hoary was all about
<Kamion> we use the first half of the installer to bring up a system that's a literal Ubuntu desktop installation plus a very few extra selected packages
<kq> but i'ma have to talk to the livecd guys to get them to buy into my floppy-configs idea  :P
<Kamion> anyway, gotta go to karate, back in 2 hours
<kq> good luck, and thanks for all
<kq> not just the answerss
<kq> *answers
<kq> mostly for ubuntu; that's a slightly bigger contribution to the world than answering my questions  :)
<kq> damn, who will i bother now...?  :P
<kq> could anyone please tell me who're the guys (mostly) in charge of the livecd part (autodetection, booting, etc) of ubuntu, and when could i find them here (that, considering they hang out here)...?
<amu> kq: what's about, write your idea's to the wiki? http://www.ubuntulinux.org/wiki/LiveCD/
<dholbach> does anyone have the time to explain briefly how to generate patches used in a cdbs--tarball--simple-patchsys---environment?
<jbailey> dholbach: What I usually do is get the tarball unpacked and the current patches applied.  Copy the file to a .old version.  Make the diff from in the root of the build-tree and stuff it into debian/patches in a numbered form to preserve sort order.
<dholbach> jbailey, thanks... i'll try your explanations :-)
<jbailey> dholbach: np.  Ping here again if you need more help.
<dholbach> jbailey, right
<dholbach> jbailey, thank you VERY much - it worked *WOOHOO!*
<zul> later bbl
<kq> amu: thanks a lot (took me a while to answer; i was at some other thing), but i'd rather talk to them personally... it's much easier to agree that way
<amu> kq: the better way, write down your idea's, place it to the wiki, point the people to there, also tell others ( in the mailling list ) about it. Otherwise you've to wait weeks/month someone has time to listen your idea. Ex. i missed them
<kq> yeah you're write
<kq> *right
<kq> it's just that i've been contributing to much smaller projects, and i must have gotten used to that way
* T-Bone sees elmo's mail, never thought of booting a Live CD in serial console. Funny :)
<Kamion> lamont: hope #6681 is in time for today(?)'s kernel upload
<lamont> Kamion: so far, everything is. :-)
<lamont> today is probably late late tonight
<Kamion> ah, right
<Kamion> I've checked how modules.pcimap looks after that patch and the mptscsih one; looks OK to me
<Kamion> lamont: I guess somebody without an ia64 wouldn't be much use at doing the oo.o-amd64 thing?
<Kamion> I *could* just do it, but it's a big mirror hit if I get it wrong ...
<lamont> Kamion: my mirror is almost kinda current - I figure I'll add it to my list after the kernel upload
<Kamion> ok, I think it'd be a really big step to convincing everyone that ia64 is releaseable
<lamont> mjg59: you around?
<mjg59> lamont: Yo
<ogra> 00
<ogra> ######################+
<dholbach> i guess that was the new cat :-)
<Kamion> ajmitch: http://people.ubuntu.com/~lamont/buildLogs/m/muine/0.8.2-4ubuntu1/muine_0.8.2-4ubuntu1_20050219-0137-i386-failed
<Kamion> ajmitch: should muine build-dep on libgtk-cil rather than libgtk2.0-cil?
<ogra> oops, sorry...my ne housemate
<dholbach> haha
* dholbach knew it
<ogra> s/ne/new
<ajmitch> Kamion: no
<ajmitch> Kamion: I've uploaded gtk-sharp-unstable
<ajmitch> but it hasn't appeared yet
<lamont> ajmitch: new?
<ari> how come GIMP is listed on the bounties page under Python scripting projects?
<ajmitch> lamont: yep
<sivang> ari: because there is a wish to create a DOM spec that would allow programs such as gimp and the other listed there to be used from one std. and agreed API common to all of them , I think
<ari> ah.
<sivang> ari: sorry, that would allow scripting those programs from one coherent api
<Kamion> ajmitch: ah, ok
<lamont> Kamion: is the patch for 6681 stolen from head, or is it our own?
<Kamion> lamont: I wrote it today
<lamont> cool
<lamont> i386 patch, yes?
<lamont> Kamion: added
<lamont> Kamion:  you know that -20 is unlikely to finish building everywhere before the daily build tomorrow morning, yes?
<ajmitch> bbl
<lamont> Kamion: thoughts on 6786?
<Kamion> lamont: that's ok; it changes ABI anyway, right?
<Kamion> lamont: #6786 is pretty much the same thing, I wrote that patch today too
<lamont> yeah - abi bump in -20
<Kamion> ok, so I need to rev debian-installer for that anyhow
<zul> hey
#ubuntu-devel 2005-03-05
<Kamion> evening zul
<zul> hey kamion how is it going?
<Kamion> not bad, did that advansys/fdomain/qlogicisp hotplug patch, and I think that's enough kernel stuff for me for one day
<zul> ok its going into -20
<T-Bone> Kamion: how does it look for mptscsih? :)
<Kamion> T-Bone: done, see #6786
<Kamion> well, not uploaded yet
<Kamion> the patch seems to do the right thing and willy was ok with the general idea
<T-Bone> cool!
<T-Bone> i hope it doesn't make mptbase sad tho :)
<Kamion> T-Bone: I pulled out the relevant bit of pci.agent and ran it by hand over the modules.pcimap file produced by a test build; it seemed to do the right thing
<T-Bone> awesome
<T-Bone> btw kudos for having willy to settle that quickly :)
<Kamion> I figured the easiest way to sort it out was to just talk to him :)
<T-Bone> indeed :)
<Kamion> anyhow, we'll see how it goes
* sivang --> food
<lamont> In file included from ../../k3dsdk/glutility.h:5,
<lamont>                  from paraboloid.cpp:29:
<lamont> ../../k3dsdk/glutility_private.h:40:2: warning: #warning Since you are the bigshot owner of a 64 bit machine, please consider contributing a better implementation for the following functions
* lamont cackles
<T-Bone> bwahahaha :)
<dopeman> hi you dudes
<dopeman> i d like some advice on debian
<dopeman> (someone hey)
<zul> dopeman: this is a #ubuntu development channel you might want to try #debian or even #ubuntuy
<zul> #ubuntu even
<dopeman> ok
<dholbach> good night everyone... 
<dopeman> ubuntu is debian related ?
<dopeman> am i wrong ?
<zul> yes but your question if off-topic for this channel
<Kamion> well, it might be clearer if we heard what the question was :)
<Kamion> night folks
<Mithrandir> night, Kamion
<zul> toodles Kamion 
<mdz> Kamion: here?
<mjg59> daniels: Oh, lord, there's huge gobs of difference between the xorg DRM and the stuff in the kernel
<daniels> mjg59: YOU WIN!!!
<zul> mdz: i think he just left
<daniels> mdz: welcome back
<mdz> daniels: I'm not back yet :-)
<mdz> apparently the live CD has seriously bitrotted in my absence
<mjg59> Oh, christ. WHITESPACE DIFFS.
<daniels> heh
<mjg59> ARGH NO MAKE THE PAIN GO AWAY
<daniels> mjg59: diff -w
<mjg59> daniels: Executive summary - we're fucked.
<mjg59> Unless someone can get a patch against the kernel code
<zul> hmmm?
<mjg59> zul: There are three sets of DRM code. The one in the kernel, the one from dri.freedesktop.org and the one from xorg.freedesktop.org
<mjg59> The latter bears little resemblance to either of the former. Sadly, it's the latter that has the support for making 3D work after suspend/resume on Intel graphics hardware.
<daniels> mjg59: i believe the stuff in the kernel should pretty much parallel dri.fd.o/drm
<mjg59> daniels: Yeah, it just lags behind a bit
<lupusBE> daniels, xproto is that available in hoary?
<lupusBE> if so in which package?
<mjg59> daniels: Any ideas about how to proceed?
<daniels> mjg59: kick dave airlie (airlied/#freedesktop), ask him what the changes were between the stuff in extras/drm and dri.fd.o/drm, and then just work with that and see if you can get the power management delta applied with that in mind
<daniels> lupusBE: xproto.pc is not available
<lupusBE> how come it is not packaged? I'm building xcb for fun :)
<daniels> lupusBE: because the modular xlibs are not packaged
<lupusBE> ic
<daniels> lupusBE: if you're building xcb, you probably want to start at the bottom of xlibs
<daniels> it won't be very exciting for you
<mjg59> I wish CVS had the concept of changesets
<Clint> I wish cscvs were maintained
<dilinger> i wish something like baz would become as ubiquitous as cvs
<mjg59> daniels: On the bright side, the DRM diffs for the PM look fairly small
<mjg59> Hrm. To  be brutally honest, I'm having trouble finding where the DRM code changes actually *are*
<lupusBE> daniels, are there still problems with xcb (why it is not enabled in ubuntu?)
<mjg59> Ah! Almost all the change is in the dri stuff, the DRM module just needs to flag that it does the right thing...
<daniels> mjg59: heh
<daniels> mjg59: probably, yeah
<daniels> lupusBE: it's not ready yet.  doesn't support everything.
<lupusBE> I thought xcb add the moment was more like a extension
<lupusBE> then a real replacement
<daniels> no, xcb is a total replacement.  the entire point of xcb is that it's an alternative to xlib, and when you build xlib with xcb support as a wrapper, xcb replaces its entire transport layer.
<daniels> it's nothing cool or fun, seriously.  the only difference you'll notice is that some stuff might break.
<lupusBE> k :)
<lupusBE> s/add/at/ damn my english is bad somtimes
<mjg59> Argh. Where's drm_drv.h gone?
<mjg59> Ah. It's been merged into drm_drv.c. OBVIOUSLY.
<mjg59> daniels: I've got a 17K patch that doesn't apply in the slightest
<mjg59> But is probably fairly easily mergable
<daniels> mjg59: cool.  i think the changes were mainly to core drm stuff rather than the i915 module
<mjg59> Yeah.
<mjg59> So, do I get to make it your problem now? :)
<daniels> mjg59: sure, it's easy -- just present me with a 17kB patch that applies and works. :)
<mjg59> Argle.
<daniels> at that point, I'm happy to adopt it as my problem
<mjg59> I have no idea where the fuck half this code went
* mjg59 screams
<mjg59> IT'S BEEN ENTIRELY REWRITTEN
<mjg59> Ok, I'm starting to get a handle on this
<zul> mako: ping
<zul> mako: willy has signed my key
<daniels> oh my god, are these guys for real?
<daniels> afaict, evdev does not generate separate buttonpress and button release events
<daniels> (for the mouse)
<mjg59> daniels: This stuff is all crack. I may just see if I can hack in the i915 stuff and ignore the generalised PM support.
<daniels> heh :)
<daniels> mjg59: go poke dave airlie
<daniels> mjg59: he's online at the moment
<marcin_ant> hi guys - I'm looking for Apache Tomcat packages for ubuntu. Could you help me and tell if they are available somewhere?
<daniels> mjg59: he's also your countryman
<lamont> daniels: you around?
<daniels> no
<lamont> heh.  getting ready to play with a kernel upload (abi bump) - the question is your preference: should I fix lrm, or let you have the hotseat later tonight?
<daniels> if you want to fix lrm, that would be fantastic; also if CONFIG_DRM=m could get back in (aiui it isn't)
<lamont> is here... I think that went into -19
<daniels> ah, awesome, thanks
<lamont> linux-source-2.6.10 (2.6.10-19) hoary; urgency=low
<lamont>   * Build drm as module:
<lamont>     - DRM=m.
<daniels> rad
<lamont> Kamion: if there are multiple ethernet interfaces, but only one has link, that one should just be the default, no?
<zul> night
<marcin_ant> where can I find "broken packages"?
<marcin_ant> I need apache tomcat - I know that it is not buildable currently
<marcin_ant> but I would like to take a look and try to find if I'll be able to fix it
<HiddenWolf> Matt zimmerman is a ubuntu guy too, right?
<jdub> HiddenWolf: mdz, head of the distro team.
<HiddenWolf> jdub: thanks
<marcin_ant> jdub: hi!
<marcin_ant> jdub: maybe you know if Apache Tomcat packages are available somewhere?
<jdub> nup, no idea
<marcin_ant> jdub: someone here gave me link to build logs... 
<marcin_ant> jdub: and there was only log with some errors
<jdub> http://people.ubuntulinux.org/~lamont/buildLogs/
<marcin_ant> jdub: exactly
<marcin_ant> jdub: but there is only log
<marcin_ant> jdub: maybe you know where can I download source?
<jdub> in the repositories
<jdub> if it's in the build logs, it's in the repos
<marcin_ant> you mean apt-get source tomcat4? 
<jdub> yes
<marcin_ant> heh :)
<marcin_ant> sometimes it's hard to get really easy solution :)
<marcin_ant> thanks :)
<dilinger> herbert xu is doing kernel security updates for warty?
<lamont> dilinger: I believe so
* lamont pokes smurfix 
<lamont> or maybe Kamion 
<lamont> hrm.. looks like really smurfix
<daniels> lamont: keyboard selector?
<lamont> cdebconf
<lamont> daniels: so for the abi roll in lrm...
<daniels> yeah ...
<daniels> ok
<daniels> so bump everything in control
<lamont> I change the minor versions in debian/rules, and the Depends/package names in control?
<daniels> bump all the udebs in debian/d-i
<daniels> change the minor versions
<daniels> ... profit!
<lamont> just debian/d-i/kernel-versions, yes?
<daniels> yeah
<lamont> daniels: so why does nvidiaminor not have an _ like all the others???
<lamont> *whap*
<daniels> lamont: i dunno
<lamont> you wanna review my changes before I upload?
<lamont> back in a minute or so - need to reboot the router
<daniels> lamont: sure
<lamont> mdz: home again?
<lamont> daniels: diff mailed
<daniels> lamont: thanks
<lamont> just waiting for the kernel build to finish
* lamont wants to build successfully on at least i386...
<CtrlPhrek> anyone installed on a dell inspiron 1150 yet? :)
<mdz> lamont: not yet
<lamont>   kdelibs-data: Depends: gnome-menus but it is not going to be installed
* lamont giggles
<jdub> morning mdz 
* lamont grumbles at the circular build-dep loop involving gnome, dbus, and kde
* lamont waits for the kernel to finish building, so that he can sleep
<HiddenWolf> lamont, that kernel will build no faster if you stay awake to encourage it
<daniels> a watched kernel never compiles
* HiddenWolf should sleep aswell
<lamont> well, if I stall another 33 minutes, then (1) 4/5 i386 kernels will probably be done, and (2) I can flat guarantee that the new kernel will not show up in the daily builds at all
<lamont> these are both _good_ things
<HiddenWolf> lamont: how is delaying the goodness a good thing? :-)
<HiddenWolf> unless you're sure it's broken. :-P
<lamont> because Kamion  needs to bump d-i as well.
<lamont> so the daily builds would definitely be broken if I managed to get it into the archive
<lamont> then again, if I just wait another 2 minutes or so, then the source will be there in time, but the binaries won't
* HiddenWolf thinks that warrants calling kamion in the middle of the night and raise hell. 
<lamont> nah - is planned
* HiddenWolf just likes to raise hell
<daniels> lamont: if you wanted to do l-r-m-2.6.11 while you were at it ... ;)
<HiddenWolf> Anyhow, I've been destructive enough. Bought more cd's over amazon tonight then I did in the last few years. Need to be off. :)
<lamont> daniels: not really
<lamont> daniels: but the patch looked good to you?
* HiddenWolf goes off
<daniels> lamont: email hasn't been arriving today :(
<daniels> i trust your skillz tho
<lamont> daniels: daniel.stone@ubuntu.com, yes?
<daniels> lamont: yeah, but nothing's been getting through for the last few hours
<lamont> bummer
<da_bon_bon> OOo2.0-devel hangs while creating pdf files ?
<bluefoxicy> bluefox@icebox:~$ esd --help
<bluefoxicy> polypaudio esd wrapper 0.7
<bluefoxicy> bluefox@icebox:~$ esd -d /dev/dsp -unix
<bluefoxicy> main.c: read() failed: No such file or directory
<bluefoxicy> known bug yet?
<lamont> daniels: so you have no objections to the kernel being uploaded, yes?
<daniels> lamont: none whatsoever
<lamont> Kamion hasn't given a green light, but seemed to be assuming that it would upload... so I'm gonna consider that "green"?
<lamont> s/?$//
<lamont> the demo CD got all warm fuzzy and all that then?
* lamont upload
<lamont> s
<daniels> lamont: yah :)
* lamont sleeps
<sivang> Mortning all
<sivang> any known problem with the apache2 package in main? seems to give me nothinig after I install it
<sivang> using the /etc/init.d/apache2 script to start/stop it doesn't yield any reasonable results.
<daniels> have a look in /etc/default/apache2
<sivang> daniels:  ah ok, I may have missing some config options needed there?
<sivang> daniels: thanks alot, this was the one I was looking for. Is this somekind of security thing? not having it enable by default?
* sivang --> breakfast.
<daniels> sivang: it was more for install compatibility with a1, i think
<smurfix> lamont: ?
<smurfix> Ah, autoconf. Sigh. Forgot it again. :-(
<amu> moins 
<sivang> daniels: ah ok, should probably be added to the after the install or something, or into the README.Debian
<sivang> daniels: I mean - a message about it etc.
<sivang> moins amu 
<amu> hey sivang
<dholbach> good morning
<sivang> moring dholbach 
<dholbach> hello sivan!
<dholbach> already here or still here?
<sivang> dholbach: already here, trying to switch back to GMT
<sivang> :)
<dholbach> sounds like a good plan :-)
<amu> someone has also problmens with booting the daily live? 
<zenrox> spammer in #ubuntu
<Kamion> morning folks
<Kamion> hm, I wonder what mdz meant about the live CD having bitrotted; the last one I tried was fine
<Mithrandir> hi Colin
<Kamion> ah, he sent mail
<Kamion> hey Tollef
<daniels> yo tollef, colin
<Treenaks> Anyone coming to FOSDEM this weekend? :)
* dholbach won't :-(
<Mithrandir> I am
<dholbach> hai d3vic3 
<d3vic3> lo dholbach 
<Mithrandir> daniels: hmm, I think I was going to ask you something about fd.o, but I've forgotten now. :/
<daniels> Mithrandir: word
<pitti> Morning
<daniels> morning pitti
<dholbach> hi pitti
<Mithrandir> I guess it'll come about and I can just ask you then. (:
<daniels> heh
<Kamion> amu: what's the problem?
<amu> it wont boot, insert the CD, nothing happen
<amu> +ed
<Kamion> I'm just rsyncing live/i386 now
<dholbach> morning mvo :-)
<mvo> hi dholbach, morning all
<amu> Kamion: i'll try later with another (new) blank media, tried with 2005-02-21 09:03 hoary-live-i386.iso
<daniels> unfortunately I'm fresh out of blank media
<amu> moins mvo, you lost a "_" in your nick :)
<dholbach> amu, yes, celebrate! :-)
<mvo> amu: it's my nick now :) I had to pay the other "mvo" beer to get it, but we settled it now
<dholbach> he had to duel the other mvo :-)
<dholbach> oh mvo: my story was far more exciting ;-)
<Kamion> lamont: the linux-source-2.6.10 .dsc looks totally broken
<Kamion>  linux-headers-2.6.10-3 - Header files related to Linux kernel version 2.6.10
<Kamion>  linux-headers2.6.10-4-386 - Linux kernel headers 2.6.10 on 386
<mvo> dholbach: I'm a shy person, I didn't wanted to tell all the bloody details
<dholbach> hehe :-)
<Kamion> any kernel team types around, or shall I upload to fix that?
* Kamion takes silence as consent ...
<Mithrandir> Kamion: just upload.
<Mithrandir> Kamion: I'm just amd64 porter kernel guy, but still. :P
<Kamion> on its way
<Treenaks> Mithrandir: you're no longer a czar? :P
<dholbach> hi dredg 
<Mithrandir> Treenaks: of course I'm the AMD64 czar as well, but that wasn't so relevant in this context.
<dredg> lo dholbach 
<Treenaks> Mithrandir: isn't kernel porting part of the czar's responsibilities? :)
<Mithrandir> I'm not sure. ;)
<Kamion> surely delegating kernel porting is part of the czar's responsibilities ... :)
<Mithrandir> I just need to acquire some subjects I can delegate to. :)
<Mithrandir> but now, breakfast
<pitti> Hey, ppc sleep patches in latest Hoary kernel
<pitti> THAAAANKS lamont
<sivang> Morning pitti !
<pitti> Hi sivang 
* sivang is attempting switching back to GTM :)
<sivang> s/GTM/GMT/
<pitti> sivang: btw, I think I finally know how we tackle gcm
<sivang> pitti: yay, am all ears.
<pitti> sivang: instead of providing two C functions, I will provide two programs
<pitti> sivang: cupsys-enable-browsing and cupsys-get-browsing
<pitti> sivang: the former has to be called with gksudo
<pitti> sivang: thus you spawn a gksudo cupsys-enable-browsing $enable in g-c-m
<sivang> pitti: hmm, sounds pretty cool :)
<pitti> sivang: so we don't need weak permissions on the conffile
<sivang> pitti: yes
<pitti> sivang: and in addition I don't need to write the conffile juggling in C
<pitti> but can use e.g. python
<sivang> pitti: rock
<pitti> sivang: so please write your interface in a way that you encapsulate the program calls in two central functions
<sivang> pitti: could you remind me the limitation which suggested you need to write the juggeling in C ?
<pitti> sivang: so we can exchange the backend interface with relatively little effort
<pitti> sivang: initially I wanted to make the code part of libgnomecupsui
<sivang> pitti: ahh
<pitti> sivang: but since we don't want to run g-c-m with root privs, we now call an external program
<pitti> sivang: and with gksudo we don't need setuid
<pitti> Kamion: ^ would that work for you?
<sivang> pitti: would probably be better to seperate it to an external programs anyways, to enable pulginability
<pitti> Kamion: calling a cupsys wrapper over gksudo?
<pitti> sivang: the additional scripts will be part of cupsys
<pitti> sivang: since cupsys does not need to be installed, please check for the existance of these scripts
<sivang> pitti: part of the ubutnu pkgs that is, not upstream right?
<pitti> sivang: if they aren't present, don't display the stuff
<pitti> sivang: yes, Ubuntu specific (maybe Debian adopts it)
<sivang> pitti: ok
<Kamion> lamont: I think you could lose minipatch.diff from the source package
<Kamion> pitti: sounds reasonable
<pitti> ok
<sivang> pitti: I'm puzzled by the fact that cupsys need not be installed in order to have gcm
<seb128> grrrr inotify
<pitti> sivang: well, cupsys-client should be enough to add printers
<pitti> seb128: boot with "noinotify"
<pitti> seb128: and watch all the gnome hotplug stuff get working again :-)
<sivang> pitti: ok
<seb128> pitti: I've restarted with noinotify yep
<Kamion> lamont: might wanna kill the .svn directories in debian/d-i/hppa/modules/
<trukulo> daniels, u there?
<trukulo> only one question
<rburton> daniels: ping?
<trukulo> fabbione, ping
<pitti> trukulo: fabbione is on holiday
<dholbach> bbl
<pitti> sivang: I appended the spec to #2251
<pitti> sivang: please review it again
<trukulo> pitti, ah, thanks for info
<sivang> pitti: ok, onto it now
<Kamion> amu: today's daily-live i386 image boots fine for me
<sivang> pitti: looks pretty good
<sivang> pitti: I'll investigate where this can be integrated in the gui
<amu> Kamion: thx, i'm also syncing now
<Kamion> (as did yesterday's)
<stockholm> elmo: awake?
<dholbach> re
<ogra> moin
<Kamion> daniels: safe for me to upload stuff like base-config yet?
<Mitario> morning
<rburton> when i tried the LWE livecd i had display corruption (looked like every other row was offset) on nvidia, is this a known/fixed problem?
<mvo> hi Mitario 
<amu> rburton: it's fixed in ubuntu's live
<rburton> amu: ah cool
<rburton> Kamion: did you manage to try and find the wireless network bug?
<rburton> Kamion: note that it worked for me with LWE's live cd from 17/2
<stockholm> when does elmo get up, normally?
<stockholm> or rather: when is he available?
<amu> rburton: tested some minutes ago, live from yesterday, with a ipw2200, my card is detected, but not configured
<amu> daniels: Kamion: problem with german lan is still there :) i choose german, got a pc104 with us layout 
<sivang> stockholm: should be here in sometime I think, he usually follows GMT daytime IIRC
<sivang> stockholm: what do you need?
<sivang> stockholm: speaking of the devil :-)
<stockholm> sivang: (c:
<Kamion> rburton: thought I said I'd fixed it
<rburton> Kamion: ah, must have missed that
<rburton> i'll rsync and try
<Kamion> cool, thanks
<rburton> i wish firewire support didn't suck in linux
<elmo_> Kamion: /etc/yaboot.conf from where?
<elmo_> Kamion: neither first nor second stage seem to have one
<Kamion> elmo_: second stage. uh, how do you boot a Mac without /etc/yaboot.conf?
<elmo_> it's live?
<Kamion> oh
<Kamion> hmm
* elmo_ points to first word of subject in mail kamion was replying to ;-)
<Kamion> d'oh
<Kamion> elmo_: well, we only pivot, we don't exec a new kernel, so the kernel should still have that argument
<Kamion> so I don't know what that could be ...
<elmo_> hmm.  ok.  and yeah, I realised now the command line argument thing is crack as the console is fine up until X starts
<elmo_> heh, stracing eject is neat and all, but afterwards things like less don't work anymore, making it not entirely useful :)
<Xof> reset / stty sane?
<elmo_> Xof: hmm? no, the point is, I'm running of a live CD and I just ejected the CD, so any further attempts to run stuff just gives me IO errors :)
<Xof> oh, fair enough
<Xof> that's a rather more fundamental problem
<HiddenWolf> XoF: you're kidding. :-P
<pitti> sivang: my scripts work
<pitti> sivang: now I'll package that stuff
<HiddenWolf> Will mdz be around?
<elmo_> hum.  is xresprobe meant to get things completely wrong with a KVM?
<pitti> HiddenWolf: he's on vacation
<Kamion> mdz's on holiday, he'll be back at some point I'm sure
<elmo_> completely wrong to the extent of calling and LCD a CRT etc.
<elmo_> s/and/an/
<Kamion> elmo_: strace> mount a tmpfs first and put the stuff you need there
* HiddenWolf will suffer in silence
<elmo_> Kamion: I just ran lftp before running the eject; that got it in the kernel memory
<elmo_> Kamion: people.ubuntu.com/~james/paste/eject-strace.txt - if you care; I'll put it in a bug later
<daniels> Kamion: go nuts
<daniels> amu: yeah
<daniels> rburton: pong
<Kamion> whoa, while tmpfs is cool, running a kernel build in one and hosing your laptop due to thrashing is less cool
<Kamion> especially because that stupid patch-series system wants ALL YOUR INODES
<HiddenWolf> kamion: if it doesn't smoke, it's not broken.
<rburton> daniels: too late. i was asking about nv display corruption on the LWE livecd, but i hear its been fixed already
<Kamion> ioctl(3, CDROMEJECT, 0x24000442)        = -1 EIO (Input/output error)
<Kamion> elmo_: does ejecting the CD in software normally work on that box?
<Kamion> thankfully Macs still have a three-finger salute
<pitti> Kamion: Ctrl+Apple+Power Button?
<Kamion> yes
<pitti> :-)
<pitti> Kamion: however, ctrl+alt+del works for me, too
<Kamion> pitti: yes, but that requires software cooperation
<pitti> right
<Kamion> pitti: which is slightly less effective when your box is busy trying to swap everything out to disk
<pitti> Kamion: btw, does sleeping now work reliably on your powerbook?
<pitti> Kamion: I'm eager to test the new kernel :-) but it is not yet built
<Kamion> pitti: haven't tried yet, we haven't had a successful kernel build with that patch; I'm fixing
<pitti> Kamion: I thought you were using the kernel built in Matar?
<pitti> (for testing sleep, at least)
<Kamion> oh, I'm using that normally yes, works fine
* thom is going to get *very* bored of typing "nsCOMPtr<foo>" very soon
<Treenaks> thom: hacking firefox?
<thom> Treenaks: backporting security fixes
<Treenaks> thom: ugh
<thom> very
<Treenaks> you could add a macro for that..
<pitti> thom: inoremap :-)
<sivang> pitti: cool
<elmo_> Kamion: actually, I just tried i386 and eject doesn't even work there
<thom> i could, indeed
<Kamion> it's been working for me on amd64
<elmo_> eject: unable to eject, last error: Inappropriate ioctl for device
<elmo_> is warty error message on the same box as that strace
<elmo_> and with warty it doesn't even manage to physically eject the CD
<Kamion> it always complains (Invalid argument, I think), but it does work
<Kamion> mdz mentioned that he got the complaint too, but it ejected nevertheless
<elmo_> it does eject with hoary live, problem is because eject returns !0, it hangs the reboot process
<Kamion> ah
<elmo_> which combined with the powerpc console breakage, is particularly confusing :)
<Kamion> er, no, that makes no sense
<elmo_> Kamion: ?
<Kamion> eject is run from a script that isn't 'set -e'
<Kamion> I don't see how its exit code could even be noticed
<dholbach> d3vic3: ping
<d3vic3> dholbach, pong
<Kamion> there's a deliberate "Please remove the disc and press Enter:" prompt
<dholbach> d3vic3: cool - have a question concerning apoo - wanted to do its transition
<elmo_> Kamion: oh, eww!
<elmo_> I assumed it only prompted you if it failed to remove the disc - why always prompt?
<Kamion> elmo_: presumably to stop the "disc goes out, disc gets sucked straight back in again" effect on many systems
<dholbach> d3vic3: Package: python2.3-apoo - Conflicts: python2.3-apoo   <-- this can't be intentionally
<Kamion> e.g. my amd64 system un-ejects the CD at POST time
<Kamion> or before
<elmo_> but wouldn't install have the same problem?
<d3vic3> dholbach, yes, it can't be 
<Kamion> elmo_: install takes a bit longer to reboot, and there's a prompt immediately beforehand telling you to remove the disc
<Kamion> to reboot after the disc gets ejected, I mean
<dholbach> d3vic3: just wanted to make sure, i didnt get things wrong :-)
<ogra> amu: i just mailed karriere@credativ ;)
<dholbach> d3vic3: i'll throw out 2.2 
<d3vic3> dholbach, cool 
<dholbach> apoo-2.2 that is :-)
<dholbach> ogra: they'll do good with a master of the universe :-)
<ogra> hopefully....
<amu> ogra: hehe
<ogra> :)
<rburton> daniels: eek, just tried latest livecd and it still happens
<rburton> daniels: pretty much unreadable, every other line is shifted a pixel
<rburton> Kamion: much better, network detection doesn't loop. is there any way of giving it a WEP key?
<Kamion> rburton: not in the first stage in live mode; use network configuration in GNOME
<rburton> okie
<Kamion> NOPASSWD sudo is broken in today's daily; the password is ubuntu
<rburton> i wanted to see if hoary will power-off my desktop (warty doesn't) and if firewire has improved
<pitti> elmo_: bidwatcher and prozilla syncs, please (new upstream microreleases to fix security bugs; but both in universe)
<elmo_> Kamion: I don't suppose there's a live net-boot, right? :)
<Kamion> elmo_: it would be possible to construct one, but it doesn't exist yet
<elmo_> ok, cool (don't get me wrong, I don't want/need one, just needed to know if I was meant to be testing it
<Kamion> ah, ok. we'd need somewhere public to put the rootfs to make that work
* sivang out --> be back later
<elmo_> upload.ubuntu.com (aka ftp-master etc.) is going away in 5 mins for 5-10 mins
* pitti hurries up to upload his cupsys crack
<Kamion> d3vic3: you're not uploading packages *just* for Standards-Version increments, are you?
<Kamion> d3vic3: S-V is pretty unimportant really ...
<pitti> sivang: new cupsys is up
<d3vic3> Kamion, no 
<d3vic3> the std ver was 3.5.10 in gaby's case 
<d3vic3> testing on python2.4 produced an error 
<sivang> pitti: yay cool, however I need to take care of something, so I will add the gui support later today.
<Kamion> d3vic3: gcipher was the one I noticed, where that was the only change noted in the changelog
<d3vic3> hmmm
<sivang> pitti: and prepare a new gnome-cups-manager package.
<sivang> laterz all
<elmo_> upload.ubuntu.com (aka ftp-master etc.) is back
<elmo_> mjg59: is "Video state get buffer" (or summat like that) your vbetool thing at work?
<mjg59> elmo_: Yeah
<elmo_> Get video state buffer size failed
<elmo_> Save video state failed
<mjg59> On x86?
<elmo_> I've gotten that on every i386 server so far
<elmo_> yeah
<mjg59> They probably lack a VESA BIOS
<mjg59> (which isn't unsurprising)
<mjg59> Uh, which isn't surprising
<mjg59> The information is only used for suspend/resume support
<elmo_> ok
<elmo_> hey, is the auto-upgrade stuff going to be in hoary?
<elmo_> auto-CD-upgrade
<ogra> isnt it already in ?
<elmo_> could be, that's why I'm asking :)
<ogra> at least for me a popup asks if i want to....(never clicked ok though)
<Kamion> elmo_: yeah, definitely in
<lamont> Kamion: you fix that for me?
<lamont> could have sworn I got all of them.
<Kamion> lamont: fix which?
<lamont> linux-source - is there anything newer than -22?
<Kamion> nope
<Kamion> -21 was to fix the package names, -22 was to fix me forgetting 00list-* in -21 ...
<lamont> which, btw, is ftbfs on ppc in pmac_cache.S
* lamont runs kids to school, will stare at kernel stuff after that
<Kamion> yeah, I just noticed that :( must be the sleep patches
<Kamion> it's vaguely familiar from before ...
<Kamion> lamont: try Debian #263057?
<Kamion> lamont: although the patch there isn't applicable, even semantically ...
<dholbach> d3vic3: WOW... you shrink wiki/UniversePythonTransitionTODO in no time :-)
<Kamion> lamont: I'll mail benh and ask for advice
<d3vic3> dholbach, what you mean ? 
<dholbach> d3vic3: you really get work done! :-)
<dholbach> hi zul
<zul> hey dholbach 
<Mithrandir> elmo_: please sync openbox from debian incoming.
<tseng> Mithrandir: heh, did you fix that nautilus buglet?
<Mithrandir> yes; it's openbox's fault.
<tseng> yeah I figured that out.. then saw you talking about it the other day
<tseng> cheers
<Mithrandir> it put out some _crazy_ numbers for the desktop size
<zul> mako: ping
<pitti> lamont: here?
<zul> pitti, is there something i can help you with
<pitti> zul: hi, wrt what?
<zul> kernel stuff or is it something else you were going to ask lamont about
<pitti> zul: I have a buildd problem, by security upload doesn't build :-(
<zul> doh
<zul> hey mako
<zul> mako: willy has signed my key so now what?
<ogra> zul: upload your key and the signature to a public keyserver
<zul> ogra: ok will no
<ogra> zul: then sign the code of conduct and send it to mako
<elmo_> Kamion: ?
<Kamion> elmo_: ?
<ogra> zul: for uploading you have to additionally send the key and your mailaddress to the addresses mentioned on the Uploads wiki page
<elmo_> Kamion: will debootstrap --arch=i386 DTRT on amd64?
<elmo_> and/or is there another/better way to get an i386 chroot on an amd64 box
<Kamion> debootstrap --arch=i386 works
<Kamion> you might want to use linux32 to force the kernel personality to 32-bit (affects uname())
<Kamion> Mithrandir: d'you think we should have linux32 in main?
<elmo_> heck yes
<dholbach> doko: ping
<elmo_> tho IANAMITHRANDIR
<Kamion> it didn't build on amd64 in warty for some reason, probably hence the oversight
<elmo_>    linux32 |        1-1 | warty/universe | source, i386
<elmo_> yeah, meh
<Kamion> looks like it was PaSed or something, oh well
<mako_> zul: hey there
<doko> dholbach: pong
<elmo_> cdrecord: Success. write_g1: scsi sendcmd: no error
<elmo_> go useful error messages
<ogra> hehe
<ogra> cdrecord is soo beautyful
<dholbach> doko: i'm looking at vtk atm, it doesnt provide a python2.x-vtk, but just python-vtk - what do you reckon, i should do? just let it build 2.4 modules?
<zul> mako: so willy signed my key im going to upload the signature
<Treenaks> zul: is your (signed) pubkey on the servers?
<zul> Treenaks, i did an gpg --armout --output signature.asci
<zul> Treenaks, yeah i uploaded to the server that mako preferred
<mako> zul: hey there
<zul> mako: i sent you the signed coc correct?
<doko> dholbach: yes, that should be sufficient
<mako> zul: hold up dude, caffienated
<mako> sorry caffienating
<zul> k
<dholbach> doko: cool, thanks
* Kamion semi-fixes #3690. phew
* elmo_ looks at kamion
<elmo_> 2005-02-22 15:20: base-config_2.62ubuntu2_source.changes
<elmo_> 2005-02-22 15:25: base-config_2.62ubuntu3_source.changes
<elmo_> 2005-02-22 15:30: base-config_2.62ubuntu4_source.changes
<HiddenWolf> kamion is enjoying himself obviously. :-)
<elmo_> "The JoeyH tribute band, led by Colin Watson"
<Kamion> heh
<Kamion> base-config is a bitch to test
<Kamion> don't worry, I've stopped now ... for the moment
<elmo_> anyone who cares, concordia now has a i386 chroot, 'linux32 dchroot -c hoary-i386' will get you there
<thom> elmo_: i won't care till concordia is sat under my desk ;-)
<Kamion> sheesh, imagemagick not in desktop?
<Kamion> anyone fancy doing a lilo boot graphic?
<Kamion> Ubuntu-branded
* sivang --> back
<dholbach> wb sivan
<sivang> dholbach: hey
<amu> away abendessen
<dholbach> guten hunger, amu :-)
<amu> argl :) danke
<elmo_> oh wow, the serial console 'text mode' is SO old skool
<Kamion> YM the cdebconf text frontend?
<HiddenWolf> elmo_ That's half the fun about linux: Every once in a while, you still find the look and feel of a 80's mainframe. :)
<elmo_> yean, the 'readline' thing
<elmo_> Kamion: hum.  
<elmo_> If possible, the first 
<elmo_> connected network interface found has been selected.
<elmo_> if it says that, but then prompts me, does that mean it couldn't figure it out?
<elmo_> 'cos I have no idea either, and it's not like I can switch to another VC ;)
<Kamion> that means it's selected that as the default answer (if you can tell the difference in readline)
<elmo_> Prompt: '?' for help>
<elmo_> if there's a default it would say "; default=<n>" after 'help'
<Kamion> in that case it probably couldn't do mii/ethtool; just pick one and sort it out later
<Mithrandir> Kamion: yes, absolutely.
<pitti> lamont: pinnnnnng
<elmo_> Starting up the partitioner  ..11%..22%..33%..44%..50%..61%..72%Partition disks
<elmo_> !! ERROR: No partitionable media
<elmo_> ... you said.  Our survery said ... BZZZZT
<Kamion> anything in /dev/discs?
<elmo_> cat: /dev/discs: No such file or directory
<Kamion> (it'd be a directory, but yeah)
<lamont> pitti: yo
<Kamion> um, what hard disk driver would it need?
<mako> jdub: around? #ubuntu-meeting if you are
* lamont finally allows his computer to force him to take a 1 minute break
<elmo_> Kamion: ah, nm, it's mpt fusion
<Kamion> ok, so will be fixed; modprobe mptscsih in the meantime
<elmo_> uh, no module available
<Kamion> architecture?
<elmo_> ia64
<Kamion> it got built in for a while ...
<Kamion> maybe that didn't work properly or something
<elmo_> is the config around at this stage?
<elmo_> kernel config I mean
<Mithrandir> elmo_: /proc/config.gz ought to
<lamont> Kamion: it got removed in -20, iirc
<lamont> so depending on which ISO he's booting...
<elmo_> the scsi vs. scsi-extra is a bit strange
<Kamion> you might be booting a -20 kernel but have -19 modules
<Kamion> or something similar
<elmo_> scsi seems to contain a bunch of 80's SCSI cards, and then mpt fusion which is in a whole bunch of modern servers is in extra
<Kamion> ./modules/ia64/scsi-modules:5:drivers/message/fusion/mptscsih.o
<Kamion> although I see your point on i386
<Kamion> do you find mpt fusion on many powerpc systems?
<elmo_> err, dunno, ours aren't SCSI
<Kamion> all the same, it doesn't matter
<Kamion> scsi-modules is for stuff like SCSI CD-ROMs
<Kamion> i.e. when you need the SCSI driver before you get a chance to install more udebs
<elmo_> ah, k
<Kamion> although I suppose if you were actually attaching the CD-ROM drive via SCSI on one of these systems it would make a difference; I take it you aren't
<elmo_> how do I tell what kernel etc. I'm on?
<elmo_> 'cos dpkg -c scsi-modules-2.6.10-3-itanium-smp-di_2.6.10-19_ia64.udeb  | grep mpt
<elmo_> isn't giving me no love
<Kamion> elmo_: grep 'Version: 2.6.10' /var/lib/dpkg/status
<Kamion> if it's all the same version apart from the l-r-m stuff, you're in sync
<elmo_> eh.. .*2.6.10 ?
<elmo_> oh, meh, wrong machine, nm
<elmo_> yeah, 2.6.19-19
<elmo_> oh my god you can't search in more(1)
<elmo_> Kamion: how does the busybox environment not drive you insane?
<elmo_> I keep wanting to do basic things (grep -A) that don't work
<thom> elmo_: see, you're assuming he's not insane already
<Mithrandir> elmo_: I think you have nano in there
<elmo_> okay, so CONFIG_FUSION=m, but the module isn't in scsi-modules and there's no scsi-extra-modules; do I need to retry this when 2.6.10-20 filters through to a CD?
<pitti> Kamion: what do you think about dropping most of cyrus-sasl from supported?
<pitti> Kamion: nothing really depends on its packages, most of the world uses cyrus-sasl2 now
<Kamion> elmo_: probably, yeah
<Kamion> pitti: will check in a moment
<thom> what the hell does "foundWindow = !!namedItem;" result in? C++
<mjg59> elmo_: Kamion: When -20 is built for PPC, any chance of you checking whether sleep/resume works?
<elmo_> mjg59: will do
<Kamion> mjg59: will do, but it'll have to be -23 since -20 to -22 don't build on powerpc
<Kamion> I've mailed benh asking if he can supply a fix
<mjg59> Kamion: Erk. What's the failure?
<lamont> mjg59: bad ppc
<lamont> arch/ppc/platforms/pmac_cache.S: Assembler messages:
<lamont> arch/ppc/platforms/pmac_cache.S:53: Error: Unrecognized opcode: `dssall'
<lamont> arch/ppc/platforms/pmac_cache.S:171: Error: Unrecognized opcode: `dssall'
<mjg59> lamont: ?
<mjg59> Argh.
<elmo_> boggle
<lamont> that's on power-3
<mjg59> Blah, that's from one of my patches
<elmo_> that's a really old failure
<lamont> elmo_: was introduced with one of mjg59's patches
<pitti> Kamion, elmo_: the latest cyrus-sasl security upload has a medium-sized problem
<Kamion> it's a power3-only thing
<Kamion> thom: !! is an idiom for turning anything into a boolean
<thom> Kamion: ahah, thanks
<pitti> Kamion: cyrus-sasl was FTBFS in Warty due to a partial libdb3 -> libdb4.2 transition
<Kamion> thom: i.e. 0 => 0, non-0 => 1
<Kamion> elmo_: there was an old binutils bug I found that you'd commented on with the same failure, but the patch that solved that has been applied
<elmo_> oh, is the stuff mjg59 stole from gentoo?
<pitti> Kamion, elmo_: ^ c-sasl depends on libdb3-dev and heimdal-dev, but the latter depends on libdb4.2-dev (and both versions conflict to each other)
<mjg59> elmo_: No, it's from bk
<pitti> Kamion, elmo_: since we shouldn't break the db format for a security update, what do you think about manually rebuilding the package with an older heiimdal-dev (with libdb3)?
<Kamion> pitti: vomit
<pitti> Kamion: welcome in the club
* pitti wades through the mess
<lamont> was fixed in hoary by adopting the debian change to cyrus-sasl, which ISTR was just s/db3/db4.2/
<lamont> accompanied by prayers about db conversion if needed
<lamont> most of the file format was the same, iirc
<lamont> there was certainly a diff, but I think it was off in some wierd logging corner case or some such.. dunno
<mjg59> Kamion: By the looks of it, that code just shouldn't be built on POWER3
<lamont> mjg59: does this mean I get a new patch from you?
<Kamion> mjg59: our power3 build has PPC_PMAC turned on
* Kamion tries to remember if there are power3 pmac machines?
* lamont considers making Kamion check in his changes to the arch tree
<Kamion> lamont: happy to ...
<mjg59> There are no real power3 pmac machines
<Kamion> oh, there we go, just kill that then?
<lamont> p.u.c:~lamont/public_html/Archives/...
<mjg59> I've no idea if power3 has semantics that make it useful in other cases
<mjg59> But if the Mac kernels are separate, you ought to be able to kill PPC_PMAC from them
<Kamion> lamont: that won't be writable though?
<lamont> Kamion: you'll notice some tagging stuff
<Kamion> mjg59: we only build one (pair of) kernels for power3, not separate Mac kernels
<lamont> Kamion: it is for you if you make it an sftp archive
<Kamion> lamont: yeah, what's with the commas in the tags?
<lamont> can't use periods
<mjg59> Kamion: What kernels get installed on Macs?
<Kamion> mjg59: depends on the mac; linux-image-{powerpc,power4}{,-smp}
<lamont> Kamion: and you'll notice that it's in the branch name, not the version (since _that_ doesn't allow anything but numbers and periods)
<mjg59> But what I actually meant is that the code in question is useless on power3 - the processors those calls are fiddling with aren't power3
<mjg59> Kamion: Right, I'd expect you to be able to drop PPC_PMAC from them
<Kamion> in other words, drop PPC_PMAC from power3 and power3-smp
<elmo_> mjg59: er?
<elmo_> what's PPC_PMAC do?  'cos my laptop's using (or would be if I used distro kernels) power3
<Kamion> meh what? how?
<elmo_> err
<Kamion> power3 is like a different processor from your laptop
<Kamion> it's IBM big iron
<elmo_> yeah, sorry, I'm getting confused
<elmo_> this is why I HATE subarches
<Kamion> you and me both
<mjg59> Kamion: Any idea why it was switched on?
<Kamion> mjg59: nope
<elmo_> my laptop which is a 'g4' -> powerpc, our powermac G5 -> 'power4'.  wtf?
<mjg59> elmo_: G5 is PPC64, which is power4
<Kamion> mjg59: it doesn't appear to be that way in Debian
<mjg59> Kamion: Kill with extreme prejudice, then
<Kamion> which rather worries me, I wonder where we got those configs
<elmo_> mjg59: yeah, I know, it's just hellishly unintuitive
<mjg59> Kamion: Kernel default config has PPC_PMAC switched on
<Kamion> lamont: so can I check in the changes one by one rather than in a big batch? :)
<Kamion> mjg59: yeah, but I thought we'd have got our config by starting with Debian's config
<Kamion> since that's what we did with the udebs
<lamont> Kamion: however you want, but would be nice to have tags for -21 and -22
<ogra> wasabi ?
<Kamion> lamont: right, will do
<pitti> Kamion (cc:lamont) are you fine with a manual cyrus-sasl build?
<Kamion> lamont: I'll commit the config change discussed above too, if that's ok
<Kamion> pitti: whatever lamont's ok with ... (dangerous though that statement is)
<pitti> okay :-)
<lamont> Kamion: manual build will require resurecting a heimdal set from the morgue somewhere, manually installing it on the buildds, and thereby preserving the FTBFS issue....  elmo will kill me.
<lamont> so I'm gonna require a very clear edict before I'll accept that path...
<elmo_> don't drag me into this horrow show
<elmo_> it's warty - we can't fix it right now, just fix it however you need to; the most important thing is to make damn sure we don't have any packages like this in hoary
<elmo_> (which is blocked on me, I know - go me)
<tseng> elmo_: hey, did gtk-sharp-unstable ever get into NEW?
<tseng> elmo_: or still having mysterious problems
<elmo_> tseng: nah, it's in NEW, I'll have a look at in a bit
<tseng> elmo_: ah great. thanks
<elmo_> tseng: tho, why are we doing the whole '-unstable' thing instead of just uploading the newer version as gtk-sharp?  is it that unstable?
<tseng> elmo_: they are paralel installable. most apps use gtk-sharp 1.0.x
<tseng> this is 1.9.x
<tseng> also, miguel asked it have something to the effect of -unstable, as the api isnt frozen
<elmo_> ok
<tseng> so thats how the debian maintainer packaged it..
<tseng> its sort of unclear how/when it will go into experimental
<tseng> only muine uses atm, and we want a recent version (which actually builds)
<Kamion> pitti: can this wait 'til mdz gets back? I don't really feel comfortable saying "yes, do this evil thing"
<pitti> Kamion: it's a security update, but since nothing really uses this old crap, I'm fine with waiting
<elmo_> isn't that slac^W^Wour fearless distro-leader due back todayish anyways?
<pitti> dunno, he spoke about "a few days" in his holiday reminder...
<tseng> elmo_: will the same package going into sid with a slightly different name cause you major pain in the future? or correctable
<tseng> elmo_: this is the name from the debian maintainer, but I havent gotten a strong commitment that that will be the name in sid
<Kamion> IIRC it was indeed today, but I might be a day or two out
<Kamion> tseng: try not to clash with their version numbers ...
<Kamion> tseng: different .orig.tar.gz files with the same filename will cause pain, too
<Mithrandir> ubuntu in the .orig.tar.gz file name?
* Mithrandir hides
<Kamion> lamont: could you chmod g+w the revision lock in that archive?
<Kamion> lamont: (might want umask 002 in your .bashrc ...)
<lamont> GAH!
<elmo_> cdrecord: A write error occured.
<elmo_> cdrecord: Please properly read the error message above.
* elmo_ <heart> joerg
<aj> Mithrandir: foo_1.0+ubuntu1.orig.tar.gz is pretty plausible, especially if there isn't an official tarball
<thom> HAHA
<Mithrandir> elmo_: use DVDs and growisofs. :)
<thom> (at the cdrecord error)
<Mithrandir> aj: true enough.  Still ugly.
<Kamion> or 1.0~ubuntu1.orig.tar.gz, better
<lamont> Kamion: fixed
<Kamion> (since we'd want a Debian version to win)
<elmo_> err, guys, we're talking about the package name not version?
<elmo_> AIUI
<elmo_> or tseng was originally
<Kamion> oh, slightly different name, not the same name; misread
<shaya> something I've noticed recently is that new windows pop up in the background
<elmo_> so. hum.  something greatly upsets CD burning on my laptop and I'm beginning to think it's xmms - is that even plausible?
<shaya> is this the way its supposed to be?
<shaya> i.e. if I click on an email link in firefox, evolution compose email window is obscured
<tseng> elmo_: yes, different names. he alluded to possibly making gtk-sharp2-unstable vs gtk-sharp-unstable
<shaya> also, any ubuntu ppc people here?
<elmo_> tseng: that's fine we can merge later without problems
<pitti> shaya: right now I'm typing at a ibook g4
<tseng> elmo_: wonderful, all I wondered
<tseng> hm, hi shaya 
<shaya> anyone know if ppc64 stuff is supported?
<shaya> i.e. J20 (970FX) blades
<shaya> js20 that is
<shaya> IBM donated a 14 unit blade center to us and we'd like to get a debian type distro on it, plain debian doesn't seem to do it
<tseng> seb128: hey did you upload f-spot to sid? I got a reject message, dist was set to hoary
<seb128> tseng: grumpf, the debian maintainer did
<seb128> I've pointed the hoary packages
<seb128> he has changed the version but not the distro
<pitti> bbl
<tseng> hm alright. the mail went to him as well so I imagine he'll fix
<shaya> does f-spot actually work for anyone?
<shaya> and not crash w/ a gnomevfs error?
<tseng> sure does.
<shaya> Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for Gnome.Vfs.Vfs ---> System.DllNotFoundException: gnomevfs-2
<tseng> yep you mailed me.
<shaya> oh
<shaya> you're hale
<tseng> brandon, yes
<shaya> want to log into my laptop now and try it for yourself?
<shaya> yes, but brandon might get you confused w/ overfiend
<shaya> "brandon" that is
<tseng> overfiend is branden
<tseng> heh.
<Mithrandir> he uses a bit more caps too
<shaya> eh, close enough.  I have letters from ACM addressed to Ms. Shaya Potter. that's a bit more off
<tseng> ouch
<shaya> at least last time I looked down
<tseng> :D
<shaya> tseng: so do you want to check out my laptop?
<tseng> I could, but my mono debugging skills are pretty limited
<lamont> pitti/Kamion: so the decision is to stall waiting for mdz to surface, and then probably commit unspeakable evil in the name of preserving the status quo?
<shaya> just can see if there's anything abnormal
<tseng> shaya: if you checked out for proper installs of gnome-vfs2 and libgnome-cil I'm not sure what else to look at. we can talk to lewing
<tseng> and co
<tseng> shaya: care to see if anyone is home on #f-spot, irc.gnome.org ?
<tseng> I've just joined
<shaya> lewing is in #hula
<tseng> lewing is in #f-spot as well..
<shaya> in #hula's he's been idle 14 hours
<tseng> unless you both really want to divert the topic of #hula, which is damn busy last I checked
<shaya> hmm, try irc.gnome
<shaya> msg him
<tseng> 7hrs
<shaya> says 14 for me
<Kamion> lamont: right, if that's possible
<lamont> ok
<lamont> I'll root around in the morgue and find the right evilness
<shaya> figured it out
<shaya> [pid 11824]  open("/usr/lib/gnomevfs-2.so", O_RDONLY) = -1 ENOENT (No such file or directory)
<tseng> yeah
<tseng> htf are you missing that?
<shaya> same problem
<tseng> um
<tseng> one second
<Amaranth> wait, how the hell could you be missing gnomevfs and have a working system?
<shaya> it's not missing
<tseng> Amaranth: thats the wrong path
<shaya> .so.0 is included
<Amaranth> ah
<shaya> same problem as w/ the gphoto
<shaya> and make the link and f-spot works
<Amaranth> well, you could symlink for now and report the problem to the maintainers
<Amaranth> yeah
<shaya> yea, strace
<shaya> or that should have been a yay strace
<tseng>  /usr/lib/libgnomevfs-2.so.0 is in libgnomevfs2-0
<shaya> yes
<shaya> tseng: so how did you get the .so link
<shaya> :)
<Kamion> oh, you're using the -dev .so symlink
<shaya> made it yourself?
<Kamion> shaya: it's in libgnomevfs2-dev or whatever
<tseng> no, its in -dev
<tseng> so I will make you a fix
<shaya> k
<shaya> is this a bug in gnomevfs packaging or mono?
<tseng> hm I wonder if I can hit that in muine also
<shaya> as seems to be something we hit a lot
<tseng> shaya: I am thinking libgnome-cil (gtk-sharp)
<shaya> k
<shaya> anyways
<tseng> yeah muine isnt affected
<Kamion> it's not a bug in gnomevfs
<tseng> its a bug in mono packaging
<shaya> back to work for me, need to finish this paper http://www2005.org/program-fri.html#T10:30 (as don't want to miss my chance to go to japan for free)
<tseng> muine has
<tseng>        5   <dllmap dll="libgnomevfs-2-0.dll" target="libgnomevfs-2.so.0"/>
<tseng> bingo
<tseng> f-spot just needs the same thing
<Kamion> lamont: -21 and -22 committed
<Kamion> lamont: I'll do the power3 config thing on a separate branch, and you can merge
<lamont> thanks
<tseng> shaya: im fixing now. cheers
<lamont> and thanks for dealing with the power3 config thing.
<ajmitch> tseng: you want #6805?
<tseng> ajmitch: hm id like to wait and see if they can reproduce with 0.8.2.. sound fair?
<ajmitch> ok
<tseng> lemme finish this f-spot fix
<shaya> this whole dllmap stuff just weirds me out
<tseng> whys that?
<shaya> just seems hackish, whatever happened to good ole ld
<tseng> its C# dude
<shaya> yea
<tseng> no linker
<shaya> mono is the linker
<tseng> well it doesnt do ld
<ajmitch> shaya: yeah it's annoying, but since the assemblies don't request which version to use, it's sort of needed
<shaya> right, but no reason it shouldn't.  i.e. to the kernel, elf binaries can be viewed as bieng executed by /lib/ld-linux
<tseng> shaya: anyway ill have a .deb for you in 2 minutes
<shaya> and mono binaries can be viewed as bieng executed by mono
<shaya> but ok, I'll take ajmitch's answer
<tseng> theres no elf
<tseng> its bytecode
<shaya> right
<shaya> I agree, but it seems like just importing window's DLL hell world into linux
<shaya> and have a hack way around it with the dllmap entries
<lamont> Kamion: once you have happy ppc stuff, I need to merge in a new tosh acpi from kinnison, it would appear...  so I'll plan on -23 sometime soonish
<shaya> lamont: you do ppc?  know anything about my js20s?
<Kamion> jbailey: can you look at #1440? there's a comment that it'll be obsolete once #1763 is fixed, but you fixed #1763 and there's still a report of it being broken
<Kamion> what is a js20s?
<shaya> 970fx based blade
<shaya> http://penguinppc.org/ppc64/machines.php
<shaya> supposdly "works"
<shaya> but no debian based distro seems to work
<jbailey> Kamion: Hmm, if loading ide-cd and ide-generic don't do it, there's other problems, but I'll try and figure it out.
<tseng> shaya: http://getsweaaa.com/~tseng/f-spot/f-spot_0.0.9-0ubuntu2_i386.deb test this please.
<Kamion> jbailey: thanks
<Kamion> shaya: hoary doesn't work? warty was missing 970fx bits, but hoary should have most of them
<lamont> Shaquile: I just build stuff
<Kamion> shaya: however we don't have a ppc64 kernel yet, so ...
<Kamion> mjg59: hm, menuconfig only offers one all-in-one "CHRP/PowerMac/PReP" option for machine type
<tseng> shaya: huh wtf
<T-Bone> hey Kamion, lamont :)
<Kamion> hi T-Bone
<lamont> T-Bone: howdy
<T-Bone> lamont: so you uploads stuff without building it, heh? :^)
* lamont tries to think of something controversial to say to t-bone, decides that would be mean.
<T-Bone> s/ds/d/
<T-Bone> dooh
<Kamion> admittedly so did I, with -21 :(
<lamont> T-Bone: 4/5 built...
<T-Bone> Kamion: yeah you were the next target on my slap list :)
<lamont> was bedtime dammit
<T-Bone> lamont: hehe :)
<lamont> but it _booted_
* Kamion claims "doing emergency hot-fix" mitigation
<T-Bone> lamont: and that's supposed to prove anything? :^)
<lamont> T-Bone: and btw, the parisc breakout patches went balistic, so I reverted that (but left them in the tree)
<Kamion> lamont: my problem now is that the installer's gonna be broken tomorrow
<T-Bone> lamont: balistic like how?
<T-Bone> Kamion: gaaah :P How so?
<lamont> T-Bone: yeah, that you want to say :%s/2.6.10-3/2.6.10-4/g, not :%s/2.6.10-3-/2.6.10-4-/g
<lamont> irq major borkage
<Kamion> T-Bone: er, ABI breakage, it goes with the territory unless you get the whole thing over with in one day
<lamont> T-Bone: does not play well with others kind of issues
<Kamion> lamont: it looked more like :%s/-2.6.10-3/2.6.10-4/g or something like that
<lamont> Kamion: whip cracking time?
<T-Bone> lamont: dude, all i did was splitting existing patches. I haven't (and couldn't) tested them
<lamont> T-Bone: understood
<lamont> I just didn't want to hold up the upload for hppa, because that would have been, well, bad.
<Kamion> lamont: just trying to get something I can run 'make config' on right now
<T-Bone> lamont: at any rate this should make our lives easier when backporting stuff from kyle
<T-Bone> lamont: sure
<lamont> T-Bone: yeah - I'll make some time to play with the patches some more in my off time later this week, assuming that anysuch time exists.
<T-Bone> hehe
<T-Bone> lamont: remember that a good part of that non-existing time should be devoted to oo.o ;)
* T-Bone ducks!
<lamont> meanwhile, arguing with d-i's archive-arrangement assumptions has given me the fun opportunity of adjusting my evil-archive scripts more, and will yet again.
<tseng> shaya: heh sorry about that. had to look at the code to see what it was actually trying to load
<T-Bone> lamont: heh :)
<lamont> because this is wrong: pool/main/debian-installer/a/anna/anna_1.06ubuntu4_hppa.udeb
<tseng> shaya: also chokes on libgnomeui at least
<Kamion> lamont: follow the Filename: in Packages ...
<jbailey> Kamion: Do I understand this right that the Hoary livecd works, but not the installer?
<elmo_> what's default debconf in warty?
<Kamion> jbailey: no, I think those comments are talking about the Warty live CD
<Kamion> elmo_: default debconf what?
<elmo_> priority, sorry
<Kamion> elmo_: in warty, critical in the installer and high in the installed system
<elmo_> cool, tnx
<Kamion> in hoary, the installer shifted back to high
<T-Bone> Kamion: if i get it right, today's ISO should have the mptscsih fix, right?
<Kamion> T-Bone: no, because of kernel build problems
* mvo is away for ~2h
* thom wonders idly if firefox will build
<lamont> Kamion: yeah - the issue is that this is a fresh import, and it was because I was a little too complete in forcing main/debian-installer to be a component
<lamont> fixed now, but it's an archive event for my poor archive.
<T-Bone> Kamion: gah. something generic or something I have to fix?
<T-Bone> (and don't say the latter just to get me mad :)
<lamont> which means: 1) move *_hppa.deb and *_hppa.changes back into the upload queue, 2) remove binary-hppa/Packages.gz; and 3) re-import
<Kamion> T-Bone: no. see the above conversation?
<Kamion> T-Bone: you knew it didn't build, since you were complaining at lamont about it, surely?
* T-Bone needs to catch up with scrollback quickly
<Kamion> T-Bone: I've spent a good part of today on it ...
<T-Bone> Kamion: actually i didn't know it doesn't build. I blamed lamont for uploading a package with missing data (which he would have noticed if he'd built the package). I didn't know the problem was "bigger"
<tritium> With the changes to cupsys browsing, shouldn't dpkg-reconfigure ask whether or not to enable it?
<lamont> T-Bone: ppc is ftbfs
<Kamion> T-Bone: ah, I see :) what was the missing data?
<lamont> --> -23 today sometime
<lamont> Kamion: metadata
<T-Bone> lamont: ah it's the ppc fixes from benh?
<lamont> specifically, the lingering instances of 2.6.10-3
<lamont> T-Bone: yes.
<Kamion> T-Bone: right - it's just on power3
<T-Bone> ok now i've sync'd both halves of my brain ;)
<lamont> which are solved with a config change
* lamont gets dragged into town by his wife - back in a bit
<T-Bone> ok, so it's not such a big deal, is it?
<Kamion> lamont: hm, well
<T-Bone> heh, see ya
<lamont> Kamion: well, in theory anyway...
<Kamion> lamont: you can't turn off CONFIG_PPC_PMAC just by running 'make config'
<Kamion> it doesn't let you do that individually
<Kamion> which makes me a bit leery of doing that
<lamont> ah. ouch.
<Kamion> CONFIG_PPC_MULTIPLATFORM is one piece, you see ...
* lamont begins to chant his "Kamion knows best" mantra, while disappearing for about 120minutes or so
<Kamion> not about the kernel I don't :)
<lamont> anything more before I flee for a bit?
<Kamion> I mailed benh about it, but no reply yet
<dholbach> i'm out running *wave*
<T-Bone> Kamion: grant me 1h and I'll have a look
<T-Bone> have to go out now
<Kamion> T-Bone: http://people.ubuntu.com/~lamont/buildLogs/l/linux-source-2.6.10/2.6.10-22/linux-source-2.6.10_2.6.10-22_20050222-1238-powerpc-failed
<T-Bone> copy/pasted. Will look when I get back
<tseng> shaya: here?
<Kamion> lamont: I think I might just whack #ifndef CONFIG_POWER3 around that for now
<shaya> yes
<shaya> tseng: back
<shaya> wsa downstairs
<shaya> f-spot seems to work now
<tseng> with my new deb?
<shaya> yes
<tseng> wonderful
<shaya> and with my gnomevfs.so symlink removed
<tseng> heh, bye..
<tseng> shaya: can you reply to all and let ondrej know as well that the new package works as expected
<tseng> shaya: thanks alot for playing along.
* tseng sighs
<tseng> ajmitch: commented #6805, thanks for pointing
<Mitario> hi everyone
<seb128> elmo_: gnome-mag (from unstable) and gazpacho (from incoming) syncs please
<trukulo> who is in charge of suspend work on laptops?
<seb128> trukulo: what part ?
<trukulo> er... acpi suspend, hibernate, sleep, you know
<seb128> yeah, I know, but what part ?
<mx|gone> jbailey: ping
<seb128> backend ?
<seb128> UI ?
<trukulo> support on concrete models
<seb128> mjg59/thom 
<trukulo> thanks seb
<seb128> np
<trukulo> i'll ask them if they want me to try scripts on my compaq laptop, it seems that compaq is not specially well supported
* enrico points the finger at http://people.ubuntu.com/~mako/docteam/quickguide/
<enrico> It's almost finished, and it ROCKS
<enrico> Almost finished, as in: http://people.ubuntu.com/~mako/docteam/status/qg-report.html
<tseng> enrico: will the first be avilable in yelp?
<elmo_> Kamion: ?
<mako> enrico: taht's fantastic
<Kamion> elmo_: ?
<enrico> tseng: yes.  If you checkout DocteamRepository, you can build a .deb out of it
* seb128 needs to fix yelp
<enrico> tseng: the OMF files have still to be written, though
<trukulo> mjg59, ping
* Kamion screams at the fucking stupid linux-source-* build system
<Kamion> waste of time
<elmo_> Kamion: I've got two 80Gb disks, I get offered Erase a, Erase b, Use largest free, and Manual.  I select the third and get told "failed, probably not enough space"?
<zul> Kamion: hmmm?
<Kamion> elmo_: do you actually have free (i.e. unpartitioned) space on those disks?
<Kamion> zul: the stupid "patch -1, unpatch -1, patch -2, unpatch -2, patch -3, ..." ritual it goes through before getting out of bed
<zul> Kamion: heh welcome my world :)
<Kamion> I want to put a big "I DON'T CARE" label on that repeated patching
<elmo_> Kamion: no - but couldn't it see that itself and not offer me an option that's doomed to fail? :)
<Kamion> elmo_: hm, yeah, guess so, would have to think of how; file a bug please?
<elmo_> yeah
<Kamion> elmo_: package partman-auto
<elmo_> Kamion: also does "large contiguous free space" count spanning across disk? :)
<elmo_> ah, hmm, this is a mac so #1 is sacrosant isn't it.. meh
<jbailey> mx|gone: Here.
<jbailey> trukulo: suspend to ram is working fine on my Compaq Armada E500
<jbailey> trukulo: This might be better done on #ubuntu, though.
<Kamion> elmo_: it would if we did auto-LVM ...
<trukulo> jbailey, i know, i know, i'm only offering as a tester if they want, i don't ask for direct support here
<jbailey> trukulo: Ah, makes sense.
<trukulo> :)
<elmo_> Kamion: dude.  gb.archive.ubuntu.com - you rock.
<Kamion> elmo_: just worked? cool.
<elmo_> en_AU.. pfft
<daniels> elmo_: don't be hatin'
<elmo_> en_ZA? WTF is that.. "Would you like to continue, hey? [Y/n] "
<helix> heh
<elmo_> remind me why we register documentation in the foreground?
<jbailey> Kamion: I found a system that matches this one more or less:
<jbailey> Kamion: Apparently the ata_piix driver doesn't support proc-fs, I may have to just punt this bug to kernel folks.  I'll try a bit more, though.
<elmo_> neat. the apple (paper) docs seem to come in either German or Japanese 
<pitti> elmo_: if you need some help with the former... :-)
<Kamion> elmo_: because the moment after you finish the installation is the one time when it's most likely that the user will want to use the machine rather than having it gummed up by background jobs?
<zul> jbailey: once you have finished looking at it open up a bug so we can keep track of it
<jbailey> zul: Ubuntu #1440
<elmo_> pitti: tis okay, even with non-parseable docs I can see there's no spare harddrive, but I suppose that wasn't a realistic hope anyway ;)
<zul> jbailey: great thanks
<elmo_> Kamion: yeah, I guess
<dholbach> re
<zul> jbailey: is that on a recent cd?
<jbailey> zul: Running Hoary system, 2.6.10-3-686
<zul> ah...k
<jbailey> zul: It looks like ata_piix just isn't picking up the IDE CD Drives, but is taking over the ports, so that ide-generic can't do it either.
<zul> grrr
<elmo_> argh.  does software raid not work for partman on ppc either?
<jbailey> zul: I tried loading sg by hand, but it didn't do it, and /proc/scsi/ata_piix/0 tells me "The driver does not yet support the proc-fs"
<jbailey> zul: So even if it were appearing, there's nothing my hotplug script could do to pull it out of there anyway.  I think I'm about at the point where I'm out of options.  I'l googling a touch, though.  I have trouble imagining that noone else has come across this.
<Kamion> elmo_: no, needs newer parted
<Kamion> I might backport that actually
<zul> jbailey: have you tried 2.6.11 ?
<jbailey> zul: No.  This is a server in a datacentre 3 timezones free here.  The 2.6.11 in the archive stayed running for about 2 minutes on my home machine before oops'ing so I'm a little reluctant to try it.
<jbailey> s/free/from/
<zul> ah i c..ok well ill have a look at it tonight
<jbailey> zul: Thanks.  I'll add myself to the bug cc: list.
<elmo_> Kamion: that'd rock
<elmo_> I can even test it; as I'll have to reinstall this machine when it gets it's third disk back anyways
<Kamion> elmo_: (I don't know if it needs *only* newer parted; but that's a necessary condition at least ...)
<Kamion> elmo_: ok, will queue that up after this kernel crap
<trukulo> 2.6.11 oops on my machine too after 2 minutes of use (several times)
<Kamion> y'know, if I were intelligent, I'd build this on davis
<elmo_> uh, you'd have difficulty
<Kamion> ... oh, davis is down. poo.
<elmo_> I'm using it's gfx card to install royal
<Kamion> haha
<elmo_> davis won't boot without it :(
<elmo_> uh, wtf
<elmo_> stage 2 is asking for the CDROM
<Kamion> GAR. does the kernel build system EVER WORK AT ALL?
<Kamion> The changelog says we are creating 2.6.10, but I thought the version is 2.6.10-4-power3-smp
<Kamion> oh, maybe I need Ubuntu kernel-package
<Mithrandir> Kamion: by accident, on Thursdays?
<Kamion> ah, that did it
<jbailey> zul: When is tonight for you?  I can try to make sure I'm around if you need information from a running system.
<T-Bone> Kamion: just got back, any update on the ppc kernel update
<T-Bone> ?
<Kamion> still building but at least it's got past the earlier failure
<T-Bone> ok
<zul> jbailey: i should be back on irc around 7ish tonight
<jbailey> zul: 'kay.  I'll try to make sure i'm back on around then.
<zul> k cool
<Kamion> lamont: please pull colin.watson@canonical.com--2005/kernel-debian--powerpc-config--2.6.10--patch-1, and add powerpc-fix-no-altivec to the 00list for the new version
<T-Gone> bbiab (Dinner)
<Kamion> T-Gone: the patch I just pointed lamont at should fix the powerpc issue
<Kamion> lamont: that's http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005, by the way
<Kamion> ah, bugger, still no go
<Kamion> arch/ppc/platforms/built-in.o(.text+0x1488): In function `flush_disable_caches':
<Kamion> : undefined reference to `__flush_disable_L1'
<Mithrandir> does opening http://216.239.59.104/search?q=cache:H8-Vvmd6ByEJ:www.geocrawler.com/mail/msg_raw.php3%3Fmsg_id%3D8686678+Xlibs+cookie+MIT-MAGIC-COOKIE&hl=no&client=firefox open up the print dialog for anybody else?
<Mithrandir> (firefox, i386)
<ogra> amd64 .... the dialog opens here
<HiddenWolf> I've never been able to make xchat and firefox to play nice on i386
<Mithrandir> ogra: weird; I'll file a bug.
<Mithrandir> I'm sure thom will love me.
<ogra> yup
<LBM> i get a print dialog (i386)
<HiddenWolf> Mithrandir: it opens for me too.
<Mithrandir> ok, I think we can call the verified. :)
<T-Bone> Kamion: benh is on #d-kernel.
<Kamion> lamont,T-Bone: ok, you probably want the rest of the colin.watson@canonical.com--2005/kernel-debian--powerpc-config--2.6.10 branch too (patch-2 and patch-3), and I renamed the patch from powerpc-fix-no-altivec to powerpc-fix-pmac-cache
<Kamion> lamont,T-Bone: I haven't done full builds, but I've successfully done the monolithic kernel part of the build with power3-smp, power4, and powerpc
<T-Bone> sounds good
<Kamion> I don't think it should affect modules
<elmo_> Kamion: davis is back, fwiw ;)
<T-Bone> Kamion: you'll want to have lamont get that in our archive. I don't have write access to it (sigh)
<Kamion> elmo_: bit late, slacker :P
<Kamion> T-Bone: aye, we really need a better solution for shared archives
<T-Bone> Kamion: indeed. It's actually a bit pointless for us to have that archive, for only you or lamont can commit there
* T-Bone is still going through the pain of learning how to use arch anyway
<Kamion> T-Bone: well, no, it allows lamont to integrate from a branch you create
<Kamion> T-Bone: you can still make commits and their history will be preserved
<T-Bone> fair enough
<T-Bone> i really have to educate myself about that monster. It's just that looks so ugly to me :-}
<Kamion> in the same way as Linus' kernel archive isn't pointless, despite the fact that only he can commit to it :)
<T-Bone> yep
<Kamion> (leaving aside political stuff about BK ...)
<T-Bone> shhh ;)
<Kamion> still, an archive labelled kernel-team should be writable by the whole team, really
<T-Bone> Kamion: actually it should be writeable by team leader(s). Since I don't know yet how the whole arch stuff work, i don't know what are the implications of more people being able to write
<T-Bone> Kamion: as we've stated it, leader(s) has(ve) to filter what goes in the final package
<T-Bone> and that archive is intended to reflect what will go there
<Kamion> oh, ok
<Mithrandir> pqm, possibly, then
<Kamion> sorry I sidestepped that with my uploads earlier today then; I was acting in my capacity as installer team leader to fix an issue that was blocking me, if you want to look at it that way
<Kamion> :)
<Kamion> (or if you want me to be pompous ...)
<elmo_> talking of slacking and installer team leads - where's that graphical installer???
<elmo_> \o/
<T-Bone> Kamion: hehe :)
<Mithrandir> elmo_: you want a graphical installer you can use over serial?
<Kamion> yeah, dude, still waiting for that jigdo snapshot archive stuff
<T-Bone> Kamion: actually i think it would be a good thing that you have write access to it
<T-Bone> Kamion: and that you *use* that right :)
<Kamion> I sincerely hope not to have to very often, kernel stuff has a bad habit of eating whole days at a time
<T-Bone> elmo_: heh. Nice test of the livecd indeed. I must confess I didn't think of trying it with a VT100 :)
<T-Bone> Kamion: heh. Welcome to our world :)
* Kamion has a horrible thought about language packs
<Kamion> pitti: I bet you're stripping base-config, aren't you?
<pitti> Kamion: I should
<Kamion> pitti: could you, er, not?
<pitti> Kamion: hm, right, at that time the langpack is not available...
<Kamion> pitti: base-config is the thing responsible for installing language packs
<Kamion> right, exactly
<pitti> Kamion: sorry, didn't think about that
<Kamion> no problem, nor did I until just now
<Kamion> running a test at the moment
<pitti> Kamion: are there any other packages which must not be stripped?
<Kamion> pitti: passwd's debconf templates shouldn't be stripped
<Kamion> (source package shadow)
<Kamion> because they're used from the first stage
<Kamion> that's all I can think of at the moment
<pitti> Kamion: do you think this has time until tomorrow? I'm falling asleep atm
<Kamion> pitti: oh, no massive urgency, just pre-hoary
<pitti> okay, will do tomorrow
<Kamion> thanks
<pitti> Kamion: today I'm afraid I would mess something up, I feel terrible
<Kamion> get some sleep :)
<pitti> okay, shadow and base-config
* Kamion nods
<pitti> good night, guys!
<Mithrandir> Kamion: is there an overview of the different states for a Channel in ssh somewhere?
<dholbach> bbl
<Kamion> Mithrandir: looking
<Kamion> Mithrandir: http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-24.txt maybe?
<Kamion> Mithrandir: the states are really internal to the implementation though
<Mithrandir> Kamion: great, thanks.
<zul> right...ill be back later
<Mitario> jdub, here?
<lamont> Kamion: so I want all the changes on your branch?
<Kamion> lamont: yeah, plus adding powerpc-fix-pmac-cache to 00list-23
<Kamion> lamont: BTW I've uploaded debian-installer with 2.6.10-4, it'll probably need a dep-wait on powerpc
<Kamion> hm, in fact on all architectures, I guess it's in NEW
<lamont> grumble.
<lamont> I thought elmo was going to preseed NEW for an abi rev or 3
<Kamion> speaking of seeds, nobody's updated them for 2.6.10-4
<Kamion> I'll do that now
<lamont> oops.  guess we need to add that to the new ABI checklist, eh?
<lamont> does powerpc-fix-pmac-cache replace anything, or it's just a new one on top of the rest?
<Kamion> the latter
<lamont> cool
<Kamion> specifically it must be on top of stolen-from-head_ppc-sleep
<jdub> Mitario: pong
<lamont> right - all the stolen-from-head patches come first, so that's cool
<Kamion> stolen-from-head_ppc_sleep, rather
<Mitario> jdub, about my pgo feed :)
<Mitario> jdub, sorry to bother you again, but i tought maybe you forgot :)
<Kamion> lamont: there's also linux-meta; though once we upload that, everyone will start complaining about stuff being uninstallable ...
<lamont> right - that's last. :-)
* lamont debates the pros and cons of just uploading with {arch} and .arch-ids/* intact
<Mithrandir> lamont: debuild -i is too much work?
<lamont> Mithrandir: huh?
<Kamion> $ grep arch ~/.devscripts
<Kamion> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i'(?:^|/).*~$|(?:^|/)\..*\.swp|DEADJOE|(?:/CVS|/RCS|/\.svn|/\.deps|\{arch\}|\.arch-ids|\.arch-inventory)(?:$|/)' -ICVS -I.svn -I\{arch\} -I.arch-ids -I.arch-inventory -uc -us"
<lamont> oh - cool
<lamont> dpkg-buildpackage -rfakeroot -S will hit that then?
<lamont> most awesome, fellow dudes!
<Kamion> no, but debuild -S would
<Mithrandir> Kamion: you know you can just use -i and dpkg-buildpackage will just add all that magic?
<Kamion> Mithrandir: yeah, but not in woody; my .devscripts is shared
<lamont> hrm.. never used debuild...
<lamont> in hoary it would?
<Kamion> definitely, warty too
<Kamion> Mithrandir's right that in warty/hoary you should probably just drop the gunk between -i and -ICVS
<Mithrandir> yeah
<lamont> anything besides Kamion's fixes that we need in -23?
<lamont> Kamion: hrm.. -23 can't be an abi event relative to -22, since -22 didn't build on the one architecture that changed.  Right?
<Kamion> lamont: right
<Kamion> lamont: would it be an ABI event otherwise?
<Kamion> (I have a hard time seeing how ...)
<lamont> Kamion: not sure - but I've gotten paranoid
<lamont> so debuild -S -rfakeroot?
<Kamion> debuild does -rfakeroot by default
<lamont> ok.
<ogra> can anybody explain: Depends: python (<< 3) ?
<ogra> this seems to show up in a bunch of python related packages
<Kamion> dh_python
<ogra> yup
<ogra> what does it mean ? i dont think we need to worry about python3 yet
<dholbach> Kamion: how can it be tightened, without writing Depends: explicitly?
<Kamion> it seems generally sane to me as it is
<Kamion> anything with a python module gets a tighter dependency (<< 2.5)
<dholbach> but some other {python:Depends}  are expanded to  python (>=2.4), python (<< 2.5) 
<Kamion> ordinary programs get (<< 3)
<dholbach> ah... hmm
<ogra> oh
<Kamion> which I think makes sense
<dholbach> i'll point metalikop towards this conversation
<ogra> yup
<mxpxpod> jbailey: still there?
<elmo__> seb128: ok to override gnome-mag ubuntu mods?
<seb128> yep
<elmo__> and  I missed gazpacho sorry - I'll get it once it hits a mirror
<seb128> no problem
<seb128> thanks :)
<Kamion> night all
<dholbach> bye kamion
#ubuntu-devel 2005-03-06
<dholbach> brb
<zul> hey
<thom> Mithrandir: *sigh*
<zul> jbailey, ping
<Mitario> good night everyone
<zul> mako: ping
<zul> mako: ive uploaded willy's key to the keyserver 
<mako> zul: um.. ok :)
* dholbach has a sudden dja-vu :-)
<dholbach> seb128: you had the URL of herzi's gaim-encryption?
<dholbach> seb128: i'd check it against dredg's one
<seb128> the URL is in the bug
<seb128> and the package name is in the bug title
<seb128> should be easy to find :)
<zul> must go clean the guinea pig cage
<dholbach> seb128: ok... i'll get to it
<dholbach> *grr* why doesnt darcs->ghc6->haddock exist on any other platform than i386?
<elmo_> it's a haskell compiler written in haskell IIRC
<dholbach> i see
<elmo_> err, tho, it should exist on powerpc
<elmo_> and ia64 and sparc
<dholbach> ghc6 build failed on every arch except i386
<dholbach> haddock only was succesfully built on i386 too
<elmo_> I mean in Debian, it exists on those arches, might be worth looking into why it failed for us
<dholbach> so i can't test the tla-load-dirs python-transition--package (only have amd64)   (contains darcs-load-dirs)
<dholbach> ah ok... sorry - didnt look in debian
<elmo_> might need an, err, helping hand from lamont
<lamont> elmo_: heh
<lamont> dholbach: it doesn't exist because either it didn't work when I tried bootstrapping it, or I didn't try
<dholbach> sounds reasonable ;-)
<zul> svenl: how is the ppc stuff going?
<zul> lamont: the inotify patch is the new inotify patch the one i added before abi brokerage 
<lamont> zul: the inotify patch is the one you sent that was backed out pending the abi roll
<zul> lamont: ok because i was going to add a note to a bunch of inotify bugs to tell the users to use the new kernel that was uploaded today
<lamont> ah, ok
<zul> so ill ask them to try it now
<seb128> inotify should be fixed ?
<zul> i hope :)
<seb128> it crashed my box this morning
<zul> 2.6.10-4-22?
<zul> or 2.6.10-4 
<seb128> -19
<zul> try the newest version
<seb128> yep, I've not noticed it, dunno why
<zul> grr
<seb128> hum
<seb128> it's not in the updated
<seb128> updates even
<zul> umm...okie dokie lamont..^^^
<seb128> grah, that's -4 now
<zul> heh
<lamont> -23
<lamont> seb128: yeah - abi event
<lamont> linux-meta hasn't been uploaded yet - we're waiting for d-i to be there
<seb128> hum
<seb128> the new inotify is booong
<tseng> hey seb128, thanks for helping me fix bug again.
<seb128> the kernel crash before getting the desktop loaded
<seb128> np
<seb128> thanks for the packages :)
<tseng> np :)
<seb128> jdub: here ?
<jdub> yo
<seb128> why are you flooding my logs with audio stuff ? :p
<tseng> oh rock out gtk-sharp2 is in !
<jdub> seb128: haha :)
<seb128> BTW have you read the rhythmbox bug that I've reassigned ?
<tseng> lamont: hey.. if you find a spare moment could you please kick muine 0.8.2 on the buildds, it should be in depwait since gtk-sharp2 didnt make it in first
<jdub> hrm, missed that one; #?
<seb128> jdub: http://bugzilla.ubuntu.com/show_bug.cgi?id=6741
<mjg59> Hmm. That was an interesting night.
<jdub> seb128: bah, no useful information ;)
<seb128> no, but I'm starting to wondering if we should roll back to esound
<jdub> seb128: yeah, same here; lennart has only just come back from egypt
<marcin_ant> jdub: oh you are here
<marcin_ant> jdub: hi
<zul> seb128: still crashes with the 2.6.10-4?
<seb128> no
<seb128> -3 crashes when I umount a device with nautilus open on it
<seb128> -4 crashes when I log in
<zul> gah..frig
<seb128> it: I get some icons on the panels and a gaim connection one
<seb128> and that freeze
<robtaylor> mjg59: it was? ;)
<marcin_ant> jdub: short and last question on this topic to you - what's going on with ubuntu website contest?
<jdub> marcin_ant: coming soon :)
<marcin_ant> jdub: come on :)
<mjg59> robtaylor: Friend DJing at the Kambar tonight. 64 tracks of grind metal in 60 minutes.
<marcin_ant> jdub: the truth is that I ask because I would like to use my project for some other website
<robtaylor> mjg59: ah. i almost went, but got distract by hacking on gst-plugins =)
<marcin_ant> jdub: and I don't know if this contest is abandoned or not.... 
<robtaylor> rather worrienly compiling gstreamer from cvs just caused jadetex explode out of control and hose my machine..
<marcin_ant> jdub: ehhh :)
<mjg59> robtaylor: Well, it was certainly an experience
<mjg59> If you'd gone, you could have introduced me to your myriad of h0t fr13nd5
<robtaylor> mjg59: i bet =)
<robtaylor> heh, at Wake Up Screaming? 
<robtaylor> you dont get hot freinds at WUS ;)
<robtaylor> come down the kambar on fri, though, and i'll see what i can do ;)
<marcin_ant> jdub: can't you tell when - approximately?
<mjg59> I'm in Brussels on Friday
<marcin_ant> jdub: ok, I give up :) I'll wait until 02.28 and then I'll use this layout I sent on contest to another website
<marcin_ant> jdub: night
<dholbach> good night, everyone
<robtaylor> mjg59: doh of course.. enjoy =)
<robtaylor> night all.
<zul> damn power outage
<wasabi> Has anybody given any thought into packages that require a reboot/logoff-or-on after/before installation?
<zul> hey daniels
<daniels> zul: sup
<lamont> tseng: actually, it's bitching about gnome parts being out of date, because only configure knows what rev it wants, instead of the build-depends being correct.  kicking
<tseng> lamont: ok, thanks.
<lamont> tseng: given back on i386 and ppc
<tseng> hm looking at log now
<lamont> tseng: and btw, dep-waits automatically get cleared once the package is in the archive (unless it's a depend: on a virtual package)
<tseng> ah
<tseng> No package 'gnome-icon-theme' found
<tseng> argh
<jbailey> zul: Sorry for the lag.  My evening went differently than I expected it to.
<zul> jbailey: no problem 
<zul> i was just trying a new sata snapshot
<jbailey> snapshot?
<jbailey> Is it developped outside of the kernel?
<zul> nah...its a newish bk snapshot
<zul> jbailey: its supposedly turns on atapi support
<jbailey> zul: The new snapshot, or the driver in general?
<zul> new snapshot
<jbailey> Hmm.
<jbailey> Any idea how long until they bless it?
<jbailey> As I said, my last run in with 2.6.11 was... short lived. =)
<zul> well im going to see if i can get it into our 2.6.10
<jbailey> Ah, cool.
<zul> right im off to bed...night all
<jbailey> zul: 'night!
* tseng kicks mono in the junk
<lamont> I don't suppose Kamion is around...
<bluefoxicy> uh
<bluefoxicy> I ordered my cds in like, november
<bluefoxicy> should they be here yet?
<bluefoxicy> tseng:  still no mono on amd64, still no beagle
<tseng> bluefoxicy: hoary+1, see you there.
<bluefoxicy> tseng:  I thought beagle was gonna be in hoary universe and be main in hoary+1
<tseng> hah, beagle in main? crack
<bluefoxicy> i dun remember, I'll have to dig up the mailing list messages
<tseng> I dont care what the messages say, beagle is too much of a moving target
<bluefoxicy> haha
<tseng> it needs a new dbus every week for some reason
<tseng> dbus is frozen in hoary.
<tseng> see the dilema?
<Amaranth> dbus is a moving target
<crimsun_> my machines running 'linux-image-2.6.10-4-686-smp' [2.6.10-23]  are highly unstable unless I boot with "noinotify"
<ajmitch> Amaranth: true, looks like dbus 0.31 might be out soon
<tseng> crimsun_: another counter point for beagle
<tseng> inotify = crack.
<crimsun_> fwiw, inotify-0.18-rml-2.6.10-16.dpatch was reverted in [2.6.10-18] 
<crimsun_> (updated in 2.6.10-17, reverted in -18, updated again in -20)
<Amaranth> heh
<Amaranth> didn't inotify just get a complete rewrite?
<lamont> crimsun: the version in -20 is the version that was in -17 (which caused an abi bump, and therefore got delayed)
<crimsun_> lamont: right, and I experienced hard freezes when booting without "noinotify"
<lamont> :-(
<lamont> please file a bug with whatever details you can determine
<crimsun_> surely.
<crimsun_> (reverting that patch allows for a much more stable system)
<pitti> Good morning
<dilinger> hey
<daniels> elmo_: er, as for the ddc stuff, there's nothing we can do really ... the kvm's returning entirely valid resolutions
<pitti> argh
* pitti dist-upgrades and now is presented with the postfix debconf stuff
<doko> morning, all
<pitti> Hi doko
<lamont> pitti???
<pitti> lamont?
<lamont> * pitti dist-upgrades and now is presented with the postfix debconf stuff
<lamont> what debconf stuff?
<pitti> lamont: oh, I already fixed that
<pitti> lamont: I had debconf priority to medium
<lamont> ah, ok
<pitti> s/to/set to/
* lamont notices that debian libatomic-ops differs from ours only in that it adds amd64 support.. maybe we should sync it?
* lamont notices the time, turns into a pumpkin
<lamont> g;night all
<pitti> elmo_: vdr sync please
<pitti> elmo_: openswan sync please
<Mithrandir> thom: I knew you would appreciate that bug. ;)
* thom shakes his fist
<mdz> morning
<dholbach> hai
<pitti> Hi mdz 
<pitti> mdz: had a nice vac?
<pitti> Hi dholbach 
<dholbach> hi pitti!
<dholbach> wie gehts? :-)
<pitti> elmo_: xpcd sync, please
<ogra> morning...
<dholbach> hello ogra!
<pitti> Hi ogra
<pitti> ogra: what's the status of the dmidecode patch
<pitti> s//?/
<mdz> pitti: yes
<pitti> ogra: and the hal-device-manager frontend?
<mdz> but I have returned to a houseful of problems
<ogra> you will get both before the weekend....had some real world probs here
<pitti> mdz: I have some more for you, but they can wait until tomorrow
<pitti> mdz: settle down first :-)
<pitti> ogra: that's fine
<ogra> (which results in a decision if i write my resignment today or wait until the end of the week)
<pitti> ogra: oh, you resign from your current job?
<ogra> i think i will have to, eve i dont know frm what i shall live the next three months (they lock ma dole for three months as you know)
<pitti> ogra: "ma dole" ?
<pitti> ogra: you should grab some bounties :-)
<ogra> my new manager i have since november told me monday that i'm not allowed to use any linux at my workplace anymore and no extarnal HW is allowed anymore (no laptop)
<ogra> my dole indeed
<jdub> ouch
<pitti> that sounds bad...
<ogra> but since i was not interested in digital video broadcasting anyway it was only a matter of time....
<dholbach> hi mvo
<ogra> ....he and i had kind of a fight the last months...i guess he won :)
<pitti> Moin mvo
<mvo> hi dholbach, hi pitti, morning all
<Kamion> morning
<Kamion> mdz: up a bit early?
<mdz> morning, Kamion/mvo
<mdz> Kamion: just got in from the airport
<mdz> up late would be more accurate
<ogra> mdz: how is the water situation ?
<ogra> heard bad news about lots of rain again
<mvo> hi mdz, did you had a nice vacation?
<mdz> ogra: it is very bad
<ogra> damned
<mdz> mvo: yes, thanks
<dholbach> crimsun: ping
<dholbach> mdz: where have you been?
<mdz> dholbach: vacation
<dholbach> yes... that's what i already read :-)
<dholbach> but it's ok... settle down :-)
<dholbach> good morning dredg 
<dredg> lo all
<dredg> lo dholbach 
<ogra> hi dredg
<dredg> hi ogra 
<thom> hrm, mutt-ng looks interesting
<opi> mutt-ng?
<opi> some kind of fork()?
<pitti> thom: what's cool about it?
<bob2> they intergated nntp, for one
<opi> nice
<bob2> and a sidebar
<opi> but slrn fans will not be happy ;)
<bob2> tho that sounds kinda ass in a terminal
<jdub> interesting
<opi> point us to the url, man! :)
<bob2> (mutt-ng.berlios.de)
<pitti> a _sidebar_???
<pitti> gulp
<ogra> heh
<dholbach> someone did packages of it
<dholbach> i think it was norbert tretkowski
<dholbach> yes: http://www.inittab.de/blog/debian
<opi> http://mutt-ng.berlios.de/
<pitti> so where are the screenshots? :-)
<bob2> their blog is awesome
<pitti> thom: does that mean that mutt-ng supports gpm now? 
<bob2> especially the bit about being unable to connect to the db
<pitti> bob2: ah, I already thought it worked for you...
<thom> gpm?
<pitti> thom: console mouse
<Treenaks> pitti: also works in xterms :)
<pitti> thom: or what should a sidebar be good for without mouse?
<thom> i know what it is, i'm just puzzled by the concept :P
<thom> dunno, not tried it yet
* pitti is still fastest with c+enter
<opi> I'm trying to build under Hoary
<Treenaks> pitti: 2 sets of navigation keys: 1 for the message list, 1 for the navbar
<Kamion> pitti: totally without having tried it, you could use <some shift keys>-tab to get to the sidebar
<dholbach> crimsun: uploaded your pymad
<pitti> Kamion: sure, but all those keypresses are not faster than two keystrokes
<pitti> anyway, let's see :-)
<Kamion> pitti: yeah. I can kind of see the appeal for browsing purposes, not sure; it would have to be possible to disable the sidebar
<Kamion> in woody's mutt at least doing anything other than "go through mailboxes in sequence" or "go to mailbox whose name I know" is a bit annoying and requires lots of random hitting of c, tab, space, enter
<opi> looks normal
<opi> ie. no sidebar ;)
<opi> pitti: http://www.opi.mnc.pl/muttng.png 
<pitti> thanks
<Kamion> dholbach: BTW you only need to (and probably, should only) use the first three parts of the Standards-Version, i.e. 3.6.1 rather than 3.6.1.1
<Kamion> dholbach: the final .1 represents minor typographical fixes
<pitti> opi: hmm, looks exactly like the normal mutt when unconfigured :-)
<opi> pitti: well, maybe I should tweak .muttng ;)
<dholbach> Kamion: thanks for the hint, will do
<pitti> carlos: ping
<carlos> pitti: pong
<thom> see, the one killer thing that would make me love mutt for ever would be for imap to happen in a seperate thread, so it didn't block the UI
<pitti> carlos: I'm currently at fixing pkgstriptranslations
<pitti> carlos: at that occasion I can also add the translation -> binary deb mapping
<pitti> carlos: if you want
<Mithrandir> thom: the same goes for me with gnus and emacs.  It's supposed to be able to do async I/O, it just doesn't ATM.
<pitti> carlos: that requires changes to your import script to process both types of domains.txt
<pitti> carlos: is that okay for you?
<carlos> pitti: not now
<thom> Mithrandir: *nod*
<pitti> carlos: okay, then I do that later
<carlos> pitti: that change will break current dogfood script
<carlos> you should do it after the script is updated to handle it
<pitti> carlos: okay, no prob
<pitti> carlos: btw, any news wrt the export?
<carlos> pitti: have you added the new domains.txt format to the wiki?
<pitti> carlos: it does not even exist
<pitti> carlos: this was just my first proposal to Mark's question
<carlos> pitti: ok
<pitti> carlos: i. e. put deb name in second column after domain
<bob2> Mithrandir: how does one load the chipset-specific SATA modules?
<bob2> presumably the generic one grabs the device during boot?
<carlos> pitti: feel free to move that question as part of the document
<carlos> pitti: that document explains how the system works
<carlos> or should do it
<pitti> ok
<carlos> pitti: https://wiki.launchpad.canonical.com/CurrentSchedule
<carlos> pitti: there you have what are we working on 
<Mithrandir> bob2: hotplug, I'd think
<bob2> Mithrandir: hm, ok
<Mithrandir> bob2: or possibly by the initrd.
<bob2> right
<pitti> Kamion: I added blacklist support to pkgstriptranslations, preconfigured with "base-config passwd"
<pitti> Kamion: I will tell lamont about the changes
<Kamion> pitti: thanks
<pitti> Kamion: will you upload a new shadow and base-config soon? or shall I do a dummy upload to get translations back?
<Kamion> pitti: I upload base-config fairly frequently, and shadow isn't urgent until I change it to use the passthrough frontend which will require an upload anyway
<pitti> okay, that's fine then
<Amaranth> carlos: I take it I'm not supposed to be able to go to that URL?
<carlos> Amaranth: sorry, it's a private one
<Kamion> pitti: is the change active on the buildds now, or do I need to wait for lamont?
<pitti> Kamion: since it updates the conffile, you need to wait for lamont, I think
<pitti> Kamion: I added a "nostrip" option, if it is not present, all packages will be stripped (like now)
<Kamion> ok, I have a base-config upload to do nowish, but I'll just do it and there'll be a later upload for something I'm sure
<pitti> Kamion: but since lamont changed the conffile, it won't be updated automatically
<pitti> Kamion: yeah, just upload it; another day of broken translations won't hurt :-)
<Kamion> and it's only in expert mode anyway
<dholbach> hm, i can't find documentation on  debian/<package>.install files, does anyone have a pointer towards it?
<Treenaks> man dh_install ?
<Treenaks> at the bottom
<dholbach> Treenaks: an excellent suggestion :-)
<Treenaks> somehow I'm one of the few people who get lots of thanks for saying things that are essentially "RTFM" :)
<bob2> wish I had that superpower
<dholbach> Treenaks: i had a look at maint-guide, developers-reference and debian-policy and couldnt find it
<jdub> thom: what do you think about enabling smooth scrolling by default in firefox?
<jdub> thom: know of any ugly bugs with it?
<Treenaks> bob2: well, you could read the manual...
<abelli> Treenaks: any adjective?
<thom> jdub: meh!
<Treenaks> abelli: friendly manual?
<abelli> Treenaks: yes: )
<jdub> thom: that will make ephy sexy too :)
<Treenaks> jdub: smooth scrolling being ugly is a feature :)
<pitti> thom: was CAN-2004-1316 (buffer overflow in nsNNTPProtocol.cpp) already fixed in your yesterday's ffox upload?
<tuo2> jdub: just installed warty on my sister's second hand computer. She's never owned a computer before, and she's a convert.
<thom> pitti: no; i only got the bug after the upload :(
<tuo2> Good work gyus
<tuo2> s/gyus/guys/
<pitti> thom: ok
<jdub> tuo2: rock!
<thom> pitti: i'm giving up on the window injection backport again, will look in a few
<tuo2> jdub: berrock.
<thom> jdub: so should we (seb) be including those vte patches?
<tuo2> jdub: but it's a pos 333. any recommendation for a faster window manager, or should I go dredge up a 500 from somewhere?
<dholbach> dredg: replied to your mail
<jdub> thom: he's looking at them (and they may go into vte anyway)
<thom> cool cool
<jdub> tuo2: turn on metacity's low resources mode
<dredg> dholbach: argh. that will teach me to do things at 3am.
<dholbach> dredg: don't worry :-)
<tuo2> jdub: which I find where?
<jdub> tuo2: gconf /apps/metacity -> in there somewhere
<tuo2> jdub: cheers.
<tuo2> And if you see any shitty 500mhz boxes going cheap, lemme know?
<stockholm> when is jane around?
<dholbach> hi seb128 
<seb128> morning
<Treenaks> sebz0r
<dholbach> jdub: please ban hostinggeek in #ubuntu-love
<stockholm> lol
<rburton> man i'm always in the wrong channels for amusingly idiots
<bob2> dholbach: please don't inflame it
<dholbach> bob2: i already told him exactly the same thing, some minutes ago... but he just keeps on trolling
<bob2> yes, he is an idiot
<dholbach> [11:07:09]  <HostingGeek> b0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o
<dholbach> [11:08:01]  <HostingGeek> i am on my brothers computer and making him look gay on msn
<stockholm> perhaps one should mail HostingGeek about his brother...
<dredg> perhaps we should /ignore him and stop caring.
<Treenaks> stockholm: maybe someone should mail his brother about HIM
* dredg shrugs
<bob2> he's been a problem for a very long time
<Kamion> elmo: please sync putty 0.57-1 (security fix)
<stockholm> Treenaks: i was assuming that hostingGeek was the brothers nick.
<Treenaks> stockholm: it is not..
<Mitario> hi everyone
<mvo> hi Mitario 
<jdub> dholbach: hrm
<dholbach> jdub: bob2 calmed the situation down
<jdub> yeah
<bob2> haha "calmed".
<stockholm> bob2: what did you do? (c:
<pitti> hey, now we have two elmos :-)
<dredg> 3 :)
<dredg> 1 :(
<pitti> hm, what a pity :-(
<Amaranth> 2!
<dredg> er, elmo bingo? :)
* pitti is confused by the wildly varying number of elmos
<opi> pitti: and cloning is illegal ;)
<pitti> opi: he doesn't clone, he fork()s
<opi> pitti: so, he's resource hungry
<mjg59> Kamion: Around?
<Kamion> mjg59: yo
<mjg59> Kamion: Did you sort the kernel build issues?
<Kamion> mjg59: yup; couple of #ifdefs, see colin.watson@canonical.com--2005/kernel-debian--powerpc-config--2.6.10
<Kamion> (powerpc-config is really misnamed, but hey)
<Kamion> mjg59: lamont's uploaded -23 with that, it built
<Mithrandir> pitti: I might be picking up the tpb bug and rewrite it, if I get around to it.  So if somebody else volunteers in the next week or so, give it to them.
<mjg59> Kamion: Rock. Have you had a chance to see what it does on your ibook?
<pitti> Mithrandir: okay, have fun :-)
<Kamion> mjg59: not yet, waiting to be able to build an ISO with it
<Kamion> adare's currently building d-i, so after BYHANDing ...
<mjg59> Ah, ok
<elmo_> Kamion: when will an install iso for ia64 with the new kernel appear?  not are-we-there-yet-ing, just need to know when i should retry
<Kamion> elmo_: if you ping me when debian-installer_20041227ubuntu15_powerpc has built and you byhand it, I'll start building ISOs then, so +1hr
<Kamion> I'll be out at lunch from 12:30 though
<elmo_> ok
<Kamion> elmo_: did you catch my putty sync request?
<elmo_> hmm, nope not in my logs either
<pitti> elmo_: and my requests? (vdr, xpcd, openswan)
<elmo_> pitti: did them
<pitti> elmo_: thanks
<elmo_> Kamion: done
<elmo_> Kamion: powerpc d-i's in queue/accepted, will go out in next cron.daily in ~10 mins
<Kamion> 10:50 < Kamion> elmo: please sync putty 0.57-1 (security fix)
<Kamion> oh, you got it
<pitti> mjg59: here?
<pitti> mjg59: just tried ppc sleep with new kernel
<pitti> mjg59: now it indeed goes to sleep, but it doesn't wake up again
<pitti> mjg59: if I press a key while sleeping, the hd starts again, but the screen remains black and I can't ping
<Mithrandir> Kamion: do you have trouble with pterm using the altscreen (or what it's called) feature of xterm, but not cleaning up properly?
<pitti> mjg59: anything I could try?
<mjg59> pitti: Hmm.
<mjg59> pitti: What model is this?
<pitti> mjg59: new iBook G4, 7455 CPU
<pitti> mjg59: Radeon 9200
<mjg59> Ok.
<mjg59> So in theory it ought to work, but it plainly isn't.
<Kamion> Mithrandir: hm, don't think I've noticed that
<Mithrandir> Kamion: let me make a screenshot
<pitti> mjg59: well, the older kernels didn't even go to sleep
<pitti> mjg59: this works perfectly now, but it doesn't fully wake up
<pitti> mjg59: at least network and screen don't, so debugging is hard
<jdub> *ouch*
<jdub> i hadn't got the inotify bug until just now
<pitti> jdub: hehe
<jdub> i upgraded to -4, massive hang on login
<seb128> lucky you
<seb128> I don't go to the desktop with -4
<seb128> some icons on the panel
<seb128> gaim starts
<jdub> yeah
<seb128> and BUM
<jdub> same here
<Kamion> jdub: should I make the CDs use noinotify for now?
<seb128> BOOM even
<jdub> must be gamin starting ;)
<mjg59> pitti: Right. I'm looking into that.
<seb128> yeah
<jdub> Kamion: as default grub config?
<mjg59> pitti: I can't find any obvious differences between the patches in the kernel and the ones that were in the old ibook sleep diff
<Kamion> jdub: yes
<jdub> Kamion: means those installers won't get inotify ever, right? :)
<jbailey> thom: Ping?
<pitti> mjg59: it behaved exactly the same with older patches
<Kamion> jdub: yeah
<pitti> mjg59: with the older patches I also tried to stop X and remove all possible modules
<jdub> Kamion: hrm...
<pitti> mjg59: and stop all services
<Mithrandir> Kamion: http://err.no/tmp/pterm-altscreen-fuckup.png has dpkg output overlaid my older ls.
<pitti> mjg59: still no luck
<mjg59> pitti: Ah, which older patches?
<Kamion> jdub: I'll leave it off for now, but if it takes too long to fix I'm going to have to add that
<mjg59> The ibook-g4-sleep stuff from benh?
<pitti> mjg59: I tried the Kernel that Kamion compiled in Matar
<Kamion> Mithrandir: ick. so that was aptitude?
<mjg59> pitti: No idea what that one was, I'm afraid
<Mithrandir> Kamion: yes
<mjg59> Kamion: Do you have any recollection?
<Kamion> mjg59: yes, I can send you the patch
<mjg59> Kamion: Ok, thanks
<Mithrandir> Kamion: I have XTerm.VT100.titeInhibit:  true, though.  Not sure if that affects it
<mjg59> Kamion: Did that one work on your machine?
<Kamion> mjg59: yes. you have mail
<Kamion> mjg59: although at the moment pressing the power button doesn't seem to have any effect
<Kamion> mjg59: I haven't changed the kernel so I think it's a userspace problem
<Kamion> Mithrandir: pterm doesn't look at anything in XTerm.*
<mjg59> Kamion: As in it slept and resumed correctly?
<mjg59> Kamion: But the same kernel didn't work on Martin's ibook?
<pitti> mjg59: right
<Kamion> mjg59: yes, it slept and resumed correctly
<elmo_> Kamion: cool, thanks
<mjg59> Kamion: What spec is your ibook?
<elmo_> mjg59: he has a  powerbook
<mjg59> Ah. Strange, I thought it was an ibook. Right
<Kamion> powerbook g4, the 15" model
<eazel7> hi
<elmo_> IIRC it's a PowerMac5,3 or so
<mjg59> So it'll be a different radeon
<elmo_> mine's a 5,4
<Kamion> machine         : PowerBook5,2
<Kamion> motherboard     : PowerBook5,2 MacRISC3 Power Macintosh
<elmo_> 0000:00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 
<mjg59> I'll handwavily blame video reinitialisation, then
<Kamion> 0000:00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 
<eazel7> I'm trying to compile koffice cvs but it tells me that it requires autoconf 2.53 or newer, but I have autoconf 2.59 installed
<eazel7> how do I continue?
<mjg59> pitti: Does your machine boot if you disable the framebuffer?
<pitti> mjg59: hmm, I have to try
<mjg59> And if so, does it then suspend/resume correctly?
<pitti> mjg59: how do I do this, vga=1?
<pitti> mjg59: or is there a framebuffer kernel option?
<mjg59> pitti: video=radeonfb:off
<mjg59> Kamion: The patch you sent me looks broadly equivilent to the stuff that's been applied, so if you have a chance to test the stock kernel that would be great
<pitti> mjg59: bah, specifying command line args at yaboot doesn't work. Have to try again
<Kamion> mjg59: will do later today
* Kamion -> lunch
<Kamion> pitti: command line args to yaboot should work fine?
<pitti> indeed, it made a difference
<pitti> mjg59: I booted with that argument
<pitti> mjg59: I saw the initial boot messages, but now if I switch to the consoles I don't see anything
<pitti> mjg59: and the thing doesn't go to sleep
<pitti> mjg59: when pressing the power button, at least (this worked before)
<mjg59> Ok, that figures. The framebuffer needs to say that it supports sleep, and it won't if radeonfb is disabled.
<mjg59> Hmm. Not sure of the best way to test, then.
<mjg59> pitti: How about if you do video=ofonly ?
* pitti tries
<pitti> mjg59: I still get the boot logo and normal-sized boot messages (is that right?)
<pitti> okay, consoles are black
<pitti> and it won't sleep
<pitti> mjg59: ^
<mjg59> pitti: Hm. Ok, that's probably consistent.
<mjg59> One last thing to try - can you boot normally (so with radeonfb switched on), log in at the console, stop HAL and try sleep?
<mjg59> pitti: Oh, and what does /proc/cpuinfo look like?
<pitti> mjg59: this failed with the old patch, but I try again
<pitti> mjg59: will tell you when it booted
<mjg59> pitti: No problem
<pitti> mjg59: shall I shutdown X?
<pitti> mjg59: cpuinfo:
<pitti> cpu: 7455, altivec supported
<pitti> revision 3.3 (pvr 8001 0303)
<pitti> 610.30 bogomips
<mjg59> pitti: Yeah, go to the console and do snooze -f
<pitti> PowerBook6,3
<pitti> detected as: 287 (iBook G4)
<pitti> pmac flags: 0000001b
<pitti> NewWorld
<pitti> mjg59: snooze doesn't exist
<mjg59> pitti: Ah. apm -s ?
<pitti> mjg59: that does nothing
<pitti> mjg59: I stopped hal, X is still running, I'm at the console
<mjg59> pitti: Does /dev/apm_bios exist?
<pitti> yes
<ogra> hmm, so hibernate seems to work on my aspire 1520, it just doesnt wake up anymore....
<pitti> mjg59: wakeup without hal and with X from console doesn't work, too
<Treenaks> ogra: DOH
<Treenaks> I'm still waiting for locking suspend scripts
<pitti> mjg59: Caps lock operation works, so it's not completely dead
<ogra> Treenaks: wasnt unexpected :)
* Treenaks waves at thom 
<mjg59> pitti: Hrm, the snooze command seems to be missing from pmud-utils nowadays. How odd.
<mjg59> pitti: I've no idea how caps lock is handled on Macs, sadly. If you do it from the console, when you resume are you able to do ls -R / and get lots of disk access?
<pitti> mjg59: I can also try to play a sound
<pitti> mjg59: I try both
<mjg59> pitti: Ok, cool
<stockholm> pitti: can we make wishes what you play?
<stockholm> does jane silbers surface here regularly or am i waiting for godon (or however that guy was spelled)?
<pitti> mjg59: neither works
<pitti> stockholm: "Insomnia - I can't get no sleep"
<stockholm> pitti: seems fitting enough. (c:
<pitti> mjg59: ctlr+alt+del doesn't work either
<mjg59> pitti: Ok, so it's not waking up. I suspect it's radeonfb being unhappy, but it's hard to be sure.
<Mithrandir> stockholm: she's not in here usually, no.  And it's Godot.
<elmo_> stockholm: I think Jane's out of the country ATM
<stockholm> oh. ok, thanks
<thom> stockholm: and this is not #harrass-canonical-employees, anyway :-)
<Mithrandir> stockholm: try email. (:
<jdub> jane took a plane to the plains in spain
<jdub> i hope it doesn't rain
<jdub> because that would be a pain
<stockholm> thom: i did not assume it was.
<Treenaks> MC Jdub: word!
<stockholm> thx
<Keybuk> jdub: can you not upload the vte-enhanced stuff to Ubuntu?
<jdub> Keybuk: i could
<Keybuk> it'd make a nice change for you to upload something not broken <g>
* dholbach encourages jdub :-)
<Keybuk> not that I'm bitter about my sound not working, or anything
<jdub> well, hey, that's why i haven't uploaded it :)
<jdub> but i've been using it for a while now
<Keybuk> do you have a planned fix for the "polypaudio only works for the first 10 apps" problem?
<seb128> what change is that ?
<Keybuk> jdub: got debs?
<Treenaks> Keybuk: killall polypaudio, set default gstreamer backend to alsa :)
<jdub> Keybuk: yeah
<Keybuk> Treenaks: sound card can't multiplex :-(
<elmo_> Treenaks: alsa is horked on ppc
<jdub> seb128: kjartan's vte test tarballs
<Treenaks> elmo_: oh wait yeah
<jdub> seb128: see my blog
<seb128> jdub: oh ok, stealing my packages
<Treenaks> elmo_: so is polyp on i386 :)
<seb128> jdub: bad boy :p
<jdub> Keybuk: polypaudio isn't working for you?
<Keybuk> jdub: nope
<seb128> for me neither
<jdub> what is it doing?
<seb128> I need to kill it 
<Keybuk> jdub: refuses connections because it already has 10
<seb128> it refuses to work with totem/rhythmbox whatever
<Keybuk> Feb 23 11:41:48 descent polypaudio[9164] : protocol-esound.c: Warning! Too many connections (10), dropping incoming connection.
<Keybuk> etc.
<seb128> probably the same issue
<Treenaks> same for me
<jdub> man, that is weird
<jdub> i have never seen that
<Keybuk> I assume the 10 existing connections are things like the panel, nautilus, applets, etc. as each opens an esound connection for events
<jdub> ywah
* ogra still uses: polypaudio -k && polypaudio -nF /etc/polypaudio/default.pa
<ogra> on every startup....
<seb128> jdub: you should include a "current vte" in the blog
<jdub> seb128: down the bottom
<thom> seb128: the update has that
* dholbach funnily is quite content with polypaudio
<seb128> oh, k
<seb128> rock
<seb128> is he going to do a release ?
<ogra> dholbach: does rhythmbox work for you ?
<jdub> seb128: most likely, yes
* pitti uses all sound stuff (also rhythmbox) successfully with polyp
<jdub> seb128: i was just going to wait until then
<seb128> k
<Keybuk> jdub: polyp/protocol-esound.c line 49-50
<jdub> Keybuk: yeah
<Keybuk> #define MAX_CONNECTIONS 10
<Keybuk> /* Don't accept more connection than this */
<Keybuk> #define MAX_CONNECTIONS 10
<Keybuk> gee, only 10 apps get sound, that's _handy_
* pitti imagines 10 sounds played at the same time
<Mithrandir> why isn't that FILE_MAX?
<pitti> Mithrandir: probably the developer thought that connected apps woudl play sound all the time :-)
<pitti> instead of just beeping every once in a while
<Treenaks> why is it a #define and not a config option? :)
<jdub> Keybuk: i'll set it to 50 :-)
<Mithrandir> jdub: wrong fix.
<Keybuk> jdub: yeah, or you could always just remove the check
<jdub> Mithrandir: sure, but i'll leave it to lennart to fix it correctly
<jdub> line 1048
<tseng> yeah that MAX_CONNECTIONS is causing crack with muine as well
<tseng> there is no error handling hacks for when an esd connection cant be made by gstreamer, so the whole thing segfaults
<tseng> not cool.
<dholbach> ogra: nope :-/
<Astharot> good morning
<dholbach> can somebody tell me, why evolution now types everything backwards?
<pitti> Hi Astharot 
<dholbach> *GRRR*
<dholbach> ynnuf ton si siht
<elmo_> dholbach: haha, really?
<dholbach> it's like some dumb roleplaying spell
<Keybuk> gub ktg zi
<Mithrandir> (:
<Treenaks> 821bes semalb em\
<dholbach> ti kcufnu esaelp ydobemos
<Treenaks> !!! 821BES
<dholbach> ah fine... now it crashed
* dholbach hates re-writing mails
<Treenaks> dholbach: you sure you didn't insert a Unicode "RTL" mark?
<dholbach> don't think so
<dholbach> well the mail i replied to was written on a turkish keyboard
<dholbach> but that's not RTL at all
* dholbach waits the rest of the day for gdb to finish its backtrace
<Treenaks> (hmm.. how to annoy other people.. add a unicode RTL mark after every email you send.. and hope their client doesn't strip it on reply)
<Treenaks> *adds to BOFH lsit*
* jdub attempts to use the new muine
<dholbach> Treenaks: i'd love to have your worries instead :-)
<tseng> jdub: i recommend using alsasink while polyp is smoking crack
<jdub> it is not smoking crack here :)
<jdub> $ muine
<jdub> Segmentation fault
* jdub removes old muine data
<jdub> aha ;)
<Keybuk> ok, why isn't update-grub getting run when I upgrade linux-image-* ?
<elmo_> Keybuk: check /etc/kernel-img.conf
<Keybuk> elmo_: first thing I checked, just has do_symlinks=No and do_initrd=yes
<elmo_> I think you need do_bootloader=yes too ?
<Keybuk> never had it before
<sivang> "morning" all
<dholbach> hi sivan! phase shifting again? :-)
<thom> Keybuk: mine has:
<thom> postinst_hook = /sbin/update-grub
<thom> postrm_hook   = /sbin/update-grub
<Keybuk> what puts those there?
<elmo_> older warty did
<elmo_> new warty doesn't AFAICT
<thom> interesting; time for a reinstall i guess
<Keybuk> weird, have those on hoary array 4 too
* Keybuk fixes
<elmo_> ah, hang on
<elmo_> the machine that doesn't have the _hook stuff is one where grub doesn't work on the CD
<elmo_> so I may be talking complete rubbish (as usual) just  ignore me
<Mitario> mvo, here?
<Mitario> mvo, oh, never mind ;)
<dholbach> hmmm, bug-buddy--called--gdb seems to hang... 
<dholbach> could it be, that  gdb --pid=<pid>  doesnt work when there's another  gdb  attached to the process?
<dholbach> i get   /home/daniel/16799: file not found
<Keybuk> gdb =process pid
<Keybuk> isn't it?
<Keybuk> uh, =process being "path to process binary"
<elmo_> I don't think you can ptrace something twice, I may well be on crack tho
<elmo_> yeah
<elmo_> ptrace: Operation not permitted.
<elmo_> dholbach: that should be the line above the file not found error
<dholbach> damn, so so i'll loose that backtrace
<Keybuk> yeah, U get that too
<Keybuk> I even
<dholbach> i wonder why gdb hanged itself in the first place
<Keybuk> the "No such file or directory" is probably gdb being thick and assuming the next argument must be a filename and not a pid
<dholbach> Keybuk, elmo: you're right
<dredg> hmm... if i want to remove a couple of files after the binary-install (ie just before the deb is created) is it better to use a $packagename.install file to only install selected files, or is it ok to use a couple of 'rm' lines to wipe them out
<sivang> dholbach: tried to shift my daytime, no success yet :)
<dredg> additional: i'm using cdbs, and the rm lines are being added to a `binary-install' section in rules
<dholbach> sivang: go running in the afternoon :-)
<sivang> dholbach: yeah, seririously, I should.
<dholbach> sivang: but i was in bed at 3:00 this morning again :-)
<jbailey> dredg: If it's a single package, so everything's being installed into the package dir, already, use rm.
<jbailey> dredg: If you're Using an .install file anyway, I generally prefer to see it done there (since people don't really expect bits to be rm'd out of the way outside of debhelper files)
<dredg> jbailey: that's what i figured, i just wanted clarification after i got a suggestion from someone else
<dredg> jbailey: previously i had not being using a .install file. thanks for clarifying
<dholbach> brb
<zul> hey
<mjg59> Who should kernel issues be assigned to at the moment?
<Kamion> jdub: can I merge mdadm 1.9.0 past UVF? see Message-ID: <1109157340.421c65dcdb413@testmail-mobilmail-at.dmz.fiber-connect.at> on ubuntu-users
<Kamion> mjg59: I've been giving them to lamont
<mjg59> lamont@canonical.com?
<Kamion> lamont@ubuntu.com; but just type 'lamont' and bugzilla works it out
<mjg59> Oh, neat
<Kamion> how come nobody has ops on #ubuntu-love?
<Kamion> (not registered with chanserv)
<jdub> i do
<jdub> Kamion: yeah, approved
<Kamion> jdub: ah, obviously chanserv magic of which I wasn't aware; didn't know you could do that with unregistered channels
<Kamion> jdub: thanks
<jdub> Kamion: perhaps we should autofile bugs for urgency=high uploads? :)
<jdub> it's a registered channel
<Kamion> oh, silly irssi
<Kamion> '/msg chan<tab>' expanded to '/msg -OFTC chanserv' and I believed it
<jdub> heh
<dholbach> seb128: ping
<seb128> pong
<dholbach> seb128: want to have a look at dredg's gaim-encryption package? it's alright with me now and i'd upload it 
<seb128> if you want
<seb128> url ?
<dholbach> seb128: http://niall.frogstomp.com/wip/gaim-encryption/, if YOU want :-)
<elmo_> Kamion: there's already a bug about that btw
<elmo_> mdadm - but please do it - I need it for the DC in a big way
<seb128> dholbach: looks fine, the debian/dirs file is probably not needed
<abelli> sorry what's it.archive.ubuntu.com?
<Kamion> elmo_: there is? I'll go check
<dholbach> dredg: listening?
<Kamion> elmo_: (just uploaded, btw)
<dholbach> seb128: but it shouldnt hurt either :-)
<pitti> lamont: ping
<abelli> i mean what's the difference with plain archive.ubuntu.com?
<abelli> pitti: ciao... tomorrow: last exam.
<pitti> abelli: good luck!
<Kamion> abelli: none yet, someday perhaps there will be
<abelli> pitti: thanks
<dholbach> abelli: *crosses fingers*
<pitti> abelli: then I can bother you again with the kernel? :-)
<abelli> pitti: ill be so glad...
<abelli> dholbach: thank you... electrotechincs.. bah...
<Kamion> abelli: right now *.archive.ubuntu.com == archive.ubuntu.com apart from a few exceptions, but the installer uses <country-code>.archive.ubuntu.com for purposes of future expansion
<abelli> Kamion: ok thank you
<seb128> dholbach: right, you can put a lot of useless stuff in the package and they that doesn't hurt
<dholbach> abelli: i hopefully had my last exam 1 week ago
<seb128> dholbach: not a good reason to have them though
<dholbach> seb128: hehe :-)
<dredg> ok.
<elmo_> there's a de.archive.u.c now too, and fr.archive.u.c is just pending testing
<seb128> anybody with an evolution's bug to fix for hoary around ?
<seb128> please point them now
<elmo_> (and that covers the top 3 in terms of BW)
<pitti> seb128: yesh
<seb128> (there is an evolution meeting)
<dholbach> seb128: had a strange issue an hour ago - i edited a mail and suddenly typing was all backwards - 2 minutes later evo crashed and gdb hung, couldnt get a backtrace :-(
<pitti> seb128: darn, now I can't reproduce it any more
<seb128> without a backtrace or a wait to get it ...
<dredg> seb128: so just the `dirs' file then?
<seb128> pitti: which one ?
<seb128> dredg: correct
<dredg> seb128: fantastic, cheers
<Kamion> jdub: did you mean to close #966?
<Kamion> (it's still ASSIGNED)
<pitti> seb128: unfiled
<pitti> seb128: however, I have a big wishlist item
<seb128> description
<pitti> seb128: add an option to change the editor
<seb128> I've patched from some gtkhtml crashers
<pitti> seb128: without vim integration, evo is nearly worthless :-)
<seb128> that's not going to happen for hoary, we are in feature/string freezes
<pitti> seb128: I know, but I thought you talk with upstream?
<pitti> seb128: for Hoary+1 it would be cool
<pitti> or whenever
<seb128> that's a meeting to know what is to fix for GNOME 2.10 :)
<pitti> ah, ok :-)
<seb128> but I note the wishlist
<pitti> sjoerd: ping
<sjoerd> pitti: pong
<dholbach> ahhh bradb: ping
<bradb> dholbach: hi
<dholbach> hi bradb - i've told, i had to bug you, if i wanted to close a bug in malone and don't know how .-)
<dholbach> ...i've _been_ told...
<bradb> dholbach: you have to be 1. logged in and 2. either the assignee on that task or the maintainer of the thing on which that task has been filed.
<dholbach> i'm the maintainer of the package in universe, but i guess that's != malone-task-maintainer
<bradb> dholbach: i'm in the midst of making that suck less (i.e. so that malone understands what a team is), but there's other bricks to lay before i get to that.
<tseng> hm there are bugs in malone now?
<bradb> universe is using Malone? :) nobody told me that. :)
<dholbach> bradb: i wont bother you, it doesnt give me sleepless nights, i left it with a comment :-)
<dholbach> https://launchpad.ubuntu.com/malone/bugs/158
<lamont> pitti: sup?
<dholbach> bradb: cool you're working on it :-)
<thom> uuurgh, why on earth is malone bottom up? that's so bizarre
<bradb> if you fixed that in universe, there should be an Ubuntu task filed on that bug (File Against Package...), or we won't be able to track that it was fixed in Ubuntu.
<bradb> s/^/dholback: /
<bradb> er, dholbach even
<Kamion> bottom-up> whoa, debbugs circa 1997
<Kamion> that sucks
<dholbach> bradb: this is something, tim fuchs (the reporter and maintainer(in malone)) should have done, right?
<dholbach> bradb: or did i do anything wrong?
* dholbach just didnt get it
<doko> pitti: pumount did freeze again ...
<Keybuk> ok, uh, so I can't login to my desktop without it crashing hard
<pitti> doko: I know. noinotify
<pitti> Keybuk: noinotify :-)
<bradb> dholbach: The person that knows that the bug exists in Ubuntu should file that as an Ubuntu task. If you're an Ubuntu maintainer, see that the bug exists in Ubuntu, but doesn't yet have a task that is equivalent to say "yes, we need to fix this in Ubuntu", then you should file such a task and, when fixed, mark that specific task as fixed.
<Keybuk> pitti: where do I put that?
<bradb> s/say/saying/
<pitti> Keybuk: it's a new kernel boot option
<elmo_> hum, mpt is now built-in to the ia64 kernel is that a feature?
<Keybuk> and who gets an hour with the sodomotron?
<pitti> Keybuk: Fabio added this option because it is really necessary now :-)
<lamont> elmo_: depends on the kernel vintage
<Keybuk> pitti: but it worked with the old kernel just fine?
<pitti> Keybuk: the best thing is to put it into menu.lst
<elmo_> lamont: -4 ABI
<dholbach> bradb: ah ok... now i understand... thanks 
<lamont> hrm.
<elmo_> what I mean is, why builtin and not a module?
<pitti> Keybuk: well, "just fine" is certainly an exaggeration
<bradb> dholbach: cool.
<Kamion> elmo_: I thought that got un-built-in
<pitti> Keybuk: but at least one could log in, yes
<lamont> elmo_: because module detection wasn't working
<elmo_> lamont: uh
<pitti> Keybuk: btw, the 2.6.11 kernel has the exactly same symptom
<lamont> Kamion: me too
<elmo_> -3 ABI didn't include mptbase modules in a udeb
<Keybuk> why isn't noinotify the default if people can't even log in? :-/
<elmo_> it didn't get a chance to be detected
<Kamion> elmo_: not true for all -3 ABI
<elmo_> -4 ABI seems to have just gone for =y 
<Kamion> elmo_: this is ABI-orthogonal
<pitti> Keybuk: blame lamont :-)
<Keybuk> pitti: I always do; is this his fault too?
<elmo_> okay, forget ABI I'm just too lazy to remember l-s-2.6.10 version numbers
<lamont> elmo_: CONFIG_FUSION=m on all the configs I see for ia64
<zul> blame inotify
<pitti> *chuckle*
<Kamion> elmo_: it got built in temporarily, then I added hotpluggification, it was supposed to have been modularised again
<pitti> Keybuk: I mean lamont should disable it by default in the next kernel
<elmo_> ok, maybe I'm on smack, ignore me for now, I'll try and get a shell at some point
<pitti> Keybuk: he did not mess up the inotify patch if you mean that :-)
<lamont> -17 made it builtin, -20 made it a module again
<Keybuk> who messed up the inotify patch?
<lamont> (and broken until d-i fixes their stuff...)
<pitti> Keybuk: upstream patch :-)
<lamont> Keybuk: zul was doing inotify stuff, iirc
<Kamion> lamont: meh what?
<lamont> but it's from upstream
<pitti> Keybuk: however, it crashed the box from time to time even with older kernels
<pitti> Keybuk: did you never encounter this?
* tseng did, always blamed it on laptop-mode for some reason
<Keybuk> yeah, I actually investigated the crashers this morning
<Keybuk> found I tended to see them when disconnecting USB devices
<tseng> only ever noticed on battery
<pitti> Keybuk: exactly
<pitti> tseng: well, it was fairly heisenbuggish
<pitti> Keybuk: in particular it worked if there was still a nautilus window open for that device
<Keybuk> so I now have noapic and nonotify
<Keybuk> can we have a nobugs kernel option? :p
<pitti> Keybuk: no"i"notify please
<Keybuk> pitti: typo here, got it right in the boot line\
<pitti> ok
<zul> Keybuk: sure...but then again 
<Kamion> $ dpkg -c scsi-modules-2.6.10-4-itanium-smp-di_2.6.10-23_ia64.udeb | grep mpt
<Kamion> -rw-r--r-- root/root    126066 2005-02-23 06:10:36 ./lib/modules/2.6.10-4-itanium-smp/kernel/drivers/message/fusion/mptbase.ko
<Kamion> -rw-r--r-- root/root     98645 2005-02-23 06:10:36 ./lib/modules/2.6.10-4-itanium-smp/kernel/drivers/message/fusion/mptscsih.ko
<Kamion> elmo_: ^-
<dholbach> i guess there'll be an option in reportbug soon, like:  [6]  blame-inotify
<Keybuk> "iz inotify bug"
<Keybuk> ah, I can log in; so I shall be nice. and use lubricant :p
<elmo_> Kamion: okay, sorry, clearly I'm stupid, but why do I see the mpt stuff as part of the initial boot then?
<Kamion> elmo_: maybe it's in the initrd?
<Keybuk> wasn't inotify something jdub advocated?
<Keybuk> that explains it
<thom> harsh, dude
<Kamion> Keybuk: bingo
<Kamion> thom: ... but fair
<Keybuk> when mdz gets back, I'm adding a new step to seed changes
<Keybuk> "Did jdub suggest this?  ...  REJECT!"
<thom> Keybuk: he is back
<elmo_> OH!
<elmo_> gar, rsync -e ssh fails HORRIBLY when the remote end is -ENOSPC
<Mithrandir> elmo_: yes, it does.  Just goes on and on and on.
<Kamion> good, isn't it
<elmo_> not so much, no 
<Kamion> "couldn't make a directory. Oh, what the hell, let's try a few more in case it was just having a laugh. No? Well, I didn't have anything else to do today anyway ..."
<Kamion> I think somebody compiled rsync with -DWHATEVER
<elmo_> haha
<lamont> mdz is back?
<elmo_> hmm, crappy parted won't allow me to set 'raid' on ppc, even in hoary
<pitti> lamont: yes
<Kamion> elmo_: indeed, that's why we need new parted for that; have to go to the shops now but will merge when I get back
<elmo_> Kamion: ah, sorry I thought you said partman
<Kamion> nah, it's a parted thing; dunno if it requires partman changes too, hope (and think) not
<elmo_> I wonder how the hell I got davis using sw raid
<Kamion> the thing is that there's no actual standard way to represent a RAID partition on Mac partition tables
<Kamion> you can put whatever you like in the partition type (it's a string) and mdadm etc. will accept it I think, but parted didn't know that
<Kamion> ditto for LVM
<elmo_> ah
<Kamion> Sven made it use Linux_RAID and Linux_LVM types in parted 1.6.21-1 or so, which were just made up on the spot basically but should work
<elmo_> 4        954.660  78533.437              untitled              
<elmo_> apparently I put .. absolutely nothing :)
<lamont> Kamion: outside of the inotify love, are we ready to roll linux-meta, you think?
<Kamion> you can probably create a RAID partition by hand if you use 'C' (or whatever it is to select the type by hand) and say Linux_RAID
<Kamion> lamont: already done that this morning :)
<lamont> woot
<lamont> well.. wo*inotify*ot
<Kamion> haha
* Kamion -> shops
<lamont> hrm.. need variable fonts
<TreadingSoftly> has anyone else found gnome/kde prone to freezing up Ubuntu shortly after starting, subsequent to dist-upgrade today?
<lamont> TreadingSoftly: boot with noinotify
<lamont> or something like that.. :-)
<TreadingSoftly> lamont: how to i do that, and what will it break (and will i be able to turn it on again later)?
<elmo_> mdadm: error opening /dev/md0: No such file or directory
<elmo_> eh?
<pitti> TreadingSoftly: s/anyone else/everybody/ :-)
<TreadingSoftly> pitti: that's oddly comforting :)
<lamont> TreadingSoftly: pretty sure it's a matter of overriding the boot parms in grub, and it reverts a change back to the non-lethal version
<Mithrandir> elmo_: this is the problem of udev and md -- the device isn't created before the kernel is told about it, and the kernel isn't told about it before it's started.
<Mithrandir> elmo_: you can just mknod it manually, afaik
<lamont> TreadingSoftly: or just boot yesterday's kernel
<elmo_> Mithrandir: score
<lamont> -24 should have things changed
<TreadingSoftly> lamont: ah, will that automatically be the second kernel in the grub list?
<Mithrandir> elmo_: it's know upstream and will be fixed by having the kernel provide something mdadm can twiddle to make the devices appear, but it's not there yet, AIUI.
<lamont> should be
<elmo_> Mithrandir: isn't that going to entirely kill root raid for the installer?
<TreadingSoftly> lamont: cheers, i'll try that
<Mithrandir> elmo_: mm... depends, I think.  the installer uses devfs, and that's fine somehow, I think.
<elmo_> hmm, my klogd isn't
<dholbach> dredg: uploaded you gaim-encryption package *woohoo!*
<TreadingSoftly> hmm when i booted with the recovery kernel, gnome starts loading but then gives up before populating the menus and freezing
<TreadingSoftly> s/freezing/freezes
<lamont> TreadingSoftly: one revision of kernel down?
<lamont> == not recovery kernel
<TreadingSoftly> lamont: just twigged that might be the case: trying that
<TreadingSoftly> trying 2.6.10-3-386
<lamont> that'd be the one you want
<lamont> 2.6.10-4-* has the inotify issues
<TreadingSoftly> lamont: thanks ... 2.6.10-3 seems to work ... touch wood :)
<mdz> lamont: yes
<lamont> mdz: writing email
<elmo_> Kamion: gar, ybin overrides my custom boot-device setting :(
<dholbach> bbl
<pitti> Morning mdz 
<zul> hi mdz
* mvo is away for ~1,5h
<Mitario> cya mvo
<lamont> mdz: mail sent, summarizing the discussion between pitti and I todate
* lamont looks for somewhere to vomit
<lamont> mdz: the only thing missing from the mail is that elmo is working on setting up the test archive so that we can do full-rebuild-testing of hoary on an ongoing basis.  Sadly, it seems other more-urgent tasks keep landing on his plate.
<pitti> mdz, lamont: err: cyrus-sasl is in main for warty
<mdz> ok, it's about 11229th in order in my mailbox
<mdz> pitti: :-(
<lamont> pitti: not the binaries.. :-)
<pitti> mdz, lamont: right, no debs, but still the source is seeded
<pitti> mdz: Kamion and I already agreed to drop cyrus-sasl from the seeds for Hoary
<mdz> lamont: libsasl7 and sasl-bin are in main
<mdz> for hoary anyway
<lamont> zgrep 'Package: cyrus-sasl' dists/warty/main/source/Sources.gz
<lamont> Package: cyrus-sasl2
<lamont> cyrus-sasl2 != cyrus-sasl
<lamont> zgrep 'Package: cyrus-sasl' dists/warty/universe/source/Sources.gz
<lamont> Package: cyrus-sasl
<lamont> pitti: if it had been main, I'd have cared more before release...
* lamont stands behind his assertion of universe status
<elmo_> cyrus-sasl doesn't have any binaries in warty, at all
<lamont> elmo_: right
<lamont> nor is the source in main
<pitti> right
<tseng> lamont: hm whats the assertion?
<lamont> tseng: I assert that cyrus-sasl was a universe package in warty, not a main package.
<lamont> cyrus-sasl2, otoh...
<tseng> ah, right.
<elmo_> boggle
<lamont> elmo_: FTBFS, conflicting build-deps
<lamont> universe --> never resolved
<elmo_> no, I'm boggling at something having created /etc/mdadm/mdadm.conf
<pitti> lamont: oh right, I mixed that up with a different library I recently stumbled upon, sorry
<lamont> elmo_: btw, please make sure that the test archive has warty in it too - I'd like to get a handle on how bad the warty/universe buildability thang really is
<elmo_> lamont: eh, do we have  to?
<elmo_> there's nothing we can do about it now
<lamont> elmo_: I understand that sabdfl is adding 3 hours between 02:00 and 02:00:01 tonight for you  :-)
<elmo_> might as well just deal with them as they come up
<lamont> elmo_: well, it'd be nice to know
* pitti -> supermarket
<lamont> on the bright side, we'd only have to run that suite _once_. :-)
* lamont remembers that he was going to cook breakfast and eat
<seb128> is the daily's amd64 livecd known to be broken ? It doesn't start xorg and hangs on the message saying there is probably a config error
<lamont> seb128: it's pronounced 'inotify'
<seb128> hum
<seb128> inotify is already used at this point ?
<lamont> try adding 'nonotify' to the kernel args
<tseng> has been for awhile
<seb128> on my standard install that hangs when gamin starts, ie on the desktop
<lamont> it's re-enabled in the 2.6.10-4 abi
<lamont> or rather, the newest patch went into -4, and broke itself
<seb128> yeah, I've noticed, it crashes when gamin start :p
<elmo_> ok, partitioning in readline mode is painful
<lamont> <elmo-mode>Kamion: fix that, kthxbye</elmo-mode>
* lamont blames it on the low blood-sugar.  bbiab
<Mithrandir> elmo_: _ew_
<Mithrandir> elmo_: I think you might be the first person to ever have done that with partman
<Kamion> Mithrandir: the installer does not use devfs
<Mithrandir> Kamion: oh, true.
<Kamion> elmo_: udev should create /dev/md0 anyway, but then again mdadm should be looking for /dev/md/0 in a udev world; do you have /.dev?
<elmo_> yes, I copied it from there
<elmo_> I'm trying root raid now, on a different machine
<Kamion> elmo_: root RAID works fine in the installer for me, or did after I made a couple of fixes ...
<Kamion> elmo_: oh, hang on, only /dev/md/0 in the installer probably - dunno
<Kamion> yeah, it's /dev/md0 in the real system
<Kamion> elmo_: you might need to use --auto=yes to mdadm
<sivang> seb128: do you still have the netowrk-admin bug that dropps the auto in interfaces file? (I didn't know what ended with it, went away after we talked)
<elmo_> Kamion: when?
<Kamion> elmo_: on create
<elmo_> Kamion: the problem I was having earlier I solved by mknod-ing (well cp -a, but who's counting) as mithrandir suggested
<Kamion> basically /dev/md0 should always exist, at the moment it's the hook that mdadm uses to create all the other devices from
<Kamion> elmo_: did you have the relevant modules loaded? dm-mod is the relevant one I think
<elmo_> Kamion: I tried mod-probing 'raid1' but it didn't create any devices
<Kamion> hm, yes, same here
<Kamion> weird, that worked for me in the installer
<seb128> sivang: ? I've not worked to fix it
<elmo_> ARGH
<elmo_> I forgot 'server' and now the damn thing is INSTALLING THE WORLD on a headless buildd.
<Mithrandir> how.. useful
<Kamion> mjg59: rock, sleep works perfectly now
<Kamion> although, wow, icons are fucked, I guess that's the big-endian issue with the icon cache
<lamont> Kamion: we need a ubuntu-antidesktop that Conflicts: withe everything brought in by desktop and not base. :-)
<Kamion> lamont: ew :)
<elmo_> /dev/md0 on / type ext3 (rw,noatime,errors=remount-ro)
<lamont> Kamion: just for elmo, mind you. :0
<elmo_> sweet
<lamont> elmo_: Nice
<mjg59> Kamion: Ok, cool
<mjg59> So it's Martin's machine that has problems for some reason
<mjg59> elmo_: If you could test that kernel at some point, that would be sweet
<mjg59> Then I'll push in the swsusp support
<elmo_> mjg59: will do, it's just my only machine right now, so it'll need to be later this evening or so
<mjg59> elmo_: Yeah, that's no problem
<lamont> mjg59: is this with the last round of patches you sent me?
<mjg59> lamont: Yup
<lamont> and do we know how well sleep should work on vaios?
<mjg59> The Vaios I've (personally) tested work. I can't give a general answer.
<mjg59> But there ought to be a decent chance
<elmo_> does grub support SW RAID now?
<elmo_> pitti: !
<elmo_> pitti: I've found what looks like a super obvious candidate for de-rooting
<Treenaks> elmo_: grub does, grub-update seems to barf on /dev/md stuff (at least, in warty)
<elmo_> Treenaks: ok, cool
<Treenaks> elmo_: but I hacked it into submission (in an ugly way), now it boots from RAID1 just fine :)
<Kamion> update-grub got fixed post-warty
<Kamion> but it's still a bit dodgy
<elmo_> ok, elilo obviously does
<Kamion> grub-installer (I think) sets the wrong root device by default
<elmo_> oh, and yaboot uses a separate partition, so that's cool
<elmo_> duh, so does elilo, -ESOSTUPID
<Kamion> it translates /dev/md0 to (hd0,0), which is wrong; it needs to use one of the underlying devices
<Kamion> but you can sort that out from the grub boot menu, and fix it in menu.lst
<elmo_> Kamion: even in hoary?
<Kamion> elmo_: yes, this was in one of my recent tests
<elmo_> ok
<Kamion> elmo_: d'oh, I think the parted lvm/raid fixes for powerpc aren't in current Debian after all; maybe I was too enthusiastic about trying to encourage svenl to give us something stable for sarge
<T-Bone> hey!
<Kamion> hi T-Bone
<Kamion> T-Bone: current daily should have the mptscsih fix
<T-Bone> Kamion: woot! Can't wait to rsync it then :)
<elmo_> Kamion: it does
<elmo_> that /dev/md0 / box is an ia64 with mpt :)
<T-Bone> elmo_: yay, that rocks
<Kamion> bonus
<T-Bone> so we can at last announce ia64 proper install support, or is that still a bit too early? :)
<Kamion> I'd like to at least have us try that OOo hack first
<T-Bone> heh
<elmo_> ugh, I hate how /etc/network/interfaces depends on hotplug support now
<elmo_> it's eeeeeeeeeeeevil
<T-Bone> hell yes :P
<elmo_> or rather automatic upping of interfaces depends on it
<mdz> this australian ETA web service is sketch-o-riffic
<mdz> "please enter your credit card details, and then we'll give you a chance to ask for what you want"
<Kamion> mdz: any idea why 'apt-get update' might kill /var/lib/apt/lists/<cdrom disk label>_dists_unstable_Release.gpg when the CD isn't available?
<Kamion> mdz: it leaves _Release there just fine, but helpfully kills _Release.gpg so that everything shows up as unauthenticated
<mdz> Kamion: it cleans everything in lists that it doesn't understand
<mdz> unless the variable is set which tells it not to do so
<mdz> probably that bit of code needs to be taught about .gpg for CD-ROM sources
<Kamion> I tried setting APT::Get::List-Cleanup, didn't seem to work
<Kamion> er, setting it to false
<Kamion> trying it again now
<Kamion> nope, didn't do the trick
<mdz> weird
<mxpxpod> jbailey: you there?
<Kamion> "the King of Weird dropped by and knighted Evolution" <- heh :)
<thully> hi - what's the status of KDE going into main?  I'm really anxious for this (and would love to be able to download a DVD iso w/KDE and GNOME on it)
<Kamion> mdz: very easily reproducible; 'apt-cdrom add' some signed CD, watch *_Release.gpg appear, 'apt-get update', watch it disappear
<Kamion> thully: pending a few security reviews I believe
<thully> will it be soon? 
<Kamion> it's not on my plate, so I don't know
<thully> it will be for hoary, though - right?
<Kamion> I don't think "are we there yet"-ing it will help :)
<Kamion> that is the intention
<thully> Also - I know weekly dvds are built now - any way these could be done for array releases on weeks with array releases
<sivang> welcome back mdz, at home alrady? :)
<Kamion> thully: only once I have better bandwidth so that I can actually test them before releasing them
<Kamion> that is planned soon
<pitti> elmo_: I'm back, what is it?
<elmo_> pitti: mdadm runs as root, simply to poll a world readable /proc file
<pitti> elmo_: mdadm -F you mean?
<dholbach> re
<pitti> elmo_: cool, indeed
<pitti> elmo_: I'm using that on my server, too.
* pitti grins evily
<mdz> sivang: yes
<pitti> elmo_: nice idea, thanks
<mdz> Kamion: the only surprising part is that it still happens with list-cleanup=false
<Kamion> mdz: oh, it leaves it in /var/lib/apt/lists/partial/
<mdz> Kamion: apt-get update does?
<mdz> or apt-cdrom?
<Kamion> mdz: apt-get update
<mdz> Kamion: has mvo looked at it?  I'm buried
<Kamion> mdz: no, I've only just noticed it
<mdz> Kamion: sounds like maybe fallout from the fix for #4769
<Kamion> I'll file a bug
<ogra> argl.... 
<ogra> seb128 ?
<sivang> mdz, Kamion : how hard will it be to produce an installer cd of current hoary snapshot that already containes the hebrew transaltions and support packages? (as compared to the livecd way which seems easy and straight forward)
<Kamion> #6865 filed
<Kamion> sivang: I'll try to produce documentation at some point along the lines of the live CD customisation document; it's not that hard
<sivang> Kamion: if you'd like, I'd b interested in doing that, so you can toss me the basic part, I will trial the instructions and add comments there.
<sivang> Kamion: (am not talking about the preseeding, stuff, there is also docs for that)
<Kamion> yeah, I realise that
<Kamion> can't be today, though, I'm finishing up soon
<sivang> Kamion: sure, I'll try catching you up tommorow then :)
<elmo_> Kamion: uh, you know  about how you get prompted for language packs 'cos they're unauthenticated, right?
<sivang> Kamion: s/also/already/
<Kamion> elmo_: that's what I was talking about with mdz above; #6865
<elmo_> oic
<mjg59> Good god, it links
<ari> common misconception
<seb128> ogra: pong ?
* lamont notices that the 'rip postfix out of ubuntu base' discussion on ubuntu-devel has pretty much died..  Adds 'remove postfix from ubuntu-base' to his list for later in the week
<ogra> sb128: is there any list of upcoming pygtk deprecations ? its quite annoying to program in a language that changes the syntax every two weeks
<ogra> seb128 ^
<seb128_> ogra: 
<seb128_> <seb128> ogra: what language change every 2 weeks ?
<seb128_> --- Disconnected ().
<ogra> seb128: for example: GtkDeprecationWarning: gtk.FALSE is deprecated, use False instead
<Kamion> lamont: yeah, the earlier the better I think
<lamont> Kamion: was gonna work on getting -24 (with inotify disabled again) in first...
<Kamion> lamont++
<seb128_> ogra: I was expecting this reply
* lamont composes the u-d email now
<seb128_> ogra: first that's one change, it doesn't change that much
<ogra> seb128: i think at least one of these is in every pygtk upgrade currently....(last time it was gnomecanvas)
<seb128_> ogra: second this still works fine, that only display a warning
<seb128_> ogra: third you use a devel branch
<seb128_> ogra: what's the point to a gtk.FALSE and gtk.TRUE where python has a boolean ?
<ogra> seb128_: i know :) it would just be fine to have an overview...a list or something, to be prepared....
<Treenaks> ogra: there is: pygtk-devel :P
<lamont> Kamion: the fun part is going to be the exim-hunt in main.. :-)
<seb128_> ogra: there is no such list
<ogra> Treenaks: when do i read that one ?
<seb128_> ogra: I don't get your issue, just s/gtk.TRUE/True/
<Treenaks> ogra: what I meant was: the development mailinglist for pygtk
<ogra> seb128_: ok, thanks then.... i'll live with it, would just have been nice
<seb128_> ogra: these function are still working, there is no breakage
<ogra> seb128_: i dont like warnings in my programs :)
<seb128_> don't use devel branch
<ogra> heh
<seb128_> or accept the changes
<ogra> i do
<seb128_> that's a working branch
<seb128_> BTW what are you coding ? :)
<ogra> seb128_: i was only asking if you know about such a list....
<seb128_> nop, you can ask on #pygtk @ irc.gnome.org
<ogra> seb128_: hwdb-client and the hal-device-manager changes for it
<seb128_> but I don't think there is a list of planned deprecated stuff
<seb128_> k
<ogra> (adding one button)
<Kamion> woo, network-kickseed nearly works
<lamont> Kamion: woot!
<Kamion> can preseed the root password over the network, yay security ;)
<lamont> Go Kamion !!
<Kamion> lamont: I might ask for nfs-modules.udeb at some point, for better kickstart support
<lamont> Kamion: either tonight, or next week.  'k?
<Kamion> let's make it next week then :)
* Kamion is already late
<lamont> goal for today is a -pre24 branch with all our changes in before 0700UTC today
<lamont> er, tomorrow
<zul> today?!! :)
<Kamion> lamont: oh, "exim-hunt in main"?
<lamont> Kamion: Recommends/Depends: exim[4]  | mail-transport-agent --> R/D: postfix | mail-transport-agent
<Kamion> ah
<lamont> be vewy quiet.  we're hunting exim.
<mdz> lamont: so about the MTA proposal...
<lamont> mdz: yeah
<lamont> ...
<mdz> have you started uploading things yet?
<lamont> pop-con a few weeks back
<mdz> cron/at/anacron are the only ones that really give me the creeps
<lamont> today was some buildd maintenance after elmos tasks, then kernel prep for -24, so we can test it tomorrow.  Then I was going to work on the uploads for postfix moving
<mdz> my gut feeling is that it is hoary+1 material
<lamont> the notifier, or just the 'bitch about it' part of things?
<mdz> the transition as a whole
<mdz> we just aren't likely to have a lot of people testing this stuff without an MTA installed
<lamont> true
<lamont> can I have my local/internethost/... question back to kill the postfix-is-br0ken complaints???
<mdz> that is almost certain to receive a sabdfl veto
<lamont> well, yeah
<lamont> that was _my_ motivator for ripping my baby out of base.
<lamont> and remind me to throw things at jdub :-P
<zul> be my guest
<mdz> lamont: I absolutely agree that it is the right way to go
<lamont> mdz: it would be nice to at least go on the exim-hunt, though, in preparation.
<lamont> well, except that'll be easier with lunchpad
<mdz> we should have done it at the start of the Hoary cycle, but it wasn't raised at the kickoff meeting
<lamont> mdz: please place it at the top of the agenda for hoary+1, then... :-)
<mdz> it's on my list
<lamont> woot
<mdz> it's scheduled for part of a BOF in Sydney
<lamont> awesome
<mdz> preview is in 2 weeks :-O
<lamont> do we get new artwork with the preview this time??? :-)
<lamont> I mean, if not, we have to do something for hte controversy... :-)
* lamont will send recant mail to the mailing list
<mdz> we should have the beginnings of some new artwork, but it is unlikely to be as controversial
<lamont> mail sent
<mdz> thanks
<mdz> it pains me, but we have to be pragmatic at this stage
<zul> bbl
<mdz> thom: ping?
<Goshawk> maybe it is off-topic: does somebody know a way to read from tty1 ? do i treat tty1 as a normal file?
<smurfix> Goshawk: It is. #ubuntu please.
<mdz> jdub: ping, re: gnome-app-install
<mako> Kamion: around?
<Nafallo> is hwdb-gui supposed to do something atm? :-)
<ogra> nope
<ogra> Nafallo: not as long as hwdb-qa is missing....
<ogra> http://www.grawert.net/hwdb_schema.png
<herzi> any1 on ppc around?
<Nafallo> ogra: nice :-)
<herzi> > dpkg -L hicolor-icon-theme | grep png\$ | wc -l >>>>> 0
<herzi> can any1 verify this?
<robtaylor> seb128: do you know anying about gstreamer stuff in hoary randomly complaining that /dev/dsp is already in use? its a little odd as this even happens when i configure my gstreamer sink/src to alsa :/
<elmo_> dear gaim/glib/gnome/whoever upstream, please stop breaking stuff on powerpc, some of us only have powerpc desktops available.  kthxbye.  love, james
* daniels puts 'gaim works' as another X40 advantage.
<robtaylor> seb128: even odder as noone has /dev/dsp open =)
<mdz> dear ppc users, please file bugs, thx
<elmo_> there are bugs?
<seb128> no
<herzi> mdz: of which kinds of bugs are you tlking?
<seb128> there is the icon cache issue
<seb128> but out of this
<herzi> seb128: how do i solve it?
<seb128> robtaylor: use esound
<herzi> or which number is it
<seb128> herzi: solve what ?
<robtaylor> seb128: i.e. polypaudio is borken?
<herzi> "the icon cache issue"
<ogra> herzi: reverse the endian order of your cpu
<seb128> rm /usr/share/icons/*/icon-theme.cache
<herzi> ogra: bll
<seb128> ogra: that's not an endian issue
<seb128> ogra: that's a g_stat/compiler issue
<ogra> oh, ok
<herzi> seb128: does the hicolor-icon-theme contain ANY images?
<seb128> herzi: no, that's a tree
<seb128> themes put images in it
<herzi> ahja
<ari> is the ubuntu xorg repository up on the web anywhere
<herzi> ari: the sources are there
<herzi> apt-get source xorg
<ari> i just want a couple files
<herzi> seb128: http://www.blaubeermuffin.de/images/missing-images.png
<herzi> ari: which ones?
* herzi has got a source tree on disk
<ari> dunno, whatever i need to get it to build on amd64
<herzi> build to a deb or just build?
<ari> just build
<seb128> robtaylor: some people have issues with it
<seb128> herzi: <seb128> rm /usr/share/icons/*/icon-theme.cache
<robtaylor> seb128: ah, actually now i've set my gstreamer sink/src back to esd and use that with polypaudio, evreythings fine.
<mdz> ogra: ping, re: hwdb
<ogra> pong
<mdz> ogra: I just tried hwdb-gui; it looks very nice but doesn't get very far
<robtaylor> polypaudio really is much better than esd, cool :)
<seb128> how ?
<mdz> ogra: I get the first informational screen, then click Forward, and I get a mostly-empty window with an icon at the top
<robtaylor> i can play a dvd without the sound skipping :)
<robtaylor> which was ehy i was using alsasink and dmix before
<ogra> mdz: not yet... it will only be a xml viewer to be reused in other projects.... the backend is hwdb-qa 
<ogra> mdz: http://www.grawert.net/hwdb_schema.png
<ogra> mdz: -qa is not ready yet....working on it
<Nafallo> that icon was a small red x I hope?
<mdz> ogra: I see, thanks
<mdz> Nafallo: yes
<zul> hey
<elmo_> uh
<mdz> jdub: ping, re: gnome-app-install
<justdave> did usplash ever come back, or is that still a work in progress?
<elmo_> I managed to download an entirely corrupt ISO across our LAN.  score.
<YokoZar> ogra: ping
<ogra> yup
<mdz> Kamion: did you make archive-copier smart about the installation DVD?
<mdz> justdave: deferred to hoary+1
<YokoZar> I haven't been on IRC in a while, but I wanted to know if you've combed through my Wine packages at all and if they're fit for Universe
<elmo_> our iso's should have the md5sum in the filename
<ogra> YokoZar: i wrote a mail about it to the ML
<YokoZar> ah, found it
<YokoZar> Ok.  Two things: 1) The only other person active on the Ubuntu lists that knows a lot about Wine is I believe Mike Hearn, who has endorsed my packages (as have the Ubuntu backports users).  No package depends on Wine yet (except Winetools, which I maintain separately and isn't in Universe)  2) I'd like to be on the MOTU team to review it :)
<ogra> YokoZar: you know that i know about both ;)#
<dholbach> YokoZar: maybe the newly installed package review squad will be able to help you there
<ogra> YokoZar: we have two new reviewers now ...
<YokoZar> It's not terribly critical at the moment, though I would like to get on their agenda.  Which is why I've been doing other Wine work in the meantime rather than parading around the channel.  Once we get a Wine release out that runs Half Life 2, though (soon, possibly after Hoary released), it'd be cool to update universe.
* dholbach puts little *censored* marks on the word "backports"
<ogra> YokoZar: ...for me this package introduces a to big change currently, which in my opinion should get mentored by a very experienced developer, the new reviewers Treenaks and Mithrandir can probably help out... but it is also the general decision about moving away completely from debians package structure that scares me a bit... this is a topic big enough i would rather  ask jdub or mdz for 
<YokoZar> hmm
<YokoZar> Yeah there may be political ramifications that I'm sure you're not too happy about.  Maybe it'll all go away if Ove decides to give up maintainership.
<ajmitch> not just political, also pragmatic for people who want to migrate from debian->ubuntu
<ajmitch> ogra: when doko reconnects yet again, tell him I had to run out for an hour or two, and will get back to zope later :)
<ogra> ajmitch: k
<Mithrandir> ogra: we should have a real discussion about whether completely changed packaging is ok -- I'm divided on it.
<YokoZar> ajmitch: I designed the packages so it upgrades cleanly from the Debian ones
<ajmitch> ogra: thanks :)
<ogra> Mithrandir: i was always fearing the moment i would say the following....
<ogra> Mithrandir: ....so we should have a MTU meeting then
<ogra> MOTU even
<Mithrandir> YokoZar: will it sidegrade to a new debian version too?
<Mithrandir> ogra: we should schedule one, then. :)
<ogra> gah
<ogra> ok, i'll care :)
<YokoZar> Mithrandir: Yes, unless you have the wine-dev package installed (the Debian one should put a replaces for it there)
<Mithrandir> ogra: I'm in CET, but I'm in Brussels friday until monday, so I'd prefer it not to be then.
<YokoZar> But no one uses wine-dev except wine developers at the moment, since winelib is kinda experimental
<YokoZar> Or, rather, compiling with winelib.  I'm working on a package that depends on it, though, if I can get it to compile right.
<ogra> Mithrandir: hmm, since Treenaks is at fosdem and i plan to come too, we should probably hold a short beermeeting there ;)
<ogra> Mithrandir: but i think a #ubuntu-meeting meeting next week is early enough
<Mithrandir> ogra: sure
#ubuntu-devel 2006-02-27
<ploum> http://www.fosdem.org/2006/index/interviews/interviews_waugh : jdub interview for FOSDEM (just for info)
<Kamion> doko: so this libgcj-doc package in NEW; does the way it's packaged mean that we have to rebuild it every time the libgcjN-src package changes? this seems a little odd
<doko> Kamion: I first had it in gcj-4.1. It's a 35mb binary ... which takes some time to build and to upload. it only needs a rebuild, when the libgcj interface changes. that was see reason to split it out.
<mdz> infinity: around?
<Kamion> doko: so it only applies to gcj-4.1 at the moment? (presumably accepting it wouldn't affect earlier gcj?)
<sistpoty> Kamion | mdz: do you know if there is an ETA until syncs will be progressed again?
<doko> Kamion: doesn't affect it; can be rebuilt against libgcj6-src, if necessary. the idea is that other java-doc packages have reference this one, so it doesn't make sense to have two libgcj[67] -packages
<Kamion> sistpoty: elmo was asking for example syncs to test earlier, so I assume he's working on them. I have no ETA.
<sistpoty> Kamion: thx... this is really good news :)
<Kamion> doko: hmm, ok. is the documentation build time really a huge proportion of the overall gcj-4.1 build time?
<doko> about 20minutes
<doko> of 4hours
<Kamion> that doesn't really seem to justify splitting off a separate source package
<Kamion> but whatever, I guess it's tiny
<Kamion> I just think we ought to stop this source package splitting at some point
<doko> Kamion: there are no _sources_ in this package, it just has a b-d to libgcj7-src
<doko> the source package itself _is_ tiny
<Kamion> yes, I know, and packages like that are an extra maintenance burden and should only be introduced when absolutely necessary
<Kamion> it's another thing to forget when updating the toolchain
<Kamion> mdz: what do you think?
<infinity> mdz: Am now.
<mdz> Kamion,doko: in my opinion the time to build the documentation is not significant
<mdz> infinity: wanted to talk about splash-down
<infinity> mdz: It works as-is on my hard drive with a change to gdm (needs to be replicated to kdm and ldm, obviously) to call a splash-down helper/wrapper, which invokes usplash.
<infinity> mdz: I was waiting on fixing a bogl bug that's preventing me from daemonising usplash (so it can properly block and detach, rather than backgrounding and praying it's ready), but that can wait.
<mdz> infinity: so it'll land before feature freeze?
<infinity> mdz: There's also the part where "Sending TERM signal to processes" is taking forever and a day in current dapper, which kind of messes with things, but that's not usplash's bug. (and should be hunted down before release anyway)
<mdz> hmm, haven't seen the TERM thing taking forever here
<infinity> Lucky you.  A few people saw it in London, and I see it here on nearly every shutdown/reboot.
<infinity> I guess I should try to trace it, if the problem's not universal.
<doko> Kamion: building it from the gcj source adds a cyclic build dependency (gjdoc -> libgcj). you may argue that we already have one (gettext). So please reject it, I'll add it
<infinity> mdz: FeatureFreeze is in 2 days?  Yeah, I can land the usplash/gdm changes today or tomorrow (at the latest), and clean up the kdm/ldm integration post-freeze, if that's okay with you?
<infinity> mdz: What is Xubuntu using for a *dm?  gdm as well?
<mdz> infinity: yes (the alternative is that we defer it)
<Kamion> doko: a build-dep cycle certainly isn't ideal, but I think when updating Dapper to gcj-4.1 we should probably change the packaging as little as possible in the process
<infinity> mdz: I see no overwhelming need to defer it.  Though if we defer it, it'll probably just not happen at all, since for dapper+1, I'd rather see a push towards "shutdown in 2 seconds", not "pretty graphical shutdown that takes a long time"
<infinity> (No reason why we CAN'T get a desktop system down almost instantly.  Very few things that we "stop cleanly" actually NEED to be stopped cleanly)
<Kamion> doko: rejected, thanks for the discussion
<mdz> infinity: if it doesn't land by feature freeze, it won't be feasible for dapper.  it's long past time we stopped fiddling with the startup/shutdown sequence and finish working out the bugs we already have
<mdz> so I see no overwhelming need to defer it, unless it doesn't make the deadline ;-)
<Kamion> infinity: gdm, according to the Xubuntu seeds I have here
<infinity> mdz: Understood.  I'll try to land it in my spare time in the next day or two.
<infinity> Kamion: Thanks.
<infinity> mdz: Speaking of features (or changes thereof), I've almost completely ignored PHP during this release cycle, but was wanting to ask you if it'd be okay (even if it spills past FeatureFreeze by a week or two) to re-do the PHP configuration so it actually works for everyone (basically, using a conf.d setup that doesn't confuse people, rather than the current debconf configuration that doesn't work in many cases)
<doko> Kamion, mdz: if I update java-gcj-compat to use gcj-4.1, please can you promote gcj-4.1 to main, or should I wait until tomorrow?
<infinity> mdz: The current config relies on you having the interpreter installed before an extension.  So, if you install php50cli, then php5-mysql, then libapache2-mod-php5, you'll only have MySQL support in php5-cli, unless you dpkg-reconfigure, which most users don't know.
<Kamion> doko: if mdz's ok with it, I can do it right now
<mdz> Kamion: fine with me
<Kamion> and if you tell me exactly which binaries to promote
<infinity> mdz: Changing it to make it less broken isn't much effort, but it's effort I've not had the time to spend.
<infinity> mdz: At least, not the spare time.  If I can take a day or two of "paid time", I can fix it up.
<mdz> infinity: I'm less concerned about the effort than about changing it at all, rigid-and-boring etc.
<infinity> mdz: I know earlier, you and Mark cornered me about making PHP less ocnfusing for users, so I would like to fix it.
<Kamion> looks like everything but lib32gcj7-dbg and lib32gcj7-dev? (matching gcj-4.0)
<mdz> infinity: what's consuming your time?  haven't seen activity reports from you
<infinity> mdz: Rigid and borind was why I never changed it in hoary or breezy, but it IS broken, so...
<infinity> s/borind/boring/
<infinity> mdz: These days, it's mostly hunting down missing and failed builds and dealing with the 12-clicks-per-give-back in soyuz, while I help cprov write proper dep-wait handling and continue to file bug to make the buildd interface work.
<Kamion> oh, and not libgcj7-dbg or libgcj7-src either (again matching gcj-4.0)
<Kamion> doko: promoted gcj-4.1 gcj-4.1-base gij-4.1 lib32gcj7 libgcj7 libgcj7-awt libgcj7-dev libgcj7-jar, matching gcj-4.0; please change seeds to match if necessary
<Kamion> mdz: while we're here, anything of mine you're concerned about wrt feature freeze? I think the remaining things on the espresso to-do list that might count as features are the keymap and location/timezone pages, language pack support, and maybe preseeding
<mdz> infinity: at the status update meeting I asked for details about that; I would appreciate bug numbers and CCs for the soyuz issues
<mdz> Kamion: espresso, espresso and espresso
<Kamion> colour me unsurprised :-)
<mdz> Kamion: is Mithrandir working in parallel with you now?
<doko> mdz, Kamion: what about pending syncs and the feature freezy?
<Kamion> mdz: yes
<Kamion> doko: as I said to sistpoty above, elmo appears to be working on getting syncs working
<Kamion> (again)
<mdz> doko: pending syncs will be processed
<Kamion> since I'm insomniac tonight, I'm trying to get the NEW queue down
<doko> nice
<infinity> mdz: https://launchpad.net/people/adconrad/+reportedbugs
<infinity> mdz: Every one of my currently open reported bugs is against soyuz, so that's easy enough.
<sistpoty> Kamion: rock! :)
<infinity> mdz: I can CC you on the ones that are really killing my time (mostly anything dealing with dep-wait handling or batch processing)
<mdz> infinity: thanks, please do
<florian> hi all
<mdz> infinity: activity reports wouldn't hurt either; that's my best chance at knowing what you're up to
<infinity> mdz: Even if they say nothing more than "spent all day wading through the soyuz buildd UI finding failed builds, analysing them, and giving them back"?
<mdz> infinity: especially if they say that
<infinity> Fair enough.
<mdz> because that means you're unable to make progress on your other work
<infinity> mdz: I'm working with cprov to do some of the build-slave side of fixing up the dep-wait stuff to actually work.  Since I used to hack on sbuild and buildd in the Old World Order, that seems to be a fair transition of my job description.
<sivang> mdz: I've made some very good progress with HUB, and worked solely on the last day, however it may happen that I'm still missing some bits to go when the clock hits 23Feb, is their a chance to get a 1-3 days (basically the weekend) more if that happens? (I'm left with finishing the restore functionality, multisession burning, and connecting this to a GUI) it would be a shame for me to see it doesn't make dapper when it would have needed a day or
<jcole> hi guys, who is working on this? --> https://wiki.ubuntu.com/EmbeddedUbuntu
<Burgwork> jcape, afaik, currently nobody
<jcape> Uhh, what?
<jcape> Not me :-)
<mdz> sivang: feel free to continue as you like in universe
<Burgwork> jcape, sorry
<Burgwork> jcole, afaik, currently nobody
<Burgwork> jcole, are you referencing the fsm interview with mark?
<jcole> "GPE will be used as reference graphical environment."
<jcole> florian and france are from #gpe
<Burgwork> jcole, IANAD, but I have heard nary a word of it
<dolson> hello everyone. could anyone tell me if the PAM (and possible bash & glibc) patch for rtprio and nice rlimits is going to be implemented for Dapper?
<Kamion> is there a bug somewhere for it?
<Kamion> including a patch?
<france> jcole: florian is much more involved with gpe.  I do more overall bits and pieces.
<dolson> yes, bug #17348
<Ubugtu> malone bug 17348 in pam libpam0g "Please add support for RT prio & nice rlimits" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/17348
<Burgwork> jcole, check with this person --> https://wiki.ubuntu.com/AndersonLizardo
<sivang> mdz: I do not wish to defer now, I still got a day and some more to work on it.
<france> jcole: the embedded ubuntu page looks good
<Burgwork> france, are you an upstream gpe dev?
<Kamion> dolson: I've assigned the bug to me, and I'll have a look in my next piece of free time (unless somebody else wants to grab it off me)
<france> bootldr, kernel, familiar, hh.org site.
<Burgwork> france, ah
<dolson> Kamion: thank you. this is an important thing for us musicians, so your attention is much appreciated
<jcole> EmbeddedUbuntu wants to use u-boot... "florian: but u-boot is a bad idea, iirc it doesn't support suspend/resume"
<Burgwork> jcole, feel free to edit the spec as needed
* florian is not sure if this changed recently, but iirc Ole checked some weeks ago
<Kamion> NEW queue down to 40; off back to bed
<florian> jcole: Using only one bootloader isn't possible in fact... 
<jcole> "Needs guidance" -> https://launchpad.net/distros/ubuntu/+spec/embedded-ubuntu
<jcole> "Priority:  High. This specification is strongly desired for the next major release, and we have every reason to believe that it can be delivered in that timeframe."
<Burgwork> jcole, floam it is not going to happen for dapper in april, I don't realistically think
<Burgwork> floam, sorry, tab completion
<mdz> sivang: what are you proposing?
<floam> jerk!
<Burgwork> floam, watch out, tone doesn't carry in text
<floam> heh
<floam> noone says "jerk" with an exclamation mark seriously
<ajmitch> floam: many do on irc, sadly
<floam> jerks!
<floam> maybe I'll be more careful
<ajmitch> please do
<floam> now, if I had this house rigged to blow up when I'm mentioned on IRC, because I'm certain the FBI is after me, I might be a little peeved
<Burgwork> jcole, france, florian ask ajmitch if you have any development questions. I am leaving work now
<france> Burgwork: thx
<ajmitch> Burgwork: you had to drop me in it, didn't you? :)
<florian> okay :-)
<mdz> jcole: unfortunately the workflow for spec prioritization in launchpad isn't very good yet; those values won't be reliable until that's been resolved
<mdz> Kamion: is the xpdf in anastacia.txt another instance of the bug you fixed in germinate?  Depends: xpdf-reader | pdf-viewer
<Keybuk> hmm, this router promises to Unleash Networking Power
<Keybuk> I do hope Tony Robbins doesn't come round on Friday to install it
<sivang> mdz: I've emailed you, I have to hit bed now...good night.
<Keybuk> "Firstly, in order to plug a computer into the Business Broadband service you will need to have an available Ethernet socket on your computer, which is not supplied as part of this pack."
<mdz> your computer is not supplied with the unit?
<mjg59> Ooh ooh ooh aigl is SO SHINY
<Keybuk> mdz: indeed, a disappointment I must say
<france> Burgwork: would u send me an e-mail to france@handhelds.org?
<france> Burgwork: with e-mails addresses of the folks involved etc....
<florian> good night
<mjg59> infinity: Version of fglrx in lrm doesn't seem to match userspace
<mjg59> Hilarity ensues
<Keybuk> mjg59: what's aigl?
<mjg59> Keybuk: Accelerated indirect gl
<infinity> mjg59: ...?
<infinity> mjg59: Does here.  amd64 or i386?
<mjg59> infinity: amd64
<infinity> mjg59: Have you been forcefully update to the -16 kernels yet?
<infinity> updated, too?
<mjg59> infinity: I'm on -16, yes
<mjg59> Oh, hang on
<mjg59> Sorry, it just booted -15 again
<mjg59> Ah! I installed lrm for -16, but not the kernel itself. Sorry!
<infinity> Yeah, linux-meta still needs to get through the queue and into the archive, I guess.
<mjg59> Keybuk: On a dist-upgraded machine, I just got an eth0_clashed device
<infinity> Oh, hah, there it is.
<Keybuk> mjg59: does the mac in /etc/iftab match the mac of the card?
<mjg59> Keybuk: Only one card has an entry in iftab, and it matches eth0 rather than eth0_clashed
<Keybuk> can you elaborate a bit there ...
<Keybuk> you have two cards, but only one is mentioned in /etc/iftab?
<Keybuk> and the one mentioned in /etc/iftab has the "eth0" name and not the "eth0_clashed" name?
<mjg59> Keybuk: Correct
<Keybuk> ok
<Keybuk> that's fine then
<Keybuk> it's behaving exactly right
<mjg59> Uhm.
<Keybuk> the card you wanted to be called eth0 is called eth0
<mjg59> This is an odd definition of "right"
<Keybuk> you haven't given the other card a name
<mjg59> Why not then call the other one eth1?
<Keybuk> I will
<Keybuk> the code is just #if 0...#endif'd so I can see it working right first
<mjg59> So by "correct" you mean "incorrect but not implemented yet"?
<mjg59> Ah, ok
<Keybuk> it's harder to discover whether the "eth1" got that name by accident or deliberate action
<Keybuk> but the _clashed thing shows up like a sore thumb and helps me debug when it goes wrong
<Keybuk> mjg59: was this a fresh install/upgrade and reboot?
<mjg59> Keybuk: Nope, upgrade from breezy
<Keybuk> have you rebooted?
<mjg59> Yes
<Keybuk> do you have a /var/log/udev ?
<mjg59> Nope
<Keybuk> bah
<Keybuk> /dev/.udev.log ?
<mjg59> Nope
<Keybuk> mustn't have made it into the archive in time for your update then :-/
<Keybuk> you have udev ubuntu 13?
<Keybuk> heh, that upset ubugtu
<mjg59> Sorry, it's just rebooting again
<infinity> Oh hey, lookie there, NetworkManager works again.
<Keybuk> pitti finished breaking it?
<infinity> Yes. :)
<Keybuk> he was clearly trying out the Keybuk school of uploads
<Keybuk> break everything, then pick up the pieces :p
<Mez> grr...
<Keybuk> right, quick reboot before bed I think
<Mez> If feature freeze is tomorrow... what happens to stuff in the NEW queue before then ? does it just get ignored?
<Mez> or will it get in eventually
<Keybuk> Mez: feature freeze largely concerns specification-related work
<infinity> It'll get looked at.
<Keybuk> if it's in NEW, it's clearly "done"
<Keybuk> it's the date we drop the specs, and start on the bugs
<Keybuk> of course, it's entirely allowed to shove your feature work in at the last minute
<Keybuk> and then legitimately spend the next month working on all the bugs in it :)
<Mez> Keybuk: lol - I just want to get iFolder into universe :D
<Mez> and whoevers' been reviewing NEW lately either has a massive work load or is busy doing other sutff
<Keybuk> actually, I don't think anyone's been able to do NEW reviews with the shift to launchpad
<Keybuk> I only listened with a fraction of an ear on that though
<LaserJock> I thought Kamion was working on NEW today, but I could be wrong
<Mez> Keybuk: lol - good to hear that soyuz has made so many things impossible
<Keybuk> amongst a thousand other things, I suspect, yes
<Mez> (like backports, security uploads, new)
<Keybuk> Mez: not impossible, just teething problems; expected in an archive switch, and will be all shiny and better by the time dapper is done
<Keybuk> soyuz has also made so many things much easier
<Keybuk> like udebs not needing to be BYHANDed every upload
<Mez> lol:D
<Mez> true ... but - meh - backports arent currently possible :D
<Keybuk> *shrug* who cares about backports
<Keybuk> :D
<Mez> Keybuk, many many many users
<Mez> and anyone who doesnt know how to/cant be bothered/cant learn how to package their own stuff
<Mez> If I want anything backported
<LaserJock> Mez: do you have an idea of how many backports there are? I'm just curious.
<Mez> I backport it :d
<Mez> http://packages.ubuntu.com/breezy-backports/allpackages
<LaserJock> Mez: is the policy still no packports for packages that would need changes?
<Mez> LaserJock, pretty much
<Mez> unless we make the changes in dapper and they work in dapper and breezy
<Mez> though that may eventually change with hct 
<Mez> I hope
<LaserJock> hmm, that's a fair amount that you're still able to backport it seems. Everything I wanted to backport had to have dependency changes. Granted it was only 1 or 2 packages
<Mez> LaserJock, yeh - we're pretty lucky with this one...
<Mez> breezy/dapper havent really had any major changes
<Mez> so everything seems plain sailing enough
<mjg59> Are any builds actually happening at the moment?
<mjg59> There's a huge pile of stuff in the queue
<Mez> mjg59, well adare is broken
<infinity> Mez: Which doesn't relate.
<infinity> mjg59: It looks like the buildds are all idle.  <grumble>... Will need a Kinnison or cprov to hunt that down until I have access to look at that stuff myself.
<Mez> but the buildds seem to have stopped building 45 mins ago
<infinity> mjg59: Err, wait.  I don't see anything in state PENDING, except for backports packages..
<Mez> there are backports packages pending 
<Mez> ?
<Mez> o_O
<Mez> thought backport packages werent possible atm
<mjg59> Oh! Sorry, it's the backports.
<infinity> Backports and updates, yes.
<infinity> I think the last code drop was meant to start on the road to gettting -backports and -updates buildable.
<Mez> infinity - where can you see the lists (Pending, NEW etc)
<infinity> So, the stuff is in the queue, it won't build just yet.
* mjg59 wonders where his x11proto stuff has gone, then
<infinity> Mez: https://launchpad.net/distros/ubuntu/+builds
<infinity> mjg59: https://launchpad.net/distros/ubuntu/+source/x11proto-gl/1.4.3-0ubuntu6 for instance?
<mjg59> infinity: Yeah. The one with "no builds recorded"
<infinity> mjg59: Looks like it hasn't even been picked up by the queubuilder yet.  Whether that's a bug or impatience on your part, I'm not sure.
<Mez> infinity: Quick Question to you regarding a bug for unrar-nonfree in debian
<mjg59> infinity: Ah, I see it only hit the queue quite a while after it was uploaded. Probably just me being impatient, then
<infinity> mjg59: Could just be impatience.  The New World Order takes a while for stuff to shove through.
<infinity> Mez: Shoot.
<Mez> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352089
<Mez> infinity that bug I forwarded on to Eugene 
<Mez> who basically replied "unrar isnt being told to do anything - so it doesnt return an error code"
<Mez> RAR and UnRAR without parameters print the help screen and exit
<Mez> with 0 code. It is not a syntax error and I see no reason to return
<Mez> non-zero exit code. I've checked several other command line archivers
<Mez> (Windows versions of arj, pkzip, infozip) and their behavior is
<Mez> the same.
<Mez> is what he replied.
<Mez> Should I close the bug?
<infinity> Mez: But it's being invoked with an unknown options.
<infinity> s/an //
<infinity> I assume, anyway.  "unrar foo.rar" can't possibly be a valid way to call it.
<infinity> I dunno.
<infinity> Mez: I don't see "called with invalid options" being the same as "called with no options", but that's between you, upstream, and the bug submitter.
<Mez> ok
<infinity> Mez: Regarding #328166, he /did/ provide the .rar file as an attachment in the previous comment. :)
<Mez> did he?
* Mez grabs
<Mez> hmm - a lot of devs seem to use a shell which shows the cwd on the right hand of ths ecreen
<Mez> whats used to do this ?
<LaserJock> hmm, are there mirrors for the Flight 4 isos?
<crimsun> here's one: http://se.archive.ubuntu.com/mirror/cdimage.ubuntu.com/releases/dapper/flight-4/
<LaserJock> crimsun: ah thanks. that is much better
<CarlFK> shouldn't dapper-server be a 300mb install?
<CarlFK> not dapper boot:server, but http://cdimage.ubuntu.com/ubuntu-server/daily/current/
<LaserJock> CarlFK: I'm not sure
<LaserJock> CarlFK: maybe they just filled up the space with server goodies :-)
<CarlFK> looks like it grabbed ubuntu-desktop_0.98_i386.deb 
<infinity> CarlFK: I'm not sure I understand the question.  You mean the installation should take 300 MB on disk, or the ISO should be 300MB?
<CarlFK> install on disk
<infinity> CarlFK: Ahh.  Yeah, there's some work to be done to fix the server install right now.  It's known.
<infinity> (And fix the seeds too, so we don't end up with any desktop cruft on the CD)
<CarlFK> ok, I was re-aranging things and thought maybe I got mixed up 
<CarlFK> who  thought that dapper-install-i386.iso and dapper-install-i386.iso were good names for the images?
<infinity> No one thinks those are good names, trust me. :)
<infinity> Kamion's planning to rename things to a state where they can all live happily in the same directory and scrap the subdirectories.
<infinity> I believe.
<CarlFK> what a splinded idea 
<CarlFK> installed dapper-server (and got it right this time) then apt-get install ubuntu-lite-desktop - saw this fly by: /tmp/xserver-xorg.config.37761: line 30: laptop-detect: command not found
<CarlFK> is that worth posting to launchpad?
<crimsun> ...there's a ubuntu-lite-desktop? 
<infinity> Yeah.  It shouldn't be doing that in the config script (or it should be guarded)
<CarlFK> https://wiki.ubuntu.com/InstallingUbuntuLite
<infinity> CarlFK: Please file a bug, so I don't forget about it.
<CarlFK> will do
<crimsun> aha, external repo.
<CarlFK> yes, but I think just one meta-package
<CarlFK> infinity: package name?
<infinity> binary: xserver-xorg, source: xorg
<CarlFK> infinity: https://launchpad.net/distros/ubuntu/+source/xorg/+bug/32422
<Ubugtu> malone bug 32422 in xorg xserver-xorg "xserver-xorg.config laptop-detect not found" [Normal,Unconfirmed]  
<infinity> Danke.
<CarlFK> I am seeing lots of: Fontconfig error: Cannot load default config file
<CarlFK> post?
<infinity> Yes, that will happen on every font installation until fontconfig is configured.
<infinity> A longstanding bug.  Already filed.
<CarlFK> k
<infinity> It's harmless, but someone really should fix it so it stops scaring people (and generating bug reports), I suppose. :)
<Burglaptop> infinity: on bootup, one of the strings says "Will not check root file system". For consistency, it should read "Checking root file system"
<Burglaptop> infinity: didn't know which package I should file that on
<infinity> Burglaptop: s/not/now/, I hope. :)
<Burglaptop> infinity: yes
<Burglaptop> :)
<infinity> (base)adconrad@cthulhu:~$ grep "Will now check" /etc/init.d/*
<infinity> /etc/init.d/checkfs.sh: [ "$VERBOSE" != no ]  && log_action_msg "Will now check all file systems"
<infinity> /etc/init.d/checkroot.sh:               log_action_msg "Will now check root file system"
<infinity> (base)adconrad@cthulhu:~$ dpkg -S /etc/init.d/checkroot.sh /etc/init.d/checkfs.sh
<infinity> initscripts: /etc/init.d/checkroot.sh
<infinity> initscripts: /etc/init.d/checkfs.sh
<infinity> (Helping users help themselves, next on Fox)
<Burglaptop> infinity: shall I file or will you fix?
<infinity> File away.  initscripts is keybuk's baby currently, and I'm swamped.
<Burglaptop> salut highvoltage
<Burglaptop> infinity: do you know if mvo's automatic updater is going to be ready for dapper?
<infinity> Burglaptop: I sure hope so.
<Burglaptop> infinity: less words for me to write to
<Burglaptop> s/to/too
<shaya> is /var/run/mysqld not supposed to be a+x ?
<shaya> regular users can't connect to mysqld.sock
<wasabi> Hey, there any creative way to boot using grub on my system to root=/the/livecd?
<wasabi> Kernel in my /boot, /root someplace else.
<infinity> shaya: Yes, on my bug list.
<shaya> does reportbug file bugs?
<shaya> just did one via it
<infinity> shaya: I guess since I've been asked twice in two days about that one, I should just upload.
<infinity> shaya: reportbug mails bugs to ubuntu-users... A bit suboptimal. :/
<shaya> no one wants integration w/ it it via malone?
<infinity> shaya: Until we get some sort of gateway for reportbug, best to report bugs directly in Malone.
<infinity> shaya: Oh, we want integration, the Malone developers haven't given me an interface to throw bugs at yet, that's all. :)
<dieman> ooo, installable beagle!
<jsgotangco> ?
<pitti> Good morning
<fabbione> bug 32428
<Ubugtu> malone bug 32428 in gconf2 "gconftool-2 turns living people into wormfood" [Major,Confirmed]  http://launchpad.net/bugs/32428
<fabbione> ah here he is
<fabbione> dholbach: 
<fabbione> bug 32428
<Ubugtu> malone bug 32428 in gconf2 "gconftool-2 turns living people into wormfood" [Major,Confirmed]  http://launchpad.net/bugs/32428
<fabbione> please fix.. now
<fabbione> :)
<dholbach> hello fabbione
<dholbach> hello everybody else
<fabbione> dholbach: hey dude
<dholbach> fabbione: that's a duplicate of bug 28744
<Ubugtu> malone bug 28744 in gconf2 "gconftool-2 very slow" [Normal,Confirmed]  http://launchpad.net/bugs/28744
<dholbach> but thanks for the encouragement and faith you have in us.
<fabbione> dholbach: my bug report is better :)
<dholbach> oh well :)
<fabbione> dholbach: ETA for a fix?
* fabbione larts dholbach gently
<dholbach> as seb already said on the other bug: that's not trivial to fix
<dholbach> i can't give ETAs, but I promise to look into it
<fabbione> dholbach: thanks
<sivang> mdz: still around?
<jsgotangco> now that's a bug report
<fabbione> infinity: ping?
<pitti> dholbach: would it be technically possible at all to switch the primary gconf source back to split files?
<pitti> dholbach: since the huge combined file is what makes it so slow, right?
<pitti> dholbach: (on writing, that is)
<dholbach> pitti: I can't really tell. I'd need to look into it.
<dholbach> pitti: since seb worked on it and with the Debian folks
<pitti> Kamion, mdz: you recently approved upgrading postgresql-8.1 to the new microversion; similar microreleases are available for 7.4 and 8.0 with even fewer bug fixes, and they are universe; can I assume that I can update them as well?
<pitti> dholbach: alright, thanks
<Chipzz> I'ld say it's an upstream bug that you can't register/unregister mulptiple schema's at once
<Mithrandir> can't we use a real db backend instead of XML?
<Chipzz> aren't the translations stored in the xml too?
<infinity> fabbione: pong.
<fabbione> infinity: pitti wants to talk with you about ssl-cert grp & co :)
<fabbione> pitti: be gentle ok? :)
<infinity> pitti: Do your worst. :)
<pitti> re
<fabbione> bah he went for breakfast..
<pitti> infinity: so, what now? "Please, Adam, when do you plan to upload ssl-cert, so that I can upload postgresql-common for snakeoil cert?" or "Upload this damn thing by feature freeze, man!" :)
<infinity> pitti: Both!
<pitti> self.split()
<infinity> pitti: You're just missing the group (and group readability of the private key), right?
<pitti> infinity: yes, right
<pitti> will you do any other changes to it which might need modifications for psql?
<infinity> I'll upload for that, plus Fabio's changes in SVN, tonight, then.  And I'll do the other upload (more bugfixes I wanted, etc), post-feature-freeze.
<pitti> that sounds good
<pitti> I'll prepare the new branch then
<infinity> pitti: The interface isn't excepted to change.  If it works now (modulo file permissions), it'll keep working.
<infinity> s/excepted/expected/
<pitti> infinity: it will be 1.0-11ubuntu2, or will you sync against Debian or so?
<pitti> infinity: nice typo :)
<infinity> 1.0.11.0ubuntu1, just to confuse you.
<infinity> (It's debian-native, the version is changing the reflect that... Next Debian upload will be 1.0.12)
<pitti> heh, good to know
<infinity> You can therefore use (>> 1.0.11) and it'll work great for both dists.
<Kamion> pitti: yes, should be no problem with similar bug-fix UVF breaks for postgresql in universe
<Kamion> Mez: I'm working my way through NEW; halved the size of the queue yesterday
<infinity> pitti: postgres doesn't need to be able to read the directory, does it?  Just traverse and get at the file?
* pitti checks code
<Kamion> Mez: and for the record, ifolder3 has been in NEW for 5 hours 50 minutes, so you appear to have complained about the size of the NEW queue about three minutes after uploading it ;-)
<infinity> pitti: Just trying to minimise the scariness of changing the dir from 700, by at least changing it to 710 instead of 750.
<Kamion> oh, hmm, maybe three minutes before. ENOTENOUGHCOFFEEYET
<pitti> infinity: right; it needs to check the presence of that file in pg_createcluster, but that happens as root
* infinity ponders.
<infinity> Ugh.
<pitti> infinity: after that, you only need to be able to follow a symlink to the snakeoil key as postgres
<infinity> That directory ships 700 in openssl.  openssl can't very well depend on ssl-cert, that'd just be wrong.  Maybe the snakeoil private key should be in /etc/ssl/private-snakeoil or something instead. :/
<infinity> fabbione: pong.
<infinity> fabbione: ping, too.
<pitti> infinity: oh shit
<fabbione> infinity: yes one sec...
<infinity> pitti: I mean, I could just alter the permissions of that directory in my postinst (and alter it back if ssl-cert gets removed), but that feels dirty.
<pitti> infinity: with dpkg-statoverride, I presume? or is the directory created in openssl's postinst?
<pitti> hm, no, it's shipped
<infinity> pitti: The directory is shipped.
<pitti> infinity: hm, everyone can already see that this directory exists, and it's no secret anyway; do you see any security implications with 710? (I don't)
<infinity> pitti: Not that it matters, since dpkg doesn't touch directory permission changes, AFAIR.
<pitti> drwxr-xr-x 2 root root 128 2006-02-13 18:54 /etc/ssl/private
<pitti> urgh
<infinity> See? :)
<pitti> I'm not aware of ever having changed that on my desktop
<infinity> You must have changed it when testing pgsql/ssl-cert stuff.
<infinity> I hope.
<pitti> infinity: I did that on my laptop in London only
<infinity> Oh.  Neat!
<fabbione>  4 drwx------   2 root root 4096 2005-12-18 17:10 private
<fabbione> this is on fresh install
<fabbione> so you will need 750 private and chgrp ssl-cert private
<infinity> 710
<fabbione> or something along that line
<pitti> hey seb128 
<fabbione> infinity: you still need to be able to read from it, don't you?
<seb128> hi pitti
<pitti> fabbione: not for postgresql
<infinity> I don't like the idea of a daemon running in the ssl-cert group being able to randomly scan through there.
<fabbione> pitti: ok
<fabbione> infinity: yes, make sense if it works..
<fabbione> :)
<fabbione> and it works for me
<fabbione> so go ahead
<infinity> You don't need to be able to read the directory if you know the filename you want.
<infinity> And we do, by design. :)
<seb128> fabbione: thanks for not deciding the milestone for the maintainer and your gconf one is a dup 
<fabbione> seb128: dholbach told me about the dup.. 
<fabbione> seb128: but it needs to be fixed.. it's unbearable
<seb128> and we decided that the tradeoff installation runtime was ok
<fabbione> who decided?
<seb128> mdz
<fabbione> i will talk with him
<seb128> sure
<fabbione> i find it amusing that building a kernel takes me less time than upgrading a package
<seb128> anyway we are in a tricky position to revert now
<seb128> and that's not a good time to rewritte gconf backend to use something else than xml
<fabbione> seb128: i have another idea instead
<pitti> people installing with espresso won't feel this pain so much, right?
<fabbione> but i wanted to discuss it with you, dholbach, pitti and infinity 
<seb128> which is?
<fabbione> well there are several packages that needs to run always the same set of commands during upgrades
<fabbione> that is scrollkeeper, gconftool-2 and others...
<seb128> pitti: there is no such much slowness, out of gnome-applets and gnome-games which ship a lot of schemas other packages are mostly fine
<pitti> fabbione: dpkg triggers ;)
<fabbione> these 2 are the ones that bites the most
* mvo thinks of .... 'triggers'
<seb128> fabbione: no, gconf doesn't act that way
<seb128> scrollkeeper rebuild the base
<fabbione> seb128: please let me finish one sec :)
<Chipzz> fabbione: no, dpkg triggers won't help you for gconf
<seb128> gconf writes key
<fabbione> Chipzz: as above
<seb128> fabbione: you can"t run "gconf base building" after installation
<fabbione> if you let me finish
<seb128> k
<fabbione> each of these commands have their own sintax and "features"
<Chipzz> seb128: talking about "base building", is a solution needed for gstreamer plugins?
<seb128> we .xml has to be parsed to write every key, I doubt any of your "tricks" will change that
<seb128> Chipzz: no
<Kamion> pitti: not as much, no
<fabbione> so building a generic framework is not easy
<seb128> s/we/the
<Chipzz> seb128: cfr recent thread on desktop-devel wrt to startup-time
<seb128> Chipzz: we didn't get any bug about that
<fabbione> but what can be done is at least to get run gconf or scrollkeepr all in one go
<fabbione> or
<seb128> and I've no startup time issue here
<fabbione> many times as required in a loop
<Kamion> fabbione: the gconf and scrollkeeper cases are really very different
<seb128> fabbione: scrollkeeper can, there is a db-update comment, not gconf
<fabbione> to at least take advantage of the file cache in ram
<Kamion> scrollkeeper's very easy to divert away and just run once at the end
<Kamion> gconftool is called with radically different arguments each time, so isn't so easy
<seb128> gconf has to be called on every schemas
<seb128> and that would not make it faster to call it one time after installation
<fabbione> please read the lines i wrote as last before both of you have gone to a problem i am aware of
<Chipzz> Kamion: not radically different arguments, just with a different filename every time
<fabbione> seb128: it will make it faster if you call it in a loop with all the different args, instead of calling it N times in the middle of an upgrade
<seb128> fabbione: I've read everything you said, there is no file cache in ram acting here
<Kamion> fabbione: I read them, doesn't help particularly given that it's being called from different packages and can't easily be consolidated
<fabbione> Kamion: that can be fixed changing the way in which gconftool-2 is called.
<seb128> fabbione: your slowness it probably one one or 2 packages that takes several minutes to process and already " call it in a loop with all the different args" in fact
<fabbione> queuing up the request, tracking how many and what requests have been done
<Kamion> fabbione: sorry, wontfix, not putting obscene hacks in the installer for this.
<fabbione> and the last package flush the queue
<Kamion> this is too hacky
<fabbione> Kamion: did i mention installer anywhere? i am talking about something different
<seb128> and will not be useful
<Chipzz> for schema in "$@"; do
<Chipzz>   if [ `echo "$schema" | cut -c1` != / ] ; then
<Chipzz>     schema="$schema_location"/"$schema"
<Chipzz>   fi
<Chipzz>   if [ -e $schema ] ; then
<Chipzz>     HOME="$tmp_home" GCONF_CONFIG_SOURCE=xml:merged:/var/lib/gconf/defaults \
<Chipzz>         gconftool-2 "$option" "$schema" >/dev/null
<seb128> that's what we do atm right
<Mithrandir> seb128: do you happen to know what part is taking so long?  I suspect it's parsing the monolithic file, BICBW.
<Chipzz> snippet from /usr/sbin/gconf-schemas
<seb128> Mithrandir: it is parsing the file
<Mithrandir> seb128: so if we used another backend, say a regular database, it should go faster?
<Mithrandir> seb128: (I realise this may be dapper+1 material, though)
<seb128> Mithrandir: probably but
<seb128> <seb128> and that's not a good time to rewritte gconf backend to use something else than xml
<seb128> right
<Mithrandir> seb128: agreed.
<Chipzz> Mithrandir: how do you propose to store translations in a db? that will get very ugly very fast
<fabbione> this is a torture for users...
<Mithrandir> Chipzz: depends on what database, really.  If you use sqlite, say you use one db per language.
<Mithrandir> Chipzz: (just as an off-the-top-of-my-head suggestion)
<seb128> fabbione: users upgrade once from one distro to next one, if that takes 5-10 extra minutes they can live with it
<Chipzz> I agree that it's torture
<dholbach> ... since their resulting system is faster.
<Chipzz> but I think this is very much an upstream issue
<seb128> Chipzz: if that was a were state you would be in trouble :p
<Chipzz> several issues as a matter of fact
<seb128> s/were/war
<Mithrandir> seb128: it also means installing new packages will be a lot slower, though.
<Chipzz> seb128: what exactly were you commenting on? :)
<seb128> Chipzz: what torture is exactly
<fabbione> seb128: it's not just install or upgrades from release to release. As you might notice, we all test gnome everytime you upload...
<seb128> fabbione: I agree the installation time sucks, but there is nothing easy we can do to fix it
<seb128> changing the way gconftool is called will not change the way it parses the xml for every key it writes and the number of keys stay the same
<fabbione> seb128: does gconftool-2 spend time on I/O or CPU processing?
<fabbione> how do you access this xml file basically...
<seb128> fabbione: I parses a 10-20M xml file an hundred of time
<mvo> seb128: could we make it write some (very basic) status information? maybe something like "updateing schemas ..." and a "." every 10-30s or something? so that people see it's still alive? 
<seb128> it parses I mean
<mvo> I'm thinking especially about older machines where it can take (literally) minutes 
<fabbione> seb128: yes clearly i never saw you in front of my pc parsing XML :P
<seb128> ;)
<mvo> fabbione: we are talking about *magic* seb here
<mvo> he is a bit like the hogfather ;)
<fabbione> seb128: do you think there is space to optimize the parsing code?
<fabbione> like reducing the amount of times the file get parsed?
<seb128> that's possible yep
<seb128> there is place to put a cache or something imho
<fabbione> seb128: so why are you still here talking to me instead of fixing it ? :P
<seb128> like if a schemas has 20 keys to write, not parsing the base 20 times
<fabbione> that would speed up a lot :)
<seb128> but that's not the sort of change that would be trivial to do and I don't want to break gconf for dapper
<fabbione> seb128: does gconf2 comes with a testsuite?
<seb128> no
<fabbione> or is it on the wave of "test at your own risk"...
<fabbione> i guess the latter.. suck
<seb128> there is some tests with the tarball but I would not rely on it only
<seb128> I've started to make some change before distro sprint in fact, I think we could speed it up by a factor 2 quite easily but that will still be quite slow ...
<fabbione> seb128: can you point me to the function that does the file parsing?
<fabbione> at least you can save me the time to learn all the code in there
<infinity> mvo: Output from postinsts (unless REALLY necessary) is just ugly, IMO.  We need to get rid of what we have, not add more.
<mvo> infinity: why? people who are interessted in it like to see what is going on. everyone else should use a frontend that hides the dpkg/script chatter anyway
<seb128> fabbione: I don't know that codebase sorry. The xml parsing stuff are probably to gconf2-2.13.5/backends/xml-entry.c
<infinity> mvo: But where do we draw the line between "useful output" and "too much"?.... I could put all sort of "doing this:" and "doing that:" in my postinsts, just cause I think it's nice to know what's going on.
<mvo> infinity: sure, that's all a bit blurry. but my machine showing: "confiugring gnome-panel-data" for 10min can make me think that it had died. some sort of progress indication for really long runing tasks is usefull IMHO
<fabbione> seb128: ok
<infinity> mvo: Policy 3.9 starts out with "The package installation scripts should avoid producing output which is unnecessary for the user to see and should rely on dpkg to stave off boredom on the part of a user installing many packages. This means, amongst other things, using the --quiet option on install-info."  While the example given (install-info) is obviously dated, the point still makes sense.
<Kamion> policy kind of assumes that packages won't take forever and a week to install
<Kamion> (rightly so, I think)
<sladen> mjg59: I have a report of HP NWXXXX with copmletely different special key mappings
<infinity> mvo: Fair enough, though I've not noticed any of it taking 10 minutes, just taking "a bit longer than I'd like".
<sladen> mjg59: https://wiki.ubuntu.com/LaptopTestingTeam/HPNW8240/Kubuntu and grep for "Hi Luka"
<Treenaks> sladen: my 8240 is normal
<sladen> Treenaks: is that /exactly/ the same model number?  could you drop to a console and run showkey -u  and see if you see the same things
<sladen> Treenaks: for bonus points, try with   /etc/init.d/hotkey-setup stop   too which will tell us if we already did the remapping
<Treenaks> sladen: I have a NW8240
* raphink is having a great fun with compiz on Dapper Flight 4 
<Treenaks> sladen:         Product Name: HP Compaq nw8240 (PG818ET#ABU)
<Treenaks> sladen: (that's demidecode)
<mvo> infinity: ok, you are right. it takes only 3min to install gnome-panel-data on my dated p3/1200.
<raphink> I can't seem to get this transparent windows effect 
<raphink> dunno where it is
<infinity> mvo: Ugh.  I can see what all the fuss is about then.  3 mins is still way too long.
<pitti> raphink: the window borders (title bar) are
<infinity> mvo: I take back my comment then.  Progress output would be an okay stopgap until the real problem is addressed.
<raphink> pitti: yeah I know the title bar is transparent
<raphink> pitti: but I've seen a video that shown that you could make any window transparent
<pitti> raphink: anyway, this is #ubuntu matter 
<raphink> pitti: yeah you're right 
<raphink> hehe
<sladen> infinity: "real problem" is gconf2-tool just being stupidly slow?
<infinity> mvo: Though I could also use your argument against you.  People using frontends will get a progress bar and won't think their machine is hung, so only the "hardcore" will notice the pause, and they should be smart enough to use other tools to see that the postinst is still running. :)
<infinity> sladen: Indeed.
<Chipzz> sladen: real problem being gconf being retarded in multiple ways ;)
<infinity> pitti: If you didn't catch it on -changes, go forth and ssl-certify...
<infinity> pitti: (Unless you're waiting for binaries to test against... Wimp)
<pitti> infinity: yay, thanks
<Pygi> hi all, sorry about yesterday :-/ may somebody please say what was the conclusion about GAIM and the protocols?
<pitti> infinity: yes, I never upload a p-common without running the 20 minute test suite in a real system
<infinity> pitti: And that's why I love you.
<mvo> infinity: point taken :) currently those very long postinst make synaptic open the terminal window with the dpkg stuff and show them to the user because synaptic dosn't detect any activity on the terminal and assumes something is wrong. that is easy enough to fix with a bigger timeout though
<pitti> infinity: for being a wimp? :)
<infinity> pitti: No, for actually testing stuff.  You may be the only one. ;)
<pitti> infinity: I seriously hope I'm not 
<seb128> mvo: what package does that take long on your box with gconf?
<seb128> mvo: gnome-applets-data take ~1min here
<infinity> pitti: Based on the number of build failure I get daily, I can only assume lots of people don't really test the sources they're uploading (though they may test the fixes they're including, then not test the final source upload)
<infinity> pitti: After years as a frustrated buildd admin, that's precisely why I always do anal things like "source build -> clean chroot -> binary build -> test -> sign and upload original source build"
<mvo> seb128: gnome-applets-data, but it takes less when it's in the file cache (i.e. when it is re-run)
<seb128> what file cache?
<pitti> fabbione: hmm, I just installed dovecot, and now: 'dovecotError: Can't use SSL certificate /etc/ssl/certs/dovecot.pem: No such file or directory'
<pitti> fabbione: isn't it supposed to use the snakeoil cert?
<fabbione> pitti: eh, yes? i did change that a long time ago...
<fabbione> and tested..
<pitti> fabbione: the commented path in dovecot.conf indeed points to the snakeoil one, but it seems that the internal default doens't
<pitti> fabbione: if I uncomment the two lines, it works
<fabbione> but ssl is not enabled by default...
<fabbione> i will check again.. 
<fabbione> thanks dude
<pitti> (ssl-{cert,key}-file
<pitti> fabbione: hm, I just enabled 'protocols = imaps' in the file
<pitti> fabbione: that might have triggered it
<fabbione> yes i am checking right now
<infinity> Yeah, the compiled in default should definitely change, then. :)
<infinity> (Does anyone else think a compiled-in default for an ssl cert path is dumb?)
<pitti> fabbione: ah, I think you forgot to patch ./src/master/master-settings.c
<pitti> fabbione: I'm working on the package anyway (security update), so I can fix that quickly
<fabbione> pitti: ah ok.. thanks
<fabbione> that would be lovely
<pitti> fabbione: actually, I'd rather just change the default dovecot.conf to uncomment the settings
<Pygi> infinity: well ,can't we use the ssl cert path out of some external file? 
<pitti> that seems much cleaner to me
<pitti> fabbione: what do you think?
<fabbione> pitti: i would prefer matching internal defaults
<infinity> pitti: Change the compiled-in default too.  It will confuse people if they break their config a bit.
<pitti> fabbione: alright, will do that then
<fabbione> thanks
<pitti> 'Office for Complication of Otherwise Simple Affairs' -> lol
<Kagou> hi
<mvo> infinity: btw, anything about the auto-dist-upgrade-test thing yet? 
<Kagou> is there a procedure to submit patch to close a bug in package ?! Do i "just" send my patch to bug report in launchpad ?
<infinity> mvo: Absolutely nothing, but if you but me the day after tomorrow (ie: after feature freeze), I can build the chroots and we can start testing it.
<infinity> mvo: s/but/bug/
<mvo> infinity: thanks, that would be great
<infinity> mvo: Day after feature freeze is when I get to jump into "mass rebuilds and other testing stuff" mode, so this fits well.
<Mithrandir> Kagou: click the "add attachment" link to the right.
<Kagou> Mithrandir, ok. 
<Pygi> so, what was the conclusion due to GAIM and breaking TOS yesterday?
<fabbione> pitti: sshhhhh! that was a surprise :)
<slomo> hm, will we get a list of all packages in NEW in the future like there exists for debian?
<Kamion> I believe that's in the plan, yes
<slomo> nice :)
<jdub> BUENOS DIAS, AMANTES DE LA LIBERTAD!
<seb128> morning jdub :)
<Pygi> mornin'
<Seveas> buenos dias, seor jdub
<pitti> jdub:  , !
<Seveas> who should I bug about https://launchpad.net/malone/bugs/32440 ? sounds worthwile to me
<Ubugtu> malone bug 32440 in samba "3.0.21b is newer and fixes memory leaks" [Normal,Unconfirmed]  
<Kamion> Seveas: infinity
<Kamion> note that he's already subscribed to the bug
<Seveas> ah, right
<Seveas> missed that 
<Kagou> please tell me what to do after : 
<Kagou> apt-get source package
<Kagou> cd package
<Kagou> -> do my modifications
<Kagou> --> how create patch to send to bug report ?
<pitti> Kagou: dch -i
<pitti> Kamion: type some comments
<Seveas> Kagou, dch -i ; debuild -s ; debdiff
<pitti> erm, Kagou ^ (sorry Kamion)
<Seveas> debuild -S that is
<infinity> Seveas: I'm sure we'll get the new version, don't fret.
<Kagou> thanks pitti & Seveas 
<Seveas> infinity, I'm just triaging, didn't notice you were already subscribed. Thanks for the info, I'll add it to the bug
<pitti> Kamion: debdiff on the old and new .dsc then
<Seveas> pitti, fix your <tab> ;)
<pitti> Seveas: I did actually, just autofingers
<infinity> Seveas: Samba's microreleases (a, b, c, etc) are bugfix only, so the UVF exception should be easy to get.
<slomo> mdz: the gst 0.10 swfdec plugin is now in gstreamer0.10-plugins-bad if you still need it :) but should move to good soon anyway
<seb128> slomo: don't ship it with bad so please
<seb128> slomo: or we will have to Conflicts/Replace over Debian when it moves
<Kamion> bit late
<slomo> seb128: we'll have these replaces anyway as hopefully everything from bad moves to good/ugly... but sure, i can remove swfdec from bad as it should be in good very soon
<seb128> slomo: if you already ship it no point to drop it, it's done
<Kamion> lp_archive@drescher:/tmp/cjwatson$ dpkg -c ~/ubuntu/pool/universe/g/gst-plugins-bad0.10/gstreamer0.10-plugins-bad_0.10.1-0ubuntu1_i386.deb | grep swfdec
<Kamion> -rw-r--r-- root/root     20336 2006-02-22 01:37:00 ./usr/lib/gstreamer-0.10/libgstswfdec.so
<seb128> I would appreciate if you coordinate with me next time for such case though :)
<seb128> no big deal anyway
<slomo> seb128: i thought that would be fine with you as we obviously have the replaces-problem with everything in bad sooner or later
<seb128> slomo: right
<slomo> seb128: so maybe a general "Replaces: gstreamer0.10-plugins-bad" in good and ugly will solve it forever...
<seb128> slomo: it would be wrong though
<slomo> seb128: why? good/ugly should be always allowed to replace stuff from bad
<seb128> slomo: dunno, that feels wrong, that should be used when it actually replaces something, no because one of the next versions might move something again
<dholbach> janimo: xubuntu-artwork - YAY! :)
<mvo> janimo: the grub splash stuff went away again (just FYI)
<atie> hi
<janimo> dholbach, which part of it you like ? 
<janimo> mvo, I noticed, good thing I did not rush to make a xubuntu splash :)
<dholbach> janimo: i just saw the gdm theme
<janimo> dholbach, that's nice indeed
<dholbach> janimo: what about the rest of the desktop, dependencies still broken?
<janimo> it's just not (yet) consistent with wallpapers, default theme, usplash
<janimo> dholbach, no it should install fine now
<mvo> janimo: yeah, sorry for it, but it made too many problems
<janimo> if not it's a bug
<dholbach> janimo: so i can dist-upgrade and drop all the stuff it wants to remove?
<janimo> dholbach, yes :)
<janimo> ping me if anything is wrong
<dholbach> i query you
<sladen> lamont: HP suck.  They buy other Compaq.  Re-brand the dmi-signatures to include "HP", but don't actually change the way the laptops work...
<janimo> mvo, on the subject of using gconf for update-manager, did I understand corrcetly that you would be ok with another config layer as long as it works?
<janimo> I am thinking of upgrading issues it might cause
<janimo> but would be nice to use python's own INI format, to avoid all the gnome-python dependency
<mvo> janimo: yes
<janimo> mvo, yes for upgraduing issues or for INI format? :)
<mvo> janimo: for both :) 
<janimo> :)
<mvo> janimo: upgrading shouldn't be that bad, we can extract the stuff with gconftool
<janimo> if you think ini would be fine and you're overloaded I may take a look this week
<mvo> janimo: that would be nice, thanks. try to keep in sync with glatzor, he wants to do some work on the software-properties dialog
<janimo> mvo, ok is your bzr archive the place to start and follow enough?
<janimo> anyway the changes should be unintsrusive
<mvo> janimo: yes, my bzr repo is fine
<pitti> doko: xmlsec1 approved
<sivang> hi all
<doko> pitti: thanks
* sivang hugs pitti 
<pitti> hey sivang 
<Kamion> Mez: did you really mean to say "Architecture: i386" in the libflaim control file?
<Kamion> Mez: simias seems to install files in /usr/web/ and /usr/etc/; please fix that to conform to our standard filesystem hierarchy
<Kamion> actually, I'll send mail
<Kinnison> I need a "Foo happened, did you want it to, yes/no []  tickybox-do-not-tell-me-again" dialog (ideally in glade) -- anyone know where I can find one to cadge?
<sivang> pitti: what do I need in order to promote dar into main other then a main inclusion report? It looks pretty fine in debian bts, has a responsive and a nice reelase cycle upstream...
<pitti> sivang: mainly that, a good main inclusion report with those references, upstream/debian bug research, etc.
<sivang> pitti: okay. 
<pitti> sivang: no vulns in the past :)
<sivang> pitti: ah, okay, I would have to search the CVE db. is there any other place to search besides the CVE?
<pitti> I'll do that, don't worry
<pitti> sivang: I meant that I just checked
<sivang> pitti: ah - I know it's very cool piece of software :)
<pitti> yes, indeed
<simira> hi marilize :)
<marilize> hi simira, how are you?
<simira> marilize: good. Trying to figure out some decent preseeding for Ubuntu installations in my company
<simira> marilize: and you? How is your work going?
<pitti> Riddell: how does keep manage to backup system files (/etc and the like)? will it run as root, or is it only meant for user files?
<marilize> simira; great thanks, just having allot of wireless problems today :) still enjoying the new job?
<simira> marilize: so far, so good :)
<Riddell> pitti: it's only ment for user files
<Riddell> although you can run it as root if you want to
<pitti> Riddell: ok, that's good; so no potential root escalation by putting bad files into your ~ :)
<pitti> Riddell: thanks
* pitti waves to Yagisan 
<simira> marilize: when can I order Dapper cd's?
* Yagisan waves back to pitti
<Riddell> simira: in about March
<simira> Kamion: ping
<pitti> Riddell: approved then, thanks
<Riddell> pitti: great
<marilize> simira: not yet, 
<simira> who ate launchpad!
<marilize> Will let you know as soon as we have the dates sorted :)
<Riddell> Kamion: keep for moving to main, konserve for universe
<simira> marilize: got a mail last week, a guy who wanted 2000 cd's, within 3 work days...
<marilize> simira: dapper? 
<simira> marilize: Breezy. But still a bit too short notice
<mjg59> sladen: No, the behaviour of the 8240 should be identical to all the other business machines
<mjg59> (Yes, HP laptops since the merger have been Compaqs)
<marilize> well, depends where he is., and what he want it for.....he should mail me if his still interested...info@shipit.ubuntu.com
<simira> marilize: well, the 3 days are past now, so ut's over due anyway. And he's in Norway, couple of miles outside Oslo. I told him to get back to me a bit earlier next year :)
<Kamion> simira: hi
<marilize> simira:  you can just tell people to contact me directly at the shipit address,  in Europe 3 days should have been ok if we send it high priority :)
<mjg59> sladen: The issue here is that KDE doesn't have the keybindings setup. That's all.
<Kamion> Riddell: will promote keep when the publisher's finished; can't demote konserve until after you've updated kubuntu-meta
<simira> marilize: I will remember that
<Kamion> Riddell: (keep promoted)
<Kinnison> If you press the close button on a yes/no dialog is that yes or no?
<marilize> simira:  :)
<simira> Kamion: we're having some trouble setting locales on an automatically installation of Breezy, I am talking to Tollef now.
<simira> Kamion: if we don't get it to work, I will put a bug on it, when launchpad is back
<mvo> ping freeflying
<mvo> freeflying: I would like to talk about scim. after installing all the required stuff and logging in with a chinese locale I don't get a scim panel. ctrl-space does nothing etc. I only get it when I start scim manually. any idea about this?
<Kamion> pitti: you still haven't ever edited the skim inclusion report page; is it approved? shall I just promote it now?
<pitti> Kamion: yes, please
* pitti edits page
<Kamion> chmj: kdescreensaver-aasaver produces an empty binary package; please fix; also please set a Section in debian/control (kde would be suitable)
<Kamion> chmj: (well, empty apart from files under /usr/share/doc/)
<chmj> O.o 
<chmj> Kamion: ok, will ahve a look 
<Kamion> thanks
<freeflying> mvo: pong
<mvo> freeflying: I would like to ask about how scim is activated for a user after the language-support-zh pack was installed. I had to start scim manually after that
<freeflying> mvo: you shall set the IM variable in system or you own direstion
<glatzor> hi mvo
<mvo> hey glatzor! thanks for your mail
<sladen> mjg59: no.  It's a Compaq...  Which is the reason that you're baffled that it doesn't work and that the vendor string is 'HP Compaq'
<mjg59> We're talking about the 8240?
<sladen> mjg59: yes
<mjg59> It's an HP
<mjg59> In the same way that all machines in that range are
<mjg59> HP's business laptop team came from Compaq
<mjg59> The scancodes are identical. KDE just does nothing with them.
<sladen> mjg59: the only keycode they have in common is for 'Presentation'.  All the other keys match Compaq Presario keycodes  . o O {...}
<mjg59> sladen: This doesn't match the previous reports I have of the 8240
<mjg59> (more than one)
<glatzor> mvo: i've lost the url of the spec. could you please point me to the wiki page?
<glatzor> i don't find it anymore using the search, too
<mjg59> It also doesn't match the HP BIOS documentation I have
<mjg59> sladen: Hang on a moment. e05f is /identical/ to the HPs for sleep.
<mjg59> We don't bother mapping it because that scancode already goes to KEY_SLEEP
<mvo> glatzor: https://wiki.ubuntu.com/RepositoryDialogRedesign
<tseng> mark makes his best ELER apperance yet
<tseng> http://geekz.co.uk/lovesraymond/archive/cancomical-lynchpad
<sladen> mjg59: is that a 1-in-128 fluke?  Or because acpi_fakekey is sending it from an ACPI event?
<mjg59> sladen: No, it's because that's the mapping Microsoft use
<mjg59> The HPs send identical sleep and volume scancodes to MS keyboards, which is also the mapping the kernel uses
<sladen> sanity starts to prevail
<Treenaks> mjg59: I've seen keyboards that claim to have 'MS XP Standard hotkeys: No driver required'
<mjg59> Yeah
<glatzor> mvo: have you heard anything new about gtkmozembed?
<mvo> glatzor: unfortunately not, I'm subscripted to the upstream bugreport and Diziet did  a lot of debugging on it, but currently no solution
<Yagisan> Treenaks: last time I checked, there was no such thing as a "MS XP Standard hotkey"
<Treenaks> Yagisan: Apparently, a there is a small subset.
<sladen> I would guess it's whatever the MS Pro desk-replacement sends
<Kinnison> mjg59: I've got the battery info notify going
<glatzor> mvo: should i implement the "add sources.list" thing?
<mjg59> Kinnison: Rock
<Kinnison> mjg59: Also I'm about 70% of the way to the 'are you sure about suspend' dialog
* Kinnison is really struggling with the async nature of gtk though
<sladen> Kinnison: for g-p-p ?
<Kinnison> sladen: yes
<ohoel> can anyone inform me about who maintains laptop_mode?
<mjg59> Nobody
<mjg59> We've moved to laptop_mode_tools
<ohoel> well, that then ;)
<mjg59> Probably me - what's up?
* mvo goes to get some food
<viviersf> Mithrandir, ping
<Mithrandir> viviersf: yes?
<zul> heylo
<viviersf> if i put extra scripts into : /usr/share/initramfs-tools/scripts/casper-bottom/
<viviersf> and i just rebuild initramfs will it just go into it ?
<ohoel> mjg59: sorry, had a bit of an X-reset accident ;) - laptop_mode status reports my lid status as closed while the laptop is "open"... isn't that incorrect?
<mjg59> ohoel: Uhm. laptop_mode? If so, that's obsolete.
<ohoel> I set gnome-power-manager to suspend on lid close, which led to an immediate suspend
<Kamion> mjg59: is xorg-air targeted to be merged into xorg-server at some point post-dapper?
<mjg59> Kamion: That's the long-term plan, but it's unclear how long it'll take
<viviersf> hey Mithrandir ?
<ohoel> mjg59: laptop_mode is provided by laptop-mode-tools isn't it?
<mjg59> Oh, so it is.
<ohoel> I suppose I should file a bug for this, but want to include anything you deem relevant at first go
<mjg59> Sorry, I was thinking of laptop-mode.
<mjg59> (argh)
<mjg59> ohoel: What does /proc/acpi/button/lid/*/state say?
<giftnudel> and he disappeared into nirvana ...
<Kamion> anagramarama wins the prize for the hardest package in today's NEW queue to type
<ohoel> no idea why I keep pressing ctrl-alt-bckspace
<mjg59> ohoel: What does /proc/acpi/button/lid/*/state say?
<ogra> Kamion, why? its only 4 letters ...
<ohoel> mjg59: closed
<ogra> ohoel, no 5 actually
<ogra> grmpf ...
<ogra> *oh
<ohoel> (LID0)
<mjg59> ohoel: That would be the problem, then
<bronson> What happened to the multimedia systems selector in Dapper?
<ohoel> bronson: menus-revisiteds victim, I suppose
<ogra> bronson, alt-f2 gstreamer-properties
<ohoel> mjg59: anything I can supply to help find the root cause?
<jdub> hrm, in add printer, there are no vendors/drivers listed
<bronson> ogra, thanks.
<mjg59> ohoel: Sounds like a kernel bug of some sort, but it could just be your hardware being rubbish
<bronson> Guess I'll file a bug on Totem so its error message can be rewritten.
<ohoel> mjg59: it's pretty much the standard intel centrino-style stuff... does breezy have laptopmode?
<tseng> it does, but its disabled per default
<ohoel> could see if it's a regression of sorts maybe
<jdub> oh wait
<jdub> it is
<Kamion> desrt: around?
<jdub> but after aaaaaaages of 100% CPU mess
<Kamion> desrt: where was the timezone widget stuff you were pointing me at? ISTR there was some GNOME component for it that was better than "cut-and-paste it from Evolution"
<Kamion> or if anyone else happens to know (hi, Mr. GNOME Release Manager!)
<janimo> Kamion, libegg?
<jdub> Kamion: it's in evolution
<janimo> I know that has a lot of cut-n-paste stuff
<Kamion> janimo: doesn't appear to be packaged?
<jdub> Kamion: and gnome-system-tools has copied it out nicely
<jdub> libegg is a cut-n-paste cvs module
<jdub> it's not in there
<janimo> Kamion, I thought you meant is there a gnome lib which is used for cut-n-paste not inclusion, but I think that's not what you meant
<Kamion> right, no, I meant specifically whether there was one currently containing the timezone widget
<janimo> don;t know about that sorry
<Kamion> jdub: ah, interesting, I might start with gnome-system-tools then
<Kamion> to see how to factor it out
<jdub> mjg59: mmm, xorg-air
<jdub> mjg59: too scary to patch xorg proper atm?
<jdub> mjg59: (didn't we have most of the patches required already?)
<Kamion> poo, no python bindings there either
<mjg59> jdub: It requires xorg HEAD, which is potentially ABI incompatible with existing drivers
<jdub> ahr
<Treenaks> oo. more X love
<mjg59> Install it, point /etc/X11/X at /usr/bin/Xorg-air, switch on composite in xorg.conf, mravel
<mjg59> I'll upload libcm later on
<azeem> mjg59: is this air stuff only coincidently named similar to acclerated_indirect-0-0-1, or is this the same?
<seb128> Kamion: I uploaded " evince (0.4.0-0ubuntu4.1)" to breezy-updates some time ago, do you know if it's waiting on approval somewhere?
* Kamion tries to work out which of evolution and gnome-system-tools has a newer e-map
<mjg59> azeem: It is precisely that
<Treenaks> mjg59: how about new metacity?
<mjg59> Treenaks: Yeah, I'll look at that
<Treenaks> cool
<Kamion> seb128: yes, it's in the breezy unapproved queue, I'll grab mdz after feature freeze and sit down and go through that stuff
<azeem> mjg59: ta
<seb128> Kamion: ok, thank you. That's a 1 line crasher fix, should be easy to approve ... :)
<Kamion> right, but we'll do it all at once
<seb128> works for me
<seb128> thank you
<Kamion> I have a bit too much to do right now I'm afraid
<seb128> that's fine
<jdub> Kamion is over-caffeineated :)
<mjg59> azeem: Basically, it just needs mesa with the texture binding protocol additions and an updated x11proto-gl
<seb128> an user was just pinging on the bug where I mentionned the upload asking if the package is coming soon
<mjg59> azeem: Other than that, I just built it using the existing packaging for Xorg (except disabling xnest, xvfb and so on)
<azeem> cool
<Kamion> I'm over-mapificated
<mjg59> Much easier than Xgl
* Kamion decides that gnome-system-tools is a better starting point; yay for cut-and-paste code that's the grandchild of the original :-/
<sivang> Kamion: what are you using the g-s-t code for? espresso?
<Kamion> sivang: yeah
<Kamion> need a country/timezone selector
<jdub> mjg59: you are a trooper :)
<mjg59> jdub: You may buy me beer in Brussels
<jdub> mjg59: going to roy's on friday?
<mjg59> jdub: Yeah, but might be quite late
<azeem> it's going to be sooo full in there 
<mjg59> (Like, 11 or so)
<Treenaks> Hm.. I'm only going to be there on Saturday
<jdub> mjg59: ok
<sivang> mjg59: already planning to package aigl ? :)
<mjg59> sivang: Already done
<mjg59> Dude
<mjg59> Get with the times!
<mjg59> It's just gone through NEW
<jdub> if you're not on dapper-changes
<jdub> YOU'RE NOT ON DAPPER
<Treenaks> oh
<sivang> heh, sorry guys, it's been hard tracking latest stuff while I'm stuck head over hills in HomeUserBackup..you're my only source of info currently :)
<zakame> mjg59: w00t
* sivang raises up from the chair to only go to the lavartory and get an occassional slice of pizza
<sivang> mjg59: which technology sis better in your opinion?
<Kinnison> mjg59: 45-suspend-warning-dialog, 46-sleep-button-combo and 90-suspend-warning-and-sleep-button-impl are pretty much finished :-)
<mjg59> sivang: Xgl allows cooler effects. Xair works better.
<mjg59> Kinnison: w00t
<ogra> Kinnison, WOW
<Riddell> Kamion: germinator.plantSeed() now takes an extra argument, breaking the *buntu-meta update scripts
<infinity> Kamion: UVF exception for the new Samba is a no-brainer, I assume?  I may as well fire that one off before bed, since it's minimal effort.
<Kinnison> mjg59: in fact, I think that finishes off all the g-p-m notes from last night, leaving g-ss and g-s-d ones
<infinity> Kamion: 3.0.21a -> 3.0.21b, bugfixes only.
<mjg59> Kinnison: Rock
* Kinnison builds a source package to stuff on rookery
<mjg59> jdub: The g-p-m UI has got a lot of love
<sivang> mjg59: then I'm in for the cooler effects :)
<mjg59> OH ARGH I HATE YOU ALL
<mjg59> (libcm doesn't have a copyright notice)
<infinity> mjg59: Surely that message was meant for #freedesktop, then. :)
<Kinnison> mjg59: Here, have some UI love...
<Kinnison> mjg59: http://people.ubuntu.com/~dsilvers/are-you-sure.png
<mjg59> Kinnison: Looks good
<mjg59> Kinnison: You probably want to check the HIG over whether the checkbox is in the right place
<Kinnison> mjg59: I think I'm gonna remove the "You have chosen to..." because it's a bit odd
<mjg59> I have a feeling it should be aligned with the text, but I'm not sure
<Kinnison> mjg59: the checkbox alignment is my main concern, the rest is spaced according to a similar dialog I found which lacked a checkbox
<infinity> Kinnison: Do you have a harsher "DENIED" message for people who try to enable suspend where it just plain can't work (not enough swap, etc)?
<Keybuk> shouldn't those buttons be "Enable Suspend" and "Don't Enable Suspend" ? :)
<infinity> The buttons should be "EEK!" and "Bring it!"
<infinity> But that may not agree with the HIG.
<Keybuk> PUSH THE BUTTON!
<Kinnison> Keybuk: I am not a HIG expect
<Kinnison> Keybuk: If you want me to change the buttons I'll change them
<Keybuk> Kinnison: me neither
* Kinnison thought it might be safer to ask a yes/no question and present yes/no buttons :-)
* Kinnison removes the "You have chosen to..." text because it's pointless
<Keybuk> I liked the VIG better
<Keybuk> (Vorlon Interface Guidelines)
<pitti> Kinnison: the only thing I know about HIG is that yes/no buttons are bad
<Kinnison> infinity: No, if they choose to turn it on, it's their own fault :-)
<Keybuk> all dialogs, no matter how complex, only had two buttons
<Treenaks> Kinnison: 'Enable suspend' 'Do not enable suspend' ?
<Keybuk> "Yes" and "It is too late for the pebbles to vote"
<Kinnison> pitti: then why are there stock yes/no buttons?
<Treenaks> Kinnison: the keyword for Gnome/HIG buttons is 'verbs'
<Keybuk> Kinnison: backwards compatibility
<infinity> Kinnison: Oh wait, that's suspend, not hibernate...
<pitti> Kinnison: good point :) But essentially you should still know what you do if you only see the buttons without any text
<infinity> Kinnison: I was thinking hibernate (which should not allow you to do it if it can't be done.. Windows won't let you hibernate if you don't have enough disk space, for instance)
<Kinnison> infinity: need to think about that afterwards
<Keybuk> Kinnison: also the dialog should NOT have a title or icon
<Kamion> Riddell: oh well, better update *-meta, sorry
<Keybuk> in fact, no window decorations of any kind
<Kamion> Riddell: I'll do it
<Kamion> Riddell: although, hm, I guess I can make it backward-compatible
<Kamion> infinity: link to upstream changelog please?
<pitti> infinity: could you please check out something for me? according to https://launchpad.net/+builds/+build/170296, amarok was built on ross on the 20th, but it's not on http://ross.buildd/~buildd/translations/20060220 (or any later directory)
<pitti> infinity: so, I'm a bit concerned about losing random tarballs (we didn't get any amarok tarball since the start of february, e. g.)
<pitti> infinity: the build log says that the tarball was generated
<infinity> Kamion: http://us4.samba.org/samba/history/samba-3.0.21b.html
<jdub> mjg59: what do you think about making ctrl-alt-bksp launch the logout dialogue?
<Riddell> Kamion: I'm just not sure what to put in as the new seedrelease attribute
<infinity> Kamion: There's one pretty vile memory leak in winbind that will bring a machine to its knees within a few days of uptime.  The rest of the bugs are less critical, but certainly look buggy enough to me.
<mjg59> jdub: Difficult
<Kamion> infinity: ok, I can't say I follow all of that; if you're comfortable with it, do it but keep a close eye on bugs
<infinity> Kamion: Always.
<jdub> mjg59: they're far apart, but there are some contexts where the fingers are close by, and wow does it fuck people off
<mjg59> jdub: It's caught by the X server
<jdub> mjg59: hrm, suck
<mjg59> We could just disable it by default
<jdub> mmm, true
<j^> does pressing the power button show the shutdown dialog?
<Treenaks> but that would break stuff for lots of people
<Mez> Kamion: ping
<Kamion> Mez: hi
<mjg59> j^: It's configurable in gnome-power-manager
<Mez> Kamion: regarding Simias
<Treenaks> When X gets stuck and won't terminate normally, I ctrl+ alt+ bs it
<infinity> pitti: Hrm, I don't see sbuild's "publishing translations" message in that build log...
<Mez> Kamion: The programs are written so that they install to $PREFIX
<Kamion> Mez: your .install file says usr/etc/*
<Mez> and all the stuff in $PREFIX/bin has to have access to $PREFIX/etc 
<Kamion> Mez: as I understand it, that will cause dh_install to install files to usr/etc
<Kamion> which is bad
<Kamion> Mez: every other package in the world copes
<Mez> Kamion: this package is dumb
<Kamion> the traditional solution is to set sysconfdir=/etc or similar
<Kamion> Mez: I'm sorry, but I'm not letting a package past NEW that ships files in /usr/etc/
* infinity blinks.
<Kamion> Mez: I realise it may take a bit of work, but you'll have to fix it
<infinity>  /usr/etc?  Nice.
<Kamion> or get help from upstream if need be
<Kamion> likewise /usr/web/
<Mez> Kamion: I can understand that ... 
<Mez> I've been bitching at upstream for ages....
<infinity> Mez: Patch the source to use sane paths, if you can't do it with ./configure options.
<Mez> infinity - I don't know the source well enough
<infinity> Mez: We follow Debian policy, which in turn follows the FHS for filesystem layout.
<infinity> Mez: Grep for the offending bits. :)
<j^> mjg59 is that with a new verison of g-p-m? with the one i currently have i can not find settings for the power button
<Mez> infinity: I've tried - it shows one reference to etc
<mjg59> j^: Interesting. Possibly it defaults to that, then.
<Kinnison> Keybuk: screenshot updated. better?
<j^> hm, with my x30 nothing happens than pressing the power button for a shot time
<jdub> pitti: http://blog.fubar.dk/?p=64
<Keybuk> Kinnison: yeah, seems better
<infinity> Mez: Well, if you're horribly stuck on this, you can ask me for some help giving it a quick once-over, but not for a couple of days.
<Treenaks> It works on my Acer 1684
<Treenaks> I get the lots-of-buttons logout dialog
<infinity> pitti: Did it produce translations on any other arch?
<pitti> jdub: heh, we have this since breezy :)
<pitti> infinity: no
<jdub> pitti: ;-)
<infinity> pitti: I'm testing locally here.  I have a feeling it's not producing any at all.
<pitti> infinity: hm, the build log says it does
<Diziet> FFS!  Why oh why oh why does firefox with ./configure --debug install a SIGSEGV handler ??!
<infinity> pkgstriptranslations: preparing translation tarball amarok_2:1.3.8-0ubuntu5_powerpc_translations.tar.gz...done (285 files)
<infinity> Hrm.  That does look like it did one, doesn't it?
<pitti> right
<jdub> Diziet: report-back functionality - makes sense :)
<Kinnison> mjg59: http://people.ubuntu.com/~dsilvers/gpm-shiny
<Kinnison> mjg59: fancy having a play and see what you think?
<infinity> pitti: On the other hand, the sbuild hook to copy the tarball is obviously working in other cases, since I have directories filled with recent translations tarballs...
<Kinnison> mjg59: http://people.ubuntu.com/~dsilvers/gpm-shiny/gnome-power-manager_2.13.91-0ubuntu2_source.changes
<Kinnison> mjg59: for the changes
<infinity> pitti: So, something very goofy is happening to amarok specifically.
<pitti> infinity: right, that's what I was wondering about
<infinity> pitti: Anyhow, testing locally to see what it produces.
<pitti> infinity: maybe the epoch in the version number doesn't match some wildcard, or so?
<Diziet> jdub: If they wanted to do that they should do it in the wrapper script.
<infinity> pitti: Oh, does that epoch end up in the filename?
<j^> ah pressing the power button for longer it show the old new logout dialog. would be good if that would be the same as the one one gets than selecting System->Shut Down...
<pitti> infinity: well, it's the package version
<infinity> pitti: It shouldn't, ideally, since epochs don't go in source/binary filenames.
<pitti> infinity: I see
<infinity> pitti: Whether or not that's pissing off sbuild, I'll have to see.  Let me look at the code.
<giftnudel> j^, well, there is no hibernate button in that dialog
<mjg59> Kinnison: Oh, have you got the rate limiting?
<Kinnison> mjg59: rate limiting?
<mjg59> Kinnison: Multiple sleep event stuff
<Kinnison> mjg59: you may mean 80-suppress-policy-timout
<mjg59> Kinnison: Ah, ok
* Kinnison has been coding on this since he got up :-)
<infinity> pitti: Or, other way around.  Maybe you don't do the epoch, and I do?
<pitti> infinity: no, I do
<pitti> see build log: ' preparing translation tarball amarok_2:1.3.8-0ubuntu5_powerpc_translations.tar.gz'
<mjg59> Failed to fetch http://uk.archive.ubuntu.com/ubuntu/pool/main/m/mesa/libglu1-mesa-dev_6.4.1-0ubuntu6_i386.deb  Cannot initiate the connection to 2080:80 (0.0.8.32). - connect (22 Invalid argument)
<mjg59> Something has gone very wrong here
<janimo> pitti, since there's no firewall spec implemented for dapper, what  do you think shipping one of the frontends for iptables?
<Kamion> can anyone give me a simple example (i.e. not pygtk) of a GNOME component that has a C widget plus Python bindings for it?
<janimo> there are a lot of them I know
<janimo> I have just tested firestarter and was pleasntly surpised
<Kinnison> pitti: epochs plus tar files == danger will robinson
<Kinnison> pitti: in particular, tar treats the colon as a remote-machine thingy
<pitti> Kinnison: right, with -f
<pitti> infinity: so, it's probably best to change pkgstriptranslations to not include the epoch
<janimo> Kamion, I assume no python-gnome2 either ?
<infinity> pitti: Yes, indeed.  But see /msg
<Kamion> janimo: that's likely to be a bit heavyweight as well - I only have one widget to wrap
<Kamion> albeit the Evolution map widget, so not quite a trivial one
<Seveas> Kamion, pygtkmozembed? or is that too pygtk already?
<Kinnison> mjg59: if it doesn't eat your laptop, I'll send that g-p-m to the archive
<mjg59> Suddenly all my apt http methods are getting 2080 as a hostname/address
<mjg59> And ftp ones work fine
<j^> whats the ~ autostart now? ~/.config/autostart does not work
<torkel> j^: .local/share/autostart/
<sivang> does anybody know how to make the num pad's arrows and PgUp work again? for some reason it has gone bad and now controls my mouse :)
<Mithrandir> sivang: press shift-numlock
<Treenaks> oh wow
<janimo> Kamion, anastacia output still has some xfce packages saying rdepends xubuntu-desktop, but they don't anymore
<Treenaks> can I make it move faster, too?
<sivang> Mithrandir: YOU ARE MY HERO!
<Mithrandir> sivang :-)
* sivang hugs Mithrandir for saving his life
<j^> torkel thanks. what would be a good place to document that?
<torkel> j^: somewhere close to gnome-session?
<Kamion> janimo: example?
<janimo> xfce4-systray, xfce4-iconbox
<janimo> and all ending in -plugin
<janimo> Kamion, and the old names for libxfceXXX
<Kamion> janimo: they do on hppa and sparc
<Kamion> I'll take those two architectures out for now - they're not helping
<Kamion> janimo: better now?
<janimo> Kamion, better. I still have to see why the libs are there though
<janimo> libxfce4mcs-client-2 for instance
<Kamion> libxfce4mcs-client3 depends on libxfce4util-1 on ia64
<janimo> Kamion, so should I take hppa and sparc out of the xubuntu-meta update script as well?
<Kamion> xfdesktop4 depends on libxfce4mcs-client-2 on ia64
<Kamion> janimo: no please don't, they'll be resurrected soon
<janimo> Kamion, if these leftovers do not impend the promotion of the good parts in main and CD building I don't mind actually
<Kamion> https://launchpad.net/+builds/+build/170401 says xfdesktop4 is in dep-wait
<janimo> Kamion, for ia64 I assume
<Kamion> yes
<janimo> that arch misses x11-common
<janimo> so everything is dep wait there
<janimo> was last time I looked anyway
<Kamion> huh? no it doesn't
<Kamion> x11-common | 7.0.0-0ubuntu17 |        dapper | amd64, i386, ia64, powerpc
<Kamion> it might need a kick though
<Kamion> infinity: ?
* janimo looks again
<janimo> hmm indeed, it progressed
<infinity> Everything on ia64 needs serious kicking.  Ignore it for a while, I need to untabgle the mess after feature freeze when I have some time.
<infinity> untangle, too.
<janimo> Kamion, what tasks are still needed to start producing ISOs?
<Kamion> janimo: primarily main promotion
<janimo> if there's anything I need to do/should not do while this happens please ping me
<Kamion> will do, don't worry
<tepsipakki> is it still time for a new version in main (libnfsidmap_0.12, now 0.8) ?
<tepsipakki> s/it/there/
<tepsipakki> it is only needed for NFSv4, and the only packages that depends on it is nfs-common/nfs-kernel-server
<Xof> someone in the office is having trouble reporting bugs
<Kamion> tepsipakki: can you get a main uploader to look at it and mail mdz/me if they think an exception's justified, please?
<Kamion> Xof: #launchpad's probably better
<Xof> specifically, when he tries to log a bug, he gets a page saying "oops, something just went wrong in launchpad"
<jono> Kamion, maybe a bug with the partitioner in espresso - when I selected the unused space and clicked New I could only create an 'msdos label'
<Kamion> jono: file bugs please
<jdub> morning jono
<tepsipakki> Kamion: sure, thanks
<jdub> jono: nice stuff inspiring jonoedit
<jono> hey jdub 
<Kamion> Xof: #launchpad can investigate given the OOPS code
<jono> Kamion, sure :)
<jono> jdub, cheers :)
<Kamion> jono: ("gparted sucks")
<Kamion> well, that's harsh - but it may be inadequate for our purposes, we'll see
<jono> Kamion, heh, figured you would say that it sucked a bit
<Kamion> but an msdos label is surely what you want on a PC system
<Kyral> Mornin
<Kamion> jono: perhaps I should translate - by "create msdos label", it means "create a PC partition table"
<jono> ahhh
<Kamion> on many other systems partition tables are known as disklabels
<Kyral> oh Kamion, if I modify the Espresso doc package, I'll just throw it to azuredream.homelinux.org/ubuntu (I plan to start documenting this weekend :P). Izzat alright with you?
<Kamion> Kyral: fine
<Kyral> kk, ty for lettin' me play with them :D
<Riddell> mvo: is APT::Periodic::Update-Package-Lists "1";  on by default in dapper?  it doesn't seem to be for me
<mvo> Riddell: if you have update-notifier installed, otherwise not
<Riddell> mvo: does update-notifier have a postinst script for that?
<mvo> Riddell: the rational is that it only makes sense if you have something that tells you about the new updates
<mvo> Riddell: no, it puts a file in /etc/apt/apt.conf.d
<Riddell> yes, I see it now
<Riddell> we'll have to do the same for adept-updater then
<Riddell> hmm, then we'll have clashing files
<freeflying> mvo: hi
<mvo> Riddell: if adept-updater runs as root anyway it is not required. the rational for update-notifier droping that file is that it runs as user only. if adept-updater runs as root it can just do the apt-get update itself
<mvo> Riddell: or will adept-updater register itself in the user session as a notification icon? then you need it of course :)
<mvo> freeflying: hi
<Riddell> sorry, I mean adept-notifier, not adept-updater
<Riddell> adept-notifier is the systray icon that runs as user
<mvo> Riddell: oh, right. yes, then it's needed
<Riddell> mvo: how can we do that without clashing files?
<Riddell> adept could just have a 11periodic instead of 10periodic but that doesn't seem very clean
<freeflying> mvo: the best way to add IM variable for scim/skim is using langpack-pack-gnome/kde-base
<mvo> Riddell: you could do that, I'm not sure if dpkg will like replace on conf files
<mvo> freeflying: you mean to ship 90xinput in there?
<freeflying> mvo: y. and this file can be add by postintall instead of ship in a package 
<mvo> pitti: have you seen this suggestion by freeflying? about adding the required xsession stuff in langpack-{gnome,kde}?
<pitti> mvo: no I didn't see it
<Riddell> I'd say langauge-support- not language-packs
<pitti> mvo: but no, langpacks won't contain any code, it's too difficult
<pitti> same for support
<mvo> Riddell: yes, sorry
<pitti> mvo, freeflying: scim-* itself should do the necessary modifications
<freeflying> pitti: how about postintall script
<tepsipakki> where do I find people that can upload to main and could review a package? :)
<pitti> freeflying: right, scim's (or any module's) postinstall should do that
<Riddell> pitti: if scim does them then if affects the user even if they just have scim installed and not used (e.g. if scim is on the CD)
<freeflying> pitti: then every locale user will have scim/skim startup when they loginto desktop
<Riddell> also then how do you set the language used, which I think needs done
<pitti> freeflying: well, *if* this interferes with users who don't use that particular locale (i. e. Chinese), then we can't do it by default anyway
<pitti> isn't there an unintrusive way?
<freeflying> pitti: actually it will be harmless for that 
<pitti> freeflying: it seems to me that the most appropriate place would be in some scim-module then?
<freeflying> pitti:  ok, and may I discuss it with later , I'd leave now 
<pitti> ok, see you! have a nice evening
<freeflying> pitti: thanks 
<freeflying> pitti: Huahua may discuss this with u too
<Riddell> Kamion: what happened to the files in http://people.ubuntu.com/~cjwatson/bzr/espresso/ubuntu/espresso/components/ ?
<huahua> hello , pitti
<pitti> hi huahua 
<jono> Kamion, right, I will submit the bug
<jono> Kamion, ok, https://launchpad.net/distros/ubuntu/+source/espresso/+bug/32479
<Ubugtu> malone bug 32479 in espresso "'create msdos label' in partitioner unclear" [Normal,Unconfirmed]  
<jono> ahhh
<jono> thats handy :)
<jono> :P
<sivang> Riddell: what's the name of the nice GUI KDE regular expressio builder program?
<Kamion> jono: ta
<Kamion> Riddell: nothing, they're all provided by other packages
<Kamion> user-setup, partman, espresso-locale, espresso-grub
<Riddell> sivang: the easy to pronounce kregexpeditor
<sivang> Riddell: hehe
<sivang> Riddell: thank you :)
<sivang> Riddell: on useful piece of software :)
<Treenaks> Riddell: in Dutch, it actually IS easy to pronounce that.. it's not in Scottish?
<Riddell> the name doesn't roll off the tongue
<Treenaks> no, it kind of sticks in the back of your throat
<huahua> pitti:  I will discuss those with freeflying more  .  skim can launch by itself, and scim need help eg for im-switch
<huahua> scim can run on all locale 
<huahua> and im-switch must work on special locale
<huahua> im-switch provides the framework to switch default of input method on X Window System.
<huahua> if it use im-switch to launch  the input method
<jono> Kamion, I noticed a few other quirks with the partitioner - would you prefer one bug report with them all, or lots of bug reports?
<huahua> he freeflying-ibook 
<Kamion> jono: one per logical issue is good
<jpatrick> he left
<Kamion> launchpad has no means to split up bugs at the moment
<jono> Kamion, no problem
<atie> huahua, do you also consider xim with scim, non-CJK-users and CJK users who want to use other IMs?
<huahua> atie: yes
<Kamion> Riddell: is there likely to be anything I can merge (or even look at) for espresso-frontend-qt before feature freeze?
<spacey> how can i find out which packages replaced package xlibs?
<Riddell> Kamion: probably not merge yet but I'll give you what I have at the end of today
<Kamion> spacey: install grep-dctrl, 'grep-dctrl -nsPackage -FReplaces xlibs /var/lib/apt/lists/*_Packages'
<Kamion> Riddell: thanks
<Kamion> that grep-dctrl is marginally wider than you actually want (it catches Replaces: xlibs-data too), but close enough for government work
<huahua> atie:  User can also choose her favorite input method by 'im-switch' command or other GUI front-end
<huahua> atie: im-switch  launchs  input method  only  on the registered locale .
<atie> huahua, yes, but im-switch doesn't count IM variables in ~/.gnomerc or ~/.kde/env/.
<huahua> atie: it use /etc/X11/xinit/xinput.d/LOCALE
<huahua> atie: it can count IM variables
<huahua> hua@vgh:~$ ls /Sid/etc/X11/xinit/xinput.d/
<huahua> ja_JP  none  zh_CN
<huahua> like it
<sivang> weird. KregExpEditor matches something that python math doesn't......
* sivang grumbles
<atie> huahua, in my case I'm using scim under en_US.
<sivang> ah, found the issue. python matches from _the_ _start_ of the string
<huahua> humm
<jdub> Kamion: germinate packages!
<atie> huahua, and make /etc/X11/Xsession.d/75scim by myself because of 90im-switch
<huahua> atie: I see
<huahua> atie: I used /etc/X11/Xsession.d/95xinput before im-switch come be
<Mez> Kamion:ping
<huahua> atie: if we use /etc/X11/Xsession.d/75scim  , user will can't choose her  favorite input method .
<Mez> or infinity ping
<Kamion> jdub: for ages
<Kamion> Mez: yes?
<Mez> Kamion, regarding /usr/web
<Mez> would /usr/share/simais/web/bin be ok?
<Kamion> Mez: if the stuff there is architecture-independent, yes
<Kamion> if it's architecture-dependent, use /usr/lib/simias instead
<tseng> if its xsp stuff it should be arch indep
<Mez> yeah it's arch indep
<Mez> does this mean i have to make the package arch-indep ?
<Mez> or create a new arch indep for those files?
<dholbach> *sigh* I find it easier to read ubuntu-users@ than ubuntu-devel@ at the moment.
<Mez> dholbach, lol
<jdub> dholbach: ?!
<jdub> (mind, i haven't looked at u-d for a bit)
<jdub> do we need some more tear gas in there?
<seb128> jdub: 230 mails on u-d since monday morning
<jdub> goodness me
<Keybuk> all of them about totem
<seb128> or gnome-screensaver :p
<jdub> what's the controversy?
<Keybuk> "I don't care about legal issues, compatibility issues, etc. I WANT TO WATCH MY PORN!"
<dholbach> Keybuk: I fully agree with you.
<Keybuk> jdub: totem and gstreamer 0.10 do not support enough formats of porn
<doko> seb128: where's PlanetaryGears gone in gnome-screensaver ?
<jdub> Keybuk: ahr
<doko> seb128: where's the preview button gone?
<seb128> doko: that's a question for ogra
<seb128> I don't mention screensaver stuff
<doko> ogra: ^^^
<Keybuk> I think we should make a wiki page for people to attach the movies they're having trouble playing with it :)
<dholbach> Ok, I will add a  *please don't even think of mailing your ideas to any mailing list* to the media testing announce
<Keybuk> obviously to explain why those movies can't be played legally
<seb128> and I don't use screensaver not know what PlanetaryGears is in fact :p
<doko> seb128: and the different paste buffers in gnome-terminal and X ? 
<Keybuk> "this algorithm is patented by fraunhoffer, and those girls don't look older than 15"
<seb128> Keybuk: trying to collect free p0rn? :)
<stockholm> lol
<seb128> doko: fixes with CVS, new tarbalsl next week
<doko> nice
<seb128> "fixed with CVS, new tarballs next week"
<ogra> doko, no settings button ... i can add glanetary gears if you urgently need it its just another .desktop file :)
<ogra> *planetary even
* seb128 is thinking to unsubscribe from ubuntu-devel
<dholbach> seb128: I'd unsubscribe from ubuntu-desktop@ if we'd move that kind of discussion to ubuntu-desktop@
<seb128> lol
<ogra> but its a desktop task, isnt it ? 
* ogra hides
<doko> and *g*lanetary gears is Gnome^2 ;-P
<ogra> hehe
<jdub> dholbach: there's more moral authority on ubuntu-desktop to knock this stuff off
<jdub> dholbach: so we have to push people there first ;)
<jdub> "Move readahead-list into /sbin so it's actually on seb's root filesystem."
<jdub> ha ha ha
<jdub> is filesystem boog
<Kamion> Mez: normally only Architecture: all packages should install to /usr/share, yes; if it's inconvenient to split the packages up, you can just use /usr/lib
<jdub> Keybuk: readahead-watch -> nice :)
<Keybuk> jdub: yeah, needs some tinkering yet
<Keybuk> and I'm not sure it orders the list right
<Keybuk> but I thought I'd get a first upload in, just to publish early and often, type thing
<Mez> Kamion, FAIR ENOUGH - I'LL TALK WITH IFOLDER DEVS ABOUT HWO THEY WANT TO DO IT
<Mez> damn caps
<jono> later all!
<seb128> jdub: I've already no nice udev automatic debug due to Keybuk :p
<seb128> seems it's not good to have differents partitions for /usr and /var nowadays
<jdub> seb128: he obviously has no respect for anal retentive filesystem layouts!
<seb128> bastard!
<Keybuk> seb128: *shrug* you didn't have it before, so it's hardly a regression :)
<Keybuk> I'm not putting everything in /sbin for you <g>
<seb128> bah ;)
<Kamion> mjg59: xserver-xorg-air-core binaries accepted FYI
<mjg59> Kamion: Excellent
<ploum> http://geekz.co.uk/lovesraymond/archive/cancomical-lynchpad
<carlos> seb128: btw, do you know why gossip doesn't have any sound on dapper? I think it's related with gstreamer 0.10
<seb128> carlos: nop, I can try having a look later, but it doesn't use gst
<carlos> seb128: isn't the new GNOME using gstreamer as the way to play sounds?
<seb128> no
<carlos> oh!
<carlos> ok
<seb128> libgnome still uses esound
<seb128> apps using gst are using 0.10
<seb128> ie: totem, rhythmbox, sound-juicer, gnome-media
<seb128> bet sound events still use esound
<carlos> seb128: the problem came more or less at the same time gstreamer 0.10 was available for dapper
<seb128> probably not due to gst
<carlos> seb128: sound events work, that's why I thought it was a problem with gossip not using gstreamer 0.10
<seb128> I'll have a look later and let you know :)
<carlos> seb128: it's not a big issue, so if you are busy, don't worry
<seb128> right, I'll have a look but not now :)
<carlos> ok, thanks
<carlos> pitti: hi
<pitti> hi carlos 
<carlos> pitti: could you join #launchpad ?
<pitti> yes
<carlos> we are having problems with pkgstriptranslations
<xxenon> are nvidia drivers currently broken ?
<ogra> pitti, http://people.ubuntu.com/~ogra/Screenshot.png
<ogra> pitti, is that g-v-m or udev ?
<pitti> ogra: rather gnome-vfs, I'd say
<ogra> hmm, k
<ogra> seb128, ?? known error of gnome-vfs ? ^^^^
<dholbach> ogra: there were no changes to gnome-vfs in nearly two weeks - when did this start happening?
<pitti> ogra: your lshal and mount output could be interesting
<ogra> dholbach, i didnt look directly on my desktop since about a week, it wasnt there last time i looked though ...
<ogra> pitti, nothing unusual in mount ...
<ogra> pitti, haha
<ogra> pitti, i had manually mounted /dev/hda7 to /media/cdrom due to lack of a mountpoint for it ... nautilus/gnome-vfs/hal labeled it proc ...
<pitti> ogra: still odd, unless the partition's device label is really 'proc'
<pitti> ogra: can you check?
<ogra> unlikely ...
<pitti> ogra:sudo blkid /dev/hda7
<ogra> /dev/hda7: UUID="83b79969-0136-4d18-bba4-56ec8445c562" SEC_TYPE="ext2" TYPE="ext3" LABEL="/"
<Riddell> Kamion: I'm merging in the language page in espresso and I get an error..
<Riddell> File "/media/hda4/jr/src/espresso/ubuntu/espresso/components/language.py", line 44, in run
<Riddell> UnicodeDecodeError: 'ascii' codec can't decode byte 0xd8 in position 96: ordinal not in range(128)
<ogra> pitti, its my tect installation ...
<Riddell> Kamion: is there somewhere I need to set the encoding for it not to be ascii?  
<ogra> *test
<Riddell> I have the coding: utf-8 line at the top of kdeui.py
<pitti> ogra: and lshal has 'proc' as the device label for that file?
<ogra> ogra@edubuntu:/mnt/devel/packages/ubuntu-artwork-0.2.29$ lshal|grep proc
<ogra>   linux.pmu_path = '/proc/pmu'  (string)
<ogra>   linux.pmu_path = '/proc/pmu/battery_0'  (string)
<ogra>   linux.pmu_path = '/proc/pmu/info'  (string)
<ogra> nope
<Burgwork> somebody pinged me?
<pitti> ogra: iz gtk bug, then
<ogra> heh
<ogra> likely :)
<Kamion> Riddell: what version of espresso-locale do you have there?
<Riddell> Kamion: 0.27ubuntu8
<Kamion> Riddell: could you run espresso with ESPRESSO_DEBUG=1 and tell me what the last bit of debconf interaction before that was?
<Kamion> Riddell: it's also possible the line number is just lying and that the problem is that you haven't made sure that strings given back to you by the python-qt bindings are turned into python unicode objects
<Kamion> Riddell: there are a number of places in the gtk frontend where I do unicode(some python-gtk function)
<ogra> Kamion, ubuntu-artwork has a new child, called ubuntu-artwork-screensaver, can you promote it to main and un NEW it ? its only a single png 
<ogra> (once its built that is)
<Kamion> ask me once it's built or I'll forget
<ogra> ok
<Riddell> debconf (filter): widget found for languagechooser/language-name-fb
<Riddell> debconf (developer): <-- GET languagechooser/language-name
<Riddell> Kamion: ^^
<Riddell> Kamion: if I add 'utf-8' as the last argument to unicode() in language.py it works
<Kamion> Riddell: nothing after that, even after you ctrl-c espresso?
<Kamion> there should be a response
<Riddell> there is..
<Riddell> debconf (developer): --> 0 English
<Riddell> debconf (developer): <-- METAGET languagechooser/language-name choices-c
<Riddell> debconf (developer): --> 0 C, Albanian, Arabic, Basque, Belarusian, Bengali, Bosnian, Bulgarian, Catalan, Chinese (Simplifie
<Riddell> etc
<Kamion> I would find the whole response useful
<Kamion> perhaps in /msg
<Riddell> well it's just a list of all the languages
<Kamion> please
<Kamion> this should be frontend-independent, and it works for me
<Riddell> Kamion: http://kubuntu.pastebin.com/567017
<Kamion> unless you're poking at python's default encoding?
<seb128> ogra: weird, that's new
<fabbione> mdz, Kamion: ping?
<Kamion> fabbione: I'm right here
<Riddell> Kamion: not that I know of
<ogra> seb128, its as well not reproducable ...
<fabbione> Kamion: i need UVF exception for Redhat Cluster Suite.
<ogra> so dont worry to much
<fabbione> Kamion:   The "Upstream told us to do an urgent update or CMAN will bite us!"
<fabbione> + release
<ogra> seb128, i just tried ... will dig more if it should appear again
<fabbione> Kamion: for the history, that package is only built on top of their stable branch that gets only bug fixes
<Kamion> Riddell: can't think of any other explanation ...
<fabbione> Kamion: it's nothing more than a CVS update
* Kamion CVS updates fabbione to five years from now
<Kamion> fabbione: please mail changelog to mdz+me
<Kamion> Riddell: I can go through and put 'utf-8' on the end of all unicode() calls - would just like to know why :-/
<Riddell> Kamion: I'll ask pykde types to see if qt/kde is likely to be poking at python's default encoding 
<Kamion> sticking 'utf-8' on the end seems to work, so I'll do that
<Burgwork> mjg59, going to go for more fame by posting the aiglx stuff to -devel-announce?
<mvo> Kamion: I just tested expresso and it didn't like my grub anymore. I get a grub error 15 after the install
<Kamion> mvo: if you could upgrade espresso to the current version in dapper and send me /var/log/installer/espresso, that would help
<mjg59> Burgwork: Not just yet
<mvo> Kamion: I was using the version from the latest live-cd. I'll upgrade from that and re-try the install, ok?
<mvo> Kamion: anything else but espresso I need to upgrade?
<Kamion> mvo: it'll probably pull in espresso-locale, otherwise no
<Kamion> unless the latest live CD happens to have espresso 0.99.15 anyway
<mvo> I upgraded to 0.99.15 now
<Kamion> Riddell: ok, fixed in espresso bzr now and I'm fixing localechooser
<AlinuxOS> pitti, I saw a bug corection :) thank you.
<pitti> AlinuxOS: breezy langpacks should be happy again for you :)
<AlinuxOS> ;)
<AlinuxOS> pitti, I'm working for dapper and gnome 2.14 now :)
<sivang> is sys.stdin.readline() a good way to wait for the user to press enter on the console?
<jpatrick> 'pass'
<sivang> jpatrick: ?
<jpatrick> nm
<sivang> jpatrick: were you answering me?
<jpatrick> sivang: I thougth  'pass' was a command to wait for the user
<Kamion> (it's not)
<Burgwork> mjg59, are you coordinating with the debian xstrike force? They have filed itps on aiglx and xgl
<mjg59> Burgwork: I hadn't as yet, since I don't read d-d any more
<mvo> Kamion: interessting. on the espresso install was no grub installed
<Kamion> mvo: yeah, I thought as much
<Kamion> mvo: problem is that at the moment it has to install grub from the network, and sometimes it doesn't manage to get networking set up properly first
<Kamion> so known problem - I'll try to figure out something to do about it soon
<sivang> Kamion: could you please assure me, when I'm doing something like proc = subprocess.Popen(....,stdin=subprocess.PIPE,stdout=PIPE,stderr=PIPE..) in a pyhton program, and in another part of it I attempt sys.stdin.readline() , will the former part clash with the attempt to read from the user? the former is how I spawn the program I use to do some of the work, so I assumed it will have no effect on the python program IO
<Kamion> sivang: proc.stdin is independent from sys.stdin, so yes, that's safe
<sivang> Kamion: apparently, it stills IO from the main process...
<mvo> Kamion: ok, np. if it's known I won't bug you
<Kamion> sivang: if you're having problems, I'd advise using strace to investigate which fds python is actually reading from
<Diziet> This magicmirror snapshot thing is very nice.  I have daily snapshots of the archive running back a whole month ...
<sivang> Kamion: when the main (python) program sys.stdin.readline() waits, I can't see anything I'm typing. Is that a sign for IO stealing? :)
<Kamion> no, that suggests that something has turned off local echo on your terminal
<Kamion> at a guess, anyway
<Kamion> as I say, use strace before flailing around trying to Zen what's going on :)
<sivang> Kamion: ah , right. thanks it must be it if what you said previously is correct. 
<sivang> (which I tend to think is ;-)
<sivang> Kamion: trying that now, but it'\s ugly :) as my python program spanw another progra, reads from its stderr , stdout and write to stdin ..
<Kamion> 'strace -f -s 1024 -o /tmp/foo.trace your-python-program' and look at /tmp/foo.trace in another window
<jdub> ogra_: argh, can you tell me when you're going to do u-a changes?
<Kamion> (it's in NEW anyway ...)
<Kamion> or will be
<sivang> Kamion: also, what's interesting is that when I break my main py prog in the middle, is has the same sympton as if the echo is turned off, and also when I press CR the next bas line doesn't come after a CRLF, but as if only a " " space was applied.
<ogra_> jdub, gnome-screensaver-default-image is one of my specs
<mdz> mjg59: that laptop-mode hang is definitely still around; happened twice just now
<ogra_> jdub, oh, you mean we clashed ? 
<ogra_> jdub, really sorry ...
<jdub> ogra_: you're adding stuff while i'm repositorising it and so on - prefer if you send me changes if they're not just patches (it's going to be ubuntu-native very soon)
<jdub> ogra_: mostly waving my hands around wildly because i'm sitting here setting up the repo and shoving in changes as we speak ;)
<mjg59> mdz: Bugger. Right, ok.
<ogra_> jdub, ok ...
<mjg59> mdz: When you're on battery, right?
<mdz> mjg59: correct
<mdz> I was on battery for all of 60 seconds or so and hung both times
<hunger> Anyone else having suspend-trouble?
<mjg59> mdz: Right. Which fits with ATA breakage.
<hunger> echo -n mem > /sys/power/state gives a "device or resource busy" here.
<mdz> mjg59: anything I can do to track it down?
<mjg59> mdz: Get it on the console and see if there's an error?
<jcole> when will print to pdf in gnome-print be supported again (currently doesn't work)? i'm running breezy
<mjg59> mdz: Is it reliable in terms of when it does it?
<mjg59> I mean, does it happen on all power transitions?
* jcole thinks ps2pdf doesn't understand the "newer" ps format used by some apps (ie: firefox)...
<mvo> Mithrandir: is #31051 something for you? he wants to remove "update-manager" and "update-notifer" from the live cd
<Mithrandir> mvo: nocando, we use -desktop there
<mvo> Mithrandir: I thought so, so I can reject the bug?
<Mithrandir> mvo: we can disable the cron jobs by default, though.. Kamion, thoughts?
<Mithrandir> we're kinda reluctant to munge the image more than absolutely necessary.
<mvo> Mithrandir: ok, I rejected it
* mdke boggles at the devel mailing list nowadays
<jdub> don't boggle - redirect!
<mdke> jdub, can we make it a moderation only list? you can moderate
<tseng> mdke: you dont want that
<tseng> mdke: it will take a month to post an email.
<jdub> mdke: no, that would suck
<jdub> mdke: we just need to use social solutions
<jdub> not technical ones
<mdke> it was a joke
<mdke> crappy english sense of humour
<jdub> incompatible withe the crappy english weather
<mdke> yeah
<LaserJock> I don't understand this "social solutions no technical ones" thing. can you elaborate?
<jdub> LaserJock: better to encourage people to understand good behaviour and participate well, instead of trying to use technology to box them in
<ploum> jdub: not at all. How could english live in *that* weather without *that* sens of humor ?
<jdub> ploum: by becoming mass murderers?
<ploum> hm.. I will investigate this theory
<ploum> english weather is like belgian weather in a good day
<ploum> (that's perhaps why we have better beer)
<ploum> LaserJock: it's easy to explain. Do you prefer a closed door at castle Anthrax or a spanking party ?
<ploum> "Open the door ! Open the door " -> technical solution
<ploum> "Naughty naughty zout !" -> social solution
<ploum> That's why we prefer social solutions
* jdub chuckles
* Burgwork wonders about ploum 
<jdub> yes, JUST LIKE THAT
<j^> can i change the effects in metacity/xorg-air?
<LaserJock> but can we make social solutions? It would seem that technical solutions are much easier to make. :-)
<jdub> j^: you want some castle anthrax effects?
* j^ hopes its only the i830m that is soo slow
<jdub> LaserJock: that's the problem
<jdub> LaserJock: lazy people/communities do exactly that
<j^> jdub i want the windows to minimize towards the window list
<jdub> j^: instead of zooming, and then flying off towards it
<jdub> ?
<j^> jdub and moving it to another desktop it would be nice to slide out in that direction
<j^> jdub its doings something strange and than disapears in the middle of the desktop
* j^ blames it on the the graphic card and switches it off again.
<jdub> j^: yeah, so it zooms out, then in the background, swooshes off to the window list
<lakin> Hey guys, just wanted to let all the ubuntu-devs know that they rock!
<jdub> j^: i don't know why it does that behind everything
<j^> jdub what graphic card do you have?
<lfittl> Kamion: ping
<jdub> j^: radeon on lappy, nvidia on desktop
* jdub misses his i810 lappy :(
<whiprush> you know, the new X60 comes with an intel card. :p
<j^> jdub so you use Xorg-air or Xgl?
<florian_kc> hi all
<Amaranth> Doesn't Xglx use glitz to do OpenGL acceleration of RENDER too?
<Amaranth> I don't think Xorg-aiglx does that, although with EXA for open-source drivers and nVidia's closed-source ones I think it's covered (RenderAccel)
<LaserJock> jdub: do you have any references talking about "social solutions", I'm somewhat intrigued and I know it probably seems stupid but I'd like to figure out how to contribute to the social solutions.
<jdub> um
<jdub> not really
<jdub> "be nice" :)
<LaserJock> that's ok, I just thought there might be something right off hand
<LaserJock> so just basically abide by the CoC?
<Burgwork> LaserJock, ask people politely to post elsewhere, suggest an elsewhere and tell them about what the -devel list is
<LaserJock> hmmm, that sorta seems like just ignoring the situation. Or is it more like moving it to a more appropriate forum?
<jdub> the latter
<LaserJock> it usually comes across to me as "bugger off, we don't want your discussion here"
<jdub> that's why redirecting is important
<jdub> or putting your foot down where appropriate
<LaserJock> anyway, this is quite OT so I'll shut up now and let you guys get back to work. I'm just very interested in the social aspect of Debian/Ubuntu development.
<Pygi> laser: what was decided yesterday about protocols?
<herzi> mvo: ping
<mvo> herzi: pong
<herzi> https://launchpad.net/malone/bugs/5752
<Ubugtu> malone bug 5752 in update-notifier "TrayIcon-Code is suboptimal" [Normal,Needs info]  
<herzi> i still get those lines
<mvo> herzi: what theme do you use? I can't see those lines
<herzi> clearlooks
<herzi> try a transparent panel, then you should see them with any theme
<mvo> herzi: thanks, the transparency helps. I will have a look RSN
<herzi> mvo: take a look at tray.c:190
<herzi> the bug might be in that passage
<herzi> (at least for the update icon)
<mvo> herzi: sorry, tray.c is dead code (I need to remove it from the repository)
<mvo> herzi: update.c and update-notifier.c are the ones used nowdays
<mvo> herzi: my suspicion is that the other apps don't hide the EggTrayIcon but destroy it complettely
<herzi> no
<herzi> i wrote some test app for that
<mvo> herzi: nice, is it available somewhere so that I can have a look?
<LaserJock> Pygi: well, I think somebody (Burgwork perhaps) closed the bug. Basically I think it was decided that it isn't Ubuntu's problem :-)
<Pygi> LaserJock: that's kinda ignorant, but it's not my call to decide on somethin' like that :-/
<sivang> mvo: and idea?
<sivang> s/and/any/
<Burgwork> LaserJock, I closed the bug. It is not an Ubuntu problem
<Burgwork> Pygi, and there is nothing we can realistically do about it, without crippling functionality over a vague threat that doesn't even effect Ubuntu/Canonical
<LaserJock> Pygi: well, maybe dapper+1 might be a better time time to address that issue. I'm wondering if it needs to be an upstream thing.
<Burgwork> LaserJock, this is an example of a social issue, not a technical one
<shaya> seb128: you here?
<shaya> wondering why gstreamer0.10-ffmpeg is compiled w/ out a-52/ac3 support
<Pygi> Burgwork: true, but it does affect users...
<Burgwork> Pygi, that I don't disagree with
<Burgwork> Pygi, I would be more interested in getting a .ubuntu service off the ground
<LaserJock> Burgwork: .ubuntu for jabber?
<Burgwork> LaserJock, yes
<LaserJock> that would be very good, I think.
<Pygi> yup, agreed...
<Burgwork> Pygi, LaserJock https://wiki.ubuntu.com/UbuntuMac
<Pygi> burgwork: seems kinda like some kind of intranet web app....maybe somethin' eyeOS like :)
<Burgwork> Pygi, no, it is more than that
<Burgwork> and nto a web app
<Pygi> ah,kk, I'll read it up more now *entire maybe :) *
<mvo> herzi: if you could pass me a copy of that test-app that would be very helpful :)
<herzi> i'm just looking for it
<Pygi> burgwork: seems like a nice idea, but it would be hell of a job to integrate all those things together :-/
<Burgwork> Pygi, got to start somewhere
<Pygi> burgwork: true...has any of work started?
<LaserJock> if even half of those things got going it would be awesome. I think email, address book, and jabber/blogging would be great. Seems like it would be a lot of time, and hardware.
<Burgwork> Pygi, not yet
<Burgwork> hula will be the answer for some of it, I suspect
<Pygi> also, roundcube seems like a very good app
<LaserJock> why is it called .Mac though?
<Burgwork> LaserJock, because that is the working title, to compare it to an existing service
<Pygi> laser: to resemble .Mac service :) the name can  be change as stated there :P
<LaserJock> ok, I was just getting a little worried that's all;-)
<jcole> shaya: i noticed that gstreamer-ffmpeg is also excluded from all gstreamer-plugins-* meta packages, for some reason
<Pygi> laserjock: :P
<shaya> jcole: reason being that it seems ac3 support is in ugly plugins
<shaya> but very hard to figure out what plugins ones needs
<shaya> took me a while to figure it out
<Pygi> burgwork: roundcube email system seems a lot nicer then hula one's, but then again if we use hula for calendar and adress book ... :-/
<jcole> shaya: i have more success with totem-xine and mplayer on breezy (uses gstreamer 0.8)... not sure about dapper
<Burgwork> Pygi, the backend to hula is netmail, which is rock solid and known to scale very well
<shaya> jcole: I was using totem-xine w/o a problem
<shaya> but it doesn't play nice on my laptop w/ 6 channel ac3
<shaya> can't control speaker settings
<Pygi> burgwork: yes, that is understandable, as well the roundcube is in deep alpha, but still :-/
<shaya> unsure that gst works perfectly, but can hear what I need to hear
<Pygi> also, roundcube contains adress book
<Pygi> just testing it now...
<tseng> roundcube is not at all in the same class as hula
<Pygi> tseng: yes, I know...
<Burgwork> tseng, can you elaborate?
<tseng> roundcube is a webmail client that sits on top of a traditional unix mail stack
<tseng> hula is netmail, and multi-user enterprise calendering and address book
<tseng> they arent nearly comparable
<tseng> you could compare roundcube to squirrelmail
<Pygi> yup, because there are meant as pure webmail solutions
<tseng> Pygi: have you ever used exchange and outlook heavily
<Pygi> tseng: sorry, I haven't used windows heavily since 3.0 :-/
<Pygi> and even then I only had it for a week 
<tseng> I get the feeling you dont understand the more important use cases
<Pygi> yup, I got the point
<tseng> mail is nice, but I can get imap mail 100 ways
<tseng> enterprise address book and calendering, not so much
<Pygi> true...
<Pygi> I nowhere said that we don't need address book and calendaring, haven't I? :)
<Pygi> also, we need something that will be able to hold out a lot of users
<LaserJock> would it be bad idea to just start out offering some services like that to Ubuntu members as sort of a "in recognition of your contribution to Ubuntu ..." ? 
<mae> where can i download slightly more aged kernels from the dapper repository - the current ones all have problems - build 12 worked like a charm for me but is no longer in the repo.
<Kamion> lfittl: yes
<Kamion> ?
<Pygi> LaserJock: that would mean that we are favoring one users above others...but that might not be a bad idea as a test of a service
<lfittl> Kamion: Could you tell me if the audiere source is still in NEW?
<Kamion> lfittl: yeah
<lfittl> Kamion: k, thanks
<Kamion> lfittl: I sort of automatically avoid things that mention "MP3" :-)
<Kamion> is MP3 support enabled in that audiere build?
<Kamion> I guess it's ok for universe anyway
<lfittl> let me look..
<Kamion> but still ... there were easier things to process
<Kamion> and I'm sort of out of energy for NEW for today
<lfittl> Kamion: sure, I just wanted to know if it got Rejected or not, the whitelisting is not working since the soyuz rollout..
<lfittl> Kamion: I think mp3 gets activated, but I don't have time atm to find that out, I will just wait for you / elmo processing audiere
<Kamion> lfittl: don't think there is any whitelisting any more, you just have to be in the ubuntu-dev team
<Kamion> if you're being sponsored, then yes, you won't get mail
<Kamion> although I think your sponsor will
<lfittl> Kamion: yep all my sponsors get the mails
<sistpoty> Kamion: does the sponsor get a rejected-mail as well?
<lfittl> Kamion: no chance for MOTU hopefuls to get this mail?
<Kamion> lfittl: ask on #launchpad, I have no control
<Kamion> sistpoty: you too, I don't have hard facts, just what Kinnison told me
<sistpoty> Kamion: will do, thx
<Kamion> he told me that the signer gets mail
<Kamion> lfittl,sistpoty: in any case, there's no way to give reasons to soyuz for manual rejects at the moment so we have to send mail separately anyway
<sistpoty> ah... ok
<Kamion> ogra_: so I don't understand why ubuntu-artwork-screensaver was split out
<Kamion> ogra_: it's just one more file, it's still Architecture: all, and it has no extra dependencies (only a Recommends)
<Kamion> can you explain it to me please?
<fabbione> night everybody
<ogra_> Kamion, it will be used as a build dep for xscreensaver, xscreensaver checks for the existence of the directory (i dont like to build depend on the whole of ubuntu-artwork) ...
<ogra_> additionally it might get updates of the backgrounds collection.... 
<ogra_> it will hold more than the one file in the future and might get a very bog download ...
<ogra_> *big
<ogra_> s/get/become/
<Kamion> is it to go on the CD?
<ogra_> i think so, yes
<ogra_> i doubt it will be really huge this release, but it might grow in the future ... 
<elmo> Kinnison: ping?
<elmo> err -ping, nm
<sivang> OMG, has anyone see that? http://geekz.co.uk/lovesraymond/archive/cancomical-lynchpad 
<sivang> :)
<tseng> yes, hours ago
<Kamion> ogra_: if it gets much bigger than the current size, that's going to be a serious problem
<Kamion> it's currently a 2MB .png which compresses not at all
<mae> where can i get old debs?
<mae> for dapper
<mae> that aren't in the cu rrent repo
<ogra_> Kamion, will fix that ... 
<Kamion> ogra_: also, why a build-dep for xscreensaver? are you planning to copy it into xscreensaver-* packages at build time?
<tseng> mae: you really dont.
<mae> tseng: eh?
<Kamion> 'cos that seems kind of wrong
<tseng> mae: if its not in the repo, its gone
<mae> ic.
<ogra_> Kamion, nope, but xscreencaver fails to include the directory if its nonexistent at build time
<Kamion> ogra_: probably better to just clobber its build system to override that
<ogra_> and it checks the hosts system, not the chroot 
<Kamion> if you're going to build-depend just for the sake of test -d returning true ...
<Kamion> or just stick the relevant directory in debian/whatever.dirs
<Kamion> ogra_: was the image meant to be much more compressible, then?
<dholbach> can we get ubuntu-{media,legal,usability}@lists.ubuntu.com and additionally start moving desktop stuff to ubuntu-desktop@?
<ogra_> it was planned to go away as soon as i have something else
* jdub spanks dholbach 
<dholbach> jdub: what's wrong?
<jdub> dholbach: btw, if i have a say, there will never be such a thing as 'ubuntu-legal'
<dholbach> jdub: i don't like it much either. I just had a look at the devel list and tried to separate one stuff from the other
<jdub> yeah
<ogra_> Kamion, i'm sure it can be smaller ... since its purpose is to get cut in pieces, distorted and to bear other tortures :)
<ogra_> you will nearly never see it clearly ...
<Kamion> Riddell: um, when I try merging your branch, it removes and re-adds espresso/frontend/gtkui.py
<Kamion> that seems a tad unfriendly :)
<Kamion> Riddell: can you move liveinstaller.ui to a subdirectory?
<ploum> dholbach: a first good sort would be ubuntu-trolls@lists.ubuntu.com
* LaserJock runs to subscribe ;-)
<ploum> just to move all that "gstreamer doesn't play my WMV", "reply-to field must be set in the list", "epiphany is better than firefox"
<mdke> dholbach, jdub, i just assumed all you real developers were using a private mailing list and -devel had just become for noise
<Kamion> Riddell: (I understand it's not ready to merge yet, it's just the easiest way to look at the differences)
<dholbach> mdke: *cry*
<mdke> *grin*
<mdke> dholbach, the -desktop list is not safe either :)
* mdke urges everyone to use the -doc list
<ploum> "you are not fun anymore"
* ploum dressed as a knight, slaps mdke with a chicken
<dholbach> mdke: not at all
<tseng> you could all stop reading the mailing lists
<tseng> it works great for me.
<LaserJock> tseng: I think it is some sort of "Pavlov's Dogs" experiment where we are wading through all the muck to find a "treat" here or there.
<sistpoty> yeah... I used to sort them into appropriate folders in the past instead of reading... now I found out that filters can do that, so I only need to mark them read ;)
<ploum> filtering on "codecs, legal, patents, multimedia" just remove half of the devel-list without any problem
<LaserJock> the problem for me is that I care about the issue, just not all the noise :(
<ploum> In fact, most people are just writing what they believe, without thinking nor reading answers
<janimo> hmm is apt-get installing packages in Recommends somehow?
<Riddell> Kamion: yeah, bzr got the better of me and I deleted and added gtkui.py, can't even remember why now.  that gtkui.py is full of debugging lines
<Burgwork> mdke, there is no ubuntu-private
<Riddell> Kamion: moving liveinstaller.ui to a subdirectory was on my todo for when everything else works 
<Mithrandir> Riddell: you do know about bzr revert?
<LaserJock> janimo: aptitude does by default. sure your using apt-get?
<Riddell> Mithrandir: nope :)  but I should learn it
<Mithrandir> Riddell: "uncommit" is also handy when you've committed something you shouldn't have
<ploum> Is the  "Add to panel" dialog customized for Ubuntu or from standard GNOME ?
<ploum> http://bugzilla.gnome.org/show_bug.cgi?id=331768 : this bug look more like an Ubuntu one
<Ubugtu> gnome2 bug 331768 in Panel "gnome panel crash" [Critical,Unconfirmed]  
<seb128> ploum: Ubuntu
<seb128> ploum: a debug backtrace is required for it
<ploum> seb128: have you xchat configured to beep every time someone say "bug" ?
<ploum> seb128: ok, I will ask him the backtrace
<seb128> no, but I tend to read ubuntu chans :p
<seb128> gnome-panel-dbg libglib2.0-0-dbg
<ploum> seb128: are they on http://people.ubuntu.com/~seb128/hoary_dbgdebs/ ?
<seb128> no, -dbg are standard packages, synaptic or apt-get them
<ploum> cool ! 
<ploum> I didn't know about them...
<seb128> the packages I put on my people package have no -dbg to the name
<janimo> Laserjock, sure apt-get.thanks
<janimo> I have to see why does gnome-session get installed by xubuntu-deskto
<janimo> p
<seb128> because GNOME is good? :)
<ploum> There is only one Desktop and seb128 is his packager !
<ploum> (and jdub is his prophet )
<ploum> Well, I usually say :
<ploum> There is only one distribution and Mark is his prophet
<sivang> amen to that :)
<ploum> And then I show picture from old and new jdub : "See ! Our prophet is now hairless ! He's pure ! He will show us the way to the Nirvana ! Come my brother in our world of peace !"
<ploum> And eventually they keep Windows...
<Panzerboy> hey all
<Panzerboy> i cannot install beagle in dapper, the error message i get is  beagle: Depends: libgalago-cil (>= 0.3.2) but it is not going to be installed
<Panzerboy> can this be a bug?
<Panzerboy> ;)
<Burgwork> Panzerboy, likely, please file
<ploum> Panzerboy: I don't have this bug anymore
<ploum> I can install beagle now
<ploum> I had it for a long time
<ploum> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=331768   tes dsirs sont des ordres ;-)
<Ubugtu> gnome2 bug 331768 in Panel "gnome panel crash" [Critical,Unconfirmed]  
<seb128> ploum: merci :))
<Panzerboy> ploum: hmmm ...
<Panzerboy> ploum: any idea how did u solve it? :D
<ploum> Panzerboy: apt-get install beagle just now...
<Pygi> what version of liboil is included in dapper?
<Panzerboy> ploum: hmmm ... let me try to update
<ploum> Panzerboy: what is said when you apt-get install libgalago-cil ?
<Panzerboy> ploum: 1 sec ...
<Panzerboy> ploum: The following packages have unmet dependencies:
<Panzerboy>   libgalago-cil: Depends: libgalago1 (>= 0.3.2) but it is not going to be installed
<Kamion> libgalago1 | 0.3.3-2ubuntu2 | dapper/universe | amd64, hppa, i386, ia64, powerpc, sparc
<ploum> Panzerboy: and what is the problem with this one ?
<ploum> try : apt-get install  libgalago1
<Kamion> you sure your packaging system isn't confused? apt gets a bit muddled sometimes - try 'apt-get -f install'
<Panzerboy> Kamion: right, trying now
<ploum> apt-get is not a cartesian software. You must use your intuition rather than your intelligence
<ploum> that's perhaps why I like it
<Panzerboy> Kamion: that was it, installing libgalago1 now
<Panzerboy> aaaaand now beagle :0
<Panzerboy> thanks a bunch!
<Panzerboy> the problem was that i've interrupted an installation of deskbar-applet before, and that's what probably confused apt
<Kamion> yes
<florian_kc> bbl
<Pygi> will dapper ship with everything ready *packages* to properly build gst-plugins-base?
<ploum> Kamion has a better intuition than mine...
<dholbach> Pygi: what do you intend to do?
<Pygi> dholbach: well, I need it for development...
<Pygi> I am currently struggling with compiling all the things I need from source :)
<dholbach> if you look at http://packages.ubuntu.com you will see which packages are available
<Pygi> hm, will those packages be upgraded by the time we ship?
<dholbach> after the release no
<Pygi> well, I mean before the release :)
<dholbach> we have the newest released version in
<Pygi> nop, we don't actually
<Pygi> if I am not mistaken, liboil in repos is 0.3.6-1, and newest is 0.3.7
<Pygi> yup, me is correct :)
<dholbach> i thought you were talking about gstreamer
<dholbach> if you have good reasons for stuff to be updated, you should file a bug report
<dholbach> because we're in upstream version freeze now
<Pygi> yes, I do understand that...
<Pygi> ah, guess I should have reported that earlier..
<Pygi> nvm then, thanks for help
<dholbach> It it's important and has fixes, it's great if you let us know.
<Pygi> just noticed that oggdemux,oggmux, theoradec,theoraenc, vorbisdec, xvimagesink,and entire gst-plugins-base is missing :-/
<Pygi> dholbach: If I am not mistaken, gstreamer depends on liboil...altought it can be compiled with the version that is provided with dapper, 0.3.7 is suggested one
<dholbach> yeah, i know it's built with it
<dholbach> seb128: you read that about liboil? maybe it fixes the strange liboil bug we have
<seb128> maybe
<seb128> worth trying :)
<Pygi> dholbach, seb: what's the bug?
<seb128> Pygi: from where?
<Pygi> seb128: http://liboil.freedesktop.org/wiki/
<dholbach> Pygi: bug 5861
<Ubugtu> malone bug 5861 in liboil "Error message shown during installation of gst plugins by apt-get" [Normal,Confirmed]  http://launchpad.net/bugs/5861
<seb128> Pygi: I was asking about "oggdemux,oggmux, theoradec,theoraenc, vorbisdec, xvimagesink,and entire gst-plugins-base is missing"
<Pygi> seb128: well, from the dapper repos
<seb128> gstreamer0.10-x: /usr/lib/gstreamer-0.10/libgstxvimagesink.so
<seb128> by example
<Pygi> dholbach: well, when we don't have all dependencies...and don't know how the package was built...
<dholbach> Pygi: apt-cache show <package> will show you dependencies
<Pygi> dholbach: yup, i know
<dholbach> Pygi: and packages wouldn't build if they didn't have sufficient build dependencies
<dholbach> seb128: freedesktop bug 5406
<Ubugtu> freedesktop bug 5406 in unknown "function fbCompositeSolid_nx8888mmx in class composite_over_argb_const_src failed check" [Normal,Resolved: fixed]  https://bugs.freedesktop.org/show_bug.cgi?id=5406
<Pygi> dholbach: actually, packages like gst-plugins-base can be built without some dependencies
<dholbach> seb128: might be worth the update
<dholbach> seb128: want me to look?
<herzi> ogra_: ping
<dholbach> seb128: although... that's a gst0.8 problem... hm
<ogra_> herzi, pong
<herzi> https://launchpad.net/distros/ubuntu/+source/gartoon/+bug/30147 is still broken
<Ubugtu> malone bug 30147 in gartoon "gnome-icon-theme-gartoon has got the wrong GTK_STOCK_GOTO_FIRST icon" [Normal,Unconfirmed]  
<Pygi> dholbach: hopefully I haven't created too much trouble by mentioning this...if everything works fine, no need to update liboil
<dholbach> Pygi: i'll check the changelog
<seb128> dholbach: if you want, I don't know that code enough to have an opinion
<Pygi> dholbach k, thanks
<ogra_> herzi, the funny thing about that bug is that its only a filename error :) gtk-goto-first-ltr contains the rtl image and -rtl contains ltr :)
<mrzero> fabbione: do you run a self modified version of irclog2html ?
<dholbach>  Good night!
<pitti> night dholbach 
<dholbach> night pitti
<Pygi> night
<dholbach> Pygi: checked it, looks good, filed an upstream version freeze exception report
<dholbach> Pygi: bye Pygi
<Pygi> k, thanks
<tseng> ogra_: going to guadec?
<ogra_> tseng, barcelona ? i think so ...
<tseng> ogra_: ok
<tseng> ogra_: im looking into it
<ogra_> cool :)
#ubuntu-devel 2006-02-28
<xerox_> Do you know how to adjust those things changed in the latest kernel releases?  I have CPUfreq which doesn't go to 100% when I do computational-expensive things... i.e. compilations take ages!  That's so bad... but I see what it *could* be useful for, in a desktop system.
<CarlFK> https://launchpad.net/distros/ubuntu/+source/preseed/+bug/31435 
<Ubugtu> malone bug 31435 in preseed ""put grub where?"" [Normal,Rejected]  
<CarlFK> I have that again, but I think it falls into the "/dev/sda1 is trashed" case - sda1 is for swap, sda2 is for raid
<CarlFK> however, the installer is trying to use (hd0) but failing, which I think is a problem
<sivang> ogra_: guadec in barcelona, sounds cool
<sivang> ogra_: any canonical/ubuntu people other then you will be there?
<Burgwork> sivang, jdub I imagine
<sivang> Burgwork: ah right, GNOME release manager after all :)
<Burgwork> sivang, not anymore, but I imagine seb and dholbach might be going
<Burgwork> sivang, http://www.pcmag.com/slideshow_viewer/0,1205,l=&s=26945&a=171997&po=41,00.asp <-- this screenshot and the next 3
<ajmitch> iirc jdub is no longer release manager for GNOME
<Burgwork> sivang, actually, the next 5
<sivang> Burgwork: it appears to be a common hot issue these days, but for the record I'd say that madrake/madriva were the first to come up with something very simialr to what vista screenshots you showed me
<sivang> :)
<sivang> Burgwork: and they did it quite a while ago
<Burgwork> sivang, just wanted to show you
<sivang> Burgwork: yes, thanks, it's good to see they have choosen the same approach (the 'simplistic' approach)
<CarlFK> c: 48GB drive with 39 free - think there is anything other than the OS? ;)
<Burgwork> CarlFK, likely it is a fresh install
<CarlFK> how many DVD's does it take?
<Burgwork> the new Vista? no idea
<CarlFK> i was just amused at the 9gig used on what probably is just the OS
<Burgwork> yes, ouch, and that doesn't include the office suite, etc.
<Kamion> WOOT
<Kamion> my python bindings for the evolution map widget work
<Burgwork> is that the zooming map widget?
<Kamion> yeah
<Kamion> well, the zoominess is separate
<Kamion> or at least the control of it; the map widget itself does implement some of the zooming
<Burgwork> should I try flight 4 or the daily espresso?
<Kamion> daily will give me more useful debug information if it fails
<Burgwork> ok
<Kamion> (/var/log/installer/espresso)
<Burgwork> ok, will do tonight
<Kamion> yup, zoominess works too
* ogra_ applauds Kamion 
<TheMuso> Kamion: When is the next daily CD run due?
<TheMuso> That includes the updated gfxboot-theme-ubuntu package?
<Kyral> Could we get a jigdo for the Daily Live?
<CarlFK> Kyral: the .torrents are working really well
<Kyral> CarlFK: my school blocks Torrents rather effectively
<pitti> Kyral: live CDs can't be built with jigdo
<Kyral> oh
<pitti> (at least not in a sensible way, that is)
* Kyral sighs
<Kyral> Is there anyway to diff it and make it so I don't have to download it (with my cap) every day?
<TheMuso> Kyral: rsync
<Kamion> TheMuso: 31 7 * * *      for-project ubuntu cron.daily; for-project ubuntu cron.daily-live
<Kyral> I almost forgot about rsync
<Kamion> that's London time
<Kyral> I dunno how to use it lol. Maybe grsync
<sivang> Kamion: do you ever sleep? :)
<Kamion> sivang: not with feature freeze approaching fast
<pitti> Kyral: rsync -vP rsync://cdimage.ubuntu.com/cdimage/daily-live/current/dapper-live-amd64.iso dapper-live-amd64.iso
<TheMuso> Kamion: Thanks. Looks like I will have to wait a while. :)
<sivang> Kamion: :)
<pitti> Kyral: but please move this to #ubuntu
<sivang> Kamion: :)
<Kyral> pitti: sorry
<infinity> pitti: How far did you/carlos/cprov get with translations uploads?
<pitti> infinity: pretty good actually
<infinity> pitti: I saw some talk in #c about putting all the .po files in the .changes individually (!)... I hope they got talked out of that.
<pitti> infinity: http://librarian.dogfood.ubuntu.com/1567507/buildlog_ubuntu-dapper-i386.ept_1.90ubuntu1_FULLYBUILT.txt.gz
<pitti> infinity: yes, I think so, they'll just use the tarball
<pitti> Files: 
<pitti>  03d022cea06cf976d6201b1a04b2965f 3256452 kde optional adept_1.90ubuntu1_i386.deb
<pitti>  3da9cc970c74e69cea92675e16cbf27b 4378 raw-translations - ept_1.90ubuntu1_i386_translations.tar.gz
<infinity> Yeah, the .changes looks good.
<infinity> Now, is it being handled by soyuz? ;)
<pitti> infinity: apparently; carlos needs to check the import tomorrow though
* infinity nods.  Fair enough.  Sounds good in any case.
<CarlFK> Kamion: can you read the comment that starts "repo, but not using the preseed file." https://launchpad.net/distros/ubuntu/+source/preseed/+bug/31435
<Ubugtu> malone bug 31435 in preseed ""put grub where?"" [Normal,Unconfirmed]  
<CarlFK> and tell me if you have any interest?
<CarlFK> or should I hit reset and do it again with /boot outside the raid
<Kamion> CarlFK: looks like an entirely separate bug
<CarlFK> oh
<Kamion> CarlFK: in that syslog, grub-installer says that installing grub failed
<Kamion> which is apparently because grub couldn't read the stage1
<Kamion> it probably just can't handle /boot being on RAID
<CarlFK> i just rebooted and am back to the parition step
<Kamion> now isn't really the best time for me to go through it with you step by step though, sorry - I have a bunch of code to write before I can go to bed
<CarlFK> no problem
<CarlFK> your call - I'm just having fun banging on it and seeing what falls apart
<CarlFK> Ill try /boot on its own partition and see how that goes
<doko> infinity: please requeue valgrind on amd64, builds for me
<infinity> doko: Looks like it wants a build-dep on libc6-i386?
<doko> infinity: it does have one
<doko> 3.1.0-2.1
<infinity> Oh, I don't see -2.1 in soyuz, only -2
<doko> you're right.
<infinity> Right, so upload that and your problems are solved, I assume. :)
<doko> hmm, ok, uploading as 3.1.0-2.1build1
<infinity> I don't see an upload of -2.1, ever.  -2.1build1 wouldn't be necessary.
<infinity> But whatever. :)
<funkyHat> Is Normal XChat still available in Dapper? In universe or something. I'm running Flight 4 Live CD in VMware and I think XChat-GNOME is poop
<tseng> thats an #ubuntu question (topic)
<pitti> hello
<infinity> Yo, pittster.
<freeflying> pitti: hi
<ajmitch> hi pitti 
<pitti> hi infinity, hey freeflying 
<spacey> good morning
<Pygi> mornin' everyone
<freeflying> pitti: how about your discussion on scim/skim yestoday ?
* pitti -> at phone, brb
<mpt> pitti: Does it, or could it, ever happen that one Ubuntu bug report is associated with more than one CVE report?
<Mithrandir> yes, if a person reports more than one vulnerability in a bug.
<Mithrandir> "Hi, package $foo seems to be vulnerable to CVE-$bar, CVE-$baz, please fix, kthxbye"
<HiddenWolf> Mithrandir: lol
<mpt> Would it be unreasonable to say "one bug per bug report please, kthxbye"? Or to split out the bug reports yourself?
<mpt> If so, that could make Malone's CVE interface a lot simpler
<Mithrandir> can you clone bug reports in malone?
<infinity> mpt: It's also been known to happen that our fix was "better" than upstream's and caught two CVEs in one (yes, I have a practical example of this)
<mpt> hmmm, ok
<infinity> mpt: It would seem silly to file a second bug report to track the second CVE which we fixed as a result of the first.
<Mithrandir> infinity: *cough* PHP *cough* ?
<infinity> Mithrandir: How'd you guess? :)
<mpt> ok, thanks
<infinity> mpt: Can't there just be a list of "associated CVEs"?
<infinity> I don't see that as being overwhelmingly complex to read/use.
<infinity> Hrm, someone tripped over the wire to New Zealand.
<ajmitch> fairly typical 
* mpt growls
<pitti> re
<pitti> hey seb128 
<seb128> hi pitti
<pitti> mpt: actually, I planned with Brad that we'll semi-automatically open new bugs for new CVEs for tracking;
<Pygi> mornin' seb
<pitti> mpt: however, for manual reporting, several CVEs could be handy
<seb128> hi Pygi
<mpt> pitti, ok then
<dholbach> good morning
* infinity decides that everyone waking up is a fine time for him to quit work..
<infinity> See you all around meeting time.
<dholbach> infinity: nice work u-down
<infinity> dholbach: Yeah, it still needs a few bugfixes in usplash to make it less goofy, but I needed to upload something before featurefreeze, so I had bugs to work on for the next month. :)
<dholbach> infinity: i tested it on two machines, it's nice! ROCK ON!
<Pygi> mornin' dholbach
<dholbach> hey Pygi
<pitti> good night infinity 
<dholbach> hey pitti
* pitti hugs dholbach 
* dholbach hugs pitti back!
<mdke> jdub, see "your" email on sounder?
<TheMuso> dholbach: Basic accessibility profile stuff is done, and Mithrandir should have it by now.
<dholbach> Nice!
<dholbach> good work :)
<seb128> infinity: know about /usr/share/lintian/overrides/python2.4-samba conflict between python2.4-samba and samba?
<mdke> what package does the disk space notification stuff?
<sivang> re all
<infinity> seb128: I do now.  Can you file a bug for me so I can fix it when I get home?
<seb128> infinity: sure
<infinity> seb128: Oh, I see, the old package was buggy.  Feh.
<infinity> seb128: The file wasn't in the wrong package in breezy.  Do we care deeply about having the Replaces in there just for smooth dapper->dapper upgrades?
<infinity> seb128: If so, I'll fix it when I get back.
<seb128> infinity: usually I do use a Replaces until next sync with Debian
<seb128> where I drop it
<pitti> mdke: gnome-volume-manager
<seb128> that avoids to get 40 people asking on IRC about it
<infinity> seb128: Sounds fair to me.
<seb128> infinity: bug #32585
<Ubugtu> malone bug 32585 in samba "conflict between python2.4-samba and samba" [Normal,Unconfirmed]  http://launchpad.net/bugs/32585
<mdke> pitti, thanks
<seb128> Kamion, mdz: would updating xchat-gnome to a new version (new "sound plugin" and mostly polish, cleanup, bug fixing) would be ok?
<Kamion> seb128: yes, fine
<seb128> thank you
<Kamion> seb128: though I'd like to see the changelog
<seb128> Kamion: k, I'll mail mdz and you with it when they have roller the tarball
<seb128> s/roller/rolled
<Kamion> thanks
<seb128> np, thank *you* :)
<TheMuso> What would be an appropriate way to refer to the GNU free documentation license in the debian/copyright file?
<Kamion> copy/paste the text of the licence
<TheMuso> ok
<mpt> Kamion, yo
<Kamion> obviously listing the copyright holder and any text used to apply the licence to the docs at the top
<Kamion> mpt: hiya - so I'm working on Espresso's location page at the moment
<Kamion> mpt: I've got the zoomy map ported over from Evolution (I'll undo the zoominess later, was just easier to port the whole thing)
<Kamion> mpt: I'm having a bit of trouble working out how to do the timezone option menu you proposed, though
<Kamion> mpt: it appears that we meant it to be a list of timezone names, presumably in some kind of "more canonical" form (so GMT rather than Europe/London, say)
<dholbach> Kamion: like in   gksudo time-admin   ?
<Kamion> mpt: but this turns out to be unexpectedly awkward; firstly there's no list of all such timezone names anywhere, and secondly some of them clash with each other (e.g. EST)
<mpt> oh.
<Kamion> dholbach: yeah, same widget
<Kamion> gnome-system-tools lifted it from evolution too, I actually used the gnome-system-tools code because it was better-encapsulated
<mpt> Kamion, but given a city, you know what timezone it's in?
<Kamion> mpt: yeah, and it's quite easy to get the letter-abbreviation name for a given timezone
<Kamion> so I was thinking maybe turn that into a label rather than an option menu?
<mpt> Kamion, ok, how about making the timezone text instead of a control
<mpt> yeah
<mpt> snap
<Kamion> I know we put it there in case you knew your timezone but (for whatever reason) not the nearest city in that timezone
<Kamion> but if the text updates dynamically as you move the mouse over the map, I reckon it shouldn't be too bad
<mpt> yeah
<mpt> that's fine
<Kamion> ok, great
<Kamion> shall I amend the spec accordingly?
<mpt> I can do that if you like
<Kamion> if you don't mind, sure - no need to spend time doing a new mockup though, if it's just "put a label in the place where the option menu used to be"
<Mithrandir> uh, where did the "print" option in the gimp go?
<Kamion> hmm, the way time-admin centres the city name in its hover-text is sort of suboptimal
<Kamion> it means the start of the city name jumps about and it's hard to read on the fly
<Kamion> dholbach: (same widget except that I ported everything but the map itself to Python so that I could fiddle around with the UI more easily ;-))
<dholbach> Mithrandir: you need gimp-print package
<dholbach> Kamion: you rock!
<seb128> lifeless: what version of evolution do you use?
<dholbach> does anybody have some .swf files to share?
<HiddenWolf> dholbach: just rip some off the flash/shockwave sites.
<dholbach> HiddenWolf: rip off?
<HiddenWolf> dholbach: you can probably just download them off the sites.
<dholbach> that's what I looked for, but it proved less easy than I though
<dholbach> t
<Pygi> dholbach: how should I send them to you?
<dholbach> dholbach@ubuntu.com - if that works for you
<Pygi> 3 enough? or more needed?
<dholbach> Pygi: 3 sounds like a good start - thanks a lot
<Pygi> k, once you need more please let me know
<highvoltage> what's the new ubuntu version after dapper going to be called?
<tepsipakki> highvoltage: AFAIK, it's not named yet
<ogra_> dapper+1 :)
<jdub> BUENOS DIAS, AMANTES DE LA LIBERTAD!
<highvoltage> ogra_: :)
<pitti> hey jdub 
<Pygi> ogra: hehe :)
* highvoltage votes for Obsessed Ogre
<highvoltage> :)
<Pygi> one week after release or something like that naming is done if I am not wrong?
<jdub> Pygi: it's usually quietly known for a while
* jdub has been calling it edgy to influence the decision :)
<Kinnison> hehe
<doko> pitti, Riddell, dholbach, everybody: please could you check out "deb http://people.ubuntu.com/~doko/tmp/OOo2 ./" if printing still works?
<doko> pitti: ... and how to change the language packs
<Riddell> printing?  that's for people who like, print.
<Riddell> doko: renamed to s/2//?
<doko> Riddell: yes
<Riddell> seems to bring in awhole load of libgnomeprint stuff
<pitti> doko: langpacks change? due to the renaming of the locale packages?
<doko> pitti: -l10n and -help packages
<pitti> doko: alright, I can clean that up right after it gets uploaded
<Pygi> everyone: any chance that we can patch gaim for dapper to say to users that they are breaking TOS when we are not removing that functionality?
<hunger> Any chance of getting the r300 driver working in dapper?
<hunger> From what I understand the stuff should be Xorg as used in dapper already.
<Pygi> hunger: r300 is heavily unstable
<theine> Hi, will the latest stable version of the ipw2100 driver (1.2.0) be part of Dapper's kernel?
<hunger> Pygi: I got positive feedback from my gentoo-using friends... not that this is a garantee for anything;-)
<lemsto> has a bug report been made for mouse buttons problem in xorg? (11 buttons when 7 is set). Many people are talking of it on ubuntu forums but i can't find a bug report about it....
<Pygi> hunger: even on their site:  It is *UNTESTED* and *BROKEN* ! :)
* hunger keeps getting (EE) Failed to load /usr/lib/xorg/modules/extensions/libGLcore.so
<Pygi> hunger: we tend to take catious steps :)
<hunger> Is that normal?
<hunger> Pygi: Yes... I know. But then Xgl is, too;-)
<hunger> Pygi: And without r300 I can not even test that;-)
<Riddell> doko: "No Default Printer Found"  crash
<doko> Riddell: crash?
<Pygi> hunger: well, you can install it, but it shouldn't be there by default
<Riddell> openoffice.org-kde bringing in gtk/atk/pango/cairo is quite evil
<Pygi> hunger: Xgl is proved to work, but r300 is no-no :-/
<Riddell> doko: yes
<hunger> Pygi: Xgl is proven to work?
<doko> Riddell: gnome or kde desktop?
<hunger> Pygi: All 3 people trying it had their machines frozen when opening the first window...
<Riddell> doko: kde
<hunger> Pygi: Of course that is only the people I know:-)
<mdke> Kamion, mdz, could you have a look at approving ubuntu-docs 5.10-6.3, you should find it somewhere in the breezy-updates queue
<Kinnison> hunger: Xgl vaguely worked on my laptop
<doko> Riddell: no, it's in -core, we will assimilate you ...
<doko> pitti, dholbach: does printing work for you?
<hunger> Well, no use in discussing relative brokeness of features. Too bad r300 won't make it in dapper, even though I do understand the reasoning.
<pitti> doko: downloading in progress...
<pitti> doko: oh, a dist-upgrade doesn't catch it
<pitti> doko: will there be transitional packages?
<doko> doko: no, -desktop will depend on the right things
<hunger> Does udev handle creation of /dev/udev/card* ?
<hunger> s/udev/dri/
<pitti> doko: and for all the poor lads who don't have -desktop installed?
<Kamion> mdke: likely to go through breezy-updates just after feature freeze
<pitti> doko: ah, boggle, I know why I can't install anything - no amd64 packages
<Kamion> mdke: what about ubuntu-docs 5.10-7?
<Kamion> was it the obsolete one?
<mdke> Kamion, who uploaded it?
<mdke> if it was daniel back in december, then yes, obsolete one
<Kamion> the changelog says you, but it was back in December
<Kamion>    * new text, image and css in /usr/share/ubuntu-artwork/home/index.html (Ubuntu #15013, #16932, #17605 and #20692)
<Ubugtu> ubuntu bug 15013 in About Page "About Ubuntu page needs proper theming" [Normal,Resolved: fixed]  http://bugzilla.ubuntu.com/show_bug.cgi?id=15013
<Ubugtu> ubuntu bug 16932 in ubuntu-docs "firefox default page: section "Kernel" talks about GNU" [Normal,Resolved: fixed]  http://bugzilla.ubuntu.com/show_bug.cgi?id=16932
<Kamion>    * new and updated translations for about-ubuntu and faqguide
<Ubugtu> ubuntu bug 17605 in About Page "no version listed on first page of About Ubuntu" [Normal,Resolved: fixed]  http://bugzilla.ubuntu.com/show_bug.cgi?id=17605
<mdke> right yeah kill that please
<mdke> i thought it got killed when 5.10-6.2 was processed
<Kamion> nah, katie couldn't really reject from the unapproved state so it sat around forever
<Kamion> fortunately, soyuz can, so rejected
<mdke> yay
<Kamion> and ubuntu-docs_5.10-6.3 looks pretty straightforward actually - accepted
<mdke> thanks, yes it's really simple
<pitti> Kamion: can you please demote python-osd to clean up anastacia a bit?
<TheMuso> c
<TheMuso> sorry, wrong window.
<Kamion> pitti: anastacia's not listing it for demotion ...
<doko> pitti: you can start them from a i386 chroot
<pitti> Kamion: odd, it has no reverse deps
<Kamion> ubuntu-server-dapper/server: * python-osd
<Kamion> I'll fix the seeds
<pitti> oh, server
* pitti merges
<pitti> oh, ok
<pitti> thanks
<lifeless> seb128:  2.5.91-0ubuntu1  
<lifeless> mjg59: ping
<seb128> lifeless: k, ... upstream have reopened the bug, a debug backtrace would be welcome but you can wait on the new -dbg that will come probably for that
<lifeless> seb128: ok
<dexem> what's the package name of the new installer? I want to fill a bug against it...
<Riddell> seb128: where can I find the default font sizes in gnome?
<tepsipakki> dexem: debian-installer
<tepsipakki> dexem: or do you mean espresso on the live-cd?
<seb128> Riddell: gconftool-2 -R /desktop/gnome/interface | grep font
<seb128> Riddell: and the window manager is somewhere else probably
<seb128> why?
<seb128> the font for the wm I mean
<dexem> tepsipakki: espresso :)
<jdub> ogra_, Kamion: that u-a upload hasn't hit the archive  yet, right? is it out of NEW?
<mjg59> lifeless: Hi
<ogra_> jdub, dunno if Kamion finally approved it 
<jdub> ogra_: you added some images and created a new package in control, right?
<lifeless> mjg59: hi
<ogra_> jdub, i created a new package and only copied the default wallpaper so far ...
<lifeless> mjg59: tracked down one resume lockup
<lifeless> https://launchpad.net/distros/ubuntu/+source/linux-meta/+bug/32593
<Ubugtu> malone bug 32593 in linux-meta linux "Dell X1 fails to resume with mmc_core and sdhci modules loaded" [Normal,Unconfirmed]  
<ogra_> jdub, the source should be in the archive ...
<lifeless> mjg59: hibernate appears borked though, the hibernate key has stopped working
<Riddell> seb128: trying to get KDE fonts to match (we are using a mostly fixed DPI now)
<Riddell> seb128: so 10 is the default?
<seb128> yep
<seb128> depending of what you speak about
<lifeless> mjg59: I found some weird gnome option to turn suspend into hibernate and I tried that, it appeared to hang during the hibernate process - left it for 15 minutes with the disk light hard on, no seeking appeared to happen.
<seb128> interface is "Sans 10" by default
<lifeless> mjg59: want a bug filed about the hibernate button regression ?
<mjg59> No, that'll be fixed soon
<lifeless> mjg59: ok. Want one on hibernate taking so long/hanging ?
<janimo> hunger, there are some people who have dri working with r300 in dapper (not me though)
<StevenK> I've found hibernate taking an age in breezy.
<mjg59> lifeless: That's more interesting
<StevenK> I moved back to -9-686 and it seems to have stopped doing that.
<mjg59> lifeless: Can you disable the dpms stuff in /etc/default/acpi-support ?
<mjg59> That may get you some more diagnostic output
<lifeless> mjg59: sure.
<lifeless> mjg59: I shall try a hibernate now
<lifeless> mjg59: do you need more detail on the mmc_core/sdhci thing ?
<lifeless> mjg59: I presume unloading them during suspend/resume will fix it trivially.
<mjg59> lifeless: I'll look into it. Does your sd slot work?
<lifeless> mjg59: dunno. won't with them removed :)
<lifeless> hang on, I'll load them and find my demo card
<Kamion> jdub: I was a bit scared by a new 2MB package that was to go on the CD
<Kamion> jdub: and was unconvinced that it should be split in the first place
<Kamion> but whatever, I'll approve it in a bit
<jdub> Kamion: whoa, whoa,
<jdub> Kamion: i don't disagree :-)
<jdub> Kamion: i wanted to see the changes first :-)
<Pygi>  dholbach: ping
<dholbach> Pygi: pong
<Pygi> what was the result of the test?
<lifeless> mjg59: yes it works
<jdub> whoa, pitti's playing whack-a-png
<lifeless> put in the card, up it came in a file browser
<lifeless> eject it and it unmounted
<lifeless> mjg59: ok, I've changed the acpi default-support stuff
<dholbach> Pygi: it didn't change much, i felt
<Kamion> jdub: they're in the archive - do you want to review them before I accept?
<lifeless> mjg59: I'm trying a hibernate run.
<Kamion> source, anyway
<Kamion> http://archive.ubuntu.com/ubuntu/pool/main/u/ubuntu-artwork/ubuntu-artwork_0.2.29-1.dsc
<jdub> Kamion: ok, sec
<Pygi> dholbach: k, so no update then?
<dholbach> i did the update already
<jdub> ogra_: ping
<Pygi> dholbach: ah,kk
<Pygi> g2g now, bye all
<jdub> whoa
<jdub> huh
<jdub> this makes now sense
<jdub> no sense
<ogra_> jdub, ?
<jdub> ogra_: what's the rationale for the separate package, and why should it include a separate copy of a 1.9M desktop background? :)
<ogra_> jdub, the copy is a dummy ... it shall contain the image collection of screensaver backgrounds
<lifeless> mjg59: so hibernate is better now
<lifeless> mjg59: it came back up but failed to load the bios modes
<lifeless> mjg59: for the 915 driver
<lifeless> it didn't take the 15 minutes this time, dunno why.
<mjg59> lifeless: Upgade 915resolution
<jdub> ogra_: why a separate package?
<lifeless> mjg59: restarting X seems to have fixed it
<lifeless> mjg59: ok. Will do.
<ogra_> jdub, because it might get huge in the future and we'll probably make it only recommended ...
<jdub> ogra_: so it won't be a depends of ubuntu-desktop?
<pitti> sjoerd: do your recent dbus commits fix the hang of h-device-mgr?
<ogra_> jdub, for now it will ...
<ogra_> jdub, but if it grows to big for the CD we can easily remove it there ...
<jdub> Kamion: how are we doing for CD space?
<sjoerd> pitti: afaik that's still not fixed :(
<pitti> sjoerd: hm, ages ago j5 said that he had a patch to commit to fix that :(
<sjoerd> pitti: Robot101 should know a lot more about dbus internals then me, so maybe he knows what's going on with that issue :)
<sivang> Kamion: tryreadlines() is the non blocking reading method?
<Kamion> jdub: not very comfortably
<Kamion> sivang: yes
<Kamion> obviously if you need non-blocking output as well then it gets rather harder, since you might not manage to output everything you want at once
<sivang> Kamion: I was hoping to be able to propogate the spawned child's stdout, and when it says on stderr "Please swtich to slice #X" to re.match it and propogate to the client code. I have this code already working, it's just that when my function matches this in stderr, it yeilds back (being a generator) to the caller, where the caller sys.stdin.readline()'s. at this point the caller's user CRs, and then it appears you need varying number of CRs to 
<sivang> hmm, I'm now thinkign of making stderr and stdout add up in the same buffer form the spanwner POV, then process only one buffer
<Kamion> perhaps your caller is just not flushing its output after writing to it
<jdub> Kamion: so 8MB would make your hair stand on end?
<Kamion> jdub: definitely
<Kamion> and I should hope it'd make ogra's hair stand on end too, given that Edubuntu is the worst-off for space
<jdub> Kamion: hrm, not much hope for a screensaver images package then, i reckon
<infinity> pitti: Thanks for the PNG transition uploads, dude.
<Kamion> dexem: please don't set milestones on bugs ... we'll do that at developer's / release team's discretion
<pitti> no problem
<jdub> Kamion: are you counting current example-content size?
<pitti> infinity: gnome-panel will be done by seb128, the rest of main should be settled
<Kamion> jdub: I'm trying not to think about it
<Kamion> jdub: I also haven't looked at sizes since example-content landed. However, before that I had to remove a bunch of language packs to get us within size.
<infinity> pitti: Rock.
<Kamion> 20/30MB worth of language packs in some cases
<viviersf> infinity, i put a new script into the casper dir , now the initramfs is giving problems, any idea why ?
<infinity> viviersf: Define "giving problems"...
<viviersf> ok well lemme explain
<viviersf> live cd sais : mounting root fs
<viviersf> after putting my script
<jdub> ogra_: dude, i don't think there's much hope for screensaver images, unless we co-opt a bunch of crap we're already installing (which could include example-content)
<viviersf> it hangs at that script
<viviersf> just doesnt do anything
<pitti> infinity: is the new pkgstriptranslations (22) already installed into the buildd chroots?
<lifeless> mjg59: its up to date already
<Kinnison> pitti: the chroots upgrade themselves as part of the build process
<infinity> pitti: If it's in the archive, the chroots upgrade automatically.
<Kinnison> pitti: so once it was built and in the archives, the chroots started using it
<lifeless> mjg59: tried again and its still leaving X uphanppy
<pitti> Kinnison: cool; even if it is permanently installed?
<infinity> (For better or worse)
<pitti> that's great anyway
<infinity> pitti: Yeah, at the beginning of the build, a dist-upgrade is done.
<viviersf> infinity, you understand the problem ?
<ogra_> jdub, its one of my feature goals ... mark wanted a possibility to push image collections as screensaver backgrounds *shrug*
<pitti> Riddell: can you please do a no-change upload of amarok to build with newer pkgstriptranslations? with the previous version we didn't get translations
<Kinnison> infinity: actually you and I should try and pick a time to coordinate updating the chroots to reduce the buildd times
<ogra_> jdub, you were at least at one of the BOFs we held about it 
<infinity> viviersf: I guess I'd need to see what your script does, and where you're putting it. And preferably not when I'm supposed to be going to bed.
<infinity> Kinnison: Yes, we need to play with the chroot tool some more and make sure I can do it myself on a whim.
<jdub> ogra_: we're screwed for room - that doesn't mean we can't do it either off the CD (recommended) or if we want at least something on the CD, co-opting other images already on the disk
<viviersf> ok 
<Kinnison> infinity: aye
<infinity> Kinnison: I'll need to be able to mangle them to make sure they're lean and light, etc.
<viviersf> whats the time there infinity ?
<dexem> Kamion: sorry for that :P
<Kinnison> infinity: can we coordinate a time to play next week?
<jdub> ogra_: i'm definitely not saying "let's not do this at all" :)
<Kinnison> infinity: It'd be worth getting cprov to sort out a newer version of the launchpad-buildd package too, I did a couple of fixes to it last week
<infinity> viviersf: 23:13
<infinity> Kinnison: Please.
<mjg59> lifeless: Can you check that you have /etc/acpi/resume.d/915resolution?
<viviersf> infinity, kewl ill bug you with it 2moz
<infinity> Kinnison: I need to get some fixed committed for sbuild before we roll out a new package.
<infinity> Kinnison: s/fixed/fixes/
<ogra_> jdub, i'm aware of the space problems (edubuntu is way worse) including the images in the artwork package itself would be silly, thats why i split out that package ... i doubt that the images we ship in there need to be super high quality, since they are only background for visual +effects ...
<lifeless> /etc/acpi/resume.d/49-915-set-resolution.sh
<lifeless> its hardcoded for the resolutions I need, which unlike the 915 package are set on all three bit-depths
<jdub> ogra_: i don't believe we have space on the CD for these images at all. we do have other options.
<lifeless> I filed a bug in debian but it got closed without fixing it. :(
<Kinnison> infinity: Sure, either punt them to me or cprov in a mail
<mjg59> lifeless: Is it executable?
<ogra_> jdub, i freed up 5MB recently with screensaver changes ... it would be nice if i could have at least a minor amount of that back for the screensaver
<lifeless> mjg59: yes
<lifeless> 755 root root
<mjg59> lifeless: Hm. That should be running on resume, then.
<jdub> ogra_: haha :)
<jdub> ogra_: you know one of the stages of grief is bargaining, right? ;-)
<infinity> Kinnison: I need to write them first (It's on my TODO for tomorrow after the meeting), so I can punt then. :)
<jdub> BenC: ping
<fabbione> infinity: ping?
<fabbione> bah you are here
* ogra_ will upload the big parts first next time and free up stuff in the end ... :)
<mjg59> lifeless: If you chuck set -xs in the appropriate places, can you try to figure out what's going on?
<Kamion> ogra_: having some of the 5MB back is fine, but it has to be not in 2MB chunks
<fabbione> infinity: mind if i upload initramfs? i need mptsas and mptfc in hook-functions
<Kamion> 100KB chunks or thereabouts would be more like it ...
<lifeless> mjg59: I'll chuck that in resume.sh
<ogra_> Kamion, i'll try how much i can compress any images ... only one pic would also be fine for now, simply to not have the ugly tv test screen by default
<Kinnison> infinity: okies
* Kamion nods
<Kinnison> pitti: I have a translations question
<Kinnison> pitti: gnome-power-manager has some more UI which I added in its glade files
<Kinnison> pitti: does pkgstriptranslations automatically end up with those for translating?
<Kinnison> pitti: Or do I need to run some command in the source package first?
<jdub> ogra_: i'll be doing a new u-a today, so i'll sort something out for that too
<infinity> fabbione: I suspect we just want everything from kernel/drivers/message/fusion/, don't we?  Since I keep getting asked for "just one more".. :)
<mjg59> Kinnison: Suggestion: if sleep type when inactive is "Do nothing", don't show the sliders for it?
<fabbione> infinity: probably.. mptsas and mptfc are required on sparc...
<fabbione> infinity:  i can't speak about the others
<Kinnison> mjg59: I'd rather make them insensitive
<infinity> fabbione: Let me mangle the list here a bit.
<Kinnison> mjg59: having UI appear/disappear confuses people
<fabbione> infinity: ok
<ogra_> jdub, ok, if you dont want an extra package, please link the default background to /usr/share/backgrounds/screensaver/ that should do it for a start
<fabbione> infinity: i won't touch it than
<Kinnison> mjg59: Please file a bug so I remember to address it
<fabbione> infinity: but please wait a sec before you upload
<mjg59> Kinnison: Oh, "When laptop lid is closed:" "When battery power critical"
<ogra_> jdub, thats at least still better than the tv screen ...
<mjg59> Either add an "is" or lose one
<jdub> ogra_: i do want separate pacakge, rationale was good - though i might do it as a separate source package
* Kinnison is current "having lunch" which equates to reading a local authority search
<ogra_> jdub, ah, ok ...
<Riddell> pitti: ok
<dholbach> mjg59, Kinnison, ogra_: do you have a laptop-power-something-team on launchpad, which i could subscribe to bug reports?
<fabbione> infinity: ok... test successful 100%. please upload when you can :)
<ogra_> dholbach, Kinnison and me are default subscribers to all g-p-m bugs
<dholbach> ogra_: i was just thinking about stuff like libpam-foreground or the hibernate-patch in gdm, etc
<lifeless> mjg59: ok, it *is* setting the resolution
<infinity> fabbione: Kay, uploaded.
<lifeless> mjg59: but X is still getting fucked
<fabbione> infinity: danke
<lifeless> mjg59: I redirected output from the resume.d scripts to /tmp/foo
<lifeless> mjg59: and its all there
<pitti> re
<pitti> Kinnison: depends; the added translation must find its way into the pot file
<pitti> Kinnison: does g-p-m use cdbs+gnome.mk?
<pitti> Kinnison: if so, the pot file is updated automatically at build time
<Kinnison> pitti: yes it does
<Kamion> mpt: http://people.ubuntu.com/~cjwatson/tmp/espresso-location.png
<Kinnison> pitti: any way I can check that?
<pitti> Kinnison: then it shuold work OOTB
<pitti> Kinnison: yes, the build log should contain 'intltool-update' and mention the pot file
<pitti> Kinnison: and after the build, the new string should be in po/g-p-m.pot
<Kinnison> pitti: I shall look when I've finished my lunchtime legal wrangling
* pitti wonders why he always misses IRC messages, and notices that this damn PC speaker is broken *again*
<pitti> keeeeybuuuk
<Keybuk> pitti: that won't make my nick hilight work :P
<pitti> (just kidding :) )
<mpt> Kamion, cool
<mjg59> lifeless: And you need to restart X to get it back?
<mpt> Kamion, that top bar's just for debugging, right?
<Keybuk> pitti: what's up?
<pitti> Keybuk: well, I had to modprobe pcsprk again to get beeps
<pitti> pcspkr, too
<pitti> deja vu :)
<Keybuk> heh
<Keybuk> unsurprising, nothing causes that to get loaded
<pitti> Keybuk: I think it's only since today; after yesterday's dist-upgrade probably
<Kamion> mpt: it's a leftover from Guadalinex
<Keybuk> I have an interesting one here, the PC Speaker works and generates beeps
<Kamion> mpt: I'm undecided on it; I can see the advantage of having some indication of where you are in the process
<Keybuk> quite literally, from the PC Speaker in the case
<Keybuk> my old PC used to beep on the soundcard
<Keybuk> so it's verrrrrry quiet
<Keybuk> which, frankly, is great in the morning when I have to mash the keyboard to get vim to do my bidding ;)
<mpt> Kamion, if there was a list of steps, it should probably be vertical, but I don't think it's necessary at all
* sivang wonders why pexpect swallows cmd line args.
<Mithrandir> mpt: it's a kind of progress bar and something I _absolutely_ think we should have.  Not knowing the number of steps is annoying.
<mvo> is adding a "mp3 support" meta-desktop-file in gnome-app-install that installs gstreamer0.10-plugins-ugly a problem from a legal point of view? 
<mpt> Mithrandir, part of the point of having assistants in general is that it helps you avoid unnecessary steps, which means that the number of steps varies depending on your early choices. That the number of steps is constant for this particular assistant is unusual.
<Kamion> the number of steps is not constant
<Mithrandir> mpt: the breadcrump path shows phases, not steps.
<Kamion> although the current top bar collapses the non-constant steps into single chunks (namely the partitioner)
<mpt> Mithrandir, you just said, "not knowing the number of steps is annoying" :-P
<mpt> but even the assistant can't know, until it's partway through the partitioning questions
<Kamion> people don't care exactly which page number they're on, they care approximately how much further they have to go
<Kamion> an indication of the list of phases is a good indication of that
<mpt> sure, that's the reason for the "... about five minutes" on the first page
<Kamion> which is a pointless lie
<Kamion> we have absolutely no clue how long the CD will take to do its thing
<Mithrandir> mpt: well, knowing how far you've come, then.
<Kamion> although, ok, it does say "answering the questions", not "the installation"
<mpt> exactly
<Kamion> but I'm still unconvinced; manual partitioning will take people a lot longer to set up than automatic partitioning
<mpt> in which case that phase will take much longer than all the others
<Kamion> yeah, but they'll know from the progress indicator that it's the last thing they have to do before installation
<Kamion> people using the advanced partitioner will generally have seen something like that before, and will expect it to involve a few steps
<Kamion> they won't necessarily know that it's the last thing to do
<Kamion> which I do contend is useful information
<mpt> Well, if you do keep some sort of progress, I'd prefer it be "Step x of y" text in the bottom left corner
<Kamion> ok, that would certainly be doable
<mpt> using the "phase" meaning of step, rather than the "click" meaning
<Kamion> yeah
<Kamion> Mithrandir: happy with that?
<Mithrandir> Kamion: I still prefer the breadcrumbs, but I could live with it, yes.
<Mithrandir> the steps aren't evenly-sized so enumerating them makes sense.
<Kamion> ok, added to UbuntuExpress/ToDo
<Kamion> thanks mpt
* Kinnison heads to ely for a bit, back soon
<janimo> Keybuk, you know a way of finding out which processes hold refs to a certain loadable module?
<janimo> something a la lsof
<Keybuk> processes don't hold refs to modules ... ?
<Keybuk> module refs are just in-kernel things, usually the devices and other modules and stuff
<ogra_> janimo, check with lsof for open devices and find the udev rule for the device :)
<janimo> I tried lsof on the sound devices but no procs there
<Keybuk> other then /sys/module/$MODULE/refcnt there's no real tracking of it
<janimo> but thanks
<ogra_> Kamion, there is a edubuntu-docs package in NEW ... i have already a better version on http://people.ubuntu.com/~ogra/ can you review this one for NEWing and wipe 0.1-1 ? 
<Kamion> ogra_: can you just upload 0.2-1? it's easier for me to review when it's actually in the queue
<ogra_> yup, will do ... didnt want to upload without asking
<Kamion> no, that's fine
<Kamion> 0.1-1 will just be superseded then
<ogra_> oki, uploading ...
<lifeless> mjg59: yes
<mjg59> lifeless: Do you get /any/ display back?
<BenC> jdub: pong
<jdub> BenC: do you know of anyone testing on sun amd64 galaxy boxes (even someone internally)?
<BenC> no
<BenC> I got a /msg from someone about it about 3 minutes ago, but they don't appear to be alive anymore
<BenC> 30 minutes ago I mean
<BenC> sun amd64 are Opteron's, correct?
<jdub> yeah
<jdub> BenC: was that davekempe?
<lifeless> mjg59: 640x480ish bright muave rectangle
<BenC> jdub: yeah, did he talk to you?
<mjg59> lifeless: Hmm.
<jdub> BenC: he's a sydney dude, talk to him a lot
<mjg59> lifeless: Very weird. What does switching to a console do?
<jdub> BenC: they just got one - wondering if we had any more dedicated testers
<jdub> BenC: when's kernel freeze?
<lifeless> 640x480 console... what I'm typing in now
<mjg59> lifeless: And switching back to X?
<lifeless> funky display comes back
<BenC> jdub: kernel is pretty much "not going to change unless it has to" right now
<BenC> I would expect sun-smd64 to just work though
<mjg59> lifeless: Running 915resolution again and switching back?
<lifeless> no diff
<mjg59> lifeless: Ok, so certainly not a 915resolution thing. Hmm.
<mjg59> lifeless: Anything in the X log?
<lifeless> mjg59: well when I first tried 915 resolution, a similar behaviour occured.
<lifeless> until I had it set to run on unsuspend
<lifeless> I'll check the log
<mjg59> Right
<jdub> BenC: has some panics and so on at boot, for various driers
<BenC> if you talk to him again before I do, just have him send me the dmesg
<jdub> BenC: ok
<lifeless> mjg59: no nothing
<mjg59> lifeless: Right.
<spacey> for filing a bug with the espresso install stuff on the livecd. What package should i file the bug on? just espresso? espresso-frontend-gtk ?
<Mithrandir> espresso, probably
<spacey> k
<spacey> i'll just do that
<lifeless> mjg59: should I file a bug 
<seb128> Kamion, pitti: gnome-vfs2 has been splitted to get a -bin and a -extra to Debian, I'm syncing it now (breaks circular Depends and allow to get extra stuff shipped with -dbg), is that ok if I update the desktop seed to list -bin and -extra?
<pitti> sure, ok for me
<Keybuk> *sigh* today I mostly hate uncooperative users who seem to feel that providing you with debugging information is a chore, and you should just psychically know what's wrong with their system and fix it
<seb128> pitti: cool, doing that now :)
<pitti> Keybuk: 'use the force, Luke' :)
<doko_> dholbach, seb128, anybody who has a printer: please could check the OOo test packages?
<seb128> my printer is kind of broken atm
<seb128> it does some "motor forcing on something blocked" noise
<kbrooks> I want to build a LiveCD based on Ubuntu, that includes all of the Python goodies.
<seb128> I've planned to have a look on it later, but not now
<kbrooks> But how do I do this?
<dholbach> doko_: i'll download an check when i'm back, ok?
<kbrooks> *pokes everyone*
<dholbach> kbrooks: look on the wiki
<kbrooks> dholbach, do  you have a link to this wiki page
<doko_> dholbach: better download while you're away
<dholbach> no i'd have to search myself - it's something about livecd and customization
<dholbach> doko_: yes
<dholbach> doko_: i386 only I suppose
<doko_> dholbach: yes
<dholbach> hrm ok
<ploum> hello
<seb128> lu ploum
<ploum> For a few weeks, I experience a random mouse-click freeze in dapper
<ploum> The click is not responding on my mouse anymore
<ploum> and the workaround is to type a shortcut key (for exemple switch desktop key) and that's all
<seb128> check the mouse cable? :)
<seb128> do you have the click event to xev when that happens?
<ploum> seb128: :p   as a keystroke solve the problem, I'm not sure it's a hardware bug
<ploum> seb128: it's very difficult because it must happen with a xev already openend !  (as the keystroke solve the problem)
<seb128> ploum: run an xev on every desktop until that happens next time :p
<ploum> but it's really strange how a simple button not responding make you feel that your desktop is completely crashed !
<ploum> seb128: I will try
<ploum> I was just asking if someone saw it
<seb128> I had some such bug
<ploum> to be sure I'm not crazy
<seb128> but I think my desktop was really not responding
<seb128> like disk access blocking
<seb128> because keyboard didn't unblock it for me
<seb128> and I think alt-f2 was not opening the run app dialog
<ploum> not the same indeed
<ploum> here's, it's very strange because a random keypress will not solve the issue. It must be a shortcut !
<ploum> If I can find more informations, I will fill a bug
<seb128> "shortcut"?
<seb128> like alt-F2?
<ploum> yes
<ploum> or Ctrl+alt+arrow
<ploum> (I never tried alt-F2)
<ploum> if you ever hear someone complaining about something similar, please let me know
* ploum must do some slides for FOSDEM...
<seb128> ploum: will do
<ploum> thanks :-)  have a good day
<seb128> ploum: you too! :)
<mjg59> lifeless: Best to
<JaneW> can anyone answer this enquiry I have "My question is whether ubuntu is going to make xgl the default interface when you install ubuntu."? tyia
<jdub> ogra_: i'm going to do an artwork upload without the screensaver stuff
<jdub> JaneW: "not yet"
<Kinnison> JaneW: "Not for dapper, no"
<JaneW> jdub/ Kinnison : thanks.
<jdub> ogra_: and sort that out as a separate package
<ogra_> jdub, oki
<jdub> JaneW: "... and every time someone asks, a kitten dies"
* ogra_ *sighs* deeply about this xgl noise
<JaneW> jdub: hrm... so how many are down now? *efg*
<Treenaks> JaneW: they're almost extinct
<jdub> JaneW: they're calling it "kitten flu"
* Lathiat laughs
<JaneW> LOL
<Keybuk> jdub: are there any kittens left?
<mvo> Riddell: konsole dosn't have a Comment field in it's desktop file anymore (and some other kde apps seem to have lost them too). is there a reason for this?
* ogra_ wonders how many kittens make a pony
<zul> 3
<JaneW> no way
<seb128> 1 kitten is better than a pony
<JaneW> 300 at least
* JaneW is off kittens
* mvo I want a pony *and* a kitten
<JaneW> rats are better ;)
* seb128 slaps JaneW
<Treenaks> JaneW: you used to snort kittens?!
<JaneW> seb128: zut allors!
<seb128> lol
<seb128> "alors" :)
<JaneW> sorry
<zakame> ooh kittens
<JaneW> Treenaks: I have been trying to give them up
* Keybuk wonders for the millionth time why syslogd starts in rc2 and not rcS
<Keybuk> bah, I want half-hour-days back again
<jdub> Keybuk: not in eastern europe.
<Keybuk> hour-long-days means I have to actually build packages myself, and can't just wait for them to show up in updates
<Kinnison> Keybuk: So do I
<jdub> ukranian children were forced to down thousands of kittens when nat friedman presented XGL at solutions linux in france
<Kinnison> Keybuk: It's possible that the faster db server may let us go to half-hour days
<Keybuk> Kinnison: btw, spec approved
* jdub realises he did a pretty dismal changelog
<jdub> i just uploaded ubuntu-artwork_1 ;-)
<Kinnison> Keybuk: thanks
<Kinnison> Keybuk: did you update lp?
<Keybuk> Kinnison: I did
* Kinnison hugs ta
<Keybuk> btw, why doesn't gpm have a "Power Off" option for low battery?
<Keybuk> it just had Suspend and Hibernate last time I looked
<mjg59> Keybuk: It does
<Keybuk> oh
<mjg59> "When battery power critical: Shut down"
<Keybuk> I clearly wasn't looking hard enough :)
<Keybuk> hey haggai 
<Kamion> Keybuk: BTW, I keep forgetting to mention it, but when I debootstrap dapper at the moment I end up with /var/lock and /var/run still being mounted in the chroot after debootstrap finished
<Kamion> finishes
<seb128> quick opinion question
<haggai> hi Keybuk 
<seb128> evolution-data-server has a collection of libs, if you would do a -dbg variant, would you make a -dbg by binary package or an evolution-data-server without all the debug stuff?
<Kamion> this is suboptimal; is there anything that can be changed in sysvinit to avoid that (e.g. don't mount /var/{lock,run} if in a chroot, which would also be useful when upgrading a chroot) or should I just make debootstrap umount them?
<seb128> s/without/with
<ogra_> Kamion, i noted the same ...
<Keybuk> Kamion: oh, interesting
<Keybuk> is there any easy way to tell you're in a chroot?
<Keybuk> or, more pointedly, running under debootstrap?
<Kamion> you should never special-case debootstrap; the case of upgrading a chroot is often just the same, and arguably more annoying
<Kamion> do you use invoke-rc.d?
<Keybuk> no ...
<Keybuk> the initscript itself does the mounting
<Kamion> what calls the initscript?
<Keybuk> because it's the only way to ensure the user gets moved over to /var/run-as-tmpfs properly
<Keybuk> uh s/initscript/postinst/
<Kamion> oh
<Keybuk> otherwise you end up with a /var/run underneath the /var/run tmpfs which is full of crap :)
<Kamion> hm, ok, arse
<Kamion> I'll just make debootstrap umount those then
<Keybuk> it's a breezy-dapper upgrade issue
<Keybuk> I'm not sure why it's happening on a fresh install though
<Riddell> mvo: "CVS_SILENT replaced Comment= with GenericName= if the comment is shorter 30 characters"
<Keybuk> that's probably not necessary
<Riddell> curious
<Kamion> oh, yeah, making it not happen on a fresh install would do the trick
<Keybuk> on a fresh, we just have to make sure we mkdir /var/run /var/lock after alerting the user to the three-headed monkey standing behind them
<Keybuk> (assuming they have /var mounted as a different filesystem)
<mvo> Riddell: would it be possible to undo that change? gnome-app-install uses that data as a short discription
<Riddell> mvo: not easily, what does it use the GenericName for?
<mvo> Riddell: it dosn't use it at all, I could fall back to it when I get nothing from Comment 
<mvo> Riddell: I guess that would be easiest
<Keybuk> Kamion: done
<Manny> hi :)
<Manny> herzi hi
<seb128> hey Manny
<Riddell> mvo: running gnome-app-install I get an error  gobject.GError: Icon 'gnome-settings-default-applications' not present in theme
<Manny> seb128 my brother had big problems getting his win partitions mounted. He had to poke with fstab and such. Is there anything planned for unpainifying this? :)
<seb128> Manny: GetRideOfWin? :)
<Manny> maybe the gst disk manager should support more options :/
<Manny> i.e. it should be a bit more smart about user mounts
<seb128> yeah, the gst disk manager could use some work
<Manny> seb128 nice proposal. Not very practical when you have win32-only specialized software running unter wine
<Manny> s^running^ not running^
<seb128> but that would be a rather an installer issue imho
<seb128> win partitions should be added to fstab (dunno if it does atm)
<seb128> Kamion?
<herzi> Manny: can you confirm http://bugzilla.gnome.org/show_bug.cgi?id=323969
<mvo> Riddell: some apps (like konsolesu) don't even have a genericname ?
<Manny> seb128 windows was installed afterwards. Also assume possible repartitioning.
<Ubugtu> gnome2 bug 323969 in Window List Applet "Buttons could look a bit better in transparent mode" [Normal,Unconfirmed]  
<seb128> Manny: ah, windows installed after is a special case already :)
<mvo> Riddell: about the error, this should be in the gnome-icon-theme IIRC, can you please put the compolete backtrace to a pastebin?
<seb128> mvo: it's a part of gnome theme, so your theme has to Inherit=gnome
<Manny> herzi nope
<Riddell> mvo: http://kubuntu.pastebin.com/568619
<Riddell> I do have gnome-icon-theme installed
<seb128> Riddell: does your GTK theme inherit from gnome theme?
<seb128> ups
<seb128> icon theme I mean
<glatzor> we can use "try:" to load the icon
<glatzor> mvo: 
<seb128> or you can put an icon to "hicolor" :)
<Riddell> no idea, I presume it's just set to default
<Riddell> I don't have any file called gnome-settings-default-applications installed
<Riddell> oh wait, yes I do
<glatzor> Riddell: i will fix this
<mvo> Riddell: do you have gnome-icon-theme installed?
<seb128> mvo: having it installed will not help if your icon theme doesn't inherit from gnome icon theme
<Riddell> mvo: yes
<Riddell> how do I find out my gnome icon theme?
<seb128> you need a setting manager to apply it
<seb128> gnome-settings-daemon or xfce do that
<seb128> dunno what KDE does with the icon theme
<seb128> I guess the icon theme is not desktop specific
<seb128> which theme do you use for KDE?
<Riddell> crystal
<mvo> seb128: hm, I call gtk_icon_theme_get_default() to get the icon theme ...
<glatzor> seb128: haven't the gnome icons moved from hicolor to gnome lately?
<seb128> Riddell: putting Inherits=gnome to /usr/share/icons/crystal/index.theme should fix the issue
<seb128> glatzor: they did
<seb128> mvo: which will return nothing if your theme doesn't inherit from GNOME icon theme
<seb128> mvo: the icon is stored to /usr/share/icons/gnome
<seb128> that's not a standard fallback, which is hicolor
<Riddell> seb128: it doesn't (and I don't see why gnome apps would be using crystal anyway)
<mvo> *grumpf*, ok
<seb128> Riddell: that's why it doesn't find the icon
<seb128> the icon should be stored to /usr/share/icons/hicolor
<seb128> so every theme list it
<Riddell> yes
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=330061
<Ubugtu> gnome2 bug 330061 in general "some applications are broken by the icons move from hicolor to gnome" [Normal,Unconfirmed]  
<Riddell> although an app shouldn't crash just because it can't find an icon
<Riddell> in my opinoin
<trappist> realplayer used to do that to me
<mvo> Riddell: sure. if you are interessted in runing g-a-i for testing, just remove that line (until I do the next upload)
<seb128> Riddell: that is a bug for sure
<mvo> i would be interessted it crashes on the next icon as well :)
<glatzor> Riddell: mvo: seb128: It won't crash anymore if you merge from me. :)
<glatzor> seb128: should we copy the icon to hicolor? or set gnome as fallback of the fallback theme hicolor :)
<seb128> the first would be a workaround, the second would be ugly
<mvo> Riddell: could you please test what effect removing that line has?
<seb128> not sure, I'm going to mail the GNOME lists about that now
<Riddell> mvo: http://kubuntu.pastebin.com/568647
<Riddell> setting gnome as a fallback from hicolour would be evil
<trappist> bug 23018 has been fixed for some time but nobody's closed it.
<Ubugtu> malone bug 23018 in iptables "libipt_recent is not there" [Normal,Unconfirmed]  http://launchpad.net/bugs/23018
<mvo> so this clearly sucks, because there is no generic "{kde,gnome,IdontCare}-other" icon
<mvo> it looks like g-a-i needs to ship it's own falback 
* hunger is happy to see those /var/run cleanup init scripts vanish.
<Riddell> well, yes
<Riddell> every app needs to have a hicolour icon
* mvo goes to fix g-a-i
<Keybuk> seb128: it'd be really nice if file-roller could actually suggest a program to run
<dooglus> gaim crashes every time I try to connect to ICQ.  what is the recommended way of getting a patch applied to fix it?
<dooglus> I attached a patch to the relevant Malone bug, but that didn't help.
<seb128> Keybuk: yep, it should use the same list as nautilus right click, I agree
<Kamion> Manny: we made Windows partitions be automounted in breezy, but there is one bug that means it doesn't happen under certain circumstances
<Kamion> I'll look at fixing that for dapper
<mjr> set nls to utf8 as well?
<Manny> Kamion using pmount? :)
<Manny> i.e. how does it work?
<Keybuk> Manny: old fashioned "put them in /etc/fstab"
<Manny> Keybuk at what time, and using what code? :)
<Keybuk> at install time, in partman
<Manny> Keybuk ah, ok
<Keybuk> then then get mounted at boot time, using mount
<Manny> yeah.
* Manny remembers something like this on his mother
<Manny> s computer
<Manny> Keybuk I'd be very fond if we implemented something pmount-related, i.e. really user-space powered :)
<Keybuk> what would be the point?
<Keybuk> that sounds like a solution looking for a problem
* jdub totally wants support for cifs/smb, nfs and iso amongst other things in pmount
<jdub> plus fuse and friends
<Keybuk> jdub: uh, pmount does support those things?  it just calls mount, after all
<Keybuk> pmount is just a setuid wrapper for calling mount on removable devices
<Keybuk> there's no magic in there
<jdub> policy magic!
<jdub> speaking of pmount and magic
<jdub> it is PITTI THE GREAT
<Keybuk> BERPITTI!
<Keybuk> jdub: btw. how do I fix the fact I can't watch most of my porn at the moment?
* Manny asks on the GnomeVFS list
<Manny> Keybuk you can
<Keybuk> it's all in wmv format, and those damned windows dlls are 32-bit
<Manny> Keybuk oh :/
<jdub> Keybuk: xine
<jdub> Keybuk: totem-xine, rather
<Keybuk> jdub: xine doesn't seem to, nor does the gstreamer ffmpeg plugin
<Manny> Keybuk wmv3 doesn't work. Sad but true, nowadays most PureTNA porn is distributed in wmv3 :/
<jdub> all of my porn works FINE
<Keybuk> jdub: would you like some of mine to try? :)
<infinity> Obviously, you need DivX porn.
<jdub> Keybuk: pia would ;)
<Keybuk> I guess I could just install the 32-bit mplayer packages
* pitti blushes
<pitti> jdub: pmount?
<jdub> pitti: you're going to have to come up with a new trick ;)
<HiddenWolf> Do we really want to know about other people's tricks? ;)
<pitti> jdub: samba mounts in pmount?
<pitti> jdub: the pmount-uber-alles spec was defered :)
<jdub> pitti: yeah. we were just chatting about it.
<Keybuk> meh, answering the question "I know this file is open, is it open for WRITING?" is difficult
<mdke> Kamion, what does the package installation-guide do?
<seb128> sorry to ask again. But does having a evolution-data-server-dbg with the debug version of all the libs from libe* binaries seems a good idea or wrong to you?
<pitti> seb128: can't hurt :)
<pitti> seb128: is that a package you get many crash bugs for?
<seb128> pitti: my question is probably not clear
<Kamion> Manny: we discussed using pmount and decided it was a bad idea, because it would require weakening pmount's policy
<seb128> Package: evolution-data-server
<seb128> Binary: libcamel1.2-dev, libegroupwise1.2-9, libedataserverui1.2-6, evolution-data-server, libebook1.2-dev, libedataserver1.2-7, libedata-book1.2-2, evolution-data-server-dev, libecal1.2-3, libedata-cal1.2-dev, libedataserver1.2-dev, libecal1.2-dev, libegroupwise1.2-dev, libedata-book1.2-dev, libebook1.2-5, libexchange-storage1.2-1, libcamel1.2-8, libexchange-storage1.2-dev, libedataserverui1.2-dev, libedata-cal1.2-1
<seb128> pitti: that's e-d-s
<Kamion> Manny: (the pmount author and I came up with the design)
<Kamion> mdke: it doesn't do anything, it's documentation :)
<seb128> pitti: my question is I should do a collection of small -dbg or an evolution-data-server-dbg for the list of stuff
<seb128> s/is/is if
<Kamion> mdke: it's the d-i installation manual
<LaserJock> mdke: yeah, I had to look that up too ;-)
<pitti> seb128: oh, I'd prefer one package then, easier to handle
<pitti> seb128: but I guess you should have the final word in this :)
<ideafix> whats the difrence betwen installing from expresso versus the regular install iso ?
<Chipzz> seb128: which of these packages get used by gnome-panel?
<Chipzz> seb128: (clock applet to be more specific)
<mkde> Kamion, sorry not sure if you replied or not to my question, i lost my internet connection
<Chipzz> s/panel/applets/
<ideafix> whats the difrence betwen installing from expresso versus the regular install iso ?
<Kamion> mkde: 16:23 < Kamion> mdke: it doesn't do anything, it's documentation :)
<Kamion> 16:23 < Kamion> mdke: it's the d-i installation manual
<Kamion> ideafix: ideally, nothing, in practice, espresso still gets several things wrong
<mkde> Kamion, is it applicable to ubuntu now?
<Kamion> mkde: yes
<Kamion> it has significant modifications
<Kamion> it's also the only documentation I'm aware of that goes through our current preseeding provisions in any detail
<ideafix> so will live cdrom become the default instal media for ubuntu ?
<Kamion> ideafix: if espresso gets finished in time, yes
<Chipzz> seb128: some people may not want evolution to be installed, and trying to debug clock applet for example... but I guess that doesn't make much sense since evolution is installed by default and you would have to remove it
<mkde> Kamion, a user suggested we publish it on the internet, any thoughts?
<ideafix> nicwe
<Kamion> ideafix: the traditional installer will continue to be available though
<ideafix> why ?
<Kamion> mkde: we definitely should, but I haven't figured out where to do that yet; I'd like there to be http://www.ubuntu.com/doc/ with unpacked versions of our packaged documentation available
<Kamion> ideafix: because espresso will not fulfil everyone's use cases
<Kamion> it will be totally inappropriate for installing servers, for instance
<mkde> Kamion, help.ubuntu.com?
<Kamion> it is not designed to be all things to everyone
<Kamion> mkde: fine if it can be set up to automatically publish things from the archive
<seb128> Chipzz: I don't really care about such a modularity for people wanting to debug
<seb128> Chipzz: that's enough a special case to force them to download a few meg
<ideafix> why Kamion ?
<mkde> Kamion, it probably can, but in any case, the archive doesn't change significantly once a release is stable right?
<xxenon> in dapper, is mp3 support still provided by gstreamer0.8-mad ?
<ideafix> can you get the live cd to do package seletions ?
<Kamion> ideafix: think about it - it's installing by copying the contents of the live filesystem
<Kamion> ideafix: no, not easily at all
<Kamion> a server install shouldn't have all that stuff installed, only the base system
<Chipzz> seb128: my thoughts weren't about megs, but about pulling in extra packages... but that's all they were, just some thoughts ;)
<Kamion> mkde: no, but I want the development version to be published as well
<LaserJock> Kamion: but should we just link to the debian documentation that we haven't changed anything? DNMG for example
<seb128> Chipzz: -dbg are here to be handy for common users
<Kamion> LaserJock: sure, no reason not to
<seb128> Chipzz: if you are a space disk and depends maniac you can build your debug package yourself :)
<mkde> Kamion, at the moment we publish development things at doc.ubuntu.com, we could set that up too
<ideafix> Kamion mabet you could make the live cd to use netinstall from repos and make package seletion availble that way 
<Kamion> ideafix: not really interested sorry, the traditional installer is better for that
<Kamion> mkde: that would be good
<Kamion> ideafix: we also don't have time to make espresso do everything
<mkde> Kamion, ok i'll take a look at the package. as long as the xml works, it should be easy to do
<ideafix> i dont think that would be very dificult 
<Kamion> mdke: it's built into binary packages, so it should do
<ideafix> i could be wrong 
<Kamion> ideafix: as the person who's maintained the Ubuntu installer for the last year and a half, I beg to differ
<ideafix> isnt ther a ubuntu netinstall iso ?
<ideafix> like debian has 
<Kamion> it is very much non-trivial, particularly given that espresso is designed along totally different lines
<Kamion> ideafix: there's a netboot iso
<Kamion> we've never got round to building a netinst as such (i.e. installer plus base system), but the netboot mini.iso should suffice
<mkde> thanks Kamion, I'll let you know how I get on
<ideafix> so the difrence betwen expresso and regular install iso arent that trivial ...
<Kamion> http://archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/current/images/netboot/mini.iso
<Kamion> ideafix: correct
<Kamion> espresso uses much of the code from the traditional installer (as much as I can), but it's not quite so simple as "run d-i with pretty frontend"
<Kamion> even though that's the basic theory
<Riddell> Kamion: espresso broke my debconf http://kubuntu.pastebin.com/568716, any ideas how to fix?
<ideafix> wouldnt be too dificult to get the netinstall iso stuff into expresso 
<Kamion> ideafix: yes, it would be difficult.
<ideafix> ??!?!
<Kamion> Riddell: you have another process running using debconf somewhere else; find it and kill it
<ideafix> all have to take your word for it then 
<infinity> Kamion: Though, if we get around to doing filesystem overlays (allowing us to have a base filesystem, with ubuntu-desktop and ubuntu-live overlaid on it), doing a server install from espresso wouldn't seem terribly far-fetched.
<Kamion> ideafix: we're going round in circles, and I'm afraid I don't have time to explain the design of espresso from the ground up
<ideafix> i would like to know the out line 
<Kamion> sorry, the day of feature freeze isn't the best time to ask :)
<Kamion> http://wiki.ubuntu.com/UbuntuExpress may help
<ideafix> ok thankx 
<infinity> ideafix: Espresso doesn't install packages (like a netinst, or a traditionally installer does), it copies over the contents of the livecd's filesystem, and reconfigures it.
<xxenon> !restricted
<xxenon> how do I get mp3 support in dapper ?
<infinity> ideafix: Doing than, then removing most of the packages (to get to a server install) would be VERY painfull.
<infinity> s/painfull/painful/
<ideafix> infinity i think i hade figured that much 
<Riddell> Kamion: I'm pretty sure I don't have any other process using debconf
<Kamion> also, espresso intentionally simplifies some things that desktop users generally don't need but server installs do
<Kamion> Riddell: well, debconf thinks you do
<Kamion> Riddell: (and it's generally right)
<ideafix> i just dream abaut every linux distro isos being live and install sources at the same time 
<tepsipakki> what time is the DL for UVF?
<Kamion> not everyone wants that
<infinity> ideafix: It'll happen sometime, perhaps, but not for dapper.
<Kamion> if you're installing 2000 machines, you don't want to waste time booting a live filesystem on all of them
<ideafix> how do you do it ?
<infinity> (OEM installer, whee)
<Kamion> let us have our installers that work for us, and you can have the installer that works for you. :)
<Kamion> rather than trying to take away the installer that works for us
<ideafix> you have to boot something from cdrom
<Kamion> ideafix: er, no - PXE boot
<ideafix> or use pxe ?
<Kamion> see the installation manual :)
<pitti> mvo: did you update the desktop file in g-a-i? (there's no changelog entry)
<ideafix> Kamion it would be easy to add an pxe install boot to the expresso boot menu 
<Kamion> ideafix: no it wouldn't, we don't have space on the CD
<ideafix> hummm
<Kamion> please please *please* stop saying "it would be easy to ..."
<Kamion> it's immensely frustrating
<pitti> Keybuk: sysvinit and you have a real argument, haven't you? :)
<ideafix> sorry
<ideafix> i just thought it made sence
<Kamion> I don't mind discussing wishlists, but I don't like being told that things are easy when they aren't
<ideafix> what about it would make sence to have a pxe boot entry in expresso boot menu ? :)
<ideafix> ok 
<Kamion> well, who would use it?
<Kamion> why put in a CD to PXE boot? :-)
<ideafix> im not pestering you with it anymore 
<Kamion> the whole point of PXE booting is that you don't need a CD
<Keybuk> pitti: today, yes
<ideafix> some bios dont have pxe boot 
<Kamion> in practice nobody wants to install on 2000 of such machines
<Kamion> if you're doing a large deployment, you generally have reasonably appropriate hardware for it
<ideafix> i thinkl most IBM machines have pxe boot 
<Kamion> most modern systems do
<jsgotangco> new machines generallly hvae it
<ideafix> so i can use pxe boot to install ubuntu across the internet ?
<Kamion> please see the documentation
<jsgotangco> ideafix: the manual on the cd has setup for such deployments
<Manny> jdub I just asked on gnome-vfs-list :)
* Manny is confident
<jdub> Manny: about?
<Manny> jdub pmount windows mounts
<Kinnison> mjg59: almost finished the patch to g-ss to make it notice coffee keypresses
<Manny> oh, and the nfs module probably will be resurrected :). Somebody worked on it.
<ideafix> ive read that the UN is endorsing open source and linux any idea what distro they are suporting ?
<jdub> Manny: oh, i see.
<Kamion> ideafix: this is a development channel; please take general conversation elsewhere
<mjg59> Kinnison: Rad
<Kamion> #ubuntu-offtopic or sounder@lists.ubuntu.com would do
<ideafix> A user wishes to use the live CD with the intent of installing the system immediately. They should be able to select a CD boot option which immediately launches the installer.
<ideafix> thats what i meant 
<ideafix> after all its an expresso goal
<infinity> ideafix: There's just not enough room on the CD (nor enough hours in the day) to implement that as it's written.
<ideafix> and the install can do network instal cant it ?
<infinity> ideafix: Can you please let it drop?
<Keybuk> seb128: gtk bug for you ... totem appears to need me to hit "next" for every damned track
<pitti> seb128: confirmed
<ideafix> i think you can put has much has 2 gigas on the live cdrom 
<seb128> ie? it stops after reading one?
<ideafix> thats lots of space 
<Keybuk> after it plays one yeah
<seb128> is that playing a CD? or do you call "track" a playlist entry?
<Keybuk> have two mp3s in play list, it finishes first one and doesn't play the second
<pitti> seb128: same for movies
<seb128> does it do that if you have, let's say 10 entries to it?
<Keybuk> ....
<Keybuk> yup
<Kamion> ideafix: our live CD images are ALREADY just about at the limit of their available space.
<seb128> k
<Kamion> please let it drop
* seb128 tries on his box
<Keybuk> and if shuffle
<Kinnison> mjg59: flip me, even if it doesn't work, gs-listener-dbus.c just compiled
<Kinnison> mjg59: flip-me-harder the code works
* Kinnison does a "Some C code just worked first time" dance
<Kinnison> mjg59: after a judicious "sudo setkeycodes cc 152", pressing my acpi lock button causes the screen to blank and lock
<Keybuk> grr @ kernel ... it describes the FIBMAP ioctl as "legacy", but doesn't say what to use instead
<Kinnison> Keybuk: legacy?!
<Kinnison> Keybuk: my trick was to look at what lilo used
<Keybuk> don't suppose you still have your code around?
<Keybuk> it got expunged from the readahead package by tollef
<Kinnison> naah, but a hoary source package would have it
<Keybuk> yeah, you just use FIBMAP too
<Mithrandir> Keybuk: what code?
<Keybuk> Mithrandir: old file ordering ... it may have been Thom
<Keybuk> when we switched from readahead to readahead-list
<Kinnison> Keybuk: FIBMAP was probably not deprecated in hoary days
<Mithrandir> oh, that wasn't me. :-)
<infinity> seb128: Are you deep in FeatureFreezePanicMode right now, or would you like to look at a (possible) pango bug for a sec?
<Kinnison> Keybuk: I could download a kernel source and start poking around but you've probably already got one to hand
<mjg59> Kinnison: Rock
<Keybuk> there doesn't seem to be anything to replace it
<infinity> seb128: If the former, I'll catch you in a day or two.
<Keybuk> I think they've just deprecated it because they think it's scary
<Kinnison> mjg59: 2.13.91-0ubuntu2 accepted for the next archive cycle
<seb128> infinity: no real feature freeze panic, GNOME has feature freezed some time ago
<mjg59> Kinnison: Ta!
<seb128> infinity: I'm under UI freeze presure, but I've 2 weeks for that :)
<Kinnison> mjg59: amusingly the same vsn nr as g-p-m currently
<seb128> infinity: ie: feel free to ask
<infinity> seb128: https://launchpad.net/distros/ubuntu/+source/mozilla-thunderbird/+bug/31325
<Ubugtu> malone bug 31325 in mozilla-thunderbird "New build crash" [Normal,Needs info]  
<Kinnison> mjg59: We've now got two things blocked on you getting that kernel patch accepted
<Kinnison> mjg59: also we really need to pick a keycode for the battery event and get acpi-support and hal updated
<infinity> seb128: Turns out that enabling pango in Tbird gave this guy instant crashes... Removing the font I saw in his strace (he's sent me the .ttf file out-of-band via email) magically made it happy again.
<infinity> seb128: I haven't the first clue where to start debugging "pango hates a font" issues.
<seb128> infinity: usually that is "attach the font to an upstream bug with a way to reproduce and let them fix it" :)
<Kinnison> jeepers people are taking this feature-freeze thing seriously :-)
<Kinnison> a gajillion uploads today so far
<seb128> infinity: do you have a backtrace of the crash?
<infinity> seb128: His was monumentally useless, I can probably produce a better one (if I can reproduce the crash) now that he's sent me the file.
<infinity> seb128: Shall I just get a decent backtrace, attach it to the bug, and reassign to you/pango to deal with?
<infinity> seb128: (The font is a Microsoft font, so I'm a bit wary of distributing it worldwide via Malone, but I have no issues linking to it off my private server or something)
<seb128> infinity: sounds fine to me
<seb128> infinity: could you mail me the font too?
<Kinnison> Mithrandir: any complaints if I take on powernowd and fix some bugs? one or two are biting me :-)
<seb128> infinity: pango has a -dbg package, but without magic, you need to set LD_LIBRARY_PATH to get debug stuff
<infinity> seb128: Yeah, I know how typical Debian -dbg packages work. ;)
<seb128> infinity: GNOME packages are not "typical" usually :)
<seb128> we use dh_strip on most of them and gdb figures alone where to find the debug
<ogra> Kinnison, it *is* serious ...
<infinity> Yeah, detached symbols are the way of the future, but I'm still familiar with the old -dbg libraries too. :)
<Kinnison> ogra: pardon?
<ogra> <Kinnison> jeepers people are taking this feature-freeze thing seriously :-)
<infinity> seb128: Anyhow, I'll get a decent trace and other such things when I'm not half asleep, and forward the mess to you.
<infinity> seb128: Thanks.
<seb128> thank *you* for not just bouncing the bug back :)
<Kinnison> ogra: Oh right, My phraseology wasn't quite right
<ogra> heh
<Kinnison> ogra: I meant that they're shoving lots in just before it
<Kinnison> ogra: Kinda "The feature is there, now I can bugfix it into working"
<ogra> yup, the concept works ;)
* Kinnison grins
* Kinnison needs to add hibernatebutton support to g-p-m next
<Kinnison> just waiting for my laptop to finish upgrading then I need to reboot
<Keybuk> hmm, nope, even doing it your way I just get "0" from FIBMAP for every file
<Kinnison> Keybuk: they don't expect you to use a different ioctl per fs do they?
<Keybuk> this is just ext3
<Kinnison> goddamn we need class actions in dpkg
<hunger> What can I do to help debugging a suspend issue? system goes down, beeps, turns on the suspended led and comes up again.
<mjg59> hunger: Did it ever work?
<hunger> mjg59: Worked fine in breezy and through most of dapper.
<mjg59> hunger: dmesg would be a good start, then
<mjg59> After a failed suspend
<hunger> mjg59: Didn't work at all after g-p-m was introduced (I am using kubuntu).
<pitti> ogra: hm, wasn't gtk-qt-engine the package that was so hideously broken? I thought it should be demoted?
<hunger> mjg59: Ah! I see a "Could not suspend device 3-1: error -16.
<hunger> mjg59: seems to be related to hci_usb...
<mjg59> Right
<mjg59> That'll be because we no longer unload USB drivers
<ogra> pitti, i'd like to see it demoted ... Riddell objected ...
<Riddell> well, I've just never had any problems with it
<Mithrandir> Kinnison: feel free.
<Mithrandir> Kinnison: I was just assigned the merge bugs for it a while back, iirc
<Kinnison> Mithrandir: okay
<hunger> mjg59: How do I reenable unloading of usb stuff?
<mjg59> hunger: You don't want to, since it'll break USB after resume
<hunger> mjg59: Adding hci_usb to MODULES in /etc/default/acpi-support is not enough:-(
<mjg59> hunger: Why not? Same failure?
<hunger> mjg59: Yeap. looks like other modules depend on it.
<mjg59> hunger: How so?
<hunger> mjg59: Like usbcore:-(
<mjg59> hunger: Uh. No.
<mjg59> Other way round, perhaps
<hunger> mjg59: Aehm... you are right... its the other way round:-)
<mjg59> But hci_usb just provides bluetooth support
<hunger> mjg59: I am using bluetooth.
<mjg59> hunger: Right. 
<mjg59> hunger: If you unload it now, does suspend work?
<hunger> mjg59: rmmod fails since the module is in use.
* hunger stopped bluez-utils... still in use.
<mjg59> hunger: Interesting.
<mjg59> hunger: Now you need to find out why it's in use :)
<hunger> mjg59: Guessed that:-(
<hunger> The nice thing is that my Bluetooth mouse doesn't work in dapper anymore either:-(
<hunger> So suspend is broken for a mouse that does not even work.
* jdub should figure out bluetooth phone/keyuboard control for presentations
<hunger> jdub: Install breezy... BT works there like a breeze.
* jdub has never even tried to do it, so has to 'figure it out' more than anything else
<jsgotangco> jdub: yeah dude my phone has this bluetooth presentation thing i couldnt figure it out myself...sigh
<hunger> jdub: With breezy I just had to get my laptop close enough to my mouse for it to work.
* Kamion goes out for a couple of hours before the meeting
<jsgotangco> it just sees it and it works?
<jdub> jsgotangco: do i have to get extra software on my phone?
<jdub> mice/keyboards are a different case altogether
<jsgotangco> jdub: i dunno, i use a high-end SE and its already there
<kbrooks> well
* kbrooks pokes everyone
<jdub> i have a sony/ericsson t630
<kbrooks> i'd like to make ubuntu (dapper+1) easier
<Keybuk> Kinnison: weird, appears to be a 64-bit thing
<Keybuk> works fine on i386
<kbrooks> well
<kbrooks> i'm looking at the IdeaPool
<Kinnison> Keybuk: Hmm, you are passing the right types in to get the results back?
<kbrooks> and i want a screen that pops up on every startup: "Welcome to Ubuntu"
<kbrooks> with some pointers to commonly used applications in Ubuntu
<Kinnison> Keybuk: /msg me the code in question so I can have a quick peek
<Keybuk> Kinnison: dunno, I think so
<Keybuk> now I'm just getting weird things happen
<kbrooks> there?
<kbrooks> ANYONE
<kbrooks> talk.
<Kinnison> kbrooks: an attitude like that will get you /ignored
<jsgotangco> jdub: mine is a k600i and it has "Remote Control" under Entertainment and there's a "Presenter" application
<jdub> kbrooks: why interrupt the user's exploration by getting in their way of the (beautiful, discoverable, lovely) desktop system?
<hunger> mjg59: Managed to remove that module (need to turn of BT via the keyboard). suspend works fine without the module.
<kbrooks> Kinnison, i want feedback on my idea. :)
<Kinnison> kbrooks: and I want all my bugs fixed and someone to give me a million dollars
<kbrooks> jdub: it wouldnt be full screen.
<Robot101> Kinnison: and a pony!
<jdub> kbrooks: it would still be an interruption
<Kinnison> kbrooks: you punted out a desire and then waited less than two minutes for a busy bunch of developers to say anything
<jdub> kbrooks: read the GNOME HIG about startup wizards
<mjg59> hunger: Ok
<kbrooks> jdub, URL on there?
<mjg59> hunger: That gives us a good starting point :)
<kbrooks> jdub, and this isnt a startup wizard.
<jdub> kbrooks: google
<jdub> kbrooks: it's the same principle
<kbrooks> jdub, some people dont know that you can add folders 
<jdub> jsgotangco: bummer, don't have one of those
<kbrooks> or files
<jdub> kbrooks: dude. you're looking at a general purpose pc. there are limitless things you can do.
<kbrooks> some people don't know that there are applications waiting to be used.
<kbrooks> ... and so on.
<kbrooks> yes, very true.
<jsgotangco> kbrooks: that's why there's documentation :)
<jdub> best solved by getting out of their way so they can dive right in and discover
<hunger> mjg59: Updating my bugreport on the issue right now so this is not forgotten before someone manages to fix the issue:-)
<kbrooks> jdub, how about some links that users can get to?
<kbrooks> jdub: i dont see any section on wizards here: http://developer.gnome.org/projects/gup/hig/2.0/
<jdub> jsgotangco: oh, it seems it turns up in connectivity -> accessories if there's a device to talk to. i will have to make one. ;)
<kbrooks> point me to it please
<jsgotangco> kbrooks: its best to go to gnome irc than here
<kbrooks> jsgotangco, ...
<hunger> ~.
<hunger> Wow... BT mouse works again...
<hunger> Recharging batteries sometimes works wonders:-)
<jsgotangco> hmm kdebluetooth is in main but gnome-bluetooth isn't oh well
<hunger> mjg59: You know what is curious? Now that suspend worked once I can suspend over and over again without unloading hci_usb
<mjg59> hunger: Odd.
<kbrooks> "Ubuntu should come with a 'tour' of the distro for first time users (especially first time users of linux), that will get people on their first foot. showing them howto setup the distro, What on earth some things mean (note; root means nothing to my mum, telling her to sudo would help no-one) and where to look for more information. Could easily be achieved with a short series of HTML pages with images or a small program designed for this. A
<kbrooks> lso should automatically open on the first install. People should not have to look up on the Internet to find out how to do basic things. -- Gord Allott"
<mjg59> Kinnison: Patch sent, keycode query submitted
* mjg59 goes out
<kbrooks> i wonder.
<kbrooks> uhoh.
<Kinnison> mjg59: rock
<kbrooks> jdub: ^^^
<kbrooks> jdub, note: "should open on the first install"
<jdub> kbrooks: random pastes from the wiki don't convince me
<kbrooks> jdub, many people have asked for this already
<jdub> many people think eating whales is a good idea
<jsgotangco> rotfl
<kbrooks> jdub, crazy metaphor.
<jdub> we're going to have tourish things in the installer
<jdub> during copying
<jdub> that's a good start
<kbrooks> jdub, tourish things?
<Kinnison> infinity: the usplash_down crud... the first TERM signal message doesn't get through to it on my laptop so it sits there for ages before it gets going with no visible progress
<kbrooks> jdub, well, i will get the cd AGAIN
<kbrooks> jdub, i'll install it as a dualboot and blog about dapper
<kbrooks> i hope i can...
<jdub> for most applications, and indeed the entire desktop, i'm not convinced that a tour like thing is going to be better than just making the whole thing Just Work, be discoverable, etc.
<kbrooks> jdub, does dapper or breezy include gparted?
<jdub> both
<kbrooks> no. bundle.
<jdub> kbrooks: this is a developer channel - you're best off asking support questions in #ubuntu
<infinity> Kinnison: That TERM message isn't sent to usplash at all.  I can hack up sysvinit to make it do so... But that's why I currently have it at least give you a "shutting down, please wait" thing.
<jsgotangco> jdub: don't forget example content! :)
<jdub> jsgotangco: exactly - that's a rocking way forward
<Kinnison> infinity: right
<infinity> Kinnison: OTOH, it's a bug that that bit of sysvinit is taking as long as it is (it never used to), so I'd rather just fix THAT.
<kbrooks> jdub, what is "example content"?
<Kinnison> infinity: I guess that'd be better :-(
<Kinnison> infinity: it really does take ages
<infinity> Kinnison: Yeah.  It should only take a second or two.  And some reboots, it does.  Others, it takes almost a minute here.
<Kinnison> infinity: indeed
<infinity> Kinnison: That behaviour is definitely recent (broke around January, maybe?), and is clearly buggy.
<Kinnison> interesting. Even without telling compiz to do cube, it does it
* Kinnison kicks compiz
<pitti> Riddell: amarok translations.tar.gz is back \o/ and it looks good now
<Riddell> pitti: great, thanks
<Riddell> hello enrico, don't think we've seen you in here before 
* jpatrick has
<enrico> Riddell: hello!  I've been around for more than a year :)
<enrico> not very active indeed, but around
<enrico> I mainly sniff the traffic for magic keys
<enrico> say, "debtags" :)
<sivang> enrico: dude!
<Treenaks> uh-oh.. it's dude-o-clock
<Keybuk> mvo: grub has lost its bar background colour
<Keybuk> was that your bad?
<Burgwork> dholbach, can I bug you to package gimmie?
<dholbach> Burgwork: we'll have feature freeze in some minutes
<Keybuk> infinity: splashdown doesn't seem to work past the K scripts
<pitti> Kamion: would I disturb your bzr or anything if I uploaded an espresso package with X-Ubuntu-Gettext-Domain= in the .desktop file?
<dholbach> Burgwork: which is final dead line
<mvo> Keybuk: just remove the splashimage line from /boot/grub/menu.lst, we don't do it for dapper
<dholbach> Burgwork: and i'd rather like the mono guys to do that one
<Keybuk> infinity: I suspect the fact that usplash might get -TERM/-KILL up its arse by init has something to do with that
<dholbach> (as i have no clue)
<Keybuk> mvo: aww, but it looked so cute
<pitti> Kamion: oh, nevermind, let's wait until espresso actually has translations in the langpacks
<infinity> Keybuk: I noticed the same thing, and had planned to poke it with a stick after today's stress passes. :)
<Keybuk> infinity: ok, good; looked great otherwise!  I had an "ooooh, shiny" moment
<infinity> Keybuk: Shouldn't be too hard to eclude it from the TERM list if that's all that's hurting it.
<Burgwork> dholbach, gimmie is python
<infinity> exclude, too.
<mvo> Keybuk: you liked it :) ? nice! you can get the bar back with background=800000
<Keybuk> mvo: did nobody else like it?
<Keybuk> how come the splashimage= line stayed, but the background= one went away?
<mvo> Keybuk: it broke on quite a few machines. nothing that we can't fix, but to risky for dapper
<Keybuk> fair enough
<infinity> I found it hideous anyway.
<infinity> had a big read screen on boot.
<infinity> (maybe that was buggy behaviour, though)
<mvo> Keybuk: I reverted the update-grub changes and now it things that you put the splashimage line in. but it dosn't understand about "background" so it just deltes it
<jdub> it would be fine if we shifted the grub menu around
<Keybuk> mvo: will it do that every time?
<mvo> infinity: that was buggy, it didn't show a splash with "nomenu"
<pitti> mvo: did you update the desktop file in g-a-i? (there's no changelog entry)
<mvo> Keybuk: yes, you need to put the background line somewhere where it dosn't touch it (above)
<mvo> pitti: yes, just forgot to mention it
<pitti> mvo: great, thanks
<Keybuk> infinity: I have an amusing discovery
<Keybuk> infinity: readahead'ing modules makes things boot fast
<Keybuk> but which modules do we pick for the default lists? :p
<mvo> cheers, thanks for reminding me
<infinity> Keybuk: Can we note make it dynamic?
<infinity> Keybuk: s/note/not/
<Keybuk> infinity: no, sadly not
<Keybuk> on some machines it can take over a minute just to *start* the "profile the boot sequence" process
<infinity> Keybuk: lsmod on shutdown?
<ogra> read it on first boot
<infinity> Keybuk: No need to profile just to get modules.
<Keybuk> I'm just going to not care I think :)  if they want the extra 1.5s, they can always just boot with "profile" on the kernel command-line once
<infinity> Will that also catch the modules?
<Keybuk> yes
<jdub> Keybuk: that is rad :)
<infinity> Of course, you'd need to re-profile on each new kernel, unless you're clever enough to strip uname -r out of the paths and re-insert it at runtime.
<jdub> Keybuk: maybe we should have a special grub option for that :)
<infinity> (which wouldn't be a bad idea)
<Keybuk> jdub: Ubuntu kernel blah blah (unroll loops!)
<jdub> ha ha
<kent> mvo: there should be no "splashimage.." line in grub for Dapper?  
<mvo> kent: it was added automatcally for a couple of days (~5) but we reverted it again
<Keybuk> jdub: http://people.ubuntu.com/~scott/bootcharts/quest-dapper-20060223-2.png
<infinity> Keybuk: Anyhow, if you're looking for default modules ot add to readahead, I don't think there are too many modules loaded on every system which aren't also in the initramfs (and we don't readahead in the initramfs), so you lose.
<mvo> kent: if it works for you you can obviously keep it :)
<Keybuk> infinity: aye, that's very true
<Keybuk> infinity: you don't *need* to readahead the initramfs ... it's already in ram :)
<kent> mvo: well, it seems to work. I just noticed that I had it in there,  and I run dapper.  :)
<infinity> Keybuk: Yes, I just mean "you lose on getting to pick 'common modules'"
<mvo> kent: it won't be removed automatically 
<jdub> dholbach: good attempt at refocusing on u-d
<dholbach> jdub: merci beaucoup :)
<Keybuk> anyway, now I just have to make this work on seb's machine
<HiddenWolf> seb128: do you know if ross burton does irc?
<Kinnison> I've been playing with Xgl on and off, and currently am suffering from an amusing issue
<Kinnison> anyone know how to get emacs to start under Xgl?
<Kinnison> anyone suggesting 'emacs -nw' will be summarily executed
<sivang> Kinnison: why it says undefined color black? :)
<Kinnison> sivang: that's the issue, yes
<infinity> You didn't need black anyway, did you?
<Kinnison> infinity: for emacs to start? yes
<Kinnison> :-(
<Treenaks> Kinnison: Xgl is compiled with the wrong path to rgb.txt
<Kinnison> Treenaks: aah
<Treenaks> Kinnison: start Xgl with the right one on the command line probably
<Kinnison> Treenaks: that might solve it
* Kinnison grins
<Kinnison> no time now, perhaps another time
* Kinnison works around the problem
<trappist> maybe symlink to the real rgb.txt
<jdub> ploum: ah! was jjust looking for you
<ploum> hello jdub
<jdub> ploum: your cleaned up cosmogotchi has a snipped shadow on the right side
<ploum> argh
<ploum> I didn't saw it
<jdub> ploum: i used your last one on puc though :-)
<jdub> ploum: if you go to fix the shadow snippage, please make the shadow a little transparent so it's not 100% black
<jdub> ploum: then i'll update puc
<jdub> ploum: that is one rad hackergotchi - i think mark will love it :)
<jdub> ploum: i loved your little cartoon too
<ploum> wow, what a bunch of flowers !
<jdub> http://ploum.fritalk.com/cosmo_mark.png
<jdub> ^ :-)
<mdke> haha
<mdke> awesome
<fabbione> lovely
<mdke> ploum, are those rss feeds you've got in epiphany? if so, pls explain in a /query how you do that
<ploum> mdke: I don't understand. What rss feeds ?
* mdke goes to query
<jdub> Keybuk: they readahead changelogs are fun :)
<Keybuk> jdub: why fun?
<jdub> Keybuk: nice little problems and solutions
<ploum> jdub: what size do you want for the hackergotchi ?
<mdz> devel meeting in #ubuntu-meeting at 2000 UTC (~7 minutes)
<Kinnison> Treenaks: Do you know how to tell Xgl where rgb.txt is?
<pitti> hey mdz
<Keybuk> mdz: you may find you enjoy reading LWN's kernel page today
<jdub> ploum: current size is good
<jdub> ploum: thjough if you've created it at a bigger size, having that would be handy too
<JaneW> ping: BenC,  infinity, iwj, jbailey, hno73, kamion, keybuk, krstic, lathiat, mjg59, pitti, Riddell -> #ubuntu-meeting
<ploum> jdub: http://ploum.fritalk.com/cosmogotchi1d.png is that one good ?
<JaneW> Lathiat: ping?
<ploum> (mm bigger, the drop shadow is not very pretty)
<jdub> ploum: awesome!
<ploum> well, gimp did it nearly alone
<ploum> jdub: it would be cool to have hackergtochies in the RSS feed of puc
<jdub> ploum: indeed
<Kamion> pitti: what do I need to put in the .desktop file? I'll do it for my next upload
* jdub fixes
<pitti> Kamion: X-Ubuntu-Gettext-Domain=<domain>
<pitti> Kinnison: e. g. = espresso
<pitti> Kamion: ^ (sorry)
<Kamion> do I need to create a .pot file with the right strings in it?
<pitti> Kamion: so that langpacks can translate espresso's desktop file
<pitti> Kamion: yes
<seb128> HiddenWolf: he does, ross on #gnome-hackers usually
<Kamion> that'll take a bit longer, need to set up i18n for espresso properly
<Kamion> i.e. at all
<pitti> Kamion: it's not that urgent, though, I can help you with that if you want
<Kamion> I've done it before, so should be doable
<pitti> don't worry about it for now, I just noticed it on the autogenerated list of apckages which need fixing
<Kamion> may need to rearrange some bits
<HiddenWolf> seb128: thank you
<seb128> np
<jdub> ploum: just doing it for rss2
<Kamion> pitti: domain added to the .desktop file in bzr, will do the rest later
<ploum> time to eat. See you saturday . thank for fixing this ;-)
<pitti> Kamion: thanks
<pitti> Kamion: that'll save you from fiddling with intltool-merge, too :)
<ploum> seb128: YEAH ! I was able to reproduce my bug with xev !
<ploum> (alt+F2 doesn't deblock my mouse)
<ploum> and no xev event for the mouse click
<seb128> so not a GNOME bug, pfiou :)
<fabbione> seb128: it's not going to help you anyway :)
<fabbione> you will still have to fix it :)
<seb128> fabbione: xorg bugs list is not good
<fabbione> seb128: i know.. i only have 24 hours per day
<seb128> I had a look on bugs on "xorg" source package today
<fabbione> i need help
<seb128> trying to find a dup ... really not cool
<fabbione> seb128: nothing i can do.. i did ask help in London and you guys did all step back.. so i will take it.. when i have time
<seb128> fabbione: I've fixed startx some days ago :) But my xorg foo is not really good, I will not fix annyoing bugs alone soon probably
<fabbione> seb128: my X input foo is not good either
<fabbione> it's a year i  don't touch X
<fabbione> acutally
<fabbione> since a month after hoary release
<Kinnison> Diziet: Do you know about ff being a bit odd and reporting an XML error in its chrome?
<jdub> Kinnison: have you upgraded it underneath?
<Kinnison> jdub: No, rebooted since upgrade
<Kinnison> Diziet: http://users.pepperfish.net/dsilvers/firefox_mess.png
<fabbione> Kamion: the problem is how pam define rtprio
<fabbione> there are 2 ways and none of them has been defined as standard
<fabbione> one is rtprio and one rt_prio
<Kamion> it's in upstream CVS as rtprio
<Kamion> upstream release, in fact
<fabbione> also the patch that use #define is wrong
<fabbione> it should use glibc defines ones they are there
<Kamion> the patch in my upload? (I changed it)
<fabbione> or it may cause issues..
<Kamion> ok, that's true
<Kamion> but I don't seriously think that's a big immediate issue
<fabbione> no no
<fabbione> it's mainly because mdz asked me to do it
<fabbione> and i was waiting Jeff for glibcx
<Kamion> sorry, didn't realise I was stepping on your toes
<fabbione> i wasn't aware people started poking at it
<fabbione> no problem dude
<fabbione> i know what you do is 100% correct in 99.9% of the cases ;)
<Kamion> I saw the billion mails asking about it and talked briefly to Dana Olson last night, who's one of the musicians very keen for it
<Kamion> so I thought I'd just do it since the approach in upstream Linux-PAM seemed clear
<fabbione> Kamion: don't worry...
<fabbione> if you took upstream approach i am fine
<fabbione> it was something i should have checked myself but -ENOTIME
<fabbione> so if jb does glibc and doko bash..
<fabbione> i am happy..
<fabbione> i had to do nothing other reading mdz's email ;)
<Kamion> if it's been fluctuating between upstream releases, then my bad; I only checked the most recent one
<Kamion> which is 0.99.something, dunno if it's classed as a stable release
<Kamion> perhaps we can support both rtprio and rt_prio if it turns out to be an issue
<Kamion> as long as the values for those are vaguely consistent (which I think they haven't been in the past ...)
<fabbione> yeah that was my original idea.. let see how it evolves
<mvo> are daily cdimages mirrored somewhere? they are unbearable slow for me from cdimage.u.c
<fabbione> doko: i did forward you the entire email with the patches for bash
<doko> fabbione: thanks
* jdub considers upgrading his linode to dapper
* jdub fears the boot foo with kernel 2.4
<jdub> and keybuk just disappeared
<jdub> boh
<fbn> hi, can somebody tell me what the main changes in the courier-mta package are from 0.47 (ubuntu version) to 0.52 (source version)?
<jdub> fbn: worth reading the debian and upstream changelogs
<fbn> jdub: Hi Jeff! Is there a way to view the debian changelogs online? packages.debian.org brings me to a 404 not found ... 
<fbn> courier-mta upstream changelos is too technical for me ...
<jdub> fbn: try packages.qa.debian.org
<ogra> fbn, changelogs.ubuntu.com
<jdub> and packges.ubuntu.com
<ogra> fbn, packages has only the logs for releases ... it doesnt mirror the development changelogs
<fbn> ogra: that sounds better
<fbn> thanks to both of you! :-)
<fbn> ah damn ... the ubuntu and debian changelogs only go up to version 0.47 ... and I need the difference between 0.47 and 0.52 *g*
<fabbione> night everybody
<ogra> night fabbione 
<ploum> well, party time..
<ploum> good night all
<dolson> Kamion: thanks!
<tepsipakki> anyone with main privs, could you take a look at a new version of libnfsidmap? http://revu.tauware.de/details.py?upid=2019
<tepsipakki> it should be ready to go in
<tepsipakki> seems that everyone is understandably quite busy, or I'm too late (or both)
<torkel> Kinnison: you can work around ff by removing the helpGetHelpOnline (and maybe helpTranslate) from content/browser/baseMenuOverlay.xul in /usr/lib/firefox/chrome/browser.jar
<torkel> it's a zip archive
<sivang> hmm, anybody have an idea how to add widgets on a druid page in glade?
<sivang> it complains about no containers, but where are the container's icons int the palette ? :)
<doko> infinity, lamont: ugh, some generic buildd problem? http://librarian.launchpad.net/1584374/buildlog_ubuntu-dapper-i386.openoffice.org_2.0.1oob680m2-0ubuntu1_FAILEDTOBUILD.txt.gz
#ubuntu-devel 2006-03-01
<slomo> doko: ping? do you know something about valgrind and can confirm that http://slomosnail.de/~slomo/temp/valgrind_3.1.0-2.1ubuntu1.debdiff is the correct solution for bug 2958?
<Ubugtu> malone bug 2958 in valgrind "valgrind is generating warnings on /lib/ld-2.3.5.so" [Normal,Unconfirmed]  http://launchpad.net/bugs/2958
<doko> slomo: can look at it, but not before the weekend
<slomo> doko: ok, thanks... just ping me when you have some time... shouldn't take too long :)
<PounK> hello
<PounK> does dapper will have ubuntu express?
<Burgwork> PounK, yes
<PounK> but why it is in Deferred BreezyGoals ( https://wiki.ubuntu.com/DapperDrake )
<tepsipakki> does this raise any concerns http://benjamin.smedbergs.us/blog/2006-02-22/debian-versioning-of-mozilla-libraries-harmful
<tepsipakki> +?
<PounK> oh, breezy goal lol
<Burgwork> PounK, that is old
<PounK> is it in the flight cd 4?
<Burgwork> yes
<PounK> good
<PounK> and does kubuntu live contain ubuntu express?
<Burgwork> PounK, they are working on a kubuntu-express
<PounK> and it will be avalaible for dapper / it avalaible on flight 4 ?
<Burgwork> ready for dapper, not ready for flight 4, afaik
<PounK> ok, thank
<Burgwork> np
<CarlFK> dapper install, grub step, error.  should I be able to run grub from the VT2 shell?  cuz I can't.
<dholbach> good night
<ohoel> ( http://appelsinjuice.org/firefox-huge-error.png ) Malone next stop?
<jdub> ohoel: no, quit firefox and restart
<jdub> ohoel: you probably upgraded it underneath a running session
<ohoel> persistent after a firefox restart and a reboot
<ohoel> ah, nailed it to the nb/no language pack
<Kinnison> torkel: thanks
<jouston> hello. 
<jouston> Anyone familiar with ACX100/110 driver?
<Burglaptop> jouston: if you are having issue with it, please test the latest dapper and file a bug
<jouston> Burglaptop: I don't think it is a bug. I also already installed Feb 17 dapper
<Burglaptop> jouston: if it doesn't work ootb, it is a bug
<jouston> Burglaptop: BTW, your promptly reply surprice me. XD
<Burglaptop> I try
<jouston> Burglaptop: I suppose everybody is sleeping in another side of earth. XD
<Burglaptop> jouston: yes
<jouston> Burglaptop: I just want to explain this issue and ask it is a bug or not.
<jouston> ACX driver need proper firmware to drive the cards.
<Burglaptop> ok
<jouston> Unfortunately, my card isn't supported by default firmware in dapper.
<Burglaptop> then file a bug
<jouston> More unluckly, we don't have any firmware compatible with ACX driver on PCi's website.
<jouston> Burglaptop: But. NDISwrapper can support this card.
<Burglaptop> jouston: if it doesn't work out of teh box, it is a bug
<jouston> How can I tell a good story for this bug? I'm wondering.
<Burglaptop> say it doesn't work and relate all information you have about it
<jouston> Burglaptop: thanks.
<Burglaptop> jouston: np
<jouston> And I have another issue. There is no "jdmouse" for ubuntu
<Burglaptop> jouston: jdmouse?
<jouston> This is essential for a Sony vaio.
<jouston> http://jr0bak.homelinux.net/~imai/linux/jogdial.html
<jouston> Sorry it is a Japenese site.
<Burglaptop> hardware that doesn't work out of the box is a bug, file it as such
<jouston> Basically, it will ran as a daemon to handle Fn KEY event for a Vaio
<Burglaptop> not saying it will be dealt with, but at least we know it is there
<jouston> Burglaptop: OK. I'll file two bugs.
<jouston> Burglaptop: But where can I file? I'm not familiar with Ubuntu development process.
* jouston making a lot of trouble. :-~
<Burglaptop> https://launchpad.net/distros/ubuntu/+filebug
<jouston> Burglaptop: Great thanks.
<Burglaptop> np
<Tulga> hi all! I want install xgl on kubuntu dapper 4. please recommend me good howto
<crimsun> Tulga: please redirect to #kubuntu
<Se7h> mjg59 u available?
<Burglaptop> Se7h: it is 6am where he is
<Se7h> :o u don't say
<Se7h> thats ok, i'll 'try again later' 
<robitaille> he has been idle for 7+ hours
<Se7h> :)
<Se7h> robitaille i didn't check hes idle
<crimsun> more than likely asleep, being in the UK
<Se7h> uk?
<Se7h> im confused
<Se7h> its not 6am in uk
<Burglaptop> sorry, 4am, my math was off
<Se7h> same timezone here ;)
<wasabi> So I must now get Xgl working
<wasabi> How do our packages fare?
<Se7h> i'll expose the annoying thing here. My external usb hd is getting into 'sleep mode' while being used
<Burglaptop> Se7h: file a bug. this channel is for discussion of your fix to that bug, not the bug itself
<Se7h> sure, i dont even know if its a bug, i'm just asking for some suggestions any of u might have
<desrt> whoever; pong
<Burglaptop> Se7h: if it doesn't work on a default install of Ubuntu, it is a bug
<Burglaptop> desrt: salut
<Burglaptop> long time, no see
<Se7h> its been always like this, i thought it might be something with configs or something
<desrt> indeed
<desrt> how is life?
<Burglaptop> work isn't bad. Book writing is harder than expected. But the cool new thing I am organizing is a Freegeek style organization for Victoria
<desrt> what are you writing a book about?
<Burglaptop> desrt: Ubuntu
<shaya> any kernel guys here?
<Burglaptop> myself, Jono and Mako are writing "The official Ubuntu book"
<shaya> there might be a bug in isofs 
<shaya> dvd i burnt reads fine in windows, but on dapper gets a "trying to read past end of device" error
<mako> Burglaptop: in fact, i'm writing it RIGHT NOW
<ajmitch_> mako: hoping to have it available under some free license?
<Burglaptop> mako: racing to the deadline like me, hmm?
<Burglaptop> ajmitch_: yes
<mako> ajmitch_: in fact it will
<mako> Burglaptop: when is the deadline?
<ajmitch_> great
<mako> Burglaptop: i think one chapter will be a few days late
* Burglaptop just laughs
<Burglaptop> next monday
<mako> hmm.. maybe i will make it
<Burglaptop> ajmitch_: the currently plan is cc-by-sa 2.0 and gfdl, same as the doc team
<mako> no, probalby not
<Burglaptop> it might actually be stored in the docteam repos
<mako> Burglaptop: you should have seen my last book.. SO LATE
<Burglaptop> mako: how many pages to go?
<mako> Burglaptop: i'm not really counting by pages
<Burglaptop> mako: I gathered that from speaking deb
<ajmitch_> Burglaptop: ok, shippable in main/universe?
<Burglaptop> with deb, even
<mako> i got it all in before i needed to be
<Burglaptop> ajmitch_: not for dapper, afaik
<mako> but it was under the line
<ajmitch_> Burglaptop: ah well
* ajmitch_ will have to get an autographed hard copy
<Burglaptop> ajmitch_: it will be published by just after dapper
<Burglaptop> hence the tight deadline
<mako> it's not so bad
<mako> well, review is a pain in the ass
<mako> author review and all that
<Burglaptop> mako, I figure I will look good compared to you, if I get it all in on the deadline
<Burglaptop> :D
<ajmitch_> getting the autographs might be a fun task 
<mako> yeah, i'll have all but one chapter in by the deadline
<mako> and the last one in by.. next week i guess
<Burglaptop> the money from this book should fund me to the next conference
<ajmitch_> that would be great
<ajmitch_> I doubt I'll be at the next one
<Burglaptop> screw my student loan
<ajmitch_> my loan is already well over
<Burglaptop> 10k to go!
* ajmitch_ is doing a bit of C# work right now that might pay for it, if I really wanted to go
<Burglaptop> ajmitch_: windows or mono?
<mako> Burglaptop: yeah, i always find time for this but my real life has to take priority
<mako> Burglaptop: i had a big academic AI paper due on tuesday night that i was working on
<Burglaptop> mako: holy crap ya
<LaserJock> mako: what degree are you working on?
<mako> LaserJock: SM->PhD
<ajmitch_> Burglaptop: win ce.net
<mako> at the MIT Media Lab
<Burglaptop> ajmitch_: at least it isn't php
<LaserJock> mako: cool, I'm working on my PhD too, but in Physical Chemistry
* Burglaptop is looking for someone to integrate Userful's multiseat hacks into X.org multiseat for dapper+1
<ajmitch_> Burglaptop: that was my last job, for several months
<ajmitch_> Burglaptop: when I met you in .ca I was a self-confessed php hacker
<Burglaptop> my kingdom for more and better free software jobs
* ajmitch_ is shocked to see his laptop swapping away
<ajmitch_> but I did just start OOo2
<Burglaptop> ajmitch_: how much ram do you have in that thing?
<ajmitch_> 1GB
<Burglaptop> whiprush: how is that detriot youth and ubuntu thing
<Burglaptop> swapping with 1gb???
<ajmitch_> but it's bzr chewing the RAM doing a merge
<Burglaptop> ah
<ajmitch_> and vmware server running winxp
<Burglaptop> so you do you development in bzr and ubuntu, with wince running in vmware?
<whiprush> Burglaptop: just got started, got about 20 of them done.
<whiprush> still figuring out logistics, donations, etc. etc.
<ajmitch_> no, winxp is in vmware to run some windows apps for this job
<Burglaptop> whiprush: how quickly do you think you are going to scale?
<whiprush> Burglaptop: once I get pics I'll blog a status report.
<Burglaptop> whiprush: and you are recycling computers or using new?
<whiprush> recycling
<fabbione> morning guys
<ajmitch_> morning fabbione 
<whiprush> people and companies donate, get the tax writeoff, and then people can buy edubuntu PCs for $100.
<ajmitch_> whiprush: sounds reasonable
<whiprush> for everyone they buy a needy family in detroit gets a free PC.
<Burglaptop> whiprush: ah cool. I am in the beginnings of doing something similar in Victoria
<whiprush> ah, have you seen freegeek?
<ajmitch_> whiprush: what made you choose edubuntu?
<Burglaptop> yep
<whiprush> ajmitch_: seemed like the natural choice.
<ajmitch_> whiprush: targetting the families with kids?
<Burglaptop> I was thinking of taking the old p1 and p2s and running a pure gcompris desktop on them
<whiprush> yeah, well, kids actually refurb the PCs and stuff.
<Burglaptop> whiprush: http://www.relectronics.org/ <-- who I am basing it off of
* ajmitch_ didn't think that you'd need the edubuntu server functionality
<whiprush> it's tied into a program in the city that is designed to educate kids on technology and whatnot.
<whiprush> ajmitch_: it has a workstation mode.
<Burglaptop> whiprush: have you thought about multiseat?
<ajmitch_> whiprush: yeah I know
<Burglaptop> whiprush: because if you can find a development, I have some code for you
<Burglaptop> s/ment/er
<whiprush> Burglaptop: the key was to just attach to an existing charity. They did all the legwork on getting corporate sponsorship, getting nonprofit status, etc.
<ajmitch_> Burglaptop: you're allowed to release some of the code from work?
<whiprush> Burglaptop: not at this point.
<Burglaptop> ajmitch_: already technically gpl/lgpl
<Burglaptop> and X now has multiseat
<ajmitch_> Burglaptop: nice, I thought it was based on the X code
<Burglaptop> http://openuserful.sourceforge.net/wiki/index.php/Patches
<Burglaptop> already released
<whiprush> Burglaptop: the neat thing is that some towns around here are doing free municipal wifi, so a refurbed PC with a wifi nic is feasable without the ongoing cost of an internet connection.
<Burglaptop> whiprush: I am going to attach myself to habitat for humanity (who are much less christian in .ca)
<ajmitch_> Burglaptop: you've shown these to ogra?
<Burglaptop> ajmitch_: I will once dapper releases
* ajmitch_ imagones 1 or 2 at least might be useful
<whiprush> so, right now we're bouncing the idea of corporate sponsors kicking in for the price of the PC, and in return we could do like an RSS-like screensaver that'll show off their products or something.
<ajmitch_> whiprush: you'll love that f-spot has a gnome-screensaver hack in it now
<whiprush> yeah I read that, awesome.
<Burglaptop> you doing it volunteer?
<whiprush> me? yeah.
<ajmitch_> whiprush: I have 0.1.10 ready here, needs UVF exception though
<whiprush> nice nice.
<whiprush> Burglaptop: we've already approached Ford Motor for sponsorship
<Burglaptop> ogra: http://openuserful.sourceforge.net/wiki/index.php/Patches
<whiprush> so like, they help subsidize the PC, they get a screensaver with the latest model of the car or whatever.
<Burglaptop> cool
<whiprush> then us volunteers just run classes for the kids and stuff while they build the PCs.
<Burglaptop> whiprush: can we chat on the phone tomorrow about how you are doing it?
<whiprush> one of our loco guys is going to do simple python classes and whatnot.
<Burglaptop> whiprush: I can all you wherever
<whiprush> yeah sure, 248-370-2584, I'm on EST.
<Burglaptop> thanks. I am trying to talk to all the various organizations like freegeek, etc. about what they are doing
<whiprush> yeah we just started so we're finding all sorts of problems, heh.
<Burglaptop> and one more longdistance phone call really doesn't matter
<whiprush> we're going to have the local news stop by in a few sessions.
<Burglaptop> how many people do you have volunteering?
<whiprush> ~20-ish so far.
<whiprush> we haven't done brochures yet or anything though.
<Burglaptop> whiprush: http://freegeekcolumbus.org/wiki/Main_Page <-- these people install Ubuntu
<whiprush> that's the nice thing about hitching with an existing charity.
<whiprush> they usually have this infrastructure already in place.
<Burglaptop> yep
<Burglaptop> partnering with hfh gets me their restore, which means i get retail space
<whiprush> the first few hours suck, rebuilding all those PCs, but once the kids get going in the gimp or whatever it's really rewarding.
<Burglaptop> you think edubuntu is a better fit for most than ubuntu?
<Se7h> now that would be a nice a idea, spread this to portugal schools instead of that malicious windows
<Burglaptop> Se7h: spain leads europe in number of linux (and gnome) desktop, from what I understand
<whiprush> well, i'd rather trust ogra and co. to pick out the good educational apps than me customizing a CD to add kid programming.
<Se7h> i don't doubt of it
<whiprush> plus, ideally we can provide good feedback to edubuntu
<Se7h> uncle bill came here not long ago (few weeks) to spread his 'faith'
<Se7h> :>
<ajmitch_> evening mpt__ :)
<Se7h> but realy, i'd enjoy seeing ubuntu/edubuntu in school computers instead of just 'lets talk about linux now' for just a fews weeks at classes
<Burglaptop> Se7h: make it happen
<Se7h> i will if i get the chance, dont doubt
<Burglaptop> whiprush: ogra is looking for someone to help packaging willow, a bayseian web filter
<whiprush> yeah I need to get our plan in order a bit more still though.
<Se7h> that would be a nice step for PC's sellers to asked 'i want linux on my desktop/laptop'
<Se7h> *to be asked
<Se7h> well 5.25am, it's bed time
<Se7h> later all
<Burglaptop> whiprush: jsut reading the point about tiger_whitehead wanting filtering
<whiprush> yeah, I've been looking at integrating dansguardian.
<whiprush> I'm still researching around though.
<Burglaptop> whiprush: ogra seemed to love willion because it is bayesian
<whiprush> bed for me too, we'll talk more tomorrow.
<Burglaptop> http://www.digitallumber.com/willow
<Burglaptop> ajmitch_: the mounted volumes not placing icons on the desktop. Is that a policy decision or a bug?
<ajmitch_> policy, I *think*
<Burglaptop> I can't seem to find anything on DapperDesktopPlan
<ajmitch_> it's a gconf key (/apps/nautilus/desktop/volumes_visible)
<ajmitch_> so I imagine it's been set off by default
<ajmitch_> you'll have to check with seb128
<Burglaptop> appears to be unchecked
<Burglaptop> ah, bloody hell, stupid gpm
<Burglaptop> hiding while on AC is crack
* Burglaptop fires off two mails to -desktop
<pitti> Hi
<ajmitch_> hey pitti 
<pitti> hi ajmitch_ 
<jouston> Hi
<jouston> Anyone knows where the hotplug directory is?
<jouston> I would like to put some non-free firmware into my Dapper
<crimsun> jouston: hotplug is gone from Dapper.
<Burglaptop> jouston: please ask in #ubuntu+1
<ajmitch_> bbl, see you next week
<jouston> Burglaptop: THX
<siretart> morning
<mdke_> morning :)
<pitti> hey siretart 
<mjg59> Kamion: When you're up - any chance you can NEW spiftacity? It'd be good to be able to say this is all in at FOSDEM
<mjg59> (No rush, though)
<infinity> spiftacity? :)
<infinity> spiftastic metacity, I assume?
<Treenaks> (no rush, but FOSDEM is tomorrow :P)
<tepsipakki> <any main-priv devel>: ping?
<infinity> tepsipakki: Pong.
<tepsipakki> infinity: hi! do you have time to push a new version of libnfsidmap? I've asked for UVF already (no answer yet, though)...
<infinity> tepsipakki: No can do without the UVF from mdz or Kamion.
<tepsipakki> inifinity: ok, I'll try to get that first, then ,)
<tepsipakki> ;)
* infinity nods.
<infinity> I'll be happy to go over your changes and sponsor the upload once you get approval.
<tepsipakki> it's here, if you'd like to take a first look.. (it's repackaged according to the feedback I got from libgssapi and librpcsecgss which made it in) http://revu.tauware.de/details.py?upid=2019
<tepsipakki> sorry, Section: libs is still missing from the Source:
<tepsipakki> new version on the way..
<siretart> uuuuh
* siretart notices that openal is in main
<siretart> :/
<infinity> tepsipakki: Can you mail me about it (better yet, CC me on your UVF enquiries, so I know when it's okay to sponsor the upload?)
<infinity> tepsipakki: I'm off for the weekend now, so... Mail is always best.  adconrad@ubuntu
<tepsipakki> infinity: ok, thanks!
<tepsipakki> will do
<dholbach> good morning
<Treenaks> hey dholbach 
<Treenaks> dholbach: are you going to FOSDEM?
<dholbach> Treenaks: no, sorry, I won't.
<Kamion> mjg59: source NEWed, will check for binaries later
<mjg59> Kamion: Thanks!
<pitti> yay hal 0.5.7
<mjg59> pitti: There's a pretty vital looking patch in there (lets hal-input-addon work with ADB keyboards)
<Treenaks> mjg59: so.. what's spiftacity? just metacity + build-options? or a complete fork?
<pitti> mjg59: whoa, that's a whole lot of bug fixes in the changelog
<pitti> sjoerd: new hal's out for 2 hours, so where's your deb? :-P
<mjg59> Treenaks: Metacity CVS + build options + libcm dependency
<pitti> hey seb128 
<seb128> hi pitti :)
<dholbach> hey seb128!
* seb128 grumpf to yesterday dist-upgrade which took ages, thanks to pitti :p
* pitti whistles innocently
* seb128 hugs pitti
<seb128> dholbach: hi :)
<hunger> Any chance of seeing malone #23388 fixed in dapper?
<Ubugtu> malone bug 23388 in lsb lsb-base "tput used in /lib/lsb/init-functions after /usr is unmounted" [Minor,Unconfirmed]  http://launchpad.net/bugs/23388
<hunger> The bug is marked for ubuntu-6.04... but so far I have not seen anybody working on the issue.
<seb128> pitti: that means we will divert from Debian for all the packages you uploaded now?
<pitti> seb128: I actually diverted very few, maybe 5
<pitti> seb128: most of them were already diverted before
<seb128>  ekiga (1.99.1-0ubuntu3) dapper; urgency=low
<seb128>  .
<seb128>    * debian/rules: Add gettext domain to .server and .desktop files to get
<seb128>      language pack support for them. (Similarly to cdbs' gnome.mk)
<seb128> 
<seb128> stuff like that?
<pitti> yep
<seb128> hum, k
<sivang> pitti: morning
<pitti> hey sivang 
<sivang> pitti: did you send me anything?
<pitti> sivang: no, not yet
<pitti> I thought I'd wait for you, and check if you actually have time
<pitti> sivang: anyway, I'm already down to 7 packages on the TODO list
<sivang> pitti: since when have you been working? ;-)
* pitti is up since 6:30
<sivang> or wasn't there a lot of package in the first place..
<pitti> it wasn't that much any more
<sivang> wow
<sivang> okay, where the todo list?
<pitti> sivang: tomboy tuxmath tuxtype vim xmms xsane xscreensaver
<pitti> ogra: will xscreensaver stay in main?
<pitti> ogra: nevermind, -data will
<Treenaks> pitti: I have a XUL error (launchpad-related I think) in Mozilla
<pitti> Treenaks: how can LP cause them?
<pitti> that rather means some locale package or so is not in sync
<Treenaks> ('<menuitem label="&helpGetHelpOnline.label;")
<Treenaks> That _sounds_ like launchpad-integration to me
<sivang> Treenaks: IIRC seb128 did that, you can ask him.
<pitti> yes, true
<pitti> the patch should just be reverted, mozilla is universe now
<Treenaks> pitti: it's firefox, sorry
<seb128> what patch?
<seb128> pitti: you think we patched mozilla for lpi? :)
<seb128> one browser is enough :p
<pitti> seb128: I hope not :)
<seb128> anyway 
<seb128> "   Bookmark, search and translation reference regression fixes:
<seb128>    * Restore `Translate This Application' and `Get Help Online'"
<seb128> from the upload Diziet did yesterday
<Treenaks> OK, so that broke it
<Treenaks> or broke..
<Treenaks> I have a perfectly working firefox
<Treenaks> with an XML error at the bottom
<Treenaks> (and no help menu)
* mvo is going to to his first commit to the new *bzr* tree of synaptic
<dholbach> mvo: !!! :)
* mvo goes to create a ubuntu branch
<highvoltage> history happening here? wish i could understand all of it :)
<Treenaks> pitti: so, when will the firefox locales be updated? :)
<pitti> Treenaks: I have no idea how to change them
<Treenaks> great!
<Treenaks> so where do I file the bug?
<pitti> well, I'll check out the issue
<Treenaks> ok
<pitti> Treenaks: file it on firefox please
<torkel> it is already filed multiple times
<torkel> Treenaks: See #32651 for a workaround.
<pitti> what's wrong with LP builders? I uploaded cdbs almost two hours ago, and the new deb is still not even attempted to be built
<hunger> Hmmm... shouldn't be readahead get run only after /usr is mounted?
<hunger> It tries to read files from /usr after all... or maybe it could be run twice?
<hunger> It is about 50% of the files in /usr after all.
<ogra> pitti, xscreensaver will stay in main for xfce 
<pitti> ogra: yep, nevermind, the .desktop files are in -data and we need them anyway I guess
<pitti> ogra: besides, it's already fixed :)
<ogra> the .desktop files for gnome-screensaver dont need to be translateable for now ... they only show the app name ...
<ogra> so dont waste time on them
<Treenaks> ogra: well, I might want to change 'Gears' to something else in Dutch... ?
<ogra> really ?
<Treenaks> ogra: yeah, in Dutch it's 'Tandwielen'
<ogra> was it translated in xscreensaver ? 
* ogra cant remember and is to lazy to install it ...
<Treenaks> ogra: no, but that's not the point :)
<hunger> Is Michael Vogt still around?
<mjg59> hunger: I see acpi-support bugs without them being assigned to me
<hunger> mjg59: Sorry then. I am trying to clean out my reported-bugs list somewhat.
<dholbach> hunger: it's mvo
<hunger> dholbach: Thanks.
<Kamion> in general reporters should not assign bugs to people in malone
<Kamion> you can subscribe other people to a bug if you want them to see it
<Kamion> the assigned-to field is (I'm told) intended to mean "this person is working on the bug"
<hunger> Kamion: Is that documented somewhere?
<Kamion> the UI is not great when you're *re*assigning, so this doesn't always work right, but at least we can avoid reporters declaring that the maintainer is working on a bug when this is not true :)
<Kamion> hunger: no idea, I'm not a Malone developer
<hunger> Kamion: I do not want to do something wrong... I am just doing what seems to get the bug fixed.
<hunger> Kamion: assigning one works wonders most of the time;-)
<hunger> Kamion: Besides: somebody recommended here to assign to the last person mentioned in the changelog a while back when LP was still new.
<hunger> Kamion: and the UI is not great whatever you do;-)
<Kamion> I get people assigning me bugs I was already subscribed to quite a lot
<Kamion> the only effect is more noise in my mailbox for me to wade through
<Kamion> I would rather they just pinged me if they wanted to know the status
<hunger> Kamion: OK, I'll try to keep that in mind before assigning stuff to you;-)
<hunger> Seriously: I do not want to cause more work for anybody. So I'll no longer assign bugs.
<hunger> How can I find out whom to ping about the bug status though?
<Kamion> a comment in the bug?
<Kamion> I mean, if there hasn't already been one recently
<hunger> Kamion: OK. I'll do that then.
<mvo> hunger: hello?
<simira> gee, you guys are working too much sometimes! *upgrades*
<hunger> mvo: yes.
<mvo> hunger: anything particular you wanted from me?
<hunger> mvo: I only wanted to know whether "Michael Vogt" was still with the team or whether I needed to reassign my bug:-)
<dholbach> hunger: he's one of our best assets
<hunger> dholbach: Yes, I know mvo.
<hunger> dholbach: I just did not know that he was Michael Vogt:-)
<hunger> LP should really list the IRC nick in addition to the mail address.
<dholbach> it does, if you specified it
<mvo> dholbach: haha, thanks dholbach
<dholbach> it does for mvo
<hunger> dholbach: Yes, you can find it out somehow, but not from the bug-report page.
<dholbach> launchpad.net/people/mvo
<hunger> dholbach: Yeap, I can search for it via the people page.
<hunger> dholbach: But then I'll end up backtracking to the bugreport.
<dholbach> find a solution to make it easier and propose it to the launchpad team :)
<hunger> dholbach: Yes, I should nag them for a bit instead of keeping honest working ubuntu maintainers of their work!
* dholbach hugs hunger
* mvo hugs hunger
<mdke_> hunger, you can search from the bug report page too
<mdke_> click on "(Choose)" from the bug status page
<hunger> mdke_: Yes, but as soon as I click that the bug gets unassigned and the search is not that useful as it finds 6 mvos.
<mdke_> i don't think that is right.
<mdke_> yes it finds 6 mvo's, but the bug's status doesn't change until you commit your changes
<hunger> mdke_: Oh and it does NOT find the email cut'n'pasted into the search field from the assigned-to bug-report area.
<mdke_> sorry, i don't understand
<mdke_> best take it to #launchpad
<hunger> This is nothing that needs discussion here:-)
<BockBilbo> hello
<BockBilbo> i just wanted to tell you guys that the mozilla-firefox-locale-es-es package in dapper is corrupted
<BockBilbo> it makes firefox work badly
<BockBilbo> showing an error in the botton saying: <menuitem label="&helpGetGelpOnline.label;" ______^
<seb128> already known, but thanks for reporting it :)
<BockBilbo> ok
<BockBilbo> :)
<BockBilbo> bye!
<seb128> (though launchpad is the right place to send bugs, on IRC it's likely the maintainer will not read your message)
<BockBilbo> ok
<BockBilbo> ill make a note for the next time
<BockBilbo> :)
<BockBilbo> by the way, have you guys noticed that if using xserver-xgl the gnome session takes a long while to load...
<BockBilbo> ?
<seb128> #ubuntu-xgl
<seb128> :)
<BockBilbo> ok
<seb128> I've not tried it for my part ;)
<BockBilbo> thanks seb128 
<BockBilbo> :)
<seb128> np
<BockBilbo> bye! Ill be in #ubuntu
<Diziet> Kinnison: ping
<mvo> Diziet: I think he left for fosdem
<Diziet> Ahh.
<Diziet> Hmm.  Does anyone else have this firefox xml error ?
<Treenaks> Diziet: Yes
<Diziet> Oh, here we go, in the scroolback.
<Treenaks> Diziet: I've merged a few bugs about it into one
<Diziet> It's very strange.  Yesterday when Kinnison told me about it I thought I'd manage to bungle the upload somehow but that's not it.  It works fine for me.
<carl> http://cdimage.ubuntu.com/ubuntu-server/daily/current/ is empty - is that expected ?
<Treenaks> Diziet: It has something to do with the interaction Launchpad-integration <-> langpacks
<Diziet> I mean, even the version built by the buildds works.
<Treenaks> Diziet: if I remove my langpack, it works OK
<Diziet> Ahh, excellent info.  I should read my mail really ...
<Diziet> Just to confirm: normally, if some of the strings in ff aren't translated, do you get bits of English text ?
<Diziet> (Like normal, with a not-completely-translated program?)
<Treenaks> Diziet: in non-XULly programs, yes
<Diziet> But what about in XUL ?
<Diziet> I think I must have put the English string for the menu item labels in the wrong place.  I need to put them in the `fallback' place, not in en_US-only.
<Treenaks> Diziet: then I just get errors when the translation-version is out of sync with the 'original'
<Diziet> So every string has to be translated ?
<Diziet> And, errors like this one ?
<Treenaks> Diziet: Yes, missing translations give errors like this one.
<Diziet> Joy.
<mdke_> are you guys talking about this:  <menuitem label="&helpGetGelpOnline.label; ?
<Diziet> Yes.
<mdke_> isn't it just a typo?
<mdke_> GetGelp?
<Treenaks> Diziet: happened a few times before.. when the langpacks didn't get updated but firefox did
<Diziet> Err, Kinnison's screenshot shows `GetHelp'.
<Treenaks> mdke_: it's correctly spelled here
<mdke_> ah right
<mdke_> perhaps the chap in here mis-copied
<mdke_> sorry
<Diziet> So does the langpack construction process somehow automatically greps the strings out ?
<Treenaks> Diziet: --> pitti
<Diziet> I'm trying to figure out what I need to do now and of course what I need to do next time.
<pitti> Diziet: not for ffox, it doesn't use gettext
<Treenaks> Diziet: I _think_ XUL (or Firefox, or whatever) lacks a 'fallback' method (or it's heavily under-used)
<pitti> We just import the xpi files from upstream
<Diziet> How annoying.
<Diziet> What's an XPI file ?
<Diziet> Feel free to tell me to RTFM if you can provide a URL for the FM :-).
<pitti> Diziet: a zip file with a .jar (the actual translations) and some description metadata
<pitti> Diziet: it's the common install format for mozilla stuff
<Treenaks> isn't a .jar a zip in disguise?
<pitti> i. e. you can point to it in the address bar, or in the extensions dialog
<Diziet> So what if I want to add a new translated string ?
<pitti> Treenaks: yes
<pitti> Diziet: that's highly nontrivial, and we have a spec about it
<pitti> https://launchpad.net/products/rosetta/+spec/rosetta-firefox-support
<Diziet> Err, sorry, I'm confused.  I mean: I have added, in a patch to our firefox, a couple of new menu items, which have labels which ought to be translated.
<Diziet> Apparently something needs to be done to the langpacks.  What ?
<Treenaks> (and for which translations _are_ available, in the launchpad-integration package ?)
<Diziet> Or, is there something I should do in firefox to make it work ?
<Diziet> I'm not asking for Rosetta integration.
<pitti> Diziet: the spec is about dissecting translation .jar files to gettext po files, which we can modify, and then rebuild new .jar files from them
<pitti> but that's a highly nontrivial process
<Diziet> Yes, so I don't want to do that.
<pitti> Diziet: is there a way in ffox to mark these strings as not translatable?
<Diziet> Yes.
<pitti> Diziet: that would be good enough for now, I think
<Diziet> Oh.
<Diziet> It seems a bit odd to have `Translate this application' (a) in English and (b) not let you translate this application !
<pitti> Diziet: well, in fact, in Dapper you won't be able to translate firefox anyway
<Diziet> Also `Get help online' is something that it would be very nice to have translated.
<Diziet> So I should rename it to `help translate Ubuntu' ?  And if so, why is it in the Firefox help menu ?
<pitti> Diziet: maybe it makes sense to drop that particular menu item for dapper
<Diziet> sabdfl specifically noticed that it was gone and complained.  I'm trying to understand why the original decision was made; it's always wise to understand the original reasons before you decide to overturn a decision.
<Diziet> (gone = in earlier 1.5 packages for Dapper)
<pitti> hmm
<pitti> well, all I can say is that ffox translations won't be there for dapper; I hope it will for dapper+1
<Diziet> Right.
<Diziet> Do most Gnome applications have a `translate this program' in the Help menu ?
<pitti> yes
<Kamion> carl: it's probably just taking ages to sync to the mirrors; there's still an rsync running from the cdimage master machine
<carl> okee dokee
<Diziet> OK.  Well, I'll remove the Translate item and untranslate the Get Help Online then.
<Diziet> Thanks for the info.
<pitti> thanks
<tepsipakki> Kamion: have you received my emails about the UVF-exceptions we discussed some day?
<sladen> elmo: please sync hotkey-setup 0.14 and let me know you need me to rebounce you some emails
<Kamion> tepsipakki: yes, but I am swamped and cannot deal with them
<Kamion> carl: (I've brought it up with admins)
<Kamion> tepsipakki: at least not today
<tepsipakki> Kamion: ok, no hurry if it's still possible
<Kamion> is VETSEL Patrice here?
<Kamion> oh, never mind, dholbach already dealt with it
<sivang> mvo: can you offer one of you simple programs to use as an example of using a ListView in python/gtk?
<sivang> s/you/your/
<kbrooks> Hey all.
<kbrooks> Maybe the Ubuntu developers  could include debins into dapper+1
<Treenaks> debins?
<kbrooks> http://programmer-art.org/debins 
<tseng> you could use gdebi
<tseng> or synaptec
<kbrooks> I have sent a patch to them fixing a minor problem with debins
<tseng> if you really want to see this package in you could create a debian source package and upload it to REVU
<kbrooks> tseng, apparently you don't understand what debins was designed for. 
<kbrooks> You double click on a .deb package, and debins goes off & does the work
<Lathiat> sounds like gdebi :)
<tseng> yeah..
<kbrooks> i didnt create it
<mjg59> kbrooks: That's what gdebi does
<tseng> unless you are more interested in being argumentative
<tseng> your next step is really here:
<tseng> https://wiki.ubuntu.com/MOTU/Packages/REVU
<tseng> you could make it in for dapper if you hurry :)
<kbrooks> Well....
<kbrooks> okay.
<kbrooks> `wherres the motu chsaannel
<tseng> #ubuntu-motu
<Lathiat>  #uvbuntu-motu
<kbrooks> i joined #motu no workie
<kbrooks> ty
<Lathiat> minus the typo :)
<doko> Kinnison, mjg59: which package is responsible for setting up the power management of hard disks?
<mjr> doko, I'm not sure if this is the answer you're looking for, but hdparm can set it for ide drives (maybe sata, dunno)
* mvo kicks his network
<Kamion> carl: it's there now
<sivang> mvo: I'd like to ask you 2 questions: 1)Do you have a good simple example of using ListView in PyGTK of your program, 2) How do I find out in pyhotn which mime types are supported / available on the deskotp / system?
<sivang> mvo: (I pasted before but your network got ofF)
<sivang> :)
<sivang> mvo: the media part is to exclude media files from a user's backup, based on mime types registered in a system rather then having a hard coded list of extensios.
<mvo> sivang: I found http://www.pygtk.org/pygtk2tutorial/ch-TreeViewWidget.html useful
<sivang> mvo: ah , okay :) thanks. I bumped into another tutorial when googleing for it, that was a bit less then what I needed. :) thanks!
<mvo> sivang: for the mime-type stuff I don't know
<sivang> mvo: ok, thanks for all your help, btw when using TreeVIew from SimpleGladeApp.py, do you get the reference to the Model from the widget object or create it from scratch, and then 'attache' it?
<mvo> sivang: http://www.pygtk.org/pygnomevfs/class-gnomevfs-fileinfo.html may help you, it seems to include mime-information
<Kamion> you have to create it, glade won't do it for you
<sivang> Kamion: (I'm a bit puzzled of how to find it in SimpleGladeApp.py 
<Kamion> once you've created and set it once you can get it from the widget, though
<Kamion> sorry, don't know what/where SimpleGladeApp.py is
<mvo> sivang: what kamion said (create it yourself)
<sivang> Kamion, mvo : you mean for the model? because the widgent (the 'view') is already created by glade..
<jpatrick> can we still do syncs? (trying to fix malone #6679)
<Ubugtu> malone bug 6679 in nut "fails to start because of change to /var/run" [Critical,Confirmed]  http://launchpad.net/bugs/6679
<mvo> sivang: yes, you need to create the model (and the renderers) yourself
<Kamion> jpatrick: I believe elmo's still working on making the code work reasonably with soyuz
<jpatrick> ok
<Kamion> should an error dialog that requires the application to exit (right at the start - it's because it needs to be run as root) have an OK button or a Close button?
<jbailey> Keybuk, pitti: Let's try here where we can all see.
<jbailey> Keybuk: I remembered for a while you had talked about bringing interfaces up when they were detected.
<pitti> jbailey: well, in dapper we now bring them up when the interface itself arrives
<pitti> jbailey: i. e. when plugging in an usb wireless
<pitti> however, it doesn't do link detection ATM
<jbailey> Right, so not on link state,.
<pitti> that's network-manager's job
<pitti> (which actually works quite well)
<infinity> (for interfaces that support link state)
<ogra> Kamion, a "Cancel" button (since that indicates you have to do the former action again ...) ?
<jbailey> pitti: I remember that old Catalyst switches on a spanning tree network could easily take 30 seconds before giving link.
<Kamion> ogra: ... OK, I didn't expect anyone to say that! Cancel indicates "please let me go back to what I was doing"; I don't think it really works for unrecoverable errors
<pitti> jbailey: something less heavyweight than n-m would be ifplugd
<jbailey> pitti: If we have no way to poll link state, is it hard to beat dhclient into trying again 15 seconds later and repeat, say, a half dozen times before it gives up?
<ogra> hmm, thats how i'd read such a button ... i cancelled the last action i did (which was starting the app apparently), but that might be a misconception ...
<pitti> jbailey: probably not, but I'm not sure whether we should do that by default 
<pitti> jbailey: you mean, there are still a lot of cards around which don't have mii link detection?
<jbailey> pitti: The link detection was infinity's comment, not mine. =)
<jbailey> I have no guesses on that.
<infinity> Kamion: I think the prevailing UI convention seems to be to use "Close" in that case.
<Kamion> infinity: thanks
<infinity> pitti: There are very few cards left that can't do it, but some drivers in the kernel still don't expose it.
<infinity> pitti: And no, I don't recall which drivers, though I remember that only one card on daniels's amd64 machine knew its link state.
<infinity> pitti: One marvell, one nforce.  Don't recall which one sucked more.
<jbailey> pitti: I'm wondering if the retry cycle would actually be harmful in that case, though?  If we're just getting send_packet failures, it's pretty clearly not getting anything out, so trying again shortly after doesn't seem that harmful.
<infinity> jbailey: Didn't we used to do that with dhclient anyway?  (have it retry for quite a while, sleep, retry, etc, then give up after a LONG time...)
<infinity> ie: dhclient itself has that functionality built in, I don't mean WE tried anything special.
<pitti> afk for 5 minutes
<jbailey> infinity: Lemme check in the logs.  Oh, hmm.  There is a link up at 07:02:26.  Then it dhcp's at 07:20:29, gets a send_packet: Network is down.  Tries again at 7:02:49, network is still down.  7:03:04, network is still down.  Then I ifdown'd and ifup'd at 07:03:41.  got network_down.  got link up another link is up at 07:03:43, and dhcpdiscover got love at 07:03:44
<jbailey> Hmm, maybe I'm chasing the wrong bit of confusion.
<sjoerd> pitti: tonight probably :p 
<sjoerd> pitti: btw, you probably want to merge the dbus patch i sent to the dbus list yesterday (if you haven't done already)
<pitti> re
<pitti> sjoerd: no, haven't found time yet
<sjoerd> k, patch is in pkg-utopia svn too 
<sjoerd> will update the debian package tonight
<pitti> sjoerd: you rock :)
<sjoerd> thanks ;)
<sivang> sjoerd: rolling new dbus package? :)
<sivang> sjoerd: possibly with the volume.capacity namespace? :-)
<sjoerd> sivang: that's hal :)
<sjoerd> but i'll update that tonight too
<sivang> sjoerd: ooo, that would be so cool :-D
<sivang> sjoerd: (and sorry about the mistake, I confuse between them alot)
<pitti> sivang: btw, he talks about Debian, not Ubuntu :)
<pitti> sivang: not sure whether we can update hal to 0.5.7; the changelog looks worthwhile, though
<sivang> pitti: indeed, I wonder if you could get UVF expection for that. I recall seb128 said it also makes GNOME a bit happier 
<pitti> yes, and half of the actually intrusive changes we already have as patches anyway
<seb128> go go go for an UVF exception :)
<seb128> that's today or not for that cycle anyway
<pitti> seb128: ok, I'll forward the changelog to mdz and comment about the changes
<seb128> pitti: thank you
<mdke_> how long does it normally take after a package is successfully built for it to appear in the archive?
<seb128> depending if it goes to NEW or not
<mdke_> if not?
<seb128> around 1 hour I would say
<mdke_> hmm
<mdke_> https://launchpad.net/distros/ubuntu/breezy/+source/ubuntu-docs/5.10-6.3 hasn't appeared yet afaics
<seb128> breezy
<infinity> All bets are off for breezy stuff.
<mdke_> oh it's in the archive
<seb128> uploads to stable are moderated and not processed atm
<infinity> The -updates and -backports stuff in soyuz is still in beta.
<mdke_> seb128, it's built and in the archive, but isn't coming onto my system for some reason
<mdke_> http://archive.ubuntu.com/ubuntu/pool/main/u/ubuntu-docs/
<seb128> mdke_: apt-cache policy ubuntu-docs ?
<LinuxJones> Crist there is a spammer in #ubuntu can someone please pop in and kick him ?  damian
<mdke_> seb128,   Candidate: 5.10-6.2
<seb128> mdke_: so it's not listed by the index
<mdke_> right, does that take some time too?
<seb128> should not
<infinity> Well, not, but like I said, the soyuz handling of -updates is still ongoing work right now.
<mdke_> shall i ask in #launchpad?
<infinity> So it could be "half-published", which some kinks get worked out.
<infinity> mdke_: That might be better.
<mdke_> ok, thanks
<Kamion> mdke_: yes, please do
<infinity> s/which some/while some/
<mvo> Kamion: testinstall on a networkless system seems to have worked fine
<Kamion> good, thanks
<mvo> (just FYI)
<Kamion> so CC.archive.ubuntu.com is in sources.list?
<Kamion> uncommented?
<mvo> yes it was
<mvo> apt-get udpate worked when network was available and stoped quickly when it wasn't 
<Kamion> fantastic
<mvo> infinity: the latest apt upload should have fixed the problem that apt sometimes eats the package index files
<infinity> mvo: I noticed the changelog, yes.  Here's hoping.
<tepsipakki> dholbach: ping?
<infinity> mvo: Also, thanks. :)
<dholbach> tepsipakki: pong
<tepsipakki> dholbach: why did you mark malone 29646 as rejected?
<Ubugtu> malone bug 29646 in apt-setup "support for multiverse" [Normal,Unconfirmed]  http://launchpad.net/bugs/29646
<Kamion> tepsipakki: just the dapper task
<dholbach> tepsipakki: just the Ubuntu Dapper task
<mvo> infinity: cheers 
<tepsipakki> oh, so it's not going to happen for dapper?
<tepsipakki> bah
<dholbach> tepsipakki: that's not what it means
<tepsipakki> dholbach: what then?-)
<dholbach> tepsipakki: Dapper is just not released yet, so it makes no sense, to look for special "Dapper" bugs
<Kamion> tepsipakki: no, dholbach was going through everything filed against dapper because most of them were mistakes
<Kamion> in that particular case, I deliberately marked it for dapper to remind myself
<Kamion> but never mind
<dholbach> Kamion: I'm sorry.
<dholbach> Kamion: you could set the target though.
<tepsipakki> ok, it just seemed as if it was closed :)
<infinity> tepsipakki: If you hit the web page, you'll see that it's still open in one instance, though rejected in the other.  Yes, I find that aspect of Malone very confusing too.
<Kamion> dholbach: that's what I did!
<Kamion> dholbach: if you set the target, it creates a dapper task
<dholbach> argl
<tepsipakki> hehe
<segfault> is there any problem with the latest firefox build? something about the Help Menu.
<mdke> segfault, yes, they are on the case
<segfault> yeah, bug #32678
<Ubugtu> malone bug 32678 in firefox "firefox displays strange error on bottom" [Normal,Confirmed]  http://launchpad.net/bugs/32678
<segfault> its something in browser.jar/content/browser/baseMenuOverlay.xul
<Lathiat> mjg59: please try the synaptics thing?
<Lathiat>   Option          "MinSpeed"              "0.49"
<Lathiat>         Option          "MaxSpeed"              "0.63"
<Lathiat> wrong window
<Kamion> mvo: are #23965 and #26065 fixed with default-apt-sources?
<mvo> Kamion: checking
<Kamion> mjg59: still no binaries for spiftacity - looks like a missing build-dep?
<Treenaks> still?
<Kamion> he asked me to see if it could be made available for FOSDEM, so I'm watching the NEW queue
<infinity> Kamion: I uploaded to fix that.
<Kamion> not just are-we-there-yet-ing
<infinity> Kamion: You're obviously not watching -changes. :)
<Kamion> infinity: ah, thans
<Kamion> +k
<Kamion> it only JUST arrived in my mailbox, after you said that :)
<infinity> Sure, sure. :)
<infinity> Kamion: Do you still have to NEW each arch individually, or has that been fixed?
<infinity> (I ask because you won't see powerpc binaries for a while, it's stuck behind an openoffice build)
<Kamion> infinity: last I checked I did, yes
<infinity> Oh well.  I should go to bed before I accidentall get a second wind and stay up all night again.
<carl> Kamion,  daily files are up, but the BT doesn't have any seeds: http://cdimage.ubuntu.com/ubuntu-server/daily/current/dapper-install-i386.iso.torrent
<carl> Kamion, nm - there are now seeds
<sivang> seb128: yes, let's hope pitti gets the expection :) (re: HAL)
<pusling> would there be any issues like udev or other stuff in backporting a dapper kernel to breezy ?
<seb128> yep
<Toadstool> hi devels
<Toadstool> ping ogra 
<__keybuk> pish
<__keybuk> urhgh
<__keybuk> can't type
<__keybuk> pusling: yeah, backporting dapper kernel to breezy is a "don't do it unless you really know what you're doing" exercise
<pusling> __keybuk: I am not yet that much into kernelpackaging ...  but my alternative might be taking a kernel from kernel.org.
<pusling> and manual install it
<seb128> pusling: what do you need from the new one?
<__keybuk> pusling: that'll have the same problem
<__keybuk> anything hotplug related will cease to work
<pusling> I am just havingsome weird issues with 'freezing' and the computer is not answering for 5-6 seconds while havin thread heavy processes.
<__keybuk> pusling: have you tried a dapper live cd to see whether that really fixes the problem?
<__keybuk> also have you tried booting with pci=noacpi tec.
<pusling> I have trried qeuite different things ...
<pusling> I am having 10 different machines with excactly same hardware, running breezy, doing this.
* Lathiat ponders dmraid support in the installer
<Treenaks> Lathiat: That would give us so many gamers
<Lathiat> heh
<Treenaks> Lathiat: we have a website here ('tweakers.net') which is full of Windows-gamers... who say they'll switch to Linux when it has (a) games and (b) support for the crappy/weird hardware
<Treenaks> Lathiat: dmraid is one of the things that'd need
<Lathiat> it would also let me share my two disks in a raid0 with a certain other os
<Lathiat> :)
<Amaranth> did the -devel list change the reply-to to point to the list?
<seb128> no
<Amaranth> odd, gmail used to have Reply and Reply To All, now it's only showing Reply, which goes to the list
<tseng> maybe they figured out what a mailing list was
<Amaranth> no, wine-devel and d-d-l are still showing those options
<mdke> reply to is normal here, looking at Amaranth's last message
<Amaranth> that's the strangest thing
<Amaranth> is the "Precedence: list" header new?
<Amaranth> err, no, wine-devel has that too
<Amaranth> oh well, i'll just enjoy it
<seb128> doko: grumpf, you broke pycairo the same way as pygtk
<seb128> doko: -dev packages are not to make empty when you drop python2.3 stuff :p
<doko> seb128: fix the rules file, so that that change is a one liner ;-P
<ogra> seb128, but it saves a lot of CD space :)
<seb128> that's no my package
<dholbach> seb128: what? is it mine now?
<seb128> ogra: I'm not sure than some .h .pc are the issue on the CD :p
<doko> seb128: you own NO package in ubuntu :P
<seb128> dholbach: speaking about Debian maintainer
<ogra> somehow we need to compensate for example-content :P
<dholbach> seb128: I was just kidding
<seb128> :)
* dholbach hugs seb128
<seb128> i (h)ate you :p
<doko> kids!
* dholbach pushes the red button on his desk and a huge trapdoor under seb128's feet opens
<seb128> ahhhhhh
* dholbach waves seb128 byebye :)
<seb128> I'll come back soon
<seb128> hihihi
<dholbach> seb128: you have to practise the diabolic laughing a bit :)
<seb128> I've to ask to jdub, he has some nice ones I'm sure ;)
<ogra> we should have more freezes, everybody is so releaxed afterwards :)
<seb128> we have enough freeze
<seb128> UI and string freeze still to come
<ogra> but from a logical point of view, we could relax more if we had more ...
<ogra> :)
<mvo> Kamion: it like I timed adding gdebi to the desktop seed bad. you already did a ubuntu-meta upload today...
<mdke> gdebi will be installed by default?
<mvo> mdke: yes, it will do into the desktop seed
<mdke> ok, thanks
* mdke amends the docs
<Mirv> mvo: hi, could you check your e-mail at some point? I sent you update-notifier's translation twice during the last two weeks, and I just now sent you gai, update-manager (at least for which you said you'd include translations in bzr happily), update-notifier and language-selector translations also
<Mirv> it appears you are developing all of those
<Mirv> no hurry, I just wonder if they're going to /dev/null
<mvo> Mirv: I did all of them already IIRC, update-notifier should be in svn already
<mvo> Mirv: do you follow bzr/svn?
<Mirv> mvo: yes.. not in update-notifier's svn, and the others I didn't send you until 3 minutes ago
<mvo> Mirv: thanks for the g-a-i one :)
<Mirv> Finnish (fi.po)
<mvo> Mirv: looking at it now, I'll send you a mail when it is in
* mvo goes for some early dinner
<Mirv> mvo: thank you! and you're welcome.
<tseng> mdz: ping
<WaterSevenUb> mvo, I also sent you update-manager pt.po a while ago.. I think not included yet. :-))
<tseng> mdz: we'd like to demote gtk-sharp in favor of gtk-sharp2, working on a patch for tomboy
<tseng> mdz: is that the last thing seeded by your count?
<Kamion> mvo: ah well ...
<mdz> tseng: is what?
<mvo> WaterSevenUb: no? can you please resend it, maybe it didn't made it or something. a upload is scheduled for today :)
<WaterSevenUb> mvo, probably now is very outdated, but I will send it anyway...
<mvo> WaterSevenUb: thanks
<tseng> mdz: tomboy
<mdz> tseng: the last thing seeded?
<mdz> in which sense of "last"?
<tseng> mdz: if we build tomboy against gtk-sharp2 binaries, can we make gtk-sharp go away
<tseng> to universe
<mdz> that would be good
<mdz> tseng: so tomboy is the only package in main which uses it?
<mdz> (did you check germinate?)
<tseng> oh crap
<tseng> dbus
<tseng> has libgtk-cil as a build-dep for some reason
<Lathiat> because it uses the gtk mainloop
<Lathiat> in c#
<slomo> Lathiat: that's the glib mainloop
<slomo> i'll get this fixed
<slomo> don't worry
<tseng> slomo: rock.
<Lathiat> slomo: yeh but last check glib was only in gtk-cil? or has it been split out now?
<Lathiat> ah thats changed
<Lathiat> cool
<tseng> Lathiat: its always been split
<tseng> Lathiat: in debian
* Lathiat wonders if hes getting confused with something else
<Lathiat> perhaps python
<Lathiat> yes i think
<slomo> lamont: yes
<slomo> s/lamont/Lathiat/
* lamont grumbles at nfsv4, prepares to drop it again
<slomo> tseng: so dbus is the last one build-depending on gtk-sharp stuff?
<tseng> http://people.ubuntu.com/~cjwatson/germinate-output/dapper/dapper_main_Sources
<tseng> there are only a handful of -cil's if you jump around to get a picture
<slomo> tseng: it doesn't even build-depend on it in reality... it's only a leftover in control :o
<tseng> slomo: oh, thats useful
<slomo> tseng: fixed
<theCore> I'm just wandering, is it a good idea to use Dapper for developping Dapper?
<tseng> slomo++
<tseng> theCore: of course it is
<tseng> theCore: the launchpad guys call it "eating your own dogfood"
<sivang> theCore: dapper is rocking :)
<sivang> indeed. using what you develop do develop it :)
<sivang> (a bit recursive, but what the hack, fogooding is I gues smore simple)
* theCore love recursion
<theCore> I got a disk crash recently, so I'm thinking to get Dapper as a new install.
<theCore> btw, does any of you know how to fix an inode table?
<theCore> (manually, of course)
<sivang> theCore: I don't know manually :) there's fsck for that AFAIK
<mdke> mdz, could we add a DocumentationTranslationDeadline for April 13th, same as LanguagePackDeadline? gives them an extra week, later translations shouldn't break stuff
<mdz> mdke: to be honest, I think the existing deadlines are already quite late
<mdz> there is not only breakage to consider, but problems with the translations themselves
<mdke> mdz, ok, but doesn't that apply to language packs too?
<mdz> mdke: within language packs, most of the contents can be fixed after release with no ill effects if necessary (i.e., packages not installed by default)
* mdke nods
<mdke> ok then!
<mdz> with documentation, it's on the live CD forever
<mdz> and forever on the desktops of users who don't have Internet access
<mdke> mdz, ok, that makes sens.
<mdz> so we should leave at least some time for users to see the translations
<mdke> +e
<mdke> although we can't fix bugs in the translations without getting translators to fix it in rosetta, and then synching again
<mdz> mdke: if you can enable documentation translation through language packs...
<mdke> haha
<mdke> i wish
<seb128> mdz: I wanted to build nautilus linked with libbeagle (that's a small C lib, it allows to use beagle at runtime if installed and use standard simple method if not) but beagle promotion didn't happen yet ... it should probably be scheduled for next cycle rather now, right?
<slomo> Kamion: tomboy needs gtk#2 now (and dbus is fixed to not depend on gtk#)... can you a) get gtk-sharp2 in main again, it was already approved before breezy release and b) will gtk-sharp move to universe automatically when there's no build-dependy and dependency anymore in main?
<lamont> Keybuk: ping
<Keybuk> lamont: 'sup?
<lamont> looking at your util-linux patch....  you think that's the right solution (as in, I should upload it to debian?)
<Keybuk> lamont: what was the change?
<lamont> hwclock -> S50
<lamont> "after /usr is mounted, fer shur"
<Keybuk> hmm, tricky one; our rcS is rather different from Debian's
<lamont> Keybuk: actually, you completely trashed module loading
<mdz> seb128: if pitti has time to do it soon, it's OK
<Keybuk> lamont: I did, how did I do that?
<seb128> mdz: ok, thank you!
<Keybuk> lamont: I think we would have noticed if it were completely trashed ... :)
<lamont> Keybuk: hwclockfirst.sh is specifically there to address having time be correct during module loading.
<Keybuk> lamont: why does the time need to be correct during module loading?
* lamont goes to find the archived debian bug
<Keybuk> and if it does, hwclockfirst.sh wasn't any good either, it would need to be in the initramfs!
<Keybuk> (where we load a good portion of the modules)
<lamont> bugs.debian.org/50572
<Kamion> slomo: have to go out soon, so not now
<lamont> modules.dep
<Diziet> Has anyone with the strange ff xml and bookmark problem installed 1ubuntu5 yet ?
<Keybuk> lamont: ah, you mean "before you generate modules.dep"
<Keybuk> yes, I was aware of that
<lamont> Keybuk: yes
<Keybuk> and the fact we don't generate modules.dep on boot was a fair reason I took that out
<Kamion> mdz: hmm, I was in hack mode and it didn't really register that you had turned up, but I have to go soon; I might be around for a bit later tonight if you want to discuss espresso progress, otherwise let's make it Monday?
<lamont> Keybuk: ok.  I'll merge things so that ubuntu does things diff than debian... go me.
<lamont> because I'm gonna sync 2.12r-8 after I upload it (dropping nfsv4 again)
<Keybuk> ok, please try to keep our local changes :)
<Keybuk> they took a while to get right <g>
<Keybuk> personally I wish the timezone information wasn't a symlink into /usr
<mdz> Kamion: ok
<Keybuk> because then we could set the clock at S05 or earlier
<mdz> Kamion: it hadn't really registered with me that I had turned up either
<Keybuk> I think jbailey said he'd change that in dapper+1
<mdz> I haven't even finished IRC/mail backlog
<mdz> from 7 hours ago
<Kamion> ouch
<Kamion> if I chmod +x a file, will bzr notice and record that?
<Kamion> hmm, appears so
<lamont> Keybuk: any particular objections from you if hwclockfirst.sh existed but did nothing?
<Keybuk> lamont: yes
<Keybuk> lamont: please leave things as they are :)
<lamont> ok
<lamont> hwclock.sh will get a shade more complicated, but it'll behave correctly
<sivang> hmm, is there a module or a wrapper around the 'file' shell command for python?
<Keybuk> lamont: please observe that one of the changes is to make all of hwclock.sh happen in the background
<sladen> sivang: python-magic
<Keybuk> tbh, I'd rather you just left the script as it is, and not worry about trying to make the Ubuntu and Debian ones "the same"
<Keybuk> especially this close to dapper
<Keybuk> we are after UVF, after all
<Keybuk> we can worry about merging them when dapper+1 opens
<lamont> Keybuk: hrm... what actually brought it up was trying to get nfsv4 support in, but I'm about to rip that out anyway...  Which is to say, I'll work on getting it the same, but we don't need to sync now either.
<sivang> sladen: does it come in the stdlib?
<lamont> Keybuk: so as long as debian works, your merge in dapper+1 should be pretty easy... :-)
<lamont> Keybuk: in fact, I think I'
<lamont> ll just ignore it
<Keybuk> heh, ok
<lamont> Keybuk: when do we generate modules.dep?
<sladen> sivang: it's probably installed on Ubuntu:  apt-cache search python-magic
<Keybuk> lamont: in the postinst of new kernel and module packages
<lamont> ok
<Keybuk> after all, the module information isn't going to magically change :)
<sivang> sladen: it's in universe :-/
<sivang> sladen: I wish it was in main, probably woth another main inclusion report :)
<Diziet> These xen people are mad.  It downloads linux-kernel-yada.tar.bz in debian/rules build.
<Keybuk> sounds like a doogieism
<Diziet> No, I think it came from upstream.
<Diziet> There's various witterings on the pkg-xen list about how to make it not do that.
<Blender_neo> Hello @ all - Did someone mention already that if you paste an extraordinary long string to an variable GnomeApplication it will kill the application?
<dholbach> i just copied 1.000.000 lines
<dholbach> and still no crash
<dholbach> do i need more?
<Blender_neo> I just copied 164k file and every application I tried crashed...
<shaya> any kernel guys here, just filed a bug
<shaya> can help try to debug it if needed?
<zul> try #ubuntu-kernel
<seb128_> re
<dholbach> Blender_neo: if you could follow the instructions on http://wiki.ubuntu.com/DebuggingProgramCrash and file a bug on the crashing application, that'd help
<seb128_> dsl IP change
<seb128_> Diziet: did you get what I was saying?
<dholbach> wb seb128_
<seb128_> dholbach: what did you read from me since some min?
<seb128_> since -> for
<dholbach> mdz seb128: if pitti has time to do it soon, it's OK
<dholbach> Keybuk lamont: I did, how did I do that?
<dholbach> seb128 mdz: ok, thank you!
<lamont> dholbach: did what?
<seb128_> <seb128> Diziet: I think you broke epiphany-browser without your DefaultApplicationsFirefox change
<seb128_> <seb128> s/without/with
<seb128_> <seb128> Diziet: it download stuff all the time now instead of opening the "do you want to ... open ... download" dialog
<dholbach> lamont: excusez-moi - seb128_ was asking what the last thing was, the world heard from him
<lamont> ah, okl
<dholbach> lamont: (before he vanished)
<dholbach> lamont: sorry
<seb128_> dholbach: I was asking from some min ago
<lamont> np. /me goes back to sleep. :-)
<dholbach> lamont: good night then :)
<seb128_> I was not timeouted one hour ago :)
<dholbach> have a nice weekend
<Treenaks> Diziet killed my bookmarks!
<Treenaks> oh wait
<Treenaks> it's the langpack thing
<Treenaks> Diziet: nm
<tepsipakki> lamont: I forwarded the changelog-entry from util-linux_2.12r-8 to nfsv4-list :)
<tepsipakki> ..and of course they released a new version of librpcsecgss today
<lamont> tepsipakki: thanks much
<lamont> it's pretty easy to reproduce: apt-get install nfs-user-server on machine A, export something, and mount it on machine B :-(
<lamont> the v4 code sends an extra 0x10 bytes in its rpc request, which gets it a 'server down' error
<lamont> and I don't feel like bit-decoding
<tepsipakki> thanks, I'll add that to the mail
<tepsipakki> it's strange because the patch is pretty old, but maybe RH or SuSE has patches that they haven't sent upstream
<tepsipakki> but I'll continue to investigate this
<lamont> tepsipakki: and given the collection of twisty mazes of stuff, I didn't feel like tracking down _what_ it thought it was trying to do...
<lamont> it could just be a bug in sarge/nfs-user-server's portmapper... but we still have to work around it...
* lamont lunches
<lamont> tepsipakki: and fwiw, I fixed a couple compile warnings in the patch, which is still there, just not applied.
<tepsipakki> lamont: does the user-server only support udp? the default is tcp after the patch
<tepsipakki> I got a fast reply =)
<tepsipakki> (from the list)
<CarlFK> instlaler installed everything to a fairly sane raid setup (/boot on hda1, / on md0) but on reboot the kernel couldn't mount md0 on / and dropped me to a prompt 
<CarlFK> posting to lanuchpad - what package?
<CarlFK> nm, package is optional now
<Keybuk> tsk @ hunger ... filing bugs just because you *think* there's a problem, without actually confirming whether there is or isn't, is just not tennis, ok? :)
<Keybuk> ugh
<Keybuk> I hate openssl
<Keybuk> I can never remember how to bloody well make certs and crap
<mdz> seb128: gnome-games-data.prerm takes an impressive 3 minutes on my desktop
<lifeless> there used to be a good guide on the freeswan site
<seb128> mdz: gconftool?
<mdz> seb128: yes
<mdz> 3 minutes!
<seb128> mdz: I've some good optimization on my box, I worked with Josselin on that
<seb128> I'm testing it atm on my box
<mdz> on a 2GHz machine with ultra2 disk
<mdz> what does the optimization do?
<seb128> it concatenates the list of schemas if there is one and call gconftool a different way
<seb128> the gnome-applets schemas registration takes 4s instead of 54s before
<seb128> but I want to give some testing to the concatenation stuff before uploading
<seb128> that way it parses the xml base only once
<seb128> that's a bit of a hack but should work fine
<mdz> sounds wonderful
<seb128> we change gconf-schemas, which is the helper used by dh_gconf
<seb128> ie: should be transparent
<seb128> I'll upload monday if it works fine until then on my box
<marcin`> hello developers
<marcin`> I'm trying to prepare some packages for ubuntu
<marcin`> and I got a question
<marcin`> could you guys tell me what will happen if I'll remove all language-* packs from my system?
<seb128> you will get no translation
<marcin`> will gnome still work when I'll remove all language-pack-gnome* ?
<seb128> for main packages, that's it
<seb128> yep
<seb128> it'll just be in english
<marcin`> seb128: but which language...
<seb128> english
<marcin`> a.. so english is 'default' 
<seb128> yep, applications are usually coded in english
<seb128> but that's not really the change to speak about that, you may want to try #ubuntu or #ubuntu-motu if you start with packaging
<seb128> change -> chan
<marcin`> they didn't know how will gnome behave without any lang packs
<marcin`> so they said that I may ask here
<seb128> still not the right chan :)
<seb128> but you got a reply so that should be fine
<marcin`> anyway now I got an answer
<marcin`> exactly - thanks
<seb128> you're welcome
<sivang> seb128: do you know if there anywhere a reference for python-gnome2-desktop::nautilusburn python module? Seems missing from pygtk.org..
<seb128> sivang: dunno, but the API is the C one wrapped so you can use the C one
* sivang goes to look for the C implementation docs
<seb128> anyway, time to stop IRC for today, later
<sivang> seb128: good night , have fun!
<lamont> tepsipakki: dunno - I'll try forcing udp
<lamont> rpc.nfsd 9745 root    4u  IPv4  24197       UDP *:2049 
<lamont> rpc.nfsd 9745 root    5u  IPv4  24200       TCP *:2049 (LISTEN)
<lamont> tepsipakki: ^^
<lamont> and it's the query to portmapper that kills it, not the actuall nfsd/mountd conversation
<pitti> hello again
<jag_fsf> howdy folks -- i just have a question that seems a uniquity in ubuntu that i wanted to ask your thought on... in gconf, there are two similar keys: /desktop/gnome/applications/browser and /desktop/gnome/url-handlers/http -- most distributions seem to sync the two together automagically... ubuntu seems to entirely ignore /desktop/gnome/applications/browser (i.e. it's set for epiphany, even if epiphany isn't installed and firefox is the default 
<jag_fsf> is it just that no gnome application uses /desktop/gnome/applications/browser or that ubuntu has hacked everything to only rely upon /desktop/gnome/url-handlers/http
<bluefoxicy> Anyone want to give me a hand building gtk-gnutella 0.96.1 release?
<bluefoxicy> I can compile/install it, but I want to build an official-quality deb as an exercise
<Burgwork> bluefoxicy, #ubuntu-motu for that sort of stuff
<bluefoxicy> ok
#ubuntu-devel 2006-03-02
<bluefoxicy> Hey guys, on dapper, is there a specific known problem with openoffice.org freaking out?
<Amaranth> gmail is getting really goofy now :/
<Amaranth> ubuntu-devel Reply goes to list, messages sent to me and the list no longer sort into the right label :/
<bluefoxicy> it's telling me 'no suitable windowing system found', oowriter2 won't start at all. . hrm
<bluefoxicy> and nothing on launchpad, so . . . I'm gonna try init 1 3 and see if that fixes it.
<Burgwork> holy crap yum is slow
<LaserJock> Burgwork: that is one reason why I left Fedora :(
<bluefoxicy> haha
<Burgwork> don't I wish
<Burgwork> our desktop multiplier stuff doesn't work on the new X, so no Ubuntu for me
<Burgwork> http://archives.mandrivalinux.com/cooker/2006-02/msg02455.php <-- seems we are not alone in the livecd installer thing
<zakame> afternoon devs :D
<spstarr> hmm, do we have the compositor merged into metcity?
<tepsipakki> lamont: thanks for the info, I sent it to the list...
<Mez> godamn 
<Mez> I wish malone was actually used by everyone else
<Mez> it'd make my life easier
<Mez> wow
<Mez> the mandriva bugzilla is good
<Mez> "Priority: wishlish"
<Tm_T> ugh, osd_cat finally works
<heno> Hello, anyone else having trouble accessing the wiki?
<heno> I get a certificate error now
<pitti> Hi
<freeflying> hi pitti 
<sivang> hi pitti 
<sivang> pitti: any news about the new dbus/hal ? :)
<pitti> sivang: didn't you see Matt's reply?
<pitti> it's approved
<pitti> will do on Monday morning
<pitti> I'd like to do some postgresql hacking and RL stuff on the weekend
<sivang> pitti: oh sorry, was it to u-devel ? 
<pitti> sivang: no, I cc'ed you, and Matt did as well
<sivang> pitti: hmm, then maybe a problem with my email, sorry for nagging then, you ROCK! thanks! 
* sivang hugs pitti 
* pitti hugs sivang
<sivang> pitti: have a nice weekend.
<pitti> you too!
<sivang> thanks :) (back to my hacking)
<TheMuso> c
<siretart> is esspresso supposed to be able to install in lvm volumes? is this a targeted goal for dapper?
<StevenK> Ohhhhh, Dapper Flight 4 looks *nice*.
<sivang> StevenK: ofcourse it does :)
<zakame> it should :D
<StevenK> doko: You are aware that the binary package for moin prior to your upload was 'moin', right?
<StevenK> doko: So now you/I/someone needs to adds Conflicts/Replaces to the three binary packages.
<StevenK> So, who do I need to talk to about a FF exception? :-)
<StevenK> And also talk to about punting the old moin 1.5.0-0ubuntu1 out ...
<Pygi> hi, has it happened already sometimes that one device has several mount points in fstab by installation of dapper?
<Pygi> anyone alive? ping :P
<kent> Pygi: I have seen bugreports about it in launchpad.  
<Kamion> siretart: no, it's not
<Kamion> Pygi: yes, known bug reported about half a dozen times, not investigated yet
<siretart> Kamion: ok. I just tried to install it on lvm, and the partitioner showed my each LV as separate volume. this is quite confusing
<Kamion> siretart: feel free to file a bug; it won't support LVM installations for dapper though
<Kamion> too much else to do and the partitioner will be hairy enough as it is
<siretart> Kamion: right. The bug would be about hiding the lvm volumes
* mdke tries to imagine what a hairy partitioner looks like
<siretart> filed as bug #32845
<Ubugtu> malone bug 32845 in espresso "Should hide LVM volumes" [Normal,Unconfirmed]  http://launchpad.net/bugs/32845
<Pygi> Kamion: k, thanks
<Kamion> mjg59: spiftacity binaries accepted, fyi
<ogra> ogra@edubuntu:/mnt/devel/bazaar/dapper$ ls -l /var/log/cups/*_log
<ogra> -rw-r--r-- 1 cupsys lpadmin 1449623 2006-02-25 16:51 /var/log/cups/access_log
<ogra> -rw-r--r-- 1 root   lpadmin 1048612 2006-02-25 15:24 /var/log/cups/error_log
<ogra> hmm, should the error_log be owned by root ? 
<Pygi> ogra: not really :)
<ogra> yes, thats why my crond thinks as well :)
<ogra> since i never ever touched cupsys on this machine, it must be a bug ...
<Pygi> ogra: ah, *reports, fixes, uses* :)
<triceratops> I just saw that fetchmailconf is only a script which points to '/usr/lib/python2.4/site-packages/fetchmailconf.py'. but this file don't exist. Is this a bug or is there a paket missing I have to install?
<sshrdp> hi
<sshrdp> I think it is better to add more description to the list of mailing-lists at http://lists.ubuntu.com so that users know the actual purpose of that mailing-list. 
<LaserJock> any TB members awake?
<ploum> Hello
<ploum> Treenaks, leuk moviegotchi
<LaserJock> hi ploum 
<ploum> I'm in my bed with the 770 from vuntz
#ubuntu-devel 2006-03-03
<j^> will ubuntu switch from firefox-dev to xulrunner for dapper+1?
<Burglaptop> j^: might. Would be nice
<Burglaptop> then we can ship epiphany and not FF
<j^> i dont want epiphany
<j^> i want ff
<dolson> ick
<Burglaptop> it is not about what any of us want, it is about what is a good default for users
<j^> and imho epiphany is not a good default
<j^> its firefox
<j^> ff has momentum
<Burglaptop> to be honest, users don't care and don't know. My company (Userful) sells FC4-based machines for public use (to libraries, etc.) and we ship Epiphany
<Burglaptop> never heard or had anything feedback that is negative
<j^> Burglaptop its about switching, not shiping firefox, you loose everybody that just switched to firefox and liked it.
<j^> but no need to repeat that enless thread from ubuntu-dev on irc 
<Burglaptop> http://mail.gnome.org/archives/epiphany-list/2005-October/msg00077.html
<dolson> I don't think that someone is going to install Linux and not know how to use Firefox
<Burglaptop> that is restricting your market
<Burglaptop> and what about those that get Ubuntu pre-installed for them?
<dolson> ?? a lot of Windows users are installing Firefox on their own now
<Burglaptop> 10% at most
<dolson> a browser is a browser is a browser
<Burglaptop> indeed, hence the arguement FOR epipahny
<dolson> if it just worked, then yeah, I'd agree
<Burglaptop> currently FF takes up about 1/2 of Diziet's time. That is huge for a relatively minor package. And that doesn't even include the security issues or the trademark ones...
<crimsun> getting off-topic, but epiphany uses ff anyhow.
<dolson> ok, you have convinced me. so why haven't we already switched to Epiphany for Dapper?
<Burglaptop> dolson: readup about xulrunner
<Burglaptop> currently you need to have a copy of either FF or Moz installed to get gecko
<Burglaptop> which is also needed for yelp and a few other packages
<Burglaptop> https://wiki.ubuntu.com/EpiphanyDefaultBrowser
<dolson> so people who have been using Ubuntu all this time will be thrown for a loop when the next version comes out and Firefox is gone
<Burglaptop> they would be able to install it, just like with Thunderbird now
<dolson> so we assume that users are too stupid to use Firefox but are smart enough to install it if it's suddenly changed on them?
<Burglaptop> it is not about relative intelligence
<Burglaptop> it is about good defaults
<Burglaptop> my company dogfoods, so we have all linux desktops
<Burglaptop> I am the only person who uses Linux at home. None of the six of us have any extensions installed
<dolson> I remember when I read about Epiphany becoming the new default, and so I installed it, and I used it for about an hour, and it continually crashed
<Burglaptop> that is a bug and I have never seen that
<dolson> it was on a relatively new Breezy install. I haven't tried it on Dapper yet, but I will.
<Burglaptop> basically, I have seen real Windows users using a Linux desktop for 6 months straight and seen where they curse and where they don't
<dolson> I may as well get started moving over my bookmarks and passwords and stuff now
<dolson> to be honest, I hate both browsers equally
<Burglaptop> I switch to epiphany full time about four months ago. I hated it at first but then discovered all the cool things (like better bookmark handling) and love it
<dolson> the last time I used it, it didn't have any icons on my bookmark panel.. does it have that now?
<dolson> I haven't used a good browser since the old Galeon 1.x series. And then it got screwed over when they bumped it up to 2.0 and then it seems to have been forgotten about
<HiddenWolf> dolson: the galeon developers are out of time, and porting galeon functionality as plugins to epiphany, basically merging the browsers
<dolson> that's good news
<HiddenWolf> Burglaptop: I have a similar story, It took me some time to get used to it, but I like epi a lot now.
<dolson> I haven't used Galeon for a long long time.. I think I was still using Mandrake when I last used it
<HiddenWolf> There are some things I sorely miss still, but I'll wait on the plugins. :)
<dolson> Firefox used to crash on me randomly, just like Epiphany did
<dolson> but 1.5 seems to not have had that issue (yet)
<Burglaptop> not being able to drag tabs in FF 1 sucked and the visuals for tab dragging in Epip "feel" more smooth
<dolson> another thing I remember about Epiphany was there seemed to be a lot of wasted screen space
<Burglaptop> never seen that
<Burglaptop> anyway *if* we switch, it will stir up a giant firestorm of controversy
<Burglaptop> we will probably lose users
<dolson> in Firefox I can move pretty much anything anywhere. like, I have the File Edit, etc menu, and on the same bar, I have the Address bar and google bar.. can you do that in Epiphany?
<Burglaptop> should be able to
<StevenK> Hang on, didn't we already punt mozilla to universe in Dapper?
<Burglaptop> StevenK: we did
<j^> Burglaptop so will we get users by switching to epiphany?
<Burglaptop> part of ReducingDuplication
<dolson> is that a wise idea then? risk losing users just for a browser?
<StevenK> Which means using xulrunner is pretty much moot, right?
<Burglaptop> StevenK: xulrunner != mozilla
<StevenK> I'm well aware of that
<Burglaptop> dolson, j^, we will provide a better user experience for the vast majority
<Burglaptop> the people we actually need to target, the average computer user
<j^> can i install the annodex plugin? (http://annodex.net/)
<Burglaptop> and in the end, it is not a pissing content about getting most users
<Burglaptop> j^: this is all hot air right now, so any questions like that are premature
<dolson> I know that, but why would you want to annoy existing users?
<dolson> part of the reason I switched from debian was that everything good to use was there by default, meaning gnome, gaim, firefox,etc
<Burglaptop> because I fell Epiphany provides a better out of the box experinece for users
<Burglaptop> s/fell/feel
<dolson> and then if someone wants to remove it and install firefox, it'll take ubuntu-desktop with it, right?
<Burglaptop> dolson: just like they would with evolution now
<Burglaptop> and -desktop is not important after install
<dolson> for upgrades it is. so we'll end up downloading a bunch of extra stuff just to delete it again and download yet more stuff
<StevenK> ubuntu-desktop can Depend on ephiphany | firefox
<dolson> is evolution being replaced too?
<StevenK> And you can educate aptitude to upgrade firefox and leave ephiphany uninstalled.
<Burglaptop> dolson: evolution will never be replaced by thunderbird
<StevenK> Besides, ephiphany is hard to type.
<Burglaptop> regardless, this is all hot air
<dolson> I didn't specify what it would be replaced by
<dolson> it's not an official gnome project, is it?
<Burglaptop> evo? yes it is
<dolson> ah, ok
<Burglaptop> since 2.8 I think
<dolson> so evo = kmail for gnome
<Burglaptop> yes
<dolson> alright, I didn't know it was adopted as their own
<dolson> I still don't like it. I use gmail only, so having evolution junk running in the background is useless to me
<dolson> but I think it's the better software
<Burglaptop> evolution-data-server != evolution
<Burglaptop> e-d-s is used by more than evo
<Burglaptop> http://live.gnome.org/TwoPointThirteen/Desktop
<dolson> yeah, I know
<Burglaptop> this is getting off-topic, so we should probably end it here
<dolson> It takes two hours for the calendar to open up while it searches for appointments when I click on the date in the gnome panel
<Burglaptop> again, file bugs, this is not the place to discuss such issues
<Burglaptop> upstream if you have a fix
<dolson> right, sorry.
<Burglaptop> np
<SEJeff> How do I get gdb to run a command with arguments to the command?
<StevenK> SEJeff: set args=''
<StevenK> Without the =, sorry.
<SEJeff> so something like, gdb /usr/bin/executable then set args '--sync' then run?
<StevenK> SEJeff: Yes
<SEJeff> thanks
<StevenK> SEJeff: And setting breaks and stuff before run if needed
<StevenK> doko: Er, it seems I didn't check hard enough, moinmoin-common Replaces and Conflicts moin.
<desrt> SEJeff; much easier way
<desrt> gdb --args /usr/bin/executable these are your arguments
<SEJeff> desrt, thanks, but xchat-gnome still dies and doesn't give gdb anything remotely useful
<desrt> then just (gdb) run
<desrt> not my problem :)
<desrt> try blowing away your config files
<SEJeff> It is a bug with xchat-gnome and the nvidia driver. says the server doesn't support the operation
<SEJeff> malone bug #31705
<Ubugtu> malone bug 31705 in xchat-gnome "Crash when turning on transparent" [Normal,Needs info]  http://launchpad.net/bugs/31705
<Kyral> kinda stupid question, but what Volume Manager is Dapper Current using (need to know so I can pass it to Thunar)
<crimsun> gnome-volume-manager
<crimsun> if you mean Ubuntu Dapper
<Kyral> I meant in general.At the low level.
<crimsun> meaning pmount, hal, and udev?
<Kyral> yah
* Kyral falls down
<Kyral> I didn't have libhal-storage-dev installed..thats why it wasn't picking up on it lol
<mdke> jpatrick, around?
<jpatrick> mdke: yes, sir
<mdke> jpatrick, ah cool. would you join #ubuntu-doc?
<jpatrick> there
<tenco> why is anacron and cron installed on ubuntu by default?
<Kamion> Riddell: FYI, there are some substantial changes in my espresso archive you'll want to keep up with; I've moved the copy and config stages to debconffilter, which involves adding a debconf_progress_region method to your frontend and changing all the stuff around progress_loop (or whatever your equivalent is)
<tuhl> hi all! where do I find a xen 3.0.1 kernel for ubunut?
<mdke> Kamion, do you think it might be desirable to include the ubuntu css that I've applied to the installation-guide online in the packages too? 
<Kamion> mdke: probably not, don't want to diverge where I don't have to
<mdke> Kamion, no problem, just thought I'd ask.
<Kamion> it looks good though
<mdke> Kamion, :)
<tuhl> hi! any help for activating the composite extension and Xorg-air?
<mjg59> tuhl: Not in here, no
<mjg59> tuhl: #ubuntu is a better bet
<tseng> mjg59: could you hit me with a clue about my multimedia keys
<tseng> mjg59: volume down has stopped sending a keypress event (dell 600m)
<tseng> volume up, rather
<mjg59> tseng: Uhm.
<mjg59> tseng: Nothing shows up if you hit it on the console while running showkeys ?
<tseng> hm i was using xev
<tseng> mjg59: nope, nothing on showkey either
<tseng> only for vol down and mute
<mjg59> tseng: Sounds like a hardware problem
<mjg59> I'm fairly sure we haven't changed anything that would touch that
<tseng> ok.
<mjg59> tseng: Test under a Breezy livecd?
<tseng> sure
* tseng wonders if kubuntu team is working on Kerry
<Lathiat> kerry?
<tseng> http://www.kdedevelopers.org/node/1820
<Lathiat> ah, knew i'd seen it somewhere
<jpatrick> not me
<pitti> hi ogra 
<ogra> hey pitti 
<ogra> pitti, would you mind taking a look at http://people.ubuntu.com/~ogra/esd.patch if you find time ?
<pitti> ogra: I can't judge whether it works, but it looks innocent enough
<pitti> ogra: but isn't ESPEAKER already checked in a different place?
<ogra> oki :)
<pitti> ogra: I faintly remember that we already applied a similar patch in the past
<ogra> might be, i just need to aviod the clashing filenames for the sockets
<pitti> ogra: ah, right, that patch is just for determining the socket name
<ogra> you applied the getuid change: sprintf (dirname, "/tmp/.esd%s-%i", audiodev, getuid());
<ogra> but that doesnt help if you run with the same user several times :)
<pitti> yes, I wasn't aware where that patch actually applied (socket, not output device)
<pitti> yes, looks reasonable then
<pitti> ogra: be aware that it'll break with third-party apps
<ogra> are there apps accessing the socket directly apart from esd ?
<pitti> ogra: i. e. commercial apps which don't use our libesd, but just look for /tmp/.esd
<pitti> ogra: but we never particularly worried about these :)
<ogra> but that will break already through the getuid change ;)
<Treenaks> Argh! The logout dialog somehow triggers my mind into thinking 'Touch screen!'
<pitti> right
<ogra> i'm just setting audiodev ...
* Treenaks now has smudges on his LCD
* pitti hands Treenaks a towel
<Treenaks> must be because they look like the (touch screen) train ticket machines here in .nl
<Treenaks> pitti: thanks :)
<ogra> perhaps we should make the buttons bigger :)
<Treenaks> ogra: sure, make them full-screen#
<Treenaks> ogra: saves you having to code the fade-effect too ;)
<ogra> yeah :)
<Treenaks> ogra: did you see the new moviegotchis I caught at FOSDEM? :)
<ogra> nah, url ?
<Treenaks> ogra: foodfight.org/movies/Ubuntu%20Fanpeople
<Treenaks> (ross, daniels, ploum and sladen x2)
<Treenaks> and: the movies work GREAT in dapper + totem-gstreamer + firefox
<Treenaks> all sync problems, etc. have magically gone away, it seems
<Treenaks> \o/ gstreamer people
<tseng> Treenaks: they really do work great
<Treenaks> yeah, I think gst 0.10 rocks :)
<Riddell> Kamion: ok, will look at that tomorrow
<Riddell> tseng: no
<sivang> Treenaks: have you been able to make emacs work under xgl?
<sivang> (or anyone elase know if Kinnison solved ths issue and/or how?)
<_lemsx1_> hello all
<jpatrick> hello _lemsx1_ 
<_lemsx1_> is there a way that somebody can apply this patch to the ubuntu artwiz-cursor/xfonts package? this is an old bug with a patch
<_lemsx1_> https://launchpad.net/distros/ubuntu/+source/xfonts-artwiz/+bug/3255
<Ubugtu> malone bug 3255 in xfonts-artwiz "fonts install in non-standard directory" [Normal,Unconfirmed]  
<_lemsx1_> jpatrick: hello
<_lemsx1_> i started fixing just that same bug and then found it in malone... next time i'll look first ;-)
<simira> what package do I meld a bug on when I don't get the external monitor working for my laptop?
<jpatrick> xorg?
<simira> possibly
<Kamion> _lemsx1_: I'll have a quick look now
<Kamion> ugh, what possessed the reporter to patch version 1.3 anyway
<Kamion> ah, epoch, never mind me
<_lemsx1_> Kamion: thanks. because i'm trying to apply the patch and it's giving me problems
<Kamion> that use of update-alternatives is evil
<Kamion> tempted to drop that bit of the patch until somebody sorts it out properly
<_lemsx1_> Kamion: the idea is the dpkg-divert should be done in /usr/share/X11/fonts/misc
<_lemsx1_> Kamion: dpkg-divert --package artwiz-cursor --remove --rename --divert \
<_lemsx1_> 		/usr/share/X11/fonts/misc/cursor.pcf.gz-artwiz \
<_lemsx1_> 		/usr/share/X11/fonts/misc/cursor.pcf.gz
<_lemsx1_> sorry for the paste
<_lemsx1_> you get the idea
<Kamion> dpkg-divert != update-alternatives; I'm not talking about dpkg-divert
<Kamion> I understand the code
<_lemsx1_> then an artwiz-cursor.theme needs to be created
<Kamion> but using update-alternatives --set / update-alternatives --auto is fundamentally wrong
<_lemsx1_> ok, update-alternative needs to install a link for x-cursor-theme to some real .theme file (since the core.theme is not part of Ubuntu's Xorg package)
<_lemsx1_> Kamion: i agree. i didn't see that --auto stuff
<_lemsx1_> Kamion: i almost had my package done before i saw this
<_lemsx1_> Kamion: and i was taking a similar approach
<_lemsx1_> Kamion: ok, i just diff the dpkg-source -x (extract) of the original package as is in ubuntu now (dapper)
<_lemsx1_> Kamion: against the stuff i had done so far... can i give you this patch?
<Kamion> use debdiff, attach to bug
<Kamion> not sure even *more* big monolithic patches will actually help though :)
* Kamion -> dinner
<_lemsx1_> Kamion: this is a small patch
<Kamion> is it a subset of Seth's?
<_lemsx1_> Kamion: exactly
<Kamion> no need then
<_lemsx1_> Kamion: ok
<Kamion> I just went through Seth's patch and trimmed it down a bit
<Kamion> I'll upload once I've tested it
<_lemsx1_> Kamion: thanks
<_lemsx1_> Kamion: i'll stop this none sense here then ;-) put my efforts somewhere else
<jpatrick> there's a 0.4.2pre2 verison of gpac in multiverse that can't build because of dep problems however malone #32362 fixes it, if I upload will it be considered as NEW?
<Ubugtu> malone bug 32362 in gpac "Unmet dependency" [Normal,In progress]  http://launchpad.net/bugs/32362
<setuid> doh
<setuid> Weak references are not implemented in the version of perl at /usr/lib/perl5/AptPkg/hash.pm line 8
<setuid> BEGIN failed--compilation aborted at /usr/lib/perl5/AptPkg/hash.pm line 8.
<setuid> wow, apt-file is broken 
<setuid> Server file no newer than local file `/var/cache/apt/Contents-i386.gz' -- not retrieving.
<setuid> # ls -l /var/cache/apt/Contents-i386.gz
<setuid> dolson: /var/cache/apt/Contents-i386.gz: No such file or directory
<setuid> s/dolson/ls:/
<setuid> How do I know which package a specific file is in? 
<setuid> (normally, I'd use dlocate or apt-file, but they're both broken in dapper) 
<dolson> auto-apt search file
<glatzor> setuid: dpkg -S FILE
<Seveas> setuid, maybe the server has no Contents-i386.gz at all 
<sivang> anybody here uses emacs and has tab completion enabled / working / know how to set it up?
<Kamion>       gpac |  0.2.0-0.0 | dapper/multiverse | amd64, i386, powerpc
<Kamion>       gpac | 0.4.0+rc2-0.0 | dapper/multiverse | source
<Kamion> jpatrick: no, won't be NEW unless it creates new binaries
<Kamion> as in, binaries whose names are new to dapper
<jpatrick> Kamion: I figured that out and uploaded
<Kamion> Seveas: it has Contents-*, but it hasn't been generated since January 19
<Kamion> I assume that was just rsynced over from the katie-based archive
<Kamion> yeah, same timestamps
<desrt> where did the nice logout dialog go?
<tsdgeos> are fixes for dapper accepted or is it already frozen?
<simira> I think it is still accepted
<xxenon> hmm, I installed gstreamer0.10-plugins-ugly as documented, but I still get no mp3 support in xine. Any clue ?
<desrt> xxenon; you're seriously in the wrong channel
<desrt> xxenon; you mean to ask that in #ubuntu
<xxenon> ok ..
<xxenon> well, Im testing flight 4
<desrt> see topic:  Ubuntu Development (not support, even with dapper)
<tsdgeos> does aspell-ca has a mantainer? do you need one? I filed a bug against it but don't know if there's anyone that can do the work, if not i'd be willing to take the job
<desrt> seb128; i know you're lurking
<ploum> hello
<ploum> Hi JanC 
<ploum> I didn't see you at FOSDEM
<JanC> hi ploum, you did see mee 
<ploum> Arf !
<ploum> Have you said that you was JanC ?
<ploum> or just your real name ?
<JanC> I introduced myself as Jan Claeys
<ploum> OKI !
<ploum> I didn't make the link
<ploum> (altought it was obious)
<ploum> sorrrryyyy !
<ploum> (I've meet so many people)
<JanC> no problem
<ploum> I remember :-)
<JanC> jdub already created a list?  ;-)
<ploum> he will do tonight !
<JanC> great
<ploum> Have you seen his final talk ?
<ploum> JanC it was really great to see so much people for ubuntu-be !
<JanC> yeah, and I hope the video of jeff's talk will be released
<ploum> awesome, awesome
<JanC> (someone was filming it I saw)
<ploum> cool :-)
<ploum> I didn't hear much feedback from nederlandstaligen after the ubuntu-be meeting
<JanC> there weren't that many there I guess, but those that were are really interested
<JanC> and some others are interested too  
<ploum> cool :-)
<JanC> some of the people that I know are interested were at other talks or even helping out with the organisation
<ploum> I understand
<ploum> But it's cool they are interested
<JanC> also some people didn't come to fosdem--not everybody is a geek! ;-)
<ploum> the only bad point is the bad guy who was late and who was always joking during my speech
<ploum> (follow my eyes)
<JanC> hehe  :P
<ploum> Someone started a forum to discuss about ubuntu-be between us. I'm not sure it's a good idea but it exists : http://www.carolinux.be/
<ploum> you have to register
<JanC> I don't really like web forums  ;-)
<JanC> ploum: do you know the people who registered ubuntu-linux.be or ubuntulinux.be ?
<JanC> to me it seems like they only try to profit from ubuntu's popularity  :-(
<JanC> hm ubuntu-linux.be is now redirected to a webmail
<JanC> but www.ubuntulinux.be still redirects to a company website that doesn't even mention ubuntu...
#ubuntu-devel 2006-03-04
<LaserJock> any TB members awake? When will the next TB meeting be?
<Burglaptop> LaserJock: TB requires Mark and other busy developers, likely a while now
<LaserJock> Burglaptop: are they going to announce the day/time ahead of time?
<Burglaptop> LaserJock: one assumes so
<LaserJock> Burglaptop: hmm, well that is frustrating. I'll just keep checking the wiki and fridge then :-)
<Burglaptop> LaserJock: mark is currently in Asia and the development team has just been rushing to FF, so I suspect that taking some time off for a TB meeting has kind of fallen to the side
<LaserJock> hmm, it's just that I'm on the agenda and I trying to schedule it :(
<pitti> Good morning
<ajmitch_> morning pitti 
<Burglaptop> salut ajmitch_, pitti
<fabbione> morning guys
<pitti> hi Burglaptop 
<ajmitch_> hi fabbione, Burglaptop 
<Burglaptop> damn, this is best twisting of SABDFL yet: SABDFL, Self Admiring, Buys Debian For Loosechange
<marcin`> Burglaptop: cool but not true unfortunately
<Burglaptop> mako_ !
<ajmitch_> hey mako
<mako> Burglaptop, ajmitch_: hi guys
<mako> Burglaptop: i got the intro and the appendix in
<mako> Burglaptop: yesterday
<Burglaptop> mako: ahead of me then. I gave up fighting with OO.o in dapper yesterday
<Burglaptop> will try it on my work Fedora machine
<mako> Burglaptop: oh my god, tell me about it
<mako> Burglaptop: it's bad enough when it works fine
<mako> Burglaptop: i tried with oo1.1 and nearly died of frustration.. oo2 was bad but possible
<Burglaptop> oo.o may be the one application that drives certain people in my office to windows
<mako> Burglaptop: my laptop is breezy :)
<mako> for just these sorts of occations
<Burglaptop> I need to test flight 4, but am waiting for later this week, cause I can't afford to have it mess up at this time
<mako> well, i'm off for the night
<mako> g'night
<dholbach> good morning
<TheMuso> /c/
<TheMuso> Morning dholbach 
<dholbach> hey TheMuso!
<pitti> hi freeflying
<Burglaptop> dholbach: aren't random and useless threads  on -devel fun?'
<ajmitch_> Burglaptop: NO!
<dholbach> Burglaptop: if you ask me like that, NO
<Burglaptop> lol
* Burglaptop goes to kill the init-ng/launchd/smf thread
* ajmitch_ goes offline for the night
<freeflying> hi pitti 
<freeflying> pitti: dose language-pack-zh depend on im-switch now ?
<pitti> freeflying: Depends: mozilla-firefox-locale-zh-cn, mozilla-firefox-locale-zh-tw, openoffice.org2-l10n-zh-cn, openoffice.org2-l10n-zh-tw, openoffice.org2-help-zh-cn, openoffice.org2-help-zh-tw, scim-chewing, scim-pinyin, scim-tables-zh
<pitti> freeflying: I can add the dependency explicitly if it doesn't make sense to add it to the scim modules directly
<freeflying> pitti: I'd prefer to add to the language-pack than scim 
<pitti> freeflying: (it's language-support-zh btw, not -pack)
<freeflying> pitti: y
<pitti> freeflying: ok, I'll do that then
<freeflying> pitti: how can we setup IM variable ?
<pitti> freeflying: what's that, an environment variable?
<freeflying> pitti: ya
<pitti> freeflying: not at all in general
<freeflying> pitti: may those be added by postinstall of language-pack-zh/ko/ja
<pitti> we can for new user accounts, but not for existing ones
<freeflying> then only CJK or any other language user need scim can have those variable set up
<pitti> what does it say?
<pitti> i. e. what does the variable control?
<freeflying> pitti: like XMODIFIERS  GTK_IM_MODULE  QT_IM_MODULE
<pitti> freeflying: hm, that still doesn't make sense to me
<pitti> freeflying: I don't know about scim very well, but if we can figure out the value of these variables automatically, then why do we need them at all?
<pitti> freeflying: can't scim just deduce the necessary values from the current locale?
<pitti> freeflying: also, we don't want scim for all locales
<freeflying> pitti: scim an not set up those variable , so we need add them 
<pitti> freeflying: we can make it to :)
<pitti> hm, which program actually evaluates XMODIFIERS?
<pitti> and GTK_IM_MODULE?
<freeflying> I think let language-pach-zh/ja/ko add those , it will be a better choice than anyothers
<pitti> XMODIFIERS -> does xorg itself need that?
<pitti> freeflying: well, add where?
<freeflying> pitti: add to /etc/X11/Xsession.d  
<pitti> hmm
<pitti> as I already said, the language-support packages currently can't do that
<pitti> they can be made to, of course
<pitti> but it needs some work
<freeflying> pitti: :)
<pitti> and it would still seem more logical to use the locale setting for that
<freeflying> pitti: if you agree on that , then we just need wait
<pitti> well, I still don't see the point of statically adding a fixed variable value
<pitti> it just feels so utterly useless
<pitti> and as soon as you would install more than one support package, they would even conflict
<freeflying> or we'd look for other measure 
<fabbione> Migrating old dbus init symlinks to runlevel 12 ...
<fabbione> ???
<fabbione> runlevel 12???
<pitti> freeflying:  i. e. you'd get the asciibetically last language instead of the one you actually want
<pitti> fabbione: well, priority :)
<pitti> fabbione: I need to merge current dbus from Debian to get some bug fixes anyway
<pitti> fabbione: I'll fix that when I do that, too
<fabbione> ok thanks :)
<freeflying> pitti: the scim/skim will be in ubuntu/kubntu'cd defautly ?
<pitti> freeflying: yes
<pitti> freeflying: and the modules will be pulled in in l-support-*
<pitti> freeflying: i. e. users will get it automatically (if they agree to download language support)
<freeflying> pitti: y,but how to make scim/skim work automatically ? that what I wanna solve 
<pitti> freeflying: right, I see
<pitti> freeflying: well, they worked OOTB for me, but apparently not for others
<pitti> freeflying: I thought im-switch did the selection automatically?
<freeflying> pitti: maybe we'd use im-swich setup what we wanna according to locales
<pitti> freeflying: that's what I would consider the most straightforward and integrated solution
<pitti> freeflying: it doesn't do this already?
<pitti> freeflying: I thought this was the main point of the package
<freeflying> pitti: still need work on im-switch and scim too
<pitti> sjoerd: can I get your hal 0.5.7 orig.tar.gz from somewhere? I'd like to use the same one for ubuntu
<Burglaptop> Kinnison: darling, you there?
<seb128> desrt, Burglaptop: thanks for the rant on the panel, nothing like that to start the week :p
<Burglaptop> seb128: it was not a rant
<seb128> Burglaptop: it really pisses me, that has been discussed n times and I'm against the hammer and the wall which is really not funny
<Burglaptop> seb128: a rant would look like this "j00 loosers made my panel stoopid, loolz. I want to get my old dialog back, etc.)
<seb128> Burglaptop: Mark is decided on that, so I've just to read people ranting
<seb128> that's quite what the bug is in fact
<Burglaptop> seb128: the decision at UBZ was made without seeing what upstream has done in this cycle
<seb128> I've mailed Mark since, without screenshot of what has been done, etc
<Burglaptop> had the current upstream logout/shutdown dialogues existed at UBZ, I would not have supported the change
<seb128> he doesn't like upstream stuff and he decided to go with that dialog
<Burglaptop> seb128: I just cc'ed mark on the bug
<seb128> that's not going to work, but feel free
<Burglaptop> mark has to have his one foolish decision per cycle I guess :)
<seb128> note that the icons are a moo point
<seb128> they are going to be changed before dapper
<Burglaptop> by march 9th?
<seb128> yep
<seb128> with the new icon theme probably
<Burglaptop> still doesn't solve point 1 and 2
<seb128> there is some icons which are going to be make by disagners if I got it correctly
<seb128> point 1 beeing "the cancel button looks like a buttons", a good
<seb128> I though it was looking like a IRC window :p
<seb128> the icons change on mouseover, which is better looking that having a border around every icon by default imho
<Burglaptop> seb128: no it is not
<Burglaptop> unless people actually mouse over, they will not realize it is a bug
<Burglaptop> s/bug/button
<Burglaptop> and *no* other button anywhere in gnome/kde does that
<seb128> for the 2 rows, we have been trying to argue with Mark at UBZ and since that we should have 2 dialogs like window, he'll not heard about it
<seb128> nothing I can do
<Burglaptop> seb128: mostly the dialog "feels" wrong. It is hard to quantify
<seb128> it feels really right to Mark ... :)
<seb128> according to the comment he sent during the cycle by mail
<ploum> hello
<seb128> hi ploum
<Burglaptop> salut ploum
<Burglaptop> anyway, I have to sleep
<seb128> Burglaptop: if you don't know that yet it's likely that you will learn that moving Mark from his position when he's decided is not something easy
<ploum> seb128, we talked about you yesterday night !
<ploum> Good night..
<seb128> at fosdem? :)
<ploum> yes
<ploum> Jeff was explaining the wonderful SEBuild system
<ploum> :-)
<ploum> We have talked about Epiphany as default browser in a pub and the table juste behind us was occupied by the Firefox team :-D
<ploum> it was really fun
<ploum> Jeff's talk was awesome !
<Treenaks> ploum: so is your video :P
<ploum> awesome, awesome !  (say it with an australian accent)
<ploum> Treenaks, hem... I've learned with that video that my mother read planet.ubuntu....
<ploum> hem
<seb128> Jeff talks are always great :)
<Treenaks> ploum: LOL
<sjoerd> pitti: http://beast.luon.net/~sjoerd/hal_0.5.7.orig.tar.gz
<pitti> sjoerd: thank you
<ploum> I think that Jeff has something that I can't have, even with really hard work
<ploum> Treenaks, you have to send me a picture of you. You NEED an hackergotchi !
<sjoerd> pitti: dbus qt stuff failing sucked up my time friday, that's why hal in debian isn't updated yet :(.. 
<ploum> seb128, I hope to see you in real life too !
<ploum> :-)
<ploum> Jeff promises to make ubuntu-be list yesterday...
<ploum> ..but with belgian beer it can be "ubuntu-qsdfg" or anything...
<ploum> I'm worried
<seb128> :)
<ploum> So, I unfortunatly have a lot of ironing to do...
<ploum> Have a good day all
<zakame> hello all
<jdub> boh, missed ploum
* jdub makes list during hangover instead of when drunk - safer that way :)
<Keybuk> seb128: yesterday I was trying to burn an Audio CD with serpentine, and it SEGV'd every time I clicked "Write to Disc"
<Keybuk> I tried with just a single ogg file, and it crashed then too
<seb128> Keybuk: package welcome :)
<seb128> ups
<seb128> backtrace
* seb128 wakes up
<seb128> Keybuk: I think that might be to some gst0.8 package interfering
<Keybuk> seb128: you'll have to wait a week for one of those, it was an "as I was going out of the door" thing
<Keybuk> but it was every damned time
<Keybuk> could be, I still have 0.8 installed -- can I purge that?
<simira> Keybuk :) Freezing yet?
<seb128> yep you can
<seb128> hey jdub :)
<jdub> morning sebuild ;)
* jdub has to build flumotion against 0.20
<jdub> er 0.10
<jsgotangco> awesome
<Keybuk> I used k3b in the end, and gods that is a terrible program
<fabbione> pitti:      + Build mono bindings as arch indep.
* jsgotangco just deployed a test flumotion server a week ago
<Keybuk> and just as I thought it couldn't get any worse, it played the most stupid wav file to tell me the burning was finished
<Keybuk> I nearly died
<fabbione> meh.. that's going to screw arches with no mono?
<Keybuk> fortunately I was trying to explain the difference between GNOME and KDE at the time
<Keybuk> and that did it quite neatly
<pitti> fabbione: we have this for a while, and Debian adopted it
<StevenK> "See, KDE looks and acts like crap."
<fabbione> pitti: ok :)
<pitti> fabbione: true, the packages won't be too useful there
<fabbione> ok
<jdub> jsgotangco: cool!
<janimo> seb128, a heads-up: I'll upload an evince-gtk package these days and conflicts/replace will be needed with evince. If you don't have other evincep kg changes pending I'll put a patch in LP ok?
<seb128> janimo: how does that affect evince?
<seb128> evince-gtk is going to be universe?
<janimo> seb128, uses the same common files
<janimo> no hopefully in main as it is part of xubuntu
<janimo> ideally it would be a patch in evince/debian/patches but hey
<seb128> no way
<janimo> oh, no ideally it would be upstream
<seb128> I will not change evince for that, we already talked about it
<janimo> seb128, I know I don't expect you to do what is ideal for me ;)
<seb128> anyway if pitti is happy about duplication
<janimo> so you'll just need the conf/repl on evince-gtk binary and you're all set
<janimo> I am sure nobody is ahppy about duplication
<seb128> and as far we don't get the real evince package flooded by your custom hacks on it
<janimo> but I am not happy about gnome depends
<pitti> it would be better to build a -gtk and a -gnome package from the same source
<pitti> janimo: you could use xpdf :)
<mvo> can't it be made a configure thing in the source? or can't it be seperated cleanly?
<janimo> pitti, no way :)
<seb128> pitti: I'm not going to cripple evince and create maintainship work for me at every upstream change no, that's a some hundred lines of code change and I don't want to spend hours updating it when upstream roll a new tarball
<janimo> I have a patch wich add ifdef gnomes and --disable-gnome in configure so it is clean
<pitti> janimo: anyway, evince itself is no big threat; so oh well...
<seb128> mvo: that's a custom patch, that's not trivial work to follow upstream changes probably
<pitti> seb128: I didn't intend you to :)
<janimo> seb128, you're blowing this way out of proportion but anyway
<pitti> seb128: I mean that upstream shuold offer a configure switch, then we can do multibuild
<janimo> I am prtty sure other gnome bits have more ubuntu patches against upstream
<seb128> janimo: I've already too much work, I'm not subscribing for extra tasks when I don't need to :)
<mvo> seb128: sure, but having the gnome bits seperated clean and with a configure option, it would probably increase the chances of upstream acceptance
<seb128> janimo: yeah, and I know too well that's creating update work
<janimo> seb128, I would have taken the extra work or even full evince work instead from you :)
<mvo> janimo: how big is the patch?
<janimo> mvo, 1000 line diff
<seb128> janimo: so I would have to wait on you to update to the new versions and that would slow us down
<seb128> updating evince is 10min of work
<janimo> seb128, I am updating against CVS quite often
<janimo> and besides it would only affect the build of the -gtk package if the diff b0rked right?
<seb128> no, if -gtk doesn't build the source package doesn't build
<seb128> so if you are in VAC 2 weeks and a no package cames?
<mvo> well, you could disable the -gtk package then until it get fixed by someone else ...
<janimo> seb128, ok.
<seb128> I either have to wait for you, to update the patch myself, or to drop -gtk
<janimo> well drop gtk then in that case
<janimo> anyway I probably have the patch updated by the time a release comes
<seb128> mvo: if we are going to drop and put -gtk again, I like as well having a separate source package
<janimo> I assume you do not package CVS snapshots
<jdub> whoa, we totally need the firefox open dialogue back
<seb128> janimo: I do sometime, depending of the bugs fixed and how upstream is reactive to roll new tarballs
<janimo> seb128, not quite, a new source package is different in the pool
<seb128> jdub: it breaks epiphany :/
<jdub> seb128: the removal?
* Keybuk giggles as a notification popup misses the icon
<Keybuk> apparently I need to click "tomboy" to restart my computer :p
<seb128> jdub: yep, do "do you want to open ... save" dialog
<janimo> seb128, pitti whatever is good for you, I just want evince-gtk in the archive ;)
<seb128> jdub: and it puts everything to /tmp
<Treenaks> Keybuk: well, do it! :)
<mvo> seb128: I was thinking about it from a "maintain in stable" perspective, but I guess that point is moot anyway because usually it's libpoppler that needs updating (e..g security) and not evince*. so I shut up now :)
<jdub> seb128: erk!
<janimo> mvo, sorry I did not get around to gconf/ini in update-manager
<seb128> jdub: it breaks everything using gecko in fact
<janimo> yet
<mvo> janimo: the window hasn't yet totally closed :)
<mvo> Keybuk: hrm, no icon from notification-daemon? 
<seb128> jdub: https://launchpad.net/distros/ubuntu/+source/firefox/+bug/32934
<Ubugtu> malone bug 32934 in firefox "auto-download breaks embedders" [Normal,Confirmed]  
<seb128> mvo: you want to stop using gconf?
<Keybuk> mvo: yeah, but it lept to the left after the window popped up
<janimo> seb128, either that or gnome-python needs splitting
<Keybuk> one of the panel applets must have got wider
<Keybuk> probably the clock or weather applet
* jdub is watching french tv
* Keybuk mutters about non-constant-width applets
<janimo> seb128, update-manager pulls in whole gnome libs too just bec of gconf
<seb128> right
<mvo> seb128: only if janimo provides a clean patch for it. the idea is that update manager can than be used in xubuntu as well
<janimo> it's not right ;)
<seb128> but we should not start crippling Ubuntu because some derivative can't stand GNOME
<janimo> seb128, I was just thinking that you'll say something with 'crippling' in it
<jdub> seb128: can we get gimp-svg into dektop seed?
<janimo> seb128, update-manager should be an ubuntu updater not a gnome one, please stop being such a bigot :)
<seb128> jdub: fine with me, but you should ask to mdz or Kamion, I'm not deciding of that :)
<seb128> janimo: please don't call be a bigot
<mvo> seb128: this is really a minor change, it's about storing ~10 conf options
<seb128> janimo: I didn't insult you
<janimo> seb128, excuse-moi I had a smiley too in there just in case
<seb128> mvo: right, but should I move nautilus away from gconf next? :p
<janimo> seb128, no need to xubuuntu won't use nautilus
<Lathiat> no they have thunar :)
<seb128> mvo: we can port the whole GNOME using ini format if you take it that way
<seb128> janimo: there is not only xubuntu :)
<janimo> seb128, please stop exagerrating
<jdub> mvo: we shouldn't *remove* gconf support from it, or we'll lose the administrative features
<janimo> I only want the places which are not obviously gnome to not depend on it
<seb128> janimo: I would rather see mvo fixing Ubuntu bugs than spending efforts moving away from GNOME to please derivates to be honest
<janimo> seb128, realize that gconf and gnome-client small as they are  usually are enough for apps to be rewrtittem from scracth for kde or whatever just because they pull in
<janimo> the whole gnome stack
<janimo> hwdb-client,upadte,rlanguage-selector etc
<seb128> KDE will not use GTK apps for its desktop anyway
<janimo> these could all be written in pure gtk and than a qt version would foloow
<janimo> but because of a tiny libe they're written from scratch
<jdub> there are good reasons why we need to use gconf
<janimo> same with g-s-s gnome-mount g-p-m
<Lathiat> can you fix gconf not to pull in the entire gnome stack?
<janimo> the functionality added by gnome libs is minimal but just enough to keep the desktops reimplementing all of it
<janimo> seb128, right mvo will fix bugs that's why I said I'll write the ini file patch
<mvo> jdub: right
<dholbach> Lathiat: liborbit2-dev, libxml2-dev,libgtk2.0-dev is not what I'd call entire gnome stack
<jdub> Lathiat: gconf is not the problem
<doko> pitti: which one is a working kurdish locale?
<janimo> Lathiat, gconf bu itself does not pull gnome in , just the pythoin=-gnome bindings
<Lathiat> janimo: ah
<sivang> morning all!
<janimo> similarly gnomecanvas-python -> all gnome libs
<Lathiat> that seems to be a common problem with the python gnome stuff
<Lathiat> and related bits
<Lathiat> like dbus needing glib main loop which was actually in gtk which would importerror if DISPLAY wasn't set
<sivang> Kamion: do you recall the culmus patch I've sent you? what do we need to do in order to backport it to breezy? (same issue, same fix)
<jdub> janimo: if it were to be done,m it would have to be a rebuild or something like that - we can't sacrifice gconf in general
<janimo> seb128, really tying stuff to gnome only is not helping the fd.o goal
<Lathiat>  uh all, he said fd.o :)
<Kamion> sivang: uh, I thought the old font location was just fine for breezy
<seb128_> re
<pitti> doko: ku_TR.UTF-8 is supposed to work
<seb128_> sorry got disconnected
<seb128_> <janimo> the functionality added by gnome libs is minimal but just enough to keep the desktops reimplementing all of it
<seb128_> <seb128> mvo: if you move away from gconf, makes sure derivatives have a way to set different default values and that mandatory values are possible too
<seb128_> <seb128> differents values without changing the package
<Kamion> otherwise we'd have been fixing these issues like mad in breezy rather than fixing them like mad in dapper, surely?
<seb128_> <seb128> (like gconf.defaults stuff we have)
<janimo> jdub, for update-manager you mean? I asked mvo and he said he just uses it for somehting ini files would do no fancy notification stuff or such
<seb128_>  JanC JaneW janimo
<seb128_> <seb128> Lathiat: no, gconf triggers orbit2 and libxml2 basically
<sivang> Kamion: appears not, already seen on that on 2 boxes near me..
<sivang> Kamion: let me recheck just to make sure.
<Lathiat> seb128_: right, the problem is
<Lathiat> 18:12 < janimo> Lathiat, gconf bu itself does not pull gnome in , just the pythoin=-gnome bindings
<Kamion> sivang: otherwise, you'll have to talk to the backports people; they have a mailing list
<jdub> janimo: not using gconf means we lose administrative benefits
<seb128_> Lathiat: so the solution is to split python stuff, not to cripple the app
<jdub> janimo: it would be better to split out python-gconf
<Kamion> sivang: but
<seb128_> and the default value setting too
<Lathiat> seb128_: as we're discovering
<Kamion> sivang: if it's broken, then breezy-updates would be more appropriate than breezy-backports, probably
<janimo> jdub, yes that would be better but seb said users don;t care about it
<jdub> janimo: yes they do
<jdub> janimo: you don't, but users do
<janimo> jdub, tell seb :)
<seb128_> I didn't say they don't care
<Kamion> (-backports => shiny, -updates => didn't-work-before, basically)
<seb128_> I said it's not a priority
<janimo> jdub, I mean the splitting not gconf
<mvo> janimo: jdub raised a important point about the adminitstative stuff, I think it's better to try to make python-gnome split out gconf
<jdub> janimo: i don't think splitting is relevant to users whether it's done or not
<janimo> jdub, mvo I agree
<janimo> so please tell  seb128 that having granular python-gnome bindings is good :)
<jdub> it may provide a solution to this problem
<seb128_> janimo: stop speaking like I was not here
<janimo> and for hwdb-client
<janimo> seb128, I did not want to highlight you
<jdub> splitting python-gobject helped for flumotion - it's probably better to talk to upstream about this problem
<seb128_> janimo: if you mention my nickname you highlight me anyway
<sivang> Kamion: oops, right. I need a breezy-update then. same issue, same remedy :-)
<janimo> I toiught only seb128 not seb is you nick.oko
* jdub woiuldn 't mind if the python bindings were maintained in their parent library sources ;)
<sivang> (I just verified)
<Kamion> janimo: (you mentioned his whole nick, not just "seb")
<janimo> ok, then my fault
<sivang> Kamion: (I dislexitivy switched them in my mind)
<Kamion> sivang: ok, but I don't have time at the moment sorry, maybe somebody else does
<Kamion> man, I really wish soyuz told me which freaking binary packages were new
<Kamion> sooooooooo painful to process evolution-data-server otherwise
<sivang> Kamion: okay, thanks.
<seb128_> Kamion: evolution-data-server-dbg :)
<Kamion> seb128_: (no offence but I like to check myself anyway in case of accidents)
<Kamion> but thanks
<seb128_> np, it was in case it's useful
<Kamion> only built on amd64 and i386?
<seb128_> I stopped trying to look on build logs to be honest
<seb128_> tracking every single package build log on launchpad is not funny
* seb128_ has a look
<Kamion> no argument there, although it wasn't like it was easy before :(
<Kamion> seb128_: please add evolution-data-server-dbg to the supported seed
<seb128_> the daily page was useful
<pitti> Kamion: ogra's build log page was pretty nice
<seb128_> k, will do that now
<Kamion> pitti: fair point, I never used that
<seb128_> I was looking on the daily pages before, that was giving an idea of what was building or not
<seb128_> " Timeout error
<seb128_> Sorry, Launchpad took too long to process your request. "
<seb128_> bah :)
<pitti> seb128_: Monday morning dizzyness :-P
<seb128_> #   dapper powerpc   Dependency wait
<seb128_> # dapper ia64 Dependency wait 
<seb128_> Kamion: 
<seb128_>   libgnomeui-dev: Depends: libgnomeui-0 (= 2.13.3-0ubuntu1) but it is not going to be installed
<seb128_>                   Depends: libbonoboui2-dev (>= 2.8.1-2) but it is not going to be installed
<seb128_> dunno what is the issue exactly
<Kamion> jdub: speaking of which, ubuntu-artwork 1 failed to build: http://librarian.launchpad.net/1583720/buildlog_ubuntu-dapper-i386.ubuntu-artwork_1_FAILEDTOBUILD.txt.gz
<seb128_> maybe a retry would go fine
<Kamion> ah, ok, infinity will need to look at that then
<fabbione> seb128: it's because new gnome-vfs2 is in and chroots need updates
<Kamion> jdub: (I've rejected ubuntu-artwork 0.2.29-1 binaries)
<fabbione> + some libs need to be rebuilded in order
<seb128> fabbione: gnutls stuff?
<fabbione> seb128: gnome-vfs2 ?
<seb128> yep
<fabbione> dunno the changes there
<seb128> k, you were saying that like there is a known issue with gnome-vfs2
* fabbione explains again
<fabbione> gnome-vfs2 has been NEW'ed
<fabbione> the libgnome-vfs2-common changed from arch: any to arch: all
<fabbione> if the chroots are not updated
<fabbione> some -dev are not installable
<fabbione> that's why you see these DepWait
<Kamion> update as in apt-get update presumably
<jdub> Kamion: ah, thanks, checking out now
<seb128> fabbione: ah ok, makes sense, thank you :)
<fabbione> Kamion: that's what i did on sparc to get out of that loop.
<fabbione> Kamion: assuming the chroots are clean at the same level..
<jdub> Kamion: boh! :)
* Kinnison turns up. Sorry for lateness
<pitti> dholbach: can you please avoid using 'ubuntu' in fake sync versions?
<dholbach> pitti: arg, yes
<dholbach> pitti: you're perfectly right
<seb128> pitti: using "build"?
<pitti> I use NMU-like numbers
<dholbach> or -<n>.1 or something
<pitti> but we don't have a common standard for that
<seb128> Debian could use the NMU
<dholbach> build1 is better probably
<seb128> I think so
<dholbach> pitti: so I won the next merge :-)
<pitti> dholbach: yes, shouldn't hurt
<pitti> dholbach: congratulations :)
<dholbach> yay! :)
<seb128> the best way would be to get a real sync though
<freeflying> pitti: ping
<pitti> freeflying: pong
<freeflying> pitti: we have a package for IM select in our distro based upon debian 
<freeflying> pitti: shall we use this way for the IM in ubuntu ?
<pitti> fabbione: how is it done there? based on locale?
<freeflying> pitti: it's a GUI program , it will give you choice , then user just need select what they wanna
<fabbione> pitti: ?
<pitti> fabbione: ?
<fabbione> pitti: sorry.. i was not following
<fabbione> <pitti> fabbione: how is it done there? based on locale?
<pitti> fabbione: argh, sorry, ETAB; was supposed for freeflying 
<fabbione> ok :)
<freeflying> pitti: if u can read in chinese, plz http://linux.hiweed.com/node/2673
<pitti> I can't
<freeflying> pitti: will it be a chioce ?
<pitti> mvo: whoa, tetex-bin's postinst is what I call 'verbose'
<seb128> Kinnison: new gnome-power-manager tarball, you may want to update it
<freeflying> s/chioce/choice
<Kinnison> seb128: I'll look in a bit, thanks for the headsup
<pitti> freeflying: I don't understand the page; however, if we only have scim, why should we have a selector for scim alternatives?
<seb128> np
<mvo> pitti: hehe, yes :) 
<freeflying> pitti: because other locale user wouldn't like to use scim/skim 
<seb128> mvo: BTW seems you fixed that update-notifier CPU loop, nice :)
<seb128> didn't happen for some time now
<pitti> freeflying: hmm, it seems that this gui is entirely orthogonal to the scim module selector with env vars we talked aobut earlier then?
* mvo hugs seb128
<freeflying> pitti: y
<freeflying> pitti: actually , any locales user can use scim ,u know u can use it under en_US without any problems
<pitti> sjoerd: dbus crashes again on <policy group="...">
<pitti> sjoerd: I thought this was fixed long ago...
<pitti> sivang: volume.disc.capacity = 735051776  (0x2bd00000)  (uint64)
<pitti> :)
<sjoerd> pitti: is fixed (again?) in dbus 0.61
<pitti> sjoerd: ah, good to know, thanks
<seb128>  hum
<seb128> where would you guys ship little utilities than can be useful for debug with a package?
<seb128> like list_cddrivers for ncb
<tenco> hi all
<seb128> to /usr/share/doc/package/utility or something like that?
<tenco> is  it normal that ubuntu dapper starts kgpg and kalarm?
<seb128> Hi
<seb128> no, it's a conflict with /usr/share/autostart feature between both desktop and will be fixed
<pitti> seb128: why not /usr/share/package/?
<tenco> seb128: good to know. thanks
<seb128> pitti: no reason, I'm not sure if that should be shipped to /usr/bin or some other place
<seb128> seems a bit "/usr/bin noise" to me, I'm fine with /usr/share/package
<tenco> seb128: quick fix?
<seb128> tenco: uninstall KDE
<tepsipakki> hehe
<tenco> seb128: err, no
<tepsipakki> I noticed that conflict 5min ago
<seb128> tenco: grep OnlyShowIn /usr/share/autostart/*
<tenco> seb128: was just testing. i dont liked what i see. :P
<tenco> s/liked/like
<sivang> pitti: yay!! :-)
<seb128> tenco: testing what? what does the grep prints exactly?
<tepsipakki> only gnome-stuff uses that
<tepsipakki> it seems..
<tenco> seb128: where should i paste?
<tenco> btw: spelling correction within gaim is awful
<seb128> tenco: pastebin.com
<seb128> tepsipakki: use what? /usr/share/autostart? why would KDE packages put stuff to it so?
<tepsipakki> seb128: sorry, I was wrong... the computer where I ran that didn't even have KDE =)
<tenco> http://pastebin.com/574718http://pastebin.com/574718
<tenco> http://pastebin.com/574719http://pastebin.com/574719
<tepsipakki> my install has kgpg and khotkeys that need fixing
<tenco> first: your command. second: cd /usr/share/autostart;ls
<tepsipakki> that directory is meant for packages (and admins) to start stuff with the session?
<seb128> tenco: seems that kgpg and kalarm have no OnlyShowIn=KDE
<hunger> tenco: There is a bugreport about kgpg starting by default.
<tenco> hunger: ok
<hunger> and about kalarm, too.
<hunger> ... and kpowersave ...
<hunger> kalarm is #31923, kgpg is #31294.
<tenco> btw: in rythmbox why cant i skip forward and backwards within a track when its start not from the playlist?
<hunger> kpowersave is #32340 FWIW.
<tenco> s/start/started
<tenco> in the meantime i will move them to a separate dir
* hunger thinks that the problem is that kde-developers seem to think they own that directory since gnome only recently started using it.
<seb128> tenco: what do you mean?
<tenco> when i play a track from the collection browser or the podcast view, i cannot skip forward or backwards within the track
<seb128> "collection browser"?
<seb128> it works fine with a podcast source here
<tenco> musiksammlung
<tenco> ah. sorry. seems like it was an old configuration
<tenco> before i deleted ~/.gconf* and ~/.gnome2* it didnt work
<tenco> strange
<tenco> which feed-reader do you recommend?
<tenco> no it doesnt work anymore :-(
<tenco> i started a podcast from the podcast view
<tenco> skip till the tracks end
<tenco> started the podcast again
<tenco> now i cannot skip forward or backwards within the track anymore
<tenco> same for playing songs from the collectioin
<tenco> reproducable
<tenco> additionally, downloading a podcast makes rythmbox constantly access the harddisk
<sabdfl> hey guys, who's the best person to discuss beagle with?
<simira> I really lik beagles, but...
<Keybuk> sabdfl: Novell Person, or Ubuntunaut?
<sabdfl> ubuntunaut, i have a request from someone that we fix it to work well with msft word files
<Keybuk> my memory suggests Lathiat or tseng, but not sure
<tenco> reproducable, but only with one mp3. its over 3 hours long
<setuid> Can someone tell me if the fglrx xorg server is in dapper? 
<Keybuk> seb128: evo ... does "Signature: BAD" just mean snake-oil?  or is its TLS broke?
<Mithrandir> setuid: there's no fglrx xorg server.  There's a fglrx xorg driver which is in warty, hoary, breezy and dapper.
<setuid> Ok, I'll give that a go
<sabdfl> Lathiat, tseng: ping
<sabdfl> thanks Keybuk
<jsgotangco> oh wow
<jsgotangco> 173 users in a devel channel that is neat
<ploum> jsgotangco: : and really few noise. It's definitly good :-)
<setuid> Mithrandir: Looks like the fglrx isn't in dapper... yet
<Mithrandir> setuid: it is
<setuid> Not in main, universe, multiverse
<setuid> Just checked
<ogra> setuid, its in restricted
<ogra> indeed
<setuid> or if it is, its not by the name xorg-driver-fglrx
<Mithrandir> : tfheen@thosu ~ > apt-cache show xorg-driver-fglrx |grep ^Desc
<Mithrandir> Description: Video driver for ATI graphics accelerators
<Mithrandir> this is an i386 dapper system
<setuid> I wonder why upgrade and dist-upgrade don't show it as a target for replacement
<Keybuk> infinity: ping?
<setuid> Is dapper relatively functional at this point? 
<setuid> I mean... no major crashes/bugs in core? 
<setuid> I know there's one in locales, which I had to work around (tzconfig bug) 
<Lathiat> setuid: if its not installed, you cant upgrade it.. you need to apt-get install it
<tenco> ok. bugs reported :-)
<AlinuxOS> mjg59, here ?
<AlinuxOS> hello all people :)
<AlinuxOS> pitti, here ?
<pitti> hi AlinuxOS 
<tenco> bye
<pitti> sjoerd: do you know whether the hal-device-manager hang is fixed in dbus 0.61?
<sjoerd> pitti: not afaik
<pitti> sjoerd: I didn't find an upstream bug so far, I'll file one
<maswan> Mithrandir: do you know if there was a kernel upgrade wrt scsi stuff between flight-3 and flight-4?
<Mithrandir> maswan: quite possibly.
<maswan> hmm.. wonder if I should try and pull a new cd or just try flight-3 then.
<maswan> hmm. going to try it. back in a bit. :)
<tseng> sabdfl: good morning
<pitti> mjg59: please meet AlinuxOS, or famous Georgian translator :)
<pitti> mjg59: do you have the source package for this georgian font package around somewhwere? (bug 30671)
<Ubugtu> malone bug 30671 in language-pack-ka "ttf-bpg-georgian are GPL ttf fonts for language-pack-ka and GNOME interface." [Normal,Needs info]  http://launchpad.net/bugs/30671
<tseng> sabdfl: word in beagle needs a new package (wv1-dev), its totally doable aside from putting a bit of crappy old code in main
<setuid> Lathiat: I know that, its already installed on Breezy
<tseng> sabdfl: (was planning on promoting beagle this week for nautilus search features)
* setuid isn't exactly a newb here, been running/admin'ing Debian boxes for >8 years, Slack/RH/Ygdrassil before that
<Kinnison> tseng: IME beagle chews all my RAM and crashes my desktop. It doesn't feel ready for main
<tseng> Kinnison: mmm since when
<Kinnison> tseng: Last tried it a couple of weeks back, so I guess they could have fixed it since
<Keybuk> the annoying thing about Beagle is how much inotify sucks
<tseng> Kinnison: the chewing ram has mostly stopped for the worst offenders in the last two releases
<AlinuxOS> pitti, ;)
<Keybuk> in order to watch your home directory, it has to do "find ~ -type d"
<tseng> Kinnison: and ive never heard of "crashing my desktop" aside from excessive ram usage
<AlinuxOS> the font's were taken from http://bpg.sytes.net/BPG-InfoTech/sppro/bpg/publications_list.asp?vjob=vcat,167  Authors site
<setuid> woo
<setuid> Total number of unique IPs blocked on port 25: 7966
<AlinuxOS> pitti, am I famous ? :) woow :)
<setuid> We might break 8k today
<Kinnison> Keybuk: and I have a couple of kernel trees and some gtk/glib extracts etc all in there
<Kinnison> Keybuk: btw, "Bedknobs and Broomsticks" AICMFP
<tseng> Kinnison: ajmitch_ seems to have the worst registered experience with his gazillion stored feeds from liferea, and his daemon stays under 30mb now
<Mithrandir> Keybuk: it should be easy enough to do "add directories matching this mask", I'd assume.
<Kinnison> tseng: I guess I should try it again then
<Keybuk> Kinnison: there is no FP to claim
<Keybuk> Mithrandir: sadly not
<Kinnison> Keybuk: :-(
<Mithrandir> Keybuk: why not?
<Keybuk> Mithrandir: inotify is "watch this directory" or "watch this file"
<Keybuk> there's no "watch this and all of its children"
<Mithrandir> Keybuk: "easy enough to add" implies kernel code. :-P
<torkel> tseng: beagle is still broken wrt evolution (or rather evolution-sharp is still broken)
<Keybuk> Mithrandir: ah, this is clearly some new definition of "easy" I wasn't previously aware of
<Mithrandir> Keybuk: it's C, it's easy.
<Mithrandir> What Could Possibly Go Wrong?
* Keybuk points at your vmware install
<Mithrandir> I guess you could do it using kprobes.
<Keybuk> everyone's machine could look like that
<Mithrandir> I blame BenC
<Keybuk> kanalprobe
<Mithrandir> it works just fine with flight 4.
<Mithrandir> I should probably do something like a bit gisect.
<tseng> Kinnison: yeah, id like to have your feedback on that now
<tseng> torkel: im pretty aware of that
<tseng> torkel: people file bugs at least 3 duplicates at a time when it comes to beagle
* Keybuk investigates how to make Google less Norweigian
<Mithrandir> Keybuk: use google.co.uk?
<Treenaks> google.com/ncr
<dholbach> sabdfl: slomo too (mono, beagle)
<tseng> dholbach: er, hi
<dholbach> hey tseng :)
<dholbach> tseng: ah right, you just chatted :)
<dholbach> sabdfl: nevermind :)
<jsgotangco> hey tseng!
<Keybuk> and yet again, I observe that the "List of languages" is still localised
<tseng> dholbach: hugs
<tseng> jsgotangco: hi there
<Keybuk> that is Google's biggest UI b
<Keybuk> bug *ever*
<Mithrandir> Keybuk: good thing we're not in China, then.
<Mithrandir> or Japan
<Keybuk> exactly
* dholbach hugs tseng back :)
<Keybuk> I'd need to know the crouching-wombat hidden-waffle for English to get my language back
<Kinnison> Keybuk: visit google.co.uk ?
<Keybuk> it should be a static list of the local names for every language
<Keybuk> Kinnison: the observation was that the Google bar in firefox goes to .com whatever you use as your home page
<Mithrandir> Keybuk: fix your firefox to use google.co.uk for the google bar thingy.
<Kinnison> Keybuk: oh dear
<torkel> tseng: check. I only found one against evo-sharp
<Keybuk> Mithrandir: I've never got that to work
<Keybuk> it always goes back to .com anyway
<tseng> torkel: er, most go straight to beagle
<tseng> torkel: regardless of where the bug is
<tseng> torkel: varying degrees of clarity as to which bug is which
<tseng> torkel: if you wanted to help triage.. :D
<torkel> tseng: sure, if you can find me some time to do it...
<Kinnison> Kamion: gnome-volume-manager has released a new upstream (2.13.91 -> 2.13.92) which contains a bunch of bug fixes we'd like to have in dapper. I've been reviewing the changelog etc this morning and it all looks fairly benign. http://ftp.gnome.org/pub/GNOME/sources/gnome-power-manager/2.13/gnome-power-manager-2.13.92.news may be of use to you -- I would like a UVF/FF exception to integrate our patches with this and upload to dapper. Can y
<Treenaks> Kinnison: you start about g-v-m, but go on about g-p-m..
<Kinnison> gah, gnome-power-manager all the way
* Kinnison keeps saying g-v-m 'cos I was playing with it this w/e
<Kinnison> Kamion: Sorry, g-p-m all the way, not g-v-m at all
<Keybuk> we're lucky he didn't end up in gnome-theme-manager
<Treenaks> Keybuk: gnome-pointer-manager ?
<Mithrandir> or gpm
* Kinnison sighs
<ogra> Kinnison, isnt bug 22502 fixed in g-p-m since quite some time ? 
<Ubugtu> malone bug 22502 in gnome-screensaver "Blank screen when returning from suspend/hibernate" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/22502
<Kinnison> ogra: umm, yes it should be
* Kinnison hasn't re-triaged bugs in a while and I probably missed that last time
<ogra> oki, thanks ... i wasnt sure
<ogra> nope, its assigned to g-s-s
<Kamion> Kinnison: yes, looks reasonable
<ogra> Kinnison, mind to take a look at bug 22522 ?
<Ubugtu> malone bug 22522 in gnome-screensaver "Moving mouse while laptop lid is closed turns on screen" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/22522
<AlinuxOS> mjg59, here pal ?
<ogra> Kinnison, never mind, i just see youre subscribed :)
<sivang> how do I go about syncing / merging irssi from debian unstable? it a new upstream release which fixes a lot of mem mamangemtn bugs..
<tseng> you have to post a changelog diff and diffstat to ubuntu-motu list
<tseng> hm its in main actually
<tseng> approval from mdz or Kamion to break uvf
<sivang> hmm, nahh, I See the upstream build on my machine didn't solve the particular problem..better to try come up with a patch.
<Keybuk> I HATE BZR!
<Keybuk> activity report: two intelligent people trying to get bzr push/pull to work to/from chinstrap: 1 hour
<pitti> Keybuk: pull/push to rookery works flawlessly for me at least
<pitti> Keybuk: what makes chinstrap 'spethial'?
<Mithrandir> pitti: it's not a problem with chinstrap.  It's that the current dailies are special.
<Keybuk> pitti: if I push, then nothing appears in the resulting directory (except .bzr) and Tollef gets a strange error when he tries to pull from it
<pitti> ah, I see
<pitti> Keybuk: the former is not really a bug, but intended
<Keybuk> pitti: is the error intended though?
<Mithrandir> pitti: it's _really_ silly.
<pitti> Keybuk: you didnt' get a warning? ('Cannot update working directory' or so)
<Mithrandir> since it means bzr push foo:path is no long a way to do remote branching.
<Mithrandir> which then means you actually have to have bzr installed on all machines you want to check out on.
<Keybuk> pitti: yeah I get that warning
<Keybuk> plus some random Python DeprecationWarning
<pitti> Mithrandir: right, I find that annoying, too
<Kinnison> Mithrandir: did you check push's help
<Keybuk> the push-doesn't is so broken though
<pitti> Mithrandir: I recently switched back to rsync push, it's both much faster and updates the working dir
<Keybuk> pitti: how do you do rsync push?
<Kinnison> Keybuk: install bzrtools
<pitti> Keybuk: with bzrtools
<Mithrandir> Kinnison: no, I didn't.   I got annoyed over bzr push suddenly changing behaviour.
<Keybuk> yeah, I just did that, and it didn't do anything
<Kamion> Mithrandir: (you can always just rsync the whole thing rather than bzr push)
<Keybuk> bzr push foo:bar just made a foo:bar directory in my cwd
<pitti> Keybuk: you have to change the push location to an rsync spec
<pitti> Keybuk: i. e. like chinstrap:bzr/mypackage
<Keybuk> pitti: that made directories in my cwd
<pitti> hm
<Kamion> Keybuk: if you had bzrtools installed, definitely sounds like rsync push broe
<Kamion> broke
<Kamion> bzrtools does a weird decorator thing with the push builtin, looked pretty fragile to me
<pitti> I didn't push after today's dist-upgrade, so that's entirely possible
<Keybuk> doesn't rsync push also cause major issues if two people push together?
<Kamion> Keybuk: yes
<Kamion> you have to use sftp push for safe operation on shared archives
<Kamion> use rsync for the initial push 'cos otherwise it's brain-deadeningly slow, but after that sftp is usable enough
<Kamion> though I heard mutterings about sftp push having been sped up by a factor of $LOTS recently
<Keybuk> does the sftp update the branch directory too?
<Mithrandir> Kinnison: bzr push has --no-tree which doesn't update the working tree.  That means not updating the working tree is a bug.
<sivang> Keybuk: it doesn't only meta data
* sivang uses push to sftp
<Mithrandir> (unless you pass --no-tree, obviously)
<Kamion> Keybuk: no, I have my own "push-fix" plugin which does sftp push then 'ssh $host bzr revert && find -name \*~ | xargs rm -f'
<Kamion> or words to that effect
<Kamion> well, unless they've changed it - the --no-tree option wasn't there last time I checked
<Kinnison> afaict, bzrtools hasn't had any changes made to it which would break rsync pushing working tree
* Kamion decides not to upgrade bzr for a while as it sounds like the current dailies are a bit broken
<Mithrandir> Kamion: I'm running 0.7, though
<Kamion> Mithrandir: I can chuck you over my push-fix plugin then
<Mithrandir> Kamion: please.
<Kamion> Mithrandir: http://people.ubuntu.com/~cjwatson/push-fix/__init__.py - install in ~/.bazaar/plugins/push-fix/__init__.py
<Keybuk> the only thing currently more annoying than bzr is bogofilter cheerfully declaring "yes, that's spam" and then sticking it in my INBOX anyway
<Kamion> it's almost certainly really nasty bzrlib abuse and I can't guarantee that it'll keep working
<Kamion> and it only works for sftp push at present
<Mithrandir> Kamion: thanks.
<AlinuxOS> mjg59: ping
<maswan> Mithrandir: Well, it works. Kind of. And after lots of local hacking, due to the install/mkinitramfs stuff being crap (say, wouldn't it be a good idea to load the driver and some scsi modules before throwing up your hands and say you can't find sda1?)
<Mithrandir> maswan: it does.
<Mithrandir> maswan: and then it hangs around for a while, but the scsi bus might be exceedingly slow on ravel, I'm not sure.
<maswan> Mithrandir: No, after manually adding them to the mkinitramfs/modules list it works fine.
<maswan> Mithrandir: the driver modules weren't even included in the initramfs
<Mithrandir> maswan: blame scott, then. :-)
<maswan> Mithrandir: Now the question is, do I want to try and reproduce this with flight-4, or am I satisfied with just whining about it on irc? :)
<Mithrandir> maswan: if you would try with flight 4 it'd be useful for us.
<maswan> hmm.. we did install the latest kernel though already.
<Keybuk> maswan: if your scsi driver wasn't automatically loaded ... then it's likely a kernel bug
<Keybuk> it also could be an initramfs bug ... was the driver actually in the initramfs before you stuck it in /etc/mkinitramfs/modules ?
<maswan> Mithrandir: Yeah, I know. Just not sure I'm up to that right now (it took two install attempts to get stuff in to begin with, but that was just me misdiagnosed by me as "can't find the VG" -> lvm crapped out, not scsi crapped out)
<maswan> Keybuk: I tried to find it in /lib/modules on the initramfs, and I couldn't find the mpt* modules.
<Keybuk> maswan: blame infinity 
<maswan> Keybuk: after I got a busybox shell when it coudln't mount root
* maswan blames infinity 
<Keybuk> if the modules aren't in the initramfs, it's an infinity bug
<Keybuk> if they are and they don't get loaded, it's a BenC bug
<Keybuk> only if they get loaded, and there still isn't a /dev/sda1 is it a Keybuk bug
* maswan nods
* maswan does not blame Keybuk then :)
* pitti boggles about udev rules
<pitti> Keybuk: if/when you have a minute, could you give me a ping, please?
* Keybuk gives pitti a ping
<Mithrandir> maswan: what's the exact module ravel needs?
<maswan> mptspi                 10888  0 
<maswan> mptscsih               40544  1 mptspi
<maswan> mptbase                53792  2 mptspi,mptscsih
<Mithrandir> scsih isn't added by default.
<maswan> I also needed to add sd_mod (and possibly scsi_mod)
<Mithrandir> but spi is.
<maswan> Ok
<Mithrandir> can you get me the broken initramfs or is it gone?
* maswan looks. no, it's gone. :/
<Mithrandir> hmm, ok. :-/
<maswan> Oh, well. If I just get a bit to recover, I can go at it again.
<Mithrandir>   * Add mptspi to the list of SCSI modules put in the initramfs by default,
<maswan> besides being boring, an install isnt' so bad
<Mithrandir>     which is required for some LSI Logic controllers and for the VMware SCSI
<Mithrandir>     controller in recent VMware versions (See launchpad.net/{27187,31229})
<Mithrandir> might be the fix.
<Mithrandir> 14th Feb
<maswan> ah
<maswan> yeah, possibly
<maswan> would that have made it to flight-4?
<Mithrandir> which is post-flight-3, IIRC.
<Mithrandir> yeah
<Mithrandir> flight 4 is a week ago, approx.
<Mithrandir> iirc
<Mithrandir> ooh, possibly.  Maybe not.
<Mithrandir> it's an edge case.
<Kamion> definitely post-flight-3 and pre-flight-4
<Kamion> I made sure that got in for vmware installs
<Mithrandir> heh, ok
<tepsipakki> is jeff bailey on a vacation or similar?
<Kamion> tepsipakki: he's working on Canonical support full-time now, not distro team any more
<Kamion> so don't expect to see him around much
<tepsipakki> who's maintaining glibc/nscd then?
<tepsipakki> launchpad says there's a team, but no members on it ;)
<infinity> tepsipakki: Jeff is doing so somewhat until the dapper release, but he and I are working on a soft transition to me taking on glibc.
<tepsipakki> infinity: ok, there are some very easy bugs that could be fixed :)
<jono> Kamion, hey, has espresso changed much since flight 4?
<maswan> Ok, going to burn and try flight-4 then
<infinity> tepsipakki: I haven't had a chance to dig through the list yet.  Though, nothing in glibc is ever as "easy" as it looks, owing to the fact that one thing almost always breaks something else somewhere else. :)
<infinity> tepsipakki: If you're just talking simple packaging bugs, then yeah.  I need to tackle the list in the next couple of weeks and nail those.
<tepsipakki> infinity: well, these are: malone 3365 and malone 30141
<Ubugtu> malone bug 3365 in glibc "nscd does not create necessary directories in /var" [Normal,Unconfirmed]  http://launchpad.net/bugs/3365
<Ubugtu> malone bug 30141 in glibc "nscd needs to start earlier" [Normal,Unconfirmed]  http://launchpad.net/bugs/30141
<tepsipakki> but ok, I'm sure these will be fixed for dapper ;)
<infinity> Ahh, more /var/run on tmpfs bugs. :)
<Kamion> jono: yes, lots
<infinity> Yeah, we need to either sort every last one of those or get Scott to revert that. :)
<infinity> I've already uploaded for half a dozen or so.
<jono> Kamion, is the UI drastically different?
<Kamion> 100 lines of changelog since Flight 4
<tepsipakki> I just reinstalled my other workstation, and because of ldap I have 52 connections to the servers. nscd is a must when using ldap..
<Kamion> jono: yes, added language and timezone selection pages
<Kamion> keymap still to come
<jdub> Kamion: how many changes in debconf bits have been required for espresso, or is it pretty neatly separate?
<Kamion> jdub: quite a lot
<jdub> s/debconf/d-i/
<Kamion> jdub: same answer :)
<jdub> :)
<Kamion> it's not supposed to be neatly separate, it's supposed to be well-integrated
* jdub is very keen to try it out - will download a CD when he gets home
<Kamion> jdub: most of the changes are packaging though
<jono> Kamion, is there a simple way I can get my hands on it, can I just dist-upgrade my installed system and re-run it?
<Kamion> jdub: i.e. making d-i packages spit out espresso-foo
<jdub> Kamion: in a not-objectionable way to debian?
<jdub> hrm
<Kamion> jdub: remains to be seen. some of the non-espresso-specific changes have already gone upstream
* jdub kicks off download now
<jdub> muhaha
<Kamion> jono: dist-upgrade a live CD
<Kamion> of course you have to have enough memory to cope ...
<Keybuk> infinity: at some point, in my copious free time, I plan to just grep the archive for any package that includes a /var/run dir or mentions it in postinst, and blitz them all in one go
<jono> Kamion, ok
<Kamion> jono: you might want to wait a couple of hours though, I just made a big upload a few minutes ago
<jono> Kamion, ok cool
<jdub> Kamion: what's my best choice for test iso love?
<Keybuk> hmm... ok, I'm now getting *no* mail... wonder if I've over-filtered it :p
<Kamion> jdub: today's daily seems to be O
<Kamion> OK
<jdub> Keybuk: "you've got qmail!"
<jdub> Kamion: ok!
<Kamion> and has the cute timezone page, even without my most recent upload
<jdub> http://cdimages.ubuntu.com/ <- bong
<jono> where are the daily isos?
<Kamion> jono: http://cdimage.ubuntu.com/daily-live/current/
<Keybuk> jdub: it's better than gmail
<jono> awesome
<jono> jdub, enjoy FOSDEM?
<Kamion> jdub: wanna RT that?
<Keybuk> after two weeks of having to use gmail, I want to give my invite back
<jdub> Kamion: aye
<Kamion> I think one half of cdimage.ubuntu.com is not configured to respond to cdimages
<Znarl> Kamion : Which half?!?  :/
<maswan> jdub: cdimages != cdimage, perhaps?
<Kamion> Znarl: .155
<Lathiat> i think releases. has problems with that as well
<Kamion> .176 works fine, according to a raw-HTTP test
<jdub> Kamion: daily or daily-live?
<Kamion> jdub: daily-live
<jdub> thanks!
<jono> ahhh cunning I can dist-upgrade to espresso and write the book
<jono> woo!
<Kamion> jdub: there's one big debconf change yet to come, which is a bit complicated and has compatibility implications if we get it wrong - I'm talking about it by mail with joeyh at the moment
<Mithrandir> jono: you like our live CDs? :-)
<Znarl> Kamion : Corrected.
<Kinnison> Kamion: did you see my request for a UVF exception?
<jono> Mithrandir, yes indeedy
<Kamion> jdub: I sincerely hope nobody ever wants to backport to breezy
<jdub> Kamion: ha ha
<Kamion> Kinnison: 13:49 < Kamion> Kinnison: yes, looks reasonable
<Kinnison> Kamion: aah ogra confused me into missing you saying it looked reasonable
<jdub> Kamion: you're happy with it so far?
<Kinnison> Kamion: Thanks
<Kamion> jdub: mm, well, sort of. lots to do
<Kamion> it's a lot better than it was a month ago
<Mithrandir> jono: it's a bit of a shame there's no way to upgrade the kernel on them, though.  Not yet, at least.
<Mithrandir> jono: like, runtime.
<infinity> Mithrandir: kexec()!
<Keybuk> infinity: please don't give him ideas
<Keybuk> he has that look on his face
<simira> who can I hit for xlibs not being in Dapper?
<infinity> simira: No one, it shouldn't be.
<simira> infinity: Opera depends on it :-( It was in Breezy
<ogra> simira, it died a slow, awful and ugly death with xorg 6.X
<infinity> Mithrandir: Tell your friends at Opera to rebuild on a Debian/Ubuntu base from the 20th century, kthxbye.
<Keybuk> simira: hit Opera
<Mithrandir> infinity: hmm.  Need to preserve the tmpfs-es and such, though.
<jsgotangco> infinity: +1
<Mithrandir> simira: no, it doesn't.
<simira> Keybuk: Not until they hav answered it I get a job there or not ;)
<Mithrandir> simira: it depends on xlib6g | xlibs.
<simira> Mithrandir: says so to me...
<simira> Mithrandir: well, xlib6g isn't in Dapper eiter
<Kamion> Mithrandir: neither of which exist any more
<Mithrandir> Kamion: the problem would then be that it depends on xlib6g, not xlibs. :-P
<simira> I thought xlib6g was a part of xlibs, anyway
<Mithrandir> simira: xlibs hasn't existed for years.
<simira> Mithrandir: must have been 6g I used in Breezy then. Doesn't help me much anyway. Now, do you want me to make dinner today or what? :p
* Mithrandir ruffles simira 
<Mithrandir> simira: I can ask Christian to build a package on something a bit more reasonable.
<infinity> sarge or hoary would be nice.
<infinity> breezy would be great (for an Ubuntu-spefici package)
<infinity> specific, too.
<simira> Mithrandir: Christian who? Anyway, it should be solved in some way.
<Kamion> xlib6g hasn't existed for years. xlibs existed up to breezy.
<Mithrandir> Kamion: hmm?  I thought it was the other way around.  I'll have to kick him, then.
<Kamion> xlib6g was never in an Ubuntu release
<Mithrandir> simira: Christian Westgaard.
<simira> Mithrandir: oh, Nafallo.
<simira> no
<simira> whatever
<Kamion> that's Bjlevik
<simira> as long as I get Opera installed, I'm satisfied. If I don't, I am not.
<Mithrandir> infinity: so just building it on sarge should pick up libx11 instead?  I'll get him to do that.
<Mithrandir> infinity: I don't think he builds ubuntu packages directly.
<infinity> Mithrandir: Should do.
<infinity> Mithrandir: Of course, Ubunut users will be stuck using the static build (since we can't use the dynamic build with our gcc-4.0-using QT), but no big deal.
<Mithrandir> infinity: sure, but as you say, not a big issue.
<infinity> Mithrandir: You could beg for an Etch build, though, which would also work on breezy and dapper smashingly. :)
<Mithrandir> infinity: there _is_ an etch build, which is what surprises me
<infinity> Hrm, I wonder if they're doing statically-generated deps or something scary, then.
<Mithrandir> - Depends: libc6 (>= 2.1.3), xlib6g (>= 3.3.6) | xlibs, libqt3c102-mt, libstdc++5
<Mithrandir> + Depends: libc6 (>= 2.1.3), xlib6g (>= 3.3.6) | xlibs, libqt3-mt (>= 3.3.4) | libqt3c102-mt (>= 3.3.4), libstdc++6
<Mithrandir> is the difference between them.
<infinity> Perhaps they build one binary on "some gcc-4.0 system" (like SuSE), then package them all up with static deps.
<Keybuk> simira: apt-get install firefox
<Mithrandir> infinity: they didn't used to do that, at least.
<Mithrandir> though, there's an unversioned dependecy on libstdc++ which looks slightly fishy.
<infinity> Mithrandir: Yeah, they're obviously using static deps.  There's no way dpkg-shlibdeps would give you those deps (neither the X deps, nor the scary QT|QT dep)
<simira> Keybuk: oh, will that give me a proper opera-install? :D
<infinity> Mithrandir: That QT|QT dep is just horribly wrong...
<simira> Keybuk: besides, ff is buggy also :p
<Mithrandir> infinity: la, la, la.
<infinity> Mithrandir: Plus, if it was built on anything recent, the shlibdep for glibc would be a lot higher.
<Mithrandir> indeed
<infinity> Mithrandir: Maybe you should offer a packaging lesson. :)
<Keybuk> simira: no, but it'll give you something you can bitch about to us <g>
<Mithrandir> infinity: I probably should.
<Mithrandir> infinity: it's just a ten minute bike ride from home, so I could really just pop by there an afternoon to say hi to them anyway.
<simira> Keybuk: who said I was finished? I am testing flight 4 right now... ;)
<infinity> Mithrandir: Heck, we could even repackage it for them in multiverse, if they were willing to hand us prebuilt binaries. :P
<infinity> (And give us a license to distribute)
<simira> Mithrandir: I consider applying for a application testing job there
* mode/#ubuntu-devel [+o Keybuk]  by ChanServ
<Keybuk> simira: are you saying you're not finished? :p
<simira> Keybuk: with flight 4 and bugging you? What part do *you* maintain?
* mode/#ubuntu-devel [-o Keybuk]  by ChanServ
<infinity> simira: All the broken bits.
<Keybuk> simira: none of it
<Keybuk> simira: I maintain my innocence
<Mithrandir> (he says, chuckling)
<Mithrandir> infinity: yeah, the redistribution licence used to be a problem, uhm, five years ago.  No idea if the talking with the lawyers ended up with anything changing.
<simira> Keybuk: I can't seem to find the innocence-package here... must be severely broken, then?
<Mithrandir> infinity: actually, the binaries are built on random crackful systems.  I should absolutely go there and fix that.
<Mithrandir> (RH9 and FC4)
<infinity> Mithrandir: Teach them some basic packaging, and extend an offer for me to set up a Debian/Ubuntu build system for them.
<infinity> (Even if it's just debian/ubuntu build chroots on an FC4 system)
<Kamion> Mithrandir: say hello to Eddy Welbourne from me if he's still there
<Mithrandir> Kamion: willdo
<ogra> anybody in here with a ati mobility 7500 ? (i.e. thinkpad t30) 
<seb128> pitti: every user should have a dbus session bus running, no?
<pitti> seb128: should have
<seb128> that's not the case?
<pitti> for whom?
<seb128> I've noticed that my "play with" user has no session bus running
<seb128> ie: I'm already logged and I tried to startx -- :1 with an another user
<torkel> ogra: about 22045? It's flickering for me with a Thinkpad T42 (ATI Technologies Inc Radeon R250 Lf [FireGL 9000] )
<seb128> and running dbus-launch returns _ADDRESS and _PID for the already running session bus (the one used by my user)
<seb128> pitti: gnome-screensaver refuses to start for that user saying it can't connect to the session bus because it is unable to determine the adress of the message bus or something like that
<seb128> said differently: "lock screen menu items does nothing" :p
<seb128> wb pitti_
<pitti_> meh network
<maswan> now that's an interesting regression, during installing base system flight-4 hangs (D) and I get scsi timeouts logged in dmesg.
<maswan> Mithrandir: sorry, no flight-4 report on that. I didn't get that far. :/
<torkel> ogra: and I haven't had time to investigate it. If you have anything you want me to test, let me know
<ogra> torkel, i just wanted to know if anybody else is still seeing it ...
<ogra> torkel, i assume you are on an up to date dapper 
<torkel> ogra: yes. Gimme a couple of sec and I will try it again just to verify
<desrt> seb128; you're welcome :p
<torkel> ogra: it's still flickering and I did my daily update half an hour ago
<ogra> torkel, ok, thanks ...
<ogra> weird that it only happens on ati cards ...
<ogra> i dont have it here *anywhere*
<pef> hello
<desrt> pef; hello
<ogra> Mithrandir, is casper still setting the "RUNNING_UNDER_GDM" variable ? its essential for preventing the screensaver from locking ...
* davyd_ appears
<davyd_> does anyone want to chat about #30557?
<lemsx1> hello all
<maswan> Mithrandir: moving over homedirs to ravel, then we'll have to look at chroots.
<lemsx1> the fix for this bug is really simple and it has been reported many times already: #32576
<lemsx1> all it needs is a TAB (instead of 8 spaces) in debian/rules and rebuild
<ogra> lemsx1, that looks like a weridly mixed debian/ubuntu saystem 
<ogra> there is no 2.6.15.3-desktop-2 kernel in ubuntu
<lemsx1> ogra: that part doesn't matter
<lemsx1> ogra: that's a custom kernel i built
<ogra> lemsx1, sure it does 
<lemsx1> ogra: no it doesn't, look at the other bugs for the same package. 
<lemsx1> ogra: there are 8 spaces in debian/rules. (opened in vim showed the line in red)
<ogra> its still info that matters to me if i triage a bug ...
<lemsx1> ogra: agree. but in this case the bug is in fglrx-kernel-source
<lemsx1> ogra: https://launchpad.net/malone/distros/ubuntu?field.searchtext=fglrx-kernel-source&orderby=-priority%2C-severity&search=Search
<ogra> lemsx1, be sure that will get fixed before release :)
<lemsx1> ogra: there was an earlier bug reported, but against the restricted modules package
<lemsx1> ogra: let's hope. if not, it doesn't matter... is not like ATI drivers work anyway ;-)
<WaterSevenUb> Kamion, hey. do you plan to add translation support for the menu item in the first installation screen of dapper? 
<lemsx1> ogra: i always go back to pulling the installer from ATI's site and building deb's that way... i just wanted to report the problem early so that Dapper doesn't get released like that
<torkel> ogra: when running gltext by hand it does not flicker...
<Kamion> WaterSevenUb: er, sorry, which string are you talking about?
<ogra> torkel, yes, must be a glitch between ati and g-s-s ... sandly it works fine on my ibook with ati card
<seb128> pitti: hum, dbus works fine now ...
<WaterSevenUb> Kamion,sorry, the menu items :)  all of them..."Install to the hard disk", "CD test"... etc.
<pitti> seb128: good to hear, but bad that it didn't work after the upgrade
<seb128> but that's weird, they may have a gnome bug
<pitti> seb128: however, I jsut checked the debdiff of my last upload again, and I can't see any related change
<seb128> when I log in
<WaterSevenUb> Kamion, they are not translatable it seems...
<seb128> if I try to lock the screen sometime it doesn't work on first try
<jvw> What's Ian Jackson's IRC nick again?
<seb128> that's like first try runs gnome-screesaver
<pitti> jvw: Diziet 
<Kamion> WaterSevenUb: oh, right, yeah, I do plan to
<jvw> pitti: thanks
<seb128> and second try lock the screen
<pitti> jvw: Hi Jeroen, how are you?
<jvw> pitti: fine, but very tired (FOSDEM)
<Kamion> WaterSevenUb: not quite sure *how*, I'll probably just messily hack them into gfxboot-theme-ubuntu
<jvw> pitti: and still finalizing and reworking bits of my DPL platform
<ogra> Kamion, anything that holds up edubuntu-docs  ?
<mantiena> doko, hi again, just now I got rid of kids...
<Kamion> ogra: not especially, just haven't looked at the NEW queue much for a few days
<ogra> ah, k
<ogra> :)
<WaterSevenUb> Kamion, ok... thx. since it is the first thing a user sees imho it's important to have it in their language. Probably the hack is not a bad idea.
<Kamion> WaterSevenUb: sure, I agree
<mantiena> doko, if you are online it would be nice to know your plans about OpenOffice.org in Ubuntu dapper. Are you planing to upload new builds with important bugfixes, like not working database form design or missing FontWork and Gallery ?
<Kamion> WaterSevenUb: I'll have a quick look now
<doko> mantiena: there will be new uploads, hopefully this week
<Kamion> WaterSevenUb: the strings include a ^ character that's used to indicate an accelerator key (like "Run preinstalled ^live system", accelerator key 'l'); do you think translators will understand that, or do I need to add comments?
<doko> mantiena: is there a bug report about the database form design?
<mantiena> doko, yes, of course, I can search and tell you bug number if you want ;)
<mantiena> doko, maybe somethere are the sources, which I could compile and test ?
<doko> mantiena: not yet with final package names
<mantiena> doko, what is "final package names" ?
<mantiena> hi herzi, long time without chat ;)
<herzi> hey
<doko> mantiena: to be decided
<davyd_> BenC: around?
<BenC> davyd_: yep
<WaterSevenUb> Kamion, well... I would understand that but a minority of the translators won't. It's a compromise. If you think u'll loose too much time including the comments, don't incld
<davyd_> BenC: can we chat about Ubuntu bug 30557?
<WaterSevenUb> kamion, include them.
<Kamion> WaterSevenUb: I think I'll just include them, it's easy to do
<WaterSevenUb> Kamion, well... in the end they are just a few so... :)
<Kamion> # Boot menu item; a ^ prefix indicates a unique accelerator key.
<WaterSevenUb> Kamion, yape. great.
<BenC> davyd_: sure
<davyd_> BenC: the bug seems to manifest itself when I change my maximum c-state option
<mantiena> herzi, are you still working on GNOPPIX ?
<BenC> davyd_: let's take this into #ubuntu-kernel to avoid noise
<davyd_> BenC: ok
<mantiena> herzi, or just amu alone works on GNOPPIX ?
<herzi> i don't
<mantiena> doko, hehe, this is not important for testing - I wanna test Ubuntu OpenOffice.org for important bugs in software, package names are not important for these tests ;)
<Kamion> I'll just say "an accelerator key" actually - they only need to be unique for the set of items on a given CD image, which is too complicated to explain in a translator comment
<sladen> Treenaks: did you get jdub?
<Treenaks> sladen: I got him last October ;)
<Treenaks> sladen: http://foodfight.org/movies/Ubuntu%20Fanpeople/
<ploum> Treenaks: I don't see Martijn van de Streek in your list !
<ploum> :-D
<Treenaks> ploum: I know I knokw
<sladen> Treenaks: if you replaced all the ' ' spaces with '-' dashes, they'd be easier to download
<sladen> Treenaks: I was wondering if you were going to get RMS saying ''I like OObuntu or whatever the version he likes is actualy called''
<Treenaks> sladen: If I copy/paste the URLs from firefox, they become %20s, which wget properly un-escapes, if you're so inclined :)
<sladen> Treenaks: yeah, they don't autoleethighlight in Gnome Terminal as it stops at the spaces
<Treenaks> sladen: ah... yes..
<Treenaks> that's why I pasted '%20' :)
<Treenaks> sladen: do you like them?
<sladen> Treenaks: a bit embarassing---you could do a video combining all the people just saying 'ubuntu', certainly keep collecting :)
<Treenaks> sladen: :)
<mantiena> doko, so, how I can get latest Ubuntu OpenOffice.org sources ?
<Pygi> hello :)
<Pygi> dapper daily build message when installing/booting system
<Pygi> Feb 27 17:45:13 ubuntu kernel: [4294671.850000]  pnp: PnPACPI: unknown resource t ype 7
<Pygi> 6 yimes
<Pygi> times*
<pitti> sivang: can you please do s/unstable/breezy-updates in your breezy-updates culmus pacakge?
<pitti> sivang: the change looks safe enough, so unless Kamion objects, I can upload the package
<feistel> hi
<feistel> I need help with Ubuntu installer, I need modify them
<feistel> Only I need change some strings of Ubuntu Installer
<feistel> where I can find that strings? I need change the templates of debconf, don't?
<feistel> any suggest?
<ploum> Treenaks: by looking at your collection, I realize that we really need more women involved in Ubuntu
<Kamion> feistel: which strings?
<Kamion> feistel: and are you trying to translate them, or change them for some other purpose?
<feistel> Kamion: some strings in the installer, debconf
<Kamion> pitti: no objection
<Kamion> feistel: please tell me which strings or I cannot help you.
<feistel> Kamion: ok, whait
<Kamion> feistel: they're very unlikely to be in the debconf package itself
<feistel> Kamion, the message in the end of first stage, when say "ubuntu is installed..."
<Kamion> feistel: that's in the prebaseconfig source package
<sivang> pitti: will do , thanks. sorry for missing this out
<Kamion> oh, hang on, let me check that
<feistel> Kamion: where that message are? I can't find any .mo file in the installer
<mgalvin> hmm, both abiword(after a sec or two) and ooo(on start up) crash on amd64
<mgalvin> oowriter2 on the cli says, no suitable windowing system found, exiting.
<pitti> sivang: same for irssi
<Kamion> feistel: hmm, no, actually, I cannot find the message you mention; please give me the full string?
<Kamion> not just the start of it
<pitti> sivang: the irssi one is only for dapper, is that right?
<sivang> pitti: correct
<Kamion> feistel: the installer doesn't use .mo files; it uses debconf templates
<pitti> sivang: alright, I'll upload irssi now
<pitti> sivang: does Debian know about the patch?
<Kamion> feistel: see the debconf-devel(7) and po-debconf(7) man pages
<feistel> Kamion: ok, where I can find in the install CD the debconf templates? In the initrd or in a .udeb package?
<Kamion> feistel: you'll find the templates in debian/po/ in each source package
<Kamion> feistel: that depends on which string you're talking about
<Kamion> some of them are in /var/lib/dpkg/info/ in the initrd, and some are in the templates file in the control area of .udebs
<Kamion> I wasn't just asking you for which string you were talking about for the fun of it :)
<doko> mantiena: sending you the URL
<Kamion> ultimately of course the initrd is built out of udebs too
<feistel> Kamion: ok, I need change some installer file, whait a moment please
<Pygi> anyone have any comment on that possible bug? :)
<pitti> sivang: irssi uploaded, please close the bug and such
<sivang> pitti: thanks you! 
<sivang> pitti: I will ping JD when he comes online again, he was supposed to sync up a new upstream, but the latest package from unstable didn't fix that, and i couldn't spot if he synced or not. I don't have a debian box near me so I can't test..
<feistel> Kamion: thanks!!!!!!! I find, yes!!! in the DEBIAN directory inside of a udeb packages, thanks again!!!!
<pitti> sivang: oh, reading changelog should be enough
<Kamion> WaterSevenUb: any chance you could have a look at http://people.ubuntu.com/~cjwatson/bzr/gfxboot-themes/Ubuntu/po/pt.po and translate the boot menu items there?
<Kamion> feistel: right, DEBIAN corresponds to the control.tar.gz
<WaterSevenUb> kamion, sure.
<Kamion> feistel: you'll find the original .po files in debian/po/ in the source package, which will almost certainly be easier to handle
<Kamion> WaterSevenUb: thanks
<Kamion> WaterSevenUb: works for me with a test string, anyway
<WaterSevenUb> Kamion, good:) I will test afterwards in any case.
<Kamion> might be as fast to send it to me and I can feed it to my test rig
<feistel> Kamion: only I need edit the DEBIAN/template file I rebuild the udeb package, without recompile anything?
<Kamion> feistel: once again, it depends on the string - you don't seem to want to tell me exactly which string it is
<Kamion> feistel: it's much easier to fetch the *source* package, change that, and debuild
<Kamion> (after installing the build-dependencies, obviously)
<feistel> Kamion: the string is "Description-es.UTF-8: Reiniciando a su nuevo sistema Ubuntu..." in english "Description: Rebooting into your new Ubuntu system..."
<jpatrick> maybe nueva is correct
<feistel> Kamion: then I dpkg -x and dpkg -c the udeb package, edit the template file, and dpkg -b , is correct?
<Kamion> feistel: thank you. Yes, that's prebaseconfig (and in dapper, it does not include the word "Ubuntu")
<Kamion> feistel: no, that is not correct
<Kamion> feistel: apt-get source prebaseconfig, edit debian/prebaseconfig.templates, debuild
<jpatrick> "Reiniciando a su nueva sistema de Ubuntu..."
<Kamion> and edit debian/po/LANGUAGE.po if you want to change translations too
<Kamion> jpatrick: irrelevant since it's changed in dapper now anyway ...
<Kamion> (although otherwise it could be changed, sure)
<feistel> ok I try
<feistel> jpatrick: nuevo is fine
<jpatrick> but it's female
<pitti> Riddell: can you please merge the kubuntu seeds against the latest ubuntu ones? there were several commits which weren't merged immediately and I'm not sure which pacakges you want
<Riddell> pitti: ok, doing
<pitti> thank you
<feistel> Kamion: debian/po/es.po file say
<feistel> # DO NOT MODIFY IT DIRECTLY : SUCH CHANGES WILL BE LOST
<Kamion> feistel: only applies if you're working in upstream d-i svn
<Kamion> which you aren't
<feistel> no
<feistel> ok I trt
<feistel> try
<Riddell> Kamion: are you editing the kubuntu seeds?
<Kamion> Riddell: no
<feistel> Kamion: how I debuild the package? I try dpkg-source -b , but don't generate a .udeb file
<jono> later all
<Kamion> feistel: install the devscripts and fakeroot packages, run 'debuild'
<Kamion> do not use dpkg-source -b
<feistel> Kamion: inside the directory?
<Kamion> feistel: yes
<feistel> ok I try
<WaterSevenUb> kamion, the accelerator keys shouldn't be underlined in the menu?
<Kamion> WaterSevenUb: they don't work at all at the moment :-)
<Kamion> WaterSevenUb: so no
<WaterSevenUb> kamion, ah:)
<Riddell> network-manager is on live?
<Kamion> they're just there for future support
<Kamion> Riddell: on Ubuntu, yes
<WaterSevenUb> Kamion, sent you the file by email.
<Kamion> sivang: pitti's right, you don't need to CC us for approval of simple bug fixes that don't involve sucking in new upstream versions
<sivang> Kamion: okay, sorry for the noise then. Will not happen again.
<Kamion> Mithrandir: http://people.ubuntu.com/~cjwatson/bzr/casper/preseed/ FYI - I've uploaded it
<feistel> Kamion: is planned a Ubuntu Graphic Installer?
<sivang> pitti: http://muse.19inch.net/~sivan/culmus/breezy/ , see if it's okay now. (there's a debdiff there) I did the update you requested.
<Kamion> feistel: http://wiki.ubuntu.com/UbuntuExpress
<feistel> Kamion: yes, I know about Ubuntu Express
<Kamion> feistel: if you're referring to a graphical version of d-i, I'm keeping an occasional eye on the work being done upstream on that, but until it stabilises somewhat more I don't intend to do the work needed to integrate it into Ubuntu
<feistel> ok
<sivang> pitti: I'm off for some time, be back in 1 hours, let me know if you could upload.
<Kamion> mvo: I'm planning to use python-apt (either the old API or the new one, whatever works ...) to install language packs in espresso
<Kamion> mvo: in either API, is there a way to cancel a download in progress?
<Kamion> so make the fetchprogress object be able to say "user cancelled operation" or something
<mvo> Kamion: yes, fetchprogress.pulse() is called regularely. if you return False in it, the fetch will be stopped
<mvo> Kamion: I would recommend the new api if at all possible, if you need anything for it, let me know
<Kamion> ah, yeah, just found the same by trawling through apt code :)
<Kamion> thanks, will do
<Kamion> right, that sounds perfect, matches well to debconf's progresscancel interface
<mvo> Kamion: nice. do you plan to use vte+gtkprogress for the actual installing?
<Kamion> mvo: probably not - I already have a progress interface so I'll map it onto that
<Kamion> and I think a terminal will not be required
<Kamion> well, not a visible one anyway
<Kamion> although if it turns out to be necessary I'll use vte, sure
<Kamion> I may end up just making debconf-apt-progress understand progresscancel, in fact
<mvo> Kamion: ok. let me know if you if I can help you with the interface in any way
<BenC> Is there any way to delete targets for bugs in launchpad?
<dholbach> no, you can just Reject/FixReleased them
<mantiena> doko, do you plan to include OOo 2.0.2 in Ubuntu Dapper ?
<BenC> yeah, but some users pollute things, and I just want to kill off the silliness
* ogra wouldnt like to reject a valid bug just because of a bureocratical mistmatch ... i'd call it a bug if you cant unset targets ...
<Amaranth> what bug?
<setuid> Why was aes256 removed from dapper? (this worked fine in breezy)
<setuid> ioctl: LOOP_SET_STATUS: Invalid argument, requested cipher or key length (256 bits) not supported by kernel
<LaserJock> yes, it is confusing to me when I get "Fix Released" or "Rejected" emails when the bug is still open
<setuid> And I have aes_i586 loaded
<Amaranth> LaserJock: People need to give better comments when they change the bug details. :)
<LaserJock> Amaranth: or people need to be able to separate/remove tasks ;-) probably both I think
<Kamion> mvo: I think the most "fun" bit will be that I have to run all this in a chroot
<Kamion> might be able to persuade apt to operate that way, otherwise I'll just copy bits of python around
<mvo> Kamion: right. you should be able to do most of it by setting "apt_pkg.Config.Set("Dir::") hopefully
<Kamion> thanks, hope so
<wftl> I'm playing with yesterday's Dapper live CD. Just wanted to say to whoever is responsible that the Espresso Installer is great. I know it's not completely done, but I'm very impressed.
<mantiena> :)
<jfbeckers> hi
<sladen> wftl: excellent;  I'm sure people will be glade to hear it.  Did you find any bugs or parts that you think could be improved?
<wftl> sladen: Nothing major. The keyboard section is missing, no big deal at this stage. The install went through quite smoothly. So now I'm busy writing the chapter that covers it. I'll do another pass before it's done but I feel confident enough about it to put it on paper (so to speak) :-)
<wftl> What would be really cool is an option to transfer the network settings I configured while running live. That would be amazing.
<sladen> wftl: nod
<sladen> wftl: can you file it as a bug please
<wftl> Where?
<wftl> I'm just a lowly author. ;-)
<Kamion> mvo: oh, hang on, do you mean literally "Dir::" or is that shorthand for various items under Dir:: ?
<Kamion> wftl: thanks for the feedback!
<Kamion> wftl: it should copy your network settings automatically, actually
<wftl> Kamion: Is thatyour baby?
<Kamion> wftl: yep
<wftl> Nice.
<wftl> Must be something in this development version then. The settings didn't follow me.
<sladen> Kamion: https://launchpad.net/distros/ubuntu/+source/expresso/+filebug didn't work, where's the place to point people to?
<Kamion> FYI the language and timezone UIs are reasonably close to final, keymap obviously isn't, username etc. will change as will the partitioner
<Kamion> sladen: spell "espresso" right
<Kamion> wftl: hmm, that's a bug, I don't know why it wouldn't - please file that one and I'll have a look
<wftl> Kamion: Sure thing. I almost hate saying this, but I wish I had a Windows machine to test a dual-boot install.
<Kamion> yeah, I keep a scratch Windows CD around so I can test that occasionally
<Kamion> it's ... painful
<wftl> Understood.
<Kamion> wftl: oh, we forgot to add that hook in casper (networking)
<Kamion> should be easy to fix
* Kamion sticks it on the to-do list
<sladen> wftl: https://launchpad.net/distros/ubuntu/+source/espresso/+filebug  would be the case then :)
<Mithrandir> Kamion: 'k, can you send it to me in a mail, since I'm in the middle of brewing beer? :-)
<Kamion> Mithrandir: send which?
<Mithrandir> Kamion: the "please merge $url, kthx"
<wftl> Kamion: Bug #33064 filed.
<Ubugtu> malone bug 33064 in espresso "Network settings not carried through installation" [Normal,Unconfirmed]  http://launchpad.net/bugs/33064
<wftl> Hmm . . . just saw the last message about casper.  Kind of makes the bug report redundant.
<Kamion> Mithrandir: done
<Kamion> wftl: never hurts to have a bug reminder, thanks
<wftl> My pleasure. Thank you.
<Kamion> might not do it in casper though, I was thinking of having an espresso-netcfg
<Kamion> so I can have /etc/hosts and stuff too
<Kamion> we'll see
<mdz> Kamion: just did an espresso test on amd64; it seemed to go splendidly until the reboot, which failed very early with GRUB error 15.  is there a known problem there?
<Kamion> mdz: yup, should be fixed as of a couple of days ago - the grub package just wasn't getting installed
<Kamion> were you testing flight-4?
<mdz> Kamion: no, the most recent daily I have been able to get
<Kamion> I added grub to the live seed to get around that
<mdz> I'll check the version
<Kamion> mdz: check whether grub's in the live filesystem
<Kamion> failing that, I would like /var/log/installer/espresso
<mdz> Kamion: the user experience for the simple install case is looking quite nice
<Kamion> the upload I did today adds better error checking for that case, anyhow, so that should improve matters too (not to mention that it actually builds on amd64)
<Kamion> good, glad you liked it
<Kamion> is now a good time to talk about progress?
<mdz> yes
<mdz> I wanted to actually have a look at a recent version first
<Kamion> mm, the version you had will be missing the timezone page
<mdz> it's been too long since I had time to do a round of CD tests
<Kamion> it might be worth dist-upgrading the live CD before starting espresso
<mdz> yes, I don't recall being prompted for that
<mdz> grub is not installed in my live fs
<Kamion> I gave the URL to a screenshot in last week's progress meeting, anyway
<Kamion> ok, perhaps the live fs is just out of date
<mdz> eek, 130M dist-upgrade
<mdz> might be just enough memory to do it
<Kamion> which is curious, the log for today's build looks fine and includes grub
<Kamion> apt-get install espresso should be enough
<mdz> Kamion: hmm, where can I find the CD  build number on the CD filesystem these days?
<mdz> on a live CD
<Kamion> /cdrom/.disk/info probably
<Kamion> although you'll have to mount /cdrom separately, current casper doesn't bind-mount its own mount into the real root
<Kamion> which I think is sort of a bug
<mdz> ok, had to upgrade espresso-* also to get it going
<mdz> but am running another attempt now
<mdz> time zone selector looked and worked as expected
<mdz> eek, it's dated 20060218
<mdz> but I downloaded it last week
* mvo goes to have dinner
<mdz> Kamion: what's the name of that wiki page you created with the espresso task list?
<mdz> ah, UbuntuExpress/Todo
<ogra> mdz, dailies were disabled some days due to flight preparation
<mdz> Kamion: the partitioning step feels much more responsive now
<Kamion> it's remarkable how much a blocked UI process is noticeable even if you aren't explicitly trying to provoke it
<Kamion> so of the features I listed on Thursday: I've done the preseeding glue, state of localisation is better but I still need to finish the debconf multi-line METAGET work I alluded to in order to make it work properly throughout (am working with upstream on that)
<Kamion> and I've done all the prereqs for language pack installation and am working on the actual code for it now
<Kamion> (I expected to defer the preseeding glue, until I remembered that it was necessary for language pack support)
<mdz> ok
<mdz> how is the keymap work coming?
<Kamion> I gave JaneW a run-down of approximate percentages complete of the various specs on Friday, which I think she was going to work into her report
<mdz> (apart from Mithrandir being occupied this week)
<Kamion> Mithrandir said to me a couple of days ago that "it's not there yet, but I can give you what I have, which shouldn't be utterly wrong and bad"; I think it was qwerty-only or some such but otherwise functional
<mdz> sabdfl: good morning
<Kamion> I've been encouraging him to get it to me before the UI sprint
<mdz> yes, the percentages made it into JaneW's report
<mdz> Kamion: are espresso bug reports making their way to you effectively?
<Kamion> mdz: yes
<LaserJock> umm, since a few of the TB are here, has the next TB meeting been scheduled?
<mdz> LaserJock: it's tomorrow at the usual time
<LaserJock> mdz: yikes? really?
<mdz> LaserJock: it's been at the same time every two weeks forever
<mdz> it's in the Fridge calendar feed
<LaserJock> mdz: no it's not
<LaserJock> and the wiki hasn't been updated either
<mdz> it usually is
<mdz> and the wiki is updated now
<LaserJock> mdz: ok, thanks. I'm not trying to be a pain, but I'm not sure if I can be there at the beginning. I'm up for MOTU (deferred from last TB meeting)
<mdz> Kamion: is there more work remaining on the partitioner apart from the advanced/gparted bits?
<mdz> the UI seems to need some adjustment to match the spec
<mdz> but backend-wies?
<mdz> wise?
<Kamion> mdz: my feeling is that by far the easiest way to beat the partitioning UI into shape is to change the backend to match what mpt described
<Kamion> that will change the behaviour of the traditional installer as well, but I think it will probably be worth it
<Kamion> there are alternative approaches, but they seem over-complex and fragile to me
<mdz> Kamion: how big are the code changes for that?
<Kamion> mdz: I haven't gone through and itemised them yet, but I think they should be pretty surgical
<Kamion> the most complicated bit is the proposed disk chooser, and if need be it'll be possible to leave that out
<mdz> ok
<mdz> I'll be in london on the 6th
<Kamion> most of the rest is just string changes (which can be made for Espresso alone if we want) and running os-prober in a few strategic places
<mdz> Kamion: would some pygtk manpower help?
<Kamion> mdz: honestly, not really
<mdz> Kamion: what would?
<Kamion> about the only bit on the to-do list that's amenable to general pygtk hacking is moving the breadcrumbs to be "step x of y" and maybe fixing the back button
<Kamion> perhaps partman help
<mdz> have anyone in mind?
<Kamion> I think the people we have who know their way around that are Mithrandir and fabbione
<Kamion> the partman changes can be made without espresso experience, imho
<mdz> anyone upstream/external who might be a bounty candidate?
<fabbione> sorry... -ENOTIME...
<Kamion> just a tiny bit of hacking at the end to fit stuff in
<fabbione> i am trying to fix parted too
<fabbione> that's already a hell of a job
<mdz> fix parted?
<fabbione> mdz: yes there is a catch 22 with libparted
<mdz> please explain
<Kamion> if Anton Zinoviev weren't at the end of a piece of wet string in Bulgaria that only gets connected once a month or so, I'd suggest him like a shot
<fabbione> they did implement some CHS checks that are not exctly understood by part_server
<fabbione> mdz: it's arch specific but it is an issue that needs to be solved
<mdz> jdub: the fridge calendar has the TB meeting 2 weeks from tomorrow, but not tomorrow's
<mdz> fabbione: for sparc?
<fabbione> mdz: yes
<fabbione> mdz: it is quite of a blocker for d-i at the moment
<fabbione> all the other pieces are in place or so it seems
<mdz> fabbione: what happened since breezy to break it?
<Kamion> otherwise everyone just nibbles round the edges of partman; Martin Michlmayr's done some bits, Sven Luther, joeyh obviously, Jurij Smakov's done sparc bits
<fabbione> mdz: that's what i am still digging :)
<Kamion> I don't think there's anyone external strong enough to make farming it out worth the risk
<wftl> Does the live CD have the option for a persistent home directory, a la Knoppix, so that subsequent boots recall the user's settings?
<Kamion> on the other hand I'll be talking to upstream for the advanced partitioning side of things, so I don't expect to have to do much more on that myself
<Kamion> wftl: https://wiki.ubuntu.com/LiveCDPersistence
<wftl> Kamion : Thank you.
<Kamion> I have to go in a moment for quality time; perhaps we can continue this later / by e-mail if there's more you want to talk about
<Kamion> by the way, I've got to admit that the new python-apt API looks lovely
<mdz> Kamion: this has been helpful, thanks
<mdz> Kamion: I'm still concerned about our timeline, though; let's follow up at a later time
<Kamion> ok
<Pygi> when will logout/shutdown stop changing every day? :)
<dredg> for random values of 'tomorrow'
<Pygi> dredg: hehe :)
<LaserJock> I'm missing all that joy since I just ssh into my Ubuntu box, I'm pretty much CLI only at this point :(
<ogra> whats wrong with ssh -X ?
<LaserJock> ogra: I do a bit of that, but over DSL -X is pretty slow, even vnc is kinda slow, but I use it when I need to test GUI stuff out
<dredg> in work i'm 100% on my mac these days, until i get around to fixing kerberized nfs
<ogra> LaserJock, i wasnt serious :)
<trappist> LaserJock: ssh -X -c blowfish is quite a bit faster
<dredg> it's ssh -Y these days
<LaserJock> actually I've been doing quite a bit with vnc lately, I wish vnc4 was fixed, tightvnc seems to have weird keymapping problems
<ogra> dont forget -C :)
<LaserJock> trappist: thanks for the hint, I'll try that
<dredg> i tend to use -c none, but that's prerequisite to patching ssh
<dredg> plus it's not the kind of thing you want unless you're damn sure you know you want it :)
<LaserJock> hmm, "ssh -Y -c blowfish" is very fast on my local network. cool!
<LaserJock> still, it's too bad vnc4 is so messed up. I really liked it for slower (DSL) connections
<psusi> I don't like ssh, and kerberos even less... shared secret < public key < x.509 digital certificates
<dredg> kerberos is, IMO, essential for nfsv3.
<psusi> well it's better than no authentication I suppose
<dredg> yeah. what's wrong with kerberos?
<psusi> it's based on shared secrets
<psusi> you generate a password and both the server and client have to know it
<psusi> that doesn't scale well, nor it it very secure
<psusi> crack a KDC and you've got everyone's password
<dredg> when you come up with a widely supported better way let me know
<psusi> one exists... x.509 digital certificates
<psusi> aka Public Key Cryptography Standards number 7, 12, and friends
<psusi> implemented by openssl
<psusi> not sure if there's a pam module out there that uses it or not... hrm...
<dredg> yeah, i need pam and ssh and a whole bunch of client apps to support it
<psusi> iirc, there's a generic ssl wrapper package you can use to wrap plain old telnet... no need for ssh... and I use it at work here to authenticate with apache/subversion
<dredg> krb5 isn't perfect but it works quite well without changing too much for users. and because everyone's homedir is on nfs, it needs to work with that too
<dredg> i have an X forwarding requirement
<dredg> and a portforwarding requirement. and a whole bunch of ssh gateways that take onetime passwords that i expect to be able to forward ports through
<psusi> ipsec can take care of that
<psusi> transparent encryption and authentication for all services...
<dredg> have ipsec as well for vpn. this is just for external ssh access
<dredg> i find port forwarding quicker
<dredg> but more importantly, what changes need to be made for a few thousand users from my POV and their POV to continue doing their jobs?
<psusi> configure the client and server to use ipsec to encrypt their connections
* psusi just might have to write an x.509 pam module if he can't find one... hrm...
* lamont wonders what he did that his breezy-security machine now doesn't bring up lo.
<psusi> aha! found one!
<psusi> PKCS #11 PAM Login Tools, rock on!
<CarlFK> should the installer be trying to recognize existing raid and LV configs?  Because it is trying, but sometimes failing
<CarlFK> personally, I don't think it should try - but maybe it doesn't have a choice given that it uses the partition table to store the settings when moving in and out of "setup RAID" option 
<jroes> shouldn't we do a bugreport instead of bugging them?
<Burgwork> jroes, yes, you should
<Pygi> jroes, wrong channel :)
<jroes> Burgwork: ;)
<Pygi> just a sec...is PnP ACPI supposed to work only on Laptops?
<astronut> does raphael hertzog come on IRC?
<seb128> he's buxy
<astronut> oh
<setuid> Where do I need to lobotomize the Ubuntu grub config to *NOT* neuter my kernel lines every time a distro kernel is added to the system? 
<setuid> I build and run my own kernels, and changes to menu.lst get clobbered every time dapper upgrades an existing distro kernel
<seb128> ?
<setuid> seb128: What was unclear about that? 
<seb128> what got changed to grub
<seb128> you don't want to get the installed kernel to be listed?
<setuid> Changed "to" grub? Nothing, its the default bootloader. 
<setuid> No. 
<seb128> to grub config
<setuid> Ok, let me try rewording it 
<seb128> if you want to play on the words, I don't want to start trolling
<setuid> dapper has a 2.6.15-whatever kernel by default.. 
<lifeless> setuid: there is a template
<lifeless> setuid: in the file
<seb128> find somebody else to figtr with
<lifeless> setuid: look for 'template'
<lifeless> setuid: it controls what the generated content looks like
<lifeless> setuid: and 
<seb128> ### BEGIN AUTOMAGIC KERNELS LIST
<seb128> ## DO NOT UNCOMMENT THEM, Just edit them to your needs
<setuid> I build and put System.map + kernel into /boot, and add the appropriate stanza in menu.lst
<seb128> did you follow those stuff?
<lifeless> setuid: you can put whatever you like outside of the ### BEGING AUTOMAGIC... END AUTOMAGIC section
<setuid> I add the kernel lines I require to the stanza
<lifeless> and update-grub won't touch it
<setuid> lifeless: I need it to be kernel-specific, not global
<seb128> after the automagic part?
<lifeless> setuid: in short, we know your problem, read the file content more closely, it does exactly what you need
<seb128> list your stuff after "### END DEBIAN AUTOMAGIC KERNELS LIST"
<setuid> Ok, so my kernel stanza should go below that dreck, gotcha
<setuid> I'll try that
<koke> anybody knows why update-manager is arch-dependant??
<seb128> the comments make it pretty clear
<setuid> There's a nasty glibc double-free bug that's trashing lots of apps 
<seb128> if people would start by reading ...
<lifeless> seb128: yeah.
<lifeless> seb128: we need a click through agreement obviously ;)
<seb128> hehe
<setuid> "people" should stop fucking with the default application behavior
<seb128> are you sure that the double free is from glib?
<setuid> glibc, not glib
<seb128> or that's rather glib detecting a double free from a lib?
<seb128> playing on words again
<seb128> libc if you prefer
<setuid> sec, it just happened with gdmsetup
<lifeless> setuid: glibc reports double frees, but it is not likely to be glibc itself *having* the bug
<setuid> glib != glibc, its not a play on words, its called being accurate
<setuid> lifeless: possibly
* setuid looks at the log
<seb128> right, but you made clear which one you were mentionning
<lifeless> setuid: try running gdmsetup under valgrind then
<seb128> there is some gdmsetup crasher and double free known
<seb128> and fixed with tarball rolled like 1 hour ago
<setuid> Lots of weird wacky things since moving from Breezy to Dapper
<seb128> going to be updated if I stop chating on IRC :p
<setuid> Lots of application behavior changed 
<seb128> welcome to an unstable distro
<setuid> Of course
<lifeless> seb128: shoo
<setuid> I ran Debian unstable for years, I know the drill
<lifeless> seb128: go package :0
<seb128> Debian unstable is not that unstable
<seb128> ie: we package unstable GNOME to experimental
<seb128> not to unstable
<astronut> seb128: what nick does he use?
<astronut> i had typed that, and forgot to send it
<seb128> buxy?
<astronut> oh, thought you meant he was "busy"
<astronut> sorry
<astronut> and just made a typo
<seb128> np :)
<ploum> hello cassidy :-)
<cassidy> hi ploum
#ubuntu-devel 2006-03-05
<sivang> is anyone using emacs21 under Xgl? ;-)
<Burgwork> sivang, that is an ambomination
* sivang dicts for the word
<tseng> he spelled it wrong so
<Burgwork> tseng, shhh! that was part of my "plan"
<tseng> Burgwork: ah :D
<sivang>   1. The feeling of extreme disgust and hatred; abhorrence;
<sivang>         detestation; loathing; as, he holds tobacco in
<sivang>         abomination.
<sivang>         [1913 Webster] 
<sivang> ?
<tseng> yes
<sivang> heh
<tseng> but used as a noun
* sivang waits for emacs21 to compile with debug symbols
<Burgwork> sivang, running a dated piece of 70s technology on modern bling
<sivang> hehe, indeed. What can I do if I got used to some of its niceities? ;-)
<sivang> (./me thinks if there are any other py editor that do not suck)
<trappist> sivang: I heard it fails in Xgl because it can't find rgb.txt, because the Xgl package was compiled with the wrong path to it
<trappist> err because it can't find 'black' because no rgb.txt
<sivang> trappist: do you happen to know the right path? My strace shows that it looks for it where I Put it, /etc/X11/rgb.txt
<trappist> sivang: I just overheard this in #ubuntu-xgl or somewhere.  I have no first-hand knowledge of the problem.
<sivang> trappist: okay, thanks anyway
* sivang fantasizes of his green emacs21 window in wobbely mode.
<sivang> Burgwork: I guess I'm a 70's hippie, after all :p
<trappist> I can't talk compiz into using mesa's libGL, so I'm fantasizing about anything in wobbly mode.
<Burgwork> to be honest, the most interesting thing I am looking forward to is expose-style window shrinking
<trappist> it's all about the live thumbnail previews.
<sivang> Burgwork: F12 does that for me
<sivang> Burgwork: it's way cool, I agree. and very productive
<Burgwork> sivang, vista has a cool feature on window switching
<tseng> Burgwork: xgl has thumbnail preview on window switching too
<tseng> if you turn it on
<Burgwork> tseng, cool, haven't played with xgl yet
<Seveas> xgl is a major cpu hog
<dholbach> hey haggai
<ploum> cassidy: http://ploum.frimouvy.org/?gallery/life-of-ploum/fosdem-2006/img00029  : some ubunteros @ FOSDEM sunday evening 
<cassidy> ploum: thx
<cassidy> ahh i'm half hidden :p
<ploum> I told you...
<ploum> Scandaleux
<cassidy> yep
<sivang> Burgwork: I hope we can give a good competition with Xgl to vista..
<ploum> Treenaks: ping ?
<ploum> cassidy: it can be cool if we can give names to people on this picture. I can only say jdub, vuntz, ploum, kikidonk and cassidy 
<cassidy> ploum: the other guy with me is not involved in Ubuntu. And my 2 neighbors at the table either
<ploum> oh... I tought
<ploum> Next year, we will do an Ubuntu Room !
<hunger> ploum: That would be great... then I might had actually found you guys.
<cassidy> it means that we have to choice between GNOME and Ubuntu devroom. Big dilemma :)
<ploum> cassidy: it would be indeed a big dilemna. But there are many ubuntu things to discuss
<ploum> hunger: indeed, it was difficult to find Ubuntu fans
<ploum> No stand, no room
<ploum> Ubuntu-be will solve this problem next year :-)
<cassidy> GNOME/Ubuntu entre les deux mon coeur balance ;)
<hunger> ploum: A stand is not really important IMHO... the people coming to fosdem know about ubuntu anyway.
<cassidy> ploum: ping me when the mailing list will be installed
<ploum> hunger: I agree. That's why I think a room it's better
<hunger> ploum: And the stands are in the hallways which are always so crowded that it is hard to stop and talk anyway.
<cassidy> hunger: i agree. Discuss about specific ubuntu discuss and meet ubuntu fans is more interesting
* hunger agrees.
<cassidy> s/discuss/stuff
<cassidy> (and drink beers ;)
<ploum> cassidy: I will have to annoy jdub
* hunger never understood the debian and gentoo stands... they got rooms to sit behind their laptops in.
<cassidy> let him time to go back to his home :)
<ploum> Anyone is aware of an easy way to convert a video to Theora/ogg ?
<ploum> Pitivi doesn't work as well as the demo at FOSDEM !
<hunger> ploum: What a surprise... ;-)
<hunger> ploum: I am sure apparmour won't work as well either;-)
<CarlFK> ploum: http://transcoding.org - easy once you have done it ;)
<subterrific> i need help figuring out what component to report a bug against
<ploum> CarlFK: isn't transcode a CLI tool ? (I'm just too lazy to read a man page like the mencoder one now)
<ploum> hunger: I've heard about apparmour but I was not at the talk. Was it interesting ? what was the demo ?
<CarlFK> ploum: yes, but there are some GUIs for it
<ploum> subterrific: what's the bug ?
* hunger found it very interessting.
<dholbach> good night everybody
<ploum> good night
<hunger> It is not as powerful as selinux, but it is way easier.
<subterrific> i tried doing a flight-4 install and it failed because update-initramfs -u was saying "Kernel too old, requires 2.6.12 or greater". the problem was that the /boot partition i selected had old kernels on it from an old breezy install
<hunger> ploum: The demo was writing a profile for a php-app in apache in less then 3 min.
<subterrific> is that an initramfs-tools bug or debian-installer or what?
<hunger> ploum: They got perl scripts to help with creating the profile... it just asks a couple of questions and you are done.
<spacey> would be cool to have it packaged for dapper *hint*
<spacey> although really late
<hunger> spacey: Too late I think.
<subterrific> i ended up fixing it by dropping into a console and removing all the symlinks and the old kernel from /boot and then rerunning update-initramfs -u
<ploum> subterrific: hmmm. I'm not expert at all. I would say : report it again intramfs (it's the part that produce the error). It could be changed later if it's wrong
<subterrific> ok, thanks
<hunger> spacey: It needs to be started as early in the boot sequence as possible... I doubt that somebody may change the bootup process for that at this point in time.
<ploum> hunger: seems intersting indeed. 
<spacey> hunger: yeah that would be a problem
<hunger> ploum: Well, it is by far not as powerful as selinux...
<ploum> I think that Dapper target is more Desktop. Apparmour seems to be mainly for servers
<Burgwork> ploum, hunger, ajmitch_ is the right person to ask about selinux and apparmour
<ploum> (of course there's Ubuntu Server ;-) )
<Burgwork> ploum, dapper is targetted at everything and so is app armour
<ploum> Burgwork: Apparmour on a desktop ? Really ? 
<hunger> ploum: Nope... he said he uses profiles for every app with network access (gaim, firefox) and pdf readers.
<ploum> hunger: I'm not a selinux expert at all
<Burgwork> ploum, it is very similar to selinux, with FC runs on their desktop
<ploum> oh so..
<hunger> ploum: Basically everything where there were recent exploits;-)
<ajmitch_> afaik, we'd have to choose one or the other
<ajmitch_> which won't be up to me
<Burgwork> ajmitch_, what is your gut feeling? is the additional "complexity" of selinux worth it, due to the greater support for it?
<hunger> ajmitch_: Not my task either... selinux is more powerful... but apparmour is way easier... I do not even want to decide that.
<hunger> Burgwork: I'd personally go for apparmour...
<ajmitch_> Burgwork: I feel selinux is a better choice, but that's from someone who hasn't looked at apparmour very hard
<Burgwork> hunger, have you used either?
<ploum> it's like choosing between Xgl and Aiglx (or whatever is the name) :-)
<ajmitch_> ploum: I'm afraid it's not :)
<hunger> Burgwork: I have not used apparmour... and I failed to get selinux configured, so I wouldn't listen to me if I had anything to say:-)
<Burgwork> hunger, hence why I asked ajmitch_ ;)
<setuid> Riddle me this, a source package for a dapper kernel should build out of the box, with debuild, right? 
<setuid> I mean... I'm _running_ the binary version of that kernel, so it built on at least 1 machine
<ploum> ajmitch_: it was just a joke. I'm not at all in technical details
<ajmitch_> setuid: yes, and I've built dapper kernels with just debuild (from the git tree)
<Burgwork> ajmitch_, it seems the main selling point of apparmour is that selinux is "hard"
<setuid> ajmitch_: Something is amiss with 2.6.15-16... gives me some weird error at boot about /dev/hda2 not existing, and dumps me to busybox
<hunger> Burgwork: It was at the demo at fosdem.
<ajmitch_> setuid: sounds like initramfs issues
<setuid> But /dev/hda2 works fine, 2.6.12-10 is booted to it (but no fxlrx driver support in 2.6.12)
<setuid> ajmitch_: Ok... lemme check that
<setuid> initramfs support packages are onboard, what else should I poke at? 
<ajmitch_> Burgwork: of course, and having simplicity as a selling point of security isn't necessarily good
<hunger> Burgwork: That and that apparmour works with all apps while selinux is supposed to have apps linked to some lib.
* ajmitch_ could pull up examples of why path-based MAC is bad, and all other stuff
<ajmitch_> hunger: vile lies :)
<ajmitch_> hunger: a *few* apps get linked to libselinux, to get things like listing security contexts, etc
<hunger> ajmitch_: I am just repeating what I heared. As I said: I was too stupid to work out selinux.
<Burgwork> ajmitch_, I would love to see selinux or something similar for dapper+1
<ajmitch_> hunger: no, integrating something like that into a distro is not easy
<ajmitch_> it's not a matter of stupidity
<ajmitch_> Burgwork: sure, and for a change there are others willing to help out, mainly in debian
<Burgwork> seems like either apparmour or selinux is simply a lot of work, either way
<hunger> ajmitch_: And frankly I do not feel comftable with the idea of having several independent sets of permissions (filesystem and selinux/apparmour whatever).
<ajmitch_> there's a very capable team of people doing selinux in debian now
<ploum> good night
<Burgwork> ajmitch_, they might ship you to Germany in May if you offer to do selinux for dapper+1
<ajmitch_> Burgwork: hah funny
<Burgwork> ajmitch_, honestly, I would email Mark and say thta
<Burgwork> because something like selinux would need to be decided as a goal at teh conference, due to its tentacles of doom nature
<ajmitch_> Burgwork: what do you think I specced at the last 2 conferences?
<Burgwork> indeed
<hunger> Burgwork: And some really good docu will need to get written or too many people will just deactivate it (or - god forbid - leave for debian;-)
<ajmitch_> hunger: fyi, https://alioth.debian.org/projects/selinux/
<hunger> ajmitch_: I know there is a project about selinux in debian, but it will take AGES to get that done there (if at all). Ubuntu can be much faster if you guys ever set your mind on getting it in.
<ajmitch_> hunger: who are these 'you guys' that are so willing to help out?
<hunger> ajmitch_: The ubuntu developers. I am just a user listening in on you;-)
<ajmitch_> the difference between ubuntu & debian is that there are people willing to do the work in debian
<Burgwork> ok, I have now tried twice to kill the alternate init thread without success
<ajmitch_> hunger: 'the developers' is a vague enough term - it's pretty much just been me who's cared in ubuntu
<ajmitch_> Burgwork: some things just need to die naturally
<Burgwork> ajmitch_, sadly yes. Until then, hundreds of people will have more crap in their inboxes
<Burgwork> one thing I noticed about the Fedora devel list is they don;t have the same policy of shutting people down who are posting things that belong on other lists
<ajmitch_> at least it's not as nasty as the python stuff thread
<Burgwork> yes
<hunger> ajmitch_: Maybe. But ubuntu has fewer developers that need convincing.
<ajmitch_> where the developers were accused of all sorts of incompetence
<ajmitch_> hunger: good, get to work convincing them
<hunger> ajmitch_: Me? I'm just a user listening in here;-)
<ajmitch_> yeah right
<hunger> ajmitch_: And I am not convinced myself yet.
<ajmitch_> saying 'the developers should..' without backing it up, is what doesn't work
<ajmitch_> few developers means they're all stretched thin
<hunger> ajmitch_: I personally think security should be tightened somehow, I am just not yet sure selinux is the thing for me.
<j^> is network-manger broken by the latest gnome-keyring upload?
<Burgwork> ajmitch_, to be fair to Ubuntu, it is much younger and the paid developers have a great deal on their plates
<hunger> ajmitch_: As I said earlier: it basically introduces another priviledge system that is independent of the traditional filesystem descretionary one.
<dieman> http://www1.umn.edu/ohr/employment/openings/job135042.html
<dieman> bwhaha
<dieman> ubuntu experience as part of the qualifications
<dieman> (its a repost for an internal canidate due to stupid hr rules)
<dieman> but still
<Burgwork> dieman, where di you find that?
<ajmitch_> hunger: which is the intended behaviour, because discretionary access control is seen to be limited
<ajmitch_> dieman: at least it didn't mandate 3 years ubuntu experience
<dieman> ajmitch_: ahahah
<dieman> Burgwork: i work there
* Burgwork has 12 years of Ubuntu experience and 9 years of Windows XP experience
<dieman> Burgwork: the posting is one of my coworkers who was on a 6month temp positing
<dieman> this one is a 12mo temp posting
<dieman> its hr hell
<Burgwork> ah
<ajmitch_> Burgwork: the developers having a lot on their plates is what I'm saying - there need to be very good reasons for resources to be allocated to tasks
<dieman> you can't just 'make jobs'
<Burgwork> there are good reasons for taht
<hunger> ajmitch_: Yes, I see that. I wouldn't mind if the old one could get removed altogether (which is obviously impossible). It just sucks having two systems for the same thing.
<subterrific> ok, one more question. after i got my flight-4 install to finish and then rebooted. it had set the grub root to (hd2,0) which was wrong and I was left with a 'Error 15: file not found' message. i had to manually change it to (hd0,0) so grub could find the kernel. what component is that a bug for?
<ajmitch_> hunger: they complement each other - selinux takes DAC permissions into account as well
<hunger> ajmitch_: So if I were convinced of selinux: What could I do to help in the limited time I have.
<subterrific> grub-installer perhaps?
<ajmitch_> hunger: we're past feature freeze for dapper - most work is in debian on the packaging of the reference policy right now
<hunger> ajmitch_: Yes, to some extend. But having ACLs and owner-group-other permissions will confuse the hell out of me:-)
<ajmitch_> once that is in a usable state (which I started work on), then testing & tools is what's important
<ajmitch_> hunger: you generally don't need to worry about them
<hunger> ajmitch_: I can test, I'll unable to stay on a stable system anyway:-)
* ajmitch_ can't do much at the moment, too busy with work
<hunger> ajmitch_: Oh, believe me: I will need to worry about them! I change too many things on my systems not to run into that at some point.
<hunger> ajmitch_: Just tell me when there is anything to test. I'll do so if I have the time.
<ajmitch_> ok
<dieman> im still bummed out that i wont get to play with nfsv4 with dapper it sounds
<dieman> since it breaks mounting sarge nfs userspace server mounts
<dieman> no nfs filesystem acls for us just yet.
<jdong> where would I go to ask questions about the Ubuntu website?
<jdong> mainly relating to the licensing of the stylesheets
<CarlFK> jdong: try /join #ubuntu-doc
<jdong> thx
<subterrific> ok, 3 bugs reported i encountered installing flight-4 last night: 33101, 33104, and 33106
<Burgwork> subterrific, if they are filed, that is the correct place for disuccsion. I would also try the dailies
<CarlFK> dapper installer errorrod, then hit 'go back" and dinked a bit - now I am looking at var/log/syslog tryihng to find the details of the error - what should I be searching for?
<CarlFK> "[Ee] rror" isn't it
<CarlFK> here is all 400k of it: http://dev.personnelware.com/carl/temp/Feb27/e/log/syslog
<CarlFK> found it
<CarlFK> duh... ERROR
<setuid> hrm, loop-aes-utils doesn't allow >128bit passwords!?
<setuid> arg
<setuid> ioctl: LOOP_SET_STATUS: Invalid argument, requested cipher or key length (256 bits) not supported by kernel
<setuid> It worked in breezy, I wonder why it was crippled for dapper
<jk-> Riddell: ping ?
<hunger> setuid: loop-aes is deprecated anyway.
<setuid> hunger: In favor of...? 
<setuid> hunger: I have a partition encrypted with aes256, and I need to access the data on it 
<setuid> losetup -e aes256 -C3 -S SuperSecret /dev/loop0 /dev/hdc1
<setuid> blah blah
<setuid> That doesn't work in dapper, works in breezy
<mjr> are you sure you've installed the separate loop-aes kernel module in dapper?
<setuid> Yep
<hunger> setuid: Use devicemapper. loopaes has sever problems with its implementation and was deprecated.
<setuid> hunger: Any docs on that? 
<hunger> setuid: google for cryptsetup:-)
<setuid> I have that installed, problem is, I need to get into the partition as it is now
<setuid> I can't just use cryptsetup, blow away 300GiB and start over
<setuid> KNOPPIX can do it, but KNOPPIX (4.0.2) has *PITFULLY* slow usb implementation (200k/sec. max, over a usb2 that I get 40+MiB on regular transfers) 
<hunger> setuid: The algorithem for encryption is identical. It is just the hash alg. used to generate the key that differs.
<setuid> Sure, which means it won't work 
<hunger> setuid: So you can make cryptsetup read loopaes partitions IIRc.
<setuid> Note the -C3 above
<hunger> setuid: "All" you need to do is find the right hash alg. and force cryptsetup to use that:-)
<mjr> afaik cryptsetup is backwards-compatible with regular cryptoloop, but not loop-aes
<setuid> Sure, and then hash it 3 times with my seed, which cryptsetup does not support
<setuid> mjr: Correct
<setuid> I'd just like to know why it was crippled in dapper, and not in breezy
* mjr uses loop-aes incidentally also, with breezy
<hunger> setuid: Oh... then you are in trouble:-(
<setuid> It may be deprecated, but functionality should not have been _removed_ 
<mjr> seemed to have better options
<mjr> what with the multi-key-3 mode
<hunger> mjr: Have you looked into LUKS?
<mjr> I've glanced at it
<setuid> mjr: Got a dapper install somewhere? 
<mjr> on my laptop
<hunger> mjr: Stores all the details for you and is way nicer then anything else I used so far.
<mjr> (where there's no encryption as of yet)
<mjr> ah well, I have the crypted fs mirrored so I can re-encrypt it easily by disengaging the mirror for a while, if need be
<setuid> mjr: Just try to create a loopback file with aes256 under dapper
<setuid> For some reason, it ignores 256 and 128-bit keys... probably some other bug lurking
<hunger> setuid: There is a script to access loopaes on dmcrypt here: http://clemens.endorphin.org/Cryptoloop_Migration_Guide
<setuid> hunger: I'm not using dmcrypt, but I'll take a look
<hunger> setuid: Dunno whether that will work for you.
<setuid> I'll just decrypt this, blow it away and rebuild it 
<setuid> I set it as xfs anyway, which is bad to do on a crypted volume anyway
<mjr> setuid, sure you're using loop-aes-utils versions of losetup?
<hunger> setuid: I'd recommend using devicemapper with LUKS then:-)
<setuid> hunger: I need something that is distro-transparent, i.e. works with KNOPPIX and similar tools
<setuid> mjr: Yes
<hunger> setuid: Try the script... it should be able to mount loopaes volumes via devicemapper.
<hunger> setuid: LUKS is meant to be distro-transparent. IIRC gnome-volume-manager supports it nowadays, so it can not be purely ubuntu;-)
<mjr> hunger, that work for multi-key-modes 2 and 3 too?
<setuid> hunger: Looks like that script is missing a good whack of functionality, specifically the target partition, mount point, seed and cipher number
<hunger> mjr: It should with a bit of twiddling;-)
<mjr> sure, anything works when you twiddle enough source code
<setuid> Precisely ;) 
<hunger> mjr: calling hashalot several times should make that work I think. But I have never tried it, just stumbled over it googleing for setuid;-)
<mjr> that just hashes the password
<setuid> Yeah, this script is very non-functional
<setuid> sigh
<setuid> Thanks for the googling though
<hunger> setuid: Too bad:-( I feel for you, I reencrypted my volumes several times so far as well:-(
<mjr> pardon me, but my loop-aes setup has 64 different aes256 keys and one extra key for IV computation
<mjr> I fail to see how this script makes use of that info
<setuid> Mine is a bit simpler than that. 
<setuid> Which kernel module (besides aes and aes_i586) do I need? 
<setuid> min keysize  : 16
<setuid> max keysize  : 32
<setuid> ugh
<hunger> mjr: Been a while since I used loopaes.
<hunger> setuid: Tried using bytes instead of bits?
<hunger> setuid: I guess you can't change that.
<setuid> Nope
<setuid> arg
<setuid> # losetup -d /dev/loop0
<setuid> ioctl: LOOP_CLR_FD: Device or resource busy
<mjr> hmh, I'd have to check how luks handles multi-key and IV before switching to that...
<setuid> This is so broken, I think I'm going to go back to Breezy or Sid
<mjr> cbc-essiv, mmh
<setuid> man, its taking this machine like 2 hours to build this kernel package... a normal (kernel.org) kernel build is like 7 minutes. 
<setuid> whoa, kernel just finished, now its doing modules. There must be some sort of a recursive loop here
<CarlFK> someone want to throw me a Package Name for a bug on the installers partitioner
<CarlFK> partconf-find-partitions
<setuid> Ok, more snags... how the heck do I compile the vmware modules on a distro-supplied kernel? I'm in a catch-22. I can't run dapper without fglrx (ATI hard-locks Thinkpads), and I can't build my own kernel from source because fglrx doesn't build clean. 
<setuid> So I've got 2.6.15-16 installed, but now vmware wants kernel headers, but they don't exist, because this kernel was built as SMP, even on UP machines. 
<setuid> Arg! 
<setuid> So where are the headers for _this_ kernel? 
<pingu> I. Need to get a custom 2.6.15 kernel onto an AMD64 Ubuntu install CD.
<pingu> Does anyone have any suggestions?
<pingu> That would be a no :/
<theCore> does anyone here know why Yelp doesn't render some characters?
<theCore> I would like to fix that, as soon as possible, because it's really annoying
<pingu> Does anyone here know anything about the install CD?
<pingu> Can't seem to find where the modules go, there is a vmlinuz image in install though.
<pingu> I somehow think replacing that just isn't going to do it for me.
<TheMuso> pingu: They are in the initrd.gz image.
<psusi> pingu, there's a howto on the wiki
<pingu> Thanks TheMuso!
<pingu> A little late, but thanks.
<pingu> psusi, I've seen the one which mentions just editing preseeds.
<pingu> But, I need a different kernel, that's a little beyond the preseed ;D
<pingu> Is there any way I can get a snapshot of the current kernel used on the livecd, anyone?
<pingu> As in, before it was compiled?
<Kyral> uhh, linux-source from the Dapper Repos?
<jk-> Lathiat: ping ?
<pingu> Not dapper, but the install CD?
<pingu> I'm specifically trying to get the sources of:
<pingu> The AMD64 kernel booted on the 5.04 install CD.
<infinity> pingu: Same answer.  If you want the kernel from 5.04, you want linux-source-2.6.10 from the hoary archive, if you want the kernel for 5.10, you want linux-source-2.6.12 from the breezy archive...
<pingu> So the install CD.
<pingu> Is just a stock kernel?
<pingu> *install CD's kernel.
<infinity> Yes.
<Lathiat> jk-: pong
<jk-> Lathiat: hey!
<pingu> infinity: What about all those extra module packages, does the install CD shove those in the initrd too?
<infinity> pingu: That's the idea, yes.  They're only broken out into seperate packages for the installer, they're all in one package on the installed system, but it's the same kernel build, just split differently.
<pingu> Thanks for your help.
<dholbach> good morning
<pingu> Good afternoon.
<LaserJock> good evening ;-)
<pitti> Good morning
<stub> Launchpad is going down in 15 minutes time, which will also put the wikis into read only mode. Estimated down time is 10 minutes.
<Mez> mdz: ping
<mvo> Mez: he might be sleeping, it's late in his TZ
<Mez> it's for when he's back
<mvo> k
<Burglaptop> mvo: it is only just past midnight here
<mvo> Burglaptop: some people consider this late ;) but you are right of course, it's not a unusual time 
<pingu> Oh noes. I'm still at work.
<pingu> Bye everyone!
<Kamion> CarlFK: by the way, I recommend just using "debian-installer" if you don't have sure knowledge of the correct component name rather than picking one that includes "part" in its name ;-)
<sivang> morning everybody
<Kamion> mvo: could apt.InstallProgress.updateInterface() perhaps call a method when the percentage/status changes and the status isn't pmerror or pmconffile?
<Kamion> mvo: at the moment I don't really see how to properly handle percent/status changes without rewriting updateInterface, since the default implementation changes self.percent and self.status even for pmerror and pmconffile when the values will make no sense as percentages or statuses
<Kamion> mvo: also using the errno module for EAGAIN would be better than hardcoding 11
<pitti> infinity: do you think it'll be necessary to rename mozillla-thunderbird-locale-all as well? After all, these xpi are from official mozilla...
<pitti> infinity: and we didn't rename mozilla-firefox-locale-all either
<Kamion> mvo: and shouldn't you limit the split() to (status, pkg, percent, status_str) to 3 splits so that you don't inadvertently split on colons in status_str?
* Kamion decides to rewrite anyway, being scared by the code now :)
<mvo> Kamion: hello, sorry, I got disconnected
<mvo> Kamion: can you /msg me the bits I missed?
<infinity> pitti: I'm not picky one way or the other, and I doubt they are either, but from a UI perspective, if you have a package called "thunderbird" installed, you're going to look for "thunderbird-*" packages to extend its functionality, not "mozilla-thunderbird-*"
<cprov> slomo: ping
<cprov> slomo: anyway, head-up on missing orig for liferea upload, see you later
<slomo_> Kamion: hi... please move gtk-sharp to universe and gtk-sharp2 back to main :) gtk-sharp2 was approved already before breezy release and now nothing in main depends on gtk-sharp anymore
<Kamion> is gtk-sharp2 just a renaming of gtk-sharp2-unstable?
* Kamion is looking for a suitable main inclusion report, y'see
<slomo_> Kamion: yes
<Kamion> gecko-sharp2 and gtk-sharp2 promoted; you might like to get somebody to look at seeding appropriate documentation packages from those sources
<Kamion> gtk-sharp-gapi demoted, but according to anastacia the rest of the binaries from the gtk-sharp source are still in use somewhere
<slomo_> Kamion: yes, tomboy depends on it currently and the version which uses gtk-sharp2 is on dep-wait atm... this will solve itself after the gtk#2 version of tomboy built?
<Kamion> presumably
<Kamion> until then it'll stay in main
<slomo_> ok... shall i ping you when it built?
<Kamion> also dbus Build-Depends-Indep: libgtk-cil
<Kamion> no need, it'll show up in anastacia and there's usually no great rush for demotions anyway
<slomo_> not anymore in the latest version of dbus
<Kamion> I'm looking at dbus 0.60-6ubuntu1, which is the current version in dapper
<slomo_> ok, thanks :)
<Kamion> although it failed to build, but even so
<slomo_> huh? i'll take a look at it
* sivang arghs as tomboy crashes when pasted text into one of its note windows
<slomo_> Kamion: yes, was a mistake while merging dbus...
<sabdfl> who moderates ubuntu-devel-announce?
<pitti> sabdfl: Kamion at least
<sabdfl> Kamion: could you give my post the go ahead when next you look at that queue please? not urgent
<sabdfl> just a pointer to https://wiki.ubuntu.com/DapperIcons
<dholbach> sabdfl: they look nice - who worked on those?
<sabdfl> dholbach: professional icon team
<Kamion> sabdfl: done
<dholbach> Cool!
<pitti> sabdfl: nice; SVG and all that?
<sabdfl> jane and i leading the specification, jdub prioritising
<tepsipakki> they indeed look great
<jpatrick> tepsipakki++
<tepsipakki> the cd/dvd-icons that specify which media it is.. just like on OSX ;)
<tepsipakki> (which I haven't even used, just seen over the shoulder)
<seb128> nice
<Kamion> Keybuk: my bad on floppy, I misread the code
<Kamion> Keybuk: ide-floppy as well?
<Kamion> or will that be autoloaded?
<Keybuk> I think ide-floppy will be autoloaded
<Keybuk> SUBSYSTEM!="ide", GOTO="ide_end"
<Keybuk> IMPORT{program}="ide_media --export $devpath"
<Keybuk> ENV{IDE_MEDIA}=="floppy",               RUN+="/sbin/modprobe -Qba ide-floppy"
<Keybuk> so yeah, that one's detectable
<Keybuk> (ignoring the bug that udev doesn't work with anything above hdf :)
<Kamion> Keybuk: ok - will adding floppy to /etc/modules close #32599?
<Keybuk> yup
<Kamion> ok
<Kamion> Keybuk: the one concern I have is that modprobing floppy can be quite slow
<Kamion> it certainly at least used to take a while in the installer on some machines, because it sat there synchronously trying to find floppy drives
<Kamion>      - Use x rather than x in progress bar
* Kamion wonders if that's Soyuz "helpfully" smashing everything to ASCII
<Keybuk> Kamion: other than 
<Keybuk> probing it in the background, what other solution is there
<Keybuk> like you say, the module itself looks for the drives
<Kamion> Keybuk: well, yeah, I'm just bringing it up since you care about boot times
<Keybuk> so until we load the module, we don't know that there *are* drives
<Keybuk> while you're in there, could you remove mousedev from /etc/modules? :p
<Keybuk> it's compiled in
<tepsipakki> I have a intel-iMac at my disposal.. does the installer have any chance of working with that, or is it even considered to be supported hardware for dapper?
<Kamion> tepsipakki: I doubt it'll work yet, but if you have it convenient then telling us where it breaks would be *very* helpful!
<Kamion> I don't even know whether it has VESA compatibility
<Kamion> tepsipakki: we (Canonical) have been trying to order one for testing, but as I understand it the order won't come through for a while yet
<tseng> someone has hacked together a working knoppix cd with the relevant driver love
<tepsipakki> Kamion: ok, I'll try to get it netboot ;)
<tepsipakki> (whee, EFI looks nice ;)
<Kamion> tepsipakki: doesn't it boot from CD?
<tepsipakki> probably
<tepsipakki> but that's lame ;)
<Kamion> it would be a more helpful test I think
<tepsipakki> ah, ok
<Kamion> since practically nobody will netboot those things just yet
<tepsipakki> hehe
<Kamion> netboot would be good too, but it can come later ...
<Kamion> tseng: do you have a URL?
<tepsipakki> sure, is flight-4 the one to test=
<tepsipakki> ?
<tseng> Kamion: sure, lemme look
<Kamion> tepsipakki: that or a current daily
<Kamion> pitti: shouldn't locale-gen do mkdir -p "$SUPPORTED"? I have locales installed, but no /var/lib/locales/supported.d
<Kamion> and locale-gen fails
<pitti> right, it should
<pitti> Kamion: ah, the preinst generates it, but only for upgrades
<pitti> Kamion: will fix that
<tseng> Kamion: http://www.osxbook.com/book/bonus/misc/linux/
<tseng> Kamion: i thought this was a full knoppix iso, it seems to be something less
<tseng> Kamion: but the experience seems to be relatively well documented
<WaterSevenUb> pitti, dumb question. I may (or I should) close something like this https://launchpad.net/distros/ubuntu/+bug/19474 given that https://wiki.ubuntu.com/LangpacksDesktopfiles implemented?
<Ubugtu> malone bug 19474 in Ubuntu "desktop file translations are not updated with langpacks" [Wishlist,Confirmed]  
<Kamion> hmm, so no BIOS, EFI only, that'll be interesting
<Kamion> my impression is that we don't have free X drivers yet, so we're probably screwed on that front
<Kamion> pitti: thanks
<Kamion> but it may be possible to figure out how to produce a hybrid ISOLINUX/elilo ISO image
<pitti> WaterSevenUb: right, thanks for reminding me; I'll close it
<Mithrandir> Kamion: as long as you keep the VESA fb around, you should be able to run VESA, I think
<Keybuk> Kamion: EFI is easy enough ... cf. ia64
<Kamion> unfortunately the Intel reference EFI implementation is non-free
<Kamion> Mithrandir: that seems to be what the mactel lot are doing, yes
<Keybuk> I believe that people have them booting with elilo and keeping around the boot-loader framebuffer to get a console
<Kamion> the mactel people are using GraphicsConsole.efi from the Intel EFI implementation to get the console, and then chaining to elilo
<Keybuk> pitti: strange ... I just got my iAudio mounted as /media/sda1 not /media/iAudio
<Kamion> unfortunately the former piece is non-free
<WaterSevenUb> pitti, only the "assigned to" person can do it? the initial reporter can't or shouldn't do it?
<pitti> WaterSevenUb: oh, I think everyone can
<pitti> Keybuk: but sudo blkid /dev/sda1 can figure out the label?
<Keybuk> /dev/sda1: LABEL="iAudio" UUID="43DB-3ADE" TYPE="vfat"
<Keybuk> it's worked every single time except for today
<Keybuk> hal got upgraded yesterday
<Kamion> hmm, and Apple's EFI implementation apparently doesn't support UDF or ElTorito
<pitti> Keybuk: indeed, for my USB stick, too
<pitti> Keybuk: thanks for pointing that out, I'll investigate
* pitti adds to TODO
<Treenaks> pitti: btw, the mounter doesn't look in the right place for the label with LUKS-encrypted volumes
<pitti> Treenaks: we currently can't support label reading on crypto devices
<Treenaks> pitti: I think it looks at /dev/sda1 (the original place) instead of /dev/mapper/_dev_sda1 (the dm_crypt mapped one)
<pitti> we will in dapper+1
<Treenaks> pitti: cool
<pitti> when we switch to gnome-mount
<pitti> but that's too late for dapper
<Keybuk> pitti: volume.label is right in hal-d-m
<Keybuk> what's gnome-mount?
<Kamion> oh, actually, a hybrid El Torito / HFS+ image like we use for powerpc would probably do it
<pitti> Keybuk: a wrapper around hal's new Volume method to read user's gconf settings and so on
<pitti> Keybuk: at least that's what it's meant to be
<Treenaks> pitti: replacement for g-v-m?
<pitti> right now it doesn't evaluate any gconf settings
<Treenaks> pitti: or replacement for pmount?
<pitti> Treenaks: neither
<pitti> Treenaks: replacement for the hal fdi files which determined policy
<Treenaks> extra layer between those two?
<pitti> Treenaks: once we can make hal to handle the VOlume methods in a safe fashion, we could drop pmount for that
<pitti> or change gnome-mount to use pmount, whatever we like
<pitti> right now I disabled mounting through hal since it's nowhere near safe
<pitti> Keybuk: ah, bug 33120 matches your problem :)
<Ubugtu> malone bug 33120 in hal "HAL 0.5.7 broke /media/{labelname}" [Normal,Unconfirmed]  http://launchpad.net/bugs/33120
<Keybuk> you don't keep an eye on your incoming bugs too, eh? :p
<pitti> I just did the first time for today
<Keybuk> I don't know why I don't ... there's something about the way Malone floods you with incoming e-mail that makes it damned hard to deal with my "bugs" folder
<Keybuk> if I could put my finger on it, I'd file a bug
<pitti> Keybuk: mail works pretty fine IMHO, but browsing in the UI sucks a lot
<pitti> but Malones' email interface was broken a few days back, too, which hurted a lot
* pitti hopes it's fixed again, will try out later
<Keybuk> yeah, the UI seriously needs a "show me all bugs I probably care about" mode
<pitti> ... on *one* page
<Keybuk> rather than the kooky "bugs I'm assigned to" thing, which misses all the new ones
<Keybuk> totally
<siretart> isn't that wat 'subscribed bugs' are supposed to be
<Keybuk> pitti: I do wish Malone wouldn't mail me my own bug traffic sometimes though
<Keybuk> I clear out the bugs folder, do a bunch of stuff, and have to clear it out again
<Keybuk> siretart: that doesn't seem to include Assigned bugs
<Keybuk> I have bugs in my assigned list that aren't in that one
<Keybuk> you seem to be able to be assigned but not subscribed
<Keybuk> not to mention subscribed includes reported bugs, which I don't want to see when I'm in a "things I need to fix" mood
<siretart> thats strange
<siretart> usually, when I think that somebody should look at, but I don't want to assign him this bug, I subscribe him and make a comment. so he gets the email
<ogra> Keybuk, just get a secretary :)
<Keybuk> siretart: heh, I hate it when people do that ... because I nearly always miss the context of when they subscribed me
<Keybuk> the UI doesn't say "YOU WERE SUBSCRIBED HERE" in the list of comments
<Keybuk> so I'll read the first 3 or 4, decide the bug has nothing to do with me, and unsubscribe again
<Keybuk> then discover later than the 15th or 16th comment explained why I was copied in
<siretart> Keybuk: I see. I try to avoid that by giving the reason for subscribing (you) in the very first comment after subscribing. But I see your point
<Keybuk> siretart: yeah, I make sure I put the person's name in the comment, then they can grep the UI for it
<Keybuk> usually at the start, e.g. "Kamion, can you ..."
<siretart> right
<siretart> btw, does anyone know if madwifi-ng is going into dapper?
<siretart> I've seen some test packages from infinity, but they seem not to be in dapper yet. I've yet noticed 'scanning problems' in recent madwifi uploads
<Keybuk> most likely not
<Keybuk> seb128: ping?
<seb128> Keybuk: pong
* Mithrandir ruffles avahi
<Keybuk> seb128: you remember I told you that Monospace was "dancing" in gnome-terminal
* Treenaks pokes it with a long pointy stick
<Keybuk> I managed to capture it
<Keybuk> http://people.ubuntu.com/~scott/dance.gif
<Keybuk> (or just the sequence: http://people.ubuntu.com/~scott/dance.png)
<Treenaks> Keybuk: !! we love you!
<Treenaks> Keybuk: I have this all the time
<Mithrandir> Keybuk: shiny
<Mithrandir> try turning off gif animations.
<Mithrandir> :-P
<seb128> ah, nice :)
<Keybuk> ahh, I'm glad I'm able to hit Mithrandir in real life <g>
* Mithrandir ruffles Keybuk too
<Keybuk> seb128: where should I file the bug?
<seb128> Keybuk: that is a good question ... and I'm not sure. I would try vte :)
<dholbach> seb128: say something we don't have anything to do with... say freetype or something
<Treenaks> dholbach: 'X bug'
<seb128> dholbach: you do freetype ...
<dholbach> i don't
<dholbach> seb128: Riddell touched it last
<dholbach> woohoo!
<seb128> ah, nice :)
<Mithrandir> f is almost g, so that clearly falls into the jurisdiction of the gnome team.
<Mithrandir> I love the concept of "touched it last" maintainers
<seb128> we have been relocated
<seb128> we are "Desktop Team" now :)
<Mithrandir> so you get all the d* and the g* packages?
<dholbach> f...
<Keybuk> and the f packages
<Treenaks> seb128: you do KDE and XFCE too now?
<seb128> Treenaks: no way :p
<Mithrandir> desktop is almost spelt with an f.
<Treenaks> dethktop
<Mithrandir> defcop
<seb128> and no, we don't do dpkg
<Mithrandir> dpkg is love
<Keybuk> Package: dpkg
<Keybuk> Maintainer: Tollef
<Keybuk> muahaha
<Keybuk> nah, you're safe from dpkg ... iwj touched it last
<Mithrandir> the loop is complete.  The universe may die now?
<G0SUB> hello! there is a bug in malone #1299 
<Ubugtu> malone bug 1299 in librmagick-ruby "Image.read(filename) eats characters from filename" [Major,Confirmed]  http://launchpad.net/bugs/1299
<G0SUB> the only way to fix it is to backport the latest version to Breezy
<Keybuk> bah
<Keybuk> launchpad doesn't know person "treenaks"
<Treenaks> Keybuk: it knows 'martijn' though
<Keybuk> Treenaks: I went for van de streeeeeeek
<G0SUB> i am fixing it ... will you guys review it and upload?
<Keybuk> and now I'm going to file another annoying launchpad ui
<Keybuk> the fact you have to open and close the drop down without changing it to MAKE THE DAMNED FORM SUBMIT
<infinity> Keybuk: That's because buttons are *SO* last year.
<Keybuk> right, bug 33145 filed
<Ubugtu> malone bug 33145 in malone "Cannot submit form if Person requires clarifying without doing a non-obvious no-op" [Critical,Unconfirmed]  http://launchpad.net/bugs/33145
<Keybuk> and bug 33144 for seb128 and dholbach :)
<Ubugtu> malone bug 33144 in vte "Bold fonts do the mambo" [Normal,Confirmed]  http://launchpad.net/bugs/33144
<HiddenWolf> Well, at's least it's a cheery bug. :)
<seb128> Keybuk: do you use a special tex mode?
<Keybuk> seb128: just the default one, why?
<seb128> Keybuk: because my tex mode doesn't looks the same and doesn't use bold fonts, but it might be a custom one
<Treenaks> Keybuk: my comment added
<Keybuk> seb128: odd, I don't even fiddle with fontification uch, just force global-font-lock-mode on as usual
<Keybuk> obviously it's not just the TeX mode that shows it up ;)  but that happens to be what I'm doing currently
<Treenaks> Keybuk: it's reproducible in vim perl mode as well, just use that ;)
<Keybuk> and a treenaks points out, not just emacs
<seb128> I've no bold font with vim and syntax on a perl stuff neither
<Keybuk> Treenaks: you forget what company I work for ... using Perl is a sackable offense
<seb128> what font do you guys use?
<Keybuk> Monospace
<Treenaks> Keybuk: Not using perl is, for me...
<Treenaks> 'Monospace 7' here
<Keybuk> Bitstream Vera Sans Mono
<Treenaks> (yes, 7)
<Keybuk> Monospace 10
<Keybuk> at 75dpi
<Treenaks>   resolution:    99x98 dots per inch
<Keybuk> (though I see it on my desktop at 96 dpi too)
<Keybuk> Treenaks: check System -> Preferences -> Fonts -> Details
<Treenaks> 96
<Keybuk> seb128: Subpixel Full RGB
<Keybuk> (for the rest of the details)
<Treenaks> same here
<seb128> k, I get it too
<sivang> Kinnison: ping, have you managed to solve your emacs problem under Xgl? 
<slomo_> Kinnison: short question... would it be possible or is it planned to open a bug automatically when a package FTBFS (and close when package builds fine again, reopen when it fails again + comment with buildlog etc)?
<Kinnison> sivang: no, sorry
<Keybuk> slomo_: that way lies madness
<Kinnison> indeed
<Kinnison> madness
<Keybuk> packages fail to build for more reasons than you'd believe
<Keybuk> Jeff uploads new glibc, after a day of every single upload generating a new bug report every hour, we'd kill him
<Keybuk> and we need Jeff
<slomo_> hm ok... but some kind of FTBFS notification would be nice ;)
<Keybuk> we have them
<Keybuk> it's called "infinity"
<Keybuk> and if you care more than waiting until Adam notices, the build logs are available on Launchpad for your own interest
<Keybuk> usually if you upload and care, you'll notice binaries not showing up in short order, and investigate yourself
<Keybuk> Kinnison: some kind of bayesian analysis of build logs? :p
<slomo_> Keybuk: yes sure... i care for my uploads but what is with automatic syncs after dapper?
<Keybuk> train crm114 to detect failed builds, and successful builds
<zakame> ooh madness!
<Keybuk> slomo_: they'll get noticed by buildd admins, who'll file a bug in the right place
<zakame> hi everyone
<slomo_> Keybuk: sounds ok... but much work for them when they do that for universe too
<infinity> slomo_: It's my intention, once finer-grained ACLs are done in launchpad's buildd interface, to train a well-trusted MOTU and get him to handle some of the workload for universe buildd wrangling.
<zakame> infinity: I'm interested :)
<infinity> slomo_: I suspect this is a post-dapper goal, given how many other features we need in place before that.  But it'll happen.
<slomo_> infinity: thanks :) it isn't that urgent right now as now everybody should care for their uploads and nothing is getting in automatically ;)
<setuid> What provides the /media/* hookups? udev? For some reason, I only have /media/sdc1 style mounts, not /media/usbdisk-1, and so on. 
<Mithrandir> setuid: gnome-volume-manager and pmount-hal
* setuid checks
<setuid> Ok, I have gnome-volume-manager and pmount installed, what must I tweak? 
<Mithrandir> setuid: it ought to just work
<Keybuk> setuid: bug 33120
<Ubugtu> malone bug 33120 in hal "HAL 0.5.7 broke /media/{labelname}" [Normal,Unconfirmed]  http://launchpad.net/bugs/33120
<Keybuk> seb128: odd, I get NXDOMAIN for qa.mandriva.com
<Keybuk> actually, not true, I get SERVFAIL
<seb128> WFM
* Treenaks hands Keybuk a proper DNS server
<Keybuk> Treenaks: hand it to Tollef, I'm at his office
<ogra> ogra@edubuntu:~$ host qa.mandriva.com
<ogra> Host qa.mandriva.com not found: 2(SERVFAIL)
<ogra> same here 
<Keybuk> grr ... gnome-terminal is now doing its "I'm not going to start another one, ha-ha" bug
<Keybuk> Treenaks: just tried a scratch recursive lookup, and the dns server is definitely down -- it must be in your cache
<Treenaks> Keybuk: hm.. ok
<seb128> $ host qa.mandriva.com
<seb128> qa.mandriva.com has address 84.14.106.137
<Mithrandir> host is useless for DNS debugging
<setuid> Some weirdness with nautilus too, probably related. 
<setuid> No icons show on the desktop
<seb128> Mithrandir: I don't want to debug, that was just to point the IP
<seb128> setuid: no, that's a gconf setting
<seb128> /apps/nautilus/desktop/volumes_visible
<setuid> seb128: Oh? I wonder why that default changed from Breezy to Dapper
<seb128> and /system/storage stuff
<ogra> Mithrandir, for the firts debugging step (does it resolve ?) its enough ;)
<ogra> *first
<seb128> setuid: because that's an unstable version you are trying, upstream did some changes and we didn't clean up the way we want yey
<setuid> Yep
<seb128> yey -> yet
<ogra> Keybuk, can you get www.mandriva.com ? they seem to have a bigger problem ... that one resolvs bit the webserver seems broken
* setuid wonders if he should go back to Breezy
<Keybuk> ogra: I can
<ogra> hmm, i'm redircted to wwwnew.m.c which doesnt load
<tepsipakki> hmm, the x86-iMac doesn't show the daily-install-cdrom as a bootable media.. I'll try netboot
<ogra> whaa, what made my edubuntu CD explode ? 
<zul> you stickeed it in the microwave? ;)
<ogra> *sigh* example-content is 8MB big ? no way for edubuntu ....
* ogra removes
<pitti> setuid: yes, known bug, as Keybuk said
<pitti> ogra: 8 MB?? holy...
<setuid> pitti: Right, trying to fix that up now
<pitti> setuid: I will fix it ASAP
<ogra> pitti, yup :/ no way i can make so much space on any edubuntu Cd
<setuid> Need to locate 0.5.6-4ubuntu4 
<seb128> I think that example-content is a waste of CD space
<ogra> seb128, ++
<seb128> it's not useful for an installation
<pitti> seb128: it's nice for the live CD, though
<seb128> I can get the point for a demo liveCD, but on a desktop ...
<seb128> pitti: right
<ogra> for edubuntu it doesnt even fit on the liveCD ...
<Riddell> Kamion: patch for espresso to make usersetup.py UI independent http://kubuntu.org/~jriddell/tmp/espresso.diff
<Keybuk> seb128: bug 33153 ... any other debugging info I can provide while the bug is still hot and reproducible?
<Ubugtu> malone bug 33153 in gnome-terminal "Factory refuses to spawn new terminals" [Normal,Unconfirmed]  http://launchpad.net/bugs/33153
<Keybuk> (if not, I'll kill the running factory and the bug will go away for a while)
<seb128> Keybuk: does starting an xterm work?
<Keybuk> yes
<Keybuk> also gnome-terminal --disable-factory works
<seb128> so that's not the same bug as pitti got
<Kamion> Riddell: thanks, applying (with a trivial rearrangement in gtkui.py)
<seb128> Keybuk: nop, not really. I'll ping upstream and ask you if they need anything next time you face the issue
<Keybuk> ok, it happens about once every day or two, so won't be long before I can debug it again <g>
<Keybuk> damn, had a cool rhythmbox bug there
<Keybuk> but didn't screenshot it in time
<Keybuk> "Now playing" ... and an empty notify popup :)
<Keybuk> MYSTERY TRACK!
<Treenaks> Keybuk: hidden bonus track!
<Keybuk> now that reminds me of those cute intro quizzes people did for a while
<seb128> do you have any special char?
<Keybuk> and the silly person who managed to copy the id3 tags into the files
<seb128> there is an escaping issue fixed with the CVS
<seb128> I've to backport the patch on my list
<Keybuk> seb128: if & is special, yes
<seb128> yep, it has to be escaped
<seb128> probably that bug
<Keybuk> ok, won't bother with that one then
<seb128> Keybuk: http://bugzilla.gnome.org/show_bug.cgi?id=330784
<Ubugtu> gnome2 bug 330784 in User Interface "Notification bubble shows empty" [Trivial,Resolved: fixed]  
<seb128> for the record
<seb128> Diziet: around?
<tepsipakki> Kamion: x86-iMac support for the installer would need an elilo.efi loader, and some kernel patches I think: http://www.osxbook.com/book/bonus/misc/knoppix/
<Kamion> tepsipakki: yep, already found that link
<Kamion> or been pointed to it, whichever
<Diziet> seb128: Hello.
<seb128> Diziet: hi :)
<Diziet> (Just happened to glance at IRC.  In general, if you actually want an answer in a timely fashion, feel free to phone.  Email is good too.)
<seb128> Diziet: do you think that the "open with" dropped from firefox will stay that way?
<Kamion> tepsipakki: we need the patches filed as bugs in the relevant places, and some clue about how to build CDs in a way that the Intel Macs can boot
<Diziet> I haven't read the flamewar^Wdiscussion today yet.  It depends what people thing.
<Diziet> Err, think.
<Diziet> Why ?
<seb128> Diziet: no hurry, I replied on the list about your firefox mail and you got a bug but didn't comment on any
<seb128> Diziet: it breaks all the stuff using gecko
<Kamion> tepsipakki: the latter I think can probably be done using a hybrid ISO9660/HFS+ filesystem the way we do on powerpc already, but it isn't entirely clear
<seb128> Diziet: so I have to let know upstream if they should put some special workaround for Ubuntu and if I should start patching epiphany, galeon, etc
<Diziet> seb128: I saw your bug report about gecko.  Can you explain ?
<Diziet> I mean, why doesn't it just do the nice (or nasty, depending on your opinion) thing for gecko-embedders too ?
<seb128> epiphany has an option "automatic download"
<seb128> which allows to get stuff automatically open
<seb128> or to get the "save as or open" dialog if not used
<seb128> your change break the option
<seb128> it automatically opens all the time now
<seb128> and store stuff to /tmp
<pitti> slomo: mono-tools, nunit, nant approved for main
<Diziet> Oh, you probably don't have the download manager disappearing again, either.
<seb128> Diziet: the guy who opened https://launchpad.net/distros/ubuntu/+source/firefox/+bug/32934 is epiphany upstream
<Ubugtu> malone bug 32934 in firefox "auto-download breaks embedders" [Normal,Confirmed]  
<Diziet> (Really I wish these things didn't turn up in the download manager.)
<seb128> Diziet: so feel free to ask any technical question you want on the bug
<slomo_> pitti: cool thanks :) is it too late for a new maininclusionreport (liferea)?
<Diziet> They're not downloads.
<Diziet> Yes.
<pitti> slomo_: no, promotions/demotions can happen for a while still
<Diziet> So that breaks epiphany.  But what about the other gecko-embedders ?
<Diziet> I mean, I could just move the pref out of gecko into firefox (effectively), I think.
<slomo_> pitti: ok... a package in main is dependening on a binary package out of mono-tools... so i don't have to do anything for these 3?
<pitti> Kamion: btw, racoon promotion is fine (source in main since warty), and libpng source-only promotion too (source renamed from libpng3)
<pitti> slomo_: 'these 3'?
<pitti> slomo_: you can consider mono-tools in main now
<seb128> Diziet: better to reply on the malone bug imho, upstream know the code better
<Kamion> pitti: done, thanks
<pitti> slomo_: (for the purpose of a new main inclusion report, that is)
<seb128> he did some comments on IRC friday
<seb128> <chpe>  +  if (!(NS_SUCCEEDED(rv) && defPrefBranch)) return PR_TRUE;
<seb128> <chpe>  who wrote that!?
<seb128> <chpe>  NS_FAILED exists for a reason :p
<seb128> by example
<seb128> Diziet: as I got it, right it would be nice to move the pref from gecko to firefox
<Kamion> Riddell: uploaded
<Diziet> seb128: re NS_FAILED: uh,  I wrote  !(NS_SUCCEEDED(rv) &&   not   (!NS_SUCCEEDED(rv) &&
<Diziet> And why is he trying to do code review feedback by IRC ??
<seb128> Diziet: no, he was just looking on the patch
<tepsipakki> Kamion: I'll see what can be done.. but the machine is here maybe for a week, so it won't be here for testing after that ;)
<Diziet> OK, I'll reply to the bug.
<pitti> Kamion: may I bother you with approving culmus for breezy-updates? (cprov wanted to have a test package)
<Diziet> looking on the patch == reviewing the code
<seb128> Diziet: that come that way, nobody warned them about the changes, and they started getting bugs on epiphany
<seb128> Diziet: so they looked on what we did
<seb128> ie: got the firefox diff and looked on what the diff do :)
<seb128> I think that was just some "talking on IRC while reading the patch"
<slomo_> pitti: ok, so these 3 (mono-tools, nunit, nant) only have to be added to the overrides by Kamion and everything is fine?
<seb128> anyway chpe opened the bug, so better to reply on it and ask whatever might be useful for you
<pitti> slomo_: right, anastacia already wants mono-tools, so germinate-wise they are fine
<seb128> Diziet: thank you 
<Diziet> I did suggest he should mail ubuntu-devel but I don't think he did.
<seb128> I don't think they are subscribes to ubuntu-devel
<seb128> subscribed
<pitti> slomo_: if some binaries of mono-tools are not caught by dependencies, then we might need to explicitly seed them, though; please just tell us in this case
<slomo_> pitti: ok :) hmm, i'll fix dbus now (still FTBFS)... or are you already doing it?
<pitti> slomo_: hm, it worked here (I could reproduce the former FTBFS)
<pitti> slomo_: last time I checked it wasn't attempted to build yet
* pitti checks again
<slomo_> pitti: i don't understand the current ftbfs yet :)
<pitti> WTF???
* pitti hits autotools really, really hard (again)
<pitti> slomo_: I removed all autotools stuff  from my system and it built fine *sigh*
<pitti> slomo_: I'm currenlty a bit busy, so if you have time and want to fix it, go ahead :)
<pitti> otherwise I try to look into it later today
<slomo_> pitti: i'll take a look at it ;) are you still doing the reports?
<pitti> yes
<pitti> trying to reduce the queue a bit :)
<pitti> slomo_: do you use liferea heavily? how stable and user friendly is it?
<slomo_> pitti: i use it always ;) i never had a crash with the latest versions on ppc or x86, only amd64 is a bit crashy currently but this could also be a problem in the libraries below (i.e. glib, pango, gtkhtml)... it's imho easy to use... i don't know what could be done better but i'm probably the wrong to ask regarding user friendlyness as i'm using it since ages
<pitti> alright, so it's not brand new unstable crack then?
<slomo_> no... first upload to debian was 2004, the app itself exists even longer, maybe 2002... we had it since warty
<pitti> slomo_: I installed and started it; two thirds of the articles are empty, and it crashed after a few clicks with a segfault (amd64)
<slomo_> pitti: uh... what feeds do you have in there? and segfaults on amd64 are normal unfortunately... sometimes it happens instantly, sometimes after a day of use... that's what i meant with crashy on amd64 above
<pitti> slomo_: just the default one (mozillaZine I think)
<slomo_> pitti: ah wait... you mean the article summaries are empty? that happens when there's no summary for the article in the feed which is the case for most feeds of news sites :/ you can get the article by double clicking on it
<pitti> slomo_: ah, I see
<pitti> slomo_: the back trace looks quite useful
<pitti> slomo_: maybe you can take a look at it?
<slomo_> pitti: sure... paste it somewhere :)
<AlinuxOS> mjg59, hello
<AlinuxOS> mjg59,  around ?
<AlinuxOS> pitti, hello ;)
<pitti> slomo_: http://paste.ubuntu-nl.org/9541
* pitti waves to AlinuxOS 
<mjg59> AlinuxOS: Hi
<pitti> slomo_: it calls _gdk_x11_convert_to_format() with a NULL pointer argument, should be quite obvious
<pitti> hi mjg59, how are you?
<slomo_> pitti: oh, that's something new i never saw before... the bug i meant is bug 4732
<Ubugtu> malone bug 4732 in liferea "liferea crashes when it jumps to a new article" [Normal,Confirmed]  http://launchpad.net/bugs/4732
<mjg59> Stuck clearing a lab
<AlinuxOS> mjg59, I've talked with pitti yesterday...
<mjg59> AlinuxOS: Ok
<AlinuxOS> he told me that he needs georgian font-s source package :)
<mjg59> ?
<mjg59> They're in the archive
<tepsipakki> Kamion: uh, the kernel-diff is 2MB.. I believe this won't make it in for dapper ;)
<pitti> mjg59: oh, I could only find your deb on the URL stated in the bug report
<mantiena-baltix> hi doko 
<pitti> mjg59: so much the better, great :)
<mjg59> pitti: They're supposed to be in universe
<mjg59> I uploaded some time ago
<AlinuxOS> mjg59, yes 2 weeks ago I suppose
<mdke> jdub, the planet rss20.xml feed is broken again. 
<AlinuxOS> mjg59, what about changes of default font for Gnome interface ?
<slomo_> pitti: thanks... hmm... there's no function from liferea called so can we assume that the bug is somewhere outside liferea?
<pitti> mjg59: do you see an easy way to (ab-)use dbus' at_console policy check so that other programs (like g-v-m) can call a dummy function to check whether they are on a currently active display?
<AlinuxOS> BPG_Chveulebrivi.ttf  BPG_Courier.ttf  BPG_Glaho.ttf this free fonts are contained in .deb package
<Treenaks> mdke: that error is WEIRD!
<AlinuxOS> BPG_Glaho.ttf is most sutable for GNOME interface
<mdke> Treenaks, due to & char I suppose
<AlinuxOS> but by default there is BPG_Courier.ttf 
<pitti> slomo_: not necessarily; something likely passes wrong (i. e. NULL) arguments down the chain
<Treenaks> mdke: hmm. yeah, I see
<mjg59> pitti: Not really. The Right Answer is to use Davidz's spec
<mjg59> (That he's just posted a first cut of)
<AlinuxOS> mjg59, is there some techniques that can change default font for GNOME interface ?
<pitti> AlinuxOS: I already told you, it needs proper fontconfig changes
<AlinuxOS> example BPG_Courier.ttf to BPG_Glaho.ttf
<mjg59> AlinuxOS: It needs Fontconfig work, but unfortunately I don't understand fontconfig
<ogra> pitti, whats the advantage of a dbus function over getenv("DISPLAY") ?
<slomo_> pitti: hm, when does this happen? and is it reproducible always?
<AlinuxOS> pitti, yes you've told me but I don't know who can change things there ?
<pitti> ogra:  that doesn't help me to detect whether the app is on the current foreground console
<AlinuxOS> and who is mantainer ?
<AlinuxOS> maybe I can talk with a mantainer about this ? :)
<pitti> slomo_: I reproduced it twice in a row without any difficulty
<ogra> pitti, ah
<pitti> mjg59: where did he post his spec? in his blog?
<slomo_> pitti: interesting... it isn't that easy on the amd64 of my brother... well, defer the report for now until i ping you again about it ;) interesting thing is, that nobody in debian had this problem on amd64
<Hirion> slomo_, sometimes liferea crashes after a few minutes, sometimes after some hours...
<mjg59> pitti: Yes
<AlinuxOS> who is Keith Packard ? :)
<AlinuxOS> maybe he is here .)
<AlinuxOS> :D
<Treenaks> AlinuxOS: I saw him at FOSDEM
<AlinuxOS> :)
<AlinuxOS> he is fontconfig mantainer :)
<AlinuxOS> or packages :)
<AlinuxOS> packager for debian :)
<jono> heya sabdfl
(koke/#ubuntu-devel) There are some missing translations in dapper, but they are ok in /usr/share/locale-langpack
<koke> (the tooltips of Applications/System/Places)
<koke> but the menus are translated
<slomo_> pitti: are you using the gtkhtml or mozilla renderer? please try with liferea-mozilla (and set this in the preferences of liferea)
* Keybuk throws snowballs at jono
<jono> Keybuk, oi!
<jono> :)
<jono> Keybuk, hows it going pal?
<Keybuk> cold - but otherwise good
<jono> Keybuk, are you in brum?
<Keybuk> no, Oslo
<jono> oh really?
<Keybuk> I get about a bit :)
<jono> Keybuk, oh yeah, you said you would be away for a bit
<jono> heh
<jono> how is it there, apart from cold?
<sivang> Keybuk: what are you doing over incol oslo ? :) (/me guesses working with tollef)
<ogra> hum
<Mithrandir> sivang: making snowmen.
<Mithrandir> :-)
<ogra> does xlibs-static-pic have an successor ? does anybody know the name ? 
<Mithrandir> ogra: no, it doesn't. Why do you need it?
<ogra> Mithrandir, vlc build deps on it ...
<sivang> Mithrandir: heh, /me wishes for some snow instead of the desert dust that been rulling in Tel Aviv lately
<ogra> i was just about to fix screensaver stuff in there and do a testbuild ...
<Keybuk> jono: mostly just cold actually
<Mithrandir> ogra: which parts does it need?
<AlinuxOS> pitti, I'll mail fontconfig package mantainer about bpg-georgian-fonts problems. ;)
<Keybuk> there's probably some other stuff, but I'm TOO COLD to think about it
<Keybuk> ;)
<Keybuk> hmm, how unsufferably British of me, bitching about the weather
<jono> heh
<jono> Keybuk, yes indeed, I assume you are sat there in your Union Jack shorts
<jono> :P
<pitti> AlinuxOS: great
<ogra> Mithrandir, no idea its in the build-deps is all i know for now 
<Mithrandir> ogra: find out, then
<ogra> ENOCRIMSUN :(
<AlinuxOS> pitti, will this package by default in Dapper Drake ?
<AlinuxOS> to have native support of georgian language  ?
<pitti> AlinuxOS: this sentence no verb :)
<pitti> AlinuxOS: we can include the font if it's fontconfig'ed properly, yes
<AlinuxOS> pitti, I have a soultion :) maybe you can include only BPG_Glaho.ttf font :)
<AlinuxOS> it's most usable and better than other
<pitti> that still reqires fontconfig'ing
<AlinuxOS> and other fonts can be added later from another package 
<pitti> but I always appreciate reducing package size :)
<AlinuxOS> pitti, :) consider that BPG_Glaho.ttf is the main font for gnome interface.
<AlinuxOS> it's only 149K
<pitti> AlinuxOS: what did you have to do to make it work properly, apart from installing hte deb?
<AlinuxOS> other fonts are not requred for georgianisation of gnome :)
<pitti> did you manually configure it in the gnome font dialog?
<AlinuxOS> no
<AlinuxOS> .D
<AlinuxOS> I've removede other 2 fonts :)
<AlinuxOS> I don't need them for interface.
<AlinuxOS> BPG_Glaho.ttf works great (small medium and huge) sizes
<pitti> i. e. just dropping that one ttf into your font folder is everything required?
* pitti doesn't know anything about font handling unfortunately 
<jono> http://www.desktoplinux.com/files/article019/osdl-dtl-survey-12.jpg - nice!
<AlinuxOS> /usr/share/fonts/truetype/ttf-bpg-georgian$ ls
<AlinuxOS> BPG_Glaho.ttf  fonts.cache-1
<AlinuxOS> yes :)
<AlinuxOS> pitti, I use only this fonts
<AlinuxOS> and have whole GNOME in georgian :)
<AlinuxOS> it's shared with openoffice too :)
<AlinuxOS> mainly other fonts are used for typing.
<pitti> AlinuxOS: you just dropped that ttf into that dir, and everything magically worked?
<pitti> (that would be wonderful, but sounds like black magic to me)
<AlinuxOS> pitti, before I need fc-cache 
<AlinuxOS> in /usr/share/fonts/truetype/ttf-bpg-georgian$ directory
<AlinuxOS> than restart X and magically everything is in georgian
<AlinuxOS> of course locales must be in georgian :)
<AlinuxOS> you must specify Georgian like default language in "Language Selector"
<pitti> right, setting locale is clear
<pitti> AlinuxOS: ok, the package's postinst script should deal with fc-cache
<AlinuxOS> so the procedure is: put BPG_Glaho.ttf into /usr/share/fonts/truetype/geo, then move into geo, lauch fc-cache, restart X..and voila :)
<AlinuxOS> pitti, yes is very simple :)
<pitti> indeed, that's scaringly simple :)
<pitti> where's the catch?
<AlinuxOS> mjg59, so ? :) do you like this georgian font tip ? :)
<mjg59> No, we should just fix the fontconfig configuration
<mjg59> Which requires finding someone who understands the damn thing, but.
<AlinuxOS> BPG_Glaho.ttfwe can use like main font for gnome interface ;) and other + extra pacakges
* pitti installs ttf-bpg-georgian-fonts and gets a lot of 'Use of uninitialized value in print' warnings
<AlinuxOS> pitti, ;)
<AlinuxOS> mjg59, no fontconfig maestros on ubuntu-devel ? 
<AlinuxOS> for example you pitti as German, which font do you use for main interface ? 
<pitti> no idea, I never bothered to change it
<pitti> just the default one
<ogra> bitstream vera then :)
<pitti> "Sans"
<AlinuxOS> pitti, eh, you indoeuropeans are lucky :(
<ogra> pitti, sans points to vera :)
<pitti> AlinuxOS: so, yes, the package already deals with the fc-cache call
<AlinuxOS> but I'm too tired ..because I'm alone who cares about this...
<ogra> AlinuxOS, youre doing a great job :)
<AlinuxOS> some people has donwloaded Ubuntu in georgia...and tested packages
<AlinuxOS> (pitti, no erros now :D with double .mo files)
<pitti> AlinuxOS: alright, I can remove the other two fonts from the package if it helps to make it work OOTB
<AlinuxOS> and who interface wasn't in BPG_Glaho.ttf, but in courier
<pitti> AlinuxOS: then we just need to add it to the desktop seed (but I'll test it again to make doubly sure)
<AlinuxOS> and it was horrible :)
<AlinuxOS> ogra, thank you, it's the first week that I'm GNOME's georgian coordinator too :)
* AlinuxOS almost alone, translates GNOME... :) %-)
<AlinuxOS> need help, but people is too lasy :)
<fabbione> has racoon been moved from universe to main?
<fabbione> pitti: ^^
<AlinuxOS> fabbione, :) italian ?
<mjg59> pitti: No, that isn't a good option. It means that anyone who adds the fonts gets breakage.
<pitti> fabbione: yes
<pitti> fabbione: any trouble with that?
<fabbione> pitti: no, just scared the hell out of me when i saw a sparc binary being rsynced
<fabbione> AlinuxOS: yes
<AlinuxOS> fabbione, mi fa piacere frattelone fabbione :)
<AlinuxOS> mjg59, you mean if people add fonts to /usr/share/fonts/truetype/ttf-bpg-georgian ?
<mjg59> AlinuxOS: Yes
<AlinuxOS> mmm
<AlinuxOS> normally, Linux people (some people that I know)... adds only BPG_Glaho.ttf into /usr/share/fonts/truetype/
<AlinuxOS> and other fonts in open office specific font location.
<AlinuxOS> I've asked to GPLise BPG author 3 fonts... but only  BPG_Glaho.ttf is well suted for GNOME or KDE.
<mjg59> AlinuxOS: No, both are suitable.
<mjg59> Uh, all.
<mjg59> You want a monospaced Georgian font for the terminal.
<AlinuxOS> mjg59, yes I know, but spaces in others are ugly.
<mjg59> Just fix the fontconfig setup.
<mjg59> Don't try to work around it. Don't split things up into separate packages. Just fix the thing that is actually causing the problem.
<AlinuxOS> mjg59, ok, for example I've fixed locally this problem, howto make this thinks automatic for other people that will use georgian language in interface ?
<AlinuxOS> will they do this difficult thing manually?
<CarlFK> Kamion: debian-installer - okee dokee
<AlinuxOS> mjg59, monospaced georgian font dosen't exist in georgian yet... some friends are making them... that's why I can't start to translate debian-installer to
<AlinuxOS> to add georgian into main installation.
<sivang> does anybody know what phpmyadmin depends on apache2-prefork and its dependency list wants to remove apach2-worker??
<sivang> s/what/why/
<fabbione> sivang: php5 is not thread safe
<fabbione> so it pulls in php5 and -prefork
<mjg59> AlinuxOS: There's a monospaced georgian font in that package!
<sivang> fabbione: ah, bummer
<mjg59> AlinuxOS: The way to make it work for everyone is to fix the fontconfig setup
<AlinuxOS> mjg59, which one ? ???
<AlinuxOS> mjg59, I will fight with fontconfig! :)
<AlinuxOS> whichone is monospaced font ? :)
<AlinuxOS> mjg59, ?
<mjg59> AlinuxOS: "BPG Courier"
<AlinuxOS> mjg59, with this font will I see files and directories into georgian ?
<AlinuxOS> even if I don't start X ?
<mjg59> AlinuxOS: No. It's a truetype font,.
<mjg59> The console requires bitmap ones
<AlinuxOS> BPG_Glaho.ttf works great for X
<mjg59> Not in a terminal, it doesn;t
<mjg59> Like gnome-terminal
<mjg59> That needs BPG courier
<AlinuxOS> mjg59, :)
<AlinuxOS> I'll show you a screenshot :)
<AlinuxOS> I'll write you name in terminal :)
<mjg59> BPG-Glaho is not useful in gnome-terminal. It's not a monospaced font.
<AlinuxOS> http://alinuxos.no-ip.org/font.png
<pitti> AlinuxOS: ah, it seems you use the standard fixed font in the terminal then
<AlinuxOS> pitti, ? ;)
<dieman> arugh. someone wants to buy 5 machines with a xgi chipset in them for video
<pitti> AlinuxOS: I only see latin chars in your terminal (however, loading is very slow, I only see the first 20% of the pic)
<AlinuxOS> pitti, when I even grep georgian strings it works
<AlinuxOS> pitti, refresh please.
<mjg59> AlinuxOS: Glaho is not a monospaced font. It is therefore not a sensible font to use in a terminal. It'll /work/, it'll just be ugly.
<mjg59> So we have to ship Courier
<mjg59> Which means we have to fix the fontconfig configuration
<AlinuxOS> pitti, it works even when I grep  georgian text.
<mjg59> (If I have to point this out again, I'm going to scream)
<AlinuxOS> mjg59, :) Oooops :)
<AlinuxOS> ok ok ok
<AlinuxOS> We Will Fix fontconfig! :)
<dieman> i dont even understand fontconfig
<dieman> and ive got a resonable grasp of how lots of things work under debian/ubuntu
<dieman> oh no, im confusing that with defoma
<dieman> which seems like another scary mess
<AlinuxOS> mjg59,I'm sorry , sometimes I think that there is more easy methods... but you must consider that I'm newbie ;) so don't be angry with me :)
<AlinuxOS> pitti, has some experience with me.... sometmes he even don't understands me 
<AlinuxOS> dieman, :) I'm not even a programmer :)
<AlinuxOS> so you can understand that I have many problems..
<trappist> hrm.  georgian is pretty.
<AlinuxOS> and most problems has technique refference.
<mjg59> AlinuxOS: When you type your name, look how there's a large gap between the first character and the second character
<mjg59> That's why you need Courier
<AlinuxOS> I have no base, to build then 
<AlinuxOS> other lanaguages have their standarts..and
<AlinuxOS> people simply translate into rosetta.
<AlinuxOS> but with georgian thing are more complicated..
<AlinuxOS> :(
<mantiena-baltix> doko, maybe you are online ?
<AlinuxOS> mjg59, everything is clear, thank you for your time..
<AlinuxOS> you've right...there is ugly spaces between charachters.
<AlinuxOS> mjg59, be sure that when there will 100% GNOME translated into my native language...
<AlinuxOS> your and pitti's name will be written in gold on Georgian Gnome's project site! :)
<AlinuxOS> thank you for everything...and sorry me
<doko> mantiena-baltix: here
<AlinuxOS> trappist, grazie per il complimento :) Si, la mia lingua  bella da scrivere :) per c' un casino da risolvere prima :)
<pitti> AlinuxOS: English spoken here
<mantiena-baltix> doko, could you look at my post in #debian-oo channel or I should copy-paste here ?
<AlinuxOS> ok, translation: thank you for appreciating , Yes, my language is beautiful to write, but there is too much problems to solve before :)
<doko> mantiena-baltix: is it Ubuntu related?
<mantiena-baltix> doko, yes, you told me yesterday where are latest OpenOffice.org 2.0.2rc sources for Ubuntu and I tried to compile them this night
<mantiena-baltix> On Ubuntu Breezy (with backported needed build-deps)
<mantiena-baltix> but after ~10 hours I got an error :(
<mantiena-baltix> doko, so, maybe you can help my to find the problem, why OpenOffice 2.0.2rc doesn
<mantiena-baltix> doesn't compile on my system
<elmo> is network manager known to be broken in dapper atm?
<pitti> the daemon is pretty crashy for me, but the applet works fine
<pitti> what do you mean in particular?
<elmo> hmb just upgraded and the applet is not appearing
<seb128> run nm-applet
<seb128> the applet is started with the session
<elmo> no such command
<seb128> install nm-applet binary package
<elmo> that's not part of ubuntu-desktop?
<seb128> no
<Kamion> nor is network-manager ...
<seb128> that's not good enough for desktop
<seb128> we only ship it by default on the liveCD atm
<elmo> oh, ok, guess sabdfl installed it then
<elmo> the low disk space thing could do with some smarts to not whine about recovery partitions
<doko> mantiena-baltix: sorry, no time for a breezy backport at the moment. you certainly will have to adjust some ooo-build patches
<sabdfl> elmo: yes, i installed it manually here
<elmo> sabdfl: nah, I mean on hmb's machine
<sabdfl> yes, same
<Diziet> Well, here goes, let's see if this Xen thing boots.
<elmo> LOL, 'killall NetworkManager' takes out the gnome-power-manager applet
<mantiena-baltix> doko, I think this problem is very simple - openoffice doesn't find headers from libnss-dev packages during compilation of xmlsecurity subproject
<mantiena-baltix> I got few errors like this:
<mantiena-baltix> In file included from /tmp/buildd/openoffice.org-2.0.1oob680m4/ooo-build/build/oob680-m4/xmlsecurity/source/xmlsec/nss/securityenvironment_nssimpl.cxx:41:
<mantiena-baltix> /tmp/buildd/openoffice.org-2.0.1oob680m4/ooo-build/build/oob680-m4/xmlsecurity/source/xmlsec/nss/securityenvironment_nssimpl.hxx:95:22: error: pk11func.h: No such file or directory
<Diziet> Apparently not.
<mantiena-baltix> doko, but pk11func.h is in libnss-dev and libnss-dev is spedified in buid-deps. pbuider installs this package automaticallty, but it seems during compilation openoffice doesn't find there headers :(
<pitti> mdz: I have two bug fixes in what will become pmount 0.9.8, plus updated translations from Rosetta. Ok for me to upload this?
<pitti> mdz: (very pathological case of UVF, though)
<pitti> carlos: ping
<doko> mantiena-baltix: you to make sure that config_office/configure finds the correct headers
<mdz> pitti: in any case where you are upstream, the version number is irrelevant so long as you are making changes appropriate for the freeze state
<pitti> mdz: yes, I would take the two bug fixes anyway
<pitti> mdz: oh, and one is already there as a patch from mjg59
<pitti> alright, thanks
<AlinuxOS> mjg59, here ?
<AlinuxOS> :) I understand font choosing criterium
<AlinuxOS> maybe it will help to solve this problem
<ploum> seb128: you remember the bug I told you about "no mouse click"
<mantiena-baltix> doko, btw, should xmlsecurity subproject build in 2.0.2rc ? It seems now we use external xmlsec1 libraries from Ubuntu, they are in build-deps
<ploum> I have it in a xnest-window
<ploum> do you think that I can do something to see where the problem is ?
<dieman> whoa, i didn't know cdimage.ubuntu.com has a vmware image handy
<pitti> bah, this new firefox 'just open without asking' behaviour is awful
<Diziet> pitti: Thanks for your feedback.  Post it to ubuntu-devel.  I will put it back if everyone hates it, I promise.
<pitti> oh, sorry, wasn't meant as a blame
<Diziet> Originally I did it because (a) it seemed sane to me and (b) DefaultApplicationsFirefox said so and (c) sabdfl wanted it too.
<pitti> it just breaks clicking on links in any application
<Diziet> No, no, that's fine, do grumble.  Feedback is good.
<pitti> Diziet: hmm, (c) is a compelling reason :)
<sabdfl> pitti: how?
<Diziet> But perhaps I should make it only do it in ff and not elsewhere ?  All things are possible.
<seb128> ploum: no real idea on that, nop
<pitti> Diziet: whenever I encounter an URL to a tarball in my mutt, xchat, or whereever, I usually want to download the file
<pitti> sabdfl: ^
<seb128> same for me
<sabdfl> pitti: set your default behaviour to be different, then
<seb128> I download all the tarball from evo
<seb128> now I need to open the browser
<pitti> some hours ago I wanted to download a different file type, and nothing happened at all, I jsut got an empty tab
<seb128> stop the download, go to the folder and right click
<sabdfl> hmm... so the problem is that it is opening up a tarball viewer?
<seb128> it opens file-roller for me yep
<pitti> sabdfl: ... or nothing at all
<seb128> but I want to package the new tarball, not to browse it, so usually I just save it on the desktop
<sabdfl> hmm. fair enough, that's not good
<Diziet> One alternative to the current thing would be to list explicitly the content-types that should be opened immediately.
* pitti tries to remember the file type that caused to just produce an empty tab
<mdz> seb128: does file-roller not let you save a copy of the file?
<sabdfl> but i suspect that you can change the default behaviour yourself for specific types, right?
<mdz> evince does that, it's nice
<pitti> sabdfl: I guess so
<Diziet> sabdfl: Yes, but not via the UI.  You have to mess in about:config.
<sabdfl> Diziet: really? in thunderbird there's a nice prefs page for it
<ploum> in epiphany too
<Diziet> There's View & Edit Actions I suppose.
<seb128> mdz: there is "save as", yep, but I was not sure if it was going to make a new .tar.gz and maybe changing the md5 from upstream ... I should try :)
<Diziet> But you still have to know the mime type.
<Diziet> Save as should save it.
<mdz> seb128: yeah, it would probably repack it
<sabdfl> Edit->Preferences->Downloads->View & Edit Actions
<dholbach> edit -> preferences -> downloads -> view and edit actions?
<seb128> ploum: epiphany is broken by that change
<sabdfl> snap snap snap
<seb128> the new pref is unknow by the other browsers
* dholbach pets the poor epiphany
<Diziet> I don't see why having the pref unknown by the other browsers is per se a problem.
<Diziet> What you mean, surely, is that the new behaviour is a problem.
<ploum> seb128: indeed. That's what I tried to say
<seb128> Diziet: because that breaks them until we teach them about the pref and how to use it
<Diziet> seb128: Why does it break them ?
<Diziet> I mean, I understand that it breaks epiphany because it already has a different pref for the same thing and a GUI to set it.
<Diziet> But why would it break some more naive embedder ?
<seb128> because epiphany expects standard firefox behaviour
<seb128> and acts according to that
<seb128> I've not said it breaks every embedder
<seb128> but it breaks galeon too the same way
<Diziet> Because galeon also has a pref for the same thing ?
<seb128> yep
<Diziet> That is, a different pref for the same thing.
<Diziet> So they're really working around the deficiency in gecko, aren't they ?
<Diziet> Maybe the right thing would be to push this new pref upstream and make galeon and epiphany use/set it instead of their own ?
<seb128> sort of yep
<seb128> correct
<Diziet> I'm not sure we have enough of a grip on the situation for that.  I mean really, that I have enough of a grip on the situation.
<Diziet> So is there code in g. and ep. that mirrors the code in gecko ?
<seb128> we just have to consider that having a distro specific way is an issue for upstream
<seb128> and force us to patch others packages too
<Diziet> It's definitely a problem if we have to patch naive embedders (of which there are several?  yelp etc.)
<seb128> yelp just use gecko for rendering, that should be fine
<Diziet> But if it's just a couple who've already added complex wart on top of the gecko lack-of-feature then I don't feel so bad about that.
<seb128> I only knows about epiphany and galeon beeing broken by the change atm
<Diziet> As it happens yelp never triggers this because the help files never have any externally handled content types.
<seb128> and yelp has no option for that
<seb128> so it would just follow firefox behaviour
<Diziet> Right, so if it did have any such types it would DTRT.
<Diziet> So it sounds like having g. and ep. override the gecko pref would be sufficient.
<seb128> correct
<Diziet> I think that's the correct workaround for now.
<seb128> but upstream is not wanting to make special case for every distro around doing his custom hack
<Diziet> I shall try a bit harder to punt my patch upstream.  I sent it to the Debian people with a note saying `dunno if you want this' but I haven't sent it directly upstream yet.
<seb128> s/his/its
<seb128> that would be nice
<Diziet> seb128: So we make the pref change in Ubuntu.  We have facilities for that, don't we ?
<seb128> if the feature goes upstream that's better for everybody
<Diziet> Yes, certainly, which is why we should try to get it upstream.  But in the meantime we have to solve our Ubuntu problem.
<seb128> we can patch epiphany/galeon, some people will still doing local builds for testing stuff, or because they jhbuild GNOME, or other and bug upstream but that's not a big deal
<Diziet> So, FYI, in case you didn't know, the pref is browser.helperApps.defaultNoAsk.openFile and you just need to set it to false.
<seb128> k
<seb128> I'll patch epiphany and galeon so
<Diziet> Can I get you to write up a mail to ubuntu-devel CC relevant people explaining this decision ?
<Diziet> Or should I do that ?
<seb128> do we need to use the ML where we have a laucnhpad bug with revelant people Cced?
<Diziet> We should have some record of it so that in 6 months' time we're not "err, dunno, I remember there was a reason, um".
<seb128> I've already pointed the bug on the list
<Diziet> I think a list posting is a lot more findable than an LP bug.  You could mail it to both.
<seb128> I've already mailed the list friday pointing to the issue and the launchpad bug about it
<Diziet> (more findable> hopefully LP's searching will improve but for now it's a bit of a swamp.)
<Diziet> I'm sure one nice clear coherent mail won't upset anyone.
<seb128> but I've no objection to follow on the list
<seb128> k
<Diziet> Do CC the bug too of course.
<Diziet> There's nothing wrong with a crosspost between list and bug.
<seb128> ah right, we can do that with launchpad :)
<seb128> I'm used to bugzilla
<Diziet> (Not sure if LP will cope properly but we can fix things up if the mails go to the wrong places.)
<Diziet> (Probably the only problem is that the copies coming via LP will have the headers mangled so you can't tell the crosspost, so mention it in the body of your mail.)
<seb128> right
<Amaranth> Wouldn't it be better to have it default to off and have a post-install (or profile creation, whatever) turn it on?
<Diziet> I wanted to enable it for existing profiles.
<Amaranth> make it an upgrade note?
<pitti> seb128, Diziet: FWIW, the 'Save as' in file-roller is disabled when I open a tar.gz URL from a terminal
<Amaranth> you're breaking the platform so you can save upgraders a little hassle
<Diziet> I don't think I am breaking the platform.
<Kamion> if it's broken, then it's equally so for upgraders and fresh-installers; this is a *good* thing
<Diziet> I'm breaking some rather hacky extra features added on top of the gecko builtin UI.
<Kamion> it means we don't miss out on hearing about problems because only fresh-installers notice
<Diziet> By as far as we know only two very complex embedders.
<seb128> pitti: weird, it works when I open one from nautilus here
<Amaranth> Is it possible for someone to distribute a binary-only app that uses the gecko in Ubuntu (but isn't Ubuntu specific)?
<Kamion> mvo: InstallProgress.waitChild() spins rather unpleasantly on os.waitpid()
<seb128> Amaranth: non patched build expecting the upstream behaviour will be screwed if that's what we ask
<Diziet> amaranth: Yes, and I think those apps should work just fine unless they try to second-guess the external content type dialogue (read: unless they try to fix the bug I'm fixing here).
<Amaranth> Yes, that's what I'm asking.
<Kamion> mvo: it would be nice if it only tried to waitpid on receipt of SIGCHLD, or at least slept a bit between calls, or something ...
<Diziet> It's just the usual case that if you fix a bug in a more-core place you break workarounds accreted elsewhere.
<Kamion> the first would be ideal but is obviously more fiddly
<Amaranth> Diziet: Got a bug open upstream with the patch? I'd like to follow it.
* Kamion has a 26MB strace to wade through now
<Diziet> amaranth: No, and I'm trying to fight grub and Xen today instead of getting sucked into ff again but please email me and I'll add you to the CC when I file it.
<ogra_> Diziet, there is no /usr/lib/mozilla-firefox/xpidl anymore ? 
<Diziet> Urrr.
<Diziet> It's in /usr/lib/firefox now.
<Diziet> Why ?
<ogra_> i'm just trying to make a testbuild of vlc, it fails searching for it ...
<Kamion> Sometimes I feel as if I spend my entire life plumbing bits of debconf together.
<Diziet> Do you know why it's looking there ?
<ogra_> (needed for the plugin it seems)
<Diziet> It's probably some remnant /usr/lib/mozilla-firefox reference in some package file or .pc or something.
<ogra_> Diziet, no idea ... i added four lines to the screensaver handling :) 
<Diziet> If you can find out where it's getting that path from and it's in one of the firefox packages do file a bug and I'll fix it.
<Diziet> :-)  Sorry I made your program bitrot ...
<ogra_> might simply be an old build ...
<ogra_> its from new years eve
<Kamion> fantastic post about the lack of configuration files for PCMCIA in the new world order
<Kamion> http://lists.infradead.org/pipermail/linux-pcmcia/2006-February/003300.html
<Diziet> FF build from NYE ?  That is very old.
<ogra_> ah, the prob was that xpidl is in firefox, but only -dev was in the build-deps :)
<Kamion> pitti: that culmus upload appears to be wrong
<Kamion> pitti: here's the diff for dapper:
<Kamion> -FONTDIR=$(DEB_DIR)/usr/X11R6/lib/X11/fonts/Type1
<Kamion> +FONTDIR=$(DEB_DIR)/usr/share/X11/fonts/Type1
<Kamion> pitti: but here's the diff for breezy:
<Kamion> -FONTDIR=$(DEB_DIR)/usr/X11R6/lib/X11/fonts/Type1
<Kamion> +FONTDIR=$(DEB_DIR)/usr/share/X11/fonts/
<Kamion> spot the difference
<Kamion> sivang: ^--
<pitti> right
<dholbach> there's a change for imake pending which will make a good bunch of paths sane again (but that's dapper+1 material, as we have no idea of the amounts of bits shuffled around)
<fabbione> dholbach: dude.. didn't we agree to try to change it locally and build a set of packages on top of it?
<fabbione> dholbach: that's what we discussed at the Hug Day
<dholbach> If you read again, I said "dapper+1" :)
<fabbione> dholbach: yes, but perhaps we could have fixed for dapper :)
<fabbione> we are still in time to do it i think
<dholbach> hmhmhmhmhm
<dholbach> *whine*
* fabbione rants to the MOTU's face ;)
<dholbach> i'm not sure how happy this will make us
<Kamion> whoa, espresso managed to install language packs
* ogra_ applauds
<Kamion> although no cancel button for some reason
<fabbione> dholbach: neither am I, that's why i suggested to take a sample (if not all) pkgs that B-D on imake and rebuild + debdiff :)
<dholbach> fabbione: I test-built 2 or 3 packages and that was enough for me to say "next release"
<fabbione> dholbach: ehehe ok
<Diziet> ogra_: -dev should have a dep on firefox, I think.
<ogra_> hmm, true
<mammadori> hi all, I know about casper, squashfs and unionfs but I would like to study the daily build scripts for ubuntu-live, but I cannot find where they lies, any hint?
<Kamion> I'm afraid they've never been published anywhere outside our buildds
<Diziet> ogra_: I've added a note to my todo list.
<Kamion> they're pretty specific to Ubuntu of course, most of the actual hard work they do is debootstrap + install ubuntu-desktop/ubuntu-live + nasty custom hacks
<ogra_> great, thanks :)
<Diziet> kamion: Uh ?  `scripts used to control compilation and installation of the executable'
<mammadori> Kamion: I'm helping debian-live subproject, could I access some way these buildd scripts?
<Kamion> actually creating the filesystem is just mksquashfs
<Kamion> Diziet: the live CD image almost certainly contains both GPLed and GPL-incompatible material so I doubt the whole is covered by the GPL ... but I agree it should be public anyway
<Kamion> sabdfl: ^--
<Diziet> Ahm.  I don't really have time now for this conversation, unfortunately.
<Diziet> I'm supposed to be in town at 1900.
<mammadori> Kamion: nice, tnx, we should reinvent the wheel perhaps :-), we are going on hacking the casper tool and the cdd system, I would like to help ubuntu by helping debian (low level work), tnx anyway
<Kamion> mammadori: you'll need to make sure to install casper, run update-initramfs and fish out the initrd produced by that
<Kamion> colin.watson@canonical.com--2005/debian-cd--ubuntu--0 at http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005 includes some hacks to get the initrd onto the CD image, although that's the easy bit
<Kamion> you'll probably also want to install xresprobe and laptop-detect in the live filesystem to get X autoconfiguration; but that will vary quite a bit between Debian and Ubuntu, I imagine
<Diziet> TTFN
<Kamion> grr @ readahead - please let my live CD boot in finite time, kthxbye
<comfrey> anyone else seeing any issues with current dapper and gnome panel items not appearing?
<comfrey> tomboy for example has stopped showing up in the panel.
<elmo> oook, dapper _loses_ on this laptop
<comfrey> as well as rythmbox.  all of the applets work fine.
<elmo> got an IBM T42, where 2.6.15 fails to boot, says it can't find the root partition, boot messages show it finding the harddrive but not the partitions... any ideas?
<comfrey> elmo: live cd or post install?
<elmo> post upgrade from breezy
<Kamion> might be easiest to wait until Keybuk's around
<comfrey> elmo: use grub cli to verify boot params
<elmo> boot params are fine
<elmo> I can boot breezy kernel into  single user
<fabbione> elmo: initrd
<elmo> haven't tried multi, but assume it'll fail thanks to the new udev world order
<elmo> fabbione: how do you mean?
<fabbione> it's probably missing a module for the driver?
<Kamion> then it wouldn't find the drive surely
<elmo> fabbione: it can see the drive tho, just not the partitions
<elmo> plus mdy has a t42 and dapper's kernel works for him
<AlinuxOS> mdz, ping
<mdz> ?
<Mithrandir> elmo: your partition layout might be slightly funky in a way which trips the kernel?
<AlinuxOS> mdz, hello
<elmo> Mithrandir: yeah, I suspect it is
<AlinuxOS> will georgian bpg font included in Dapper main ?
<jvw> how many fulltime canonical employees are there working on Ubuntu?
<jvw> (roughly)
<AlinuxOS> if not, there is no georgian font at all to support ka_GE locales.
<pitti> AlinuxOS: yes, as soon as there is a proper font config
<pitti> jvw: 16ish
<AlinuxOS> pitti, ;) 
<jvw> pitti: thanks
<mdz> jvw: why?
<Kamion> the current list is 15 I think
<fabbione> elmo: i would check the 2 initrds to see if they are different
<jvw> mdz: DPL elections campaigning is on, and someone asks questions like "What do you think of Ubuntu"
<fabbione> elmo: and possibly if mdy is updated at the same level
<mdz> jvw: yes, Raphael did I think
<jvw> indeed
<jvw> as one of the candidates, I'm of course answering...
<elmo> that could be hard, mdy being the part timer he is, has left for the night
<elmo> am I right in assuming breezy's kernel won't work with dapper?
<fabbione> elmo: it might...
<mdz> elmo: I think udev may be fucked in that configuration
<mdz> jvw: and?
<jvw> mdz: well, I'm still composing it, best await the reply by mail I guess :)
<jvw> mdz: btw, did you do anything with the poll results for maintainer-field yet? I said in some other mail I still wanted to prod someone, and that someone is you :)
<mdz> jvw: I'm curious about why that particular piece of information was relevant to your opinion
<mdz> jvw: yes, infinity is working on the implementation
<fabbione> jvw: you running as DPL?? did your mother gave you permission to do so? :P
* fabbione pats young jvw 
<jvw> it isn't relevant to my opinion, but I want to be factual in the statement that basicly says "It is good to have N people working fulltime on basicly what is rougly sid, or at least, close to it"
<AlinuxOS> pitti, I was only asking generally, cause some georgian users are asking me howto install georgian fonts on Ubunts
<jvw> (or so, I didn't finalize my exact statement yet)
<AlinuxOS> that's all :)
<jvw> fabbione: dude! I'm young, but not *that* young :)
<jvw> fabbione: there are people of my age having 3 children already
<jvw> (in the US probably more)
<fabbione> jvw: isn't underage sex punishable by law? :P
<fabbione> jvw: congratulation for the run anyway.
<jvw> mdz: what implementation will you choose? Just the 'winner', even though you noted it isn't probably the best solution?
<jvw> fabbione: running isn't hard, being able to sign a mail is all it takes
<fabbione> jvw: well running is always difficult.. not just to sign up ;)
<mdz> jvw: something functionally equivalent to the winning option, using a more accurate name for the field
<jvw> I see
* fabbione heads for dinner
<Rique18> hei people!
<Rique18> good afternoon
<Rique18> somebody can help me?
<Rique18> we are creating a free radio in my town
<Rique18> and want use free content to manage the radio
<Rique18> somebody meet some linux distro for radios?
<elmo> meh, breezy kernel boots, but not ipw2x00 love, I'm so dead
<Rique18> elmo hi
<mjg59> mdz: I'm going to nap for half an hour, I've set an alarm for the meeting
<mdz> mjg59: see you then
<Rique18> people...
<Rique18> say me something
<Kamion> well, it's not really a particularly good channel for your question ...
<Kamion> if Ubuntu isn't suitable for your needs, Googling for a more suitable distribution would probably be your best bet.
<Rique18> Kamion thanks for helping
<Rique18> Kamion do you meet the right channel or irc network?
<dholbach> You didn't quite say how anybody could help you - what you are looking for specifically - mailing ubuntu-users@lists.ubuntu.com might be a better approach
<Kamion> Rique18: no idea, sorry
<Kamion> but this channel is for the development of Ubuntu and is only appropriate if you're working on Ubuntu development
<Rique18> Kamion i understand
<Rique18> thanks!
<mvo> hm, http://cdimage.ubuntu.com/releases/5.10/release/ has only dvd images?
<janimo> Kamion, any eta on xfce main promotion, and cd build? thanks
<Riddell> mvo: CDs are on http://releases.ubuntu.com/
<Kamion> mvo: yes, it should really link to releases for the rest
<Kamion> janimo: erm, not yet, sorry, I'll try to look at it this week for you
<mvo> aha, thanks
<janimo> Kamion, thanks
<mammadori> kamion: Tnx a lot for tips, you were invaluable, I'll watch your scripts (I miss enter key 1 hour ago.... dinner caught me :-) )
<elmo> GRR
<elmo> GRR GRR GRR GRR HATE
<Treenaks> elmo: who? what? where? why?
<jpatrick> how?
<elmo> (for anyone following along at home, my problem was #32123, but I didn't get a backup of the broken initrd.img)
<CarlFK> so infinity has passed?!
<CarlFK> and I missed it.
<sivang> 58/152 0:09:28
<sivang> go bzr go!
* sivang pushes bzr
<sivang> yes, you are almos there, just a little bit more
<sivang> copy  97/152 0:04:00
<mvo> sivang: you sound so excited. is this your first push?
<sivang> mvo: ehehe
<pitti> sivang: looking at this number, you will rather be annoyed, I guess
<sivang> mvo: actually it's a re-branch... I have diverted accidently so I need to check/merge
<pitti> sivang: the very first push to a remote site should still better be done with tar/scp/untar
* pitti went back to the rsync push for some projects
<sivang> pushes are a bit quikcer. 
<tseng> i need to try the new push code
<sivang> well, from the crappy net connection I have here, sftp works finr for the pushes, I might need to switch back to rsync for the pulling
<sivang> mjg59: I tried recompiling with --with-rgb-path, but compilation breaks for me at some point. are there any dependenices that are not specified in the source control file?
<sivang> mjg59: (talking about pkg:xserver-xgl)
<mgalvin> not really a devel question, but might anyone know the size in GB of the complete package archive at archive.ubuntu.com for all archs and ports, etc...?
<sivang> yay, it finshed
<mjg59> sivang: There should be no extra dependencies, otherwise it wouldn't get built by the buildds
<sivang> mjg59: I thought about it, and couldn't get why it fails on my machine...I think it said it was missing some utility which names was in CAPS, not sure. I will recheck and report back. Are you ware of the emacs problem? (unkonw color err)
<mjg59> Yes, it's because of the lacking rgb.txt
<sivang> mjg59: where do you reckon it expects it? I tried putting it for him in all possilbe locations. (/usr/.. /etc/.. etc)
<sivang> s/him/it/
<mjg59> It wants it in /usr/share, I believe
<LaserJock> mgalvin: I think I asked that questions once, seemed like the guess was somewhere around 20 GB, but I could be way off.
<sivang> mjg59: will be review a diff package I will create for adding the necessary configure options to debian/rules and upload if appropriate?
<mgalvin> LaserJock: thanks, for the time being i may try to mirror it myself to get an acurate number
<LaserJock> mgalvin: yikes
<mgalvin> well i need to know, so worth the effort for now :)
<mjg59> sivang: If it works, yes
<mgalvin> LaserJock: hopefully my ISP doesn't get too mad ;)
<LaserJock> mgalvin: I just hope you have a good connection ;-)
<mgalvin> LaserJock: i get around 500-700kB/s on a cable connection so it should not take *too* long
<mvo> does anyone mind if I upload a new ubuntu-meta?
<ogra> mvo, any changes for edubuntu-meta i'd miss ?
<mvo> ogra: no idea, I don't know a lot about edubuntu ... 
<ogra> whats changed in ubuntu-meta ?
<sivang> mjg59: btw, why do you ship the configure results in the source package? (isn't it better to leave it un configure'd, so when changes are introduced in the rules file, those will menifest in the resulting auto foo with a need for a manual run?) 
<mvo> ogra: I can put the changes on a pastebin, give me a bit
<sivang> mjg59: s/with/without/
<ogra> mvo, only if they differ much with my edubuntu-meta upload from today
<dholbach> ogra: you should be able to tell by the pastebin, no?
<ogra> dholbach, sure, i but looking aat the mail on -chqanges would be less work for mvo :)
<dholbach> i think not
<mjg59> sivang: Hm. make distclean ought to get rid of them, so I'm confused as to how they would end up in there.
<mvo> Kamion: could gdebi get promotion to main please?
<reggaemanu> mjg59, hello, is it planified to upgrade xgl and compiz packages (and adding libsvg and libsvg-cairo)? 
<mvo> ogra: http://paste.ubuntu-nl.org/9554
<mjg59> reggaemanu: Not right now, Xgl requires CVS mesa
<ogra> mvo, thats contained in my upload already, thanks
<mvo> ogra: cheers, gdebi is waiting for promotion, once it's in main, that is added to the list as well
<mjg59> I'll look into compiz
<reggaemanu> mjg59, ok, and just a modified xgl package with rgbpath set ?
<ogra> mvo, you had that here too ...
<ogra> s/you/yup/
<mvo> here?
<sivang> mjg59: make distclean failes for me with a fresh src I just grabbed. http://paste.ubuntu-nl.org/9555
<mjg59> sivang: Uhm. In that case, it's not configured.
<ogra> mvo, here in blankenheim in the list of updates when i updated edubuntu-meta ...
<mvo> ogra: aha, ok
<mvo> ogra: sorry for being slow, it's late here :)
<ogra> haha 
<ogra> not here 
<mvo> I though so :-D
<sivang> mjg59: this is what I get when autogen'ing it, do I need to switch the automake version? http://paste.ubuntu-nl.org/9556
<mjg59> Why are you autogening it?
<Kamion> mvo: erm, sorry, I'm just here really briefly and don't expect to be around when the publisher next finishes (which is when my window opens for promotions)
<mjg59> sivang: You need CVS X build macros to be able to do that
<Kamion> mvo: gdebi's lacking a main inclusion report; doesn't it need one, or did mdz exempt it?
<mdz> Kamion: I didn't, but it shouldn't need much more than a second pair of eyes
<Kamion> if pitti's looked at it already, that's enough for me, I just don't remember whether he has or not
<sistpoty> elmo: please sync bum (2.1.5-1) from unstable, no ubuntu specific changes present. thx.
<mvo> Kamion: I was told we don't need them for apps we have written ourselfs, no?
<mvo> Kamion: I can ask pitti to have a look first of course
<LaserJock> mjg59: ping?
<mjg59> LaserJock: Hi
<LaserJock> mjg59: do you much experience with licenses, I was searching debian-legal and your name popped up
<mjg59> LaserJock: Some, yeah
<LaserJock> mjg59: I'm particularly interested in the Common Public License
<LaserJock> and it's DFSGness
<mjg59> LaserJock: I believe it's fine
<Burgwork> LaserJock, is that the IBM one?
<LaserJock> mjg59: is there a website that lists DFSG free licenses, I tried doing some googling but I'm not quite sure what I'm looking for exactly
<mjg59> LaserJock: There isn't, no
<sivang> does anyone know if pmount has something close to a python api to be able to mount from python applications?
<LaserJock> mjg59: ok, that's fine. I'm just trying to get a package moved from multiverse to universe and I wanted to sound somewhat intelligent when I emailed elmo
<LaserJock> Burgwork: something like that, I'm not sure
<sivang> or, otherwise I just need to subprocess.call() it?
<Kamion> mvo: I've promoted gdebi now; will be available in an hour or so
<mvo> Kamion: cool, thanks a lot
<Kamion> as you say, we wrote it ourselves, pitti can look over it later if need be
<elmo> mvo: does the dist-upgrade tool force gnome debconf?
<elmo> mvo: I just had mine error out because postgres-* was trying to display a not via gnome debconf, but gnome libraries weren't in a usable state
<elmo> a note too
<Kamion> debconf's gnome frontend should generally fall back itself, but there was a bug in lib{glib,gtk}-perl (can't remember which) in dapper a while ago that meant it couldn't
<koke> mvo: I think I have asked this a hundred of times, but I always forgot... where is the current repo of update-manager??
<mvo> elmo: yes, it forces it. I got a bugreport about that (gnome debconf not usable)  before
<mvo> s/before/recently/
<mvo> koke: haha, no problem. it's http://people.ubuntu.com/~mvo/bzr/update-manager--dapper/ for the current dapper version
<mvo> and http://people.ubuntu.com/~mvo/bzr/update-manager--mvo/ for the current devel tree. that one contains some ui fixesin the software-properties window, that may be too risky for dapper. I will discuss that at the ui sprint
<mvo> elmo: it's now on my MUSTFIX list 
<mvo> elmo: did the upgrade-tool otherwise worked?
<mvo> koke: do you plean to hack on it (again)? that would be wonderful :)
<koke> mvo: I have some ideas :)
<koke> actually not mine. I've been using osx for some time and I like their update system
<elmo> mvo: apart from the career-destroying initrd SNAFU, yeah, but I doubt that's update-manager's problem
<mvo> elmo: I like to blame the packages for any failures :P
<mvo> koke: nice, I'm looking forward for cool stuff from you :)
<elmo> hmm, this new font or whatever is messing with my brain
<elmo> I assume the lack of pretty cursors is a known thing?
* mvo wonders if a bzr from breezy can get a current bzr tree
<tseng> elmo: yeah its been that way for some time
<tseng> elmo: if you just give it a poke in system - prefs - mouse - pointers, its back
<ajmitch_> mvo: I think it should, still
<ajmitch_> hello tseng 
<tseng> hey andrew
<mvo> ajmitch_: yes it does. pretty amazing stuff that bzr (I use 0.1.1 to get the archive)
<koke> mvo: an interesting thing from osx. Instead of download updates in the background, the option is to download important (security, I presume) updates in the background
<ajmitch_> mvo: I've been using it a lot lately, very happy with it :)
<tseng> ajmitch_: are you using push now?
<ajmitch_> tseng: currently not, though I've used it in the past
<mvo> ajmitch_: yes, I'm pretty happy with it as well. I switched synaptic over recently. and once that stupid baz-import for apt finises that one will be bzr too
<koke> mvo: another one is to group non-important updates in a combined update (like 'Ubuntu 6.X update 2006-06-12')
<Ubugtu> ubuntu bug 6 in gdb "gdb package contains non-free GNU FDL documentation" [Normal,Resolved: notwarty]  http://bugzilla.ubuntu.com/show_bug.cgi?id=6
<ajmitch_> mvo: sadly the selinux debian packaging will be using arch, so I think I'll have to use baz2bzr to stay sane
<mvo> koke: oh, interessting. we will have a "install security upgrades" for dapper, but that not silently download only those
<koke> and have a small translated changelog 
<tseng> ajmitch_: id almost rather upstreams use svn over baz
<tseng> ajmitch_: i feel bad saying that.
<mvo> koke: another nice idea. only this aggregation makes translated changelogs feasbile IMHO
<mvo> otherwise it is too much work
<mvo> for the translators
* mvo prepares for bedtime
<koke> yep, also the description can be done while fixing the package to be ready when uploading it
<sabdfl> mjg59: your shiny new toy is in elmo's hands
<koke> mvo: ok, I'll tell you more
<koke> mvo: btw, what's that ui sprint thing?
<sabdfl> mjg59: i'm in the market for a new laptop, x60 is delayed till March 21st, any suggestions for stuff you don't have and would like to test?
<sivang> sabdfl: what kind of toy is that? :-)
<mvo> koke: it's about a get-togehter for polishing the UI for dapper. final touches, that kind of stuff
<sabdfl> imac
<mjg59> sabdfl: Rock. Any chance of getting it sent up here?
<sivang> ah , cool
<mvo> koke: please tell me tomorrow, I'm already half asleep :)
<mjg59> sabdfl: March 21st? Suck. A Core Duo machine of some sort would be good.
<koke> mvo: ok, I have lots of comments :)
<sabdfl> mjg59: sure, just ask elmo for it, and can we have it back for the office please?
<mjg59> sabdfl: Indeed
<mvo> koke: cool, that is *good* :)
<sivang> mvo: ui polish sprint? where?
<mjg59> sabdfl: Dell are shipping the Inspiron 9400, I'm not sure if any of the other major manufacturers have one out yet
<elmo> I can't find any from HP or Sony, FWIW
<sabdfl> sony has them. in japan.
<sabdfl> would have bought one but the keyboard was bake-your-noodle material
<elmo> mjg59: I assume cvd has your shipping details?
<koke> sabdfl: you can remap it if you know the layout :)
<koke> it's also good for improve typing speed
<mjg59> elmo: Yup
<sabdfl> mjg59: how predictable are the Windows keys on keyboards and laptops?
<mjg59> sabdfl: In what way?
<mjg59> They always generate the same scancodes
<sabdfl> it would be nice if we could map them to fire up the K menu, or the G applications menu
<mjg59> Oh, I see what you mean
* sivang nods
<sabdfl> nice, that is, for windows users
<ogra> thats trivial ...
<Burgwork> sabdfl, it would be also nice to map some of the other windowskey+key codes as well
<sabdfl> Burgwork: i don't know them... tell?
<Burgwork> sabdfl, ie, if you simply press and release the windows key, you get the start menu, but if you hold it, you can use it like a ctrl or alt
<mjg59> sabdfl: In Gnome, just set the "Show the panel menu" shortcut to that
<ajmitch_> win+m for minimise all, for example
<Burgwork> such as W+e launches explorer and w+r for the run command
<ogra> ctrl-alt-del for the system-monitor ?
<Burgwork> w+l for locking the screen
<LaserJock> I've got an Intel iMac if anybody needs some testing
<tseng> LaserJock: Kamion seemed somewhat interested, but i doubt its much good to him remotely, at this stage
<LaserJock> tseng: hmm, I don't think the boss would let me send it to him ;-)
<sabdfl> LaserJock: will you test the Flight 5 CD on it?
<LaserJock> sabdfl: I will if it works ;-)
<tseng> sabdfl: flight 5 wont be very useful afaik
<sabdfl> Flight 6 perhaps
<mjg59> You can't boot iso9660 CDs on them
<tseng> someone will have to get a box at canonical and do the dirty work of hacking elilo
<tseng> and vesafb
<mjg59> It'll have to be a separate CD image for Dapper, for +1 we can probably manage a CD that'll do both
<LaserJock> sabdfl: if you guys get Ubuntu to work on macintels and all the i386 stuff works then you'll doing great. Fink and darwin ports are really giving me troubles
<mjg59> sabdfl: Ok, Dell claim to be shipping the 9400 in the UK. It's a Centrino Duo platform, so it's pretty similar to the new Thinkpads.
#ubuntu-devel 2007-02-26
<Adri2000> is there any archive admin here?
<Xerroz> does anyone know how i can build an ubuntu base with full debugging symbols?
<geser> Xerroz: there are for nearly all packages debug packages available with the symbols
<Xerroz> right, but I want to install a clean base setup for full debugging, and i am unsure how
<bddebian> Heya
<mariano> anyone can point me to the source packages for gnome-session?
* mariano is tracking a gnome error...
<Fujitsu> mariano: It's in the source package `gnome-session', and can be retrieved from http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-session.
<Fujitsu> Or from the gnome-session page on LP, probably.
<mariano> thanks
<mariano> which file is the source package?
<mariano> *blush*
* mariano has never installed a deb file in his life :-)
<Fujitsu> The source package is made up of the .dsc, .orig.tar.gz, and .diff.gz of the appropriate version.
<mariano> ah
<mariano> thanks
<dholbach> good morning
<sid> http://www.markshuttleworth.com/archives/95 "In addition to all of this, we have restarted the effort to produce a flavour of Ubuntu that includes no proprietary drivers or firmware at all. In fact, this flavour will take an ultra-conservative approach to all forms of content on the .iso, whether that be artistic or code. More on that initiative later."
<sid> Does this mean there will be a new release with Feisty? ie Edubuntu/Ubuntu/Kubuntu/Xubuntu .. and now a free ubuntu or something? Fubuntu? So an all free Ubuntu will release with the rest in April?
<LaserJock> I don't think it's quite like that, but I could be wrong
<Fujitsu> That sounds like gNewSense to me.
<sid> LaserJock: Is there a page about this "flavor of Ubuntu"? I couldn't find it on ubuntu.com anywhere
<LaserJock> well, he once wrote about a gnubuntu or something like that
<LaserJock> I think gNewSense is basically that now
<sid> but it says "we have restarted the effort to produce", so it implies it will be from Ubuntu.com; Do any of the devs in here know about this flavor? or was he speaking about the distant future? or for the next release cycle?
<pitti> Good morning
<dholbach> heya pitti
<pitti> hey dholbach 
<bluefoxicy> wait what the fuck
<bluefoxicy> oh, wrong matt, nvm.
<Mithrandir> sid: I haven't seen that before, but it's not something we are going for this cycle.  We are post feature freeze now.
<sid> Mithrandir: ok. thanks for the information. I appreciate the help.
<pitti> seb128: any OMGskyisfalling trouble with X yet? works fine here so far (but there's no new server yet)
<seb128> pitti: the server is OMGskyisfalling
<seb128> pitti: http://people.ubuntu.com/~seb128/xorg-server/ if you want to try
<seb128> xorg doesn't start on i810 for dholbach with it (from friday)
<seb128> and I had EXA enabled for my radon, with it swimming windows take 10 seconds with high CPU ise
<seb128> use
<pitti> seb128: would it even be worth the trouble to build amd64 packages? (I can do that now if you want)
<tepsipakki> seb128: oh, so you had "some" issues with it :)
<seb128> tepsipakki: didn't you read the chan? ;)
<seb128> hi tepsipakki
<tepsipakki> yeah, hi
<pitti> seb128: and it doens't get better with the accompanying 7.2 drivers either?
<seb128> pitti: wait, I want to discuss a patch with tepsipakki first
<pitti> sure
<seb128> pitti: dunno, we do incremental updates
<seb128> I didn't try drivers updates yet
<tepsipakki> seb128: only quickly, since I've been sick since I left on Friday..
<tepsipakki> so my head isn't working right
<seb128> tepsipakki: #ubuntu-x
<tepsipakki> yep
<seb128> ah :/
<seb128> we can talk about that later if you want
<tepsipakki> no lets just get on with it, I'm feeling better compared to yesterday
<seb128> pitti: http://people.ubuntu.com/~seb128/xorg-server/, amd64 build would be welcome
<pitti> seb128: doing now
<seb128> I'll upload i386 debs soon
<seb128> then testing of them will be welcome ;)
<fabbione> seb128, tepsipakki: xorg server is always best done in combo with drivers
<fabbione> before you start patching to fix stuff around
<fabbione> even if they are incremental updates, server and drivers retain an ABI together
<seb128> fabbione: ok, thanks for the hint
<fabbione> so i suggest you prepare and test all of them at once
<fabbione> and if it works, push it
<tepsipakki> fabbione: the ABI hasn't changed AFAIK..
<fabbione> tepsipakki: AFAIK != sure.. you need to make 200% sure
<fabbione> or you will get random crashes
<fabbione> in some obscure code
* fabbione has been there
<tepsipakki> heh
<tepsipakki> maybe I trust XSF too much ;)
<seb128> Debian did update the server and not the drivers yet
<fabbione> seb128: note that debian has that stuff in experimental..
<fabbione> so they are allowed to break things there
<fabbione> because sid is more stable than stable in debian
<fabbione> and Debian used to have a different ABI/API IIRC
<fabbione> not sure now
<fabbione> pitti: do you have a list of pkgs that needs the maintainer field changed somewhere?
<fabbione> pitti: i am curious to see if there is any of mine that needs love
<seb128> updating the drivers would be nice anyway
<pitti> fabbione: it's quick to generate, see https://wiki.ubuntu.com/MaintainerFieldRebuilds
<fabbione> pitti: ok
<pitti> fabbione: I just uploaded another 12 from the top of the list
<fabbione> thanks
<fabbione> pitti: btw.. you want to make sure to do that check per architecture.. not all packages are on all arches
<fabbione> and we might miss a few
<pitti> fabbione: right, I'll do those as well
<fabbione> pitti: danke
<fabbione> Her General!
<pitti> *tsk*
<hunger> Is there a reason for aptitude to install linux-image-debug-2.6.20-9-server when upgrading linux-source-2.6.20?
<ajmitch> morning jono 
<pitti> seb128: new x server works for me (2D/OpenGL/XV) with nvidia driver
<seb128> pitti: good, thank you ;)
<jono> hey
<dholbach> seb128: happy
<seb128> dholbach: it works on i810?
<dholbach> seb128: yep
<seb128> brilliant ;)
<dholbach> :-)
* Fujitsu tests it on i810 as well.
<pitti> seb128: works fine with nv driver as well
<seb128> good
<tepsipakki> I should probably read the forum thread about my xorg-packages to see if there is anything new..
<pitti> seb128: if you need more testing, I can build it on powerpc and test with radeon
<seb128> pitti: any testing is welcome but don't bother too much for that
<pitti> heeey, the new X server finally fixes the comb effect of XV on nv
<pitti> that means I can finally watch videos with the free driver again! \o/
<Fujitsu> pitti: Comb effect?
<pitti> Fujitsu: whenever I scaled a video, I got huge comb-like image distortions
<pitti> Fujitsu: this worked until Hoary, then in breezy it broke, I filed a bug upstream, no answer, and now it's fixed again
<Fujitsu> At least it's fixed :)
<StevenK> pitti: Is it screenshotable? I'm curious now.
<pitti> StevenK: well, with a digicam :) I had a screenshot attached on the upstream bug, a minute
<StevenK> Oooh, a dbmail upload.
<StevenK> Maybe it won't FTBFS on Feisty now.
<StevenK> pitti: Sure.
<pitti> StevenK: freedesktop bug 4686
<Ubugtu> Freedesktop bug 4686 in Driver/nVidia (open) "comb effect with nv driver (GeForce Fx 5200)" [Normal,New]  http://bugzilla.freedesktop.org/show_bug.cgi?id=4686
<StevenK> Right, UVFe for dbmail it is.
<StevenK> pitti: Way cool. :-)
<pitti> StevenK: rather not :/
<pitti> StevenK: it was the only thing that kept me from using the free driver
<pitti> StevenK: and now it's the general desktop sluggishness that was introduced a week ago or so
<StevenK> pitti: Ah, so now you can watch movies, but the whole desktop is sluggish? Ugh.
<Fujitsu> I have no Composite, but other than that 1.2 seems to work OK.
<pitti> argh, no, comb effect is still there; I didn't scale the other test movie
<ajmitch> how unfortunate
<pitti> seb128: scp is horribly slow for me at the moment, uploading the amd64 debs will still take a while
<seb128> pitti: ok
<pitti> seb128: do you happen to have an un-retraced amd64 crash at hand which I could use to test my shiny new fakechroot apport-retrace stuff?
<seb128> pitti: bug #87538
<Ubugtu> Malone bug 87538 in control-center "[apport]  gnome-keyboard-properties crashed with SIGSEGV in g_list_foreach()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87538
<seb128> pitti: I've a ppc one also I kept on my "unread" list if you want ;)
<dholbach> we should tag bugs as <arch>-needs-retrace  :-))
* mvo wonders if anyone else noticed that bazaar.lp.net is a bit on the slow side today?
<seb128> dholbach: good idea
<dholbach> seb128: i'll document it in on the bugsquad/tags page later
<dholbach> hey thom
* dholbach hugs thom
<seb128> thank you
<seb128> hi thom
<thom> heyhey
<Mithrandir> how was the skiing?
<thom> ace :-) 
<Mithrandir> good to hear. :-)
<ajmitch> hi thom, Mithrandir 
<Mithrandir> hiya Andrew
<ajmitch> Mithrandir: did you get a chance to look at that f-spot UVF exception?
<Mithrandir> ajmitch: no, sorry.  Where?
<Mithrandir> I've managed to miss it completely enough that I can't remember having seen anything about it at all
<pitti> dholbach: indeed such a tag would be nice, then my fakechroot system could walk the list, retrace them, and remove the tag
<pitti> dholbach: or, if tag mangling is not possible with email comments, we can use a retracing-<arch> team
<ajmitch> probably because I just gave you an url to a debdiff in here earlier - filed bug 87927 earlier
<Ubugtu> Malone bug 87927 in f-spot "UVF exception for f-spot 0.3.4" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87927
<pitti> seb128: thanks
<seb128> pitti: np
<dholbach> pitti: both'd work for me
<ajmitch> we've switched to using the packaged ndesk-dbus libs now, thankfully
<pitti> dholbach: https://help.launchpad.net/UsingMaloneEmail doesn't talk about tags, so let's use team subscriptions
<Mithrandir> ajmitch: looks good to me.
<ajmitch> ok
<ajmitch> thanks
<dholbach> pitti: I think that tags were created after that document
<pitti> dholbach: /me asks Bjorn
<dholbach> pitti: you beat me to it
<gpocentek> good morning
<ajmitch> good morning gpocentek 
<gpocentek> hi ajmitch 
<ajmitch> dholbach: I saw your email about the MC meeting clashing with TB?
<gpocentek> thunar-volman-plugin binary has not been published, could an archive admin tell me what's happening?
<gpocentek> also I've uploaded a new xfwm4 package and got no mail (no Accepted, no Rejected)
<dholbach> ajmitch: robitaille just wanted to let us know that there's the possibility of clashing, if we stick to the same time and date
<gpocentek> and the upload doesn't show up on LP
<dholbach> hiya gpocentek
<ajmitch> dholbach: does the TB time rotate at all now?
<dholbach> ajmitch: no idea
<ajmitch> hm
<ajmitch> I'm sure we can agree on some other time if needed :)
<dholbach> atm it's ok
<pitti> dholbach: teams it shall be then, no tag manipulation per email
<dholbach> ok
<fabbione> does "Cristian Aravena Romero" IRC?
<ajmitch> caravena
<fabbione> thanks
<ajmitch> is he still updating bug reports?
<fabbione> yes
<fabbione> a sparc bug assigned to him
<fabbione> cool
<fabbione> ajmitch: has he been kicked out somehow?
<ajmitch> not afaik, just been spoken to
<fabbione> ok
<slomo> Mithrandir: hi :) can you take a look at #86982? again a new bugfix-only release of liferea...
<seb128> where is doko when you need him? ;)
<ajmitch> is ogra still away as well?
<Mithrandir> slomo: looks reasonable to me.
<pitti> mvo_: do you have some time to throw an eagle eye on SRU bug 85394?
<Ubugtu> Malone bug 85394 in tzdata "New timezone data 2007b" [High,Fix committed]  https://launchpad.net/bugs/85394
<pitti> mvo_: we should really push this out before start of March
<pitti> Riddell: can you confirm bug 87757? the .po file in the edgy langpacks seems to be fine
<Ubugtu> Malone bug 87757 in apport "apport-qt seems to have problem with UTF-8" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87757
<pitti> Riddell: (the bug is for feisty, but the langpacks in feisty are still from edgy)
<pitti> Riddell: hm, indeed, I get it as well
<Riddell> pitti: wouldn't entirely surprise me, pyqt has some strange behaviour with unicode strings
<Riddell> pitti: it's entirely fixable though, I just need to copy the code from ubiquity or dist-upgrade tool or whatever
<pitti> Riddell: hm, any idea how to circumvent this?
<pitti> ah
<Riddell> pitti: it just needs the right combination of casting from one string type to another, can't remember it off hand
<pitti> Riddell: ah, this might be the same issue as in bug 87753
<Ubugtu> Malone bug 87753 in apport "apport-qt system tray icon doesn't work" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87753
<pitti> Riddell: I'll have a look in the dist-upgrader
<pitti> Riddell: that's adept-updater?
<mvo_> pitti: I haven't done any SRU processing yet
<mvo_> pitti: but I can have a look now
<slomo> Mithrandir: thanks
<Riddell> pitti: yes, that'll be the same issue
<seb128> Mithrandir: any objection to update xorg-server to 7.2? It got testing from a bunch of people with different cards already
<jwendell> seb128, it was uploaded already, not? i'm using it...
<Hobbsee> jwendell: not all of it
<seb128> jwendell: no, maybe you are using the package from tepsipakki?
<seb128> or the one I uploaded on people.ubuntu.com?
<jwendell> seb128, i'm using packages from feisty...
<seb128> jwendell: apt-cache policy xserver-xorg-core?
<jwendell> xserver-xorg-core:
<jwendell>   Installed: 1:1.1.1-0ubuntu14
<jwendell>   Candidate: 1:1.1.1-0ubuntu14
<seb128> xorg-server for 7.2 is versionned 1.2.0
<seb128> 1.1.1 is xorg 7.1
<jwendell> seb128, ok... but  apt-cache policy xserver-xorg:
<jwendell> xserver-xorg:
<jwendell>   Installed: 1:7.2-0ubuntu1
<jwendell>   Candidate: 1:7.2-0ubuntu1
<seb128> xserver-xorg != xorg-server
<seb128> xserver-xorg has the config scripts, the logic, etc
<seb128> xorg-server is the actual xorg server program
<jwendell> ahhh, ok
<Lathiat> sjoerd: oh dear
<Lathiat> sjoerd: anand sent a nice ranty email to lennart & i about nss-mdns/NOTFOUND=return
<Lathiat> sjoerd: i don't expect lennart to reply fondly :P
<jbjuly>  I have a question about update-inetd, It's installed default by Ubuntu, does it provide inetd already? I search for /etc/init.d/inetd but could not find it.
<jbjuly> does update-inetd load inetd? or should I install inetd manually in order for it to work. Why is it installed by default?
<kagou> seb128, your xorg packages works great for me with nv or nvidia driver
<seb128> kagou: excellent, thank you for testing them
<kagou> np
<dholbach> gpocentek: did you ever have a chance to look into the new goffice/gnumeric?
<gpocentek> dholbach: not yet, but it's on my TODO
<gpocentek> I hope I'll get this done today or tomorrow
<dholbach> alrighty - just wanted to check
<gpocentek> np
<jwendell> seb128, if you want, i can try your xorg package. I'm using i810-modesetting in my laptop, in order to get 1280x800
<mr_pouit> jwendell, is 1280*800 natively set, or is 915resolution still needed ?
<jwendell> mr_pouit, with this driver, 915resolution is not needed anymore
<mr_pouit> great :)
<dholbach> kwwii: i'll move the artwork packages over to python-distutils-extra and native packaging one by one now - if you do changes to them be sure to pull changes before
<seb128> jwendell: you are welcome to test them, http://people.ubuntu.com/~seb128/xorg-server/
<sistpoty> Mithrandir: can you please route supertux-stable through new? it's the same version known as supertux from unstable (where our supertux is from experimental, however upstream strongly advised us to ship the stable version as well)
<jwendell> seb128, what should i write to sources.list? 
<seb128> jwendell: deb http://people.ubuntu.com/~seb128/xorg ./
<seb128> ups
<seb128> change xorg with xorg-server
<jwendell> seb128, ok
<jwendell> seb128, it worked. I ran glxgears and had that output:
<jwendell> wendell@wendell-laptop:~$ glxgears 
<jwendell> libGL warning: 3D driver claims to not support visual 0x5b
<jwendell> 3789 frames in 5.0 seconds = 757.655 FPS
<jwendell> 4085 frames in 5.0 seconds = 816.912 FPS
<jwendell> 5835 frames in 5.0 seconds = 1166.800 FPS
<jwendell> 3831 frames in 5.0 seconds = 766.159 FPS
<jwendell> XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
<jwendell>       after 147 requests (146 known processed) with 0 events remaining.
<jwendell> seb128, last message appeared when i closed the app
<seb128> jwendell: good, minor bugs like that can be fixed later (fedora has some patches that might fix that)
<kwwii> dholbach: cool, will do
<seb128> Mithrandir: around? that's about the xorg question I asked you before, having a reply would be nice
<bddebian> Heya
<spike> hi there
<spike> ubuntu-boot is dead so thought I'd asked here: what are supposed to be the numbers in partman expert_recipe? ie "40 50 100 ext3 $primary{ } $bootable{ }....", what are those 40 50 100?
<tepsipakki> spike: read the docs
<spike> I would guessed fdisk like sectors but uhm, 40 50 100 makes very little sense
<tepsipakki> it's there
<spike> right, I'll try again then
<spike> tepsipakki: do you mean the -install doc?
<spike> k, sorted, ta
<vignatti_> hey guys
<vignatti_> can anyone point me how to submit a package to ubuntu?
<bddebian> Submit a package or request one?
<vignatti_> yeah, request
<Adri2000> request: https://wiki.ubuntu.com/MOTU/Packages/New
<vignatti_> tkx Adri2000
<spike> hi again. any idea why when preseeding keyboard input wouldnt work at all? I've never had this issue. I'm passing kbd-chooser/method=uk as boot param which did solve a problem when it was complaining about keyboard not being detected
<spike> I'm connected via serial console, against a server's pahntom
<spike> after solving some issues I got to the point where it cant detect the network... god knows why since it booted correctly, but anyway, it prompts me to press continue which I cant
<spike> I dont think it's either kermit or the phantom, 'cause I can either detach or reboot the server (altho the phantom's menu wont ever be displayed)
<spike> the serial console is setup as console=ttyS1,9600 --, which I guess is right otherwise I wouldnt see all the stuff I see (full boot process + preseeding screens)
<seb128> if somebody has a reason to not update xorg-server to 7.2 now speak
<seb128> otherwise I'm going to upload
<ogra> or shut up forever :)
<pitti> or be without X for all times
<ogra> right
<seb128> ogra: no, you can still complain later but the upload will be done :p
* pitti fanboys seb128 and cheers 'X! X! X!'
* ogra joins cheering
<seb128> pitti: GetRideOfTheDesktop, next step coming ;)
* pitti installs libgtk-backend-asciiart
<ajmitch> ogra: well, I have f-spot build-depending on gnome-screensaver now, to get the right paths from pkg-config
<ogra> oh, nice 
<ajmitch> yeah, so next time upstream changes I don't have to go digging
<mvo__> seb128: btw, have ypu seen bug #87947 ?
<Ubugtu> Malone bug 87947 in libxcb "xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." [Undecided,Unconfirmed]  https://launchpad.net/bugs/87947
<seb128> mvo__: that's a duplicate, I'm going to close it, thank you
<mvo__> seb128: thanks
<seb128> that's not a bug from that lib
<seb128> that's likely to be a bug from nvidia-glx
<seb128> the lock problems are due to libs
<seb128> most of xorg libs have been fixed
<seb128> nvidia-glx divert mesa though
<seb128> and seems to be bugged
<mvo__> seb128: ok
<mvo__> seb128: OTOH I would not been suprised if e.g. im libs have not been fixed yet, what do you think? and still have locking issues?
<seb128> mvo__: I'm installing the package, a sec
<seb128> #8  0xb7d86962 in _XReply (dpy=0x8097358, rep=0xbfa66384, extra=0, discard=1)
<seb128>     at ../../src/xcb_io.c:364
<seb128> #9  0xb7d65c8c in _XGetWindowAttributes (dpy=0x8097358, w=62914593, 
<seb128>     attr=0xbfa663e8) at ../../src/GetWAttrs.c:116
<seb128> #10 0xb7da3551 in _XimGetWindowEventmask (ic=0x80bfe68)
<seb128>     at ../../../../modules/im/ximcp/imDefLkup.c:469
<seb128> hum
<seb128> then that's not the nvidia bug
<mvo__> seb128: I except we will get quite a few problem reposts like this because of xcb locking error detection
<seb128> "expect"?
<seb128> yeah, probably
<seb128> though most of the xorg (maybe all of them) have been fixed
<mvo__> right
<seb128> and there is probably few apps playing with xorg locks like that
<mvo__> yeah, mostly toolkits I would imagine
<mantiena> Hi all
<Mithrandir> seb128: xorg-server 7.2> go ahead.
<seb128> Mithrandir: ok, thank you
<mantiena> seb128: hi, are you responsible for Gnome control center and gnome-panel ?
<seb128> mantiena: hi, sort of, why?
<seb128> mantiena: pong?
<mantiena> seb128:  There are one  regression-usability problem in Ubuntu Feisty
<seb128> the control-center shell will be replaced by the menus again with the updates coming from the new GNOME
<mantiena> seb128: *all* Ubuntu versions had System->Preferences and System->Administration submenus, but not these menus gone :(
<seb128> that's not because Ubuntu used to be a way that it can't change
<seb128> we will change back to menus for that cycle because the shell has still problems at the moment
<seb128> it'll likely be the default next cycle
<seb128> and you can get those menus by unmasking them with alacarte
<mantiena> seb128: now I'm talking only about next release (Feisty). In any case, I think one "control panel" button should be in slab (gnome-main-menu applet), but in top gnome-menu should be expandable submenus, it's easier
<mantiena> and faster to access needed function
<seb128> mantiena: I'm talking about feisty as well
<dholbach> i personally like the shell better
<seb128> mantiena: we don't use slab
<mantiena> seb128: but I see some specifications about slab in blueprint.launchpad.net
<dholbach> some specifications are not targetted for feisty or deferred or written by people who are not part of the active development community
<seb128> mantiena: the specification speaks about having it on the CD, not using it by default
<mantiena> dholbach: important thing is compability with previous versions, if ubuntu will choose not to use submenus, then  this mode should be used only for new installations, and submenus should be left  if user upgrades from old versions,  alsothere should be ability to easy switch between  control conter in one window and submenus modes
<seb128> mantiena: it's easy, open the menu editor and unhide them
<dholbach> alacarte should in my opinion be easy enough to switch
<mantiena> seb128: Yea, I understood this, thanks for info, btw, when Ubuntu Feisty will have submenus as default ?
<seb128> mantiena: did you read what I wrote?
<seb128> today or tomorrow
<seb128> with the new GNOME we are packaging
<dholbach> Mithrandir: can you take a look at bug 86305?
<Ubugtu> Malone bug 86305 in gthumb "UVF exception: gthumb 2.9.2" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86305
<spike> hi, preseeding again. it seems that with the old breezy the number of boot params possible was <=8 
<spike> I've googled for it and the only ref I found is to kernel <= 2.6.9 being limited to 32
<spike> altho if I have more than 8 things on my boot line for pxe, the last one will be cut off
<spike> namely the serial console one
<tepsipakki> there's a limit for characters
<mantiena> seb128: thank you very much
<iwj> pitti: Sorry, that autopkgtest upload I did didn't ship all of the docs in the .debs.  This is fixed in 0.7.1.
<iwj> Also I added adt-virt-null for your comfort and non-root-playing convenience.
<pitti> iwj: ah, sweet!
<spike> tepsipakki: thanks
<seb128> mantiena: np
<iwj> pitti: Have you looked at adt-run(1) yet ?
<pitti> iwj: not yet, sorry, I was busy with some other things today
<tkamppeter> pitti, ping
<pitti> hi tkamppeter 
<tkamppeter> hi pitti
<tkamppeter> I want to talk with you about whether to get rid of this /usr/lib/cups/backend-available/ and leave all backends directly in /usr/lib/cups/backend/
<spike> Failed to load the preconfiguration file <-- I get that error. how can I find out what's wrong with it?
<tkamppeter> To make it easier for the user ...
<spike> being the partman recipe the only thing I added I spose it's that one, but cant see nothing wrong with it as I used the default example
<spike> just changed ext3 -> reiserfs and the size of /
<pitti> tkamppeter: I'd like to avoid carrying another delta to Debian for that; it should be much easier to enable additional backends that we want?
<tkamppeter> So this backend-available comes from Debian?
<pitti> tkamppeter: yes
<pitti> tkamppeter: so that users can enable/disable them easily
<tkamppeter> pitti, the backends currently disabled by this mechanism are snmp, serial, and scsi. I would like to at least enable snmp, as it makes it much easier for users to set up their network printers, for example with the CUPS web interface (but probably also wioth most other printer setup tools).
<Mirv> Mithrandir: should you consider that fix/workaround for the bug 22985 I mentioned before herd 5? bug 63503 also has a link to a patch in debian's bugzilla that fixes hangs with radeon 9200 + 3D.
<Ubugtu> Malone bug 22985 in xserver-xorg-video-ati "[x700]  fails to infer lvds for primary connector on acer ferrari 4005 | card detected, but driver fails to use right output port" [High,Confirmed]  https://launchpad.net/bugs/22985
<pitti> tkamppeter: we can do that if it's sane; I just heard from various places (Debian lists) that it's not a good thing by default
<Ubugtu> Malone bug 63503 in xserver-xorg-video-ati "graphics lockups with radeon DRI" [High,Confirmed]  https://launchpad.net/bugs/63503
<tkamppeter> pitti, what are the problems caused by snmp?
<pitti> tkamppeter: I don't know, I have never used it (nor would I be able to test it), the discussion just came up at the Debian list and Kenshi decided not to enable it by default; I'd need to search the archives
<tkamppeter> I had it always active as I made packages for Mandriva 2007 last year and there were no reports about problems. In the last months Mike Sweet has also fixed the problems which occured with certain brands of printers. So currently snmp should be in a good shape.
<Ubugtu> Mandriva bug 2007 in Installation "Switching to alternate screens during install crashes X" [Normal,Resolved: fixed]  http://qa.mandriva.com/show_bug.cgi?id=2007
<tkamppeter> Ubugtu, shut up!
<pitti> tkamppeter: ok, let's enable it then
<pitti> tkamppeter: but please get Mithrandir's ack, since it is a feature
<tkamppeter> Are there also reasons why serial and scsi are disabled? serial I have disabled years ago in Mandriva because the detection process of serial ports was slow, but I do not know whether this is still the case.
<pitti> tkamppeter: I don't have a particular reason; we just inherited that from Debian
<tkamppeter> Mithrandir, can we enable the CUPS snmp backend by default? It will give us auto-detection of network printers for free in all printer setup tools (gnome-cups-manager, CUPS web interface, KDE Print Manager, ...).
<tkamppeter> Currently, it is very stable and reliable, Mike Sweet has fixed several incompatibilities with certain printer brands and so it detects nearly every network printer and its preferred protocol and correct URI.
<sabdfl> tkamppeter: is this an open, listening port by default you want?
<tkamppeter> No, the snmp backend is not a daemon. I searches the local network for printers by accessing the printer's SNMP port. It does not listen or wait for events, and it is only executed when CUPS is asked to auto-detect printers. It is not executed to do the actual printing.
<elmo> tkamppeter: how does it search the local network?  ping every IP in the network range?
<tkamppeter_> elmo, my connection got interrupted, now I will answer your question again.
<tkamppeter_> elmo, the snmp backend does SNMP broadcast. It asks for the printer MIB and so it gets only answers from printers
<tkamppeter_> And it only broadcasts into the local network(s), not into the internet (this is also configurable)
<alexmac> hi people, how do I request that an ubuntu package is updated? wacom-tools is rather out of date and I'd like it updated so that people can use my tablet configuration applet: http://alexmac.cc/tablet-apps
<LaserJock> alexmac: we are past Upstream Version Freeze.
<alexmac> so when will it next get upgraded?
<LaserJock> the release after Feisty
<alexmac> ahh, ok
<shawarma> Is infinity on holiday or something?
<sabdfl> mdz: what time is the tb meeting tomorrow?
<kwwii> anyone here "in the know" with Yelp?
<mdz> sabdfl: 2000 UTC
<mdz> shawarma: I'm not sure, he might be.  are you having trouble getting responses from him?
<sabdfl> mdz: i can be there
<mdz> sabdfl: ok, we'll have quorum then
<mjg59> I ought to be there
<Riddell> kwwii: #ubuntu-doc might be a better bet
<tenco> what script spawns this process? : "/bin/dd bs 1 if /proc/kmsg of /var/run/klogd/kmsg"
<tenco> it's heavy on disk io for several minutes
<mdz> tenco: klogd
<mdz> if it's busy, it's because the kernel is logging messages
<tenco> i dont get it. /var/run/klogd/kmsg has a size of 0 bytes
<tenco> such high disk io cant be from logging. and then /var/run/klogd/kmsg should be a huge file
<LaserJock> kwwii: what do you need?
<tenco> whats odd, too: this command is broken. it will not
<tenco> ...run
<Riddell> pitti: new kdelibs patch up at bug 84717, let me know if that looks good to upload now
<Ubugtu> Malone bug 84717 in update-manager "SRU: updates necessary for Kubuntu Upgrade Tool in Edgy" [Undecided,Needs info]  https://launchpad.net/bugs/84717
<pitti> Riddell: Ah, will have a look tomorrow, thanks
<pitti> Riddell: I'm just trying to figure out how to treat strings for pyqt -- do I have to use the .fromUtf8()/.utf8() methods everywhere?
<kwwii> LaserJock: there is a guy in another channel who redesigned the help center, but now he needs help on various points which I cannot begin to answer...looking for someone who knows more
<LaserJock> redesigned?
<LaserJock> kwwii: is that  h4writer_ ?
<kwwii> LaserJock: yes, it is
<Riddell> pitti: yes, it does seem to need it everywhere
<shawarma> mdz: Well yes, but not in general. Just today.
<mdz> shawarma: it's the middle of the night where he is at the moment
<shawarma> mdz: I know. I pinged him 22 hours ago. :-)
<shawarma> pinged? pang? oh well..
<shawarma> I've never been to Australia, but AFAICT it must have been day at some point during those 22 hours. :-)
<mdz> perhaps he didn't see your message on IRC and you should send email instead
<shawarma> That's an idea as well.. I'll do that.
<shawarma> mdz: Thanks.
<mdz> bug 88134 could use a look from someone more familiar with cdbs
<Ubugtu> Malone bug 88134 in python-apt "Package is empty except for documentation" [High,Unconfirmed]  https://launchpad.net/bugs/88134
<seb128> mdz: I think mvo has that on his todo, he spoke about it today
<mdz> hmm, I looked at the bug list before filing it and didn't see it there
<seb128> well he complained about breaking python-apt and not testing before uploading
<mdz> it's generating a lot of duplicates by breaking update-notifier
<seb128> the fix is easy, either change the destdir for the install or use a .install
<seb128> let me look if mvo fixed it to bzr
<seb128> I'll fix it otherwise
<mdz> looks like cdbs defaults to tmp if it only sees one package
<seb128> no
<seb128> cdbs use debian/package-name if there is one package
<seb128> and debian/tmp otherwise
<mdz> oh, right, I read it backwards
<seb128> and then we use .install to move them to the different binaries
<seb128> or you can set the install dir to debian/rules to be debian/package-name
<mdz> python-apt installs the debug bits separately to debian/python-apt-dbg, and leaves the rest in debian/tmp
<seb128> doko broke deskbar-applet the same way, I'm wondering how many package he uploaded without trying if they worked
<seb128> hum
<seb128> mvo did python-apt uploads that afternoon
<adam0509> hi
<adam0509> I'm a Windows noob coming to linux I want to ask u : why you have removed "disks-admin" from Edgy Eft ? This tool was sooo great !!
<doko_> seb128: before you spread fud, please see http://librarian.launchpad.net/6457135/buildlog_ubuntu-feisty-i386.python-apt_0.6.20ubuntu6_FULLYBUILT.txt.gz
<doko_> I'm looking at the package now
<seb128> doko_: I'm looking as well, and I don't spread fud
<mdz> debian/python-apt.install went missing
<mdz> -debian/tmp/usr/lib/python*
<mdz> -debian/tmp/usr/share/python-apt
<seb128> so mvo broke it? ;)
<seb128> doko_: sorry, I though you did the same as for deskbar-applet :p
<mdz> seb128,doko_: I suspect it wasn't added to bzr
<seb128> ah, might be
<seb128> mvo was in fact complaining that doko did changes without updating bzr this afternoon IIRC
<seb128> and he went to look at the debdiff to update bzr before doing the changes he was working on
<seb128> he probably overlooked that
<doko_> yeah, it doesn't have a X-vcs header; it's difficult to remember which packages use which vcs
<mdz> python-apt isn't on BzrMaintainedPackages
<Sp4rKy> hi there
<seb128> let's just do an upload with the .install and we will sort with mvo how is python-apt maintained tomorrow
<mdz> yep, I'll do so and mail mvo
<doko_> hmm, how did he upload 0.6.20ubuntu8 without setting the ubuntu maintainer address?
<seb128> doko_: he uses an edgy desktop I think
<mdz> seb128: seriously?
<seb128> well, he had edgy on his laptop during the Oslo sprint and feisty to vmware
<seb128> not sure when he's at home
<seb128> I think he has a feisty desktop as well at home
<seb128> he might just have built the package from bzr on the laptop or something
<stgraber> shawarma: Thank you for working on the NetworkManager VPN bugs, it'll be a really usefull and widely used software once those small "missing features" added
<dieman> hrm
<dieman> person in my boots back in cs.umn.edu land is seeing this on ubuntu machines:
<dieman> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=369536
<Ubugtu> Debian bug 369536 in libc6 "netgroup: nis in nsswitch.conf causes libc6 to fail and programs like sudo" [Important,Open]  
#ubuntu-devel 2007-02-27
<shawarma> stgraber: No problem. I also think they're an important piece of the big easy-networking puzzle.
* pochu is off to bed very happy as he is now an ubuntu member :)
<pochu> good night!
<dholbach> good morning
<Kagou> hi
<pitti> Good morning
<dholbach> ogra: new gnome-screensaver for you :)
<dholbach> Mithrandir, cjwatson_, mdz: can you consider bug 86305 please?
<Ubugtu> Malone bug 86305 in gthumb "UVF exception: gthumb 2.9.3" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86305
<kwwii> dholbach: I pushed a gdm last night, you might want to check that I didn't b0rk the setup.py
<dholbach> kwwii: alrighty
<dholbach> kwwii: looks super
<kwwii> dholbach: great :-)
<kwwii> now if I could get the session splash to appear for more than 3 seconds I could finish that as well
<kwwii> dholbach: do you know where the bg color is set? (ie the bg color shown while the session splash is shown)?
<Mithrandir> dholbach: do you have a diffstat?
<dholbach> kwwii: feisty-wallpapers ubuntu-wallpapers.xml.in
<kwwii> dholbach: thnx :-)
<dholbach> Mithrandir: attached
<Mithrandir> dholbach: I'm wary of it; it's a large bunch of changes.
<Mithrandir> dholbach: however, bugs like 409799 looks quite scary.
<dholbach> yeah :-/
<Mithrandir> dholbach: have you played with it for a bit to see if you can spot any immediate problems?
<dholbach> i played a bit with 2.9.2 and that was fine, I'll let you know about 2.9.3 once I'm through with the other gnome updates
<Mithrandir> dholbach: thanks. 
<Mithrandir> dholbach: what's the status of the RC tarballs from gnome and getting them packaged?
<dholbach> working hard on it - looks like most of them got rolled over night
<Mithrandir> it was a question, not a nag. :-)
<dholbach> I understood it as that. :-)
<Mithrandir> good to hear.
<pitti> hrmpf #$(*# no X after reboot
<LaserJock> did you try mv'ing your xorg.conf out of the way?
<LaserJock> that worked for me today
<tepsipakki> pitti: I guess it doesn't find all fonts?
<fabbione> pitti: Xorg.0.log please?
<fabbione> tepsipakki: if that's the case,  one patch has been dropped in the merge
<pitti> no, don't worry guys, it's just that lrm for -9 is not yet available
<Hobbsee> oh good, as i'm just updating :P
<fabbione> pitti: true that :)
* pitti looks in NEW
<Mithrandir> oh, this'll be a fun herd, then.
<Hobbsee> oh yes, so it isnt
* Mithrandir waves to Hobbsee 
<fabbione> Mithrandir: and what's different from the others? :)
<Hobbsee> heya Mithrandir!
<pitti> Mithrandir: oh, herd this Thursday?
<Mithrandir> pitti: indeed.
<pitti> Mithrandir: oh, then I indeed need to talk to you
<fabbione> Mithrandir: did you get my report yesterday?
<Mithrandir> fabbione: I did, yes.  It looks quite good.
<Mithrandir> pitti: shoot
<pitti> Mithrandir: my plan right now was to review/promote compiz/desktop-effects and put it into the -desktop seed
<fabbione> Mithrandir: good... hopefully we will fix the export format to something more readable
<pitti> Mithrandir: should that go into herd 5?
<Mithrandir> pitti: go for it.
<Mithrandir> pitti: we still need the new GNOME tarballs which are due today.
<pitti> Mithrandir: ah, I'll NEW lrm and backports-modules, ok?
<Mithrandir> thanks a lot.
<pitti> Mithrandir: also, I would like to sort out bug 67925 RSN
<Ubugtu> Malone bug 67925 in Ubuntu "Do not ship translations without matching input support" [High,In progress]  https://launchpad.net/bugs/67925
<pitti> Mithrandir: but that'll require large amounts of CD space, so dropping some translations in exchange
<Mithrandir> we're not very high on the number of translations atm.
<Mithrandir> iirc
<pitti> Mithrandir: at least the good thing is that the fewer translations we ship, the fewer input methods we have to ship
<Mithrandir> heh
<pitti> the thing that sucks is that the Chinese input tables require some 10 MB, and it's on the top of the list
<pitti> Mithrandir: I'll do some more detailled research and come back to you with the plan
<Mithrandir> ok, thanks.  I think post-herd5 might be a plan.
<pitti> Mithrandir: ok, so I'll don't do that for h5
* pitti cleans up the other binary NEW stuff while he is at it
<LaserJock> you're going to put compiz into Main?
<pitti> LaserJock: under protest, but yes
<Mithrandir> pitti: fiddling with what goes on the cd is a lot less painful if you don't have me standing over you asking whether we're there yet. :-)
<pitti> Mithrandir: heh, yes :)
<LaserJock> pitti: yikes, good luck with that :-)
<pitti> LaserJock: s/)/(/... that thing really sucks in various dimensions (usability, slowness, not working at all with nvidia, etc.)
<Hobbsee> pitti: compiz is being put as default now?
<pitti> Hobbsee: noooo!
<Hobbsee> pitti: didnt think so.  hence why are you putting it into the desktop seed?
<pitti> Hobbsee: but we want desktop-effects installed by default for an 'one click to break your desktop' experience
<Mithrandir> yes, we'll remove metacity and kwin.
* Mithrandir hides.
<Hobbsee> pitti: ahhhh....gotcha.
* Hobbsee thwaps Mithrandir 
<pitti> it's all part of GettingRidOfTheDesktop spec
<LaserJock> so it'll be install, just not turned on?
<LaserJock> *installed
<pitti> LaserJock: right
<LaserJock> seems sort of reasonable
<Hobbsee> Mithrandir: neither beryl nor compiz works with kwin terribly well
* pitti avoids sentences which contain both 'compiz' and 'reasonable'
<pitti> no, I'm not bitter
<Hobbsee> pitti: heh
* Mithrandir gives pitti some pills to make him relax.
<Mithrandir> :-)
<pitti> Mithrandir: yay candies!
<LaserJock> well, considering all the trouble we go to with MIRs, it seems like a bit of a double standard
<Lathiat> not working with nvidia?  i found compiz/beryl worked far more often with nvidia than ati
<Lathiat> in fact i cant get neither compiz or beryl to run on my ati atm
<pitti> Lathiat: well, if you count 'being slow and having no window decorations at all' working, then it works
<pitti> Lathiat: the window decorations can be fixed with a magical xorg.conf option
<Lathiat> hrm, works fantastically for me *shrug*
<fabbione> i was never able to get compiz to work with nvidia
<fabbione> i should probably give it another shot
<Lathiat> pitti: oh yeh i think i had that option.. good point :P
<pitti> which in turn breaks other things, but makes compiz work
<Lathiat> heh
<Lathiat> yeh the compiz+beryl stuff is still not "even nearly there" ;)
<Lathiat> its a fantastic demo
<Lathiat> and i dont mind using it for a bit but then it does weird things and then i just turn it off :P
<Lathiat> with jsut the basic plugins, *mildly* wobbly windows, cube, brief fade in/out
<Lathiat> burning windows is a bit much for me
<Hobbsee> burning windows?  neat!
<Lathiat> yeh its neat the first time
<Lathiat> then you find the "multi color" option, its neat the second time
<Lathiat> and then suddenly its extremely annoying
<Hobbsee> heh
<Mithrandir> I want exploding windows, with particle effects.  And sounds.
<Hobbsee> Mithrandir: you have tried xblast, presumably?
<Lathiat> hrm
<Lathiat> does launchpad.net prevent google indexing bug reports or something
<Lathiat> trying to find the bug where the fireworks screensaver with sounds interupts him & his girlfriend
<Lathiat> and causes his grandmother to faint
<Lathiat> and the neighbours to make a complaint
<Lathiat> or something along those lines
<Mithrandir> Hobbsee: no sound and no particle effects, iirc?
<Lathiat> but google & launchpad search are failing me
<Lathiat> oh well home time back later
<Hobbsee> Mithrandir: true that.  but blasting windows is fun
<seb128> ogra: new dia and gnome-screensaver to package
<mneptok> everybody out of the pool!
<pitti> hi lool
<pitti> Mithrandir: hm, u-meta upload is still missing, the current ./update does very weird things for me (removed tons of stuff)
<carlos> pitti, seb128: Feisty opening is planned for tomorrow morning
<carlos> (translations)
<pitti> yay!
* pitti crosses fingers that it'll work this time
<carlos> and we will start importing all new .pot and .po files from feisty (at that time, we will get a copy of Edgy)
<seb128> carlos: nice!
<pitti> maybe they'll make it to herd-5
<seb128> how long is going to take the import?
<Mithrandir> pitti: hmm.
<seb128> pitti: I doubt of it, import is going to takes days probably
<pitti> ah, right
<carlos> pitti: and Thursday, I will prepare new language packs for it
<carlos> seb128: at least two days...
<Hobbsee> tepsipakki: argh.  my downwards scroll has broken.  (on my touchpad)  - the rest seems to work, though
<poningru> question... isnt thursday supposed to herd5... would the import cause troubles for that?... just a thought being thrown out I really dont have any clue about the process
<Mithrandir> poningru: I don't see why it would cause problems for that?
<poningru> ok cool
<tepsipakki> Hobbsee: ok, I'll look around for a fix
<fabbione> feh
<fabbione> so what's the workaround for X server not being able to find fixed fonts? :)
<tepsipakki> fabbione: you tell me :)
<fabbione> tepsipakki: does reverting the server to an older version work?
<tepsipakki> fabbione: it seems that for some /usr/share/X11/fonts is left behind by some package
<fabbione> that shouldn't matter
<tepsipakki> and so the symlink is not made
<fabbione> ah
<fabbione> where are fonts now?
<asac> hmmm ... how can I decouple falsely marked duplicates in lp?
<seb128> /usr/share/fonts/X11
<fabbione> seb128: ok thanks
<seb128> asac: click on "mark duplicate" and empty the entry
<seb128> fabbione: np
<fabbione> but.. hmm
<fabbione>  /usr/share/fonts/X11 should be hardencoded in the server
<fabbione> i recall this patch somewhere
<asac> seb128: naturally :) 
<tepsipakki> fabbione: in our previous version?
<fabbione> tepsipakki: yes
<fabbione> checking now...
<fabbione> it might be you forgot or drop a patch by mistake
<seb128> fabbione: Debian dropped some patches and changed configure option for fonts
<tepsipakki> fabbione: we (and debian) used to have "--with-fontdir" as a configure option
<tepsipakki> and that was changed by debian in September to --with-font-path
<tepsipakki> don't know if that has anything to do with this
<seb128> fabbione: what do you think about http://cvs.fedora.redhat.com/viewcvs/rpms/xorg-x11-server/devel/xorg-x11-server-1.1.1-builtin-fonts.patch?rev=1.1&view=markup ?
<fabbione> seb128: i can't look at it right now.. i am in deep text mode :)
<fabbione> tepsipakki: it might easily be...
<seb128> fabbione: 
<seb128> -#ifdef KDRIVESERVER
<seb128>  	BuiltinRegisterFpeFunctions();
<seb128> -#endif
<seb128> "- Enable builtin fallback versions of cursor and fixed fonts."
<seb128> patch from Fedora
<fabbione> might be
<seb128> that would be a good idea maybe, if that makes xorg robust to fonts problems like that
<fabbione> seb128: i am checking some diff stuff now.. but i will stay in text mode to test the fix so i am unable to do a bunch of things easily
<tepsipakki> fedora also has "built-ins" appended to the --with-font-path
<tepsipakki> which maybe is what makes that patch to actually work
<fabbione> i can see a patch has been dropped between 1.1.1 and 1.2
<fabbione> 11_debian...
<fabbione> in 1.1.1
<tepsipakki> looking..
<fabbione> the change is relevant to that font-path/font-dir change
<tepsipakki> fabbione: ok.. sigh
<tepsipakki> the numbering confused me
<fabbione> tepsipakki: the patch was dropped by Debian
<seb128>   [ Eugene Konev ] 
<fabbione> but we need to understand why
<seb128>   * Use --with-default-font-path instead of --with-fontdir.
<seb128>   * Set RGBPath through --with-rgb-path.
<seb128>   * Drop 11_debian_always_use_default_font_path.diff.
<seb128>   * Drop 14_debian_always_look_in_our_module_path.diff.
<seb128>   * Ship SecurityPolicy in xserver-xorg-core.
<seb128> right
<tepsipakki> oh, it was at the same time
<tepsipakki> the change was made..
<fabbione> ahhhh
<fabbione> it looks like a typo somewhere
<fabbione> indeed
<fabbione> check the font path in debian/rules
<fabbione> " X11/fonts/Type1"
<fabbione> there is an extra space
<fabbione> let me try to rebuild without that space
<fabbione> that path seems just wrong to me
<seb128> hum, right
<fabbione> hmm no
<fabbione> there is the correct one right before
<fabbione> never the less.. that one is wrong
<fabbione> Whisky Foxtrot Tango!
<fabbione> well ok. i understand what's wrong...
<fabbione> basically with the old patch + configure command the default path was added dinamycally
<fabbione> with the new behaviour, we switch to it only if the font path in xorg.conf is totally bogus
<fabbione> in this case the font path is valid because of left overs
<fabbione> and we never look in the other path
* fabbione sighs
<fabbione> so either we fix configs (difficult and bad) or we repatch the server
<tepsipakki> easy to decide ;)
<seb128> or we use the fedora way and use builtin fonts?
<fabbione> seb128: we can try for sure
<tepsipakki> fedora uses both --with-fontdir and --with-font-path
<fabbione> in fact.. as soon as i change the config and add the correct paths it works
<fabbione> seb128: i have a test case here.. so it's easy for me to test...
<seb128> ok
<fabbione> seb128: can you put that fedora patch somewhere i can scp it?
<fabbione> seb128: like chinstrap?
<seb128> fabbione: done, on my user dir on chinstrap
<fabbione> tepsipakki: and we should probably do that too.. the 2 are not mutual exclusive
<tepsipakki> fabbione: seb128 tested it yesterday and that alone doesn't help, but maybe with 'built-ins' added to --with-font-paths it does
<seb128> I was going to say that
<fabbione> yeah
<fabbione> let's try one thing at a time
<fabbione> first seb patch
* fabbione builds
* fabbione gets nausea for looking into X once again...
<fabbione> i HATE YOU ALL :P
<pitti> seb128, Mithrandir: btw, do you plan to update the X video/input drivers for or after h5?
<tuxcrafter> hello guys
<seb128> pitti: there is not lot to update in fact
<tuxcrafter> i have a discussion with some claws mail guys and need some adivce
<seb128> pitti: upstream didn't roll much of new tarballs for drivers apparently
<tuxcrafter> i am trying to build there cvs 
<tuxcrafter> but there are errors in it
<seb128> tuxcrafter: that's not an user support chan, you might want to try #ubuntu
<tuxcrafter> they say the cvs is not for compiling 
<pitti> seb128: ah, ok; is there a list/repo somewhere? I'll add the other packages to my 'to be rebuilt for maintainer' list then
<tuxcrafter> what do you think?
<seb128> pitti: no, but I'm going to keep looking at them today, any hurry or is that afternoon fine for giving you a list?
<pitti> seb128: oh, don't worry, I won't get to 'X' before next week ;)
<seb128> ok, so I will let you know
<pitti> seb128: I'm still at 'l'
* fabbione taps his fingers....
<tuxcrafter> can someone point me to the rules of using a cvs checkout
<tuxcrafter> i believe in this:
<tuxcrafter> i don't want to use tarballs i want to use cvs checkouts and dependencies need to be pointed out before compiling when run the .autogen.sh or .configure.sh script not when you are installing and get errors
<tuxcrafter> but i want some feedback on it
<fabbione> tuxcrafter: this is not the right forum or place to discuss certain things.
<fabbione> please ask in #ubuntu
<tuxcrafter> but ubuntu is for normal users i have developing questions
<tuxcrafter> #ubuntu-motu check them out
<seb128> tuxcrafter: that's not a developing question
<seb128> or not about developing Ubuntu, what is what the chan is about
<tuxcrafter> fabbione: sorry to have bother this list but it is very unclear than what kind of people are in this list. thought there were developers?
<Hobbsee> tuxcrafter: there are.  they're also in other channels.
<fabbione> seb128: the patch is not enough
<seb128> fabbione: :/
<fabbione> tepsipakki: how does fedora call --with-fonts-dirs? or path?
<tepsipakki> ah, they have "--with-default-font-path="unix/:7100,built-ins""
<tepsipakki> and "--with-fontdir=%(pkg-config --variable=fontdir fontutil)"
<tepsipakki> looking at the changelog they added "built-ins" to the path right after that patch
<fabbione> our fontdir would be empty
<tepsipakki> yep
<fabbione> or we need a build-dep
<fabbione> tepsipakki: trying that
<fabbione> built-ins...
<fabbione> tepsipakki: do you have any option to also check what pkg-config in fedora returns?
<tepsipakki> I have access to rhel4/5
<tepsipakki> but they are servers
<fabbione> that won't help
<tepsipakki> oh wait
<tepsipakki> a friend of mine is a fedora-addict :/
<fabbione> ask in #fedora? :)
<fabbione> or even #xorg-devel
<tepsipakki> I'll check my friend first :)
<mneptok> hmmm .... maybe i should deploy a FC VM here ...
<fabbione> even with ccache it takes ages to build this code
<fabbione> tepsipakki: nope.. config path and patch don't help
<fabbione> seb128: ^
<fabbione> so either their server works because of the pkg-config output
<fabbione> or we can safely revert the debian changes into the old ones
<tepsipakki> on FC6 it returns /usr/share/X11/fonts
<seb128> <alex__> seb128: fc6: /usr/share/X11/fonts
<seb128> confirmed :p
<tepsipakki> heh
<fabbione> oh wait
<tepsipakki> so we could hardcode --with-fontdir to /usr/share/fonts/X11?
<fabbione> one more test
<fabbione> no never mind
<fabbione> ok i am back to X and we can look at the solution
<tepsipakki> heh
<tepsipakki> crashed quickly?-)
<ogra> seb128, meh, all gdm related code is vanished from gss
<seb128> ogra: and that's not good because...?
<seb128> ogra: http://bugzilla.gnome.org/show_bug.cgi?id=407964
<Ubugtu> Gnome bug 407964 in dialog "direct fast user switching" [Normal,Resolved: fixed]  
<ogra> yep, saw it in the changelog 
<seb128> that's the work from fedora guys, they want user switching working out of the box for FC7
<seb128> which seems to be a good thing
<ogra> right
<fabbione> re
<ogra> so looks lik i can drop that one completely, nice ...
<ogra> and we need no dep on gdm :)
<Hobbsee> gah....can someone write me a program to always be able to find my carkeys please?
<cjwatson> Hobbsee: #include <stdio.h>\nint main(int argc, char **argv) { printf("they're down the back of the sofa\n"); return 0; }
<Hobbsee> cjwatson: hahaha
* Hobbsee doesnt have a sofa in here
* Hobbsee would be very suprised if they ever managed to be behind the sofa...
<fabbione> tepsipakki, seb128: imho we should temporary revert to the old behaviour
<fabbione> it's know to work
<seb128> fabbione: why "temporary"?
<seb128> either that's right and we should do it
<fabbione> because it might take a while to get to the right fix
<seb128> or it's not and we should better to fix it properly now
<tepsipakki> fabbione: wouldn't it be enough to add "--with-fontdir=/usr/share/fonts/X11"?
<fabbione> tepsipakki: i am not sure... i didn't try that solution
<fabbione> and we keep adding vars.. patch/config options.. etc.
<fabbione> but anyway.. we know what it is
<fabbione> i leave it up to you how you prefer to fix it
<tepsipakki> I'll try --with-fontdir
<fabbione> tepsipakki: can you reproduce the bug locally?
<fabbione> otherwise i can drive you on how to do it
<fabbione> it's pretty simple tho
<seb128> just delete the symlink
<tepsipakki> I should be able to
<tepsipakki> haven't tried
<seb128> and make xorg.conf uses the /usr/share/X11/fonts path
* fabbione ponders food
<jsgotangco> good idea
<mvo> Mithrandir: could you please have a look at bug https://beta.launchpad.net/ubuntu/+source/debian-cd/+bug/86133 ? 
<Ubugtu> Malone bug 86133 in debian-cd "ubuntu-minimal cannot be found - herd 4 upgrade fails" [High,Unconfirmed]  
<tepsipakki> hmm, I really need to set up a local package cache.. painful to keep three machines uptodate via 1Mbit downlink :)
<Mithrandir> mvo: u-m isn't Essential and it seems to be in the archive just fine..
<cjwatson_> mvo: FYI ubuntu-cdimage product not debian-cd sourcepackage in Ubuntu
<Mithrandir> mvo: oh, sorry, I misread the bug report completely.  Ignore me. :-)
<mvo> cjwatson_: oh, sorry. I will remember this for the future
<cjwatson_> mvo: applying, thanks
<mvo> cjwatson_: cool, thanks a lot! lets see if it works as it should :)
<tepsipakki> fabbione: --with-fontdir didn't help.. so I think we'll need to add that patch again
<pitti> Mithrandir: WDYT about an UVFE for bug 87675? changelog looks reasonable
<Ubugtu> Malone bug 87675 in utf8-migration-tool "Please sync utf8-migration-tool (main) from Debian unstable (main)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87675
<Ng> `/win 82
<Ng> gah
<ogra> dholbach, do you know if glibs handling of gthread changed somehow ? i cant get gss to build here ...
<dholbach> ogra: what is the build error?
<ogra> /tmp/buildd/gnome-screensaver-2.17.8/src/gnome-screensaver-dialog.c:529: undefined reference to `g_thread_init'
<dholbach> ogra: i doubt it's glib's fault that g-s-s does not build
<ogra> i'm already depending on glib2.0-dev
<dholbach> last glib upload:  Wed, 17 Jan 2007 10:24:11 +0100
<pitti> Mithrandir: FYI, u-meta uploaded for desktop-effects
<Mithrandir> pitti: thanks.
<ogra> and the configure output even lists it
<ogra> Base libs:                -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXfixes -lpango-1.0 -lcairo -lX11 -lgmodule-2.0 -ldl -ldbus-glib-1 -ldbus-1 -lgconf-2 -lORBit-2 -lgthread-2.0 -lrt -lgobject-2.0 -lgnome-menu -lglib-2.0 
<dholbach> ogra: how many patches onfor g-s-s do we have?
<Mithrandir> dholbach: how's the new tarballs coming?  As in, should I freeze now-ish and just let the rest through or would you rather I wait for a bit?
<ogra> dholbach, one ... the one that checks for the LTSP_CLIENT env var
<ogra> a two liner
<dholbach> Mithrandir: better ask seb128 once he's back on irc
<Mithrandir> dholbach: kthx
<dholbach> Mithrandir: I just came back from helping a friend with moving
<dholbach> Mithrandir: so i need to read mails first
<dholbach> ogra: can you upload the source package - I'l have a look
<Mithrandir> pitti: tbh, I think we should just throw it out of main.
<pitti> Mithrandir: I just thought the same; but syncing it would be a good idea nevertheless
<ogra> dholbach, sure, but i'ts not complete yet, so please dont upload it ...
<dholbach> ogra: sure
<seb128> what package?
<Mithrandir> pitti: oh sure, if the motus want it.
<Mithrandir> seb128: hiya; how's the tarballs coming along?
<dholbach> seb128: g-screensaver ftbfs - i'll take a look at it
<pitti> Mithrandir: I'll go ahead and unseed/demote/sync it then
<Mithrandir> pitti: cheers.
<seb128> Mithrandir: mostly done, there 6-7 small tarballs left
<Mithrandir> seb128: coolie.  Are you ok with me freezing now and just letting the last ones through when they show up, then?
<seb128> Mithrandir: yes
<ogra> seb128, gss
<ogra> <ogra> /tmp/buildd/gnome-screensaver-2.17.8/src/gnome-screensaver-dialog.c:529: undefined reference to `g_thread_init'
<ogra> but 
<ogra> <ogra> Base libs:                -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXfixes -lpango-1.0 -lcairo -lX11 -lgmodule-2.0 -ldl -ldbus-glib-1 -ldbus-1 -lgconf-2 -lORBit-2 -lgthread-2.0 -lrt -lgobject-2.0 -lgnome-menu -lglib-2.0 
<ogra> seb128, ^^^
<seb128> ogra: does it #include <glib.h>?
<ogra> libgthread is there and linked ... but the compiler complains about it 
<ogra> yes
<pitti> ogra: do you want desktop-effects/compiz in edubuntu-meta?
<seb128> pitti: are we getting compiz to desktop now?
<pitti> ogra: and, initially, -desktop seed of course
<seb128> ogra: where is the source package?
<pitti> seb128: already done, as per last week's discussion
<ogra> pitti, nope
<pitti> ogra: 'k, because I need to merge seeds
<ogra> pitti, it's in main through ubuntu-desktoip, right ? 
<seb128> pitti: good, would be nice to fix desktop-effects, I'll have a look at it today
<pitti> ogra: right
<pitti> seb128: what to fix in particular?
<seb128> pitti: it's not working atm I think, it breaks the plugins list
<ogra> thats enough ... i fear it might distrub ltsp ...
<seb128> pitti: I start compiz with "compiz --replace gconf" when I try it
<seb128> ogra: the error is a linker one?
* ..[topic/#ubuntu-devel:Mithrandir] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Main frozen for herd 5
<ogra> seb128, nope, compiler
<seb128> ogra: do you have -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include ?
<pitti> Riddell: do you want compiz-kde in kubuntu-desktop?
<pitti> Riddell: (I guess not, but checking)
<ogra> seb128, only -ldl /usr/lib/libglib-2.0.so
<seb128> ogra: do you have the src package somewhere?
<ogra> seb128, still uploading, give it a second, my upstream BW sucks
<Riddell> pitti: since it's an empty package it wouldn't do much good
<pitti> oh, heh :)
<ogra> seb128, http://people.ubuntu.com/~ogra/gss/
<seb128> ogra: 
<seb128> PKG_CHECK_MODULES(GNOME_SCREENSAVER_DIALOG,
<seb128>         libglade-2.0 >= $GLADE_REQUIRED_VERSION
<seb128>         gtk+-2.0 >= $GTK_REQUIRED_VERSION)
<seb128> that should be enough
<seb128> let me try
<ogra> gah, autoconf mess
<Mithrandir> it should PKG_CHECK_MODULES(GSS, [libglade-2.0 ... ] ), btw.
<dholbach> ogra: new dia also
<ogra> dholbach, already on it
<dholbach> yoohoo
<ogra> how do we handle packages that are one version ahead of debian but use their packaging of the older package, do i need to add XSBC-Original-Maintainer or just change the maintainer field to my name ? 
<ogra> (dia is such a candidate)
<seb128> ogra: we use XSBC-Original-Maintainer for GNOME packages atm
<ogra> so i should add it additionally then, right ? gss doesnt have that prob, its your package ;)
<seb128> ogra: gnome-screensaver builds fine on my desktop
<ogra> hmm, in pbuilder  ?
<seb128> no, on feisty
<seb128> you might lack a Build-Depends then
<seb128> let me try with pbuilder
<ogra> i added lobglib2.0-dev already ...
<ogra> *lib
<ogra> that shouldnt be the prob ...
<seb128> and you are sure it was installed?
<seb128> to your pbuilder
<ogra> unlkess gthread went secretly to its own package :)
<seb128> nop
<seb128> let me try with pbuilder
<ogra> yes, i saw it getting installer
<ogra> *installed
<ogra> i wouldnt ask here if i hadnt tried all options i know ;)
<seb128> does it build on your desktop?
<ogra> hmm, thats something i usually dont try ... have to wait for dia eating my cpu ...
<ogra> seb128, btw dont we need a package of consolekit ? seems gdm, gss and gpm all switch to it before 2.18
<seb128> pitti: ^
<seb128> did you look at it?
<seb128> Fedora is going to have user switching integration with it for FC7
<seb128> would be nice ot have, we are past feature freeze though
<seb128> but since those features are part of GNOME 2.18 we might want to give it a try
<pitti> seb128: argh
<seb128> what?
<seb128> that's not policykit
<pitti> shouldn't Gnome be past feature freeze as well?
<seb128> it's consolekit
<pitti> right, I know
<seb128> pitti: they have those options for a while
<pitti> I'll take a look at it if we really need it
<seb128> that's just optional
<ogra> seb128, well, i'm not very keen on having it either, ldm doesnt support it yet and i dont know what happens if you have a desktop without it 
<seb128> but if FC7 will have that
<seb128> we could try to do it as well
<ogra> in the beginning it looked lik i just have to set some env vars, but it mutated a lot
<ogra> seb128, weird, gss builds on my desktop 
<ogra> oh, wait
<ogra> no, i lied
<seb128> ogra: it's building to pbuilder for me atm
<seb128> ?
<ogra> gnome-screensaver-dialog.o: In function `main':
<ogra> /home/ogra/packages/gnome-screensaver-2.17.8-bastel/src/gnome-screensaver-dialog.c:529: undefined reference to `g_thread_init'
<ogra> again ...
<Mithrandir> ogra: can you post the build log somewhere?
<seb128> k, doing the same with pbuilder there
<ogra> Mithrandir, http://paste.ubuntu-nl.org/7795/ for the relevant part
<ogra> i can get you a full log of the desktop build if that helps
<Mithrandir> yes, please.
<Mithrandir> (if that's failing?)
<ogra> both is failing  here
<ogra> pbuilder as well as a plain debian/rules binary
<seb128> ogra: you lack a Build-Depends on libgnomekbdui-dev BTW
<ogra> meh, i know i added that at some point when 2.17 started ... 
<ogra> i'll add it
<seb128> it's not there
<ogra> no, but do you remember me nagging ? 
<seb128> ogra: and on libxkbfile-dev
<ogra> ok
<seb128> that fixes the build problem
<seb128> maybe the code path when building without it is buggy
<ogra> http://people.ubuntu.com/~ogra/gss/gss_log.txt
<ogra> Mithrandir, ^^
<ogra> seb128, trying now
<ogra> i wouldnt understand why it fails on g_thread_init then though
<ogra> hmm, but it looks good ...
<Mithrandir> ogra: uh, that build log doesn't look like it failed?
<ogra> Mirv, hmm, right, the end is missing
<ogra> Mithrandir indeed
<seb128> ogra: 
<seb128> -LIBGNOMEKBDUI_CFLAGS=''
<seb128> -LIBGNOMEKBDUI_LIBS=''
<seb128> +LIBGNOMEKBDUI_CFLAGS=' '
<seb128> +LIBGNOMEKBDUI_LIBS='-pthread -lgnomekbd -lgnomekbdui -lxklavier -ldbus-glib-1 -ldbus-1 -lgnomeui-2 -lSM -lICE -lbonoboui-2
<seb128>  -lgnome-keyring -lxml2 -lgnomecanvas-2 -lgnome-2 -lpopt -lart_lgpl_2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 
<seb128> -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXfixes -lpango-1.0
<seb128>  -lcairo -lX11 -lbonobo-2 -lgnomevfs-2 -lbonobo-activation -lgconf-2 -lgmodule-2.0 -ldl -lORBit-2 -lgthread-2.0 -lgobject-2
<seb128> .0 -lglib-2.0  '
<seb128> ogra: something probably benefit from the LIBGNOMEKBDUI_LIBS definition
<dholbach> kwwii: would you mind if i change the maintainer field of the artwork packages to ubuntu-art@lists.ubuntu.com?
<ogra> but that seems somewhat wrong ...
<seb128> ogra: as said before
<ogra> anyway, it builds with the added deps
<seb128> " maybe the code path when building without it is buggy"
<ogra> thanks ! 
<seb128> np
<dholbach> three cheers for magic Sb
<ogra> do you think thats worth an upstream bug ? 
<seb128> ogra: yep
<ogra> oki, will file
<seb128> ok, gotcha
<seb128> gnome_screensaver_dialog_LDADD =	\
<seb128> 	$(GNOME_SCREENSAVER_DIALOG_LIBS)\
<seb128> 	$(SAVER_LIBS)			\
<seb128> 	$(AUTH_LIBS)			\
<seb128> 	$(LIBGNOMEKBDUI_LIBS)		\
<seb128> 	$(NULL)
<seb128> 
<seb128> none of those has -lgthread-2.0 out of LIBGNOMEKBDUI_LIBS
<gpocentek> Mithrandir: I have new goffice and gnumeric almost ready (gnumeric is building), is it ok to upload them, do I need to provide something?
<seb128> ogra: ^
<ogra> aha
<Mithrandir> gpocentek: they should be fine to just upload.
<Mithrandir> seb128: goffice and gnumeric are part of gnome or not?
<seb128> Mithrandir: no
<seb128> gnome-office is not official part, it doesn't follow the GNOME schedule, freezes, etc
<Mithrandir> seb128: ok.  Have they traditionally have had standing UVF exceptions?
<seb128> usually we do file UVF exception requests and they are accepted
<gpocentek> Mithrandir: I can file UVF bugs if you prefer
<Mithrandir> gpocentek: please.
<gpocentek> ok
<gpocentek> Mithrandir: could you check if my xfwm4 upload is stuck somewhere (4.4.0-0ubuntu2) please?
<gpocentek> I didn't receive a rejected/accepted mail
<seb128> ogra:  
<seb128> --- configure.ac.orig   2007-02-27 14:41:46.000000000 +0100
<seb128> +++ configure.ac        2007-02-27 14:42:19.000000000 +0100
<seb128> @@ -63,6 +63,7 @@
<seb128> 
<seb128>  PKG_CHECK_MODULES(GNOME_SCREENSAVER_DIALOG,
<seb128>          libglade-2.0 >= $GLADE_REQUIRED_VERSION
<seb128> +       gthread-2.0
<seb128>          gtk+-2.0 >= $GTK_REQUIRED_VERSION)
<seb128>  AC_SUBST(GNOME_SCREENSAVER_DIALOG_CFLAGS)
<seb128>  AC_SUBST(GNOME_SCREENSAVER_DIALOG_LIBS)
<seb128> ogra: that fixes it probably
<ogra> likely
<Mithrandir> gpocentek: http://librarian.launchpad.net/6527059/bWLxhr0amPIG26EQeuM5mxMFP3U.txt ; use @, not at.
<seb128> Mithrandir: could you give a retry to the random GNOME packages which didn't build on amd64 and sparc?
<Mithrandir> seb128: yes, I've just been waiting for canvas to be published, but I think it is now
<kwwii> dholbach: sure, if you think that will help
<gpocentek> Mithrandir: ah ok, thanks
<seb128> Mithrandir: ok, good, thank you
<Mithrandir> seb128: but thanks for the prod nevertheless. :-)
<seb128> np ;)
<pitti> argh, gnome-spell is ftbfs in feisty
<pitti> yay me for becoming TIL for so many packages :)
* seb128 hugs pitti
<seb128> pitti: don't complain, you didn't touch libx11, xorg and xorg-server :p
<pitti> seb128: urgh, can you please have a quick look? might be a transient problem http://librarian.launchpad.net/6556688/buildlog_ubuntu-feisty-amd64.gnome-spell_1.0.7-1ubuntu2_FAILEDTOBUILD.txt.gz
<seb128> pitti: cf what I said to Tollef like 1 min ago ;)
<pitti> seb128: ah, I see; sorry
<seb128> pitti: nothing to be sorry about, that's going to sort itself ;)
<Mithrandir> pitti: already given-back
<pitti> Mithrandir: cheers
<Mithrandir> Riddell: your kde4base upload broke; looks like a missing build-dep on libldap-dev
<Riddell> Mithrandir: curious, I'll look into it
<ogra> whee, evo crash out of the blue ...
<ogra> sigh, 35Mb apport ....
<jdong> ogra: hehe ever had Xgl using 450MB RAM crash on you? ;-)
<jdong> the apport is quite a tad more interesting.
<ogra> nah, i dont use xgl :)
<ogra> evo and ff are probably the biggest things i use regulary ... oo.o very rarely
<jdong> :)
* ogra wonders whats done first, the pbuilder-satisfydepends for the gss tesbuild or apports 35M upload ... 
<ogra> gah
<ogra> apport wins ...
<pitti> \o/
<pitti> apport FTW!
<ogra> tar: gnome-screensaver-2.17.8/data: Cannot mkdir: No space left on device
<ogra> pitti, ten mins ago i had 35M more space on my disk :P
<seb128> ogra: just upload, it builds fine
<seb128> if you tested it on your desktop I mean
<elmo> ogra: buy a bigger disk
<ogra> it just cheated to make gss stop building :P
<elmo> if you can't afford 35M of space, you have bigger problems
<seb128> doko: what did you change to gnome-python to make it not Depends on python2.4?
<jdong> BenC: ping; curiousity, what's up with iwlwifi? will it be in Feisty? will it replace ipw3945?
<sebas> Seveas: ping
<sebas> Seveas: LH just told me you've got email from her.
<doko> seb128: disable the linking of the extension module with -lpython
<seb128> doko: you changed the Makefile.am and ran autotools then or patched the Makefile.in by hand? just trying to figure the easier way to do that
<doko> let me look
<ogra> Mithrandir, dia and gss for approval in the queue
<doko> seb128: sent you email
<gismo_> hello all
<seb128> hi gismo_
<Mithrandir> ogra: cheers.
<gismo_> I posted my question on ubuntu-motu, I think it's better
<eilker> hi to all, i need some advices...
<eilker> we wanna replace all icons and all themes of ubuntu with my icons and themes, how can i do it ? any experience ?_ ,this may be a new iso, or a package in repo's to change all icons and themes of kubuntu, is it possible ?
<eilker> where to start...etc...
<pitti> Mithrandir: http://pastebin.ca/374339 -> trivial fix for dhcp3, ok to upload?
<BenC> jdong: I tried it, and it didn't work
<jdong> BenC: ah, ok :)
<seb128> Mithrandir: could you accept the gedit upload, it should fix python plugins on amd64
<pitti> BenC: btw, is there anything I need to change in apport bug bug 87065? i. e. did the rules for CORE_REAL_RLIM change?
<BenC> pitti: I'm pretty sure I commented on the changes in the bug
<BenC>  bug 87065
<Ubugtu> Malone bug 87065 in linux-source-2.6.20 "does not set CORE_REAL_RLIM correctly" [Undecided,Confirmed]  https://launchpad.net/bugs/87065
<pitti> BenC: right, but I couldn't decipher it, sorry
<seb128> doko: thanks for the mail
<seb128> doko: btw
<seb128> doko: 
<seb128> $ python-dbg -c 'import ORBit'
<seb128> Traceback (most recent call last):
<seb128>   File "<string>", line 1, in <module>
<seb128> ImportError: /usr/lib/python2.5/site-packages/ORBit_d.so: undefined symbol: Py_InitModule4
<seb128> doko: do you know what cause that and how to fix it?
<seb128> hum
<seb128> looks like you did changes out of the debian dir for that package as well :/
<pitti> BenC: i. e. I already do check the variable, but it's not set correctly ATM
<BenC> pitti: Basically, CORE_REAL_RLIM is always set now
<BenC> pitti: it can be >= 0
<pitti> BenC: ok, so the second case in comment 4 doesn't happen any more
<BenC> right
<BenC> so you always need to check it to decide how much to write out
<pitti> BenC: right, and I already do
<jdong> BenC: got any ideas on tifm7xx1 not working anymore?
<jdong> it's some sort of 2.6.20 regression
<pitti> BenC: btw, for unlimited, it's set to '-1' now in -9, so I need to update the test
<jdong> and I've seen it tossed around lkml too....
<BenC> pitti: Ah, I had forgotten that
<BenC> pitti: So -1 is the same as your second case
<pitti> BenC: ok, so maybe the test suite just fails differently due to that now, I'll check
<doko> seb128: no, looking at it. most likely it's built with -I/usr/include/python2.5, not -I/usr/include/python2.5_d
<pitti> BenC: ah, indeed it seems to work now with the smaller ulimits (it's not empty any more); great!
<dholbach> kwwii: I just thought it'd reflect more who'S in charge
<bddebian> Heya
<seb128> doko: well, I update GNOME packages by keeping the debian dir, I'll look for what you changed out of it and which got dropped
<doko> seb128: I probably didn't put the regenerated files in a patch file, sorry; the non-rebuilt part should be in configure.ac or acinclude.m4
<seb128> doko: ok, thank you, and you run only aclocal and autoconf?
<seb128> doko: or do you need other autotools for that?
<doko> seb128: I know, that dholbach did run autoreconf -i for dbus-python, but aclocal & autoconf should be enough for the other gnome stuff; just make sure that $PYTHON-config --includes is used in the generated configure script
<seb128> ok, thank you
<pitti> Mithrandir: I need to upload a new apport to match the new 2.6.20-9 kernel behaviour: http://pastebin.ca/374373
<kwwii> dholbach: as long as it does not bring a lot of discussions about decisions that are out of my hands, I am happy with the change :-)
<dholbach> kwwii: I think that that mail address is more suited than mine ;-)
<pitti> Mithrandir: tentatively uploading apport, btw
<kwwii> dholbach: lol, yeah, probably so
<tbf> guess that question is too technical for #ubuntu, therefore I ask here: how do I permanently disable some binfmt without deleting it?
<tepsipakki> tbf: update-binfmts?
<tepsipakki> +man
<tbf> tepsipakki: update-binfmts doesn't remember the settings on next startup
<tbf> tepsipakki: and the manpage doesn't mention any configuration files
<tepsipakki> ok
<cjwatson> tbf: "without deleting it"> you mean without deleting the file in /usr/share/binfmts?
<tbf> cjwatson: more likely without removing it from the list "update-binfmts --display" generates
<tbf> cjwatson: see, I cross-compile quite some stuff for win32 and there the cli-detector and wine cause problems
<cjwatson> so you want it always to be disabled on startup, but to be able to selectively enable it if you want?
<tbf> on the other hand I want to be able to reenable the detectors with some simple "update-binfmts --enable"
<tbf> cjwatson: yup, maybe adding some lines to rc.local is the best solution for now
<cjwatson> tbf: OK - I think your best bet is to edit /etc/init.d/binfmt-support
<cjwatson> and either --enable selectively, or --disable certain things after --enable
<tbf> yup.
<cjwatson> tbf: could you file a bug about that? I should think about whether I can add a better facility for dealing with that sort of thing
<tbf> cjwatson: ok, I do
<cjwatson> thanks
<dholbach> Mithrandir: can you reject the human-gtk-theme upload next time you look?
<hile> I think just adding /etc/default/binfmt-support with ENABLE="" and DISABLE="" variables, empty by default
<dholbach> Mithrandir: i'll merge human-gtk-theme and human-theme - the split never made sense (but that's post-herd material)
<hile> then, if you set something to DISABLE (space separated list), those are disables after --enable
<hile> and if you set ENABLE="" to a value, only those formats are enabled and DISABLE is not used
<hile> quite trivial to implement
<hile> of course, as usual, this file only affects init script
<cjwatson> hile: I think it needs to be more fine-grained than that, so you can ask for only certain binfmts to be disabled on startup
<pitti> Mithrandir: I upload a new nss-mdns to fix bug 87207; diff is relatively easy (http://pastebin.ca/374407), but feel free to ignore for h5; I just don't want to forget about it
<Ubugtu> Malone bug 87207 in nss-mdns "libnss-mdns libraries should be /lib" [Medium,In progress]  https://launchpad.net/bugs/87207
<cjwatson> hile: oh, sorry, didn't read far enough
<cjwatson> hile: something like that could work, yes
<cjwatson> I want to think about it a little though, to make sure it fits in with the design of the rest of binfmt-support
<hile> of course
<pitti> asac: ping
<asac> pitti: pong
<tbf> hile: could work
<tbf> hile: as update-binfmt enables by default only the DISABLE variable might be needed.
<pitti> asac: got my /msg?
<hile> yep
<asac> pitti: yep :)
<ogra> Mithrandir, one edubuntu-meta upload waiting for approval ...
<bluefoxicy> Does something in ubuntu-desktop depend on slocate to function?
<bluefoxicy> I keep trying to remove it because I don't want slocate (I never use locate; and one day I noticed my computer was all laggy, updatedb had been running for 5 hours so I disabled locate), and now it fails to update because the post-install scripts return errors
<bluefoxicy> there we go, removed and reinstalled slocate
<bluefoxicy> I've just been curious why that has always been required though... it's not mentioned by the SUS as required in a standard Unix environment either (http://www.unix.org/version3/apis/cu.html)
<seb128> doko: ok, the python packages are broken for most of the GNOME updates we did
<seb128> I've copied your modified .m4 and ran aclocal and autoconf, the configure is updated correctly, that doesn't fix the undefined symbol though
<seb128> and python-vte build breaks with cc: @PYTHON_LIBS@: No such file or directory
<seb128> I've upload a gnome-python fixing the Depends on python2.4
<seb128> I applied to .m4 changes and aclocal, autoconf run, if you could have a look that would be nice
<doko> seb128: so I'll look at vte, and gnome-python. anything else?
<seb128> doko: if you can look at those that would be nice, I will adapt fixes for the others if you figure what is wrong
<seb128> doko: should I scp them somewhere? I've uploaded gnome-python with some changes but it's blocked by the freeze
<doko> seb128: would be nice
<seb128> doko: http://people.ubuntu.com/~seb128/gnome-python/
<seb128> doko: that version drops the Depends on python2.4, it still does that though:
<seb128> "ImportError: /var/lib/python-support/python2.5/gtk-2.0/gnome/_gnome_d.so: undefined symbol: Py_InitModule4"
<dholbach> seb128: which dir are you in, wenn you call    python-dbg -c "import ..."    ?
<seb128> doko: for vte you can start for the archive version, I've just copied acinclude.m4 from your package with aclocal and autoconf
<seb128> dholbach: ~ or ~/Desktop
<dholbach> seb128: ok, hm
<seb128> $ python-dbg -c 'import vte'
<seb128> Traceback (most recent call last):
<seb128>   File "<string>", line 1, in <module>
<seb128> RuntimeError: could not find _PyGObject_API object
<seb128> 
<seb128> also
<seb128> dholbach: does that one work for you?
<doko> seb128: do you test from the package dir? if yes, try to change the dir
<seb128> doko: no, I test from ~/Desktop
<doko> hmm
<seb128> and I've nothing special on my desktop
<seb128> only some downloads and directories
<dholbach> seb128: no
<seb128> ok :/
<seb128> dholbach: vte is probably broken because the updated dropped the acinclude.m4 change and the configure update
<seb128> dholbach: when I try to apply them again the builds break with "cc: @PYTHON_LIBS@: No such file or directory"
<jdong> lol I see pitti wants to join the desktop-effects club
<jdong> </sarcasm>
<dholbach> seb128: oh damn, i must have missed the change then :-(
<seb128> he's not around to read that :p
<seb128> dholbach: that was a change made out of the debian dir
<dholbach> oh, hm
<dholbach> i'll finish something up here, then take a look at it
<seb128> dholbach: thank you
<doko> seb128: hmm, I get in a chroot:
<doko> ImportError: could not import gtk
<doko> make[3] : *** [check-local]  Error 1
<doko> strange
<seb128> doko: weird
<doko> seb128: in the acinclude.m4, PYTHON_EMBED_LIBS is always set to link with the shared library; I'm wondering why that change was made
<doko> setting it to the empty string should allow you to link without -lpython
<pmitros> Page up. http://www-swiss.ai.mit.edu/~pmitros/ubuntu-first-run.txt
<seb128> doko: for what package? python-vte?
<doko> seb128: gnome-python
<sabdfl> thanks pmitros
<seb128> doko: I've fixed the Depends on python2.4 problem, that's the python-dbg import which is still broken, no?
<doko> seb128: yes, trying to build in a newer chroot now
<jwendell> seb128, bugs are closed (tagged as fix released) in LP automatically now? from their changelogs?
<imbrandon> moins all
<seb128> jwendell: no, I just copy the changelog when closing a bug, why?
<jwendell> seb128, just curiosity, because bug 43050
<Ubugtu> Malone bug 43050 in vino "vino-server crashes after connect if resolution has been changed via xrandr" [Medium,Fix released]  https://launchpad.net/bugs/43050
<seb128> ah ok
<seb128> usually I close it with the comment
<seb128> but you closed it first :p
<finalbeta> What does this spec do then? Should be closing bugs from the change log  : https://blueprints.launchpad.net/ubuntu/+spec/changelog-closes-bugs
<ogra> if a spec exists, that doesnt mean its implemented
<jwendell> seb128, another curiosity: in that upload, you dropped patch 70_relibtoolize.patch:  "dropped, the new tarball has been made with the Debian libtool". what did this patch do?
<finalbeta> ogra: my mistake, I was thinking implemented means that it's implemented.
<seb128> jwendell: reduce inflated depends due to libtool
<ogra> oh, right, its set to implemented, hmm
<seb128> ogra: the Ubuntu parts is implemented
<imbrandon> probably a mistake ogra 
<seb128> ogra: needs launchpad work now
<imbrandon> ahh
* imbrandon hushes
<ogra> aha
<imbrandon> what needed to be implmented in ubuntu ( other than just a set way to type it in the changelog ? heh )
<thom> imbrandon: changes to dpkg, one imagines
<thom> dpkg-parsechangelog or whatever the hell it's called
<imbrandon> ahh right, yea
<cjwatson> pmitros: if you're stuck for other methods, I'm happy to get an e-mail with a brief summary of installation problems (cjwatson@ubuntu.com). Can't promise to help with stuff outside the installer itself though
<pmitros> cjwatson: I've been filing bug reports right now. They seem a bit frivilous, though. 
<pmitros> cjwatson: I'll e-mail it to you, and you can decide what to do. 
<pmitros> cjwatson: Thanks. 
<tenco> what's the purpose of "/bin/dd bs 1 if /proc/kmsg of /var/run/klogd/kmsg"?
<thom> tenco: preventing klogd running as root
<cjwatson> replacing = with spaces makes your question a lot less clear, BTW
<cjwatson> (it's bs=1 if=/proc/kmsg etc.)
<thom> cjwatson: dd loses its ='s in ps
<cjwatson> ah
<seb128> doko: vte depends on python2.4 seems to be an upstream bug, there is a new tarball with "- Do not link to libpython in the python bindings"
<tenco> thom: thanks. just wondered. this process does heavy disk i/o for over 15 min on my system
<thom> cjwatson: (i have no idea why, though)
<cjwatson> tenco: check /var/log/kern.log to see if your kernel is spewing vast numbers of error messages
<tenco> cjwatson: no. maybe it's another process, but i couldnt spot any in ps output which could cause this. it's a bit annoying, that's all (at least for desktop systems...)
<doko> seb128: gnome-python: dpatch  deapply-all  
<doko> reverting patch 01_dont_build_with_lpython from ./ ... failed.
<doko> make: *** [unpatch]  Error 1
<seb128> clean target bugged?
<doko> yes, thats the clean target
<doko> seb128: http://people.ubuntu.com/~doko/gnome-python.diff
<seb128> doko: does that fix the dbg package as well?
<doko> yes
<seb128> good
<seb128> I'm wondering why it worked before
<seb128> I didn't drop any change to debian/rules
<seb128> doko: thanks ;)
<doko> and we should link the gnome-vfs thing with -lpython. the other fix avoids generating the dependency on python2.4
<seb128> ok
<seb128> the 01_dont_build_with_lpython patch can be dropped then, right?
<khermans__> is there a doc for upstart?  i am trying to investigate how Ubuntu Server can boot up so quickly
<cypher1> khermans__, i remember a blog by keybuk
<khermans__> cypher1, i found it thx
<cypher1> are there any C++ projects actively being developed by ubuntu itself ?
<cjwatson> I can't think of any, assuming you mean "by Canonical's Ubuntu team itself"; it's pretty hard to say what breadth of stuff is being done across the whole Ubuntu community
<cjwatson> oh, there may be some things in Kubuntu
<cjwatson> it would make more sense there
<cypher1> cjwatson, something like bugsquad tools
<cjwatson> doing that in C++ would be pretty odd
<cjwatson> all the bugsquad software is in Python as far as I know
<cypher1> cjwatson, no what i had meant was like that some other project
<cypher1> cjwatson, i was going thru the teams registered in launchpad.. 848 teams !
<cypher1> cjwatson, pretty difficult to find a project one like to contribute :(
<cjwatson> Mithrandir: we're switching to 2.6.20-9 for Herd 5, aren't we?
<Mithrandir> cjwatson: we are
<cjwatson> Mithrandir: debian-installer upload coming up then
<Mithrandir> cjwatson: great, thanks.
<ogra> Mithrandir, did you get my ping about the -meta upload ? i see no accepted mail 
<Mithrandir> ogra: yes, but I've been at my father's place for dinner so I haven't caught up with everything yet.  I'll tend to it in a minute.
<cypher1> cjwatson, one question regarding usplash, i am curious to know whether "No Usplash Timeout" spec code has been checked into feisty
<ogra> oki, didnt want to be pushy ...
<cjwatson> cypher1: no; you can tell from "Implementation: Deferred" on https://blueprints.launchpad.net/ubuntu/+spec/no-usplash-timeout
<cypher1> cjwatson, ok just understood that
<cypher1> cjwatson, thanks !
<cjwatson> no-usplash-timeout is an utterly trivial spec though - it really mostly exists to depend on the fsck progress fix that's necessary first
<cjwatson> removing the timeout without adding fsck/usplash progress interaction would be harmful
<cypher1> cjwatson, yes
<cliebow> fabbione:ping 
<fabbione> cliebow: pong?
<cliebow> im experimenting with sun server..have kernel and initrd loaded but know what it wants for a 
<cliebow> enter filename [install] 
<cliebow> install seems not found
<cliebow> ogra thought you might be able to help
<ogra> you should point out that its sparc sun :)
<fabbione> cliebow: i have no idea what you are doing.. 
<cliebow> heh..
<fabbione> first.. what release are you trying to install
<fabbione> and how
<fabbione> and on what machine
<cliebow> i have sun server 450e trying to put ubuntu on
<cliebow> and edgy sparc release
<cliebow> 6.10
<cliebow> 450r
<cjwatson> Mithrandir: d-i in the queue, seed changes all committed
<cliebow> my apologies..i am on low end of learning curve with this
<fabbione> cliebow: how are you trying to install?
<cliebow> cd
<fabbione> and btw.. best if you use dapper
<cliebow> ok..
<cliebow> ill give that whirl with dapper then
<fabbione> well i still would like to understand where you see that message
<cliebow> appreciate your input
<fabbione> i don't recall anything asking me for a filename
<ogra> sounds like a openfirmware prompt 
<fabbione> no it's not
<cliebow> yeah it does doesnt it
<cliebow> i see "losading kernel2.6.17
<fabbione> -ENOPARSE
<cliebow> loading initial ramdisk
<cliebow> Illegal instruction
<fabbione> ahhh
<fabbione> ok
<cliebow> {0}ok
<fabbione> known problem
<fabbione> with plenty of bugs 
<cliebow> To you maybe 8!)
<cliebow> so try dapper?
<fabbione> it might not solve it.. not even feisty
<cliebow> i see..it is not like i paid anything for it..but hate to see 2 gig of ram go to the dug hole
<cliebow> and quad processor
<fabbione> cliebow: i have heard tons of stories on how to fix that error
<fabbione> we still don't know what's the real cause of it
<fabbione> suggestions:
<fabbione> - update OBP
<fabbione> - poweroff and keep the machine off for 1 minute and power on again
<fabbione> - try netbooting
<fabbione> - install solaris -> update the world -> install linux
<cliebow> i will try two of three 8~)
<fabbione> - oh.. try to remove a gig of ram for the fun
<fabbione> you may never know
<fabbione> seriously.. this is the most annoying bug EVAR
<cliebow> thanks for the suggestions
<fabbione> no problem
<fabbione> sorry i can't help more than this
<cliebow> very good..!!i owe you a heineken..
<cliebow> or two
<fabbione> brrrrrrr....
<fabbione> heineken?
<fabbione> that's like milk for breakfast :P
<cliebow> i hope that is a good thing..i believe we sat at the bar for a little in Monreal last
<cliebow> ubz
<fabbione> probably
<cliebow> ill get out of your hair...Happy Day!
<fabbione> thanks.. cya
<cliebow> cya!
<khermans__> cliebow, dapper worked for me on my sunblade 150 where edgy failed
<cliebow> Thanks:ill go after that then!
<cliebow> Back to ltsp...
<Mithrandir> Keybuk: +mount -t tmpfs -o size=mode=0755 udev /dev
<Mithrandir> Keybuk: isn't there a comma missing there, or size= should go away?
<Keybuk> oops
<Keybuk> serves me right for re-editing after testing, instead of copying the tested version
<Keybuk> can you reject that
<Mithrandir> yes, I'll do that.
<Mithrandir> (done)
<Keybuk> thanks
<khermans__> anyone know if or can tell me how to see if Garziks Native Command Queuing (NCQ) for SATA was backported from his patch on 2.6.18 into the 2.6.17 Edgy kernel?
<mjg59> We didn't
<khermans__> mjg59, how would i find details of things like this in the future?
<mjg59> khermans__: Check the kernel changelog?
<khermans__> mjg59, there is a specific ubuntu kernel changelog somehwre?
<mjg59> /usr/share/docs/linux-image-foo/changelog.Debian
<ogra> Mithrandir, do the iso cronscripts run tonight, or are you on manual already ? 
<Mithrandir> ogra: they run tonight.  Or rather, tomorrow morning.
<ogra> ok, thanks ...
<ogra> i just want to make sure i see what the seed changes affect in tomorrows build
<ogra> so i have enough time to revert stuff if anything breaks
<Mithrandir> ogra: does dia follow gnome release schedule, etc?  (And should be regarded as part of the gnome RC release?)
<ogra> Mithrandir, yes
<ogra> at least according to seb128's ping frequency ... if new releases are out ... 
<ogra> :P
<zul> *grumble*
<zul> sorry..
<sbalneav> I would like to suggest that *buntu come configured with mozex by default, with the text editor set up for vim, so that editing wiki pages can be done sanely from within vi, as opposed to a textbox in the browser.
<sbalneav> Thank you for your attention :)
<ogra> sbalneav, asac is the right address for such prayers
<sbalneav> heh, I was just joking
<sbalneav> Like anyone other than insane people like me want to edit wiki pages in vi :)
<sbalneav> Oh! Crumb!  This isnt #edubuntu!
<ogra> hehe
<ogra> many people would agree about mozex though i guess :)
<seb128> Mithrandir: no, they don't, we have a 0.96pre version though and 0.96 is planned for soon
<ogra> seb128, but we agreed that it is in the general exception in hoary or breezy i think ...
<seb128> ogra: dunno about that, they don't roll new tarballs every 2 weeks, etc though so they don't follow GNOME cycle
<spacey> is /var/run a special device? During startup its complaining its expecting /var/run to be a special device. As far as i can see it is just a normal directory? (happened after a little var moving)
<spacey> i know it would mount a tmpfs on /var/run but i don't see why it can't now
<mjg59> crimsun: Hm. 2.6.20-9 still doesn't give me sound loving on an MBP.
<mjg59> crimsun: Headphones work fine
<Riddell> mvo_: I fixed a bug in dist-upgrade tool in update-manager bzr, could you upload a new version to whereever it goes?
<mvo_> Riddell: it should be available via a normal update-maanger upload now, fancy to test this? alternatively I can do it via the "old" mechanism
<Riddell> mvo_: sure, I can try that
<mvo_> Riddell: pleae do, thanks!
<Riddell> mvo_: current version in ubuntu is 0.57.2, in bzr is 1:0.57.6
<Riddell> why the epoch?  and why the missing versions?
<mvo> Riddell: because the old raw-dist-upgrader had versions like 20061102.1
<Riddell> mvo: ok
<mvo> Riddell: and the missing versions are because of a bunch of problems with the uploads (rejections, ftbfs because of python-apt breakage)
<mvo> Riddell: rejection because of version nubmer to low for example
<seb128> Mithrandir: don't accept gnome-python 2.17.92-0ubuntu3 if you didn't do it yet
<sebest> seb128: ping
<seb128> sebest: pong
<sebest> hello, do you remember about the modifications with default samba config to allow nautilus-share to work out of box?
<sebest> enabling net usershare
<seb128> yeah
<seb128> I need to talk to infinity about it
<sebest> i posted on the mailing list, but there was no answer
<seb128> I know
<seb128> it's on the list of things we need to fix
<seb128> might be for feisty+1 though, feisty is feature frozen atm and the changes are non trivial
<seb128> changing samba might be ok, nautilus-share still had to be promoted, add an user, etc
<sebest> add a user?
<seb128> for the shared directory
<seb128> or a group
<seb128> no?
<sebest> yes a group
<sebest> but this must be in the samba package
<seb128> and the location of that directory needs to be discussed, etc
<seb128> right
<seb128> that's why it might be for feisty+1
<sebest> i understand
<seb128> there is also the duplication with shares-admin
<seb128> nautilus-share is better for smb
<seb128> shares-admin do NFS though
<seb128> not sure how much users benefit from that
<sebest> yes, nfs sharing...
<sebest> mostly a server feature imo
<gilligan_> i hope this doesn't fall  under support leading to me being flamed for asking...  :) BUT: I am testing feisty herd4 right now, and grub installation fails because the installation uses RAID and grub won't know where to install without first registering the device properly (device (hd0) /dev/maper/blabla..)  -- ANYWAY: What other steps follow the grub installation that I should perhaps manually invoke now so that I can actually te
<gilligan_> st and run the installation at all ?
<gilligan_> oops ..that got kinda long :)
<mooey> gilligan_, you might want to try #ubuntu+1 if you have not already
<seb128> doko: your patch breaks the non-debug gnome-python modules
<gilligan_> mooey, oh okay -- well I had a look at #ubuntu and quite honestly the "bullshit traffic" in there is so high it is hard to take 
<mooey> ubuntu+1 is a little quieter
<Hobbsee> gilligan_: i know i've just come in, but that still doesnt make this a support channel.
<gilligan_> Hobbsee, yes that is very true. I'm sorry.. I thought given that i am actually installing feisty for the sake of testing i would be forgiven.. :] 
<gilligan_> Hobbsee, but that's beside the point.sorry again, I gonna shut up now :)
<Hobbsee> gilligan_: like i say, i didnt see the backscroll
<Hobbsee> gilligan_: also, depends if anyone here is awake/responding or not
<gilligan_> Hobbsee, oh ooops, you just joined..right
<Hobbsee> gilligan_: right - i'd check if there are bugs on raid that mention feisty
<Hobbsee> gilligan_: otherwise, i'd ask cjwatson if he knows about the problems with raid in the installer, after you've filed a bug (bugs make great todo lists, not irc queries :) )
<gilligan_> hehe
#ubuntu-devel 2007-02-28
<gilligan_> Hobbsee, actually i am not even sure if this scenario is supposed to be supported.. will dmraid be included in feisty final?
<Hobbsee> no idea
<Hobbsee> hence the bugtracker might
* Hobbsee doesnt deal in the installer
<gilligan_> right,ok
<Hobbsee> if it's not now, it's either a feature that isnt going to be done in time, most likely (as we're past feature freeze), or it's a bug, ie, it's supposed to work, but is broken.
<gilligan_> okay well then i am pretty sure that it's not going to be in there.. had to install dmraid manually
<gilligan_> and consequently grub doesn't get the right instructions to set up the device
<gilligan_> well maybe it'll work with my manual tweaking
<gilligan_> off to #ubuntu+1
<gilligan_> thanks again (and sorry..)
<ogra> dmraid was never in main
<ogra> hmm ... to late
* Hobbsee tells her in #ubuntu+1
<doko> seb128: vfb-run /usr/bin/make -C build-2.4 check
<doko> xvfb-run: error: xauth command not found
<doko> make: *** [build-2.4/build-stamp]  Error 3
<doko> I didn't touch the check target
<seb128> doko: that's an xorg-server bug, fix waiting for moderator ...
<seb128> Mithrandir is not around apparently
<seb128> doko: xvfb lacks a Depends on xauth
<doko> yes, seen as well
<seb128> cjwatson: could you reject the gnome-python upload waiting for freeze approval?
<seb128> and maybe accept the xorg-server one (add Depends xvfb which have been dropped)
<cjwatson> you should be able to do the reject at least ...
<seb128> hum
<cjwatson> but I've done it
<cjwatson> q -Q unapproved reject gnome-python
<seb128> I've not even though to do freeze work
<doko> seb128: why reject, rebuild should be ok?
<seb128> ok, thanks
<cjwatson> it's not really freeze work as such - rejects are safe
<seb128> doko: 0ubuntu3 has your patch and it breaks the non debug version
<seb128> cjwatson: right, I will do that myself next time ;)
<seb128> thank you
<cjwatson> seb128: accepted xorg-server, looks fine
<seb128> thank you
<seb128> doko: 
<seb128> $ python -c "import gconf"
<seb128> Traceback (most recent call last):
<seb128>   File "<string>", line 1, in <module>
<seb128> ImportError: /var/lib/python-support/python2.5/gtk-2.0/gconf.so: undefined symbol: _Py_RefTotal
<doko> frumble
<doko> grumble
<seb128> the patch looks fine though, I'm wondering why it's doing that
<doko> hmm, I see, dh_install is called twice with different sourcedirs; should add -N *-dbg, and -p *-NOTDBG as args. checking ...
<seb128> ah, right
<robertj> are gtk input methods being deprecated for uim?
<seb128> probably no need of -N
<seb128> just -p binary should be enough
<seb128> robertj: no idea
<robertj> im-hangul seems to have dissapeared, which is of no great consequence because it has a replacement in uim I believe, but im-classicalgreek is unmaintained and does not
<wasabi_> dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
<wasabi_> who invented that and how do I turn it off?
<Hobbsee> you cant.  
<wasabi_> bah.
<Hobbsee> it's discussed on hte ubuntu devel ML, about maintainer fields
<wasabi_> it's a bit flawed.
<Hobbsee> if you want to read the thread (and associated spec), you're welcome.
<wasabi_> I'm adding my personal local changes to an ubuntu deviated package... so my version is basically... 1ubuntu1wasabi1
<jdong> wasabi: change Maintainer: to an @ubuntu.com address
<jdong> and it'll be happy again.
<wasabi_> sure. make one up.
<jdong> yeah
<wasabi_> "bah"
<jdong> :)
<jdong> screwthispolicy@ubuntu.com
<jdong> there.
<jdong> use that.
<Hobbsee> wasabi_: that works.  ubuntu-motu@lists.ubuntu.com also works
<Hobbsee> which is what most are changing to
<wasabi_> Well, since it's a company internal package, I'd rather have MY address there. ;)
<sistpoty> wasn't there some upstream switch?
<wasabi_> -W should at least disable it.
<wasabi_> I have an overlay repository at the office.
<wasabi_> And I regularily fix minor things or tweak things and introduce new versions.
<wasabi_> Makes sense to have the contact address be me.
<jdong> wasabi: I totally agree with you :)
<wasabi_> This has almost motivated me to being vocal... almost.
<wasabi_> But not quite. =(
<mooey> shout it from the rooftop
<wasabi_> I should put together a system which automatically builds packages including specific CVS revision numbers from upstream...  So I can just jump to some web form someplace and type '123:124'
<idn> hi i was wondering if someone could help me point where im going wrong, im trying to set up anjuta to start hacking on my school project, im developing a gnome app. I need the dbus bindings so I include '#include <dbus/dbus.h>' but i get a warning saying there is no such file or directory. I have install the dbus-dev package so i cant seem to figure out what is wrong
<wasabi_> Not exactly an appropriate question for this channel.  (but you need to specify -I to gcc)
<mooey> idn, this isn't a support channel
<mooey> please consult the topic
<idn> ok
<mjg59> What happened to wine?
<mjg59> Oh. 64-bit. Doh.
<sabdfl> we dwunk it
<Gacoment> compile wine cvs
<kylem> sabdfl, lol.
<jdong> cjwatson: do you think ubuntu-archive can process backports this Friday or whenever the next archive-day is?
<jdong> it's been a while, once again
<cjwatson> wasabi_: I agree with you that there should be a way to turn it off
<cjwatson> jdong: mail whoever's archive day it is as a reminder, maybe
<jdong> cjwatson: how do I determine whose archive day it is?
<cjwatson> jdong: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-February/000250.html
<jdong> cjwatson: thanks
<xstasi> hi
<xstasi> http://rafb.net/p/kWm1jy82.html
<xstasi> running feisty fawn on powerpc, herd 4
<xstasi> happens with any file, both mplayer and mplayer-nogui
<xstasi> to who should i report this? you or mplayer?
<mjg59> crimsun: I've attached a patch that gets speakers working for me here
<bdmurray> Riddell: ping
<bddebian> Heya
<xstasi> any developer?
<thelsdj> aww, does migration assistant not import accounts from edgy? that seems kinda silly maybe feature just isn't complete :)
<Adri2000> xstasi: hmm
<Adri2000> xstasi: bug #85550
<Ubugtu> Malone bug 85550 in mplayer "mplayer fails to decode mp3 audio on ppc" [Undecided,Needs info]  https://launchpad.net/bugs/85550
<xstasi> oh
<xstasi> i was just filling in reportbug
* xstasi quits the text editor and closes reportbug
<xstasi> let's hope someone takes care about it
<xstasi> it's a serious bug
<Adri2000> xstasi: if you want to help, provide the informations requested in the existing bug report
<xstasi> mh, i'm right now compiling mplayer svn
<xstasi> i have the original ubuntu sources too, i can try recompiling them with debug symbols later
<xstasi> well i have a backtrace anyway
<evand> thelsdj: It should.  File a bug and attach /var/log/syslog if it doesn't.
<g0su> Hello, i have a little problem with tmpfs, i can put the umask options. Why? http://pastebin.gulic.org/266
<thelsdj> hm, evolution in the 'Office' menu on feisty doesn't appear to have an icon?
<thelsdj> ah i see bug
<g0su> in my feisty , my evolution have icon :S
<thelsdj> g0su: is it in both menus?
<thelsdj> internet and office?
<g0su> Aplications -> office -> evolution
<thelsdj> 'evolution mail' in internet vs 'evolution' in office
<thelsdj> hm mine doesn't have an icon, i installed flight 4 then updated
<g0su> yes, i have two evolutions
<g0su> evolution mail in internet and evolution in office
<thelsdj> the one in office doesn't have icon, not sure if i had one before update
<g0su> yes same hier, flight four
<thelsdj> weird
<thelsdj> where is the data for the menu?
<g0su> the data in my menu?
<thelsdj> i just mean where on disk is the data for the menu stored so i can see if bad path or something weird
<g0su> ich weiss nich, i dont know
<g0su> i understand but i am not know when gnome store the menu
<thelsdj> sure, thanks
<thelsdj> do both of your evolution icons look the same?
<g0su> evolution in office is the evolution icon
<g0su> but the icon of evolution mail is different
<LaserJock_>  /usr/share/applications/ is where most .desktops are
<g0su> one world with one letter
<thelsdj> so appears the .desktop file has Icon=evolution-2.10
<g0su> /home/user/.gconf/apps/evolution :s
<thelsdj> and looks like both evolution and evolution-common install their own .desktop files, that seems kinda silly
<g0su> but thelsdj evolution exec -> Exec=evolution-2.10 and evolution-mail -> Exec=evolution --component=mail
<thelsdj> actually there are 3, i mean theres the mail one, and then there is evolution.desktop and evolution-2.2.desktop and neither appears to have a valid icon, though only one is enabled in the menus i guess, but not sure why there are 2 (maybe for people with an old version installed, i don't know)
<thelsdj> https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/88439 was marked as resolved only a while ago, so maybe new package will fix eventually
<Ubugtu> Malone bug 88439 in evolution "[Feisty]  no evolution icon" [Low,Fix committed]  
<g0su> thelsdj, use alacarte
<g0su> you can see the 3 evolution :D
<thelsdj> yea thats where i first noticed there was a hidden one
<g0su> http://img177.imageshack.us/img177/9127/pantallazo1hc1.png
<thelsdj> so 2.9.92-0ubuntu1 was released earlier today, i wonder if this bug was introduced by that
<thelsdj> g0su: you update your feisty today?
<g0su> thelsdj, yesterday
<thelsdj> ok so you might not have the buggy version :)
<g0su> :D
<SEJeff> When was it decided that compiz would be installed by default?
<LaserJock> it isn't
<_ion> It is.
<jdong> it is
<LaserJock> or rather it *is* installed
<jdong> today.
<jdong> :)
<LaserJock> just not turned on
<jdong> LaserJock: I think that's what installed by default means.
* jdong ducks
<LaserJock> well ...
<LaserJock> installed by default usually implies used by default
<SEJeff> LaserJock: I realize that, but I read last weeks dev meeting and the note from sabfdl that beryl and compiz should both go in universe
<LaserJock> although not always ;-)
<SEJeff> This is confusing to watch compiz install from a dist-upgrade
<LaserJock> SEJeff: apparently Mark decided to have it promoted
<SEJeff> LaserJock: Very cool
<jdong> Mark is magical.
<LaserJock> I'm a bit suprised since it's not exactly Main material
<LaserJock> but the masses will be happy
<jdong> meh, Novell/Redhat at least somewhat believe it's enterprise-ready
<jdong> to some degree :)
<SEJeff> LaserJock: True, but that will likely give it much more testing (which can only be good in the end)
<jdong> but masses happy is good
<jdong> besides FC6 has been guinea pigging desktop-effects for us
<SEJeff> Right
<LaserJock> I don't look forward to the bugs/support problems
<jdong> the truth is people who want to enable desktop effects will go to all lengths to do it
<jdong> and many are willing to risk that stability for it
<LaserJock> but yeah, hopefully it'll get cleaned up quick
<jdong> look at all the guides around for Xgl and Beryl and such.
<SEJeff> jdong: and doing it in a somewhat supportable way is much better
<jdong> don't those make you CRINGE? :)
<jdong> "delete libxmesa.this and copy libxmesa.that into it"
<jdub> LaserJock: compiz is main material, just not for everyone :)
<LaserJock> uhhh ;-)
<jdong> you mean like emacs?
<jdong> lol
<jdong> well actually that's for no one.
<mpt> What Ubuntu needs is a decent text editor
<SEJeff> mpt: sudo apt-get install vim-full && sudo update-alternatives --config editor :P
<_ion> But... It already *has* ed.
<mpt> SEJeff, I said "decent"
* mpt flees
<_ion> It is the standard editor.
<LaserJock> I was going to say emacs, but didn't want to get shot
* jdong shoots LaserJock for even suggesting it
<SEJeff> emacs is a great operating system, it just needs a decent editor
<SEJeff> Like vim
<mpt> ok, I'll rephrase
<jdong> god emacs needs to C-x C-DIE a slow painful death
<LaserJock> I like it for editing, not so much the OS part
<mpt> Programmers currently using UltraEdit, EditPad, BBEdit, etc don't seem to have an equivalent editor they can use on Ubuntu
<SEJeff> emacs is actually a lot less code than vim too
<jdong> I like it for the fact that I can alias it to vim, not so much for the vim is not default on Athena part.
<jdong> mpt: GEdit :D
<SEJeff> mpt: And sadly, site is one of the best editors like that in the repos
<jdong> actually GEdit is interestingly useful
<SEJeff> s/site/scite/
<jdong> aren't I supposed to be doing some backport of scite.... hmm....
<mpt> jdong, I use gedit daily. It doesn't even have Find with grep.
<SEJeff> *cough* python plugin
<mpt> what?
<jdong> python
<jdong> gedit
<jdong> import re
<jdong> and friends
<jdong> voila
<SEJeff> mpt: Gedit is scriptable with python and really really easily
<jdong> gedit can be an OS too.
<jdong> but it doesn't hurt your pinkie
<SEJeff> Or make people hate you
<mpt> jdong, but see, if I have to learn python just to find regexps, I might as well just use emacs in the first place
<jdong> mpt: well python is actually something useful to leran.
<mpt> whereas with the other editors I mentioned, it's a checkbox in the Find window.
<mpt> It's also modal, which is another thing that annoys me about gedit
<mpt> e.g. if you've nearly finished typing the thing you want to search for, and then you realize "oh, this thing needs to be a regular expression", you'd have to exit out of it and start again in the python console
<SEJeff> mpt: Have you used the gedit CTRL K search? Doesn't sound like you have
<mpt> SEJeff, yes, I reported a bug about it yesterday
<SEJeff> mpt: ok, just checking
<mpt> but that's not quite relevant to this issue :-)
<mpt> well, actually, it is
<mpt> e.g. start typing a Ctrl+K search, and then realize "oh, this search needs to be case-sensitive", so you have to exit out of it and start again in the Find window...
<LaserJock> so all editors suck, emacs just sucks less?
* LaserJock runs
<mpt> Something like that :-)
<jdong> @lart LaserJock 
<jdong> :)
<mpt> for various values of "emacs"
<jdong> for extremely nonexistent values of emacs.
<LaserJock> mpt: amazingly I've found a similar thing with web browsers, email clients, and OSs
<SEJeff> We need a meta-package called emacs-ng that just depends on vim-full
<LaserJock> eww
<jdong> actually vim-full Replaces: emacs
<jdong> at least in my dreams
<jdong> lol if I submit a patch... never mind :P
<g0su> emacs vs vim? troll xD
<LaserJock> I love vim, but that's just wrong :-)
<mpt> LaserJock, how do you mean?
<LaserJock> web browsers suck, email clients suck, OSs suck
<LaserJock> some just suck a little less than the others
<SEJeff> So write your own
<mpt> This isn't really a matter of sucking, it's more a symptom of "lack of itch" on the part of the developers
<mpt> Same reason we don't have much kids' software
<LaserJock> SEJeff: now why would I do that?
<LaserJock> mpt: somewhat for sure
<SEJeff> Well if it sucks, maybe you could make it better
<mpt> or an Internet connection assistant
<LaserJock> SEJeff: extremely doubtful
<stub> Launchpad is going down in 26 minutes for a code update and data migration work. Estimated downtime is 3 hours.
<SEJeff> LaserJock: That was sarcasm, nvm my OT
<mpt> because the people who would be able to solve those problems are the people who do not have them.
<LaserJock> SEJeff: ;-)
<Hobbsee> stub: yay.  the one time where I *wasnt* about to do triaging work.  we're making progress here.
<LaserJock> mpt: I understand what you're saying for sure. I'm a scientist and I'd love to see better scientific software. But it's hard for scientists to do it becuase they are busy doing science
<supervillain> Why does NoDisplay=True doesn't work in Feisty?
<Hobbsee> supervillain: please see the topic
<Hobbsee> supervillain: after that, please think on not barging in and asking a question, and more importantly, about actually providing some context with your question - like, what app it's in.  also, checking the bugtracker adn reporting it, if it's not there, is useful.
<g0su> Hobbsee, when i see one error when i report it? i am new with ubuntu, sorry. I am reading the https://wiki.ubuntu.com/MOTU but is so lange and i need some time.
<mpt> hmm
<mpt> Someone tell me about package descriptions
<mpt> I see a lot of descriptions with lines that are blank except for "."
<mpt> What is that for?
<Hobbsee> g0su: that's fine.  you can always ask for help on how to search, etc
<Hobbsee> mpt: er, that's something to lart the maintainer over, if that's the only thing in the description.  "." is the way to get a new line.
<mpt> Hobbsee, why can't you just get a new line with \n?
<Hobbsee> mpt: dunno, actually...
<_ion> \n is a record separator
<_ion> ...for the lack of a better word
<_ion> in debian/control, that is.
<mpt> _ion, I see plenty of other "\n"s in the description though
<Hobbsee> oh yeah, as it says that the section below the space is unknown, or whatever.
<mpt> looks like it's hard-wrapped
<mpt> See, in Launchpad we have code that converts Ascii text to HTML
<mpt> so it inserts <br /> and <p> and so on
<_ion> Perhaps the software is pedantic and the descriptions contain a space after the dot, or something like that.
<mpt> so for example, the sqcwa description ends up as
<mpt> &nbsp;This program reads squid/access.log on the fly, analyses it and<br />
<mpt> &nbsp;searches inside all text/html objects for some &lt;meta&gt; tags, and<br />
<mpt> &nbsp;if found, tells squidclient to purge the page.<br />
<mpt> &nbsp;.<br />
<mpt> ... etc
<mpt> Not as nice as it could be
<mpt> so it looks like package descriptions are using some not-quite-plain-text format
<mpt> http://www.debian.org/doc/debian-policy/ch-binary.html doesn't describe the format
<mpt> hmm, I bet the MOTUs will know
<mpt> they spend all day packaging :-)
<Toadstool> mpt: because control files follow rfc822 afaik and in rfc822, an empty line separates headers and an optional body
* Hobbsee doesnt know :P
* Hobbsee isnt a very good MOTU
<mpt> "Blank lines, or lines consisting only of spaces and tabs, are not allowed within field values or between fields - that would mean a new paragraph."
<mpt> http://www.debian.org/doc/debian-policy/ch-controlfields.html
<mpt> aha!
<mpt> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description
<mpt> "[Lines]  containing a single space followed by a single full stop character ... are rendered as blank lines. This is the *only* way to get a blank line[34] ."
<mpt> "Completely empty lines will not be rendered as blank lines. Instead, they will cause the parser to think you're starting a whole new record in the control file, and will therefore likely abort with an error."
<mpt> fantascinating
<mpt> ok, so Launchpad needs a new formatter
<mpt> thanks Hobbsee, _ion, and Toadstool 
<Hobbsee> no problem
* Hobbsee knew there was a reason.  just couldnt remember exactly what it was
<g0su> For search who packet have one file in ubuntu?(i only know in gentoo: equery f file XD)
<g0su> becouse i am searching the dh_make
<g0su> and i have dpkg-dev
<g0su> lol dh-make i am searching with dh_make XD
<g0su> 7:00 and i dont sleep i think than this is the problem :P
<giftnudel> dpkg-query -S
<g0su> giftnudel, i wont one children with you :P
<g0su> thanks you a lot ;)
<g0su> giftnudel, but this is only if i have install the package but if i dont install the package, and for example i dont know than lspci is in pciutils, what is the command for search lspci y the repository?
<LaserJock> g0su: you probably want to use packages.ubuntu.com in that case
<Toadstool> or apt-file
<Hobbsee> apt-cache search is also good
<g0su> root@DarkTemplar:~# apt-file
<g0su> -su: apt-file: orden no encontrada
<g0su> root@DarkTemplar:~# apt-cache search lspci
<g0su> root@DarkTemplar:~# 
<g0su> oki doki i go to search the apt-file in  packages.ubuntu.com
<Toadstool> g0su: you have to install apt-file in order to use it but I guess packages.u.c is a better option for you
<dholbach> good morning
<_ion> Good evening.
<dholbach> hiya _ion
<_ion> What's up?
<dholbach> I'm slowly *waking* up :-)
<dholbach> How are you?
<_ion> I'm going to try to get unresting, make something to eat and then go sleeping. :-)
<dholbach> sounds good :)
<_ion> Well, i should try to eat more often than every 24 hours or so. :-)
<pitti> Good morning
<ajmitch> morning pitti 
<sabdfl> yikes! what happened to thunderbird branding / palette?
<sabdfl> oh, it's every application. seems we lost something in the ubuntu-theme upload
<dholbach> sabdfl: oh? can you post a screenshot? which version of human-theme do you have?
<sabdfl> dholbach: i'm up to date on feisty
<sabdfl> all the menus and dialogs look like windows98
<sabdfl> hmm... not all
<sabdfl> t-bird
<sabdfl> oo.o
<sabdfl> both affected
<pitti> I just dist-upgraded as well, and it looks fine so far; /me starts ooo
<sabdfl> calculater too
<sabdfl> pitti: try rebooting / logging out and in?
<pitti> sabdfl: yep, will do; brb
<dholbach> ooo looks nice for me too - i did a restart when i dist-upgraded today
<dholbach> the human-theme upload i did was 'packaging changes' and it should only affect the window decorations anyway
<pitti> hm, gnome-terminal is crashy-crashy now (hey dholbach)
<dholbach> pitti: can you get me a debug backtrace?
<pitti> dholbach: will do in a minute
<pitti> sabdfl: today's dist-upgrade removed human-gtk-theme and installed human-theme; maybe something went wrong with that?
<dholbach> pitti: I merged the two packages.
<dholbach> and they should only affect the metacity window decorations
<pitti> dholbach: oh, oops, ENOLAUNCHPAD
<dholbach> sabdfl: it'd be nice if you could post a screenshot - for the moment I'm clueless to what might have happened there
<pitti> arrrgh
<pitti> dholbach: http://people.ubuntu.com/~pitti/tmp/gnome-terminal.crash
<dholbach> pitti: gracias
<dholbach> pitti: it must be vte and there was a new release yesterday that seb128 wanted to take care of - i hope it'll resolve it
<pitti> dholbach: I already have yesterday's new release -- oh, you mean there's yet another one?
<dholbach> 0.15.5
<dholbach> 0.15.4 is in the archive afaik
<Mithrandir>        vte | 1:0.15.4-0ubuntu1 |        feisty | source
<Mithrandir> so yes.
<Mithrandir> (and I can't access the queue now, since LP is down)
<dholbach> ah no... 0.15.5 is not interesting
<dholbach> it has the patch i merged in manually
<dholbach> pitti: i'll forward it
* dholbach hugs pitti
* pitti hugs dholbach back, thanks
* pitti takes a note to do everything in screen today
<ajmitch> :)
* ajmitch dist-upgrades the laptop
<sabdfl> dholbach: https://chinstrap.canonical.com/~mark/human-theme-issue.png
<dholbach> sabdfl: and ooo looks just like that?
<sabdfl> yes
<sabdfl> need to catch a car now
<sabdfl> cheers
<dholbach> sabdfl: it can't be the human-theme upload - the window decorations are all correct. 
<dholbach> ok see ... you
<dholbach> pitti: gnome bug 412977
* pitti pokes Ubugtu
<pitti> dholbach: thanks
<pitti> Ubugtu: *shake* *shake* wake up, dude!
* dholbach hugs pitti
<ajmitch> pitti: I doubt it'll go with LP down :)
<ajmitch> poor pitti
<pitti> ajmitch: bugzilla.gnome.org != launchpad.net
<pitti> not yet, at least :-P
<ajmitch> pitti: I know, but still..
<jdub> anyone using bind on fisty? mine seems to be wedging every now and then, not answering anything (even rndc)
<jdub> rt_sigsuspend([] 
<jdub> ^ strace sitting there...
<pitti> Mithrandir: could you please update the powerpc live CD? it's a week old, and the jigdo doesn't work any more
<Mithrandir> pitti: this morning's one should have built fine, but I'll check.
<pitti> Mithrandir: thank you!
<jdub> hrm
<jdub> strace -f:
<jdub> [pid 25742]  <... gettimeofday resumed> {1172650424, 797245}, NULL) = 0
<jdub> [pid 25742]  gettimeofday({1172650424, 797645}, NULL) = 0
<jdub> [pid 25742]  futex(0x80a6f90, FUTEX_WAIT, 9, NULL
<jdub> 
<Mithrandir> cjwatson: what do you think of enabling the migration assistant by default now?
<jdub> hrm, hitting that every few seconds
<pitti> Mithrandir: hm, today's images seem to be out of date anyway, packages seem to be from < Feb 26
<Mithrandir> pitti: I'll go check on it now.
<pitti> no, wait, md5sum doesn't match
* pitti checks
<Mithrandir> pitti: ah, of course.
<Mithrandir> pitti: are you looking in /ports/daily or just /daily ?
<pitti> might entirely be my silly ISP not resolving /current correctly
<pitti> Mithrandir: /daily, for amd64
<Mithrandir> pitti: hmm, I thought you talked about the ppc ones?
<pitti> Mithrandir: that too, but there you are right, I need to swich my scripts to /ports; thanks
<pitti> Mithrandir: maybe the old ppc images could be removed from /daily-live/current to avoid confusion?
<Mithrandir> pitti: yes, doing so now.
* Mithrandir cleans up some edgy dvds too
<Mithrandir> (from -daily)
<g0su> a
<g0su> are you really friki? do you like linux? sure? -> http://www.pubfoto.com/albums/album35/le_mutande_di_linux.sized.jpg XDDDDD
<Mithrandir> cjwatson: cdimage/ports/daily/hoary; can I remove that? :-)
<Mithrandir> cjwatson: and the stuff in cdimage:custom/, can that go?
<jdub> elmo: you guys testing fisty on ubuntu infra yet?
<pitti> hey seb128 
<seb128> morning pitti
<pitti> dholbach: current amd64 live CD exposes this theme weirdness
<ajmitch> hi seb128 
<seb128> Hi ajmitch
<seb128> hum, update manager is b0rked
<ajmitch> python-apt issues?
<seb128> hey mvo
<pitti> seb128: summoning powers ;-P
<seb128> I was just saying that update manager is b0rked :p
<ajmitch> morning mvo :)
<seb128>   File "/usr/lib/python2.5/site-packages/UpdateManager/fakegconf.py", line 48, in save
<seb128>     file = open(CONFIG_FILE, "w")
<seb128> IOError: [Errno 13]  Permission denied: '/root/.update-manager-conf'
<mvo> hey seb128! 
<mvo> hey ajmitch
<mvo> seb128: heh :) fixed, but my uploads are lost in soyuz
* ajmitch hopes compiz works properly on the laptop now
<cjwatson> Mithrandir: have you tested the migration assistant much yet?
<seb128> mvo: are you sure they are just not blocked by freeze?
<seb128> mvo: .7 is to the unapproved queue
<seb128> mvo: like waiting for moderation
<cjwatson> Mithrandir: ports/daily/hoary can go, not custom (need to archive that)
<ajmitch> gah, upgrade broke, /boot full
<mvo> seb128: currently there is 0.57.2 in the archive. and I uploaded quite a few since then. 0.57.5 is build sucessfully and marked "published"
<pitti> ajmitch: what's that thing with /boot on an extra partition? what does that buy you?
<ajmitch> pitti: / is LVM
<pitti> ajmitch: ah, and you cannot boot from that?
<ajmitch> grub doesn't know about LVM
<ajmitch> grub2 may do, when we use that in the distant future :)
<pitti> ajmitch: I have / (including /boot) on md raid-1 on my server, and lilo boots it just fine
<seb128> mvo: hum, k
<Mithrandir> cjwatson: no, I haven't tested it, but I'd either want to defer it or make it default soonish.
<ajmitch> pitti: right, but that's lilo, I like keeping grub since xen is easier with it
<seb128> Mithrandir: could you accept the vte update and the new desktop-effects (the diff with the previous version is basically a drop of the code which refused to activate compiz on xinerama)
<cjwatson> Mithrandir: ok, I'll think about it this morning
<ajmitch> pitti: my mistake was just making /boot too small :)
<Mithrandir> seb128: yes, I can once LP is back.
<seb128> ah, didn't know that LP was out of order
<seb128> thanks ;)
<ajmitch> seb128: so compiz should work on dual-head nvidia now?
<Mithrandir> seb128: production update.
<pitti> seb128: scheduled downtime for feisty translations
<seb128> ah, they didn't do it in the middle of the night that time
<Mithrandir> it was supposed to be done half an hour ago
<cjwatson> 2:30am would have got in the way of west coast US folks (e.g. mdz ;-))
<cjwatson> so it was moved to 5:30am
<Mithrandir> staging is up, though.  If you need to look at things, etc.
<ajmitch> seb128: xserver is dying with not finding fixed font, you uploaded a fix for that?
* ajmitch saw it discussed here earlier, can't remember who though :)
<seb128> ajmitch: no
<seb128> /usr/share/X11/fonts is probably a directory on your box
<seb128> which broke the /usr/share/X11/fonts -> /usr/share/fonts/X11 creating
<seb128> creation
<seb128> we really need to workaround that
<seb128> dunno why some install have a directory there :/
<ajmitch> yeah it is a dir
<ajmitch> old fonts.{alias,dir} that weren't removed on package upgrades
<seb128> ogra: new gnome-power-manager to package
<tepsipakki> seb128: we can bring back that patch which fixes the font-issue.. I tested it yesterday
<seb128> tepsipakki: would be nice, do you have a debdiff handy? ;)
<tepsipakki> I can dig it
<seb128> tepsipakki: I did an upload to fix the xvfb Depends which have been dropped during the merge
* ajmitch will just symlink by hand for now :)
<tepsipakki> seb128: ok, it's not visible in -changes yet though
<seb128> tepsipakki: weird, it was yesterday evening for me
<tepsipakki> seb128: oh, I can download the new source
<tepsipakki> so it is in the archive
<seb128> tepsipakki: it has been accepted like 10 hours ago, not a surprise ;)
<tepsipakki> yesh
<zyga> hi I'm trying to install edgy server on a CF card and I'm having issues with GRUB - I'm tracking the problem down but I realized that we are using grub-0.97 aka grub 1 aka grub legacy that no longer accepts bug reports or patches, am I correcT?
<zyga> In other words, assuming that I manage to fix the problem my patch will probably be lost
<zyga> I don't like that to happen
<dholbach> ogra: new gnome-power-manager
<seb128> ogra: I told that like 10 minutes ago :p
<seb128> ups
<seb128> dholbach: I told that like 10 minutes ago :p
<dholbach> seb128: OKAY
<ogra> dholbach, seb128, did you see ? there is a new gnome-power-manager :P
<seb128> ogra: there is? cool! What about packaging it then :p
<pitti> oh, bazaar.lp.net is down too
<dholbach> ogra: ROCK
<ogra> heh
<ogra> let me finish my mail ... then i'll get to it ...
<Mithrandir> pitti: do you still have the amd64 live cd booted?
<pitti> Mithrandir: no, but I can do it quickly
<Mithrandir> pitti: please, and if you can check whether installing gtk2-themes-ubuntulooks fixes the problem, that'd be swell
<pitti> Mithrandir: sure, doing now
<pitti> dholbach, Mithrandir: ^ confirmed, that repairs it
<Mithrandir> thanks.
<Mithrandir> dholbach: can you upload a new -theme package that depends on g-t-u?
<dholbach> ARG
<dholbach> definitely!
<pitti> dholbach, Mithrandir: just to avoid errors in a hurry, it's s/themes/engines/
<Mithrandir> thanks.
<Mithrandir> oh, sorry, yes.
<pitti> hm, I just got another report about /usr/share/X11/fonts b0rkage; but I guess that's not h5 critical?
<Mithrandir> that's an upgrade problem, not an install problem, isn't it?
<pitti> yep
<Mithrandir> handle it later, then
<Mithrandir> IMO
* pitti agrees
<Ng> several people in #ubuntu+1 got bitten by the font path changing yesterday fwiw
<ogra> pitti, i have one hal bug where pressing the powerbutton generates two events, i think we should look into that before release
<pitti> Mithrandir: btw, did you see my dhcp3 freeze exception request from yesterday?
<pitti> ogra: ok
<Riddell> bdmurray: pong
* Starting logfile irclogs/ubuntu-devel.log
<seb128> hum
<seb128> for things like xserver-xorg-video-* where we sync on Debian and just add an additional Conflicts,Replaces on xserver-xorg-driver-package, do we need to change the Maintainer?
<seb128> or can we use a build1 version?
<pitti> seb128: if we change debian/control, this needs to be -ubuntu1 and Ubuntu maintainer AFAICS
<seb128> pitti: ok :/
<pitti> seb128: otherwise the change would disappear automatically on next autosync
<seb128> hum, that's a good point
<pitti> yay LP!
<cbx33> ooho LP is back?
<dholbach> Mithrandir: the new gthumb works nicely for me - but i'm happy with waiting after herd5 - as you like it.
<ajmitch> dholbach: you should be using f-spot instead :)
<Hobbsee> dholbach: did you get that message that YOU ROCK?
<dholbach> Hobbsee: yes, THANK YOU!
<ajmitch> heh
<dholbach> Hobbsee: you ROCK too :)
* pitti sings d-hol-d-dhol-bach rocks!
<dholbach> Hobbsee: what do I owe the pleasure? :)
<ajmitch> dholbach: just being you?
<Hobbsee> dholbach: :)  the bzr wiki howto
* Hobbsee doesnt rock
<dholbach> you're all flattering me :)
* Hobbsee does nothing
<dholbach> Hobbsee: oh? which one?
<Hobbsee> oh crap, i needed to put a new k-d-s upload thru.
<Hobbsee> dholbach: w.u.c/bzr
<dholbach> Hobbsee: i didn't work much on it
<dholbach> Hobbsee: troy_s started it and some #bzr folks improved it
<Hobbsee> it's attributed to you and one of the LP guys
<Hobbsee> ahhh
<dholbach> I chatted with troy about bzr before
<schwuk> Is gnome control center gone for good in Feisty?
<seb128> schwuk: no, it's still there, the menu item is just hidden
<schwuk> seb128: will it remain off by default?
<seb128> schwuk: menus will be default for feisty
<seb128> and we will reconsider shell next cycle
<dholbach> seb128: you should write a DesktopTeam/FAQ :)(
<seb128> it still has some bugs that would be nice to fix
<schwuk> bugger - now I have to re-re-write my chapter!
<seb128> dholbach: yeah ;)
<seb128> schwuk: sorry about that
<schwuk> seb128: It's not too bad - I just need to re-add the bits from the first edition
<schwuk> It's a pain in the **** writing a book about an unfinished product. :(
* finalbeta searches for the location of **** on wikipedia.
<Treenaks> schwuk: nose?
<schwuk> finalbeta: insert your own four letter word depending on how coarse you are! :)
<ogra> is it on purpose that we only have amd64 images ?
<schwuk> Treenaks: I was thinking jono actually :)
<Treenaks> schwuk: 'a pain in the jono'? hmm..
<schwuk> Treenaks: It's his fault...
<mvo> Riddell: it looks like adept is crashing with the latest apt on package removal *sigh*
<Riddell> mvo: erk
<Mithrandir> dholbach: cheers, sounds good.
<cjwatson> ogra: you know where the logs are
<cbx33> ogra: had some ltsp-build-client errors on edgy
<Mithrandir> ogra: the reason you don't have ppc images is I nuked them.
<dholbach> Mithrandir: i'll mark bug 86305 as fix committed then
<Ubugtu> Malone bug 86305 in gthumb "UVF exception: gthumb 2.9.3" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86305
<ogra> Mithrandir, i was more intrested in i386 :)
<Mithrandir> ogra: i386-schaithreeeightysix. :-)
<Mithrandir> cjwatson: the normal soyuz bug is the problem; could you do your workaround?
<Mithrandir> cjwatson: (d-i + tarfile = boom)
<ogra> cjwatson, err ... the last log in http://people.ubuntu.com/~cjwatson/cd-build-logs/edubuntu/feisty/ is from feb 16th
<cjwatson> Mithrandir: meh
<cjwatson> ogra: ah, this is the first I've heard of that. will investigate
<ogra> some mirroring issue i guess
<ogra> pitti, bug 81227 was the one i was talking about earlier ...
<Ubugtu> Malone bug 81227 in hal "Logout screen appears twice [Feisty] " [Medium,Confirmed]  https://launchpad.net/bugs/81227
<Mithrandir> dholbach: your changelog for human-theme is wrong (but the fix is correct).  You're adding g-e-u to Depends, not Build-Depends.
<cbx33> is it a known bug that sometimes pressing the power button straight shutsdown the machine and doesn't prompt what to do?
<cbx33> sorry may be the wrong place to ask
<dholbach> Mithrandir: sorry
<pitti> cbx33: happens to me on ppc
<cbx33> pitti: happens to me sometimes on i386
<cbx33> but i can't reproduce, random unfortunately :(
* cjwatson fixes the cdimage daily-checks script to crash less often
<segfault> Congratulations on completing your LPIC-3 "Core" certification.
<segfault> woohoo! :>
<cbx33> w00t segfault 
<cbx33> congrats
* cbx33 wants to do LPIC
<segfault> its nice
<cbx33> my problem is I'm a JOATMON
<cbx33> Jack Of All Trades, Master Of None :p
<segfault> hehe
<cbx33> i do a bit of everything
<cbx33> guess being a sysadmin doesn't help there
<segfault> sure it helps
<ogra> feisty-server-amd64.iso              28-Feb-2007 00:48  596M
<ogra> OMG what do i do with all that space ?
<cjwatson> ogra: build logs fixed; thanks. It was fallout from the old /srv/cdimage.no-name-yet.com compatibility symlink being removed.
<ogra> ah, k
<StevenK> Ah, no-name-yet.com is getting the boot?
<cbx33> ogra, well the build failed again
<cbx33> E: There are problems and -y was used without --force-yes
<cbx33> this is ticking me off now
<cjwatson> (fix the problems, don't add --force-yes ...)
<cbx33> cjwatson: good advice ;) - If I knew where the problem lay
<Mithrandir> meh, mdebdiff doesn't handle the case of something having changed components.
<Mithrandir> StevenK: well, not having it means less hassle when tab-completing.. :-)
<cjwatson> cbx33: is this a CD build log?
<cbx33> ogra is aunauthenticated instlalation of pacakges liable to cause it to fail here?
<cbx33> no.....I installed from CD and ltsp build failed there 
<cbx33> so i was trying a manual one, but it's failing here too
<ogra> can you do one that you log ? ands send me the log ? 
<ogra> *and
<cbx33> how do you want me to log
<cbx33> just capture the output of the build?
<seb128> Mithrandir: please accept the vte update (fix a crasher) and the xorg-server update (fix "fixed font not found" problem for people who had a /usr/share/X11/fonts directory before updating)
<ogra> yourcommand 2>&1 >/tmp/file.log
<ogra> something like that
<seb128> hum
<Mithrandir> ogra: that does not do what you think it does.
<seb128> Rejected:
<seb128> Unable to find vte_0.15.5.orig.tar.gz in the distribution.
<Mithrandir> blah > file 2>&1 is usually what you want.
<seb128> Mithrandir: if I've an 0ubuntu2 to upload I should use -sa for it?
<ogra> Mithrandir, wrong order ? 
<seb128> 0ubuntu1 has not been accepted
<ogra> right
<ogra> cbx33, ^^^^
<cbx33> http://pastebin.ca/375516
<Mithrandir> seb128: if there's no .orig.tar.gz in the archive, you should use -sa, yes.
<ogra> cbx33, a *full* log please
<cbx33> okie
<ogra> thats edgy you said ?
<cbx33> yes
<cbx33> just running it again with full logging
<ogra> and you cleaned up properly before i hope :)
<cbx33> just like you told me
<ogra> good
<cbx33> sudo rm /opt/ltsp/i386 -Rf
<pitti> holy sh**, my ddebs repository is 21 GB already; poor people.u.c...
<Mithrandir> seb128: with vte and xorg-server in, you have all the changes you want before herd 5 in?
<Mithrandir> cjwatson: you worked around the soyuz / d-i breakage?
<seb128> Mithrandir: no, but the other are not really blockers
<seb128> Mithrandir: I would like to have a gnome-panel inverting admin and system menus (the way they used to be ordered) and dropping the network applet (which dups with network-manager icon)
<seb128> s/inverting/switching
<Mithrandir> seb128: do you have the packages for this ready?  If so, I can sneak them in.
<seb128> Mithrandir: no, but that's just using again a patch we dropped and modifing a .schemas, that will be quick, doing that now
<Mithrandir> seb128: go ahead, then.
<poningru> halp
<poningru> what do you guys think should go in the herd5 'release notes'?
<poningru> added bunch of stuff like artwork etc.
<poningru> apport
<seb128> poningru: compiz on the CD?
<poningru> xorg 7.2
<poningru> ooh awesome
<poningru> vpn plugins
<poningru> for nm
<poningru> keep it coming btw
<Ng> oh awesome, I'd been building the openvpn one myself :)
<poningru> yeah soren hansen did those two
<poningru> atleast checked them in
<poningru> ...
<cbx33> ogra http://pastebin.ca/375546
<Ng> poningru: well my thanks to whoever it was ;)
<cbx33> is there a pipe to clipboard command?
<cbx33> cat something | clipboard
<Mithrandir> xclip?
<cbx33> thanks
<cbx33> ogra: it still failed with the same message
<cjwatson> Mithrandir: argh, sorry, not yet, doing now
<Mithrandir> seb128: should I hold the publisher waiting for you?
<seb128> Mithrandir: package is building on my box, shouldn't take long, please do
<Mithrandir> seb128: cheers; publisher on manual.
<Mithrandir> tell me when your packages are uploaded?
<cjwatson> Mithrandir: some amd64 oversizing in daily-checks mail
<Mithrandir> almost 10MB. :-(
<shawarma> Ng: No problem. :-) (re: the network-manager vpn plugins).
<Ng> shawarma: :)
<ogra> cbx33, hmm, strange i was expecting to see more errors above ... i wonder why it cant authenticate the packages ... i dont see that behavior here 
<cbx33> no....it is odd and bloody annoying
<cbx33> excuse my language
<ogra> any special optionsa you give to ltsp-build-client ?
<cbx33> none
<cbx33> jus ta straight run
<seb128> Mithrandir: gnome-panel uploaded, I didn't do the menu switch, it should rather be done to the gnome-menus layout and can wait after herd, the other changes might be useful for herd (fix gdm_socket location, which is used for people using the upstream session dialog mode) and dropped the wireless applet from the profile (dup with network-manager)
<cbx33> i really can't understand it
<cbx33> is there a way i can check gpgv
<Mithrandir> seb128: ok.
<cbx33> see if that's causing the issue?
<cjwatson> Mithrandir: so did you want that ubiquity migration-assistant change? I have it in bzr now
<cjwatson> will try to do a test run first
<Mithrandir> cjwatson: if you think it's reachable for feisty, I think it's about time it's turned on.
<Mithrandir> seb128: I'll accept the upload, but IMO you should reverse the test.  Right now, I can make gnome-panel unable to talk to gdm by doing "touch /tmp/.gdm_socket"
<seb128> Mithrandir: good point
<seb128> will fix that after the freeze
<cbx33> I tried running gpgv and it seemed to be ok
<cbx33> ogra even apt-get update fails to run gpgv properly
<ogra> on the server ?
<ogra> or in the chroot ? where did you test that
<cbx33> on the server
<ogra> Mithrandir, there is a new g-p-m waiting in the queue
<cbx33> Unknown error runn gpgv
<cbx33> s/runn/executing
<Mithrandir> ogra: *sigh*; you just missed the publisher with that.
<ogra> meh
<ogra> i didnt want to push it untested, else i'd have been ready 15min ago :(
<cbx33> ogra got it
<cbx33> damn it the clock had skewed....we should warn the user about this
<cjwatson> ltsp-build-client should just use the gpgv option that ignores timestamp skew
<cbx33> well it doesn't as yet :p
<cbx33> cos apt-get update worked when changing the time
<cjwatson> base-installer writes out an apt.conf.d fragment for the duration of the install that does that
<cbx33> so i hope this will fix it
<ogra> cbx33, does /usr/share/ltsp/plugins/ltsp-build-client/Ubuntu/020-apt-get-update exist ? 
<cbx33> lemme check
<cjwatson>         # Avoid clock skew causing gpg verification issues.
<cjwatson>         # This file will be left in place until the end of the install.
<cjwatson>         cat > /target/etc/apt/apt.conf.d/00IgnoreTimeConflict << EOT
<cjwatson> Acquire::gpgv::Options { "--ignore-time-conflict"; };
<cjwatson> EOT
<ogra> cjwatson, it uses --ignore-time-conflict since dapper
<ogra> (ltsp-build-client that is)
<cbx33> yeh it's in there
<cbx33> it exists
<cbx33> but that's probably why my install failed too
<cjwatson> ogra: if I were you I'd install an apt.conf.d fragment as above rather than just passing the argument to a single apt-get invocation
<ogra> oh, wait, i think i see the error
<cjwatson> ogra: we tried the latter approach in d-i and it was too annoying to track down all the apt-get invocations that might call gpgv
<ogra> cjwatson, i only have one 
<cjwatson> ogra: and besides the ltsp-build-client plugin that tries to do that is obviously broken
<cjwatson>         chroot $ROOT apt-get update
<cjwatson>         export APT_GET_OPTS="$APT_GET_OPTS -o Acquire::gpgv::Options::=--ignore-time-conflict"
<ogra> but for fuiture releases apt.conf.d might make sense
<cjwatson> I'm not sure what that's meant to achieve ... :-)
<ogra> cjwatson, yep, right, just discovered that
<ogra> it was in a different order once and the chrooted line had $APT_GET_OPTS in it
<ogra> smells like a merge oversight
<ogra> cbx33, change the order of the two lines and make the second one: chroot $ROOT apt-get $APT_GET_OPTS update
<ogra> then it should work
<cbx33> well i have changed the time now...i will try it later on
<ogra> i wonder why i never saw it on my ibook, where the clock is wrong on *all* installs 
<ogra> thats a bit strage 
<seb128> Mithrandir: I've uploaded a gnome-menus update to fix the menus order, if you come to do an another publisher run for whatever reason please accept it, otherwise it can wait for after herd
<jwendell> seb128, please help me, i have a doubt about debdiff
<Mithrandir> seb128: cheers.
<seb128> jwendell: debdiff old.dsc new.dsc
<seb128> jwendell: or debdiff old.deb new.deb
<jwendell> seb128, wow, i was typing my question and you answered! thanks!!!
<seb128> np
<Mithrandir> or debdiff old.changes new.changes.
<cbx33> ogra: if I have 2 nics setup in the machine, but don't want to use the dhcp server.....what do I have to do to set it up?
<cbx33> anything special?
<ogra> why do you use two nics then ? 
<ogra> just use one :)
<cbx33> ok....will try that
<ogra> and make sure your other dhcpd is configured properly indeed 
<cbx33> yeh i wrote the book on that :p
<cbx33> well not quite
<ogra> ;)
<jwendell> seb128, a bug in gnome-screensaver must be assigned to desktop-bugs, right?
<seb128> jwendell: no, ogra maintains that package
<seb128> don't assign it
<jwendell> ok
<seb128> he's subscribed to the bugs probably
<seb128> what is the bug number?
<jwendell> yep
<jwendell> seb128, just a minute
<cbx33> ogra: on edgy....i thought ldm screen said edubuntu
<cbx33> not ubuntu?
<jwendell> seb128, ogra, bug 84662
<Ubugtu> Malone bug 84662 in gnome-screensaver "Xnest: ghost mouse" [Medium,Confirmed]  https://launchpad.net/bugs/84662
<ogra> jwendell, already on my radar for post herd5
<jwendell> ogra, thanks
<jwendell> ogra, did you see the debdiff?
<ogra> yep
<heno> ogra: you're still using the gartoon icon set right? (re: winfoss styling)
<ogra> yep
<heno> cool
<jwendell> ogra, did i do something wrong?
<ogra> jwendell, looks fine to me
<jwendell> ogra, i'm just learning, to, someday, become a ubuntu-dev ;)
<seb128> jwendell: waouh, that's a gnome-screensaver bug
<seb128> jwendell: nice catch ;)
<jwendell> jwendell, it wasn't me, i just made the debdiff
<jwendell> seb128, but it's really interesting
<seb128> that bug is annoying me for some time
<seb128> nice to get it fixed
<ogra> yep
<ogra> a good strep forward towards ubuntu-dev ;)
<ogra> *step
<ogra> cbx33, suedo dpkg-reconfigure edubuntu-artwork
<ogra> *sudo indeed
<ogra> it will check the chroots and switch the themes
* Lathiat ponders vmjg59
<Lathiat> some people have far too much time on their hands
<fabbione> Mithrandir: impressive.. you made /. with herd 5 main freeze
<Mithrandir> must be a slow day.
<Mithrandir> I could understand a herd release showing up there, but those freezes are quite frequent.
<pitti> asac: argh, could firefox please stop telling me that I upgraded to 2.0.0.2? does this affect the stable updates as well?
<finalbeta> pitti: only told me once.
<asac> its just once
<pitti> it keeps telling me whenever I log in
<asac> on feisty?
<pitti> asac: yes
<asac> pitti:  in about:config ... what is set for key browser.startup.homepage_override.mstone ?
<pitti> asac: rv:1.8.1.2
<asac> i constantly switch back and force from and to different branches/minor version ... for it always pops up just for first time
<asac> sounds reasonable
<cjwatson> https://beta.launchpad.net/ubuntu/+source/partman-auto/+bug/87275
<Ubugtu> Malone bug 87275 in partman-auto "feisty fawn herd 4 server loops when partitioning disks attempted" [Undecided,Needs info]  
<cjwatson> Partitioning method:
<cjwatson> 0
<cjwatson> Guided - resize cdrom-retriever and use freed space
<cjwatson> *blink*
<cjwatson> how on earth did cdrom-retriever get there
<asac> pitti: can you reproduce by simply restarting firefox or just on each login (session auto start)?
<pitti> asac: hm, merely quitting/restarting DTRT; I'll investigate further and file a bug with some details
<asac> i think you forcefully shutodwn firefox when log out -> preferences are not persisted
<asac> and thus your browser.startup.homepage_override.mstone might still have been old?
<pitti> perhaps
<pitti> asac: ffox is started with the session for me, and I never bother to close it manually
<pitti> maybe it even works now, since I manually closed it once now
<asac> there is not much we could do about that ... maybe firefox should try to persist preferences if killed?
<asac> pitti: i would think so
<pitti> asac: I think it should just restore the previous homepage right after displaying the upgrade one the first time
<asac> homepage is not touched
<asac> its just that if milestone in pref is smaller then actual version, it will open the upgrade notice
<cbx33> ping ogra, I have some machines that won't tftp boot.  PXE-E32 TFTP open timeout
<asac> pitti: if you file a bug, please drop info what signal firefox receives if you just logout ... e.g. SIGTERM?
<pitti> asac: yep, will do if I can still reproduce it
<iwj> pitti: I thought I would do a few main inclusions if you're not busy with the queue right now.
<mvo_> Mithrandir: could you please accept update-manager 0.57.7? it fixes a couple of issues and earlier versions were blocked by soyuz (and I did not knew aobut this)
<asac> if its now gone ... set the mstone pref manually to 1.8.1.1 ... then use as you did before (e.g. never quit manually)
<pitti> iwj: that would be appreciated
<pitti> asac: ah, nice trick, yes
<Mithrandir> mvo_: it's not in the queue yet
<mvo_> Mithrandir: oh, sorry. it should be any minute
<cjwatson> Mithrandir: ubiquity 1.3.23 in the queue
<Mithrandir> cjwatson: ugh, ok.  I just (before I had to go out with the dog for a couple of minutes) started a publisher run for the new u-m.  Oh well.
<bddebian> Heya
<cjwatson> Mithrandir: sorry, should have mentioned earlier to hold off :-(
<Mithrandir> tepsipakki: hmm, is the new xserver-xorg-input-keyboard herd5 critical?
<seb128> Mithrandir: no
<Mithrandir> good
<seb128> Mithrandir: I keep uploading xorg updates but they are not for herd
<Mithrandir> seb128: that's fine; thanks.
<cliebow> fabbione:i got this monster solaris installing...pulled some memory did the trick
<seb128> np
<seb128> Mithrandir: if you still accept updates maybe consider the gnome-menus one? So we don't get a bunch of bugs complaining about the menus order ;)
<seb128> hi gismo
<gismo> hello seb128, hello all
<bddebian> Hello gismo
<Mithrandir> seb128: you're aware your gnome-python upload FTBFS?
<Mithrandir> seb128: http://librarian.launchpad.net/6563637/buildlog_ubuntu-feisty-amd64.gnome-python_2.17.92-0ubuntu2_FAILEDTOBUILD.txt.gz
<seb128> Mithrandir: need a retry with the xorg-server I've uploaded yesterday evening
<Mithrandir> seb128: ok.  I'll do that once the new xorg-server is done, then
<seb128> Mithrandir: xvfb 2:1.2.0-3ubuntu2
<seb128> Mithrandir: it should be done, cjwatson accepted it like 16 hours ago
<Mithrandir> oh, ok
<seb128> I did another update since ;)
<Mithrandir> given-back, then
<seb128> thanks
* pitti sends some juicy spec tests to fabbione 
<AlinuxOS> pitti, hello ;)
<pitti> hi AlinuxOS 
<AlinuxOS> pitti, how are you ?
<pitti> pretty good, and you?
<AlinuxOS> pitti, ok me too ;) Testing Feisty
<AlinuxOS> (translation related testings)
<AlinuxOS> pitti, here is Mozilla 2.0.2 with no locale package ...is it normal ?
<pitti> AlinuxOS: feisty doesn't have langpacks yet
<AlinuxOS> or maybe it's only english for a moment.
<AlinuxOS> ah
<AlinuxOS> ;)
<pitti> AlinuxOS: ah, no firefox 2.0 translations for Georgian available, sorry
<AlinuxOS> pitti, understood ;)
<pitti> (these have nothing to do with language-pack-XX)
<AlinuxOS> pitti, why so ?
<pitti> AlinuxOS: well, noone updated the Goergian translatios for 2.0
<AlinuxOS> https://launchpad.net/ubuntu/+source/mozilla-firefox-locale-all/+bug/73581
<Ubugtu> Malone bug 73581 in mozilla-firefox-locale-all "Providing Firefox 2.0 Georgian (ka) localisation." [Wishlist,Fix released]  
<AlinuxOS> pitti, http://www.mozilla.com/en-US/firefox/all.html  Georgian  is present.
<pitti> AlinuxOS: ah, maybe it was added for 2.0.0.2
<pitti> AlinuxOS: I didn't update it since 2.0.0.1
<AlinuxOS> I suppose final realise of Feisty will have 2.0.0.2 Firefox... ;)
<AlinuxOS> so you could use official translation ;)
<AlinuxOS> pitti, I remmember you had a your private langpack repository 
<AlinuxOS> is feisty supported ?
* iwj reads about WSDL.  This Java nonsense nightmare is giving me a headache.  Come back, Python; all is forgiven!
<pitti> AlinuxOS: no, Rosetta doesn't have Feisty translations yet
<pitti> iwj: *grin*
<docmur> hello all
<thom> iwj: should i even ask what you're doing with SOAP?
<pitti> thom: everyone needs to wash himself occasionally...
<AlinuxOS> pitti, are you going update mozilla 2.0.2 langpacks in the near future for feisty too ?
<thom> pitti: wash in acid, should they happen to go near WS-* or SOAP...
<pitti> AlinuxOS: yes, I will; you can file a bug to remind me
<AlinuxOS> pitti, on wich package ?
<AlinuxOS> pitti, ;)
<pitti> AlinuxOS: mozilla-firefox-locale-all
<AlinuxOS> pitti, ok ;) thank you...and have a nice day !
<mooey> is the system -> quit (logout) dialog part of gnome-session?
<seb128> mooey: yep, why?
<mooey> seb128, but 88015 - it freezes - need to direct the reporter to get a backtrace from the right process
<mooey> bug 88015 even *
<Ubugtu> Malone bug 88015 in linux-source-2.6.20 "shutdown window freezes everytime" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88015
<seb128> mooey: I closed the gnome-panel task and just commented on that one like one min ago
<mooey> weee, just noticed that
<mooey> too fast for me, heh :-)
<iwj> thom: the main inclusion queue has some Java things in it.
<thom> run! away!
<iwj> As you say.
<iwj> And I had a headache today before I started on this.
<docmur> hello all
<docmur> I'm trying to find a guide on how to set up a miniboot loader with a mini shell, thats it
<docmur> I'm starting a project in college to make my own OS
<docmur> I can find the guide I saw it like 3 years ago
<iwj> I think you're probably in the wrong place.  This channel is for people working on the development of Ubuntu.
<fabbione> cliebow: so removing the ram made the problem go away? even for linux?
<docmur> well I don't know where else to go I figured on of you might know 
<iwj> docmur: I'm sorry but we're all busy developing Ubuntu.
<superm1> ping BenC 
<pitti> heh, I /msg'ed that guy an URL, that URL seems to have kicked him out
<superm1> haha
<superm1> well i'll just shoot him an email if he doesnt come back in the near future
<BenC> superm1: pong
<superm1> heya BenC , i was wondering if upstream version freeze guidlines were as strict on things like drivers for the kernel.  ivtv 0.9.1 is with feisty, but 0.10.0 was released a few weeks ago and supposedly is a big redesign that is highly recommended
<BenC> superm1: a) File a bug report and I'll prioritize it, or b) (best solution), get a patch against our tree to update it to 0.10.0 source, test build it, and send the diff to kernel-team@lists.ubuntu.com
<cliebow> fabbione, yes i pulled two of four sticks and the prob went away..it appeared to load fine.but still boots to Solaris..so i must have picked wrong hd
<superm1> sigh. my only feisty box doesn't have any PCI slots to throw a tuner in, i'll do A for now, unless I can manage to upgrade my box with tuners to feisty this weekend
<superm1> okay
<fabbione> cliebow: just change the boot disk in the OBP
<jelmer_> siretart: hi
<cliebow> ok..ill sort that out then
<cliebow> thanks
<cliebow> 
<cliebow> so setenv boot-device ?
<cliebow> banner
<fabbione> cliebow: yes.. boot-dev
<fabbione> feisty will fix that for you...
<fabbione> but dapper and edgy can't
<mooey> should bug 87796 be refiled against evolution data server? the delay seems to occur when the clock is waiting for eds to fire up
<Ubugtu> Malone bug 87796 in gnome-panel "the calendar of the clock applet is slow" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87796
<seb128> mooey: not really
<mooey> alright
<seb128> mooey: it happens also on the first click I think
<seb128> I've evolution running, I just clicked on the applet and it took one second before opening
<seb128> and even if starting e-d-s is the problem then gnome-panel should maybe do it in an idle loop so it's ready before clicking 
<mooey> hm. i don't get a delay when i've started evo first
<seb128> it's a low priority bug though
<mooey> i can't set bug priorities :p
<seb128> maybe the delay is shorted and you don't notice it
<mooey> i'll confirm it and report it upstream
<mooey> if i dont start evo first the delay is noticible
<seb128> mooey: thank you
<seb128> look first if there is already a bug about it
<mooey> of course 
<jdong> evince takes a ridiculously long time to start in Feisty
<jdong> it happened like starting from last week
<jdong> ** (evince:12341): WARNING **: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
<jdong> ^^ what's it trying to contact?
<seb128> jdong: looks like a dbus problem on your side
<jdong> seb128: :( anyway to debug it more?
<jdong> no other apps seem to complain
<jdong> just evince
<seb128> pitti or slomo might know better
<jdong> it only happens once at the start of a session
<jdong> any subsequent evince runs normally
<AlinuxOS> Hello Devs, I can't see Georgian text files with emacs(or vim) in non X (=terminal mode) mode. Even then in Feisty "console-setup-1.13ubuntu6" has Georgian language support.(Georgian bitmap fonts are present).Cow can I solve this ?
<cliebow> fsabbione:  heh: i swapped the two drives..it starts to boot to    
<lems1|gone> AlinuxOS: did you try #ubuntu?
<cliebow> gentoolinux///mounting proc at /proc..mount command failed with error..proc already mounted
<AlinuxOS> lems1|gone, I'm talking about Feisty, and geo bmp font support is important for debian-installer. 
<lemsx1> jdong: sounds like a possible problem with /etc/hosts and the caching of resolved names... make sure that 127.0.0.1 is in your /etc/hosts ... that usually slows things down a lot (when it breaks). and if you are running a caching daemon like nscd, stop it
<lemsx1> AlinuxOS: at first that sounded like a support question ;-)
<AlinuxOS> lemsx1, sorry ;)
<carlos> mvo_: hi, could you confirm whether https://bugs.beta.launchpad.net/rosetta/+bug/84349 is a bug with your ddtp scripts?
<Ubugtu> Malone bug 84349 in dict-gcide "E: Problem with MergeList /var/lib/apt/lists/fr.archive.ubuntu.com_ubuntu_dists_feisty_main_i18n_Translation-fr" [Undecided,Confirmed]  
<AlinuxOS> lemsx1, I'm in contact with console-setup mantainer Anton Zinoviev, he included georgian16.bdf font in later console-setup version... but I can't see georgian letters in terminal mode.
<cjwatson> we included that patch ages ago
<cjwatson> AlinuxOS: you might find that running 'sudo setupcon' helps - there's a problem with fresh installs of feisty setting up a broken initramfs that doesn't quite get it right
<cjwatson> (running that from the console)
<cliebow>   r
<AlinuxOS> cjwatson, ah ok I'll check. Can you tell me which font size is used in a terminal mode by default ?
<AlinuxOS> console-setup supports for the moment only 16 an 14 sizes. (I'm working on remaning sizes).
<cjwatson> it depends, iirc
<cjwatson> check the config script
<AlinuxOS> iirc ?
<AlinuxOS> cjwatson, which config script ? (sorry I'm not a developer..I'm just translator...and little bit font designer) :)
<cjwatson> console-setup.config
<mvo_> carlos: let me check
<mvo_> carlos: that was a bug in the script, but it should be fixed since ~4 weeks or so
<AlinuxOS> cjwatson, I've found that http://lists.alioth.debian.org/pipermail/pkg-kbd-devel/2006-December/000474.html sadly there is no man page :/
<AlinuxOS> cjwatson, ah ok I've found some infos in a config file.
<cjwatson> I mean /var/lib/dpkg/info/console-setup.config
<hyakuhei> I just saw M.Shuttleworths talk at work. Its awesome, keep up the good work all :-)
<frenkel> hyakuhei: which talk? link?
<hyakuhei> frenkel: Dont have a link to it, It was the talk about where Linux in general is heading, visually it was just many slides with single points on them which he then discussed. Went over the things linux needs to do to be universally accepted
<dsas> "n big challenges" or something, he turned it into a blog series.
<hyakuhei> The only link I can find is : http://computing-colloquia.web.cern.ch/computing-colloquia/upcoming.html#ubu
<frenkel> ah ok
<hyakuhei> Was fun anyway :-)
<frenkel> thnx
<hyakuhei> Though at one point during some question answering his laptop cut in with some seriously psychedelic swirling colours - I'm pretty sure from that point on he just hypnotised us to think his talk was great whilst he went out for a coffee....
<mvo_> doko: is python-bittorrent waiting in NEW? 
<doko> mvo_: maybe, didn't look
<cliebow> fabbione: still around?
<fabbione> cliebow: very busy...
<fabbione> cliebow: please just write in /msg and i will answer later
<fabbione> cliebow: i need to feed my son now and i am not sure how long it will take
<doko> what do three blinking keyboard LEDs mean, if usplash fails to come up (on amd64)?
<zyga> doko: kernel panic?
<dholbach> Accessibility Team meeting in 3 minutes in #ubuntu-meeting.
<tkamppeter> pitti, Mithrandir: ping
<Mithrandir> tkamppeter: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
<tkamppeter> pitti, Mithrandir, it is about the activation of the SNMP backend of CUPS.
<tkamppeter> I have posted on the ubuntu-devel and ubuntu-devel-discuss lists about that.
<tkamppeter> On ubuntu-devel it seems that no one does the moderator task, I never got a message that my posting got accepted or rejected.
<tkamppeter> On ubuntu-devel-discuss I got no answer at all.
<pitti> tkamppeter: hm, no idea;
<tkamppeter> pitti, Mithrandir: My suggestion is to activate it and to see whether it causes complaints, there is still enough time to de-activate it again if it causes more problems than benefit. Small issues get probably fixed upstream quickly if we get bug reports.
<pitti> that WFM
<tkamppeter> pitti, WFM is "works for me"?
<pitti> it's innocent enough AFAICS, the worst that can happen is that it doesn't work att all
<pitti> and that's no worse than what we have now
<pitti> tkamppeter: yes; sorry
<tkamppeter> That's true if it has a bug and therefore does not detect the FooJet XYZ, the user is in the same situation as with snmp deactivated, but the user whose Paperwaster 1000 is detected will love Ubuntu.
<pitti> tkamppeter: the only thing I'd be concerned about is network packet flooding, but that doesn't seem worse with snmp than with cups browsing
<tkamppeter> Package flooding is no big problem as the snmp backend does not run permanently. It runs only 3-4 seconds once during running the add printer wizard of a printer setup tool.
<tkamppeter> And CUPS' broadcasting runs every 30 sec all the time.
<delire> i'm looking at putting Ubuntu onto a number of machines here at UNI. on trying out the Live/InstallCD on the Dell Optiplex workstations I'm responsible for i notice that the X server crashes on init. changing the driver to VESA fixes the problem. would it be possible to have a script for starting X that falls back on vesa in the event that a driver like ati fails? surely one could just pass it to sed and run it a second time with 
<delire> as you know, many people that say they've tried and left Ubuntu do so because X doesn't start. there are a high percentage of these cases.
<cjwatson> delire: that's https://blueprints.launchpad.net/ubuntu/+spec/bullet-proof-x, unfortunately didn't make it for feisty (actually the design never got finished)
<cjwatson> delire: safe mode is our workaround for now, but we would definitely like it to get done
<delire> ahh cool. well it's good to know. 
<delire> a sys-admin here told me before i tried "Ubuntu doesn't work on Dell's, don't bother - we've already tried" ;)
<cjwatson> unfortunately safe mode was broken in edgy, but it's fixed in feisty
<cjwatson> obviously we would also like to have some kind of workflow in there that lets us find out about the machines that are falling back to vesa and fix them eventually
<delire> yes i was thinking about this too.
<delire> cjwatson: are you thinking about some sort of user authorized report mechanism? eg sending dmesg Xorg.0.log to a db when the machine is next online?
<ogra> iwj, seeing you do MIRs, please dont bother with the libpam- libnss- ones, i'll redo them soon
<cjwatson> delire: dunno :-) I think there are rough notes in the bullet-proof-x page but they haven't been tidied up
<cjwatson> delire: gluing it into the apport crash reporting mechanism would be the obvious approach
<Robot101> ogra: which pam/nss stuff are you adding?
<delire> righto well it sounds like you're onto the case. very good to see. 
<ogra> Robot101, libpam-{ldap,mount} and libnss-ldap
<cjwatson> delire: I'm not, personally, and nobody is working on this right now
<cjwatson> delire: it is very high on the Canonical distro team's list of things that should get done
<cjwatson> delire: but we are still working on hiring an X maintainer so that we stand a chance of realistically doing them
* ogra thinks seb128 makes a very good X maintainer recently ...
<delire> right, well it is such a big showstopper it warrants that kind of commitment.
* ogra rather hides now
<seb128> ogra: run, *fast* :p
<iwj> ogra: OK, if you want to defer them, put them into the `needs work' section of the queue ?
* ogra grins behind the corner
<ogra> iwj, oki
<iwj> Thanks.  This is good especially now that there are two of us doing these occasionally.
<ogra> moved ....
<ogra> i just didnt want to drop them completely to not forget about them
<tepsipakki> delire: which version of the livecd are you using?
<pochu> heno, Mithrandir: I've just mailed you about herd-5 and xubuntu, because a xubuntu tester administrator mailed me this afternoon.
<heno> pochu: ok, thanks
<pochu> heno: there's also a surprise in the mail ;)
<Adri2000> Mithrandir: will the sync requests be processed before the end of the week?
<heno> pochu: I didn't get it yet. mails with attachments sometimes get caught in the spam filter
<pochu> heno: if you don't receive it, tell me. I attached a image
<finalbeta> Ok, feel free to shoot me if I'm out of place. But I have Rhythmbox crashing on my when playing a certain song. apport doesn't come up, no crash log is left in /var/crash and only Segmentation fault is left on the terminal. How do I provide usefull information if I want to make a bug report?
<finalbeta> Or, just ignore me, that will work 2, hehe
<pochu> yeah! I have my @ubuntu account :)
<pochu> yohooooo
<delire> tepsipakki: i downloaded an Edgy ISO around 1 week ago.
<delire> tepsipakki: it doesn't pickup X on any of the Dell workstations using ATI cards (mostly Optiplex).
<imbrandon> umm i thought we wenrnt doing the compiz/beryl , but now its in -desktop ?
<imbrandon> wth
<pochu> imbrandon: yeah, martin updated it, but it's not enabled by default
<imbrandon> that still sucks
<tepsipakki> delire: ok, you could try feisty herd 5 when it is released later this week
<pochu> imbrandon: maybe if you have an ati card :P
<j1mc> Mithrandir: Cody Somerville said I should contact you regarding the status of Xubuntu testing
<tepsipakki> delire: but you could file a bug and attach Xorg.0.log to it before that
<j1mc> Mithrandir: he's in the hospital, so I've been taking care of it.  Please see our test results on the wiki.  https://wiki.ubuntu.com/Xubuntu/Testing/Current
<tepsipakki> delire: if you can get it out from the livecd-session ;)
<pochu> j1mc: heya :)
<pochu> j1mc: have you received my mail, about 15 minutes ago?
<j1mc> pochu: no, not yet
<j1mc> oh, wait . . . yes
<j1mc> thanks for your reply
<pochu> j1mc: np :)
<pochu> heno: did you received it?
<delire> tepsipakki: i should've grabbed that log, but in a rush i've just gone ahead with the installations. 
<tepsipakki> what have you installed on them?
<delire> tepsipakki: these Optiplex machines will be used as game/3d development workstations.
<tepsipakki> ok, wife is grumpy, need to stop :P
<delire> ;)
<delire> pochu: given that Compiz and ATI don't play well, around half of all laptops capable of running a 3D game won't be able to enjoy a 3D desktop.
<pochu> delire: yes, but that's because ati drivers, isn't it?
<delire> of course, but the user doesn't care/know about that. i'm not sure if Compiz should've been the default.
<delire> although it is arguably more stable, when it does work.
<pochu> delire: it isn't prepared to be default, but it isn't enabled by default ;)
<j1mc> pochu: here is the link to our current testing page:  https://wiki.ubuntu.com/Xubuntu/Testing/Current.
<j1mc> yes, I've flip-flopped the Testing & Xubuntu, and will get that corrected after the next herd release.
<j1mc> :(
<pochu> j1mc: yeah, I've read it, but we started a different way of testing images ;)
<pochu> j1mc: oh, that's fine :)
<sladen> doko: your kernel has crashed.
<delire> pochu: for so many users, and for reasons i largely find dubious, a 3D desktop is the difference between Ubuntu being considered as an alternative against Vista and OS X. for this reason i'd probably go with a default that has the highest hit-rate. ATI dominates the portable market and so alot of users will be disappointed with Compiz. nonetheless this is a well-worn conversation and doesn't need to be dragged around again.
<j1mc> pochu: yeah . . .   i've just now gone back to find some of the info on where you're headed.  with cody being in the hospital, i expected to have revisions, but needed to get something up rather quickly.
<pochu> j1mc: you have some useful links here:
<pochu> https://launchpad.net/~isotesting
<doko> sladen: I did fear that ...
<j1mc> thanks.  funny how i'm a member of that team.   https://launchpad.net/~jwcampbell  :)
<pochu> j1mc: yeah, I saw it :)
<pochu> j1mc: if you have any question, just ask it :-)
<j1mc> pochu: thanks.  well, i'm sure we'll be in touch more going forward, but for now my big concern is seeing if there will be a Herd 5 for Xubuntu.
<j1mc> given the amount of effort and testing, I would hate for their not to be a Herd 5.
<Mithrandir> j1mc: thanks a lot; I'll take a look
<Mithrandir> j1mc: if you're in touch with him, send my regards and wishes for him becoming well again.
<j1mc> Mithrandir: thanks!  I've just sent Cody a note, copying what you just wrote.
<pochu> j1mc: thanks to you for your testing ;)
<j1mc> np.  Cody conned me into it.  :)
<pochu> j1mc: did you received the image I sent within the mail?
<j1mc> pochu: not yet
<pochu> argh! :)
<j1mc> i got the note you sent about an hour ago, though.
<pochu> I'll sent the mail without the image, at least :)
<mrec_> hi guys, what's the best way to get involved with ubuntu development?
<mrec_> I'd be interested to move my linuxtv project from linuxtv directly to ubuntu
<pochu> mrec_: you may want to read this:
<pochu> https://wiki.ubuntu.com/UbuntuDevelopment
<j1mc> pochu: i need to go, but feel free to be in touch via email.  i did get your email with the attached image.  thanks.
<mrec_> kylem: ping
<kylem> pong
<mrec_> just read that you're in the ubuntu video team, I have some problems with other linux-dvb developers and I'm now looking for a new home for my project
<mrec_> maybe developing it directly with ubuntu would be a better way to get forward
<kylem> oh.
<mrec_> http://linuxtv.org/v4lwiki/index.php/Em2880
<mrec_> it's about that driver here, around 50 new devices
<kylem> cool.
<mrec_> I'm sick of having endless discussions with them
<kylem> what do you need?
<mrec_> can I put that wiki site somewhere onto an ubuntu webserver?
<mrec_> I'll split it off linuxtv now
<mrec_> it's fine to commit that code as a USB driver
<mrec_> maybe some ubuntu guys are even interested in helping out with that project?
<mrec_> the site has around 110.000 hits since 1.1.2006 :)
<kylem> BenC, ping
<mrec_> the code is around 8000 lines at the moment
<mrec_> the problems with the linux-dvb guys is about changing a smaller part of the dvb api to add support for a generic tuner interface
<mrec_> so that 1 tuner module could be used with dvb or video4linux
<mrec_> since this is not possible and nacked by them and another solution didn't get proposed I will quit that community
<heno> pochu: thanks. you have mail
<mrec_> (I've triggered 2 discussions about that and they end up nowhere as I expected at the beginning)
<pochu> heno: looking :)
<mrec_> but I don't want to delay the inclusion of that code another year
<kylem> ok.
<mrec_> so the em28xx should directly interface the tuner module, and skip the official v4l and dvb tuner interface
<mrec_> the problem is that tuner is a hybrid tuner for analogue and dvb-t
<mrec_> merging parts of the v4l and dvb framework is a nogo for them
<mrec_> (so that was the background information)
<kylem> from the sounds of it, there seems to be demand for this... we should probably be including this driver.
<BenC> kylem: yo
<pochu> heno: looks promising ;)
<BenC> mrec_: We have a git tree (wiki.ubuntu.com/KernelTeam is where you'll get all our info)
<mrec_> I'm interested to join the ubuntu team to help improving it :) if interested
<heno> pochu: feel free to hack on it :)
<BenC> mrec_: If you can work from the git tree, we can pull directly from you
<pochu> heno: I'll try :)
<mrec_> BenC: sure I can
<pochu> heno: do you know what Mithrandir has been doing? just to not duplicate efforts
<pochu> Mithrandir: ^
<Mithrandir> pochu: my approach is to store as much as possible in LP
<BenC> mrec_: Are you worried that doing it this way will keep the driver from getting into upstream kernel?
<mrec_> BenC: I'm in contact with Greg KH as I wrote, I know what I have to do to get it into upstream kernel. I just ran into wrong directions by thinking I could work with linuxtv guys
<mrec_> the video4linux maintainer would accept my changes, but dvb maintainers are hell against it
<mrec_> and discussions are over now with them.
<pochu> Mithrandir: sure. What I've been thinking is to make a page with the current state of each image, and links to them, so we can see in a moment which ones haven't been tested, or which need another try...
<Mithrandir> pochu: yes, that's the goal.
<Adri2000> Mithrandir: will the sync requests be processed before the end of the week?
<pochu> Mithrandir: but the reports would go to LP, and the status field in the LP report would be the status in the page
<pochu> (IMHO)
<pochu> as heno wrote in the wiki :P
<Mithrandir> Adri2000: I don't see why not.
<BenC> mrec_: Excellent, because the ultimate goal would be to get it to that point. I look forward to the first pull of your driver :)
<BenC> mrec_: Note, we're about to freeze the kernel, so the sooner the better
<mrec_> I could do some amd64 too, since I work for AMD :)
<Mithrandir> pochu: yes, but I'd also want to grab the list of subscribers and their comments from LP.
<Adri2000> Mithrandir: ok :)
<BenC> mrec_: Oooh, then maybe you can get AMD to be more Linux friendly :)
<mrec_> BenC: let's see what the future will bring up
<mrec_> that driver is a private project though
<pochu> Mithrandir: do you mean to show them in the 'overview page'?
<BenC> mrec_: Right, understood
<Mithrandir> pochu: yes.
<BenC> mrec_: For future discussion on this, #ubuntu-kernel may be more suited
<pochu> ok :)
<BenC> mrec_: kernel-team@lists.ubuntu.com for discussion and patch submission/git-pull request
<BenC> mrec_: We take patches on the same basis as you would do for Linus
<mrec_> fine :)
<mrec_> BenC: so I'll try to migrate my driver during this weekend, the code should be available within a few days then.
<BenC> mrec_: sounds good
<psusi> what's the argument again for not having the livecd mount hard disks?
<jdong> psusi: automatically without asking, or not having the ability to instruct Ubuntu to mount it after bootup?
<psusi> the other day I found that with the dapper livecd, if you right click on a hard disk in gnome and choose mount, it says pmount failed... clearly this is not acceptable, but it seems it is intended that pmount not auto moun hard disks
<jdong> I personally would not like a livecd implicitly mount without my permission
<jdong> but as far as the behavior you describe, I'd call it a bug.
<psusi> why?
<psusi> would an acceptable solution then be to have pmount accept hard disks, but have hal not try to auto mount them?  thus the gnome mount option would work manually?
<psusi> or what if it only auto mounts them read only?
<jdong> psusi: what if my volume was badly damaged to the point where mounting it causes a kernel oops
<jdong> and that's happened to me before
<jdong> read-only is better
<psusi> then that's a bug in the kernel and should be fixed ;)
<jdong> but read-only is not 100% read only either.
<psusi> that is another bug that needs fixed...
<jdong> i.e. some filesystems execute journal recovery anyway
<jdong> well, you go fix that
<jdong> then I'll agree to mounting read-only
<psusi> hehe ;)
<jdong> </ubuntu attitude>
<jdong> actually...
<psusi> well, you do agree that it should moun when you tell it too right?
<jdong> absolutely.
<jdong> that's agreed
<mrec_> BenC: what's the best place to move the documentation to?
<psusi> iirc, it is gnome-volume-manager that calls pmount... it should just not do that for hard disks automatically, but if pmount is called at the user's request, then it should not refuse to mount hard disks.... make sense?
<Mithrandir> psusi: g-v-m doesn't use pmount any more.
<psusi> ohh?  it directly mounts itself?
<Mithrandir> it uses some hal methods for doing it, AIUI.
<jdong> has seb128 already finished serving his archive day today? :(
<seb128> jdong: no, I didn't do lot though, I'm not sure what I can do during a freeze
<seb128> jdong: what do you need?
<jdong> seb128: can you do all the in progress backports?
<seb128> ah, I can have a look at that, right
<jdong> it's been... a month since an archive manager has paid any attention to it
<jdong> thanks, I really appreciate it
<seb128> I never done them, need to look what has to be done there first ;)
<Mithrandir> jdong: "already"?  It's after 22:00, even seb needs to sleep once in a while.
<jdong> Mithrandir: I'm sorry, I didn't know what timezone you guys are all in
<seb128> archive team is to european time
<jdong> ok
<jdong> if you don't want to deal with it, that's fine
<seb128> jdong: I'll probably have a look tomorrow rather than tonight
<jdong> ok
<jdong> good night
<seb128> 'night
<Mithrandir> jdong: np. :-)
<mdke> fabbione: ubuntu-serverguide is in the archive. Can you include it in the server installation and maybe have a think about some potential ways to make users aware of its presence?
<BenC> mrec_: Documentation/ is good
<mrec_> BenC: hmm, I put it to https://wiki.ubuntu.com/em28xx, would be nice if you could move it
<BenC> mrec_: Oh, that's fine too
<pochu> mrec_: have you thought in making subpages, to not make the page so long?
<pochu> I think then it will look better :)
<mdke> how long does it take for mail to ubuntu-devel to be moderated nowadays? are there a good few moderators? or is it faster to write to -discuss for getting to the developers' attention?
<LaserJock> it could take a little bit, I'm really not sure
<mdke> i see waves of email coming into that list every now and again, so I have the impression the moderation isn't perhaps as frequent as it should be
<mdke> I don't understand the distinction with the two mailing lists anyway, I'll use -discuss
<mvo> mdke: have you seens that #74555 is now verification-done?
<mdke> mvo: yeah thanks a lot! I've passed it onto dholbach for uploading
<mdke> :)
<mvo> mdke: cool, thanks 
<mrec_> pochu: feel free to change it :)
<mdke> mvo: since you're here - do you know who is in charge of implementing the easy installation of binary drivers that mdz mentioned in his recent announcement?
<mvo> mdke: originailly that was assigned to me, but then scott took it over
<mdz> mdke: I believe pitti is working on it
#ubuntu-devel 2007-03-01
<Riddell> Mithrandir: could you let libapt-front and adept through please, the current version of adept crashes lots
<tenco> i mentioned yesterday that i had a process running which generated high disk i/o for over 15min. i thought this was some process connected to klogd. it was trackerd
<poolie> i was just helping someone get gcc going
<poolie> should gcc perhaps depend on libc6-dev rather than just recommending it?
<poolie> it's not very useful without it
<Lathiat> its perfectly usefull if your not using the standard c library :)
<Lathiat> generally installing 'build-essential' works well
<poolie> true enough
<Lathiat> but yeh i mean your right in the general case gcc is usefull
<Lathiat> but its not a hard dep
<MichaelScott> Lathiat: that's what she said?
<Lathiat> MichaelScott: no i'm saying that "in the general case, your right", but in the more specific case, it's not a hard dependancy
<MichaelScott> oh forget it
<MichaelScott> you non-Americans don't appreciate dumb american humor.
<MichaelScott> :)
<MichaelScott> I mean... humour
* ajmitch tries to identify the humour in Lathiat's statement
<MichaelScott> _hard_ dep
<MichaelScott> come on, it's michael scott humor
<MichaelScott> finding ridiculously stretched innuendos in every statement.
<ajmitch> I'll just nod & smile & return to work
<MichaelScott> tha'ts what she said.
<MichaelScott> ;-)
<MichaelScott> btw, ajmitch , is that consolidate-the-changelog thing something I should do or will you guys handle it? :)
<ajmitch> you need to do everything once it gets UVF approval
<ajmitch> like subscribing ubuntu-universe-sponsors, etc
<MichaelScott> ok
<MichaelScott> and does your statement count as a +1? :)
<ajmitch> yes
<MichaelScott> yay :)
<MichaelScott> so now I find another target to annoy?
<ajmitch> so you can stop bugging me
<MichaelScott> ajmitch: you are free
<MichaelScott> ajmitch: speaking of UVFe for l-r-m fglrx....
<MichaelScott> kidding
<ajmitch> bug ubuntu-release
<jcole> http://video.ubuntu.com/
<jcole> lively web server
<jdong> streaming hardcore ubuntu artwork 24/7
<ajmitch> ah, I remember those fun talks
<manchicken> Anybody know how to enable debug with pbuilder explicitly?
<Hobbsee> manchicken: ie, with a compile time option?
<Hobbsee> ie, debug pbuilder, or debug the app you're building with pbuilder?
<manchicken> Yep ^_^
<manchicken> as in pbuilder build --enable-debug foo.dsc
<manchicken> Where --enable-debug is the flag that actually works ^_^
<manchicken> I'm guessing there's a pass-through option?
* Hobbsee suspects you'd have to pass that in debian/rules as a configure flag of the package, else it would just debug pbuilder itself
<manchicken> Wouldn't I have to screw with the tar, thus killing the sig?
<ajmitch> plus setting DEB_BUILD_OPTIONS
<manchicken> Ooh...
<ajmitch> disabling stripping, but it still wouldn't add debugging if it wasn't there
<manchicken> Will that actually pass those to configure?
<ajmitch> there are docs about using it with pbuilder
<manchicken> I've never seen a really good doc for pbuilder.
<Hobbsee> yes, the man pages are kinda confusing
<Hobbsee> so many options
<manchicken> Weird...
<manchicken> It won't build.
<ajmitch> of course you may find that there are separate debug symbols elsewhere if it's a package in the archive :)
<jcole> http://www.getacoder.com/projects/operating_system_42879.html
<lasindi> Hi all, I have been trying to use Xsane for scanning, and I find the user interface to quite confusing. Since Xsane is included by default in Ubuntu and one of the goals of Ubuntu is ease of use, I was wondering, are there any alternative GUIs for scanning being developed in the Ubuntu camp? As a developer, I've been thinking of starting work on one myself.
<theCore> Could someone in the dev team look up at bug 57951. It been open since the early Edgy development days, and it still not fixed, even if the patch is available. 
<Ubugtu> Malone bug 57951 in xchat "xchat crashes frequently on quit" [Medium,In progress]  https://launchpad.net/bugs/57951
<ajmitch> what timing, we were just discussing it earlier
<bddebian> Heya
<theCore> The fix works -- I used it for about 4 months -- so, it just a matter of applying the patch and releasing the package  
<theCore> http://librarian.launchpad.net/5374594/changes.diff
<theCore> Also, fixing this bug would make my mailbox very happy :)
<theCore> Should I upload a fixed package to REVU, so someone with an access to the main archive uploads it?
<ajmitch> theCore: attaching a debdiff to the bug & subscribing ubuntu-universe-sponsors (if they're not already) would be good
<ajmitch> actually it may be motu-sru
<jdong> oh look.
<jdong> subscribing.
* jdong shuts up
<theCore> ubuntu-universe-sponsors is already subscribed
<ajmitch> jdong: please
<theCore> I will do the debdiff
<fabbione> mdke_: i can include it in the seeds.. yes.. we can add it to the release notes.. i can't think of any easy way to notify users otherwise
<LaserJock> fabbione: what's a good of reading it?
<fabbione> LaserJock: ?
<LaserJock> fabbione: when I made the serverguide package I didn't provide for any way to look at it
<LaserJock> just installed the HTML
<fabbione> LaserJock: let me wake up a bit and think about it
<poningru> add what to the release notes?
<Fujitsu> poningru: The Ubuntu Server Guide.
<poningru> yeah that needs to talk about lack of root -p on mysql as well
<poningru> for whatever reason on feisty you cant set root password on mysql
<highvoltage> hey viviersf 
<fnf> What is the current development state of Ubuntu Feisty server ?. I noticed there's no Server installation CD on Herd 4 (Herd 3 is the last). Does that mean the Server version will no longer receive major changes until Feisty is finalized ?
<LaserJock> I don't think that's what it means
<lifeless> it more likely means that the server wasn't ready for herd4, or failed to built or some such
<fnf> Laserjock, lifeless: that sounds reasonable.
<LaserJock> hi pitti
<pitti> Good morning!
<fabbione> fnf: it was just an overlook when herd-4 was released but they are alpha image so it's not soooooo tragic
<fabbione> fnf: anyway there are daily images you can always test
<fabbione> http://cdimage.ubuntu.com/ubuntu-server/daily/current/
<fabbione> if images are missing is NOT a disaster
<fabbione> they might not build
<fnf> fabbione: thanks for the link, this is Mat 1st already, may I assume all the versions are Herd 5 ?
<fabbione> no you cannot assume
<fabbione> they might get rebuilt later today
<fabbione> those are daily as the name say
<fabbione> tomorrow they will change even if herd-5 is released in between
<fnf> fabbione: I know, but today Herd 5 gets released, so these are also Herd 5 version I think.
<fabbione> no.. as I just said.. we can rebuild images at any given time during the day
<fabbione> and you might notice that i386 server is missing
<fnf> fabbione: I see.
<fabbione> so that needs fixing before we can publish herd5
<Fujitsu> pitti: Can you please find some time to take a look at that zope3 SRU which has been sitting dormant for some 2 weeks?
<pitti> Fujitsu: what's the state of it?
<pitti> Fujitsu: My role is to verify and approve debdiffs and do the archive processing, so if one of those is the current blocker, I apologize
<pitti> however, I run through the currently pending issues every Friday
<Fujitsu> pitti: You asked me to attach a new debdiff and set it back to `In Progress'. I have done both.
<Fujitsu> (it's OK if you're doing other stuff, of course)
<pitti> Fujitsu: ah, great; will have a look
<poningru> herd5 will be the last alpha right?
<mdke_> fabbione: colin added it to the seeds already, thanks tho
<fabbione> mdke_: ok
<LaserJock> fabbione: what if we installed a script like /usr/bin/serverguide that fired up a html viewer with the URL to the server guide?
<fabbione> LaserJock: no, i think we should just mention it in the Release Notes
<LaserJock> ok, so that should be sufficient?
<fabbione> otherwise you will get a gazillion bugs about the preferred html viewer and all that crap
<fabbione> i think it will be enough
<mdke_> how many html viewers are installed by default?
<LaserJock> isn't there a /etc/alternatives for that?
<lifeless>  /win 18
<Fujitsu> LaserJock, indeed there is.
<Mithrandir> x-www-browser, for instance.
<Fujitsu> Hey Mithrandir.
<Mithrandir> hi Fujitsu 
<fabbione> you will need www-browser for text browsing
<fabbione> x-www-browser is for well X GUI stuff
<fabbione> that we for sure don't ship on server
<mdke_> so if www-browser is used, there wouldn't be a problem about preferring an html viewer
<Mithrandir> use sensible-browser, then.
* Fujitsu watches the Accepted mails flood in.
<mdke_> fabbione: something like a /usr/bin/ubuntu-serverguide that executes 'www-browser /usr/share/ubuntu-serverguide/html/$LANG/index.html' might work, unless you think that adding scripts like that is a bad idea generally
<Lathiat> pitti: you removed the nss-mdns cleanup code? :?
<Lathiat> pitti: :/ rather
<ogra> Mithrandir, did you only do alternate last night ? i'm still missing i386 desktop
<Mithrandir> ogra: it's building now.
<ogra> thanks
<Mithrandir> that it, it should just be done now
<poningru_> oh blargh?
<poningru_> herd 5?
<poningru_> fuck
<poningru_> sorry
* poningru_ hurries up with the notes
<tepsipakki> poningru_: is the draft available somewhere?
<poningru_> working on gobby
<tepsipakki> ok
<poningru_> err well I have it written down
<poningru_> and putting it up
<poningru_> trying to find someone who can do screenshots
<Mithrandir> ogra: there are your desktop ISOs too.
<ogra> thanks :)
<dholbach> good morning
<_ion> Good time of day.
<dholbach> hiya _ion
<pitti> hey dholbach 
<dholbach> heya pitti
<doko> pitti: bug 88843, why does apport insist on python?
<Ubugtu> Malone bug 88843 in python-defaults "[apport]  python crashed with SIGSEGV in gtk_tree_view_remove_column()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88843
<pitti> doko: hm, seems apport doesn't figure out that it is an interpreted script in this caes
<pitti> doko: I'll open an apport task and look at it, thanks
<doko> pitti: already did that with another one yesterday
<doko> Mithrandir, cjwatson: what was the status of the CD size discussion? edubuntu ships with another one, but all other ship with one? or don't we provide a powerpc cd anymore offcicially for feisty (which was the biggest one)?
<Mithrandir> doko: powerpc is a community port, so it's certainly there, but I am not going to spend much time on trying to size it down.
<Mithrandir> doko: ubuntu is not going to ship on more than one cd, at least not this cycle.
<pitti> doko: saw it, thanks
<ogra> doko, edubuntus live CD is still only one, i have the same problems there as ubuntu
<ogra> cjwatson, what do you think about http://bugzilla.mindrot.org/show_bug.cgi?id=1215 ? i have one edubuntu users authenticating against netware, he tried that patch and said its working fine (after a week of struggling) do you think it would be feasable ?
<Ubugtu> bugzilla.mindrot.org bug 1215 in PAM support "sshd requires entry from getpwnam for PAM accounts" [Enhancement,New]  
<Mithrandir> ogra: that looks like quite a hacky way of solving a problem.  Why not just make the user exist through some NSS module?
<ogra> apparently that didnt work 
<cjwatson> I'm not comfortable with that until it gets applied upstream
<cjwatson> Darren is an upstream developer, so if he thinks it's production-quality, he's entirely capable of checking it in
<cjwatson> if he hasn't, then there's probably a good reason
<ogra> well, i was thinking about the one at the bottom, not about darrens proof of concept hack
<Mithrandir> ogra: tracker bugs filed for the current images.  Please update those when you have tested.
<ogra> yep
<Mithrandir> same for ubuntu desktop and alternate; please test everybody.
<seb128> Mithrandir: is the current amd64 desktop image good to test?
<Mithrandir> seb128: yes, it should be.
<seb128> ok, just finished rsyncing it, burning CD now
<doko> Mithrandir: if a md5sum of a package is wrong on the cd, is this a bad disk? burnt it twice, but it didn't get away
<Mithrandir> doko: and you had the same package go bad on each check?
<fabbione> doko: check it manually with the md5um in archive?
<doko> Mithrandir: yes, yesterday's daily (grub), so I just removed the line for the cd in sources.list and continued.
<pitti> FYI, I just did a 'check' on amd64 desktop and alternate, both succeeded
<pitti> hey mh21
<pitti> moin Keybuk 
<Keybuk> morning
<mh21> goedemorgen pitti
<pitti> eek, 'Report a problem' in Applications -> System Tools
* pitti fears seb128's wrath
<seb128> pitti: why?!? 
<pitti> seb128: aaah, *phew*, it's from apport-qt
<seb128> ah ;)
<pitti> seb128: Categories=KDE;Application;System;
<pitti> seb128: there was a key that says 'do not show in Gnome', right?
<seb128> it should have an OnlyShowIn=KDE
<pitti> ah, great
<pitti> yep, that does the trick; /me hugs seb128, thanks
<xerxas> Hi all
* seb128 hugs pitti back
<seb128> hi xerxas
<xerxas> hi seb128  
<pitti> seb128: hmm, System->'Report a bug' doesn't seem to care about OnlyShowIn
<seb128> pitti: no, that one is coded to gnome-panel code
<pitti> ah
<seb128> that menu is not a xdg dynamic one
<seb128> pitti: why do you want to mask it?
<pitti> so I'll add OnlyShowIn=Gnome to apport-gtk.desktop to hide it for KDE users
<seb128> GNOME
<pitti> seb128: oh, =KDE was just for testing
<pitti> ah, all caps then; thank you!
<seb128> np
<pitti> seb128: will '=GNOME;XFCE' work?
<seb128> yes
<seb128> GNOME;XFCE; 
<seb128> not sure if the ";" is mandatory, other .desktop use it
<ogra> grmbl, rsyncing takes significantly longer with two more isos :/
<funpop> i know this is not a support channel, but i cant find any answer: if need a log of whats wrong if i shutdown my system (cause its not powering down)
<funpop> *if = i
<pitti> amd64 desktop live system and ubiquity install works fine, good
<pitti> heno, Mithrandir: do you already track install success on the current images?
<ogra> pitti, there should be bugs
<heno> https://bugs.launchpad.net/ubuntu-iso-tests/+bugs
<pitti> right, so the current images are already candidates?
<heno> only 10 of them AFAICS
<heno> If they are listed there, then I assume so
<heno> I think tollef posts them when they become candidates
<heno> pitti: ^
<pitti> heno: thanks
<cjwatson> ogra: I'd rather trust a patch Darren's acked ;-)
<ogra> cjwatson, right ...
* ogra gives mvo and cjwatson a loong big hug 
<ogra> thanks so much for the add-on CD work, its working great !
<ogra> mvo, how hard would it be to filter empty categories from the main list
<LaserJock> pitti: I've just added edubuntu-docs to the MIR queue but I just uploaded a new version (0.5-1) so it might take a while (manual shove) to get through
<pitti> yup, no problem
<LaserJock> pitti: thanks a ton
<mvo> ogra: oh, yeah. I need to look into this
<ogra> apart from that its perfect 
<mvo> ogra: yeah, I tested it today too :)
<ogra> hmm, wait, gcompris has no entry 
<ogra> mvo, where does the CD get the desktop entries from ? app-install-data ? 
<mvo> ogra: yes
<ogra> hmm, on my disk there is a gcompris.desktop in /usr/share/app-install/desktop/
<ogra> but not on the CD
<mvo> ogra: is gcompris on the addon cd?
<ogra> yep
<ogra> aaah, crap
<mvo> ogra: it seems like the CD has only sound+data?
<ogra> mvop, my fault ... 
<mvo> np
<ogra> seeds fixed ...
<Riddell> mvo: no luck with dist-upgrade tool in archive?
<mvo> Riddell: it should be there, no?
<mvo> oh, no
<mvo> crap
<Fujitsu> mvo: You seem to be the master of gnome-app-install... I'll be uploading a new SoundConverter package soon with an icon, revamped .desktop (without spelling mistakes), etc. How do I go about getting the versions in app-install-data updated?
<Riddell> Fujitsu: it happens magically
<Fujitsu> Riddell: Apparently not.
<mvo> Fujitsu: it happens magically (and gets merged ~1 week)
<Fujitsu> mvo: OK, if you say so :)
<mvo> Fujitsu: did it not work for you for some reason?
<Fujitsu> Well, there's been a new soundconverter .desktop and icon in the archive for a couple of months now, while app-install-data still has the one from Edgy...
<mvo> Fujitsu: let me check ...
<mvo> Fujitsu: it seems like the pixmap does not get picked up because of the symlink that is used, I will check the script. the desktop file got picked up it seems
<Fujitsu> The symlink is gone in the new version (it's pending on a UVFe), because upstream now has a proper icon.
<Fujitsu> mvo: Ah, I see it has indeed picked up the .desktop... I must have been looking at old data when I last checked.
<mvo> Fujitsu: that will probably make it work, also it is a bit strange as symlinks should be picked up
<mvo> Riddell: thanks a lot for the adept fix btw!
<Fujitsu> Thanks for clarifying all that, mvo.
<mvo> Fujitsu: you can check it yourself at http://people.ubuntu.com/~mvo/gnome-app-install/menu-data-full-feisty.tar.gz that one is updated nightly
<Fujitsu> Even better! Good to be able check :)
<pitti> aah, now I found out how to trigger auto-resize in d-i: choose 'entire disk', say 'no', go back to 'guided partitioning', and voila, there it is
<pitti> cjwatson: ^ maybe it does not (fully) detect the current partition layout the first time?
<ogra> pitti, isnt that obvious ? :P
<sabdfl> dholbach: thanks for fixing my themes :-)
<dholbach> sabdfl: did you run an "apt-get autoremove" afterwards?
<dballester> hi to all
<dballester> where is the best channel to discuss about what kernel modules could/should be part of the kernel package ? I need to talk about ocfs2. Thanks.
<fabbione> dballester: ocfs2 is already part of the kernel
<fabbione> you need the -server kernel
<sabdfl> dholbach: no
<dballester> fabbione, yes, but is not compiled by default
<sabdfl> when i do that now it wants to remove npt and ntp-simple
<fabbione> dballester: uh?
<fabbione> dballester: what kernel are you trying to use?
<dballester> fabbione, in desktop kernel i say
<fabbione> dballester: yes, it has been removed from the desktop kernel and it is in the server kernel
<fabbione> <fabbione> you need the -server kernel <-
<dholbach> sabdfl: then I don't really understand what happened on your box, but am happy that it's fixed (apt-get autoremove would have removed ubuntulooks, which might have been the problem) - I added the dependency, when tollef and pitti prodded me about it, so it should all be good now
<dballester> fabbione, but in the other hand ocfstools / console are offered as package and this packages as no sense without the ocfs manager module
<fabbione> dballester: we can't filter the packages based on the install.. the great power of being able to do whatever you want without your machine
<dballester> but I now have clear why ocfs is not offered as desktop kernel
<fabbione> you might switch kernel
<fabbione> you can compile yourown.. etc. etc.etc.
<fabbione> we offer it in the server kernel where it makes more sense
<dballester> fabbione, agree, i only try to understand why my kernel had ocfs module set to off :)
<fabbione> tho it is *theoretically* possible to have / on ocfs2 with local mounts, i see really little point in supporting these kind of operations
<sabdfl> dholbach: i use aptitude, and have it set to keeppackages pruned, and yes i think it removed ubuntulooks
<dballester> fabbione, totally agree, i'm only trying to have all pieces to make a little conference about ocfs2 in one freenode irc channel, and was preparing the 'learning scenario'. My idea is that people can apply locally the commands that i run, and see how it works
<seb128> testing the amd64 desktop CD atm, seems to work fine
<dholbach> sabdfl: Ok, then it makes sense. Thanks for prodding about it.
<fabbione> dballester: did you try to talk with the ocfs2 guys? they are really nice guys and very available
<dballester> fabbione, I know :) i'm member of the oracle ocfs2 mailing list and use ocfs2 a lot ( Oracle RAC environments )
<fabbione> ah ok cool
<dballester> fabbione, my target is to make a little 'hands on' irc conference, and i'm trying to see if it's possible that each user could make a 'test scenario' on is own computer without effort/danger. This is why i was asking about ocfs2 module in ubuntu desktop kernel
<fabbione> dballester: i understand.. well in the worst case you can easily build one
<fabbione> dballester: but using the server kernel is the right thing to do
<dballester> fabbione, totally agree
<fabbione> also.. what release of ubuntu are you going to use?
<dballester> well, i'm using 6.10
<fabbione> ok
<cjwatson> pitti: I need /var/log/partman
<fabbione> i am waiting oracle to release 1.2.3 ocfs2-tools for feisty that do support local mount
<dballester> and is what i hope assistants use
<fabbione> without the need of a cluster
<fabbione> that for testing > *
<fabbione> so if timing fits, that would be much easier for all your audience 
<fabbione> being able to test on loopback devices without special hw or setup will help a lot
<cjwatson> pitti: oh, it could just be offering to auto-resize the pending results of the first round of guided partitioning you did :-)
<cjwatson> pitti: i.e. erase entire disk creates big hda1 (ext3) and small hda5 (swap), auto-resize spots the big hda1 with lots of free space and offers to resize it ...
<pitti> cjwatson: urgh, that would in fact be dangerously wrong, since I told it to not use the scheme; I'll check whether the previous installation is still there
<dballester> fabbione, if i remember well, oracle released some days ago 1.2.4 ocfs2 module, hope 1.2.3 tools will come quickly
<cjwatson> pitti: not dangerous because it hasn't been committed yet
<fabbione> dballester: we have the 1.3 series for the kernel module. i have 1.2.3 ready from svn, but i am waiting for the to release officially after QA is completed
<cjwatson> pitti: most of partman works quite happily with pending uncommitted changes - client scripts only notice that a partition isn't actually physically on disk yet if they really try
<pitti> cjwatson: OTOH, if it's able to resize the scheme it just created, I wonder why it never offers me to resize the very same scheme from the previous 'entire disk' run
<cjwatson> the normal "what partitions are on this disk" tools will show the desired state
<fabbione> dballester: they usually tag in SVN and send to QA before releasing the official tarball
<cjwatson> pitti: because parted doesn't know how to resize current ext3 partitions yet
<cjwatson> pitti: this is a really nasty annoying bug that I would very much like to fix before release
<cjwatson> pitti: it can't cope with the resize_inode flag
<pitti> cjwatson: oh, ISTR having successfully resized older ext3 partitions, but that's indeed a while
<pitti> cjwatson: so maybe we should test this with VFAT instead?
<cjwatson> pitti: but if the partitioning hasn't been committed to disk yet, this doesn't apply - it's just a virtual resize which is easy
<dballester> fabbione, ok. Thnaks for your info and interest!
<cjwatson> pitti: if you actually want auto-resize to work, try something other than ext3, yes
* Keybuk wonders what the policy is for TB members changing their own ubuntu-core-dev expiry
<StevenK> Heh
<cjwatson> pitti: I don't want to stop people reminding me of the problems with ext3 though
<fabbione> dballester: no problem.
<cjwatson> pitti: the biggest use case for auto-resize has always been vfat/ntfs
<pitti> cjwatson: ah, that explains why resizing is so fast now; thanks for the heads-up
<Fujitsu> Keybuk: Don't they have implicit membership anyway?
<Keybuk> Fujitsu: yes, but I prefer not to risk it :p
<cjwatson> pitti: right, virtual resizing is just shuffling a directory in /var/lib/partman/devices ;-)
<cjwatson> (virtual = not on disk)
<cjwatson> pitti: it is sort of a bug that auto-resize bothers with virtual partitions
<cjwatson> 'cos that's really pretty pointless
<cjwatson> ubuntu/daily-live: feisty-desktop-amd64.iso oversized by 186368 bytes (736237568)
<cjwatson> so close
<cjwatson> wow, we managed to oversize the Kbuntu DVDs
<cjwatson> Kubuntu
<StevenK> cjwatson: By how much?
<cjwatson> that's really rather impressive
<cjwatson> 350MB
<cjwatson> (on i386 anyway)
<StevenK> Oh yeah, that's quite impressive.
<cjwatson> I'd really rather not create a second DVD ...
<StevenK> cjwatson: Just declare we require dual-layer media. :-P
<cjwatson> hah
<Chipzz> how do you manage to oversize the *dvd*? :)P
<Hobbsee> strike!
<cjwatson> ditching linux-image-debug-* would be one approach there, I guess
<Keybuk> "Your Derivative is SO PHAT that it oversized a DVD!"
* ogra thinks its all Hobbsees fault, she packages to much KDE stuff
<Hobbsee> haha
* Hobbsee so didnt do any of it.
<Hobbsee> cjwatson: to oversize by 350MB - what hte heck is on it?
<Hobbsee> cjwatson: yes, quite likely
<cjwatson> everything up to the supported seed
<ogra> there were a lot MIRs this release
<cjwatson> linux-image-debug-* is 478MB for i386
<ogra> wow
<cjwatson> hmm, oh, I know
<cjwatson> we probably haven't processed removals there for a bit, so it'll be taking all versions
<cjwatson> which is apparently five times as much as it actually needs
* cjwatson goes to run the cruft-checker
<Hobbsee> heh
* ogra liked the Hobbsee theory better
<StevenK> Yes, but you can't exactly purge Hobbsee from the archive.
* Hobbsee blames ogra 
<torkel_> ogra: are you sure it's not a conspiracy? - The Hobbsee conspiracy :-)
<Hobbsee> the conspiracy of DOOM!!!
<StevenK> The pointy conspiracy?
<ogra> heh
* Hobbsee is NOT POINTY!
<Hobbsee> StevenK: you could try.
* Hobbsee has a theory about ogra and sabotage...
<Hobbsee> :P
<Treenaks> Hobbsee: You mean ogra grew a moustache? (http://www.beastiemania.com/songspotlight/images/sabotage.jpg)
<Hobbsee> eek!
<ogra> heh, beautiful 
<jsgotangco> lol
<jk_work> What's the right place to report new USB vendor/product IDs for a driver?
<jk_work> I already submitted a patch upstream
<Keybuk> upstream is fine
<jk_work> so it's OK for Ubuntu to wait until it percolates into a linus release?
<Keybuk> if it's an important driver, they an be submitted as a patch to the kernel team
<jk_work> well, hardly :-)
<Keybuk> but it's pretty likely that we'd pull from upstream git anyway
<jk_work> but it's been asked for on the forums
<jk_work> http://ubuntuforums.org/archive/index.php/t-230365.html
<mjg59> There's no problem with submitting that as a patch
<jk_work> mjg59: As a bug against the kernel in launchpad, or where?
<asac> hmmm ... since a few days my default emacs (edgy) fonts became really tiny/unreadable .... what might have happened ... what package might have caused this? I see nothing about fonts in aptitude log.
<cjwatson> jk_work: yeah, linux-source-2.6.20
<jk_work> tnx
<mjg59> jk_work: Yeah
<jk_work> #88929
<Fujitsu> Who do I poke about getting pkg-create-dbgsym build failures resolved?
<slomo> Fujitsu: pitti probably
<Fujitsu> Thanks slomo, I shall try to catch him tomorrow.
<slomo> Fujitsu: if you do so please tell him from me that i put i present for him in the hal bzr branch ;)
<seb128> what is the account from the migration assistant tab for? does it work to import settings from several account when you can enter only one user?
<tbf> what's the best way to contribute a new package?
* tbf quickly created a package for Vala (http://vala.paldo.org/) and wants it to show up in Ubuntu
<seb128> ah, the user infos apply to the selected account
<ogra_> tbf, #ubuntu-motu is the right place to talk about that
<seb128> tbf: try on #ubuntu-motu
* tbf visits #ubuntu-motu
<Fujitsu> pitti: I hear that you may deal with build failures caused by pkg-create-dbgsym... If so, can you have a look at drscheme on i386/amd64?
<pitti> url?
<Fujitsu> https://beta.launchpad.net/ubuntu/+source/drscheme/1:352-10ubuntu1
<carlos> pitti: do you want to start playing with Feisty lang packs?
<pitti> carlos: of course!
<carlos> pitti: I'm planning to generate the first export today (although it's more or less the same as Edgy)
<Fujitsu> pitti: It builds fine without pkg-create-dbgsyms
<pitti> carlos: oh, then don't worry
<pitti> carlos: I'd be interested in a tarball once the entire import is done
<carlos> ok
<carlos> I will ping you then once that's done
<pitti> great, thanks
<carlos> pitti: anyway, I'm going to enable again lang pack updates for the other distros
<carlos> pitti: so you can prepare March update
<pitti> Fujitsu: hm, it did build on sparc/ppc
<Fujitsu> pitti, yup. I found that somewhat irritating.
<pitti> Fujitsu: du: `./usr/share/plt/doc/doc-license.txt': Not a directory -> doesn't sound particularly pkg-create-dbgsym'ish to me...
<Fujitsu> It builds fine without it, and I had someone else confirm that installing pkg-create-dbgsym gave such an error.
<pitti> Fujitsu: hm, I'll try it on my local system then
<Fujitsu> Thanks.
<Fujitsu> I need to head off to bed now.
<asac> pitti: source rejected with: "firefox_1.5.dfsg+1.5.0.10-0ubuntu0.6.06.1.dsc: Version older than that in the archive."
<asac> but .debs got accepted apparently
<pitti> asac: ah, that's fine
<pitti> source was already there, right
<asac> ok
<asac> good :)
<pitti> asac: yay, binaries are finally there!
<pitti> *phew*
<asac> at last
<asac> ;)
<cjwatson> seb128: best check with evand on #ubuntu-installer if you're puzzled
<seb128> cjwatson: ok
<seb128> brb, trying new install
<pitti> Fujitsu: works fine here
<ogra_> BenC_, did you revert the broadcom drivers in -9 ?
<ogra_> i just booted an upgraded system which hardlocks immediately if NM kicks in 
<ogra_> hmm, also happens with -5
<ogra_> false alarm then, must be something different than the kernel
<Mithrandir> pitti: thanks a lot for all your testing, but the amd64 desktop one is oversized so a bit more testing of that (once it's built) would be great.
<pitti> Mithrandir: oh, sure
<pitti> Mithrandir: I'd like to avoid reinstalling my main desktop once again, though; vmware should do though, unless we get new kernels
<pitti> Mithrandir: what do you throw out? just langpacks, or something more intrusive?
<Mithrandir> pitti: yup, it's just a removal of a couple of langpacks.
<Mithrandir> we're down to just en + de on amd64 desktop now. :-(
<pitti> urgh
<pitti> that pretty much solves the Chinese input support question for this case at least
<Mithrandir> indeed.
<dxdemetriou> hi. can I optimize my whole system from i386 to k7? I have seen somethings about apt-build and prelink, but I don't now if it is a good idea
<seb128> Mithrandir: desktop amd64 CD and installation works fine on my desktop
<Mithrandir> pitti: but the .fr langpack seems to be huge, since it's now almost 25 MB below the limit..
<Mithrandir> I need to sit down and just play with those bits when we get closer to release and everything settles down a bit.
<pitti> urgh
<Mithrandir> seb128: I just completed a rebuild of amd64 desktop, so if you could test that.. :-/
<seb128> Mithrandir: rsyncing and burning CD again then ;)
<Mithrandir> seb128: thanks a lot.
<Mithrandir> sorry.
<pitti> Mithrandir: French langpack should be 3.9 MB (including Gnome)
<seb128> np
<Mithrandir> pitti: then something else is jumping around.
<pitti> Mithrandir: Interested in an exact list of cumulative langpack sizes?
<Mithrandir> pitti: if you have it, certainly.
<pitti> just generating
<pitti> Mithrandir: http://people.ubuntu.com/~pitti/tmp/langpacksizes.txt
<pitti> Mithrandir: 'G:' is the language's size for Gnome (i. e. base+gnome package), 'GSum:' is the cumulative size for this and all previous langs
<pitti> Mithrandir: and the order is according to priority
<Mithrandir> pitti: great. :-)
<Mithrandir> pitti: how did you generate it?  Just apt-cache filtering?
<pitti> Mithrandir: more or less, yes: http://people.ubuntu.com/~pitti/scripts/langpacksize
<cjwatson> dxdemetriou: the gain is tiny; it's not worth it
<pitti> Mithrandir: it's a quick hack, runs slow as hell, but has proven to work :)
<cjwatson> dxdemetriou: chances are you'll spend more time rebuilding than you'll ever get back
<pitti> Mithrandir: it's in the langpack-o-matic bzr
<Mithrandir> pitti: shiny, thanks.  I'll see if I can use that in my release status pages to tell me that "you do have room for those three other langpacks".
<pitti> that would be shiny indeed
<j1mc> will Herd 5 be out today?
<Mithrandir> j1mc: that is the goal, yes.  I should probably build new xubuntu isos too
<dxdemetriou> cjwatson, I know that some times is small difference. I tried eryl with ubuntu and sabayon for example, and I saw is more optimized with i686. The better way is to optimize only the packages I want and not the whole system?
<j1mc> Mithrandir, thanks.  :)
<pitti> Mithrandir: oh, are you building another one, filling the remaining 25 MB? or is this 'the' image now?
<Mithrandir> pitti: the current i386 and amd64 ones are the final ones, barring anybody finding blockers.
<fabbione> Mithrandir: are you also publishing -server ?
<Mithrandir> fabbione: if somebody tests it, sure
<fabbione> Mithrandir: i can test i386 and sparc when i am back. i need a break now
<Mithrandir> fabbione: sure.  ISOs building.
<fabbione> Mithrandir: thanks
<pitti> Mithrandir: alright, let's sort out translations for the beta, when we'll actually have some ;)
<Mithrandir> pitti: yup.
<pitti> argh, fresh install -> no vmware any more
<asac> fabbione: you are translation master?
<pitti> asac: carlos: Rosetta, me: langpacks, actual translations: one team per language
<asac> I need to update ffox and tbird locales (because of official branding) at some point; should I coordinate with someone (you) or just push up after freeze?
<tepsipakki> are the images publicly available somewhere? a friend of mine would like to install amd64
<pitti> asac: updating mozilla-firefox-locale-all for 2.0.0.2 is on my TODO list ATM, but I'm happy to hand that over to you
<carlos> pitti: what's the time limit to see whether we could start using Rosetta to prepare firefox language packs ?
<pitti> carlos: hm, beta, I'd say
<carlos> pitti: we are finishing native support for it
<asac> yes ... would like to use such simple packages to train people of mozilla team a bit on packaging ... maybe not for this round, but definitly in future.
<pitti> oh, great!
<pitti> asac: most complicated part is to rename the upstream files, like de.xpi -> de_DE.xpi
<asac> yeah :)
<pitti> asac: or, alternatively, go through the pain of renaming the packages again
<pitti> and provide transitional packages with all the C/R/P goo
<carlos> pitti: are you renaming de.xpi to de_DE.xpi???
<pitti> carlos: for hysterical raisins
<asac> pitti: will not change such things for feisty i guess
<pitti> carlos: so far I did that to avoid renaming the packages; it doesn't make much difference usually
<asac> ok .. i am out again ... cu  @meeting.
<carlos> pitti: well, that prevents that es_MX people start translating because there is an es_ES one, for instance (yeah, I know there is already es_ES and es_AR)
<carlos> which is madness
<carlos> pitti: I hope you do the package rename at some point ...
<pitti> carlos: but es_ES/AR/MX are the very reason why we need the per-country ones in the first place?
<carlos> pitti: the thing is that just es.xpi would work
<pitti> carlos: yes, we probably have to; and I really hope that upstream does not change them *yet again*
<pitti> carlos: if you have ex_MX installed and are in es_ES, it'll still be used
<pitti> (if you don't have es_ES, that is)
<carlos> as far as I know, es_AR started because the original one was es_ES and was not well maintained
<carlos> wow, so they had to 'hack' the way they get language packs to 'find something es_*' ?
<carlos> pitti: my point is in the lose efforts maintaining translations for es_ES, es_MX, es_AR, etc.. when a single 'es' would be enough
<pitti> Mithrandir: amd64/desktop tests running (two in parallel, should go pretty fast)
<carlos> not that the application is not able to cope with them
<pitti> carlos: right
<Mithrandir> pitti: cheers
<pitti> carlos: but Rosetta needs to duplicate the common strings to es_AR/es_ES.xpi anyway, right?
<carlos> no, if we just import 'es'
<Mithrandir> Riddell: ISOs for you; tracker bugs filed.
<pitti> Mithrandir: will you create another bug for Ubuntu amd64/desktop?
<Mithrandir> pitti: that's #88944 already
<pitti> ah, it appears now
<tepsipakki> Mithrandir: where can I grab an amd64-image to test?
<Riddell> Mithrandir: ack
<Mithrandir> tepsipakki: cdimage.ubuntu.com
<Mithrandir> (/daily or /daily-live)
<tepsipakki> oh
<ogra_> edubuntu server and add-on amd64 are fine here
<ogra_> including X :)
<Mithrandir> ogra_: good.  Tracker bugs are updated too?
<tepsipakki> Mithrandir: thanks, the daily-timestamps seemed "old" ;)
<ogra_> not yet
<ogra_> i'm doing them all together if i'm back on my normal work system
<Mithrandir> tepsipakki: daily is from yesterday ; daily-live is from this morning and about an hour ago.
<Mithrandir> ogra_: ok
<bddebian> Heya
<bddebian> doko: Sorry, I would have done the UVFe.  I wasn't clear on whether you wanted me to do that or not
<pitti> Mithrandir: oh, btw, bug 88944 is all good
<Ubugtu> Malone bug 88944 in ubuntu-iso-tests "20070301.1: ubuntu amd64 desktop" [Undecided,In progress]  https://launchpad.net/bugs/88944
<Mithrandir> pitti: great, thanks.
<ogra_> argh
<ogra_> since when does NM nopt recpect static interfaces anymore ? 
<ogra_> it just killed the interface my dhcp, nfs and tftp server for ltsp are running when i loaded the broadcom driver for the wlan
<ogra_> thats extremly evil ...
<pitti> ogra_: right, just noticed that two hours ago when reinstalling my desktop
<ogra_> can we avoid such behavior again ? 
<seb128> I find it really handy to be able to pick my static interface for nm when trying the desktop CD some hours ago
<seb128> s/find/found
<ogra_> seb128, i didnt pick anything
<ogra_> i loaded a module
<ogra_> while bein in a thin client session ...
<ogra_> the session then locked up .... hard ...
<seb128> ogra_: that's a bug, doesn't mean it should ignore the static interface
<ogra_> well, it recognizes the interface i have up during boot #time ...
<ogra_> it shouldnt just shut it down ... in no case
<ogra_> even if i click on it it shouldnt ... what the admin configured in /etc/network/interfaces shouldnt be overridden
<ogra_> thats a security issue imho
<ogra> ah, thats better
<dxdemetriou> the apt-build is safe to rebuild my whole system or it can broke it? I just want to try to see how can be optimized
<psusi> I don't know if I'm being dense or what, but I can not for the live of me, identify where the upstream source is for the udev package by inspecting the source package readmes and such
<psusi> where's this thing come from?
<kylem> http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
<kylem> it should really be in debian/copyright. oh well.
<psusi> that's what I thought, but it isn't ;)
<psusi> thanks though
<psusi> cause I was getting really confused becayse in the FAQ it refers you to a mailing list on sourceforge, only the project appears to have nothing to do with udev
<seb128> Mithrandir: new amd64 desktop CD and installation works fine for me
<psusi> or rather, was the old pre udev hotplug system...
<ogra_> mvo_, somehow gai should learn to handle the moiunting and unmounting more properly ....
<ogra_> i end up with a bunch of windows after some action ... would probably be good if it set the gcopnf key for gnome-volumemanager to not mount the CD over and over
<mvo_> ogra_: yes, I noticed that too
<fabbione> asac: no sorry
<fabbione> Mithrandir: are server iso published?
<Trewas> should I file a bug for this (latest i386 alternate daily) and if so with what details, http://img453.imageshack.us/img453/91/partitionerqj1.png
<Trewas> I honestly don't know what to make of those partitioner choices, and if it is now generally broken or just for this computer...
<cjwatson> Trewas: I'd like you to try to reproduce that for me with a bit more debugging, and then file a bug
<cjwatson> Trewas: at the first boot screen, press F6 to edit the kernel boot parameters line, and add " DEBCONF_DEBUG=5" to the end of the boot parameters (without the quotes)
<cjwatson> Trewas: then reproduce the problem
<cjwatson> Trewas: when you get to the screen you posted, back up until you get to the installer's main menu (it'll have "Partition disks" on it)
<cjwatson> Trewas: select "Save debug logs" from there, and use one of the methods it'll offer you to extract the syslog and partman log files
<cjwatson> Trewas: then file a bug report on partman-auto and attach those logs to it, and tell me the bug number
<Trewas> cjwatson: hmm, it doesn't want to let me go back from that screen, "No root file system. Please correct this from the partitioning menu. <go back> <continue>", and both choices go back to the same screen
<Trewas> cjwatson: well the logs seem to be in /var/log/, I guess they will do
<cjwatson> Trewas: right, those'll do great
<cjwatson> Trewas: if you have an ssh server on another system, you can 'anna-install openssh-client-udeb' from tty2 and then you'll have scp to copy them out
<tepsipakki> cjwatson: a friend of mine is having some problems with ubiquity hanging in the "migrate settings" phase
<tepsipakki> with amd64 current daily
<cjwatson> the partitioning thing is also bug 87275, FWIW, but a DEBCONF_DEBUG=5 syslog would still help
<Ubugtu> Malone bug 87275 in partman-auto "feisty fawn herd 4 server loops when partitioning disks attempted" [Undecided,Needs info]  https://launchpad.net/bugs/87275
<cjwatson> tepsipakki: run with 'ubiquity --debug' and attach the resulting /var/log/syslog, /var/log/installer/debug, /var/log/partman to a bug
<cjwatson> tepsipakki: it's certainly possible - the migration stuff is new and this is the sort of thing we need to solve early
<tepsipakki> cjwatson: thanks, I'll tell him
<doko> infinity: are the results from the rebuild tests somewhere available?
<Trewas> cjwatson: bug filed, bug 89004
<Ubugtu> Malone bug 89004 in partman-auto "Wonky partitioner choices in alternate cd" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89004
<cjwatson> Trewas: thanks, that should be enough
<cjwatson> deeply, deeply weird though
<cjwatson> it's like the cdebconf confmodule just decided not to bother setting RET
<ogra_> cjwatson, hmm, none of the additional apps i had in -live were installed by ubiquity, do i need to duplicate them in ship-live ?
<cjwatson> ogra_: no, that won't work, you need to talk to me
<ogra_> ok
<cjwatson> ogra_: if you want them installed on the target system, why not just put them in desktop?
<cjwatson> that's the purpose of desktop
<ogra_> because then they are on the server cd again
<ogra_> i dont want them there, but on the liveCd and in the ubiquity installs
<cjwatson> why shouldn't they be on the server (i.e. what everyone else calls alternate install) CD?
<cjwatson> the alternate install and desktop CDs should generally install the same things
<ogra_> because they were moved to the add-on CD
<cjwatson> blink
<ogra_> all big apps moved 
<cjwatson> surely you'll run out of space on the desktop CD too if you try to put them there
<ogra_> like the spec says, gcompris and kdeedu are on the add-on CD
<cjwatson> yes, server should be equivalent to desktop in terms of package selection though
<ogra_> it cant 
<ogra_> not if stuff moved to the add-on CD
<cjwatson> the add-on CD should be usable with a desktop install in just the same way as with the server CD
<ogra_> right
<cjwatson> so stuff from the add-on CD doesn't need to be on the desktop CD
<cjwatson> just use the add-on CD
<ogra_> but the server install is completely different to a ubiquitiy workstation install
<ogra_> thats not what i wqant
<ogra_> the user experience of the liveCD shouldnt change 
<cjwatson> well, five packages different
<ogra_> that was the plan
<cjwatson> and the LTSP client
<cjwatson> ogra_: OK, if you really want this (and I'm not at all sure it's a good idea) then you need to talk to infinity and get him to make the livefs build script install the contents of a further seed (in addition to desktop) before creating manifest-desktop
<ogra_> currently its rather like 30 packages difference 
<cjwatson> there is no way to do what you want in the current seed structure, so it'll need seed changes
<ogra_> the apps are on the live desktop just fine just ubiquity doesnt install them
<cjwatson> code changes I mean
<cjwatson> ogra_: yes, I wrote the code which removes them; I'm familiar with what it does
<cjwatson> ubiquity intentionally removes everything which is in live but not desktop
<cjwatson> since otherwise you would end up with ubiquity installed on the target system
<ogra_> ah, right i remember
<tepsipakki> cjwatson: should I file the bug against ubiquity or m-a?
<Riddell> cjwatson, Mithrandir: there's a crash in the new partitioner in KDE Ubiquity, I've committed the fix to trunk, can I upload?
<cjwatson> Riddell: have you bumped the version in configure.ac?
<cjwatson> tepsipakki: probably ubiquity
<tepsipakki> cjwatson: ok, will do
<Riddell> cjwatson: nope, can do
<cjwatson> Riddell: bump that and run ./autogen.sh, assuming you have the autotools installed
<cjwatson> Riddell: check the diff - it should be small and just version changes
<cjwatson> Riddell: commit that, then upload
<cjwatson> Riddell: could you set yourself up with CIA too?
<Riddell> cjwatson: I thought I had, let me check
<cjwatson> your commit didn't appear on #ubuntu-installer
<zoli2k> Hi, can anybody help me with squashfs? I want to build a small usb distro based on ubuntu.
<sabdfl> zoli2k: BenC is likely the best starting point
<gilligan_> I have a question regarding ubuntu kernel patches -- if the question is inappropriate to ask in this channel then just tell me ..     in  /include/linux/fs.h : void (*umount_begin) (struct vfsmount *, int);  <--- the vanilla kernel (2.6.17.11) does not have the second, int argument. I am trying to build a kernel module (a fistgen filesystem) which fails because of this difference
<zoli2k> Will under edgy work an /etc/fstab containing: "/dev/loop0  /  squashfs    ro,defaults       0 0"
<gilligan_> so can anyone tell me what the change in umount_begin is about and why there is an extra argument ?
<BenC> zoli2k: Probably best to use an initramfs to handle find the filesystem, like out livecd does
<BenC> s/out/our/
<BenC> gilligan_: check in fs/ for usages. I think for most cases it's just 0
<cjwatson> Trewas: it's almost like two copies of partman are running simultaneously
<cjwatson> one of which has gone nuts
<zoli2k> BenC: initramfs will allow to use the default edgy kernel?
<BenC> zoli2k: Yep
<zoli2k> Benc: thx
<BenC> zoli2k: np, good luck
<gilligan_> BenC, well you seem to be right.. seems like it is mostly being invoked with 0 as argument for the second argument (int flags)
<BenC> gilligan_: I think it was done to facilitate one or two special cases
<gilligan_> BenC, I am really anything but an expert in that regard, but I am surprised to see ubuntu kernel patches at that level. Then again I didn't really care about that before
<Riddell> cjwatson, Mithrandir: new ubiquity uploaded, can you let it through?
<BenC> gilligan_: It's caused by one of two things, either a security patch required us to backport that portion of code, or a driver/patch we need required us to do it
<BenC> gilligan_: It was definitely from upstream, and probably from 2.6.18, so expect to see it in newer kernels anyway
<cjwatson> Mithrandir: bug 89004 is a pretty nasty autopartititioning problem, and seems to involve an infinite loop somewhere - still tracking it down
<Ubugtu> Malone bug 89004 in partman-auto "Wonky partitioner choices in alternate cd" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89004
<pitti> BenC: btw, I just tried readlink /proc/pid/exe when deleting the binary while the process is still running; I just get the normal path with ' (deleted)' appended; I wonder where those strange null bytes and gibberish in between came from
<Riddell> cjwatson: kubuntu i386 desktop CD doesn't seem to have any winfoss on it
<gilligan_> BenC, I see.. oh and I just realized that the it's not only the first argument really..  vanilla: (struct super_block_t*) / ubuntu: (struct vfsmount*,int)   --- guess I will have to install a vanilla kernel in a VM to work on the code. In any way: thanks for your information
<cjwatson> Trewas: would you mind following that procedure through again, but this time, when the installer is waiting for you to enter a hostname, switch to tty2, 'nano /bin/partman' and put 'set -x' on the second line
<cjwatson> Trewas: then return to tty1 and continue
<cjwatson> Trewas: from that, I need /var/log/syslog
<pitti> BenC: it seems that I can reasonably assume that /proc/pid/exe will point to a nonexisting binary after the original binary got unlinked; do you have an idea whether there are any further assertions? (path before the first null byte or space is original binary, etc.)
<BenC> gilligan_: np, ubuntu kernel team is in #ubuntu-kernel if you need anything further
<BenC> pitti: No, I've been meaning to check on that code to see how it comes up with the exe name in that case
<pitti> BenC: ah; no hurry
<BenC>                 memcpy(end, " (deleted)", 10);
<Trewas> cjwatson: sure, I'll try that
<BenC> I see that much :)
<pitti> BenC: well, that's something handy already :) 
<BenC> pitti: Basically it truncates the exe buffer by 10 and inserts that string at the end
<BenC> pitti: It doesn't seem to check the actual path len, just the buffer than the pathname is stored in
<BenC> *that
<BenC> pitti: Hence why it gets garbage I guess
<pitti> BenC: I see; thanks for checking!
<pitti> BenC: so I could just try and check whether the part before the first space or NUL is an existing binary, and if so, then it's an upgrade; if it doesn't exist, I simply ignore it
<cjwatson> Trewas: thanks
* cjwatson -> dinner
<BenC> pitti: But it also means that the actual path can be truncated (e.g. "/usr/bin/share/d (deleted)")
<pitti> BenC: right, then we are screwed; but at least we can hope to catch a good deal of cases where it's not truncated
<BenC> pitti: And if the full path is < 10 (not likely, but...) then it wont prepend " (deleted)" at all
<BenC> pitti: Ok, let me know if you need more info
<pitti> /bin/bash :)
<pitti> /bin/ls, etc
<BenC> but the buffer has to be less than 10, so I'm not sure if that's possible
<pitti> BenC: oh, one more question; does the %e macro (respective the corresponding CORE_ env var) has the very same modification, or is it the original exe name?
<BenC> pitti: hmm...no idea
<BenC> They don't appear to come from the same thing
* pitti just tries
<heno> Riddell: lacking winfoss > that could explain why Mithrandir is seeing so much extra space as well
<heno> has it fallen off the ubuntu images too?
<pitti> BenC: ah, too bad, CORE_EXECUTABLE aka %e only has the basename, no dir
<pitti> well, but that should do
<Riddell> heno: I don't konw
<Trewas> cjwatson: new syslog attached to the bug
<heavensrevenge> i am just wondering, has fiesty entered a freeze yet??
<giftnudel> have a look at the topic
<Adri2000> UpstreamVersionFreeze and FeatureFreeze, yes.
<giftnudel> there is a wiki page with the dates though
<mdke> specifically, FeistyReleaseSchedule
<Burgwork> mdke: whiprush was looking for the Ubuntu moin theme
<heavensrevenge> so as of herd 5 it will be frozen?
<mdke> Burgwork: https://wiki.ubuntu.com/LoCoTemplates
<Burgwork> mdke: ah
<heavensrevenge> srry 4 askin such noobish q's, ive decided to jump ship to ubuntu from xp
<mdke> we should rename that page really
<mdke> I don't understand why it is supposed to be loco specific
<heavensrevenge> and im wondering since i think it would be safe as long as ther main install base is frozen, then only patches are commited
<heavensrevenge> since i wouldnt want to break my install right away:P
<Adri2000> feisty is not for you
<mrevell> heno: ping
<mdke> Burgwork: alright, moved to "Templates"
<Burgwork> rock
<Burgwork> mdke: whiprush says thanks
<LaserJock> Burgwork: say hello to him for me
<Burgwork> done
<cjwatson> heavensrevenge: we're still upgrading the X system (i.e. the bottom graphics layer) so I'm not sure we could honestly say that our main install base is frozen yet :-)
<cjwatson> heavensrevenge: of our supported releases, 6.06 is solid while 6.10 is a bit more leading-edge/risky; feisty's intended for developers and experienced users who are happy digging themselves out of holes at this point
<heno> mrevell: hi
<mrevell> heno: Hey - I'm planning a weekly Launchpad users meeting, as the user panel was going to be too exclusive, I think.
<mrevell> heno: I'm thinking of each Wednesday
<mrevell> heno: so we can discuss isues raised in the thurs LP meeting
<heno> the day before they are raised!
<heno> or 6 days after
<mrevell> heno: Sorry :) I meant so that issues raised by users could be discussed in the LP team meeting
<heno> ah, that makes even more sense :)
<heno> mrevell: sounds good. what time?
<mrevell> heno: Well, that's the problem. I was thinking of 17:00 for purely selfish reasons (we record LugRadio every other Wednesday evening)
<mrevell> heno: But that's rubbish for .au and .nz
<heno> mrevell: that's always going to be a problem
<heno> many meetings have rotating times for that reason
<mrevell> heno: Yeah, I was thinking that's what we'd have to do.
<mrevell> heno: I'll announce the time when I've settled on one for the first meeting.
<heno> mrevell: cool. speaking of meetings, there is a distro one in 8
<heno> mrevell: did you catch the conclusion on the LP performance discussion?
<mrevell> heno: I'd love to join in but I need to finish work soon :)
<mrevell> heno: Erm, no I'm not sure that I did.
<mrevell> heno: after the meeting?
<heno> mrevell: yeah, I think I got most of it. They may inline CSS and JS
<Fujitsu> Didn't the conversation sort of disintegrate completely into emptiness?
<mrevell> heno: Cool.
<heno> or at least do more testing
<mrevell> Fujitsu: If there's more than needs to be said, come and join us in the Launchpad users meeting :)
<mrevell> Fujitsu: Time and date TBA
<mrevell> :)
<mrevell> I'll announce it on the Fridge
<ajmitch> mrevell: a users meeting now?
<mrevell> ajmitch: sorry, no. I'm planning one for Wednesday
<mrevell> ajmitch: provisionally 17:00
<mrevell> UTC
<ajmitch> not now, obviously, but the fact that you're having one
<ajmitch> ah, an annoying time of day
<mrevell> ajmitch: It'll be at different times, to suit different timezones.
<mrevell> ajmitch: what's your time zone?
<ajmitch> NZDT (UTC+13)
<mrevell> ajmitch: ah, yes, not a good time for you.
<Fujitsu> A worse time for me :P
<mrevell> ajmitch: If we make the next one 21:00 UTC, that works out better.
<Riddell> Mithrandir: can you let ubuntu 1.3.24 through?
<cjwatson> YM ubiquity?
<Mithrandir> Riddell: uh.  Do you mean ubiquity or something?  I don't think you have a package called ubuntu? :-)
<Riddell> err, yes
<Riddell> clearly I shouldn't have peach wine before a meeting
<Mithrandir> Riddell: does that mean you want it for the kubuntu images?  I was planning on making the ones now final.
<Riddell> Mithrandir: yes it's needed, it crashes on almost all partitioning operations
<Mithrandir> Riddell: ugh.
<Mithrandir> cjwatson: only kubuntu or ubuntu too?
<cjwatson> it's only the KDE frontend
<Mithrandir> ok
<Mithrandir> cjwatson: about 89004, it looks weird, but do you think it's a blocker?
<cjwatson> Mithrandir: I wish I knew, TBH
<cjwatson> Mar  1 20:24:50 main-menu[3246] : (process:15502): /lib/partman/auto.d/10initial_auto: 117:  
<cjwatson> Mar  1 20:24:50 main-menu[3246] : (process:15502): /lib/partman/automatically_partition/question: Permission denied 
<cjwatson> that's super-weird
<cjwatson> I'll check right after the meeting
<Mithrandir> ok
<Mithrandir> cjwatson: the latest console-setup upload seems to contain a .svn directory.
<cjwatson> gar
<cjwatson> oh, yeah
<Mithrandir> or rather, lots of .svn directories.
<cjwatson> Mithrandir: it does that because the current Debian version did and I didn't want to create a vast diff.
<Mithrandir> ahkay.
<Mithrandir> Riddell: anyway; new ubiquity accepted
<Riddell> thanks
<giangy> 'evening
<Mithrandir> Riddell: your alternates are ok, right?
<Mithrandir> so I'll just reject the desktop bugs.
<Riddell> Mithrandir: both good yes
<Riddell> sure
<cjwatson> ogra: ok, would you be willing to take that up and either fix it or deliver it back to me with a clearer picture of what's going wrong?
<cjwatson> (63175)
<ogra> yep
<j1mc> Mithrandir: do you think there will be a xubuntu herd 5?
<Mithrandir> j1mc: if you guys test and are happy with the current images, sure.
<ogra> is anyone testing them ?
<Mithrandir> j1mc: if you need something updated or respins, tell me.
<Mithrandir> j1mc: I meant to tell you earlier, but you weren't here.
<j1mc> yes.  afaik, i think we're ok.  
<j1mc> ogra: check:  https://wiki.ubuntu.com/Xubuntu/Testing/Current
<j1mc> our testing leader is in the hospital, so i've had to fill in.
<j1mc> i think i'll be maintaining it going forward.  we just need more AMD64 and PPC testers.  i'm working on it.
<j1mc> Mithrandir: thanks.
<Mithrandir> j1mc: ppc is a port anyway, I'm not sure xubuntu has ports build?
<cjwatson> ogra: if the problem is that the system clock resets to zero on every boot, then there's nothing we can do about it and the bug should be rejected
<ogra> j1mc, well, i checked the buglist https://launchpad.net/ubuntu-iso-tests/+bugs 
<cjwatson> ogra: but it might be something else
<ogra> cjwatson, as i said, i saw it on all herd releases until today
<ogra> so for me something has changed apparently
<cjwatson> ogra: right, but I'm wondering if your system suffers from this problem anyway
<j1mc> ogra: yes, we need to update where we report info to.  i'll get that changed for next herd.
<ogra> but i will pull a herd 4 and compare
<cjwatson> ogra: this is something you should be able to check by looking at the date before ntpdate runs
<ogra> cjwatson, usually i dont have probs with my clock on this machine
<cjwatson> or alternatively, ntpdate (or is it just ntp now?) could be doing something mad
<cjwatson> ogra: yeah, but remember the installer doesn't use ntpdate
<cjwatson> ogra: it could be that it's being fixed up for you on every boot
<ogra> well, givenm that i dont do networked installs usually ....
<cjwatson> fsck runs before ntpdate
<cjwatson> hmm, ok
<cjwatson> anyway, seems like something to check
<ogra> yep
<elmo> cjwatson: eh, why can't we do anything about it?
<ogra> i'll first try to reproduce it with herd4 and then check the differences in clock handling
<elmo> cjwatson: the whole time I was a powerbook user, I wished we would set the date to something completely incorrect, but at least sane
<elmo> (due to the 1904 crap)
<elmo> I mean we know the date is at least 2007-03-01, right? ;-)
<Spads> release date
<ogra> ++
<ogra> i had the same probs with my ibook for a long time
<ogra> and i think gnome still has probs with 1904
<cjwatson> elmo: I'm not sure that would obviously help with fsck
<cjwatson> elmo: suppose it might
<cjwatson> elmo: there's an adjtime thing in base-files which Santiago updates every so often
<cjwatson> I always wondered if that was meant to be for the sort of thing you mention
<Fujitsu> Any buildd admins around that could look at drscheme? It build on multiple i386 machines I have, but fails on the i386 and amd64 buildds (powerpc and sparc built fine).
<cjwatson> base-files updates it on fresh install, and something else updates it from time to time
<Mithrandir> Fujitsu: looking.
<Riddell> mvo: kubuntu upgrader tester had a bug https://launchpad.net/bugs/89049
<Ubugtu> Malone bug 89049 in update-manager "Kubuntu upgrade edgy -> feisty crash" [Undecided,Unconfirmed]  
<Fujitsu> Thanks Mithrandir.
<cjwatson> elmo: I think /etc/init.d/hwclock is *meant* to do this, but maybe doesn't
<mvo> Riddell: oh?
<ogra> cjwatson, the last part of your sentence is worrying
<cjwatson> could be it doesn't spot the 1904 case
<cjwatson> ogra: ?
<ogra> " and something else updates it from time to time"
<mvo> Riddell: thanks, I seem to remember that I have fixed that, but I will have anohter look. thanks
<cjwatson> ogra: it's hwclock. I just hadn't found out what it was yet at that point
<joumetal> Just confirmed bug 88990 and just asking someone to assign it.
<Ubugtu> Malone bug 88990 in firefox "evolution breaks with libnss update" [High,Confirmed]  https://launchpad.net/bugs/88990
<ogra> ah, ok
<cjwatson> joumetal: for many teams it is not standard procedure to assign bugs. You shouldn't worry about whether a bug is assigned or not
<Mithrandir> pitti: does the build failure for drscheme/i386 look like anything the binary package mangler could be responsible for?
<pitti> Mithrandir: I tested it locally on amd64, and it just worked
<pitti> Mithrandir: and it built on sparc/ppc as well
<pitti> the buildd failure didn't really look specific to ddebs, no idea :/
<ogra> heno, is there any howto for the winfoss stuff ? great to have a tgz, but i have no idea what to do with it now :)
<cjwatson> pitti: could you look at bug 88990? bug in the dapper firefox security update
<Ubugtu> Malone bug 88990 in firefox "evolution breaks with libnss update" [High,Confirmed]  https://launchpad.net/bugs/88990
<cjwatson> ogra: it gets dropped onto CDs by the cdimage tools and autoloads when you stick the CD into a Windows box
<joumetal> cjwatson ok thanks. There is discussion about it in #ubuntu-bugs
<ogra> cjwatson, so i only copy it to the right place ? 
<Mithrandir> dpkg-gencontrol seems to call du, but I really don't see why it complains about something not being a directory.
<cjwatson> ogra: no, I do
<ogra> ah, ok
<Mithrandir> Fujitsu: I'll just try a give-back.  I doubt it'll help, but it can't harm.
<cjwatson> ogra: you don't have to do anything except take its space usage on the desktop CD into account
<Fujitsu> Mithrandir, we can hope :) Thanks.
<ogra> cjwatson, add-on CD ;)
<cjwatson> ogra: errr
<cjwatson> ogra: normally it goes on the live-type CD because that's the best workflow to encourage Windows users in
<ogra> its supposed to go on the add-on CD ... i dont have any space on the desktop CD 
<cjwatson> meh
<cjwatson> ok, more grotty cdimage code then
<heno> ogra: just unpack and browse with firefox, or burn to a CD and start it in Windows
<ogra> henrik just wanted to fill the remaining space there
<doko> Mithrandir: estimate for archive unfreeze?
<Mithrandir> doko: tomorrow sometime.
<ogra> cjwatson, sorry for that, i thought it was clear :/
<Mithrandir> Riddell: can you do your own desktop rebuilds once ubiquity is through the hoops?
<ogra> Mithrandir, all images for edubuntu are good, bugs are updated, from my side we're release ready
<Mithrandir> ogra: excellent.
<cjwatson> Riddell: WinFOSS *is* on the Kubuntu desktop CD
<cjwatson> Riddell: for some reason the bits are in /kubuntu/ though, which may be confusing something?
<Riddell> cjwatson: it was certainly confusing windows, it couldn't find anything
<cjwatson> heno: could you get rid of the /kubuntu prefix on the files in the Kubuntu WinFOSS tarball
<cjwatson> ?
<Riddell> Mithrandir: sure
<cjwatson> yeah, autorun.inf is in /kubuntu/ rather than at the CD root, which won't work
<heno> cjwatson: sure. That's what I've generally used before, but if it helps
<cjwatson> heno: I mean inside the tarball
<cjwatson> heno: like /kubuntu/bin/chrome/...
<heno> cjwatson: oh, you mean I've included the dir, sorry
<cjwatson> yeah
<heno> got it
<heno> sure 2 sec
<mdke> heno: while on winfoss, did you see my email?
<heno> mdke: you mean from weeks ago about the win/ubuntu guide?
<mdke> heno: yes, I followed up this morning
<heno> mdke: I got the files, just need implementing
<heno> ah, ok, looking
<mdke> just a followup :)
<heno> mdke: I didn't get it actually. Mails with attachments tend to get caught in the spam filter these days :-/
<mdke> no attachment, but maybe someone went wrong my end then
<mdke> seems to have been sent, 8.31 am gmt
<heno> ok, perhaps CC henrik.omma@gmail ?
<doko> Mithrandir, seb128, pitti: I would like to upload some universe packages (rebuilds) now so that they can build overnight. could somebody of you process them?
<seb128> doko: will do
<mdke> heno: no worries. It just said - "have you done it yet?" You've answered that :)
<mdke> heno: also I wondered if you are interested in translations or not
<seb128> doko: universe is frozen?
<heno> mdke: not very. that content is still not translated unfortunately
<doko> seb128: well, I don't think so, but it must be processed manually?
<mdke> heno: that's fine - I vaguely recollected that, just wanted to check
<mdke> heno: lemme know how you get on, I can send you a final version after string freeze maybe
<seb128> doko: maybe better asking Mithrandir ;)
<seb128> doko: if he's not around I'll have a look
<heno> mdke: yep. I'll do some winfoss polish this weekend
<mdke> heno: cool!
* mdke goes to bed
<heno> cjwatson: done
<Fujitsu> seb128: universe isn't frozen, but needs to be manually let through. Soyuz can't freeze just one component.
<cjwatson> indeed
<cjwatson> I just bumped through the current obvious things
<Mithrandir> seb128: q  -Q unapproved info and q  -Q unapproved accept blah
<Mithrandir> seb128: feel free to accept anything with Component: universe/multiverse
<seb128> Mithrandir: ok, thank you
* doko should update the autobuild script ...
<sistpoty> seb128: could you let supertux-stable through new? It's basically just the much older but rock-solid version of supertux from unstable, where our supertux is the all new blingy version from experimental (and upstream kindly requested to also ship the stable version)
<seb128> sistpoty: is that source NEW? It's getting late, I'll probably let that for pitti tomorrow
<Fujitsu> It's not new as such.
<Fujitsu> It's more OLD.
<sistpoty> seb128: yes, source-new
<sistpoty> seb128: though it's not new as in new, since it's already in unstable ;)
<Fujitsu> And it was in Dapper/Edgy.
<cjwatson> Mithrandir: are you finished building CDs?
<cjwatson> Mithrandir: (as in, can I deploy cdimage changes, or should I wait?)
<Dragonhorse> Do anybody know when xorg 7.2 will be in edgy?
<cjwatson> Trewas: sorry, but would you be willing to go around one more (hopefully last) time?
<cjwatson> Trewas: this time, I need 'set -x' added on the second line of /lib/partman/auto.d/10initial_auto
<pochu> Dragonhorse: it's in feisty
<cjwatson> Trewas: that seems to be the actual script that's failing
<pochu> Dragonhorse: I think it won't be in edgy
<cjwatson> pochu is correct
<Dragonhorse> pochu: i see
<Dragonhorse> thanks
<pochu> Dragonhorse: np
<Dragonhorse> it is so because fiesty release is near?
<pochu> Dragonhorse: no. It's because it would mean breaking a lot of things
<cjwatson> no, we don't make that sort of enormous change to stable releases
<cjwatson> that's exactly the sort of thing that people use stable releases to avoid
<Dragonhorse> reasonable :)
<cjwatson> Trewas: (otherwise, same procedure as before)
<Dragonhorse> milli: thanks
<cjwatson> Trewas: I've tried tracing through the code, but I'm pulling my hair out trying to see why on earth it would (apparently) be trying to EXECUTE /lib/partman/automatically_partition/question (which isn't and shouldn't be executable), and believe me that's a lot of hair
<cjwatson> I haven't been able to reproduce the problem here
<cjwatson> it almost looks like something did alias cat='' or something equally mad
#ubuntu-devel 2007-03-02
<wolfeon> I've a question about regulations and policies about software included in Ubuntu
<wolfeon> Shouldn't an author's personal rants be taken out of software when available to the user?
<wolfeon> xchm for instance, the guy goes on the "use gpl, anyone else is ignorant" spreee
<wolfeon> would it be too bold of me to file a bug in launchpad so people may talk about it?
<cjwatson> we have no policy covering that, and we'd only take the risk of aggravating the upstream author by removing it if it were particularly egregious and offensive
<wolfeon> cjwatson: this is free software though. Isn't the point of Ubuntu to make the distrobution the best user oritented there is? the author's rant is nothing but flame bait/a troll
<Chipzz> wolfeon: and how does a troll change the quality of ubuntu?
<Chipzz> most people will never even read it
<wolfeon> Chipzz: seeing the rant for 2-5 seconds every time I open a chm is getting very irritating
<Chipzz> than use gnochm?
<Chipzz> s/than/then/
<wolfeon> hmm
<wolfeon> I think there was a reason for not using it
<Chipzz> I use it, and it opens my whole collection of ebooks :P
<mc44> remove the line from the source if you are that bothered. Thats the joy of free software
<wolfeon> mc44: I'm sure others would like to take out the rant from the binary distribution...
<mc44> if they were Im sure they have created a package for others like yourself to download
<wolfeon> oh, that is right..
<wolfeon> gnochm doesn't position everything correctly
<Chipzz> mc44: that doesn't take ubuntu updates into account though
<mc44> Chipzz: they could submit such a package to the motu. Im sure the delta from debian would be soooo worth it.
<Chipzz> wolfeon: iirc you can use gtkhtml and gecko in gnochm; maybe try the other rendering backend?
<wolfeon> mc44: rants aren't in my catagory of being friendly. How'd you like one of Linus's famous troll emails to splash on your screen every time you boot ubuntu?
<Chipzz> (I may be mistaken though)
<wolfeon> well one thing I do like about gnochm, it launches a browser when you click on an external link.. xchm trys rendering in the program.
<mjg59> If you're worried about packages in universe, #ubuntu-motu may be a better bet
<wolfeon> hmm, oh.. yes..
<wolfeon> mc44: thank you for clue batting me
<mc44> wolfeon: im sure you mean mjg59. But anyway :)
<wolfeon> mc44: lazy tabber me
<Fujitsu> doko: Shouldn't some of those rebuilds have been build1, not ubuntu1?
<AndrewB> Guys, why would a package be in the repo for 6.10 but not 6.06? For instance.. ajaxterm is there for 6.10 and not 6.06, is it that nobody has packaged it up for a 6.06 system or any reason?
<Lathiat_> it was likely only added in 6.10.
<AndrewB> but 6.06 is LTS so would it not be sane to add to 6.06?
<Lathiat_> no, nothing is added to releases post release
<ajmitch> not particularly, and it's in universe also
<Lathiat_> about the only exception is the -backports archives
<Lathiat_> and AFAIK thats just newer versions and not new packages
<ajmitch> being LTS means that it doesn't get all this new stuff thrown into it
<AndrewB> Ahh that makes sense..
<AndrewB> it is just maintained.. what packages are there..
<Lathiat_> correct
* AndrewB hits head of desk. I should and did know that..
<AndrewB> I am doing some wiki pages and realised that it only worked on 6.10.. and that 6.06 didn't work. What should happen there.. do I just leave as is.. or go find out how to make 6.06 work with it?
<_ion> Or upgrade.
<AndrewB> _ion: personally I do have 6.10. It is for the others that read said documentation.
<AndrewB> _ion: possibly that means leave documents as is.
<LaserJock> AndrewB: is this on the ubuntu wiki?
<AndrewB> Yes.
<AndrewB> LaserJock: yes.
<LaserJock> AndrewB: you might want to ask the doc team then
* |PrinCo| #projectoX la nueva sala en espaol para ayuda sobre temas relacionados con windows y linux ;) todo los temas/probemas sera solucionados ;);)
<bugnthecode> I'm not sure if this is the correct place to ask, but I was wondering what the opinions on "Beginning Linux Programming," (published by wrox) were?
<Hobbsee> bugnthecode: it's the middle of the night in europe, you're probably not going to get an answer.  maybe try #ubuntu-offtopic
<bugnthecode> Hobbsee: thanks
<jdong> bugnthecode: it's an interesting book to read... as is everything from wrox, about traditional Linux programming
<jdong> POSIX programming in general
<jdong> IIRC it starts with a good section about bash scripting
<jdong> then goes into POSIX-ish C programming
<Mithrandir> cjwatson: yes, I was done building CDs.
<pitti> Good morning
<Mithrandir> hiya Martin
<Hobbsee> hey pitti, Mithrandir :)
<LaserJock> hi pitti :-)
* pitti hugs Mithrandir, Hobbsee, and LaserJock 
<Hobbsee> :)
* Mithrandir kicks the sync script.
* pitti blinks
<Mithrandir> you can have positive version numbers less than zero.
<pitti> doko: hm, from your ldbl128 change I see a lot of -Xubuntu1 versions -- shouldn't these have been -Xbuild1 ones without Maintianer: change?
<Mithrandir> which is really, really crackful.
<Hobbsee> Mithrandir: better would be to fix it :P
<Fujitsu> pitti: I said that this morning...
<StevenK> Mithrandir: I think the sync script is smart enough to kick back...
<Mithrandir> Hobbsee: it took a while for me to work out wtf was happening.
* Fujitsu doesn't like the sound of having to look through all of them manually for Feisty+1.
<Hobbsee> heh, i'll bet!
<Mithrandir> [Nothing to update]  blktrace (0 [ubuntu]  >= 0~git-20061221162513-3 [debian] )
<Mithrandir> fun?
<Fujitsu> Hahah.
<StevenK> steven@liquified:~% dpkg --compare-versions 0 gt 0~git-20061221162513-3 && echo true
<StevenK> true
<StevenK> Which means dpkg is also on the same crack?
<Fujitsu> StevenK, that's the right comparison.
<Fujitsu> Going by the rules, the Debian version is less.
<StevenK> But it looks like the sync script is doing the same comparsion...
<Mithrandir> StevenK: it's correct, but it shouldn't assume that 0 is the lowest version possible.
<StevenK> Mithrandir: But what else is there?
<Fujitsu> Mithrandir: there is no lowest version possible.
<Fujitsu> Shouldn't it check if it actually exists?
<StevenK> What about the empty string?
<StevenK> I don't think Policy even mentions that.
<Fujitsu> That works.
<Fujitsu> Empty string is lower.
<Mithrandir> StevenK: ~ is less than an empty string
<Mithrandir> hmm
<StevenK> Mithrandir: Not according to dpkg.
<Mithrandir> weird:
<Mithrandir> : tfheen@thosu ~ > dpkg --compare-versions '~' lt "" && echo true
<Mithrandir> : tfheen@thosu ~ > dpkg --compare-versions '0~' lt "0" && echo true
<Mithrandir> true
<Fujitsu> ~ is greter than ''
<Mithrandir> that's arguably a bug.
<Fujitsu> Yes, that.
<StevenK> Actually, dpkg seems to just exit 1 with an empty string first.
<LaserJock> pitti: don't know if you saw but new edubuntu-docs packages is built and ready for MIR now, when you get a chance
<Fujitsu> Surely ~ should be less than '', anyway.
<pitti> LaserJock: ah, great; I saw mvo's ack, just upload
<Mithrandir> hah, the version number is buggy.
<Mithrandir> "The upstream_version may contain only alphanumerics[33]  and the characters . + - : (full stop, plus, hyphen, colon) and should start with a digit."
<Mithrandir> but policy doesn't talk about ~, so it's probably lagging implementation.
<Trewas> cjwatson: done (I was already sleeping when you asked)
<dholbach> good morning
<LaserJock> pitti: what did you mean by "just upload"?
<pitti> LaserJock: I mean, after a bug gets verification-done, you don't need another approval for the -updates upload
<LaserJock> pitti: it's a MIR not an SRU
<pitti> argh, yes; sorry, mixed that up
<LaserJock> np, I was just confused
<LaserJock> I was pretty sure you didn't want me to upload it to Main :-0
<pitti> :)
* pitti fanboys mh21 and bounces
<Riddell> pitti: what has he done this time?
<pitti> Riddell: oh, nothing code-wise, just coming here to #u-d :)
<Riddell> Mithrandir: ubiquity 1.3.24 only seems to have some of its .debs in the archive this morning :(
<Riddell> pitti: awooga
<Mithrandir> Riddell: gnr, ok
<Mithrandir> Riddell: investigating
<mh21> pitti: hanging out with the cool guys :-P
<pitti> urgh, 44 sync requests again?
<pitti> Mithrandir: ah, btw, are you done with syncing?
<Mithrandir> pitti: yes, given that the single sync I wanted to do failed due to a soyuz bug.
<Mithrandir> Riddell: seems like the binaries ended up in failed-to-move; reprocessed.
<pitti> Mithrandir: negative version numbers *tsk*
<Mithrandir> pitti: they're positive, they just happen to be less than zero.
<pitti> Mithrandir: hm, I guess that's only valid if you wiggle the empty string into an appropriate place of the rational numbers :)
<tepsipakki> Mithrandir: how about that nfs-utils sync I talked about a few weeks ago?
<pitti> tepsipakki: can do, if you requestsync a bug
<Mithrandir> pitti: it's a new upstream version.
<Mithrandir> tepsipakki: I haven't gotten around to looking at it yet, sorry.
<pitti> ah, NEEDSBLESSING then
<tepsipakki> pitti: right :)
<tepsipakki> it's 1.0.11, we have a git-version prior to that
<tepsipakki> besides it has a patch which makes root-access to work with kerberos
<Kagou> cjwatson: can we discuss about Bug #89069 ?
<Ubugtu> Malone bug 89069 in ubiquity "problem with time" [Medium,Unconfirmed]  https://launchpad.net/bugs/89069
<pitti> Mithrandir: hm, I guess at some point I need to learn the policy about backports, too, and do them; they seem to pile up
<Hobbsee> [20:32]  *** You set the channel topic to "Welcome to the Ubuntu Feisty Fawn support channel | Feisty is NOT stable, and not even close to usable | Feisty Herd 4 released: http://www.ubuntu.com/testing/herd4 | Please don't use Feisty if you need a working system or you can't afford to have a broken system | Please use #ubuntu to ask questions about Dapper or  Edgy. | Xorg 7.2 has been merged, Beryl/Compiz now work.  Herd 5 is not out yet, it
<Hobbsee> will be out 2 hours after the last person asked".
<Hobbsee> sigh.
<Hobbsee> now i can just point them to the darned topic.
<Riddell> Mithrandir: are those ubiquity .debs likely to appear soon do you think?
<Mithrandir> Riddell: about now, I believe
<Riddell> I'll keep pressing F5 :)
<Riddell> mvo: no new dist-upgrader tar?
<mvo> urgh, it went away again?!?
<mvo> Riddell:  Iwill do another upload
<cjwatson> Kagou: could be related to bug 63175; what do you want to discuss beyond what's in the bug? I hadn't actually read the bug yet until you mentioned it
<Ubugtu> Malone bug 63175 in e2fsprogs "Edgy Beta -- fsck on every (re)boot" [Medium,Confirmed]  https://launchpad.net/bugs/63175
<mvo> I get 403 for http://archive.ubuntu.com/ubuntu/pool/main/g/glibc/libc6-dev-i386_2.4-1ubuntu12.1_amd64.deb is that known?
<Kagou> cjwatson: when ubuntu first boot (after installation), i suspect that fsck/partition  is done before setting local time isn't it ?
<cjwatson> before it's guaranteed to be set, anyway
<cjwatson> I don't really think a fix for this ought to be ubiquity-specific
<Kagou> cjwatson: when ubiquity ask for localtime, does it set system time to local time ?
<Kagou> so that explain that when it create partition and format it it do it on local time instead of system time
<Mithrandir> fabbione: the ocfs2 one is fairly large, but if you've tested it and is happy with it, go ahead.
* Kagou is not sure to be explicite
<cjwatson> Kagou: not to my knowledge, no
<Kagou> cjwatson: so why on first boot, ubuntu says that my new partitions (made by ubiquity) have date in futur ?
<cjwatson> Kagou: I don't know. Stop grilling me about it 15 minutes after I've woken up
* Kagou offer coffee to cjwatson 
<cjwatson> if the partitions are created in UTC, then their creation time will appear an hour later once the clock is set to UTC+1
<cjwatson> so I can believe that that could do it, but I'm not willing to make up a fix for it on the spot - clock handling is hairy and you have to think about it carefully
<Riddell> yay, new ubiquity in /me builds CDs
<doko> pitti: hmm, bug in the script ... I'll note these packages ...
<pitti> doko: NB that my version did *not* create -buildX version
<pitti> s
<pitti> doko: next_version() vs. next_version_rebuild()
<pitti> doko: ok, that shouldn't have been necessary for the Maintainer: purposes, but I needed it for something else and left the function in
<pitti> mvo: may I nag you about bug 85394? it's March, we need to push this urgently
<Ubugtu> Malone bug 85394 in tzdata "New timezone data 2007b" [High,Fix committed]  https://launchpad.net/bugs/85394
<pitti> hey seb128
<mvo> pitti: oh, sorry. it didn't show up in my search because the task for feisty was closed :/
<pitti> mvo: NB that *all* SRUs should have a fixed feisty task :)
<mvo> pitti: quite a few do not :)
<mvo> pitti: but yeah, I agree 
<pitti> mvo: I usually don't accept those
<pitti> except for cases where the bug is only about an edgy-specific sru
<seb128> hi pitti
<mvo> pitti: I will do 85394 before lunch
<pitti> mvo: danke!
<mvo> pitti: de'rien
<mvo> Mithrandir: could you please accept update-manager? 
<seb128> are we rolling CD images again?
<StevenK> pitti: Do you want to accept my edgy SRU? :-)
<pitti> StevenK: cyrus? I just did
<StevenK> Oh nice, thanks!
<pitti> Riddell: bug 84717, patches are good now, I updated the bug
<Ubugtu> Malone bug 84717 in update-manager "SRU: updates necessary for Kubuntu Upgrade Tool in Edgy" [Undecided,Confirmed]  https://launchpad.net/bugs/84717
<Riddell> pitti: great, thanks
<Frost^> Good morning. I'd like to examine Ubuntu's boot flow. Can someone please tell me what is the first script which is ran when the system is started?
<seb128> Mithrandir: how is herd-5 CD testing going?
<cjwatson> Frost^: 'init' in the initramfs (typically /initrd.img or /boot/initrd.img); you'll find a copy of the initramfs init along with related scripts in /usr/share/initramfs-tools/init
<cjwatson> Frost^: the initramfs eventually chains to /sbin/init in the real system
<cjwatson> Frost^: which then (in edgy and later) does things based on job files in /etc/event.d/
<Frost^> cjwatson: Thank you, I'll have a look.
<MagnusR> Frost^: More about edgys new starting system can be found at http://upstart.ubuntu.com/
<pitti> Laser_away: edubuntu-docs approved
<Frost^> Thanks MagnusR, I've read about upstart a little already. I hope upstart being backward compatible will not complicate my understanding of it.
<MagnusR> Frost^: Jupp Upstart is backward compatible.
<pitti> cjwatson, Mithrandir: do you have any objection against me adding /usr/lib/debootstrap/{edgy,feisty}.fakechroot scripts to debootstrap proper? that seems much more useful to me than keeping them in apport (after h5 release, of course)
<Frost^> Thank you, this gives me plenty of information to start with.
<Keybuk> Frost^: mostly, "backwards compatible" just means that one of the upstart job is to run the old /etc/init.d/rc script
<Keybuk> upstart has a superset of the features that were provided by sysvinit through the /etc/inittab file, so it is able to perform the same actions
<Frost^> I see. By the way, will all packages use upstart in fiesty?
<cjwatson> pitti: is the fakechroot patch to debootstrap less horrible than it used to be?
<cjwatson> pitti: oh, it's already integrated
<pitti> cjwatson: you mean the difference of the normal vs. fakechroot scripts?
<cjwatson> pitti: sure, no problem then
<pitti> it's pretty tame
<Keybuk> Frost^: no
<pitti> cjwatson: ah, yes, the _fakechroot() functions are there; it's just adding the new release scripts
<cjwatson> ok
<Frost^> I see. Thanks. I'll start debugging some init scripts now :)
<Mithrandir> mvo: there's no point; we're not rolling new CDs.
<Mithrandir> seb128: I need to test i386 alternate, assuming that's good, we're just waiting for kubuntu.
<mvo> Mithrandir: the important point is that the dist-upgrader bit gets into the archive, it does not need to go onto the CD
<Mithrandir> mvo: hm, ok
<mvo> thanks
<seb128> Mithrandir: ok, good
* poningru wonders whats holding herd 5 back
<doko> Riddell: kde version tests ...
<Keybuk> <Mithrandir> seb128: I need to test i386 alternate, assuming that's good, we're just waiting for kubuntu.
<doko> make[1] : Entering directory `/build/buildd/konserve-0.10.3'
<doko> *** YOU'RE USING autoconf (GNU Autoconf) 2.61.
<doko> *** KDE requires autoconf 2.53 or newer
<Riddell> doko: probably quite a lot of packages affected by that, it's a simple enough patch to fix
<doko> Riddell: yeah, maybe, just seen that while rebuilding packages in universe, maybe point that out the kubuntu community (if they care)
<Riddell> doko: this is the archive rebuild test?
<doko> Riddell: no, rebuild for the ldbl128 changes on sparc and powerpc
<Keybuk> ... if the KDE community didn't abuse the autotools ...
<doko> pitti, I need a guinea pig for the OOo powerpc build, just in case you know one ... ;)
<doko> fabbione: same for sparc
<Riddell> Keybuk: how does KDE abuse autotools?
<Keybuk> Riddell: last time I looked, they had a hideous patched version of automake and libtool
<Keybuk> that may have changed since
<Riddell> it has, they got scrapped for CMake :)
<Keybuk> eww
<highvoltage> anyone happen to know why the default wallpaper is still called warty-final-ubuntu.png ? :)
<mvo> pitti: how can I test #85394
<seb128> bug #85394
<Ubugtu> Malone bug 85394 in tzdata "New timezone data 2007b" [High,Fix committed]  https://launchpad.net/bugs/85394
<seb128> mvo: probably use the timezone that need to be update, set a date after the time switch and look if you have the correct hour
<cjwatson> highvoltage: IIRC because changing the wallpaper name would require transitioning the default somehow ...
<cjwatson> (but ICBW)
<highvoltage> ah. pity they didn't make it an alternative called default-wallpaper.png :)
<doko> dholbach: you do have a powerpc machine as well, do you?
<dholbach> doko: yes, an old one
<doko> dholbach: so you compete with pitti ;)
<dholbach> doko: hm?
<dholbach> doko: I'm not sure I know what you're referring to :)
<doko> dholbach: two elderly people with old computers ;-p
<dholbach> pffffft :)
<Hobbsee> Mithrandir: ping?
<Mithrandir> Hobbsee: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
<Hobbsee> meh
<mvo> seb128: thanks, I just couldn't figure out, what exact date the swich happens
<Hobbsee> Mithrandir: are you here, with your archive admin hat on?
<seb128> Hobbsee: friday is pitti's day, or that's a freeze question?
<Hobbsee> seb128: i need 4 uploads accepted.  i'd forgotten that pitti could do it
<Mithrandir> Hobbsee: just universe stuff?  I'll do it.
<Hobbsee> Mithrandir: could you accept my uploads of konserve, kat, ksniffer and kalcul please?
<Hobbsee> they all fix the FTBFS, after doko's rebuild
* Hobbsee curses automake
<Hobbsee> yup, they're all universe
<Mithrandir> Hobbsee: yup, 'll do.
<Hobbsee> Mithrandir: thanks very much :)
<mantiena> hi all
<pitti> Hobbsee: back from lunch; still want me to do anything?
<Hobbsee> pitti: i think Mithrandir's handling it
<Hobbsee> oh $%^&
<StevenK> Hobbsee: ?
<mantiena> anybody knows, why there are no todays daily-live .iso at http://cdimage.ubuntu.com/daily-live/ ?
<cjwatson> mantiena: logs are at http://people.ubuntu.com/~cjwatson/cd-build-logs/; you should always check there before asking here
<mantiena> cjwatson: thanks
<cjwatson> but there *are* images there
<cjwatson> reload, or look harder. :-)
<mantiena> cjwatson: there are only yesterdays images,.. btw, there are some laptops, which doesn't boot  with any ubuntu version (including herd4) until I specify boot  parameter "noapic"
<seb128> mvo: http://en.wikipedia.org/wiki/Daylight_saving_time
<seb128> mvo: "Starting in 2007, most of the United States and Canada observe DST from the second Sunday in March "
<Hobbsee> Mithrandir: crap, i'm an idiot.
<mantiena> cjwatson: what data I should submit in bugreport ? only laptop model or some other data ?
* Hobbsee didnt actually fix kat or ksniffer.
<mvo> seb128: woah, thanks
* Hobbsee puts on the dunce cap, and goes and hides in the corner.
<mantiena> maybe lspci -n ?
<Mithrandir> Hobbsee: just upload again instead. :-)
* mvo hands seb128 the sru-verification team badge
<pitti> mvo: oh, btw, if you wonder because of the current SRU: that rule for the U.S. is already present in the current -updates version (2006p)
<Hobbsee> Mithrandir: i dont know hwo to fix them - they die in the middle of make.
<pitti> mvo: the new changes are a bit less prominent, but would still be nice to have
* Hobbsee took doko's word that they were all automake breakages, instead of actually checking the build logs.
<pitti> mvo: in general, I think we should always keep our stables up to date with the latest tz data, so this will be a recurring task
<doko> Hobbsee: I don't know if they break otherwise ...
<seb128> mvo: no thanks ;)
<mvo> pitti: right, I'm trying to test if the fix is working, but I'm struggeling right now. my understand is that if I move the date to Apr 2007 the time should change by 1h 
<Hobbsee> doko: two of them fail not due to autohell
* Hobbsee got suspicious when the one that she test built didnt have autohell as a build-dep
<pitti> mvo: please look at the attached diffs to find out the new rules and affected TZs. it does *not* affect U.S.
<pitti> mvo: btw, you know about zdump(1)?
<pitti> mvo: zdump -v -c 2005,2007 Europe/Berlin, for example
<mvo> pitti: no, I don't know about this. what time zone is affected by the dst change in the diff? austrialia/eucla ?
<cjwatson> mantiena: oh, during releases the cron jobs get turned off so there are no images for today. This is perfectly normal.
<pitti> mvo: Bahamas, and Pacific/Easter, for example
<mantiena> cjwatson: OK, I hope yestersays daily-live images will be almost identifical to herd5 ;)
<mvo> pitti: ok, thanks. I will test with that
<Mithrandir> mantiena: images will never be "almost identical" to published images, they'll be the same images, or rebuilds.
<Mithrandir> Hobbsee: ksniffer seems to build fine on i386 at least
<Hobbsee> Mithrandir: yes...
<Hobbsee> Mithrandir: it did before, that's no help :P
<Mithrandir> Hobbsee: why it blows up on ppc, I'm not sure..
* Hobbsee beats the hell out of the launchpad beta
<Hobbsee> stop rolling up those little boxes that i'm trying to click on!  gah!
<simira> ah... test herd5, yes...
<pitti> Hobbsee: folded portlets suck++
<Fujitsu> Mithrandir, can you please give back drscheme on amd64 again? i386 worked the second time, so third time lucky!
<Hobbsee> pitti: yup
<Fujitsu> pitti++
<mantiena> Mithrandir: I mean  not binary "identifical", but identifical behaviour, I just need to test Ubuntu bugs on some laptops
<cjwatson> mantiena: releases are always binary-identical to a daily build.
<mantiena> cjwatson: Thanks for info, could you tell me what data I should submit in bugreport about not starting Ubuntu  until I specify noapic ? only laptop model or some other data ?
<cjwatson> mantiena: no.
<cjwatson> mantiena: as in, you're asking me because I happened to be talking, not because I actually know anything about it, and that's not good behaviour
<mantiena> cjwatson: sorry, I though, that you are responsible for kernel bugs
<cjwatson> I'm not sure where you got that idea, but I'm not
<cjwatson> and have never been
<pitti> Mithrandir: is it ok or too confusing for you if we upload sources which are not h5 critical, but which we want to get out of our eyes?
<schwuk> When's herd 5 due out now?
<Hobbsee> schwuk: two hours after the last person asked, as you would have seen in #ubuntu+1's topic.
<pitti> Mithrandir: (I probably asked already, but the stanza 'all uploads must be approved' keeps making me doubt)
<Hobbsee> ah, you're not there.
<mantiena> cjwatson: few weeks ago you told me, that I should report a bug agains kernel, when I  asked,  thats why I though, that you are responsible for kernel ;)
<Mithrandir> pitti: no, that's fine.
<schwuk> Hobbsee: I am now :) thanks for the pointer
<Mithrandir> pitti: in general, I prefer people to stay off, but we're probably ok now anyway, so it's just a matter of getting stuff tested before we release.
<Mithrandir> Hobbsee: http://err.no/src/lp_expandportlets.user.js
<tepsipakki> how do I disable network-manager safely? It thinks I don't have network at all
<Fujitsu> Mithrandir, some GreaseMonkey script?
<Mithrandir> Fujitsu: yes.
<Mithrandir> hmm, that didn't work correctly here.  I wonder why
<Riddell> Mithrandir: kubuntu amd64 desktop CD doesn't load :(  "invalid or corrupt kernel image"
<Hobbsee> Mithrandir: nice, thanks.
<Mithrandir> I wonder why it doesn't work for me any more.
<Mithrandir> Riddell: ugh, sure the burn is good?
<Fujitsu> Mithrandir, doesn't work here either... Though I am using Epiphany, which is unlikely to help.
<Riddell> Mithrandir: done it on two CDs
<Mithrandir> Fujitsu: try grabbing it again
<Fujitsu> Mithrandir: That works a whole lot better :)
<Fujitsu> Very nice.
<Mithrandir> Hobbsee: ^^ you might want to grab it again
<Hobbsee> Mithrandir: the kubuntu cd?
<Mithrandir> Hobbsee: no, the user.js. :-)
<Hobbsee> ahh
<Mithrandir> if you want to have expanded portlets by default.
<Hobbsee> thankyou :)
<mantiena> Anyone could tell me what data I should supply in bugreport, when  onlyUbuntu text mode in HP dv6103 laptop fine until X triest to start and Ubuntu gets frozen iduring X startup (even CapsLock doesn't work). But when I use "noapic" boot parameter then such problem dissapears.
<mjg59> mantiena: Kernel, attach lspci, uname -a, dmesg and /proc/interrupts 
<mjg59> mantiena: Do dmesg and /proc/interrupts for both the noapic and normal cases
<Mithrandir> Riddell: but i386 is fine?
<Riddell> Mithrandir: yes
<Riddell> not sure what to do
<Mithrandir> Riddell: I'll download the amd64 image now and see if it works for me.   If it doesn't, we'll just release without it, sounds ok?
<Mithrandir> fsvo ok.
<mantiena> mjg59: thank you very much
* Hobbsee wonders what fsvo is.
<Riddell> Mithrandir: ok, thanks
* Hobbsee only has an i386 machine, btw
<Hobbsee> so i cant test, sorry :(
<Mithrandir> Hobbsee: you probably don't have 45Mbit either, so I'd be done testing before you anyway. ;-P
<j1mc> Mithrandir: haha  :)
<mjg59> Hobbsee: For some values of
<Mithrandir> j1mc: how's the xubuntu images?
<j1mc> i did an expert install last night, went just fine
<Hobbsee> mjg59: ahh
<Hobbsee> Mithrandir: heh.  quite possibly.
<j1mc> Mithrandir: I'm getting an AMD64 machine, and hopefully we'll get more xubuntu testers soon.  we're starting to get more
<j1mc> sorry i haven't had too many other architectures to report.
<Mithrandir> j1mc: ok.  My question is "are you images all good and should be released?"
<j1mc> yes
<j1mc> how are other *ubuntu's looking?
<Mithrandir> apart from a problem with kubuntu amd64 desktop, we look good.
<j1mc> what's going on there?
<Riddell> kernel doesn't load
<j1mc> ouch
<cjwatson> some hosage if you have NTFS filesystems too, but it's workaroundablee
<j1mc> cjwatson: you mean if people try to autoresize ntfs partitions, or they get hose just during a regular install?
<cjwatson> if you have an NTFS filesystem present, the autoresize calculation in the autopartitioner (even if you don't select autoresize) will confuse the partitioner horribly to the point where you have to reboot
<cjwatson> workaround is 'mv /usr/bin/ntfsresize /usr/bin/ntfsresize.real' before the autopartitioner starts
<tepsipakki> for the record, I just reinstalled (netboot) my work desktop with feisty and all is well :)
<tepsipakki> and found out how to disable NM
<j1mc> Mithrandir: I'm headed out of town today, and will be gone for the weekend.  . . .  Just letting you know that I won't be around.
<Mithrandir> j1mc: ok, thanks for your effort.
<j1mc> thank you.  :)
<mjg59> I just plugged in a zd1211, and it appeared in network manager. I clicked, and it connected.
<mjg59> IT'S THE FUTURE
<Mithrandir> mjg59: \o/
<_ion> In the future, zd1211 plugs in you.
<_ion> Humans are quite good energy sources, you know.
<j1mc> greets, pochu 
<pochu> heya j1mc :)
<pochu> j1mc: how are things going?
<j1mc> well, thanks.  no show-stoppers in xubuntu
<pochu> j1mc: :)
<Kagou> wich package/where do i search for X resolution detection on feisty live ?
<tepsipakki> Kagou: xresprobe I think
<pitti> doko: do you want libjaxp1.3-java-gcj in main?
<Kagou> tepsipakki: sure, but i'm searching wich/where is it called on live boot
<doko> pitti: yes, that should be sucked in by a new xerces2/xalan2 package, IIRC
<Kagou> is it casper/xorg...
<Mithrandir> Kagou: casper.
<Kagou> Mithrandir: ok, thanks
<pitti> doko: alright, done
<Mithrandir> it just calls dpkg-reconfigure xorg, though
<Kagou> Mithrandir: ah ok so it use postinst script of xorg
<Kagou> yes ! xdebconfigurator is called from casper but not installed on live
<Kagou> and for me only xdebconfigurator report good sync ranges for monitor
<Mithrandir> Kagou: then fix xresprobe; xdebconfigurator is in universe.
<Kagou> indeed Mithrandir . I will do my best to fix xresprobe
<pochu> tepsipakki: do u know when you will sync the video drivers?
<pochu> tepsipakki: it would be fine to have a new git checkout for the i810-modesetting, since it's just for testing, and the actual version is quite old
<pochu> Version: 1.6.5.git20061014.ac1-1ubuntu4
<pitti> doko: oh, you packaged wxwidgets 2.8?
<pitti> doko: there are several strange things in the debs
<Mithrandir> Riddell: seems to boot for me.
<Riddell> Mithrandir: curious.  I rsynced it and burned to a new media to make sure and still had the same problem
<pitti> doko: e. g.libwxbase2.8-dbg does not have anything in /usr/lib/debug; instead it has lots of file conflicts to libwxbase2.8-0, but doesn't C/R/P it
<doko> pitti: looking ... (the same in 2.6?)
<pitti> doko: I don't know about 2.6
<pitti> doko: I accepted the debs for now to avoid archive confusion, but this looks fix-worthy
<tepsipakki> pochu: I've merged all the drivers (37)
<tepsipakki> and updated where there were new versions
<geser> pochu: there is a new version of i810-modesetting in Debian experimental
<tepsipakki> pochu: debian is merging i810/i810-modesetting as 'intel' (same which fedora does)
<tepsipakki> in fact I didn't touch -modesetting
<tepsipakki> we'll see how soon they are uploaded
<Mithrandir> Riddell: isn't there supposed to be an "install" icon on the desktop?
<pitti> Mithrandir: it's the 'enter your credit card number to transfer 100 pounds to Riddel to install' input line
<Riddell> Mithrandir: certainly
<Riddell> Mithrandir: is ubiquity-frontend-kde installed?
<toodles> tepsipakki: Does that mean that i810/i810-modesetting will be available through a new package xserver-xorg-video-intel?
<StevenK> Mithrandir: Fixed kat uploaded. Accept at your leisure.
<Mithrandir> Riddell: there's one in the system menu, so yes.
<tepsipakki> toodles: probably there will be new versions of those before they are merged
<Mithrandir> Riddell: and it started ubiquity.
<toodles> tepsipakki: Nice!
<pitti> can .swf files be considered 'prefered format of modification'?
<Mithrandir> pitti: afaik, yes.
<pitti> Mithrandir: thanks
<Mithrandir> pitti: sorry; it's not
<Mithrandir> pitti: there should be a .fla file there
<pitti> Mithrandir: it was from vnc2swf, prerecorded desktop session snippets
<Mithrandir> pitti: hmm, then I'm not sure.
<pitti> Mithrandir: the tool doesn't create .fla files
<Mithrandir> pitti: ok, it creates .swf directly?
<pitti> Mithrandir: yes, it records VNC sessions and creates swf from them
<pitti> Mithrandir: and there are three demos in doc/
<pitti> Mithrandir: which would mean that there is no editor for those examples
<pitti> except 'record your own session'
<Liberax> hi
<Mithrandir> pitti: indeed
<Liberax> why actually feisty ubiquity doesn't recognize dmraid disks in /dev/mapper (also after installing dmraid) in the disk installation chocihe
<pitti> Mithrandir: the question arises what the prefered modification format would actually be in that case; really tricky
<Mithrandir> pitti: get the files licenced under a BSD licence and not the GPL?
<pitti> heh
<pitti> Mithrandir: maybe I should move it to multiverse for the time being to cover our backs
<elmo> eh?
<Mithrandir> pitti: that doesn't help.
<pitti> oh, right
<pitti> sorry
<Mithrandir> pitti: if it's GPL-ed and we don't have the preferred for of modification, it's undistributable, not non-free
<pitti> right, I noticed two seconds later, sorry
<cjwatson> Liberax: because it's not implemented yet
<Liberax> cjwatson: but if i install dmraid before starting ubiquity  ubiquity could see it if i choiche manual partitioning
<elmo> Mithrandir/pitti: who says .swf isn't the preferred form of modificaiton?
<elmo> AFAIK it is
<elmo> tho IANAWD
<cjwatson> Liberax: what's your question?
<cjwatson> Liberax: dmraid isn't implemented in ubiquity. Sorry etc.
<Liberax> cjwatson: it is implemented if i coiche manual partitioning
<Mithrandir> elmo: a friend of mine who has dabbled with flash says the format the adobe tools use is .fla (whatever that is) and .swf is an export of that.
<cjwatson> partially-implemented, then. It's certainly not implemented properly.
<elmo> Mithrandir/pitti: oh, sorry, never mind apparently I was being lied to.  it quite possibly/probably isn't
<Mithrandir> elmo: I'm not a flash person either, which is why I was wrong at first. :-)
<pitti> ok, then I reject the upload and get back to the uploader; thanks for your input
<Liberax> cjwatson: but on dapper after installing dmraid was possible
<cjwatson> Liberax: luck
<Liberax> cjwatson: thanks very useful 
<cjwatson> it hasn't been deliberately removed
<cjwatson> it's just that if it worked in the first place it was only accidental
<cjwatson> and the manual partitioner got completely rewritten in feisty for many other reasons ...
<cjwatson> Liberax: so your point is that they don't appear in the automatic partitioning list?
<Liberax> cjwatson: appear in the partitioning list only when i choiche manual partitioning
<Liberax> cjwatson: on the main list i see only the two separated disks
<cjwatson> Liberax: yeah, it's because /dev/mapper/* is excluded to avoid picking up LVM LVs
<cjwatson> and partman really doesn't know about dmraid at all
<Mithrandir> fabbione: have you had the chance to test -server CDs?
<cjwatson> for instance, even if I removed that exclusion, it wouldn't know how to exclude the component disks, which it would need to do
<cjwatson> (LVM: bug 32845)
<Ubugtu> Malone bug 32845 in partman-auto "Should stop partman-auto from showing LVM volumes" [Medium,Fix released]  https://launchpad.net/bugs/32845
<Liberax> cjwatson: ok so the issue is because we cannot recognize if a device in dev/mapper is lvm or a fakeraid (dmraid)?
<cjwatson> Liberax: right, and we don't know how to tell that "real" disks are just dmraid components
<Liberax> cjwatson: the second one is a minor issue
<cjwatson> you might say so but if we implemented the first but not the second it would create major confusion.
<Liberax> cjwatson: yes but i explain
<cjwatson> your minor issue == my critical bug reports because somebody got seriously confused
<Mithrandir> Riddell: ok, amd64 installed fine here.
* Mithrandir crawls back into gnome land.
<Riddell> Mithrandir: great, thanks
<Liberax> cjwatson: actually an user to use dmraid must install manually dmraid package before starting ubiquity  so i think that it recognize what disk are in raid 
<Liberax> cjwatson: do u think that parsing dmraid -r or dmraid -l could be too complex or instable?
<cjwatson> Liberax: I don't really know enough about it to say; I have no dmraid systems here. In general I much prefer to avoid parsing text output that's designed for humans to read.
<cjwatson> (we still do that in a few places with parted, and it's been the source of a number of bugs)
<carlos> cjwatson: JFYI, I just did an upload for Feisty's debian-installer based on the .pot and .po files you have in people.ubuntu.com
<cjwatson> carlos: thanks
<carlos> it will take a while as all Feisty is being imported
<carlos> but if you want I can tell you once I get the confirmation
<cjwatson> it's ok, I don't need to know
<cjwatson> thanks
<carlos> ok
<fabbione> Mithrandir: no. being sick all day and i am not going to spend more than 4 minutes around
<Mithrandir> fabbione: do you want it released?
<fabbione> Mithrandir: yes please. at least montreal can test them..
* mvo goes offline to switch network
<Liberax> cjwatson: seems that dmraid discovering metatada on the disk to recognize raid. dmraid can display the metadata in native format on in other format so we can know the disk of the raid
<cjwatson> are there dmraid invocations to (a) display all active dmraid-managed RAID devices (b) display all disks that are components of dmraid devices?
<cjwatson> preferably in a machine-readable form
<Keybuk> well, that's a new one on me
<Keybuk> [^0-9]  is not posix
<Treenaks> Keybuk: how do you do it in posix then?
<cjwatson> !
<cjwatson> ! instead of ^, I mean
<Mithrandir> ! in a charclass?
<Keybuk> I like the fact it defines it by saying [...]  is exactly like <this reference>, except '^' is gratuitously replaced with '!'
<Keybuk> [!0-9] 
<Treenaks> ok.. good to know.
<Liberax> cjwatson: dmraid -r
<Liberax> cjwatson: the first is /dev/<therealdevice>, <rawmetdataformat>, <devmapperraiddevicename>, <raidtype>, <status>, <numberofsectos> sectors, data@ 0
<Liberax> cjwatson: so we have two entry o this type for a dmraid of two disk
<cjwatson> hmm, somebody was working on doing this in d-i
<cjwatson> wonder if they got anywhere
<Liberax> cjwatson: probably because d-i works fine
<cjwatson> it does? we don't have dmraid in main ...
<cjwatson> oh, you mean Debian d-i?
<Liberax> cjwatson debian
<cjwatson> hmm, ok, I may be able to track down a patch then
<Mithrandir> cjwatson: remind me, what's the rune for publishing ports?
<Liberax> cjwatson: has ubuntu dmraid udeb?
<cjwatson> Mithrandir: just ports/daily instead of daily, IIRC
<cjwatson> Liberax: in universe, yes
<Mithrandir> cjwatson: yeah, looks like it, thanks.
<cjwatson> Liberax: it could be promoted to main if we were actually using it
<cjwatson> no matches for dmraid in Debian's partman
<Mithrandir> cjwatson: is it intentional that we have sparc alternates in ports?  I'd think we either shouldn't have them or they should be in daily?
<cjwatson> well, sparc is technically only supported on server, not desktop
<cjwatson> alternate results in a desktop
<cbx33> pitti: does that rejection should apply to pyvnc2swf too?
<Mithrandir> cjwatson: oh well, it just looks weird.  I'll publish it as a port.
<pitti> cbx33: there's no such package in NEW
<cbx33> ahh ok
<pitti> cbx33: ah, are you Lionel?
<cbx33> no
<cbx33> I'm pete
<cbx33> I was the one who tried to submit a new pacakge that included one of those files
<cbx33> and hence had to rewrite it to make it GPL compatible
<lionel> pitty: I am Lionel :) Thanks for the mail btw
<pitti> oh, hi lionel 
<cjwatson> Liberax: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338719 appears to strongly imply that the work has not yet been done in Debian
<Ubugtu> Debian bug 338719 in disk-detect "Please add dmraid support to hw-detect" [Wishlist,Open]  
<cjwatson> Liberax: maybe it works if you do some manual steps, or if you're lucky, or something
<Liberax> cjwatson: the device in raid are not hidden also in debian.. and you still do manually install grub the minor issue listed in the message with the patch for a full automatically functional dmraid are trvial but valid
<Liberax> cjwatson: i try to ask to debian-boot for an updated status
<cjwatson> Liberax: Debian has the same code to suppress /dev/mapper/* as we do
<cjwatson> Liberax: I can't parse your commentt about grub, sorry
<cjwatson> could you try with more punctuation? :-)
<Liberax> cjwatson: for grub i was talking about this http://people.debian.org/~terpstra/message/20051108.120744.d1e3e835.en.html
<cjwatson> Liberax: yeah, that's not a patch though, just a commen
<cjwatson> t
<Liberax> cjwatson: yes i think that this four trivial issue i this message are still valid: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338719;msg=15
<Ubugtu> Debian bug 338719 in disk-detect "Please add dmraid support to hw-detect" [Wishlist,Open]  
<Liberax> the message number 15 of the bug
<cjwatson> Liberax: right, except I don't think it's a trivial issue :-)
<Liberax> cjwatson: i think that parsing dmraid -r is quite affidable
<cjwatson> needs an installer expert with the hardware to actually do the work though
<Liberax> cjwatson: i have the hardware and i could give you the precise output format the any installer developer coulde parse the output
<Liberax> s/the/then
<cjwatson> my experience is that trying to do this without the hardware in front of the person writing the code is soul-crushingly difficult and slow
<cjwatson> you're welcome to send patches
<Liberax> cjwatson before i learn d-i interneal we have this device support ready by two years :)
<Mithrandir> Liberax: d-i isn't very hard.
<Liberax> where is the source code of partman auto?
<ivoks> ubiquity?
<cjwatson> Liberax: http://wiki.ubuntu.com/InstallerDevelopment
<cjwatson> bear in mind that the patch will not be in just one package
<Mithrandir> proof-reading, etc: http://err.no/tmp/herd-5.txt
<Mithrandir> I was wondering if I should put something in there about this being the last before beta.
<Mithrandir> (and the mirror list is quite bogus, but I'll fill that in when I have the list of mirrors)
<Mithrandir> hiya Mark
<sabdfl> howdy
<Liberax> the problem in closing the bug 32845 is that seems in that in dev/mapper there is only lvm instead there is also dmraid
<Ubugtu> Malone bug 32845 in partman-auto "Should stop partman-auto from showing LVM volumes" [Medium,Fix released]  https://launchpad.net/bugs/32845
<cjwatson> Liberax: indeed so
<cjwatson> Liberax: I was aware of that, but it was better to fix something that we did support than to worry about further breaking something that we didn't suppor
<cjwatson> t
<cjwatson> Mithrandir: looks ok to me ...
<cjwatson> Mithrandir: though maybe rephrase "This is an early set of images"
<Mithrandir> cjwatson: better now?
<cjwatson> Mithrandir: yeah
<pochu> Mithrandir: maybe you are interested on this: http://ubuntuforums.org/showthread.php?p=2235609#post2235609
<pochu> don't know wether that's fixed or not (or even wether that was happening to you)
<Mithrandir> pochu: looks like a bad cd, especially considering it worked when he retried.
<pochu> Mithrandir: oh, the bug report
<pochu> yeah, then I'll close the report :)
<pochu> ty
<jdong> Mithrandir: how can bad CD's cause an installed package to bork on configure?
<jdong> oh
<jdong> nvm
<jdong> ubiquity isn't GPG-checked
<jdong> was thinking of the alternate
<cbx33> hey mako_ 
<pochu> jdong: nvm = mevermind?
<jdong> pochu: yep
<cjwatson> jdong: that *is* alternate
* pochu is learning English :)
<jdong> cjwatson: yikes :)
<jdong> aren't GPG signatures supposed to catch corrupted debs?
<cjwatson> "I'm installing Feisty Herd 5 candidate 20070228.1 Alternate i386."
<jdong> RAM corruption?
<bddebian> Heya
<cjwatson> who knows, could b a real bug ...
<jdong> interesting enough
<cjwatson> the error is kind of uninformative though
<bddebian> pitti: Thanks for libtifiles2
<pochu> then do I close the report?
* pochu don't know what to do :)
<pochu> s/don't/doesn't
<jdong> pochu: I don't think we can so readily dismiss the bug as a fluke?
<jdong> s/can/should/
<pochu> jdong: hmm, have I already said I'm learning English?
<pochu> jdong: I can't undertand your question :P
<jdong> pochu: We should not ignore the bug report like that.
<pochu> jdong: ok, now :)
<pochu> jdong: I didn't know readily :)
<jdong> so I'd say just leave it :)
<jdong> launchpad has so many open bugs another one couldn't hurt </flame> :D
<pochu> yeah, probably you're right
<pochu> hehe
<jdong> (kidding, kidding)
<Simira> cjwatson: shall I just close the select-keyboard-layout bug? It works in h5.
<pochu> http://people.ubuntu-in.org/~carthik/bugstats/
<Simira> #86786
<pochu> will we ever reduce the open bugs?
<jdong> it's mako  III, attack of the clones!
<bddebian> heh
<jdong> wait
<jdong> that was II
<jdong> anyway
<jdong> you can tell I'm not a star trek nerd.
<pitti> bddebian: np
<Mithrandir> jdong: it was also star wars and not star trek.
<jdong> pfft :)
<jdong> same difference.
<Treenaks> jdong: *sound of Trekkies having heart-attacks*
* Simira giggles at new ubiquity features
<Mithrandir> Simira: the migration assistant?
<pitti> jdong: Kirk will kill you with his laser sword!!!11!!
<jdong> Treenaks: if that gives trekkies heart attacks then I'd give anime fans spontaneous combustion.
<Simira> Mithrandir: yes
<Simira> Mithrandir: what do you want as a password on my laptop?
<Mithrandir> Simira: uh, I'll set it when I get home? :-)
<jdong> pfft vistakeys@home
<jdong> amusing.... I don't think BOINC would be thrilled.
<cjwatson> Simira: weird, I've no idea how that got fixed, but if it works now, go ahead
<AndrewB> Who's bot is ubotu.. or even who setup the bot. [I know it is a supybot] 
<geser> AndrewB: Seveas is his master
<AndrewB> thanks.
* AndrewB found it on a wiki page :)
<Seveas> 'sup AndrewB ?
<mvo> cjwatson: I updated bug #67130 (sru-verification), I would appreciate if you could give me a hint about how to reproduce the original problem
<Ubugtu> Malone bug 67130 in ubiquity "mount points preparation locked - "No root file system"" [Critical,Fix committed]  https://launchpad.net/bugs/67130
<AndrewB> nm Seveas I will be back later.. changing house  =/ hehe
<cjwatson> mvo: easiest (if not fastest) way is to do a full install with autopartitioning, then reboot back into the installer and try to install on the same partitions with manual partitioning without changing the partition layoutt
<cjwatson> mvo: i.e. just set the mount points to what they were before
<cjwatson> mvo: hmm, but you said you did that, curious
<mvo> cjwatson: thanks, I will try this now. I used a vmware snapshot that should be pretty pristine, perhaps there is a issue with it or something
<cjwatson> mvo: did you reformat them in gparted?
<mvo> cjwatson: no
<mvo> cjwatson: should I ?
<cjwatson> no
<cjwatson> mvo: oh, hmm, try an existing reiserfs partition instead of ext3
<cjwatson> I think with ext3 it may manage to detect what it is and bypass the problem
<cjwatson> the code's icky
<mvo> that is much better, reiserfs triggers it
<mvo> thanks
<cjwatson> that was quick
<mvo> yeah :) so far the most time-consuming part of the sru-verification is triggering the original problem
<mvo> (for the sru-verifications I have done so far at least)
<mjg59> cjwatson: Did you say you'd done an upload with the HFS+ resize patch?
<mjg59> Or were you going to do that after Herd 5?
<AndrewB> Seveas: back. How goes?
<Seveas> a bit ill
<cjwatson> mjg59: I did it, but it's queued until after Herd 5
<mjg59> cjwatson: Thanks
<AndrewB> Seveas: hmm me too, cold :(
<mvo> pitti: If you reject bugs with the verification-needed tag, could you please also remove the tag? 
<pitti> I was just typing my answer...
<Seveas> dwerwe
<Seveas> ok, so there's a bug in vnc, sorry for spewing gibberish
<pitti> Seveas: we know your r00t password now :)
<Seveas> hehe
* doko *loves* icon discussions ...
* Laser_away hugs pitti 
<doko> pitti: which files do conflict in wxwidgets2.8?
<pitti> doko: AFAIR the libraries in /usr/lib/
<doko> pitti: no, all have a 'd' in its name
<pitti> doko: oh, ok, then this was an oversight; sorry
<doko> don't ask me if that makes sense ...
<Riddell> Mithrandir: is herd 5 being released?
<pitti> I had expected /usr/lib/debug/ stuff
<pitti> iwj: is there a trick how to convince dpkg --unpack not to run any maintainer scripts?
<Treenaks> pitti: ar x file.deb ; tar -x -v -z -C / -f data.tar.gz
<Treenaks> pitti: ? :P
<pitti> Treenaks: no, that won't register the deb as unpacked, so I cannot purge it any more
<kylem> anyone running feisty with an ati card feel like testing 7.2 driver deb?
<Treenaks> good point
<pitti> Treenaks: for that, dpkg -x is easier :)
<pitti> kylem: my powerpc at most
<pitti> kylem: radeon 9200 (runs with free driver)
<pitti> but I guess there are testers with more elaborate hw :)
<Treenaks> kylem: X700 (with bug 20283, but should work 'good enough')
<Ubugtu> Malone bug 20283 in xserver-xorg-video-ati "[fgl v5000]  really bad sync" [Medium,Needs info]  https://launchpad.net/bugs/20283
<Treenaks> kylem: x86
<kylem> Treenaks, http://people.ubuntu.com/~kyle/xserver-xorg-video-ati_6.6.3-2ubuntu1_i386.deb
<Treenaks> kylem: downloading
<kylem> pitti, 6.6.3-2ubuntu1 in my ~kyle/public_html on rooker
<kylem> pitti, you'll have to build it yourself. :P
<pitti> kylem: right, but building a single driver shouldn't take that long (I hope)
<kylem> it's quite speedy.
<pitti> kylem: upgrading my ppc to latest feisty will take the better part of the time :)
<kylem> hehe
<Treenaks> works
<Treenaks> still has bug 20283, but bug 22985 is gone
<Ubugtu> Malone bug 20283 in xserver-xorg-video-ati "[fgl v5000]  really bad sync" [Medium,Needs info]  https://launchpad.net/bugs/20283
<Ubugtu> Malone bug 22985 in xserver-xorg-video-ati "[x700]  fails to infer lvds for primary connector on acer ferrari 4005 | card detected, but driver fails to use right output port" [High,Confirmed]  https://launchpad.net/bugs/22985
<iwj> pitti: None at all ?  No.
<kylem> Treenaks, i'll beat up dave for you.
<iwj> pitti: Why do you want to do that ?
<pitti> iwj: ok, so unpack control.tar.gz - mangle - repack deb - --unpack, right?
<Treenaks> kylem: I sent him my video bios.. he said he'd probably have to rewrite the ATOM parser for it to work.. 
<pitti> iwj: for the apport-fakechroot stuff
<kylem> Treenaks, ouch.
<iwj> pitti: You can do that if you want, yes.  dpkg -x; dpkg -X; rm; repack.
<pitti> iwj: I'd like to be able to purge packages after unpacking them
<Treenaks> kylem: and in another bug, I saw that 'rewriting the ATOM parser' is part of Randr 1.2 work
<iwj> pitti: OIC
<kylem> Treenaks, i'll find out what the status is for you.
<iwj> And the maintainer scripts are bad ?
<pitti> iwj: but for a gdb run I don't need any configuration, just the naked files
<Treenaks> kylem: cool, great
<pitti> iwj: some preinst files fail with fakeroot unfortunately
<iwj> Doesn't debootstrap know how to synthesize a dpkg database ?
<pitti> iwj: I retraced some Gnomeish report with a really huge dependency chain, and about 7 packages didn't install (some that pre-depended on x11-common or so)
<pitti> iwj: not sure what you mean with 'synthesize a dpkg database'?
<pitti> iwj: debootstrap uses dpkg to unpack/configure all apckages except dpkg itself
<pitti> (well, and a few other exceptions)
<cjwatson> debootstrap does roughly: touch /var/lib/dpkg/status and create random directories and stuff; extract all core packages; re-unpack all core packages over the top; configure
<pitti> ah, the re-unpacking does the trick then
<cjwatson> where core => whatever you need to run dpkg
<iwj> pitti: If you want a --no-maint-scripts option it shouldn't be too hard.  I wonder if debootstrap would like it too.
<pitti> iwj: I can go with the repacking option (since it needs to work on stable releases, too), but eventually such an option would be handy
<pitti> iwj: repacking is easy, just takes some time
<cjwatson> iwj: my concern with --no-maint-scripts is that people would use it and then report bugs due to the preinst not having run or something
<cjwatson> it'd have to be a separate "half-unpacked" state or something, except you wouldn't be able to convert it into unpacked
<pitti> iwj: I guess I could even keep the data.tar.{gz,bz2} and just repack control.tar.gz to be faster
<cjwatson> the only thing you would have to be allowed to do would be to purge it again
<pitti> hm, I think I'll do it with a less hackish way: dpkg-deb -x and keep track of the files myself
<pitti> oh, no, then dpkg -S doesn't work
<doko> pitti: please could you promote the fastjar source into main? it's splitted out from gcc, so I hope no new inclusion report is needed
<pitti> right
<pitti> doko: done
<doko> thanks
<iwj> pitti: You could write a crappy script that did some of the right things.  Maybe use the Perl dpkg of yore ? :-)
<iwj> cjwatson: Yes, you're probably right.  It could be undocumented I suppose.
<iwj> Or   --no-maint-scripts-yes-i-promise-not-to-report-any-bugs
<pitti> lol
<iwj> --no-maint-scripts would be a nice alternative to  rm /var/lib/dpkg/info/stupid-package.prerm
<Treenaks> --no-maint-scripts --no-really --really-really
<Treenaks> or --trust-me :)
<iwj> --really-really-im-lying-actually-this-is-apt-and-i-want-to-fuck-your-system
<iwj> pitti: For the crappy script approach, the things I can think of you have to do are:  1. control fragment to /v/l/d/status, with Status: install ok installed.   2. info/<package>.list   3. info/<package>.{{pre,post}{inst,rm},md5sums}   3. conffiles (yuk)
<iwj> I mean, 3. for each entry in conffiles make an entry in the status fragment.
<pitti> iwj: right, or that; I thought of that, but using some ar magic to repack the .deb seems a bit more robust
<iwj> And apparently I can't count.
<pitti> even if it takes a little longer
<iwj> Sure.
<pitti> but since I do not have to repack data.tar.gz, it's not that bad
<iwj> Right.
<pitti> iwj: no idea how bad the overhead of 'ar r' actually is, but should be okay
<iwj> The ordering of members in a .deb is important, btw.
<pitti> iwj: right, 'ar r' *seems* to preserve it
<iwj> pitti: Odd, the FM disagrees.  But well and good.
<pitti> oh?
<iwj> Oh I'm misreading it.
<iwj> It says `_new_ members are added at the end of the file' (emph mine).
<pitti> hm
<pitti> worked here, but that might have been sheer coincidence
<iwj> Thus failing to specify what happens when replacing but the correct behaviour seems clear.
<iwj> SuSv3 `Files that replace existing files in the archive shall not change the order of the archive'
<pitti> iwj: I'll find out soon eough :)
<pitti> kylem: new ati driver works fine for me
<kylem> awesome
<kylem> thanks
<seb128> any i810 user wanting to test the new driver package? http://people.ubuntu.com/~seb128/xserver-xorg-video-i810_1.7.4-0ubuntu1_i386.deb
<KaiL> especially people, who are already planning to replace their VGA chip ;)
* KaiL hides
<geser> seb128: this isn't the modesetting branch, is it?
<kylem> geser, it isn't.
<pochu> seb128: I would like to :)
<pochu> seb128:  Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller
<pochu> seb128: I just need to restart X, right?
<seb128> pochu: yep
<seb128> pochu: install the package and restart xorg
<seb128> geser: that's the tarball for xorg 7.2 
<pochu> seb128: already installed
<pochu> going now :)
<seb128> ok
<seb128> thank you
<pitti> nice weekend everyone!
<seb128> pitti: you too, enjoy as well
* pitti hugs seb128 
<pochu> seb128: works fine :)
<seb128> pochu: good, thanks for testing ;)
<pochu> seb128: do u want me to look for something?
<pochu> maybe LP bugs
<seb128> pochu: you are welcome to look at bugs and ask people to try the new version when it'll have been uploaded
<pochu> seb128: what about the -modesetting driver? will you also update it? :)
<seb128> pochu: no, Debian has no new version and I'm not maintain xorg, just giving an hand to update to xorg 7.2 and that's not an official tarball
<mjg59> pochu: I'll look into that if I have time
<pochu> mjg59: thanks :)
<pochu> seb128: ok
<geser> seb128: is xserver-xorg-video-i810-modesetting 1.7.2.git20070210-1 to old for xorg 7.2?
<pochu> mjg59: I think that, as the -modesetting is heavy development, and even unstable, we can checkout a new git version, since the actual is too old
<pochu> ups, that's what I want!
<pochu> :)
<geser> that 1.7.2-* version is Debian experimental
<seb128> geser: you don't ask to the right person, I'm using ATI on my desktop and don't know anything about that modesetting driver ;)
<seb128> geser: we can probably sync that from Debian
<pochu> tepsipakki: do you know geser question?
<geser> crimsun compiled the Debian experimental version for Ubuntu: http://revu.tauware.de/~crimsun/
<mjg59> Which version we want will depend on what version of xorg we ship
<seb128> mjg59: we ship 7.2
<tepsipakki> geser: we could sync from experimental like seb128 suggested
<seb128> looks like we could just sync the Debian package
<tepsipakki> hmm, what was the problem with EXA&ati again?
<mjg59> seb128: Sorry, I meant server version rather than release version
<tepsipakki> mjg59: 1.2
<seb128> mjg59: we have 1.2, is 1.3 available yet?
<tepsipakki> not yet
<mjg59> 1.3 is out this week, in theory
<seb128> when will it be available?
<mjg59> I believe that the code is frozen
<seb128> we might want to consider it
<mjg59> I'll check
<seb128> not my call though
<tepsipakki> yes, we might want that
<mjg59> If we get 1.3, then we also want randr 1.2, which needs a rebuild of the modesetting driver
<seb128> that's 1.2 with new xrandr right?
<pochu> crimsun: dpkg: considering removing xserver-xorg-video-i810 in favour of xserver-xorg-video-i810-modesetting ...
<pochu> dpkg: no, cannot proceed with removal of xserver-xorg-video-i810 (--auto-deconfigure will help):
<pochu>  xserver-xorg-video-all depends on xserver-xorg-video-i810
<seb128> mjg59: we already have randr1.2 (if you speak of the lib)
<mjg59> seb128: There's some awkward build-ordering issues - I can't remember whether it needs redoing with the new server
<geser> pochu: that package is for quick testing and need proper merging
<pochu> crimsun: that's related to bug 80417
<Ubugtu> Malone bug 80417 in xserver-xorg-video-i810-modesetting "i810 modesetting driver can't be installed concurrently with ubuntu-desktop" [Low,Confirmed]  https://launchpad.net/bugs/80417
<pochu> geser: ok :)
<pochu> well, going to restart x :)
<Amaranth> and he was never heard from again
<Amaranth> :P
<pochu> -modesetting works fine, but I have the same issue I had with the old version, and with 915resolution
<Amaranth> pochu: ?
<pochu> i didn't reported it
<pochu> the Y axe is stretched
<geser> streched?
<pochu> geser: that's what the dictionary says ;)
<pochu> geser: it's longer than it should be
<pochu> so the icons are larger, and all that :)
<pochu> also, the fonts are strange...
<pochu> screenshot
<mjg59> cjwatson: I've got a patch that adds basic GPT/MBR synchronisation. I'll throw it at you later.
<pochu> http://emilio.pozuelo.org/screenshot.png <--- do you see it fine?
<pochu> look at the ubuntu icon, for example
<geser> it looks normal to me
<mjg59> pochu: No, that looks fine here. Which is unsurprising.
<tepsipakki> pochu: so you have a wrong resolution which the panel stretches?
<mjg59> If there's an issue with your display, then...
<mjg59> That is, if you take a screenshot, it'll still look fine here
<pochu> then I'll take a photo :)
<phanatic> pochu: rather take a photo ;)
<phanatic> :)
<pochu> phanatic: :)
<cjwatson> mjg59: great, thanks
<mjg59> cjwatson: I've mailed it to parted-devel, waiting for feedback from that
<cjwatson> mjg59: now the last urgent partitioning item for feisty is to make partman able to resize ext3 with resize_inode despite it being hideously hard to implement in libparted
<pochu> tepsipakki: no, the resolution is well configured, (1280x800), but it's displayed ugly
<pochu> as if it would be displaying a 1280x600, so the Y res is aumented
<seb128> Mithrandir: have you planned to unfreeze the archive today?
<pochu> geser, tepsipakki & co: http://emilio.pozuelo.org/modesetting.jpg
<geser> pochu: I still don't see any problem 
<pochu> geser: don't you see larger the ubuntu icon?
<pochu> geser: and the fonts?
<geser> look also normal to me
<lemsx1> is it just me but Feisty seems to double the swap space... i have a 2GB partition set for swap and it looks in top like 4GB. i use swapoff -a and swapon -a and it shows as 2GB (like it should)
<lemsx1> perhaps the swap partition is being mounted twice??
<doko> pitti, seb128, Mithrandir: did you promote python-qt3-gl to main? if yes, then pyopengl needs to be promoted as well
<jcole> who maintains the vmplayer ubuntu package?
<pochu> geser, tepsipakki: I hope you can find the difference with this: this is me, with the modesetting: http://emilio.pozuelo.org/photo2.jpg, and this is me without it: http://emilio.pozuelo.org/acerca-de-pochu/
<Treenaks> pochu: lots of moire!
<crimsun> pochu: what happens after you ctrl+alt+F# then alt+F7 ?
<Mithrandir> seb128: yes
<G0SUB> Seveas: ping
<Seveas> G0SUB, ?
<pochu> crimsun: let's see
<G0SUB> Seveas: can you kindly send Ubugtu to #ubuntu-in ?
<Seveas> no
<G0SUB> Seveas: we need its help some times
<pochu> crimsun: same
<G0SUB> Seveas: why?
<Seveas> the bots are in too many channels already
<Seveas> you can easily grab its code and host your own bot
<G0SUB> Seveas: hmm. fine. where is it?
<Seveas> !code
<Seveas> hehm ubotu not in here :)
<Seveas> anyway, bots.ubuntulinux.nl
<G0SUB> ok
<G0SUB> Seveas: thanks
<crimsun> pochu: did you rebuild from experimental's source package?
<G0SUB> Seveas: http://bots.ubuntulinux.nl/code/ gives me 403
<Seveas> G0SUB, odd
<pochu> crimsun: no, I downloaded your package
<Seveas> try launchpad, ubuntu-bots product
<G0SUB> Seveas: ok
<crimsun> pochu: please pbuild it; that version was compiled against older xserver-xorg-dev
<pochu> crimsun: ok, could you give me the link again? :)
<crimsun> pochu: adhd.irule.net/~crimsun/
<crimsun> pochu: if in doubt, check the upstream git branch, too.
<pochu> crimsun: it isn't there
<crimsun> err, sorry. tiber.tauware.de/~crimsun
<pochu> crimsun: http://revu.tauware.de/~crimsun/
<pochu> err, they're the same :)
<Mithrandir> mvo: is upgradetestingprocess complete and the archive can be unfrozen?
<mvo> Mithrandir: yes, http://people.ubuntu.com/~mvo/automatic-upgrade-testing/ looks good
<Mithrandir> mvo: thanks.
* ..[topic/#ubuntu-devel:Mithrandir] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Herd 5 released
<pochu> crimsun: done, going to restart
<pochu> crimsun: same :(
<pochu> crimsun: built with pbuilder up-to-date
<pochu> tepsipakki: ^^
<Mithrandir> tepsipakki: just let your large amount of changes through.  Great work. :-)
<pochu> sure, this is just the -modesetting driver, which isn't stable yet. The -i810 works fine (without the good resolution, but that also happened before the update)
<tepsipakki> Mithrandir: thank seb128 and kylem for reviewing ;)
<tepsipakki> pochu: I still don't see the picture as too wide, looks good to me :/
<Mithrandir> tepsipakki: was this the rest of the bits needed?
<tepsipakki> Mithrandir: yes, there are some minor updates to the utils though
<Mithrandir> ok, coolie
<netstar> what the heck happened to the PowerPC release? Why was it dropped?
<Seveas> netstar, that's all in the announcement...
<netstar> which one?
<Seveas> the one that said that PowerPC would be downgraded from official to community-supported
<netstar> where does one get it from?
<crimsun> pochu: then it's likely an issue to be addressed (or is in progress in upstream's git branch)
<Seveas> https://lists.ubuntu.com/archives/ubuntu-announce/2007-February/000098.html
<netstar> SPARC is more dead than POWER
<netstar> insane
<Mithrandir> netstar: powerpc is in ports, though.
<cjwatson> we'd definitely welcome more development effort on powerpc ...
<cjwatson> from interested folks
<netstar> I think I'd be more interested in keeping the debian powerpc port alive
<netstar> sigh
<cjwatson> well, the Ubuntu powerpc port has the same status as the Debian one :-)
<cjwatson> neither is corporately supported
<cjwatson> that's really the only difference
<cjwatson> we're not going to stop building it at all, if nothing else 'cos I have a powerpc laptop ... ;-)
<jcole> netstar: i usually install via debian installer myself (mini.iso) -> http://archive.ubuntu.com/ubuntu/dists/feisty/main/installer-powerpc/current/images/
<cjwatson> the powerpc CDs haven't gone away: http://cdimage.ubuntu.com/ports/daily-live/current/ and http://cdimage.ubuntu.com/ports/daily/current/
<netstar> :/
<Mithrandir> and http://cdimage.ubuntu.com/ports/releases/feisty/herd-5/ for the just-released herd 5
<Mithrandir> oh well, I'm off to bed.  See you around later.
<jcole> netstar: you think you feel unsupported, i'm running ubuntu on hppa :P
<netstar> lol
<toodles> Just wanted to mention that widescreens that have a native resolution of 1440x900 and intel g945 don't work at all with i810 - X fails to start at all. The current modesetting driver allows X to start, but screen is always blank. I've also tried the modesetting driver at http://revu.tauware.de/~crimsun/ which had the same effect. For this reason, would it not be better to promote 915resolution to main for feisty. As it is (for the compi
<toodles> nation I just mentioned), the live cd (edgy or herd5) does not work at all (X fails), and the alternate install requires 915resolution to be installed from commandline before X starts.
<toodles> s/compination/combination
<toodles> The bugs at http://bugs.debian.org/915resolution don't seem relevant issues to not promote it. What are the developer opinions on this? Is there anything that speaks against this? If the i810-modesetting driver is considered so unstable, then it seems like a good idea to use 915resolution to me.
<toodles> If nobody as any objections, I'd fill out an MIR. :-)
<pochu> toodles: have you filed a bug in freedesktop?
<toodles> No, just on launchpad. 1 sec
<toodles> https://launchpad.net/ubuntu/+source/xorg/+bug/62002 is a bug about edgy, but it is the same problem. From what I can see, this as always been an issue.
<Ubugtu> Malone bug 62002 in xorg "Installer X server startup fails" [High,Confirmed]  
<toodles> pochu: I just checked, this bug has been reported on freedesktop. https://bugs.freedesktop.org/show_bug.cgi?id=9076
<Ubugtu> Freedesktop bug 9076 in Driver/i810 "i810 modesetting: 1440x900 panel setup fails" [Normal,New]  
<pochu> toodles: you also have Bug #82189
<Ubugtu> Malone bug 82189 in xserver-xorg-video-i810-modesetting "Using xserver-xorg-video-i810-modesetting results in a blank screen" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82189
<toodles> pochu: I completely forgot about that!! I reported that one myself :-P
<pochu> toodles: :)
<pochu> toodles: does the normal i810 (not the modesetting) driver works for you?
<toodles> pochu: No. X Fails completely, no matter what resolution or settings I try. It only works after 915resolution is installed.
<pochu> toodles: even with x.org 7.2?
<toodles> pochu: It effectivly makes ubuntu not work out of the box, not matter how it's installed.
<toodles> pochu: Yes. I'm using herd 5 as we speak.
<pochu> tepsipakki: oh, it isn't supposed to be too wide, but too height :)
<pochu> tepsipakki: believe me, it *is* :)
<toodles> pochu: The funny thing is, usplash nearly displays correctly. It's a bit squashed from top to bottom, but it displays. It makes it seem strange that X then fails.
<pochu> toodles: do you have an x.log?
<toodles> pochu: Of it failing?
<pochu> toodles: yes
<toodles> pochu: Give me a few minutes to remove 915resolution and restart X. I'll get it for you. Back in a few :-)
<pochu> toodles: ok :)
<toodles> pochu: I'm back :-) The x.log here: http://paste.ubuntu-nl.org/8285/
<pochu> toodles: looking
<pochu> but sure tepsipakki will know a lot better than me :)
<pochu> toodles: (EE) I810(0): No Video BIOS modes for chosen depth.
<toodles> pochu: I really appreciate you looking :-) I would do what I can to get this fixed, so if there's anything I can do or read up on that might help, please let me know!!
<toodles> pochu: Want me to try with 1024x768?
<pochu> toodles: sure
<pochu> toodles: what is your exact laptop?
<toodles> Dell Insporon 640m
<toodles> pochu: I have a friend who has the same laptop, but his native resolution is 1280x800 - his one works out of the box at 1024x768 and he can install from the live cd.
<toodles> pochu: Hence I came to believe that this only affects people with wide screens and a resolution of 1440x900 or higher.
<pochu> toodles: have you seen this? https://wiki.ubuntu.com/LaptopTestingTeam/DellInspiron640m
<sladen> toodles: can you take a photo of it (with a digital camera) and file a bug report with it attached
<toodles> pochu: No
<pochu> toodles: if he has the same laptop, why he has 1280*800 and you have 1440*900?
<toodles> pochu: Of course I can
<pochu> toodles: take a look ;)
<pochu> toodles: you wanted to say sladen right?
<toodles> pochu: I will. What? What is sladen?
<pochu> sladen: hello!
<toodles> pochu: Dell offer two different screeens with this model laptop. One has a higher resolution.
<pochu> toodles: oh, now I understand :)
<sladen> pochu: hello
<pochu> toodles: like acer and my laptop :)
<toodles> pochu: Your acer also has 1440x900?
<pochu> toodles: 1280*800 :)
<toodles> pochu: Ah, ok. I've seen the pictures you posted with the off resolution.
<pochu> toodles: it works out of the box with i810, and works with modesetting, though I have a problem with this one
<pochu> toodles: yeah, I have to file a bug upstream
<toodles> pochu: Yes, I've seen many people have success with both i810 and the modesetting driver but their resolution was always less than 1440x900.
<toodles> pochu: If you would still like me to try again with 1024x768, I will do it now.
<pochu> then I'm not in that group :(
<pochu> toodles: yes, and let's see if then it works :)
* Chipzz waves at sladen :)
<toodles> sladen: Sorry, I missed your message earlier. I will make a quick video of the process, and take a picture for you to see.
<toodles> pochu: sladen: Have to make a phone call first, so I might need an hour. :-P Hope that's ok with you.
<pochu> toodles: then I probably won't be here, but there are a lot of people who can help you much better than me :)
<toodles> pochu: Ok. Thank you for all your help! Have a nice evening :-)
<pochu> toodles: night here :)
<toodles> pochu: :-)
<pochu> toodles: same for you, and I hope you can fix your problem soon!
<toodles> pochu: Thank you!
#ubuntu-devel 2007-03-03
<pochu> toodles: if you don't know, there is a channel with the X frikis, #ubuntu-x so you may want to hang there :)
<toodles> pochu: Thank you, will do :-D
<tepsipakki> toodles: have you tried other distros?-)
<toodles> tepsipakki: No, but that's a very good idea. (Still, I'm not gonna leave ubuntu. I love it too much) Any suggestions? fedora, opensuse?
<tepsipakki> no idea.. I haven't tried any other for a long time
<pochu> toodles: search for one which fits in one cd ;)
<toodles> tepsipakki: Same. Found ubuntu was happy with my OS the first time ever.
<pochu> me too :)
<toodles> pochu: Lol. :-)
<pochu> tepsipakki: would it be possible to checkout a newer git to include it in ubuntu? for the modesetting driver
<pochu> tepsipakki: (if I test it and works fine)
<tepsipakki> why not
<toodles> tepsipakki: I'll be glad to test all you want too!
<pochu> tepsipakki: and to build it, would be enough to copy the debian/ into the new git, or there would be some work to do?
<tepsipakki> that should work
<pochu> ok, then I'll try it :)
<toodles> pochu: If your build works, would you mind sending me a link??
<pochu> toodles: sure :)
<toodles> pochu: cool!
<pochu> toodles: sure I can, I mean
<pochu> not that I mind doing it :)
<pochu> toodles: if it works...
<toodles> pochu: hehe, gotcha
<pochu> :P
<pochu> toodles: but I will try to build it tomorrow
<pochu> if it works, I'll mail you :)
<toodles> pochu: That would be swell :)
<pochu> who should I poke about a security problem in an ubuntu package?
<poningru> what is the 'desktop effect' that is activated?
<poningru> is it compiz or beryl?
<tepsipakki> compiz
<poningru> awesome thanks
<tepsipakki> beryl is not in feisty
<poningru> as in not packaged for it??
<keescook> poningru: generally me or pitti.  feel free to email security@ubuntu.com too (goes to me and pitti)
<keescook> gah.  pochu: ^^
<poningru> :)
<tepsipakki> poningru: yes
<poningru> tepsipakki: thanks
<pochu> keescook: ok, ty :)
<pochu> keescook: can I pm you a second?
<keescook> pochu: yup, feel free.  :)
<LaserJock> poningru: compiz was in Universe and beryl wasn't/isn't
<tepsipakki> compiz is in main now
<tepsipakki> ah
<tepsipakki> "was"
<poningru> awesome
<roico> compiz is in universe?
<poningru> in main now
<pochu> and in the install cd, also
<geser> tepsipakki: is the virtual package xserver-xorg-video now versioned in Ubuntu or still only in Debian?
<keescook> pochu: looks like Debian (and Ubuntu's) wordpress is clean; the orig.tar.gz matches the official published version (not the bad one)
<pochu> keescook: the official was affected, so does it match 2.1.2?
<pochu> keescook: cvs wasn't affected, though
<pochu> keescook: but if the tar.gz used by ubuntu/debian was from wordpress.org, it should be affected...
<keescook> pochu: the official release was fine for a while, but was recently (in last 4 days) modified.  to avoid confusion, WP is just declaring all 2.1.1's as "bad".  I verified that our 2.1.1 is the official version (and has no backdoor)
<pochu> keescook: oh, well :)
<keescook> pochu: the orig was downloaded before the bad guy changed it on wordpress.org.
<pochu> I understood that all the 2.1.1 were affected :-/
<pochu> keescook: ty anyways :)
<keescook> they're just saying that to avoid confusion.
<keescook> i.e. since *some* 2.1.1's are bad, they're just declaring the entire version bad.
* pochu should read twice before disturb the devs
<geser> tepsipakki: is Provides: xserver-xorg-video-1.0 fixed in the last xserver-xorg-video-ati upload?
<Ng> are there bzr branches for packages? I just did "bzr branch http://launchpad.net/xine-lib" and got 1.1.3, but 1.1.4 is in feisty
<Burgundavia> Ng: for some yes
<geser> tepsipakki: xserver-xorg has only a dependency on xserver-xorg-video (without the -1.0)
<Ng> Burgundavia: bah ;)
<Fujitsu> Ng: Some, but few, packages are in bzr.
<Fujitsu> I believe we'll soon be able to attach branches to distro source packages, so it may become more common in future.
<Ng> cool
<Ng> 'cos I have a patch I want to use in xine, but isn't suitable for merging, so being able to track a bzr branch would be most handy
<Fujitsu> Did my messages get through a couple of minutes ago? My 'net connection was going silly...
<Hobbsee> Fujitsu: the two?  yes
<Fujitsu> I was wondering, as my network connection sort of dropped, but didn't....
<pochu> night all!
<pochu> oups :)
<K3nto> could somebody here do me a big favor? i was helping a fellow in #ubuntu install Edgy Eft but i got booted 
<Hobbsee> K3nto: why did you come here then?
<K3nto> so see if somebody could go there and tell him it was an accident
<Hobbsee> K3nto: people here dont usually have ops in #ubuntu .  try #ubuntu-ops
<K3nto> ok thanks
<K3nto> Seveas isnt responding
<firefly2442> Will Feisty have spellcheck built into Firefox by default?
<jdong> firephoto: certainly
<jdong> grr
<jdong> guy left
<jdong> never mind
<SEJeff> In launchpad, I found the kernel package and Bugs is insensitive. How can I report a kernel oops when apport is retarded and dies?
<shawarma> I'm at a Linux Expo in Denmark and people keep asking if Feisty CD's will be available from ShipIt. Has that been decided yet?
<lifeless> I dont think its decided yet, but I suspect the answer will be yes - its much less crack than edgy
<mdke_> edgy wasn't that crack
<mdke_> presumably they will continue to distribute dapper as an LTS, so it will depend on whether the resources are there to ship two versions at once
<astopy> is changelogs.ubuntu.com down?
<Hobbsee> astopy: it seems not.
<Hobbsee> ping chsarah@LongPointyStick:~$ ping changelogs.ubuntu.com
<Hobbsee> PING changelogs.ubuntu.com (82.211.81.132) 56(84) bytes of data.
<Hobbsee> 64 bytes from rookery.ubuntu.com (82.211.81.132): icmp_seq=1 ttl=46 time=291 ms
<Hobbsee> 64 bytes from rookery.ubuntu.com (82.211.81.132): icmp_seq=2 ttl=46 time=292 ms
<Hobbsee> 64 bytes from rookery.ubuntu.com (82.211.81.132): icmp_seq=3 ttl=46 time=301 ms
<Hobbsee> 64 bytes from rookery.ubuntu.com (82.211.81.132): icmp_seq=4 ttl=46 time=296 ms
<Hobbsee> 64 bytes from rookery.ubuntu.com (82.211.81.132): icmp_seq=5 ttl=46 time=291 ms
<Hobbsee> --- changelogs.ubuntu.com ping statistics ---
<Hobbsee> 5 packets transmitted, 5 received, 0% packet loss, time 3999ms
<astopy> hmm, the machine is up but apache doesn't seem to be responding
* stgraber confirms
<stgraber> Waiting for changelogs.ubuntu.com ...
<StevenK> You're right, it's up, but doesn't respond to any services.
<MrStein> Before I bugger, is it noraml that the live CD (Herd5) uses the VESA driver instead of radeon ?
<MrStein> noraml=normal
<MrStein> OK, I'm "bugging" Where should I report bugs with FF Herd 5 lice CD ? Just as normal bugs into https://bugs.launchpad.net ?
<Hobbsee> yep
<MrStein> 'key...
<MrStein> Hobbsee: you know the answer about the above question about VESA driver ?
<Hobbsee> no
<MrStein> is there a channel for testing releases ?
<Hobbsee> #ubuntu+1
<MrStein> ok, thanks. Moving to #ubuntu+1
<Sp4rKy> hi
<Sp4rKy> does anyone know why casper only set $LANG and no $LANGUAGE ?
<hunger> Is x.org now at version 7.2?
<stgraber>  Protocol Version 11, Revision 0, Release 7.2
<stgraber> oops
<stgraber> X Protocol Version 11, Revision 0, Release 7.2
<stgraber> so the answer is yes :)
<hunger> stgraber: I have not restarted X in weeks... So it still claims Release 7.1 here. Looks like I need to reboot soonish to test the new kernel and xserver:-)
<stgraber> hunger: you can check what version of X is installed with "X -version"
<hunger> stgraber: Oh, cool, hadn't known that:-)
<hunger> stgraber: I used xdpyinfo to get the version no.
<hunger> Maybe X won't crash when I start glxgears with the new drivers:-)
<stgraber> ATI board ?
<Fujitsu> hunger: I've heard that it fixes some glxgears crashing on ATI.
<hunger> Fujitsu: Great:-)
<hunger> stgraber: Yeap, ATI graphics card in a laptop.
<Sp4rKy> is there someone who can help me with casper ?
<Hobbsee> Sp4rKy: seeing as tehy havent answered, probably not
<Sp4rKy> ^^
<Hobbsee> Sp4rKy: also, look at the day.
<Sp4rKy> indeed
* Hobbsee cant spell.
<provolone6787> hy
<Sp4rKy> hy
<provolone6787> i've a problem making deb package
<provolone6787> .S
<provolone6787> i made deb package from source
<provolone6787> but when i install it all files is put into / dir
<provolone6787> do u know the reason?
<doko> cjwatson: debootstrap currently doesn't create the fd devices; I want to add them, devices-std or divices?
<\sh> moins
<\sh> who came up with this idea: dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
<ForgeAus> are there any plans to add download acceleration (well more like multi-source downloads) to adept for kubuntu?
<ForgeAus> I mean currently it does do multiple separate downloads at once, just doesn't use more than one source that I know of for a single download
<Seveas> ForgeAus, "download acceleration" is only annoying for servers and doesn't speed up anything in this case since the ubuntu archive isn't speedlimited
<Hobbsee> \sh: the debian maintainer field spec should explain all...
<\sh> Hobbsee: but it's wrong..
<ForgeAus> thanx Seveas sounds reasonable....
<\sh> a package with 0ubuntuX doesn't mean, the maintainer needs to be an ubuntu.com email address holder ;)
* Hobbsee didnt write it.
<Seveas> \sh, there was talk about that in the last devel meeting. It'll be overridable and check whether DEBEMAIL has @ubuntu.com in it iirc
<\sh> Seveas: well, there needs to be a difference between debian packages changed by ubuntu {core,motu} devs and a new package to ubuntu, where a package maintainer can be someone else...
<zul_> LS
<RenatoSilva> hi
<RenatoSilva> I'm renato from Rio, Brazil
<RenatoSilva> how open are you for suggestions?
<angasule> ol :) I think they're all sleeping here
<RenatoSilva> angasule: hi
<RenatoSilva> angasule: who are you?
<RenatoSilva> angasule: brazillian
<RenatoSilva> angasule: ?
<angasule> eu sou argentino
<pochu> RenatoSilva: what do you need?
<RenatoSilva> angasule: tell me, are they the GNOME developers uahuhauhaaaaa
<RenatoSilva> pochu: it's not a need
<RenatoSilva> pochu: suggestions
<RenatoSilva> pochu: but before i need to now a thing
<RenatoSilva> pochu: is GNOME customized on Ubuntu?
<RenatoSilva> pochu: coz the suggestions is about gnome
<mjg59> Gnome is lightly customised, but most of the code is from gnome.org
<RenatoSilva> well the suggestions are
<RenatoSilva> 1) create a special theme format
<RenatoSilva> actually
<RenatoSilva> just change the extension from tar.gz to .theme
<RenatoSilva> so that user click over the downloaded file
<RenatoSilva> and it installs automatically
<RenatoSilva> just like .debs do
<mjg59> That would have to be a change in upstream gnome
<RenatoSilva> so i'd have to tell them this not you?
<bluefoxicy> just create a content handler
<bluefoxicy> when you click .tar.gz it opens it
<RenatoSilva> and add a remove button on the main theme window, not the details windows
<bluefoxicy> and sees if it has a specific directory structure
<bluefoxicy> if it does, okay!
<bluefoxicy> if not, file-roller
<RenatoSilva> bluefoxicy: it's not for me, it sshould be a defaulkt behavior
<Mithrandir> bluefoxicy: that's hacky, it should rather be another mime type.
<Mithrandir> IMNSHO.
<mjg59> RenatoSilva: Yes, discussing this with Gnome people is probably a better bet
<bluefoxicy> Mithrandir:  another MIME type would wtf me
<RenatoSilva> mjg59: thanks
<bluefoxicy> I look at rpm + deb and I'm like "WHY THE HELL DOES TAR + GZIP NOT OPEN THIS!?"
<RenatoSilva> mjg59: do you know the gnome channel?
<bluefoxicy> I spent hours trying to figure out how to get rpm to unzip a .rpm file instead of installing it
<bluefoxicy> (I still don't know)
<RenatoSilva> bluefoxicy: .debs are just tar.gzs?
<RenatoSilva> bluefoxicy: i didn't know that
<bluefoxicy> RenatoSilva:  I thought they were but they're apparently not.
<bluefoxicy> tar.gz or tar.bz2 with special directory structure
<bluefoxicy> apparently not so.
<Mithrandir> no, they're not
<kylem> ...
<kylem> please stop spreading misinformation.
<kylem> bluefoxicy, btw, rpm2cpio.
<bluefoxicy> I still can't imagine what prompted all these package developers to create their own package format
<mjg59> bluefoxicy: deb is designed to allow you to get at the metadata without having to scan the entire archive
<mjg59> That would be impossible with a plain tarball solution
<bluefoxicy> mjg:  ah, you can't force that to reside in the first file in the tarball?
<mjg59> I've no idea what the rpm people were thinking. "Yummy crack", possibly.
<imbrandon> .deb's are an ar archive with a control.tar.gz and data.tar.gz inside
<stgraber> .deb are in fact "ar" archives with .tar.gz inside of them
<stgraber> :(
<imbrandon> ( would help to read the docs hehe )
<stgraber> imbrandon: you were faster
<bluefoxicy> ah
<stgraber> after : ar x package.deb you have : control.tar.gz  data.tar.gz  debian-binary
<imbrandon> ar -x blah_i386.deb data.tar.gz
<imbrandon> yea
<stgraber> control.tar.gz containing the install scripts
<stgraber> and data.tar.gz the files themself
<stgraber> and data.tar.gz the files themselves
<bluefoxicy> did not know all that.
<bluefoxicy> I thought someone slapped a header onto a tarball
<kylem> no. quite a bit more thought went into it than that.
<imbrandon> bluefoxicy, might be good to read the debian maint guide if your gonna hang in the -dev chan :)
<bluefoxicy> imbrandon:  I've read it 5 times, I just never retain it.
<RenatoSilva> people if you don't fork gnome
<bluefoxicy> no
<bluefoxicy> no forks of something giant like gnome
<RenatoSilva> so what you do in ubuntu?
<bluefoxicy> I will kill you
<imbrandon> afaik rpm is in a similar situation but i dont know the specifics ( i'm sure a quick google will come up with the info though )
<imbrandon> RenatoSilva, why would we fork gnome ?
* imbrandon see's no point in that statement
<RenatoSilva> imbrandon: coz a suggestion i have changes gnome
<bluefoxicy> a suggestion you have adds a load of development overhead and incompatibility
<imbrandon> RenatoSilva, would probably be better sent upstream then, forking isnt commonplace
<RenatoSilva> imbrandon: but i don't believe, as Linus do, that gnome people will give me attwntion
<RenatoSilva> attention
<RenatoSilva> imbrandon: AND
<_lemsx1_> RenatoSilva: did you try to get their attention?
<RenatoSilva> imbrandon: synaptic has thousands of forks
<imbrandon> RenatoSilva, then get some like minded people togather and work on it your selfs but ubuntu devs already have enough on their plate to take on such a huge project
<RenatoSilva> _lemsx1_: i will
<bluefoxicy> imbrandon:  ubuntu-minix :D
<bluefoxicy> *ducks*
<RenatoSilva> _lemsx1_: i know i cannot judge them
<RenatoSilva> imbrandon: ok
<RenatoSilva> imbrandon: but what you do exactly if don't touch in gnome?
<imbrandon> besides generaly ubuntu works "with" upstream , not against them, so if they reject it we will likely too ( there are exceptions )
<mjg59> This discussion really isn't appropriate here at this point
<imbrandon> mjg59, +1
<mjg59> Please move it to either -offtopic or the appropriate project channel
<RenatoSilva> imbrandon: i thought gnome was already forked by you because of the lot of software that is so (looks like everything, because of the "ubuntu" atachment on version)
<RenatoSilva> imbrandon: and also, in ubuntu, gnome doesn't have special permissions: st
<RenatoSilva> mjg59: what?
<bhale> RenatoSilva: mjg59 asked nicely.
<imbrandon> RenatoSilva, as mjg59 asked , this is no longer really appropriate here
<RenatoSilva> dont misunderstand me please
<mjg59> RenatoSilva: This discussion is off-topic on this channel. Please take it elsewhere.
<RenatoSilva> i have a question
<RenatoSilva> not a discussion
<imbrandon> brb afk
<RenatoSilva> the question is
<RenatoSilva> is GNOME a totally true version from GNOME community, or did you do some changes??????
<bhale> every distro does changes, but that discussion is off-topic
<pochu> RenatoSilva: <mjg59> Gnome is lightly customised, but most of the code is from gnome.org
<bluefoxicy> it's branded
<pochu> RenatoSilva: if you want that change, you should talk the gnome developers, not the ubuntu ones
<RenatoSilva> 2) why SUSE's GNOME do have S/UGID/Sticky bit and Ubuntu's GNOME doesn't?
<bluefoxicy> that's about it
<RenatoSilva> pochu: thanks, the end.
<bluefoxicy> (2) is because they're smarter than to SUID everything willy-nilly here.
<RenatoSilva> people dont' misunderstand i'm not a flammer
<bluefoxicy> ........
<bluefoxicy> you heard it here folks
<mjg59> bluefoxicy: Please be quiet.
<RenatoSilva> bluefoxicy: don't understand
<pochu> RenatoSilva: no problem, but just this is not the appropiate channel :)
<stgraber> Novell certainly patched it or if this is in upstream, Ubuntu choosed to disable that (maybe you can enable it through gconf-editor)
<RenatoSilva> bluefoxicy: people are telling me will kick me off
<mjg59> RenatoSilva: We make very few changes to upstream gnome, most of which are simply branding (adding Ubuntu logos). I've no idea why SUSE is different to Ubuntu in this respect.
<stgraber> but it's not the channel for that kind of question, #ubuntu or #ubuntu-offtopic are way better for that
<mjg59> RenatoSilva: You're not being accused of being a flamer. You're being told that this is the wrong place for this discussion.
<bhale> no one said they would kick you off, the topic of this channel is very specific.
<RenatoSilva> mjg59: so the special permissions is NOT an original feature of GNOME, but instead, SUSE actually has did a fork of it?
<RenatoSilva> mjg59: i'm not discussion as i've said
<RenatoSilva> discussing
<RenatoSilva> are NOT
<stgraber> not a fork, a fork means you do everything twice, you are completly separated from upstream, what they do and what Ubuntu does is patching upstream version
<stgraber> maybe Novell patched gnome with a patch that was refused upstream
<mjg59> RenatoSilva: I have no idea. This isn't the place to talk about it.
<stgraber> that's still not a fork
<RenatoSilva> mjg59: why this is not the place to ask wheter original GNOME has "st" or not?
<RenatoSilva> mjg59: since you're involved with GNOME
<mjg59> RenatoSilva: Because we don't develop the original gnome. Ask the gnome developers.
<RenatoSilva> mjg59: So...
<mjg59> RenatoSilva: #gnome on irc.gnome.org
<bhale> ask the gnome developers in a forum appropriate to them.
<RenatoSilva> you don't know completely this feature?
<bluefoxicy> wow
<mjg59> bluefoxicy: Ssh.
<RenatoSilva> ok
<RenatoSilva> so i ask them and suse
<bluefoxicy> mjg59:  into what?
<RenatoSilva> it's simple
<mjg59> RenatoSilva: Yes.
<bhale> please also be sensitive to the connotation of "fork"
<RenatoSilva> you don't need to hurt me
<RenatoSilva> bhale: ok
<bhale> it is somewhat inflamatory when used incorrectly
<RenatoSilva> bhale: i think anything is different from original is a fork
<RenatoSilva> bhale: such that special permissions
<RenatoSilva> so...
<stgraber> xorg is a fork of XFree, beryl is a fork of compiz. But Ubuntu's gnome isn't a fork of gnome, it's just gnome+a few patches
<RenatoSilva> if gnome suggestions are not suitable here
<mjg59> Sorry, it's clear that something has gone horribly wrong with the internet
<RenatoSilva> what kind of them i can make here?
<mjg59> And that when people say that they've heard what I'm saying, these responses are being generated by some intermediate machine rather than the person they appear to be from
<imbrandon> this really isnt the place for any sugestions
<Treenaks> mjg59: must be your internet, mine's fine :P
<mjg59> There's no other explanation for why 3 billion people would all say "Yes, this discussion is inappropriate here" and then carry on with it anyway
<RenatoSilva> imbrandon: people from ubuntu-br told me it is
<RenatoSilva> imbrandon: sorry
<mjg59> Is there?
<imbrandon> mjg59, nope
<mjg59> Excellent.
<bluefoxicy> mjg59:  sometimes when you work in support, you just have to answer the customer's questions to get him to go away
<RenatoSilva> imbrandon: so what is this all about?
<bluefoxicy> mjg59:  on the other hand, this isn't a support channel, and there are no customers.
<imbrandon> RenatoSilva, this channel is for the developers of ubuntu to collaborate on packaging 
<imbrandon> nothing more
<RenatoSilva> imbrandon: where can I make suggestions for features in Ubuntu? 
<bluefoxicy> launchpad
<bhale> launchpad.net
<mjg59> bluefoxicy: No, please, be quiet.
<imbrandon> www.ubuntuforums.org or launchpad.net are good places to start
<RenatoSilva> imbrandon: so it's suitable for me only if i'm a develofer of ubuntu?
<bhale> RenatoSilva: you can suggest things by filing bug reports or writing specs, both are handled by launchpad.
<RenatoSilva> imbrandon: thanks
<imbrandon> no non-devlopers can collaborate with the developers if it pertains to pakaging for the release
<RenatoSilva> thanks all of you
<imbrandon> but this isnt such a topic thus needs to cease
<RenatoSilva> imbrandon: what?
<RenatoSilva> ubuntu is written in C or C++?
<bhale> RenatoSilva: last warning
<hagi> lol
<bhale> RenatoSilva: please move along.
<imbrandon> in short, you dont have to be a developer to be here but you have to stay on topic and as stated many times this isnt on topic, nor is an questions that dont specificly pertain to packaging ubuntu
<RenatoSilva> i have to go
<RenatoSilva> bye
<bhale> stupid CoC
<imbrandon> wow i dont know how much simpler i could have said it , nor bhale or mjg59 heh
<stgraber> :)
<bhale> that happens semi-reguarly, its hard to try to placate them and send them on their way without just getting mean or using force
<bluefoxicy> bhale:  You're just still used to banning me every 10 minutes.
<mjg59> bluefoxicy: Really, I'm serious. If you don't have anything topical to say, then please don't say it.
<fabbione> java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
<fabbione> i guess there is no workaround for this one...
<bhz_> I will pay $20 via paypal if you DoS someone for 5 hours. will pay $4 every hour. message me if interested
<mhb> hello everyone; can someone point me to the information about why the new control center disappeared?
<mhb> I tried to ask at #ubuntu+1, but nobody knew
<phanatic> mhb: was disabled by upstream (gnome)
<phanatic> mhb: but you can still run gnome-control-center to get the integrated view
<mhb> phanatic: yes, I know
<mhb> phanatic: but its not the same as having it available for the common user
<mhb> phanatic: does that mean Ubuntu Feisty final will also stick to the old menu?
<phanatic> since gnome 2.18 will probably ship with the old one, my answer would be yes, but i'm not an ubuntu gnome maintainer...
<mhb> too bad
<mhb> I must say Ive read a lot of positive feedback about it
<jdong> mhb: heh I've heard more negative feedback about it
<mhb> one way or the other, I guess you folks should make an info page for the users stating why it got dropped
<phanatic> i don't think it's ubuntu business... i mean it was decided by upstream not to ship it by default
<imbrandon> that and it was never shiped in a stable release, no need to explain decesions that were never released
<phanatic> imbrandon++
<zoli2k> Hi, I want to build a small USB ubuntu distro based on  edgy and squashfs. I think the easiest  way to derive it from the ubuntu livecd. Where can I get a base root compatible with casper?
<jdong> zoli2k: https://help.ubuntu.com/community/LiveCDCustomization/6%2e06
<jdong> zoli2k: I think the Dapper instructions are still applicable
<zoli2k> jdong: The problem is that I am not able to purge x11-common from the livcd root. There are 9 unresolvable dependencies, aptitude says.
<jdong> zoli2k: oh. Probably because parts of casper scripts call x11-common
<Funcod> Hi
<Funcod> is there anyone here whos working on the ubuntu website?
<jdong> zoli2k: x11-common is only like 300KB, right?
<Funcod> theres a problem in the rendering of the homepage in ie 6
<Funcod> there's an enormous gap
<Funcod> and if u scroll down a lot
<Funcod> u see the content
<zoli2k> jdong: I would like to purge also all  X and gnome related apps
<jdong> zoli2k: you should be able to purge all of those without incident
<jdong> zoli2k: or enough of X such that the remainder doesn't take up significant space
<Funcod> since ur tryin to make ppl swith from windows you should fix that ...when they arrive on the website they see an empty page
<jdong> Funcod: hmm I recall the site working fine in IE6
<Funcod> exept the top and right pane
<jdong> unfortunately I don't have IE6 atm
<jdong> I've only got 7 on Vista
<Funcod> u want a screenshot?
<jdong> is that worth testing?
<jdong> no, I believe you
<jdong> besides, I don't work on the website so I couldn't do much anyway :D
<Funcod> well since i wont last long here
<zoli2k> jdong:  Ok, I will do in this way. Is there a way to boot to squashfs withot casper?
<Funcod> its a major problem i think
<Funcod> u arrive and theres only a white background
<jdong> zoli2k: well casper sets up the system to be bootable.
<jdong> zoli2k: I guess you _can_ remove casper but keep all the files on :D
<Funcod> well hum no one care about it then?
<jdong> Funcod: there's not really anyone around
<jdong> Funcod: bad timing :(....
<Funcod> can i give u ss
<ScottK> I can confirm the web site issue with IE6 running on crossover-office on Dapper.
<Funcod> and u give them?
<jdong> Funcod: try e-maililing the webmmaster?
<Funcod> theres no email
<jdong> ScottK: ok
<Funcod> on the website
<Funcod> i think
<Funcod> or its hidden
<Funcod> :)
<jdong> ScottK: does it happen in newer IE's?
<Funcod> and i though the admin was here
<ScottK> Dunno all I have is IE6 on crossover/wine.  I have no Windows.
<Funcod> scottk
<Funcod> u can tell em about it?
<ScottK> Not me.
<Funcod> :/
<Funcod> oh well np
<Funcod> ull lose a lot of custumers thats all :p
<Funcod> -u+o
<zoli2k> jdong: Thx for your help.
<ScottK> Funcod: You might have more luck in #ubuntu-marketing.
<Funcod> lol
<Funcod> #ubuntu told me to come here
<Funcod> and now u tell me to go there :p
<ScottK> Funcod: I'm not sure.  It's just a thought since you're getting no traction here.
<Funcod> k
<niktaris> cjwatson, how do I edit the gtk interface of ubiquity. I tried glade but can't get pass the second screen
<cjwatson> doko: er, it does - except maybe not for amd64, which is a bug that should be easy to correct in the Makefile
<cjwatson> niktaris: make sure to use glade-3, get to the 'steps' widget in the inspector, and edit the page number
<funpop> guys get of your screen from time to time, we got lunar eclipse 3/3/2007
<niktaris> cjwatson, thanks
<doko> cjwatson: hmm, no (I don't mean the floppy devices, but /dev/std{in,out,err}
<cjwatson> doko: why are those needed? debootstrap intentionally creates rather few devices and leaves the rest to frontends such as udev
<cjwatson> doko: anyway, actually, it already should create thosse
<cjwatson> DEVS := generic hde hdf hdg hdh sde sdf sdg sdh scd-all initrd input usb md lp rtc video \
<doko> cjwatson: bash autoconf test, so everytime I build bash in a new chroot, I re-remember to create the devices
<doko> I think infinity did add the creation of these to the buildd setup
<cjwatson> generic => generic-i386 => fd => /dev/fd as symlink to /proc/self/fd and /dev/std{in,out,err} as symlinks
<cjwatson> so it's definitely meant to do that already, provided that /proc is mounted
<doko> but debootstrap mounts /proc ... wondering
<cjwatson> doko: only while it's bootstrapping, and then it unmounts it just before exiting
<cjwatson> you probably just need to mount it again?
<cjwatson> testing here
<doko> just created a new chroot, no /dev/stdin
<cjwatson> any devices at all?
<doko> yes, it creates devices, but no /dev/stdin
<cjwatson> oh, hmm, I see, it's only in devices.tar.gz (which is the one used in the udeb)
<cjwatson> you can't just bind-mount /dev or something?
<cjwatson> anyway, I don't particularly mind you adding fd to devices-std.tar.gz, I just don't want it creeping back up to be essentially devices.tar.gz since that would be a considerable divergence from Debian
<cjwatson> having stuff like /dev/stdin seems fairly reasonable though
<cjwatson> (although since you need to mount /proc, mounting /dev is a pretty small extra step)
<doko> yes, sure, mounting /proc is standard procedure, calling MAKEDEV as an extra step maybe not. I'll add it tomorrow
<cjwatson> not calling MAKEDEV, but bind-mounting /dev
<cjwatson> I didn't say calling MAKEDEV
<doko> ahh, ok
<hunger> Any idea why pam_mount no longer works for partitions protected by a openssl encrypted key?
<hunger> It did work on since breezy.
<cypherbios> pochu: nice portuguese :)
<pochu> cypherbios: ty ;)
<cypherbios> pochu: where are you from?
<pochu> cypherbios: spain
<pochu> cypherbios: I now nothing about portuguese, but it's a little similar to spanish :)
<cypherbios> pochu: oh, it explains :)
<pochu> hehe
<pochu> though I had to search one word (folder) in the dictionary :)
<_lemsx1_> cpio: ./etc/udev/rules.d/*-lvm.rules: No such file or directory
<_lemsx1_> i saw that while upgrading to Feisty
<_lemsx1_> that was the only hiccup. everything else is fine
<_lemsx1_> time to reboot
#ubuntu-devel 2007-03-04
<okaratas> i prepared a deb packet for ubuntu which is not in the archives. how can i send this to archives? what should i do?,
<pochu> okaratas: you may want to ask in #ubuntu-motu ;)
<Hobbsee> okaratas: we're in a freeze, which means we're not accepting any new stuff, for the rest of feisty.  for more info, see !feisty.  Also, feisty uses sources, not binaries into the archive.
<Hobbsee> okaratas: you'll find lots more information in the topic in #ubuntu-motu including https://wiki.ubuntu.com/MOTU/Documentation
<okaratas> thank you very much Hobbsee and pochu 
<Hobbsee> :)
<pochu> np
<cypherbios> someone knows what is the sintax parsed by Udate Manager to create a link to an bug in the change log viewer embed on update-manager? i.e: LP:#89325 links to https://launchpad.net/bugs/89325
<Ubugtu> Malone bug 89325 in aptoncd "returns to the beggining if the user hasn't enough rights to save the folder" [Undecided,Unconfirmed]  
<cypherbios> I just need to put on changelog '* closes LP:#89325' and update manager will show an link to the corresponding bug automatically ?
<pochu> Seveas: ping?
<Seveas> pochu, ?
<pochu> Seveas: I've read you are the irc cloak man, aren't you? :)
<Seveas> pochu, please use #ubuntu-devel only for development issues
<pochu> ups
<pochu> I tought I was on -locoteams :)
<pochu> sorry
<jdub> Mar  4 19:25:30 localhost named[2603] : rdata.c:799: REQUIRE(source != ((void *)0)) failed
<jdub> awesome
<jdub> whoa
<jdub> only does it on waugh.id.au
<jdub> and other waugh.id.au A records
<jdub> but not other domains on that nameserver
<_ion> Interesting. :-)
<jdub> it is bizaarely reliable
<jdub> in both ways ;)
<lucas> is there an svn repository or something for apt ? I'd like to browse the history to track down a bug
<Mithrandir> it's in bzr, iirc
<lucas> do you have the branch url ?
<Mithrandir> http://bazaar.launchpad.net/~ubuntu-core-dev/apt/ubuntu, it seems
<lucas> thank you
<Mithrandir> there's one on people.debian.org/~mvo/apt too, if you want the debian one.
<Mithrandir> I believe they're quite close
<lucas> the change I'm looking for is quite old, so it shouldn't matter
<g0su> one question please, what is the diference between /etc/environment and /etc/default/locale for LANG and LANGUAJE variable?
<geser> afaik is /e/d/l the new location but not all programs use it already
<mojo> Does anyone know why public_html does not work with apache2 on Feisty Fawn Herd 5? I received 404 Not Found Error when typing http://localhost/~<username>
<elkbuntu> mojo, this channel is for development, not troubleshooting. try in #ubuntu+1
<mojo> okay, those ppl in #ubuntu ask me to ask it here
<geser> tepsipakki: are you around?
<tepsipakki> geser: not for long
<tepsipakki> what's up?
<g0su> i think than this question is more for develops XP
<g0su> why two files(/etc/default/locale /etc/environment) change the same variable(LANG and LANGUAGE)? or Why /etc/event.d/rc-default search(in elif) /etc/inittab if inittab not exist?
<geser> tepsipakki: can you fix the dependency in xserver-xorg to depend on xserver-xorg-video-all | xserver-xorg-video-1.0 as the new video drivers provide now xserver-xorg-video-1.0?
<tepsipakki> ah that
<tepsipakki> we forgot to do that :)
<geser> currently you can only install the video-all meta package because of this
<tepsipakki> right
<geser> thanks
<tepsipakki> we'll make it xserver-xorg-video-all | xserver-xorg-video-1.0 | xserver-xorg-video
<tepsipakki> maybe that makes upgrades a bit smoother
<tepsipakki> kylem: ^^
<g0su> One question, you need to install xerver-xorg-video-all for have xserver-xorg?
<tepsipakki> I have to go now ->
<g0su> in herd 4 i think no
<geser> g0su: xserver-xorg-video-all is only preferred
<geser> but currently the dependency is broken and can only be fulfilled with the video-all package
<g0su> root@DarkTemplar:~# aptitude show xserver-xorg | grep Estado
<g0su> Estado: instalado
<g0su> root@DarkTemplar:~# aptitude show  xserver-xorg-video-all | grep Estado
<g0su> Estado: sin instalar
<g0su> sin instalar = not install & instalar = install :) geser this is now in herd 5?
<geser> g0su: you can also only keep the needed video-drivers and deinstall video-all and the other not needed video-drivers
<geser> xserver-xorg depends on xserver-xorg-video-all | xserver-xorg-video and the later is provided by the individual video-drivers
<g0su> yes i understand this
<Lathiat> wow http://www.addonics.com/support/faqs/faq-pmsupport.asp
<Lathiat> shipping ubuntu 6.06 lts drivers for their port multipliers
<Lathiat> first time ive seen !redhat drivers shipped by a vendor
<g0su> jajajaj
<Lathiat> hrm custom compile instructions tho, good thign is that its in patch form and not binary
<g0su> Ei have any explain me why i have 2 files with the same variables x) http://paste.ubuntu-nl.org/8579/ i dont understand why i cant choose my locales :X
<Lathiat> g0su: it doesnt matter what locales are generated its largely irrelevant as long as the ones you want are in there
<g0su> Lathiat, yes but the locale en_EN dont create it. Sorry for take your time. I am searching but i dont fount the information. 
<geser> what should en_EN be?
<g0su> i wont to delete all es_X exp es_ES.UTF-8 and create en_EN.UTF-8
<g0su> i want to delete all es_X except es_ES.UTF-8 and create en_EN.UTF-8. Sorry for my english X(
<geser> g0su: I don't know if such a locale (en_EN) exists
<g0su> en_EN.UTF-8
<g0su> english_ENGLISH :D
<cliebow_> anyone else having trouble using 2.6.20-x in sony laptop..initramfs stops after discovering memory stick applinace..
<Seveas> g0su, the EN in en_EN does not exist, there is no country called ENGLISH
<Keybuk> en_GB is British English
<Keybuk> en_US is American
<_ion> And en_FI is what I speak.
<kylem> en_US.redneck
<cliebow_> redneck??
<kylem> cliebow_, what kind of memory stick?
<geser> kylem: did you catch the discussion about the wrong dependency in xserver-xorg?
<kylem> geser, er... i think it was occuring as i woke up.
<kylem> so i probably saw it, but didn't grok it. :)
<geser> xserver-xorg depends on  xserver-xorg-video-all | xserver-xorg-video but the new video drivers provide now xserver-xorg-video-1.0
<geser> tepsipakki suggested to change the dependency to xserver-xorg-video-all | xserver-xorg-video-1.0 | xserver-xorg-video
<kylem> ok.
<kylem> tepsipakki, any objection to renaming the i810 package to -intel for clarity?
<geser> can you do a fixed upload?
<geser> wasn't there once an -intel package?
<cliebow_> well there is no stick in it..it finds the slot..msc...lemme boot it
<kylem> -intel-modesetting is in universe.
<kylem> cliebow_, if it's tifm7xxx or something, just add it to modprobe.d/blacklist and file a bug plz.
<kylem> geser, sure.
<geser> -intel is in edgy and was replaced with -i810-modesetting in feisty
<cliebow_> scsi 0:0:0:0 direct access Sony MSC-U03 2.00 PQ ANSI:0 CSS
<cliebow_> scsi generic sg0 type 0
<kylem> mjg59, you've got a bug. :)
<cliebow_> wil do
<bddebian> doko: You aboot?
<kylem> geser, is there a bug # for this?
<Keybuk> kylem: I'm completely confused about which is the current intel/i810/modesetting drier too :p
<geser> for the dependency problem?
<kylem> Keybuk, yes, this is what i'm trying to solve.
<kylem> geser, yeah.
<mjg59> -intel is the one I uploaded. It's installable in parallel with i810.
<mjg59> i810-modesetting is the one synced from Debian. It's more up to date, but can't be installed in parallel
<geser> kylem: not that I know of (I didn't file one yet)
<Keybuk> mjg59: -intel replaces both i810 and i810-modesetting?
<doko> bddebian: ?
<kylem> ok.
<mjg59> Keybuk: ?
<Keybuk> mjg59: I have i810-modesetting installed atm, do I need to change that to a different driver? :p
<bddebian> doko: I was going to ask you about mpichpython but I found it.  Though I still don't understand the error I'm getting.
<mjg59> I don't know. What are you trying to do?
<Keybuk> mjg59: use X.
<Keybuk> mjg59: I just want to know what the "correct" driver out of the maze of different ones is
<mjg59> There doesn't seem to be any context to this discussion.
<mjg59> The "correct" driver is i810.
<geser> how many intel/i810 dirvers do we have currently? 2 or 3?
<mjg59> -modesetting and -intel are two different packagings of the modesetting branch of the i810 driver.
<Keybuk> ok, why the renaming?
<mjg59> 15:55 < mjg59> -intel is the one I uploaded. It's installable in parallel with  i810.
<mjg59> 15:56 < mjg59> i810-modesetting is the one synced from Debian. It's more up to  date, but can't be installed in parallel
<Keybuk> but why rename it?
<Keybuk> why not just update the i810-modesetting package to be parallel installable without downgrading it? :p
<mjg59> When we're talking about three different packages, "it" doesn't bind usefully
<geser> mjg59: is -intel back now?
<tepsipakki> upstream is going to rename -i810 to -intel
<tepsipakki> some time
<Keybuk> hmm
<Keybuk> I think he exploded
<geser> tepsipakki: are there any plans to update the -i810-modesetting driver?
<tepsipakki> geser: sure
<Keybuk> so, is the -i810-modesetting driver more up to date than the -intel driver, or the other way around?
<tepsipakki> Keybuk: the other way around atm
<tepsipakki> oh, and it's still -i810 not -intel
<Keybuk> err, what?
<geser> Keybuk: see bug #75480
<Ubugtu> Malone bug 75480 in xserver-xorg-video-intel "Please remove the xserver-xorg-video-intel source and binary packages from Ubuntu Feisty universe (superceded by xserver-xorg-video-i810-modesetting)" [Undecided,Fix released]  https://launchpad.net/bugs/75480
<tepsipakki> oh, so there was -intel already
<Keybuk> yes
<bddebian> Is "1.*Numeric.arrange(10)" valid Python?
<Keybuk> there's -intel, -i810 and -i810-modesetting, all of wildly different versions
<tepsipakki> then maybe it's best to rename only when the modesetting-branch is merged in
<Keybuk> and, unless I'm totally confused, mjg59 has made a new -intel again
<rpereira> Does someone know if the instability with Firefox and Flash (nonfree) was resolved on Edgy? Or on Feisty?
<tepsipakki> Keybuk: hmm, can't find it so maybe not uploaded yet
<Keybuk> <mjg59> -intel is the one I uploaded. It's installable in parallel with i810.
<Keybuk> <mjg59> i810-modesetting is the one synced from Debian. It's more up to date, but can't be installed in parallel
<tepsipakki> doesn't say when :)
<geser> he uploaded -intel to edgy, perhaps he is referring to that upload
<tepsipakki> yes
<tepsipakki> fedora already renames -i810 as -intel
<_ion> tepsipakki: Does your nick mean something, btw? :-)
<tepsipakki> _ion: you should know ;)
<_ion> tepsipakki: Well, it looks like Finnish, but i have no idea what a "tepsi" is. :-P
<tepsipakki> in that case you don't like sports much ;)
<_ion> (Or how a box is related to one.)
<_ion> Good observation. :-)
<tepsipakki> tepsi=TPS, pakki=defenseman (in ice-hockey)
<_ion> Ah, ok. :-)
<tepsipakki> why I got it is left as an exercise (no, it's not pretty)
<kylem> Subject: Accepted xorg 1:7.2-0ubuntu2 (source)
<geser> kylem: thanks
<tepsipakki> thanks
<kylem> ok
<lfittl> iwj, zul told me you could probably help me with some strange xen + lvm problem (details at bug #89133)
<Ubugtu> Malone bug 89133 in xen-source "Problem with blktap and LVM (device numbers)" [Undecided,Needs info]  https://launchpad.net/bugs/89133
<sladen> woo, 48hours of network-manager before I needed to kill it
<_ion> Months of network-manager since i last needed to kill it. :-)
<jdong> *URG*
<jdong> Bad Prank Of The Day: set shell to /usr/bin/wine cmd.exe
<_ion> Haha
<jdong> grr how do I start a real shell
<jdong> yes!
<jdong> z:\bin\bash
<jdong> is this how Windows users feel when I give them cygwin prompts?
<_ion> They get the "OMG, it's full of stars!" feeling after only having used the CLI equivalent of poking a pile of dog poo before.
<jdong> :)
<bhale> if you can call it a CLI
<jdong> meh at least Vista can have a GNU environment...
<jdong> it's a slight improvement
<bhale> hm?
<jdong> Vista SUA
<jdong> you can run most of the GNU userland
<jdong> (though by default they install SVR5 and BSD... pfft)
<jdong> it seems to perform pretty natively too
<jdong> as opposed to Cygwin
<bhale> most of the win32 network tools are BSD
<jdong> should I torture myself and use Vista for the day?
<frafu> hello, 
<frafu> I would like the drag&drop in Ubuntu to behave a bit differently: I think the best is if I give an example: 
<frafu> Let us assume we have to nautilus windows on the desktop: let's call them wina and winb. The windows are placed so that winb is partly covered by wina. In other words, wina is the front window. 
<frafu> Now I want to drag and drop an item from winb to wina. Now comes what I don't like: 
<frafu> When I click on the item in winb to drag it to wina, winb comes to the front. This is what I don't like and what I am not used to on my mac: a drag&drop should not change the order of the windows. 
<frafu> Now my question: who is responsible for the drag and dtop? Gnome? Should I file my request directly in gnomes bugzilla? 
<mjg59> It's nothing to do with drag and drop behaviour
<mjg59> That's handled by the window manager
<frafu> ok, metacity
<mjg59> But yes. It's the sort of change that we'd probably want upstream to consider
<mjg59> So feel free to file an enhancement bug in launchpad, but the best bet is probably to discuss it with the upstream developers
<mjg59> I'm pretty sure that it's metacity that's responsible, anyway...
<frafu> so I should go directly to the devs of metacity
<mjg59> Yeah. I think the easiest way of fixing it would be to require button release before raising the window
<mjg59> Though I haven't looked into the problem closely. I may be misinterpreting it.
<frafu> I will try to find the devs of metacity. Thank you. 
<frafu> Isn't metacity being replaced by a composite window manager? 
<frafu> in the next release? 
<pochu> frafu: it's installed by default, though it isn't enabled by default
<frafu> does anybody know the drag and drop behaviour of the new window manager? 
<frafu> There might be no point in asking for a change in metacity when Ubuntu is going to use another window manager 
<frafu> !? 
<pochu> frafu: if you think that is better, ask in the two places :)
<frafu> could you give me the name of the new window manager? Or has the decision not been taken yet (there were two possible candidates as far as I know) 
<alex-weej> frafu: Compiz
<frafu> Indeed, I think that it is better when the windows do not change order, because the user sees before he starts the drag&drop if the starting point and the endpoint of the drag&drop are within reach. 
<frafu> Does compiz behave like metacity or like a mac? 
<frafu> If the drag&drop in compiz behaves like the macscdrag&drop, there is no need for me to contact them. 
<frafu> Anyway, many thanks to all. 
<_ion> frafu: There's some usability work going on re: copypasting and drag&drop: http://images.mandriva.com/metisse/copy-paste-simple.avi
<frafu> _ion: in the demo, the windows don't change their order, but it is not clear how the system distinguishes between a simple click and the paste
<frafu> On the other hand, the demo shows that the order of the windows does not change when doing a selection 
<frafu> This is an old issue: 
<frafu> http://bugzilla.gnome.org/show_bug.cgi?id=80984
<Ubugtu> Gnome bug 80984 in EWMH specification "Develop specification for not raising drag source windows during the drag." [Enhancement,New]  
<frafu> And for what I could understand, the usual behaviour of a window manager is to not raise the window from which the drag&drop starts
<frafu> So chances are that compiz does not do it and behaves the way I want it. 
<supervillain> Hi, can I ask about Ubuntu SoC 2007 related topics here?
<pochu> supervillain: soc?
<supervillain> yes, I like to know what are the qualifications of a mentor for SoC 2007?
<pochu> supervillain: I don't know, but maybe you can take a look here: https://wiki.ubuntu.com/GoogleSoC2007
<pochu> supervillain: and this: http://code.google.com/soc/ubuntu/about.html
<supervillain> Is it possible to recommend someone to be a mentor for an Ubuntu project?
<Amaranth> supervillain: no, someone can volunteer though
<supervillain> Is it possible to join several projects at the same time?
<supervillain> for SoC
<shiyee> supervillain: you can apply for multiple projects, but you only get accepted for one
<illovae> yo
<pascal> In what way are the entries in the hardware database http://hwdb.ubuntu.com/ used? I'm not able to access even my own
<snoogie> evening
<snoogie> y aurait il un franais :D ?
<snoogie> hello I want to ask a sutpid question maybe
<snoogie> :D
<snoogie> so please forgive me if it is one :)
<snoogie> Suppose I found a soft that feisty need and that I want to write 
<snoogie> I want to start a soft who is a bit similar :)
<snoogie> So my question is 1) If I start write it in C++/wxWidgets because I know this language and this toolkit but on launchpad I see they want pyGTK and Glade
<snoogie> will it be rejected if I submit a beta version ?
#ubuntu-devel 2008-02-25
<ScottK> slangasek: Thank you for fixing pinentry.
<mgunes> lool, could you look at bug #195257? why may it be that the fix (in Debian) hasn't made it into Ubuntu?
<ubotu> Launchpad bug 195257 in acpi-support "missing man page for acpi_fakekey" [Low,New] https://launchpad.net/bugs/195257
<lamont> mgunes: it could be because things don't automatically sync now (for the rest of the hardy development cycle...)
<mgunes> lamont, it's been fixed a year ago.
<lamont> heh
<slangasek> ScottK: sure thing
<warp10> Good morning
<dholbach> good morning
<ion_> morniÅ
<warp10> hey dholbach
<dholbach> hey ion_
<pitti> Good morning
<Mithrandir> hiya Martin
<pitti> pochu: hm, indeed that's actually supposed to work
<pitti> pochu: where did you put that file?
<pitti> jdong: filed wrongly in what way? If it's wrong, then it should be reported to the hal upstream guys, since many distros use that patch now and it works for many people
<pitti> jdong: it's ultimately a kernel problem, but if you have a specific case which could be worked around in hal, we can do that
<bryce> pitti: if you have a moment, I put in my core-dev application a few days ago and would greatly appreciate having your feedback about it on the motu-council list
<StevenK> Oooh.
<Mithrandir> pitti: thoughts on updating bluez-gnome and obex-data-server to 0.23 and 0.3?  They seem to work fine for me in light testing here at least.
<Mithrandir> pitti: it's blocked by getting o-d-s into main though
<pitti> Mithrandir: can't really judge without looking at changelogs at least
<pitti> Mithrandir: I can do the MIR today, though
<Mithrandir> pitti: bluez-gnome changelog: http://pastebin.com/f322f84e2 ; http://pastebin.com/f49eade61 for o-d-s
<Mithrandir> current bluez-gnome is 0.15
<pitti> Mithrandir: o-d-s looks good to me, if the impact of the ABI change is confined
<pitti> API
<pitti> Mithrandir: but I don't see any reverse dependencies, so that should be good?
<Mithrandir> pitti: new bluez-gnome depends on it, but nothing else.
<Mithrandir> o-d-s got through NEW about a week ago
<pitti> ah, then it can hardly break much already :)
<Mithrandir> indeed, but I figured I'd at least pass it by another release team member rather than just sneaking it in. ;-)
<pitti> Mithrandir: bluez-gnome looks fine, by and large bug fixes; did you test the two new features? (file sharing and file receiving)
<Mithrandir> pitti: I tested file sending, I'll test the two others before uploading.
<Mithrandir> (I need to dig out my laptop then, since my phone doesn't seem to have a usable obexftp client
<Mithrandir> )
<pitti> Mithrandir: cool; go ahead then
<Mithrandir> cheers
<Mithrandir> file receiving works just fine.  I'd like to have it forced to authenticate beforehand, but absolute worst case is somebody fills up your desktop with pr0n.
<stgraber> morning
<pochu> pitti: it's at /usr/share/apport/package-hooks/tracker.py
<pitti> pochu: that sounds correct
<pitti> pochu: ah, I bet I know
<pitti> pochu: there's a missing \ after the 'and'
<pitti> pochu: do you get this exception in /var/log/apport.log?
<pitti> not sure whether I got the logging right
<pitti> pochu: in the line-wrapped string, too
<pochu> pitti: I thought python didn't need those "\"
<pochu> pitti: thanks, I'll add it and test again :)
<pitti> pochu: it does; it heavily relies on correct whitespace and indentation :)
<seb128> hey there
<pochu> morning seb128
<pochu> pitti: oh, it's not needed for lists and the like, right?
<pitti> pochu: right, not within parenthesis, brackets, and braces
<pitti> hey seb128
<seb128> hello pitti pochu
<seb128> pitti: I didn't fix the retracer, it has a login error and I'm not sure if that's p-l-b error or if you need to reinstall a cookie or something
<pitti> seb128: ok, I'll have a look; thanks
<seb128> pitti: thanks
<pochu> pitti: oh, and yes, the crashes are listed in apport.log
<pitti> pochu: cool
<ScarFreewill> please excuse me being off-topic but I've been searching over an hour and I don't know where else to look, I'm trying to send Virtual Key Codes to my system but I've got no idea how to do this, does anyone know an open source appliction that does this? I'd like to do this in java, though i don't think this is possable so if i can do it in c/c++ and run it either through jni or runtime.exec, thanks for you time
<ScarFreewill> by the way, its for an alarm clock :-P
<geser> good morning
<pitti> hi geser
<geser> Hi pitti
<Mithrandir> mvo: any idea about a fix for https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/153980 ?
<ubotu> Launchpad bug 153980 in update-manager "7.04->7.10 "Upgrade" fails: "Getting upgrade prerequisites failed"" [High,Confirmed]
<mvo> Mithrandir: let me check
<Mithrandir> mvo: a friend of mine has the problem right now, so if you want him to test something for you, I can surely get him to post more info or test stuff for you
<mvo> Mithrandir: the error messsage is given for different error conditions, it may mean that the archive server/mirror refuses the connection, that for some reason there is a authentication error or no network is available, if your friend could give me the output of /var/log/dist-upgrade/main.log, that would be much appreciated
<asac> pitti: i have an action to figure out if we can produce ffox/xul/midbrowser locales out of launchpad somehow - even though there won't be a xpi export for hardy. my idea would be to map the locale chrome entities during build to .po files and then produce chrome jars from the .po files exported from launchpad. ok, what do you think in general? possible, impossible?
<Mithrandir> mvo: thanks; just asked him.  He might join here too.
<mvo> Mithrandir: thanks
<pitti> asac: there's a project which does that
<pitti> asac: formerly called 'pootle'
<pitti> asac: now it's something else, carlos knows
<asac> pitti: really?
<kolla> mvo: hello.. you want my main.log
<Mithrandir> mvo, meet kolla, kolla, meet mvo
<kolla> *nod* :)
<asac> pitti: well ... he didn't really know
<mvo> kolla: hello! yes please
<asac> pitti: so in general that should be possible. good.
<pochu_> pitti: what makes apport not send more than 3 reports (or whatever its limit is)? I'd like to test this tracker hook but apport seems to be ignoring tracker-extract crashes now, perhaps because I've crashed it enough :)
<pochu_> I don't have ~/.apport-ignore.xml
<pitti> pochu_: there's a counter in the /var/crash/tracker.crash file
<pitti> pochu_: just delete the file
<pochu_> thanks
<pochu_> "not a genuine Ubuntu package" -- I shouldn't have bumped the version to test it ;)
<tarzeau> hi geser
<geser> Hi tarzeau
<tarzeau> geser: can you make ubuntu have http://packages.ubuntu.com/bubbros ?
<geser> tarzeau: unfortunately not, as we are already in FeatureFreeze which also means no new packages anymore
<tarzeau> geser: pity, but maybe for after that?
<geser> for intrepid (= hardy+1) it should get autosynced
<tarzeau> geser: ok thanks
<pitti> thekorn: hm, current hardy p-lp-bugs seems to wildly mix 'attachment' and 'attachments' method attributes; you recently fixed that in trunk, right?
<pitti> seb128: ah, seems that p-lp-bugs trunk works
<seb128> pitti: ah, good
 * pitti installs that
<pochu_> pitti: oh, I need to scape the single-quoted sentence
<pochu_> SyntaxError: EOL while scanning single-quoted string
<pitti> right, what I said; just append a \
<pochu_> yay it works now :)
<pitti> pochu_: rock
<pochu_> pitti: thanks for the help
<pitti> pochu_: you're welcome, no problem
<thekorn> pitti, yes, the attachement(s) issues should be fixed in the trunk, hopefully
<pitti> thekorn: seems like it, a first test looks good; thank you!
<pitti> thekorn, seb128, bdmurray: phew, retracer is running again; I installed p-lp-bugs 'main' head into the hardy chroot, which seems to help
 * seb128 hugs pitti
 * thekorn hugs pitti 
 * \sh hugs slangasek for fixing ncurses...
<TheMuso> =/c
<seb128> hi TheMuso
<TheMuso> Hey seb128.
<seb128> TheMuso: there is new atk and at-spi tarballs to package if you want to do those updates
<TheMuso> seb128: Oh ok, thanks. I guess they'll appear on gnome-announce some time, but I'll get on them.
<seb128> TheMuso: not sure if every maintainer is using the list, but there is the ftp list which has all the uploads
<TheMuso> seb128: Ah ok, I'll get on that as well, thanks.
<seb128> you are welcome
<seb128> dholbach: there is a guy on #ubuntu-bugs which would like to discuss making 5-a-day easier, is there a chan or something where I could point him since you are not hanging there? ;-)
 * ogra_cmpc wonders whats th reason for gnbd to exist, it semms not to offer more than nbd
<ogra_cmpc> thegodfather, ^^ do you know ??? is there any extra feature gnbd has over nbd ?
<pitti> mvo: is there an equivalent for apt.Cache()[pkg].candiateOrigin for the installed version?
<Mithrandir> hm, why is it ps no longer sorts by start time?
<Mithrandir> (yes, I know this changed a while back)
<mvo> pitti: no and most of the time it would give anyhting interessting because apt does not store were a package came from. so if you have "foo 1.0" and "foo 1.1" and only 1.1 is in the archive, the information were 1.0 came from ist lost
<pitti> mvo: ok
<pitti> mvo: alright, I'll continue to use the candidateOrigin then; bdmurray pointed out that apport would currently file bugs for PPA packages
<pitti> mvo: component: 'main' archive: 'gutsy' origin: 'Ubuntu' label: 'Ubuntu' site 'ppa.launchpad.net' isTrusted: 'False'
<pitti> is what I get for a PPA package
<pitti> i. e. origin is still 'Ubuntu'
<pitti> mvo: should I rely on isTrusted==True?
<mvo> pitti: sounds like a bug in the ppa archive Release file to me
<pitti> mvo: well, it is a PPA for gutsy
<mvo> pitti: for now, until they change either origin or label
<pitti> I'm just not sure how to interpret these field
<pitti> mvo: what does isTrusted mean? that the release file could be verified using the archive keyring?
<mvo> pitti: yes
<mvo> pitti: that together with origin or label sounds like a good way to me
<pitti> hm, so using this might be a little too harsh?
<mvo> pitti: I would also suggest to ask PPAs to have a different origin or label than the main archive
<pitti> mvo: I'll file that bug on soyuz
<pitti> mvo: but anyway, for now, do you recommend "isTrusted==True && origin == Ubuntu" or "origin==Ubuntu && not site.startswith('ppa')" ?
<mvo> pitti: the later I would say
<pitti> mvo: ok, thank you
<mvo> thanks
<pitti> mvo: ah, yay LP dup detection on filing; it's already there, bug 140412
<ubotu> Launchpad bug 140412 in soyuz "Release file should show that it comes from a PPA" [Wishlist,Triaged] https://launchpad.net/bugs/140412
<ogra> soren, did you ever think about creating a loopback blockdevice with nbd to get your grub-install stuff going ?
<tkamppeter> pitti hi
<pitti> hey tkamppeter
<tkamppeter> pitti, WDYT about an UVF for CUPS 1.3.6? It contains many bug fixes, especially it seems that a crash auditing was done this time.
<pitti> tkamppeter: we don't have UVF any more; if .6 doesn't have new features and only bug fixes, we should definitively get it
<tkamppeter> Yes, Upstream Version Freeze was replaced by Feature Freeze.
<\sh> tkamppeter: good to see you....
<\sh> tkamppeter: do you know any way to use a dell CL3110cn printer with ubuntu? i didn't find any usable reference for it on cups or linuxprinting.org
<asac> pitti: bug 193941 ... do i just ened to add need-XXX-retrace to tags to make retracers look at this?
<ubotu> Launchpad bug 193941 in firefox-3.0 "firefox crashed with SIGSEGV in __kernel_vsyscall()" [Undecided,New] https://launchpad.net/bugs/193941
<tkamppeter> pitti, I went to the announcement and all items are bug fixes, no new features. AFAIK the CUPS upstream policy is that minor releases are only bug fixes, so we should be able to use the highest CUPS 1.3.x coming out before release of Hardy.
<\sh> tkamppeter: the printer is attached as IP printer...and only starts working when using it via port 9100
<asac> pitti: hmm. how comes that this isn't private?
<pitti> asac: right; usually it gets done automatically, but due to a load of bugs in p-lp-bugs we lost some tags
<pitti> tkamppeter: agreed
<tkamppeter> pitti, can you do the update to also cover Debian?
<asac> pitti: should i make it private now? or is it too late?
<pitti> tkamppeter: it should be done in trunk and merged to the ubuntu branch, yes
<pitti> asac: you can do it
<asac> pitti: ok, and subscribe ubuntu-crashes-main, right?
<pitti> asac: but not sure why it was un-private-ed
<asac> pitti: it happens from time to time
<pitti> the bug reporter himself can choose to do so
<asac> pitti: well, it looks like that those are never private
<tkamppeter> \sh, you should try this driver: http://foo2hiperc.rkkda.com/
<asac> (vs. unprivated)
<pitti> asac: the retracer will automatically subscribe the right team
<asac> ok
<\sh> tkamppeter: does it mean, that dell uses oki hw and just relabled it?
<tkamppeter> pitti, what about an FF exception of foo2zjs make Hardy support a lot more ugly winprinters, and it cannot break anything as other printers are supported by other drivers.
<pitti> tkamppeter: -> slangasek
<pitti> tkamppeter: please file an FF exception request and subscribe ~ubuntu-release
<pitti> tkamppeter: it will have good chances
<tkamppeter> \sh sorry, the model name looks so similar to the ones of the OKIs. In general Dell does not develop printers, they relabel printers of many brands, Samsung, Lexmark, ... So the chance is not bad that yours is an OKI, but it can also be a Lexmark.
<\sh> tkamppeter: grmpf..I dislike dell serverwise .. now I know another reason printer-wise
<tkamppeter> \sh, so try the mentioned OKI driver but also this Lexmark driver: http://foo2slx.rkkda.com/
<tkamppeter> Perhaps you can even try the driver for the cheapo Samsung color lasers (SpliX).
<\sh> tkamppeter: ok...let's see what the outcome is...:)
<tkamppeter> \sh, if you get your printer to work, tell me which model/driver selection did the trick. Thanks.
<\sh> tkamppeter: will do :)
<ivan_> hi, i've just fixed latex209-bin package for ubuntu 7.10 in order to prevent bug https://bugs.launchpad.net/ubuntu/+source/latex209/+bug/149145
<ubotu> Launchpad bug 149145 in latex209 "package latex209-bin 25.mar.1992-10 failed to install/upgrade: Unterprozess post-installation script gab den Fehlerwert 1 zurÃ¼ck" [Undecided,Confirmed]
<ivan_> but i'm in doubt what to do nex
<ivan_> t
<ivan_> how should i contact a supervisor of package in order to publish it?
<cjwatson> ivan_: start with https://wiki.ubuntu.com/MOTU/TODO/Bugs
<persia> ivan_: https://wiki.ubuntu.com/SponsorshipProcess is the process description.  As latex209 is in universe, you might ask for help in #ubuntu-motu, although you may be redirected to https://wiki.ubuntu.com/MOTU/Contributing
<ivan_> cjwatson, persia: thanks
<ogra> geez, thast cool ... http://spritesmods.com/?art=picframe&amp;page=1
<Riddell> evand, cjwatson: kubuntu kde 4 daily-live CD working surprisingly well, however ubiquity freezes when trying to access debconf, might something be missing from the CD?
<cjwatson> Riddell: would be difficult to break it in that particular way by leaving stuff out without ubiquity being totally absent - anything interesting in the usual logs?
<ogra> Riddell, probably something thats pulled in by using universe that wouldnt be available otherwise ? (a recommends etc) ?
<Riddell> cjwatson: syslog just has the one entry "Feb 25 12:22:39 ubuntu ubiquity[10785]: Ubiquity 1.7.10"
<cjwatson> Riddell: how do you know it's freezing when trying to access debconf?
<Riddell> cjwatson: hmm, hang on, installer/debug has "QMutex::lock: Deadlock detected in thread"
<cjwatson> ogra: I really don't think guessing is helpful ...
<ogra> sorry
<cjwatson> Riddell: is the startup process in ubiquity-dm still right for kde4?
<Riddell> cjwatson: ok, I got it
<Riddell> it's the kde 4 widget style
<cjwatson> ogra: (don't get me wrong, thanks, it just seems like a bit of an extensive logical leap :-) )
<Riddell> it loads QtDbus which breaks with python-qt-dbus is loaded
<ogra> cjwatson, i dont, but i know i'm a big guesser and shouldnt be :)
<cjwatson> ogra: the way I handle that is to figure out some evidence which might support or contradict the hypothesis, and ask about that
<cjwatson> intuitive guesswork is important, but also the careful deduction that can support it :)
<ogra> yep ... :)
<cjwatson> Riddell: ah, and ubiquity loaded python-qt-dbus first and got in the way?
<ogra> i'll try to not start off with a guess first place in the future :)
<Riddell> yes, so as it happens ogra is right, since that kde 4 widget style is something in universe which has never been used with ubiquity before :)
<cjwatson> :-)
<cjwatson> probably easier to get there stepwise though
<Riddell> ArneGoetje: qt 4 fonts aren't anti aliased by default, but I notice large text is (http://muse.19inch.net/~jr/tmp/qt4.png), any idea why?
<ion_> I have the same problem, but i havenât got around to investigating it.
<ogra> ... phew ... what a changelog for edubuntu-meta ....
<mvo> pitti: if you have a bit of time, it would be cool if you could review #195419 and let me know if that is ok to upload to gutsy-proposed
<pitti> mvo: the diff appears twice because it's a symlink somewhere, right?
<pitti> mvo: confirmed, bug updated
<Mithrandir> pitti: I finally managed to test the file sharing thingy by using my N810.  It works fine then.
<Mithrandir> pitti: so a new bluez-gnome is just waiting on the MIR. :-)
<seb128> Mithrandir: speaking about new bluez-gnome, bug #190405
<ubotu> Launchpad bug 190405 in bluez-gnome "[FFE] please upgrade bluez-gnome to 0.21" [Wishlist,Confirmed] https://launchpad.net/bugs/190405
<Mithrandir> seb128: yes, it's including the bits from there
<Mithrandir> it'll be 0.23
<Riddell> evand, cjwatson: ok if I apply this patch and upload ubiquity? http://muse.19inch.net/~jr/tmp/ubiquity.diff
<seb128> Mithrandir: ok, good ;-)
<Mithrandir> seb128: are you following the OBEX bits of gvfs?
<Mithrandir> (http://bugzilla.gnome.org/show_bug.cgi?id=509621)
<ubotu> Gnome bug 509621 in general "Implement obex-ftp backend" [Enhancement,Assigned]
<seb128> Mithrandir: not really no, but looks like bastien nocera is working on that
<Mithrandir> seb128: yeah, though it's blocked on some changes in gvfs itself.
<seb128> alex is responsive so that should be alright
<Mithrandir> ok, coolie
<cjwatson> Riddell: sure
<seb128> mdke: hi
<slytherin> Hi all. Can anyone comment on MIR for obex-data-server. I didn't file the bug, but I promised the bug report that I will handle it in his absence.
<seb128> slytherin: is the mir team subscribed to the bug?
<slytherin> seb128: yes it is.
<seb128> slytherin: so they will likely comment on it when they have a look
<slytherin> ok
<slytherin> The reason I was asking is that recent versions of bluez-gnome are using obex-data-server as backend for file transfer and I am waiting for o-d-s to be in main for getting latest bluez-gnome in Ubuntu.
<Chipzz> who has the "contentless ping" script here?
<Mithrandir> http://err.no/src/contentless_ping.pl
<seb128> slytherin: ah, you just joined, Mithrandir was speaking about that some minutes before you joined, he did the bluez-gnome 0.23 update
<ktk> hi all
<ktk> tkamppeter: here?
<Mithrandir> seb128: we spoke about it in #ubuntu-mobile, but thanks. :-)
<Chipzz> Mithrandir: thx! :)
<pitti> Mithrandir: ack
<cjwatson> mvo: bug 195121: gnome-app-install doesn't depend on software-properties-gtk any more. Should we add it to the desktop seed?
<ubotu> Launchpad bug 195121 in ubiquity "software-properties-gtk is not installed on Hardy Alpha 5" [Undecided,New] https://launchpad.net/bugs/195121
<asac> Riddell: back?
<asac> Riddell: oh i see that you talked above ... do we have kde libs in archive yet that are GPLv3 compatible?
<soren> ogra: No, but I doubt that'll work.
<ogra> soren, works fine up to the point where i need to have partitions
<Riddell> asac: yes
<Riddell> asac: qt is now gpl 3 so gnash etc is fine
<asac> Riddell: hmm i think they need some kde headers as well?
<Riddell> asac: kdelibs is LGPL so no problem there for GPL 3
<asac> ah ok, so it was just QT. great
<mvo> pitti: yes, it appears twice because of the symlink
<soren> ogra: Erm... Ok.
<ogra> soren, grub sees it as real blockdev (which it actually is) if you adjust device.map it works fine ... the prob s that i want two partiotions and nbd or udev seems to not support them (not sure yet)
<jdstrand> lamont: re bind9 autotool-- I was not aware I did.  I checked my debdiff against -3 and I only see my apparmor changes
<mvo> cjwatson: I added it as a recommends for synaptic, but it should probably go to the seeds as well
<soren> ogra: kpartx is your friend.
<ogra> soren, yeah, i saww you use it
<ogra> i didnt have time today yet, to much general work
<ogra> i'll look into it
<ogra> someone told me debian live uses grub to install to loop devices, but looking at the code didnt show any evidence for that
<soren> ogra: To be honest, I forget what the exact problem was..
<ogra> i need/want to create an image from scratch that has two patitions and uses grub ....
<soren> ogra: Oh, that's not what I meant.
<ogra> like: dd it, fdisk on it, make filesystems and install grub ...
<soren> ogra: I mean I forgot why I couldn't get grub to do what I wanted it to do.
<ogra> it doesnt support loop devices
<cjwatson> mvo: yes, please do - I'll assign you the bug?
<mvo> cjwatson: yes, thanks
<ogra> looks like your code works around that by picking pieces out of stage1 and 2 to assemble an mbr
<keescook> Keybuk: say, can you look at my comments on 45842?  I wanted to get your thoughts before we worked on fixing it.
<ogra> i'll use yours if i dont find a better way, but nbd loopdevices (unlike gnbd you actually can have loopback blockdevs with nbd) seem to be a tad cleaner here
<lamont> jdstrand: hrm.. it's possible that I did... :)
<lamont> the autofiles get regenerated when I build the source package
<Keybuk> keescook: opening...
<lamont> OTOH, they get built by bad means - bind needs some auto* love to come into the current version and have autoreconf -f -i -v work
<Keybuk> keescook: err, I can't remember why it only waits for certain things
<Keybuk> keescook: I think it was to avoid waiting on things like cdrom drives
<sistpoty|work> infinity: any chance, that you could increase the inactivity kill timeout on the sparc buildd for ghc6 (it just takes its time..., see bug #194912)?
<ubotu> Launchpad bug 194912 in ghc6 "ghc6 6.8.2-1ubuntu1 FTBFS on sparc" [Undecided,Confirmed] https://launchpad.net/bugs/194912
<keescook> Keybuk: I'm not sure I follow (this is for NFS)
<Keybuk> keescook: was reading the patch at the bottom, it reverts the fact that waitnfs only waits for /usr and /var right?
<kirkland> Keybuk: that's one part of it
<keescook> Keybuk: right, there's that part too.  It should still only be paying attention to network fs's when building that list
<keescook> what do you think of using watershed to solve the races?
<Keybuk> I'm not sure I ever understood what the races were?
<Keybuk> or what the problem was
<keescook> Keybuk: basically, the ifup script can run before rcS finishes
<Keybuk> right
<keescook> so it will try to NFS mount before mtab is ready
<Keybuk> because it's run from udev
<Keybuk> mtab isn't really that critical though?
<keescook> right, and it needs to be there due to that.
<keescook> (i.e. it should be an ifupdown script)
<Keybuk> mtab shouldn't be
<Keybuk> I don't see the link with mtab here
<keescook> let's ignore the mtab bit -- that's not the real problem
<Keybuk> ok
<keescook> there appears to be problems with NFS coming up before we get to waitnfs in rcS
<Keybuk> NFS should come up before waitnfs
<Keybuk> the idea is that NFS is mounted from an if-up.d script
<Keybuk> if-up runs from udev
<keescook> well, that relates to the problem where waitnfs only waits for things in /usr and /var.
<keescook> it should wait for all "auto" network fs's
<Keybuk> but that shouldn't stop them being mounted in the first place?
<keescook> Keybuk: afaict, the ifup script can run too early.
<Keybuk> "too early" ?
<keescook> Keybuk: and waiting until waitnfs is running is late enough to DTRT
<keescook> it fails to mount... I'll turn to kirkland now, who has reproduced this....
<keescook> Keybuk: kirkland and I will get a better determination on the root cause...
<Keybuk> if you wait until waitnfs - you may as well just put mountfs where waitnfs is ;)
<Keybuk> (with some kind of spin to wait until network is up)
<keescook> heh, I thought so too, but it seems to do additional nice things when interfaces change via udev
<kirkland> Keybuk: that was actually how I was working around the problem...  doing the mountnfs inside of the waitnfs
<ArneGoetje> Riddell: cannot say for now, need to investigate by myself. Is this onm Alpha 5?
<Keybuk> kirkland: that doesn't solve the race with ifup though
<Keybuk> if you're ifup takes a long time, your boot can take an extraordinary long time
<Keybuk> to undo the general problem, you could put a spin at the front of mountnfs, and put it back in the ordinary boot sequence
<Keybuk> the difficulty will be making sure you only spin if there are nfs mounts
<Keybuk> and spin until a network is up, only while ifup is likely to run
<Keybuk> you don't want to halt the boot because the network cable was unplugged, for example
<keescook> but if an NFS is auto, it _should_ wait until that's up.
<geser> zul: Hi, it seems we have currently three xen source packages in the archive: xen-3.2 (main), xen-source (universe), xen-unstable (universe). Are xen-source and xen-unstable of any use in hardy or can they be removed?
<zul> xen-unstable should be removed and xen-source should be removed for hardy
<Riddell> ArneGoetje: yes but it's not new
<ArneGoetje> Riddell: I didn't play around with kde4 yet, I am currently fixing font issues on gnome through fontconfig.
<kagou> hi
<seb128> hey kagou
<kagou> hey seb128
<mvo> cjwatson: I added it to the hardy desktop seed now, should I do a upload with it now or is there more stuff pending ?
<ogra_cmpc> woah, i wouldnt have guessed the langpacks on the addon make up so much space
<ogra_cmpc> (it just dropped to 430M from over 600)
<cjwatson> mvo: I don't mind
<lool> I wonder whether we have wiki macros for LP; I think I saw some for blueprints for example; how can I list available macros on wuc?  It seems these are files on the actual wiki server
<fbond> Hi, what is the difference between -dgb packages in the regular repostories and the -dbgsym packages in the ddeb repos?
<cjwatson> lool: you mean https://wiki.ubuntu.com/InterWiki ?
<cjwatson> lool: (if you need more, file an RT request)
<lool> cjwatson: It looks like what I want; thanks!
<cjwatson> fbond: -dbg in the regular archive is constructed deliberately by the source package and may (or may not) have extra debugging facilities compiled into it; for example python*-dbg has extra debugging facilities, more than just debugging symbols
<cjwatson> fbond: (sometimes they're just leftovers, though)
<cjwatson> fbond: the -dbgsym ddebs are automatically constructed and only contain debugging symbols
<fbond> cjwatson: if I'm using qprof to do some profiling, is there any way to make use of the -dbgsym packages to make qprof's output more useful?
<fbond> cjwatson: do the -dbgsym packages get used "automatically" everywhere, or do, e.g., gdb need special options to be told to use them?
<fbond> cjwatson: as you can probably tell, I'm in just a bit over my head :)
<ogra_cmpc> cjwatson, i wonder if we could teach the addon to include the corresponding kde langpacks to the ones included in ubuntu-desktop, for hardy i'll handle them manually but it seems to make sense to automate that in the future
<ogra_cmpc> (now that edubuntu-desktop depends on kdeedu again)
<cjwatson> fbond: you want pitti for that, not me :-)
<cjwatson> ogra_cmpc: ubuntu-desktop doesn't contain any language packs; you mean the Ubuntu ship seed?
<pitti> fbond: just add "deb ddebs.ubuntu.com gutsy main restricted universe multiverse" to your apt sources, then you can apt-get insall them (<packagename>-dbgsym)
<ogra_cmpc> cjwatson, err, indeed
<cjwatson> 'deb http://ddebs.ubuntu.com ...' surely?
<pitti> fbond: erm, sorry: "deb http://ddebs.ubuntu.com"...
<ogra_cmpc> i just cant effort to ship *all* langpacks as we did before
<ogra_cmpc> err
<ogra_cmpc> afford
<cjwatson> ogra_cmpc: hmm. In theory we might be able to add a germinate feature to do that but it would take some pondering
<cjwatson> ogra_cmpc: feel free to file a wishlist bug on germinate for it
<ogra_cmpc> yeah, as i said, nothing for hardy
<fbond> pitti: right, I know how to get them.  I'm wondering if I have to do anything special to make gdb, qprof use them?
<pitti> fbond: gdb finds them automatically; I don't know about qprof
<fbond> pitti: did gdb have to be patched to find them thusly?
<pitti> fbond: ideally it does; our Ubuntu packages have a 'pointer' to the debug symbols (.gnu.debuglink ELF section)
<fbond> Ah.
<pitti> fbond: no, gdb has supported that since ages
<fbond> Interesting.  I'll give it a shot.
<cjwatson> pitti: BTW, I noticed that it didn't seem to be finding them for a GTK application I was debugging
<cjwatson> although I was using the regular -dbg packages, not -dbgsym
<pitti> cjwatson: hm, the original dh_strip should do the same
<cjwatson> ii  libglib2.0-0                                            2.15.5-0ubuntu1                            The GLib library of C routines
<cjwatson> ii  libgtk2.0-0                                             2.12.8-1                                   The GTK+ graphical user interface library
<cjwatson> ii  libglib2.0-0-dbg                                        2.15.5-0ubuntu1                            The GLib libraries and debugging symbols
<cjwatson> ii  libgtk2.0-0-dbg                                         2.12.8-1                                   The GTK+ libraries and debugging symbols
<cjwatson> but gdb just pretends like those aren't there in a backtrace through libglib.so
<fbond> pitti: thanks, btw
<lool> I plan asking for the addition of [Bug ] to the InterWiki list cjwatson mentionned previously
<lool> As to allow [Bug 1234] in wiki pages, reports etc.
<ubotu> Bug 1234 on http://launchpad.net/bugs/1234 is private
<ogra_cmpc> :P
<geser> pitti: I'm just looking why ocamlrpcgen is still broken. I found the problem but I don't know whose fault it is. Do you know if a space is allowed between dh_strip -X and the argument?
<pitti> geser: it's not documented to be allowed
<pitti> geser: and pkg-create-dbgsym assumes that there is no space
<pitti> geser: dh_strip might get along with it, though, I haven't checked the implementation
<geser> that seems to be the problem, cdbs calls dh_strip with spaces between -X and the argument
<geser> dh_strip.pkg-create-dbgsym -plibocamlnet-ocaml-bin -X usr/bin/netplex-admin -X usr/bin/ocamlrpcgen leaves the binary intact
<geser> but it breaks if I use dh_strip
<geser> but dh_strip works if I remove the space after -X
<pitti> geser: ok, I need to fix that in pkg-create-dbgsym then
<pitti> geser: I reopened the bug, thank you
<cjwatson> lool: I'm not sure the syntax would work quite that way ("Bug:1234" surely?), but sounds good in principle
<cjwatson> or possibly [wiki:Bug/1234] if it doesn't like the above syntax
<tkamppeter> pitti, \sh, slangasek: foo2zjs FF exception posted, bug 192948
<ubotu> Launchpad bug 192948 in foo2zjs "FF Exception for foo2zjs: NEW updated version, supports more printers (like OKI c3300n)" [Medium,Triaged] https://launchpad.net/bugs/192948
<tkamppeter> ktk, I am here.
<asac> calc: sorry if i missed it, but did you roll ooo xul1.9 update yet?
<calc> asac: not yet, i plan to roll it into the OOo 2.4.0 upload i do this week
<asac> calc: great
<asac> thanks for the info
<calc> asac: i was going to put it into 2.3.1 upload but found out it would be a good idea to get 2.4.0 in this week so stopped working on 2.3.1 and updated 2.4.0 as quickly as i could :)
<calc> asac: its ready pending OOo 2.4.0 rc2 release
<asac> good
<cjwatson> calc: any reason to block it on that, out of interest? I meant to ask before ...
<cjwatson> calc: after feature freeze it's generally better to get things in early
<calc> cjwatson: ok, see privmsg :)
<Riddell> siretart: why does xine depend on libxine1-plugins | libxine1-misc-plugins ?  seems to me libxine1-plugins beings in some optional extras that aren't necessary (and it breaks things since it tried to bring bad packages onto the CDs)
<calc> i may just not be able to read but where do i set the bug contact for a project in lp?
<calc> i see actions on the left but haven't found which one is the proper one
<pitti> Mithrandir: does that obex server process run as root or dbusdaemon?
<calc> also how do i add a group to a project?
<cjwatson> https://bugs.launchpad.net/PROJECTNAME/+bugcontact
<cjwatson> possibly only if you're the registrant
<cjwatson> you can do https://bugs.launchpad.net/PROJECTNAME/+subscribe
<calc> cjwatson: yea i am
<cjwatson> which doesn't require magic privileges
<cjwatson> what do you mean by a "group" in this context?
<calc> cjwatson: er 'team
<calc> ' actually
<pitti> Mithrandir: ah, root, nevermind; hm
<cjwatson> oh, teams behave just the same way as persons for nearly all purposes
<cjwatson> except for things like special UI entries for teams you're a member of
<calc> cjwatson: ok
<cjwatson> you can only subscribe a team to a project if you're the team administrator
<calc> cjwatson: yea i already did that for bugs, how do i have the team joined as members of the project?
<cjwatson> projects don't have members as such ...
<calc> cjwatson: oh ok
<cjwatson> they have contacts for various specific purposes
<cjwatson> like driver, bug contact, security contact
<calc> cjwatson: i tried +security for security contact but it didn't seem to work
<calc> ah its +securitycontact
<cjwatson> calc: it's linked from the bugs tab
<cjwatson> e.g. https://bugs.launchpad.net/openoffice, look at the bit on the left
<calc> cjwatson: ah ok
<Riddell> infinity: could you update livecd-rootfs on king.buildd, or work out why it isn't updating
<infinity> Riddell: It upates once a day, in theory.  when was the last upload?
<Riddell> infinity: days ago.  the i386 one has updated fine
<infinity> Friday...
<infinity> Hrmph.
<infinity> Looking.
<infinity> buildd@king:~$ sudo chroot build-hardy-live/chroot-hardy/ dpkg -l livecd-rootfs | grep ^i
<infinity> ii  livecd-rootfs              0.53                        construction script for the livecd rootfs
<infinity> Looks like it auto-updated fine...
<slangasek> he may need the updated BuildLiveCD script
<infinity> Ahh, yes, this is possible. ;)
<infinity> -       *ubuntu|*ubuntu-dvd|kubuntu-kde4|ubuntu-lpia|base|tocd) ;;
<infinity> +       *ubuntu|ubuntu-lpia|base|tocd)  ;;
<infinity> Picky, picky.
<infinity> Riddell: Should be happier now.
 * infinity needs to move the valid project test out of BuildLiveCD...
<infinity> Though, adding new project shouldn't happen often.
<Riddell> thanks infinity
<Chipzz> infinity: but it would have the advantage of being easier to configure if you want to make your own live cd ;)
<Chipzz> infinity: so ++ for derivatives ;)
<infinity> Chipzz: Well, people home-brewing don't need to use BuildLiveCD at all, unless they're really keen on publishing things the way I do, etc.
<infinity> Chipzz: There's a reason it's packaged as an "example". :)
<infinity> Still, in one of these mystical "free time" periods, livecd.sh and BuildLiveCD both could use some "No one's really done anything to them other than minor changes for years" love.
<Chipzz> :)
<infinity> And they're the worst kind of example of what happens when LaMont writes something, I take it over and half rewrite it, and then some other poor schmucks (yay, distro) get stuck trying to make sense of it.
<Riddell> evand: can I upload another ubiquity with a kde4 fix?
<xivulon> slangasek: did you discuss metalink urls with the webmaster?
<evand> Riddell: sure
<slangasek> xivulon: yes; the conclusion is that it's not feasible to host it on www.ubuntu.com, so we will need to have two different metalink urls - one for alphas, one for beta/rc/final
<xivulon> do you mean, that it is possible to host metalinks on ubuntu.com, but without redirection?
<slangasek> xivulon: I'll try to get some final URLs settled on cdimage.u.c and releases.u.c this week so you can start making use of them
<xivulon> thanks
<xivulon> couple of minor things
<slangasek> xivulon: I mean, www.ubuntu.com is not provisioned to scale the way that releases.ubuntu.com is; anything that's going to be hammered at release time needs to go to the latter
<xivulon> release.ubuntu.com is perfectly fine, provided the url does not change I do not care
<xivulon> can I have daily-live + final?
<slangasek> the daily-live will *not* be on releases.ubuntu.com, it'll be on cdimage.ubuntu.com
<slangasek> so - two urls to check
<infinity> slangasek: Oh, BTW, regarding things like #184210, if you thing it should never build on !x86, please poke me to P-a-s it and close the bug.  Might be more sane in this case, though I'm not sure if it's meant to be portable and fails to be.
<xivulon> will be 3: alpha6/beta/final
<xivulon> slangasek I assume that having MD5SUMS + MD5SUMS.gpg is ok
<xivulon> the ones in use now are: http://www.wubi-installer.org/metalinks/8.04/
<xivulon> no partial sum and only 1 mirror in there
<xivulon> the signature there is mine for obvious reasons
<slangasek> infinity: I think it's meant to be portable and fails to be; so AFAICS it's a bug, but not release-critical by any means
<slangasek> xivulon: I'm assuming that we want to put the metalink file in the per-release root directory (http://cdimage.ubuntu.com/releases/hardy, not http://cdimage.ubuntu.com/releases/hardy/alpha-6), so that you don't have to have an index of all the possible milestone names to poll
<infinity> slangasek: Yeah, I was pretty slack on the "check the arch, determine the priority" thing, as I had 3 failure logs for most builds, and would just pick one at random to read.
<slangasek> so in that case, there would be only two urls; one on cdimage. and one on releases.
<xivulon> slangasek that would be nice
<slangasek> infinity: right :)
<slangasek> xivulon: now, what do you mean about MD5SUMS + MD5SUMS.gpg?  I don't remember this being mentioned as a new requirement related to metalink
<xivulon> slangasek: we could already put in there the metalinks for both, they will not have any checksum
<xivulon> slangasek: I need the md5 of the metalink files, and a signature of that
<slangasek> ok
<xivulon> to avoid spoofing attacks
<slangasek> please document that in the bug report, if it's not there already
<xivulon> will do that
<slangasek> given that this is a single file, is there a reason we wouldn't want to provide just a .gpg sig for the metalink files themselves?
<xivulon> I do use 1 metalink for each distro
<xivulon> see http://www.wubi-installer.org/metalinks/8.04/
<ogra_cmpc> xivulon, googling for grup on loopdevices revealed that you seem to have done work on that area ... was there any outcome (i'm trying to do something similar here)
<ogra_cmpc> err
<ogra_cmpc> s/grup/grub/
<ogra_cmpc> :0
<slangasek> a single MD5SUMS for all the metalink files for a release would be nice, but impractical because of the way in which each flavor is generated separately
<slangasek> oh, there'll be different metalink files for each arch, that's true
<xivulon> ogra_cmpc: we do not install grub on loop device if that is what you mean
<slangasek> in that case we can do MD5SUMS{,.gpg}, sure; there'll be a separate one for each flavor, all the same
<xivulon> since the boot folder is a windows folder bindmounted into the loop device
<ogra_cmpc> xivulon, well, i only saw you worked on fixing it
<ogra_cmpc> ah, thats quite different from my setup, thanks
<xivulon> ogra_cmpc: I have added 1) detection of host device when menu.lst is generated 2) making sure that device.map is there
<xivulon> what is your requirement exactly?
<ogra_cmpc> loopmounted device with loopmounted partitions
<xivulon> in what context do you boot them?
<ogra_cmpc> i.e. /dev/loop0 is the image, /dev/loop1 the first partition (mounted with offset)
<xivulon> or better what is your boot setup?
<ogra_cmpc> i dont boot them, i want a dd-able image you can just dump on a usb stick
<ogra_cmpc> without forcing the user to manually install grub during that process
<xivulon> ah I see
<ogra_cmpc> i have something half way working with a loopback nbd device but not quite ...
<xivulon> what about using grub4dos in mbr?
<xivulon> that can use --find-root
<xivulon> which allows you to get the right device without coding it into menu.lst
<ogra_cmpc> i'll look into it, thanks ... i was just googling for grub and loopback on the weekend and the results have your name scattered all over
<ogra_cmpc> so i thought i'd ask
<xivulon> yes they kept me busy...
<xivulon> with wubi stuff
<xivulon> by the way, wubi images can also be useed on USB
<ogra_cmpc> developer life was so much easier with dumb old lilo .... sigh ...
<xivulon> ahah
<xivulon> I could add wubi support to target USB if you wish, that is the same as a regular wubi installation + dropping wubildr.mbr in the mbr
<ogra_cmpc> nope
<xivulon> one less for me then :P
<ogra_cmpc> what i do here is quite specific :) wubi wouldnt help here
<ogra_cmpc> but thanks for the offer :)
<xivulon> slangasek: if we have a signature for each metalink, I see no much point in having also the MD5
<xivulon> I mean no point in having md5+signature for each metalink. metalink + signature is enough
<slangasek> xivulon: there will be a separate metalink for each architecture, so it makes sense to only sign once for each flavor; in which case there's no reason for us to break your existing code
<xivulon> sure
 * slangasek stares at the python2.5 testsuite.  Did it just play a Monty Python clip at me?
<Keybuk> slangasek: entirely possible
<slangasek> test_normalization and test_ossaudiodev, apparently
<\sh> guys, how do I debug an apache2 which is segfaulting? (i guess it's php5)
<slangasek> run it under gdb in debug/foreground mode?
<\sh> slangasek: good idea.../me is braindead at this time of the day
<Keybuk> The following NEW packages will be installed
<Keybuk>   libpam-doc
<Keybuk> ...cover me, I'm going in!
<\sh> hmmm
<\sh> it's gutsy...and there was an pcre upgrade...
<\sh> the segfault is coming and gdb tells me : 0xb7f517ac in ?? () from /usr/lib/libpcre.so.3
<\sh> trying a bt full gives me
<\sh> #0  0xb7f517ac in ?? () from /usr/lib/libpcre.so.3
<\sh> Cannot access memory at address 0xbf121c20
 * LaserJock throws Keybuk a few grenades ... just in case
<Keybuk> LaserJock: you're not supposed to throw them *at* me
 * Keybuk recovers his limbs
<LaserJock> hmm
<\sh> slangasek: any idea how to tell gdb to be more noisy? :)
<Keybuk> \sh: install the debug sym packages?
<Keybuk> deb http://ddebs.ubuntu.com gutsy main universe
<Keybuk> deb http://ddebs.ubuntu.com gutsy-security main universe
<Keybuk> should be an apache-dbgsym
<Keybuk> and maybe a libpcre3-dbgsym there
<\sh> Keybuk: thx
<Keybuk> (there is, I just checked)
<\sh> Keybuk: ah well...unmet deps ;)
<\sh> Keybuk: the dbgsyms are not automatically rebuild when a -security or -update package is uploaded?
<Keybuk> \sh: not sure, I think they are
<Keybuk> that being said, gutsy-security is kinda empty
<Keybuk> pitti: ^
<\sh> Keybuk: and now there were again my problems ;)
<\sh> and this damn system must be running tomorrow morning at 8am UTC
<Keybuk> \sh: does it work if you unapply the security update?
<\sh> Keybuk: well..I'll have to revert the all the apache2+module deps etc...
<Keybuk> \sh: you will?
<\sh> Keybuk: I have to actually...if I can't find the problem until tomorrow morning, I'm fcked
<Keybuk> have you tried just reverting the security update though
<Keybuk> to see whether that fixes the problem?
<Keybuk> that would tell us whether we have an issue
<\sh> Keybuk: you mean of the pcre fix?
<Keybuk> yes
<\sh> give me a min :)
<\sh> Keybuk: it would be easy if libpcre3-0ubuntu0.7.10 would be still in the archives
<\sh> Keybuk: which means, the last update was a -security fix, and the version before it, was also a security fix,
<slangasek> hrm? where is that version number from?
<Keybuk> \sh: https://edge.launchpad.net/ubuntu/gutsy/+source/pcre3/7.4-0ubuntu0.7.10.1
<Keybuk> you can download from there
<Keybuk> (minus the edge)
<Keybuk> pick the appropriate architecture on the left to get to the resulting binary packages
<\sh> Keybuk: the same...it's not pcre it seems
<lamont> infinity: livecd.sh wasn't supposed to live this long...
<evand> ogra_cmpc: Will there continue to be full edubuntu desktop CDs going forward, or will that eventually be disabled on cdimage?
<infinity> lamont: Hey, it still works... More or less. :)
<\sh> Keybuk: and actually the dbgsym packages of apache2 are out of date
<slangasek> my understanding was that edubuntu desktop would remain a discrete image, only server was being rearranged into an ubuntu-server adjunct?
 * \sh upgrades now to hardy...and if this is not working I'm reinstalling the gutsy image..I'm tired
<evand> hrm, ok.  Thanks slangasek
 * \sh 's wife will kill him ... since 3 weeks in the company and already a nightshift
<ScottK2> Shouldn't have bought the company life insurance then.  You might be safer.
<\sh> ScottK2: *g*
<\sh> we had a similar crash under debian etch..I solved it with replaceing debian with ubuntu..and now we added some stuff to the php backend which uses ZF...and bang again a segfault
<slangasek> evand: that's my understanding; plans may have changed when I wasn't looking
<\sh> (debian <- old php release)
<evand> slangasek: indeed, noted
<\sh> ScottK2: but actually a good news: zend is working with me on making ZendFramework in ubuntu rock...direct upstream contact established
<LaserJock> slangasek: I'm not sure that a Desktop CD will be possible for Edubuntu, because of size issues
<LaserJock> unless we want to do some funky stuff like not putting edubuntu-desktop on the Edubuntu Desktop CD :-)
<slangasek> LaserJock: it's currently oversized; but how is it better to not have a desktop CD than to trim the metapackage?
<LaserJock> because the Desktop CD is stupid for Edubuntu anyway ;-)
<LaserJock> it's kind of a bad thing, IMO, to have a Desktop CD that is radically different from what you get when you install Edubuntu the "recommended" way
<stgraber> slangasek: having an edubuntu desktop CD which is basically an Ubuntu with a different artwork is useless from my point of view
<stgraber> you would need to add the content of the add-on CD to the desktop CD to have a real educational desktop
<LaserJock> exactly
<LaserJock> it wouldn't have very many of the apps actually available
<stgraber> you will need both edubuntu desktop and add-on CD, then why not have the ubuntu desktop and the edubuntu add-on CD ?
<stgraber> LaserJock: what do we have more in Edubuntu desktop than Ubuntu desktop ? gobby and the artwork ?
<LaserJock> ogra added most of the edu apps
<slangasek> stgraber: does the add-on CD include all of the edubuntu desktop packages?  I don't know that it currently does
<stgraber> slangasek: it does, it was the test I did for Alpha-5
<LaserJock> it now contains most of the stuff that's on the add-on CD
<stgraber> slangasek: I started from an Ubuntu Alternate and then installed the whole Edubuntu desktop from the Edubuntu add-on CD
<LaserJock> i.e. the way it was before we split the CDs
<slangasek> stgraber: oh, it includes the *desktop* add-on packages?  hrm, ok; that means the edubuntu server went untested, I guess :)
<stgraber> slangasek: edubuntu server won't exist for Hardy
<slangasek> well, not my decision anyway how edubuntu CDs should be structured
<slangasek> stgraber: er, I thought that was also part of what was on the edubuntu add-on
<\sh> bah....apache2 upgrade path is broken
<stgraber> LTSP was moved into the Ubuntu Alternate
<slangasek> hmm, ok
<stgraber> so I can now install LTSP from Ubuntu Alternate (also one of the tests I did for Alpha-5)
<stgraber> and then install the add-on CD to have the same as the previous Edubuntu server
<\sh> keescook: ping pcre3 security fix
<\sh> keescook: looks like that it breaks here (on hardy now)
<\sh> keescook: same problem as on gutsy...
<ScottK2> \sh: Sounds promising (the zend bits, not the pcre).
<\sh> ScottK2: well, the pcre bit is giving me a headache..
<\sh> but I wonder how can I resolve this: 	rrc = Cannot access memory at address 0xbf69ad18
<slangasek> that typically points to stack corruption
<slangasek> try valgrind?
<slangasek> (which may or may not be useful, given that php does its own memory management)
<\sh> slangasek: well...if you hint me on running apache2 + php5 inside valgrind? or just valgrind /usr/sbin/apache2 -X
<\sh> ?
<slangasek> exactly
<\sh> slangasek: trying
<\sh> slangasek: could it be that, while running in valgrind, that php5 is not reading it's ini?
<slangasek> \sh: valgrind should be invisible to php.
<\sh> slangasek: I got the error now
<\sh> slangasek: http://paste.ubuntu.com/4983/
<shaya> anyone have any idea how to get home button in navigation toolbar in firefox 3? Ubuntu's version doesn't drag for me in "customize" mode
<\sh> slangasek: your guess was correct it seems
<slangasek> \sh: heh, nice
<slangasek> that's a very, very strange use of memcpy()...
<\sh> slangasek: as it is the very same secfix in hardy and gutsy I think we have a problem
<\sh> hoping that kees is still awake ;)
<slangasek> well, the first error returned by valgrind is not caused by pcre
<\sh> slangasek: the message of Access not within mapped region at address 0xBE094FFC
<\sh> is raised in pcre_exec.c, or do I read something wrong?
<slangasek> no, you've read that right; but I'm not sure what that signifies
<slangasek> because before that, it's giving a stack overflow
<el_cubano> Hello.  Does anyone know if (or where) the kernel team maintains their work in a VCS of some sort?
<jdong> el_cubano: kernel.ubuntu.com
<el_cubano> jdong: Wow!  That was easy?
<jdong> :)
<el_cubano> Next question, is anyone aware of how easy/hard it would be to remove the AppArmor patch from the kernel?  Any potential problems with that?
<\sh> slangasek: hmm...what could give us the information we need? I installed apache2*, php5 and libpcre3 dbgsym packages
<jdong> el_cubano: why do that?
<jdong> would blacklisting the module not suffice?
<slangasek> \sh: probably some google searching on that error message
<el_cubano> jdong: Because AppArmor makes it impossible to build Lustre modules
<el_cubano> jdong: Using kernel 2.6.22 from Gutsy
<slangasek> \sh: have you confirmed that downgrading prce3 fixes the problem?
<jdong> el_cubano: you should be able to just stop apparmor's init script and unload the apparmor module
<jdong> and in that case, it'd be pretty much identical to an un-apparmored system
<el_cubano> jdong: That does not help if the compilation of the lustre modules never succeeds
<el_cubano> AppArmor changes the vfs_* calls around.
<jdong> el_cubano: ah, well I've never tried reverting the apparmor patches, I wouldn't think it'd be that hard to do
<\sh> slangasek: I'm downgrading now...
<el_cubano> jdong: OK.  Thanks for the pointer.
<\sh> slangasek: strangly using the zend-core binaries of apache2+php5 doesn't raise this...
<siretart> Riddell: because it would break dapper->hardy upgrades. in dapper all plugins were included in the libxine1 package. if that dependency was dropped, those plugins would silently vanish from the user system
<siretart> Riddell: vorlon explained me that was unacceptable for debian, and I don't see why it therefore should be for ubuntu
<\sh> slangasek: downgraded to libpcre3 7.4-1ubuntu1 now
<geser> shaya: wait for firefox 3 beta 4 (see bug 192505)
<ubotu> Launchpad bug 192505 in firefox-3.0 "Where's my home button?" [Low,Fix committed] https://launchpad.net/bugs/192505
<shaya> danke
<\sh> slangasek: ok...the same happens with the old version...
<slangasek> \sh: right.  you say you're using some Zend extension on this system?  Is that extension relevant to reproducing the bug? (i.e., can you put together a test case that doesn't depend on the extension?)
<\sh> slangasek: nope...we are using ZendFramework it's a simple php source lib (so it's interpreted by php5)
<\sh> slangasek: and nope I can't setup a testcase...normally a module shouldn't segfault when something is wrong with the source files (regarding php actually)
<slangasek> er, of course it /shouldn't/, but the test case is still needed in order to let others try to reproduce the problem
<\sh> slangasek: well, if I would knew what part this triggers I would cry out loud and fix it...but there are two possibilities: 1. something goes wrong in detected system locales (which was the cause when using ZendFramework and debian php5) or 2. I don't know...because on the other machine with the zend provided binaries, it works
<fbond> pitti: Just FYI, I'm now using oprofile, and it makes use of debug symbols nicely.  It's a great package!
<soren> Isn't gdb supposed to automagically pick up the -dbgsym stuff if I have those installed.
<Riddell> seb128: your last change to libgpod broke libgpod3-nogtk, it can't be installed
<\sh> slangasek: just FYI..with the zend-core binaries on this ubuntu... it segfaults to
<\sh> too
<seb128> Riddell: I didn't change this one in a while now
<seb128> Riddell: and why installing the common would break the nogtk version?
<Riddell> seb128: and it's been broken for a while
<Riddell> seb128: because it only depends on the gtk version
<seb128> ?
<Riddell> really it shouldn't depend on any of course, they should depend on it
<seb128> no
<seb128> the depends is right
<seb128> the hal helper which is used to make new ipods work is using libgpod
<seb128> and they install it there
<\sh> slangasek: I wonder if it's really this locale thing...that this ZendFramework doesn't know anything about utf-8 locales
<seb128> but right it should have a | libgpod3-nogtk there
<seb128> seems that nobody is using nogtk though
<seb128> the change has been ages ago
<Riddell> seb128: amarok does
<slangasek> \sh: there's really not much more I can say about this without a reduced test case I can use to reproduce the problem
<\sh> slangasek: well, I'm stopping now, because I think the bug is inside the application and/or in ZendFramework. I can reproduce the crash with two independent installations
<\sh> slangasek: I'm writing an email to the ZendFramework guys with providing all necessary infos ... well, anyways I'm fcked tomorrow.
<slangasek> a segfault in PHP is a bug in the engine, no matter how it's triggered; but it still needs a reduced test case to be debuggable
<\sh> slangasek: both are using 5.2.4 so this is the common thing
<\sh> slangasek: and I'll talk tomorrow to our php devs..they should reproduce something
<komputes> whats the best way to install Firefox 2 on Hardy?
<infinity> komputes: apt-get install firefox-2
<komputes> infinity: from what source repository?
<\sh> slangasek: and the bad thing is...the version which works is php 5.2.1
<komputes> infinity: firefox-2 is not a package in any of the hardy repos from what I can see
<infinity> komputes: Err, it's probably in binary NEW currently.
 * infinity goes to see about that.
<komputes> infinity: can you let me know which repository that is so I can add it to my sources.list
<infinity> komputes: It's not a repo at all, it's a "waiting on archive admin intervention".
 * komputes is confused
<geser> komputes: it will be in universe in a few days
<infinity> komputes: New binaries (new names) need manual intervention.  I've just intervened, so "firefox-2" will exist in an hour or two, after the publisher gets to them (in universe)
<komputes> infinity: thx
<komputes> infinity: is there a .deb of firefox 2 somewhere?
<komputes> infinity: can I add a gutsy repo and download it from there?
<infinity> komputes: You could just wait an hour or two, surely?
<komputes> infinity: actually, i kind of wanna go home
<infinity> komputes: Alternately, you can download the binaries before they hit the archive from: https://edge.launchpad.net/ubuntu/+source/firefox/2.0.0.12+2nobinonly+2-0ubuntu3/+build/524435
<infinity> komputes: (Assuming you use i386, follow links up and to another arch, if you need another)
<komputes> infinity: the .changes file?
<infinity> komputes: The links to the binaries on the left...?
<infinity> (Which are 404, go soyuz)
<komputes> haha
<infinity> https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=2&queue_text=&start=20
<infinity> Expand "firefox (your arch)"
<infinity> Those links work.
<komputes> i386
<komputes> infinity: URL please :o
<komputes> my bad
<komputes> infinity: thanks two fold
#ubuntu-devel 2008-02-26
<ogra_cmpc> evand, eventually, yes ... i cant tell if that means hardy though, thats a RichEed decision, afaik he wants something to demo an edu desktop
<evand> ogra_cmpc: ok, thanks
<ogra_cmpc> grmbl
 * ogra_cmpc just learned that the lenovo page kills classmates 
<LaserJock> ogra_cmpc: yucky
<ogra_cmpc> and i didnt even get to see any pics of the new lappie ...
<bobwhoops> join #gsoc
<bobwhoops> whoops
<superm1> slangasek, did you ever manage to get those changes merged into cdimage?
<slangasek> superm1: now I have... :)
<superm1> slangasek, yay :)
<superm1> slangasek, so with space being a commodity, would it be feasible to only ever keep one image of ours at a given time?
<superm1> slangasek, or will we have to wait until cdimage gains more hard drives?
<slangasek> superm1: currently the etc/purge-days script has a single rule for all daily alternate images; I've made a policy change already that gives us a little more space though, so mythbuntu should fit in ok
<superm1> slangasek, wonderful :)
<superm1> slangasek, we're not going to explore doing the livecd via livecd-rootfs for some time, to that will work great
<TheMuso> superm1: You guys are getting images done via cdimage for mythbuntu? Awesome!
<superm1> TheMuso, at least for an alternate disk (which we have needed for ages) :)
<TheMuso> superm1: Again, awesome!
<Hobbsee> *drool*
<Hobbsee> iwlwifi fixes!
<TheMuso> Hobbsee: I can only guess that they benefit you.
<RAOF> Hobbsee: As in: "please don't fill up /var/log with gigabytes of debug spam"!
<RAOF> Things get really wierd when there's 0 bytes free on /, /tmp and /var :)
<ScottK2> Hmmm. Spam.
<Hobbsee> RAOF: yeah, that too.  the led, in particular
<RAOF> Hobbsee: My LED has been working?
<Hobbsee> ipw or iwl?
<RAOF> iwl
<RAOF> ipw doesn't work anymore, right?  I don't have the non-free daemon anymore, certainly.
<RAOF> Or whatever it was keeping ipw in -restricted.
<Hobbsee> strange.
<RAOF> I suppose it depends on what you mean by "working".  My LED is _on_.  It doesn't seem to turn off when I hit the killswitch, though :)
<RAOF> I've just never noticed this, because I treat the killswitch as basically a way to accidentally break my networking.
<StevenK> "accidentally" ? :-)
<RAOF> It's in a place where I *can* accidentally brush against it.  Or removing the laptop from a bag, or...
<Hobbsee> RAOF: ah right.  mine's always off, killswitch or not
<RAOF> Hobbsee: Yay for crazy non-standard laptops.  Standards are for _pussies_!
<Hobbsee> hehe
<pwnguin> its a bit sad though
<pwnguin> iwl is a much bigger powertop offender than ipw
<RAOF> pwnguin: I haven't noticed that, but then the nvidia driver is a big powertop offender, too.
<pwnguin> i turned off the nvidia driver
<pwnguin> but check out the top offender
<pwnguin> 59.1% (148.6)      <kernel IPI> : Rescheduling interrupts
<RAOF> I like compiz, when I'm not using nouveau.
<pwnguin> is nouveau usable for 2d?
<pwnguin> i just use nv
<RAOF> pwnguin: Nouveau is *extremely* usable for 2d.
<RAOF> It's basically as fast or faster than the blob for 2d, at least on my chip.
<pwnguin> neat
<RAOF> (Also, has better dual head support).
<pwnguin> double neat
<pwnguin> the twenty thousand dollar question: xrandr rotations
<RAOF> Accelerated.
<pwnguin> 180?
<RAOF> and 90, and 270.
<RAOF> As far as I can tell.
<pwnguin> have you tried 180?
<RAOF> No, I don't think so.
<RAOF> Oh, actually, yes I have.
<RAOF> Probably.  I played around with "mirror x", "mirror y", "mirror xy" at one point.
<RAOF> Somewhere in that playing I probably managed a 180 rotation :)
<pwnguin> not quite the same
<RAOF> Try it yourself, then :)
<pwnguin> im considering it
<RAOF> I can even play OpenArena on nouveau :)
<pwnguin> heh
<pwnguin> i'd be more interested in the crack attacks and gunroars
 * StevenK remembers submitting debugging information about his card to the nouveau guys on RAOF's insistance
<RAOF> :)
<pwnguin> RAOF: does your ppa still have nouveau up for testing?
<RAOF> Yup.
<RAOF> I should work out the module-assistant magic required to make this useful for Debian and push it into experimental.
<RAOF> StevenK: And in return, the randr12 code probably properly handles your chip :)
<StevenK> RAOF: Heh. Come back to me when Nouveau is in Ubuntu and handles WoW, and I'll switch :-)
<RAOF> StevenK: I've tried, it doesn't quite yet :P
<StevenK> RAOF: It doesn't run, or it looks wierd?
<RAOF> It won't be in Ubuntu until DRI2 is stable, probably.
<RAOF> StevenK: Doesn't run.  There's still a bunch of unimplemented stuff in gallium, would you believe it? :)
<StevenK> Heh
<RAOF> Although I also had to fight with my additional 32bits, so it's possible (but unlikely) that an i386 install would have better luck.
<pwnguin> wow is overrated
<TheMuso> pwnguin: Watch out!
<TheMuso> :p
 * RAOF hopes DRI2 will make Ibex.  DRI2 not only brings back kittens killed by god, it also procs world peace (5% chance).
<pwnguin> so did ati actually release 3d docs?
<toresbe> Ibex?
<toresbe> Is that the one after Heron?
<TheMuso> toresbe: Yes.
<toresbe> neat
<toresbe> I think there's a painkiller in Norway named Ibex
<toresbe> no, that's Ibux, probably.
<toresbe> http://www.ibextours.com/ though.
<StevenK> toresbe: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-February/000383.html
<dholbach> good morning
<asac> morning dholbach
<dholbach> hey asac
<warp10> Good morning!
<pitti> Good morning
<thekorn> hi dholbach, where can a file bugs/suggestions related to this 5-a-day tool?
<thekorn> https://edge.launchpad.net/five-a-day/+filebug seems to be disabled
<dholbach> thekorn: should work now - thanks for letting me know
<thekorn> dholbach, yes, works, thanks
<dholbach> asac: http://daniel.holba.ch/ubuntu/ic/ does not load up in hardy, but does in gutsy
<pitti> lool: WDYT about the updated packages in bug 186647 ?
<ubotu> Launchpad bug 186647 in pigment "promote to main" [Undecided,New] https://launchpad.net/bugs/186647
<asac> dholbach: didn't i look at that once?
<asac> dholbach: i think it was illegal html ;)
<dholbach> "illegal html"
<dholbach> EXPECT THE POLICE! :)
<asac> hehe
<asac> dholbach: close the script elements properly
<asac> or use XHTML DTD :)
<asac> e.g <script type='text/javascript'></script>
<dholbach> asac: OK, seems to be the script tag :)
<Mithrandir> asac: it doesn't handle <script type='text/javascript' /> correct either, even with doctype = XHTML
<asac> Mithrandir: is |'| legal in xml?
<Mithrandir> asac: well, it was "", iirc.  I don't have that bit of code in front of me here.
<asac> hmm
<Mithrandir> asac: I ran it through a validator and it didn't complain, at least.
<asac> Mithrandir: scary. you didn't file a bug, did you?
<Mithrandir> asac: no, but I could.
<pitti> slangasek: WDYT about bug 193265 ?
<ubotu> Launchpad bug 193265 in sane-backends "FF exception request: update sane-backends to 1.0.19 final" [Undecided,New] https://launchpad.net/bugs/193265
<asac> Mithrandir: please do you if you can reproduce with latest ffox 3 ... and attach the testcase
<Mithrandir> asac: 'k
<asac> Mithrandir: we are still pretty good at forwarding bugs upstream and getting things fixed
<asac>  ... though time runs low
<asac> ;)
<slangasek> pitti: wanted to finish reading through the upstream changelog, which I don't think I'll get through tonight
<asac> Mithrandir: package "xulrunner-1.9" most likely
<pitti> slangasek: ok, no problem; just wanted to check if it's on your list, thanks
<slangasek> pitti: yep, definitely; I should be able to catch up on the list of FFe requests tomorrow (Tuesday)... and sooner if other members of ubuntu-release were to help ;)
<pitti> slangasek: I obviously can't approve my own request, but if you need help I can look at others
<slangasek> I'd appreciate it if you had the time
<pitti> ok, noted
 * Hobbsee headbashes quietly
 * Mithrandir puts a pillow between Hobbsee's head and the wall
<Hobbsee> hey there Mithrandir!
<cjwatson> toresbe: FWIW, if we're going to use a single word to describe the release, we normally use the adjective, not the noun
<cjwatson> RAOF: ^-- err, I guess that was really for you
<pwnguin> what was the i? idyllic?
<cjwatson> pwnguin: please see ubuntu-devel-announce
<pwnguin> intrepid
<lool> pitti: I've poked philn to please commit his elisa/pigment packaging changes for the new upstream release/svn snapshot he mentions; if it takes too long, I'll do them; if you like, I can do a quick upload with only the python 2.5 packaging fixes, but it wont solve the issue you were seeing
<ArneGoetje> Riddell: If you use "System Default" as antialiasing setting in KDE, it will probably fall back to fontconfig. However, hinting and antialiasing is not enabled by default in fontconfig.
<ArneGoetje> Riddell: the Gnome desktop uses Greyscale (rgba none) and medium hinting as default settings. Question is if we should enable this setting in fontconfig globally... then KDE should get the same settings...
<pitti> lool: right; when we do an Ubutu upload, it shuold make the package actually working
<pitti> lool: we can wait a few days, but for the MIR it would be good to get it working ASAP
<pitti> Mithrandir: since you seem to work on bluetooth, do you have an idea about bug 72033? what would need to happen to make this work OOTB?
<ubotu> Launchpad bug 72033 in ubuntu-meta "Install gnome-bluetooth by default to enable receiving files via bluetooth" [Undecided,Confirmed] https://launchpad.net/bugs/72033
<lool> pitti: Not sure we want to have an obex server listening on bluetooth 100% of the time
<lool> (No open port policy?)
<pitti> ah, right
<pitti> so the bug is merely about making it much easier, not making it totally automatic?
<lool> I guess so
<mjj29> installed, but not enabled by default is probably reasonable
<mjj29> so enableable from the gnome menus
<lool> pitti: The bug seems to be about having it installed by default
<lool> Someone proposes installing it when a bluetooth device is present/inserted
<lool> I'd say we should install on mobile devices like laptops; I'm not sure it's easy to see the bluetooth adapter if it's off
<lool> (ISTR it's an USB device appearing on the USB bus on my thinkpad)
<lool> pitti: Also, I don't think there's an easy way to launch the obex server from the bluetooth adapter icon when it's visible
<geser> pitti: Hi, please give-back: libwnck. Thanks.
<pitti> hi geser; kicked
<Riddell> ArneGoet1e: why would we ever not want antialiasing by default?
<Keybuk> pitti: are ddebs not being generated automatically any more?
<seb128> Keybuk: they are, what package is that about?
<pitti> Keybuk: they are supposed to
<Keybuk> pitti: there's nothing in gutsy-security
<seb128> ah, pockets is an another story
<pitti> Keybuk: right, it seems that the sbuild hack is not applied to the security buildds
<seb128> I think it's a buildd thing
<pitti> seb128: for bug 186569, TBH I'd prefer to fix nautilus for conforming to the SuSv3 spec rather than changing ntfs3g; do you object?
<ubotu> Launchpad bug 186569 in ntfs-3g "cannot delete files off of an Fuse mounted NTFS partition in nautilus" [High,In progress] https://launchpad.net/bugs/186569
<pitti> seb128: I'll do it and forward it to upstream, just asking for your opinion
<seb128> pitti: let me ask alex, we discuss bugs on IRC usually
 * pitti hugs seb128, merci
<seb128> pitti: but are you sure it's not a ntfs3g issue?
<seb128> pitti: man rmdir on hardy doesn't list EEXIST as a valid codecase
<pitti> seb128: well, you can argue that ntfs3g should throw the errno as described in the Linux manpage of rmdir
<pitti> seb128: but since the unix spec says otherwise, I see the point of ntfs3g doing it otherwise
<seb128> why should we trust the unix specs rather than the ubuntu rmdir one?
<pitti> "NTFS-3G uses EEXIST because more software handle the relevant error scenario better that way. Seemingly that doesn't include Nautilus." -> I can't really validate this, but it should be considered at least
<pitti> seb128: well, rmdir() on ext3 just returns ENOTEMPTY exclusively, no doubt
<pitti> but it doesn't actively say "rmdir must not return anything else"?
<ArneGoetje> Riddell: in that case, the fontconfig package needs to be patched.
<Riddell> ArneGoetje: doesn't sound too hard
<seb128> pitti: well, if you can't trust the manpage ...
<pitti> seb128: I don't have a strong opinion on doing either, but in the principle of being tolerant with inputs and strict with outputs I tend to fix nautilus
<seb128> well, I'll discuss it with alex
<seb128> but I'm not fan to use workarounds for broken code
<pitti> seb128: I'll file a bug against the rmdir manpage in Debian
<ArneGoetje> Riddell: yep, will do.
<pitti> seb128: done
<seb128> pitti: thanks
<Hobbsee> pitti: i didn't know MIR's could get done without going thru universe.  that's kinda neat.
<pitti> Hobbsee: how do you mean? they should usually go through universe first
<Hobbsee> pitti: the hwdb stuff
<pitti> oh, right, that should get ~motu-release subscribed
<Hobbsee> pitti: no point now - youv'e already given the ack...
<pitti> we should consider it, though, hwdb-client is horrible
<pitti> Hobbsee: no, I didn't?
<ogra_cmpc> pitti, i was told hwdb2 is ready for hardy
<Hobbsee> well, put it on the MIR list is the same as "you have an exception for this, if it's OK", isn't it?
<Hobbsee> it's a good way for getting important stuff thru REVU
<Hobbsee> er, with avoiding REVU
<pitti> Hobbsee: no, not at all; I didn't approve anything yet, I asked to get it into universe first
<pitti> ogra_cmpc: hwdb2?
<Hobbsee> pitti: i thought your comment after reverted that, saying it was in a ppa, so that was OK
<cjwatson> seb128: if SUSv3 documents things that aren't mentioned in the Ubuntu rmdir manual page, you should trust SUSv3 rather than the manual page because many more people were involved in reviewing SUSv3 and it applies to more operating systems. If the manual page explicitly mentioned a deviation from SUSv3 then that might be a different matter, but it doesn't
<ogra_cmpc> pitti, the thing liw and cr3 work on
<ogra_cmpc> (they didnt change the gui much though)
<cjwatson> seb128: besides, the Linux manpages package only really documents what the Linux kernel does
<Hobbsee> well, for MIR review
<seb128> cjwatson: ok, I don't know what SUSv3 is and didn't know that was a reference on the topic
<pitti> ogra_cmpc: right, isn't that what hwtest is?
<ogra_cmpc> thats the replacement
<cjwatson> seb128: SUSv3 == POSIX
<cjwatson> http://www.opengroup.org/onlinepubs/009695399/nfindex.html
<ogra_cmpc> pitti, once you see its gui you understand :)
<ogra_cmpc> it looks pretty miuch identical
<pitti> cjwatson: my thought as well, that's why I filed a bug against manpages-dev (not in the BTS yet)
<ogra_cmpc> just the insane backend is gone
<cjwatson> seb128: definitely the applicable standard :)
<seb128> cjwatson: ok, good to know, thanks ;-)
<seb128> speaking about fuse, could we add desktop users to the fuse group on hardy?
<seb128> what would be the right place to discuss that? irc? mailing list? launchpad?
 * ogra_cmpc wouldnt mind
<ogra_cmpc> would make things easier in ltsp land as well ...
<seb128> gvfs does fuse mounts transparently when accessing a network location which means applications not using vfs can access network shares transparently
<ogra_cmpc> seb128, do you plan gvfs-fuse in the desktop as well ? i heard there are some massive probs with sabayon
<seb128> ogra_cmpc: no idea about sabayon, we got no bug on launchpad and it's not in the default installation
<ogra_cmpc> seb128, i was planning to pull it into e-dsktop
<seb128> ogra_cmpc: I don't think it's a desktop user application
<ogra_cmpc> (thats why we had so many sessions about it in boston :))
<seb128> and yes having gvfs-fuse in the desktop installation would be nice
<ogra_cmpc> seb128, well, then edubuntu-server in any case it will end up on the edubuntu cd
<pitti> seb128, cjwatson: FYI, Debian bug 467552
<ubotu> Debian bug 467552 in manpages-dev "rmdir(2) can return EEXISTS, too" [Normal,Open] http://bugs.debian.org/467552
<ogra_cmpc> seb128, ok, thats all i wanted to know :)
<cjwatson> seb128,ogra_cmpc: we discussed this 20 days ago in this channel and the agreed output was not to add all users by default, and for Oliver to add a notification to fuse-utils. However, I'll make the user-setup change now to add the default user to the group
<cjwatson> seb128: see http://irclogs.ubuntu.com/2008/02/06/%23ubuntu-devel.txt for the log
<seb128> cjwatson: right, I know we discussed it but I didn't open a bug or anything and no change was made that's why I was asking again
<seb128> cjwatson: thanks ;-)
<ogra_cmpc> i'll do the fuse change today ...
<cjwatson> user-setup> will do it once we've fixed a bit of bzr desync
<seb128> pitti: http://bugzilla.gnome.org/show_bug.cgi?id=518816
<ubotu> Gnome bug 518816 in general "should handle rmdir returning EEXIST correctly" [Normal,Unconfirmed]
<pitti> seb128: cool, thanks; did alex agree?
<hackeron_> hey, it seems hardy is ignoring my xorg.conf -- I have Modes           "800x480" - yet hardy starts X with "800x600" -- Is there anyway to force hardy to use my required resolution?
<pitti> Riddell: does anything in Kubuntu still use cupsys' enable_{browsing,sharing}?
<Ng> is sun-java6-plugin supposed to be empty apart from directories?
<Riddell> pitti: no
<seb128> pitti: the gvfs fix has been commited to svn and uploaded to hardy now
<cjwatson> mjg59: are you planning to push that vt font restoration patch to the hardy kernel?
<pitti> seb128: wow, that was fast
<mjg59> cjwatson: Can do
<cjwatson> thanks
<seb128> carlos, pitti: any idea of why seahorse.mo is not in the hardy language packs?
<pitti> hm, according to the build logs they were stripped
<pitti> seb128: from what I can see it's probably stuck in the LP translations moderation queue?
<seb128> pitti: no idea, that's why I was asking
<seb128> is carlos on holidays this week?
<seb128> right, he's not working today, ok will ask him tomorrow
<pitti> sorry, I tried to find it out using the webui, but it's not really searchable enough
<seb128> that's alright
<ScottK> pitti: I was looking into recent Debian changes in cyrus-sasl and it looks like there are some fixes worth a merge to get.  I'm a little uncertain how to proceed since when Debian incorporated your lidbd4.6 migration patch they did it slightly differently.  Would you please take a look at it and advise me if their patch is appropriate?
<pitti> ScottK: looking
<ScottK> Thanks
<pitti> ScottK: meh, our Ubuntun diff is horrible, 2.6 MB
<pitti> and only because someone autoreconf'ed with a wildly different version
<pitti> ScottK: can you please clean this up during the merge?
<ScottK> pitti: I can try.
<ScottK> pitti: I'm not certain this is one I'll be sufficiently confident to do on my own, but I'm going to give it a shot and see how it goes.
<pitti> ScottK: confirmed that the Debian patch for db migration is fine
<ScottK> pitti: Thanks.  I'll add that back to my TODO then.
<cjwatson> tjaalton: ooh. I figured out the console-setup 'any' keysym bug
<cjwatson> -               && ($symbol !~ /^nosymbol$/i
<cjwatson> +               && ($symbol !~ /^(?:nosymbol|any)$/i
<cjwatson> all that over a one-liner ;-)
<\sh> slangasek: thx again for your help yesterday night :) I found the error actually...and it has nothing to do with ubuntu or anything from the system
<ogra> seb128, hmm, with gvfs my ltspfs patches seem not to work anymore, i suddenly have unmount options for ltspfs devices in nautilus
<seb128> ogra: sure, gvfs has no ltsp patch yet
<ogra> right, seems i need to look into that
<seb128> you are welcome to do the patch porting
<ogra> i have to look at gvfs first :)
<seb128> I will have a look otherwise but that was not a priority on my list before getting gvfs uploaded
<ogra> right, understood
<ogra> i just noticed it after upgrading my ltsp server
<tjaalton> cjwatson: yay :)
<cjwatson> Riddell: please push your ubiquity 1.7.12 release to bzr
<Mithrandir> pitti: 72033 is fixed with the new bluez-gnome
<pitti> ah, neat
<cjwatson> Riddell: also if you could try to avoid the tab characters in debian/changelog that make vim display them in red as errors, that'd be good ;)
<Riddell> hmm, I'm sure I did
<Riddell> right, I missed the final commit
<cjwatson> 'bzr bind' is your friend :)
<ogra> http://paste.ubuntu-nl.org/57470/ any comments from native english speakers ?
<ogra> (thast supposed to become teh fuse-utils notification)
<jdong> ogra: awfully wordy for a simple concept IMO
<ogra> jdong, i'm open for everything, suggest a better text
<ogra> it shouldnt scare my mom on upgrades please :)
<jdong> ogra: "Please add users to the 'fuse' group to grant permission to use fuse filesystems" would be a good paraphrase
<jdong> probably not optimal either, but I don't see a reason why it can't be said in a sentence
<jdong> if you choose to go with the original, s/base/basis/
<ogra> well, i thought some slightly more explaining text of teh why/how might be good
<jdong> ogra: "For security reasons, only members of the 'fuse' group are permitted to use fuse filesystems. Please use the Users and Groups administration tool to grant users this priviledge"
<ogra> now *that* sounds good :)
<cjwatson> (it's spelled "privilege")
<jdong> oops thanks cjwatson :)
<cjwatson> can we also ban the text "For security reasons"?
<cjwatson> we aren't an airport :)
<ogra> lol
<jdong> lol
<ogra> dont leave your files unattnded :)
<ogra> *unattended
<jdong> Please keep your tarballs in 3kb or smaller containers in a quart sized ziploc bag
<ogra> ok, i'll go with the above then, minus the security warning and typo
<ogra> what about the title ?
<ogra> Name: Filesystem in userspace access info
<cjwatson> "Only members of the 'fuse' group are permitted to use userspace file systems, since this is a powerful facility that has not been completely audited for safety."
<cjwatson> something like that?
<cjwatson> I think the installer goes for "file system" rather than "filesystem" consistently
<ogra> uh, that implies its insecure
<cjwatson> so does "for security reasons"
<ogra> yeah
<pitti> BenC: are you fine with bug 188806?
<ubotu> Launchpad bug 188806 in git-core "Please sync git-core 1:1.5.4.3-1 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/188806
<cjwatson> the discussion the other day was that we weren't confident enough in it to grant access to it to all users
<cjwatson> which is pretty much what the above is saying
<BenC> pitti: yeah
<pitti> BenC: i. e. do you know whether the new version introduces any behaviour changes, and have you used it?
<pitti> BenC: ok, thanks
<cjwatson> ogra: title> "Using userspace file systems"
<ogra> thanks ...
<cjwatson> although "userspace" is still jargon; I'm not sure how far we can go given that the whole thing is fundamentally jargon
<ogra> i'd really rather formulate it positive ... like "to gain you conntrol over access of ..." or so
<ogra> *control
<cjwatson> actually, the obvious flaw in all of this is that if you don't know what fuse is then you have no idea what it grants you access to
<ogra> instead of implying its not safe
<ogra> right
<jdong> cjwatson: well presumably someone who's just installed fuse-utils should know what it is?
<cjwatson> so it needs some examples, like NTFS, sshfs, etc.
<jdong> ah, examples would be nice :)
<cjwatson> jdong: not given that it's installed by default, no
<jdong> oh I totally forgot about ntfs-3g by default
<ogra> jdong, you will get the note on upgrades
<cjwatson> ogra: perhaps drop the bit about auditing but still include "powerful" in the text, which gives users a hint why it's not available across the board
<jdong> ogra: should we instead make the fuse frontends display this message?
<ogra> jdong, every single one ? that would get annoying if you have multiple ones installed
<ogra> i.e. i have ltspfs here, sshfs, through the default install i get ntfs3g ....
<cjwatson> "FUSE is a powerful facility that allows users to create virtual file systems. It can be used for applications ranging from digital cameras through online photo-sharing to compatibility with Microsoft Windows file systems."
<pitti> ScottK, mathiaz: could one of you please have a look at bug 79371 while you touch cyrus-sasl? seems to be an easy fix
<cjwatson> something like that?
<ubotu> Launchpad bug 79371 in cyrus-sasl2 "saslauthd init script does not allow movement of PID" [Low,In progress] https://launchpad.net/bugs/79371
<ogra> "By default access to it is only granted to the first user of the system to gain the system administrator full control over access. Please add users to teh fuse group to your liking"
<ogra> the repititive "access" isnt good though
<cjwatson> it also needs more punctuation
<ogra> yeah, i suck at that
<ogra> but something in that spirit combined with your explanation
<cjwatson> "By default, only the first user is allowed to work with virtual file systems. To grant access to other users, add them to the 'fuse' group."
<ogra> oki
<cjwatson> or something along those lines
<mjg59> I think "virtual file systems" is potentially confusing
<cjwatson> aye
<mjg59> As well as being inaccurate :)
<cjwatson> as it happens, I was quoting 'apt-cache show fuse-utils'
<mjg59> Heh
<ogra> mjg59, userspace filesystems instead ?
<mjg59> Yeah, though I'm not sure that's terribly meaningful for most people
<mjg59> I can't think of anything better off-hand, though
<ogra> thats my final text now: http://paste.ubuntu-nl.org/57475/+
<ogra> err
<ogra> http://paste.ubuntu-nl.org/57475/
<cjwatson> "fuse-based"
<ogra> ah
<cjwatson> and I think the second and third paragraphs should be merged into one paragraph
<ogra> ok, done http://paste.ubuntu-nl.org/57476/
<cjwatson> good enough for me
<CyberSnooP> "create userspace file systems" or "use userspace file systems"?
<cjwatson> CyberSnooP: "mount", really, except that's more jargon. You can use a fuse filesystem mounted by another user without needing to be in the fuse group yourself.
<CyberSnooP> yeah, the whole thing is leaning toward jargon anyway so I guess there is no easy way to get it right.
<Keybuk> that's ok compiz ...
<Keybuk> I didn't need window management anymore
<geser> Keybuk: isn't a terminal on each side of the cube enough?
<keescook> Keybuk: can you take a look at the most recent patch to 45842?  We were unable to reproduce the "does not mount" bug, but this fixes documentation, possible races, and the mtab bug for network fs's
<Keybuk> keescook: err, so it's not an ifup script anymore?
<Keybuk> oh, sorry, I didn't see the + at the end
<keescook> *ctrl-u* yawp
<Keybuk> I'm not sure the extra call is needed, but otherwise I see where you're going
<keescook> Keybuk: also, if it uses watershed, should we explicitly add udev as a Depend
<Keybuk> yes
<keescook> okay, we'll get that fixed
<keescook> the extra is kind of a "it doesn't hurt and may fix future problems or issues that are hard to reproduce"
<Keybuk> I have a natural distaste for "just in case" coding ;)
<Keybuk> but that's just a personal issue <g>
<keescook> Keybuk: yeah, I figured that'd be the oddest part for you.  I'm taking the angle of "for Hardy, this seems more stable".  I'd be happy to rip it out for intrepid
<Keybuk> sure :)
<Keybuk> imagine my displeasure at discovering that the reason we call sync before reboot is "just in case"
<keescook> okay, so I'll take this as a +1 from you then, and get it fixed and upload.  :)
<keescook> sync> hehe
<Keybuk> I like to think that the kernel is not silly enough to discard writes when it feels like it
<Keybuk> but I'm odd like that
<keescook> I'd tend to agree.  :)
<Keybuk> had an interesting experience the other day along those lines actually
<Keybuk> had copied lots of stuff onto USB storage device
<Keybuk> and shutdown the machine
<Keybuk> and as it was going down thought "hey, I wonder whether it's actually going to finish writing and unmount that"
<Keybuk> happily it stopped at "Will now halt..." sufficiently long that usplash timed out
<Keybuk> (it amuses me that halt() appears to not actually stop processes)
<Keybuk> and after a short while, powered off
<Keybuk> so it must have been writing out to the disk still
<keescook> so it correctly sync'd then?
<mjg59> Yes, filesystems are synced before the machine is halted
<keescook> kernel ftw
<Keybuk> mjg59: it seems they mostly are
<Keybuk> we think we found a couple of cases where they may not have been
<Keybuk> but didn't follow them up yet
<mjg59> device_shutdown() isn't called until after that, to the best of my knowledge
<Keybuk> I'm pretty sure one of them involved the ide subsystem, so was irrelevant
<mjg59> That was cache flushing, no?
<Keybuk> err, can't remember; you could possibly be right
<mjg59> The filesystem stuff is at the VFS and block device level
<mjg59> Hardware subsystems then need to make sure that writes have actually hit the disk
 * mjg59 goes out
<Keybuk> ah, you're absolutely right
<ogra> cjwatson, hmm, did you ever notice the " #!/bin/bash -e" at the top of the fuse-utils.postinst ?
 * ogra doesnt see any bashisms in there that would justify it 
<cjwatson> ogra: I don't see any bashisms either. I imagine it was there before I touched it and I never bothered changing it
<ogra> i'll try with plain /bin/sh
<ogra> if it works i'll change it
<cjwatson> Riddell: ubiquity 1.7.12 final commit is still missing from bzr
<cjwatson> Riddell: please push it so that we don't have to merge
<Riddell> cjwatson: sorry, done that now
<cjwatson> Riddell: thanks. FWIW I find 'debcommit --release' to be a useful habit (and it tags too, if your bzr branch format is new enough)
<netzmeister> pitti:  ping
<netzmeister> crimsun_:  did you know how can i contact Colin Watson?
<netzmeister> s/did/do
<cjwatson> netzmeister: hello
<netzmeister> cjwatson:  hello..
<netzmeister> cjwatson:  i need some info about that bug...
<netzmeister> https://bugs.launchpad.net/ubuntu/+source/grub/+bug/22220/comments/26
<ubotu> Launchpad bug 22220 in grub "Correct modules for I2O-based raid are not loaded" [High,Fix released]
<netzmeister> ? nice feature here.. :-)
<cjwatson> netzmeister: should be fixed in 6.06.2
<netzmeister> cjwatson:  the latest ISO's on ubuntu.com?
<netzmeister> if it is 6.06.2 the bug isn't fixed..
<cjwatson> http://releases.ubuntu.com/6.06.2/
<cjwatson> netzmeister: if there's still a problem, please update the bug with all relevant detail
<cjwatson> it is entirely possible it is a specific problem with your hardware rather than a recurrence of the general problem, for instance
<netzmeister> cjwatson:  jep there is still a problem..
<netzmeister> :(
<netzmeister> i don't understand, because the installer works perfectly.
<nosrednaekim> pitti: ping
<shaya> anyone use bzr on feisty?  the package seems broken to me
<nosrednaekim> shaya: if you are try to use it with launchpad, I think you need to use the latest version
<shaya> nosrednaekim: just trying to run it
<shaya> errors out w/ python error
<shaya> can't find bzrlib
<shaya> very default feisty installation
<nosrednaekim> shaya: oh... whats the error?
<shaya> ImportError: No module named bzrlib
<shaya> Please check bzrlib is on your PYTHONPATH....
<shaya> could it be a python problem? (updating python now, but download is slow, only 120kB/s)
<nosrednaekim> shaya: did the package install correctly? and did you install bzr-common (I think there is apckage called that)
<shaya> no bzr-common in fesity
<shaya> bzr, bzrtools
<shaya> works on my debian testing box w/o a proble
<pochu> is ubuntu-minimal installed in buildds?
<pochu> or does anyone know why gnome-build fails to build in the buildds but builds in my pbuilder and in debian? http://launchpadlibrarian.net/12236635/buildlog_ubuntu-hardy-i386.gnome-build_0.2.3-1ubuntu1_FAILEDTOBUILD.txt.gz
<pochu> this is the new configure check: http://pastebin.com/f65e1711a
<cjwatson> the buildd chroot does not install ubuntu-minimal
<cjwatson> start with 'debootstrap --variant=buildd' if you want to reproduce it
<shaya> ok, seemed like a python bug
<shaya> updated python fixed it
<pochu> cjwatson: thanks. seb128 suggested it could be liblocale-gettext-perl, which is priority required in debian, but I've noticed ubuntu-minimal depends on it (indirectly)
<cjwatson> it's actually priority required in Ubuntu too (due to adduser), so I'm not entirely sure why it isn't installed, but no matter, you should have a build-dependency on it anyway
<emgent> pitti, ping
<Riddell> slangasek: how come you didn't remove xen-unstable in bug 195453 ?
<ubotu> Launchpad bug 195453 in xen-source "Please remove xen-{source,unstable} from hardy" [Undecided,Fix released] https://launchpad.net/bugs/195453
<slangasek> Riddell: I was checking with geser whether it needed blacklisting; it's blacklisted now, you can do the xen-unstable removal or I can
<Riddell> slangasek: thanks, I'll do it
<okaratas> hello
<tino> hello
<luisbg> is there a problem with the bzr package in gutsy?
<luisbg> two friends already asked they are having trouble and they are running an old version
<luisbg> but up to date to the repo
<TheMuso> luisbg: They could still be bitten by the python-central issues that were around a week or so ago./
<luisbg> TheMuso, ouch! that's true
<geser> TheMuso: they affect also gutsy? I thought they affected only hardy
<TheMuso> oh sorry, right.
<somerville32> Where are the global gtkrc-2.0 settings kept?
<seb128> somerville32: what do you want to know exactly?
<seb128> somerville32: there is no global configuration, each theme has its own gtkrc
<somerville32> hmmm
<somerville32> Ok, I think you've answered my question thanks.
<seb128> you are welcome
<zyx386> hi
<zyx386> we are as Kurdish users of ubuntu, have we ubuntu on our language however mussen we manuel after that installation kurdish fonts the package to add. it would better be if beside many fonts packages kurdish fonts also in usr/shre/fonts its.
<zyx386> can anyone answer me!?
<zyx386> :)
<zyx386> that is very very important for us.
<somerville32> zyx386: You should file a bug report.
<zyx386> somerville32, that is not bug!
<slangasek> zyx386: the solution is to identify the missing font packages and have them added to a language-support-fonts-ku package, depended on by language-support-ku
<slangasek> zyx386: of course it's a bug.
<zyx386> ok who can report bug?
<somerville32> zyx386: You can :)
<somerville32> zyx386: http://launchpad.net/ubuntu/+filebug
<zyx386> yes thanx
<slangasek> rather, http://launchpad.net/ubuntu/+source/language-support-ku/+filebug
<ScottK> zyx386: I think I know of a font that might work reasonably well that's already packaged for Ubuntu.  I need a moment to check.
<zyx386> ok
<zyx386> her is some report about my Q
<zyx386> https://bugs.launchpad.net/ubuntu/+source/djvulibre/+bug/33981
<ubotu> Launchpad bug 33981 in djvulibre "No font for Kurdish in Arabic script" [Medium,Fix released]
<zyx386> uboto no, is not fixed
<ScottK> https://launchpad.net/ubuntu/+source/ttf-sil-scheherazade is a font that is said to support Kurdish.
<ogra_cmpc> according to that bug above the kurdish characters are in the DejaVu Sans font
<slangasek> uh.  how did a font bug get filed against djvulibre?
<zyx386> ScottK, i mean kurdish in arabic script, if inot add the font paket manuel. can't see any website in kurdish (sorani)
<ScottK> zyx386: ttf-sil-scheherazade is an arabic font.
<zyx386> but not kurdish
<zyx386> arabisch fonts are not utf-8
<slangasek> that's not true
<ScottK> zyx386: http://www.wazu.jp/gallery/views/View_Scheherazade.html is does have Kurdish
<slangasek> whether a font is unicode has nothing to do with whether it's arabic
<ScottK> is/it
<zyx386> ScottK, that is kurdisch fonts Sorani
<zyx386> http://www.wazu.jp/gallery/Fonts_KurdishA.html
<ScottK> zyx386: Scheherazade is one of the fonts listed on that page.
<zyx386> ScottK, this page are not complet correct kurdisch fonts, sschehrezade fonts is arabisch fonts but is edited to kurdisch and have arabic encoding
<zyx386> i mean 44 kurdish fonts Unkurd Fonts(unicode fonts)
<ScottK> zyx386: Would Scheherazade be better than what you have now?
<zyx386> no schehrezade is not Unikurd fonts
<zyx386> the unikode font begin with Uni###
<zyx386> that is correct list from unikurd fonts
<zyx386> http://kurditgroup.org/download/fonts
<slangasek> zyx386: can you please explain again why the scheherazade font is not suitable for this purpose?  It's already in the archive, so if there are bugs with it that we can fix, that would be a shorter path to a solution
<ogra_cmpc> so scheherazade wouldnt display your webpages correctly ? do you have a page that shows wrong font behavior with the fonts missing ?
<zyx386> slangasek, i try to explain you, sorry for my bad englisch. i can german to
<zyx386> also Sherhrezad fonts is arabic fonts under encoding arabich
<slangasek> what do you mean by "encoding arabisch" (arabic encoding)?
<slangasek> are the glyphs needed by Kurdish present in the font?
<zyx386> but the Unkurd font under encoding UTF-8, and is standard in all kurdish webpage
<zyx386> ok
<zyx386> the 99% kurdish website used this fonts as standard
<zyx386> Unikurd Web
<slangasek> the encoding for a webpage, and the encoding for a font, do not have to be the same in order for them to be used compatibly
<slangasek> it's only required that the system *know* the encoding of each, and know how to map between the encodings
<ScottK> http://www.omniglot.com/writing/kurdish.htm seems to show that standard Arabic fonts should be adequate.
<zyx386> schehrezad font is unknown, the standard fonts is Unikurd Web
<slangasek> when I visit http://kurditgroup.org/download/fonts from Ubuntu, I see text in Kurdish.  I of course don't know if it's correct, or if there are characters missing, because I don't speak Kurdish; but the text displays
<zyx386> for exapmle
<slangasek> so I don't see any encoding problem
<zyx386> slangasek, can you tke screen shot
<zyx386> for expample show all CSS page
<zyx386> http://www.webchin.org/style/style.css
<zyx386> Unikurd Web is  standard
<zyx386> or Tahoma
<slangasek> zyx386: http://people.ubuntu.com/~vorlon/Screenshot-kurditgroup.png
<zyx386> wow
<zyx386> i test with ubuntu!!
<zyx386> but have ubuntu or debian, because of debian is ok
<ScottK> Works fine with Kubuntu too.
<zyx386> ScottK, just 1min
<somerville32> Works fine with Xubuntu too
<slangasek> this screenshot is with Ubuntu; it's hardy, the upcoming release, so I don't know for sure if it works the same in Ubuntu 7.10
<ScottK> slangasek: It displays fine on my Dapper Kubuntu in Firefox, so I suspect all the ones in between work too.
<zyx386> slangasek, of 7.10 not worked fine
<zyx386> in Faist fawn and dapper have no problem
<zyx386> i remove the kurdish font paket and take screenshot ok
<ScottK2> I'm on Gutsy Kubuntu now and it looks like slangasek's screen shot.
<zyx386> i find it
<zyx386> the problem is firefox
<zyx386> because of galeon have no prblemo
<ScottK2> Works fine for me with both Firefox and Konqueror.
<zyx386> ScottK, test this website please and take screenshot
<zyx386> i think the problem is CSS atribude
<slangasek> zyx386: can you show us a screenshot of the wrong behavior, instead?
<zyx386> ok
<zyx386> http://img508.imageshack.us/img508/8038/screenshotnh0.png
<cjwatson> that looks like lack of proper Arabic shaping to me ...
<cjwatson> (by which I mean Arabic and related scripts)
 * ScottK2 needs to go eat dinner.
<cjwatson> seems to display much better in Firefox 3 in Hardy; it may simply be that Firefox 2's Arabic shaping support was poor
<zyx386> cjwatson, correct
<zyx386> ok i found my annswer, and thank you Ubuntu
<zyx386> thanx all
<cjwatson> (not that I would know for sure, I can just see that characters are joined up better; and I have to go to bed ;-) )
<ogra_cmpc_> probably a good ised
<ogra_cmpc_> *idea
<zyx386> have nice time all
<TheMuso> Hrm. Are there any known issues with python and apps not being able to import module _bsddb?
#ubuntu-devel 2008-02-27
<dholbach> good morning
<pitti> Good morning
<Hobbsee> morning pitti!
 * pitti hugs Hobbsee
 * Hobbsee hugs pitti back
<milli> alright...  running 'update-manager -d' from a mostly gutsy AMD64 box, (still have feisty kernel 2.6.20 because of sky2 driver issues in 2.6.22)
<LaserJock> pitti: morning
<Mithrandir> pitti: why do you think that the obex-data-server runs as root?
<Mithrandir> tfheen   23119  0.0  0.0  30604  2044 ?        S    Feb25   0:00 /usr/bin/obex-data-server --no-daemon
<Mithrandir> pitti: (this is the o-d-s MIR, bug 193816)
<ubotu> Launchpad bug 193816 in obex-data-server "Main Inclusion Request" [Undecided,Incomplete] https://launchpad.net/bugs/193816
<pitti> Mithrandir: I didn't find a place where it would specify an user name, but so much the better; thanks!
<pitti> Mithrandir: I wasn't able to actually spawn the daemon
<pitti> I played with some fake dbus-send commands, but these didn't bring it iup
<Mithrandir> hm, ok.  What kind of problem did you run into?
<pitti> s/iup/up/
<pitti> Mithrandir: I was just waiting for your answer; seems all fine now
<Mithrandir> pitti: ok, so MIR approved then?
<Mithrandir> I'll be happy to add this to the bug log for documentation purposes.
<pitti> yep, I will add it there in a second
<LaserJock> pitti: not sure if you have time/interest but I just uploaded my squeak packages to NEW
<Mithrandir> pitti: cheers and thanks.  I'll upload the new bluez-gnome then
<pitti> Mithrandir: approved in the bug and promoted
<pitti> LaserJock: Seb's archive day today, but if it's still there on Friday I'll get to it
<LaserJock> pitti: k, np
<pitti> LaserJock: btw, do the new langpacks in -updates finally work for you?
<LaserJock> let me check specifically real quick, the ones in the PPA did
<dholbach> hey seb128
<seb128> hello dholbach
<seb128> how are you?
<dholbach> good - how 'bout you?
<seb128> tired but good otherwise, thanks ;-)
 * dholbach hugs seb128
 * seb128 hugs dholbach
<mdke> morning all.
<mdke> seb128: you pinged yesterday?
<seb128> hey mdke
<mdke> hiya, how are you?
<LaserJock> mdke: hello!
<mdke> LaserJock: hi :)
<seb128> mdke: yes, the ubuntu layout patch, the easy changes you described doesn't match the code, I commented on IRC about that some time ago but maybe you didn't read it there
<seb128> mdke: basically I'm waiting for somebody to ubuntu the patch for hardy
<mdke> seb128: ah, I didn't see that on irc - fine. I'll have to chase Don, I think
<mdke> I'll do that asap
<seb128> I'll likely have a look if nobody else does but I don't know how to do that and I've other things on my list ;-)
<seb128> mdke: thanks
<seb128> carlos: hey
<seb128> carlos: do you know why the seahorse translations are not in the hardy language packs?
 * carlos tests
<carlos> well, checks :-P
<seb128> carlos: we got a bug about that weeks ago and I though it would be fixed in the next updates but there is no change
<carlos> at first sight, everything looks ok
 * carlos does a deeper check
<pitti> hey carlos
<pitti> carlos: I moved all -proposed langpacks to -updates yesterday, so we can mark them as 'used' in the db
<LaserJock> pitti, carlos: gcompris is looking great here
<LaserJock> thanks for the work!
 * LaserJock wanders of to send an email to upstream
<carlos> pitti: ok, thanks
<dholbach> TheMuso: http://mces.blogspot.com/2008/02/gnome-outreach-program-accessibility.html - wow! :)
<TheMuso> dholbach: Yeah I know about it.
<carlos> pitti: btw, is that only for Gutsy or for Dapper, Feisty and Gutsy?
<TheMuso> dholbach: Lets say I'm involved in a big way.
<pitti> carlos: dapper, edgy, feisty, gutsy
<carlos> ok
<carlos> pitti: btw, didn't you update Hardy's base language pack recently too?
<pitti> carlos: I want to, but I didn't yet
<pitti> carlos: I added some filtering code to remove "msgid == msgstr" strings to conserve some space
<carlos> seb128: I think I found a possible problem, but I need to do some more investigation. Will ping you once I can confirm / reject it as the problem
<seb128> carlos: ok thanks
<carlos> pitti: ok. I detected a problem with language packs in Hardy, so seems like we were getting differences from the wrong base package (differences are against 20080122 but base package in Hardy is the one from 20080119)
<carlos> pitti: having a new base language pack would help to fix that
<carlos> pitti: btw, this month, I'm supposed to finish the missing parts to update that information with each package upload instead of doing it manually
<carlos> which should help to prevent this kind of problems...
<geser> good morning
<asac> ArneGoetje: whats your preferred email?
<asac> ArneGoetje: hmm is ~arnegoetje you on launchpad? there are no emails listed
<pwnguin> is there anything close to a standard interpretation of USB HID?
<pwnguin> in particular, people writing games intending to support gamepads, is there any hope of simply using HID and not having to deal with binding axis and buttons to labels?
<tkamppeter> hi pitti
<ionstorm> anyone know if ubuntu-restricted-modules-generic 2.6.24-10 is in repo's?
<ionstorm> I cannot grab it
<persia> pwnguin: Much better to provide a configurator, so that the game supports all of a 2-axis 1-button joystick, a 12-axis 37 button joystick, and someone with a couple of PowerMates.
<pitti> hi tkamppeter
<carlos> seb128: found the problem. It's not exactly what I thought. We approved its .pot file last 20th February so that's why we didn't get any translation in language pack until then
<carlos> seb128: latest update does include those translations
<ArneGoetje> asac: yes. fixed. :)
<asac> ArneGoetje: thanks. i forwarded to @canonical for now
<asac> ArneGoetje: can we get that?
<seb128> carlos: thanks, is there any work in progress to have translations automatically approved or something?
<seb128> carlos: what is the point to have those waiting weeks for approval?
<tkamppeter> pitti, it seems that the CUPS daemon can segfault under certain conditions, with both 1.3.5 and 1.3.6 (so the 1.3.6 update did not break anything here): bug 148910, bug 195965, bug 194580
<ubotu> Launchpad bug 148910 in cupsys "cupsd crashed with SIGSEGV" [Medium,Incomplete] https://launchpad.net/bugs/148910
<ubotu> Launchpad bug 195965 in cupsys "package cupsys 1.3.6-1ubuntu1 failed to install/upgrade: subprocess post-installation script returned error exit status 3" [Undecided,New] https://launchpad.net/bugs/195965
<ubotu> Launchpad bug 194580 in cupsys "cupsd crashed with SIGSEGV in strcasecmp()" [Medium,New] https://launchpad.net/bugs/194580
<carlos> seb128: we need to improve our logic to 'port' blocked entries from one release to another (documentation and package templates that are not yet handled in Launchpad and language-packs) so the queue is cleared as soon as possible automatically. Right now is a manual process
<seb128> ok
<seb128> carlos: thanks for approving those ;-)
<seb128> carlos: btw do you have a list of hardy packages which don't build a template somewhere?
<seb128> carlos: if we have some of those now would be a good time to fix the builds
<carlos> not yet, I wanted to clear the queue first. but I plan to have such report today and prepare it to add a new page to launchpad that shows such information
<seb128> carlos: thanks
<carlos> well, today == this week
<carlos> ;-)
<carlos> seb128: btw, for seahorse, from what I see at https://launchpad.net/ubuntu/+source/seahorse/+publishinghistory
<asac> carlos: hi, will you still be here later today?
<carlos> it was moved to main on 2008-01-17 and it was approved a month after that. Not perfect but it was not so bad O:-) (forget this joke, I thought it was moved 2008-02-17)
<carlos> asac: yeah, my day just started
<seb128> carlos: it's not really bad but it could be better ;-)
<carlos> yeah
<Keybuk> you know how cdbs reduces /usr/share/doc contents to symlinks if already in a dependency package?
<Keybuk> how do I force that for another package?
<Keybuk> I have a libfprint-doc package which gets README, etc.
<Keybuk> but it doesn't symlink those to libfprint0 by default
<Keybuk> (since assumedly the indep -doc gets build before the arch lib package)
<ArneGoetje> asac: yes, will do that later.
<asac> thanks
<asac> Keybuk: i think you would need to patch debhelper.mk to force that
<Keybuk> is it ok if those files are duplicated?
<pwnguin> persia: one of the troubles I'm having is deciding what exactly to bind my wiimote stuff to ;)
<zyx386> hi all again :9
<zyx386> i have some question about this bug report
<zyx386> https://bugs.launchpad.net/ubuntu/+source/djvulibre/+bug/33981
<ubotu> Launchpad bug 33981 in djvulibre "No font for Kurdish in Arabic script" [Medium,Fix released]
<asac> Keybuk: i don' think that we need to eliminate _all_ doc duplicates as long as we catch most of them.
<zyx386> ScottK, you say the ttf-sil-scheherazade is ubuntu now, but i have gutsy and musst i add the ttf-sil-scheherazade manuel.
<pitti> tkamppeter: is that known upstream already?
<tkamppeter> I do not know. I think I should report a high-priority upstream bug on them.
<ionstorm> can someone change the topic and mention that the linux-restricted-modules-2.6.24-10-generic package is not built for i386 yet? :)
<pitti> tkamppeter: does it happen to be http://www.cups.org/str.php?L2656 ?
<ubotu> CUPS bug 2656 in Core CUPS Software "cupsd dies due to double freeing of a remote printer" [Priority high,Closed w/resolution]
<tkamppeter> pitti, Mike Sweet has fixed this STR mid-January, so at least CUPS 1.3.6 cannot crash on it any more.
<tjaalton> archive problems again? the latest lrm for i386 is not available on the archives
<tjaalton> oh, it was mentioned already
<pitti> ah, it's in NEW
 * pitti pokes
<tjaalton> yeah, the first upload was buggy :/
<tkamppeter> pitti, I have now posted CUPS STR 2722
<tkamppeter> ubotu, you must say http://www.cups.org/str.php?L2722 now.
<ubotu> CUPS bug 2722 in Core CUPS Software "CUPS daemon segfaults under certain conditions" [Priority high,New]
<pitti> cups bug 2722
<pitti> cups str #2722
<pitti> hmm
<tkamppeter> some improvements are still needed at ubotu.
<tkamppeter> CUPS bug 2722
<ubotu> CUPS bug 2722 in Core CUPS Software "CUPS daemon segfaults under certain conditions" [Priority high,New] http://www.cups.org/str.php?L2722
<pitti> ok, linux-restricted-modules-2.6.24 NEWed
<tkamppeter> case-sensitive, this needs to be changed.
<tkamppeter> And also CUPS STR ... should work.
<tkamppeter> pitti, how can we get a stack trace for bug 195965? Problem is here that it is triggered by package installation and not by a crash/segfault recognition.
<ubotu> Launchpad bug 195965 in cupsys "package cupsys 1.3.6-1ubuntu1 failed to install/upgrade: subprocess post-installation script returned error exit status 3" [Undecided,New] https://launchpad.net/bugs/195965
<pitti> tkamppeter: ask people to do sudo /etc/init.d/cupsys start ?
<pitti> this should crash as well, and then apport should kick in
<tkamppeter> pitti, done.
 * pitti wonders why he gets a pretty ominous upgrade warning about fuse groups
<pitti> ogra: you discussed that yesterday, didn't you?
<pitti> ogra: AFAIK I need fuse for ntfs-3g, so maybe that should be pointed out, too
<ogra_cmpc> pitti, right
<ogra_cmpc> pitti, on;ly the first user is in the group by default
<pitti> ogra_cmpc: also "only the first user" is slightly misleading
<ogra_cmpc> well, the install user, call it how you like :)
<pitti> I'm uid 1000 and not in fuse
<ogra_cmpc> i'm open for suggestions
<pitti> and this is a hardy-5 installation
<ogra_cmpc> because you upgraded ...
<ogra_cmpc> colin changed it yesterday iirc
<cjwatson> right, for fresh installs
<pitti> but isn't the entire point of an upgrade notification to apply to upgrades? :)
<cjwatson> that's a fair point
<ogra_cmpc> right
<cjwatson> *old* first users won't be in that group
<pitti> what actually changed? I mean, ntfs-3g worked OOTB before
<ogra_cmpc> pitti, nothing ... buut we have tons of bugs because admins dont get the concept that they need to add the users to fuse
<pitti> seb128: oh, btw, auto-mount of encrypted partitions now works again; thank you!
<pitti> ogra_cmpc: ah, ok
<zdzichuBG> fedora just discussed dropping fuse group altogether
<pitti> ogra_cmpc: so it sounds much scarier than it actually is :)
<ogra_cmpc> so either you add all users by default or notify the admin somehow
<seb128> pitti: thanks for testing, and that's upstream who did the work but good to know it's working ;-)
<ogra_cmpc> i'm open for better text suggestions indeed :)
<pitti> or make it available for all local users
<seb128> I think it would make sense for all local users
<ogra_cmpc> how would you tell local from non local here ...
<ogra_cmpc> thats on a group level
<pitti> CK?
<ogra_cmpc> ugh
<ogra_cmpc> please dont
<pitti> crw-rw---- 1 root fuse 10, 229 2008-02-27 10:27 /dev/fuse
<pitti> it's that, right?
<cjwatson> pitti: worked OOTB by means of mounting as root, presumably?
<ogra_cmpc> i have a hard enough time with ldm getting it recognizing CK stuff
<ogra_cmpc> pitti, yup
<cjwatson> zdzichuBG: right, I think that will make sense for the future but not for hardy
<ogra_cmpc> and fusermount should be setgid fuse
<pitti> cjwatson: ah, that might be; I didn't try an NTFS partition on an USB drive
<pitti> ogra_cmpc: CK> only a suggestion; with hal's automatic ACLs it can be made available to the currently active local terminal, and such
<seb128> ogra_cmpc: it is setgid already no?
<ogra_cmpc> pitti, right, i'm all for it, just not now, as that would require me to rewrite a lot of ltspfs
<ogra_cmpc> seb128, yes
<pitti> ogra_cmpc: right, too late for hardy
<seb128> ogra_cmpc: I didn't understand your "<ogra_cmpc> and fusermount should be setgid fuse" then
<ogra_cmpc> seb128, because pitti pointed out the device perms
<pitti> mvo: hm, I just set up a dapper chroot and upgraded to the hardy dhcp3-client (bug #174128); I can't reproduce the conffile question
<ubotu> Launchpad bug 174128 in dhcp3 "asks debconf question on dapper->hardy upgrade" [Undecided,In progress] https://launchpad.net/bugs/174128
<pitti> mvo: did you still get that in recent updates?
<mvo> pitti: interessting, I need to check that, I'm not at home currently, so its a bit more difficult for me to do it
<mvo> pitti: friday maybe?
<pitti> mvo: yeah, no hurry
<pitti> mvo: I added all infos to the bug report
<mvo> pitti: great, thanks
<pitti> carlos: argh argh bug 191327
<ubotu> Launchpad bug 191327 in language-pack-kde-en "7.10: en_CA causes KDE apps to fail to start" [Critical,In progress] https://launchpad.net/bugs/191327
<pitti> carlos: do you have some minutes to look at this with me? this requires immediate action
<carlos> sure
 * carlos loads the bug report...
<pitti> carlos: darn, noone noticed that while we tested the -proposed packages
<carlos> pitti: I guess it's only a problem with en_CA.po file for kdelibs...
 * carlos looks for it
<pitti> carlos: right, looks like
<pitti> carlos: maybe en_US, too, see https://bugs.edge.launchpad.net/ubuntu/+source/language-pack-kde-en/+bug/195647/comments/2
<ubotu> Launchpad bug 195647 in language-pack-kde-en "language-pack-kde-en packages break KDE for canadian english users (dup-of: 191327)" [Undecided,Confirmed]
<ubotu> Launchpad bug 191327 in language-pack-kde-en "7.10: en_CA causes KDE apps to fail to start" [Critical,In progress]
<carlos> pitti: well, they say that changing locale to en_US fixes the problem...
<pitti> carlos: I asked in the bug whether anyone was using something else than en_CA
<pitti> carlos: right
<carlos> anyway, I'm waiting for the .po files download to check its content and see what's wrong there
<pitti> carlos: we have it on rookery
<pitti> /srv/language-packs.ubuntu.com/gutsy-proposed/sources-base/language-pack-kde-en-base/data/en_CA/LC_MESSAGES/kdelibs.po
<carlos> I'm using directly what we exported in Launchpad
<pitti> +"Plural-Forms: nplurals=2; plural=n != 1;\n"
<pitti> I guess that's the significant bit of the diff
<carlos> not really
<carlos> KDE doesn't use that
<persia> pwnguin: Sorry for the long delay: the logical names for all the controls are defined in ./include/linux/input.h in the kernel source.  Try for the best match there, and you'll likely hit close to the defaults for most games.
<carlos> well KDE < 4.0
<pitti> oh, wait
<pitti>  "to do mail thd@kde.org and coolo@kde.org, they will tell you. Better leave "
<pitti>  "that out if unsure, the programs will crash!!\n"
<pitti>  "Definition of PluralForm - to be set by the translator of kdelibs.po"
<pitti> -msgstr ""
<pitti> +msgstr "Definition of PluralForm - to be set by the translator of kdelibs.po"
<pitti> carlos: I bet that's it
<pitti> carlos: apparently someone put in a lot of identical msgstrs
<pitti> (i. e. msgid == msgstr)
<carlos> that's done by clueless people...
<carlos> and that was my bet
<pitti> and the comment says "don't translate this in any way"
<carlos> is just a matter of patch the file
<pitti> right
<pitti> does anyone here have a gutsy KDE installation at hand?
 * pitti greps the other langpacks for that
<carlos> pitti: I was doing the same ;-)
<pitti> carlos: current langpack-o-matic filters these out, so it would have helped in this case
<pitti> but not if someone would actually have put in a different string
<pitti> ok, it's the only one
<carlos> yeah, if it's not well translated, there is no way to detect it
<carlos> pitti: btw, the right value is msgstr "TwoForms"
<carlos> pitti: at least to match en_GB
<carlos> pitti: I'm going to fix it in Launchpad
<pitti> carlos: hm, but it was empty before
<carlos> so next update has it fixed
<pitti> carlos: thanks
<pitti> carlos: I'm going to do a manual upload for this
<carlos> pitti: which means to use the default
<carlos> pitti: so is up to you
<pitti> carlos: an empty string (as before) shuold work, too, I guess
<carlos> pitti: sure, just wanting to prevent that next automatic export breaks it again
<pitti> right
<carlos> pitti: yeah, anyone should be good enough
<\sh> seb128: how is someone supposed to remove "Bookmarks" from the Places menu, e.g. when adding bookmarks for remote servers?
<seb128> \sh: bookmark or mount?
<seb128> \sh: bookmarks can be edit from nautilus or the gtk fileselector
<seb128> \sh: mounts are just for the session and you can right click and unmount on the desktop or in computer
<\sh> seb128: I added an ssh server via Places/Connect To Server and add a bookmark which is displayed now under the Places/{Documents,Videos,etc} ...
<\sh> seb128: ok then there is the error...it's not mounted, but displayed as bookmark
<seb128> which seems correct
<seb128> it's mount when you access the share
<\sh> seb128: hmmm
<pitti> carlos: ok, uploaded
<\sh> seb128: ok my fault...I added /bin/false to /etc/shells and thought sftp can use this setting for having a non shell user, but someone who needs sftp...
<carlos> pitti: I just uploaded a fixed .po file into Launchpad
<pitti> carlos: ah, this affects hardy as well
<carlos> pitti: what about dapper, edgy and feisty?
<pitti> carlos: I'll check in a minute
<pitti> carlos: I'll request a full export for hardy, ok? I think it's time to refresh the langpacks
<carlos> sure, but let me fix that problem first
<carlos> hmm, well, is ok, given that it will not be generated until next Saturday
<carlos> and yes, -updates are already near 300MB...
<pitti> carlos: dapper to feisty are unaffected
<carlos> ok
<crimsun_> superm1: alsa-utils verified & uploaded.  Thanks!
<Hobbsee> bad intel driver.  stay off the crack.
<Hobbsee> it drawing artifacts on my screen of the brightness applet is kinda annoying...
<\sh> Hobbsee: on kdeÃ
<Hobbsee> \sh: no, gnome
<\sh> Hobbsee: hmmm...good to know that the brightness applet doesnt work for me...and the intel driver doesnt draw artefacts at my place
<geser> asac: Hi, what's the correct replacement for MOZILLA_CONFIG=/usr/bin/firefox-config? (I'm trying to rebuild vlc)
<jdong> Hobbsee: bip looks good, I'll approve it
<Hobbsee> jdong: goody
<asac> geser: look at the totem example on https://wiki.ubuntu.com/XulrunnerGecko ... most likely vlc changes will be much simpler.
<geser> asac: how do I know if vlc needs xpcom?
<asac> geser: look in configure
<geser> asac: thanks. need_xpcom_libs=false
<geser> :)
<jdong> lamont: could you coordinate with archive admins to frontport git-core from dapper-backports to {edgy, feisty}-backports?
<jdong> having dapper's version be newer than edgy/feisty is not ideal
<asac> geser: np ... don't hesitate if you have more questions ;)
<jdong> lamont: at the same time, I wouldn't mind at all if you wanted to backport the newest hardy git-core to everything too ;-)
<lamont> jdong: heh
<lamont> I don't actually ever use backports....
<lamont> other than uploading things for ScottK and such from time to time
<lamont> did I upload git-core to dapper-backports?
<jdong> lamont: well, you did last-touch the dapper-backports release and that should frontport correctly to subsequent releases
<geser> asac: if I understood the wiki page correctly I need always add xulrunner-1.9 to depends?
<jdong> /home/jdong/irclogs/FreeNode/#ubuntu-devel.2007-11-28.log.txt:17:31 < lamont> jdong: if I upload current git-core to dapper-gutsy backports, will you let it in?  1.4 has an absolutely sucky interface.  And, yes, 1.5 is a UI change of some significance.  OTOH, I haven't met anyone who prefers it...
<\sh> asac: lightning should show up in thunderbird after apt-get install lightning-extension right?
<jdong> ^^ :)
<lamont> jdong: guilty as charged.
<jdong> hehe
<lamont> slangasek: when you wake up, please either shove git-core forward from dapper-backports until it's older, or tell me what to do. kthx. :-)
<jdong> slangasek: I'll request git-core hardy->gutsy soon too (that only works for gutsy, older FTBFSes)
<asac> \sh: if you use the ubuntu thunderbird, yes.
<\sh> asac: hmm...it doesn't
<asac> \sh: is lightning in any of vi /usr/lib/thunderbird/extensions/*/install.rdf
<\sh> yeah
<\sh> just blame me...because I installed it on my homeserver and not on my local desktop..too many terminal error
<asac> \sh: backup your .mozilla dir (to repro) ... then stop tbird and remove .mozilla/thunderbird/*/extensions.*
<asac> see if that helps
<\sh> asac: na...installing it on the machine where it should run helps :)
<\sh> the problem sits always in front of the screen ;)
<asac> ah ;)
<cjwatson> mvo: is there a way to ask apt-get to *only* perform list cleanup, and not do the other network access implied by 'apt-get update'?
<cjwatson> mvo: this is for commenting out 'deb cdrom' entries at the end of the installation. It actually looks like I can just comment it out of sources.list and not bother running 'apt-get update'. Is that reliable?
<mvo> cjwatson: yes, if you comment it out apt will ignore it even if its still available in the lists/ directory
<cjwatson> ok, sounds like I can get rid of one time-consuming step then, cool
<pochu> soren: hi, any chance you can take a look at the debdiff at bug 192051? thanks!
<ubotu> Launchpad bug 192051 in gtk-vnc "Vinagre keyboard not working, mouse not always visible" [Medium,Confirmed] https://launchpad.net/bugs/192051
<soren> pochu: There's a new gtk-vnc release due out on Saturday. I'm a bit reluctant to spend a lot of time on gtk-vnc until then. Sorry.
<sistpoty|work> pitti: any reason you subscribed motu-release to bug 195964?
<ubotu> Launchpad bug 195964 in eclipse "[needs review and upload] Eclipse 3.2.2-5ubuntu1" [Wishlist,New] https://launchpad.net/bugs/195964
<ScottK> sistpoty|work: My guess would be that any upload of eclipse is at least as scary as an upstream feature release for most packages.
<sistpoty|work> ScottK: heh, might be true
<jdong> ScottK: touching eclipse is always scary :)
<jdong> IMO it wouldn't hurt to separate the eclipse platform from the eclipse IDE...
 * ScottK knows.  Has uploaded it before.
<pitti> sistpoty|work: previously ubuntu-release was subscribed, but it's an universe package; but now, looking at the version number, there are probably no new features
<pitti> should have checked before, sorry
<sistpoty|work> pitti: np... just thought you might have a special reason ;)
<jdong> ScottK: do you think I'll have mobs and riots after me if I were to, for hardy+1, bundle a SWT source with azureus that upstream blesses?
<jdong> lol
<jdong> I bet yes
<soren> cjwatson: The "required" seed lists essential packages... I'm a bit unsure about whether it defines it or just documents it?
 * ScottK sees SWT, smells Java and passes out from apathy.
<jdong> lol
<sistpoty|work> ScottK: I've unsubsribed motu-release from eclipse bug :)
<cjwatson> soren: essential is a subset of required that isn't in fact listed in any seed but is in debian/control files
<cjwatson> soren: it's a bug if anything is essential but not in the required seed; but essential is changed so rarely that this is basically ok
<soren> cjwatson: Ah, ok. I somehow got the idea that launchpad used the info from the seeds to set the Essential: field.
<soren> cjwatson: Is that perhaps the case for build-essential?
<soren> Or am I making all of this up? :)
<Sawoc> I dont speeck english!
<Mithrandir> what's our reason for not having traceroute in ubuntu-standard?
<jdong> Mithrandir: I believe traceroute requires root to be effective while tracepath doesn't?
<jdong> though personally I found tracepath doesn't work as well as traceroute
 * Keybuk uses mts
<jdong> i.e. unknown route via tracepath while traceroute tends to get it right
<Keybuk> mtr even
<pitti> Mithrandir: we have mtr?
<soren> Mithrandir: We have tracepath instead, don't we?
<jdong> mtr's even cooler
<pitti> oh, tracepath; didn't know about that even
<Mithrandir> soren: https://bugs.launchpad.net/ubuntu/+source/iputils/+bug/57167 claims that tracepath doesn't work in some cases that traceroute does.
<ubotu> Launchpad bug 57167 in iputils "traceroute6 installed by default but not traceroute" [Undecided,Confirmed]
<Mithrandir> pitti: that's true.
<soren> Mithrandir: Ah, ok.
<cjwatson> soren: for build-essential, yes, it is
<soren> cjwatson: Ah, ok. Thanks!
<Mithrandir> pitti: some old unix geeks are complaining about not having traceroute, I guess it's more about finger macros than anything else.
<pitti> Mithrandir: I agree; took me a bit to get the s/traceroute/mtr/ into my brain, too
<Mithrandir> pitti: it feels a bit heavyweight to provide a wrapper in mtr, but we could think of something along those lines.
<pitti> Mithrandir: like an alternative?
<Mithrandir> yeah, for instance.
<Mithrandir> should be done in coordination with Debian if so
 * ScottK didn't know about tracepath.
<Keybuk> hmm
<Keybuk> how do you get pbuilder to accept its own result directory as a source of build-dependencies?
<sistpoty|work> Keybuk: I'm not sure that would work w.o. a local apt-repository, as iirc pbuilder uses apt to satisfy the build deps
<jpatrick> generating a "Packages" file there and adding deb file://.... to sources.list?
<jpatrick> that's what prevu does for these kind of things
<Keybuk> how do you add something to its sources.list?
<Mithrandir> configure it that way when you create it or use --login and --save-after-login.
 * Mithrandir points Keybuk to pbuilder(8)
<sistpoty|work> pbuilder login --safe-after-login; edit apt sources there
<Keybuk> Mithrandir: I've read through it -- it's quite non-useful
<Keybuk> it assumes you know how pbuilder works and are refreshing your memory
<Keybuk> (like most manpages)
<Keybuk> also its own docs appear to be wrong
<Keybuk> I can't get it to execute the necessary hook
<Keybuk> despite having copied and pasted it from the docs
<shreevathsa> hi
 * pitti enters "about:config" into firefox-3.0 and laughs
<\sh> pitti: lol
<ScottK> Seems about right for Mozilla Corp these days.
<pochu> soren: I didn't know that. That's fine. The patch is just one line anyway ;)
<soren> pochu: Oh, ok.
<slangasek> lamont: sorry, I don't understand what you're asking for with git-core
<pitti> hi slangasek
<pitti> slangasek: I dealt with the git-core b-deps, btw
<lamont> slangasek: promote git-core from dapper-backports to edgy,feisty,gutsy backports pls
<Keybuk> pitti: so it turns out that passwd is actually written properly and uses pam_unix to change the password ;)
<slangasek> pitti: saw that git-core went through for hardy, thanks
<slangasek> lamont: erm... so reverse-backporting a backport?
<lamont> slangasek: no.  promoting binaries
<lamont> and source
<lamont> as it sits, the binary in dapper-backports is newer than the version in edgy-*
<slangasek> so "promoting" is a pocket-copy?
<lamont> dunno
<lamont> that's why I lobbed it.
<lamont> sounds right though
<slangasek> lamont: ok, done
<cjwatson> git-core> I think it should be a re-backport so that it gets ~edgy etc. version numbers, really
<slangasek> the backportable version is apparently superseded in hardy now, so that would require a hand-backport
<slangasek> which they're welcome to do; I don't think it hurts to have the current working version around in the meantime
<cjwatson> mkay
<hellboy195> Is any LP build-admin around?
<demir> hi
<Riddell> maswan: ping, could you mirror to se?  I'm about to release kubuntu-kde4 alpha
<demir> tÃ¼rkÃ§e bilen var mÄ±
<nosrednaekim> ping pitti
<slangasek> demir: this is an English-speaking development channel, no
 * ogra_cmpc wonders why he still ends up with a parport driver loaded ... despite the fact that its in all possible blacklist files
<ogra_cmpc> and the classmate has no parallel port ...
<maswan> Riddell: as in our cdimage.u.c mirror?
<Riddell> maswan: looks like it's already there
<maswan> Riddell: Ok, then I don't have to act cron. :)
<robertj> I'm getting a black screen between Grub & X where usplash is supposed to be, any ideas on things to check so I can file a more helpful bug report?
<nosrednaekim> robertjÂ» there are serveral existing bug reports about that problem.
<robertj> I don't know if that makes me feel better or worse
<ArneGoetje> Riddell: hmm... seems antialiasing is already enabled in Kubuntu by default... can you check with kmag on your system if the letters have grey pixels in and around the glyphs?
<Riddell> ArneGoetje: in KDE 3 yes, not in KDE 4
<Riddell> ArneGoetje: there's something which makes a .fonts.conf file that seems to add antialiasing in KDE 3, I'm not sure what
<Riddell> but it strikes me that shouldn't be necessary
<ArneGoetje> Riddell: ... how to test?
<Riddell> ArneGoetje: install a qt4 app, speedcrunch for example, and run that
<ArneGoetje> Riddell: on the alpha5 live cd I can't see any .fonts.conf
<Riddell> ArneGoetje: try running the installer
<ArneGoetje> Riddell: ok... will take some time to install the system...
<Riddell> ArneGoetje: no, just that the installer is qt4 only
<robertj> bug #68647 seems to be it
<ubotu> Launchpad bug 68647 in usplash "[usplash] black screen during usplash. Ubuntu boots fine" [Medium,Confirmed] https://launchpad.net/bugs/68647
<Riddell> ArneGoetje: you don't need to install it
<sich> hi
<ArneGoetje> Riddell: ok, I see... confirmed. the fontconfig settings are needed to enable antialiasing. Will upload a new package.
<\sh> slangasek: are we able to say how many users Ubuntu Hardy has? or just a number in downloads of hardy isos?
<slangasek> it's definitely not possible to count users of hardy; ISO downloads we could count, but that doesn't tell a whole lot either
<\sh> slangasek: I know about the truth about those statistics, but marketing people don't want the truth, they need numbers ,-)
<\sh> slangasek: but I think I can give those guys a different statement :)
<slangasek> if you're trying to make things look good for marketing people, surely you would want to grab statistics for a released version of Ubuntu?
<slangasek> (marketing is Not My Department though, so I don't know what statistics are available there anyway)
<\sh> slangasek: nope...Zend is asking me on some numbers, just because we ship their Framework for Hardy:)
<\sh> s/for/with/
<\sh> slangasek: I'll formulate something nicely without numbers (like: since 2005 Ubuntu is the leading Linux Distribution on Distrowatch)
<ogra_cmpc> \sh put in a nice google chart as well :)
<\sh> ogra_cmpc: do you have something like this? would be cool :)
<ogra_cmpc> http://www.google.com/trends?q=ubuntu%2Cgod
<ogra_cmpc> \sh, or a bit more serious http://www.google.com/trends?q=ubuntu%2Credhat%7Cfedora%2Csuse%7Cnovell&ctab=0&geo=all&date=all&sort=0
<\sh> ogra_cmpc: this is a good one, I replaced god with a different word with 3 chars...and ubuntu lost ;)
<ogra_cmpc> heh
<ogra_cmpc> chris used to use ubuntu vs britney spears for some time in his talks :)
<\sh> ogra_cmpc: and one of the truths is, that google is using an Ubuntu derivative as inhouse OS?
<ogra_cmpc> no comment
<ogra_cmpc> but its a well spread rumor
<calc> how is smb done in kde, via kioslave?
<calc> or something else?
<slangasek> ogra_cmpc: rumors like http://en.wikipedia.org/wiki/Goobuntu ?
<ogra_cmpc> yeah :)
<slangasek> calc: kdebase-kio-plugins Depends libsmbclient
<ScottK> \sh: This one might be interesting: http://www.google.com/trends?q=ubuntu%2Cwindows+vista&ctab=0&geo=all&date=all&sort=0
<\sh> ScottK: added and send :)
<\sh> thx guys for the help :)
<\sh> ScottK: claws-mail will be finished tomorrow...now it's time to relax and to cook some food for wife
<ScottK> \sh: Great.  I wanted to make sure you were aware of it.
<\sh> ScottK: hmm...I didn't find it, but is there an RSS feed of debian-changes somehow? I don't want to subscribe another useless ML but an RSS feed would be great
<ScottK> \sh: Dunno.  You did find the new claws-mail in Debian though, right? http://packages.qa.debian.org/c/claws-mail.html
<\sh> ScottK: yepp...
<ScottK> OK
<ScottK> \sh: http://www.jordomedia.com/RSS/l_op=viewrss/lid=88022.html
<\sh> vorbidden
<\sh> aeh
<\sh> forbidden
<\sh> well...everything is broken there ;)
<ScottK> \sh: http://www.mail-archive.com/debian-changes%40lists.debian.org/maillist.rdf seems to work for me
<\sh> ScottK: thx :)
<somerville32> http://www.google.com/trends?q=ubuntu%2Cvista&ctab=0&geo=all&date=all&sort=0
<\sh> and off for today
<ArneGoetje> Riddell: new fontconfig package is on rookery: ~arne/fontconfig/
<TheMuso> doko: Onboard is in bzr, but I'm waiting for a python-virtkey update ack before I can update onboard. Give me a sec and I'll fetch the bzr branch URL for you.
<Riddell> calc: yes, a kioslave with libsmbclient
<Riddell> ArneGoetje: ooh, thanks, I'll try it
<TheMuso> doko: http://bazaar.launchpad.net/~onboard/onboard/main/ is the onboard trunk.
<bdmurray> bug 196223 is receiving quite a few duplicates
<ubotu> Launchpad bug 196223 in libxklavier "package libxklavier12 None [modified: /var/lib/dpkg/info/libxklavier12.list] failed to install/upgrade: trying to overwrite `/usr/share/libxklavier/xfree86.xml', which is also in package libxklavier11" [High,Confirmed] https://launchpad.net/bugs/196223
<seb128> bdmurray: thanks, will fix it now
<bdmurray> seb128: thanks - didn't know you were still around...
<shaya> has anyone tried running vmware-server-console on feisty lately?  It unable to dynamically link
<djb> hey guys
<Jeeves_> Hi there
<Jeeves_> Q: I just used do-release-upgrade -d to upgrade from dapper to hardy (for testing). When configuring Grub, I could not ask for a diff of menu.lst. Should I file a bug for Grub, of update-manager-core ?
<djb> i was wondering how can i get involved with developing, but I have no prior developing exprience
<ScottK2> djb: #ubuntu-motu is usually the best place to start.
<djb> what is that
<Jeeves_> djb: Another IRC-channel
<seb128> bdmurray: uploaded
<Jeeves_> Like the one you're on now
<Jeeves_> Type /j #ubuntu-motu
<djb> for development, ie more of a beginners
<aehgt1> MotU = Masters of the Universe
<ion_> I take it weâre not talking with *the* djb. :-)
<Jeeves_> ion_: Shhhhhhhh. He's undercover!
<_MMA_> djb: Its the channel for the maintainers of the Universe repo. "Masters of the Universe" Best place to start getting technically involved.
<djb> ok will do, thanks for the info and help
<aehgt1> there's also an upcoming ubuntu-server mentoring program https://wiki.ubuntu.com/ServerTeam/Mentoring
<_MMA_> djb: You might also want to register you nick with Freenode.
<djb> yah def, thanx for the heads up
<mathiaz> djb: have you looked at https://wiki.ubuntu.com/ServerTeam/GettingInvolved ?
<djb> no i have not
<infinity> djb: I realise that "djb" are probably your initials, but you might want to pick another nick if you're going to swing in free/open software circles. :)
 * slangasek grins
<infinity> djb: Unless you want people to randomly hate and/or worship you for being someone else. :)
<djb> good point thankx
<infinity> http://cr.yp.to/ <-- The more well-known, revered, and reviled DJB.
<fmarier> Does anyone know whether Perl 5.10 will make it to hardy ?  or will it stay at 5.8.x ?
<Riddell> ArneGoetje: yes, they sort it
<evand> anyone know when the next Community Council meeting is?  It doesn't seem to be listed on the fridge or on the CC wiki page.
#ubuntu-devel 2008-02-28
<emgent> hello people
<somerville32> hi
<emgent> somerville32, heya
<somerville32> :)
<emgent> someone can open task for Gutsy, Feisty, edgy, Dapper in Bug #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, only >=MOTU can open task :P
<ArneGoetje> I need a core-dev to sponsor my fontconfig update. It's available on rookery in ~arne/fontconfig/ . Thanks a lot!
<somerville32> ArneGoetje: file a bug and subscribe ubuntu-main-sponsors
<superm1> slangasek, how often is the cdimage cron job going to run on the mythbuntu disk?
<superm1> i haven't seen it show up as of yet
<ArneGoetje> somerville32: done, thanks.
<TheMuso> superm1: 6:19 AM London time it seems.
<CarlFK> Bug #196359
<ubotu> Launchpad bug 196359 in onboard "Depends: python-virtkey (>= 0.50) but 0.42 is to be installed" [Undecided,New] https://launchpad.net/bugs/196359
<CarlFK> that is causing hardy alt install to fail.
<ScottK2> IIRC getting virtkey updated just got approved.
<CarlFK> k - I'll watch for it and close the bug
<CarlFK> so should that have been filed against package python-virtkey?
<ScottK2> No.
<ScottK2> Updating virtkey is the fix for that problem.
<TheMuso> ScottK2: virtkey has been uploaded so all should be well very shortly.
<ScottK2> Great.
<TheMuso> And has built everywhere, so should be hitting the mirrors.
<dholbach> good morning
<geser> Hi dholbach
<dholbach> hi geser
<dholbach> up early today? :)
<geser> yes, I have to. I've an exam in one hour.
<dholbach> how does it look? well-prepared? :-)
 * dholbach crosses the fingers
<geser> thanks, I should be well-prepared.
 * geser leaves now for the exam, bbl
<dholbach> ROCK ON :)
<slangasek> superm1: right, it should run daily, no promises that it succeeds though... :) let me have a look at the logs
<slangasek> ! Could not open lamp-server from checkout of (any of):
<slangasek> !   http://bazaar.launchpad.net/~mythbuntu/ubuntu-seeds/mythbuntu.hardy
<slangasek> !   http://bazaar.launchpad.net/~mythbuntu/ubuntu-seeds/platform.hardy
<slangasek> !   http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/mythbuntu.hardy
<slangasek> !   http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.hardy
<slangasek> superm1: ^^
<pitti> Good morning
 * slangasek waves
<dholbach> hi pitti, hi slangasek
<slangasek> superm1: so, the mythbuntu branch references seeds in its STRUCTURE file that don't apply
 * pitti NEWs l-r-m and virtualbox modules
<superm1> slangasek, okay i'll remove that reference
<superm1> slangasek, for future usage is there somewhere I can browse these logs so i dont have to bug you if there are troubles with the seeds?
<pitti> Keybuk: hm, do we deliberately don't have antialiased fonts any more?
<Keybuk> pitti: not delierately, no
<seb128> hey pitti
 * pitti hugs seb128, bonjour
<seb128> pitti: dunno if you read about it yesterday but the no duplicate battery patch is creating issues
 * seb128 hugs pitti
<Keybuk> pitti: mine are still anti-aliased
<seb128> pitti: like backlight control not displaying the popup dialog correctly and lagging, the battery icon being displayed when plugged on ac, etc
<Keybuk> (having just started a new app to check)
<Keybuk> could you have a gnome-settings-daemon failure maybe?
<pitti> Keybuk: mine were as well, until I cleaned up my configuration this morning
 * pitti tries with a fresh profile
<pitti> Keybuk: can you try with a fresh profile? doesn't work for me with one
<Keybuk> sure
<Keybuk> but not right now
<pitti> seb128: ugh, all just because we ignore batteries in /proc now?
<seb128> pitti: yes
<pitti> seb128: I heard about some issues with displaying wrong charge, etc.
<seb128> pitti: does you d430 work correctly?
<pitti> so maybe the ones in /proc are right, and in /sys are wrong
<pitti> seb128: let me check; there are no obvious bugs, bug I don't change brightness often, etc.
 * pitti resumes his laptop
<seb128> pitti: well, you would have noticed if the battery icon was displayed while plugged ;-)
<pitti> seb128: I think I configured it that way
<pitti> I want the icon whenever there is a battery
<seb128> ok
<seb128> try changing the backlight there
<seb128> what it does on my laptop is to display the popup some seconds later and scrambled
<pitti> ok, booted, running on battery
<pitti> hm, now after resuming I don't have a g-p-m icon at all
<pitti> but it's running
<pitti> brightness changing works, but no popup window
<pitti> darn, this morning I still had an icon which worked
<pitti> seb128: that must be your bad influence :)
<seb128> lol
<seb128> I just noticed that yesterday in fact
<Keybuk> pitti: created a new user
<Keybuk> still has anti-aliasing
<pitti> Keybuk: weird; thanks for trying
<Keybuk> the hinting is reduced to Medium by default, but it's still aliased
<seb128> pitti: I confirmed that dropping the double battery patch fixes the issues
<pitti> ah, how I have by battery icon back
<ion_> How about we implement a convolution filter to freetype that blurs all rendered text with e.g. a 3Ã3 kernel? That would be even nicer default.
<mjg59> seb128: Are you restarting g-p-m after restarting hal? (or rebooting entirely)
<pitti> ion_: 3x3? that would make them entirely unreadable :
<seb128> mjg59: I rebooted several time a day and it's always broken
<pitti> seb128: confirming the scrambled brightness popup
<ion_> pitti: Yeah, isnât that the direction weâre going? :-)
<seb128> mjg59: I also tried to start gpm in verbose mode after the session
<seb128> mjg59: gpm is always screwed, the log shows it fails to get the backlight value, etc
<pitti> seb128: hm, if it's that broken, maybe we should reverse the patch to *only* consider batteries in /proc?
<pitti> mjg59: ^ WDYT?
<mjg59> pitti: I can't see any way that it could cause the backlight issues
<seb128> gpm is all screwed dunno why
<pitti> neither can I, seems like hal/g-p-m misinterpreting /sys or so
<pitti> but *shrug*
<seb128> the log has dbus timeout errors when getting to get the backlight
<mjg59> g-p-m never touches stuff directly - it just cares about what hal provides
<mjg59> seb128: Run hal in verbose mode as well?
<seb128> but that might be a side effect
<seb128> mjg59: how do I do that?
<seb128> brb, switching to laptop
<mjg59> hal --verbose=yes --daemon-no
<seb128> re
<mjg59> seb128: hald --verbose=yes --daemon=no
<seb128> bug #194719
<ubotu> Launchpad bug 194719 in gnome-power-manager "01_proc_sys_batteries.patch causes a regression making gnome-power-manager not detecting the battery properly" [Undecided,Confirmed] https://launchpad.net/bugs/194719
<seb128> [12012]: 11:34:51.697 [D] addon-dell-backlight.cpp:231: Received GetBrightness DBUS call
<seb128> process 12012: arguments to dbus_message_get_args() were incorrect, assertion "(error) == NULL || !dbus_error_is_set ((error))" failed in file dbus-message.c line 1667.
<seb128> This is normally a bug in some application using the D-Bus library.
<mjg59> seb128: That much makes sense, but I can't see how it could affect brightness
<seb128> the hal log has that when pressing the keys to change backlight
<mjg59> Especially if you're using addon-dell-backlight
<mjg59> Which we probably shouldn't be on any hardware supporting the acpi backlight interface, but still
<zdzichuBG> is sysfs battery interface pollable? on my thinkpad, sysfs battery level is updated maybe once per hour. this was really visible when g-p-m displayed two batteries (proc and sysfs one) -- proc battery would discharge normally, while sysfs would show 99% just to suddenly jump to 30% after some time
<seb128> mjg59: http://paste.ubuntu.com/5085/ that's the gnome-power-manager log
 * pitti wonders whether the kernel doesn't provide a good-enough /sys battery information yet, or whether hal needs to be updated to read it differently
<seb128> hal does that when gpm is started
<seb128> [12450]: 11:39:33.071 [D] addon-dell-backlight.cpp:231: Received GetBrightness DBUS call
<seb128> process 12450: arguments to dbus_message_get_args() were incorrect, assertion "(error) == NULL || !dbus_error_is_set ((error))" failed in file dbus-message.c line 1667.
<seb128> This is normally a bug in some application using the D-Bus library.
<seb128> [12450]: 11:39:41.090 [D] addon-dell-backlight.cpp:198: Received SetBrightness DBus call
<seb128> process 12450: arguments to dbus_message_get_args() were incorrect, assertion "(error) == NULL || !dbus_error_is_set ((error))" failed in file dbus-message.c line 1667.
<mjg59> seb128: As I said, I can't see any way this could have anything to do with the battery patch. addon-dell-backlight is a separate process.
<seb128> This is normally a bug in some application using the D-Bus library.
<zdzichuBG> pitti: first one can be checked by manually looking into /sys
<seb128> mjg59: might be a side effect
<zdzichuBG> pitti: I will check that in the evening, after work
<seb128> could be that the new battery doesn't have enough informations and gpm gets confused when some things are lacking?
<seb128> mjg59: gpm seems to be all broken in fact, the battery is display when the laptop is on ac for example
<Amaranth> heh, i was just about to say something about that
<Ng> since the double battery thing was fixed, gpm has been very broken wrt batteries ;)
<Fujitsu> s/very/completely uselessly/
<Ng> it tells me I have 62 hours of battery life left and doesn't show I'm on AC
<dholbach> Ng: lucky you! 62 hours of battery - not bad! :)
<Ng> dholbach: yeah! ;)
<seb128> mjg59: I don't get the hald assertions with the build done without the patch, it does that
<seb128> [12922]: 11:42:49.686 [D] addon-dell-backlight.cpp:231: Received GetBrightness DBUS call
<seb128> [12922]: 11:42:49.687 [D] addon-dell-backlight.cpp:82: Reading 5 from the AC backlight register
<Ng> I've found bugs 194719, 194201, 194052 and 194180 so far which may be related
<ubotu> Launchpad bug 194719 in gnome-power-manager "01_proc_sys_batteries.patch causes a regression making gnome-power-manager not detecting the battery properly" [Undecided,Confirmed] https://launchpad.net/bugs/194719
<ubotu> Launchpad bug 194201 in hal "Battery Monitor not working (neither the battery applet) on Hardy" [Undecided,Confirmed] https://launchpad.net/bugs/194201
<ubotu> Launchpad bug 194052 in gnome-power-manager "gpm does not create the correct profiling files" [Undecided,Confirmed] https://launchpad.net/bugs/194052
<ubotu> Launchpad bug 194180 in gnome-power-manager "After #177570 fix, GPM reports nonsensical values" [Undecided,Incomplete] https://launchpad.net/bugs/194180
<Amaranth> mine tells me i'm on AC power but my battery is discharging
<Ng> argh, damn you ubotu
<Amaranth> eep, bug flood
<StevenK> Hah
<Ng> sorry :/
<mjg59> seb128: You built both on the same system?
<seb128> mjg59: no, it's hardy version vs local build without the patch
<mjg59> seb128: Ok. I'd recommend building locally.
<seb128> I can try a local rebuild of the hardy version
<seb128> ok, trying
<pitti> Keybuk: my font preferences defaulted to 'best form', not subpixel smoothing
<Ng> while I'm here, can I get apport to catch network-admin segfaults? it doesn't seem to be atm (in hardy)
<pitti> hm, it uses policykit and thus declares itself as not dumpable
<pitti> that's normally a safety precaution which prevents your password from getting into core dumps and other processes ptrace()ing it to steal it
 * Fujitsu 's battery is always discharging and either full or 5%.
<Ng> pitti: I did wonder if the new "Unlock" button and its refusal to run with gksu was related. I'll file a text backtrace then. thanks :)
<pitti> Ng: I don't see how we can easily have both ATM
<pitti> current kernel does not allow us to disable ptrace() and still keep core dumping
<Ng> pitti: I'd prefer to have it err on the side of security :)
<pitti> and it would circumvent the ptrace protection, too
<seb128> mjg59: local build of the hardy version has the same issue,
<seb128> [6800]: 11:48:58.156 [D] addon-dell-backlight.cpp:231: Received GetBrightness DBUS call
<seb128> process 6800: arguments to dbus_message_get_args() were incorrect, assertion "(error) == NULL || !dbus_error_is_set ((error))" failed in file dbus-message.c line 1667.
<seb128> This is normally a bug in some application using the D-Bus library.
<seb128> pitti: do you plan to update dbus to 1.1.4?
<pitti> seb128: not really, unless we need it?
<seb128> pitti: well, those are bug fix versions I think
<seb128> pitti: the gvfs guys were asking about it
<pitti> seb128: I looked at it some days ago, and there were new features, so I didn't update
<slomo> pitti: you probably want to get 1.1.20 or backport the security patch from it (see CVE-2008-0595)
<ubotu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0595)
<seb128> some gvfs guys rather to be exact ;-)
<pitti> right, if we update at all, then to the latest version, but as I said, we need to test it properly for the new features
<pitti> seb128: what do they need from it?
 * pitti -> lunch, bbl
<seb128> pitti: not sure, will ask, but the new 1.1.20 has "This is the next generation supported STABLE release of D-Bus." in its description
<seb128> pitti: enjoy
<cjwatson> bug 173950 - what an excellent bug, I'd never thought of that problem
<ubotu> Launchpad bug 173950 in ubiquity "Keyboard layout choice in installer confusing" [Undecided,Confirmed] https://launchpad.net/bugs/173950
<Mez> Can anyone tell me how to find out which application a window belongs to?
<Mez> Windows-esque adware windows have just appeare on my desktop
<Mez> no window class
<ion_> mez: This isnât really a support channel, but run xprop and click the window.
<Mez> ion_, I know it's not, however, If it's adware, then I'm gonna help get rid of it
<pitti> re
<pitti> seb128: hmkay, I'll have a look at the changelog again
<\sh> doko: tomcat5.5 is not installable without a jdk...it suggests java-virtual-machine, but I have at least one installed...what do you think is the best way to fix this issue?
<doko> \sh: hmm, why does a suggests hinders you installing the package?
<\sh> doko: it should default to a free one, imho :)
<pitti> seb128: so at least 1.1.4 -> 1.1.20 is bugfix only
<pitti> so is 1.1.3 -> 1.1.4
<\sh> doko: e.g. icedtea-java7-jdk (if this is resonable and works with tomcat)
<doko> \sh: just remove the suggests
<pitti> lool: dbus 1.1.20-1 seems released in alioth svn, but not uploaded yet; do you know when this is planned to happen?
<Lure> pitti: dbus 1.1.20 is unstable release of 1.2 version, why do you want it?
<Lure> pitti: will it get in hardy?
<pitti> Lure: seb128 and slomo asked for it above
<pitti> Lure: 1.1.2 -> 1.1.3 was the really heavy release
<pitti> Lure: 1.1.3-> 1.1.4 and 1.1.4 -> 1.1.20 are just small bug fixes
<pitti> 1.1.20 primarily has the security bug fix)
<\sh> doko: the problem is, that "java-virtual-machine" is a wrong suggests...it needs a jdk and all packages providing java-virtual-machine are Runtime packages (JREs)
<lool> pitti: I tried getting some testers for the update-rc.d changes, but didn't so far; I don't know about the new upstream
<Lure> pitti: ok, seen now original msg about security fix
<pitti> lool: this was changed to forcefully remove previous symlinks on upgrade, right?
<lool> pitti: If you like, you're welcome to try it out -- I personally didn't try the new upstream part
<lool> pitti: Correct, to work with insserv and file-rc
<pitti> lool: while this is not generally good practice, I think it does help a lot in our case
<lool> As these are based on update-rc replacements and move the /etc/rc*.d/ symlinks around
<pitti> bug 25931 is open for way too long
<ubotu> Launchpad bug 25931 in dbus "Failed to initalize HAL." [High,New] https://launchpad.net/bugs/25931
<doko> \sh: so why does tomcat5.5 need a jdk?
<pitti> and it's primarily due to shuffled rc priorities
<\sh> doko: javac is needed
<pitti> so I'd love to merge this into hardy to fix it for all upgrades
<doko> \sh: why can't you fix it?
<lool> pitti: In general, the update-alternatives "symlink data is your configuration" approach doesn't scale   :-/
<pitti> lool: I'm currently reading the upstream changelog - tons of bug fixes and two or three new features
<\sh> doko: well, the fix is to remove the suggests and do something helping the user...actually, when I Recommend or Depend on a jdk, it needs to be a free one, and this means, disabling the security manager from tomcat (this works only with the sun jdk)
<lool> pitti: I see mbiebl tunned the update-rc.d snippet to hide output, so he probably tested it
<\sh> doko: all documented in README.Debian of tomcat5.5 ;)
<lool> It's hard to catch mbiebl on IRC these days, I'll drop him an email now
<pitti> lool: I'm happy to test it here, too
<lool> As you please
<doko> \sh: so then why do you ask? soren may be interested in tomcat
<pitti> lool: I'll prepare a merge anyway and test it locally; even if we don't get it into hardy for some reason we can still use it for intrepid
<\sh> doko: because you are my java pkg hero :)
<pitti> lool: since due to your excellent merging into Debian the remaining Ubuntu delta should be small
<lool> pitti: Let me know if you need me to work on merging back additional stuff into pkg-utopia, I'm happy to act as a proxy and lower our delta
<\sh> doko: I'll discuss it with the server guys
<pitti> lool: for proper merging I'd just like to have the Debian source package for 1.1.20-1
<lool> pitti: You mean an uploaded one?  I can hand you a svn-buildpackage --svn-exported one if you like
<pitti> lool: the latter would suffice, I think
<pitti> we still have a delta, so precise md5sum match of diff.gz doesn't matter
<pitti> I'd just like to use the same orig.tar.gz
<lool> pitti: We use tarballs from http://dbus.freedesktop.org/releases/dbus/ AFAIK
<pitti> ah, great
<lool> pitti: But the diff might still change since mbiebl didn't confirm he finished
<pitti> ah, I seee
<lool> He released, but then he might still change it again
<pitti> lool: ok, then I'll just use your export for an initial merge
<pitti> lool: and for the FF exception request
<lool> pitti: http://people.dooz.org/~lool/debian/dbus/1.1.20-1/sid/
<pitti> lool: our Ubuntu delta won't change with some further small fixes from mbiebl
<lool> Is an export
<pitti> lool: merci
<lool> pitti: Do I understand correctly that lang-o-matic works with the Packages file and regexps on gtk / qt / kde to sort translations into langpacks?
<pitti> lool: more or less, yes
<lool> pitti: Intuitively I thought it would look at seeds
<pitti> lool: it uses the dependencies as initial heuristics, which works for about 98% of packages
<pitti> lool: and it has an override list so that we can manually move misdetected packages into the right category
<lool> pitti: Is it possible to have multiple langpacks ship the same translations?
<pitti> lool: they would conflict to each other
<lool> pitti: One thing where it might fail is with a mobile langpack -- most things are gtk-ish already, and sometimes not easy to distinguish
<pitti> lool: if a translation is relevant for both gnome and kde (like libxine) it lands in the neural langpack
<pitti> neutral
<pitti> lool: i. e. language-pack-fr instead of language-pack-{gnome,kde}-fr
<lool> pitti: Ok; that's how I understood it
<pitti> lool: if those are only a few, we can override them manually, but IMHO it would be better to have a heuristics first
<lool> (what's called the default or standard langpack on the translationprocess wiki)
<pitti> like, a dependency to libhildon or something
<lool> TranslationLifecycle rather
<pitti> right
<pitti> I don't have a really good name for that 'default' category
<pitti> 'main' is misleading (component) and 'base' too (due to the -base/update pkg split)
<lool> I would have called it base, but then this conflicts with the base/update langpacks  :-/
<lool> Yep
<pitti> snap :)
<pitti> 'common' maybe
<lool> pitti: Concerning actually building the langpacks, we might be basing on a separate project than "Ubuntu" for UME as we might have some post string/ui freezes translations
<lool> And we also have to convert the upstream pot (or create them) and them convert them back
<pitti> lool: so, building entirely separate packages, not basing on the 'common' ones above?
<lool> Anyway, we would have to push pots into another LP project, and retrieve another tarball
<pitti> that would certainly work
<pitti> then you can also include some GTK translations and add a Conflicts:
<lool> I'd guess we would still want the mobile langpacks built frmo hardy and then continue building new ones and pushing them to our ppa or so
<lool> So, first we would have to add a mobile langpacks (with proper conflicts), then I'd like to continue pushing new langpacks to our ppa
<lool> Is it possible to build the mobile langpacks against multiple LP translation tarballs?
<lool> (Typically the Ubuntu main translations and the "mobile-translations" project translations tarball)
<pitti> lool: as long as the later ones only update the previous ones, that's possible, yes
<lool> I guess this is all manual, and results in a giant .dsc which I push to our ppa and builds the binary arch: all packages?
<pitti> no, there's one source per binary
<pitti> since we only update a langpack when its translations actually changed
<lool> So I would even be able to push a mobile langpack alone; I might need the Ubuntu + mobile translations tarballs to succeed building the .dscs though
<pitti> lool: langpack-o-matic previously had a script 'merge-tarballs' which lets you combine two exported tarballs and then build packs from the merge
<lool> Excellent
<pitti> lool: it's not there in bzr head, but it's trivial to revive from the bzr history
<pitti> I just removed it since we don't need it any more these days, but if you need it, no problem
<mjg59> seb128: Right, you get to figure out what broke between the hardy build and now...
<lool> pitti: Found it in history, thanks
<lool> pitti: What would you be your guesstimate amount of work (either for you or for me) to add a mobile langpack and to actually produce new langpack packages?
<pitti> lool: depends; do you want to build completely separate packages, or build on top of the Ubuntu 'common' and 'gnome' ones?
<lool> pitti: One high priority goal is to save space
<lool> So a completely separate one
<pitti> ok, right
 * Hobbsee curses evil x bugs
<lool> (The seed data would really be good here)
<pitti> then we'd need a langpack-o-matic branch for mobile with some updated skeleton source packages
<pitti> with updated descriptions and Conflicts, etc.
<pitti> we can drop the category matching there, since there will be just one
<pitti> lool: so, getting this langpack-o-matic branch right would take maybe one or two hours
<pitti> lool: the more interesting question is how to get a matching LP translation export
<lool> pitti: We have to remap translations from english <-> localized to msgid <-> localized
<pitti> lool: i. e. if LP translations gives us exactly one tarball which contains mobile+ubuntu we need more code in langpack-o-matic
<pitti> lool: why?
<lool> pitti: Does that happen starting from the LP tarball and before calling lang-o-matic?
<pitti> lool: that needs to happen for the LP translations web ui
<pitti> but not necessarily for langpacks
<pitti> as long as you make sure that on the mobile device at least one locale is always defined
<lool> But the code uses msgids
<pitti> I know what the code does
<lool> How do you find the msgid <-> string mapping on the device if you don't fix the LP exports before running l-o-m?!
<pitti> lool: let's have a phone call, shall we?
<lool> pitti: Sure :)
<lool> pitti: It's going to be on my mobile == expensive though
<lool> pitti: Or I can call you, sorry
<lool> pitti: I'm really stupid when I'm sick
<lool> pitti: Can I call your landline?
<pitti> lool: see /msg
 * lool is in /query overflow
<lool> Ah, another network
<slomo> pitti, Lure: 1.1.20 is a stable dbus release, only reason why it isn't 1.2 is that the licensing wasn't fixed yes (apart from that we have an unstable one anyway)
<Lure> slomo: ok, I was confused with announcement mail then
<slomo> Lure: it's explained at the bottom of that mail
<seb128> re
<seb128> Lure: the notes have "This is the next generation supported STABLE release of D-Bus.", why do you say it's an unstable version?
<seb128> mjg59: well current hardy is broken, I'll try to write a small test case, is there an easy way to send a GetBacklight over dbus using a command line tool?
<seb128> pitti: I think having the current stable dbus in hardy would be nice but no strong reason why we can't do with the version we have now so it's your call
<mjg59> seb128: Yeah, dbus-send
<Riddell> mvo: did you get my e-mail with the question from ossi?
<mvo> Riddell: let me check, I'm traveling currently
<StevenK> IRC while travelling. Way cool
<mvo> Riddell: yes, have it
<mvo> StevenK: not literally traveling, more "away from my regular environment" :)
<Riddell> mvo: answer when you can, I forgot you were travelling
<mvo> Riddell: if I haven't by monday, kick me please
<carlos> pitti: shouldn't jockey be in multiverse?
<carlos> pitti: btw, hi.
<carlos> pitti: as far as I know, is the replacement for restricted-manager and it was moved to restricted, not sure why it's reverted now...
<carlos> pitti: btw, when I said multiverse I mean restricted
<seb128> carlos: why should it be there?
<seb128> carlos: that's a managing drivers thing, not restricted to non free ones now I think
<carlos> seb128: isn't the argument for restricted-manager move to restricted valid anymore?
<seb128> carlos: why was it moved there?
<carlos> seb128: because it depended on drivers that were not free
<carlos> Jockey provides a user interface for configuring third-party drivers,
<carlos>  such as the Nvidia and ATI fglrx X.org and various Wireless LAN
<carlos>  kernel modules.
<carlos> seb128: which is also true for jockey
<carlos> at least from the description
<carlos> seb128: I wonder it because I had to do a modification in Launchpad to allow restricted manager translations in the restricted pocket, but seems like this is not true anymore, in which case I want to revert the launchpad change too, so I just want to be sure that is not just a mistake in that new package
<seb128> carlos: better to wait for pitti to respond, he had network issue and we are in a meeting right now though
<carlos> ok
<carlos> seb128: thanks for your input
<nosrednaekim> henoÂ» hello, where are the update from dapper to hardy directions?
<heno> nosrednaekim: not sure we have those yet
<heno> mvo: ^?
<mvo> nosrednaekim: yes, give me a sec
<nosrednaekim> thanks
<pitti> seb128: look, dbus 1.1.20: https://edge.launchpad.net/~pitti/+archive
<seb128> pitti: will try that, thanks
<mvo> nosrednaekim: https://help.ubuntu.com/community/HardyUpgrades#head-e7f287c730b93116f89de7ea7e05efbe95fa6dd1
<mvo> nosrednaekim: let me know how it works for you, if a error happens, please send me the logs
<seb128> pochu: hey, will you do the tracker update and uvf request?
<nosredna_ekim> mvoÂ» uhhh sorry little crash there.
<pitti> seb128: packages are already being built; dput to start of build took like 10 seconds :) (yay ppa)
<pitti> hi carlos
<mvo> nosredna_ekim: please /msg me details or put the error message into paste.ubuntu.com
<carlos> pitti: hi
<pitti> carlos: jockey is in main again, yes
<nosredna_ekim> I'm actually testing upgrading kubuntu using the gtk tool. Anything I should be  fore-warned of?
<pitti> carlos: because it's designed for free third-party drivers, too, and it doesn't hard-depend on l-r-m
<pitti> carlos: however, that doesn't generally mean that we will never put packages in restricted which need i18n
<carlos> pitti: ok, could I disable restricted translations handling in Launchpad then?
<carlos> pitti: also, you should stop stripping translations out for those packages too
<carlos> pitti: well, I discussed with you that some days ago
<seb128_> Keybuk: where does bootchart puts the chart?
<carlos> and you asked me to not import those translations for other packages because translations would end in language packs that are in main...
<Keybuk> seb128: /var/log/bootchart
<carlos> pitti: so, what should I do?
<seb128_> ah, log
<pitti> carlos: I can disable stripping for restricted if we want, but why?
<pitti> carlos: what's gneerally wrong with including restricted in the normal translation workflow?
<pitti> ah, because of the license
<pitti> I see, valid point
<seb128_> Keybuk: http://people.ubuntu.com/~seb128/hardy-20080228-1.png
<pitti> carlos: true that, so please remove the hack
<carlos> pitti: ok, thanks for clarify it.
<mvo> nosredna_ekim: no, it should be fine
<Keybuk> seb128: how strange
<seb128_> iz udev bog!
<Keybuk> seb128_: I'd say kernel
<Keybuk> if it were udev bug, udev would be a more interesting colour
<pitti> lamont, infinity: if I were to upload a new pkgbinarymangler which modifies striptranslations.conf (not strip "restricted"), would that need manual changes in the buildd chroots? (since that conffile is modified there)
<nosredna_ekim> mvoÂ» ok, thanks, I'll report back one way or the other.
<mvo> thanks nosredna_ekim
<Keybuk> seb128: udev.log would help
<seb128_> Keybuk: there is no color on this long bar
<Keybuk> seb128: 30s is a suspiciously round number
<Keybuk> that implies alarm(30) in someting
<seb128_> it's just sitting there
<lamont> pitti: does apt-get dist-upgrade prompt?  cause that'd be a non-interactive handler, I believel;
<Keybuk> yeah exactly
<Keybuk> it's sitting there
<pitti> lamont: that's the dpkg conffile prompt, not maintainer scripts or apt
<lamont> pitti: right
<seb128_> Keybuk: do you know what informations could be useful there?
<pitti> lamont: want me to file an RT for it?
<lamont> pitti: that's an infinity thing not me..
<lamont> I suspect he would want one though
<lamont> and you might want to hold off on breaking all the buildds (if it does that) until he's around...
<pitti> lamont: hm, oops; if you think it'll actually break the builds, then maybe I should do a followup upload which reverts it?
<lamont> pitti: dunno what it'll do...
<lamont> the build starts by untarring the chroot tarball, doing a non-interactive (I think) dist-upgrade, and then runs sbuild
<pitti> anyway, rt sent
<seb128> pitti: the dbus binaries are not published yet in the ppa
<seb128> pitti: I'll try when they are
<pitti> http://ppa.launchpad.net/pitti/ubuntu/pool/main/d/dbus/
<pitti> seb128: right, that should happen soon; the debs are in the pool already
<pochu> seb128: yeah I'll do it
<pochu> seb128: it's already in Debian so it's a merge ;)
<pochu> but it needs an exception, yes
<pitti> pochu: yes, I merged them (the PPA version is a merge)
<tjaalton> pitti: jockey disables composite for fglrx, is that still needed? (AFAIK it has supported it for some time)
<seb128> pitti: pochu was speaking about new tracker
<pochu> yeah, what were you talking about? dbus? :)
<seb128> pochu: yes, new dbus there ;-)
<pitti> tjaalton: no idea; if someone verifies that it works, I'm happy to un-disable it
 * pitti does not have any ATi card
<pitti> seb128: bug 196568 updated FYI; PPA binaries are published
<ubotu> Launchpad bug 196568 in dbus "update to new 1.1.20 stable version" [Undecided,New] https://launchpad.net/bugs/196568
<asabil> hi all
<tjaalton> pitti: ok, I'll find out if it can be dropped
<seb128> pitti: new dbus installed on my laptop, rebooted, everything works fine as far as I can tell
<pitti> seb128: here, too
<seb128> pitti: I've added a comment on the bug saying so
<seb128_> mjg59, pitti: so, rebuilding the hal hardy version without 01_proc_sys_batteries.patch
<seb128_> $ dbus-send --system --print-reply --dest=org.freedesktop.Hal `hal-find-by-capability --capability laptop_panel`  org.freedesktop.Hal.Device.LaptopPanel.GetBrightness
<seb128_> method return sender=:1.114 -> dest=:1.118 reply_serial=2
<seb128_>    int32 7
<pitti> wow, that's so weird
<seb128_> same box, applying the patch, make, run new version
<seb128_> $ dbus-send --system --print-reply --dest=org.freedesktop.Hal `hal-find-by-capability --capability laptop_panel`  org.freedesktop.Hal.Device.LaptopPanel.GetBrightness
<seb128_> Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
<seb128_>  
<seb128_> so it doesn't look like a gpm bug, now no idea why that timeout after using the patch
<seb128_> the laptop_panel capability doesn't change between versions
<toresbe> seb128_: hey
<toresbe> you're not the appropriate seb, sorry
<seb128_> toresbe: hi, no problem ;-)
<seb128_> pitti: does the command timeout for you too?
<pitti> seb128_: booting my laptop
<seb128> pitti: sorry for the trouble, trying to look at the issue but my hal and dbus foo are limited
<pitti> seb128: yes, I get the same timeout
<pitti> seb128: do you see anything in the hal debug output?
<seb128_> pitti:
<seb128_> [12735]: 16:41:41.975 [D] addon-dell-backlight.cpp:231: Received GetBrightness DBUS call
<seb128_> process 12735: arguments to dbus_message_get_args() were incorrect, assertion "(error) == NULL || !dbus_error_is_set ((error))" failed in file dbus-message.c line 1667.
<seb128_> This is normally a bug in some application using the D-Bus library.
<pitti> ah, right, that
<seb128_> pitti: but I fail to see how to changes are leading to that
<seb128_> I'm getting log with and without the patch and diffing those now
<mi__> did we see libtab 1.5 in hardy ?
<lool> Is anyone going to Cebit?
<seb128_> mi__: dunno what libtab is but you can look on launchpad
<mi__> taglib 1.5
<seb128_> mi__: same reply, apt-cache show or launchpad
<seb128_> mi__: or try #ubuntu for user questions
<mi__> lol...amarok2 now use this package ( hardy have old1-1.48)
<mi__> never mind
<seb128_> mi__: was that a question?
<mi__> seb128_: no ..i say never mind
<seb128_> mi__: what would be constructive is to look at the version first because you don't need to ask on the devel chan to know that and to argue about the need to update to the new version if that's what you wanted
<seb128> Keybuk: ok, no hint about what could be useful as debug information about this slow boot issue?
<Keybuk> seb128: udev.log
<pitti> seb128: oh, yay! I just noticed that nautilus/gvfs stopped showing my internal partitions on the desktop
<seb128> pitti: right, only mounts under media and the user directory are listed now
<pitti> \o/
<seb128> ;-)
<seb128> Keybuk: /var/log/udev you mean?
<Keybuk> that's the one
<seb128> Keybuk: http://people.ubuntu.com/~seb128/udev
<somerville32> Could someone regenerate and upload xubuntu-meta for me?
<seb128> Keybuk: doesn't look like really useful to me, that's only events, no debug informations nor timing there
<cjwatson> Riddell: would http://paste.ubuntu.com/5104/ be OK by you? from ArneGoetje
<seb128> ArneGoetje: maybe you could describe what your changes are doing, the fontconfig upload changelog is not very informative ;-)
<Riddell> cjwatson: should be yes
<ArneGoetje> seb128: set antialias to true, hinting to true, hintstyle to hintmedium and rgba to none. That;s the setting we use in gnome. These changes will enable these settings system wide across all flavors.
<seb128> ArneGoetje: ok, good to know, thanks ;-)
<xhaker> talking about hinting. just tried hinting set to none, and the applet freaked out. the 4 checkboxes for font rendering are checked
<seb128> xhaker: they are not checked, they are in undefined state which means none is selected
<xhaker> hmm.. let me check  with human-clearlooks
<xhaker> ok.. here is the problem. with human-clearlooks they look ok.. undefined state is different.. both human-cl and human-murrine need to be fixed i think
<seb128> those are known bugs
<seb128> patches are welcome ;-)
<xhaker> ok, will try my luck
<seb128> cool ;-)
<pitti> jdstrand, keescook: are you still the primary maintainers for the package tests branch? could you take a look at/merge the test script for 'nut' in bug 182790?
<ubotu> Launchpad bug 182790 in nut "main inclusion report" [Low,Confirmed] https://launchpad.net/bugs/182790
<lool> pitti: BTW, this is where we are tracking the langpack points https://wiki.ubuntu.com/MobileAndEmbedded/MobileLangpack
<lool> pitti: It turns out the 30 MBs or so we might save with mobile langpacks might not be worth a new langpack, however we definitely have to make hildon modules langpack-able, so the l-o-m hooks part and the scripts to convert pot and all are still needed on our side
<lool> pitti: Feel free to work on germinate integration though :)
<emgent> mdke, ping
<mdke> emgent: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
 * slangasek wonders what should be done with a langpack that depends on a package in multiverse (language-support-writing-eu -> myspell-eu-es)
<cjwatson> slangasek: bug report? :-)
<cjwatson> langpacks belong in main, so ...
<slangasek> so "drop the dependency" is the ultimate answer, ok. :)
<cjwatson> well, at least it should be <= Recommends, probably Suggests
<cjwatson> not sure what language-selector will do with that though
<slangasek> perhaps language-support-writing-eu shouldn't exist at all yet, if the only dependency is in multivesre
<infinity> cjwatson: (re: livecd-rootfs/link_in_boot) Do you envision us ever rolling new dapper livecds?
<infinity> cjwatson: If so, I can just make sure the fix is in the dapper-live chroots now and close out that task.
<mario_limonciell> slangasek, I lost my connection last night before i was able to stick around to hear a response to my question regarding logs.  In  the failed alternate cd builds, is there somewhere i'll be able to look at logs to see what happened without having to bug you?
<infinity> cjwatson: (and then watch it mysteriously disappear when I forget to back it up when I reinstall the buildds, post-hardy, but that's my own issue to deal with..)
<slangasek> mario_limonciell: would that I knew the answer to that
<infinity> mario_limonciell: http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/
<slangasek> but apparently infinity knows the answer, so hooray :)
<infinity> mario_limonciell: Assuming that has enough info for you...
<mario_limonciell> infinity, great thanks :)
<mario_limonciell> yeah that's exactly what i need
<infinity> mario_limonciell: It's less than ideally-laid-out, but it should have full logs for just about everything.  Ish.
<slangasek> cjwatson: in your opinion, given the choice between not being able to have a language-support-writing-eu package and having it in multiverse (or restricted), which would be the better option?
<infinity> slangasek: Unless we've been relaxing this of late, restricted is only for hardware support (drivers/firmware), so it would be multiverse.
<slangasek> ok
<cjwatson> infinity: I think it's unlikely
<infinity> slangasek: And you'd have to test how launguage-selector would deal with it in multiverse, I guess.
<cjwatson> mm, there is the consequential problem that language-support-eu depends on language-support-writing-eu
<infinity> cjwatson: That would have to change, obviously...
<cjwatson> I'm not honestly sure which I prefer of those two options
<cjwatson> I think I'd like to hear from mvo what it would do to language-selector (or what could easily be changed there, if necessary)
<doko> $ ldd gcjwebplugin.so | grep 'not found' 2>&1|less
<doko>         libxul.so => not found
<doko>         libxpcom.so => not found
<doko> asac: expected?
<mjg59> doko: Aren't they in the firefox directory?
<mjg59> doko: /xulrunner
<doko> yep, I'll see if that's enough
 * slangasek whimpers at the lack of sover in those library names
<infinity> slangasek: They're private libraries, in theory...
<infinity> slangasek: (Not counting gcjlolplugin's above abuse...)
<zdzichuBG> while discharging, energy_now in sysfs decreases steadily, but battery.charge_level.current in HAL stays still
<slangasek> infinity: xulrunner isn't so private anymore, though?
<infinity> slangasek: Depends on who you ask, I suppose.
<infinity> slangasek: It's still in "SOVER 0" land, in my opinion.  (ie: not necessarily private, but the API and ABI might get broken every third Tuesday).
<infinity> slangasek: As horrible as it sounds, any shlibdeps on those libs should probably be exact versions. :/
<slangasek> mmh
<infinity> slangasek: (Which makes security updates rather lollerskatish)
<geser> infinity: Hi, do you know when you'll find some time to work on bug 184557?
<ubotu> Launchpad bug 184557 in jbossas4 "Circular build-depends, needs initial bootstrapping on the buildds" [Medium,Confirmed] https://launchpad.net/bugs/184557
<infinity> geser: Sometime before release. ;)
<infinity> geser: I could do it today, perhaps... I'm currently wrapping my brain around somthing that's making me grumpy anyway.
<geser> infinity: bug 31098 needs also your attention
<ubotu> Launchpad bug 31098 in cmucl "Build-Depends dependency for cmucl cannot be satisfied (circular build-depends; needs manual bootstrapping on the buildd)" [Medium,Confirmed] https://launchpad.net/bugs/31098
<infinity> geser: That one's tougher.
<infinity> geser: The comments claim that it can only be bootstrapped with itself (ie: with the same version), which means every upload (or every new upstream, at least) would need a manual bootstrap.
<infinity> geser: I don't think I'm prepared to do that.
<geser> ok
<infinity> geser: Responded to that bug, though.
<geser> infinity: jbossas4 is more needed as other packages are in depwait on it, so you can ignore cmucl till you are bored :)
<infinity> geser: The jboss4 one is a one-time bootstrap, I assume?
<geser> infinity: yes, at least I hope
<jdstrand> pitti: re net: no problem
<jdstrand> s/net/nut/
<jdstrand> keescook: ^^
<asac> doko: yes
<asac> doko: thats ok
<zyx386> hi
<zyx386> i report now anew bug or Suggestion :)
<zyx386> https://bugs.launchpad.net/ubuntu/+bug/196764
<ubotu> Launchpad bug 196764 in ubuntu "add ku-sorani-fonts paket in Ubuntu!" [Undecided,New]
<zyx386> I hope that one makes pure ;)
<mdke> emgent: hi?
<emgent> mdke, query please :)
<Fujitsu> Why are my scrollbars orange?
<jdong> Fujitsu: orange you glad they aren't brown?
<jdong> ok sorry, that was horrible
<Fujitsu> And my menu bars have decided to be striped. Hmm..
<seb128> that's called a new theme
<seb128> you can change in the appearance capplet
#ubuntu-devel 2008-02-29
<jdong> the new theme looks pretty cool
 * jdong backports it
<StevenK> Because running Hardy is pointless if you can just backport the lot?
<jdong> StevenK: not nearly enough is backported to draw that comparison :)
<StevenK> jdong: Heh.
<_MMA_> jdong: I wouldnt backport it yet as it still needs some work.
<jdong> _MMA_: only personally for now
<jdong> I just wanted it on my gutsy machine
<jdong> call it greed
<_MMA_> Sure.
 * StevenK is content to wait.
<zyx386> and what is about my bug report?
<zyx386> well be fix it?
<blueyed> Should a package remove obsolete config files when it get's upgraded? They seem to stay in /etc and get listed as "obsolete" in "dpkg -s".
<blueyed> oops.. I've meant to ask in #ubuntu-motu..
 * Hobbsee waves
<ionstorm> can some admin ban the spammers at http://brainstorm.ubuntu.com/search?ordering=new
<ionstorm> they are screwing up the site
<RAOF> Heya Hobbsee!
<Hobbsee> hey RAOF!
<ScottK2> Heya Hobbsee
 * Hobbsee deals with gio.
 * TheMuso waves to RAOF and Hobbsee.
<RAOF> With a hammer?
<RAOF> And a howdie to you too, TheMuso.
<ScottK2> Hmmm.  Spammers messing up a site where users come up with work they think we should do...  Bug or feature?
<RAOF> Heh.
<RAOF> I was thinking a bit about that.
<TheMuso> It should have been tied to Launchpad User IDs.
<TheMuso> IMO
<ScottK2> Oddly enough Ubuntu is the distro where I have to agree to play nice and Debian is the distro where I have to agree to care about the users.
<Hobbsee> hi TheMuso
<Fujitsu> TheMuso: I was advised that it will be soon.
<Hobbsee> RAOF: no, not really.  trouble is, i have conflicting dates on when my rego was *actually* cancelled.
<Hobbsee> so they want a fax, etc, etc, etc.  nyah nyah nyah.
<RAOF> Hobbsee: Aaaah.  gio, not gio :)
<Hobbsee> RAOF: which were you thinking of?
<RAOF> GIO, the new gnome IO subsystem.
 * Fujitsu initially thought of the GVFS-related GIO.
<Fujitsu> That one.
<RAOF> Since we are, after all, in #ubuntu-devel :)
<RAOF> Not #cars-are-expensive
<StevenK> Haha
<Hobbsee> RAOF: oh.
<Hobbsee> :P
<Hobbsee> no, this is #Hobbsee-hates-making-phone-calls-that-are-overdue
<Hobbsee> blink?
<RAOF> Netsplit?
<Hobbsee> oh
<Hobbsee> was about to say - i shouldnt' be timing out from there
<Hobbsee> hurrah.  done my 5 today.
 * mpt applauds
<Hobbsee> should have got the spangly new code to do with it, though
<Hobbsee> ScottK: nuked one of yours (can't reproduce)
<ScottK> Hmmm.  Looks for bugmail.
<Hobbsee> ScottK: get-build-deps on !bash
<ScottK> Ah
<ScottK> I think he fixed that one.
<ScottK> It's OK.  I filed 10 bugs on ubuntu-dev-tools in one day.  Even if one falls out, I'm still well over 5.
<Hobbsee> heh
<LaserJock> heh
<StevenK> I thought it was fix 5, not file 5
<Hobbsee> if you file 5, you have to fix 10.
<StevenK> Heh
<ScottK2> If people would stop uploading without thinking, I'd be fixing, not filing.
<Hobbsee> bah.  bzr curled up it's toes and died.
<StevenK> Oh?
<Hobbsee> bzr: ERROR: Cannot lock LockDir(lp--1217675668:///~5-a-day/5-a-day-data/main/.bzr/branchlock): Transport operation not possible: readonly transport
<Hobbsee> bzr failed with error code 768
<StevenK> Delete the checkout and re-checkout, I think
<RAOF> Hobbsee: That looks like you're trying to push to an http branch?
<ScottK2> My favorite ubuntu-dev-tools bug was that the AUTHORS file was executable.
<Hobbsee> RAOF: no idea. i'm just using whta's in haryd
<StevenK> ScottK2: What did it do when you executed it? :-P
<ScottK2> It wouldn't have done anything much, but I didn't execute it.
<ScottK2> It's just symptomatic of a lack of care.
<ScottK2> How does that happen?
<RAOF> I often chmod +x random files.  Surely you do too? :?
<ScottK2> I'm on a different tack now anyway.  I'm going to see how well I survive without ever logging into LP.
<RAOF> I should learn the mail-based LP interface, yeah.
<ScottK2> Well I'm seriously looking at Lenny right now.  I've pretty well had it up to my eyeballs with LP for a while.
<Hobbsee> oh, meh.  it doesn't create ~/.5-a-day-data, so dies
<Hobbsee> and then still dies
<Hobbsee> ScottK2: so be producive, and find ways of diong ubuntu without LP
<ScottK2> Hobbsee: I'm planning on it.  I've been looking into actually teaching bughelper to report Ubuntu bugs instead of just whining to a mailing list.
<LaserJock> that'd be handy
<ScottK2> I think all the relevant bits of code exist, it's just a matter of pulling them together.
<ScottK2> The other thing is that Lenny with KDE 3.5.9 may be a better desktop for my than the Ibex.
<ScottK2> I'm still waiting for a reassuring answer to my comment on kubuntu-devel ML about us being over a year away from a stable/reliable kde4pim.
 * ScottK2 goes back to filing klamav bugs with upstream.
<RAOF> Wow, over a year?  How does that happen?
<ScottK2> It's like this...
<ScottK2> KDE4.0 - No kdepim for kde4.
<ScottK2> KDE4.1 - Initial kdepim port to qt4
<Hobbsee> kubuntu will carry kde 3.5.9
<ScottK2> KDE4.2 - Initial integration with the new Akdondi data engine back end
<ScottK2> KDE4.3 - I figure this is the first shot at a stable/reliable one.
<ScottK2> Releases happen every 6 months.
<ScottK2> Hobbsee: True, but how much attention is it going to get?
<ScottK2> Unless the Debian KDE people pull a miracle out of their hats Lenny will release with 3.5.9 and KDE4 will stay in experimental.
<LaserJock> but don't we get whatever work Debian does?
<ScottK2> Probably.  Assuming someone does the merges.
<ScottK2> I'm not saying which way I'm going.  I've not decided.  It's just that I'm looking into it.
<slangasek> speaking of KDE, any kubuntu folks want to rebuild kdebase-workspace for libxklavier12?
<Hobbsee> ScottK2: how much is gnome going to get?
<ScottK2> What is from my perspective declining usability in our main tool set and developers that don't care is my main concern.
<Hobbsee> slangasek: i;ll do it
<ScottK2> Hobbsee: I've no idea.
<slangasek> Hobbsee: cheers; fyi, there's a dep and a build-dep that each need changed
<Hobbsee> come on, pull faster tahn 700 kbps.
<Hobbsee> er, kBps
<ScottK2> The straw that broke the camel's back today was finding out after a long disucssion about a bug that it was known before the last LP release and neither documented nor fixed.
<Hobbsee> that happesn for a lot of bugs.
<Hobbsee> just watch a few that get marked for critical cherry picking, after sitting there for 3 months.  i find that sadly amusing.
<ScottK2> You would think if being able to include attachments in new email bug reports was being announced as a major feature it would actually work (or at least have it's limitations documented)
<Hobbsee> not really.  i'm afraid i've seen a little too much of launchpad to expect such things.
<Hobbsee> especially after seeing ppa release without a delete function, for months.
<ScottK2> Everyone over there claims it's getting better, but I don't see it.
<Hobbsee> it is.  it's getting more code, more features, and more bugs.
<ScottK2> I'm also seeing more and more replies along the lines of "we know it's not ideal, but that's what sabdfl said he wanted.  nothing to do about it."
 * Hobbsee suspects a lot of companies operate around "it's because the boss said so"
<pwnguin> is a ubuntu qa password different than lp or the wiki?
<ScottK2> Yes.
<pwnguin> fun
<Hobbsee> that being said, with all their time, and all their features, and all their new people, i would have hoped for better QA - which, at least for some parts, hasn't happened.
<ScottK2> Hobbsee: But very few FOSS projects do.
<Hobbsee> ScottK2: and launchpad is not FOSS.
<ScottK2> Exactly.
<ScottK2> So I'm not going to play free QA for them any more.
<Hobbsee> i'm actually not sure how much their "free QA", as it were, is helping them, seeing as they appear to get important bugs filed, then either ignore, or not understand the importance to people in the real world (or class them as not important)
<Hobbsee> and yet do very little with them
<pwnguin> Hobbsee: actually, im not certain a delete feature is a good idea. technically the gpl requires you to provide the source code to people for some number of months after distribution, upon request
<ScottK2> Yes.  Even more encouragement to quit.
<Hobbsee> pwnguin: ah yes - now i'm waiting for that bug to hit critical status, but it doesn't mention that it's violating the gpl, and kiko has already said "oh please...", so i'm guessing it will take a few more months, and a few more people going "uh...."
<Hobbsee> pwnguin: feel free to comment about the violation on the bug.
<LaserJock> Hobbsee: I'm not sure that's a very fair assessment
<Hobbsee> pwnguin: but it's nice to actually have control over the binaries that are ther.e
<LaserJock> there's certainly a lot of improvements that need to be made
<LaserJock> but there are a lot of bugs getting fixed
<LaserJock> and we certainly don't do much better with our bugs
<Hobbsee> LaserJock: how do you disagree?  i'll freely admit, iv'e seen more improvements in some areas than others, and i suspect i'm seeing some of the worse ends of LP, as most outside people don't see them
<Hobbsee> yeah well.  i have various things to say about that too.
<ionstorm> https://bugs.edge.launchpad.net/ubuntu/+bug/196859 <-- please notify admin asap, site is under spam attack
<ubotu> Launchpad bug 196859 in ubuntu "Brainstorm is susceptible to spam" [Undecided,Invalid]
<LaserJock> LP has a lot of functionality and is quite usable, not perfect, but it gets the job done
<Hobbsee> ionstorm: they're not awake.
<ScottK2> LaserJock: But it's getting worse not better.
<LaserJock> ScottK2: I wouldn't say that
<Hobbsee> ionstorm: oh, that admin
<LaserJock> there are some regressions here and there for sure
<ionstorm> Hobbsee, we need to wake them
<LaserJock> no doubt
<ionstorm> view http://brainstorm.ubuntu.com/search?ordering=new
<ScottK2> Personally I think the web site U/I peaked just before the beta and it's been getting more complex and less usable since.
<Hobbsee> ionstorm: good luck in finding people who work for canonical at this time of day
<LaserJock> but they've also made progress
<ionstorm> they are massively spam attacking them
<Hobbsee> StevenK: can you call someone?
<ionstorm> well canonical needs to be on irc
<ScottK2> LaserJock: Sure.  It's some good and some bad.  IMO the balance is to the bad.
<Hobbsee> stgraber: ping?
<Hobbsee> ionstorm: someone needs to not sleep, yeah
<Hobbsee> hrm.  i wonder if i can delete thru here
<Hobbsee> no, i can only edit
<Hobbsee> how useful
<Hobbsee> yes!  it's even worse than LP, in that you can't clear a dupe!
<Hobbsee> ionstorm: you'll need someone on https://edge.launchpad.net/~ubuntu-qa-website-devel
 * mpt works for Canonical
<Fujitsu> mpt: But you live on a sane side of the world at the moment.
<Hobbsee> mpt: oh, i forgot to specify "who could do something about it"
<Fujitsu> So you're not someone that we're looking for, as they're logically going to be in the wrong timezone when you need them.
<mpt> My side of the world is *always* sane :-P
<Hobbsee> unless you'r eoffering calling
<mpt> Call someone about what?
<Hobbsee> Fujitsu: you mean everyone doesn't operate on UK time?
<Hobbsee> mpt: recent backscroll is your friend :)
<Fujitsu> Hobbsee: What? Impossible!
<Hobbsee> and it relaly helps if i actually increment the changelog
<Fujitsu> Oh.
<mpt> oh, hee hee
 * ScottK2 finds it help if I upload to Hardy instead of Gutsy (last night anyway).
<Hobbsee> hah
<Fujitsu> Oh that bastard.
<Hobbsee> yeah, that too.  i got that one right htough
<Fujitsu> Erm, sorry.
<Fujitsu> But, the spammer rejecting the bug.
<Fujitsu> WTF.
<Hobbsee> heh
<ScottK2> Bug was invalid against Ubuntu anyway.
<mpt> I can't access the bug report, I get an offline message
<Fujitsu> Hm, edge looks dead.
<Fujitsu> So do I.
<Fujitsu> Try !ege.
<Fujitsu> *!edge
<Fujitsu> It worked for me a couple of minutes ago :(
<Fujitsu> !edge must work, as it redirects me...
<LaserJock> ouch
<mpt> This is an example of why I don't think edge should be a separate hostname
<Fujitsu> Doesn't the code update run around now?
<Fujitsu> It's back now.
<Fujitsu> That must have been it.
<ScottK2> BTW, I do find mpt is an exception to my broad generalizations I was making a few minutes ago.
<mpt> Well, I confirmed the bug report, but there's not much more I can do at this time of day
<mpt> We have yet to learn the lesson of planning for spam before releasing something publicly
<Fujitsu> Mhm.
<mpt> Hopefully this will be an object lesson
<Fujitsu> Hopefully.
<LaserJock> it's too bad it didn't even make it like more than 1 day
<Fujitsu> Having some kind of coverage of multiple timezones would be good too.
<Fujitsu> Having admins sitting on one side of the world is ++ungood.
<ScottK2> Fujitsu: It's not that.  It's the combination of sitting on one side of the world AND letting them sleep that's the problem.
<Fujitsu> LaserJock: Slashdot and Digg do that to websites.
<Fujitsu> ScottK2: Good point. Canonical needs to sponsor caffeine IVs.
<Hobbsee> mpt: i live in hope.
<mpt> Hobbsee, I live in a settlement that is actually called Hope
<Hobbsee> mpt: it does actually have admins in most timezones, so it is getting better.
<Hobbsee> mpt: nevertheless, with a GUI for delete, and a gui for 'mark as spam', that's not overly helpful
<Fujitsu> Gaaaah.
 * Fujitsu stabs repeatedly.
<Fujitsu> He rejected it.
 * Fujitsu kills.
<Hobbsee> hah
<Hobbsee> now now Fujitsu.  you can't kill people, otherwise people inside and otuside of canonical will whinge about you being heavy handed.
<ScottK2> Apparently this is after "months  of planning and development" what was come up with (reading planet).
<mpt> ScottK, Launchpad has its problems, but if you say that the pre-1.0 UI was better than the post-1.0 UI, people may have difficulty taking your other issues seriously
<Fujitsu> Even Launchpad has beta test phases, whereas this came from nowhere!
<ScottK2> mpt: That's how I find it, but I'm old and I like text.
<ScottK2> The old U/I also worked via my smartphone.  New one doesn't.
 * Hobbsee shudders
<ScottK2> I also clicked on the wrong thing a lot less before.
<Hobbsee> ScottK2: you ran launchpad over your *smartphone*????
<ScottK2> I agree the newer one is prettier.
<ScottK2> Hobbsee: I have an all you can use data plan.
<Hobbsee> you really are a masochist.  how long did the pageloads take?
<ScottK2> Long time.
<Hobbsee> i'll bet
<Fujitsu> There aren't any LP admins on this side of the world either, are there?
<ScottK2> They take a lot longer now and I can't change stuff, so I quit doing it.
<Fujitsu> Yay for status wars.
<Hobbsee> Fujitsu: nope
<ScottK2> Fujitsu: You could try to get his account cancelled, but you'll have to warn him, take him in front of some council somewhere, warn him again, and then maybe.
<Fujitsu> ScottK2: And that requires an admin.
<Fujitsu> He's just done it for the third time.
<ScottK2> Fujitsu: By the time you get the other stuff done, the admin will be awake.
<Hobbsee> ScottK2: no you don't.
<Hobbsee> ScottK2: for actual spam, they'll nuke it.  sometimes they'll try an email first.
 * ScottK2 confesses to engaging in hyperbole and sarcasm.
<LaserJock> really??
<LaserJock> ;-)
<ScottK2> The part about thinkin LP is getting less and less usable was dead serious though.
<Fujitsu> We need a system to vote users out, damnit!
<LaserJock> "Survivor: Ubuntu Edition"
<Fujitsu> s/Ubuntu/Launchpad/
<mpt> ScottK, does your phone browser try to do Launchpad's multi-column CSS layout?
<ScottK2> mpt: Yes.
<ScottK2> I think
<ScottK2> Let me try it.
<mpt> non-Opera/iPhone browsers are often execrably bad at CSS
<ScottK2> It's a Palm Treo 600, so it's not precisely obscure.
<ScottK2> Wouldn't suprise me.
<mpt> but a phone that ignores CSS altogether should be much happier with post-1.0 Launchpad than with the <table>-ridden pre-1.0 Launchpad.
<ScottK2> Their included mail client qualifies as excerable.
<ScottK2> The thing that got me was the switch to the current approach for the status/importance/etc section.  The old one worked.
<Hobbsee> hurrah.  finally made all the phonecalls for the day.
<Fujitsu> ScottK2: This is what the mail interface is for.
<ScottK2> Fujitsu: This is true.  There is an alternative, but it's still a regression from my perspective.
<mpt> ScottK, if you can send me a screenshot, that might help a lot
<ScottK2> mpt: I'll see if I can figure out how to get a decent one.
<ScottK2> Actually it's gotten a lot worse than the last time I tried it.  On a package page I just get the 'table' of releases.  I don't even get the tabs to go to the bugs page.
<Fujitsu> ScottK2: Oh, people use the tabs?
<ScottK2> Fujitsu: I don't usually.  I usually type in the urls on my computers, but on the phone it's a bit harder.
<Fujitsu> Ah, true.
 * lamont uses the tabs
<lamont> much easier that remembering the magic hidden URLs for stuff
<ScottK2> Fujitsu: Alternative answer is: No.  That's why clicking on the package name in the status section of a bug now takes to you the package page instead of giving you the chance to change the affected package.
<lamont> so I don't even bother trying to remember even the simple ones
<ScottK2> And it can't be changed.
 * Hobbsee has aliases
 * ScottK2 doesn't remember them either.  The browser knows where I've been before.
<lamont> Hobbsee: I have an alias for getting to a source package (which still has /distros in it, iirc), and maybe an lpbug alias
<Hobbsee> lamont: pity the url's aren't always shown on the gui
<Hobbsee> yeah
<LaserJock> I just type the urls by hand mostly
 * ScottK2 needs to get to bed.  Good night all.
 * Fujitsu does the same as LaserJock.
<Fujitsu> Night ScottK2.
 * StevenK has an alias for source package, person and bug
<Hobbsee> hrm.  how do i get firefox-2 to work?
<Hobbsee> loading that, i appear to get firefox3, as usual
<LaserJock> is there a separate .desktop?
<Hobbsee> i was using the terminal
<Hobbsee> ie, sarah@saturn:~% /usr/bin/firefox-2                                       5:39PM
<pitti> Good morning
<StevenK> Morning pitti
<pitti> jdstrand: nut bzr> thanks
<Hobbsee> morning pitti
<warp10> Good morning
<pitti> hey Hobbsee!
<pitti> moin StevenK
<pitti> bon giorno warp10
<warp10> morgen pitti!
<LaserJock> hiya pitti
<superm1> slangasek, according to http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/mythbuntu/hardy/daily-20080229.log the ISO generated, but it looks like some error with the md5sum template that may be out of my control?
<superm1> oh nvm, just took a sec to show up on cdimages.ubuntu.com
<slangasek> ok :)
<thegodfather> superm1: ping?
<thegodfather> (nothing urgent)
<mdke> pitti: you remember we do that thing in ubuntu-docs where translations that are less than 40% don't get included? I'm just working on updating translations in the gutsy package; can I drop that a bit now that iso space is no longer a consideration?
<kagou> hi
<kagou> hello seb128
<seb128> hi kagou
<seb128> hey dholbach
<dholbach> good morning
<dholbach> hi seb128
<Hobbsee> morning seb128
<kagou> hey dholbach
<Hobbsee> dholbach: your shiny is borken :(
<seb128> hey Hobbsee
<dholbach> hi kagou, hi Hobbsee
<dholbach> shiny?
<Hobbsee> dholbach: http://pastebin.ca/923001
<mdke> morning dholbach
<dholbach> hi mdke
<dholbach> Hobbsee: seems we need to transition it from "all commit to one branch" to "everybody commits to their own branch"
<mdke> dholbach: i'm just doing some updates for the gutsy package of ubuntu-docs, with updated translations. Is it appropriate for me to remove the packaging guide from that, or do we just do that in hardy and going forward?
<pitti> mdke: it'll make it still quite ugly to read, and CDs are still full, as always
<dholbach> that'll make statistics a bit hairy, but it'll fix the issues
<Hobbsee> dholbach: what's the problem with all committing to one branch?
<dholbach> mdke: I'd just do it in hardy and keep the changes to gutsy as small as possible
<mdke> pitti: are CDs still being regenerated for gutsy?
<Hobbsee> also, it doesnt' seem to create the ~/.5-a-day-data
<mdke> dholbach: fine, thanks
<dholbach> Hobbsee: it should run       bzr checkout <branch>
<dholbach> at least it did for a lot of other people :)
<Hobbsee> dholbach: this is a stock install of it.  no changes.
<dholbach> can you move .5-a-day-data away and try to run       add-5-a-day 194631 190050 150577 140612 178903 196786       again?
<dholbach> and paste the output?
<Hobbsee> dholbach: http://rafb.net/p/6xkuJL96.html
<dholbach> readonly transport?
<dholbach> do you have the right SSH key in LP?
<Hobbsee> yes
 * Hobbsee only has one ssh key.
<dholbach> hrmhrmhrm
<RAOF> Have you run "bzr launchpad-login hobbsee"?
<Hobbsee> RAOF: nope
 * RAOF presumes that's your lp id.
<Hobbsee> dholbach: i get promped for a ssh p/w, and put that in...
<Hobbsee> RAOF: same problem after doing so
<RAOF> There goes my guess :)
<dholbach> Hobbsee: where's the 'hobbsee' file?
<dholbach> is it in ~/.5-a-day-data/?
<seb128> pitti: steve gave his ack to the dbus update ;-)
<pitti> seb128: oh? didn't see it by mail
<Hobbsee> sarah@saturn:~/.5-a-day-data% ls -la hobbsee                             7:32PM
<Hobbsee> -rw-r--r-- 1 sarah sarah 204 2008-02-29 19:28 hobbsee
<Hobbsee> dholbach: so, yes
<seb128> pitti: he added a comment on the bug some hours ago
<dholbach> Hobbsee: but the branch seems to be in ~/.5-a-day-data/main ?
<pitti> seb128: ah, indeed! /me uploads
<seb128> pitti: danke
<dholbach> ah no, nevermind
<dholbach> Hobbsee: what happens if you run        cd ~/.5-a-day-data; bzr update; bzr commit -m "updated log for 'hobbsee'"     ?
<dholbach> if that makes it work,we should look into splitting up the branch quickly :)
<Hobbsee> dholbach: same problem on that commit
<Hobbsee> dholbach: you mean bzr doesn't handle big things?
<dholbach> Hobbsee: no, if lots of people hammer the same branch, you can always get out of sync in a few seconds :)
<Hobbsee> dholbach: right, but this has happened multiple times today?  :)
<glatzor> morning pitti, seb128, dholbach and Hobbsee
<dholbach> hi glatzor
<seb128> hi glatzor
<Hobbsee> morning glatzor!
<pitti> hi glatzor
<dholbach> Hobbsee: can you pastebin     bzr info -v          somewhere?
<Hobbsee> dholbach: http://rafb.net/p/LKucRO74.html
<dholbach> Hobbsee: <spiv> dholbach: as a workaround, hobbsee should be able to "bzr switch sftp://hobbsee@bazaar.launchpad.net/%7E5-a-day/5-a-day-data/main/"
<dholbach> Hobbsee: https://bugs.launchpad.net/launchpad-bazaar/+bug/196913
<ubotu> Launchpad bug 196913 in launchpad-bazaar "Cannot lock LockDir(lp--1218658708:///~5-a-day/5-a-day-data/main/.bzr/branchlock): Transport operation not possible: readonly transport" [Undecided,New]
<dholbach> hey mvo
<mvo> hey dholbach!
<seb128> hello mvo!
<seb128> mvo: back to germany?
<pitti> hey mvo, welcome back
<mvo> pitti: yeah, thanks :)
<mvo> seb128: yes, arrived last night (later, flight was slightly delayed)
 * seb128 hugs mvo
<pitti> dholbach: btw, suggestion: could update-signature do a 'bzr update ~/.5-a-day-data/'?
<pitti> dholbach: so that I can call it on all my machines
 * mvo hugs seb128 dholbach pitti
<seb128> dholbach: could you namespace update-signate btw? 5aday-update-signature or something?
<dholbach> pitti: bug 196914
<ubotu> Launchpad bug 196914 in five-a-day "<pitti> dholbach: btw, suggestion: could update-signature do a 'bzr update ~/.5-a-day-data/'?" [Undecided,New] https://launchpad.net/bugs/196914
<pitti> dholbach: wow, do you have an irc2lpbug script? :)
<dholbach> seb128: bug 196915
<ubotu> Launchpad bug 196915 in five-a-day "<seb128> dholbach: could you namespace update-signate btw? 5aday-update-signature or something?" [Undecided,New] https://launchpad.net/bugs/196915
 * seb128 hugs dholbach
<dholbach> pitti: no, I'm just quick today
<dholbach> no time until end of next week to hack on 5-a-day stuff though
<seb128> dholbach: that's like inbox handling, do it now and switch to something else? ;-)
<dholbach> so if somebody else wants to get started on those bugs.... :)
<pitti> seb128: ah, I know why I didn't get bug mail for the dbus FF request, ubuntu-release wasn't sub'ed
<seb128> pitti: I did!
<pitti> seb128: ah, so slangasek unsub'ed ubuntu-release after ack'ing apparently
<seb128> likely
 * dholbach -> dogwalk
<seb128> that's annoying you don't get a bug in such cases
<seb128> a mail rather
<seb128> that's the same when somebody reassign a bug to an another package
<seb128> you have mails about the bug
<seb128> but nothing suggesting it has been moved on somebody's else plate
 * pitti hugs seb128
<pitti> seb128: I just put my wife's new audio CD into the CD-ROM drive
<pitti> seb128: RB popped up, offered me a button "copy into music collection"
<pitti> and did all the rest
<slangasek> pitti: yes, it's the only way I see to manage our queue of FFes
<seb128> pitti: nice ;-)
<slangasek> (unsubbing u-release, that is)
<pitti> this is *sooo* mindbogglingly well integrated!!
<pitti> slangasek: right, I understand
<pitti> seb128: I noticed that g-v-m also started sound-juicer; I think it should stop doing that then?
<pitti> (and do we still need s-j at all?
<pitti> Keybuk: ^ WDYT?
<seb128> pitti: I though we dropped this tab, from gvm?
<pitti> seb128: not for playing audio CDs, that's still s-j
<seb128> pitti: oh, I though you used the fedora patch I pointed to you some time ago which masks the tab
<pitti> oh, did you? I just disabled the gconf keys
<pitti> ah, I remember
<pitti> we need to do that for upgrades, too
<seb128> the fedora patch takes care of upgrades
<pitti> seb128: shouldn't that happen upstream, too, with gvfs'/nautilus' recent progress?
<seb128> pitti: http://bugzilla.gnome.org/show_bug.cgi?id=509823
<ubotu> Gnome bug 509823 in general "remove autorun/automount options" [Normal,Unconfirmed]
<pitti> seb128: IIRC it just completely disables the usage of them, right
<Keybuk> pitti: sounds like it doesn't need my opinion ;)
<seb128> pitti: right, which is what we want
<seb128> Keybuk: having s-j still does
<Keybuk> seb128: what do you think?
<seb128> I think we should keep it, it has its users
<seb128> the UI is clean and it's small
<Keybuk> rhythmbox can't play auto cds, right?
<seb128> it does in hardy now
<Keybuk> oh, interesting
<seb128> what do you call "auto cds"?
<pitti> Keybuk: WFM
<seb128> when started with a drive parameter it switches to the audio CD and start playing
<pitti> seb128: ok, I agree we could keep it in main, it doesn't hurt; but for new installs, too?
<pitti> Keybuk: oh, "WFM" under the assumption that s/auto/audio/ :)
<seb128> pitti: it's part of the upstream desktop, not sure
<Keybuk> err, I mean audio cds
<Keybuk> seb128: which do you think we should use by default for audio cds?
<seb128> I'm not decided
<slomo> Pici: yay, dbus 1.1.20 :)
<seb128> sound-juicer has clean interface and is easy to use
<seb128> rhythmbox is nice but it might be too much to just play a CD
<seb128> what do other people think?
<seb128> we can still switch to rhythmbox by default now
<seb128> and see feedback we get until beta
 * pitti â¥ RB, but I'm not claiming to be a representative user
<seb128> and then decide on whether we use it or sound-juicer
<Keybuk> that's a good idea
<pitti> since it integrates better with your existing music collection
<pitti> I think *if* you are using RB, then you want it for CD ripping, too
<pitti> but if you *don't* use/like RB, then it's too heavy
<pitti> (like users prefering banshee, or so)
<slomo> but then you'd want to use banshee instead of sj most probably (i still prefer sj for ripping though ;) )
<seb128> hey carlos
<carlos> seb128: hi
<pitti> seb128: so, I'll apply that g-v-m patch soon
<slomo> pitti: which takes us back to http://bugzilla.gnome.org/show_bug.cgi?id=510614
<ubotu> Gnome bug 510614 in general "Allow more user friendly selection of applications to use" [Enhancement,Unconfirmed]
<seb128> pitti: thanks
<pitti> seb128: so the application for new devcies is now selected in nautilus?
<seb128> pitti: yes
<seb128> pitti: the media tab in the preferences dialog
<seb128> brb
<pitti> slomo: IMHO that's solved much better now
<slomo> pitti: how?
<slomo> pitti: the extension to the .desktop files?
<pitti> slomo: look at nautilus -> preferences -> media
<pitti> slomo: there's a dropdown with all available apps now
<slomo> pitti: how is this list generated?
<pitti> slomo: not entirely sure, TBH; seb might know?
<cjwatson> RB by default> sound-juicer doesn't do last.fm, does it? my wife uses RB for that
<seb128> cjwatson: the question was about CD playing (when you insert an audio CD in the drive)
<seb128> but it might make sense to start the music player so people can switch to listen something else easily
<cjwatson> seb128: I was talking about CD playing
<cjwatson> seb128: last.fm users like to notify last.fm when they play a CD so that it gets more information about their music preferences
<seb128> ah, right
<cjwatson> that's not on by default in RB, but it's a fairly easy to find checkbox
<seb128> yes, the plugin is not activated by default and you need to configure an account but that's easy enough
<Keybuk> I dislike the fact that configuration for plugins is hidden inside the plugins
<tjaalton> does RB do musicbrainz?
<tjaalton> when ripping
<tjaalton> apparently yes
<slomo> pitti: is dropping the xinit.d dbus-launch thing still required? was for gnome-keyring, right?
<asac> ArneGoetje: did you get in touch with thep yet (thai fonts)?
<pitti> slomo: right; maybe the newer version fixes it
<Keybuk> tjaalton: what's musicbrainz?
<pitti> mvo: hm, there's another update-manager upload in -proposed
<pitti> mvo: shouldn't we get the current one into -updates first? otherwise verification get even more hairy and dragged
<pitti> mvo: (bug 172609)
<tjaalton> Keybuk: cddb/freedb on steroids
<tjaalton> ie. much better
<lool> pitti: Did you get my remarks on the langpack stuff?
<lool> pitti: BTW, new dbus uploaded; only change is a CVE id
<pitti> lool: ah, yay; I added the CVE to the Ubuntu changelog
<pitti> lool: langpacks> sorry, seems I missed them
<lool> pitti: Concerning the langpack: we have to do the scripting and all to have hildon langpackable in all cases, but the planned savings (something like 10 MB per language so max 30 MB) are not highly interesting
<lool> So the part with new templates and copying translations into multiple langpacks are not too important for us
<pitti> lool: 10 MB per language? that sounds really much
<lool> And hence seeds support
<mvo> pitti: yes, its not easy as it needs a hppa or ia64 box to test the 0.81.2
<lool> pitti: gnome and main langpacks are currently pulled
<pitti> mvo: lamont can't test this?
<lool> s/main/common
<pitti> mvo: also, I'm actually more interested in getting a normal amd64/i386 upgrade test
<pitti> mvo: i. e. to check for regressions
<pitti> lool: so we just need the categorization for mobile and create l-p-mobile-XX, depending on l-p-gnome?
<lool> pitti: What we _need_ is only hook support, like for firefox, openoffice.org etc.
<mvo> pitti: for regressions? right, I think I can ask bdmurray for this
<lool> The rest is all optional to whether we want mobile langpacks, but it's a lot of work for little savings
<dholbach> hum... is cdimages.u.c slow for somebody else too?
<dholbach> (7k/s)
<Hobbsee> would it be a stupid question to ask why my keycodes for my multimedia keys appear not to work?
<TomaszD> hi, if anyone has a moment, this is very simple fix https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/196953 , Polish users would appreciate this fix :]
<ubotu> Launchpad bug 196953 in firefox-3.0 "Add Polish translation to firefox.desktop (diff included)" [Undecided,New]
<TomaszD> *this is a
<mjg59> Do we have anything in the distribution right now that can parse GtkBuilder files?
<mjg59> Our glade-3 doesn't seem enthusiastic, and gazpacho fails on startup
<Hobbsee> feed it some red cordial.
<mjg59> Hm. Yeah, need gazpacho 0.7.2...
<seb128> hey mjg59
<seb128> mjg59: did you read my comments about the dbus-send call and the backlight issue yesterday?
<mjg59> seb128: Yeah. No clue what's going on there. As I said, dell-addon-backlight is an entirely separate chunk of code
<mjg59> It's run as a separate process
<seb128> k
<seb128> I'll try if that's happening using the git version
<seb128> and open a bug upstream if that's the case
<mjg59> lool: Any chance you could update gazpacho? We seem to have been on 0.7.1 since April :)
<Hobbsee> mjg59: *stab in the dark* - where would i start looking for why my multimedia keys have stopped showing up in xev, but used to all work fine?
<Hobbsee> all but one seem to come up in the dbus stuff
<mjg59> Hobbsee: Erm. No clue. X keymap change?
<mjg59> No, that shouldn't affect it
<Hobbsee> mjg59: don't think so
<mjg59> Are you using evdev?
<Hobbsee> mjg59: how do i check?
<mjg59> Xorg.0.log
<Hobbsee> nope
<mjg59> lool: Eh. 0.7.2 fails in the same way for me
<mjg59> AttributeError: GazpachoObjectBuilder instance has no attribute '_version'
<Hobbsee> mjg59: any idea about who i should bug about where to start looking?
<mjg59> Hobbsee: I genuinely have no idea what could be causing that. If they're showing up in dbus, then the only thing I can think of is that it's an X problem
<mjg59> Because they're clearly being generated by the kernel
<seb128> pitti: would should we do with bug #196740?
<ubotu> Launchpad bug 196740 in gnome-utils "There are no debugging symbols for gnome-utils available" [Wishlist,Invalid] https://launchpad.net/bugs/196740
<Hobbsee> mjg59: any idea why one of them isn't showing up in dbus then?
<mjg59> Which one?
<Hobbsee> next track
<Hobbsee> previous track does
<Hobbsee> but next track is broken.
<mjg59> Is it getting mapped?
<Hobbsee> how do i check?
<mjg59> See what it generates on the console with showkeys
<Ng> Hobbsee: are they acpi event producing keys?
<Ng> I ask only because my blue thinkpad button has stopped sending events to xev, but acpid sees it
<Hobbsee> n
<Hobbsee> g
<Hobbsee> mjg59:
<lool> mjg59: I never uploaded or used gazpacho *cough* ;)
<Hobbsee> g
<Hobbsee> ah
<Hobbsee> .
<Hobbsee> a
<Hobbsee> o
<mjg59> lool: packages.qa seems to have you in uploaders
<Hobbsee> y
<lool> mjg59: I'm just an uploader as a result of pkg-gnome scripts
<Hobbsee> .
<Hobbsee> s
<mjg59> lool: Ah
<Hobbsee> i
<Hobbsee> g
<Hobbsee> h
<mjg59> Hobbsee: Erm.
 * lool slaps Hobbsee 
<Hobbsee> a
<Hobbsee> r
<Hobbsee> g
<Hobbsee> h
<Hobbsee> 1
<Hobbsee> 1
<Hobbsee> 1
<Hobbsee> a
<Keybuk> Hobbsee: are you ok?
<Hobbsee> n
<Hobbsee> o
<pitti> someone pleas stop Hobbsee
<lool> Seems over
<Pici> o.o
<mjg59> Keyboard bugs are fun
<lool> mjg59: But I can still have a look
<pitti> seb128: no idea other than 'wait for new upload', I'm afraid
<mjg59> lool: How on earth do you do any gtkbuilder work? We don't seem to have anything in the archive that actually works
<pitti> hm, libsvg wants to go to universe? that's surprising
<lool> mjg59: I ... don't lalala
<Keybuk> Hobbsee: /msg me when it's fixed and i'll unmute you
<lool> mjg59: You work on the old glade file and convert it to gtkbuilder haha
<Keybuk> (just in case +q - no offence intended)
<mjg59> lool: Fail.
<seb128> mjg59: work on a glade source and convert it to gtkui
<mjg59> gazpacho is supposed to do this, but is broken
<Keybuk> does GtkBuilder fix the fact that your custom window cannot be derived from GtkWindow but has to be an instance of that class?
<lool> seb128: Sound server isn't started anymore with the new gnome-session
<lool> I'll try again
<ogra_cmpc> lool, isnt that started by an initscript ?
<emgent> heya people
<seb128> lool: do you have the gnome-settings-daemon update uploaded yesterday?
<lool> seb128: Ah I might not
<Hobbsee> well, that was interesting.
<seb128> lool: you need it, it's the one starting the sound server now
 * lool tries that now
<cjwatson> 13:41 -!- mode/#ubuntu-devel [-b %*!n=hobbsee@ubuntu/member/hobbsee] by Keybuk, Hobbsee
<Hobbsee> mjg59, Keybuk, pitti, lool, etc:  my apologies.  keyboard was on crack.
<cjwatson> don't believe I've ever seen that happen before
<lool> seb128: I didn't; will pull it now
<Keybuk> Hobbsee: no apology necessary
<pitti> Hobbsee: itz gtk bug
<Hobbsee> it appears that it was sending the enter keypress every few miliseconds or so :P
<lool> Hobbsee: e
<lool> v
<lool> just kidding ;)
<Keybuk> cjwatson: yours reports -b too, how weird
<Keybuk> (the mode change was -q)
<Hobbsee> cjwatson: chanserv sometimes gets confused.  i've actually found a bug in it, too
<Hobbsee> Keybuk: yes, but it has a % which means a quiet.
<Keybuk> ahh
<lool> I get plenty of 404s from http://archive.ubuntu.com hmmm
<cjwatson> Keybuk: it reported the +q as +b too
<lool> (Same here)
<Hobbsee> cjwatson: that's normal.  wish it didn't though, it keeps confusing users.
<Hobbsee> +q == +b %
<lool> Bah my squid is on crack again
<pitti> Riddell: kdepim-kde4 Depends: kdebase-runtime-bin, which is NBS
<emgent> dholbach, ping (query)
<Hobbsee> emgent: he's dog walking
<dholbach> emgent: I saw the query but was too busy up until now and was just about to take my dog for a walk - sorry
<dholbach> emgent: please be patient and wait for an email on the list, I did not forget about it
<emgent> Hobbsee, lol :)
<emgent> keescook, ping
<emgent> ok thanks dholbach :)
<Hobbsee> calc: oops, you broke it.
<Hobbsee> E: /var/cache/apt/archives/openoffice.org-hyphenation-en-us_2.3.1-1_all.deb: trying to overwrite `/usr/share/myspell/dicts/hyph_en_US.dic', which is also in package openoffice.org-hyphenation
<pitti> superm1: ubuntustudio-audio depends on rosegarden4, which is NBS; can you please fix the dependency?
<pitti> superm1: (oh, NBS == not built from source, thus it'll go away by the final release)
<_MMA_> pitti: superm1 does Mythbuntu. Ill get one of our guys to fix it.
<persia> I thought we fixed that a while back?  Does it need a merge?
<_MMA_> persia: I thought so. Though, Im a little fuzzy as to what changed.
<tonio> seb128: hey ! I'm packaging a gnome app yet, and I wondered if there is a metapackage for gnome dev files like kdelibs4-dev
<tonio> seb128: atm I have something like 20 -dev packages..... I'm sure there is a way to do better no ?
<seb128> tonio: gnome-devel
<jdong>  anjuta (>= 1.2.0), bluefish,
<jdong> seb128: are you *sure* that's the one he wants?
<jdong> gnome-core-devel looks more appropriate
<seb128> jdong: dunno, he took a example I don't know about
<seb128> I'm not using KDE
<jdong> seb128: I believe he just wanted a metapackage for common build-deps associated with gnome
<jdong> rather than listing like 30 packages for the simplest of GNOME apps
<seb128> jdong: feel free to reply to him, he asked on a public chan
<jdong> tonio: ^^ see if gnome-core-devel fits the bill
<jdong> seb128: I wasn't entirely sure of the answer myself
<seb128> I've other things to do than discussing if my reply is what he wants ;-)
<tonio> seb128: thanks, jdong, same
 * Hobbsee looks for a large brick
 * jdong hands Hobbsee a macbook pro
<Hobbsee> hrm.  do you want that back, in working order?
<jdong> Hobbsee: it worked to begin with?
<jdong> one of my buds bought one to work with Linux. An interesting idea.
<Hobbsee> yeah, good point
<jdong> of course 3 hours later he opened it up and swapped out the broadcom wifi card
<jdong> I'm quite sure that's not how Apple intended it to be used ;-)
<lifeless> the macbook air is _sweet_
<jdong> now it runs Linux great but doesn't run OS X at all
<thom> lifeless: for values of sweet approaching sour
<Hobbsee> mjg59: bitter at the kernel team much?  :)
 * Hobbsee uses jdong's macbook, and knocks herself out.  night all.
<lifeless> thom: oh, you don't like
<lifeless> ?
 * soren kicks /usr/share/initramfs-tools/scripts/local-premount/resume
<jdong> Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/libg/libgweather/libgweather0_2.21.92-0ubuntu1_i386.deb  404 Not Found [IP: 91.189.88.31 80]
<jdong> one of the archive.ubuntu.com servers seems to be 404'ing like mad
<thom> lifeless: no, played with one, unimpressed
<lool> seb128: Even with latest updates, logon sound is still borkne for me
<lool> pulseaudio is started, but I don't hear the logon sound
<seb128> lool: ok, same for me, I'll try without the debian gsd startup patch and with the svn change version
<superm1> lool, did you see my email wrg to ekiga?
<lool> superm1: Yes
<lool> superm1: I'm not particular tightened to ekiga, but will have a look
<seb128> lool: doesn't work better
<superm1> lool, okay well you had just done the last merge from what it looked, so rtg said to speak with you.  Thanks
<lool> superm1: Yeah, that's what I guessed
<soren> Keybuk: It seems there's a race in the resume code in our initramfs.. Do you have a few minutes?
<Keybuk> soren: sure
<soren> Keybuk: For reasons that will go unmentioned, I had to nuke my swap lv at some point and have now recreated it. This has reordered my lvm layout so that swap_1's /dev/disk/by-uuid link gets created a bit too late for the resume stuff to be able to see it.
<soren> Adding a tiny sleep or a call to udevsettle will fix it, but I'm sure you have a better idea. :)
<soren> Well, udevadm settle, but ykwim.
<soren> I could make a wait_for_resume_device loop akin to the one that waits for the root, but I'm not too hot on that either.
<Keybuk> resume is run from local-premount, no?
<soren> Right.
<Keybuk> so it's run after the wait-for-root loop?
<soren> Yes.
<Keybuk> so shouldn't the swap device be there too?
<soren> I can see what you're getting at..
<soren> Precisely.
<soren> but it's not.
<soren> The thing is..
<Keybuk> hmm
<Keybuk> it's on the same disk?
<soren> Yup.
<soren> Due to the fact that I removed the lv and then created it again, it's now discovered as the last lv rather than one of the very first ones.
<soren> Well... I assume that's the reason.
<soren> It worked just fine before then, and now, if I break=bottom, and manually do the resume /dev/disk/by-uiid/blahblahbl, it resumes just finne.
<soren> fine.
<sistpoty|work> Hobbsee | Riddell: can one of you two give a hint about the FFe for new package keurocalc? (bug #196123) thanks
<ubotu> Launchpad bug 196123 in ubuntu "[FFe] keurocalc port to kde4" [Undecided,Incomplete] https://launchpad.net/bugs/196123
<soren> I put a few "ls -l /dev/disk/by-uuid/" into the resume script with a "sleep 1" in between. In the first one, it shows all the lv's up until and including the root, in the last one, it also has my swap.
<Keybuk> what does $RESUME contain when you do break=bottom ?
<soren> Oh, that stuff is all fine.
<Keybuk> yeah, simple race then
<soren> The path reference is just fine.
<Keybuk> to fix it properly
<Keybuk> I'd move the $RESUME -> $resume code from the resume script into init itself
<Keybuk> and then adjust the loop inside local to check for $ROOT and $resume existing
<soren> Well..
<soren> That would work.
<soren> Sort of.
<soren> The problem is that it shouldn't fail if the resume device never shows up.
<pitti> seb128: g-v-m with that patch uploaded; I had to fix the second upstream patch, took a little longer
<lifeless> thom: I thought it was better than my d430 - lighter, less volume
<soren> Keybuk: I'm thinking about adding a second loop that times out after something as low as 5 seconds.
<seb128> pitti: ok, thanks
<Keybuk> I *hate* never fail if never shows up problems
<seb128> pitti: do you think we should revert the dual battery hal change?
<soren> Keybuk: ?!?
<Keybuk> soren: racing $ROOT and $RESUME
<soren> Keybuk: I can't parse that sentence.
<Keybuk> in an ideal world, you'd just mount the root filesystem on the event for it being available
<pitti> seb128: back to double batteries?
<Keybuk> and you'd resume from swap on the event for it being available
<pitti> seb128: AFAICS we should rather change it to only consider /proc?
<soren> Keybuk: Right.
<Keybuk> but you can't do that, because you have to wait for both to determine which you need to do
<soren> Keybuk: Exactly.
<Keybuk> (see also: why we're not taking advantage of Upstart yet)
<Keybuk> it's worse, since depending on circumstance, one or the other may not show up at all
<soren> Keybuk: One could make the argument that hibernation and subsequent resuming from hibernation is somethat that will only reasonable take place on systems that don't need to wait several minutes for the resume partition to show up.
<pitti> seb128: I don't know whether it's the right solution (i. e. whether the kernel puts wrong stuff in /sys or hal just reads it wrongly), but since batteries in /proc are known to work, we should maybe just go with that in hardy
<Keybuk> if you have $ROOT, how long do you wait before assuming $RESUME isn't going to show up
<seb128> pitti: dunno if you read it yesterday but crimsun_ got some git changes fixing the battery notifications
<Keybuk> you can always guarantee someone will file a bug, because their $RESUME shows up one second after whatever you pick
<pitti> seb128: no, I didn't reat id
<soren> Keybuk: I realise.
<soren> Keybuk: Just as is the case for the current loop that waits for the root.
<pitti> carlos: any idea about this translation regression? bug 196106
<ubotu> Launchpad bug 196106 in language-pack-kde-de "context menu entry "Paste File" [and other dialogs] not translated into German (anymore)" [Undecided,New] https://launchpad.net/bugs/196106
<Keybuk> you'd end up with
<cjwatson> Keybuk: could we put a marker in the root filesystem to say that you should wait for resume?
<Keybuk>   on filesystem-available $ROOT and (filesystem-available $RESUME or 5s after filesystem-available $ROOT)
<Keybuk> type things
<cjwatson> hmm, I suppose it would have to be on the device such that you didn't need to mount the filesystem to get at it
<Keybuk> cjwatson: doesn't protect you from corrupt swap partitions :-(
<Keybuk> or partial hibernation, etc.
<mjg59> You can't partially hibernate
<Keybuk> mjg59: what happens if the power goes out while it's writing to swap?
<mjg59> Oh, sorry, I see what you mean
<Keybuk> or (and I have seen this) some idiot using md as their swap partition
<Keybuk> cjwatson: of course, we could always use swap files on the root partition ;)
<cjwatson> :-)
 * soren twitches
<cjwatson> I think we have to support swap partitions regardless of the default
<Keybuk> or mandate that the resume partition has to be on the same physical disk as the root
<soren> That is the case here.
<cjwatson> which presumably still doesn't guarantee that they show up simultaneously
<cjwatson> just quite close together
<soren> Yet, it still races (and loses).
<Keybuk> not when md, lvm, devmapper are involved - no
<cjwatson> even without any of that, it can't create both devices at the same time
<soren> Er... lvm is involved.
<soren> And it races.
<Keybuk> cjwatson: I mean that it's easy to force waiting for the rest of the partitions on the same disk to all exist
<cjwatson> ah
<Keybuk> but it's hard when you're actually waiting for a resultant block device
<Keybuk> udev may have seen the partitions, but it now has to go and run lvm, mdadm, etc.
<soren> Well, the block device is there.
<Keybuk> and those things use watershed
<soren> udev just hasn't quite gotten around to creating the uuid symlink.
<Keybuk> soren: honestly, the best quick fix solution is just to copy the busy-loop out of local into resume
<Keybuk> and reduce it from 180 to 5
<soren> Keybuk: That works.
<soren> Keybuk: Ok, I'll work something to that effect out when I get off the phone again. Thanks.
<TomaszD> excuse me, does anyone know where can I find the _Unlock button for translation in gnome-system-tools admin applets? It's not in g-s-t, it's not in policykit-gnome...
<TomaszD> forget it, my bad
<cjwatson> doko_: please commit your oem-config changes to bzr, preferably as a branch from the revision at which 1.28 was released which you then merge with evand's un-uploaded changes
<doko_> cjwatson: ok, same for ubiquity?
<cjwatson> you uploaded ubiquity? eek
<cjwatson> yes, absolutely
<doko_> down to one build dependency on python-xml ...
<cjwatson> erm, but ubiquity is awkward because you aren't in the ubuntu-installer team
<cjwatson> please publish a branch that we can merge
<cjwatson> doko_: also please don't use ubuntu1 versioning for packages maintained in Ubuntu as native packages
<cjwatson> oh, actually, you didn't, it was just the tarball ...
<doko_> yep, noticed, but forgot to rename
<cjwatson> doko_: localechooser should be done in bzr too, if you were planning to do that
<pitti> seb128: I just updated https://wiki.ubuntu.com/StableReleaseUpdates
<pitti> seb128: the procedure is *much* easier to read now IMHO; comments?
<cjwatson> doko_: if you haven't uploaded ubiquity yet, please don't, as evand is preparing an upload too
 * Keybuk tries to remember if you can match string literals in the C preprocessor #if
<seb128> pitti: much nicer indeed
<seb128> pitti: the procedure description is clear now
<doko_> cjwatson: sorry, already done. or remove if from the queue?
<cjwatson> too late :-(
<evand> uh oh
<cjwatson> the publisher is already munching on it
<sistpoty|work> Keybuk: what do you want to achieve?
<evand> I imagine I should cancel this then
<cjwatson> evand: you'll have to
<Keybuk> sistpoty|work:  #if SBINDIR == "/usr/sbin"
<evand> done
<doko_> evand: I looked for you on the distro channel, but didn't find you there. forgot to look here
<cjwatson> until doko gives us a branch to merge so that you can punt this to 1.7.14
<cjwatson> there were vcs-bzr headers in both packages, I believe
<evand> doko_, sorry, I'm somewhat in flux today and don't have xchat set up for Canonical IRC
 * seb128 hugs pitti, good work, I think it's great now ;-)
 * pitti hugs seb128
<doko_> evand: patch is here, http://people.ubuntu.com/~doko/tmp/ubiquity.diff my connection to the data center seems to be dead slow
<cjwatson> doko_: choose-mirror needs to go to bzr too (and again, there was a small unuploaded change; branch from r580)
<doko_> cjwatson: I'll take care of that
<cjwatson> thanks
<evand> doko_, thanks
<sistpoty|work> Keybuk: seems like you can't: http://gcc.gnu.org/onlinedocs/cpp/If.html#If
<Keybuk> sistpoty|work: yeah, reading C99 doesn't help either
<Keybuk> it doesn't really go into detail about what you can put there
<Keybuk> other than saying it has to be a constant expression
<sistpoty|work> only characters, but you cannot index a variable as well, so :(
<sistpoty|work> (apart from integers of course)
<sistpoty|work> Keybuk: if it uses autoconf, you could just set a definition to s.th. if sbindir is /usr/bin?
<Keybuk> well, *yes* :p
<sistpoty|work> heh
<cjwatson> Keybuk: C99 6.4.5 para 6 "It is unspecified whether these arrays are distinct provided their elements have the appropriate values" which I think means you can't rely on pointer equality
<Keybuk> I wanted value equality though :)
<cjwatson> well the preprocessor will only give you pointer equality
<cjwatson> err, not even that actually, hmm
<Keybuk> the preprocessor just gives me an error
<Keybuk> which pretty much answers the question no matter what the standard says ;)
<cjwatson> yeah, C99 says you can't do that
<cjwatson> 6.10.1 para 1 "shall be an integer constant expression"; 6.6 para 6 lists the operands that may be in an integer constant expression none of which include string literals
<Keybuk> *nods*
<Keybuk> agree
 * Keybuk returns C99 to its job of being a bookmark in Stevens APUE
<Keybuk> (I'm not the only one who uses books as bookmarks for other books, right? :p)
<lifeless> Keybuk: folding them closed around each other?
<Keybuk> lifeless: yeah, or leaving one open with the other on top of it to keep my place
<lifeless> yah, I fo the dormer
<Keybuk> http://www.amazon.co.uk/dp/0470845732/ -- best buy ever
<doko_> bzr: ERROR: bzrlib.errors.UnlockableTransport: Cannot lock: transport is read only: <bzrlib.transport.http._urllib.HttpTransport_urllib url=http://bazaar.launchpad.net/%7Eubuntu-core-dev/localechooser/ubuntu/.bzr/repository/>
 * doko_ grumbles
<bddebian> pitti: You around by any chance? (about clanbomber)
<LaserJock> pitti: I feel so rejected ;-)
<ogra_cmpc> LaserJock, what, did he not approve the MIR for squeak ? :0
<LaserJock> hah
<bddebian> heh
<Keybuk> sistpoty|work: the problem is that in autoconf, sbindir isn't fully evaluated yet
<evand> doko_, I've merged your changes in and uploaded a new ubiquity that reverted them.  It looks like you're already fixing this in localechooser and choose-mirror, though, so they'll go back in as soon as we release another ubiquity.
<evand> assuming that the new localechooser and choose-mirror are in the archive at that point
<doko_> evand: localechooser is
<doko_> but not choose-mirror
<evand> ok
<sistpoty|work> Keybuk: oh... can't it work with some m4 that's getting evaluated once configure is called (assuming that you know autoconf much than I do *g*)?
<Keybuk> sistpoty|work: yes, but it's icky :p
<sistpoty|work> heh
<cjwatson> doko_: yeah, if you ever find yourself touching anything inside d-i/source/ in ubiquity or oem-config, please read d-i/README which tells you not to ;-)
<Keybuk> Pumpernickle: do you mean to have so many clones?
<jpatrick> Keybuk: he's host reminds me of a network troll I've had problems with..
<Keybuk> jpatrick: the nick is known to me
<Keybuk> so it's likely just network problems on his end and an unattended reconnecting IRC client
<Keybuk> (giving him the benefit of the doubt - and in no way looking at the fact the numbers joined out of order <g>)
<jpatrick> forwarding him to ##fix_your_connection would be best
<calc> Hobbsee: for whatever reason it was biting me before the update, so i requested the update hoping it might fix it, since it didn't i'm going to have to update the packaging as well :-\
<Keybuk> jpatrick: how do I do that?
<jpatrick> Keybuk: /mode +b *!*@CPE0014d13c957e-CM0012c9a9a6dc.cpe.net.cable.rogers.com!##fix_your_connection
<jpatrick> Keybuk: and remove the last ban
<Keybuk> jpatrick: it won't let me add that as a ban
<jpatrick> Keybuk: you could /op me a sec
<Keybuk>  MODE +b redirection channel: :That channel doesn't exist
<jpatrick> Keybuk: whops, forgot: /mode #ubuntu-devel +b *!*@CPE0014d13c957e-CM0012c9a9a6dc.cpe.net.cable.rogers.com!##fix_your_connection
<Keybuk> it's the fix_your_connection thing it's complaining about
<jpatrick> hmm, the channel does exist and Pumper* is in there..
<Keybuk> no idea then
<Keybuk> silly network
<jpatrick> Keybuk: hmm, curious guy
<Keybuk> jpatrick: hmm?
<jpatrick>  /mode #ubuntu-devel +b *!*@CPE0014d13c957e-CM0012c9a9a6dc.cpe.net.cable.rogers.com
<Keybuk> I've always wondered whether those still work if the host is cloaked :)
<jpatrick> Keybuk: it does
<Keybuk> bored now, anyway
<Keybuk> he's clearly either got a major problem, or trying to cause one
<coastGNU> cjwatson: Hi Colin. Is there a list for oem-config discussion/development?
<cjwatson> coastGNU: ubuntu-installer@ will do
<coastGNU> cjwatson: Ok, thanks. Next question, do you plan to handle persistent-net and persistent-cdrom via oem-config or is it up to the oem to place needed hook files for this?
<heno> To #ubuntu-devel: "Thank you for ubuntu!" -- from http://brainstorm.ubuntu.com/idea/1514
<cjwatson> coastGNU: hmm, good question, I hadn't particularly thought of that
<cjwatson> coastGNU: could you file a bug for that? comes under the general category of reconfiguration for specific hardware
<coastGNU> cjwatson: I'm writing an Article for freeX magazine and there are quite a lot question marks which came up in my mind over the last weks.
<coastGNU> cjwatson: s/wek/week/
<stgraber> heno: :)
<cjwatson> coastGNU: oem-config development is basically whenever people ask for stuff :)
<coastGNU> cjwatson: Hhhm, if you would ak me oem-config is the most promising tool to fix bug #1, isn't it
<cjwatson> coastGNU: I'm not sure I'd go that far :-), but it's certainly useful
<terrex> Hi. Do you know how can I use internet inside PPA chroot? My package (maven) requires download pom and jar files from internet in order to build maven itself.
<cjwatson> you can't; you need to put any necessary files in the source package itself
<cjwatson> (this is intentional)
<terrex> ok, i'll try again but... there is a limit on the size of .orig.tar.gz ?
<cjwatson> terrex: no, aside from the usual PPA size limits
<terrex> ok, thanks!
<nicolah> will http://brainstorm.ubuntu.com/ influence your work, developers ?
<stgraber> nicolah: too late for Hardy, but AFAIK it'll be taken into account for the UDS to come (Intrepid Ibex)
<nicolah> great
<nicolah> thanks for the answer stgraber I won't bother you anymore
<soren> slangasek: Any chance you could apply some love to bug 196868?  If I have to redo the kernel merge, kittens will die.
<ubotu> Launchpad bug 196868 in kvm "[ffe] Upgrade kvm from vers. 60 to 62" [Undecided,New] https://launchpad.net/bugs/196868
<soren> That's meant as a threat, not a prophecy. I have a bag full of kittens and a sharp knife, and I'm ready to go.
<soren> Will someone *please* think of the kittens?
<evand> hahaha
<_MMA_> For shame. Laughing at the thought of dying kittens. ;)
<slangasek> soren: I doesn't negoshurait wif terrists
<slangasek> soren: yeah, I'll be looking at that one today, but not for a few hours yet
<soren> ZOMG! i haz bin lolcatzetzed.
<kavit> hi I was wondering if the kernel module firmware_class has been removed from the gutsy kernel or it has been compiled into it?
<kahrytan> Does anyone know if Hardy will use cx18 beta driver for ivtv?
<keescook> slangasek: http://outflux.net/kittens.png
<slangasek> keescook: aieee
<\sh> lol
<jpatrick> keescook: that guy looks like my old maths teacher...
<\sh> jpatrick: that guy is himself ... the master in security ,-)
<soren> \sh: Er.. No. It's slangasek. Not kees.
<keescook> that pictures is not of me.  :)
<\sh> what?
<keescook> s/s
<soren> s/s/z/
<\sh> s/security/release managing/ ,-)
<\sh> sorry ;) but the website is yours...
<keescook> heh, yawp
<\sh> but this smile on the face...I guess he hacked something before ;)
<slangasek> tjaalton: is there going to be any sort of final resolution of bug #133192?  it's been release-noted for quite a few alphas in a row now...
<ubotu> Launchpad bug 133192 in xserver-xorg-video-ati "Blank screen or distorted image because of wrong default AGPMode value" [High,Confirmed] https://launchpad.net/bugs/133192
<\sh> I had such a smile yesterday, when I stresstestbroke our servers
<\sh> so time to leave for today...
<tjaalton> slangasek: oops, sorry.. it's fixed now
<tjaalton> 6.8.0-1 reverted the behaviour
<tjaalton> slangasek: I don't remember the gory details, but there is no silver bullet to the problem, there will be setups where the only resort is to play with BIOS settings
<slangasek> so the current status is that the behavior matches the behavior from previous releases?
<tjaalton> correct
<slangasek> ok, that's probably good enough to take it out of the release notes then
<tjaalton> yep
<tjaalton> we should make a MASTER bug about this..
<cjwatson> doko: I'd appreciate it if you wouldn't remove the details from the "Automatic update" changelog message
<cjwatson> they are useful for tracking down bugs later on
<doko> cjwatson: err, I didn't ...
<cjwatson> doko: did you not run 'debian/rules update'?
<doko> yes
<doko>   [ Matthias Klose ]
<doko>   * Automatic update of included source packages.
<doko> that was included
<cjwatson> something must have gone wrong if it didn't include any details
<cjwatson> I would like to handle the next upload
<doko> ok
<cjwatson> a little worried something's out of sync somewhere subtle
<cjwatson> but thanks for the merge/upload
<laga> cjwatson: hello. cdimage.ubuntu.com is now building mythbuntu alternate disks. do i have to talk to you if i want to add preseeds?
<RichW> how does https://translations.launchpad.net read translations from projects?
<EnderTheThird> Anyone having troube with X.org taking 90+ % of CPU usage with Hardy Alpha 5?
<mbt> EnderTheThird: No, at least not with an NVIDIA driver and Compiz.  Are you using VESA or something along those lines?
<EnderTheThird> mbt:  no.  intel
<mbt> EnderTheThird: Strange.  Sounds like a bug to me.
<EnderTheThird> Dell GX260.  No powerhouse by any stretch of the imagination, but it should at least be able to do 2D.  (no Compiz)
<EnderTheThird> yeah, it's unbearably slow.
<mbt> Well, maybe try switching to the VESA driver and see if that speeds things up.  At least that would likely pinpoint the cause as being the Intel driver.
<EnderTheThird> I'll give it a whirl.  brb
<EnderTheThird> much better with vesa.  It's still not as responsive as I'd think it should be, but it's usable.
<mbt> Yeah, the vesa driver is very not optimized.  But, I think that probably just gave you enough information to report the problem
<EnderTheThird> moving windows is awful, heh
<mbt> lol yeah, though you can tweak some settings in gconf to do wire-frames and the like
<EnderTheThird> Gutsy performance wasn't too great either.  Weird thing is that I remember it running better with 6.06 and 6.10, even with Compiz/Beryl.
<EnderTheThird> nevermind.  it's not just with the Intel driver
<EnderTheThird> It seems to be jumping around with Vesa too.
<mbt> It will.
<mbt> It's doing most everything with the host CPU instead of with the GPU when using the VESA driver.
<mbt> But CPU use shouldn't stay consistently high unless you've got a lot of screen updates.
<EnderTheThird> I'm going to try downgrading to 6.06 after the d/l completes.  I remember it being much faster on 6.06.  We'll see if it's just my crappy memory, heh.
<EnderTheThird> Thanks for the help.
<mbt> No problem.
<EnderTheThird> And also for being the only one active in this channel, ha
<mbt> lol I idle a lot too
<EnderTheThird> Yeah, but 233 idlers, that's just ridiculous
<RichW> should be a idlerpg competition in here
<EnderTheThird> My god man, you just might be onto something!
<mbt> lol
<RichW> there is a #idlerpg
<EnderTheThird> That is terrifying.
<RichW> User: Joe_Berelum   Total time idled: 1501 days, 18:47:39
<mbt> Wow.
<jdong> wouldn't your freenode registration expire?
<jdong> because he hasn't identified to nickserv for 120 days or whatever?
<EnderTheThird> anyone else find it funny that talking about being idle is bringing idle people out of their idle slumber?
<jdong> I was never in idle slumber :)
<EnderTheThird> or bringing them back from the toilet...  ;)
<mathiaz> mvo: how can I do an upgrade from dapper to hardy on a server ?
<mathiaz> mvo: is there a do-release-upgrade command ?
<mvo> mathiaz: yes - see https://help.ubuntu.com/community/HardyUpgrades#head-e7f287c730b93116f89de7ea7e05efbe95fa6dd1
 * sistpoty still believes that apt-get dist-upgrade should just work for people not installing 3rd party stuff
<mathiaz> mvo: ok - thanks.
<mvo> sistpoty: for dapper->hardy? it will not, you will have to upgrade apt and dpkg first if you do it manually, the problem is the new "Breaks" field
<sistpoty> mvo: than that's wrong and should be fixed imho *g*... but I must admit that I upgrade my gf's laptop with dist-upgrade, and it was just too smooth to be real ;)
<sistpoty> not with dist-upgrade, but with the updater python thingy you wrote
<mvo> sistpoty: from dapper?
<sistpoty> mvo: from feisty to gutsy
<mvo> sistpoty: nice, good to hear :)
<mvo> sistpoty: the fix for this would be to not use breaks until the next lts got released in order to maintain compatiblity. that is a bit drastic IMO - or to backport it to dapper, but that is quite a change as well
<mdke> the first fix wouldn't work surely, because you'd just have the same problem with lts+2, no?
<mdke> but I can see sistpoty's point, I would have thought a lot of server admins will try dist-upgrade from dapper to hardy
<sistpoty> mvo: right, I guess even having s.th. getting upgraded first (e.g. libc) pre-depend on the new apt wouldn't work, due to the circular nature
<mvo> mdke: I agree that this is not a ideal situation - but I can not see what we can do (except for backporting)  - the solution we have is the release-upgrader that does some additional checks and shouldn't get in the way of any admin in server mode
<mdke> mvo: yeah. The only thing we can do is try and get the message to as many people as possible that dist-upgrade won't work
<mvo> sistpoty: yeah, even if we could make it work somehow it would be rather messy
<sistpoty> that's true, and I guess it would open a can of worms trying to fix it
<mvo> mdke: we discussed issuing a update to dappers apt that will give a big warning on dist-upgrade (if any of the upgraded-to packages are hardy)
<mvo> sistpoty: *nod*
<mdke> mvo: sounds like a plan
<mvo> yeah
<mvo> mathiaz: please let me know how well the upgrade worked for you - in case of problems, please send me the logs in /var/log/dist-ugprade
<jdong> Is there any way in pbuilder to set make -j NUM_CPUs?
<persia> jdong: Add a hook that sets MAKEFLAGS before calling dpkg-buildpackage?
<jdong> persia: is that the proper way to do it (i.e. what the buildds would do)?
<persia> jdong: I'm not sure.  Maybe setting parallel=n in DEB_BUILD_OPTIONS?  From past traffic in debian-devel, it seems to generate more FTBFS issues.
#ubuntu-devel 2008-03-01
<jdong> persia: right, certainly blindly setting MAKEFLAGS=-j2 will cause FTBFS'es that wouldn't ordinarily happen in the buildds. I was wondering if there was a more intelligent flag for that
<jdong> I recall someone saying that the buildd's do intelligently use multiple cores
<jdong> s/cores/cpus/
<persia> Maybe by building multiple packages simultaneously in separate environments?
<persia> Some packages seem to try to calculate the number of cores in debian/rules build, and call make with -j.
<jdong> persia: alright, given that it doesn't seem like there's a clear-cut utopian answer, I'll stick with default build options and exercise patience :D
<persia> jdong: Look to the future.  There've been several threads on this in debian-devel, and I think support ought hit policy sometime in the 3.7.x series.  After that, it's just a matter of testing and adjusting all the source packages, and you'll have an answer :)
<jdong> persia: awesome. Just how again do we test packages for makefile race conditions? :D
<jdong> (very carefully)
<persia> jdong: Last test I saw was a complete archive rebuild of unstable with a build system that preferred parallel builds.  debian/rules seems to be a significant offender for issues running in parallel.
<jdong> persia: ah, not at all surprising... hence why I was worried about globally setting MAKEFLAGS
<persia> jdong: Check the debian ML archives.  I think Aurelien Jarno had something that parallelised everything except debian/rules at one point.
<jdong> persia: will do
<soren> bdmurray: Around?
<jdong> !ping
<ubotu> ping yourself ;-) really the diodes all down my left side are sore
<soren> slangasek: Still around? https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/196868 is still untouched, and I'm running out of kittens.
<ubotu> Launchpad bug 196868 in kvm "[ffe] Upgrade kvm from vers. 60 to 62" [Undecided,New]
<bdmurray> soren: am now
<soren> bdmurray: Whee.
<soren> bdmurray: I was about to look through the pile of hibernation related bugs to see if I might have fixed some of them by accident. Kees said that you might have all of them in your head, and that beats the crap out of Launchpad's search features.
<soren> bdmurray: So... Do you remember any bugs about machines seeming to hibernate properly, but failing to resume either always or just once in a while or something.
<soren> ?
<jdong> soren: I think that globs just about every suspend2disk failure case
<bdmurray> soren: gah, I feel like a failure since I don't have them all in my head
<soren> Er... Let me be a tiny bit more specific.
<soren> It hibernates properly, but when it's supposed to start resuming, it just boots as though you hadn't hibernated.
<soren> jdong: better? :)
<jdong> soren: much :D
<bdmurray> This doesn't have to do with the resume partition being wrong though?
<jdong> that certainly could cause those symptoms
<jdong> IIRC there were some uuids-dont-resolve kind of bugs that cause these symptoms
<bdmurray> right, but soren indicated he fixed *something*.  I was wondering what that something was.
<soren> Yeah. I just fixed one of those cases and instead of trawling through the boat load of bugs I just wanted to feed off of your brain.
<bdmurray> which case did you fix?
<soren> What I fixed was a race in the resume script in the initramfs that would check for the swap partition's existence just a tiny bit before it actually showed up.
<soren> Well.. "fixed" is a bit strong :)
<jdong> - sleep 2
<jdong> + sleep 10
<bdmurray> heh
<jdong> like that?
<soren> Almost, but not quite :)
<soren> It didn't use to sleep at all, so I added a loop that checks for 5 seconds and if it hasn't showed up by then, it bails.
<jdong> how does an every-5-second check not use sleep? :)
<jdong> but more seriously, is there some API call in the init script "library" that performs this kind of thing?
<jdong> it's useful in more than one place
<soren> Oh, it does use sleep. It's just not stupidly extending an already existing sleep. :)
<soren> There's not, but there should be.
<bdmurray> soren: bug 93039?
<ubotu> Launchpad bug 93039 in initramfs-tools "Regression: resume from disk (hibernate) fails sometimes" [Undecided,Confirmed] https://launchpad.net/bugs/93039
<soren> bdmurray: That's the one.
<soren> bdmurray: Awesome. Thanks.
<bdmurray> soren: no problem
 * superm1 wanders in and glares around at the present core-devs.  free kittens for someone who is willing to sponsor a small debdiff :)
<fabbione> soren: just look at how you wait for root :)
<fabbione> superm1: where is the debdiff?
<superm1> bug 187459
<ubotu> Launchpad bug 187459 in cdrkit "genisoimage creates bad iso images if joliet is used - error: "Unexpected joliet directory length" appears" [High,Confirmed] https://launchpad.net/bugs/187459
<fabbione> superm1: btw.. i am having issue with the latest mythtv dvd internal player. it can't play all dvd's while both xine and mplayer can do on the same
<soren> fabbione: Yeah, I got a bit of inspiration from that :)
<superm1> fabbione, you have a bug filed on it?
<fabbione> superm1: no, i noticed only about 8 hours ago.. before going to sleep
<superm1> ah
<fabbione> superm1: and i didn't track down the differences in the iso yet.. some play some don't
<fabbione> superm1: so a bug would be very much incomplete
<superm1> ah
<fabbione> oh boy.....
<fabbione> dpatch for a one liner?
<fabbione> no
<fabbione> that's just insane
<superm1> there would be an easier way?
<superm1> it will be dropped as soon as there is a new upstream version
<superm1> i figured this keeps it easy to merge with debian
<superm1> and just drop it when necessary
<fabbione> zcat cdrkit_1.1.6-1ubuntu5.diff.gz |lsdiff
<fabbione> it already shows modified files directly in the tree
<fabbione> so either you switch all the diffs to dpatch and do a clean jon
<fabbione> job
<fabbione> or just patch it and suck the diff in the diff.gz
<fabbione> 2 different patch systems at the same time are _BAD_
 * superm1 shrugs
<superm1> okay
 * superm1 doesn't like it when people don't change stuff outside debian/ with proper patch systems
<fabbione> i don't like when they are incosistent :)
<superm1> okay i'll just put it right in the .diff.gz then
<superm1> give me a sec
<superm1> fabbione, okay i updated that patch on the bug
<fabbione> better...
<fabbione> ok i will sponsor it, but you get to fix the crap if it breaks
<superm1> sounds fair :)
<fabbione> because i have never seen that error before
<superm1> it is fscking up our mythbuntu disks
<superm1> so that's the only reason the bug became so apparent
<fabbione> superm1: i guess you mean the disks created by mythubuntu disks.. it's not related to my problem tho..
<superm1> i mean our live cds.  they are not browseable on macs or windows, which with the next alpha we're doing - we're adding a nice little windows menu to install the "Mythtv player" for windows and a few little things
<fabbione> superm1: uploaded
<superm1> i'll keep an eye out for new bugs related to this bug though.  if something goes wrong i'll take care of it. Thanks fabbione :)
<fabbione> no problem
<slangasek> soren: mmh, sorry, I did get it taken care of while it was still today for /me/, I didn't expect you'd be up this late still looking for it
<Hobbsee> calc: ah
<Hobbsee> Keybuk: pumpernickle's proxy appaers to suck.
<Hobbsee> (it's happened before)
<superm1> slangasek, could you merge another branch related to our alternate cd building? http://bazaar.launchpad.net/~mythbuntu/debian-cd/mythbuntu-debiancd has the .pcx/.rle image files so we get the right artwork
<hunger_t> I can't update anymore since yesterday. What is wrong?
<superm1> slangasek, also added to there our first seeds that should hopefully pick the right tasks off the bat.
<Hobbsee> hunger: you broke it?
<Hobbsee> hunger: open office?
<hunger> Hobbsee: Nope, I get 404 errors when trying to download anything but the package lists.
<hunger> from http://archive.ubuntu.com/ that is.
<Hobbsee> ah
<crevette> hunger: yeah I had that since yesterday too
<crevette> s/had/have/
<hunger> From the apt-get output I gess that the filenames it is trying to download are missing .deb extension or something.
<hunger> "Err http://archive.ubuntu.com hardy/main update-manager 1:0.87.10\n  404 Not Found"
<superm1> hunger, happened to me too, but it was transient
<superm1> an apt-get update and then trying again appeared to fix it at least for me
<hunger> superm1: I had it a couple of times yesterday and am seeing it consistently the whole morning already.
<mdke> could someone paste me a copy of a default hardy sources.list (does it vary for the server edition?)
<Hobbsee> mdke: no
<Hobbsee> mdke: (surely, you should know better than to even ask such a thing.  next, you'll be asking what the repos for kubuntu are)
<mdke> Hobbsee: no to both questions? ;)
<Hobbsee> mdke: to the latter :)
<Hobbsee> mdke: http://ubuntuforums.org/archive/index.php/t-308907.html do?
<Hobbsee> then sed
<mdke> has the layout not changed since edgy?
<Hobbsee> hm, maybe.
 * Hobbsee doesn't remember
<mdke> I was wondering if universe/multiverse is on the same line as main/restricted or if the wording of the comments has changed, etc
<mdke> i'll download the source package
<mdke> damn, nothing very helpful there; it's created automatically
<mdke> which i suppose might mean it's different for a different edition :)
<hunger> Ah, now the download works once more.
<hunger> Well, mostly...
<Hobbsee> grumble.  why does hardy, a LTS release, *still* not pick up vertical scrolling for touchpads?
<Hobbsee> and i can't even figure which part in particular does that now
<lifeless> Hobbsee: works for me
<Hobbsee> lifeless: which model?
<Hobbsee> dear tracker, if i've told you to pause indexing, then why are you still doing it?
<Nafallo> Hobbsee: I think you want to talk to trackerd :-)
<lifeless> Hobbsee: kill trackerd kthxbye.
<lifeless> dell d430
<Hobbsee> yummy.  gnome-app-install curls up and dies if something else already has the apt lock
<Hobbsee> lifeless: yeah, well, i'm about to do that :)
<Hobbsee> lifeless: i was giong to see if it behaved *vaguely* well before doing so, though
<Hobbsee> Nafallo: yeah, something about kill and purge...
<Nafallo> :-)
<Hobbsee> lifeless: strange.
<Hobbsee> evand: can i lodge a complaint, please?
<Hobbsee> evand: there's absolutely no indication on the initial dialog on the cd that you can install ubuntu from the first option - it now appears that you can either a) play without touching anything permanently, or b) install ubuntu, but not both.
<Hobbsee> nice wallpaper.
<Le-Chuck_ITA> Hi there, what is the freeze for universe bug fixes?
<Le-Chuck_ITA> is that betafreeze?
<Hobbsee> Le-Chuck_ITA: same as main.
<Hobbsee> Le-Chuck_ITA: see the meeting minutes for the latest info
<Hobbsee> (which i need to update on teh wiki)
<Hobbsee> jdong: oh crackmaster, please get transmission done and uploaded.
<Le-Chuck_ITA> Hobbsee: same as main is betafreeze for bugfixes, right?
<Hobbsee> Le-Chuck_ITA: i think so
<Le-Chuck_ITA> Thanks. Any developer acquainted with xinput here?
<Le-Chuck_ITA> there are big troubles for tablets in hardy
<Le-Chuck_ITA> and I don't want to see it shipped as is :(
<Hobbsee> probably not on a weekend
<Le-Chuck_ITA> we are in the weekend already?
<Le-Chuck_ITA> :)
<Nafallo> Sat Mar  1 11:24:05 GMT 2008
<Le-Chuck_ITA> I will wait monday then
 * laga has spent one hour more than Nafallo in the weekend. yay.
<Nafallo> laga: GMT == UTC, go figure ;-)
<laga> :)
<Hobbsee> Amaranth: is https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/140913 fixed in hardy now?
<ubotu> Launchpad bug 140913 in compiz "session save/restore does not work" [High,Triaged]
<Hobbsee> jdong: xvidcap, ditto.
<Le-Chuck_ITA> I found that the most important bug related to wacom tablets has already been reported three days ago by Tom Jaeger, together with a fix (using GIT version of linux wacom). I can do nothing but alert developers here and on ubuntu bugs on Bug #195953, please take a look and prioritise if you think it's worth. Tablet support is slowly improving in linux and breaking driver support in a LTS would be a shame
<ubotu> Launchpad bug 195953 in wacom-tools "Tablet input resolution tied to display resolution" [Medium,Confirmed] https://launchpad.net/bugs/195953
<Le-Chuck_ITA> already done on ubuntu-bugs
<Le-Chuck_ITA> sorry for noise :)
<Hobbsee> Le-Chuck_ITA: can you milestone it please?
<Le-Chuck_ITA> Hobbsee: yes sure - a couple of months away from launchpad and I forgot completely how to work with bugs :)
<Hobbsee> hehe
<afflux> will that funny tracker thing be enabled per default to index *everything* I have on my disk in hardy?
<james_w> Hi all. Does anyone know what package provides the boot menu on the live cd?
<james_w> I think it may be a syslinux menu, but I can't find what configures syslinux.
<james_w> This is to find a package for bug 197214
<ubotu> Launchpad bug 197214 in ubiquity "Ubuntu installation menu bug" [Undecided,Incomplete] https://launchpad.net/bugs/197214
<james_w> or rather confirm the package.
<mastro> hi there.. i had an idea for improving the liveCD feature but i don't know some thing... my idea is this ( http://brainstorm.ubuntu.com/idea/2031/ ) it's simple: create a way to save session of a live cd and let you use the liveCD as if it's an installed Ubuntu... as i know the LiveCD work on a virtual filesystem loaded into RAM.. the idea should be to "expand" this filesystem to split this filesystem to be half o
<mastro> n RAM and half on some other support.. like if there's more ram... than to save new thing you can do a "binary diff" and tar it somewhere... when you load the liveCD again you need a way to load this binary diff and apply it... but i don't know where it should be loaded and how you can friendly let the user choose from which support to load it...
<persia> mastro: I remember reading something about someone having done something like that using a USB key.  You might want to try searching for such a project, and joining that team to seek implementation.
<mastro> persia, really? i search on google.. thanks
<james_w> It's wanted to have an easy way to save data on a USB stick or similar when using the live cd, but I don't know if it is planned to have full session save/restore.
<mastro> james_w, yep... i think it's not an easy task to achieve! But the main useful thing would be: "possibility to try restricted drivers like nvidia or ati drivers directly from liveCD"
<nosrednaekim> if this the correct line for dapper-proposed?
<nosrednaekim> deb http://us.archive.ubuntu.com/ubuntu/ dapper-proposed main
<james_w> mastro: isn't that already possible?
<james_w> nosrednaekim: I believe so. Does it not work?
<nosrednaekim> james_wÂ» doesn't seem to have the "upgrade-manager" package in it
<james_w> nosrednaekim: the package is called "update-manager"
<nosrednaekim> oo! :)
<nosrednaekim> I feel dumb now... thanks
<mastro> <james_w> mastro: isn't that already possible? Â«Â« i don't think so.. not easily
<mastro> it require to reboot
<james_w> ah, ok.
<soren> slangasek: Ah, ok. I didn't know your day extended all the way to midnight :) I'm in Boston, so I'm not on my usual hours.
<afflux> doko: could you please have a quick look at bug 197160? It's a crash in python-central 0.5.60ubuntu5 which was previously marked as fix released in bug 196335
<ubotu> Bug 197160 on http://launchpad.net/bugs/197160 is private
<ubotu> Bug 196335 on http://launchpad.net/bugs/196335 is private
<lifeless> thom: so what did you not like about the air?
<jdong> Hobbsee: *hugs* thanks! Now off to write another one for Nexuiz ;-)
<Nafallo> jdong: MIRs? ;-)
<jdong> Nafallo: ROFL no, though nexuiz-by-default would be quite interesting ;-)
<jdong> FFe
<Nafallo> :-)
<evand> Hobbsee, suggestions for an alternative menu item title are welcome.
<evand> I honestly don't recall what the current options are and I don't have vmware set up at the moment.
 * Keybuk tries a new trick
<Keybuk> change the test cases *before* changing the code
<ScottK> doko: I agree that the change I made for Bug #179668 is a work around.  I shifted the duplicates around and left Bug #138189 open to document that libythonize0 is dlopening libpython2.5.so and not .so.1.  So I'm going to put the one back to fix released since the underlying issue is documented in another bug.
<ubotu> Launchpad bug 179668 in pykdeextensions "User management in systemsettings cannot find libpython2.5.so" [High,Confirmed] https://launchpad.net/bugs/179668
<ubotu> Launchpad bug 138189 in pykdeextensions "application tries to dlopen /usr/lib/libpython2.5.so (only found in the -dev package) " [Medium,Confirmed] https://launchpad.net/bugs/138189
<doko> ScottK: ahh, ok
<superm1> ScottK, promoting those to recommends, they won't be coming by default though will they?  I thought there was a decision at UDS-Boston to automatically install recommends for hardy
<ScottK> superm1: Whether it does or not doesn't affect the right answer.  Last I noticed it's not implemented, but I may be wrong.  If it's recommeds, users can still remove it.
<ScottK> Gotta run.
<superm1> ok
<__Neo__> Hi, is there a variant of Ubuntu that uses official (or mirrors of) Debian repositories either stable or later?
<Nafallo> not that I know of.
<laga> __Neo__: i think that's called "debian"..
<__Neo__> DreamLinux does this for example
<CarlFK> heh
<__Neo__> Essentially real Debian testing with extra things added and customized for the Desktop user - whilst maintaining compatibility with the debian repository
<__Neo__> I presume the answers no then?
<Amaranth> __Neo__: The answer is no
<__Neo__> I'll go back to DreamLinux - thanks anyway
<pecisk_> hi people, question - do automatical daily live cd building system includes up-to-date translations from Launchpad, like debian-installer and it's help module?
<evand> stgraber, can you make evand a developer on brainstorm, so I can post developer comments?
<superm1> i've seen at least one spec on there that is already implemented in hardy too.  if the ability to nuke such things as "complete" is available, that should be done (i'm referring to the ability to cancel fsck on bootup)
<Keybuk> superm1: not to mention "Ubuntu should recognize hardware changes"
<superm1> yeah that too :)
<Keybuk> complete things shouldn't be nuked though
<Keybuk> they should be moved to a "ideas that we listened to" board
<Keybuk> like the one in TESCO
<superm1> yeah, well who admins the site?
<superm1> stgraber, ?
<Nafallo> superm1: I think so
<nand> evand: The role is not yet here, we will add it at the next update, probably monday.
<evand> nand, oh, I thought the developer comment section that's already up was the change.  Nevermind then.
<nand> a lot of changes are incoming :)
<vignatti> hi
<vignatti> who is the tool responsible for mount /proc on ubuntu?
<vignatti> I tried to comment fstab line to not mount this but it doesn't work
<crevette> vignatti: why don't you want /proc ?
<vignatti> crevette: just to kill an xserver bug. Some guy is trying to initialize Xorg without /proc and it's segfaulting
<vignatti> crevette: for sure Xorg must a least exist nicely :)
<vignatti> any hints?
<crevette> I don't how /proc is mounted
<crevette> umount /proc doesn't work I assume
<nand> crevette: it should
<vignatti> nop
<vignatti> it returns EBUSY
<geser> /etc/init.d/mountkernfs.sh mounts /proc
<vignatti> even if I pass --force
<nand> at least, I can mount/umount on a small chrooted system. If processes use files in /proc, it's another story...
<vignatti> geser: humm, interesting
 * vignatti booting
<vignatti> humm, just commenting out the line which mounts /proc in mountkernfs.sh didn't worked :(
<slangasek> superm1: hrm, this appears to require me figuring out how the debian-cd repo is configured
<superm1> slangasek, yeah evand wasn't sure either, so he said to talk to you :)
<slangasek> soren: ah yes, I forgot about the sprint, doh
<slangasek> ScottK: huh, didn't this pythonize issue come up before?
<ScottK> slangasek: It did.  You fixed it (work around) right before Gutsy release.
<ScottK> slangasek: Then mvo reverted your work around in December with no rationale documented.
<slangasek> ah
<ScottK> So I spent several hours last night beating my head against the wall trying to figure out the real fix, traced it (I think) to libtool and gave up and reuploaded the workaround.
<slangasek> heh
<ScottK> It had enough dupes that I really thought it ought not be left broken for Alpha 6.
 * slangasek nods
<slangasek> so 138189 is the bug designated for tracking getting libpythonize fixed to use the soname?
<ScottK> That's the idea.
<ScottK> It actually correctly describes that problem and not the impacts of it on other packages.
 * slangasek takes responsibility for that one
<slangasek> superm1: mythbuntu debian-cd changes merged
<superm1> slangasek, thanks.  hopefully tonight's build turns out more fruitful :)
<Keybuk> 17124 scott     18   0  522m  86m  17m S   11  4.3 139:56.82 deskbar-applet
<Keybuk> *sigh*
<ion_> Heh
<jwest--> hi
#ubuntu-devel 2008-03-02
<CarlFK> bug 197491 - if someone will tell me where /tmp/tmpC-FmTz/DistUpgradeViewText.py comes from, I'll apply my fix and test it
<ubotu> Launchpad bug 197491 in update-manager-core "do-release-upgrade gets 'stuck'" [Undecided,New] https://launchpad.net/bugs/197491
<calc> how do i generate a diff from two directories and have it not include the topmost directory in the path/filename
<ScottK> CarlFK: Isn't it in update-manager-core?
<calc> eg diff 1 2 generates a diff 2/a/b/c/filename but i want it to output a/b/c/filename instead
 * calc manually edited the diff but thinks there probably is some way to do it less ugly
<CarlFK> ScottK - doesn't look like it: juser@dhcp142:/usr/lib/python2.5/site-packages/UpdateManager/Core$ grep Details *.py
<CarlFK> (nothing)
<ScottK> CarlFK: http://packages.ubuntu.com/search?searchon=contents&keywords=DistUpgradeViewText.py&mode=exactfilename&suite=hardy&arch=any
<CarlFK> it lies
<CarlFK> $ ls /usr/lib/python2.4/site-packages/UpdateManager/Core/
<CarlFK> DistUpgradeFetcherCore.py  __init__.py  MetaRelease.py
<StevenK> It was downloaded in the hardy.tar.gz
<CarlFK> same for 2.5
<StevenK> When you told update-manager to upgrade to hardy
<ScottK> CarlFK: No Core in the path listed on puc, but what StevenK says is right.
<CarlFK> ok, i might be able to trap that and edit, but that sounds like more trouble than it is worth.
<ScottK> CarlFK: Actually you can download it, but I don't remember exactly where.
<ScottK> I know that's not much help.
<CarlFK> the problem/fix is pretty simple - not worth the trouble
<Hobbsee> evand: right, i'll think about that
<jdub> ArneGoetje: hi -- around?
<evand> thanks Hobbsee
<Hobbsee> evand: no problem
<warp10> Good morning
<Mithrandir> cjwatson: does ssh allow me to specify type of service on the command line?  If not, it'd be useful to have.
<Mithrandir> (I want to limit the bandwidth consumed by rsync-over-ssh across a host rather than just for a single process, so --bwlimit to rsync doesn't help)
<hikenboot_> anybody know where i can get the x-windows-system-dev package that is in debian or should i say the equivalent? Noone in #ubuntu seems to know
<james_w> hikenboot_: http://packages.debian.org/x-windows-system-dev doesn't think there is such a package.
<hikenboot_> hmm great a typo
<hikenboot_> good directions...thanks
<ionstorm> anyone notice there is no /lib/modules/2.6.24-11-generic/"build" in the latest kernel rls
<ionstorm> was it moved?
<arvind> any gnome developer here
<arvind> i cant see the shutdown manager
<jdong> arvind: I think that's a known bug
<jdong> if you're on hardy
<CarlFK> bah - I can't see my ide controller.
<pochu> doko: the patch from Debian bug #445729 wasn't applied completely (only the timestamp update, but not the fix). Could you fix it for the next upload in Debian?
<ubotu> Debian bug 445729 in libwxbase2.6-0 "libwxbase2.6-0: wx2.6 crashes with aMule" [Important,Fixed] http://bugs.debian.org/445729
<doko> pochu: could you write a bug report for debian? it's unlikely that I will upload again
<pochu> doko: can I reopen it?
<doko> pochu: sure, but better fix it =)
<pochu> doko: well I don't have access to the $VCS where wxwidgets is so I can't fix it ;) but it's just a one-line-fix, so shouldn't be a big deal for the maintainer ;)
<doko> pochu: me neither
<pochu> doko: bug reopened.
<jdong> I'm no e2fsprogs expert (I know little about it in fact)... but the latest changelogs all look pretty compelling
<jdong> should we refresh e2fsprogs before release or is that risky?
<MrKeuner> hi, are there ubuntu mobile capable phones already?
<CarlFK> hardy alt installer - shouldn't IDE support be in initrd.gz?  (so that it can find the CD for instance)
<CarlFK> in the last few days, it went away from where ever it was, and so now it doesnt see any ide devices: http://dev.personnelware.com/carl/temp/Mar02/g/dhcp63/dmesg.txt
<laga> hi. is there any documentation on seeds available? eg file format, what keywords are available etc
<TheMuso> laga: Have you read https://wiki.ubuntu.com/SeedManagement?
<laga> TheMuso: yes. it explains everything but the file format
<laga> (or how to actually use seeds ;))
<TheMuso> laga: The best thing I can suggest, is to download a bzr branch of seeds, and have a look at it, then if you have any questions, ask them.
<laga> ok, i've got a branch and i#ve looked around a bit. now i wonder if i can basically inherit from one seed while excluding some packages?
<TheMuso> Well you may already be aware that all seeds inherrit from the platform.hardy seeds, that is if you are looking at seeds for hardy.
<TheMuso> laga: The STRUCTURE file basicallyd escribes how things all fit together, and what seeds go where.
<laga> TheMuso: and how'd i exclude a package? just add "! package" ?
<TheMuso> laga: I believe so, however I am no expert with seeds. I only know enough to do the work on them that I need to do.
<laga> TheMuso: OK, i've found the include statement in the structure file. it looks like one set of seeds completely inherits from platform.hardy. do you know how i can make a ship-diskless seed which is basically like ship-live but doesn't include some packages?
<TheMuso> laga: Not really no.
<laga> TheMuso: ok, thanks for your help! i'll experiment a bit
<TheMuso> laga: No problem./
<superm1> laga, i want to say you will be able to just make a ship-net in STRUCTURE that lists ship-live (in STRUCTURE)
<superm1> and then the Exclude:
<superm1> in the contents of ship-net
<laga> superm1: yeah, i'm doing something like that.. with deskto, tho
<laga> ship-live doesn't make much sense there
<superm1> yeah
<laga> superm1: in the desktop seed: why does it list mythbuntu-desktop as useful package? i thought the desktop seed was used to generate the mythbuntu-desktop package?
<superm1> that was modeled after some other seed that did similar
<superm1> so i dont know
<laga> ok
<laga> http://phpfi.com/300137 <- superm1, does this look OK?
<superm1> laga, first off that looks like you didn't update, but merged....
<superm1> but if that syntax is right for the seed itself, i think its right
<TheMuso> superm1, laga, that is done because the seeds are used to generate tasks, and the tasks have to pull the metapackage as well. So yes, leave it there.
<laga> one of these days i'll understand bzr
<superm1> laga, pull/update rather than merge if we are all working on the same branch
<superm1> if its a different branch, then you branch/merge
<laga> i just updated
<laga> superm1: ok, i'll commit and test the meta package
<laga> "pending merge"? oh noes :/
<superm1> laga, okay best of luck :)
<TheMuso> c/
<TheMuso> gah
<laga> yay, i broke it :)
<TheMuso> superm1: uploaded.
<superm1> thanks
<TheMuso> np
<emgent> heya
<emgent> please consider malone #197077 for upload in hardy
<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> (only for core-dev)
<emgent> debdiff attached
#ubuntu-devel 2009-02-23
<DBO> does anyone know when a good time to catch macslow might be?
<directhex> when he's awake & on irc. that's a good start
<DBO> thanks
<beuno> DBO, he's in germany
<DBO> mmmm, probably sleeping...
<beuno> so mon-fri 9-17hs UTC aprox
<RAOF> asac: I've just run across bug #331849; you were the last commenter on it.  It's the reason people are still hitting bug #331311.  Basically, notify-osd should be installing those icons in the hicolor theme, rather than them being shipped in Human.
<ubottu> Launchpad bug 331849 in notify-osd "Notify-osd icons should be installed for hicolor" [Undecided,New] https://launchpad.net/bugs/331849
<ubottu> Launchpad bug 331311 in gnome-settings-daemon "volume notifications are all black" [High,Fix released] https://launchpad.net/bugs/331311
<abc2xyz> how to join the team?
<RAOF> What team?
<abc2xyz> i mean the developers
<RAOF> By doing packaging work.
<RAOF> !motu
<ubottu> motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
<RAOF> Is what you want to see.
<RAOF> Also...
<RAOF> !gettingstarted
<ubottu> A great place to start your MOTU adventure is https://wiki.ubuntu.com/MOTU/GettingStarted
<abc2xyz> thanks :D
<dholbach> good morning
<pitti> Good morning
<pitti> calc: 332578> good idea, will look at it
<directhex> morning pitti
<pitti> slangasek: could you please ack/nack bug 326989 ?
<ubottu> Launchpad bug 326989 in libopenobex "FFE: Please update to 1.5 in Jaunty" [High,In progress] https://launchpad.net/bugs/326989
<pitti> kirkland: oh, I just saw screen-profiles the first time, nice! however, is it really intended to always show that menu when you run "screen"?
<pitti> kirkland: I'd expect it to come up only the first time
<pitti> kirkland: also, F3/F4 don't work for me, do they for you?
<pitti> kirkland: nicely done!
<Koon> pitti: last time I checked, the menu came only once and F3/F4 were working properly
<pitti> kirkland, Koon: hm, I have
<pitti> -rw-r--r-- 1 martin martin 0 2009-02-23 09:18 .screenrc
<pitti> maybe it isn't supposed to be empty? I'm fairly sure it only got created this morning
<pitti> yes, confirmed, it's not in yesterday evening's backup
<Koon> pitti: ah, *that* menu
<Koon> pitti: it's a new one, and I agree it's a little painful
<Koon> pitti: F3/F4 work here though, once you created a new tab with F2
<pitti> Koon: hm, I only tried it under X, and still doesn't work for me
<Koon> pitti: the 0-sized .screenrc is apparently normal
<ara> pitti, kirkland: I experience the same. https://bugs.launchpad.net/ubuntu/+source/screen-profiles/+bug/333180
<ubottu> Ubuntu bug 333180 in screen-profiles "screen-profiles menu appears always I run screen" [Undecided,New]
<slangasek> didrocks: you uploaded a totem that build-depends on a gtk-doc-tools newer than what's in the archive; any plans to upload that too?
<didrocks> slangasek: I requested a sync request and FFe
<didrocks> let me find it
<didrocks> slangasek: bug #331201
<ubottu> Launchpad bug 331201 in gtk-doc "Please sync gtk-doc 1.11-3 (main) from debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/331201
<slangasek> didrocks: ah didn't notice that you needed sponsorship, ok
<slangasek> thanks, I'll have a look at that
 * slangasek reads the very bottom of the bug description and coughs, realizing he should have already known about this ;)
<didrocks> slangasek: thanks a lot :)
<didrocks> slangasek: yeah, I am just a MOTU, not a core-dev :)
<ara> kirkland: another one on screen-profiles: https://bugs.launchpad.net/ubuntu/+source/screen-profiles/+bug/333180
<ubottu> Ubuntu bug 333180 in screen-profiles "screen-profiles menu appears always I run screen" [Undecided,New]
<ara> kirkland: I meant https://bugs.launchpad.net/ubuntu/+source/screen-profiles/+bug/333189
<ubottu> Ubuntu bug 333189 in screen-profiles "Selecting the plain profile might confuse the user when trying to change the configuration" [Undecided,New]
<slangasek> a|wen: why is kile building a -dbg package in Ubuntu?  Is this a change pulled from the Debian svn tree?
<a|wen> slangasek: we've upgraded to an svn snapshot of the kde4 version ... so right now we are ahead of debian in that sense
<slangasek> a|wen: so why are we building a -dbg package?
<a|wen> slangasek: for the same reason we are building kde*-dbg packages... is there any good reason not to build it?
<slangasek> a|wen: because it should be redundant relative to our automatically-generated -dbgsym packages
<slangasek> a|wen: which are stored in a dedicated archive, where they don't take up space on the mirrors
<slangasek> a|wen: -dbg packages are tolerable as a lesser evil when they're synced from Debian; but I don't see any reason we should be creating new ones in Ubuntu
<slangasek> so I'm inclined to reject these packages out of binary NEW
<a|wen> slangasek: i see; as it is a kde4 app, i was mostly just looking at how the other kde4 applications was made
<a|wen> slangasek: i think the package is already in the archive (the 0ubuntu1 version is there)
<slangasek> the binaries aren't
<slangasek> can you upload a -0ubuntu3 version dropping the -dbg package?
<a|wen> slangasek: yeah, no problem
<slangasek> ok, thanks :)
<a|wen> i can't upload myself, but maybe you'll be keen on the debdiff?
<slangasek> a|wen: sure
<a|wen> slangasek: http://awen.dk/packages/kile/kile_2.1~svn20090217-0ubuntu3.debdiff
<slangasek> a|wen: <yoink> :)
<slangasek> a|wen: uploaded, thanks!
<a|wen> slangasek: no problem; thx for spotting it and correcting me
<geser> Keybuk: I'm here if you need me for some udev testing/debugging
 * Ng is curious if there are any arguments against bug #157345 - and more importantly, who would be worth advocating it to
<ubottu> Launchpad bug 157345 in cupsys ""show printers shared by other systems" should be on by default" [Medium,Triaged] https://launchpad.net/bugs/157345
<dholbach> Ng: tkamppeter?
<Ng> dholbach: yeah I added a comment last night asking if he had any objections. It seems like it probably ought to have some input from team securitah
<dholbach> maybe pitti knows about it too?
<pitti> Ng: in fact I'd like to do that as well, but IMHO bug 314408 should be solved first
<ubottu> Launchpad bug 314408 in qt4-x11 "Please separate autodetected from locally configured printers" [Wishlist,Triaged] https://launchpad.net/bugs/314408
<pitti> Ng: this would then comply to https://wiki.ubuntu.com/DefaultNetworkServices
<Ng> that is exactly the kind of argument I was looking for :)
<pitti> Ng: there's no principal blocker, other than finding the time to do it for GTK and Qt
<Ng> pitti: I'll add appropriate commentary, thanks :)
<didrocks> slangasek: thanks
<pitti> Ng: cool, Qt upstream scheduled fixing for 4.6.0
<Ng> pitti: given that we're post-FF, assuming a patch existed, would this be likely to make it for jaunty?
<pitti> Ng: the gtk/qt patches fall under UIF
<pitti> Ng: but the cups change itself is FF, of course; it'll probably be accepted if it lands by UIF, but not later
<Ng> hmm, just over a week
<bigon> http://launchpadlibrarian.net/22770218/buildlog_ubuntu-jaunty-i386.openerp-server_5.0.0-3-1_FAILEDTOBUILD.txt.gz << does anybody know where this FTBFS comes from?
<Hobbsee> pitti: darn.  why does that immutable page have to have a typo on it?
<cjwatson> DefaultNetworkServices? doesn't seem immutable - are you logged in/
<cjwatson> ?
<Hobbsee> er, apparently not
<Hobbsee> hrm.  perhaps it isn't a typo either, but something i've never heard of
<slangasek> bigon: appears to be an objection from pkgstriptranslations?
<cjwatson> if you mean "DCHP", I've just corrected that
<Hobbsee> cjwatson: yeah, that's hte one ;)
<slangasek> bigon: which is pkgbinarymangler
<cjwatson> pitti: perhaps at some point you could propose a diff to ubuntu-policy encompassing that specification?
<pitti> cjwatson: added to my todo list
<cjwatson> no rush, thanks
<Silicium> hi there
<Silicium> i have created a bootsplash with gimp, 16 indexed colors, and compiled into a shared object, but it wouldnt be loaded, the bootscreen is just black with a blinking cursor while booting...
<pitti> Keybuk: wrt. https://bugs.edge.launchpad.net/ubuntu/+source/elisa/+bug/315704/comments/23, I tend to agree (both that it's better suited in universe, support-wise, and that the user experience would be better); do you still remember why you wanted it in main in the first place?
<ubottu> Ubuntu bug 315704 in elisa-plugins-ugly "FFe and merge for Elisa 0.5.28-1 / sync request for elisa-plugins-{good,bad,ugly} 0.5.28-1 from Debian experimental" [Wishlist,Confirmed]
<seb128> pitti: ask lool I think that was a mobile thing?
<seb128> pitti: lool has been working on it previous cycle for sure
<pitti> seb128: request came from Keybuk, lool helped a lot to implement it, though
<seb128> ok
<seb128> ignore me I was just mentionning it in case that was useful ;-)
<pitti> seb128: merci
<seb128> pitti: de rien ;-)
<ogra> cjwatson, partman complains, but you can go on iirc
<ogra> which means you die with oom on the slug
<cjwatson> ogra: sure, I regard that as the user's fault :)
<ogra> ok
<cjwatson> it warned you; if you ignore it you get to keep both pieces
 * ogra will do so too then, i'll m,ake sure its in the docs
<ogra> -,
<ogra> Keybuk, any idea about the weird behavior udev shows on my slug install ? http://paste.ubuntu.com/121199/
<ogra> Keybuk, the uuid's that end up in /target/etc/fstab dont match anything in the system until i call udevadm trigger which then changes the complete set of uuids for the target partitions
<ogra> beyond that the first uuid in the mkinitramfs error doesnt exist at all
<Knives> join #ubuntu-offtopic
<cjwatson> Keybuk: davmor2 has a problem with a fresh LVM installation that I speculate might be bug 332270. What's the easiest way for him to confirm that it's the same bug?
<ubottu> Launchpad bug 332270 in udev "udev repeatedly generates "change" events for the same block device(s)" [High,Triaged] https://launchpad.net/bugs/332270
<davmor2> cjwatson, Keybuk: Does this only effect certain disks or does it only effect certain type of partitioning?  Also removing quite and splash from the kernel line might give me more info wouldn't it?
<Keybuk> davmor2: absolutely no idea
<Keybuk> I still can't replicate it
<Keybuk> pitti: -mobile wanted it in main
<pitti> Keybuk: ah, thanks
<pitti> lool: does that still hold? (elisa in main for mobile)
<davmor2> Keybuk: I got it doing a LVM install test that I used the new d-i lvm resize feature on, at 20% of a 250gig hd
<Keybuk> davmor2: got what?
<davmor2> Keybuk: bug 332270 if it is that bug
<ubottu> Launchpad bug 332270 in udev "udev repeatedly generates "change" events for the same block device(s)" [High,Triaged] https://launchpad.net/bugs/332270
<Keybuk> davmor2: no, I mean what _happened_ when you got to 20%?
<davmor2> Keybuk: no I used the resize feature and set it to use 20% of my 250g hd
<Keybuk> and then what happened?
<cjwatson> it's not *re*size, BTW, it's setting the initial size
<davmor2> cjwatson: sorry :)
<davmor2> Keybuk: it wouldn't reboot
<Keybuk> davmor2: why not?
<Keybuk> did you see an error message?
<Keybuk> were there messages on another console?
<davmor2> Keybuk: two ticks I'm just removing quite and usplash from kernel line as it doesn't provide me with any other consoles
<geser> davmor2: which architecture are you using? i386 or amd64 or something else?
<davmor2> Keybuk: Disk activity is constant it seems to of detected most of my hardware and now lists /sys/devices/pci0000:00/0000:00:1f.2/host2/target2:0:0/2:0:0:0/block/sda  new line /sys/devices/pci0000:00/0000:00:1f.2/host2/target2:0:0/2:0:0:0/block/sda/sda1 and repeats
<wgrant> That's the one.
<Keybuk> davmor2: great!
<davmor2> geser: I386
<Keybuk> can you explain the steps you went through to do this?
<Keybuk> I'll try and replicate in vmware
<davmor2> Keybuk: i386 alternat install.  Select guided - lvm whole drive for partitioning.  hit enter on the next screen and then on the next screen change -12-1 to 20% and hit enter complete the install
<Keybuk> err, can you explain the -12-1 to 20% thing?
<Keybuk> pretend that I've never seen the alternate installer before
<Keybuk> was the disk blank when you did this?
<Keybuk> or was there an existing operating system there?
<Keybuk> did you remove the existing operating system?
<Keybuk> or did you select resize?
<cjwatson> Keybuk: I can help here
<davmor2> Keybuk: http://testcases.qa.ubuntu.com/Install/AlternateLvm after the guided - use entire disk and set up LVM you now get the option to not use the entire disk for more flexibility (new feature)
<cjwatson> Keybuk: the installer recently gained a feature whereby, if you choose guided LVM partitioning (i.e. erase whole disk, stick LVM on it), then rather than just munching the entire volume group for logical volumes, it asks you how much of the volume group you want to use
<davmor2> I told it to use 20% of the 250GB drive rather than -12-1 (the whole drive)
<cjwatson> Keybuk: the structure of the resulting volume group should be the same
<Keybuk> ok, so whole-disk LVM
<Keybuk> no MD?
<cjwatson> davmor2: "-12-1"? that makes no sense to me
<Keybuk> no encryption?
<cjwatson> davmor2: is that literally what you saw?
<davmor2> cjwatson: I think that is what it said I can re-run it to check for you
<davmor2> it was something weird like that
<cjwatson> davmor2: if you do see that, it's a bug, and I'd like syslog and partman; it should be more like "250 GB"
<davmor2> Keybuk: no not encrypted
<cjwatson> it could be some kind of overflow bug
<davmor2> I think I got the logs from installer hang on
<cjwatson> hmm, the partman test suite probably ought to test some bigger numbers
<cjwatson> though it does test 4.3GB
<cjwatson> $ longint2human 2500000000000
<cjwatson> 2.5 TB
<cjwatson> *seems* fine ...
<cjwatson> my only guess is that vgs is outputting garbage
<cjwatson> davmor2: I'd like the output of 'vgs -o vg_free --units K --noheading --nosuffix'
 * Keybuk sees "8.3 GB"
<Keybuk> I selected 50%
<Keybuk> now it's installing the base system
<davmor2> cjwatson: logs for partman and syslog should be http://www.davmor2.co.uk/syslog http://www.davmor2.co.uk/partman
<Keybuk> davmor2: are you doing this in vmware or on a real machine?
<davmor2> Keybuk: really hw
<davmor2> real even
<Keybuk> are you able to do it again?
<davmor2> Keybuk: Restarting now
<Keybuk> davmor2: when partman is up, can you switch to Alt+F2
<Keybuk> then run
<Keybuk> # killall udevd
<Keybuk> # udevd --debug --resolve-names=never > /var/log/udev 2>&1
<Keybuk> then continue with your test
<Keybuk> if it hangs, let it for 15-30 seconds or so
<Keybuk> then ^C udev
<Keybuk> and give me that log file ;)
<davmor2> cjwatson: from where would you like the vgs -o .... line typing ?
<davmor2> Keybuk: problem kicks in upon restart the install works fine
<ogra> Keybuk, ny< idea for my uuid prob ?
<ogra> *any
<Keybuk> davmor2: oh, you're saying that the install worked fine before?
<Keybuk> ogra: what uuid problem?
<Keybuk> ogra: I can suggest some cream?
<ogra> Keybuk, http://paste.ubuntu.com/121199/
<ogra> cream is always good
<davmor2> Keybuk: yes it's at the end of the install it reboots only then nothing happens
<Keybuk> ogra: *shrug* your UUIDs in your fstab are wrong
<Keybuk> davmor2: this is what happened last time too?
<Keybuk> davmor2: the install absolutely definitely worked, and it was after the reboot you had the problem?
<ogra> Keybuk, so you say thats a d-i failure ? even if the uuids change to the proper ones after running udevadm trigger manually ?
<Keybuk> ogra: I'm not saying anything
<davmor2> Keybuk: yeap the install log is the one I posted for cjwatson
<Keybuk> I'm just saying that all your pastebin shows is that your fstab is clearly wrong
<ogra> i would expect them to be exactly whats in fstab on forst boot
<ogra> *first
<Keybuk> davmor2: ok, interesting
<Keybuk> davmor2: so you can boot that system now, and it hangs on boot?
<ogra> Keybuk, well, the fstab matches what i see after the uuids change when i call udevadm trigger, my question rather would be why are they different at all ?
<Keybuk> ogra: no idea, why is the sky blue?
<davmor2> Keybuk: grub works then detect hw works then you get the never ending stream of /sys/devices
<Keybuk> ogra: please find out :)
<IntuitiveNipple> Keybuk: Would it help if you can watch it happening?
<Keybuk> davmor2: ok
<Keybuk> davmor2: could you boot, get to grub, replace "splash" with "init=/bin/bash"
<Keybuk> and then run the following
<Keybuk> mount -o rw,remount /
<ogra> Keybuk, because the pink paint was out
<Keybuk> edit /etc/init.d/udev
<Keybuk> actually
<Keybuk> rewind that
<davmor2> Keybuk: hang on mid install to confirm I can reproduce it
<Keybuk> just boot with init=/bin/bash
<Keybuk> and see if you get to a root prompt first
<Keybuk> IntuitiveNipple: unless you have a serial console, I'm not sure how you could set that up ;)
<IntuitiveNipple> Keybuk: I do, and I can give you shared SSH/screen access to view as it happens
<Keybuk> IntuitiveNipple: that would be helpful
<cjwatson> davmor2: tty2
<davmor2> cjwatson: there isn't one on the installed system
<cjwatson> davmor2: no, I mean during install, at the point where it gives you the LVM size prompt
<davmor2> cjwatson: np's
<cjwatson> although there most certainly is a tty2 on the installed system :-0
<IntuitiveNipple> Keybuk: OK. I'll set it up. Just so you know what you'll be seeing: It's a lab PC with a clean install on Sunday. I've just downgraded udev/dmsetup to the pre-issue versions so it is possible to get control.
<cjwatson> :-)
<Keybuk> IntuitiveNipple: I assume it's ok for me to upgrade them again while the system is running?
 * cjwatson peers at davmor2's syslog
<cjwatson> Feb 23 10:09:31 main-menu[1756]: (process:11141): .
<cjwatson> Feb 23 10:09:31 main-menu[1756]: (process:11141): TB
<cjwatson> that's ... odd
<IntuitiveNipple> Keybuk: Yes, it's a lab PC. I downgraded it specifically so we can see the initial reaction. You can also kick into the initrd by using kernel command-line "break" to stop before premount kicks off
<davmor2> cjwatson: by the way I think it is wrong to now call guided - use entire disk and setup lvm if you can set it to not use the entire disk :)
<Keybuk> IntuitiveNipple: and how do I install a package? ;o)
<IntuitiveNipple> They are in the /root/ directory of the installation, for use with dpkg. I'll show you once you're attached
<cjwatson> davmor2: maybe, though I'm reluctant to change the translated string
<cjwatson> davmor2: it does use the entire disk in the sense that it erases everything there before and puts an LVM volume group over the entire disk
<cjwatson> davmor2: one thing that may address your problem is that I've changed the text in the size question to talk about the amount of the volume group you want to allocate, rather than the amount of disk
<davmor2> cjwatson: Right still listed as -12-1 and vgs line reads 159782010.88
<IntuitiveNipple> Keybuk: OK... this will get you onto my laptop, from where you can attach to the screen multiuser session where the serial console is running: ssh -p 2222 remoteop@alexandros.tjworld.net
<IntuitiveNipple> Keybuk: The remoteop password is: letmein
<IntuitiveNipple> Keybuk: Once logged in, attach to my screen session using: screen -x tj/Multiuser
 * davmor2 right Keybuk s line next
<cjwatson> (you realise this is a publicly logged channel?)
<IntuitiveNipple> cjwatson: I should hope so :)
<Keybuk> weird, X-Chat just decided to crash there
<IntuitiveNipple> Keybuk: Did you miss my connection instructions?
<Keybuk> I've connected, and I can see the root@jaunty:~# prompt
<Keybuk> this is the lab machine?
<geser> Keybuk: I can confirm the last comment on that udev bug: when I disable one core, restart udev then the udevadm trigger doesn't cause any loop
<IntuitiveNipple> Keybuk: That is the console to the lab machine... I'll send some commands
<davmor2> cjwatson: was that directed at me?
<cjwatson> davmor2: no, IntuitiveNipple (which I can only assume is intended to mean "completely unintuitive" ...)
<IntuitiveNipple> Keybuk: You have control... snoop around... do you want to see it reboot with 137-1 so when we install 138-1 you can see the difference?
<Keybuk> no, I know what a booting Ubuntu machine looks like ;)P
<IntuitiveNipple>  :)
<IntuitiveNipple> Do you want to update dmsetup?
<cjwatson> davmor2: hmm, when you have a chance, it would be good if you could run through the installer, stop at the hostname prompt, 'nano /bin/perform_recipe_by_lvm' and stick 'set -x' at the top - then I need the resulting syslog after the rest of the installation
<cjwatson> davmor2: sorry, I know each iteration takes a while
<Keybuk> IntuitiveNipple: no, just going to take this one step at a time
<davmor2> cjwatson: np's it's better to get it fixed now :)
<IntuitiveNipple> Keybuk: ok... just there was a package dependency issue
<cjwatson> davmor2: there's clearly an arithmetic bug somewhere but I can't reproduce it at an ordinary shell
 * Keybuk hates screen
<Keybuk> it's like it *tries* to get being a terminal completely wrong
<Keybuk> on purpose
<Keybuk> IntuitiveNipple: no swap? on purpose?
<IntuitiveNipple> Keybuk: correct
<Keybuk> what's /dev/sda2 and /dev/sda4 ?
<IntuitiveNipple> Keybuk: sda2 is formatted for swap but not in fstab
<Keybuk> sda2 is not properly formatted for swap ;)
<Keybuk> someone didn't use parted for it
<IntuitiveNipple> sda3 is /   sda4 is the demo LVM area, but nothing in it gets mounted.
<highvoltage> ogra: I'm surprised that not more people agree with you on the long-term-reminder thing
<Keybuk> "demo LVM area" ?
<IntuitiveNipple> Keybuk: I had to build it using deboostrap - Sunday's live-CD ubiquity failed on starting
<ogra> highvoltage, well, cjwatson's mail showed me that i probably didnt formulate it right
<IntuitiveNipple> Keybuk: demo as in, it's not used but is 'there' to demo the bug.
<ogra> so people might not have understodd what i meant
<Keybuk> IntuitiveNipple: if you don't have that, do you not see the bug?
<cjwatson> yes, ubiquity has a missing dependency at the moment (which probably needs to be fixed by removing the dependency, otherwise I'd have fixed it already)
<cjwatson> Keybuk: how does sda2 manage to be improperly formatted for swap?
<IntuitiveNipple> Keybuk: I'm not sure tbh... don't think I did that test. I know without the lvm2 package installed the bug doesn't show, but thats different. Do you want to delete sda4 ?
<Keybuk> cjwatson: not wiped first, so looks like it has swap and ext3 metadata
<Keybuk> IntuitiveNipple: can we rewind this conversation please
<IntuitiveNipple> Keybuk: sure
<Keybuk> IntuitiveNipple: your system is not set up "normally"
<Keybuk> how you've set this up could be VERY important
<cjwatson> does parted actually get that right, I wonder?
<Keybuk> so, please explain your system's setup - and why it is the way it is
<Keybuk> cjwatson: yes
<cjwatson> note also that d-i sometimes falls back from libparted to mkswap when formatting swap partitions
<cjwatson> ah yes, libparted memsets the header
<IntuitiveNipple> Keybuk: It had to created using deboostrap, since Ubiquity failed. So, from the live-CD I fdisk-ed the 4 primary partitions and set their types, then used mkfs.ext3 /dev/sda1 and /dev/sda3, mkswap /dev/sda2, and pvcreate/lvcreate for sda4
<Keybuk> so what is sda4 for?
<Keybuk> why did you do that?
<IntuitiveNipple> Keybuk: Then used debootstrap to install Ubuntu into it
<IntuitiveNipple> Keybuk: sda4 was there to test that LVM would trigger the bug
<Keybuk> ok
<cjwatson> as, I think, does busybox mkswap (not explicitly but effectively)
<Keybuk> so sda4 is an LVM with a bunch of logical volumes in it
<Keybuk> do you mount those volumes?
<cjwatson> util-linux mkswap also does a memset, so if ext3 metadata is left around, it must be outside the swap header region?
<IntuitiveNipple> Keybuk: No. I was about to create an alternative boot option using them a few minutes ago (which is why it is mounted on /target/) but its totally unused
<Keybuk> no you don't mount those volumes?
<Keybuk> or no I'm wrong?
<IntuitiveNipple> Keybuk: It's a sacrificial system set up just for testing this bug scenario
<IntuitiveNipple> Keybuk: nothing in LVM is mounted
<IntuitiveNipple> (unless I am playing about)
<Keybuk> cjwatson: we should start a campaign to import "doch" into the English language
<cjwatson> absolutely
<cjwatson> very annoying omission from English
<Keybuk> lrwxrwxrwx 1 root root 10 Feb 23 11:54 0c3390a5-9d90-460d-bc8d-10ff5d02a6f4 -> ../../dm-0
<Keybuk> that's odd
<IntuitiveNipple> Keybuk: The disk is 'thrashing' at this point
<Keybuk> well, that definitely loops ;)
<IntuitiveNipple> That's the same as happens at boot-time in initrd as soon as udev starts
<IntuitiveNipple> and it never seems to stop... at least after leaving it 15 minutes it hasn't
 * Keybuk hates screen
<IntuitiveNipple> Well, while you hate it, I'll go grab a cuppa
<geser> IntuitiveNipple: how many cpus/cores does this lab PC has?
<Keybuk> single
<Keybuk> IntuitiveNipple: this computer has no internet access?
 * Keybuk needs to get that log file off
<IntuitiveNipple> There you go
<IntuitiveNipple> Remember I've also attached some full debug LOG_DEBUG logs to the bug report
<Keybuk> yeah, but you cut the important bit off ;)
<IntuitiveNipple> The gzip logs are the full capture from start... nothing was edited
<davmor2> Keybuk: init=/bin/bash doesn't work :(
<davmor2> cjwatson, Keybuk: I can confirm though that it is reproducible
<Keybuk> davmor2: good to know, thanks
<IntuitiveNipple> davmor2: No, it won't, since the issue starts in initrd... you need to do "rdinit=/bin/busybox" or just add "break" to stop initrd at the premount point
<cjwatson> rdinit?
<cjwatson> <cjwatson@sarantium ~>$ wcgrep rdinit /usr/share/initramfs-tools/
<cjwatson> <cjwatson@sarantium ~>$
<Keybuk> cjwatson: which init inside the initramfs to run
<cjwatson> besides surely /bin/busybox will just print a message about how you should have nominated an applet to run
<Keybuk> break=top would have been just as good
<cjwatson> invoking /bin/sh would be more normal
<IntuitiveNipple> cjwatson: sorry, yes, I was thinking and typing at the same time... always a dangerous thing to do (sh is provided by busybox was in my mind)
<davmor2> cjwatson, Keybuk: I'm off for lunch in a second so cjwatson I'll try your other request when I get back.  Keybuk is there anything else you'd like me to try?
<Keybuk> not at this time
<Keybuk> IntuitiveNipple's machine is proving a useful study so far
<davmor2> Cool :)
<IntuitiveNipple> First time it's been useful in 5 years :)
<IntuitiveNipple> It's damned noisy! How do fans get noisy when they're never used!?
<Keybuk> ok
<Keybuk> so in your case, it's lvm
<Keybuk> lvm scans all the drives
<Keybuk> and that is causing inotify events on them
<Keybuk> quite why lvm is opening them writable is anyone's guess ;)
<IntuitiveNipple> Keybuk: I did wonder, with the vscan && vgchange
<IntuitiveNipple> s/vscan/vgscan/
<IntuitiveNipple> The timing issue is interesting too... as I said before. With debug logging there seems to be sufficient delay between actions to avoid the inotify trigger
<Keybuk> sure
<Keybuk> lvm vgscan beats inotify watch
<Keybuk> it's only the inotify watch on the block device that has the LVM PV that really matters
<Keybuk> see
<Keybuk> making it not watch the LVM PV fixes the problem ;)
<Keybuk> IntuitiveNipple: I think I broke it - it's not responding?
<IntuitiveNipple> let me check
<IntuitiveNipple> I think you did :)
<IntuitiveNipple> No response on the physical console
<IntuitiveNipple> I'll try to force a restart
<IntuitiveNipple> Booting with "break" to stop at pre-mount else we'll be stuffed
<Keybuk> no we won't
<IntuitiveNipple> Yes were are... disk is thrashing madly
<IntuitiveNipple> s/were/we/
<Keybuk> ah, it's thrashing inside the initramfs
<IntuitiveNipple> I must hav mistyped the kernel command line
<Keybuk> ok, can you reboot it again ;)
<IntuitiveNipple> Yes, as always
<IntuitiveNipple> This break-top
 * IntuitiveNipple bites fingers
<IntuitiveNipple> This *is* break=top
<Keybuk> thrashing again or not?
<IntuitiveNipple> OK you broke it again :)...I have noticed that when the udev issue occurs, the next warm-boot locks the PC at this point. I'll have to do a cold restart
<IntuitiveNipple> No, it's froze up... give me amo
<lool> pitti: No, we didn't really use elisa in main after all; I was interested in doing the work back then because there was a chance of including it in the seeds and it was used by OEM
<lool> pitti: Nowadays, I think it's a blocker to have elisa* in main; so please demote if you feel like it
<Keybuk> weird
<Keybuk> grr, busybox sed is weird
<Keybuk> IntuitiveNipple: what have you set the usual ^A to on this?
<IntuitiveNipple> I've not changed anything; it's the default settings.
<IntuitiveNipple> I think you want Ctrl+]
<pitti> lool: ok, thanks
<slangasek> pitti: libsmbios-bin is NBS in favor of smbios-utils; and it looks like some of the command names have also moved around - do you know which commands hal wants from this package?
<pitti> slangasek: I know at least dellWirelessCtl, let me check for the others
<slangasek> ok; dellWirelessCtl is still present
<IntuitiveNipple> Keybuk: I have to shut everything down. Got an appointment with the electric company - they are here to replace the meter so everything has to go off for about 20 minutes.
<Keybuk> ok, np
<slangasek> pitti: oh hmm, superm1 has already committed the change to bzr, just not uploaded yet :)
<pitti> slangasek: can do
<pitti> slangasek: confirmed that it's just dellWirelessCtl
<Keybuk> isn't smbios-utils all written in Python?
<pitti> yes, that sucks, performance-wise
<Keybuk> indeed
<Keybuk> I'd like to object on boot performance grounds
<Keybuk> this change shouldn't go ahead
<slangasek> oh, there's a change of implementation language here?
<pitti> C++ -> Python
<slangasek> meh
<kirkland> mvo: hi, i see that bug 319438 has a fix committed, any idea when it'll release?
<ubottu> Launchpad bug 319438 in update-notifier "update /var/run/updates-available immediately following an apt-get upgrade" [Medium,Fix committed] https://launchpad.net/bugs/319438
<slangasek> Keybuk: the libsmbios-bin binary has already been dropped from the package; if we're trying to avoid the change in implementation language, it needs to be resuscitated since it's in NBS right now
<Keybuk> slangasek: indeed, I would recommend reverting to the previous version of the package
<Keybuk> changing things run on boot to be written in a large, expensive language like Python just is *not* on my list of things I like to see
<Keybuk> now, I realise I can't actually enforce that
<Keybuk> but I can make nice puppy eyes ;)
 * pitti melts
<slangasek> heh
<slangasek> Keybuk: well, I have no objections to a revert; perhaps you want to discuss it with superm1 and come to a consensus?
<Keybuk> indeed
<pitti> great
 * pitti has no objection to a 2.2.13+really2.0.3.dfsg-0ubuntu1
<pitti> we can probably get away with that for jaunty, but long-term upstream should do that as well
<Keybuk> "do that" ?
<pitti> Keybuk: I doubt it's actually that difficult; old libsmbios was C++ lib/binaries; new libsmbios is C library, python bindings, and python scripts
<pitti> Keybuk: do that> provide compiled binaries
<Keybuk> it's only the bits run on boot I care about
<pitti> we only care about dellWirelessCtl
<Keybuk> right
<pitti> and in fact, hal-system-killswitch-set-power-linux only calls it in three different methods
<slangasek> methods that are called at boot time?
<superm1> Keybuk, pitti: I can speak with mebrown about writing a C binary to be used in place of the python smbios-wireless-ctl soon
<superm1> it shouldn't actually be too difficult
<pitti> my preferred option would be to just rewrite that hal addon in C and use libsmbios directly
<pitti> it's some work, though
<pitti> slangasek: yes, they are
<superm1> yeah I would agree that's the right long term strategy at least
<pitti> superm1: directly using libsmbios2 from hal, you mean?
<superm1> pitti, yeah that's what I think should be done
<superm1> that's one of the reasons it was rewritten in C, so it could be lightweight for other apps to use
<asac> what do i need to run in postinst if i install a udev rule?
<Keybuk> nothing
<asac> cool ;)
<Keybuk> your udev rule will be used next time the device is plugged in
<asac> thats perfect
<Keybuk> what's the rule?
<asac> Keybuk: the udev-extras modem prober was internalized by NM
<asac> so we dont need the rest of experimental stuff
<Keybuk> ah, interesting
<asac> debian/tmp/lib/udev/rules.d/77-nm-probe-modem-capabilities.rules
<asac> debian/tmp/lib/udev/nm-modem-probe
<asac> Keybuk: ^^
<slangasek> doko: heh, seen bug #332978?
<ubottu> Launchpad bug 332978 in ubiquity "missing dependency on python-numpy" [High,Triaged] https://launchpad.net/bugs/332978
<pitti> asac: modem-prober> rock!
<doko> slangasek: ugh ... does ubiquity really need to use numpy? ok, no wonder that I didn't find that, not having ubiquity installed by default
<slangasek> doko: no idea if it does or doesn't - just saw the bug pop up on the blocker list for alpha-5 and thought you might want to have a look
<doko> looking
<cjwatson> doko: it shouldn't, I mentioned the same to evand earlier today
<cjwatson> numpy seems like total overkill there
<cjwatson> i.e. I didn't just commit a change to add the dependency because I reckoned the code ought to be changed
<evand> indeed, working on it
<doko> yep, 20 elements arry
<directhex> are we headed towards another alpha?
<james_w> directhex: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-February/000534.html
<james_w> "Our next testing milestone, Jaunty Alpha 5, is scheduled for next
<james_w> Thursday, February 26.  Jaunty Alpha 5 will again use a "soft freeze" for
<james_w> main[2].  This means that developers are asked to refrain from uploading
<james_w> packages between Tuesday and Thursday which don't bring us closer to
<james_w> releasing the alpha"
<directhex> right. slangasek how do you feel about a bodge job on gmime, to eliminate all the mono 1.0 stuff from the cd (pending the gmime 2.4 stuff meebey spoke with you about)?
<slangasek> directhex: uh... I already did that? :)
<directhex> did you? oops ^_^
<meebey> slangasek: apropros, gmime2.2 is now in pkg-gnome
<slangasek> meebey: alrighty
<directhex> slangasek, neat! so mono 1.0 classlib stuff is now gone from the cd?
<slangasek> directhex: yep
<seb128> slangasek: btw how many language packs did you manage to add with the recent changes?
<directhex> slangasek, excellent! any early indications on space savings?
<meebey> slangasek: when I got some spare time I will migrate gmime2.2 to mono 2.0 and start packaging gmime2.4 as extra source package
<directhex> meebey, grab slangasek's 2.0'd 2.2 from patches.ubuntu.com?
<slangasek> seb128: 10 on i386 alternate, 6 on amd64 alternate, 7 on i386 desktop, 5 on amd64 desktop
<slangasek> (incl. en)
<seb128> slangasek: excellent ;-)
<meebey> directhex: if merging would be simple with sucky svn ;)
<slangasek> directhex: well, we were at the point where corlib and i18n were the only bits left, so... that's how much we saved. :)
<meebey> directhex: I will take a look though, but its will be probably just build-deps + configure params
<meebey> slangasek: btw tomboy includes tons of translated images (pretty stupid)
<meebey> slangasek: wondering what the ubuntu policy is on translations
<meebey> if they should be split etc
<slangasek> seb128: I guess we can squeeze one more on alternate i386, too; I'm confused by what I've been seeing in terms of alternate CD sizes, the CD size fluctuations as I add/remove don't seem to match the output of the langpacksize script for some reason
<meebey> slangasek: 5.7M    /usr/share/gnome/help/tomboy
<slangasek> meebey: ideally they would be split, but AFAIK we don't have good general infrastructure for splitting documentation currently
<meebey> slangasek: you can make libmono0 optionally, I found out why its pulled in
<directhex> meebey, yeah, was about to talk about monoposixhelper
<meebey> slangasek: the compression streaming api uses it
<slangasek> evolution just had its docs split which was a big savings, but I think that required a bit of manual effort
<meebey> oh true, there are 2 libs in it
<meebey> and the other one is really needed IIRC
<IntuitiveNipple> Keybuk: How are you getting on?
<Keybuk> IntuitiveNipple: about 2/3rds the way through my sandwich
<IntuitiveNipple> I'm trying to make the new meter go backwards
<IntuitiveNipple> System's back online if you need it
<davmor2> cjwatson: back do you still need this doing ?  'nano /bin/perform_recipe_by_lvm' and stick 'set -x'  and does go below the #!/bin/bash line doesn't it?
<cjwatson> what #!/bin/bash line? :-)
<cjwatson> it's /bin/sh - but yes
<cjwatson> put it on the second line of the script
<davmor2> cjwatson: yes sorry :)
<ara> kirkland: ping
<Keybuk> hah
<seb128> slangasek: are you doing source new today? I've been pinged about reviewing gwibber but I don't want to work conflict with you
<Keybuk> so the reason I couldn't replicate the bug in VMware is annoyingly simple
<slangasek> seb128: I'm unlikely to get all the way through the NEW queue, feel free to take it
<seb128> slangasek: ok
<directhex> Keybuk, how's your DH7 wrangling? trying to get the gdb addin for monodevelop ship-shape, but hitting a wall
<Keybuk> DH7?
<directhex> debhelper 7, minimal rules format specifically
<Keybuk> never used it
<directhex> hm. the quest goes on, then
<geser> Keybuk: so you finally managed to reproduce that udev problem?
<Keybuk> geser: not completely
<Keybuk> I know _what's_ causing it
<Keybuk> what I can't work out is why it only happens for certain people
<maco> the lvm one?
<Keybuk> right
<maco> its not hitting all lvm users?
<Keybuk> no
<davmor2> cjwatson: logs http://www.davmor2.co.uk/partman1 http://www.davmor2.co.uk/syslog1
<Keybuk> and I _think_ it's just limited to lvm too
<Keybuk> mdadm looks sane
<munckfish> asac: if you've got a sec I'd like to quickly discuss LP #289982, I've had a breakthrough with it, but discovered another issue - wireless only works when the ethernet cable is unplugged :)
<ubottu> Launchpad bug 289982 in ubuntu-ps3-port "PS3: NetworkManager cannot connect to WPA/WPA2 wireless networks" [High,In progress] https://launchpad.net/bugs/289982
<geser> Keybuk: is it a bug in udev or lvm and udev simply triggered it?
<Keybuk> geser: arguably a bug inside lvm
<ccm> hey, is there a known bug in qt for Jaunty that prevents all qt applications to display correctly?
<Keybuk> made worse by lvm not being designed to work with udev
<ccm> i checked launchpad but don't know where exactly to look
<Keybuk> basically each time we find an lvm device, we have to tell lvm to scan for new physical volumes and activate any volume groups found there
<Keybuk> to scan for physical volumes, lvm opens every single block device to take a peek
<Keybuk> the bug is that it opens them O_RDWR instead of O_RDONLY
<Keybuk> meaning that when it closes them, you get an IN_CLOSE_WRITE event
<Keybuk> which is what udev reacts to
<Keybuk> as a change to the underlying block device
<Keybuk> so it rechecks the block device
<Keybuk> and because lvm doesn't quite support udev
<Keybuk> it has to run lvm scan again
<Keybuk> which reopens the block device O_RDWR, ...
<cjwatson> davmor2: thanks, reproduced - could you file a bug on partman-auto-lvm with a skeleton description of what happened and I'll get it fixed? I don't need the logs any more
<davmor2> Keybuk, cjwatson: out of interest would it be worth me run a standard lvm using the whole disk rather than part and see if it is still an issue?
<Keybuk> davmor2: it will be an issue if you have any LVM anywhere
<Keybuk> even if you're not mounting it
<cjwatson> busybox printf is interestingly broken
<cjwatson> $ busybox printf "%i%s%i %s\n" . 2 TB >/dev/null
<cjwatson> .TB
<cjwatson> (yes, it has the wrong number of arguments, which is the real bug here
<cjwatson> )
<davmor2> ah okay
<Keybuk> cjwatson: err, how is that broken?
<Keybuk> . isn't an integer
<cjwatson> $ printf "%i%s%i %s\n" . 2 TB
<cjwatson> -bash: printf: .: invalid number
<cjwatson> -bash: printf: TB: invalid number
<cjwatson> 020
<cjwatson> is slightly more reasonable behaviour than outputting random inscrutable junk to stderr
<Keybuk> cjwatson: telling me what bash does doesn't mean busybox sh is broken :)
<asac> munckfish: which NM version?
<Keybuk> and busybox sh is sufficiently minimal that reasonable behaviour isn't necessarily expected
<cjwatson> Keybuk: I wasn't arguing that the arguments being passed to printf here were correct - they're clearly wrong
<Keybuk> cjwatson: does busybox set the exit code
<cjwatson> to 0
<munckfish> asac: 0.7.1~rc1-0ubuntu2
<munckfish> asac: Jaunty
<pitti> tjaalton: out of interest, what does 102_dont_vblank.patch in mesa do?
<munckfish> asac: Thing is wlan0 and eth0 both have the same MAC address on PS3, I wonder if that's causing the problem
<cjwatson> Keybuk: maybe "broken" was a bit strong, but it certainly failed to provide any assistance in debugging until I saw the set -x trace :-)
<maco> ccm: might be better in #kubuntu-devel
<munckfish> asac: does NM try to bring up both when a user logs in?
<cjwatson> although the exit code is clearly wrong
<ccm> maco: okay. actually i am using ubuntu, but i will investigate further, thank you
<Keybuk>     *
<Keybuk> If an argument operand cannot be completely converted into an internal value appropriate to the corresponding conversion specification, a diagnostic message shall be written to standard error and the utility shall not exit with a zero exit status, but shall continue processing any remaining operands and shall write the value accumulated at the time the error was detected to standard output.
<Keybuk> sounds "broken" to me
<tjaalton> pitti: disables vblank again, to work around bug 320813
<ubottu> Launchpad bug 320813 in xserver-xorg-video-intel "[drm] compiz animations cause temporary freezes with vblank" [Unknown,Confirmed] https://launchpad.net/bugs/320813
<Keybuk> POSIX says it must output diagnostics and exit non-zero
<cjwatson> I would argue that simply printing the argument does not really qualify as a diagnostic message, too :-)
<maco> ccm: the kubuntu folks will know qt though
<pitti> tjaalton: ah, thanks
<Keybuk> interestingly
<Keybuk> $ printf "%i%s%i\n" . 2 TB
<Keybuk> printf: 1: .: expected numeric value
<Keybuk> printf: 1: TB: expected numeric value
<Keybuk> 020
<Keybuk> (dash)
<asac> munckfish: trying WPA enterprise?
<pitti> Keybuk: how is '.' a number?
<Keybuk> pitti: that's the point
<davmor2> cjwatson: bug 333349
<ubottu> Launchpad bug 333349 in partman-auto-lvm "Jaunty: 20090223 partman-auto-lvm has an issue with displaying correct size" [Undecided,New] https://launchpad.net/bugs/333349
<ion_> zsh: bad floating point constant
<ion_> 020
<pitti> Keybuk: ah, nevermind, just saw scrollback
<Keybuk> we don't need a comparison of how shells handle this ;)
<Keybuk> the only reason dash was relevant is that busybox's sh is theoretically dash
<cjwatson> ish
<cjwatson> I would not generally make that comparison because it's too confusing
<cjwatson> davmor2: thanks
<ion_> dashish sounds like something youâd smoke.
<asac> munckfish: i mean the issue is that pkcs11 doesnt work. thought that is only used for enterprise. maybe consider to start with a new connection?
<cjwatson> the real cause of the bug was that I'd misremembered how shell variable assignment deals with leading whitespace
<cjwatson> I thought it was stripped when you did foo=$(bar), but it isn't
<davmor2> Keybuk, cjwatson: Is there anything else you need before I move onto testing something else
<Keybuk> no
<cjwatson> davmor2: not from me, thanks
<davmor2> np's
<munckfish> asac: well the original issue was it couldn't connect to any type of WPA network. I've now proved it will connect to my WPA Personal network here at home, but like I said, only when the ethernet cable is unplugged and eth0 cannot be brought up.
<munckfish> asac: Now I know that the eth and wlan interfaces use the same MAC address on PS3, now if they are meant to be brought up exclusively then that could be why this is happening
<asac> munckfish: definitly. can you please paste the output of lshal ?
<munckfish> asac: when it fails the wireless driver in the kernel fails to associate and just times out.
<munckfish> asac: ok 1 sec
<asac> munckfish: http://paste.ubuntu.com/121904/
<asac> thats really looks like both devices are treated as the same on your system
<asac> most likely driver issue
<asac> (copy paste?)
<munckfish> asac: exactly. lshal output http://paste.ubuntu.com/121905/
<munckfish> asac: also relevant is the "Wireless" section of this description of the Linux kernel on PS3:
<munckfish> asac: http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-linux-docs/ps3-linux-docs-08.06.09/LinuxKernelOverview.html
<davmor2> Keybuk: Out of curiosity is the issue link to bug 332270 or is it something different?  Need to log it
<ubottu> Launchpad bug 332270 in udev "udev repeatedly generates "change" events for the same block device(s)" [High,Triaged] https://launchpad.net/bugs/332270
<Keybuk> "the issue" ?
<davmor2> lvm issue
<Keybuk> that is the lvm issue bug, yes
<asac> munckfish: are both both drivers in mainline kernel tree?
<davmor2> Keybuk: Thanks
<asac> munckfish: seems its the same driver actually ;)
<munckfish> asac: yes, drivers/net/ps3_gelic_*
<asac> munckfish: what time in the daemon.log do you plug in the wired?
<munckfish> asac: my understanding/knowledge is very sketchy here, but looking at that article I linked to above
<munckfish> asac: it sort of implies that both should be able to run concurrently but using some sort of vlan control to direct packets ??? not sure how that affects things
<munckfish> asac: I'm afraid that log is out of date, and only documents the issue when the cable is connected and NM is trying to connect to my wifi network
<cjwatson> Keybuk: I think POSIX's text could be read either way regarding the intended exit code, actually
<asac> munckfish: can you caputure a fresh log just with the "connect wired" ?
<cjwatson> Keybuk: you could read it as meaning that it shouldn't exit immediately, but should continue with the rest of the arguments
<Keybuk> cjwatson: but it still shall not exit with a zero status
<Keybuk> oh, I see what you mean
<munckfish> asac: I've recompiled the kernel this morning with all the debug prints enabled in the gelic driver. I can get a copy of that log for you.
<Keybuk> you can read "shall not exit (with a zero status) and may instead continue with arguments (and then exit however it wants)"
<IntuitiveNipple> Keybuk: We're got someone who has no LVM or RAID on the PC, but is using LUKS encryption on multiple file-systems.
<cjwatson> yeah. I don't *think* this is the intended reading, but it's not entirely unambiguous
<Keybuk> I think that reading it that way would be simply attempting to justify a stupid behaviour
<cjwatson> you're probably right
<cjwatson> it's certainly less helpful to exit zero
<Keybuk> IntuitiveNipple: then at this point I assume they have a different bug
<IntuitiveNipple> Keybuk: They have the 65-dmsetup.rule - taking the "watch" out of that and 60-persistent-storage fixes it
<Adri2000> Keybuk: hi. did you file a rt ticket for mod_python support on casey?
<Keybuk> IntuitiveNipple: the bug you have is very specific to LVM
<Keybuk> Adri2000: weeks ago
<Adri2000> ok
<zul> slangasek: ping can you have a look at 330626 when you get a chance?
<IntuitiveNipple> Keybuk: 65-dmsetup.rule runs "/sbin/dmsetup export"
<Keybuk> IntuitiveNipple: so?
<IntuitiveNipple> Keybuk: So, it looks like that triggers the issue the same way lvm vgscan does
<Keybuk> dmsetup only looks at /dev/mapper/control
<Keybuk> strace it if you don't believe me ;)
<IntuitiveNipple> Keybuk: The reporter is MichaelEvans, comment #9 and many others in the bug report.
<slangasek> zul: looks to me like that should be referred upstream
<Keybuk> https://bugs.edge.launchpad.net/ubuntu/+source/udev/+bug/332270/comments/29
<Keybuk> My setup:
<zul> slangasek: yeah I have done that im just trying to get more debugging information and kind of busy with other things
<ubottu> Ubuntu bug 332270 in udev "udev repeatedly generates "change" events for the same block device(s)" [High,Triaged]
<Keybuk>  ...
<Keybuk> An LVM partition
<Keybuk> --
<Keybuk> Michael Evans has LVM
<maco> are "Unknown media type in type 'all/all'" (various other mimes as well) messages when dpkg installs various packages something to ignore or something about which to file bugs?
<rgreening> ArneGoetje: ping
<IntuitiveNipple> Keybuk: Yes, thanks for that. I'm querying that with him now since he had just said there's no LVM on the PC he's testing now
<IntuitiveNipple> Keybuk: OK, he's trying to confuse me... he *does* use LVM :)
<maco> haha
<Keybuk> it won't matter whether or not it's mounted or used
<rgreening> ArneGoetje: I have a question about the language-support-translations-en package and a hard dep for evolution-documentation-en. COuld this be changed/updated to be a suggests or can we make it nicer for Kubuntu by making it an '|' with an equivalent Kde package.
<Keybuk> just as long as the PV is there
<ArneGoetje> rgreening: does it hurt on Kubuntu?
<rgreening> space on the disk for one is very limited ArneGoetje
<IntuitiveNipple> Keybuk: question: when the 60- rule activates does it setup the watch before the 85-lvm2 rule is processed?
<rgreening> and I dont think it will fit. plus we use Kontack and not thinderbird ArneGoetje
<rgreening> Kontact I mean.
<alex-weej> xev doesn't list any key event when using the eject key on computer_model could anybody help me to debug this?
<rgreening> so, logically, it should be either a suggests or and "or" with equivalent KDE package ArneGoetje
<alex-weej> macbook pro 3.1
<rgreening> s/and/an
<seb128> pitti, bryce, slangasek: is there a documented procedure to debug such issues nowadays?
<rgreening> ArneGoetje: the hard dep pulls in 38 new packages, 13 meg
<maco> alex-weej: did you check the hotkey wiki page? if it doesn't show anything in input_events either, might need a kernel quirk for it. you're talking about a keyboard-type eject button right, not the thing on the tray?
<seb128> ie multimedia keys not triggering an xevent
<rgreening> all of which are Ubuntu specific and not Kubuntu related.
<maco> seb128: pgraner told me to check the dsdt to try to figure out my keys
<alex-weej> maco: yes, keyboard.
<slangasek> seb128: https://wiki.ubuntu.com/Hotkeys/Troubleshooting
<seb128> alex-weej: ^
<alex-weej> ok thanks
<maco> seb128: ive got 2 keys which don't make it through what's on the page slangasek linked. near the end of the page it says if all else fails, kernel quirk. pitti and pgraner agreed.
<slangasek> rgreening: it definitely shouldn't be a suggests.  If it needs to be an 'or', then so be it
<cjwatson> rgreening,ArneGoetje: perhaps evolution-documentation-en should Depends: yelp | language-support-translations-en
<cjwatson> that's what the OOo translation packages do; it's ugly but we have no particularly good solution here in the dependency system :-(
<cjwatson> that would make the overhead a mere 200KB
<rgreening> sounds good, as long as we aren't required to pull in all these extra bits unnecessarily.
<ArneGoetje> cjwatson: +1
<rgreening> still not sure why we need evolution docs in kubuntu
<rgreening> :)
<slangasek> cjwatson: I thought evolution-documentation-en is one of the packages they want to avoid pulling in along with language-support-translations-en, so this would be inverted?
<rgreening> ya
<cjwatson> slangasek: on its own, though, it's pretty tiny
<cjwatson> I think it's the size impact of its dependencies that is the bulk of the practical problem
<slangasek> ok
<cjwatson> cf. openoffice.org-help-en-gb Depends: openoffice.org-writer | language-support-translations-en
<cjwatson> rgreening: you don't, it's just that we have no way at the moment to say "install language support packages of type 'translations' *that apply to Kubuntu*"
<seb128> what is the issue you try to solve?
<slangasek> seb128: kubuntu wants language-support-translations-en, just like ubuntu, but doesn't want GNOME deps pulled in with it
<cjwatson> seb128: dependency explosion on Kubuntu CDs due to dependencies language-support-translations-en -> evolution-documentation-en -> yelp
<seb128> oh
<cjwatson> seb128: and language-support-translations-en at the moment (perhaps unfortunately) has to account for both desktops
<rgreening> cjwatson:, ArneGoetje: http://paste.ubuntu.com:80/121915/
<rgreening> thats the list of new packages...
<cjwatson> seb128: the standard solution to this, as deployed in the last eight Ubuntu releases, has been to have the dependencies of language-support-* use "| language-support-foo" where appropriate
<seb128> can't language-support- have that | directly?
<rgreening> I liike having a lang pack for -kde
<cjwatson> seb128: consider the semantics of language-support-translations-en Depends: foo | language-support-translations-en ;-)
<seb128> what is wrong is to install evolution-documentation-en there
<cjwatson> seb128: true, but on its own evolution-documentation-en is a fraction of the size
<seb128> well the | choice being a kubuntu package
<cjwatson> seb128: I'm all for designing a better system, but in the meantime I would recommend deploying the existing solution to this until we figure out something better that provably works
<seb128> ie  language-support-translations-en Depends "evolution-documentation-en | kubuntu-something"
<rgreening> seb128: the ways its packaged, see the paste above. 38 packages get pulled in unecessarily.
<seb128> rgreening: I understand the issue
<cjwatson> rgreening: thanks, we understand the problem
<rgreening> :)
<rgreening> Anything you can do to assist, would be awesome
<cjwatson> seb128: I think the problem there is that we don't have an obvious candidate for the kubuntu-something - kubuntu-desktop is removable in ways that still leave you with something that's basically Kubuntu, much like ubuntu-desktop is
<seb128> alright
<rgreening> kde/kubuntu uses kontack for its groupware client, so I suggest a "|" on kontact docs.
<rgreening> or something like that
<seb128> cjwatson: I'm fine with your yelp | ... suggestion feel free to do an upload to change that if you want
<seb128> we should really split those by flavor at some point though
<rgreening> thanks for your help :)
<ArneGoetje> seb128: register a blueprint for karmic :)
<seb128> ArneGoetje: I don't think I care enough for that ;-)
<ArneGoetje> seb128: :P
<cjwatson> seb128: will do when I've finished caning my computer with upgrades ...
<cjwatson> thanks
<cjwatson> rgreening: is there a bug number for this?
<rgreening> cjwatson: nope, I just noticed it and thought I come ask about it
<rgreening> :)
<cjwatson> rgreening: could you please file one so that we have an audit trail of why we did this when we come back to figure it out later?
<cjwatson> rgreening: just a paste of the IRC log is fine if you want
<rgreening> cjwatson: sure. do you want a tag added to the bug report (if so what?)
<cjwatson> no, I don't care
<rgreening> kk.
<rgreening> 1 min
<rgreening> cjwatson:  bug 333401
<ubottu> Launchpad bug 333401 in language-support-translations-en "language-support-translations-* installs evolution-documentation-* and should not be required." [Undecided,New] https://launchpad.net/bugs/333401
<cjwatson> thanks
<cjwatson> sigh, I meant a bug on evolution about evolution-documentation-*'s heavy dependencies though. I'll reassign
<Keybuk> a lot of the commenters seem to be of the impression that inotify is somehow recursive up
<Keybuk> which is ironic, since it's not even recursive between directories ;)
<IntuitiveNipple> Keybuk: I've found a solution. Will attach a patch to the bug-report in a moment.
<pecisk> pitti: updated patch for lastest sl-modem package version on Jaunty, also attached my working init.d script fully, if patch doesn't work out again
<Keybuk> IntuitiveNipple: "a solution" ?
<IntuitiveNipple> Keybuk: Yes. Instead of setting OPTION+="watch" in any script, I've done ENV{inotify}="watch".
<IntuitiveNipple> Keybuk: Then I have a 99-inotify.rules that matches that and adds the OPTION after all rules have been processed
<Keybuk> I have a patch to udev to do the same thing
<Keybuk> it's not the complete fix though
<Keybuk> since if you ran "udevadm trigger" at any point, it would all kick off
<pitti> pecisk: thanks
<Keybuk> IntuitiveNipple: http://people.ubuntu.com/~scott/udev.inotify.patch  posted on Sunday
<IntuitiveNipple> Keybuk: I'm trying with trigger - it won't provoke the bug
<Keybuk> IntuitiveNipple: it will, because the watch already exists
<Keybuk> so lvm vgscan will trigger the change event
<IntuitiveNipple> Testing on the lab PC I can't get the bug to show issuing a trigger or vgscan
<Keybuk> right
<Keybuk> that's because you've now entered the strange situation I have
<Keybuk> where I just can't replicate the bug
<Keybuk> despite all the conditions being true
<Keybuk> and this seems to be linked to the observance that adding/removing udev_log changes the outcome
<Keybuk> as well as adding/removing cores
<Keybuk> OOI, could you test the patch and see if it has the same effect as your rules change
<asac> stgraber: pastebinit manpage doesnt really say where and in which format a user can set defaults.
<asac> stgraber: also in jaunty it doesnt use paste.ubuntu.com by default anymore. is that intentional?
<Keybuk> I can see lvm vgscan opening the block devices O_RDWR
<Keybuk> and closing them again
<Keybuk> but no inotify event is firing in udev
<Keybuk> which is a bit odd
<IntuitiveNipple> Keybuk: I have a build of the package with that patch included from yesterday; let me find where I put it
<munckfish> asac: sorry I took so long. I have a log now that documents the problem. I closed the original WPA related bug as I'm fairly certain that's solved. Have attached to bug 309457
<ubottu> Launchpad bug 309457 in ubuntu-ps3-port "[ps3_gelic] [2.6.28-rc8] Networkmanager does not autoconnect/connect on first try to wireless" [Undecided,New] https://launchpad.net/bugs/309457
<asac> munckfish: ok. there is no successful association in it
<asac> but thats ok i guess
<munckfish> asac: what do you mean?
<munckfish> asac: I can get a log with the successful association too
<asac> munckfish: no all fian ;)
<asac> did you say in the bug that it works with wired unplugged?
<kirkland> does anyone know if apport in Jaunty works through proxies?
<munckfish> asac: ok. Yes that's right. I unplugged the eth cable. Rebooted to follow the same sequence of steps, and as soon as I hit the desktop the wifi connection was up just fine.
<asac> munckfish: did you say so in the bug too (that was my question)?
<asac> otherwise please add that info
<munckfish> asac: I think I forgot, I'll add an extra note
<asac> munckfish: thanks. i am in a meeting now (~30 minutes)
<munckfish> asac: ok thx for your time, I've added extra notes now. Let me know if you have any thoughts on it. Cheers
<Keybuk> IntuitiveNipple: any luck?
<IntuitiveNipple> Had to rebuild the package, just done, and moving it to the lab PC
<doko> Riddell: please have a look at bug 304622
<ubottu> Launchpad bug 304622 in mudlet "Please update qscintilla2 package to fix crashing" [Critical,Fix released] https://launchpad.net/bugs/304622
<Riddell> looking
<Riddell> doko: hum, it says "Error: Unable to find either PyQt v3 or v4." during configure
<Riddell> doko: hmm, python2.6 can't import PyQt4.pyqtconfig
<Riddell> dunno why, I have /usr/lib/python2.6/dist-packages/PyQt4/pyqtconfig.py
<doko> Riddell: the error message is in the python2.5 build
<IntuitiveNipple> Keybuk: Just tested the patch on a clean source of 138-1 and it appears to have solved the issue.
<Riddell> doko: not for me it isn't
<doko> Riddell: my python2.6 changes are at http://people.ubuntu.com/~doko/tmp/q.diff  could you recheck with these?
<doko> Riddell: I tried on i386, if that makes a difference
<Riddell> doko: I'm missing /usr/lib/python2.6/dist-packages/PyQt4/__init__.py
<doko> looking ...
<geser> IntuitiveNipple: that patch http://people.ubuntu.com/~scott/udev.inotify.patch ? I tried it but it didn't solve the issue for me (but I can retest just to be sure)
<IntuitiveNipple> Do you want the binaries to save time?
<IntuitiveNipple> geser: http://tjworld.net/ubuntu/bugs/lp332270/
<geser> IntuitiveNipple: I've debs, just want to double check that I'm testing the right patch
<IntuitiveNipple> Keybuk: MichaelEvans is testing the binary patch with encrypted and he stills suffers the thrashing disk, although the root got opened/mounted without early incident. With the 99-inotify.rules version, his PC started without any issues
<Keybuk> IntuitiveNipple: your claims make no sense ;)
<Keybuk> the patch does what you're _trying_ to do with the ENV stuff
<Keybuk> except what you're trying to do with the ENV stuff doesn't make any difference
<IntuitiveNipple> Makes a lot of difference. With the 99-inotify.rules and changes to 60-pers... and 65-dmsetup, the systems start okay
<kozz> just a stupid question about the new dialog in transmission when a torrent is completed, what is the "cancel" button supposed to do?
<kozz> I didn't want to test right now :) but just realized that is seemed strange now when I say it
<Keybuk> IntuitiveNipple: then there must be a bug in your rules
<Keybuk> because moving the OPTIONS to 99 or to 01 won't make a blind bit of difference ;)
<IntuitiveNipple> well, it has on two separate systems with reinstalled 138-1 and dmsetup's 65- manually altered.
<Keybuk> without seeing exactly what you've done, I can't comment precisely
<Keybuk> but I suspect you've simply ended up with no inotify watches
<Keybuk> either by a typo or a mis-assumption
<Keybuk> IntuitiveNipple: I'm guessing that you're assuming that by moving the setting to 99, "after" LVM, that udev won't set the watch until later?
<Keybuk> udev doesn't work that way
<Keybuk> it processes the rules in the same manner, no matter what order things appear in
<Keybuk> e.g.
<Keybuk>   01.rules  RUN+="foo $name"
<Keybuk>   02.rules  NAME="bar"
<Keybuk> it will actually do
<Keybuk>   mkdir /dev/bar
<Keybuk>   foo /dev/bar
<Keybuk> not the opposite, as you might expect
<Keybuk> because the opposite is actually stupid
<Keybuk> so no matter where you put the OPTIONS+="watch", it will always add the inotify watch after mknod() but before all the RUN rules
<IntuitiveNipple> Hmmm... the lab PC has your binary package installed right now. I'll put the other one in and check what watches are set up after it starts
 * pitti hugs tseliot
<pitti> tseliot: thanks for figuring out bug 329410, this is driving me mad
<ubottu> Launchpad bug 329410 in gnome-settings-daemon "does not set configured resolutions at GNOME startup any more" [Medium,Confirmed] https://launchpad.net/bugs/329410
<ScottK> pitti: I see you are somewhat behind in your blog reading.  I wrote that one on notifications a long time ago.
<ScottK> pitti: I think giving users the easy option to get the more upstream experience is a great thing.
<pitti> ScottK: sorry for that, I just added a missing title today; I wrote that one weeks ago
<ScottK> pitti: OK.  That makes sense.
<ScottK> Now that you mention it, I think I even remember it.
<pitti> yeah, we talked about it on IRC
<ScottK> Personally, I'm pretty happy with what Knotify provides in KDE 4.2.
 * Keybuk facepalms
<pitti> good night everyone
 * Riddell can list half a dozen issues with Knotify
<NCommander> Is there a way to put an alternate CD on a USB stick?
<maxb> NCommander: usb-creator?
<NCommander> it doesn't work for me with alternates or server CDs; I was on the impression it was just for liveCDs
<maxb> I'm sure it worked for me, but I seem to recall it only fixed up *some* of the boot options
 * maxb hunts bugnumber
<maxb> LP 313366
<ubottu> Launchpad bug 313366 in usb-creator "cdrom-detect/try-usb=true not inserted on all relevant menu options" [Undecided,New] https://launchpad.net/bugs/313366
<Keybuk> NCommander: WFM
<NCommander> WFM?
<maxb> Works For Me
<Keybuk> Works For Me
<Keybuk> IntuitiveNipple: http://git.kernel.org/?p=linux/hotplug/keybuk/udev.git;a=summary
<Keybuk> IntuitiveNipple: top 10 patches
<IntuitiveNipple> Keybuk: I'll pull it to my local repo and build the package from that
<IntuitiveNipple> Keybuk: I meant to ask... is the repo supposed to also contain the test/sys/ ... tree ? it plays havock with any grep
<Keybuk> yes
<Keybuk> it's the udev test suite
 * soren needs "An idiot's guide to dpkg-statoverride"
<soren> $ dpkg-statoverride --list '*euca*'
<soren> root eucalyptus 04750 /usr/share/eucalyptus/euca_rootwrap
<soren> ...yet when a package comes along and provides that package, I get:
<soren> -rwsr-x--- 1 root root 6176 2009-02-20 09:40 /usr/share/eucalyptus/euca_rootwrap
<IntuitiveNipple> Keybuk: okay, because there are endless "recursive directory loop"
<tseliot> pitti: np
<IntuitiveNipple> Keybuk: well done... 18 seconds to boot
<soren> I thought statoverrides were supposed to be applied any time dpkg put the file in question in place?
<cjwatson> they ought to be, yes
<soren> cjwatson: So the stuff I pasted 15-20 lines up doesn't make any sense, does it?
<cjwatson> soren: err, the permissions in your dpkg-statoverride match those in ls -l
<soren> Not the ownership.
<cjwatson> oh, right
<cjwatson> sounds like a bug then, assuming that the package isn't doing anything else funny
<cjwatson> maybe if you're replacing an existing file you need an explicit chgrp? not sure without looking at the code TBH ...
<cjwatson> dpkg-statoverride does have an --update switch which may be relevant here
<soren> cjwatson: I tried removing the file, and "dpkg -i package.deb" again... Still no luck.
<soren> Hm...
<soren> What if...
<cjwatson> just a quick check, does that group actually exist?
<soren> $ getent group eucalyptus
<soren> eucalyptus:x:127:
<soren> Indeed.
<soren> And if I pass --update to dpkg-statoverride, it dtrt.
<soren> ...but dpkg seems to not care much.
<soren> dpkg-statoverride does it directly from perl, so it's an entirely different codepath.
<cjwatson> indeed
<cjwatson> I'm happy to investigate given sample packages and a tarball of /var/lib/dpkg
<soren> I'll look into it myself for a little bit. I just wanted to check if I was obviously doing it wrong.
<jdong_> are there any known jaunty issues with lvm+dmcrypt boot?
<soren> cjwatson: I'll take you up on the offer if I can't work it out. Thanks :)
<IntuitiveNipple> jdong: Yes: bug # 332270
<jdong_> where is the best place to break to diagnose a "volume group 'main' not found"?
<jdong_> oh.
<IntuitiveNipple> jdong: Looks like we have a fix; I've just tested Keybuk's upstream patches and it seems to do the job
<IntuitiveNipple> jdong: bug #332270
<ubottu> Launchpad bug 332270 in udev "udev repeatedly generates "change" events for the same block device(s)" [High,Triaged] https://launchpad.net/bugs/332270
<jdong_> IntuitiveNipple: thanks
<jdong_> ha. silly me. breaking on top with a USB keyboard.
<soren> cjwatson: False alarm.
<jdong_> ok that's it. LiveCD time.
<soren> cjwatson: dpkg dtrt. Immediately afterwards, the daemon I start from my postinst helpfully calls "chown root:root" on it.
 * soren pats strace on the head
<jdong_> I guess USB keyboard with broken udev is not going to work out well for my laziness.
<IntuitiveNipple> jdong: Doesn't BIOS offer an option for "Legacy USB" to cover that period? I know many do
<jdong_> IntuitiveNipple: not helpful when the kernel loads the EHCI/UCHI modules which seems to kick off the BIOS emulation
<IntuitiveNipple> jdong: the wonders of modern technology :)
<jdong_> lol, indeed :)
<jdong_> oh how helpless are we all when udev dies
<Keybuk> IntuitiveNipple: not a complete fix
<Keybuk> if you have multiple PVs, they'll just trigger each other
<soren> I have multiple pv's, but am not affected. What am I doing wrong? :)
<Keybuk> soren: there's another bug in udev I found in the process
<Keybuk> if lots of inotify events come in at once, then it only processes the first one
<Keybuk> if you apply the patch to fix _that_ bug
<Keybuk> then you'll be affected by the other ;)
<soren> Oh. Erm.. "Thanks" :)
<Keybuk> stupid dump question of the day
<Keybuk> how do I build an i386 binary on an amd64
<jdong_> package or binary? gcc -m32?
<Keybuk> jdong_: that complains about missing libgcc.a
<jdong_> fun
<ScottK> doko: Is there documentation yet on pycentral.mk?  Should it be used by any CDBS using pycentral package?
<Keybuk> I only have x86_64-linux-gnu in /usr/lib/gcc
<jdong_> is that lib32gcc1's job?
<jdong_> nope
<Keybuk> ahh, gcc-multilib
<doko> ScottK: not yet; I think it's better to move this into the python package, maybe with a better name. but I'll keep this one in python-central. Just didn't want to hard-code this in every dir
<ScottK> OK.
<Keybuk> IntuitiveNipple: so this package fixes it for you?
<IntuitiveNipple> Keybuk: It appears to have done, yes.
<Laney> IntuitiveNipple: Do you have a deb?
<IntuitiveNipple> Keybuk: Do you want to provoke/test it at all?
<Laney> I am having this too
<Keybuk> IntuitiveNipple: now that I've fixed the bug that stopped me from being able to replicate it, I'm quietly confident
<Keybuk> ie. I can fix that bug, replicate it every time in vmware, apply the other patches, and it goes away again
<Keybuk> now, in theory
<Keybuk> if I add another disk, with another LVM PV on it, it will explode
<Laney> I have multiple PVs
<IntuitiveNipple> Keybuk: OK... well if you need it, just shout
<IntuitiveNipple> Laney: http://tjworld.net/ubuntu/bugs/lp332270/
<Laney> thanks muchly
<Laney> do I need both?
<IntuitiveNipple> udev and libvolume-id1
<Keybuk> just udev actuall
<IntuitiveNipple> These are builds of Keybuk's git tree tip
<IntuitiveNipple> Keybuk: Confirmed. I deleted the PV here and created an extended in its place, and added 3 PVs inside it. As soon as I'd run partprobe the disk started thrashing
<Laney> I am getting "unable to create db file" errors with this udev deb
<IntuitiveNipple> Keybuk: Deleting the PVs whilst udev is thrashing cures the problem... a bit drastic though :)
<IntuitiveNipple> Laney: which arch?
<Laney> amd64
<Keybuk> Laney: it helps if you run it as root ;)
<Laney> *run* it?
<IntuitiveNipple> Hmmm, there were some glitches on the 'net when that was being transferred, but I did an md5sum check and it matched the source
<Laney> I just restarted my machine
<Keybuk> weird
<Laney> and yeah, I have multiple PVs and it still doesn't boot
 * Laney snaps a pic
<IntuitiveNipple> multiple PVs will trigger the bug
<Laney> hah
<Laney> it just moved on before I had the chance
<IntuitiveNipple> Keybuk: The obvious fix is upstream lvm, so vgscan doesn't open RDWR, but for now, could we work around it by having the rules add an attribute that would prevent the vgscan on any volumes that had already been scanned?
<Keybuk> IntuitiveNipple: I'm looking into the obvious fix now ;)
<IntuitiveNipple> :)
<mathiaz> slangasek: re bug 305264 and your comment https://bugs.launchpad.net/ubuntu/+source/gnutls12/+bug/305264/comments/33 - do you have reference to the discussion you mention in your comment?
<ubottu> Launchpad bug 305264 in gnutls26 "gnutls regression: failure in certificate chain validation" [High,Fix committed] https://launchpad.net/bugs/305264
<ubottu> Ubuntu bug 305264 in gnutls26 "gnutls regression: failure in certificate chain validation" [High,Fix committed]
<LaserJock> is there a kees-replacement while he's on vacation?
<Keybuk> "kees-replacement" ?
<Keybuk> soren is watching back episodes of Doctor Who, does that count?
<mathiaz> LaserJock: mdeslaur may be able to help you - as well as jdstrand
<Keybuk> pitti grew the "evil clone" beard a while back, so he's on "evil clone" duty
<Keybuk> (either that, or pitti *is* now his own evil clone from a mirror universe)
<LaserJock> Keybuk: is that a Multiverse clone then?
<mdeslaur> LaserJock: yes?
<LaserJock> mdeslaur: are Launchpad bugs filed for CVEs or are they handled separately?
<jdstrand> LaserJock: I've been told you were looking for kees
<jdstrand> LaserJock: I somehow dropped off Freenode
<LaserJock> I'm looking at http://people.ubuntu.com/~ubuntu-security/cve
<jdstrand> LaserJock: we track CVEs in ubuntu-cve-tracker
<mdeslaur> LaserJock: you're asking if you should file a bug?
<LaserJock> and there are a number of CVEs on a package I'm trying to work on
<LaserJock> I think some are going to get fixed, but I'd like to be able to track everyting, figure out which releases are effected, etc.
<tdomhan> the REVU is down? any information when it will be up again?
<jdstrand> LaserJock: LP doesn't have enough flexibility for us to track everything in it
<jdstrand> LaserJock: so we have ubuntu-cve-tracker, which that page you mentioned is generated from
<LaserJock> so I noticed there are https://launchpad.net/bugs/cve/ links
<jdstrand> LaserJock: we are getting close to being able to sync uct with LP
<jdstrand> LaserJock: we do add LP bugs to uct as we see them
<jdstrand> LaserJock: feel free to add bugs to LP, along with CVE links, and we'll get them in sync with uct
<geser> thekorn: use revu.ubuntuwire.org instead of .com
<geser> thekorn: sorry, wrong tab-completion
<LaserJock> jdstrand: ok, but what if they're already on uct, does that mean they have an LP bug?
<geser> tdomhan: use revu.ubuntuwire.org instead of .com
<jdstrand> LaserJock: if you want to do triage in uct yourself, go to https://code.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master. check out a branch, read README and ping us when ready
<tdomhan> geser, thanks, is that a permanent domain change?
<jdstrand> LaserJock: being in uct does *not* mean they have an LP bug
<jdstrand> LaserJock: when a couple of bugs are fixed in LP, that will change
<LaserJock> jdstrand: ok
<geser> tdomhan: I don't really know, I guess the .com will come back when it gets renewed again
<cjwatson> soren: haha, excellent :-)
<LaserJock> jdstrand: so in debian/changelog what's the best reference to say that we're fixing a CVE, just using the CVE number?
<jdstrand> LaserJock: yes. please see https://wiki.ubuntu.com/SecurityUpdateProcedures#Preparing%20an%20update for details
<jdstrand> LaserJock: it is good to reference the CVE number, the LP bug if there is one, as well as the patch url. The above link has details
<LaserJock> jdstrand: ok cool, this package has 10 CVEs on the tracker, hopefully we can get that number down
<jdstrand> LaserJock: excellent
<Laney> Keybuk: Here (http://orangesquash.org.uk/~laney/udev.jpg) are the new messages that I get after installing IntuitiveNipple's .deb. They don't seem to affect the boot
<Laney> also my interfaces have been renamed :(
<Laney> (but I see there is a bug for this already)
<asomething> jdstrand: Bug #316550, Debian's 0.1.1-10 only fixes CVE-2008-5620, my fix for CVE-2008-5619 comes from upstream. 2008-5620 isn't actually fixed in Testing it's fixed in unstable by using the new upstream release. i'm really not sure how to make it less invasive
<ubottu> Launchpad bug 316550 in roundcube "[CVE-2008-5619] [CVE-2008-5620] - Roundcube vulnerable and actively exploited" [High,Confirmed] https://launchpad.net/bugs/316550
<Laney> Keybuk: Is udevd hosing the CPU a part of this bug?
<asomething> jdstrand: err....  2008-5620 is fixed in testing not  2008-5619
<jdstrand> asomething: aren't both? I also looked upstream and couldn't find the changeset that matched the debdiff.
<jdstrand> asomething: if this is in error, can you comment on the bug and update the patch to reference the upstream commit that fixes this?
<jdstrand> asomething: I thought 5619 was fixed in -9...
<asomething> jdstrand: ahh, i see now, sorry. I'll use the debian fix. upstream provides new files here: http://sourceforge.net/forum/forum.php?forum_id=898542
<jdstrand> asomething: that link isn't super useful. it would be best if you could find the svn commit. however, if you go with Debian's changes, then no need
<Keybuk> Laney: that would be the primary symptom of the bug, yes
<jdstrand> asomething: thanks for your work on this :)
<Laney> Keybuk: Ah, I thought it was just slowness in the boot. Good to know, thanks
<slangasek> mathiaz: the upstream discussion?
<mathiaz> slangasek: yes
<mathiaz> slangasek: was it an discussion with gnutls upstream or openldap upstream?
<slangasek> mathiaz: gnutls upstream; linked to from the referenced Debian gnutls bug report
<mathiaz> slangasek: ok. So openldap upstream hasn't been consulted
<slangasek> indeed not
<Keybuk> hmm
<Keybuk> I wonder
<Keybuk> can you re-open a file descriptor with different flags?
<slangasek> well, I guess freopen() can, but I imagine it just closes and reopens as necessary?
<cjwatson> dup2 + fcntl?
<slangasek> ah
<cjwatson> oh but you can't fiddle with O_WRONLY etc. with fcntl
<Keybuk> cjwatson: yeah, sadly
<Keybuk> close() and open() it is
<directhex> Keybuk, we almost have a gdb addin package for monodevelop ready. and it already supports some source control systems directly. since you mentioned it on the blogosphere
<Keybuk> directhex: \o/
<Keybuk> does monodevelop have an equivalent of C-x 4 a
<Keybuk> and does monodevelop support autoconf/make yet? :)
<directhex> it has autofoo integration, although i haven't used it
<directhex> and i know it has vi bindings - dunno about emacs
<directhex> s/bindings/keyboard &/
<Keybuk> I don't want vi or emacs bindings
<Keybuk> what I mean is does it have an add-to-changelog functionality
<Keybuk> ie. I'm editing source code
<Keybuk> I press a key or two
<directhex> oh. i think so. let me check
<Keybuk> and it takes me to the ChangeLog file, with the date, my name, e-mail address, the current filename, and function all filled in already
<racarr> Keybuk: A little late, but I think you want dup3
<Keybuk> racarr: sadly again, you can only add O_CLOEXEC to the flags
<RAOF> Keybuk: It does have autofoo integration, but I always end up writing the autofoo myself; it generates only semi-sane autofoo.
<Keybuk> then again, knowing the kernel, to actually change the flags from O_RDONLY to O_RDWR would involve an fput()/fget() so it's a close()/open() anyway
<Keybuk> RAOF: don't want it to generate it - just use what's there
<RAOF> I think that works, yeah.
<RAOF> Honestly, I use monodevelop as a glorified text editor.
<racarr> Keybuk: Ah. Nevermind.
<RAOF> In part because it doesn't respect PKG_CONFIG_PATH, and I'm always developting against stuff installed in ~/.local
<directhex> Keybuk, no default key binding, but yes, changelog adding is a bindable menu option
<Keybuk> directhex: nice
<Keybuk> directhex: so when does the gdb stuff arrive?
<directhex> Keybuk, when meebey, hanska & i manage to beat git into a bloody pulp..... and a nice friendly MOTU uploads it... and it passes NEW
<Keybuk> PPA :p
<Keybuk> and a valgrind addin? :p
<directhex> Keybuk, patches welcome!
 * Keybuk would have to learn C# properly
<directhex> well you want the mdb addin if you wanted to learn c#
<directhex> i thought you were happy enough with c/c++-like things
<directhex> oh, wait, for patches
 * directhex si teh dum
<directhex> you can write addins in any mono language, if you're in the mood - e.g. monodevelop-boo is written in boo
<directhex> boo's a cute language
<meebey> 22:48:51 <Keybuk> what I mean is does it have an add-to-changelog functionality
<meebey> yes it has, all VCS commits gets added to a changelog automatically
<Keybuk> not quite what I meant
<directhex> and non-vcs commits too
<meebey> so whats add-to-changelog then
<Keybuk> ChangeLog
<Keybuk> it's a top-level file in most projects
<meebey> yes thats what it does
<meebey> you can set it to top-level or deepest
<Keybuk> I write that as I go
<directhex> i'd take a screenshot but, y'know, effort
<Keybuk> then when I commit to a vcs, I just use the diff of the top-level ChangeLog as the log message
<cjwatson> meebey: some of us prefer generating the VCS commit message from the changelog rather than the other way round :)
<Keybuk> directhex: I can't actually find the option
<cjwatson> it's easier to write that as you go along rather than being forced to do it all at the end when you're committing
<meebey> you have to enable changelog integration in the solution or project first IIRC
<directhex> Keybuk, Edit menu, near the bottom, to add an entry. project options bottom section lets you configure format
<meebey> but AFAIK its bound to the VCS actions
<directhex> meebey, nay!
<directhex> not in 2.0b1 anyway
<Keybuk> directhex: no option there, just "Insert standard header"
<meebey> cjwatson: then you dont commit often enough!
 * meebey runs
<directhex> Keybuk, is this 1.0 or 1.9.2?
<meebey> directhex: even 1.0 has changelog integration
<Keybuk> directhex: 1.9.2 from your PPA
<directhex> Keybuk, and it might be in the monodevelop-versioncontrol package, if you don't have that
<Keybuk> not that I can figure out how to create a project in monodevelop anyway ;)
<cjwatson> meebey: my commits are about as granular as I can possibly make them, actually ;)
<cjwatson> (sanely, anyway)
<meebey> cjwatson: excuses excuses! :-P
<cjwatson> I can't help it if you like a crackful changelog generation method ;-)
<directhex> if my request for UDS sponsorship gets approved, then there'll be an opportunity to play in a group environment :D
<meebey> so you switch between the changelog and the source while you are working on it?
<meebey> I usually read the diffs when I commit and then write what I changed..
<meebey> as it might need a few cycles till it works (by testing)
<Keybuk> directhex: actually, quite seriously
<meebey> so the code is written but not working and maybe the approach was all wrong
<Keybuk> how _does_ one open an existing piece of code in monodevelop? :p
<RAOF> Keybuk: file->open ?
<directhex> Keybuk, the root unit is a solution, a solution contains projects. you should be able to file/open individual files, but need a solution for useful interaction
<Keybuk> so how do I create a solution/project for an existing program?
<directhex> new empty solution, preferably of the language type that your project is, and add files
<cjwatson> meebey: not all the time, but sometimes it is useful not to write the whole changelog message right at the end
<directhex> anyway, feel free to beat upstream with a stick if you don't like it ;)
<cjwatson> meebey: I often find that, while I'm describing what I did, I notice mistakes, pare down the diff somewhat, etc.
<cjwatson> meebey: and I prefer to write the changelog with reference to a diff (i.e. bzr diff | view -, :spl ChangeLog) rather than with reference to a VCS commit editor
<Keybuk> directhex: how does it know to use autoconf, etc.?
<directhex> Keybuk, i don't think it has much in the way of existing-autofoo ability. it can create its own, but i don't know about importing existing
<directhex> Keybuk, i forget which menu it's in, but there's a clicky option in a menu to create makefiles, which lets you pick autofoo
<RAOF> Hm.  That's changed since 1.0
<RAOF> There used to be a box "run autogen.sh before build"
<Keybuk> right, but I have the complete existing project
<Keybuk> and just want to edit things
<Keybuk> can't you just go "here's a project, it has existing Makefile.am files, go figure it out yourself"
<Keybuk> ideally that would result in a complete solution already
<RAOF> No.  But that _would_ be pretty awesome.
<RAOF> It sounds quite hard, though.
<Keybuk> why?
<Keybuk> Makefile.am are eeeeasy to parse
<Keybuk> Project for each bin_PROGRAMS type entry
<Keybuk> and lookup the SOURCES for them for the files
<RAOF> I suppose if you don't want to support people doing crazy stuff, it'd be easy.
<Keybuk> crazy stuff they can just Add File, etc.
<RAOF> It'd work particularly well for C/C++ projects, because they do crazy stuff least frequently.
<directhex> Keybuk, could be a fun challenge for someone who's a little bored
<RAOF> directhex: How do you make "Edit->Add ChangeLog Entry" be not disabled?
<directhex> RAOF, um... have you enabled it in project options?
<RAOF> directhex: Yes.
<directhex> ehm..... ya SUUUUUUUUUUUUURE?
<directhex> i dunno. poke lluis or mhutch? it worked in my brief tinkering
<RAOF> directhex: YES.  In both the default policies, and in the solution.
<RAOF> Anyway.  Importing projects from a top-level Makefile.am would be pretty cool, and hopefully not too hard if you do it simple-mindedly.
 * Keybuk breaks lvm
 * geser will wait a few days before he updates udev and lvm
<Keybuk> geser: yes, that's helpful
<Keybuk> that way we won't know whether or not the bug is fixed
<geser> Keybuk: I'd test the new packages but I currently don't have time to "break" my jaunty before Thursday
<nhandler> Does anyone here know when elmo is usually online? I've been trying to contact him for a few weeks now. I have tried sending him /msg's and emails, but have not gotten a response.
<cjwatson> he was travelling last week and thus working hard at fairly unpleasant times for him. Do you really need elmo specifically?
<nhandler> cjwatson: I'm still trying to hunt down a status update of people.ubuntu.com. The response from everyone I have talked to has been to talk to elmo
 * cjwatson looks for an RT request about this
<cjwatson> normally, I would expect to be able to find elmo during UK working hours
<nhandler> I have tried sending him a /msg at around 12:00 UTC (before I leave for the day). I have also tried sending him emails. It is nothing urgent, but I would appreciate a response
<cjwatson> can't really help you further, sorry ...
<nhandler> cjwatson: No problem. But if you see him, please let him know that I have been trying to contact him.
<cjwatson> sure
<Keybuk> Displaying first 80 comments.  View all 114 comments or add a comment.
<Keybuk> !!
<Keybuk> holy launchpad misfeature!
<jdong_> It should say "Displaying summary. Add a comment, add a comment, post on Digg, or view all comments" right?
<Keybuk> it needs a link to send whatever Jono's just blogged about to the PRESS
<LaserJock> jdong_: no slashdot or technocrati?
<Keybuk> but y'know
<Keybuk> I'm usually interested in the _most_recent_ comments on a bug
<Keybuk> not the _oldest_
<jdong_> IMO there should be karma attachable to posts
<jdong_> a la digg, with a developer/driver-tickable "bump up +9000" button.
<Keybuk> no
<jdong_> if you look at recent comments you are more than likely to see "yeah I get that too" times 100
<Keybuk> we should give the posters a "bump up +9000" button
<Keybuk> that when you click it gives them a big box saying "your post has been bumped"
<Keybuk> but NOTHING ELSE
<Keybuk> they'll click on it for weeks happily without realising
<StevenK> Haha
<directhex> jdong, what, 9000?
<ScottK> doko: Since python-celementtree and python-elementtree are incorporated in Python 2.5+, should be be getting them removed or do you need them for Zope?
#ubuntu-devel 2009-02-24
<wgrant> jdong_: With LP project<->team affiliations which are coming soon, comments by real people (ie. people connected to the project somehow) will be able to be shown as more important.
<fruchtix> could somebody explain the reasoning why debtags and ept-cache are in the ubuntu repository but not integrated in ubuntu at all?
<LaserJock> perhaps nobody has had time/interest to integrate it yet
<directhex> yeah, i started but i got bored
<directhex> i might write it in intercal
<fruchtix> if 1 person would care to promote it in a suitable way there might be enough peope on #ubuntu-motu who contribute?
<directhex> ideas are cheap. developers less so
<fruchtix> enrico did all the word it needs from the developer side
<directhex> i.e. feel free to make proposals, e.g. use brainstorm, but don't anticipate a flood of people to implement your ideas before anything else
<fruchtix> before i waste my time the next weeks i am asking for the reasons why its potential use ignored by the core developers
<fruchtix> use/is
<LaserJock> I didn't even know ept-cache existed
<LaserJock> I know about debtags but I'm not sure if we've got anything that would really make use of them
<fruchtix> its one of the smartest ideas on how to handle thousands of package descriptions in such a way that users find what they are looking for - since binary packages were invented
<fruchtix> because traditional categories for packages are fine for Ubuntu's CD 1
<fruchtix> but not for 20,000 packages
<LaserJock> I think most people see the value in debtags (or at least the concept)
<fruchtix> why the promotion without the debian community did not work is kind of logical. anything new is a danger to conservative people. but i dont get why the concept is completely ignored by ubuntu
<fruchtix> without/within
<LaserJock> I don't think it's completely ignored
<cjwatson> just that nobody's had time to do anything interesting with it; as you say, it isn't really needed by the default installation so hasn't reached top-priority kind of status
<cjwatson> I think we'd welcome somebody working on it properly
<cjwatson> there's been no explicit "debtags sucks, let's ignore it" kind of decision AFAIK
<slangasek> Keybuk: will the new udev also declare a Breaks: on the old lvm2 (eventually)?
<fruchtix> i am not even close to become an ubuntu developer. so its not the right task for me
<slangasek> Keybuk: also, are the changes to libs-cleanup.patch and drop-realtime.patch in lvm2 intentional?
<fruchtix> it requires a person with enough influence to poke the right people so the necessary promotion starts. the volunteers who do the work will come to you automatically
<cjwatson> I don't think it works like that at all
<cjwatson> lots of things are bottom-up not top-down, in my experience
<cjwatson> and volunteers CERTAINLY do not automatically materialise no matter what you do
<Keybuk> slangasek: I had to refresh them, quilt told me to otherwise it would kill kittens
<fruchtix> promotion is the key
<slangasek> Keybuk: ah; the refreshed patches look rather... different from the previous revision
<Keybuk> Breaks - yes, it should probably have some of those
<Keybuk> slangasek: really? I didn't look at them
<cjwatson> anyone can do promotion
<slangasek> Keybuk: both patches now patch less than they did before :)
<slangasek> not sure why that would've happened with a refresh
<Keybuk> slangasek: quilt is evil
<cjwatson> although I would suggest a more constructive attitude than "before i waste my time the next weeks i am asking for the reasons why its potential use ignored by the core developers" / "but i dont get why the concept is completely ignored by ubuntu"
<slangasek> not IME
<fruchtix> thats not true. when the right people post a comment on their blog it creates huge waves of attention
<fruchtix> when i dedicate 5 servers it gains me nothing
<cjwatson> consider how the right people became the right people
<cjwatson> they did the work
<cjwatson> anyway, this isn't my area of interest, I'm just advising; you can take it or leave it
<fruchtix> fantastic for those who did the right things ages ago. maybe i become a hacker in my next life
<ScottK> fruchtix: Whining about not being influential and not actually doing stuff isn't likely to help you reach your stated goal.
<cjwatson> so far your general tone has succeeded in persuading me to go off and do something else more productive. :-(
<fruchtix> its just sad when you see for what rubbish some celebrities use their blog and a brilliant idea dies slowly because it gets no attention
<ScottK> fruchtix: Around here doing stuff tends to get you more attention than whining or blogging.
<Keybuk> slangasek: looks like if you pop -a after building, quilt screws up - reuploaded with the original 2 patches
<fruchtix> dude, this is not about writing code. nobody needs your code in this case.
<fruchtix> the code already exists. and a lot of data exists too
<fruchtix> but you see what reactions i get here on this channel? what do you think what reactions i get when i start "doing work", huh?
<LaserJock> fruchtix: code does need to be written to integrate debtags into useful apps like gnome-app-install and synaptic
<cjwatson> huh? the reaction you got from me was entirely due to your horrifically negative tone
<fruchtix> so thats why i takes a person with a reputation to pick it up
<maco> fruchtix: or at least someone with a less-whiny tone
<Keybuk> the people with reputations have an awfully large amount of work that they have to do already
<fruchtix> my tone? you feel my tone by text only?
<fruchtix> thats amazing
<cjwatson> I'm entirely happy to support debtags work in any way I can usefully do so, but it isn't my area of expertise so I'd rather do something I'm expert in
<fruchtix> i love this cyberspace thing
<ScottK> fruchtix: No, that's why it takes someone whoe doesn't have a horrifically negative tone to take it up.  This may be in your grasp.
<maco> fruchtix: yes, you're full of biting sarcasm, thatd be tone.
<cjwatson> text is the way in which you're communicating, so you need to be careful about how things come across; I'm afraid that's life
<directhex> you're such an optimist, colin
<ScottK> Particularly when you're trying to convince other people they want to work on something that interests you more than the.
<maco> charisma might help
<fruchtix> maybe the situation creates the sarcasm and the feeling of anger for people who believe the gained all the fame for themselves instead of using it for the benefit of the project and the users
<directhex> or maybe you just want free developers to work on your pet projects
<directhex> who can say, in this crazy world of ours
<fruchtix> thats actually the sharing philosophy, even when your paycheck from canonical is sexy
<maco> hey uh you realise a big chunk of this channel gets no paycheck for FOSS?
<ScottK> fruchtix: Most of the people talking to you don't work for Canonical.
<fruchtix> after all, its the code of upstream in most cases that makes you happy and proud
<fruchtix> so how about you check your own tone when you talk to me?
<maco> fruchtix: who says people here dont work with upstream?
<fruchtix> and how about this code of conduct. did i sign it yet or did you sign it?
<ScottK> fruchtix: So far everyone here has been trying to give you helpful advice.
<fruchtix> oh yeah?
<cjwatson> like I say, I'm entirely happy to support debtags work in any way I can
<ScottK> Yes.
<fruchtix> by judging my person?
<fruchtix> by complaining about my "tone"?
<directhex> ScottK, i haven't, i've been gently dripping sarcasm as i usually do
<maco> by telling you that if you want to get something working, then you should go make it work
<ScottK> OK.  Except him
<cjwatson> You've commented about your perceived inability to influence people; in that context I think comments about your tone are entirely reasonable.
<maco> directhex: no more than fruchtix has :P
<fruchtix> dude, if you seriously believe in this rubbish "if you want something done then do it yourself" then why the heck are we talking about a community?
<cjwatson> Because that's pretty much a direct input into your ability to influence people.
<maco> fruchtix: what do you think a meritocracy is?
<directhex> "community" doesn't mean "people doing stuff i want when i want it"
<maco> of *course* if you want something done right you do it yourself
<ScottK> fruchtix: If you seriously believe popping into an IRC channel and saying "everyone do this" works, you have no idea how the world works.
<maco> that's how its been since humans evolved/were created/came from neptune
<fruchtix> heard about co-operation?
<fruchtix> heard about "i am dedicated to my work"?
<ScottK> fruchtix: Yes.  You?
<fruchtix> heard about "i care for ubuntu and i dont just hang around here because of my cool vhost"?
<slangasek> Keybuk: ta
 * cjwatson looks at the upstream release he's preparing over --> there at 00:34 local time
<cjwatson> because I care about my work
<fruchtix> perfect
<directhex> okay, now the unexpected reality blast: if you want to see "something" done with debtags, why not make a concrete proposal which people CAN look at and comment on and cooperate on?
<cjwatson> don't preach at me
<fruchtix> cjwatson: when did i address you personally?
<directhex> rather than a handwavey "DO MY STUFF!"
<cjwatson> quite a bit, as it happens
<fruchtix> aha
<directhex> you have a lose concept and a chip on your shoulder. sort BOTH to get results
<cjwatson> I gave you useful advice, you got all offended
<fruchtix> cjwatson: and the person who pays your salery (your boss) tells you straight into your face "lamer, listen. if i need something done i do it myself. go on vacation"?
<directhex> you don't neccessarily need to write buckets of perl - just come up with a real proposal beyond "you guys should drop what you're doing, i command it so"
<maco> fruchtix: no, in that case you're being PAID
<directhex> i'm spent, sarcasm mode back on.
<maco> fruchtix: unless you are intending to offer a cash bounty to the person who does what you want, don't be so bossy, please
<fruchtix> so all of a sudden there is a difference between a paid job _for_ the community and a volunteer job _for_ the community?
<fruchtix> so all of a sudden we all realize that we only move our arse for other people when the paycheck is sexy?
<maco> look, hackers'll hack on whatever they want whenever they want
<fruchtix> is that the free software spirit now?
<maco> they don't need to take orders from anyway
<cjwatson> I believe the only person in this conversation who is paid by Canonical is me
<maco> *anyone
<directhex> hurrah for entitlement culture
<directhex> kids these days
 * ajmitch scrolls up to see what started this rant
<fruchtix> well, thanks for the interview then. have a nice day
<directhex> ajmitch, "USE TEH DEBTAGS NAO!"
<cjwatson> so the paycheck rant is rather missing the point
<ajmitch> directhex: ah ok
<maco> yeah...
<fruchtix> and btw - thanks for trolling me, too
<cjwatson> (and in any case I was involved with free software long before I was paid to do so)
<directhex> you know, i think i WILL do "something" with debtags
<maco> the point is, people will work on what they'll work on when they want to work on it, and if they dont want to work on what you want to work on, then you can do it yourself or find someone else to do it for you
<fruchtix> its the cheap tricks of a young journalist. but it seems to work
<ScottK> And oddly enough I've spent most of my FOSS time today working on stuff that other people asked me to do.
<directhex> a bonsi buddy clone, written in visual basic.net, which picks a package at random and tells you its tags
<directhex> sounds helpful!
<ajmitch> directhex: you're a bad man
<maco> directhex: that's scary
<directhex> ajmitch, by design!
<maco> just because person A finds something interesting doesnt mean person B will
<fruchtix> directhex: paid by canonical or do you troll for hobby right now?
<maco> or that B will have the skills even if they find it interesting
<directhex> fruchtix, for the love of it
<fruchtix> directhex: cool
<fruchtix> i am sure you have your fans
<directhex> oh, i do
<maco> fruchtix: did ya miss the part where cjwatson  is the only paid one here?
 * directhex fires up monodevelop, looks for some pictures of a purple gorilla
<ScottK> And I'm pretty sure he's not on the clock at gone midnight local for him.
<cjwatson> definitely not
<maco> O_O
<maco> how many hours a day do you spend on this colin?
<directhex> ScottK, don't most hackers only start being productive at 10pm? or is that just me?
<cjwatson> ... some
<ScottK> Depends.
<cjwatson> doing a man-db upstream release at the moment, taking a bit longer than I'd hoped
<fruchtix> so canonical gave up control over one of the most important ubuntu channels here on freenode. also interesting news and good to know
<maco> what?
<fruchtix> but yeah, launchpad is ready
<maco> canonical never had control of this channel...
<fruchtix> i can see the strategy
<maco> not really
<ScottK> fruchtix: Ubuntu has always been a community led distro.
<slangasek> directhex: I for one would appreciate it if you didn't taunt people quite so mercilessly when they're already clearly aggravated...
<LaserJock> fruchtix: is there a specifc thing you want done with debtags? specifically or ept-cache or is there more?
<maco> canonical's probably got more tech support people than developers, i'd guess
<slangasek> LaserJock: how's the moodle merge going? :)
<cjwatson> #ubuntu-devel was open to non-Canonical contribution from the start, and had significant community involvement from the start (I was there, so I can be pretty sure about this)
<fruchtix> ScottK: that sounds quite romantic, but i think without Mark and his investment into Canonical ... most of you guys would suck on the nibble of Debian or other distros
<LaserJock> slangasek: getting there. lots and lots of CVE reviews
<LaserJock> slangasek: I'm waiting though on a MIR for smarty
<directhex> fruchtix, most of the people you're arguing with are long-standing Debian Developers
<ScottK> fruchtix: Of course the Canonical investment is critical, but there is a very substantial community involvedm.
<maco> fruchtix: you mean if ubuntu didn't exist, period?
<directhex> slangasek, is that a "shut up" or a "stop working on Debtag Buddy"?
<cjwatson> certainly I've been a Debian developer since 2001
<ScottK> ... involvement.
<slangasek> LaserJock: uh?  there's an MIR of a template engine required to fix a moodle security bug?
<fruchtix> directhex: maybe thats why i am in the middle of my schizophrenia again. its the debian personality aspects
<slangasek> directhex: 'yes'?
<maco> cjwatson: what would you say? more devs or 1-800-help-4-me people?
<LaserJock> slangasek: not required, but I'm merging a new upstream release in
<LaserJock> slangasek: the release fixes loads of bugs and security vulernabilites
<slangasek> LaserJock: so I'm thinking that's not going to all be ready between now and Thursday and I should probably bump the milestone?
<LaserJock> slangasek: the template engine is a split out lib
 * ScottK decides to go pick up his daughter from the mall since that's more productive than this discussion.
<maco> ScottK: the computer-y one? i say "hi"
<cjwatson> maco: more developers
<fruchtix> if you would be able to isolate the technical aspects of the work of a debian person, then well, then we would not need Mark and Canonical to create ubuntu as a "helper" for the broken social aspects, right?
<slangasek> LaserJock: oh, it's code that's already in the existing moodle package?  that doesn't require a full MIR, just a bug saying that
<maco> fruchtix: the social aspects arent the problem
<LaserJock> slangasek: well, kees asked for it. It's all there
<maco> fruchtix: its the ease of use stuff
<LaserJock> slangasek: but then he went on vacation so I'm not sure where it stands
<maco> fruchtix: i mean, yeah, there's the coc stuff....but really....the 6mo release cycle and the aim for simplicity is what brings people to ubuntu, i think
<maco> its the reputation for being fairly easy to use
<maco> ....that's why my mom uses it
<fruchtix> maco: you dont know much about debian then. i am observing the situation since 8-9 years. and its 95% home made ... and social aspects
<slangasek> LaserJock: "if a new source package contains only code which is already in main, it may not need a full report. Submitting a bug with an explanation is sufficient." https://wiki.ubuntu.com/MainInclusionProcess - so if that's the case for smarty, upload and we'll fix up the overrides...
<maco> fruchtix: what do you mean 95% home made?
<fruchtix> maco: problems made by debian developers for other debian developers
<slangasek> he means that he's Patrick Frank
<cjwatson> social problems were one reason we founded Ubuntu rather than simply funding work on Debian, but far from the only one
 * maco is very confused
<fruchtix> slangasek: how is helix? are you still doing her?
<LaserJock> slangasek: it's bug #327367
<ubottu> Launchpad bug 327367 in smarty "MIR: please promote smarty to Main" [Undecided,New] https://launchpad.net/bugs/327367
<ajmitch> slangasek: that would explain a lot
<slangasek> sorry, should've gone with my gut 20 minutes ago
<directhex> that took longer than required
<maco> O_o
<cjwatson> I hadn't twigged to the debtags connection
<directhex> what's the connection?
<cjwatson> google
<slangasek> has Patrick expressed interest in debtags before?
<cjwatson> yes
<Keybuk> didn't he once threaten OFTC with legal action?
<slangasek> freenode, yes; OFTC, I don't know
<directhex> preemptive dispatch from #ubuntu-motu ?
<ajmitch> no, he's just ranting away in -server now
<LaserJock> slangasek: the moodle changelog has 26 security fixes and 20 debian bugs fixed since our current version
<LaserJock> slangasek: I was guessing that would get me a FF exception
<LaserJock> in Debian we've got a buildable package that has incorporated almost all of Ubuntu's diff
<LaserJock> so I just need to test to make sure it's not totally broken, get FFe approval, and then I can upload
<cjwatson> my apologies to this channel for being drawn in too far by a troll
<Keybuk> *sigh* you make one little change to the task_struct, and you have to rebuild almost the entire kernel :-/
<slangasek> <snerk>
<TheMuso> Keybuk: If you are using the build system used by the Ubuntu kernel, that happens even if you make a config tweak unfortunately. That can probably be fixed up though.
<directhex> cjwatson, maybe you just see the good in people. i called you an optimist half an hour ago ;)
<cjwatson> I'm only sorry that this means he'll probably infect our mailing lists for a while
<slangasek> mm, really?
<maco> its a moderated list...
<cjwatson> ubuntu-devel is; ubuntu-devel-discuss and others would require more effort to keep clean
<maco> yeah
<LaserJock> it might also ruin people's desire a little to actual do something with debtags
<cjwatson> right, that concerns me more
<cjwatson> I do think it's a useful system
<maco> LaserJock: just because itd make the jerk happy?
<LaserJock> not necessarily
<LaserJock> but getting involved in a "war" with him every time you try to do something would be pretty demotivating
<LaserJock> as well as people just getting tired of the subject
<StevenK> And the author
<cjwatson> the author?
<directhex> i couldn't spot the name of the real author. google failed to find much from what /whois revealed
<cjwatson> Enrico Zini
<slangasek> directhex: if you're referring to our guest, the name is Patrick Frank
<cjwatson> (who as far as I can tell is nothing to do with fruchtix, and is generally a very laid-back nice guy)
<slangasek> a google on that name and debian or ubuntu is... elucidating
<LaserJock> slangasek: so do you think I can get a FFe by Thursday?
<directhex> hm. flashes of obnoxiousness
<slangasek> LaserJock: "by 6pm" is also "by Thursday", so sure
<directhex> i think dragging erinn into the above little troll session was pushing it rather hard though. i do wonder about people like that
<directhex> then i mentally file them in the same bin as boycottnovell contributors, and sleep easy! \o/
<slangasek> directhex: stick around long enough and he'll give you plenty more fodder for wondering
<directhex> slangasek, we'll see where my NM application takes me!
<slangasek> directhex: the condensed backstory there, btw, is that he had a habit of joining #debian-women, each time with a different alias, despite being told his presence was unwelcome and inappropriate; and as an op there I both a) got good at identifying him, b) pissed him off to no end
<Hobbsee> oh, he's been here too?
<slangasek> yes
<StevenK> And -server
 * maco snorts
<maco> Hobbsee: that sentence told you who was being talked about?
<slangasek> the buzzing was probably enough to make that clear :)
<Hobbsee> oh, paddy.  right
<StevenK> He is one of those people that wanted debian-women to stop existing, isn't he?
 * StevenK tries to remember
<directhex> StevenK, highly likely, given the above descriptions
<maco> james_w is warning #ubuntu-women ops
<StevenK> A k-line sounds appealing right about now
<Hobbsee> StevenK: well, that's the aim.
<Hobbsee> or at least, likely to be the end result
<cjwatson> I was going to say, surely the aim is to keep the network productive ...
<StevenK> Hah
<cjwatson> A K-line would surely just get him more wound up, anyway; we already know he morphs
<ajmitch> he's trolling #ubuntu-ops now, they can deal with it
<directhex> he needs a hobby
<directhex> well, a DIFFERENT hobby
<slangasek> StevenK: not as such; he just wanted debian-women to not have ops that would kick him from the channel
<StevenK> Pity that he has moved on from annoying Debian to us. :-/
<directhex> StevenK, gotta go where the slangasek is!
<maco> slangasek: all the better to troll them with?
<Keybuk> they all come our way eventually
<slangasek> StevenK: he goes back and forth on which community to harrangue
<Keybuk> it'll be Sven Luther before too long
<Keybuk> Friendly
<maco> can we send him to...i dont know...whatever community has Theodore de Raadst? that could be amusing.
<maco> (cant spell that name, you figure it out)
<directhex> maco, openbsd
<maco> directhex: the point was theodore, not the community ;) i hear he likes to argue on the internet
<directhex> maco, newsgroups, probably. these days, newsgroups are where you go if 4chan is too civilized
<directhex> maco, it's where you can find some of my critics, for one thing ^_^
<StevenK> 4chan? Civilized?
 * StevenK chokes
<maco> StevenK: ok so we're laughing at the same thing
<Keybuk> I think directhex was aiming for irony
<StevenK> Duh :-P
<directhex> Keybuk, too sleepy for sarcasm
<directhex> Keybuk, irony will have to do
 * Hobbsee suggests the channel go back on topic?  ;)
<maco> oh right
<Keybuk> development
<ajmitch> Hobbsee: that'd just be boring
<cjwatson> sigh, I meant to do gparted 0.4.2 today
<cjwatson> I guess that will have to be tomorrow, I'd rather not do it while half-asleep
<Keybuk> cjwatson: I meant to do lots of things today :-/
<Keybuk> too much lvm inotify madness
<cjwatson> did you make any significant progress by the end of the day?
<directhex> Hobbsee, i've hit 90% of my jaunty goals already, though \o/
<cjwatson> there were a few too many trees for me to see the forest
<Hobbsee> directhex: \o/
<Keybuk> cjwatson: I believe I have fixed the bug
<slangasek> I'll be trying to confirm that as soon as amd64 binaries are available
<Keybuk> yeah, the buildds are on a go-slow today
<directhex> is openjdk still building on arm?
<StevenK> Yes
<StevenK> And koffice, and kdebindings
<directhex> Started on 2009-02-18
<directhex> and that really isn't a dead build?
<slangasek> LaserJock: I don't see that a FFe request was actually filed?
<StevenK> sbuild will kill a build that spins for 150 minutes with no output, IIRC
<Keybuk> it's ARM
<Keybuk> it has to save up for compilation in installments
<slangasek> wait, was that a mortgage joke?
<Keybuk> no, more of a "collect each monthly part and they build up to this nice collectable executable"
<Keybuk> "pay by direct debit and get this attractive binder FREE"
<slangasek> oh, so it's not about adjustable-rate mortgages
<Keybuk> no, are adjustable-rate mortgages especially on your mind right now?
<maco> i guess that means i no longer have that excuse to not use lvm (excuse being: it usually breaks badly during devel time) and should download a daily cd to install and test with
<slangasek> Keybuk: not particularly, I was just grasping at straws trying to parse "compilation in installments" :)
<Keybuk> I wish I had a variable rate mortgage
<Keybuk> mine's fixed
<Keybuk> and now the interest rate is practically non-existant
<RAOF> Below inflation, for some people.
<slangasek> we have one on the condo that we haven't been able to sell, and it keeps costing us less and less every quarter
<slangasek> Keybuk: refinance? :)
<Keybuk> slangasek: still in the fixed period
<cjwatson> so should I be rebuilding d-i against the new udev once it builds everywhere
<cjwatson> ?
<Keybuk> there's penalty clauses for early closure
<Keybuk> have only a year or so left
<maco> and will an email go out when there's a daily cd available with a hopefully-working udev/lvm combination?
<slangasek> Keybuk: sure; I assume you've looked at the math then, to determine whether it's worth paying the penalty
<Keybuk> slangasek: yeah, marginally not worth it
<cjwatson> I suspect that without a d-i rebuild the alternate install CD will have slightly hosed LVM
<Keybuk> it wasn't really that high interest rate to begin with
<slangasek> maco: not explicitly; but if the bugs are still closed tomorrow, tomorrow's CD will have the fix
<StevenK> slangasek: Still can't sell the condo? :-/
<slangasek> StevenK: nah - bearing in mind that it's still winter here, so the market is only just starting to pick up
<StevenK> slangasek: The housing market hibernates for the winter?
<slangasek> StevenK: yes
<StevenK> Odd
<slangasek> nobody wants to buy a house when they don't have enough light to look at it first
<Keybuk> hurrah, my new kernel built \o/
<Keybuk> now to remember what I was going to do with it
<slangasek> make kernel panckaes
<slangasek> pancakes
<maco> slangasek: ok. / keeps filling so it seems i need to switch to lvm so i'll be able to resize it next time i fill it.
<slangasek> :)
<Keybuk> slangasek: it is Tuesday here ;)
<slangasek> Tuesday is kernel pancake day?
<StevenK> maco: You have things like /usr and /var seperated?
<Keybuk> Tuesday is Pancake Day
<Keybuk> slangasek: http://en.wikipedia.org/wiki/Pancake_Day
<slangasek> Keybuk: wow, a cultural reference that totally eluded me :)
<Keybuk> slangasek: I'm not entirely sure you knew about that
<Keybuk> if not, that was an amazing piece of annual timing for a pancake joke
<slangasek> apparently so :)
<LaserJock> slangasek: no, I didn't file one as I don't have the packages finalized
<LaserJock> *package
<slangasek> LaserJock: oh.  I guess that means I can't give you an FFe by 6 today
<LaserJock> slangasek: why did you want it by 6 today?
<slangasek> LaserJock: because after 6, I'm not available to approve it until tomorrow :)
<LaserJock> slangasek: 6 pacific time or central?
<slangasek> pacific
<LaserJock> so 7 min
<slangasek> :)
<LaserJock> hmmm, that's rather tight
<slangasek> as opposed to -113 min
<slangasek> LaserJock: don't sweat it
<LaserJock> well, let me work on it and get it done now
<LaserJock> if I get it in 7min fine
<LaserJock> if not tomorrow will due
<LaserJock> :-)
<LaserJock> I need to get this bugger out the door
<LaserJock> I've already spent quite a few hours digging through CVEs and inline patches
<Keybuk> hmm
<Keybuk> today's daily live is unwell
<slangasek> known ubiquity bug, milestoned
<Keybuk> the fork-bombing nautilus?
<slangasek> install python-numpy by hand before invoking ubiquity if you want to use it
<slangasek> oh, no, that's not what other people reported with it :)
<StevenK> Nautilus now fork-bombs the system?
<Keybuk> seems to
<Keybuk> I get about 1,000 little "Starting File Manager" things along the bottom
<StevenK> Ow!
<slangasek> StevenK: it was mentioned in reference to update-manager mem usage, and didn't want to be outdone
<StevenK> Bwaha
<slangasek> Keybuk: can you spot any obvious reason why the fix in bug #291752 was wrong?
<ubottu> Launchpad bug 291752 in cryptsetup "[regression] cryptsetup does not work on raw encrypted drives" [Critical,Confirmed] https://launchpad.net/bugs/291752
<slangasek> Keybuk: checking for the device node, but not checking that vol_id returns something meaningful for the device, caused a regression for at least one user who says his crypted rootfs doesn't mount right anymore in intrepid
<maco> StevenK: no, i dont. just / and /home. i have to apt-get clean after each round of updates because i have gnome and kde installed and that leaves only 1gb for updates...which it is very easy to hit
<Keybuk> slangasek: the vol_id check in the initramfs?
<Keybuk> that's probably important
<cjwatson> hmm, evand fixed that ubiquity bug in bzr but didn't upload
<cjwatson> guess I'd better do that now so that it makes the next daily build
<slangasek> Keybuk: I gather that it is important, but can you explain to me why checking for the device node isn't sufficient?  There are two opposite use cases here, and while the short term fix is probably to revert to the intrepid-release handling, I'd like to get a handle on a more complete fix
<StevenK> cjwatson: I saw the commit message that added -numpy, and then he fixed the code, does it still depend on numpy?
<Keybuk> device node can exist, but have no filesystem inside it, because other things need to do magic
<Keybuk> e.g. md and devmapper devices
<Keybuk> the device node shows up when you create the name
<Keybuk> before you load the table
<slangasek> Keybuk: aha
<slangasek> that makes perfect sense then
<cjwatson> StevenK: haven't checked, but will
<Keybuk> so you need to check
<Keybuk>  1. does the device node exist? [ -e ]
<Keybuk>  2. has udev finished with it? udevadm settle
<Keybuk>  3. has it got a filesystem inside it? vol_id
<slangasek> yep
<slangasek> thanks, that tells me what I need to know
<Keybuk> hmm, u6y hangs at the partitioning stage now
<cjwatson> StevenK: dependency is all gone
<StevenK> cjwatson: Yay
<cjwatson> (r3057)
<StevenK> cjwatson: The changelog still mentions adding the dependancy
<cjwatson> easily fixed
 * Keybuk decides to go to bed
<Keybuk> I'm now too tired to test this, and it's only 38% through installing
<Chipzz> gn Keybuk :)
<cjwatson> Keybuk: I *think* that might be fixed by ubiquity in bzr
<cjwatson> I guess we'll find out tomorrow
<RAOF> You know, evolution is stupendously bad at handling my imap folder with ~200K emails in it.  How would one debug "spends 30minutes thrashing the disc when updating message list"?
<TheMuso> arthur-: Probably worthwhile archiving some of that mail. :) I am finding even mutt is starting to chug with big Maildir boxes, granted this is over a network, but still.
<TheMuso> RAOF: ^^
<TheMuso> arthur-: sorry
<RAOF> Heh.
<RAOF> I'm guessing it's something to do with evolution's new sqlite-backed folder thingies; it used to handle this pretty well.
<lifeless> RAOF: grab evo trunk
<lifeless> RAOF: that was bugfixed
<RAOF> lifeless: Sweet.  And will be in Jaunty release, because trunk is going to become 2.26?
<Caesar> Hey, is there anything documented anywhere about exactly how and when the cessation of support for Dapper is going to be done?
<Caesar> Like I know the LTS gets 3 years of support on the desktop
<Caesar> So that means sometime in June it runs out
<Caesar> So what will still get support (i.e. server-wise) after that date?
<ScottK> I think that's a good question.
<lifeless> RAOF: one hopes, don't know for sure.
<ScottK> My personal theory is that anything that needs X is toast.
<TheMuso> Is it just me, or is there no logout/restart menu options in the GNOME system menu any more?
 * TheMuso keeps doing keystrokes to get there, always forgetting they are not there, and ending up in about Ubuntu
<RAOF> I see that to, although was blaming gdm-new for it.
<firefly2442> Caesar: server is apparently 5 years as per this page: https://wiki.ubuntu.com/Releases
<TheMuso> RAOF: No, its either a gnome-panel, or gnome-session bug I think.
<Caesar> firefly2442: yeah, but what constitutes "server"?
<TheMuso> More likely gnome-panel
<firefly2442> Caesar: ahh I see the issue
<Caesar> And when in June 2009 does desktop EOL?
<Caesar> June 1 or June 30?
<pwnguin> heh, it's just a bug in the X "server" ;)
<Caesar> These sort of things aren't clearly spelled out (at least not on that page)
<cjwatson> Nick Barcet was working on that, specifically on creating full lists of packages
<cjwatson> I don't know where he put the output though
<cjwatson> nijaba: ^-
<ScottK> I'm also curious if the packages will be removed (as is normally done for an obsolete release) or left on the mirrors.
<maco> TheMuso: FUSA
<TheMuso> maco: FUSA?
<maco> TheMuso: no more shut down in the menu because it was duplicating FUSA
<cjwatson> I don't think we're likely to be able to remove them in any sane way
<cjwatson> perhaps unfortunately, but there it is
<TheMuso> maco: But what is FUSA?
<cjwatson> removing them would require regenerating all the index files and other such invasive things
<TheMuso> YOu say they duplicated FUSA, so I am confused.
<TheMuso> Oh!!! Fast switch user applet
<maco> there ya go
<TheMuso> grrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1
<TheMuso> oops sorry
<maco> was called away for "this thing in the fridge that's been here for weeks..what is it?"
 * TheMuso goes to another window
<maco> (it was vegetable sushi)
 * TheMuso digs for a gconf key.
<firefly2442> I have a general development question, how does Ubuntu deal with people contributing who live all over the world? It must be difficult for people who are able to contribute code but lack the communication skills because of a language difference to "sync" into the project and where it's headed.
<cjwatson> people do need to have some English ability, in practical terms (if nothing else they need to be able to read everyone else's code, including comments)
<cjwatson> and we do need to be fairly tolerant of language barriers, although yes it can be challenging
<cjwatson> local groups help a bit
<cjwatson> most of the practical problems we see are timezones and just plain not being in the same room
<firefly2442> cjwatson: so in you're opinion would you say text based communication is a major hindrance to OSS communication and development?
<maco> firefly2442: better shot with text than spoken
<Hobbsee> firefly2442: not a lot of the time
<maco> at least text has google translate
<maco> and many of the people around here are polyglots so finding someone that speaks your language and can pass on a "hey i have this patch that fixes ____" messages shouldnt be hard
<maco> i cant think of any programming languages that aren't english-based though, so i would guess if you can program you know at least a few words of english....like integer
<cjwatson> firefly2442: that's a bit of a leap from what I said :-)
<cjwatson> I agree with maco's comments
<firefly2442> ahh ok thanks, I'm just curious because I'm looking into OSS community management for a paper
<cjwatson> certainly I've seen a number of instances where it was very difficult to communicate with somebody in person, but e-mail allowed them to spend more time composing their words
<cjwatson> so in fact I actively disagree that text-based communication is a hindrance
<TheMuso> Yay, tweaking a gconf key and removing the fast user switch applet got some sane options back. Now, how to replicate that for a11y profiles in casper... :|
<firefly2442> good point, people are probably more apt to spend a long time composing a thoughtful email than just saying whatever pops into their head
<cjwatson> well, some people may simply be unable to follow and participate in a spoken conversation
<cjwatson> that requires better English skills than following and participating in a written conversation
<cjwatson> (I generalise a bit but I think this is mostly pretty uncontroversial)
<cjwatson> speaking of timezones: /me -> bed
<firefly2442> cjwatson: night, thanks for the suggestions
<firefly2442> I should probably head off too, thanks all
<maco> haha oh yeah, text communication in a 2nd or 3rd lang is much easier than in person
<ScottK> Do we have a standard package to substitute when a Debian package depends on locales-all?
<maco> is this back to the thing where locales are trying to bring half of gnome into kubuntu?
<ScottK> No, this is a package in universe that's depwait for locales-all because we don't have such a package.
<slangasek> huh, why do we patch out locales-all?
<slangasek> OTOH, why does any package build-depend on it, I think there's a recipe for generating locales for local use as part of a build?
<LaserJock> phew, finally got a Jaunty VM up-and-running again
<maco> LaserJock: can you IM me? like, the not-IRC way. i'm trying to see what pidgin's doing
 * LaserJock status update-manager
<LaserJock> *stabs
 * maco joins in and stabs pidgin
 * highvoltage <3 pidgin
<ScottK> slangasek: rmadison locales-all produces a blank stare in response and bgoffice-computer-terms is the package that build-dep on it.
<ScottK> Since i386 is caught up I was looking for arch all fixes I could throw at the buildd's.
<grndslm> does the liveCD every use the HD, say a HD that already has a 1GB swap partition??
<grndslm> ... or must everything be done in RAM?  I'm guessing this one
<ScottK> \o/ - Just filed a sync request for Spamassassin.  It will be the first time since Dapper we've been in sync.
<LaserJock> congrats
<ScottK> Thanks.
<maco> gnyes itll use existing swap
<maco> grndslm: yes itll use existing swap
<grndslm> kk... i figured it ought to
<grndslm> one more question i've asked before, but didn't ask properly...  how do various ubuntu repositories work?  For example, if I only want to accept security upgrades & not feature upgrades... will the feature upgrades still creep into the security repository??  Downloading the entire package for any upgrade confuses the heck outta me.
<maco> security just has security updates. updates has bug fixes.
<maco> well it's possible that a security update will be newer than whats in updates
<grndslm> maco:  i get that much.... but eventually, they've got to start converging, right?
<maco> but updates isnt features, just bug fixes
<grndslm> hmm... so the regular repository is where feature upgrades come in?
<ScottK> Post release, except for a very few exceptions, we don't do feature updates.
<maco> no they dont at all
<ScottK> We do those in the next development release.
<maco> we dont do version upgrades post-release unless there's a very good reason....like massive amounts of security patches that can only be gotten up changing versions
<grndslm> interesting
<ScottK> The one other sort of exception is kernel patches to support newer hardware on LTS releases.
<maco> so if big glaring security problems and bugs require patching such that half the code changes anyway...then an upgrade might happen
<maco> ScottK: when did that start?
<ScottK> It was done some for 6.06.2 and more for 8.04.x
<ScottK> It became clear that "LTS, but will only run on two year old hardware" wasn't going to fly.
<maco> haha
<maco> i see
<grndslm> one last question... inspired by the ubuntu forums...  when will ubuntu come out with a rolling release model?  =-P
<grndslm> to heck with separate security and bug-fix repos
<maco> grumpy groundhog?
<grndslm> that long?
<grndslm> that's like 23 releases away
<maco> no, thats the name for the mythical "if you use everything as soon as it hits the repos"
<maco> if ubuntu had something akin to debian experimental, that's the name that was chosen. it hasnt actually happened.
<maco> youd have to just go for debian sid
<grndslm> never thought about that
<maco> AFAIK there are no plans to go Arch-style
<grndslm> i still like ubuntu's hardware setup better... even more sane defaults than debian.  I couldn't get an intel wireless chip to work with debian outta the box... had to wait for ethernet!
<grndslm> but I'll prolly have to check out debian sid and arch pretty soon
<maco> i couldnt get ethernet to work on windows outta the box...had to wait for sneakernet! :P
<maco> well anyway if intel's firmware was open, we'd be good
<maco> though i do have to wonder how long ago this was
<maco> because i though with the iwl* drivers that binary firmware problem was gone
<grndslm> i just tried debian 5.0 and no go on my laptop
<maco> oh ok ..that should have iwl, i would think...
<grndslm> i was pretty sure intel was supposed to have open drivers, which is why I've always bought Intel-based lappies
<maco> yes the drivers are open
<grndslm> but the firmware isn't?
<maco> its the firmware and i think some sort of firmware-controlling daemon that aren't
<maco> right
<grndslm> more confusion
<maco> im not sure how much more was opened in the ipw --> iwl transition
<grndslm> anyway, i'll let you guys get back to work  ;)
<grndslm> lata
<grndslm> oh yea, about the liveCD issue... if the hard drive only has windows installed, then it can't use the HD, right?
<maco> right
<grndslm> figures...
<grndslm> aight, i'm really out this time
<grndslm> take it e-z
<ScottK> Did the publisher run last time?  It seems like there stuff still "ACCEPTED" that was done well before 3 after.
<LaserJock> is apache2-mpm-prefork the "default" apache package?
<slangasek> it's the one required for use with libapache2-mod-php5
<StevenK> LaserJock: If you need php or a non-threaded apache, go -prefork, otherwise, pick -worker
<LaserJock> I need PHP unfortunately
<LaserJock> well, neither help me out I guess
<StevenK> Why?
<LaserJock> I'm trying to force either mysql or postresql but apache pulls both in
<LaserJock> so then things get messed up
<slangasek> hrm?  apache does?
<LaserJock> through aprutil
<slangasek> ah
<LaserJock> aprutil deps on mysql, postresql, and sqlite
 * slangasek tricks upstream into also depending on odbc
<LaserJock> there isn't a way to test what packages are also being installed in postinst is there?
<slangasek> no
<StevenK> slangasek: And Oracle, for good meaurse?
<slangasek> StevenK: sure, why not
<slangasek> StevenK: just the server though, not the client libs
<LaserJock> I'm sort of close to picking a DB and telling everybody else to go figure it out
<slangasek> LaserJock: dbconfig-common?
<LaserJock> ah, well, I haven't looked at that yet
<LaserJock> we were using wwwconfig-common
<slangasek> ah
<LaserJock> but the vast majority of the bugs are due to DB setup issues
<slangasek> wwwconfig-common suggests: apache | apache-ssl.  Vintage. :P
<LaserJock> moodle is often uninstallable in Intrepid
<LaserJock> upgrades seems to be breaking decently often
<slangasek> is it really appropriate to fix all of this at the same time as fixing the security vulns, though?
<LaserJock> well
<LaserJock> for me personally I'm just trying to get a good, installable version of moodle for Jaunty
<LaserJock> the security stuff is a added benefit
<LaserJock> right now it's uninstallable for most (if not all) people
<LaserJock> so for a Main app I'd think that'd be an issue
<LaserJock> but I'm just a chemist and working with server/webapp stuff is not trivial for me :(
<LaserJock> it sure looks like dbconfig-common would help us out
<slangasek> LaserJock: but I think refitting it with dbconfig-common is beyond the scope of the merge request that's currently targeted for alpha-5
<dholbach> good morning
<Nightrose> hello
<maco> hello dholbach
<dholbach> hi maco
<grndslm> Is there any more firmware/drivers that jockey enables besides Nvidia, Ati, Broadcom, & Atheros... specifically in terms of networking?
<slytherin> pitti: next time you refresh ubuntu-meta, can you please take care of bug 331256.
<ubottu> Launchpad bug 331256 in ubuntu-meta "Please remove libpt-1.10.10-plugins-* from ubuntu-desktop dependencies" [Undecided,New] https://launchpad.net/bugs/331256
<grndslm> can somebody help me figure out what restricted firmware/drivers jockey enables??  /usr/bin/jockey-gtk doesn't seem to be helping me much
<slytherin> grndslm: take a look at files in package jockey-common. It should contain one handler for each of the driver category.
<grndslm> slytherin:  sweet... thanks
<grndslm> soo... it's just b43 (and how is that different from broadcom_wl?), fglrx, nvidia, & sl_modem for software modems??
<grndslm> it doesn't even handle madwifi?
<grndslm> I guess madwifi prolly isn't good enough to be in jockey, tho... which kinda makes sense now
<grndslm> still... what's the difference between b43 & broadcom_wl ??
<grndslm> ahem.. slytherin
<slytherin> grndslm: I have never heard about broadcom_wl, is that new driver in latest kernel?
<grndslm> i'm on 8.04.2
<grndslm> it's in /usr/share/jockey/handlers
<directhex> grndslm, /usr/share/jockey/handlers/broadcom_wl.py exists in intrepid
<directhex> and jaunty
<grndslm> directhex:  i wouldn't doubt it... i'm trying to find out how that's different from the b43-fwcutter
<slytherin> grndslm: I suppose it is just the name that is changed. And probably it has handling for b43legacy and b43. In hardy there was only one driver for all cards if I remember.
<directhex> slytherin, /usr/share/jockey/handlers/b43.py also exists on jaunty. why we have two, i dunno
<grndslm> slytherin: there's b43 & b43legacy in my /lib/firmware/
<grndslm> on hardy
<slytherin> wait, I remember now. broadcom_wl is new driver and it is different from b43.
<slytherin> grndslm: the best person to ask is pitti. But he seems to be away at the moment.
<grndslm> i guess i'll just drop him an email and see what he says
<directhex> fighting crime from his orbiting skyship, no doubt
<davmor2> are any of the notifyosd guys around?
<seb128> don't ask to ask just ask?
<seb128> who do you call notifyosd guys? you don't accept reply from non notifyosd people who know about what you would ask there?
<davmor2> seb128: I suppose anyone can answer but I thought they would have a better working knowledge of what was supported and not
<seb128> hard to say since you don't ask your question
<seb128> we could avoid such pointless discussions if you just ask what you want to know
<seb128> sorry for the rant there ;-)
<davmor2> I'm having an issue with pidgin not triggering notifyosd but I'm not sure if irc is supported by it yet
<seb128> no it doesn't work on IRC
<davmor2> seb128: and in future I'll just ask, thanks dude
<seb128> you're welcome
<seb128> see it's easier this way ;-)
<davmor2> also seb128 any idea why it seems to put an envelope in the system tray I thought that was for evo when you got mail
<seb128> that's the message indicator
<seb128> it's there if you have evolution or pidgin running
<davmor2> I don't have evo open only pidgin
<seb128> and the icon should change when you get a message
<seb128> well in this case you should have pidgin listed when clicking on it no?
 * directhex is still sad @ the idea of not having a "next track" button on banshee popups
<davmor2> yes that's correct :)
<davmor2> thanks again
<maco> hey by the way, is it a function of the new notification system that pidgin's buddy list is now invisible for me (not in window list or alt+tab) since i manually turned off system-tray-icon or is this a bug?
<TheMuso> Hrm. Where did /etc/adjtime go? I see base-files creates it in its postinst, but none of my jaunty systems have it, and a powerpc alternate install fails because powerpc-utils can't find it.
<seb128> maco: is it open on screen?
<maco> seb128: by invisible, i'm not joking. it must exist somewhere...it flickers into visibility for a moment when i quit it. its certainly running since there are notifications and i can receive messages...but the window itself seems to be hidden somewhere that i can't un-hide it
<maco> the notification/tray icon had a "hide buddy list" feature
<seb128> maco: did you try to select pidgin the message indicator menu to open it?
<maco> im in kde
<seb128> +in
<seb128> maco: well you did shoot yourself in the foot apparently then
<maco> hahaha
<seb128> maco: ie you turned the notification icon but don't use the message indicator and don't run the right desktop environment
<maco> i get the notification icon for notifying of new messages, however i was under the impression that setting pidgin to not live in the tray meant that it would not attempt to hide, ever
<seb128> wrong impression
<maco> >< crap
<davmor2> seb128: any idea how the envelope should change other than listing the chat and time?  should the flap open or something?
<seb128> davmor2: not sure, the icon should be different but that might be buggy right now
<slytherin> seb128: just FYI ... I updated gst-plugins-bad-multiverse to bring in sync with -bad, will update ugly-multiverse sometime this week.
<seb128> slytherin: cool
<davmor2> seb128: I'd of thought that changing it to an open envelope would of made sense for unanswered messages in case your away at the time.
<slytherin> seb128: I also added some arguments to configure in debian/rules to disable some plugins that get by default but are not included in the package. Reduces build time a lot.
<seb128> oh good too
<cjwatson> TheMuso: see util-linux changelog
<cjwatson> Keybuk: ^- powerpc-utils is a difficult one - without having looked I suspect it's coping with known problems on powerpc systems where the firmware time gets reset to the Mac epoch on battery failure, or some such. Do we really need to delete /etc/adjtime, rather than just deleting the code that used it?
<Silicium> from where is the Default Nautilus-Desktop Background Color loaded if its not set in gconf?
<seb128> Silicium: what do you call nautilus-desktop background color?
<seb128> it's an image by default
<Silicium> nautilus/gdm ans so on
<Silicium> the color i see between GDM and finaly loaded gnome
<Silicium> this is the "background color" set in the settings
<Silicium> but i cant find it in the gconf of liveCD
<Silicium> may is hardcoded?
<Ng> Keybuk: so if jaunty is failing to assemble a root LVM after last night's udev/lvm updates, what would you want/need to know? :)
<seb128> Silicium: it's a gdm.conf setting
<Silicium> ok thanks
<seb128> that will be changed soon
<ogra> asac, why does my FF open a ton of windows after the last upgrade ? (add-ons, the print dialog)
 * ogra could understand add-ons to make him chek if everything is still ok, but why the print dialog ? 
<directhex> ogra, you don't print a copy of the "your firefox has been upgraded" screen for your wall?
<asac> ogra: dont know about the print dialog
<asac> ogra: the addons dialog opens when there have been addons upgraded/disabled
<ogra> directhex, i do ! but the wall is full :P
<ogra> asac, yeah, thats what i suspected, but the print dialog is a bit strange
<directhex> ogra, phoenix 0.6 has been upgraded!
<asac> ogra: maybe print dialog opened because the "random menu item activates" bug?
<asac> did you click somewhere before it popped up?
<ogra> no, i rebooted and started FF, evo and xchat
<asac> ogra: heh. so maybe it wasnt firefox print ;)?
<ogra> from the panel where i have shortcut icons
<ogra> well, FF came up with it, evo usually takes a while
<ogra> and i dont think chat has any print dialog
 * ogra checks
<asac> ogra: ok. let me know if you can reproduce the print thing
 * ogra logs out again
<ogra> hmm, add-ons again ... no print dialog
<ogra> whoops !
<mdz> mvo: I see no notification icon for update-notifier anymore in jaunty; is this part of the new notification system changes?
<ogra> i was wrong, FF blinked in the tasklist after xchat came up, clicking the task entry shows the print dialog
 * ogra tries a third time
<mvo> mdz: yes, this is what the design team asked for. no icon, just update-manager starting up automatcially for updates every 7 days (and immediately for security updates)
<mdz> mvo: :-(  where should I send my feedback?
<mvo> mdz: there is a long debate on ubuntu-devel about it
<mvo> mdz: there is also a gconf key to get the old behaviour back
<ogra> asac, hmm, apparently reliably reproducable ...
<ogra> i get the print dialog on every login in FF now
<mvo> mdz: and yes, I like the icon too
<ogra> andthis time i only started FF
<ogra> i also seem to get the add-on dialog every time now
<mvo> mdz: seb128 had the idea that we keep showing the icon but auto launch after 7 days if it was not clicked. I like that proposal
<asac> ogra: do you stop your FF sometimes? or always just "log-out"?
<ogra> asac, the latter
<ogra> i want to keep my session
<ogra> without saving it
<asac> ogra: please check your localstore.rdf
<mdz> mvo: the restart dialog popping up all the time is also excessive
<asac> ogra: does it a) have proper permissions, b) a recent modification time, c) contain any hints about the print dialog?
<ogra> ogra@osiris:~$ ls -l /home/ogra/.mozilla/firefox/x1utrcmr.default/localstore.rdf
<ogra> -rw-r--r-- 1 ogra ogra 10296 2009-02-24 11:01 /home/ogra/.mozilla/firefox/x1utrcmr.default/localstore.rdf
<ogra> ogra@osiris:~$ grep print /home/ogra/.mozilla/firefox/x1utrcmr.default/localstore.rdf
<ogra> ogra@osiris:~$
<ogra> doesnt look like
<asac> ogra: -i ?
<asac> hmm
<ogra> nope
<ogra> -i doesnt change it
<asac> ogra: what extensinos installed?
<ogra> grab n drag and ubufox
<seb128> mdz: "all the time"? you probably had a broken upgrade which it's trying to reconfigure and which is breaking again or similar?
<mvo> mdz: right, all actions that used to show notifications are now launched directly (including reboot, interactive upgrade hooks etc). some concerns on the ML about this include that stuff that opens out of the blue will remind windows user of spyware/viruses (where this apparently happens too)
<mdz> seb128: no, I just haven't rebooted
<asac> ogra: disable g&d?
<mdz> and so each time I upgrade, the dialog pops up
<seb128> mvo: btw any clue about bug #333557?
<ubottu> Launchpad bug 333557 in python2.6 "pygobject/python2.6/dpkg upgrade failure" [High,Confirmed] https://launchpad.net/bugs/333557
<mdz> mvo: is there a bug open about this?
<mvo> mdz: about the dialog comming up all the time? or the new behaviour in general?
<mdz> mvo: either, or both
<mdz> should they be considered separate issues?
<mvo> seb128: I have a look, but it looks like a simple file conflict?
<ogra> asac, no change
<mvo> mdz: there is a bug about the new behaviour, give me a sec I look for the number. update-notifier gets bugreports about it all the time basicly, because people think its broken (no icon anymore)
<seb128> mvo: I don't think so, look at the path that's not a full one and those are not conflicting
 * ogra wonders if there is any evil javascript on a website that triggers it, nut i didnt have it on yesterdays upgrade
<ogra> *but
<asac> ogra: err. you have zillions of tabs?
<ogra> and the list of pages didnt change much
<mvo> seb128: I suspect it has something to do with the new shared location to install stuff, but i will have a closer look in a bit
<ogra> yes, a bunch, but since yesterday only some LP tabs were added
<ogra> and i rebooted yesterday as well
<seb128> mvo: thanks
<seb128> $ dpkg -c /var/cache/apt/archives/python-gobject-dbg_2.16.1-0ubuntu1_i386.deb | grep gobject.so
<seb128> -rw-r--r-- root/root    243986 2009-02-23 11:44 ./usr/lib/debug/usr/lib/python2.5/site-packages/gtk-2.0/gobject/_gobject.so
<seb128> -rw-r--r-- root/root    246472 2009-02-23 11:44 ./usr/lib/debug/usr/lib/python2.6/dist-packages/gtk-2.0/gobject/_gobject.so
<seb128> -rw-r--r-- root/root    333165 2009-02-23 11:44 ./usr/lib/python-support/python-gobject-dbg/python2.6/gtk-2.0/gobject/_gobject.so
<seb128> $ dpkg -c /var/cache/apt/archives/python-gobject_2.16.1-0ubuntu1_i386.deb | grep gobject.so
<seb128> -rw-r--r-- root/root    122172 2009-02-23 11:44 ./usr/lib/python-support/python-gobject/python2.6/gtk-2.0/gobject/_gobject.so
<seb128> -rw-r--r-- root/root    121756 2009-02-23 11:44 ./usr/lib/python-support/python-gobject/python2.5/gtk-2.0/gobject/_gobject.so
<seb128> mvo: ^
<seb128> see no conflict
<ogra> doko, is our java built with freetype support ?
<mvo> mdz: about the auto launching, bug #331054 and #332945 are probably interessting (both already closed as invalid though)
<ubottu> Launchpad bug 331054 in update-notifier "Do not launch in background" [Undecided,Invalid] https://launchpad.net/bugs/331054
<ubottu> Launchpad bug 332945 in update-notifier "[Jaunty] Removal of Update Notifier is WRONG" [High,Invalid] https://launchpad.net/bugs/332945
<mvo> mdz: there is also the mailing list discussion
<mdz> mvo: thank you
<mdz> mvo: I'm bringing it to the attention of the design team
<mvo> mdz: I think it has there attention already :)
<mvo> mdz: i.e. they replied in it
<liw> mvo, do-release-upgrade has no manpage?
<mvo> liw: no :(
<mvo> liw: I should attend to your manpage write course
<liw> mvo, that needs fixing one of these days... I'll gladly help :) in the mean while, is there a way for me to instruct it to not check for free disk space? my chroot doesn't have /proc mounted
<mvo> liw: unfortunately not. could you just mount /proc as a workaround? (mount or bind mount)?
<mvo> liw: I plan to add some switches soonish
<mvo> liw: do make it possible to have more control, but currently its a bit set-in-its-ways when it comes to that
<liw> mvo, I can mount /proc, no problem, it's just slightly less convenient to have to do that (when creating, testing, and destroying chroots)
<mvo> liw: ok, I will make it a option for you later today, ok?
<liw> mvo, nah, don't worry, I've adapted already, no need to hurry this
<liw> apropos the manpage thing: I gave a presentation in Finnish on it, so perhaps I'm ready to give one at the next UDW or something (uds?)
<liw> although I'm sure Colin would hate my style of manpage writing :)
<liw> oops
<liw> the things you do when you're used to using kvm instead of chroot... I let do-release-upgrade reboot, and it rebooted the whole computer, of course, not just the chroot
 * liw waits for the desktop to boot (root is on usb, so it's very slow to boot) and ponders aliasing chroot to kvm
<doko> ogra: what do you mean? java has it's own selection scheme for fonts
<ogra> doko, http://sourceforge.net/mailarchive/forum.php?thread_name=892226.3959.qm%40web62005.mail.re1.yahoo.com&forum_name=ltsp-discuss
<ogra> doko, see the last mail, we have a longstanding issue with ltsp where java gets unusably slow on remote X connections, appartenly only installing a fontserver solves that, i was wondering if thats solvable in a better way
<dholbach> everybody welcome rcmorano - he's from Guadalinex and doing great work on Ubuntu too!
<rcmorano> :]!
 * ogra waves to rcmorano 
<LLStarks> morning
<Ng> Keybuk: tracked it down... for some reason the initramfs had something wrong with its cryptroot hook. re-generated it after doing a manual cryptsetup+boot and it works again. bit weird that that happened though
<TheMuso> cjwatson: thanks
<LLStarks> themuso
<LLStarks> pulse 0.9.15 is a resource hog.
<TheMuso> LLStarks: talk to upstream about it
<TheMuso> LLStarks: tried turning off glitch free?
<LLStarks> eh?
<LLStarks> i'm just using whatever you packed.
<TheMuso> LLStarks: Yes, but I only made that package available for testing, expecting people would go to upstream and report problems. The only thing thats different is a few settings changes to better suit Ubuntu.
<liw> dholbach, the next UDW is sometime during the summer, yes?
<dholbach> liw: yes
<liw> dholbach, six months from January 19 would be July 19.. do you have exact dates already?
<dholbach> liw: no
<liw> dholbach, I'm asking so that I can plan my summer so that if possible, I can give the manpage writing tutorial :)
<dholbach> sorry, no dates yet
<liw> dholbach, no worries, I realize it is very early for that
<dholbach> :-)
<directhex> UDS is may, isn't it?
<liw> directhex, yes
<directhex> oh balls..... wife's birthday......... even if i can get sponsorship, i don't know if it's wise to play that particular card
<cjwatson> I've implemented the changes described in https://lists.ubuntu.com/archives/ubuntu-devel/2009-February/027427.html. Please let me know if there are any problems
<directhex> seems sound to me, cjwatson
<PecisDarbs> is new gdm theme is oficial? :)
<pitti> grndslm: hey
<pitti> grndslm: madwifi is handled, but not with a special handler
<pitti> grndslm: I have a bug about that
<pitti> grndslm: the b43 handler does use b43-fwcutter, it doesn't reinvent the wheel
<pitti> grndslm: so what's your question?
<pitti> slytherin: thanks for pointing out
<alex-weej> is gdm2 going to be in 904?
<seb128> alex-weej: no
<seb128> alex-weej: it's available in the desktop team ppa as gdm-new if you want, might to universe but we have no interest to switch by default, it brings nothing to use and add quite some limitations
<alex-weej> oh ok
<alex-weej> i used it on fedora 10 the other day and thought it actually looked more featured, but i didn't really dig into it
<Silicium> is there a channel for questions who can answered in #ubuntu?
<Silicium> so then i dont need to ask it here...
<Silicium> s/can/can't
<cjwatson> if you mean "which can't be answered", then you could try #ubuntu+1, but if they can't help then that is still not a valid reason to ask here
<alex-weej> Silicium: you could always try http://answers.launchpad.net/ -- that way your questions won't be lost after about 5 seconds when they scroll off the buffer ;)
<cjwatson> if IRC can't help, try mailing lists, web forums, answers.launchpad.net, or a bug report if that's appropriate
<Silicium> cjwatson: thats to slow
<Silicium> :/
<cjwatson> Silicium: I'm afraid that still doesn't justify asking here
<Silicium> :D
<Silicium> so, i actually dont want everytime use this chan
<alex-weej> seb128: i take it it breaks FUSA and guest session then
<seb128> alex-weej: that yes
<seb128> alex-weej: it also has no gdmsetup = no way for user to enable autologin or timedlogin
<seb128> alex-weej: it has no settings migration, no theme support
<Silicium> argh damn shiat
<alex-weej> i see. is it actually even considered ready yet?
<alex-weej> (by upstream)
<seb128> alex-weej: GNOME ships it since 2.24
<seb128> alex-weej: it doesn't add useful features over the old version out of some bling (fading, etc) but some things are not there yet, we don't think changing would benefit our users
<seb128> alex-weej: and we got too many complain about GNOME breaking things (gnome-session-saving, audio, etc) recently, we want a "stable" cycle and not another flameware about new rewrittes dropping useful feature for no user win
<alex-weej> sure, you don't need to defend yourself, i understand :)
<alex-weej> (but saying what you just said... notify-osd seems to have ruffled those exact same feathers)
<seb128> alex-weej: I'm just explain the choice not defending myself there ;-)
<apw> pitti, seems there are a few niggles with apport suspend/resume still.  i've pushed up a couple more fixes, merge proposal here: https://code.launchpad.net/~apw/apport/suspend-resume/+merge/3899
<doko> mvo, seb128: any clues about the python-gobject-dbg/dpkg conflict?
<seb128> doko: no
<seb128> I'm pretty sure that's not a python-gobject issue though
<mvo> doko: I just ran it through my auto-upgrade tester and did not get it there
<seb128> nothing special changed there and my local build didn't have the issue
<seb128> mvo: do you have an uptodate jaunty, does apt-get install python-gobject-dbg works?
<doko> do you have python2.6 installed as well?
<seb128> doko: you have to since the current pygobject depends on it no?
<mvo> let me check via chroot
<Keybuk> cjwatson: it's only deleted if it's not being used
<Keybuk> since otherwise it gets written with increasingly random values on shutdown
<Keybuk> cjwatson: I didn't know base-files created it, it shouldn't
<pitti> apw: thanks, merged; running test suite now
<PecisDarbs> hi people, is there any plans to get rid of evolution-indicator dialog thingy in Jaunty? :) it drives me m(a)*d
<apw> pitti, thanks ... sorry for so many iterations, this thing is sooo hard to test properly without crashing kit every time
<pitti> apw: no problem at all :)
<pitti> apw: erm, you don't have a "fake" susres.crash for testing the UI?
<apw> pitti, ?
<pitti> apw: I mean you actaully have a machine where suspend fails, and do that to test the GUI?
<doko> seb128: no, doesn't. but it depends directly on python2.5, which it should not
<apw> pitti, na, i can fake everything to test the UI component
<cjwatson> Keybuk: doesn't it only get written on shutdown if you turn on that code? or is that unconditional?
<apw> but as i found with the last iteration if you don't actually crash it
<Keybuk> cjwatson: it was unconditional in the init script
<Keybuk> so I made it conditional on the existance of /etc/adjtime
<apw> you don't really run it quite the way that a crash does ...
<cjwatson> Keybuk: how do you propose to fix the powerpc problem? adjtime was actually a useful "this is a reasonable minimum time that it could possibly be"
<Keybuk> cjwatson: what _is_ the powerpc problem?
<NCommander> doko, should have openjdk-6 finished building on ARM? It's been going for a week, and I think it might be stuck in an infinite loop (the Debian build only took 3 days ...)
<pitti> apw: right, you should keep a real .crash file around and just cp it to /var/crash for UI testing
<cjwatson> Keybuk: I described it earlier
<Keybuk> cjwatson: i don't have an e-mail?
<Keybuk> (or a bug report)
<cjwatson> oh, hmm, maybe I misdescribed it though
<cjwatson> 09:33 <cjwatson> Keybuk: ^- powerpc-utils is a difficult one - without having looked I suspect it's coping with known problems on powerpc systems where the firmware time gets reset to the Mac epoch on battery
<pitti> apw: I'll do another fix, and then upload
<cjwatson>                  failure, or some such. Do we really need to delete /etc/adjtime, rather than just deleting the code that used it?
<cjwatson> Keybuk: you were replying to me so you clearly saw it :-P
<Keybuk> I just see the bits you say
<apw> pitti, cool
<Keybuk> I don't see how adjtime solves that
<Keybuk> adjtime is for dealing with drift between the two clocks
<Keybuk> not one clock always saying 1 Jan 1970
<cjwatson> base-files updates adjtime every upload to a reasonable minimum time
<doko> NCommander: which Debian build?
<cjwatson> I think Santiago just updates it to the current time or thereabouts
<cjwatson> we actually don't have anywhere else to say "hey guys, it's at least 2009" ;-)
<cjwatson> 09:16 <TheMuso> Hrm. Where did /etc/adjtime go? I see base-files creates it in its postinst, but none of my jaunty systems have it, and a powerpc alternate install fails because powerpc-utils can't find it.
<Keybuk> cjwatson: that doesn't fix the problem though
<NCommander> doko, openjdk-6 on Debian on armel took three days. The last upload to Ubuntu has been going for almost a week, and has been spitting out the message "Compiler still running" for most of that time :-)
<Keybuk> and would cause others, since suddenly hwclock would be using adjtime again
<doko> if it is based on the same package, then it looks like a problem. but imo these are the arm specific optimizations
<Keybuk> for everything
<cjwatson> it doesn't *fix* it, but sometimes a vague approximation of recent time is better than 1904
<doko> NCommander: which version was the Debian build?
<cjwatson> (which is the Mac epoch, and happens to be negative Unix time, which breaks some things in fun ways)
<NCommander> doko: 6b11-9.1
<cjwatson> Keybuk: calm down, I'm not saying "argh we must reintroduce adjtime" :-)
<Keybuk> one obvious solution is ntpdate ;)
<cjwatson> Keybuk: I think I may have misdescribed the powerpc-utils problem, though; it looks to me as if it ships an hwclock port
<cjwatson> Keybuk: one of the breakages caused here is that the desktop refuses to start :-P
<doko> NCommander: that's some months old ...
<cjwatson> anyway, I suspect what we actually need to do here is port powerpc-utils' clock to the new world order
<cjwatson> or figure out whether it can be thrown away in favour of hwclock
<Keybuk> right
<Keybuk> if we need minimum time support, that can be patched into hwclock itself
<cjwatson> maybe it could use the timestamp of its executable as a minimum time or something
<mvo> doko, seb128: I have the error now, I look at it
<seb128> mvo: thanks
<Keybuk> cjwatson: that's actually not bad idea ;)
<mvo> its pretty clearly a python-support issue it seems :/
<cjwatson> anyway, I think minimum time was a red herring in response to Luke's actual bug - I hadn't looked at the code yet when I brought that up
<cjwatson> so sorry about that
<seb128> mvo: I would guess so too
<NCommander> doko, I was asking if these kind of build times are normal.  openjdk-6 uploads on ARM have taken two days
<NCommander> doko, so I'm starting to wonder if something has gone horribly horribly wrong
<mvo> *sigh*
<mvo> yeah for two implementatons of the same
<liw> mvo, hmm, do-system-upgrade -d removes system-cleaner(-gtk), but doesn't install computer-janitor -- when I tested this earlier with apt-get dist-upgrade, it worked; should I introduce a transition package?
<cjwatson> powerpc-utils.postinst copies /etc/adjtime into /var/lib/hwclock/, apparently due to Debian #280605
<ubottu> Debian bug 280605 in powerpc-utils "/sbin/clock: Newer FHS require adjtime in /var/" [Normal,Closed] http://bugs.debian.org/280605
<cjwatson> and that's the thing that's actually failing
<Keybuk> heh
<Keybuk> btw. can base-files be made to not create /etc/adjtime on non-ppc machines?
<doko> seb128: python2.5 dependency is hardcoded in control.in. please remove it for the next upload
<doko> same for the -dev package
<seb128> doko: ok
<cjwatson> Keybuk: in principle sure but I suspect there is really no reason not to fix powerpc
<Keybuk> cjwatson: what I mean is, if base-files is creating it, then hwclock will use it unconditionally
<Keybuk> even on x86
<Keybuk> that's the reason it gets removed in the hwclock postins
<Keybuk> to stop it being used
<cjwatson> right, I'm just questioning the "on non-ppc machines" bit
<Keybuk> ah ok ;)
<soren> cjwatson: You have a local mirror, right? Does it also mirror all the installer bits? I can't seem to get debmirror to grab enough stuff to make jigdo happy.
<cjwatson> yes, it does
<cjwatson> ttp://paste.ubuntu.com/122373/
<cjwatson> http://paste.ubuntu.com/122373/
<soren> cjwatson: Aha!
<mvo_> seb128, doko: http://paste.ubuntu.com/122375/ - so now its just "lets fix pysupport (or switch to python-central ;)"
<doko> mvo: now quick, seb128 just left, lets switch to python-central ;)
<soren> cjwatson: That doesn't grab updated installers in -updates, does it?
<cjwatson> soren: nope
<soren> cjwatson: Alright. Thanks!
 * Keybuk has coffee now
 * cody-somerville has cranberry juice.
 * directhex has savaged his fingertip with a pair of pliars
 * Laney cannot figure out why n != S n'
 * Laney has to go mark first year undergraduate presentations now. wish me luck
<superm1> slangasek, can you poke the mythbuntu daily builds so we can get to checking for alpha5 rc?  it looks like a hash sum mismatch again from apt-get update again (http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/mythbuntu/jaunty/daily-live-20090224.log)
<superm1> slangasek, er well hold off i think.  looks like there is something wrong with clock-setup in the current ubiquity anyhow, so we'll need to wait for one more at least
<tjaalton> Keybuk: how come DM_TYPE can be empty? broke multipath here :)
<Keybuk> tjaalton: no idea?
<Keybuk> do you mean the table type?
<Keybuk> you can create devmapper devices with no table
<tjaalton> Keybuk: it used to work until I reinstalled the box today. kpartx rule doesn't finish
<tjaalton> device-mapper table, I guess
<Keybuk> I don't think anything's changed there recently?
<tjaalton> not there, but in udev?
<tjaalton> Keybuk: how did I get the debug info again, from busybox
<tjaalton> I mean the options for udevd
<Keybuk> tjaalton: --debug
<tjaalton> Keybuk: ok, DM_TYPE was exported by kpartx_id, and not having it in the image doesn't help :)
<tjaalton> s/was/would be/
<tjaalton> Keybuk: that didn't help much, the rule is still not finished. I suspect this has something to do with the inotify changes in udev/devmapper
<apw> is there a way to tell if a package is a standard seed.  i want to know if checkbox is a default install on desktop and server
<Keybuk> tjaalton: rule is still not finished?
<tjaalton> Keybuk: kpartx.rules
<Keybuk> oh, that's multipath-tools crack?
<Keybuk> has that _ever_ worked?
<tjaalton> yes
<tjaalton> yes
<tjaalton> :)
<Keybuk> why isn't it "finished" ?
<cjwatson> apw: apt-cache show checkbox, look for the Task field
<apw> so those are the tasksel tasks?
<tjaalton> Keybuk: you tell me :)
<tjaalton> I'd like it to reach the 'kpartx -a.. ' phase
<tjaalton> but it doesn't
<Keybuk> I don't know, i've never read that rule
<Keybuk> if it doesn't _reach_ something, then something before it is taking over three minutes
<tjaalton> it worked fine until the reinstall
<cjwatson> apw: yes
<cjwatson> apw: those are constructed by dependency-expanding seeds
<apw> cjwatson, rocking thanks ... yeah seen those in the germinating phase for CD creation, terifying
<savvas> is mvo responsible for the gdebi source package? or should I subscribe ubuntu main sponsors? there's a patch for bug 190907
<ubottu> Launchpad bug 190907 in gdebi "[kde] Applications cannot read Greek folder names" [Undecided,In progress] https://launchpad.net/bugs/190907
<Riddell> savvas: if it's for the KDE side you can poke me (subscribing ubuntu main sponsors a good idea too)
<mvo> savvas: thanks, you are quick :) I know about the patch, I think its good, but I need to look a bit closer. but if Riddell could have a look that would rock of course
<mvo> Riddell: if you think its fine, I apply it, it looks good to me, but I know much less about pykde than you :) I tried to contact martin.boehm too
<savvas> Riddell: ok, noted :)
<savvas> thank you both for reviewing it :)
<highvoltage> \o\ \o/ /o/ dholbach! \o\ \o/ \o/
<dholbach> highvoltage: hm? :-)
<highvoltage> sorry, just couldn't keep it in
<dholbach> hehe
 * dholbach hugs highvoltage
<directhex> there's one compelling reason to go to UDS
<Laney> booze?
<directhex> dholbach-hugging!
<davmor2> ice cream eating comp
<dholbach> :-D
<directhex> mmm ice cream
<grndslm> pitti, you still around?
<pitti> grndslm: hi
<grndslm> pitti: heya... whole reason i'm asking you about jockey drivers is because i'm trying to use remastersys to create a distro with [at a bare minimum] all the restricted drivers
<grndslm> soo... i know i need to install madwifi, b43-fwcutter, and is there anything else?  main question in the email is what's the diff between b43-fwcutter and broadcom-wl
<grndslm> pitti:  any hints?
<pitti> grndslm: I got your mail; do you prefer IRC or email answer?
<grndslm> honestly doesn't matter... irc since we're already here ;)
<pitti> grndslm: b43 and broadcom-wl are two totally independent drivers
<pitti> grndslm: wl is shipped in l-r-m (including firmware), b43 is in the main kernel (free module), but needs non-redistributable firmware (through b43-fwcutter)
<pitti> grndslm: so you should ship either
<pitti> grndslm: jockey also provides installation of nvidia and fglrx drivers
<grndslm> pitti:  i'm mostly worried about wireless for now, so then jockey can be used to setup graphics later
<grndslm> pitti:  what is l-r-m?
<pitti> grndslm: linux-restricted-modules
<directhex> linux-restricted-modules
<grndslm> ahh... so if i have l-r-m on hardy, i've already got the wl driver?
<pitti> grndslm: I think it was added to linux-backports-modules in hardy; please check the package contents and changelog
<pitti> could also have been l-r-m, though
<grndslm> pitti:  how do i change package contents & changelog? =D  and is it possible to install both graphics drivers and have the LiveCD just automatically choose one *after* installation?
<grndslm> *check pkg contents
<pitti> grndslm: dpkg -S /path/to/installed/file gives you the package which ships a filel
<pitti> grndslm: no, you can't *install* the graphics drivers, you can at most ship them
<grndslm> soo.. just have the debs already downloaded for both of them?
<pitti> first, the 4 nvidia drivers conflict to each other file-wise, and second they do a lot of fiddling with the OpenGL libraries, etc.
<grndslm> sounds about right
<pitti> same with fglrx
<pitti> you really only want to install this on systems which actually use fglrx
<grndslm> 4 nvidia drivers?  you mean different versions of the same nvidia driver?
<grndslm> any nvidia version should work on all gfx cards, eh?
<pitti> grndslm: right; unfortunately they all support a different set of models
<pitti> grndslm: unfortunately not; if that were so, we wouldn't have four in the first place
<grndslm> wow... never realized that
<grndslm> pitti:  is this the same wl driver we're talkin' about?  http://pastebin.ca/1345923
<pitti> grndslm: that one, yes
<grndslm> it's in linux-restricted-modules... so i guess i'm all good to go in the networking department then?
<grndslm> pitti:  no more wireless drivers i need to add?
<pitti> grndslm: we don't have other packages related to that, no
<pitti> grndslm: you might want to include ndiswrapper
<pitti> grndslm: jockey doesn't support it, but it's not terribly hard to set it up manually, or with ndisgtk
<grndslm> pitti:  it's useless without firmware tho isn't it?
<pitti> grndslm: s/firmware/a windows driver/
<pitti> but it provides the infrastructure to use the bits from windows driver CDs
 * pitti never used it so far
<grndslm> i'll never understand the difference between the two
<pitti> 3v1l
<Keybuk> cody-somerville: how does one check/set the keyboard layout in XFCE?
<pitti> grndslm: firmware runs on the device, a driver runs on your computer
<grndslm> i guess i should just install it incase somebody actually has their driver cd
<pitti> grndslm: well, "driver" usually encompasses firmware, too
<cody-somerville> Keybuk, in Jaunty?
<Keybuk> cody-somerville: in general
<cody-somerville> In Jaunty, Applications > Settings > Keyboard. Click the layout tab.
<grndslm> pitti:  i get that part, but how does downloading broadcom firmware & stripping it lead to a linux compatible solution?
<Keybuk> cody-somerville: where is "Applications" ?
<Keybuk> I have something that looks like a spanner on the task bar
<cody-somerville> Keybuk, Same place it is in Ubuntu - upper left corner.
<Keybuk> that has Settings
<Keybuk> and has Keyboard Settings
<Keybuk> but that has no "Layout"
<Keybuk> this is not Xubuntu, btw
<cody-somerville> What version of Xfce is it?
<Keybuk> cody-somerville: 4
<Keybuk> 4.4.3
<cody-somerville> Keybuk, You might have to add the keyboard layout switcher applet in 4.4
<grndslm> pitti:  thanks for the help, man!!  you're too good.
<pitti> grndslm: my pleasure, good luck with your project
<grndslm> but i gotta go for now, so ttyl
<grndslm> thanks!
<Keybuk> cody-somerville: I can't see such a thing in the list
<cody-somerville> Keybuk, xfce4-xkb-plugin is the ubuntu package
<Keybuk> cody-somerville: this isn't Ubuntu ;)
<cody-somerville> Well, I don't think 4.4.x supports that really. You could use xfce4-xkb-plugin but you'd have to define the list of layouts in xorg.conf.
<Keybuk> there's no xorg.conf here ;)
<cody-somerville> Keybuk, The latest version of xkb-plugin can use libxklavier
<cody-somerville> and there is always xfkc
<Keybuk> I don't really want to change this much
<cody-somerville> Keybuk, Then your only other option is to replace the actual keyboard :P
<Keybuk> cody-somerville: lol
<Keybuk> actually, I want to test whether moblin even lets you set a keyboard
<Keybuk> because I don't think it does <g>
<dholbach> seb128: chpe says r3325 of gnome-terminal fixes the memory corruption
<dholbach> gnome bug 572549
<ubottu> Gnome bug 572549 in general "Memory corruption in gnome-terminal" [Critical,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=572549
<seb128> dholbach: you have upload right feel free to backport the change ;-)
<seb128> I'm too busy to work on that today
<seb128> and we have a meeting in 11 minutes now
<seb128> dholbach: but thank you for keeping track of the issue ;-)
<dholbach> seb128: no worries, I'll do it
<seb128> dholbach: if nobody backport it next tarball are due in a week
<dholbach> right-o - I just want to try it myself and if it helps to save the work of others, it might be worth it :)
<seb128> thank you
<dholbach> seb128: you're lucky - gnome-terminal does not use quilt, so I'll add the patch ;-)
<seb128> dholbach: he he, it might be using bzr though since mvo touched it so be carreful ;-)
<dholbach> seb128: you'Re right, it does
<mvo> seb128: which one (sorry, my network hates me)
<seb128> mvo: g-t
<mvo> yep, bzr!
<mvo> Riddell: did you had a chance to look at the patch?
<Riddell> mvo: not yet
<mvo> liw: I commited the skip-free-space-check
<seb128> slangasek, pitti: what do you think about updating shared-mime-info to 0.60, it adds a bunch of mimetype definitions
<pitti> seb128: what do these do? for opening files with programs?
<seb128> the debian version also switch to use dpkg triggers, not sure if you consider that as a risky change after feature freeze or not
<pitti> seb128: triggers are well understood by now, so they don't scare me
<seb128> pitti: that's a mapping between file content and mimetype, ie "java" on the first line is a java source, etc
<seb128> pitti: editor /usr/share/mime/packages/freedesktop.org.xml
<pitti> ah
<pitti> seb128: well, independently of FF we should review the diff for sanity, other than that it sounds okay
<pitti> i. e. to not point to programs we don't install/have/don't want to support, etc.
<seb128> pitti: http://paste.ubuntu.com/122452/
<seb128> pitti: there is no program mapping, that just define the mimetypes, then the mapping in .desktop for each applications which list the mimetypes they can handle
<seb128> pitti: the diff is the revelant part, ie the database, translations etc should not be an issue
<Keybuk> pitti: do you know much about HAL and keymaps?
<pitti> seb128: looks fine to me
<pitti> Keybuk: enough in order to be able to fix stuff and commit fdi updates upstream
<Keybuk> pitti: basically I'm trying to work out how the X keyboard map is decided/set
<Keybuk> it's not in /etc/X11/xorg.conf as I would expect
<seb128> pitti: thanks
<dholbach> seb128, mvo: do you use ~ubuntu-desktop or ~ubuntu-core-dev?
<Keybuk> but after that, I'm not sure I know
<pitti> Keybuk: that's actually the xorg -evdev driver, which translates the kernel key symbols (linux/input.h) to XF86... key names
<seb128> dholbach: whatever is in the control
<Keybuk> pitti: how does it know that I want the "gb" keyboard map?
<dholbach> seb128: very good point :)
<dholbach> seb128, mvo: filed a merge proposal
<seb128> dholbach: thanks
<pitti> Keybuk: I don't think X.org uses its own layout configuration any more; it reads it from hal nowadays, IIRC (tjaalton should know better)
<Keybuk> pitti: right, but how/where/etc.
<pitti> Keybuk: /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi
<Keybuk> that's exactly what I'm trying to trace
<pitti> Keybuk: (sorry, we are in meeting, I'm lagging)
<Keybuk> ah, and how does that differ to 10-keymap.fdi ?
<pitti> Keybuk: there I'm leaving familiar terrain (bryce/tjaalton), but I *think* 10-keymap.fdi adds the hal-setup-keymap callout to input devices (which means to call setkeycodes to assing scan codes to the linux key codes, defined in hal-info)
<pitti> Keybuk: and 10-x11-keymap pokes the keyboard layout into X11
<Keybuk> ok...
<pitti> Keybuk: i. e. it reads it from console-setup and writes it into input.xkb.{model,layout,variant,options}
<Keybuk> so what in all this calls xkbcomp to actually compile the keymap?
<pitti> which is where X is reading it from if you select "evdev keyboard" in GNOME
<pitti> you can also set another layout in GNOME, though
<pitti> Keybuk: I don't know, I'm afraid
<mvo_> dholbach: if you give me the url I merge now
<Keybuk> tjaalton: don't suppose you know?
<Keybuk> it looks like it's something in the X server that does that to me
<tjaalton> Keybuk: hal picks it up from /etc/default/console-setup
<dholbach> mvo: lp:~dholbach/gnome-terminal/fix-memory-corruption
<Keybuk> tjaalton: right; itÃ¹s the bit qfter thqt IÃ¹, trying to trqck dozn
<Keybuk> whoah, that was an interesting one ;)
<soren> *chuckle*
<Keybuk> something somewhere must call xkbcomp to get a compiled xkb map to load into the X server
<Keybuk> and I'm wondering where that thing is
<Keybuk> and what it does with the output
<Keybuk> hmm, the X server itself apparently
<Keybuk>  5626 25049  5626  5626 tty7      5626 S+       0   0:00 sh -c "/usr/bin/xkbcomp" -w 1 "-R/usr/share/X11/xkb" -xkm "-" -em1 "The XKEYBOARD keymap compiler (xkbcomp) reports:" -emp "> " -eml "Errors from xkbcomp are not fatal to the X server" "/var/lib/xkb/server-0.xkm"
<Keybuk> but that named file doesn't exist at the end
<tjaalton> Keybuk: ok, i've not dug that far
<Keybuk> tjaalton: any luck with your kpartx problem btw?
<tjaalton> there's a recent patch to use cached files after the initial run, so it should speed things up
<Keybuk> tjaalton: that's the very patch that breaks the world for me ;)
<tjaalton> Keybuk:hah :)
<Keybuk> tjaalton: do you have a reference to the patch so I can check it's the same one I'm looking at
<tjaalton> Keybuk: it was sent to xorg-devel@ on feb 19th
<seb128> pitti: poppler 0.10.3 to 0.10.4 -> http://paste.ubuntu.com/122462 if you have a minute to review
<tjaalton> by dan nicholson
<pitti> seb128: just bug fixes, go ahead
<gaspa> MacSlow: did your git been moved from f.d.o ?
<seb128> pitti: thanks
<MacSlow> gaspa, I hope not
<gaspa> MacSlow:  http://cgit.freedesktop.org/users/macslow/cairo-clock/ tell me "no repo found"
<MacSlow> gaspa, I've not touched it since the ssh-incident
<calc> how do you get a backtrace when the program having the problem catches its own error?
<Keybuk> tjaalton: hmm, this is quite different from the one I have
<Keybuk> ahh, this just avoids reworking if you change the keymap from "gb" to "gb"
<Keybuk> http://people.ubuntu.com/~scott/xkbcomp.patch
<tjaalton> Keybuk: about kpartx; I'll continue debugging it tomorrow
<pitti> calc: ideally, fix the program to re-throw the signal afterwards
<Keybuk> is the one I'm playing with
<pitti> calc: or gdb it and set a breakpoint in the error handler, perhaps?
<calc> pitti: ok, the program in this case is dselect :)
<tjaalton> i'm currently on my e71, so putty can't open links :)
<calc> gdb just gives me a "Program exited with code 02.
<pitti> *blows the dust off*, oh, dselect
<tjaalton> Keybuk: ^
<calc> i'm seeing bug 252001
<ubottu> Launchpad bug 252001 in dpkg "dselect: failed to create baselist pad" [Undecided,Confirmed] https://launchpad.net/bugs/252001
<calc> actually i could probably just grep the source to find out why that is happening, heh
<gaspa> MacSlow: ah! it works with: http://cgit.freedesktop.org/~macslow
<calc> ah i found what appears to be causing it
<calc> the ddebs repo
<MacSlow> gaspa, ok
* slangasek changed the topic of #ubuntu-devel to: Archive: feature-frozen | main frozen for alpha-5 | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | LP believed fixed - please report any further timeouts to #launchpad
<Turl> hi
<slangasek> hello
<Turl> how can I get a list of the packages installed by default on a normal ubuntu system? I'm building popcon2, so it would be great to have it, so we can filter the 'default packages' and let the other packages show :)
<slangasek> hmm, not sure of a trivial way to get that information.  By "normal" ubuntu system, do you mean a desktop system, or any install (including Kubuntu, Ubuntu server, etc)?
<Turl> well, any system that can have popcon enabled, but mainly K/X/Ubuntu
<slangasek> zul: was there an upstream bug number for 330626? (no upstream bug task linked)
<slangasek> zul: wondering if it happens to be fixed in the 3.3.1 release
<zul> yeah gimme a sec
<zul> slangasek: https://bugzilla.samba.org/show_bug.cgi?id=6126
<ubottu> bugzilla.samba.org bug 6126 in Printing "Segfault when loading printers." [Major,New]
 * slangasek links it
<LaserJock> so is it now not possible to logout/reboot from the menu?
<slangasek> LaserJock: correct; if you have FUSA, FUSA is the single place to logout/reboot
<slangasek> instead of having menu redundancy
<pitti> LaserJock: ctrl+alt+del stil works, too
<slangasek> and ctrl-alt-prtscr-k
<slangasek> wait, no, that's something different
<LaserJock> slangasek: that one doesn't work for me, baad things happen
<pitti> well, closing the door vs. blasting it out :)
<LaserJock> so what if I don't have FUSA?
<pitti> LaserJock: you'll get the menu entreis
<pitti> entries, too
<LaserJock> oh, nifty
<pitti> even dynamically
<LaserJock> I don't use the FUSA applet, but I usually leave it around just 'cause it's default
<LaserJock> that's pretty cool that the menu changes instantly
<allquixotic> apw: I've been following discussion on the kernel-team list about pulseaudio glitch-free vs. kernel configs. I tried your lp276476 PPA kernels (running Jaunty on top of it) and my glitch-free problems are not resolved. Failing that, do you think it's reasonable to resurrect the lowlatency kernel flavor which evidently died in Feisty?
<apw> allquixotic, is not the issue that glitch-free is simply not glitch-free in meaning, it means trust we have no glitches and take longer before trying to fill the buffer
<apw> so to get glitch-free sound you turn off glitch-free mode
<slangasek> glitch-free means the glitches have been set free, obviously ;)
<allquixotic> apw: Yeah, it's interesting that glitch-free does the opposite :) Are we planning to turn off glitch-free by default then? With compositing enabled by default on my Intel GM965, whenever a big GEM request goes through (such as minimizing a window causing that slide animation), glitch-free glitches :)
<apw> yeah as i understand glitch-free it means we wait until the buffer is nearly empty before refilling instead of the more normal fill any time there is any space, so it reduces cpu usage
<slangasek> allquixotic: see dtchen's mail to ubuntu-devel on 19 Feb about this
<allquixotic> It just seems like 9.04 should ship with some method of addressing the problem of "I have a driver that makes kernel latency bad" [Intel GEM, Nvidia, others...?] leading immediately to "sound clicks and pops".
<allquixotic> so we can either make the kernel more responsive or turn off glitch-free as you said
<allquixotic> either way resolves my problem
<apw> the latter seems less scarey
<allquixotic> apw: Yeah, as a kernel release manager I would also be somewhat scared of shipping CONFIG_HZ=1000 and a preemptible kernel as the default from an Ubuntu Desktop install. Of course, you could resurrect lowlatency and make it an advanced option in the installer.... but.... too late for 9.04, probably :)
<allquixotic> (I am not, of course, a kernel release manager, but in your shoes, I can see the concern)
<slangasek> well, there is an -rt kernel in the archive
<maco> allquixotic: dtchen said there's a secondary problem with glitch-free related to a pointer (I'm trying to remember the conversation) and it affects all drivers
<slangasek> ... whose meta packages need updating :P
<maco> or...no hang on. now im not sure if that was about glitc-free or auto-spawn
<allquixotic> slangasek: I noticed the bug with the meta-package today; I installed `linux-rt` and balked at the version, then aptitude search made me even more confused :)
<maco> he said ideally glitch-free & auto-spawn are both working and shipped, but he wants them on in development so theres at least a way to find the bugs to start fixing them even if they dont ship
<maco> because it exposes bugs in the underlying drivers
<maco> and he'd like to get the drivers fixed
<allquixotic> Lennart has a pretty solid effort going on between him, the ALSA core devs, and the community with his test scripts... he's trying to track down hardware-dependent bugs that cause weirdness in glitch-free. That's a different subject than latency; some hardware can't properly use glitch-free even with excellent latency
<allquixotic> if we wanted to get the benefit of that work, we would have to pull in ALSA from 1.0.19 + git patches that will probably result from the findings about five different ALSA drivers that report bad timing information
<allquixotic> that's still in the works though
<maco> PA 0.9.15 also fixes a bunch of what's wrong in 0.9.14, but of course it introduced another boatload of new bugs
<maco> and 0.9.15 would require doing what you just said with alsa 1.0.19
<maco> well really, itd probably require just plain going to 1.0.19 overall
<allquixotic> maco: Heh, 0.9.15 has a major bug currently in git, at least with our libtool (not sure if Lennart caught it with Fedora's libtool). It mysteriously can't find the module-alsa-card.so module, which is crucial
<maco> .... i have 0.9.15 installed
<allquixotic> maco: 0.9.15 isn't released yet :)
<maco> well TheMuso's PPA of it
<allquixotic> his PPA probably hasn't pulled in the bug from git :)
<maco> was just about to say "maybe he hasn't built recently"
<allquixotic> I'm trying to track down the root cause of the bug to get it fixed just in case we decide to update PA or ALSA before 9.04
<maco> ok
<ebroder> Question about bug #216761. Intrepid currently has 3.3.0-1ubuntu7. I got 3.3.0-1ubuntu8 uploaded into Jaunty. Do I need to construct a 3.3.0-1ubuntu7.1 for an Intrepid SRU, or can 3.3.0-1ubuntu8 be used?
<ubottu> Launchpad bug 216761 in xen-3.3 "errors in xendomains init script" [Undecided,Confirmed] https://launchpad.net/bugs/216761
<ScottK> 7.1
<ebroder> Anybody willing to upload http://launchpadlibrarian.net/23083056/xen-3.3_3.3.0-1ubuntu7.1.debdiff to intrepid-proposed? :)
<ebroder> Oh crap - don't upload that one, actually
<ebroder> Ok - let's try this again with a patch going in the right direction. Anyone willing to upload http://launchpadlibrarian.net/23083113/xen-3.3_3.3.0-1ubuntu7.1.debdiff to intrepid-proposed?
<pitti> bryce: would you mind if I upload the fix for freedesktop bug 19304, or do you prefer to wait until upstream commits the patch?
<ubottu> Freedesktop bug 19304 in Driver/intel "[i945 FBC] spontaneous black screen (major pipe-A underrun)" [Normal,Reopened] http://bugzilla.freedesktop.org/show_bug.cgi?id=19304
<pitti> bryce: I had several people test it successfully (also for intrepid, in my ppa)
<bryce> pitti: looking
<bryce> pitti: sure go ahead.
<bryce> pitti: if upstream ends up committing something substantially different, we'll need to make sure to update
<bryce> I'm not certain that we will be pulling -intel 2.7 for jaunty.  Intel releases are sometimes not so stable
<maco> by "spontaneous black screen" does that mean goes black and stays black, or does it mean a black flicker when it redraws?
<maco> oh ok nevermind...was looking for the launchpad bug :P
<slangasek> zul: as a data point, I've just found that I can't reproduce bug #330626 on Debian sid with 2:3.3.0-3; I don't think it's a difference in anything being patched in the source, so maybe a difference in build options or compiler settings
<ubottu> Launchpad bug 330626 in samba "9.04 Jaunty Samba 2:3.3.0-3ubuntu2 fails to start on update " [Unknown,Confirmed] https://launchpad.net/bugs/330626
<slangasek> or a difference in the existing environment for each of the servers - will try to narrow this down
<LaserJock> slangasek: well, I've got a merged moodle package that works as well as the current Jaunty one does
<slangasek> LaserJock: that sounds like an endorsement to me ;)
<LaserJock> slangasek: but considering that the current one doesn't install/remove that's not saying much ;-)
<slangasek> heh
<LaserJock> apparently it works fine on Debian
<LaserJock> but something's going wrong in the DB creation in Ubuntu
<LaserJock> I don't think I'm going to get all that figured out by Thursday
<LaserJock> so should I bump the milestone or upload the merge now and fix the DB issues after?
<slangasek> if it's not installable, is it also not upgradeable?
<LaserJock> it might be upgradable if you have an existing working install
<LaserJock> the problem it's having is in the initial DB creation
<LaserJock> if you already have a DB it might work just fine
<LaserJock> but I haven't tested it as I don't have a working DB
<slangasek> is the intrepid package also broken this way?
<LaserJock> similarly
<slangasek> oh, intrepid's at the same version
<LaserJock> I'm not sure how far it's broken in Intrepid but I have severall "can't install/upgrade" bugs for Intrepid
<slangasek> how far back does one have to go to find a version of moodle that's actually installable? :P
<LaserJock> Hardy I guess
<ajmitch> LaserJock: got a package somewhere to look at? I'll be needing to get familiar with moodle soon
<LaserJock> Intrepid's seemed to work if you choose the right options
<LaserJock> but the default DB of postgresql doesn't work
<slangasek> LaserJock: but intrepid and jaunty are at the same version, so "choose the right options" should also work in jaunty?
<slangasek> in which case, I would say it's worth having the security updates in now and the maintainer script fixes in later
<LaserJock> assuming that it's just moodle that's the problem
<LaserJock> I think it's a moodle+DB issue so it's possible that Intrepid's moodle+mysql works but Jaunty's moodle+mysql doesn't
<LaserJock> for instance, I haven't had time to go through all the permutations
<LaserJock> ajmitch: Debian has a git repo
<LaserJock> right now the package I have should be functionally as good as current Jaunty's but with security and other bug fixes
<ajmitch> and everything you've merged is there?
<LaserJock> and an internal lib removed
<LaserJock> ajmitch: yep, master branch is what I'm working on
<LaserJock> I just have a heavy load this week so I need to know if what I've got is OK for Alpha5 or not
<LaserJock> the Debian maintainer said he'd help me look into the DB creation issues, but I doubt it'll be resolved before Alpha 5 is out
<LaserJock> but we are merged
<slangasek> zul: just reproduced the problem with 3.3.0-3 by building with -PIE
<slangasek> (the Debian package calls ./configure --disable-pie)
#ubuntu-devel 2009-02-25
<zul> slangasek: ok thats going to make kees happy (sarcasm)
<slangasek> he's welcome to fix it ;)
<slangasek> zul: PIE exposes it, but it's a sourceful bug; there's no prototype for cache_path() in source/include/proto.h
<slangasek> zul: fix committed to the Debian svn tree; I can do an upload to unstable so you can pick it up via MoM?
<zul> slangasek: that would be great
<savvas> hm... is it just me, or are the .ini files linked to cisco vpn settings in jaunty?
<savvas> heh <match value="[main]" type="string" offset="0"/> in /usr/share/mime/packages/freedesktop.org.xml
<StevenK> stgraber: Ping!
<slangasek> zul: 2:3.3.0-4 uploaded to unstable, so should be available in MoM tomorrow
<ScottK> slangasek: I believe I have a patch to fix kipi-plugins FTBFS with Qt4.5.  Is it OK if I upload it or would you rather I hold if until after the Alpha?
<slangasek> ScottK: how big of a change is the upstream diff from rc1 to rc2?
<ScottK> Not sure.
<slangasek> ok
<slangasek> well, amd64 is already on rc2, so if you don't know of any reasons why it'd be disruptive, go for it
<ScottK> The patch is add one def and change 3 lines.
<ScottK> OK.  Assuming it test builds and stuff OK, I'll upload it.
<slangasek> ArneGoetje, pitti: could we please not have langpack exports the Tuesday of a milestone?
<superm1> slangasek, gah i didn't realize that you flipped the switch for freezing for alpha builds already. i just uploaded a small diff for libsmbios
<superm1> i had a hal upload ready to go with it, but i'll hold back
<slangasek> superm1: Tuesday of a milestone, should be pretty predictable? :)
<slangasek> superm1: so this is hal depending on smbios-utils, rather than using libsmbios directly?
<superm1> slangasek, the actually it's going to be hal not needing smbios-utils
<superm1> slangasek, it links directly to libsmbios_c
<slangasek> superm1: ah - I'd be happy with that being uploaded now if it's been tested, since it also kills off an NBS
<superm1> slangasek, yeah that's what i've been up to today, working out the kinks on it.
<StevenK> I've not removed an NBS in a while, can I push the button?
<slangasek> StevenK: once it's no longer a dependency of hal? :)
<superm1> slangasek, however for feature parity it might still make sense to leave smbios-utils as a recommends to ubuntu-desktop (but still removing libsmbios-bin from hal's recommends)
<superm1> that can be sorted out after alpha though
<ScottK> slangasek or StevenK: Modulo one powerpc FTBFS and one package I'm waiting for the slow archs to build, I think we're ready to remove boost (1.34).  Often when I file removal bugs the archive admin in question will find a residual rdepends on some obscure arch.  Any suggestions on how I can dig those up?
<ArneGoetje> slangasek: you mean langpack uploads, right?
<ScottK> Speaking of removals...
<slangasek> ArneGoetje: yes
<ArneGoetje> slangasek: sorry, forgot to disable the crontab entry.
<slangasek> ArneGoetje: ah - didn't realize there was a cronjob; should I add it to my checklist to prod you about that? :)
<ArneGoetje> slangasek: would be nice, yes. ;)
<slangasek> superm1: libsmbios-bin was only ever pulled in by hal, not treated as a top-level component of the desktop; seeding smbios-utils ought to be discussed separately then, I think
<StevenK> slangasek: Did you mean to give-back d-i on ia64 as well?
<slangasek> StevenK: no
<StevenK> slangasek: So ia64 will remain busted?
<superm1> slangasek, okay sounds good
<ArneGoetje> slangasek: langpack uploads to jaunty happen on Tuesdays and Saturdays
<StevenK> Not that I care, just curious.
<slangasek> StevenK: it won't have an up-to-date d-i for alpha-5, yes
<slangasek> ScottK: there's a 'checkrdepends' script we use, which basically just runs grep-dctrl over the mirror...
<ScottK> OK.  I'll try that.
<ScottK> Thanks.
<slangasek> I can post a copy somewhere if you like, but it's a trivial shell script (and not at this very moment, I'm on the way out to grab dinner as soon as I wrap up my current stack)
<doctormo> I just had an idea, probably a duplicate, I might post it to idea storm. What if we have an option in the windows cd program that adds cd-booting to the Boot.ini?
<doctormo> I just had someone claim ubuntu didn't work, turned out their bios wasn't set to boot from cdrom and they thought that meant ubuntu had failed because it went directly into windows again.
<ScottK> slangasek: I would appreciate the script when you have a moment.
<TheMuso> Is it possible to remove multiple lines of a file using either grep or sed regular expressions?
<StevenK> TheMuso: grep -EV '^(line 1|line 2)$'
<TheMuso> StevenK: Yeah I knew about the -v switch, but thanks for the rest of the syntax, much appreciated.
<TheMuso> StevenK: hrm thats not quite what I am after. I need to remove a sequence of lines, as in three lines one after naother after another. I thought grep understood \n, and I thought sed did as well, but \n to indicate newlines is not working...
<StevenK> TheMuso: grep -v -A 3 'line' ?
<TheMuso> StevenK: That would work if there weren't the same strings elsewhere in the file. I am trying to strip some XML from /usr/share/gconf/defaults/05_panel-default-setup.entries to remove the fast user switch applet from the top panel, to enable logout menus for accessibility profiles.
<StevenK> TheMuso: Perl?
<TheMuso> StevenK: This will be running in an initramfs/casper script with sh.
<StevenK> I hate you
<TheMuso> So I don't think perl will be available, unless I chroot, which is possible.
<StevenK> Ummmm. sed can do it.
<StevenK> Just not sure my sed-foo bends that far
<StevenK> | sed -e '/line/,3d' ?
<TheMuso> I'll try it. My regexp skills in general aren't that great either. :)
<TheMuso> hrm o that just gets rid of one line. I'll have a play and see what else I may be able to come up with.
<TheMuso> Or maybe just modify the required settings with gconf itself, i.e gconftool-2. Hrm.
<savvas> TheMuso: have you tried pcregrep ?:)
<TheMuso> savvas: Is it in a default install on aan Ubuntu live CD?
<savvas> I don't think so :\
<savvas> here are some handy sed one-liners: http://sed.sourceforge.net/sed1line.txt
<savvas> or awk might be easier to handle, never tried awk though
<spm> TheMuso: if still looking for a multi-line delete, way I've done in the past is with awk: awk '{ if (f==2) {f=0} else if (f==1) {f=2} else if ($0 ~/line/) {f=1} else print $0 }'
<spm> I was actually doing multi line edits based off the 1st line, so it made sense that way. ymmv....
<TheMuso> The first line is not appropriate here, because the string in that line exists elsewhere in the fie.
<spm> bummer
<spm> tho... you could still do with awk; pull the "previous matching line into a var", and print that out if the next line isn't what you're expecting kind of thing. ugly as sin tho..
<ScottK> slangasek: I also have a fix for the konq-plugins FTBFS.  May I upload that or should I hold it?
<slangasek> ScottK: go ahead
<slangasek> ScottK: and, script: http://pastebin.ubuntu.com/122673/
<ScottK> Thanks.
<ScottK> slangasek: OK, so it turns out it's also accidentally a native package: https://launchpad.net/ubuntu/+source/konq-plugins/4:4.2.0a-0ubuntu1/
<ScottK> Want me to fix that too or just leave it for now?
<slangasek> hem; leave it for now, I guess
<ScottK> OK.
<TheMuso> hrm ok, I can set what I want via gconf.
<TheMuso> I'll have to see if it works however, but fingers crossed.
<StevenK> TheMuso: Oh good. Then I don't have to cry at what you're adding to casper :-P
<TheMuso> StevenK: Nor do I./
<dholbach> good morning
<slangasek> StevenK: there's an NBS package with no reverse-deps if you want it ;)
<StevenK> I'm so there!
<StevenK> slangasek: Binned, thanks
<StevenK> slangasek: Should I be dealing with the libmysqlclient-dev rdepends? What's the situation in Debian, if you know?
<slangasek> dunno
<ScottK> Last I heard in Debian there was no appetite for making mysql 5.0 and 5.1 co-installable.
<StevenK> ScottK: You sleep with your laptop?
<StevenK> Wait, don't answer that.
<ScottK> Heh.  No, I just procrastinate a lot, including going to bed.
<StevenK> ScottK: Okay, so shall I fix the ~ 26 build-deps to 5.0?
<ScottK> I have no idea.  I've been avoiding knowing any of the details of the mysql changes.
<StevenK> ScottK, slangasek: I'll pick on a few source packages out of the list tomorrow and see what they're doing. If we can get away with a few syncs, I'll sort it out.
<pitti> Good morning
<pitti> bryce: yes, I'm following the upstream bug tracker
<highvoltage> mornign pitti
<pitti> bryce: of course that "black screen" bug hit me again right after asking you about whether I should fix it :)
<pitti> hey highvoltage
<pitti> asac: every time I open firefox I get a "new addons added" with 4 langpacks; known already, or want a bug?
<Hobbsee> heya pitti!
 * pitti hugs Hobbsee and throws a gummybear
<Hobbsee> :D
 * StevenK waves to pitti 
<dholbach> hey juanje, hey rcmorano!
<rcmorano> hiya man!
<rcmorano> :]
<dholbach> how's life in Spain? :)
<juanje> dholbach: hi! :-) Good morning
<rcmorano> it's ok, weather starts to get perfect :D
<juanje> dholbach: still cold and sleepy, but in few hours it sure will be nice
<dholbach> nice, you guys are lucky :-)
<juanje> ready to start working
<juanje> dholbach: how is up there?
<dholbach> 2Â°C, grey :)
<Mithrandir> hi, crazy holbach
<juanje> dholbach: ouch....
<dholbach> Mithrandir: crazy Tollef :)
<Mithrandir> 2Â°C is boring, all the snow starts melting.
<juanje> dholbach: ummmm.... are you planning to go to the Gran Canaria Desktop Summit? is in my town... ;-)
<dholbach> Mithrandir: wasn't my idea
<dholbach> juanje: no, unfortunately not
<juanje> :-/
<rcmorano> ouch :/
<maco> trying to pin down a bug, but testing requires that i edit /etc/udev/rules.d/70-persistent-net.rules ...do i have to restart udev or something after this for it to go into effect?
<juanje> maco: maybe with "udevadm control --reload_rules"
<maco> ok. im probably about to go offline then ;)
<juanje> maco:  but sometimes you have to reboot the machine to rebuild a clean set of devices
<juanje> hehe
<juanje> i guess
<maco> ok i guess it does want me to reboot
<tjaalton> Keybuk: ok, the kpartx rules get stuck in 'ENV{DM_PART}=="?*", SYMLINK+="disk/by-id/$env{DM_TYPE}-$env{DM_NAME}-part$env{DM_PART}"'. that rule is matched only after running 'kpartx -a ...' manually
<tjaalton> Keybuk: and DM_PART should come from kpartx_id, hmm..
<slangasek> Tonio_: kdesudo is failing to install in the kubuntu livefs builds, the removal of the transition package is wrong
<slangasek> Tonio_: this needs to be fixed so we can build ISOs for alpha-5
<kagou> bryce (or bryce_  ) I'v confirmed in bug #325394 that upstream patch from Alex Deucher  (freedesktop) is fixing the bug. Please fixe the package when you can :)
<ubottu> Launchpad bug 325394 in xserver-xorg-driver-ati "[RV770 HD 4850] ATI Radeon HD 4850 not supported - white screen and system freeze" [Unknown,Fix released] https://launchpad.net/bugs/325394
<seb128> slangasek: how disruptive would uploads be today? ie should I respect the freeze or not ;-)
<slangasek> seb128: very disruptive
<seb128> ok, the oem patches for notebook will wait then
<seb128> slangasek: thanks
<Tonio_> slangasek: we have a direct dep on the transitional package ?
<Tonio_> slangasek: that's bad...
<slangasek> Tonio_: no, I mean the removal of the transitional package was done wrong
<Tonio_> slangasek: ah ?
<slangasek> Tonio_: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/jaunty/kubuntu/20090225/livecd-20090225-amd64.out
<slangasek> Tonio_: also, I vaguely mean "wrong" as in "shouldn't have been uploaded two days before a milestone release"...
<Tonio_> slangasek: ouch... indeed, the package had crap postinst file and it looks like I missed the correct diversion...
<Tonio_> fixing...
<Tonio_> slangasek: and yeah, sorry for the upload that late...
<slangasek> s/kdesudo-kde4/kdesudo/ in the preinst should fix that part
<slangasek> but I haven't thought through what actually happens with this on package upgrades given that kdesudo-kde4 owned the diversion previously
<Tonio_> slangasek: there is a postrm that should drop the diversion and install the new one
<slangasek> Tonio_: the confidence with which you assert this makes me suspect you don't have much experience with diversions ;-)
<Tonio_> slangasek: :) no I mean, I upgraded many machines and it still works here, so I suspect that part is fixed
<Tonio_> slangasek: I perfectly know that diversions can have weird artefacts at some points
<slangasek> Tonio_: did you manually uninstall the transitional package?
<StevenK> Tonio_: An upgrade isn't the same.
<slangasek> Tonio_: I think the new kdesudo needs to Conflict: kdesudo-kde4, so that the transitional package (and its diversion) is removed before kdesudo is unpacked
<slangasek> otherwise you have two packages trying to divert the same file at the same time
<Tonio_> slangasek: nope, but probably it wasn't installed for me
<Tonio_> slangasek: well maybe we should just reintroduce the transitional package and fix this after the milestone release, no ?
 * Mithrandir ponders upgrading to jaunty.
<slangasek> Tonio_: actually... yes, because ubiquity-frontend-kde depends on kdesudo-kde4
<slangasek> Tonio_: so best to revert for now
<Tonio_> slangasek: okay, so I'll switch back and fix this after the milestone release
<slangasek> Tonio_: ok, thanks
<Tonio_> slangasek: sorry for the issue...
<pitti> superm1: great work on hal+smbios!
<dholbach> In intrepid lsof sometimes displayed information like "(path dev=253,0, inode=475136061)" at the end of the lines - my interpretation was that it was stuff in memory, that is different on the disk now - I found this very useful after doing upgrades, because I knew which services/programs I had to restart to benefit from changes that were done - in Jaunty this information seems to be gone - can anybody tell me why or where it went? :-)
<slangasek> dholbach: I don't remember ever seeing anything like that; but grepping for 'DEL' should give you that information
<dholbach> slangasek: FANTASTICO
<dholbach> gracias :)
 * DktrKranz hugs dholbach for his "italiano perfetto" :)
<pochu> DktrKranz: it was spanish! :)
 * dholbach hugs DktrKranz back :)
<Tonio_> slangasek: uploading kdesudo now
<slangasek> thanks
<DktrKranz> pochu: it was not french ;)
<pitti> slangasek: are you okay with uploading more intrusive bug fixes to packages not on the CD? (sl-modem in my case)
<slangasek> pitti: in general, yes; hopefully nothing that's going to take buildd time away from the langpacks, though
<pitti> slangasek: I can easily lower its build score
<zinzin> hi
<zinzin> ï»¿i am using 8.10 on GPU i915 Intel. i got the problem when run glxgears, like "ï»¿Failed to initialized GEM. Falling back to classic". Now OpenGL doesnt run anymore. Anybody knows this problem?
<zinzin> it didnt happen with me before, so perhaps the recent update of xorg is the culprit??
<zinzin> please soebody help?
<maco> have you already checked launchpad for a bug?
<volo> hi
<maco> zinzin: ^
<zinzin> maco: is there anything about that?
<zinzin> maco: how can i find the information on the "launchpad"? sorry i am not aware of that
<maco> er...i was asking if you'd checked launchpad already and were trying to find a dev who knew about not-on-the-bugtracker (or reported upstream) issues
<maco> http://bugs.launchpad.net/ubuntu/+bugs <-- the home of ubuntu bugs
<scizzo-> zinzin: this question should have gone into #ubuntu first AFAIK
<maco> or since you're asking about intel graphics, more specifically http://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bugs is likely to narrow it down
<maco> zinzin: scizzo- is right about #ubuntu though, or #ubuntu-bugs
<zinzin> ok, i will try with ubuntu-bugs first. thanks
<pitti> bryce: what's missing for xorg-ctrl-alt-backspace to be set to implemented; some documentation to write?
<bryce> pitti: yeah
<pitti> bryce: and    x-testing-infrastructure ?
<bryce> pitti: mostly I just need to finish up the historical driver page for that
<asac> pitti: i guess we need a bug. was that first triggered by a langpack update?
<asac> pitti: do you close ffox properly sometimes? or just forceful exit through log-out/shutdown?
<maco> asac: has there been some change that says its ok for networkmanager to try to control an interface that is configured in /etc/network/interfaces?
<asac> maco: no. only if you run the plugin in managed mode
<maco> hrm? how would i find out if it's doing that?
<maco> i just started using the interfaces file last week when i had trouble with wpa and wanted to do it manually...have since discovered that nm is still trying to manage even when ive got interfaces setup
<asac> maco: /etc/NetworkManager/nm-system-settings.conf
<asac> look if its managed=true
<maco> asac: main plugins=ifupdown,keyfile ; ifupdown managed=false
<pitti> asac: most of the time just logout (i. e kill)
<pitti> asac: yes, very probably triggered by langpack update
<asac> maco: have you rebooted in between?
<maco> asac: yes, many times
<maco> it also turns out that if i let NM connect, itll rewrite my /etc/hosts into broken-ness and then i cant launch anything in X, so ive been killing NM before logging in, then using ifup manually
<asac> maco: is nm-system-settings process running at all?
<maco> nope
<asac> thats the problem then
<maco> but i did a sudo service NetworkManager stop already
<asac> that doesnt matter
<maco> because if i let it run, i cant use graphical apps
<asac> yes. thats understood
<asac> maco: if nm-system-settings isnt running thats the problem
<asac> if you think it has to do with stopping NM check before you kill it after reboot
<maco> ok
<maco> will try that then
<maco> thanks
<asac> maco: what do you have in /var/crash?
<maco> probably a LOT
<maco> yeah, a lot
<maco> nm-system-settings is in there, if that's what you're asking
<asac> maco: yes.
<asac> maco: please submit that crash file
<asac> through apport
<maco> ok
<maco> does apport succeed at submitting now?
<pitti> asac: confirmed bug 289469 and added theory/screenshot
<ubottu> Launchpad bug 289469 in firefox "Firefox opens "new add-ons have been installed" dialog window at startup" [Undecided,Confirmed] https://launchpad.net/bugs/289469
<maco> it wont let me because i havent updated python
 * asac looks for theory ;)
<asac> pitti: there are extensions* files in your profile ... is the timestamp up to date?
<pitti> asac: https://bugs.edge.launchpad.net/ubuntu/+source/firefox/+bug/289469/comments/3
<ubottu> Ubuntu bug 289469 in firefox "Firefox opens "new add-ons have been installed" dialog window at startup" [Undecided,Confirmed]
<asac> pitti: also check whether the langpacks that are shown to be new are in the extensions.ini file
<pitti> asac: they aren't really new, they just got updated; but they all are
<pitti> asac: bug updated
<asac> ok thanks
<pitti> asac: I guess eventually it's seb128's fault :) (gnome-session)
<asac> pitti: heh ;) ... i am not sure. i have to check what is supposed to happen when on global extensions update
<seb128> asac: trying to blame yet another bug on GNOME I see ;-)
 * pitti hugs seb128
 * pitti kicks gnome-"Terminator ZAP!"-session
<asac> seb128: hey, i even tried to be politically ;)
 * seb128 hugs pitti
<asac> pitti: do we currently have problems with langpack-o-matic?
<asac> pitti: i wanted to see what happens when installing language-pack-fi
<asac> ls -l /usr/lib/firefox-addons/extensions/langpack-fi\@firefox-3.0.ubuntu.com/
<asac> total 0
<asac> also there is nothing about langpack-fi in the -base package
<asac> interesting that Mirv didnt complain yet ;)
<pitti> asac: there is a bug about it
<cjwatson> slangasek: ubiquity-frontend-kde Depends: kdesudo | kdesudo-kde4, FWIW, not just kdesudo-kde4
<cjwatson> TheMuso: you probably want to look up address ranges in sed; for instance you can do sed -e '/line/,+2d' which deletes anything matching /line/ and the two lines after it
<Mirv> asac: I filed the bug already :)
<asac> Mirv: :-D
<ogra> cjwatson, did you remove the keymaps as well for ixp4xx ?
<ogra> (the changelog entry only talks about console-setup)
<ogra> ah, you did :)
<cjwatson> yes
<cjwatson> I meant console-setup the whole pile, not console-setup-udeb the package
<ogra> btw, i still see the uuid prob here
<ogra> could it be that partman doesnt disconnect the device as soon as swap is in use ?
<ogra> so that udev cant pick up the new uuids
<ogra> thats my only explanation for that behavior ...
<davmor2>  Audio is borked on daily iso that is meant to be a5 candidate playback shows Null output (PulseAudio Mixer)
<ogra> seems partman calls swapon first and then goes on with formatting
<mpt__> Who knows about usplash here?
<cjwatson> ogra: what does "disconnect the device" mean?
<cjwatson> ogra: vol_id goes and physically looks in the contents of the block device - it doesn't matter whether it's mounted or not
<ogra> cjwatson, well, i have definately another failed install here where the uuid's are the old ones
<cjwatson> ogra: I'm not disputing that, merely disputing your suggestion for a cause :-)
<ogra> i was expecting something like blockdev rereadpt
<cjwatson> no, that gets the kernel to reread its in-memory copy of the partition table, but vol_id doesn't look at that
<ogra> though i'm not sure udev recats on that and changes the uuids
<cjwatson> and FWIW libparted does the equivalent of that internally *anyway*
<ogra> hmm
<ogra> *reacts
<cjwatson> vol_id does something much more like open("/dev/sda1", O_RDONLY) and then direct reads
<cjwatson> it does not depend on the udev database, even
<ogra> right, which means vol_id has the new uuid info, but udev doesnt get triggered to change the device node
<ogra> sadly lowmem mode gets in my way a bit, having only half a log isnt really helping :(
<cjwatson> so at which point do you observe udev having the wrong uuids?
<cjwatson> just after partitioning, or after the first reboot, or when?
<ogra> well, i get the error only if update-initramfs runs ...
<cjwatson> (I assume that by "udev having the wrong uuids" you mean something like "symlinks in /dev/disk/by-uuid/ are wrong"
<cjwatson> )
<ogra> but i.e. the fstab in /target has the new uuids
<ogra> right
<cjwatson> exactly what is going wrong?
<ogra> the symlinks show uuids that arent existent ... given that i use the same USB disk all the time they are very likely from my last install
<ogra> ~ # ls -lh /dev/disk/by-uuid/
<ogra> lrwxrwxrwx    1 root     root           10 Jan  1 00:08 4069d9b2-b663-4633-815b-c09f32761279 -> ../../sda5
<ogra> lrwxrwxrwx    1 root     root           10 Jan  1 00:08 794f4f3f-e988-45dc-83d1-f0f0a201914b -> ../../sda1
<ogra> lrwxrwxrwx    1 root     root           10 Jan  1 00:08 7e895cfc-4d4c-4104-a9be-f9c06641e63b -> ../../sda2
<ogra> thats what i have right now in d-i
<cjwatson> vol_id -u /dev/sda1
<ogra> ~ # grep boot /target/etc/fstab
<ogra> # /boot was on /dev/sda1 during installation
<ogra> UUID=7e1ff899-da3c-4ec8-9206-2219331bbdd9 /boot           ext2    defaults        0       2
<ogra> ~ # vol_id -u /dev/sda1
<ogra> 7e1ff899-da3c-4ec8-9206-2219331bbdd9
<cjwatson> ok
<ogra> vol_id, fstab and the like are right, udev isnt
<ogra> update-initramfs looks for the new uuid and doesnt find it
<ogra> thast the point where the install ends
<cjwatson> so I guess the thing that would be interesting would be to get 'udevadm monitor' output across partitioning
<cjwatson> this is more Scott's area than mine, of course, but anyway
<ogra> hmm, tricky
<cjwatson> you don't have a second console?
<ogra> i'm not sure the system will survive a second ssh connection
<ogra> 30MB ... without swap its very fragile
<cjwatson> you could start it in the background from a shell earlier on
<cjwatson> (and redirect to a file obviously)
 * ogra tries if he can run a shell on serial console while d-i runs inder ssh without hitting OOM
<ogra> yay, i wouldnt have expected the system to survive that, but i'm in base-install :)
<ogra> Keybuk, so can we have a look at my uuid prob ?
<ogra> i have a log of udevadm monitor across the d-i partitioning process
<ogra> cjwatson, heh, as i suspected, /dev/sda1 has exactly the uuid i pasted above, even after partitioning, so udev re-uses the old one
<ogra> cjwatson, when do you plan to upload d-i *ubuntu20 so i can actually test with a real d-i build instead of my hand knitted one ... seems the kernels have all build now
 * ogra would like to have some testing time before A5
<cjwatson> ogra: ... last night?
<cjwatson> has there been another kernel upload since?
<cjwatson> I think Steve would be unhappy with me if I uploaded d-i again ...
<ogra> yeah
<ogra> well, he was aware that rtg uploaded a new kernel for ipx4xx
<pitti> but that didn't bump ABI?
<ogra> pitti, no, but ixp4xx needs a firmware image rolled by d-i
<pitti> ah
<ogra> and that needs to include the new kernel
<ogra> slangasek, ^^^^ were you aware that the new ixp4xx kernel needs a no-change d-i upload to roll the firmware for ixp4xx when you approved the upload yesterday ?
<cjwatson> ogra: could you put the udevadm monitor log somewhere please?
<ogra> will do
<cjwatson> if we're very lucky it's something trivial like something missing from the udeb
<cjwatson> if we're unlucky, the kernel isn't sending any uevents when partitions change
<ogra> http://people.ubuntu.com/~ogra/arm/udevadm.log
<ogra> it doesnt look like its recieving anything after the initial "add" events
<cjwatson> an strace of parted_server wouldn't hurt, but that's going to be difficult in your environment
<cjwatson> (to confirm that it's doing the right BLKPG ioctls)
<ogra> well, i can try to swapon manually before the partitioning starts, not sure if that explodes in my face though
<ogra> hmm, i can probably try with a second disk
 * ogra fiddles a bit 
<cjwatson> second disk would reduce the probability of interfering with the observation
<highvoltage> query asac did you get my direct message? first time I tried from gwibber
<asac> highvoltage: we can continue here if you want. i dont know where i would see direct messages (is that different from @asac)?
<Keybuk> ogra: udev won't change the /dev/disk/by-uuid symlink tree unless something tells it to
<ogra> Keybuk, yeah, which according to http://people.ubuntu.com/~ogra/arm/udevadm.log doesnt happen
<Keybuk> sda is a usb disk?
<ogra> yep
<Keybuk> UEVENT[470.626540] add      /devices/pci0000:00/0000:00:01.2/usb1/1-2/1-2:1.0/host0/target0:0:0/0:0:0:0/block/sda (block)
<Keybuk> UEVENT[470.628185] add      /devices/pci0000:00/0000:00:01.2/usb1/1-2/1-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1 (block)
<Keybuk> UEVENT[470.629824] add      /devices/pci0000:00/0000:00:01.2/usb1/1-2/1-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2 (block)
<Keybuk> UEVENT[470.651764] add      /devices/pci0000:00/0000:00:01.2/usb1/1-2/1-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda3 (block)
<Keybuk> UEVENT[470.653431] add      /devices/pci0000:00/0000:00:01.2/usb1/1-2/1-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda5 (block)
<ogra> right, it gets added once
<Keybuk> you said this was a udevadm *across* the partitioning
<ogra> thats on boot
<ogra> well, from boot until base-install
<Keybuk> now look at ~657
<cjwatson> there are similar adds later too
<Keybuk> the devices are removed and added again
<ogra> oh, right
<Keybuk> and again at 659
<Keybuk> and again at 660
<ogra> thats puzzling
<Keybuk> can you do this log again
<Keybuk> but use "-e" to udevadm monitor
<ogra> why dont they get new uuids
<ogra> sure
<cjwatson> so, thinking about it, isn't the sequence of events as follows:
<cjwatson> 1) parted_server tells libparted to commit
<cjwatson> 2) libparted tells the kernel to remove existing partitions
<cjwatson> 3) libparted tells the kernel to add new partitions
<ogra> let me redo that setup (i was just experimenting wint an additional 2G swap disk to circumvent OOM)
<ogra> *with
<cjwatson> 4) something writes new filesystem bits into the new partitions
<cjwatson> 2) and 3) correspond to the remove/add uevents
<cjwatson> however, we don't have the right UUIDs until 4)
<Keybuk> right
<cjwatson> so what is supposed to deal with telling udev about 4)?
<Keybuk> udev 138-2 can do that itself
<Keybuk> earlier versions - you'd have to run udevadm trigger --subsystem-match=block --action=change
<cjwatson> which indeed d-i did
<ogra> Keybuk, 137 cant ?
<ogra> my current version of d-i still has 137
<cjwatson> well, it did udevadm trigger --subsystem-nomatch=sound actually, which of course has other problems but ...
<ogra> since i have to wait for a new initrd.gz first
<cjwatson> ogra: the current version in the archive is built against 138-2
 * ogra pulls that
<cjwatson> $ wget -q -O- http://ports.ubuntu.com/ubuntu-ports/dists/jaunty/main/installer-armel/current/images/MANIFEST.udebs | grep -m1 udev-udeb
<cjwatson>         udev-udeb 138-2 armel
<Keybuk> cjwatson: that's probably the third set of adds then
<cjwatson> Keybuk: so we should work out how to get rid of this trigger ...
<cjwatson> simply deleting it runs into the problem that d-i loads extra modules at run-time, so udev needs to try some things again
<Silicium> http://pluto.htu.tuwien.ac.at/How-To_Live-CD_verÃ¤ndern <-- If i create a usplash for the Live CD with this tutorial on Ubuntu 8.10 it will not displayed while booting the CD
<cjwatson> Keybuk: would we ever need to process add uevents again after loading specifically filesystem modules?
<Keybuk> cjwatson: udev doesn't use (or even load) filesystem modules
<cjwatson> good
<cjwatson> so in that case it's probably just a matter of specifically triggering after anna runs
 * ogra twiddles thumbs ... 
<ogra> slow HW, sigh
<ogra> doing all that in qemu would be twice as fast
<doko> Riddell: I don't understand the qscintilla2 build failure on the buildds yet. builds for me in a fresh chroot. any ideas?
<Riddell> doko: oh sorry, forgot about that, let me look into it
<ogra> Keybuk, cjwatson ok, 138-2 DTRT apparently
<ogra> before partitioning:
<ogra> ~ # ls -lh /dev/disk/by-uuid/
<ogra> lrwxrwxrwx    1 root     root           10 Jan  1 00:00 15e76768-ede6-4763-afca-f1c683c9757b -> ../../sda1
<ogra> lrwxrwxrwx    1 root     root           10 Jan  1 00:00 687b627c-fcac-4a59-8a14-a9ab965c0b81 -> ../../sda5
<ogra> lrwxrwxrwx    1 root     root           10 Jan  1 00:00 9b75eb51-319b-4ddd-9793-e160323650e5 -> ../../sda2
<ogra> after:
<ogra> ~ # ls -lh /dev/disk/by-uuid/
<ogra> lrwxrwxrwx    1 root     root           10 Jan  1 00:13 2557b59d-a108-45d5-8b7e-9344e715475e -> ../../sda2
<ogra> lrwxrwxrwx    1 root     root           10 Jan  1 00:13 56c758cd-2f7e-44a1-96bf-1c2a21d89621 -> ../../sda1
<ogra> lrwxrwxrwx    1 root     root           10 Jan  1 00:12 7a2b7ace-6199-4bd5-b4ab-eaadf4e3c637 -> ../../sda5
<cjwatson> ogra: oh good
<ogra> (unless udevadm monitor -e triggers that indeed)
<cjwatson> Keybuk: http://paste.ubuntu.com/122821/ - quick review for technical accuracy?
<Keybuk> cjwatson: ack
<cjwatson> thanks
<liw> mvo, I don't understand why an intrepid->jaunty upgrade replaces system-cleaner+system-cleaner-gtk with just computer-janitor, and doesn't install computer-janitor-gtk
<mvo> liw: could you give me the upgrade logs please? I have a look
<liw> mvo, I'll re-run the upgrade, just a minute
<pitti> liw: probably because I messed up and only seeded computer-janitor
<liw> pitti, oh
<pitti> liw: seeds fixed, rebuilding ubuntu-meta now
<liw> pitti, ack, thanks
<pitti> bug 334299 is an alpha-5 blocker anyway (IMHO), so this can just slip in
<ubottu> Launchpad bug 334299 in hal "Jaunty: No sound cards any more" [High,In progress] https://launchpad.net/bugs/334299
<seb128> could somebody in the linux team look at bug #197762 one day?
<ubottu> Launchpad bug 197762 in linux "file transfers on USB disk are very slow" [Undecided,Confirmed] https://launchpad.net/bugs/197762
<seb128> it gets quite some users comments but no bug triager or linux maintainer comments
<highvoltage> asac: have you ever considered a firefox-essential package that doesn't pull in synaptic, gnome-app-install, etc?
<ccm> hey
<ccm> do you think, that #334344 is fine as a wishlist entry or should this be a blueprint?
<cjwatson> ccm: that's a wishlist bug
<cjwatson> ccm: in general, only software developers should be writing blueprints, anyway
<ccm> cjwatson: okay, than that's fine as it is, thank you
<superm1> pitti, thanks.  hopefully that should address Keybuk's concerns about having python in the boot process :)
<Keybuk> it's the Indiana Jones act
<Keybuk> No Python in my Boot!
 * ogra feels reminded on "my hovercraft is full of eels"
<ogra> (but you probably need to know german to get the connection :) )
<asac> highvoltage: i think you refer to ubufox being a recommends?
<Keybuk> æçæ°£å¢è¹è£æ»¿äºé±é­
<ogra> Keybuk, your white squares are quite distroted today :)
<highvoltage> asac: it seems that it's apt-url that's bringing in most of the stuff that someone might not want installed
<asac> thanks. now i see that subpixel rendering for those foreign signs still is bad here
<ogra> use driod fonts ;)
<primes2h> asac: Hello, I provided a patch for this bug #334345, could you have a look please?
<ubottu> Launchpad bug 334345 in mobile-broadband-provider-info "H3G Italy APN needs to be updated." [Undecided,New] https://launchpad.net/bugs/334345
<asac> highvoltage: yes. thats ubufox - which needs apturl
<asac> highvoltage: and thats a recommends from firefox
<Riddell> doko: it needs a build-dep on python-qt4
<Riddell> doko: or rather python-qt4-dev needs to depend on python-qt4 not python-qt4-common
<doko> argh ...
<doko> Riddell: ok, I'm uploading this to the pythoneers PPA for now
<Riddell> as well as python-qt4's depend on python-qt4-common needing a version
<Riddell> doko: which are you uploading?
<doko> Riddell: quiscintilla2
<doko> but yes, python-qt4 should be fixed as well
<primes2h> asac: That bug prevents people from connecting to Internet due to invalid APN
<superm1> pitti, i think i see what might have caused that sound bug in the new hal.
<pitti> superm1: see bug 334299
<ubottu> Launchpad bug 334299 in hal "Jaunty: No sound cards any more" [High,In progress] https://launchpad.net/bugs/334299
<pitti> the debdiff
<primes2h> pitti: Now jockey patch works. Thank you.
<primes2h> :-)
<pitti> superm1: I'm fairly sure that the tools/Makefile.in diff in 87_standalone_smbios.patch broke it
<superm1> pitti, yeah I think so
<pitti> primes2h: \o/
<superm1> pitti, looking right now
<liw> there's no reason why "sudo lsof +D chroot/proc" should take over half an hour to run, is there?
<asac> primes2h: yes. is it consent that pre-paid is better translated in there?
<asac> hmm
<primes2h> asac: Now H3G Italy has two class of contract, subscription and rechargeable (I hope it's correct in English) and they have just two different APN, so the classification I did it's correct in Italian language.
<primes2h> asac: datacard.tre.it isn't present in the current classification and it leads to connection failure...
<Silicium> is there a bug in 8.0.4-2-Desktop Live CD in case of USPlash?
<primes2h> asac: Other APN (e.g. pre.h3g.it) are no longer used.
<superm1> pitti, give this a shot: http://pastebin.com/f4df29ea1 . I'll reboot the box right now in the interim and see how things come with it
<asac> primes2h: ok. so that changed recently. thanks
<primes2h> asac: yes according to the link I provided in the bug report.
<pitti> superm1: ah, that makes sense
<pitti> superm1: am__EXEEXT_6 just fell off the border then
<superm1> pitti, yeah that's what i'm thinking
<pitti> superm1: I was pondering a complete 99_autoreconf.patch, but if that fixes it already, so much the better
<s0u][ight> hello, the ubuntu live cd: how does it make a configuration file for X?
<s0u][ight> and when,
<cjwatson> it calls dpkg-reconfigure xserver-xorg during boot
<s0u][ight> is there a way to change that?
<cjwatson> /scripts/casper-bottom/20xconfig in the initrd
<cjwatson> you can edit that script if you like
<Silicium> cjwatson: do you know the my usplash file doesnt display while booting liveCD?
<superm1> pitti, yeah after a reboot it appears to fix it for me
<cjwatson> Silicium: no
<pitti> superm1: still building here, and checking debdiff
<Silicium> http://pluto.htu.tuwien.ac.at/How-To_Live-CD_verÃ¤ndern
<Silicium> i used this tutorial
<primes2h> asac: is it possible to have it loaded in Intrepid too? There are lots of Internet keys recognized by the system that can't connect due to this bug.
<s0u][ight> cjwatson, do i have to rebuild the initrd to make it take effect?
<cjwatson> s0u][ight: yes
<Silicium> yep
<asac> primes2h: yes, we put database updates in all releases. the upstream guy maintaining the database is currently super busy (moving)
<Silicium> https://help.ubuntu.com/community/LiveCDCustomization
<s0u][ight> i tryed rc.local as a workaround but that seems to be executed right after x is started
<Silicium> this is a gread tutorial for do that
<asac> so probably i will have to do this downstream (i think we have a few more updates already)
<Silicium> great
<s0u][ight> i need one right before
<pitti> superm1: debdiff /var/cache/apt/archives/hal_0.5.12~rc1+git20090204-0ubuntu1_i386.deb hal_0.5.12~rc1+git20090204-0ubuntu3_i386.deb looks good, that adds /usr/lib/hal/hal-system-smbios
<primes2h> asac: ok, Thank you!
<s0u][ight> as of now after x is started, i just have to restart it with ctrl alt backspace and x loads with the new by nvidia-xconfig created config file
<pitti> superm1: works for me as well; do you want to commit/upload, or shall I?
<superm1> pitti, if you could that would be better/quicker, i'm without a GPG key and SSH key where i am right now
<pitti> superm1: no problem at all
<superm1> (hence my DEBEMAIL of oem@oem-laptop :))
<pitti> superm1: thanks for the quick reaction
<superm1> pitti, no prob. sorry for the small break there.  touching Makefile.in is always annoying
<s0u][ight> btw, could you guys frequenty update the live cd isos? after the installation you allready get about 200 Mb of updates
<s0u][ight> like each 2 weeks would be great
<cjwatson> we could perhaps do daily builds, but there's no way we can QA them
<s0u][ight> qa?
<cjwatson> (well, not daily as such, I mean "of the general character of daily builds")
<cjwatson> quality-assure
<cjwatson> i.e. test
<cjwatson> they would be arbitrarily broken
<s0u][ight> each 2 weeks would be quiet good to go
<cjwatson> we can't test that either
<cjwatson> we're already flat-out with jaunty
<cjwatson> so we could produce untested images. Would that actually help?
<cjwatson> I'm concerned that they could end up being a bit shoddy
<cjwatson> there are also unfortunately some disk space concerns on cdimage
<Silicium> cjwatson: do you know which guy maintains the live-cd bootsplash?
<s0u][ight> extracting the squashfs and updating content and rebuilding iso, what could break?
<cjwatson> Silicium: it's not well-maintained by any one person at the moment
<cjwatson> s0u][ight: hahahaha
<cjwatson> s0u][ight: you would not believe
<cjwatson> s0u][ight: and we wouldn't do it that way anyway, it's crazy for full builds from scratch - much easier to just rebuild as usual
<Silicium> hmm
<Silicium> cjwatson: is there a bug with it?
<cjwatson> Silicium: all software has bugs
<pitti> superm1: uploaded
<cjwatson> so trivially, "yes"
<Silicium> cjwatson: is there a known bug?
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/usplash/+bugs
<s0u][ight> cjwatson, :| the way i mention: isn't it good?
<cjwatson> s0u][ight: no, it isn't
<cjwatson> s0u][ight: not for anything automated
<s0u][ight> then what is a good way?
<cjwatson> s0u][ight: why would it be an improvement to build images in a way that's different from the way we normally build images?
<cjwatson> s0u][ight: but *any* rebuild can cause problems, no matter how you do it
<cjwatson> the updates themselves could easily be broken
<s0u][ight> but how do you guys build those live cd's anyway
<cjwatson> s0u][ight: livecd-rootfs and ubuntu-cdimage
<cjwatson> s0u][ight: the process requires a full local mirror, which is why we don't recommend it to people building customised versions
<cjwatson> s0u][ight: you're still missing the point, though; the point is not that we do not have a reasonably reliable build process
<s0u][ight> cjwatson, as long as updates are not broken, my way is good to go, done it a few times and no problems till now
<cjwatson> s0u][ight: the point is that the process of rolling in updates almost inevitably causes breakage from time to time, which involves somebody paying attention to the regular builds and fixing them up
<primes2h> asac: Just another thing. In Jaunty I noticed, in the mobile connection wizard, that just few country names are showed, the most are not and it shows "missing from libgweather". Something changed in libgweather?
<cjwatson> s0u][ight: for example, every time the kernel's module ABI changes, we have to make sure that the installer is rebuilt
<cjwatson> s0u][ight: this is not a problem that affects upgraders, but it inevitably affects CD images
<asac> primes2h: can you please file a bug against libmbca about that and subscribe me?
<s0u][ight> hhmmm i understand
<cjwatson> s0u][ight: it is certainly easy to do, but requires people paying attention to intrepid-updates at that level
<s0u][ight> cjwatson, isn't there a way to automate that?
<cjwatson> s0u][ight: in other words, it's an extra load placed on already very busy people
<cjwatson> s0u][ight: no, it requires a GPG-signed package upload
<primes2h> asac: ok.
<s0u][ight> :( i need one soon :D
<Silicium> cjwatson: any idea how i can fix that?
<cjwatson> s0u][ight: I am happy to build an image if you promise not to complain if it is broken
<cjwatson> Silicium: no, sorry
<cjwatson> Silicium: I may have uploaded usplash occasionally, but I don't have time to work on it at the moment, I'm afraid
<Silicium> ok
<s0u][ight> cjwatson, never mind then
<cjwatson> s0u][ight: do you want it or not? :)
<cjwatson> bah
<primes2h> asac: Done. I subscribed you to bug #334377
<ubottu> Launchpad bug 334377 in libmbca "Lots of country names are missing, showing "missing from libgweather" in mobile broadband connection wizard." [Undecided,New] https://launchpad.net/bugs/334377
<primes2h> asac: Thanks.
<ogra> sigh, locale-gen runs since 2h on the slug ...
<Chipzz> cjwatson: ping, have a question for you on #debian-installer on irc.debian.org :)
<MacSlow> Can I edit a commit-message _after_ I did the commit (not pushed though) with bzr?
<MacSlow> I copy&pasted a line that accidentally had a CR in it
<ogra> you can uncommit
<ogra> and commit again
<moquist> I'm attempting to use dbconfig-common with the moodle package, which supports both mysql and postgresql. The configure step hangs. I added -x so I can see what's happening, and here's the config script and the output: http://rafb.net/p/m3MYtE25.html
<moquist> If anybody has any advice about how to use dbconfig-common or how to avoid that hang, I'd appreciate it...
<Keybuk> I strongly dislike the way that "yum update" does not do what "apt-get update" does
<liw> Keybuk, there you go again, assuming all software works the same; one would almost assume you had been exposed to usable software
<Keybuk> maybe I just shouldn't use a computer
<cjwatson> Chipzz: I don't see it any more quickly when you ping me here than when you ping me over <-- there
<evand> anyone else have roaming virtual desktops?  I swear, I get stuck with the weirdest bugs.
<liw> what are those?
<liw> I suspect that doesn't mean laptops :)
<evand> My windows seem to move to different virtual desktops on their own
<evand> rarely, when I ctrl-alt-left,right, and I'm definitely not holding alt.
<stgraber> StevenK: pong
<evand> err shift ;)
<Silicium> with wich gcc should the usplash be compiled?
<cjwatson> Silicium: it lists no specific requirement, so it's built with the default compiler, like most other packages in Ubuntu
<Silicium> hmm
<Silicium> strange
<Silicium> i downloaded a usplash build environment with makefile
<Silicium> the prebuild so works fine
<Silicium> if i just "make" it own, it exit with no errors but the so dosnt work
<MacSlow> gee... where is the sleep() call burried in Python? os, sys, elsewhere?
<MacSlow> anybody with a clue?
<MacSlow> thanks in advance!
<james_w> MacSlow: time?
<hwilde> time.sleep()
<MacSlow> time.sleep (2) does not work
<MacSlow> I tried to import time and os and sys
<MacSlow> always complains
<james_w> time python -c 'import time; time.sleep(2)'
<MacSlow> james_w, ah that worked ... thanks
<slangasek> cjwatson: ah, should've looked deeper than the NBS report, ahwell
<slangasek> ogra: yes, that was discussed
<alex-weej> MacSlow: the icons for notify-osd should be symlinked in hicolor i think
<alex-weej> so by all means make them original in Human
<slangasek> cjwatson: so, I was expecting a d-i upload, just wasn't expecting to re-roll !ARM images for it
<MacSlow> alex-weej, that currently being worked on by kwwii
<alex-weej> but add some symlinks in hicolor so that people who want to use e.g. gnome icon theme can have usable volume widgets
<alex-weej> MacSlow: excellent - might wanna update the wiki when you get round to it
<ogra> slangasek, good, i wasnt sure what to answer cjwatson when he looked so shocked at me :)
<alex-weej> cause right now it suggests "Human or go home"
<alex-weej> :)
<MacSlow> alex-weej, I've mentioned that in https://wiki.ubuntu.com/NotificationDevelopmentGuidelines
<Laney> is this why the volume indicator is blank for me?
<MacSlow> Laney, yes
<cjwatson> Keybuk: https://fcp.surfsite.org/modules/newbb/viewtopic.php?viewmode=thread&topic_id=67253&forum=11
<Laney> righto
<MacSlow> alex-weej, ehm... I'm just adding that... thought I had written that down already
<cjwatson> ^- glibc upstream developer recommends i586 and says that i686 is not worthwhile
<alex-weej> MacSlow: hehe ok cool
<cjwatson> (sorry, I'm sure there's a more sensible URL for the above)
<cjwatson> slangasek: ok, feel free not to
<cjwatson> slangasek: although the hal bug probably hits us either way :-/
<slangasek> yeah, I gathered that
<Keybuk> cjwatson: handy to know
<Keybuk> the benefits I saw where i386->i586, I picked up from someone else that i686 was the new recommendation - they must have been wrong
<ogra> yay
<Keybuk> (Moblin use SSE2 fwict)
 * ogra is in pkgsel on the slug
<Keybuk> or even maybe SSE3
<ogra> if flash-kernel is run in the end i'm actually a happy camper
<jdong_> was it once true that i586 is slower than i486 on non i586 hardware?
<cjwatson> it's probably worth separating out the individual optimisations being talked about here
<cjwatson> my recollection is that pipeline ordering for i586 was pessimal elsewhere
<cjwatson> but that should be verified, and may not be part of modern -march=i586
<jdong_> along those lines, Ive never found a satisfactory answer for the difference between lpia and i386 in terms of the compiler output difference
<jdong_> is it just that lpia implies sse2, sse3, ...?
<cjwatson> lpia was intended to be optimised for in-order execution
<cjwatson> the compiler patches for this never appeared (except perhaps very recently, I forget)
<cjwatson> so in practice it's just been an i686 architecture, I think
<slangasek> cjwatson, pitti: what's the current status of getting hal fixed?
<pitti> slangasek: it should have gotten published 5 minutes ago
<slangasek> pitti: you said it was uploaded - is it the -0ubuntu3?
<pitti> slangasek: ubuntu-meta is also in (for computer-janitor-gtk)
<slangasek> ok
<pitti> slangasek: and Riddell uploaded new kubuntu-meta for downsizing
<NCommander> ogra, are you using d-i over a serial console or SSH?
<pitti> slangasek: confirmed, ubuntu3
<pitti> slangasek: so the only thing I'm still aware of is a d-i rebuild from cjwatson
<ogra> NCommander, ssh indeed
<NCommander> Very cool
<pitti> slangasek: then we can spin new images
 * NCommander would like to blog about it both on Planet, and on the NLSU2 community lists (if they still exist ;-))
<slangasek> pitti: the only reason to wait for the new d-i before respinning is jigdo, which is a marginal benefit for an alpha
<slangasek> pitti: so not planning to do that
<cjwatson> jdong_: https://fcp.surfsite.org/modules/newbb/viewtopic.php?viewmode=thread&topic_id=67253&forum=11&post_id=323188
<ogra> NCommander, i have yet to see it working after first reboot, but so far it looks good
<cjwatson> pitti: I already uploaded that
<pitti> slangasek: ah, ok; no other blockers on my list
<cjwatson> ubuntu21
<NCommander> ogra, yes I know. Maybe I should make a list of the other ARM devices we have kernels for, and see if I can attract a community
<NCommander> s/I/we/g
<ogra> well, lool has the thecus .... but i doubt he has the time
<ogra> feel free to blog about it or write a miling list call for testers
<NCommander> He said d-i works, just the kernel is foobared.
<NCommander> (or d-i started, not sure if it works)
<jdong_> cjwatson: ah thanks for the info
<sbeattie> cjwatson: interesting that -mtune=generic is recommended; opensuse used to use -march=i586 -mtune=i686
<lool> Yeah Ubuntu's d-i would work if started with a Debian kernel no the Thecus
<lool> I had in mind to try out the Debian 2.6.28 kernels and if they work bisect the configs
<LaserJock> cjwatson: do you know if tasksel-data has been updated recently?
<LaserJock> or if it's automated to some degree
<cjwatson> LaserJock: I upload it from time to time; the update is automatic but not the upload. What's the problem?
<LaserJock> cjwatson: I noticed the edubuntu-desktop task was wrong
<LaserJock> cjwatson: it's using edubuntu-desktop-addon but the current seed is edubuntu-desktop-gnome
<cjwatson> LaserJock: I can easily correct that, although probably not for alpha 5
<LaserJock> cjwatson: k, should I file a bug or will you remember?
<cjwatson> I'm running the update script now, so no need
<LaserJock> k
<cjwatson> I have a script I run occasionally that tells me about unreleased packages on my disk
<LaserJock> cjwatson: so Task-Key: edubuntu-desktop just gives the title of the task?
<LaserJock> within tasksel
<cjwatson> no, Task-Key: turns into Key: in the tasksel data file, which means "don't present this task unless the key package is available"
<LaserJock> oh, oh, gotcha
<LaserJock> I was thinking Task-Metapackage would do that
<LaserJock> in any case, as long as it get's updated we're all good
<highvoltage> hey Laser
<LaserJock> hola highvoltage
<doko> pitti: did you have plans to demote tcl8.4 for jaunty?
<pitti> doko: would be nice indeed
<ogra> hmm, why do we generate locales twice in d-i
<cjwatson> we shouldn't ... but locale-gen is very memory-intensive at the moment and is always going to suck badly on lowmem
<TheMuso> slangasek: Can I assume that the latest set of studio isos have the hal fix, i.e 20090225.2?
<ogra> once its done in the "saving language" step and once if the langpack is installed
<ogra> yeah, it takes about 2h for each run on the slug
<slangasek> TheMuso: it does; please test :)
<TheMuso> slangasek: thanks.
<cjwatson> ogra: hmm, I think install-language-pack ought to notice that the locale was already generated by a manual locale-gen run and not bother regenerating it
<cjwatson> ogra: IOW this sounds like a langpack-locales bug
<ogra> oh, wait
<ogra> it is only at en_AU.UTF-8
<ogra> it *might* skip en_US if it ever gets to that
<cjwatson> yeah, this is going to really suck for you I'm afraid
<cjwatson> I did start work on improving localedef's memory consumption a while back
<cjwatson> I had trouble getting the "improved" code to be correct though ...
<cjwatson> so I put it down to work on other things and haven't picked it up again
<cjwatson> in theory I'm confident we could at least chop it in half
<ogra> well, i'll try a new install to a real USB HDD later, there the swapping shouldnt suck so much
<cjwatson> on a 30MB machine you would still be thrashing swap, though
<ogra> indeed
<ogra> but with a faster swap it will all go faster i assume
<ogra> i have a 7500rpm USB HDD around
<superm1> slangasek, how soon will mythbuntu isos be respun for testing?
<slangasek> superm1: ~3h
<superm1> slangasek, okay great thanks
<slangasek> there's more contention for livefs buildds; y'all shoulda stuck with alternate CDs instead ;)
<ogra> or help me testing slug netboot images :)
<ogra> they are spun very quickly ... just take a day to do a commandline install ;)
<LaserJock> ogra: that reminds me of doing Gentoo install back in the day :-)
<ogra> heh, yeah
<ogra> 133MHz and 30M ... its fun
<wubbbi> hey :) I want to fix this bug (https://bugs.launchpad.net/ubuntu/jaunty/+source/kubuntu-default-settings/+bug/309419) where can I find the default Panel size in the kubuntu-desktop-settings package?
<ubottu> Ubuntu bug 309419 in kubuntu-default-settings "jaunty: Kubuntu panel doesn't extend all the way across desktop on all intel machine" [Undecided,New]
<Riddell> wubbbi: it's in a file called plasmarc
<wubbbi> Riddell: thank you :)
<Riddell> wubbbi: but it's fiddly, we may end up just patching the code rather than playing with config files
<Riddell> wubbbi: ask on #kubuntu-devel if you have further questions
<wubbbi> Riddell: k thank you
<dmz> quick question..i need to build a customer xserver-xorg-core package with the xserver built in screensaver (MIT X) disabled (for a kiosk machine, xset doesn't work); i'm using phbuilder to build for x386 (amd64 box doing the build). i can build the package fine but i need to modify the configure options and patch the server..should i make a new patch & add to the diff.gz that comes with source package? what's the best way to hav
<dmz> e my patch go into the build i'm doing?
<cody-somerville> dmz, you should use whatever patch system the package uses
<cody-somerville> dmz, Do you know what patch system xserver-xorg-core is using?
<dmz> i'm using phbuilder to build the package
<dmz> it's just the "apt-get source" for the ubuntu/deb package
<dmz> and it just looks like a normal patch like i'd use "patch -p0" for
<dmz> apt-get source xserver-xorg-core && sudo pbuilder build xorg-server_1.4.1~git20080131-1ubuntu9.2.dsc --debug --debbuildopts "-I -i -j5"
<dmz> i've tried modifying the tgz that comes with the source and fixing the length & checksum on the dsc file, but then the patch failed
<dmz> is there a good devel guide for custom ubuntu package management or such?
<cody-somerville> dmz, Sure is. First tip: don't modify the tarball or .diff.gz
<dmz> sorry if i'm not asking in right area, but i figured this was a package build question could be answered her easier
<cody-somerville> https://wiki.ubuntu.com/MOTU/GettingStarted
<dmz> i didn't want to :)
<dmz> cody-somerville, thanks
<savvas> I installed jaunty, formatted root / and kept /home intact. During the install of jaunty, at the end I was prompted to import configuration for pidgin, firefox, and some other programs - does that get the configuration files like .mozilla/firefox and place them appropriately to the new user account?
<slangasek> superm1`: mythbuntu up
<slangasek> yay, faster than I thought
<slangasek> TheMuso: did sound check out for you in your latest ubuntustudio test?
<TheMuso> slangasek: seemed to be ok, will check more thoroughly for my next test. Unfortunatley seems like other studio guys don't care about testing much any more, especially Cory who is not bothering because other people don't, which is unfortunately starting to rub off on me. :(
<slangasek> well, "no testing" --> "no releasing" ...
<slangasek> anyway, if sound "seemed" ok, then that should mean this bug is fixed, thanks :)
<TheMuso> slangasek: I know that.
<TheMuso> re testing
<ebroder> Do backports changelog entries have LP closers?
<RainCT> ebroder: I don't think so
 * hyperair thinks that [needs-packaging] bugs should automatically get closed by their LP closers
<calc> is it possible to checkout a subdir of a bzr repo?
<calc> like with cvs and svn?
 * RainCT wonders what relation there's between needs-packaging bugs and backports
<LaserJock> calc: not usually no
<LaserJock> calc: I think there was a bzr plan to allow for that, but I don't know if it's ever been implemented
<calc> LaserJock: ok
<calc> LaserJock: i wanted to be able do something like that so i could have a single repo for the OOo split build
<ScottK-desktop> hyperair: I think there's an existing LP bug on that.
<hyperair> ScottK-desktop: i see. good to know it's being worked on
<slangasek> I don't think he said 'worked on' :)
<slangasek> zul: well, samba 3.3.0-4-ubuntu1 build-deps on ctdb; will you file an MIR for that, or roll back the build-dep?
<hyperair> slangasek: blah.
<zul> slangasek: sure
<tjaalton> ArneGoetje: hey, would you consider making ttf-* use triggers to only run defoma-font after all packages have been configured? or maybe that should be done in debhelper?
<tjaalton> hum, it's defoma which has dh_installdefoma, not debhelper
<slangasek> tjaalton: there are rumblings about getting rid of defoma altogether; are there cases that still need it?
<tjaalton> slangasek: I'm not sure, just concerned that it takes a while to run it N times when you install a number of langpacks which pull a lot of fonts
<tjaalton> on every fresh install
<tjaalton> same goes to texlive-lang*
<slangasek> texlive packages have their own problems unrelated to defoma, AFAIK
<tjaalton> yes, but they could trigger mktexlsr
<tjaalton> I might fix that for jaunty
<moquist> is there a preferred way to check in postinst whether or not another package is installed?
<slangasek> moquist: using dpkg --status
 * calc kicks bzr and lp hard :-\
<calc> they won't allow to put an extra / in the project or name of a branch
<slangasek> moquist: though generally it's better if you don't have to do this at all; care to provide details?
<moquist> slangasek: and checking the output? the exit code seems to be 0 every time.
<slangasek> moquist: the output, yes
<moquist> slangasek: sorry. LaserJock is castigating me for vagueness, too.
<slangasek> ah, moodle
 * slangasek wondered :)
<calc> they also have no concept of partial checkout, so i can't organize my split build in any decent fashion in the repo :\
<calc> we need a svn.launchpad.net
<calc> heh
<moquist> slangasek: moodle can use php5-mysql or php5-pgsql. If the user wants mysql and php5-mysql isn't installed, I want to let the user know the installation (in the Web browser) can't complete until the package is installed. Same thing for php5-pgsql.
<slangasek> moquist: I thought the solution that had been settled on was to have moodle-mysql | moodle-pgsql, which each depend on the correct set?
<slangasek> in which case you shouldn't need to query the dpkg database, just use some filesystem-based interface to those packages
<moquist> slangasek: that solution is (at least ATM) rejected in debian
<slangasek> hmm
<moquist> slangasek: it's not a total solution anyhow, it would still be possible to screw yourself by answering a question incorrectly.
<slangasek> how?
<moquist> install moodle-mysql and tell config you want to use postgresql (which is the default)
<slangasek> well, but you said "answering a question incorrectly" - the obvious solution there is to never ask a question when only one of moodle-{mysql,pgsql} is installed
<moquist> slangasek: right. I didn't figure out how to do that if/when the question is in the base moodle package. The question could be moved into the moodle-* packages, but that's apparently not couth so we're not pursuing that ATM.
<slangasek> don't ask the question in the config script, only ask it in the postinst
<moquist> ah, so a multiple-binaries package only has one config, and it's cool to ask questions in postinst?
 * moquist did not know that
<slangasek> some people may dispute whether it's "cool" to ask questions in the postinst - I don't feel constrained to avoid asking questions in the postinst when the alternative is asking unnecessary questions in the config :)
 * moquist nods
<moquist> slangasek: this is very helpful to know. Thank you.
<slangasek> you will get a lintian warning about this, which you should summarily override ;)
<cjwatson> hyperair: they do, if you put the appropriate "LP: #nnnnnn" in the changelog (which you should)
<cjwatson> it is not true to say that a multiple-binaries package only has one config script, though
<hyperair> cjwatson: i do, but they don't get closed. i had to close my previous two packages' needs-packaging bugs
<cjwatson> config scripts are per-binary
<cjwatson> hyperair: can you give me an example? this sounds like a bug
<cjwatson> it's certainly not as intended
<hyperair> i think codelite and sigx was like that
<hyperair> i think geanyvc and geanyprj was also like that
<hyperair> either mok0 or i closed the
<hyperair> m
<cjwatson> now, let me figure out how to get hold of the original .changes file ...
<cjwatson> ah yes, of course, in the DONE queue
<cjwatson> hyperair: oh, I know the reason
<hyperair> why?
<cjwatson> hyperair: bugs can have multiple tasks; therefore normally an upload only closes bugs that are filed against the appropriate source package
<cjwatson> s/only closes bugs/only closes bug tasks/
<hyperair> ah yes
<cjwatson> hyperair: but of course for a new package there's no such task, and can't be
<hyperair> but the thing is you can't file against a source package that doesn't exist
<hyperair> can you?
<hyperair> yeah
<hyperair> so that's the issue with needs-packaging requests
<cjwatson> I'll file a bug about this
<hyperair> thanks
<cjwatson> there are probably some heuristics that could be applied
<hyperair> at the very least, it could just look for needs-packaging requests
<hyperair> or perhaps if there's only one task, then close that task
<hyperair> for example
<hyperair> generally needs-packaging requests are filed to ubuntu, and there are no additional tasks imo
<TheMuso> slangasek: yeah sound is quite alright in studio here. Playing music with totem is fine via pulse for example.
<moquist> cjwatson: thx
<slangasek> TheMuso: yes - the bug in question would have left you with no access to the sound device at all, so it's clear that this is fixed, thanks
<cjwatson> slangasek: err, I didn't think you could call dpkg --status safely in the postinst
<cjwatson> slangasek: dpkg isn't re-entrant, in general; when running a postinst it might not have saved its internal state ...
<slangasek> cjwatson: I think Ian promised me that you could
<cjwatson> really? gosh
<slangasek> even though I didn't want him to promise that, I wanted him to promise the opposite ;)
<cjwatson> this was always in my "don't do this" bin :)
<cjwatson> hyperair: bug 334573
<ubottu> Launchpad bug 334573 in soyuz "uploads of new source packages can't close bugs" [Undecided,New] https://launchpad.net/bugs/334573
<hyperair> ooh nice
<hyperair> thanks =)
<hyperair> well i'll be off to sleep now. good ni-er morning.
<ogra> Jan  1 04:22:20 in-target: Generating locales...
<ogra> Jan  1 04:22:23 in-target:   en_AU.UTF-8...
<ogra> Jan  1 06:10:11 in-target: done
<ogra> Jan  1 06:10:11 in-target:   en_BW.UTF-8...
<ogra> Jan  1 07:52:24 in-target: done
<ogra> Jan  1 07:52:25 in-target:   en_CA.UTF-8...
<ogra> wow ....
<ogra> still ongoing ...
<LaserJock> poor ollie
<ogra> LaserJock, well, thats actually not something we can expect from our users ... even on that crappy HW
<ogra> i guess it has to work without installing a pangpack
<ogra> *lang
<LaserJock> or is that "painpack" ;-)
 * ogra wonders why d-i *ubuntu21 still isnt in the archive
<ogra> slangasek, could it be that it needs some NEW love or some such ? https://launchpad.net/ubuntu/jaunty/+source/debian-installer/20081029ubuntu21 shows it's been published 7h ago
<ogra> but http://ports.ubuntu.com/ubuntu-ports/dists/jaunty/main/installer-armel/ doesnt have it yet
<slangasek> ogra: the url you posted would have shown it as 'NEW' instead of 'DONE' for armel if that were the case
<ogra> hmm, strange
<cjwatson> lp_archive@cocoplum:~$ ls -l /srv/launchpad.net/ubuntu-archive/ubuntu/dists/jaunty/main/installer-armel/current
<cjwatson> lrwxrwxrwx 1 lp_publish lp_publish 16 Feb 25 16:03 /srv/launchpad.net/ubuntu-archive/ubuntu/dists/jaunty/main/installer-armel/current -> 20081029ubuntu21
<slangasek> ogra: I see it in the archive; mirroring issue then
<ogra> ah
<cjwatson> poke IS
<ogra> cjwatson, though it looks like we need a way to omit langpack installation (see the timestamps in my above paste) for A6
<ogra> not sure thats easily possible
<cjwatson> ogra: preseed pkgsel/language-pack-patterns=
<cjwatson> ogra: (yes, I realise this is perhaps not entirely obvious)
<ogra> heh, no, not at all :) thanks
<cjwatson> ogra: it's 'd-i pkgsel/language-pack-patterns string' in a preseed file; the above is the alternative kernel boot parameter form
<cjwatson> ogra: perhaps we could have lowmem do this
* spm changed the topic of #ubuntu-devel to: LP down 00:00-01:00 UTC | Archive: feature-frozen | main frozen for alpha-5 | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | LP believed fixed - please report any further tim
<ogra> yeah, i'll look into it after A5
<cjwatson> or I could do it now, I have the file open :)
<ogra> well, if you feel like :)
<ogra> i surely wont stop you
<ogra> i have forgotten how many locales -en includes ... but that can easily take 10-2h
<ogra> *12
<cjwatson> done in localechooser
<ogra> mucho gracias :D
<jamesrfla> Vote for nhandler!!!
 * slangasek raises an eyebrow
<nhandler> slangasek: Just ignore him. He did the same thing in #ubuntu-motu
<slangasek> nhandler: so I shouldn't vote for you?
<ScottK> Since it's not an actual election no campaigning is needed.
 * ogra looks in his inbox for bribes ...
<nhandler> slangasek: I never said that. I just said to not pay any attention to his comment.
<maco> haha
<maco> so what's the not-really-an-election thing that he's trying to campaign for you for?
<nhandler> maco: MOTU Council. It is a confirmation vote
<nhandler> maco: https://edge.launchpad.net/~ubuntu-dev/+polls
<maco> ah, well i probably cant look at that because i'm just pretending to belong in here :P
<LaserJock> nhandler: was that every announced? I haven't gotten any email on that I don't think
<LaserJock> *ever
<nhandler> LaserJock: Nope. They haven't sent anything out yet. I just posted a link to the Tech Board meeting logs in #ubuntu-motu if you want to read about it
<nhandler> cjwatson: Is the Tech Board planning on sending out an email about the vote?
<LaserJock> slangasek: hot dog! we've got a moodle package that actually installs (if you have the DB preinstalled) and removes
<LaserJock> slangasek: am I too late to get a FFe for Alpha5?
<slangasek> LaserJock: no - moodle isn't on the CDs
<slangasek> or is it on the edubuntu CD?
<LaserJock> it is
<LaserJock> I think, let me check real quick
<slangasek> ok
<slangasek> well, we haven't had any edubuntu tests check in yet either, so still ok
<ogra> it shouldnt
<ogra> the edubuntu-server package never made it on any CD iirc
<LaserJock> it's on there
<ogra> oh
<LaserJock> edubuntu-server isn't
<LaserJock> but moodle, mysql, etc. are
<ogra> even more oh
<ogra> but thats only the addon, right ?
<LaserJock> yeah
<LaserJock> moodle is in both the server and ship-addon seeds
<ogra> right, but server isnt used for anything
<ogra> only for a metapackage in the archive
<StevenK> stgraber: Ping, if you're still here.
<LaserJock> slangasek: bug #334611
<ubottu> Launchpad bug 334611 in moodle "Feature Freeze Exception: moodle 1.9.4-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/334611
<stgraber> StevenK: yeah
<slangasek> LaserJock: ack
<LaserJock> slangasek: as in FFe ack or "yeah, whatever I'll look at it in a coupla days"? :-)
<slangasek> as in I'll look at it in the next hour
<LaserJock> slangasek: awesome thanks
<LaserJock> slangasek: this one ended up even better than I had anticipated
<seb128> slangasek: when you will not be too busy can you double check gwibber in new and accept it if it looks good to you? I has been uploaded before the freeze technically but there was some issues and an another upload round, it should be fine now and quite some users would be happy to get it to jaunty it seems
<seb128> slangasek: "double check" because I already reviewed it but there is some sources under bsd3 and I would appreciate somebody else confirming that's not an issue ;-)
<slangasek> seb128: ok
<seb128> thanks
 * directhex hands slangasek some belated christmas cake
 * slangasek looks at the cake quizzically, and shakes it
<directhex> slangasek, mono 2 transition has officially begun in sid, just noticed your changes went directly into our svn
<directhex> which saves lots of time \o/
<seb128> "Launchpad will be going offline for maintenance in seven minutes. "
<seb128> does that mean it's time to go to bed? ;-)
<ogra> likely
 * ogra sighs ... en_DK.UTF-8... 
<ogra> why the heck do danes have their own english locale ...
<ogra> lots of germany speak english as well and we dont have a en_DE
<ogra> *germans
<directhex> ogra, perhaps you should! file a formal request to ISO
<ogra> eek
<ogra> not really
<slangasek> directhex: good-good
#ubuntu-devel 2009-02-26
<phil_ps> I submitted a patch for glife a few days ago on launchpad
<phil_ps> contacted the maintainer...
<phil_ps> no response from either...
<phil_ps> (I know glife is not a top priority program, but it was my first patch)
<nhandler> phil_ps: What does the patch do?
<phil_ps> nhandler: makes it compile again.  (ports from glade0 to glade2)
<phil_ps> nhandler: its been a year since the package worked
<nhandler> phil_ps: You will want to file a Freeze Exception request for it (https://wiki.ubuntu.com/FreezeExceptionProcess). Once the request gets approved, subscribe ubuntu-universe-sponsors to the bug to get it uploaded
<phil_ps> nhandler: it was the first thing on the "harvest" list
<phil_ps> nhandler: thanks
<nhandler> phil_ps: You're welcome
<phil_ps> nhandler: oh, I see, the new ubuntu is coming out so there is a freeze.  I've heard of that
<maco> haha that's a good thing for a patch to do...
<phil_ps>  its gnome2-0 supported in ubuntu 9.04? where would I find out without installing it
<phil_ps> (on a windows machine...)
<phil_ps> (linux laptop is on loan...)
<maco> packages.ubuntu.com
<phil_ps> thanks marco
<phil_ps> hmm, I guess I should get the beta and try to get it to compile there. (I am such a newbie...)
<maco> phil_ps: alpha, actually
<phil_ps> the thing I love about working on open source software so far is interacting with people regarding computers.  I am in grad school but still, it's considered cheating when you discuss problems....
<phil_ps> marco: thanks
<ia> wooow... new gdm theme in jaunty incredibly amazing :-)
<maco> phil_ps: my school says we can discuss, just write our answers independently (undergrad here)
<maco> phil_ps: and there's no r
<phil_ps> marco: yeah they say that here too.  but I dunno, this is just so much more fun
<maco> phil_ps: you know, i only get highlighted if you spell my nick right
<LaserJock> hehe, maco has a new nickname :p
<jdong_> maco: polo!
<maco> *snort*
<phil_ps> maco: sorry
<phil_ps> haha
<maco> isok im too busy laughing at jdong_ now
<maco> actually...i think i have a picture of marco polo's house...
 * LaserJock wonders if it has a pool
<maco> LaserJock: its in venice. just walk out the front door.
<maco> i took the photo from a gondola
<maco> oh....i guess that explains why it's a swimming game
<ajmitch> water polo is :)
<maco> ajmitch: marco polo is too...
<ajmitch> how odd
<maco> huh?
<ajmitch> nevermind
<LaserJock> yay, LP is back
<phil_ps> I hate that java doesn't have function pointers/delegates
<phil_ps> (probably wrong channel...)
<phil_ps> I'll goto ubuntu-offtopic
<jdong_> phil_ps: you can do the same with anonymous interface wrappers
<jdong_> well interface wrappers in general but Java now lets you declare them anonymously on the spot.
<jdong_> it is IMO utterly verbose and ugly but it does the same thing
<phil_ps> but the standard java components all use inheritance to achieve the effect. so annoying.
<directhex> phil_ps, don;t use java if you don;t like it
<phil_ps> have to for work
<phil_ps> directhex: the company loves it, so I have to learn it real quick for this project
<phil_ps> jdong_: i will look into that
<jdong_> phil_ps: but yes it's based off the same inheritance idea, just syntactic shorthand so you can do it on the spot.
<ArneGoetje> tjaalton,slangasek: until X.org has been changed that it would use fontconfig directly, we still need to deal with defoma. However, Keith Packard has mentioned that we works on that on the X side.
<jdong_> I absolutely agree with you there should be a more smooth way of doing it but Java isn't known for being non-verbose.
<maco> jdong_: which is more verbose, java or cobol?
<jdong_> maco: lol OF THE PRACTICAL LANGUAGES
<slangasek> ArneGoetje: what's left on the X side that doesn't just use Xft?
<snuffmeister> hey
<jdong_> maco: (select (list (languages (filter (practical) ))))))
<snuffmeister> dunno if this is the right channel but i-m trying to install jaunty
<snuffmeister> and the install from the livecd doens't work
<maco> ubuntu+1 may be what you're looking for
<snuffmeister> crashes, won't even start
<maco> but that could be useful info...
<maco> crashes when?
<snuffmeister> ooh
<snuffmeister> that's right
<snuffmeister> thanks
<ScottK> nhandler: patches to make stuff work don't need freeze exceptions.
<directhex> jdong_, how about some JNI? that's nice & sensible syntactically
<maco> snuffmeister: wait, when does it crash?
<snuffmeister> it doesn't start
<maco> does the lve cd not start or is it just the installer that's not working for you?
<snuffmeister> installer
<maco> did you try it from the command line to see if there are any error?
<snuffmeister> i tried installing directly from boot but it started the whole live cd, and the installer doesn't start
<snuffmeister> maco: no
<snuffmeister> how do i do that?
<jdong_> directhex: the last time I tried that I remembered the time I had to bridge a Ruby lib to Python using C as the middleman.
<maco> try that. open gnome-terminal and run ubiquity in there
<ArneGoetje> slangasek: I don't know. I'm not familiar with X.
<jdong_> that was a bazillion times easier.
<snuffmeister> is ubiquity the command?
<snuffmeister> didn't do anything, i'm waiting for the crash signal
<maco> yes, ubiquity's the installer command. run it in a terminal and pastebin whatever errors it throws
<nhandler> scottk: He was porting from glade0 to glade2. I would not consider that a basic bug fix
<ScottK> nhandler: I'd call porting from non-working to working a bug fix.
<snuffmeister> maco: didn't do anything, no errors no nothing
<snuffmeister> not even the crash signal
<ScottK> The downside risk is nil.
<maco> didnt launch either?
<snuffmeister> nope
<snuffmeister> lemme check the processes
<snuffmeister> nothing there
<nhandler> scottk: Depending on how you look at things, you could consider any change a bug fix
<maco> snuffmeister: did you check the cd?
<snuffmeister> for md5?
<snuffmeister> not really, but it's the third or fourth time i've tried it, cd and dvd over time
<ScottK> nhandler: This is true, but release management is mostly about risk management and if they thing is dead to start with, there's really not much to worry about.
<snuffmeister> and never worked, only by updating
* spm changed the topic of #ubuntu-devel to: Archive: feature-frozen | main frozen for alpha-5 | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | LP believed fixed - please report any further timeouts to #launchpad
<snuffmeister> i'm on the live cd, can i do that now?
<maco> snuffmeister: reboot and when you start up itll offer to checkthe cd's integrity
<slangasek> ArneGoetje: well, the only fonts that X itself /needs/ to have are fixed, serif, and sans (though I think the other two have other names in X); it doesn't need defoma for that; and any apps that use Xft bypass X's view of the fonts in favor of fontconfig
<slangasek> snuffmeister: what version (date) of the CD are you using?
<snuffmeister> ok, i'll do that
<snuffmeister> daily build
<snuffmeister> of yesterday
<snuffmeister> or 2 days ago
<slangasek> 2 days ago was broken
<snuffmeister> =x
<snuffmeister> mm
<snuffmeister> mm
<maco> well there's an answer
<snuffmeister> lol
<snuffmeister> ok
<slangasek> if you need a reliable CD for installing the development release, you should generally use the most recent alpha
<snuffmeister> alpha4 i guess
<ArneGoetje> slangasek: legacy X apps don't.
<slangasek> yes - unless you want to wait until alpha 5 is out tomorrow
<slangasek> ArneGoetje: correct
<slangasek> ArneGoetje: but I don't know any legacy X apps that need access to all the various fonts that are exposed via defoma
<slangasek> ArneGoetje: i.e., legacy X apps already have access to everything under /usr/share/fonts/X11, which is not managed by defoma
<snuffmeister> slangasek: crap, and i just formatted everything now =p
<snuffmeister> what time, btw?
<slangasek> snuffmeister: likely some time in the afternoon, US time
<snuffmeister> hmm.. nighttime in europe
<slangasek> yes
<slangasek> LaserJock: FFe acked
<LaserJock> slangasek: thank you kindly
<LaserJock> slangasek: are you going to respin the Edubutu CD then?
<slangasek> LaserJock: if it's still appropriate at the time the packages become available, yes
<ArneGoetje> slangasek: I personally know that fontforge needs the XLFD to access fonts. Other apps (which are not core X) I don't know at the moment.
<slangasek> if we happen to be left with an uninstallable moodle on the edubuntu alpha5 ISO, that's not the end of the world either
<LaserJock> slangasek: certainly not
<LaserJock> slangasek: I was just wondering when I should give the CD a test
<ArneGoetje> slangasek: and in the past (that might have been fixed already) there were problems toth .ttc fonts in oo.o if they weren't registered through defoma.
<ArneGoetje> s/toth/with/
<slangasek> LaserJock: ah, I was planning to check the testing status in deciding whether to reroll edubuntu for moodle :)
<LaserJock> slangasek: well, I can test it tommorow morning if we want to wait for a reroll
<slangasek> that would be fine
<LaserJock> k
<ArneGoetje> slangasek: I suggest that for karmac we disable the dh_installdefoma call in all font packages and put them into a ppa. Then we can test if there are still problems left.
<LaserJock> does the arch matter much for that one? I'm not really aware of anything that should be different between the amd64 and i386 CDs
<slangasek> ArneGoetje: alternatively, we could prod Debian to see what their plans are and what bugs they hit, since there was discussion recently on debian-qa :)  http://lists.debian.org/debian-qa/2009/02/msg00074.html
<nhandler> scottk: If that is the case, I would like to clarify what the wiki page says about Bug Fix uploads. So it would be clear that a new upstream releases/patches that fix broken packages that don't affect any other packages are ok to upload without a FFe
<ScottK> nhandler: Basically the question is bugfix or features.  It doesn't really matter much if it's upstream features or locally induced ones.
<ArneGoetje> slangasek: well, they want to fix it in squeeze... means within the coming 2 years or so... ;) If we want to be faster, then we should take the initiative for testing, I think.
<slangasek> ArneGoetje: well, I don't think pabs was talking about waiting two years before removing it, though. :)
<ScottK> So if a package is broken and you unbreak it, that's a bugfix.  An upstream release may also have feature changes and still need an FFe (we might prefer a patch to the new version).
<ArneGoetje> slangasek: true, but it might take a bit longer until all problems are found and fixed. So, the overall time until everything works like expected may take multiple Ubuntu releases.
<nhandler> scottk: But I think the definition of a bug fix is unclear. For instance, if my application doesn't currently have support for 'foo', someone might file a bug saying 'myApp does not work with foo'. So would a patch that fixes this count as a bug fix? Or would it be a new feature?
<ScottK> New functionality is a feature.
<ScottK> Just because someone scribbled in a bug tracker they want a feature, doesn't make it any less so.
<LaserJock> like generally you wouldn't do wishlist bugs
 * ogra remembers his first post FF gcompris upload ... i updated to a new upstream with a 37MB patch to aviod the paperwork ... we had no release manager back then
<ogra> so watch out for such people :)
<phil_ps> nhandler: launchpad is back up. I am trying to file the bug
<phil_ps> nhandler: it asks if the existing bug is the one I want to file...
<phil_ps> nhandler: not sure what to do
<LaserJock> ogra: tsk tsk
<LaserJock> that reminds me, I should go look at gcompris
<ogra> LaserJock, yeah, that was hoary ... i as still learning my way around
<ogra> or breezy
<ogra> cant remember
<ogra> today a RM would block it
<slangasek> superm1: were you wanting a mythbuntu alpha5 reroll for bug #334547?
<ubottu> Launchpad bug 334547 in mythtv "proper configuration of mythtv-database should *remove* mythtv-reconfigure-required popup" [Undecided,Fix released] https://launchpad.net/bugs/334547
<nhandler> scottk: I just think the line between new feature and bug fix is a little fuzzy and should be explained better on the wiki
<ScottK> nhandler: OK.  Propose some text then.
<nhandler> scottk: I will. I'm just trying to get a better idea for what you and the other -release members consider bug fixes
<ScottK> OK.
<slangasek> superm1: btw, is someone taking care of updating firmware-addon-dell to smbios-utils?
<slangasek> superm1: seems to currently use getSystemId and dellBiosUpdate, both of which are provided as compat symlinks
<superm1> slangasek, i was just talking to mebrown about that today.  will address it after alpha
<slangasek> ok
<calc> what format and where is the help that yelp shows?
<superm1> slangasek, yeah we'll need a reroll for bug 334547
<ubottu> Launchpad bug 334547 in mythtv "proper configuration of mythtv-database should *remove* mythtv-reconfigure-required popup" [Undecided,Fix released] https://launchpad.net/bugs/334547
<superm1> as long as *ubuntu4 has published by now
<slangasek> calc: xml, /usr/share/gnome/help/foo?
<calc> i have a bug report that complains that the OOo dev documentation doesn't show up in yelp, and i think it shouldn't but i don't know exactly how yelp works
<calc> slangasek: ok
<slangasek> calc: well, that's where the documentation is that's /displayed/; I don't know about how it's /registered/ with yelp
<slangasek> superm1: ok, scheduled to trigger on the buildd as soon as mythtv -0ubuntu4 is published on amd64
<LaserJock> calc: generally you'll want an .omf file and use scrollkeeper/rarian to register it
<superm1> slangasek, great thanks
<LaserJock> calc: the .omf files are placed in /usr/share/omf/<foo>
<LaserJock> calc: is that documentation you would get at via the OO.o help menu or from yelp itself?
<calc> LaserJock: neither he wanted documentation for developer stuff in ooo-dev-doc to be in yelp
<LaserJock> calc: that's sort of tricky
<LaserJock> you can get it into yelp's database but it's not exactly easy to get at from yelp
<LaserJock> the menu you see when you open up yelp is hard-coded
<LaserJock> unless it's a man/info page you gotta do a search for it, and yelp's search function is ... special
<calc> LaserJock: ok i just closed it invalid after explaining that the OOo dev docs are not Gnome dev docs and are not formatted in the special manner that it requires
<LaserJock> calc: are those docs available online somewhere?
<calc> LaserJock: not certain, its in openoffice.org-dev-doc though
<ScottK> If there's an archive admin with a free moment, I'd appreciate it if you'd toss http://paste.ubuntu.com:80/123115/ at syncbugbot for some backports (target is all intredpid, source is all jaunty).
<LaserJock> heh, I get a kick out of the happycoders-emacs long description "This is a daily cvs snapshot". The Intrepid version is 2004.08.14
<stgraber> :)
<ScottK> Didn't say which day.
<lws> Is this the channel for Jaunty questions?
<stgraber> nope, that'd be #ubuntu+1
<lws> oops
<slangasek> superm1: new mythbuntu posted
<superm1> slangasek,  bug 334341 is affecting several types of builds.  ive seen it on xubuntu and mythbuntu, looks like there are reports on normal ubuntu as well. affecting situations that you have existing partitions that get deleted i think.
<ubottu> Launchpad bug 334341 in ubiquity "Ubiquity: device or resource busy error message" [High,Confirmed] https://launchpad.net/bugs/334341
<slangasek> superm1: yes, that looks like errata material to me
<superm1> slangasek, alrighty
<dholbach> good morning
<ebroder> Any backporters around who could look at bug #334538?
<ubottu> Launchpad bug 334538 in intrepid-backports "Please backport gitosis 0.2+20080825-2 from Jaunty to Hardy/Intrepid" [Undecided,New] https://launchpad.net/bugs/334538
<ebroder> I'm mostly wondering if there's anything else I should do to the patch
<pitti> Good morning
<StevenK> Morning pitti
 * pitti hugs StevenK
 * StevenK finally finishes processing removals
<StevenK> bryce: Argh! I processed syncs like an hour ago!
<pitti> StevenK: not for main, I hope? :-)
<bryce> StevenK: no hurry
<StevenK> Uhhhh
<StevenK> I *think* they were all universe
<bryce> these syncs are all for main - they're the silly little video drivers no one uses
<StevenK> I saw, I just removed the silly little input drivers no one uses
<tjaalton> StevenK: excellent, thanks :)
<savvas> Riddell: I've just tested the patch for bug 190907 on kubuntu jaunty and it works as expected for Greek :)
<ubottu> Launchpad bug 190907 in gdebi "[kde] Applications cannot read Greek folder names" [Undecided,In progress] https://launchpad.net/bugs/190907
<bryce> tjaalton: sync req's filed - https://wiki.ubuntu.com/X/PackageNotes
<tjaalton> bryce: cool
<bryce> http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html updated
<nikolam> Hi, can I use fridge calendar when calendar has moved to google calneda? Can I import ical calendar like before?
<dholbach> nikolam: https://wiki.ubuntu.com/Fridge/Calendar
<dholbach> there's even an ICAL link at the bottom of http://fridge.ubuntu.com/calendar
<nikolam> dholbach, that is ical link?
<dholbach> no
<nikolam> liek I can import it inside Sunbird like before?
<dholbach> it's linked from there
<dholbach> linked from both pages
<nikolam> So we don`t have ability to add ical link to applications, like sunbird etc, we need to go to google to see meetings?
<dholbach> ?
<dholbach> no... search for ical on the two links I gave you
<nikolam> Ah http://www.google.com/calendar/ical/j5q85mmi6ujvjtii5s1n3li5io%40group.calendar.google.com/public/basic.ics
<nikolam> I found it.
<nikolam> It is working now :)
<juanje> hi guys, may I make you a packaging question?
<juanje> it's about the packages version
<dholbach> sure
<RAOF> juanje: #ubuntu-motu is likely to be a better place, but you can probably ask here.
<juanje> if we (in guadalinex) make a version of one package from Ubuntu, how should be the version?
<juanje> dholbach: thanks
<dholbach> juanje: you could do it like we do... just add "guada1" :-)
<juanje> that's waht we usually do, but seems too long
<juanje> so something like 0.2-4ubuntu2guada1 could be ok?
<dholbach> it's your distro, you can sure do it :-)
<juanje> it's just to be sure, the upgrade of the version from the upstream (you) make sense
<dholbach> if you decide to import 0.2-4ubuntu3 in the next release (and drop your changes because they're in Ubuntu or don't make sense anymore) the upgrade will just work
<juanje> ok, we were doing like that but it's the kind of things we were not sure if was the better way
<juanje> dholbach:  perfect
<juanje> dholbach: thanks ;-)
<dholbach> sure :)
<juanje> RAOF: sorry for asking those things here, it was just because it is more derivative policy than packaging itself. But I'll join at #ubuntu-motu channel in case we have more technical questions :-)
<RAOF> juanje: #ubuntu-motu is generally a better place for simple-ish packaging information; this is generally better for highly complex packaging, policy interactions, and such.  That said, now that I've seen the whole question, it's entirely appropriate here :)
<juanje> RAOF: :-)
<pitti> StevenK: just to make sure, did you also add arts to the sync blacklist?
<StevenK> pitti: Indeed
<StevenK> pitti: Along with everything else that I thought Debian wouldn't remove
<pitti> StevenK: splendid, thanks
 * dholbach hugs juanje and rcmorano
 * dholbach hugs RAOF too
<dholbach> hey seb128!
 * dholbach hugs seb128 too
<seb128> hello dholbach
 * seb128 hugs dholbach
 * RAOF hugs dholbach 
 * juanje hugs dholbach
<dholbach> :-D
<juanje> hahaha.... how much love in this channel :-P
<juanje> I like it
<juanje> :-)
<asac> pitti: so as expected a single proper shutdown should fix your "addons installed" issue
<asac> i managed to reproduce after langpack update by using killall firefox-3.2 to shutdown
<pitti> asac: yes, I expect that, too; I just wondered if I should keep it that way for debugging, or this is basically a "wontfix" issue
<asac> pitti: not sure. looking at code it seems they disabled it on startup to avoid excessive IO
<pitti> asac: ah, you mean the extension files are updated on shutdown?
<asac> personally i would think that it should be disabled until all extensions are properly setup/registered
<asac> pitti: yes. the extensions manifest is the problem here (extensions.cache) ... it has a mTime field for each addon
<asac> that is flushed on shutdown only atm ... but i think thats a bug
<asac> but its a bit hard to determine, when all extensions are properly updated during startup
<pitti> asac: okay; sounds a bit like "wontfix" then
<asac> i will look a bit more and bug upstream about it. seems that the code to flush on startup is actually there, but not reached. strange
<cjwatson> ScottK: backports done; I assumed that you meant kde4-style-bespin rather than plasma-widget-xbar, since the former is the source package name
<pitti> $ git reset  fdi/information/10freedesktop/10-modem.fdi
<pitti> fdi/information/10freedesktop/10-modem.fdi: locally modified
<pitti> argh, yes, that's exactly what I want to reset, you *censored*
<ion_> IIRC, git checkout -- fdi/information/10freedesktop/10-modem.fdi
<pitti> "git reset --hard" seems to have worked
<pitti> but last time I did that, I couldn't push any more
<pitti> well, let's see :)
<cjwatson> yes, stupid program. you have to use one command to revert all changes in your tree and a different one to revert individual files.
<pitti> ion_: thanks, will do that next time
<pitti> I think next time I'll just do git diff | patch -Rp1 or so..
<cjwatson> git checkout is the right thing to use here but is not exactly obvious
<pitti> cjwatson: well, I first tried git revert, but its help says "If you want to throw away all uncommitted changes in your working directory, you should
<pitti>        see git-reset(1)"
<pitti> ah, "particularly the --hard option."
<bryce> glad I'm not the only one that finds resetting git trees a bit confusing
<cjwatson> kirkland: I would really appreciate a look at bug 327348 at some point; I keep wasting time due to it
<ubottu> Launchpad bug 327348 in kvm "keep losing ability to type in guest" [Undecided,New] https://launchpad.net/bugs/327348
<apw> bryce, pitti, its just a perception thing
<apw> resetting a tree to a particular point in history makes perfect sense
<apw> if you perceive each point to be a snapshot of the world in time
<apw> i want to reset the world to as it was 'then'
<pitti> I just wanted to say "discard my uncommitted modifications"
<pitti> I think "git reset --hard" does that
<cjwatson> it's not just a perception thing; it's a bad UI design
<apw> so you wanted to reset to the HEAD of the tree
<apw> cjwatson, i don't think that is fair at all
<apw> how do you do it in bzr
<cjwatson> I do; I see people running into this frequently
<cjwatson> 'bzr revert <file>'
<apw> git checkout <file>
<cjwatson> "I want to revert my changes. I know, I'll use bzr revert"
<apw> would be the equivalent there
<cjwatson> git revert even acknowledges that people might look there for this feature
<cjwatson> in its manual pages
<apw> i want the version of this file in head, i know i'll ccheck that one out
<apw> its a perception thing in a lot of ways
<cjwatson> actually it's git checkout -- <file>
<cjwatson> AFAICT?
<apw> well the -- thing is not necessary
<cjwatson> I have seen git checkout fail when the -- is omitted
<apw> unless the filename might clash with a vranch name
<apw> branch name
<cjwatson> this is a classic case of "user must adapt to fit tool"
<cjwatson> I think it's entirely fair to criticise that
<apw> its a classic case of if you are in the bzr mind set then the commands are not intuitive
<cjwatson> it's not just bzr
<apw> i find bzr revert reverting just one file just mad
<apw> but that is cause i am in the git mind set
<cjwatson> most other revision control systems have similar semantics
<cjwatson> apw: huh?
<cjwatson> apw: 'bzr revert <file>' -> revert one file. 'bzr revert' -> revert whole trtee.
<cjwatson> tree.
<apw> what does bz revert -r -4 do ?
<cjwatson> revert whole tree to four revisions from end of branch
<apw> right where as it _should_ (in my head) undo just -4
<cjwatson> (working tree, not equivalent of the index)
<apw> the only point i am making is the interfaces are different
<apw> that doesn't make one or the other any righter
<cjwatson> the point I am making is that it makes sense to optimise for common operations
<apw> just the one you learn first is less wrong
<apw> ok and which are the common ops that are not optimised ehre
<cjwatson> "oh, shit, that change was completely wrong, let me throw it away rather than commit it" is a common operation
<apw> git checkout -f
<apw> would be undo everything
<pitti> I'd also think that "commit all my changes" is more common than "commit nothing"...
<cjwatson> I give up :)
<bryce> I dunno, I learned git first and found it confusing before I ever heard of bzr.  I was skeptical of bzr, but now I know it... I still find git syntax confusing.
<cjwatson> git just fails to realise that brain-compatibility with other systems is important
<apw> bryce, but what did you use before
<apw> or was git really your first ?
<bryce> apw, rcs, cvs, clearcase, svn
 * pitti still painfully remembers arch
<apw> cjwatson, i personally seem to be able to use both now (git and bzr) and mostly get by
<apw> bryce, so you git wasn't your first
<apw> cvs really was
<bryce> yep
<cjwatson> just like thousands of other developers
<apw> so that confusion is to be expected, and bzr to be less confusing as its closer
<cjwatson> you can't just discount the "migrating from cvs" case
<apw> yep.  but we adapt, we learn
<bryce> apw, if you argue that git makes sense for people who have never used a vcs, I will laugh ;-)
<cjwatson> tools adapt to me
<apw> i am not trying to
<apw> i am trying to argue, that its a matter of subbing in the right commands for the concepts
<apw> like when you program in perl you use $()(%)(%()$ and in C you use something else
<apw> you have to tranlate from 'if constuct' to a command line
<apw> and you do thast for every tool you use
<cjwatson> you see, I don't want to learn a VCS
<cjwatson> I use a VCS to get my work done
<james_w> I think the confusing thing is that "reset" works for the whole tree case
<apw> i don't want to learn a proigramming language
<Mithrandir> cjwatson: the same argument can be made for editors and programming languages.
<cjwatson> therefore, in a VCS, working like other VCSes is a desirable attribute
<Mithrandir> you generally don't want to learn tools.
<cjwatson> Mithrandir: I don't agree for programming languages, because their expressiveness is much more important
<apw> git and bzr are almost indistiguisable at the semantic level
<cjwatson> Mithrandir: for editors I entirely agree which is why I learnt one ten years ago and never change
<apw> just the commands differ in construction
<apw> same as programming in two languages
<james_w> because it is "revert" in most other systems, that's where people go first, and it does something different, but tells them about reset, which does whole trees. Then you try and do a single file and get a really confusing error message.
<apw> find the commands that work and you are set
<james_w> if "revert" pointed to "checkout" then that may be improved
<apw> james_w, probabally it should point to checkout really
<cjwatson> programming in two languages is completely different; languages are well-known to have widely different expressive properties (at least if you're considering them at a level above Turing machines)
<apw> james_w, ack
<Mithrandir> cjwatson: I guess I'm weird in that I use different tools for different things, then. :-)  (I use both vi and emacs)
<james_w> and if the error messages where better then it would be easier to learn. Generally they give you no clue as to what you did wrong.
<apw> cjwatson, well on that i dissagree.  i use the same bit of my brain to convert between git and bzr
<apw> james_w, yeah can't argue that some of the errors are unhelpful
<cjwatson> apw: look, I'm not trying to argue that any one system is perfect; you can look at my list of bugs filed on bzr if you like ...
<apw> anyhow, don't get the impression i think git is any better or worse
<cjwatson> apw: but I'm getting really tired of people saying that git UI bugs aren't bugs
<apw> i am trying to argue they are the same, but suttly different
<cjwatson> in that respect I prefer the bzr attitude which is, IME, "oh, it didn't do what you expected. hmm. how can we improve that?"
<apw> well you are stating that any ui difference from a cvs is a bug
<cjwatson> no, absolutely not!
<cjwatson> where did I say that?
<cjwatson> I'm saying that some level of similarity is desirable
<apw> thats the same thing just more subtle :)
<cjwatson> I don't want to have to type bzr -nq up to find out what the changes in my tree are
<cjwatson> but I do want to not have to remember a completely different lexicon of verbs for absolutely everything
<cjwatson> I don't think that's unreasonable
<cjwatson> if git people actually acknowledged UI bugs I would be a lot happier with it
<cjwatson> but everyone gets all defensive
<apw> the problem is that most of the issues come from the commands in both being the same name
<RAOF> "Where there's no compelling reason to be different, being different from is a bug" would be a reasonable rephrasing of this sentiment, I think.  Is that clearer?
<cjwatson> RAOF: yes
<apw> its not possible to 'fix' that without being incompatible with older releases
<apw> and that is the compelling reason at this stage, revert is different and making it the same would break the userbase
<cjwatson> apw: actually, fixing the error messages would help too
<apw> that is why they get defensive
<james_w> apw: I think that being more forgiving when these common issues are hit would go a long way to alleviating the problem, and wouldn't break compatibility
<cjwatson> in this particular case, if you use the wrong one, the error messages are incomprehensible
<apw> and as far as can see thing do improve with every release
<apw> cirtainly i get more human readble stuff with every version
<cjwatson> apw: so you mentioned that git checkout does different things depending on whether you give it something that looks like a branch or something that looks like a file
<cjwatson> apw: why can't git revert do that?
<james_w> it is improving, but the developers are unwilling to fix some things
<apw> if you want to point out the ones you hate and find hard to grok to me message wise
<apw> then i'll try and get them fixed
<cjwatson> its argument is a commit id
<cjwatson> it could easily say "oh, that's a filename, you meant git checkout -- <file>, I'll do that"
<apw> cjwatson, i suspect it could, and that might well be a reasonable thing
<apw> though
<apw> as revert here means "undo what was done in commit N"
<apw> then git revert HEAD -- debian/changelog
<cjwatson> "git revert <filename>" is not ambiguous
<apw> _should_ mean undo the changes to devian/changelog in head
<apw> which is not the same as make the working tree match HEAD
<apw> ie not what it means in bzr
<cjwatson> I'm not after an identical interface
<apw> right, but to add the semantic you want would be to add
<cjwatson> I want an interface that DTRT when it is unambiguous and gives me helpful output when it isn't
<apw> a semantic that makes no sence in the meaning of the command
<apw> that is a little unepexected
<cjwatson> (by and large I already have such an interface so I am undermotivated to fix git, but ...)
<apw> and would prevent that command ever undoing part of an old commit
 * apw goes paint his bikeshed a different colour
<cjwatson> "git revert HEAD -- debian/changelog" != "git revert debian/changelog"?
<cjwatson> surely
<cjwatson> if you've explicitly specified a commit id there then you're clearly in a different mindset
<apw> most commands work on HEAD if nothing is specified
<cjwatson> TBH I suspect the only way to get to B from A is to have a completely different command-line frontend
<apw> so it would mean the same
<cjwatson> which seems a bit of a waste of effort
<cjwatson> cogito died
<apw> yeah it did
<apw> i am lucky i just learn the mappiing and carry on
<cjwatson> apw: BTW, the reason I'm not diligently filing bugs about everything I find unintuitive is that Linus has explicitly said that he deliberately made it different to break hardcoded expectations
<broonie> You do need a different front end - see the git archives, this has been discussed ad infinitum.
<cjwatson> apw: which basically says "sod off, not interested in your bugs"
<apw> cjwatson, it is entirly true that git being linus' baby is not good for git nor its users
<apw> tooo big a personality
<broonie> cjwatson: That's not so much the case any more - apart from anything else Linus isn't the maintainer any more.
<apw> yeah junio is better for sure
<apw> anyhow ... sorry to waste so much time on that bikeshed.  they differ, sorry
<broonie> Most of the stuff that doesn't get changed is difficult to change.
<apw> we should get some more help in the mans for sure
<cjwatson> broonie: sure, but now it's all deeply hardcoded and as apw says a pain to change for compatibility reasons
<cjwatson> so I might as well just use a system I like instead
<cjwatson> but I hate sitting still for bugs
<broonie> The stuff that "is difficult to change", yes. Though much of the stuff that people don't like is in error handling so there's plent of room for doing better.
<maco> between apw and Keybuk, i'm getting really excited about the fact that my new job requires using git!
<apw> heheh you'll either love or hate it
<broonie> It's gorgeous for working on the kernel (or other projects that use it well).
<maco> i dont even want to find out how long bzr would take to do a merge on the kernel source
<Keybuk> maco: that's one of those "heat death of the universe" type events
<maco> hmm?
<Ng> maco: "longer than the rest of time"
<maco> ah
<maco> gotcha
<BUGabundo> pitti: ping
 * Ng shrugs, bzr not being suited to heavy kernel work is largely irrelevant if you start with the basic premise that git and bzr and others are not equivalent, and that one size demonstrably can't fit all :)
<pitti> !ping | BUGabundo
<ubottu> BUGabundo: ping yourself ;-) really the diodes all down my left side are sore
<pitti> meh, can someone please fix ubottu to say something sane about contentless pings?
<pitti> BUGabundo: hi
<BUGabundo> pitti: is this known '? http://paste.ubuntu.com/123251/
<BUGabundo> looking at LP, I see too many, not sure it's a dupe
<maco> Ng: they're just not making learning to use it sound very pleasant. my grand total experience with it included dtchen sitting next to me telling me which commands let me generate a changeset
<BUGabundo> maco: ahh?
<maco> BUGabundo: git
<Ng> maco: I've uesd git about twice ever. I'm not a hardcore developer, it just doesn't make sense for me to use it, and none of the projects I interact with use it, so *shrug*
<maco> BUGabundo: im sure you've seen Keybuk's git rants, and apw just had one of his own
<pitti> BUGabundo: no, please file a bug against apport and assign it to me
<BUGabundo> doing so now
<apw> maco, i wasn't ranting.  i was just trying to say they are differnt stop comparing them
<apw> i am not trying to change either, i just use them both and accept their esentricities
<BUGabundo> pitti: bug 334823
<ubottu> Launchpad bug 334823 in apport "File "/usr/bin/apport-collect", line 125, in <module>" [Undecided,New] https://launchpad.net/bugs/334823
<BUGabundo> assigned
<BUGabundo> bye
<Keybuk> apw: I use them most and hate their eccentricities ;)
<Keybuk> use them both, I mean
<apw> tollerance comes with age :)
<StevenK> Oooh, apw had a git rant?
<StevenK> Sorry I missed it ....
<apw> heh, na, maybe
<apw> Keybuk, is there a bzr equivalent of gitk ??
<cjwatson> yes, 'bzr vis' in the bzr-gtk package
<apw> cool
<cjwatson> though bug 283832 is a tad annoying after installing bzr-gtk
<ubottu> Launchpad bug 283832 in bzr-gtk "bzr notification icon should not be permanent" [Undecided,New] https://launchpad.net/bugs/283832
<james_w> apw: qbzr's qlog is apparently superior to "bzr vis"
<james_w> but bzr gannotate is miles better than anything I have seen
<apw> nng
<james_w> the "back" button is genius
<StevenK> cjwatson: Oh, that reminds me. You told me at the sprint that you've bent vi to your will in terms of coding Python. Do you have a sec to dig through your config for the magic?
<apw> cjwatson, oooo is that modes to do the spacing right?  please, pretty please?
<cjwatson> I think it's just:
<cjwatson> augroup myauto
<cjwatson>     au FileType python  setlocal tabstop=8 softtabstop=4 shiftwidth=4 expandtab
<cjwatson> augroup END
<StevenK> apw: I think you used up all of your brownie points with the git discussion :-P
<cjwatson> though I also set these globally, which might be relevant: set autoindent; let python_highlight_all = 1; filetype indent on; filetype plugin on; syntax on
<Ng> bah, bzr vis just seems to explode for me
<apw> StevenK, quite probabally
 * Ng blames PPA versions of bzr
<pitti> apw: I also find this very helpful:
<pitti> autocmd FileType python :set smartindent cinwords=if,elif,else,for,while,try,except,finally,def,class
<StevenK> Ng: I find blaming lifeless to be very helpful, since then he turns up and argues.
<pitti> apw: then you type something like "def foo:", press enter, and automatically get indentation
<Ng> StevenK: haha
<cjwatson> StevenK: http://www.chiark.greenend.org.uk/~cjwatson/tmp/vimrc is my whole .vimrc in case that's useful
<apw> pitti, yeah not so keen on things doing that for me, but the spacing thing being sane :)
<StevenK> Ah, excellent.
<cjwatson> there is a little bit of ancient cruft there ;)
<apw> thanks cjwatson that seems to be the incantation
 * StevenK tries to stop his eyes bleeding, since .vimrc syntax hurts
<cjwatson> yeah, it's painful
<cjwatson> I'm by no means a master
<pitti> while we are on the subject of tweaking vim, does anyone know how to stop vim from putting "*" in front of lines automatically? this drives me mad in multi-line debian/changelog entries
 * pitti 's .vimrc is 317 lines...
 * evand equally on gq
<apw> pitti, whats the symptom, add a * foo and when it wraps it add * again?
<StevenK> pitti: Heh, mine is 10
<cjwatson> pitti: that'll be something to do with 'comments' I'd have thought
<apw> i don't get that by default
<pitti> apw: right
<pitti> it tries to DTRT for C comments
<apw> i don't think i get that
<pitti> /* foo
<pitti>  *... continue
<cjwatson> you could 'au FileType debchangelog setlocal comments='
<cjwatson> although that probably isn't quite what you want
<pitti> I have
<pitti> autocmd FileType debchangelog :set nofoldenable
<pitti> right, I'll try that
<cjwatson> how about 'au FileType debchangelog setlocal comments=bf:*'
 * apw hands cjwatson a black-belt in vim foo
<cjwatson> BTW I don't see this and don't customise debchangelog at all; maybe you have some global configuration here?
<pitti> cjwatson: may thanks, that's it
<StevenK> apw: I think Colin made his own ... using vi
<cjwatson> comments=bf:<leader> is in my muscle memory because it's how you get bullet-point lists to work sanely
<pitti> cjwatson: I don't think I ever touched it (http://people.ubuntu.com/~pitti/scripts/vimrc)
 * apw adds that to his catalogue of vi magic
<pitti> maybe it's smartindent
<cjwatson> pitti: ah, I think 'filetype plugin on' arranges for debchangelog to fix this itself
<StevenK> OW, pitti has *fuctions* in his .vimrc
<cjwatson> have a look in /usr/share/vim/vimcurrent/ftplugin/
<pitti> yeah, most of it is LaTeX stuff
<cjwatson> using ftplugin saves a lot of reinvention IME
<pitti> cjwatson: right, debchangelog.vim has setlocal comments=f:* there
<pitti> at some point I need to clean up my .vimrc cruft, indeed
<s0u][ight> weird
<s0u][ight> cjwatson, what were the 2 apps you recommended me to build live cd's? livecd-rootfs and...
<cjwatson> I explicitly didn't recommend them to you :-)
<cjwatson> I said that they were what we used; they're designed for automation rather than for people to use to build their own
 * directhex explicitly recommends not eating yellow snow
<cjwatson> s0u][ight: which updated images was it you were looking for?
<s0u][ight> cjwatson, i wasn't looking for some updated iso, i was recommending you guys to build frequently new ones
<s0u][ight> because after some time you get amazing downloads like 200 MB right after installation
<cjwatson> s0u][ight: which release?
<cjwatson> I am happy to do occasional one-offs
<directhex> any release where an OOo update exists, at a guess
<s0u][ight> yes
<cjwatson> we don't have disk space on the machines in question to do it all the time
<cjwatson> and it would tend to interfere with other things - but I can do it occasionally when nothing else is going on
<cjwatson> I've kicked off hardy and intrepid live CD builds now
<s0u][ight> cjwatson, it is not a personal request, just something that would be another + for ubuntu
<s0u][ight> btw cjwatson i'm curious about the way ubuntu live cd's are made (from scratch)
<cjwatson> s0u][ight: that turns into a personal request in the end *shrug*
<s0u][ight> cjwatson, last time i installed a new distribution from a live cd was like ... a year ago or something :D
<s0u][ight> but i'm helping people around in #ubuntu-tr and often people go like, just installed ubuntu and already this much of updates
<cjwatson> s0u][ight: so, first, remember that we build images for several different architectures, so it clearly can't all be done on one machine; that's why we split the automation into two pieces
<cjwatson> s0u][ight: livecd-rootfs builds the appropriate live filesystem for a single architecture, and http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ (and the other bits listed in configs/devel in there) deals with building the ISO out of that
<cjwatson> s0u][ight: it's not delivered in a nicely packaged form AT ALL, and most people don't need this extra sophistication; they just want a quick build for their current architecture
<cjwatson> so generally speaking I discourage people from using it because I don't particularly want to end up putting in the effort to turn it into a nicely-packaged thing
<cjwatson> the customisation workflow is much easier for most people
<s0u][ight> i still have to learn so much more ...
<cjwatson> but it isn't appropriate for running daily builds every day for years; and once you have the infrastructure set up to do *that* then you might as well use it ...
<s0u][ight> daily would be too often but like with each about 100 MB of updates
<cjwatson> stop focusing on the "daily" bit
<cjwatson> pretend I said "regular" if you like
<s0u][ight> let them just get the updates themselves :D
<cjwatson> they're going to have to update eventually anyway. most people are not going to want to reinstall their system every couple of months from a CD, and it would be less efficient to do so anyway
<cjwatson> our package archive infrastructure is much more efficient and distributed than our CD image infrastructure, and we'd rather people used the former in general
<s0u][ight> ok :-)
<cjwatson> having CD images every six months at release means that those can be burned to physical media, sent out to people, etc., which is much better than them thinking that they have to download 700MB in order to do an installation
<cjwatson> it's important to think beyond the initial update, I think
<s0u][ight> cjwatson, i get the point :)
<s0u][ight> thanks for all the effort to convince me :D
<cjwatson> new images will show up in a bit at http://cdimage.ubuntu.com/hardy/daily-live/ and http://cdimage.ubuntu.com/intrepid/daily-live/ ... that is, if they don't fail
<s0u][ight> cjwatson, i would like to convince you using firefox with wine, runs much smoother :D
<s0u][ight> i'm off now laters
<cjwatson> *blink* how about "no"
<directhex> metacity and nautilus suck, can we use explorer in wine while we're at it?
<mdz> Keybuk: are you still having some mysterious I/O related issue on Jaunty, and if so, what's the bug number?
<mdz> (you mentioned some I/O performance issue at the sprint IIRC)
<lamont> pitti: 334410 sure doesn't look like a postfix bug to me...
<kirkland> cjwatson: looking at bug #327348
<ubottu> Launchpad bug 327348 in kvm "keep losing ability to type in guest" [Undecided,New] https://launchpad.net/bugs/327348
<kirkland> cjwatson: are you seeing this in kvm-84 as well?
<kirkland> cjwatson: there's some changes in 1:84+dfsg-0ubuntu3 that could affect this
<IntuitiveNipple> kirkland: Is there a reason VDE isn't enabled in kvm?
<smb_tp> bug 318978
<ubottu> Launchpad bug 318978 in dell "Hard drive in Studio XPS 13 and 16 cause a 17-18s resume time" [High,Fix released] https://launchpad.net/bugs/318978
<kirkland> IntuitiveNipple: good question ...  i don't know why that's no longer enabled
<kirkland> IntuitiveNipple: i'll check upstream
<smb_tp> -WRONGCHAN
<IntuitiveNipple> It is auto... but we don't build-depends on it
<kirkland> IntuitiveNipple: i still an an email in my inbox from you, i'm sorry, i've been swamped
<mvo> doko: is "XS-Python-Version: current" still ok to use?
<IntuitiveNipple> kirkland: That's the one :) bug # 253230
<kirkland> IntuitiveNipple: aha :-)
<IntuitiveNipple> bug #253230
<ubottu> Launchpad bug 253230 in kvm "Should it Build-Depends on libvdeplug2-dev?" [Undecided,Confirmed] https://launchpad.net/bugs/253230
<IntuitiveNipple> (helps to avoid spaces :)
<kirkland> IntuitiveNipple: okay, let me dive into it right now
<cjwatson> kirkland: I encountered it today with kvm 1:84+dfsg-0ubuntu3
<kirkland> cjwatson: :-/  okay, how are you launching the vm?
<doko> mvo: what for?
<cjwatson> kirkland: just kvm from the command line, only options are -m -hda -cdrom
<kirkland> cjwatson: okay, and just to be clear, it won't accept keyboard input?
<kirkland> cjwatson: because that's how i run, and the screen will go all goofy sometimes (that i'm still working on)
<cjwatson> kirkland: it accepts it, but it's as if a modifier key is stuck
<mvo> doko: update-manager, I'm merging your ppa changes into the bzr tree
<cjwatson> kirkland: either ctrl or alt
<cjwatson> kirkland: so I can change ttys, but not actually type into them, and I occasionally see indications that it's seeing metacharacters rather than the characters I meant to type
<kirkland> cjwatson: this only happens when running the installer?
<Keybuk> cjwatson: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=3d3a0a709a38805259fe07240c3ca47a120dd5d6
<cjwatson> it could be something to do with the order I press and/or release ctrl and alt when getting kvm to release focus?
<cjwatson> kirkland: IME yes, but that means very little since I almost exclusively use kvm for installer testing ...
<doko> mvo: IMO you should set it to all, then the symlinks are created for both 2.5 and 2.6. for private modules, current/all doesn't make a difference
<cjwatson> Keybuk: thanks!
<kirkland> cjwatson: okay, i'm pulling today's iso and i'll try to test
<Keybuk> mdz: http://bugzilla.kernel.org/show_bug.cgi?id=12309
<cjwatson> kirkland: I don't *think* that the guest is doing anything particularly special here; it's not changing the keyboard layout at the relevant time or anything
<ubottu> bugzilla.kernel.org bug 12309 in Block Layer "Large I/O operations result in slow performance and high iowait times" [High,New]
<kirkland> IntuitiveNipple: okay, i think that build depends is correct, i'm building/testing now
<IntuitiveNipple> kirkland: Yeah, it builds fine (for me) in pbuilders. I've been adding it manually up to now
<AnAnt> quadrispro: Hello, I wanted to ask you about gpm
<AnAnt> quadrispro: regarding "Add -D_GNU_SOURCE to CFLAGS, fixes FTBFS." in gpm, I am compiling gpm 1.20.6 without -D_GNU_SOURCE in intrepid & jaunty, and it does work
<pitti_live> bryce: FYI, just trying current amd64 desktop on my wife's computer (rv630); as expected, I don't get DRI and composite; video playback fullscreen (1920x1600) is not really usable (way too slow)
<pitti_live> bryce: is xv related to DRI nowadays? do you know whether the next ati driver will support better xv?
<seb128> I can't play videos on my ati r6xx desktop either
<seb128> I can't play videos on my ati r6xx desktop either, way too slow
<seb128> pitti_live: btw bug #326029 is your camera issue
<ubottu> Launchpad bug 326029 in gvfs "gvfs-gphoto2 mount 4 devices when plugin one camera" [Low,Triaged] https://launchpad.net/bugs/326029
<kirkland> IntuitiveNipple: good fix ;-)
<pitti_live> seb128: ah, I wanted to ask you about the "master" bug for that issue a few hours ago (but you were offline)
<kirkland> IntuitiveNipple: i'll upload as soon as the alpha freeze is over
<pitti_live> seb128: I reassigned a gnome-moutn bug to gvfs, will dup that then
 * pitti_live goes back to his workstation
<IntuitiveNipple> kirkland: many thanks... that'll make some people happy... I've just moved away from VDE to using tap and routing
<seb128> pitti_live: the gnome session bug you have with theming is gnome bug #567958 which is a 2.26 blocker
<ubottu> Gnome bug 567958 in general "Shutdown and Logout dialogs not themed" [Blocker,New] http://bugzilla.gnome.org/show_bug.cgi?id=567958
<kirkland> IntuitiveNipple: yeah, i try to use as many different networking options as possible for testing
<kirkland> IntuitiveNipple: and i noticed vde broke at some point, but hadn't had time to circle back
<kirkland> IntuitiveNipple: if you have any other golden kvm fixes, i'm all ears :-)
<IntuitiveNipple> kirkland: yeah, I know how it is.
<pitti> seb128: thanks
<seb128> pitti: you're welcome
<IntuitiveNipple> kirkland: Not right now, it's behaving really well.
<IntuitiveNipple> kirkland: But I hack on it occassionally so I'll be sure and let you know :)
<kirkland> IntuitiveNipple: please do.  sorry for the initial delay in response
<pitti> seb128: so should bug 274889 be linked to that gnome bug?
<ubottu> Launchpad bug 274889 in gnome-session "the new session dialog should use other icon names" [Low,Incomplete] https://launchpad.net/bugs/274889
<IntuitiveNipple> kirkland: that's okay
<seb128> pitti: no, that's different issues, yours is about the icons being used which was already a bug in intrepid
<seb128> pitti: the jaunty issue is just that xsettings are not applied, ie no theming
<seb128> pitti: yours will make it buggy when using other icon themes, the jaunty issue once fixed will make it correct with the default theme
<pitti> seb128: okay, understood; so we need to fix bug 277309 (which is the master for 274889 AFAICS) ourselves?
<ubottu> Launchpad bug 277309 in gnome-session "[Jaunty] Missing suspend icon" [Low,Confirmed] https://launchpad.net/bugs/277309
<seb128> pitti: right since that's distro change
<seb128> pitti: the dialog is not the upstream one but the opensuse one
<pitti> seb128: is that on your radar, or shall I find someone else?
<pitti> bryce: for bug 304871, do you think it's possible to switch to XAA on a per-model/chip basis?
<ubottu> Launchpad bug 304871 in xserver-xorg-video-intel "[i845G] Fatal server error: Couldn't bind memory for BO front buffer (Jaunty)" [Unknown,Confirmed] https://launchpad.net/bugs/304871
<ccm> can somebody please have a look on https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/216292
<ubottu> Ubuntu bug 216292 in aptitude "aptitude does not honour --download-only" [Undecided,Confirmed]
<kirkland> cjwatson: has the keyboard drop issue happened for you in the graphical installer?
<ccm> the guy rants and confirms his own bug
<cjwatson> kirkland: I can't say for sure
<kirkland> cjwatson: okay, i'll test it both ways
<cjwatson> ccm: what's wrong with his report? It may not be how it works right now but it seems a completely reasonable request.
<cjwatson> ccm: he deserves an answer from a developer of the software; I recommend forwarding the bug rather than looking for reasons to close it
<cjwatson> ccm: I'm not at all surprised that the bug reporter is upset
<cjwatson> I have added a bug comment to that effect
<ccm> cjwatson: actually all command line options on aptitude are not for interactive mode
<cjwatson> ccm: ... and a further comment noting that the Debian developer, a.k.a. the upstream author, has accepted the bug
<cjwatson> ccm: when developers accept bugs, bug triagers should leave them alone
<cjwatson> ccm: they aren't right now, but the bug reporter is absolutely right that this is an error
<ccm> cjwatson: than i have a different definition of an error when this is documented and intended behaviour
<ccm> cjwatson: so you count user experience first?
<cjwatson> ccm: firstly, I count the upstream author having accepted the bug as evidence that people should stop looking for reasons to close it
<cjwatson> ccm: secondly, something being documented behaviour is *not* in general a reason to close it
<cjwatson> ccm: the bug is a request for the behaviour to be changed, and "it's documented that way" is a completely irrelevant objection
<ogra> cjwatson, the localechooser workaround isnt in the archive yet, right ?
<cjwatson> ogra: correct, due to milestone freeze
<ccm> cjwatson: okay
<ogra> right, davidm just asked me if we could get it in as a post A5 exception to publish a working A5 slug image
<ogra> since 30h installs are not really feasable
<cjwatson> ogra: there is no need for an exception; it's not a feature
<Keybuk> cjwatson: found a random console-setup bug ;)
<ogra> (that would mean a post freeze upload of d-i aith immediate ublishing of the resulting slug image i think
<Keybuk> debootstrap hangs on it when installing into a chroot ...
<ogra> )
<Keybuk> ... if you have scroll lock on for the actual physical console of that machine
<ogra> *with immediate publishing
<ccm> cjwatson: actually i did not get the accepted message fromthe debian right away - need to look there more carefully, thanks again
<ogra> cjwatson, point is that i need to find a way to get that fix into an A5 image for the slug ... i'm not really sure how we can do that
<ogra> without breaking the rules
<IntuitiveNipple> Is this a version comparison problem? "xserver-xorg-input-elographics: Depends: xserver-xorg-core (>= 2:1.4.99.905) but it is not going to be installed"
<IntuitiveNipple> xserver-xorg-core: Installed: 2:1.5.99.902-0ubuntu7
<cjwatson> Keybuk: blink. interesting
<cjwatson> ogra: how about we just build a modified image and stick it on people.ubuntu.com?
<Keybuk> cjwatson: the postinst tries to call setupcon
<Keybuk> which echos > /dev/console
<ogra> davidm, ^^^^
<ogra> would that suffice ?
<Keybuk> which will block on scrolling
<cjwatson> IntuitiveNipple: might not be for quite the reason it says, try 'sudo apt-get install xserver-xorg-input-elographics xserver-xorg-core'
<IntuitiveNipple> cjwatson: thanks; will-do
<davidm> ogra, if there is an image and we point at it from the A5 page I'm happy
<ogra> hmm
<IntuitiveNipple> cjwatson: Interesting: "xserver-xorg-core: Conflicts: xserver-xorg-input-2.1"
<cjwatson> Keybuk: that's actually very odd, because setupcon isn't supposed to do that in the modes in which it's run by the postinst
<cjwatson> Keybuk: we run setupcon --save-only; setupcon --force -k
<ogra> i wonder if we can do that
<cjwatson> ogra: yes
<ogra> ok :)
 * ogra loves clear short staements :)
<ogra> *statements
<cjwatson> Keybuk: the echo to /dev/console is (effectively) if [ "$keyboard_only" != yes ] && [ "$save_only" != yes ], so one of those should fail for each of those two commands
<tjaalton> IntuitiveNipple: it probably isn't built (FTBFS) against the new xserver
<liw> when should the installer automatically create a separate /boot? can it detect if the bios is going to have problems with the kernel not being in the first 8 gigs?
<tjaalton> *ABI
<cjwatson> liw: I've never worked out how to detect that
<IntuitiveNipple> tjaalton: ahhh... I'll go look :) thanks.
<Keybuk> cjwatson: it was quite clearly hanging on an echo ;)
<cjwatson> liw: I've always been reluctant to do it all the time, because creating more partitions tends to cause further problems :-/
<IntuitiveNipple> tjaalton: Yeah.. FTBFS all the way :)
<liw> cjwatson, that's fair enough, I guess; stupid hardware with idiotic limitations...
<cjwatson> Keybuk: oh, I'm not saying you're wrong, I just can't see why off the top of my head ...
<bluesmoke_> wow, there is hardware that can only boot a kernel from the first 8GB on the drive?
<tjaalton> IntuitiveNipple: trivial to fix though
<IntuitiveNipple> tjaalton: I was just about to research it - newer upstream source package maybe?
<tjaalton> IntuitiveNipple: no, it's not fixed upstream yet
<IntuitiveNipple> tjaalton: OK, just patch ours for now, then?
<tjaalton> IntuitiveNipple: ye
<tjaalton> s
<cjwatson> bluesmoke_: there are lots of such limitations; see the Large-Disk-HOWTO
<tjaalton> IntuitiveNipple: actually, it _is_ fixed upstream
<IntuitiveNipple> tjaalton: yippee! saves me some brain-strain :)
<IntuitiveNipple> tjaalton: "xf86-input-elographics-1.2.3" branch?
<moquist> slangasek: 'apt-get install postgresql-server moodle' doesn't work. Installing postgresql-server completely and then installing moodle works. (same for mysql) I'm thinking that if I add a preinst to moodle to make sure that at least one of postgresql or mysql is ready to go, then I can display a debconf note and bail before most of a doomed moodle installation happens.
<tjaalton> IntuitiveNipple: tag, but yes
<IntuitiveNipple> I'll give it a try
<moquist> slangasek: But if mysql is ready to go and the user specifies postgresql, then this still needs to be caught in postinst. So I'd like to put these check_mysql() and check_pgsql() functions in a library that both preinst and postinst source.
<apw> cjwatson, the installer kernel, that kernel is built from the same source as the kernel on the image right?
<moquist> slangasek: do you have any objections or advice about my idea?
<cjwatson> apw: it is the same kernel, bit-for-bit
<apw> if there had been an abi buimp, could it have been missed?
<cjwatson> apw: the vmlinuz, anyway
<cjwatson> apw: which release?
<apw> hardy
 * pitti "meh"s at launchpad which broke p-lp-bugs again
<pitti> and thus apport retracers
<cjwatson> I only recently uploaded a d-i for 2.6.24-24 and I don't think that's been approved yet, but I'm not sure this is your problem ...
<cjwatson> apw: what's the symptom here?
<james_w> pitti: you assesed launchpadlib for that task I believe?
<pitti> james_w: thekorn even created a branch for that
<pitti> but it doesn't work on ronne, supposedly due to weird firewall configuration
 * pitti asks about that RT again
<apw> cjwatson, not 100% sure if there is an issue or not yet, a claim of missmatch but not sure ... the incoming information is currently not 100% clear yet
<thekorn> pitti, where is it broken, can you give me a traceback or something?
<cjwatson> apw: this sort of thing is sometimes due to people trying to use current images against outdated mirrors; I can probably help with more detail
<pitti> thekorn: http://paste.ubuntu.com/123389/
<thekorn> pitti, bug 327620
<ubottu> Launchpad bug 327620 in python-launchpad-bugs "fails to parse subscribers on edge" [High,In progress] https://launchpad.net/bugs/327620
<thekorn> don't ask me why I did not merge the fix into trunk
<pitti> thekorn: splendid, thanks
<LaserJock> slangasek: I see Edubuntu is rerolled, testing now
<Adri2000> Keybuk: seen my query? ;)
<NCommander> does anyone know where on cdimage lpia hardy images are?
<NCommander> (if they even exist)
<LaserJock> mvo: I've noticed that with the addon CD nautilus is started up as well as well as the little addon installer dialog box
<LaserJock> mvo: I don't think nautilus used to show up, do you know if there's a way around that?
<mvo> LaserJock: I don't know, I guess seb128 can help us with that
<LaserJock> mvo: and did you get a chance to get a float flag for g-a-i?
<mvo> LaserJock: I did some work on it, but its not finished :/ its relatively small, so it may land for user interface freeze (if I get it done and approval for it)
<calc> pitti: there will be more gvfs point releases before jaunty is released right?
<LaserJock> mvo: is there anything I can do to help that along?
<allquixotic> bryce: Are we planning to pull xserver-xorg-video-intel 2.6.2? It's http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=93ae6c7f8cadb60d479e626ddd2a67d7cb2cc4c0
<pitti> calc: yes, very likely
<pitti> calc: if not we can cherrypick that patch, but gvfs is in GNOME's release cycle, so it'll get point releases
<LaserJock> if a package has recommends but the recommends aren't in the archive does apt just ignore them and install anyway?
<doko> calc: when do you plan your next OOo upload?
<mvo> LaserJock: yes
<LaserJock> mvo: thanks
<LaserJock> I kept wondering why the Edubuntu CD was pulling in Universe and Main packages
<LaserJock> but when I turned everything but the CD off in sources.list it installed just fine too
<mvo> LaserJock: let me have a look at the floating patch thing again now
<LaserJock> mvo: that'd be wonderful, without it it kinda kills my spec :-)
<calc> doko: sometime after today :) why is there a specific thing you would like to see?
<LaserJock> no pressure though ;-)
<calc> doko: aiui we are in alpha 5 freeze still
<doko> calc: please do the next upload using python2.6 directly if we didn't do the change before your upload.
<doko> calc: or better: build python-uno for 2.5 and 2.6
<calc> doko: ok
<kirkland> Keybuk: around?
<Keybuk> yup, what's up?
<kirkland> Keybuk: http://people.ubuntu.com/~kirkland/Screenshot.png
<kirkland> Keybuk: booting degraded raid has regressed in jaunty
<kirkland> Keybuk: this is the first time i've tested it this cycle
<calc> doko: i have a few other changes queued up for the next upload as well, so i probably will do one sometime next week
<Keybuk> kirkland: it says your /dev/sda1 is already in /dev/md0
<kirkland> Keybuk: i'm wondering if there's something obvious you'd know about that'd cause this
<Keybuk> in fact, the very fact you're getting a kobject-related message from the kernel suggests there's an md bug here
<Keybuk> an in-kernel md bug
<kirkland> Keybuk: yuck, okay
<calc> doko: oh is python2.4 being dropped now that we have both 2.5/2.6 in main?
<kirkland> Keybuk: i'll file against the kernel
<doko> calc: does OOo still use 2.4?
<kirkland> Keybuk: the root/disk user/group message ... that's just a red herring?
<Keybuk> kirkland: there is no /etc/passwd or /etc/group in the initramfs
<Keybuk> so you can just ignore that
<Keybuk> it's the kobject message below that which is the issue
<calc> doko: no, just wondering since we have 3 pythons now :)
<kirkland> Keybuk: okay, i was just making sure that wasn't something that changed between intrepid/jaunty
<Keybuk> and it's simply a bug to even get anything like that
<Keybuk> kirkland: I don't think so
<Keybuk> unless mdadm changed ;)
<kirkland> Keybuk: okay, thanks for the analysis ;-)
<Keybuk> Adri2000: yes
<Adri2000> \o/
<Adri2000> and? :)
<Keybuk> and it's on my todo list
<Keybuk> probably today
<Adri2000> excellent, just ping me then
<Keybuk> in fact, let me go and get a cup of coffee and I'll do it now
<Keybuk> since you're here, and gcc is actually building this time ;)
<Adri2000> ok :)
<Keybuk> Adri2000: ok, I now have coffe
<Adri2000> :)
<Keybuk> the last revision I have from you is 135
<Keybuk> addcomment.py: explicitely import cgi.escape and mention the name of the p
<Keybuk> arameter quote when calling escape()
<Keybuk> is that the latest?
<Adri2000> yep
<Keybuk> ok, let me do the update on casey
 * RainCT hugs Keybuk :)
<Keybuk> Adri2000: ok, pushed
<Keybuk> how do we test this?
<RainCT> error :P
<Adri2000> indeed
<Keybuk> ?
<RainCT> Keybuk: http://merges.ubuntu.com/universe.html
<Adri2000> Keybuk: mv htaccess .htaccess?
<Keybuk> Adri2000: no htaccess permitted on casey
<Keybuk> ah
<slangasek> moquist: how would putting anything in the preinst help?  If it wasn't working in the postinst, wouldn't it be more of a problem in the preinst?
<Keybuk> try https://merges.ubuntu.com/universe.html
<Adri2000> hmm, htaccess is allowed on https but not http?
<moquist> slangasek: The idea was to catch the problem and bail earlier.
<slangasek> hmm
<Keybuk> no, the config change only got applied to https apparently
<moquist> slangasek: but I think multiple binary packages with pre-depends can simply solve the problem.
<slangasek> I don't think you should be using pre-depends
 * moquist was afraid of that :)
<Adri2000> Keybuk: what config change?
<Keybuk> Adri2000: adding mod_python
<Adri2000> mod_python is enabled on both http and https
<Adri2000> according to the ServerSignature
<Keybuk> Adri2000: the handler is only enabled on http
<moquist> slangasek: the problem is that even 'apt-get install mysql-server moodle' fails b/c mysql-server isn't completely installed before moodle's postinst runs. See things go bad on line 6 of http://rafb.net/p/kZmMbM22.html (pgsql & mysql have the same problem - the paste is pg)
<moquist> Based on my quick reading of what pre-depends do, it seems like what we need, but if there's a better way I'm all for it.
<slangasek> pre-depends would mean you *always* have to have the server installed locally
<RainCT> Keybuk: Uhm.. The .htaccess isn't in the LP branch?
<Keybuk> RainCT: I removed it
<moquist> ah, yes. Well, the package now assumes that anyhow. Maybe that's bad, but I suggest that we should have a moodle-nodb package that gives the admin max flexibility and minimal config automation.
<seb128> slangasek: hey, any idea when the freeze will lift?
<Keybuk> Adri2000, RainCT: seems to be working on https now
<moquist> Regular users who install the 'moodle' package can end up with a worknig system, while power admins can install moodle-nodb and do whatever they like.
<slangasek> seb128: US afternoon today, I expect
<Adri2000> adding comments on https works
<slangasek> moquist: if the local db server is a requirement, which I think is horribly wrong from a packaging perspective, then the db server package should be a *depends*, not a recommends
<maco> slangasek: it's afternoon in part of the US already. has been for 4 minutes :P
<slangasek> and certainly not a pre-depends
<seb128> slangasek: ok, thanks
<slangasek> maco: that coast doesn't count
<moquist> slangasek: right, I would remove it from recommends.
<geser> Adri2000: would it be possible to add a link to the debian changelog (on the debian version) on MoM?
<moquist> slangasek: does having the db server in depends do anything different than simply installing both packages simultaneously?
<ogra> hmm, cjwatson will oem-setup-debconf work over a ssh connection ? i'm pondering to do a prebuilt image for nslu2
<Adri2000> geser: I have a patch for adding a link to the PTS (like in DaD), but not merged (yet)
<Adri2000> oh, it is merged
<ogra> i see it starts by default on the tty
<slangasek> moquist: it enforces the order in which the packages are configured; I'd recommend reading the Ubuntu policy manual
<Adri2000> geser: do you want a direct link to the changelog as well?
<moquist> slangasek: Fair enough. Thanks.
<Adri2000> Keybuk: so, need a sysadmin to put the same server config from https to http?
<RainCT> Keybuk: I was working on a redesign for MoM some months ago. If I finish it, will you(/somewho) commit to get it merged in a reasonable amount of time?  (if that'll be lying around for months like the comments I may as well leave it for this summer)
<geser> Adri2000: would be nice (if it's not to much work) so one can check if a merge is usefull (e.g. now). I can go through the PTS to the changelog but a direct link would be one click less (and one page load less)
<Keybuk> RainCT: sure
<Keybuk> RainCT: the comments stuff wasn't lying around, it needed some extensive security review and discussions between different people ;)
<Keybuk> changing around the html is just a push <g>
<Keybuk> Adri2000: yes
<Keybuk> Adri2000: we also need your existing DaD comments file?
<Adri2000> yes, I already set it read-only on DaD a few minutes ago
<Adri2000> http://dad.dunnewind.net/comments
<RainCT> Keybuk: Great, I'll have a go at it within the next weeks then.
<cjwatson> ogra: hmm, theoretically, though it does prefer to have a framebuffer
<Keybuk> Adri2000: are comments cleared at any point?
<cjwatson> ogra: you'll probably run into some glitches, but I'd be happy to fix them
<Adri2000> Keybuk: yes, when the merge disappear from the list
<Keybuk> Adri2000: cool
<cjwatson> ogra: oem-config-debconf does also rather prefer to have a UTF-8 locale generated though ...
<ogra> yeah, sounds a bit saner to do it that way with a basic bootstrapped jffs2 system than having an 8h d-i install
<Keybuk> ok, your comments now in place
<ogra> meh, now my qemu kernel oopsed right at the end of oem-setup
<Adri2000> Keybuk: there are a few lines of spam in the file you can remove
<cjwatson> YM oem-config?
<Adri2000> geser: maybe file a bug so we don't forget it. also we'd need to find a place where to put the link, maybe RainCT can do that with the new design
<ogra> err
<ogra> and after qemu my X died ... fun
<Adri2000> Keybuk: also grab http://adrishost.net/~adri2000/ubuntu/MoM/result/merges/ubuntu.png and http://adrishost.net/~adri2000/ubuntu/MoM/result/merges/debian.png
<Keybuk> where do they need to go?
<Adri2000> https://merges.ubuntu.com/{ubuntu,debian}.png
<Adri2000> they're used in the Bug column
<RainCT> Keybuk: It's not just HTML, though, I also added a template engine -tinpy, available at SF under MIT License.. just a single file-, that shouldn't be a problem or?
 * ogra cries, so my 30h slug install was just done with its last locale ... grmbl
<Keybuk> RainCT: is the dependency in main?
<Adri2000> Keybuk: have you pinged a sysadmin yet? I pinged Chex as he is the one who enabled mod_python
<RainCT> Keybuk: no, I added it as a file in utils/
<Keybuk> Adri2000: yes
<Keybuk> but no response
<Keybuk> RainCT: that should be ok
 * RainCT tries to figure out why he created two branches :P
<superm1> pitti, could you take a look at https://code.edge.launchpad.net/~superm1/jockey/only-broadcom-sta/+merge/1391 ? I submitted it some time back and wanted to make sure it wasn't overlooked for jaunty
<mvo> LaserJock: please have a look at lp:~mvo/gnome-app-install/always-on-top - the remiaing problem is that its currently slower at startup, I look into that now
<Adri2000> Keybuk: "The requested URL /ubuntu.png was not found on this server."
<pitti> superm1: oh, I think I either overlooked or didn't get the mail for it
<Keybuk> Adri2000: needs a server reload
<Adri2000> ah yes, just saw your commit, you put them in .img/
<RainCT> mvo: arr.. I don't know what you're talking about, but that always-on-top sounds evil *g*
<LaserJock> RainCT: not too evil
<LaserJock> RainCT: it means I get to override the sorting in Add/Remove
<RainCT> LaserJock: Ah, I don't understand your last sentence but it sounds way less scaring ;P
<LaserJock> RainCT: normally Add/Remove sorts alphabetically
<LaserJock> RainCT: for Edubuntu we wanted a way to make certain menu items "float" to the top of the list
<RainCT> LaserJock: Oh, I see. So nothing to do with what I first thought; this actually sounds cool :)
<LaserJock> RainCT: of course! :p
<Adri2000> Keybuk: looks like it's been workarounded :p
<pitti> superm1: done; sorry that this slipped
<superm1> pitti, no problem.  i suspected it was an oversight
<Keybuk> Adri2000: cool
<Keybuk> anything else you need?
<Adri2000> nope, I'll update DaD to show a message saying to go to MoM. also, I'll send an announcement mail to ubuntu-devel, except if you want to do it? anything I should mention apart from comments merged into MoM and DaD shut down?
<RainCT> Adri2000: new interface coming somewhen soon (before they complain :P)
<Adri2000> RainCT: eheh, ok :)
<Keybuk> Adri2000: you can do that :)
<didrocks> jelmer: about evolution-mapi: do you have some time to take into account james_w concerns on REVU?
<jelmer> didrocks, those should already be fixed IIRC
<jelmer> ah, looks like the package just didn't come through
<pitti> superm1: will you be at the LF summit, btw?
<didrocks> jelmer: yep, the new upload is not in REVU
<jelmer> didrocks, I'll see if I can upload a new one in a few minutes
<didrocks> jelmer: no pb, even if it's later. I subscribed :)
<ogra> hmm, isnt oem-config supposed to uninstall itself after it has been run successfully ?
<ogra> it seems to work just fine and properly sets up the first user, but i still have the package and binaries
<cjwatson> ogra: no
<cjwatson> that's been a wishlist for a while, but is a little problematic in case you actually wanted to rerun it for some reason
<ogra> yeah, understood
<ogra> the gui version does that though, no ?
<cjwatson> no, it does not
<ogra> ah, k i thught i read it in a wiki doc
<cjwatson> glad to hear that it worked
<ogra> *thought
<ogra> well, on the tty
<cjwatson> well, you know what wikis can be like :)
<ogra> havent tried it via ssh yet
<cjwatson> ah
<ogra> i'm not a fan of setting up qemu networking on the host side :)
<ogra> so i need to do some fiddling first
<kirkland> superm1: ping, re: dkms
<superm1> pitti, probably not.  we're rather low on travel budgets, so need a good business case if I was going to go
<superm1> kirkland, pong
<kirkland> superm1: i'm no dkms expert, but it looks like there's something wrong with the kvm-source --configure bits
<kirkland> superm1: https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/334177
<ubottu> Ubuntu bug 334177 in kvm "package kvm-source 1:84+dfsg-0ubuntu3 failed to install/upgrade: " [Undecided,New]
<kirkland> superm1: does that package need some better smarts about upgrades in the postinst?
<superm1> kirkland, i'd need to see the log for sure (that log on the bug is invalid)
<superm1> kirkland, but yes you do need to have some smarts in the upgrades to make sure that all previous versions are knocked out
<kirkland> superm1: what log do you need?
<superm1> look at the fglrx or nvidia postinst's for examples
<kirkland> superm1: http://pastebin.ubuntu.com/123471/
<superm1> the dist upgrade log, apt term log, and dpkg.log
<kirkland> superm1: the current postinst is very basic
<superm1> kirkland, definitely not enough
<kirkland> superm1: which is the correct nvidia source package?
<kirkland> superm1: nvidia-glx-180, eg?
<moquist> if my package has multiple binaries with different .config scripts, should I have multiple .templates files or just one?
<kirkland> moquist: better question for #ubuntu-motu
<moquist> kirkland: OK. Thanks.
<mathiaz> robbiew: should I unassign myself from bug 289470?
<ubottu> Launchpad bug 289470 in open-iscsi "open-iscsi user-space does not match kernel module version" [Critical,In progress] https://launchpad.net/bugs/289470
<robbiew> mathiaz: yeah
<robbiew> mathiaz: I'll grab it for my team, thnx
<superm1> kirkland, yeah that should be fine. tseliot did a pretty good job keeping it clean and covering for errors
<superm1> kirkland, look at the prerm and postrm too
<cjwatson> Keybuk: davmor2 confirmed that that udev fix works
<Keybuk> cjwatson: good to know
<slytherin> anything wrong with hal again? I am having trouble playing DVD on latest jaunty.
<slytherin> s/hal/dev
<kirkland> superm1: thanks, i'm digging through it now
<slytherin> Keybuk: Can you help me here? I remember you solved my last problem with udev
<fta> is there a way to add new stuff in ia32lib in hardy? it's really messy for some upstream, like android and chromium. See bug 277772, http://groups.google.com/group/chromium-dev/browse_thread/thread/d3f6b7f4eadb43a3 and http://code.google.com/p/chromium/wiki/LinuxBuild64Bit
<ubottu> Launchpad bug 277772 in ia32-libs "Provide library symlinks for building 32-bit code." [Wishlist,Fix released] https://launchpad.net/bugs/277772
<sea-gull> ï»¿ Hi, All! Will ubuntu participate in Google Summer of Code?
<slytherin> any archive admins around? it seems libgmyth0 got eaten somehow on ports repository.
<kirkland> superm1: looks like i was really just missing "dkms remove -m $PKG -v $PKGVER --all -q > /dev/null"
<superm1> kirkland, yeah that's the important part
<kirkland> superm1: so nvidia's looks like: http://pastebin.ubuntu.com/123507/
<kirkland> superm1: i don't think the if [ "$STATUS" = "True" ] && [ -d $SOURCES ]; then ....
<kirkland> bit applies to me
<kirkland> superm1: that some custom maintainer work for nvidia, right?
<superm1> kirkland, i think that was from some errors in earlier packages to make sure it's cleaned up right
<savvas> Riddell: made patch for bug 102773 - it fixes the problem with unicode server names in combobox_server - any comments welcome :)
<superm1> kirkland, you'll want to check with tseliot though.  he wrote that part in
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/102773/+text)
<kirkland> tseliot: ping?
<kirkland> superm1: agreed, looks like custom cleanup
<maco> kirkland: did you get the mini iso to install at all?
<kirkland> maco: oh, thanks for the reminder!
<kirkland> maco: i'm back home now, and can try again
<kirkland> maco: i was onsite the first of this week and connectivity/equipement was non-ideal
<slytherin> can any of the core dev please give back elisa-plugins-* packages?
<wgrant> Is there a way I can get the old update-notifier behaviour?
<savvas> slytherin: aren't they in jaunty?
<cjwatson> slytherin: could I have the exact source package list?
<tseliot> kirkland: yes?
<kirkland> tseliot: hi there, i'm trying to fix the kvm dkms module installation
<kirkland> tseliot: superm1 pointed me your way
<kirkland> tseliot: i was looking at nvidia's install
<slytherin> cjwatson: sure, elisa-plugins-good, elisa-plugins-bad, elisa-plugins-ugly
<tseliot> kirkland: ok, what's the problem?
<cjwatson> slytherin: all architectures?
<kirkland> tseliot: i think i was just missing: dkms remove -m $PKG -v $PKGVER --all -q
<slytherin> cjwatson: they are arch:all packages
<cjwatson> oh, it's arch all
<cjwatson> ok
<kirkland> tseliot: the error reported is https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/334177
<ubottu> Ubuntu bug 334177 in kvm "package kvm-source 1:84+dfsg-0ubuntu3 failed to install/upgrade: " [High,Triaged]
 * tseliot has a look
<cjwatson> slytherin: done
<slytherin> cjwatson: thanks
 * savvas notes that give back means remove :p
<kirkland> maco: mini.iso installing....
<davmor2> maco: worked here unless we are talking about a non-standard install
<kirkland> davmor2: encrypted-home + Kubuntu
<kirkland> davmor2: starting from mini.iso
<kirkland> maco: that's the problem ^^^ right?
<davmor2> kirkland: Ah only did a standard not e-h
<slytherin> cjwatson: should I report a bug for missing libgmyth0 for ports architectures?
<maco> kirkland: yes
<maco> davmor2: kde tried to write its config files before the ~ was mounted writable. then it tried to read teh config files it failed to write. then it got upset and refused to load.
<davmor2> maco: is it only on netboot or does it happen from cd too?
<maco> i used mini iso. the original bug reporter used netboot. that's all i know.
<maco> the laptop i installed on doesnt have a well-working cd drive, so i can only use mini iso on it
<davmor2> maco: same thing really :)
<davmor2> no probs :)
<kirkland> tseliot: i'm getting an error, though
<tseliot> kirkland: I can't access the log in the bug report but it looks like the source code is being put in the same directory twice or so. I need to have a look at the source code to see what's happening
<kirkland> tseliot: http://pastebin.ubuntu.com/123523/
<kirkland> tseliot: want me to pastebin the postinst script?
<slangasek> LaserJock: is there an impending test of Edubuntu amd64?
<tseliot> kirkland: yes, please
<kirkland> tseliot: http://pastebin.ubuntu.com/123524/
<kirkland> tseliot: that's what i'm working with now
<kirkland> tseliot: this is what it looked like before: http://pastebin.ubuntu.com/123471/
<LaserJock> slangasek: no, I don't have a 64-bit VM unfortunately
<tseliot> kirkland: what's the name of the package?
<tseliot> kvm-source?
<tseliot>  yes, right
<slangasek> LaserJock: ok; is there someone else who usually helps with the amd64 tests?
 * tseliot gets the source
<slangasek> LaserJock: or should I only release the i386 ISO for this alpha?
<davmor2> slangasek: I can run that in a minute :)
<slangasek> davmor2: ok
<LaserJock> slangasek: do I have to have a test to get it released?
<slangasek> yes
<slytherin> can any of the archive/lp admin please copy libgmyth0 for all port architectures in the ports repository?
<LaserJock> slangasek: bugger, ok I can do a test in around 15 min
<kirkland> tseliot: kvm
<kirkland> tseliot: kvm-source is the binary
<slangasek> LaserJock: well, davmor2 just offered
<LaserJock> oh, then that'd be great
<davmor2> slangasek: Won't be for a minute though running tests already so after these I can :)
<slangasek> ok. :)
<LaserJock> slangasek: it seems a little weird to have to do that much testing before releasing an alpha for Edubuntu
<LaserJock> slangasek: it's pretty much just a pool/
<davmor2> LaserJock: still needs to work though dude :)
<LaserJock> well, "work" is a bit relative
<LaserJock> I can't think of much of anything that'd happen with it that I'd say "don't install this"
<LaserJock> which I think is sort of the point of the alphas
<slangasek> LaserJock: if the tasks weren't actually installable off the CD
<slangasek> then there'd be no point in keeping the ISO around
<tseliot> kirkland: ok, I'll try to install it so as to see what's wrong. I'll do it tomorrow though as it's 21:28 here and I'm a bit tired. I'll let you know how it goes
<kirkland> tseliot: thanks, i'll keep hacking on it
<kirkland> tseliot: i think i'm close
<LaserJock> slangasek: what do you mean by "tasks"?
<tseliot> kirkland: ok
<slytherin> Keybuk: please drop me an offline message whenever you see this. Need your help in debugging an issue which I believe is udev/hal related.
<kirkland> tseliot: subscribe to https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/334177
<ubottu> Ubuntu bug 334177 in kvm "package kvm-source 1:84+dfsg-0ubuntu3 failed to install/upgrade: " [High,Triaged]
<kirkland> tseliot: i'll note in there if i fix it
<slangasek> LaserJock: tasksel tasks; is that not what edubuntu installs currently?
<LaserJock> no
<LaserJock> not that I now of
<tseliot> kirkland: ok, done.
<slangasek> ok - "metapackages", then?
<LaserJock> well, I wouldn't consider those as critical to the .iso
<LaserJock> it's a big point of it and we need to know if they are broken for sure
<LaserJock> but it shouldn't stop people from trying out the software that's on the CD
<kirkland> tseliot: cheers, thanks.
<tseliot> np
<slangasek> LaserJock: they can do that straight from the archive if that's all they're doing
<LaserJock> slangasek: they can do the metapackages as well
<LaserJock> the only thing to test that you can't do from the archive is self-consistency
<LaserJock> and that's not often going to change depending on arch
<slangasek> LaserJock: these are the standards that we apply to all ISOs that we release with alphas.  I'm not going to consume disk on the CD server and point our users at ISOs that haven't even been minimally tested before the alpha release.
<kirkland> maco: i'm on tasksel now, just grab Kubuntu-desktop?
<LaserJock> slangasek: fair enough, you're the boss :-)
<kirkland> slangasek: has the archive thawed yet?
<maco> kirkland: yeah
<slangasek> kirkland: it's thawing; what do you have?
<kirkland> slangasek: nothing urgent, kvm, ecryptfs-utils
<slangasek> those should be fine to upload
<kirkland> slangasek: cool, thanks.
<slangasek> seb128: GNOME stuff too, if you want
<seb128> slangasek: ok thanks!
<davmor2> LaserJock: still no usplash on edubuntu
<kirkland> maco: hmm, kubuntu install looks fine to me
<kirkland> maco: the mini.iso install completed
<kirkland> maco: rebooted, logged into kubuntu
<kirkland> maco: my encrypted home is mounted
<kirkland> maco: checked the underlying files...  encrypted contents, encrypted filenames ...
<kirkland> maco: i don't see the problem here ...
<maco> kirkland: ><
<maco> anything change since last week?
<kirkland> maco: hrm
<kirkland> maco: not really in ecryptfs-utils
<kirkland> maco: i can't speak for the installer, though
<kirkland> maco: this should have started working just before FF
<kirkland> wow, i haven't seen kubuntu in a while
<davmor2> kirkland: installer has
<kirkland> cool :-)
<kirkland> davmor2: ah
<kirkland> maco: any chance you can try to reproduce the problem on your end?
<kirkland> maco: i'll note my experience in the bug report
<maco> yeah ill try again
<kirkland> maco: cheers, thanks.
<davmor2> kirkland: maco: I'll run a test tomorrow morning and let you know too
<maco> ok
<kirkland> davmor2: cool, thanks.
<slangasek> ScottK, ryanakca, Riddell: are there kubuntu alpha release notes for this round?
<ScottK> slangasek: How close are you to needing them?
<slangasek> ScottK: hmm, 1.5h
<ScottK> We'll have something.
<slangasek> ok
<LaserJock> wow, this new screen-profile thing is rockin'
<slangasek> ScottK: will https://wiki.kubuntu.org/JauntyJackalope/Alpha5/Kubuntu be the correct link?
<ScottK> Yes.
<LaserJock> davmor2: thanks for doing the Edubuntu amd64 test
<davmor2> LaserJock: np's
<savvas> TheMuso: any luck with powerpc and jaunty build environment?
<savvas> or any progress, heh
<TheMuso> savvas: Oh yes, I've got it set up, I just need to test build
<savvas> TheMuso: do you want me to look up the logs for the patch?
<TheMuso> savvas: no I should have a copy locally here
<savvas> great :)
<savvas> ScottK: we needed a powerpc test build for bmpx if I remember correctly, right?
<ScottK> That needs fixed too.
<ScottK> It failed on the buildd's but I don't know what to do to fix it.
<savvas> with the patch I provided?
<savvas> I mean, the patch I found :P
<ScottK> OK.  I lost sync.  Then yes, we need a PPC test build.
<savvas> ok :)
#ubuntu-devel 2009-02-27
 * Keybuk wonders whether moblin have fixed their boot yet
<slangasek> Keybuk: I think we should start calling you The Cobbler for all the time you spend working on boots
<Keybuk> a co-worker once called me a Blind Cobbler's Thumb
 * ogra orders a pair of new laces from Keybuk 
* slangasek changed the topic of #ubuntu-devel to: Archive: feature-frozen | jaunty alpha-5 released | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | LP believed fixed - please report any further timeouts to #launchpad
<Keybuk> \o/
<StevenK> slangasek: Woot!
<directhex> yays!
<directhex> slangasek, how's cd space looking right now?
<slangasek> directhex: reasonable; we've got a bunch of langpacks fitting now that weren't before (or last cycle)
<slangasek> if you have more we can trim, though, I'd be happy to get the clippers back out. :)
<directhex> slangasek, i am officially calling ":)" on that, then
<slangasek> amusingly, Ubuntu amd64 DVD is oversized
<directhex> there is some possible trimming to be done, but i don't know if there'll be enough time for jaunty
<slangasek> maybe because we now have too many translations; I haven't looked in detail yet
<directhex> but having klingon on there is vital!
<Keybuk> HIja!  tlhIngan maH!
<slangasek> TheMuso, dtchen: why does pulseaudio build-depend on libcap-dev (instead of libcap2-dev)?
<directhex> Keybuk, you win, i've been thoroughly out-nerded
<directhex> even throwing babylon 5 references at slangasek won't hide my shame
<Keybuk> Ah, hell
<slangasek> Keybuk: you were hoping for a rebuttal in Klingon? :)
<Keybuk> slangasek: no, but I was hoping someone would get _that_ language-related Babylon 5 reference <g>
<slangasek> Keybuk: what, "ah, hell"?  Kind of a thin reference. :)
<Keybuk> it's Minbari
<Keybuk> for "open fire" :p
<Keybuk> (or, at least, something phonetically very similar)
<directhex> Keybuk, NOW i remember, but slangasek has a point, a bit thin given the 80.67 hours of series to try & spot it from
<Keybuk> directhex: it's hardly geek trumps if I pick the easy ones, is it? :p
<directhex> :'(
<LaserJock> good grief, the next time somebody tells me chemists are nerdy I'm pointing them to this log :-)
 * directhex flings LaserJock through a jump point
 * LaserJock focuses his laser down to create some plasma then uses some lenses laying around the lab to launch it at directhex 
<slangasek> Keybuk: yes, you win, deh fers't
<directhex> and so to bed
<Keybuk> ;)
<Keybuk> didn't I read somewhere that Minbari was basically polish?
<directhex> zoot zoot
<slangasek> you may have read that somewhere, but I dispute this :)
<Keybuk> dunno
<Keybuk> the only phrases of any Eastern European languages I know come from pornography
<directhex> well, what's "continuous fire" in polish porn? ;)
<StevenK> "Much of the Minbari spoken on screen is derived from Polish, with phrases such as "Ð½Ðµ Ð¼Ð¾Ð¶Ð½Ð¾" (ne mozhno) spoken with a subtitle saying Don't be, such as in the episode War Without End Part I."
<StevenK> From http://en.wikipedia.org/wiki/Minbari
<Keybuk> StevenK: if Wikipedia says it, it must be true
<directhex> StevenK, ehm, isn't polish written with latin alphabet?
<StevenK> Keybuk: I wasn't saying that, I was pointing out that is where you might have read it.
<slangasek> the wikipedia is mother, the wikipedia is father. trust the wikipedia
<directhex> the wikipedia hurts us?
<directhex> *zap*
<Keybuk> what's it got in its wikis, hmm?
<directhex> nobody listen to poor directhex :(
<Keybuk> heh
<Keybuk> I wrote my entire A-Level Computing mock paper as Zathras
 * Keybuk was a little disenchanted with school at that point
<directhex> that's awesome
<directhex> i think i used lines from jimi hendrix's "hey joe" as variable names for mine
<directhex> int heyjoewhereyougoingwiththatguninyourhand = 3;
<directhex> or whatever the pascal equivalent to that is. my mind has faded with age
<Keybuk> "Zathras not know why 6502 has both direct and indirect jump statements.  Zathras not understand, but Zathras do".  etc.
<Keybuk> I still have it somewhere
<directhex> heh
<directhex> okay, now bedtime fo'realz.
<Keybuk> because the school sent it to my parents with a "We are seriously concerned about your child not taking this seriously" type letter
<directhex> it's nearly the hour of the wolf, and i lack the required vodka
<Keybuk> you missed a fine moment for an "hour of scampering" reference, there
 * slangasek traces the wikipedia article's history, and finds that the Polish claim is manufactured out of whole cloth, awesome
<Keybuk> ah!
<Keybuk> pulseaudio has finished building ...
<Keybuk> ... 25 separate debs!
<TheMuso> slangasek: Not sure, something from Debian, and didn't notice. Would you like it changed in the next upload, and are there any advatnages etc? Or is this a transition?
<slangasek> TheMuso: we currently have both libcap1 and libcap2 in main, it'd be nice to transition one of them out
<TheMuso> slangasek: right
<slangasek> TheMuso: there's not much formal transitioning needed
<TheMuso> fair enough
<slangasek> Keybuk, StevenK: hope you're happy, Vorlon has now edited the Minbari article
<TheMuso> Keybuk: Unless there is something for pulseaudio/alsa/etc that cannot wait, would it be possible to push a diff to dtchen or myself, and we can get it lined up for our next upload, since we often have stuff queued for a few days before we upload it, just in case something pops up upstream that we want to pull in?
<Keybuk> TheMuso: I've already uploaded it
<TheMuso> Keybuk: I know, hense my request.
<Keybuk> TheMuso: where would you like the diff?
<Keybuk> http://people.ubuntu.com/~scott/pulseaudio_0.9.14-0ubuntu9.debdiff
<TheMuso> Keybuk: We have a bzr repo for the pulseaudio packaging metadata at lp:~ubuntu-core-dev/pulseaudio/ubuntu. I'm already merging your changes now, so its fine for now,.
<Keybuk> TheMuso: you should add the Vcs-Bzr header to debian/control
<Keybuk> because then I would have already given you the change via bzr ;)
<TheMuso> fair enough
<dtchen> i totally added Vcs-Bzr at some point
<Keybuk> I always make sure to check for that header
<TheMuso> dtchen: looks like it got lost somewhere. I'll re-add it.
<TheMuso> dtchen: and merge your branch.
<dtchen> TheMuso: ok, thanks. i've a bunch of alsa-lib and alsa-kernel workarounds i'll be pushing to /timing before they end up in /ubuntu
<TheMuso> ok
<calc> umm evolution preferences is too big to fit on a 1280x800 screen with proper DPI set
<calc> anyone know if samba is generally broken or just for me? i segfaults on startup
<ajmitch> calc: I recall a fix being talked about a couple of days ago for a samba crasher
<calc> ajmitch: hmm must not be uploaded yet, it crashes every time on start for me
<ajmitch> 2:3.3.0-4ubuntu1?
<ajmitch> I guess it's file-a-bug time :)
<TheMuso> 8/c
<calc> ajmitch: i just upgraded and didn't get 4ubuntu1
<hyperair> meh pbuilder doesn't seem to want to create a sid chroot
<giunzin> hi. anybody here?
<giunzin> i am using Hardy, and have no Direct Rendering.
<giunzin> from glxinfo:
<giunzin> ï»¿ï»¿direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
<giunzin> my video card is: ï»¿00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
<giunzin> i reported in ubuntu-bugs, but it seems everybody is sleeping? so i come here for some helps
<calc> ajmitch: 4ubuntu1 is dep wait still so it missed alpha 5
<calc> its dep wait because someone added a dep ctdb which is universe without getting it into main first
<calc> d0h
<calc> zul: getting ctdb into main anytime soon? being able to run samba would be nice :)
<dholbach> good morning
<dholbach> can somebody take a look at bug 23435?
<ubottu> Launchpad bug 23435 in langpack-locales "Can't select Esperanto language in gnome" [Medium,Fix released] https://launchpad.net/bugs/23435
<dholbach> and bug 201495?
<ubottu> Launchpad bug 201495 in policykit-gnome "Policy Kit auth dialogue lists me as "${My Name},,,,"" [Low,Triaged] https://launchpad.net/bugs/201495
<dholbach> doko: is bug 324708 a jaunty target?
<ubottu> Launchpad bug 324708 in python2.5 "Please backport fix for http://bugs.python.org/issue4150 (r67000)" [Undecided,In progress] https://launchpad.net/bugs/324708
<dholbach> ArneGoetje: what about bug 329435 and bug 329425?
<ubottu> Launchpad bug 329435 in scim-anthy "New upstream release 1.2.7" [Undecided,New] https://launchpad.net/bugs/329435
<ubottu> Launchpad bug 329425 in anthy "new upstream release 9100h" [Undecided,New] https://launchpad.net/bugs/329425
<hyperair> dholbach: regarding bug 201495, it looks like /etc/passwd has trailing commas.
<ubottu> Launchpad bug 201495 in policykit-gnome "Policy Kit auth dialogue lists me as "${My Name},,,,"" [Low,Triaged] https://launchpad.net/bugs/201495
<hyperair> is there supposed to be any information between the commas?
<andersk> Yes, that is the GECOS information (full name, room, phone numbers).
<hyperair> ah i see
<slangasek> calc: uploaded and dep-wait.
<slangasek> calc: right, I shall learn to read my scrollback in reverse.
<calc> slangasek: heh yea :)
<calc> slangasek: its waiting on a MIR i guess
<calc> i was attempting to test a bug in OOo that needed working samba and noticed that issue :)
 * calc off to bed
<ScottK> slangasek: Would you please accept plasmoid-am4rok in intrepid-backports and throw 335296 kepas at syncbugbot?
<ScottK> Details are in Bug 335296.
<ubottu> Launchpad bug 335296 in intrepid-backports "Please backport kepas and update plasmoid-am4rok for intrepid-backports" [Wishlist,In progress] https://launchpad.net/bugs/335296
<ScottK> That hopefully will be the last backport needed to get in sync with kde 4.2.0.
<slangasek> ScottK: plasmoid-am4rok is a backport, but isn't in jaunty?
<slangasek> ah, I guess that's why it's sourceful :)
<lool> bryce_: I see there's a new upload of xorg-server being prepared, I guess it's meant for now (post-a5) it's a new upstream; I prefer not pushing that but will commit a lpia fix right now; please git pull before uploading  :-)
<lool> bryce_: Ah nevermind, my change is in xorg; not xorg-server
<cjwatson> slangasek: re grub2-by-default, it's unusual to approve a spec that has an "Unresolved issues" section. Is there anything we can do about that - perhaps some of it can be marked as future work?
<cjwatson> slangasek: UUID support is mentioned there but seems to be also mentioned in the main body of the spec
<slangasek> cjwatson: hrm, the spec template implies that the "unresolved issues" section is meant to be used precisely for identifying unresolved issues that are out of scope for the current spec
<cjwatson> hmm, last I looked at the spec template it said that a spec couldn't be approved with unresolved issues
<cjwatson> ah, I see
<cjwatson> I guess I read that too strictly, or else it's been revised
<slangasek> UUID support ought only be mentioned in the body, since we're doing that by default everywhere and rather need it to work - I just don't know if it does work or if it would imply an FFe
<pitti> Good morning
<slangasek> moin
<slangasek> dropped UUID from the unresolved issues section
<cjwatson> I can't really see how an FFe would be necessary for that, since it's dealing with software that (by presumption) hardly anyone installs right now, and the feature is present in the implementation people are actually using ...
<cjwatson> approved the spec now
<slangasek> thanks
<maco> pitti: the xserver-xorg-video-intel change you made 2 days ago. was it extensive enough to have broken VT switching, or should i be looking at xorg-core?
<maco> (or elsewhere)
<pitti> maco: I doubt it, it just adjusted some numbers; but please downgrade to the previous version and check if it fixes it?
<maco> will that require downgrading other xorg packages? if not, that won't narrow things down.
<dholbach> hiya juanje
<juanje> dholbach: good morning :-)
<pitti> Keybuk: in your init script moving efforts, did you consider moving dkms_autoinstaller, hotkey-setup, kvm, postfix, too?
<pitti> Keybuk: uh, you just call update-rc.d -f cups remove? that doesn't respect user configuration if the symlinks were removed in some runlevels
<scizzo-> slangasek: I am sorry to ask but is that grub information about UUID in the menu.lst and error 11 from trying to boot from latest grub and grub2?
<apw> bah, all these apps just popping up all over the place is awful
<tjaalton> how to make a debian/pkg.install -file arch dependent? appending .arch doesn't work, and I can't find it in the debhelper documentation :/
<cjwatson> debhelper(1) claims that debian/pkg.install.arch should work ...
<cjwatson> but you could take ubiquity's approach and just build debian/pkg.install dynamically in debian/rules
<tjaalton> I'm trying to modify adobe-flashplugin which is currently i386-only, and the goal is to minimize the changes :)
<tjaalton> building them dynamically is what I've done before
<tjaalton> maybe just having debian/install.arch doesn't work, so I'll try renaming it..
<tjaalton> yeah, pkg.foo.arch works, foo.arch doesn't
<tjaalton> thanks
<cafetiere> the new notifiers, what package are those for reporting bugs?
<cafetiere> (the new jaunty see through ones)
<pitti> cafetiere: notify-osd
<pitti> thekorn: thanks for merging the subscriber fix
<pitti> thekorn: any chance you could commit doko's p-lp-bugs change? http://launchpadlibrarian.net/23161188/python-launchpad-bugs_0.3.2_0.3.3.diff.gz
<apw_> pitti, yeah just testing the alpha CD and they are all appearing overlapping the menus
<apw_> and pretty sure thats not what they are meant to do
<pitti> previously they were a little further down indeed
<apw_> and they are too narrow to even fit connection established in
<apw_> which given they are so small they are almost unreadable is daft
<thekorn> pitti, sure, will merge the change in a bit
 * pitti hugs thekorn
 * thekorn hugs pitti 
<cjwatson> pitti: dunno if you saw, but ronne's firewall has been fixed
<pitti> cjwatson: no, just replied; it's still broken :(
<pitti> at least for the things I care about, launchpadlib and smtp; ssh also doesn't work
<cjwatson> ah :(
<pitti> thekorn: after you merged it, I'll do a new jaunty upload then, so that the retracers can be started again
<pitti> thekorn: could you use 0.3.4 as next version number?
<thekorn> pitti, yes, /me was thinking about the correct version number, 0.3.4 sounds sensible
<thekorn> pitti, pushed
<apw> apw_ ping
<apw> apw_ ping
<pitti> thekorn: uploaded
<thekorn> pitti, danke
<pitti> apw: testing yourself? :-)
<apw_> testing the popups for highlighted messages, or as they are now know Highlig...
<apw_> bah they don't concatenate either
<doko> thekorn: thanks
<pitti> doko: jockey with python2.6-ification uploaded
<doko> dholbach: yes, I set it to "progress"
<dholbach> doko: ok super - thanks
<doko> pitti: \o/
<arthur-> doko: /query please
<pitti> cjwatson: do you want intrepid-proposed d-i against 2.6.27-12 accepted? (linux is at -13 now)
<cjwatson> pitti: I can reupload for -13 now
<liw> upgrading a machine from hardy to intrepid to jaunty removes the openssl-blacklist package -- is that intentional?
<cjwatson> removes due to conflict or due to lack-of-dep?
<liw> I didn't look yet, just saw it in update-manager's list of packages it wanted to remove
<IntuitiveNipple> Which package should this bug be against? When operating more than one X screen and working on the additional screens for some time, the displays will try to go to screensaver unless there's activity on screen 0
<mdz> calc: I haven't worked out exactly which package it is the trigger, but oo.o often seems to crash while I'm installing updates.  is this a known issue?
<liw> bah, the upgraded machine blanks its screen about when usplash should be shown
<mdz> calc: maybe fonts?
<pitti> cjwatson: thanks
<seb128> mdz: could be bug #286175 as a random guess
<ubottu> Launchpad bug 286175 in fontconfig "evince crashed with SIGSEGV in FcConfigSubstituteWithPat()" [High,Confirmed] https://launchpad.net/bugs/286175
<seb128> ctrl-w on the wrong dialog
<ogra> hmm, trying our pitti's "xdpyinfo |grep dimensions" from teh ML my screen size is totally wrong ...
<mdz> seb128: maybe, thanks
<seb128> mdz: you're welcome
<ogra> i wonder how to tell Xorg about the right values
<mdz> ogra: DisplaySize in xorg.conf
<mdz> unfortunately it is not in HAL (yet?)
<ogra> mdz, thanks !
<ogra> funny
<ogra> intel(0): Display dimensions: (262, 165) mm ... from Xog.0.log
<ogra> ogra@osiris:~$ xdpyinfo |grep dimensions
<ogra>   dimensions:    1280x800 pixels (339x212 millimeters)
<ogra> (**) intel(0): DPI set to (124, 197) ... log again ...
<ogra> ogra@osiris:~$ xdpyinfo |grep resolution
<ogra>   resolution:    96x96 dots per inch
 * ogra looks puzzled
<ion_> Perhaps Gnome or something forces the DPI to 96, and then xdpyinfo computes the dimensions based on it?
<ogra> gnome forces X ?
 * ogra cant imagine that
<apw> this new login screen, is it really almost all black, with black background and black bacgrounds in the menus and dialogs?
<pitti> apw: yes
<apw> doh
<apw> is that going to be fixed?
<pitti> apw: complaints -> kwwii, I think for now that's intentional
<apw> is kwwii a person?
<ogra> the buttons of the popup windows look a bit lost
<ion_> Unlike some UI changeâs weâve seen during Ubuntu alphas, this one is quite nice. :-)
<ogra> without a window frame for the popups
<wgrant> People at work today were quite pleased, apart from it possibly being slightly too black.
<apw> the overall effect is fine, its the lack of border to the menus and popups thats plain odd
<cjwatson> pitti: (debian-installer/intrepid-proposed reuploaded now)
<cjwatson> siretart: I'd appreciate your comments on my last entry in bug 44194, when you have a moment
<cjwatson> and indeed those of others
<ubottu> Launchpad bug 44194 in netbase "wpasupplicant doesn't start when the network start" [Undecided,Fix released] https://launchpad.net/bugs/44194
 * ogra wonders why he doesnt have human icons anymore even though they are selected 
<lool> Keybuk: Just a heads up that I provided the details for the autoconf / dash? issue I've been seeing; it's definitely not a local config as I reproduced in a clean jaunty vm
<Adri2000> Keybuk: hmm the comments disappeared and adding a comment produces an internal server error. know what happened?
<Adri2000> Keybuk: I'm afraid the comments file got corrupted by something... if that's the case, it may mean we missed a security hole :/
<pitti> evand: oh, usb-creator isn't in bzr? I wanted to commit a fix for bug 331327 (which completely breaks cration with persistent storage)
<ubottu> Launchpad bug 331327 in usb-creator "install.py crashed with TypeError in main()" [High,Confirmed] https://launchpad.net/bugs/331327
<evand> pitti: it is, lp:~ubuntu-installer/usb-creator/trunk
<pitti> evand: ah; can you please add Vcs-Bzr:?
<evand> perhaps I should move that to core-dev, or make a ~ubuntu-installer team composing both core-dev and ubuntu-installer
<evand> pitti: will do
<pitti> evand: and I just saw that I can't commit anyway
<pitti> evand: just testing the proposed fix there
<evand> committed vcs-bzr change as r81
<pitti> evand: cool, thanks
<evand> I'll work on getting usb-creator open to core-dev as well.  If you'd prefer for the meantime, feel free to point me at a patch and I'd be happy to commit it.
<pitti> evand: not a diff -u patch, but explanation and new code line is in https://bugs.edge.launchpad.net/ubuntu/+source/usb-creator/+bug/331327/comments/3
<ubottu> Ubuntu bug 331327 in usb-creator "install.py crashed with TypeError in main()" [High,Confirmed]
<evand> whoa, whoops
<pitti> evand: okay, that works
<cjwatson> is there anyone in ubuntu-installer but not in ubuntu-core-dev who needs to commit to usb-creator?
<evand> thanks for catching that pitti
<cjwatson> it could just be moved to core-dev and then we wouldn't have to think about the messy bugmail consequences :-)
<cjwatson> of course ubiquity has the same problem ...
<pitti> evand: the "successful" dialog (as well as the error dialog) is horribly broken, but that's another issue
<evand> cjwatson: good point, just trying to be forward thinking in case usb-creator gets some contributors who are not in core-dev
<cjwatson> maybe we should just disable ubuntu-installer's bug subscriptions and subscribe to things individually
<pitti> evand: usually you have a trunk (with an upstream team) and an ubuntu branch (with the packaging added, and being owned by core-dev)
<evand> pitti: indeed, that's my wraplabel code being rubbish.  Working on a fix ever so slowly.
<cjwatson> pitti: excess complexity for native packages
<evand> pitti: this is a very ubuntu specific project though
<evand> indeed
<pitti> evand: ubuntu specific> oh, is it? okay, then it's sensible to just keep one branch
<pitti> I didn't know that it just works for ubuntu CDs
<evand> yeah, I hope to finish up my code to call gnome-app-install soon, among other deb specific bits (it is dependent on our syslinux and casper setup).
 * pitti goes to test-boot it on wife's machine
<evand> pitti: what's wrong with saying bs=1M?
<pitti> evand: you can say bs=1M, but then you need to use int(persistent)/1048576
<pitti> for count=
<pitti> evand: and you really don't want bs=1
<pitti> so I thought bs=%size and count=1 is both efficient and correct
<evand> size is in MB though
<evand> I think
<pitti> not for me
 * evand checks
<pitti> PythonArgs: ['/usr/share/usb-creator/install.py', '-s', '/tmp/tmpi9gLFd/.', '-t', '/media/LinBoot', '-p', '1103998510']
<evand> ah, so you're right
<evand> wonderful
<pitti> on my system (250 MB free) I had ~ 250000000
<pitti> nice, it boots
<evand> Right, so any objections to me making a new usb-creator-hackers team and adding core-dev as a member?  As previously stated, this is so the few people providing occasional patches who are not in core-dev can contribute without having to jump through hoops.
<pitti> sounds fine to me
<evand> great, will do.  I'm about to commit your suggested fix for the dd issue as well.
<Keybuk> Adri2000: you should probably fix that, then ;)
<Adri2000> Keybuk: yeah, but I'd need to see the comments file first
<Keybuk> it's zero bytes
<Keybuk> and mysteriously owned by the merge user
<Keybuk> race condition or bug between user updates via addcomment.py and system-updates via manual-status/merge-status run maybe?
<Keybuk> you could do with some locking too
<Keybuk> a read lock around get_comments
<Keybuk> likewise a lock around remove_old_comments
<Keybuk> which should be in a common file
<Keybuk> *and*
<Keybuk> just looks plain wront
<Keybuk>     file_comments = open(comments, "w")
<Keybuk>     for line in open(comments, "r").readlines():
<Keybuk> opening it for writing like that will truncate the file
<pitti> evand: this was actually the first time I tried an USB stick with persistance; this is so cool
<Keybuk> so when you open it for reading, *boom*
<pitti> a workstation to be carried on your keyring
<Keybuk> (no idea why it jumped user though)
<evand> pitti: wonderful, let me know if you run headfirst into any bugs :)
<apw> cjwatson, who is the right person to whine at if i am doing an upgrade to jaunty using upgrade manager, and the thing gets stuck sitting there with 2 mins remaining.  Nothing is obviously going on until one open the Termina where it is asking a question
<cjwatson> apw: mvo
<apw> checkbox is asking to replace its configuration files (which are unmodified)
<apw> cjwatson, thanks
<evand> pitti: I'm hopefully adding a button for gnome-app-install in a chroot for -updates, so it very much will be your custom workstation on your keyring
<cjwatson> such prompts should cause the terminal to open automatically
<directhex> importing the debian keyring takes a while
<apw> cjwatson, that they don't
<pitti> evand: only difficulty I had was wrestling with the bios; interestingly, it didn't work with any of USB-{CDROM,FDD,ZIP,HDD}, but was detected as a proper hard disk, and there was a separate menu for the hard disk priority; *grumpf* :)
<evand> (chroot of the unpacked squashfs, that is)
<cjwatson> apw: I mean "ought to, and used to"
<apw> i assume that is a bug in update-manager
<evand> odd
<apw> yeah i took you to mean that :)
<apw> will file a bug on it
<cjwatson> used to be that a read on the tty caused the window to open
<apw> seems to ahve stopped workgin
<apw> will also file a bug on checkbox as something is wrong there too
<Adri2000> Keybuk: argh... strange because I had no problem when testing that
<Keybuk> Adri2000: the code is clearly wrong
<Keybuk> common practice would be to
<Keybuk> open a temporary file for writing
<Keybuk> open the original file for reading
<Keybuk> lock the original file
<Keybuk> read lines from the original, write to the temporary
<Keybuk> close the temporary file
<Keybuk> rename the temporary file to the original filename
<Keybuk> close the original file
<Adri2000> yep, that indeed doesn't look correct when reading the code now. dunno why I didn't catch it when testing
<doko> lool: hmm, the last xorg update forced a logout
<Adri2000> Keybuk: and the internal server error is caused by the wrong ownership?
<siretart> cjwatson: is it already shown that moving the required libs to /lib will indeed solve the race conditions of that bug?
<cjwatson> siretart: which race conditions are those?
<cjwatson> siretart: the existence of race conditions here seems to be complete speculation?
<siretart> sorry, I cannot fully focus on that bug right now (I'm at work), but AFAIR the race that the networking must not be initialized too early else it will fail
<Keybuk> Adri2000: yes
<siretart> that bug does AFAIUI not only occur on systems with seperate /usr
<Keybuk> that doesn't sound like a race condition
<Keybuk> that sounds like a "hey, where did my dependencies go" condition
<Keybuk> or a "ra ra ra before the left foot went in" condition
<cjwatson> if it relied on being able to write to the root filesystem at some point, that would also explain why the udev rule didn't work
<siretart> I have to admit that I didn't understand yet why wpasupplicant actually fails here
<Keybuk> oh, wpa supplicant
<Keybuk> it fails because most of the things wpa supplicant wants are under /usr
<Keybuk> and wpa supplicant tries to write to the filesystem
<Keybuk> both of these are false assumptions
<cjwatson> Keybuk: yes, that was what I was asking siretart about way up ^- there
<cjwatson> see my last comment in bug 44194
<ubottu> Launchpad bug 44194 in netbase "wpasupplicant doesn't start when the network start" [Undecided,Fix released] https://launchpad.net/bugs/44194
<cjwatson> I think most of the write-to-the-filesystem bits have been fixed since the original bug was filed
<siretart> Keybuk: err, why would that fail on systems with /usr on /?
<cjwatson> the only thing I see remaining is the logging
<Adri2000> Keybuk: k, well I'm going to fix the code. in the meantime, we should restore the comments file from DaD. also when is merge-status.py run? if I can't give you a patch before the next run, we should disable remove_old_comments() call until then
<cjwatson> siretart: writing to the root filesystem would fail even so - and you would certainly make that "go away" by forcing the device to come up after S40networking
<Keybuk> Adri2000: please just fix it
<Keybuk> no point working around it until then
<Keybuk> since it'll just break again in 40 minutes time
<Keybuk> and an hour after that
<Keybuk> etc.
<siretart> cjwatson: okay, so your suggestion only covers the "/usr is seperate" problem, right?
<cjwatson> siretart: no, I think it covers both provided that the original problem was in fact due to trying to write to the root filesystem
<cjwatson> I agree that there is some speculation here
<cjwatson> but I think it would be a whole lot easier to work out what's going on if wpa devices were working like the rest of the boot sequence
<siretart> sure
<cjwatson> you suggested wpasupplicant failing to start yourself as a possible cause
<cjwatson> but I do concede I have not proven anything yet
<cjwatson> this just seems like the best path to satisfying everyone
<cjwatson> I think we can move the libraries to / regardless, and then proceed with wpasupplicant testing out of a PPA
<cjwatson> anything that hardcodes those library paths is truly broken :-)
<siretart> that would affect 3 packages: openssl, pcsc-lite and libz
<siretart> with libcrypto being the largest
<siretart> for local testing, wouldn't it be sufficient to hardlink these 4 libs to /usr?
<siretart> for local testing, wouldn't it be sufficient to hardlink these 4 libs to /lib?
<cjwatson> I guess, but it seems obviously correct to move them regardless of anything else
<cjwatson> and ITYM copy, if /lib and /usr/lib are on different filesystems
<siretart> of course
<Adri2000> Keybuk: what about http://adrishost.net/~adri2000/ubuntu/MoM-comments.patch ? (not tested, and the same is needed for manual-status.py)
<cjwatson> but I could start with PPA packages of  openssl pcsc-lite zlib wpasupplicant  and see what happens, I support
<cjwatson> suppose
<ion_> Letâs just make /usr/lib a symlink to /lib ;-)
<cjwatson> I'm not going there
<Mithrandir> ion_: let's make /usr a symlink to / :-)
<ion_> :-)
<Adri2000> Keybuk: if you don't have any more recent backup of the comments, use those we imported yesterday: http://adrishost.net/~adri2000/ubuntu/DaD.comments
<Keybuk> Adri2000: looks better
<Keybuk> you need locking in get_comments
<Adri2000> why? it doesn't write anything, it just reads the file
<evand> Is setting a contact address the only thing I need to do to prevent core-dev from getting spammed by being a member of another team?
<LordMetroid> Where can I see what the repositories contains for the upcomming Jaunty
<directhex> LordMetroid, http://mirror.ox.ac.uk/sites/archive.ubuntu.com/ubuntu/dists/jaunty/main/binary-amd64/Packages.bz2
<lool> doko: Really?  I don't think it was my change as I only changed:
<lool> -    alpha|hurd-i386|i386|amd64)
<lool> +    alpha|hurd-i386|i386|amd64|lpia)
<lool> in the postinst
<lool> But it might be a bug in this package still
<Stskeeps> Keybuk: ping
<Laney> could it be made more obvious that there is a text field on mom?
<sistpoty|work> Laney: that's security by obscurity :P
<Stskeeps> Keybuk: (and if you're pondering why i'm pinging you: is it possible to seperate bootchart into gathering and chart generation, much like bootchart and bootchart-view in debian.)
<RainCT> Laney: it's more obvious in my new design
<RainCT> Laney: (and Ajax will also come)
<ogra> doko, did you have qemu running by chance when that happened ? i noticed if i hit page down in qemu my X seems to crash
<doko> ogra: no
<ogra> i had that twice yestrday but didnt have time to research ir more yet
<ogra> *it
<apw> is the main login screen part of the gdm package?
<apw> for reporting bugs in it?
<cjwatson> broonie: I don't suppose you still have the diff from zlib 1:1.1.4-12 -> 1:1.1.4-13? It would save me resurrecting it ...
<cjwatson> or rather redoing
<cjwatson> (see above discussion about wpasupplicant library dependencies in /usr)
<broonie> cjwatson: I very much doubt it.
<broonie> snapshot.debian.net?
<amitk> apw: apt-cache search gdm-themes?
<cjwatson> looked there
<cjwatson> I wasn't sure, I take the packrat approach to my uploads but I know not everyone does :-)
<doko> asac: please upload xulrunner-1.9
<broonie> I do but the machine that's got the archives that old on is kaput right now.
<cjwatson> ah
<cjwatson> oh well, sure it can't be that hard
 * broonie wonders WTF I was doing up early enough to do uploads at 8am
<broonie> No, from memory it's very straightforward.
<broonie> and bitrotted by an intervening upstream build change IIRC
<apw> amitk, there are only three bugs ever in there
<amitk> apw: I thought I saw ubuntu-gdm-themes being updated today
<amitk> but I could be wrong
<apw> amitk, i have no clue how to find the package for half the things i see these days ... its probabally that one... will try and figure it out
<lamont> pitti: gar.
<ogra> amitk, uploaded tue.
<ogra> apw, the gdm theme is ubuntu-gdm-themes ...
<apw> ogra, thanks ...
<asac> doko: for the transition?
<asac> doko: you can just upload by appending .doko to current revision
<asac> ;)
<asac> if its just a respin i mean
<doko> asac: ok, will do, but without the doko ...
<asac> doko: whatever just use ubuntu1.something
<asac> and not ubuntu2 ;)
<asac> otherwise i have to bump in bzr ;)
<pitti> lamont: sorry..
<cjwatson> broonie: lp:~ubuntu-core-dev/zlib/ubuntu, FYI (figured I might as well!)
<dholbach> Matthias "doko", "Upload king" Klose
<broonie> cjwatson: Thanks, patches from Ubuntu is hte main reason I tried bzr :(
<Keybuk> Stskeeps: I've never seen the point of that
<Stskeeps> Keybuk: of seperating them? well, example - mobile device, limited space, you don't want to install a jre to get a simple bootchart
<cjwatson> broonie: well, the two outstanding patches are lpia (fairly Ubuntu-specific) and the amd64 library path stuff which would break on Debian. I've sent you a bug for the lpia addition just in case you want it though
<cjwatson> (since it's harmless)
<Keybuk> Stskeeps: but then you have all the faff of trying to copy off tarballs, etc.
<Stskeeps> Keybuk: which is immensely less troublesome than making space for a JRE :P if i wanted to generate bootcharts on-device, i could always apt-get install bootchart-view, but in 95% of cases, i wouldn't
<Stskeeps> and i would delegate the work to a more powerful machine
<Stskeeps> also, there are tools generating bootchart format files as well, and would like to not have to include the data gathering part, but would want the chart generator.
<Keybuk> Stskeeps: fair enough
<seb128> Keybuk: have you seen that some guys rewrote bootchart in python now?
<Keybuk> seb128: no, I hadn't seen
<Keybuk> *sigh* @ language elitism
<seb128> Keybuk: http://mail.gnome.org/archives/performance-list/2009-February/msg00000.html
<seb128> Keybuk: I've to admit I would prefer using python, some update recently installed me a lot of jre things only for bootchart and it breaks since when bootcharting desktop login
<Keybuk> breaks how?
<seb128> I've to look into details, it just didn't write an image in the log directory when running the stop-bootchart script after login
<seb128> I will have a look at next book and file a bug if that's still an issue
<broonie> cjwatson: Yeah, I know - it was more of a general comment, really.
<Keybuk> if you could have a look, that would be appreciated
<Keybuk> in the bug, note:
<Keybuk> is bootchart-collector running before you run stop-bootchart
<Keybuk> if not, can you see a core file in /dev/.bootchart or similar?
<seb128> ok, I don't want to reboot now but I will try a bit later and let you know
<Keybuk> try adding debugging stuff (like ulimit -c unlimited and >logfile 2>&1) to the initramfs init-stop script, regenerate and reboot
<Riddell> james_w: bzr-buildpackage -S -sa  why is -sa not an option?  how do I get it to include the .orig?
<james_w> "bzr-buildpackage -- -S -sa" if you are on an up-to-date jaunty
<Riddell> but of course
<james_w> annoying, I realise, but a huge improvement on Intrepid
<lool> Keybuk: Did you fail reproducing the Gtk+ issue locally?  would be faster if you could reproduce
<doko> pitti: is #334834 a real problem?
<Keybuk> lool: it needs a newer version of glib than I have
<Keybuk> so it failed to even configure
<BUGabundo> bryce ping
<BUGabundo> bug 335465
<ubottu> Launchpad bug 335465 in xorg "resume from hibernation crashed X" [Undecided,New] https://launchpad.net/bugs/335465
<lool> Keybuk: You're running?  intrepid?
<ScottK> slangasek: Thanks for taking care of the backports.  plasmoid-am4rok was for amarok 1, so it's dropped in Jaunty, but since we backported KDE4.2, it needed to be updated in backports for libplasma3.  Sorry I didn't explain it.
<liw> today does not seem to be the day when I get jaunty installed... upgrading broke the machine completely (every boot crashed hard), and today's installer tells me the kernel doesn't see partitions it has just created
<Keybuk> lool: yes
<BUGabundo> liw: humm is it the udev bug? wasn't that fixed?
<Keybuk> the kernel doesn't see the partitions?
<Keybuk> BUGabundo: we didn't include the fix in alpha 5
<liw> BUGabundo, I have no idea what bug it is
<liw> Keybuk, is it in the daily iso image on cdimage right now?
<pitti> doko: how do you mean?
<Keybuk> liw: the live image is yesterday's
<Keybuk> so no
<BUGabundo> guys the LP retracer is closing all bug as invalid
<BUGabundo> with this text
<BUGabundo> However, processing it in order to get sufficient information for the developers failed (it does not generate an useful symbolic stack trace). This might be caused by some outdated packages which were installed on your systemat the time of the report:
<BUGabundo> bug 334834 , bug 333530 and few other dups
<ubottu> Launchpad bug 334834 in screenlets "ClearCalendarScreenlet.py crashed with SIGSEGV in PyType_IsSubtype()" [Undecided,Invalid] https://launchpad.net/bugs/334834
<ubottu> Launchpad bug 333530 in screenlets "screenlets not working at all" [Undecided,Invalid] https://launchpad.net/bugs/333530
<liw> Keybuk, hmm, damn, then there's no point in getting the alpha5 image, either (should be the same iamge)
<pitti> doko: looks like python sigsegved, but that particular report is fairly useless
<BUGabundo> liw did you upgrade with CD or UM -d ?
<liw> BUGabundo, upgarde with update-manager, install from scratch with cd (really: usb)
<liw> the installer thinks helsinki is in murmansk, but I could live with that
<BUGabundo> s/cd/live image/
<Keybuk> liw: all of the city locations seem a little bit out
<Keybuk> I guess that the projection of the map changed from the original graphic to the timezone one
<Keybuk> and the city location overlay hasn't been adjusted to the new projection
<liw> Keybuk, something like that
<doko> seb128: I need another pygobject upload (hardcoded python2.5 interpreter version causing build failures)
<seb128> doko: just upload if you need to, there is no bzr nor pending work for thise
<seb128> those
<seb128> I'm about to run for a bit now but I can have a look later if you don't
<RainCT> savvas: weird, I got it
<RainCT> savvas: now?
<savvas> RainCT: yes
<RainCT> :)
<savvas> what was wrong? :P
<RainCT> (don't ask :))
<savvas> ah come on
<RainCT> savvas: was giving it 'email1, emails2, email3' but it wanted them in a list.. if I tried with more than one mail only the first person in the list got it :p
<savvas> hehe, glad it was solved, revu back in action!
<RainCT> The sad thing is that nobody beside you noticed this :P
<RainCT>  
<RainCT> err.. /me wonders why he moved to -devel :P
<cafetiere> for better weather?
<calc> mdz: on jaunty?
<cjwatson> liw: the partitioner problem is a race condition, so repeated tries should eventually succeed
<cjwatson> ogra: given the slug workaround we discussed yesterday and documented in the release notes, can I safely assume that you no longer need a custom build?
<mdz> calc: yes
<calc> mdz: i'll test it out and see if i can reproduce the problem
<mdz> calc: seb128 pointed out it may be bug #286175
<ubottu> Launchpad bug 286175 in fontconfig "evince crashed with SIGSEGV in FcConfigSubstituteWithPat()" [High,Confirmed] https://launchpad.net/bugs/286175
<calc> mdz: ah so its a fontconfig bug?
<mdz> calc: I don't know
<calc> ah i see i responded to the bug a while back
<calc> looks like it is probably fontconfig if it affects both OOo and evince the same way
<calc> i haven't triggered the OOo crash in a while which was why I had forgotten about it
 * calc sees a patch and checks to see if it is in ooo-build yet
 * BUGabundo and uswsusp hibernate support discussion starts again
<calc> mdz: i should have the issue fixed in the next upload, which should be next week
<mdz> calc: cool, thanks!
<savvas> bzr suggests an upgrade for lp:~ubuntu-core-dev/software-properties/main - http://paste.ubuntu.com/123882/
<Keybuk> lool: kooky
<Keybuk> libtool: link:  cat .libs/libgdk_pixbuf-2.0.exp | sed -e "s/\(.*\)/;/" >> .libs/libgdk_pixbuf-2.0.ver
<lool> Keybuk: Ah great, I searched for similar constructs but didn't find them
<lool> Keybuk: Actually that's from libtool isn't it?
<lool> Keybuk: But *libtool* is corrupted way before that
<lool> Keybuk: Which is why you see a \001
<Keybuk> you're supposed to see a \001 there though, right?
<Keybuk> ohhhh
<Keybuk> hahahahahahaha
<Keybuk> something is turning \1 into the ^A :p
<Keybuk> where \1 is the sed "first thing I matched" thing
<Keybuk> interesting that immediately after configure, the libtool script is valid
<Keybuk> lool: it's the po-properties subdir doing it
<Keybuk> ah
<Keybuk> hahaha
<Keybuk> this Makefile is just wrong
<Keybuk> 	  && CONFIG_FILES=po-properties/Makefile.in CONFIG_HEADERS= \
<Keybuk> 	       /bin/sh ./config.status
<Keybuk> lool: anyway, not a libtool bug
<Keybuk> replace SHELL=/bin/sh with SHELL=@SHELL@ in po-properties/Makefile.in.in
<lool> Keybuk: /usr/share/gettext/po/Makefile.in.in
<lool> SHELL = /bin/sh
<lool> Keybuk: And there are more examples
<lool> Keybuk: I raised this in my report
<calc> zul: ping
<lool> Keybuk: These makefiles are all awful, but I don't think there are the origin of the issue since we have these Makefile.in.ins since years
<lool> Keybuk: I described the same symptoms you listed here in my bug report BTW
<lool> doko: I upgraded to new xorg just fine; didn't cause any issue here; not sure what you had
<tedg> Keybuk: So can root get all the DBus session busses?
<pitti> asac: can you followup on bug 314778, since you already handled that before?
<ubottu> Launchpad bug 314778 in google-gadgets "Main inclusion for Google Gadgets" [Undecided,Incomplete] https://launchpad.net/bugs/314778
<asac> pitti: i am still fighting to get a go from upstream
<asac> its kind of a wierd situation. everybody say "usually we dont break ABI/API in security updates"
<asac> weird
<asac> but when you ask for a promiss/policy, it becomes hard
<asac> so far the only promise they have is to track XPCOM components
<asac> but i will poke around, hopefully getting a definite go or no by monday
<pitti> asac: I see; thanks
<kirkland> asac: hey, question about /etc/network/interfaces, i thought you might know ....
<kirkland> asac: is it possible to configure an interface to set it's wake-on-lan bit there?
<kirkland> asac: i'm currently hacking it with "ethtool -s eth0 wol g" in /etc/rc.local
<kirkland> asac: i'd like a more configurable way of setting this, and /etc/network/interfaces seems to be an ideal place for it
<kirkland> asac: thoughts?
<hyperair> kirkland: ethtool
<hyperair> oh whoops mentioned already
<hyperair> i should really read the entire scrollback before replying
<hyperair> kirkland: actually the wake-on-lan bit should be persistent once you set it once.
<kirkland> hyperair: no worries. i'd like to make that configuration stick
<hyperair> kirkland: why are you sticking it in ethtool?
<IntuitiveNipple> kirkland: I usually add such commands to a pre-up or up statement in interfaces
<hyperair> it should be tracked by.... erm... the card i think
<hyperair> and the BIOS
<hyperair> yeah
<hyperair> traditionally, you'd configure this only in the BIOS, but ethtool brought a way of configuring it within the OS
<kirkland> hyperair: hmm, i'll test again
<kirkland> hyperair: i had to do it in both bios and the os
<asac> kirkland: not that i know. if you use ifupdown you can use pre-post-up things maybe to hook your manually tweakage
<kirkland> asac: how hard/bad would it be to add a parser for "wakeonlan 1" / "wakeonlan 2" in /etc/network/interfaces?
<kirkland> asac: how hard/bad would it be to add a parser for "wakeonlan 1" / "wakeonlan 0" in /etc/network/interfaces?
<hyperair> asac: generally that gets called on boot too, so you don't have to use ifupdown
<kirkland> ie, toggle on/off there
<hyperair> kirkland: there probably wouldn't be a point in that, because it is _supposed_ to be persistent
<hyperair> it is on my hardware.
<asac> kirkland: are there other options from ethtool that one would want?
<asac> kirkland:  and yes, i am not really sure that this belongs to ifupdown; not sure where the best place to put such configuration would be though
<zul> calc: pong
<kirkland> asac: okay, fair enough
<kirkland> hyperair: let me check
<asac> kirkland: maybe even udev?
<asac> kirkland: technically it should be easy to add options like ethtool-OPTION <value>
<asac> but i dont think that we want it
<kirkland> asac: right.  let me make sure my request is even valid.  if that ethtool command is something you only have to run once, it shouldn't be something that we should have to worry about
<asac> kirkland: yeah. i think the question is if that config is really assocaiatede with a certain interface/connection configuration
<asac> if its not , then it has to be done somewhere else
<Keybuk> lool: yeah they are
<Keybuk> remember that Autoconf and libtool are designed to be portable
<Keybuk> that means they can't just use POSIX shell, since that's a relatively modern invention which most old-style UNIXes haven't adopted
<Keybuk> it turns out it's pretty near impossible to write shell that operates exactly the same
<Keybuk> at least, not useful shell
<Keybuk> so m4sh works by picking a shell, and coding to it
<Keybuk> it generally prefers bash, since bash behaves predictably
<Keybuk> so it then outputs, on your machine, all shell written for bash
<Keybuk> not for posix sh, not for sun sh, etc.
<Keybuk> that means that the value of $SHELL is kinda important
<kirkland> asac: wakeonlan is absolutely something that's associated with a given interface
<kirkland> asac: you send wakeonlan packets to a MAC address
<lool> Keybuk: So where does the regression come from?
<Keybuk> lool: the regression is caused by that Makefile doing something it shouldn't
<lool> Keybuk: Plenty of makefile.in.in do it
<Keybuk> (calling an Autoconf-generated script with something that's not the Autoconf-chosen SHELL)
<lool> Keybuk: gettext and intltool's are frequent examples
<Keybuk> yes, that doesn't mean it's write
<Keybuk> err, right
<Keybuk> I'd guess gettext did it wrong first
<Keybuk> and everybody copied that Makefile.in.in
<lool> Keybuk: I understand, but we can't simply drop support for all the Makefile.in.in in the tarballs currently available from download sites
<Keybuk> It's specifically wrong according to the Autoconf documentation
<asac> kirkland: yes. its assocaited to a given interface, but not to a given connection
<Keybuk> autoconf.info 11.9
<Keybuk> If you
<Keybuk> use Autoconf, do
<Keybuk>      SHELL = @SHELL@
<Keybuk>    Do not force `SHELL = /bin/sh' because that is not correct
<Keybuk> everywhere.
<asac> kirkland: think about the "mapping" feature of ifupdown ... you can have HOME and WORK connection for eth0 interface
<lool> Keybuk: I know, I even pointed it out in my report, but I can't fix all the released tarballs and tell all upstream to change the Makefile.in.in, therefore I think we should revert the change which expose this bug
<Keybuk> lool: I disagree
<lool> It's ok to raise the Makefile.in.in in parallel with the relevant upstreams, but will take long
<Keybuk> we should fix this bug
<lool> Keybuk: I don't intend to not fix it
<lool> I'm just saying it's the wrong thing to fix first
<Keybuk> when did you first notice the bug?
<asac> kirkland: also, does the interface need to be up to set wol?
<asac> kirkland: e.g does it work even if you ifconfig eth0 down first?
<lool> Keybuk: When I used the new autoconf with gtk+2.0
<Keybuk> "the new autoconf" ?
<Keybuk> what version of autoconf were you using before?
<lool> I don't know when it was that I built gtk+ from source in the past, and I expect it's not specific to gtk+
<kirkland> asac: i'm not sure;  i just assumed that ethtool would send an ioctl() of some kind to the device itself, and flag a bit on or off in the device
<lool> Did you try with intrepid's autoconf?  Does it expose the same bug?
<Keybuk> without knowing the time scale of when you first see the bug, it's impossible to identify any particular change
<Keybuk> I did this on intrepid, yes
<Keybuk> without knowing any more detail, I would say that all versions of autoconf since 2.50 would exhibit this
<Keybuk> as would all libtool 2.x versions
<lool> Keybuk: So you reproduced with pure intrepid?
<lool> Keybuk: I can't believe gtk+ would have been un-bootstrapable for that long, that doesn't seem possible; we routinely have to relibtoolize it for ubuntu upadtes
<Keybuk> lool: afaik, this is pure intrepid
<Keybuk>  *** 2.61-7ubuntu1 0
<Keybuk>         500 http://gb.archive.ubuntu.com intrepid/main Packages
<Keybuk>         100 /var/lib/dpkg/status
<pitti> ScottK: with your motu-release hat on, would you mind if I sync gtkperf from Debian to jaunty universe? I've been asked to get it into Ubuntu
<Keybuk> automake:
<Keybuk>  *** 1:1.10.1-3 0
<Keybuk>         500 http://gb.archive.ubuntu.com intrepid/main Packages
<Keybuk>         100 /var/lib/dpkg/status
<Keybuk> libtool:
<Keybuk>  *** 2.2.4-0ubuntu4 0
<Keybuk>         500 http://gb.archive.ubuntu.com intrepid/main Packages
<Keybuk>         100 /var/lib/dpkg/status
<lool> Keybuk: How come it doesn't break all autoreconfing of all tarballs using gettext or intltool?
<pitti> ScottK: do you want bug red tape for it?
<Keybuk> lool: well, that config.status rule would be very rarely invoked
<asac> kirkland: yeah. i really think the hook belong further down
<Keybuk> lool: or at least, it _should_ be very rarely invoked
<Keybuk> but it doesn't seem to be
<Keybuk> infact
<Keybuk> it's quite odd
<Keybuk> it seems to be expecting POTFILES to be a source to its own Makefile
<lool> Keybuk: This rules seems to be run on all builds since Makefile isn't generated by config.status
<Keybuk> yeah but that again should be the same as gettext
<lool> Keybuk: argh
<lool> Keybuk: AC_OUTPUT_COMMANDS is specific to gtk+2.0
<Keybuk> how do you mean?
<primes2h> pitti: Hi, this bug 259505 has been fixed upstream. Can I set it as "fix released" in upstream package in Launchpad?
<ubottu> Launchpad bug 259505 in gvfs "impossible to copy files with p (pipe) flag" [Medium,Triaged] https://launchpad.net/bugs/259505
<lool> Keybuk: I was searching for something specific to gtk+2.0 which would explain why all gettext wouldn't break
<lool> Keybuk: One thing which is clearly specific is this AC_OUTPUT_COMMANDS() in configure.in
<Keybuk> lool: well, on normal gettext you see this in config.status
<Keybuk> config.status: executing po-directories commands
<Keybuk> config.status: creating po/POTFILES
<Keybuk> config.status: creating po/Makefile
<pitti> primes2h: that'll happen automatically after a while, Launchpad updates the states according ot upstream changes
<Keybuk> ie. it makes po/Makefile
<Keybuk> GTK+ doesn't seem to do that
<primes2h> pitti: I know, but it has been fixed on 19 and still set as "New". Is it normal?
<pitti> primes2h: hm, that's not normal then
<pitti> primes2h: can you ask on launchpad-users@, or ping some launchpad guys on IRC?
<lool> Keybuk: It does, but doesn't output "creating"
<primes2h> pitti: what is the name of launchpad IRC channel?
<primes2h> please?
<Laney> are you kidding?
<pitti> primes2h: I'm not actually sure; usually the mailing list is okay
<Keybuk> lool: if it makes po-properties/Makefile - why does the Makefile rule to generate it get called at all?
<pitti> primes2h: or just file a bug against malone
<primes2h> pitti: ok, thanks.
<lool> Keybuk: I wonder; the only thing I can think of is POTFILES being generated later
<lool> But we'd see this with po/ as well
<kirkland> why do i have to hit ctrl-alt-f1 twice in Jaunty to get to my tty1?
<kirkland> when starting from gnome/X
<Keybuk> lool: weird
<kirkland> bryce: any idea?
<Keybuk> kirkland: probably consolekit
<Keybuk> lool: I've mailed the gettext people, btw
<kirkland> Keybuk: is this desired behavior?
<Keybuk> kirkland: no
<bryce> yes that's a consolekit bug
<Keybuk> lool: there's not really much we can do though, unless it's a specific patch that broke things
<Adri2000> Keybuk: did you try to apply my patch?
<kirkland> bryce: is it already reported, or should i do the duty?
<Keybuk> Adri2000: what patch?
<Adri2000> for MoM
<Keybuk> Adri2000: lp url?
<Adri2000> it's still borken
<bryce> kirkland: dunno, it's pretty well known though.  Probably could use additional investigation in any case
<Keybuk> lool: from what I can tell, this affects all current autoconf/libtool/etc.
<lool> Keybuk: Either other projects have been particularly lucky because of po/ being built last or it's gtk+2.0 specific in which case we're safe
<Keybuk> and is a direct side-effect of the way they write shell scripts
<Keybuk> lool: I think that it's gtk+ specific
<Adri2000> Keybuk: I gave it to you earlier and you answered "looks better"
<Adri2000> http://adrishost.net/~adri2000/ubuntu/MoM-comments.patch
<Keybuk> Adri2000: that was an incomplete patch to only one file, and I told you other changes that were needed
<lool> Keybuk: I want to believe it is, but can't understand where it goes wrong
<Adri2000> 13:40:43 <Keybuk> you need locking in get_comments
<Adri2000> 13:41:36 <Adri2000> why? it doesn't write anything, it just reads the file
<Adri2000> and?
<Keybuk> Adri2000: otherwise while reading, what happens if someone writes
<Keybuk> lool: to me, it's a bug that that Makefile rule gets called at all
<Keybuk> lool: it shouldn't - those kinds of rules are *only* for rebuild after editing auto* source scenarious
<Adri2000> Keybuk: everywhere something is written, the file is locked before. the get_comments() function only reads
<Keybuk> Adri2000: but get_comments() doesn't lock the file
<Keybuk> so while it's reading, something can write to the file
<Keybuk> and since you don't use atomic overwrite everywhere ...
<lool> Keybuk: Ah
<lool> Keybuk: after configure, po-properties doesn't have a POTFILES while po has!
<Keybuk> lool: ah!
<Keybuk> lool: that's probably a bug ;)
<Keybuk> I've just tested here btw, general gettext fails here too
<Keybuk> but it's quite hard to replicate
<Keybuk> ohhhhhhhhhhhhhhhh
<Keybuk> I've just realised why general gettext doesn't replicate this ;)
<Keybuk> gettext upstream only calls config.status with its own directory name
<Keybuk> so it only regenerates po/Makefile
<lool> Which is cleaner
<Keybuk> so it doesn't smash libtool
<lool> Keybuk: Ok, the po/POTFILES generation is in glib-gettext.m4, so it's specific to this implementation as well
<Keybuk> it's still a bug that SHELL is overwritten, but it minimises it
<Adri2000> Keybuk: so, if get_comments reads, and in the meantime something else writes. what happens? reading will fail?
<lool> Keybuk: I think we have a bunch of bugs to fix here; thanks for debugging!
<kirkland> Keybuk: bryce: thanks guys, i found the existing bug, Bug #271962
<ubottu> Launchpad bug 271962 in consolekit "VT-switching from X returns you to X the first time" [Medium,Confirmed] https://launchpad.net/bugs/271962
<Keybuk> lool: I'll follow up with the gettext guys upstream
<Keybuk> Adri2000: the fact you don't know what happens means you shouldn't tell me you don't need locking there <g>
<Adri2000> Keybuk: I *think* reading will work and that's all. you tell me it needs locking, so you need to tell me why :)
<Keybuk> no, I just need to tell you and not apply your patch until you add it <g>
<Adri2000> a priori, no locking is needed IMO. except if you can tell me it's needed because ...*
<Adri2000> -*
<Keybuk> what happens will be a bit random
<Keybuk> UNIX doesn't have per-session file images
<Keybuk> if two people open a file, one for reading, and one for writing
<Keybuk> the read() will return bits of the old file and bits of the new file
<Keybuk> the reader doesn't get an "old copy"
<ScottK> pitti: I don't mind gtkperf.  Since the main reason we stop allowing new packages is to stop burdening the archive-admins with New'ing them, if you're up for the New, there's no reason not to.
<pitti> ScottK: ok, thanks; I found an existing request for it and did it
<Keybuk> so you need to avoid concurrent writes and reads
<Keybuk> easiest way
<ScottK> pitti: OK.
<Keybuk> (whilst still allowing concurrent reads)
<Adri2000> Keybuk: I clearly understand that two people opening a file for writing will result in unexpected behaviors. I don't understand the same for one person reading and another writing. but... ok, with what you just said, I'll add a lock :)
<Keybuk> take out the reading lock with LOCK_SH
<Keybuk> take out the writing lock with LOCK_EX
<ScottK> LaserJock: I just skimmed the Edubuntu meeting.  I can tell you that my 5 year old absolutely loves Ktuberling.
<Keybuk> that way, someone writing will queue up behind someone reading
<Keybuk> while multiple people can read simultaneously
<LaserJock> ScottK: awesome, thanks
<Adri2000> Keybuk: okay
<Keybuk> Adri2000: well, take this for an example
<Keybuk> one process is using get_comments() as it exists currently
<Keybuk> and is reading lines from the file
<Keybuk> the merge-status.py runs
<Keybuk> and that opens the file for writing (truncating it to zero bytes)
<Keybuk> what happens to the process reading lines from that file?
<Adri2000> it will see nothing in the file
<Keybuk> but it's already read some of the file
<Keybuk> it may even be halfway through a line
<Keybuk> may not have reached the ":" yet
<Adri2000> I see
<Keybuk> suddenly it's off the end, and will return EOF
<Keybuk> that person may see an exception, because you don't handle the ":" being missing
<Keybuk> or that person will at best see incomplete comments
<Keybuk> maybe even the last comment cut in half
<Keybuk> clearly this is undesirable behaviour
<Adri2000> Keybuk: patch updated, available at the same place
<Adri2000> wait, I should add another LOCK_SH
<Adri2000> everything is locked now
<Adri2000> Keybuk: files open with r are LOCK_SH and files open with w or a are LOCK_EX. sounds good?
<Keybuk> yup
<Keybuk> pushed
<Keybuk> now we just need to figure out how to deal with .comments changing permissions
<lool> Keybuk: You have an upstream bug for gettext?
<Keybuk> gettext doesn't have a bug tracker
<Keybuk> it's a GNU project
<Keybuk> they use bug-* mailing lists
<Adri2000> Keybuk: my latest change has one more lock in manual/merge-status.py than what you committed
<lool> Keybuk: I wonder whether it should use something else than $(SHELL) in Makefile.in.in; SHELL is used for all subcommands, so it might wiser to simply call ./config.status, or use another var e.g. CONFIG_SHELL = @SHELL@
<Adri2000>      fcntl.lockf(file_comments, fcntl.LOCK_EX)
<Adri2000> and
<Adri2000>      fcntl.lockf(file_comments, fcntl.LOCK_SH)
<Adri2000>      fcntl.lockf(file_comments_new, fcntl.LOCK_EX)
<Adri2000> Keybuk: ^
<Keybuk> SHELL is guaranteed by Autoconf to be a POSIX-compatible shell
<Keybuk> that's kinda the point :p
<Keybuk> Adri2000: I've already applied the patch, if you want me to make any other changes, you need to supply a new patch
<Keybuk> Adri2000: no need to lock the "new" file
<Keybuk> you only use it when you have a lock on the old file
<Adri2000> I put lock everywhere now :P
<Keybuk> (arguably you should not open the new file until you have the lock on the old)
<Adri2000> hmm
<Adri2000> and the lock on file_comments (open for reading) should be LOCK_SH rather than LOCK_EX no?
<Keybuk> yes
<Adri2000> ok, let me a minute and I give you a new patch
<Keybuk> you should probably make comments_new be 666
<Keybuk> otherwise the web server can't write to it
<Adri2000> why would the web server write to it?
<Keybuk> addcomments.py
<Adri2000> adding a comment write directly to the comment file, it doesn't use a temporary "new" file
<Adri2000> writes*
<Keybuk> and how is it going to have permission to do that?
<Adri2000> hmm when mv foo bar. bar gets foo's permissions?
<Keybuk> yes
<Keybuk> that's my point
<Keybuk> when merge-status replaces the .comments file
<Keybuk> the new .comments will only be writable by the user merge-status runs as
<Keybuk> the web server runs as a different user
<Keybuk> so now addcomments.py can't write to the file
<hellocuckoo> Hi :)
<Adri2000> Keybuk: right
<hellocuckoo> hello, Im interested in Ubuntu development bu dunno where to start with my skill set... any1 there to help
<hellocuckoo> ?
<lool> Keybuk: What I'm saying is that SHELL in make is always set by make (at least in GNU make); if some commands rely on bash or /bin/sh and aren't compatible with the POSIX shell which configure selects (which might be e.g. zsh AFAIK), it might break random makefiles
<Keybuk> lool: god no!
<Keybuk> POSIX specifically forbids make from doing that
<Keybuk> GNU make leaves SHELL at whatever is set in the Makefile
<Keybuk> and if it's not set, uses /bin/sh
<Keybuk> and *does not* pick it up from the environment
<Keybuk> (so SHELL can never be zsh unless configure sets it that way)
<Adri2000> Keybuk: os.chmod is strange
<Keybuk> Adri2000: yeah, the API needs to be far more complicated than just a path and a mode
<Keybuk> you want fchmod() and fchown() anyway
<onnadi3> Hello all: is this the right channel to discuss ideas that were marked [IDEA] in the forums? I would like to contribute to one of them.
<Keybuk> Adri2000: but I don't think the python on casey has those
<Adri2000> Keybuk: I don't seem to have them either...
<hellocuckoo> hello, Im interested in Ubuntu development but dunno where to start with my skill set... any1 there to help ??
<directhex> hellocuckoo, depends on the skill set
<slangasek> so, which component of GNOME is responsible for parsing of .desktop files?
<hellocuckoo> i know java, html/css, PHP, Javascript and AJAX(learning)...... alittle C also.....
<hellocuckoo> good at using linux environment...bash and stuff.........im very eager to learn all tht stuff
<Adri2000> Keybuk: ah, actually os.chmod wants 0666 and not 666...
<Keybuk> yes, it's called Octal
<onnadi3> directhex: Hi. Do you know in which channel I can discuss possible additions to the ubuntu mouse preferences?
<mneptok> onnadi3: any reason you don't want to bring this GNOME?
<directhex> mneptok, thou shalt not make the mouse prefs useful
<directhex> mneptok, linus learnt that lesson when he sent patches
<mneptok> directhex: exactly, that's why i'm pointing him upstream ;)
<Adri2000> Keybuk: http://adrishost.net/~adri2000/ubuntu/MoM-comments-more-fixing.patch
<onnadi3> mneptok. Ah, I see. Well, I saw this thread in the ubuntuforums (http://ubuntuforums.org/showthread.php?t=410342) and thought some people here might be working on it
<onnadi3> directhex: what kinds of patches did linus send anyway? :)
<directhex> onnadi3, dunno, some mouse prefs stuff
<lool> Keybuk: That's exactly what I'm saying: SHELL is currently set to /bin/sh by make, and that might be bash; if we start adding SHELL = @SHELL@ in the Makefile it wont be the case anymore
<mneptok> onnadi3: ideas passed around on forums and never added as actual blueprints on LP have no chance of implementation.
<hellocuckoo> directhex: am intersted in packagin too, but dunno how.... and the biggest prob is my collg LAN has irc blocked so i can't connect to irc usually....
<mneptok> hellocuckoo: use an alternate port
<hellocuckoo> only http and ftp work bro....
<hellocuckoo> mneptok:
<onnadi3> mneptok: I see. Thanks. I'll swim upstream and see what they say there
<mneptok> hellocuckoo: no e-mail?
<mneptok> hellocuckoo: no https?
<hellocuckoo> mneptok: hav all tht, but not used to mailing lists and stuff..
<mneptok> hellocuckoo: connect to irc.freenode.net:8000
<hellocuckoo> mneptok: wat do u work on?
<mneptok> hellocuckoo: usually a chair and a flat surface, like a desk.
<bdmurray> tkamppeter: can bug 299011 be Fix Released?
<ubottu> Launchpad bug 299011 in hplip "hp-systray in HPLIP 2.8.10 completely broken: No Qt4 support, hpdio module missing" [Undecided,Confirmed] https://launchpad.net/bugs/299011
<hellocuckoo> mnetok: hahha.....wat team do u work with?? which software?
<mneptok> hellocuckoo: i'm an (almost) former Canonical support monkey
<hellocuckoo> mneptok: now?
<mneptok> hellocuckoo: as of Monday a MariaDB boilerman
<hellocuckoo> mneptok: so any advise where i shud start with?
<mneptok> hellocuckoo: if you aren't doing active development, it's probably best to keep this channel clear for such work. i recommend idling in #ubuntu-motu and getting a sense of how Universe works.
<Keybuk> lool: but that's ok
<Keybuk> lool: because whatever SHELL is set to by Autoconf will be the right thing
<Keybuk> /bin/sh might be the Solaris shell from hell
<directhex> Keybuk, /bin/sh is awesome. tab complete is for girls
<tkamppeter> bdmurray: Yes, bug 299011 is completely fixed with HPLIP 3.9.2. I have closed the bug now. I have posted an FFE for 3.9.2: bug 335116
<ubottu> Launchpad bug 299011 in hplip "hp-systray in HPLIP 2.8.10 completely broken: No Qt4 support, hpdio module missing" [Undecided,Confirmed] https://launchpad.net/bugs/299011
<ubottu> Launchpad bug 335116 in hplip "FFE Request: HPLIP 3.9.2 released one day after FF" [Undecided,New] https://launchpad.net/bugs/335116
<bdmurray> tkamppeter: also the next upload of cups will have the apport-hook that gathers printing info in it.  What other packages could use it?
<tkamppeter> bdmurray, I do not exactly know what the new apport hook does. pitti has added it. pitti, can you help bdmurray.
<bdmurray> tkamppeter: I wrote it pitti sponsored it.  It gathers the same info as the printingbuginfo script.  I'm curious what other packages would benefit from that information.
<Adri2000> Keybuk: now even the status pages themselves return internal server errors :/
<tkamppeter> bdmurray, Ghostscript, all foomatic-... packages and printer drivers.
<tkamppeter> bdmurray: They all get invoked by CUPS when executing a print job. So the error_log of CUPS helps also to debug all these packages.
<bdmurray> tkamppeter: okay, great thanks
<kirkland> hyperair: okay, i've tested it out ... that ethtool setting is not persistent across boots
<kirkland> hyperair: sudo ethtool eth0 | grep Wake-on:
<kirkland> hyperair: on a fresh boot, it's always "d"  (disabled)
<hyperair> how very strange
<kirkland> hyperair: i need to give it "g" to enable it
<kirkland> hyperair: it might be particular to this hardware
<kirkland> hyperair: but i've read elsewhere with people saying the same thing
<hyperair> i see
<hyperair> generally it's the bios which handles this =\
<jdong_> I don't think that is true
<jdong_> generally it is your OS's ACPI implementation that should handle it.
<jdong_> BIOS handling it should be "legacy"
<jdong_> for some silly misuse of the quoted term
<porter1> Hey, anyone know why on x86_64, lib32 doesn't directly name the libraries (e.g. libGLU.so.1 instead of libGLU.so)
<porter1> Is it to give x64 libs precdence?
<EtienneG> hey guys
<EtienneG> who do we poke when there is a -dbgsym missing on ddebs.u.c?
<Mr-Woof> #join ubuntu-bugs
<Mr-Woof> oops :)
<EtienneG> pitti, my man, are you the one we should go to about missing -dbgsym on ddebs?
<EtienneG> ha, /away
<EtienneG> I will catch on Monday then
<jdong_> EtienneG: missing or outdated?
<EtienneG> jdong_, missing
<jdong_> it kidna sucks that we dont get -updates and -security dbgsyms :(
<EtienneG> stunnel4 for i386 in hardy
<EtienneG> it is not from -update or -security
<jdong_> interesting
<slangasek> EtienneG: after the fact, there's not really a way to reconstitute the missing package short of doing another upload
<slangasek> and you can't upload to the release pocket anyway, so...
<EtienneG> slangasek, too bad then!  thanks for the info
<bdmurray> slangasek: should bug 332962 be about grub?
<ubottu> Launchpad bug 332962 in grub "Please provide talking accessible bootloader" [Wishlist,Triaged] https://launchpad.net/bugs/332962
<slangasek> bdmurray: that's where it's already assigned - are you suggesting it's mis-assigned?
<bdmurray> slangasek: I'm not suggesting, just wondering.
<slangasek> bdmurray: I have no idea if grub is what OpenSUSE is using as their talking bootloader.  I think it's unlikely that we would want to support two different bootloaders, so grub (or eventually grub2) is probably the right place for it
<tedg> Does Ubuntu Server have DBus?
<Nafallo> tedg: apt-get install...
<Nafallo> ;-)
<ogra> cjwatson, right and i guess before the first user would complain we'd have a new d-i build anyway
<Aquina> hy
<Aquina> Is there a check routing in the kernel or somewhere else within the installer to perform a small CPU and RAM check? I often whished that was included due to the fact I already had several issues with corrupt AMD CPUs caused by ESD/EMI issues.
<jdong_> Aquina: IMO the memtest and CD checksum items on the boot menu are for that purpose.
<jdong_> the memtest for short period of time even will catch most of the RAM-related problems that might cause you grief
<jdong_> and the CD checksum calculation should exercise the CPU a bit too
<Aquina> thx, jdong_
 * calc larts doko for uploading during freeze week :-\
<slangasek> calc: ?
<calc> slangasek: he uploaded OOo during the freeze i think because i wasn't going to upload it during the freeze just for a simple one line change
<calc> slangasek: i have a bunch of things queued up to change for the next upload which i will be doing early next week anyway
<calc> so it was just a waste of buildd time really :\
<ogra> well, they are idle most of the time during a freeze
<slangasek> I'm pretty sure the upload didn't happen during the milestone freeze
<RainCT> (and download time for users :))
<bdmurray> kirkland: is there a reason bug 313812 is private?
<ubottu> Bug 313812 on http://launchpad.net/bugs/313812 is private
<slangasek> calc: I see that the package was uploaded today, which isn't during the milestone freeze...
<slangasek> (setting aside the question of whether OOo should be uploaded for a one-liner change :)
<calc> slangasek: ah ok the changelog was from tue 24
<calc> i didn't know if it had just been queued during the freeze..
<kirkland> bdmurray: sort of ...
<kirkland> bdmurray: it came from the RH security team, and it was private on their end
 * calc is back to working on new OOo upload
<kirkland> bdmurray: we went a few rounds with them as to whether or not it should be considered a security vulnerability (I don't believe so --  it's just a function of the way keyrings work)
<bdmurray> kirkland: okay, thanks I was just curious
<slangasek> calc: queued yes, but on his side. :)
<kirkland> bdmurray: i'm okay with un-marking it private, but that should probably be cleared by jdstrand/kees/mdeslaur
<slangasek> kirkland: want to test out a pam change before I upload it, to see whether it regresses anything for ecryptfs
<slangasek> ?
<kirkland> slangasek: yes
 * kirkland is afraid already
<slangasek> kirkland: lp:~ubuntu-core-dev/pam/ubuntu
<kirkland> slangasek: I just replaced a few rungs on a stepladder... wanna climb to the top and make sure it still works?
 * Nafallo replaces kirkland's stepladder
<Nafallo> ;-)
<slangasek> kirkland: as long as you're standing below to break my fall ;)
<kirkland> slangasek: fair enough, sounds like a deal
 * kirkland building
#ubuntu-devel 2009-02-28
<slangasek> this may actually fix some of the ecryptfs pam bugs we have, I haven't checked yet
<slangasek> I know it fixes bug #303515, at least
<ubottu> Launchpad bug 303515 in pam "passwd indicates password updated although it wasn't" [Critical,Triaged] https://launchpad.net/bugs/303515
<kirkland> slangasek: nice, i'll test that
<kirkland> slangasek: that bug sounds like the core of the one we suffered from
<slangasek> yeah
<kirkland> long build
<kirkland> built; installing
<kirkland> slangasek: okay, normal login works, both server and desktop
<slangasek> with ecryptfs?
<kirkland> slangasek: yes, encrypted home directory
<slangasek> yay
<kirkland> slangasek: trying ssh now
<kirkland> slangasek: ssh login works
<kirkland> slangasek: trying password change
<kirkland> slangasek: successful password change works (rewraps ecryptfs password)
<kirkland> slangasek: empty password: rejected
<kirkland> slangasek: password too simple: reject (auth token manipulation error)
<kirkland> slangasek: current password wrong: rejected
<kirkland> slangasek: this looks *excellent*
<slangasek> ok, great :)
<slangasek> what are the other bug numbers I should stick in the changelog for this? :)
<kirkland> slangasek: grabbing that now
<kirkland> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/305882
<ubottu> Ubuntu bug 305882 in pam "ecryptfs private wrapped passphrase with wrong password during password change" [Undecided,New]
<slangasek> FWIW, upstream decided to simply not freeze the chain based on the results of the first pass - so this violates an expectation that's been true in Linux-PAM for a decade, but I haven't found a practical case yet where it matters
<kirkland> slangasek: well, the result is proper operation, at least in my little bit of testing
 * slangasek nods
<Adri2000> Keybuk: still internal server error...
<Baby> pitti: ping!
<Hobbsee> shiny jaunty!
<hyperair> Hobbsee: shiny indeed, but laggy for me T_T
<Hobbsee> hyperair: yeah, it seems like the xserver is having trouble again somewhere
<hyperair> Hobbsee: =(
<Hobbsee> and spontaneously explodes every once in a while, too
<hyperair> the fps dropped so far that i can play lunatic mode of this game where i could previously only play easy mode
<Hobbsee> oh dear!
<hyperair> yeh 60fps to 12 fps =(
<Hobbsee> nasty!
<hyperair> indeed
<hyperair> if i didn't get addicted to this game, i'd upgrade already. compiz still functions smoothly
<lool> Keybuk: Re: gettext doesn't have a bug tracker; what about http://savannah.gnu.org/bugs/?group=gettext ?
<arthur-> doko: /query
<lidaobing> hello, I need freeze exception for bug 335796
<ubottu> Launchpad bug 335796 in qterm "Please sync qterm 1:0.5.4-2 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/335796
<lidaobing> with out this sync, qterm will always crash under QT 4.5
<lidaobing> thanks
<ogra> hmm, should i still see powernowd and hotkey-setup in my bootchart ? i thought we removed both
 * RainCT rebuilds compizconfig-python for 2.5 + 2.6
<fargiolas_> hi I need some quick help for a friend pc I'm trying to boot. It somewhat has a corrupted mbr that prevents him to run windows. I tried several live cds telling them to boot from the first disk but it doesn't work. I tried to boot with grub from floppy and nothing. The only way to boot windows correctly is to run Ubuntu Intrpid live cd and select Boot from first disk. It boots windows flawlessly. So does anybo
<fargiolas_> dy know which command does it run? is it possibile to reproduce it from grub?
<ScottK> fargiolas_: #ubuntu for help.
<fargiolas_> ScottK, I really doubt it is a support question. I need to know from a ubuntu developer *what* boot from the first cd exactly does
<beuno> fargiolas_, that still makes it a support question
 * fargiolas_ tries at with #ubuntu
<fargiolas_> beuno, probably but I don't think anyone there has the knowledge to give me an answer
<fargiolas_> beuno, as I suspected they try to help me to solve my problem but nobody really knows what that live cd menu entry does
<beuno> fargiolas_, well, people who hang out here explicetly only want to talk about Ubuntu development, so trying to get an answer out of them just because they can isn't very polite
<fargiolas_> beuno, sure but I think only here there is someone who might know the answer, ideally the livecd developer would be the right guy to ask
<beuno> fargiolas_, still not the right thing to do
 * pochu points fargiolas_ to /topic
<IntuitiveNipple> fargiolas_: The CD isolinux code does the same that grub would. Loads the boot sector from the partition that contains Windows and hands off control to it.
<fargiolas_> IntuitiveNipple, apparently not because I tried booting windows from a grub floppy and it hangs while the live cd can boot it
 * Chipzz helps pochu by pointing fargiolas_ to the topic
<fargiolas_> Chipzz, pochu, I'm asking here just because I think people who knows the answer might hang in this channel
<Chipzz> fargiolas_: and we're saying: "ask elsewhere" because 16:42 < beuno> fargiolas_, well, people who hang out here explicetly only want to talk about Ubuntu development, so trying to get an answer out of them just because they can isn't very polite
<fargiolas_> Chipzz, pochu, If you know any other channel where I can find "them" just tell me and I'll be glad to stop my OT question
<pochu> fargiolas_: google.com
<fargiolas_> pochu, ok thanks
<Chipzz> or you could try #ubuntu-server
 * Chipzz wonders why people just HAVE TO insist on getting help here DESPITE being EXPLICITELY pointed out that this is NOT a support channel
<fargiolas_> Chipzz, I'm sorry if I insisted and paused your development work thanks I'll see if google can be more helpful
<Chipzz> fargiolas_: everyone makes mistakes; but if ppl point those out to you, don't keep making them
<Chipzz> and the above comment was not just targeted at you
<fargiolas_> Chipzz, my only mistake was believing that here there were people with the right knowledge and an helpful mood but apparently netiquettes are more important
<cjwatson> boot from first hard disk just chains to BIOS disk 0x80
<cjwatson> FWIW
<fargiolas_> cjwatson, any idea why doing the same from grub doesn't have the same effect?
<Chipzz> fargiolas_: IMO the point is very simple: like beuno pointed out, ppl are in this channel because they are interested in ubuntu development. not because they are interested in giving support. if they were interested in giving support, they would be in, say, #ubuntu
<cjwatson> my only guess is that with grub you might need to use the 'map' command to adjust its view of the world
<Chipzz> IMO this has nothing to do with netiquette
<Chipzz> and if you want to talk about netiquette: reading the topic of a channel is also part of netiquette
<fargiolas_> Chipzz, I'm not interested in continuing this discussion anymore.. your point about ubuntu development is just the reason because I asked here; I needed an ubuntu developer
<fargiolas_> btw I have no more battery :P so I'm forced to go anyway :) sorry again if I seemed unpolite
<fargiolas_> cjwatson, thanks I'll try with map
<Chipzz> fargiolas_: as an aside, I pointed you to #ubuntu-server . Why didn't you join there yet? Most likely, the ppl there *are* willing to help you
<cjwatson> Chipzz: I think there is little to be gained from you continuing to go at the guy with a great big mallet
<Chipzz> cjwatson: that last comment was actually meant in a helpfull way
<cjwatson> I am the person who added the option in question to our syslinux configuration, and I've already answered here, so ...
<cjwatson> I suppose I could go and catch up on #ubuntu-server but there seems little to gain
<fargiolas_> Chipzz, I'll see if I can connect to irc with the faulty computer my battery is really low now :P
<fargiolas_> cjwatson, I'll try to install syslinux into a floppy
<BUGabundo> ogasawara: ping
<BUGabundo> did any Intel drivers got changed in the last kernel update?
<BUGabundo> I'm getting a few wfi 4965 disconnects, that didn't used to happened, and asac mentioned it should be drivers, not NM
<Micksa> hopefully this is a quickie... if you have an x86_64 on which you want to be able to cross-compile to i386, what's the simplest way to get a cross-compile toolchain installed?
<IntuitiveNipple> Micksa: Will this help? http://tjworld.net/wiki/Linux/Ubuntu/Packages/CreatingPbuilderVariations#Cross-compilingarchitectureproblems
<Micksa> not on its own no
<Micksa> I actually want to cross-compile to a different arch :)
<Micksa> for now I'm trying to see how other people build cross toolchains
<Micksa> I figured that would be a common case
<Micksa> someone should secretly patch make to go through a target's dependencies in reverse order
<Micksa> so that all the world's broken makefiles are revealed
<cjwatson> make -j is a pretty good way to expose that kind of thing
<Micksa> not reliable
<Micksa> that's my point
<whiten0ise> is someone already working on an "Ubuntu Messenger"
<whiten0ise> i was thinking about reworking Pidgin as a project
<whiten0ise> and kind of giving Ubuntu a MSN Messenger-like thing.
<highvoltage> whiten0ise: I think the long-term plan is to adopt empathy from gnome
<whiten0ise> ah
<whiten0ise> so hacking on pidgin would be a waste of my time
<IntuitiveNipple> whiten0ise: This might be useful https://wiki.ubuntu.com/EmpathyVsPidginUsability
<whiten0ise> wow
<whiten0ise> empathy has no file transfer capability.
<whiten0ise> it seems to me from reading that that its still pretty up in the air which one will be used
<whiten0ise> whichever one gets the manpower going to fix their prog up will get the spot
<jcastro_> empathy can do zeroconf file transfers now (not sure if that support is built in the ubuntu package) and they're working on the other protocols
<sjoerd> jcastro_, whiten0ise: xmpp filetransfer should be available in the next week or two
<jcastro> ah very nice!
<pizzach> hello peoples!
 * Tm_T hides
 * pizzach sniffs his own underpit
<pizzach> do people here develop things?
<pizzach> ;-)
<pizzach> I have been trying to bring better ubuntu support for my program gWaei.  The deb scripting eludes me though
<pizzach> It always errors
<pizzach> but it does install
<pizzach> :-/  That is probably why only source based distros are including it with their package managers
<pizzach> It doesn't help that I only run Ubuntu in a virtual environment on an old computer either
<IntuitiveNipple> pizzach: what do you need?
<pizzach> I was wondering if I could get someone more experienced with debs to help me out
<pizzach> tell me if I am going about it right
<pizzach> it's only around ~7 lines
<pizzach> or maybe a tip on a good deb scripting tutorial?
<Spads> pizzach: https://wiki.ubuntu.com/MOTU/School seems to have some good resources for getting started.  there are also some MOTU-related channels where you may be able to get more ready advice.
<geser> !packaging guide
<ubottu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
<geser> pizzach: something like this ^^ ?
<pizzach> thanks guys
<alex_joni> short question.. if I build some packages to put in a custom repo, where should I put the foo.changes file so that the Update Manager sees them?
<cjwatson> alex_joni: unfortunately changelog display in update-manager (or indeed in just about anything else) is not generalised
<cjwatson> alex_joni: look at /usr/lib/python2.5/site-packages/UpdateManager/Core/MyCache.py and you'll see what I mean
<alex_joni> cjwatson: cool, thanks for the pointer
<alex_joni> only have MetaRelease.py there..
<IntuitiveNipple> I posted a patch to grab changelogs from PPAs some time ago, but it is hardy ideal
<alex_joni> this isn't a PPA.. it's a custom repo I built with apt-ftparchive
<cjwatson> alex_joni: well, ok, it just hardcodes changelogs.ubuntu.com right now - there is no metadata in the Release file to point to a location for all the changelogs, which is what's really needed
<IntuitiveNipple> alex_joni: The same general approach would be required. As cjwatson says, it needs metadata
<alex_joni> ah, I see.. so if I have another entry in my /etc/apt/sources.list or in sources.list.d/ then there's no way for a stock hardy to grab the changelog
<cjwatson> alex_joni: the .changes file is not sufficient because it only contains information from one upload (possibly more if you use dpkg-genchanges -v, but in any case the user needs to see the set of changes from whatever they have installed, so you need a complete tree of all extracted changes)
<cjwatson> that's right
<alex_joni> ok, at least I won't bother trying to copy the .changes to different locations and see if it works :)
<cjwatson> obviously you can extract changelogs from the .debs themselves after downloading them, which is what apt-listchanges does, but that doesn't let you see the changelog entries up-front
<alex_joni> cjwatson: it's not that important atm
<alex_joni> it would have been nice, but I understand that it's not a trivial change/fix
<alex_joni> especially since we still have dapper users :)
<calc> i keep noticing that it appears that the x server crashes either on suspend/resume when i bring it back up i have to log back into gdm and no apps are running any longer
<calc> bryce: i have a intel mobile 4 series (4500 i think)
<calc> bryce: its in a thinkpad x200
<beuno> calc, same here with an intel GM965
<beuno> and it has also crashed once or twice while actually working
<kirkland> hyperair: aha ...  in fact, i'm suffering from https://bugs.edge.launchpad.net/ubuntu/+source/sysvinit/+bug/71418
<ubottu> Ubuntu bug 71418 in sysvinit "/etc/init.d/(halt|reboot) disables WoL" [Low,Confirmed]
<beuno> I'm on those dell m1330
<fargiolas> cjwatson: hi, I'd like to thank you, your hint solved my problem... it was exactly the information I was looking for. Setting up a boot disk with syslinux and localboot 0x80 worked like charm
<fargiolas> as a side note this confirms that I was right to look here for that information
<calc> beuno: is there a bug open about the issue already?
<beuno> fargiolas, annoying everybody at your own benefit is hardly being right
<beuno> calc, I haven't found one, or even managed to find anything interesting in the logs to give me a hint of where the problem is
<fargiolas> beuno: I didn't annoyed anyone you could have just said nothing, cjwatson would have told me what I was looking for and everybody would have been happy...
<fargiolas> beuno: all the discussion was pointless and annoying for me too
<beuno> fargiolas, and you could learn to read the topic and respect others  ;)
<fargiolas> beuno: :) I respect you and the topic but going OT for just a little sometime is not so bad if it can be helpful for other people
<beuno> like yourself
<beuno> whatever
<fargiolas> beuno: I needed help this time, but you could need help in the future
<beuno> and I will ask in the appropriate placs
<beuno> *places
<fargiolas> i'm pretty sure you will ask where you know there is someone able to answer... I asked on #ubuntu too and I got pointless suggestions while here I got what I was looking for :)
<fargiolas> btw, don't you have something like #ubuntu-hackers, a generalist channel where ubuntu devs hang with no strict topic rules
<fargiolas> ?
<calc> fargiolas: for questions like that which require someone know what they are actually doing asking on one of the mailing lists might work about as well as asking here
 * calc agrees asking for highly technical things on #ubuntu might not always get a good answer, especially due to the sheer volume of traffic
<calc> i am in the channel but can rarely follow things in it since it scrolls by so quickly
<fargiolas> calc: exactly it's not the first time that I ask something technical on #ubuntu and I get standard unuseful responses.. I would have asked on a mailinglist but I was trying to solve the issue of a friend so it was worth a try here for a quick response
<rgreening> ScottK, vorian, NCommander, Riddell, nixternal, seele, smarter, stgraber, Tonio_: Here's my MOTU application. Please feel free to provide comments... ty in advance. https://wiki.ubuntu.com/rgreening/DeveloperApplicationMOTU
<stgraber> rgreening: here you go
<rgreening> ty sir :)
<BUGabundo> cjwatson: ping
<BUGabundo> bug 336028
<ubottu> Launchpad bug 336028 in bootchart "bootchart: using nostop, no chart is generated" [Undecided,New] https://launchpad.net/bugs/336028
<BUGabundo> wrong dev
<BUGabundo> Scott Remnant LOL
<BUGabundo> too many ppl touch bootchart
<IntuitiveNipple> Surely you have to manually stop the process to get the chart? sudo /etc/init.d/stop-bootchart start
<BUGabundo> did nothing for my system
<BUGabundo> no bootchart was generated today
<IntuitiveNipple> ahhh, of course, it can't stop itself lol
<IntuitiveNipple> It needs a minor patch
<cjwatson> fargiolas: while I'm glad that your problem is fixed, your response "this confirms that I was right" is likely to cause me not to answer in future, I'm afraid; we really do very strongly prefer this not to be a support channel and I would please ask you to respect that in future. There are other non-IRC avenues of support if #ubuntu fails
<Hobbsee> cjwatson: This is a long shot, but do you know if unattended-upgrades is supposed to work with proposed?  It currently doesn't, and i'm not sure if that's a design decision, or a bug.  If it's a design decision, then I won't look into trying to fix it.
<cjwatson> Hobbsee: not something I've looked into; I would expect it to be configurable but off by default
<cjwatson> but I don't know that code at all
<Hobbsee> cjwatson: OK.  (that's what I thought too, then discovered i'd either done it wrong, or it doesn't work).  Thanks
<cjwatson> I could understand it being a design decision, on the basis of "you should take an informed decision on each thing in -proposed", but don't know for sure
<Hobbsee> mmm, indeed.
<Hobbsee> mvo's on leave, i take it?
<cjwatson> Hobbsee: there seems to be an Unattended-Upgrade::Allowed-Origins configuration entry
<cjwatson> I think he was just taking a long weekend
<cjwatson> at any rate, it seems to me that it would be fairly difficult to write unattended-upgrades such that you couldn't make it work with -proposed fairly easily :-)
<Hobbsee> well, that's what I thought.  That's what I was using, and it doesn't work ;)
 * Hobbsee will go digging
<cjwatson> fargiolas: I answered since it was the weekend and it was either that or change nappies :-)
#ubuntu-devel 2009-03-01
 * Chipzz feels a very strong urge to break the CoC wrt fargiolas
<Chipzz> *bleep* *bleep* *bleeeeeeeeep*
<cjwatson> Chipzz: I would appreciate it if you put an end to your comments on the subject here
<Chipzz> cjwatson: ^^^ I censored myself :)
<cjwatson> I responded because I was addressed. You were not
<Aquina> hy
<ScottK> I wish if someone were going to do a complete giveback of all the build failures in the archive (I think that's what's happened) they'd have given some warning.  I certainly wouldn't have spent all the time over the last 3 week carefully picking through for retries worth doing.
<ScottK> If LP is at all right this'll take two weeks to build out.
<wgrant> ScottK: Keep in mind that lots of stuff will likely fail early.
<ScottK> True.
<ScottK> I realize it'll likely be much less.
<wgrant> And hppa and sparc are special.
<ScottK> Actually I think most of what's there will fail.  I wasn't kidding about spending the last 3 weeks going through failures looking for stuff to retry.
<ScottK> Just finished today.
<wgrant> Oh wow. That's a lot of queued builds...
<ScottK> Yes.  It's a retry on every single FTBFS for Jaunty.
<directhex> any way to abort the attempted rebuilds?
<wgrant> Not without SQL access.
<bluefoxicy> is it possible to package VirtualBox OSE on Ubuntu CDs such that they run from INSIDE WINDOWS when you pop them in?
<ScottK> https://launchpad.net/ubuntu/jaunty/+builds?build_text=&build_state=failed doesn't know about a FTBFS more than ~1 hour old.
<bluefoxicy> seeing as QT is GPL now
<directhex> bluefoxicy, not sensibly. need drivers & reboots to install virtualbox on windows
<ScottK> bluefoxicy: Qt has been GPL for year.
<ScottK> years even.
<bluefoxicy> scottK:  It's always had a restrictive Windows license
<ScottK> bluefoxicy: How is that even possible.
<bluefoxicy> Well, a commercial entity controlled Qt
<ScottK> It can't be GPL unless you run Windows.
<ScottK> That's not GPL.
<bluefoxicy> so they published the Linux version as GPL, and patched it to run on Windows but only distributed binaries of that, under a restrictive license
<ScottK> I suspect what you're thinking of is it's now LGPL.
<bluefoxicy> possibly
<ScottK> I don't think so.
<bluefoxicy> my brain may be busted.
<ScottK> You can run KDE on Windows with no problem.
<bluefoxicy> I know the Linux version had a different license
<directhex> ScottK, the qt3 license certainly used to be gpl-or-proprietary, with the windows port only available as proprietary. there were efforts to port the gpl version, but they, erm, sucked
<ScottK> OK.  Qt3 is not been developed in a long time.
<directhex> didn't say it was. just sayin'...
<ScottK> For Qt3 I think you're correct.
<bluefoxicy> directhex:  also there's lots of install-and-run software (openoffice) on the Ubuntu CDs
<bluefoxicy> wouldn't installing a driver fall under install-and-run?
<ScottK> Licensing for Qt3 hasn't changed.
<bluefoxicy> and preconfigure the installed VBox to have a "boot LiveCD with 384M RAM" option
<ScottK> Licensing for Qt4.4 hasn't changed either.  LGPL is only Qt4.5.
 * ScottK isn't kidding about being disheartened about a couple of dozen hours of work over the last several weeks turning out to be totally unnecessary.
<directhex> the blanket rebuild must've been queued y someone who doesn't pay their server power bills
<ScottK> This does cause some actual problems for how we'd planned on doing the KDE 4.2.1 upload next week.
<ScottK> Urgh.
<ScottK> So far 2 successes, 252 failures.
<directhex> ScottK, totally worthwhile!
<wgrant> ScottK: How do you calculate that?
<wgrant> There's no way to sort builds lists, AFAICT.
<wgrant> Ah, through +history?
<ScottK> https://launchpad.net/ubuntu/jaunty/+builds?build_text=&build_state=built and python-cjson was a fresh upload.
<ScottK> Any success after that is the retries
<Aquina> Short westion: Where are these outputs on system startup generated? I wanna modify them.
<ScottK> And then all of https://launchpad.net/ubuntu/jaunty/+builds?build_text=&build_state=failed are from the retries
<wgrant> There's nothing after that.
<wgrant> Oh. WTF.
<wgrant> Why does it sort differently depending on the filter?
<Aquina> (posted in #ubuntu before): Someone knows where the usplash messages come from? I removed the parameter "quiet" from defoptions ind menu.lst. I searched through all the /etc/init.d/ scripts but couldnt find these messages printed. Search engines didn't help. Please do you...
<wgrant> Compare state=built and state=all.
<ScottK> It's interesting that the time sort isn't correct.
<wgrant> Which time sort?
<wgrant> AFAICT for state != all, the key is start time.
<wgrant> For state == all, the key is queue time.
<wgrant> (I think)(
<ScottK> The failed ones were not entirely in time sequence
<ScottK> All doesn't seem to show failures.
<ScottK> Ah.  That'd make sort of sense.
<wgrant> I think it does.
<wgrant> But nothing queued recently has failed.
<ScottK> BTW, every one of the build failures will land in one or two inboxes too.
<wgrant> Oh yes, I know this well.
<ScottK> I wonder if this is revenge for me filing a bug about notification of translations success spamming my inbox.
<StevenK> I seriously doubt that
 * ScottK was kidding
<wgrant> Even I have to doubt that :P
<ScottK> StevenK: Do you know why this was done?
<wgrant> Mass-givebacks happen.
<StevenK> What wgrant said
<wgrant> Frequently.
<ScottK> BTW, I was looking at the failures wrong.  They are sorted by fail time.
<StevenK> Mass-givebacks are done at points throughout the cycle
 * wgrant likes how the distribution build failure list is preceded by empty build records created by the unembargoing process.
<mluser-home> Anyone know how I can disable pulseaudio system wide?
<wgrant> mluser-home: This is not the correct channel.
<mluser-home> wgrant: sorry
<wgrant> You want #ubuntu, or to realise that you don't want to disable PulseAudio system wide.
<mluser-home> I'm having this problem in Jaunty, and I thought #ubuntu was just for hardy and intrepid
<wgrant> #ubuntu+1, then.
<mluser-home> wgrant: thanks again
<wgrant> np
<calc> bryce: i don't think bug 322202 is UXA specifc
<ubottu> Launchpad bug 322202 in xserver-xorg-video-intel "[UXA] Session lost on resume from sleep in Jaunty on Lenovo T500" [Unknown,Confirmed] https://launchpad.net/bugs/322202
<jdong_> installer gods: We should have a brown-and-orange color scheme for the alt installer :)
<LaserJock> heck yeah
<jdong_> dear virtualbox: Please stop turning green when I resize you.
<jdong_> whee relabel ahoy
<Codd> I just installed jaunty Alpha 5 on my machine (clean install) and I'm noticing that every once in a while cpu usage spikes for just a second and everything locks up (GUI, background tasks,mp3 playing, video, downloads) and then it all returns to normal.  If I load a complex ajax page in firefox the cpu still goes upto 99% but I don't get a lock up,   Right now it seems to occur when I play media files (xvid, mp3) I formatted usin
<dtchen_> Codd: if the symptom is persistent when playing/recording audio, there's a known issue in the current jaunty pulseaudio package causing the daemon to spin in a tight loop due to bogus data being passed from the sound driver. it has been fixed in a bzr branch and will land in the next upload.
<Codd> dtchen_: sweet it does look like pulseaudio is bouncing around alot in top, I guess since the system was freezing up I didn't see it peak :)  I'm loving the new release though, keep up the amazing work!
<calc> anyone know of an easy way to determine how much space on a disk a certain file type is taking up?
<calc> eg all jpg's, etc
<Hobbsee> calc: du?
<Hobbsee> calc: looks like you want du, -c, and probably a few other switches
<calc> i found a script that does it with find and awk
<calc> just have to determine how to make it work with spaces in filenames :\
<calc> resetting IFS seems to break it too much
<calc> cool -print0 and xargs -0 is your friend :)
<maco> calc: for dealing with odd characters in filenames: http://calypso.tux.org/pipermail/novalug/2009-February/017524.html
 * jdong_ thinks one should not be scripting in such ambiguous languages anyway :)
<maco> also, anyone using the sidebar for firefox?
<jdong_> anything accepting user input that doesn't take explicit typed-list style arguments is broken for today's environment.
<maco> the all-in-one sidebar?
<TheMuso> c
<jdong_> Open Mailbox ('?' for list):
<maco> ah sorry thought i was in #ubuntu+1 before
<fargiolas> cjwatson: I usually don't ask for support here. it was a particular case where I needed to know a thing that only the involved ubuntu developer could know so I asked here. I could have probably found the answer myself but I was tired after hours fighting with a broken windows installation and not able to concentrate anymore, this could also explain why I may have seemed unpolite.
<fargiolas> cjwatson: also I still believe it was not a support question. It was more a question about an ubuntu-specific implementation detail. I'm really sorry I was OT here.. I did it in good faith.
<cjwatson> let's call an end to it :)
 * cjwatson doesn't really want to continue the argument
<fargiolas> cjwatson: me neither :)
<savvas> hi, which is the default administration group? adm?
<ogra> savvas, adm is used for access to logfiles only
<savvas> ah thanks
<ogra> if you mean the group that has sudo access by default, thats "admin"
<savvas> that's it :)
<RainCT> doko: Thanks for the tip. I tried to fix that yesterday but didn't get it to work (each build takes half an hour..)
<Hobbsee> kirkland: found you a bug.  it's your lucky day!
<StevenK> doko: Want to commit/push your changes to launchpad-integration into bzr?
<RainCT> Why does notify-osd leave space for an image when there isn't one?
<RainCT> the bubble is already small enough as to waste more space like this
<kirkland> Hobbsee: ping
<kirkland> Hobbsee: Could you try editing /usr/share/screen-profiles/profiles/ubuntu-black
<kirkland> and changing "~" to "$HOME", and see if that works?
<kirkland> Hobbsee: If so, this is a very easy fix...
<ion_> dpkg dependencies donât allow one to depend on (ruby1.8, libjson-ruby1.8) OR ruby1.9, do they?
<directhex> you could work around that with a metapackage
<directhex> i.e. myapp-ruby1.8 | ruby1.9, where myapp-ruby1.8 has no contents & only a dep on ruby1.8, libjson-ruby1.8
<directhex> or wouldn't a dep on libjson-ruby1.8 pull in ruby1.8?
<ion_> Nope, only libruby1.8, which doesnât include the binary.
<ilowe> Do Ubuntu devs prefer to receive new packages into Ubuntu or should they go upstream to the Debian repos first?
<directhex> ilowe, generally, the latter
<ilowe> directhex: thanks; so I should follow the procedure to get the package accepted into Debian and it will just get pulled down into Ubuntu (in theory at some point in the future)?
<directhex> ilowe, that's the best way for everyone - so debian & debian-based dists also gain from your work
<directhex> ilowe, but delays can sometimes make it a sucky route
<ilowe> Cool, thanks. I'll start with that and see how the delays go :)
<directhex> ilowe, given where we are now, you have about 5 months for automatic syncing into ubuntu 9.10
<ilowe> yikes....it's more an issue of having the package available on my own systems; I guess I'll keep it in my local repos while it makes it's way into Ubuntu
<directhex> ilowe, yes, that can work - the ubuntu PPA system allows you to build a personal repo available to everyone
<ilowe> hmmm... then, would I propose to Debian *and* upload to a PPA? In which case would I just abandon the package in the PPA once it reaches Ubuntu?
<ScottK> Since we're past feature freeze for 9.04 working through Debian now won't actually make it take longer.
<ilowe> ScottK: I'm more trying to get a handle on how the repos get updated; not to worried about official releases
<directhex> ScottK, right now, i don't know whether i'd agree. NEW is... taking its time. assuming no delays getting as far as NEW
<ScottK> directhex: It's also just after a release in Debian, so no suprise.
<ScottK> ilowe: If you get your package into Debian it will automatically come into Ubuntu in the next release.
<slytherin> are daily iso builds for ports architectures turned off?
<Nafallo> I believe so yes.
<slytherin> Nafallo: any particular reason?
<ScottK> Yes.
<Nafallo> slytherin: ports.ubuntu.com have been struggling a bit.
<slytherin> oh
<ScottK> There was a locking problem that caused all CD builds to fail.
<ScottK> So they had to turn off ports.
<slytherin> ScottK: thanks for info
<ilowe> http://tinyurl.com/dkrvw7 states that the original package name should be <pkg>-<ver> but the resulting name should be <pkg>_<ver>; if I maintain the upstream as well, should I be naming my package <pkg>-<ver> and updating it in the .deb or can I name it <pkg>_<ver>? dh_make chokes on the "_" version when doing the initial debianization
<geser> ilowe: the upstream tarball should unpack to <pkgname>-<upstreamversion>
<ilowe> geser: thanks
<geser> and the tarball itself has to be named <pkgname>_<upstreamversion>.orig.tar.gz
<ilowe> OK, but that will get generated by dh_make? I have a proper <pkg>-<ver>.tar.gz file.
<geser> the _ is used as separator in package files
<geser> ilowe: dh_make will make then a symlink to your <pkg>-<ver>.tar.gz
<ilowe> cool, thanks
<Notch-1> hi, since i made a loop/raid root filesystem the hibernation stopped working, any idea on where to put loop/raid information to properly restore the system?
<NCommander> hey all
<jpds> Hey NCommander.
<NCommander> hey jpds
 * NCommander has just upgraded his VAIO :-)
<RainCT> NCommander: upgraded = to Jaunty?
<NCommander> RainCT, no, hardware
<RainCT> ah
<NCommander> Total of 4GB, and a half a TB of disk space :-)
 * NCommander is waiting for Xubuntu 9.04 A5 to download 
<RainCT> nice :)
<NCommander> Yup
<hunger> Is there a trick to get fglrx running in jaunty?
<stgraber> hunger: no trick, you just need to wait.
<hunger> stgraber: Would have been nice to mention that in the release notes of alpha5.
<stgraber> "A new XServer, version 1.6, is included in Alpha 4. The binary proprietary fglrx driver is not yet supported for this server and will exhibit various serious issues if run against it. Users of this driver are encouraged to wait or to switch to the open source -ati driver in the meantime. 313027"
<stgraber> from the release notes for alpha-5
<stgraber> http://www.ubuntu.com/testing/jaunty/alpha5#Known%20issues
<hunger> stgraber: Hmmm... you are right. I read the kubuntu release notes. They do not mention this little fact.
<DetlefvomBahnhof> hallo
<ia> hello. Have someone (from developers) clashed with this bug - https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/335953 ? I asking about it, because would like, that someone from developers check this bug; I think, that problems in interfaces of apps - one of valuable and primary issues, that should be fixed (cause interface - it's a face of distro)
<ubottu> Ubuntu bug 335953 in gnome-power-manager "icons and controls in quit/logout dialog unthemed" [Undecided,New]
<cjwatson> ion_: apply boolean logic. (ruby1.8, libjson-ruby1.8) | ruby1.9 -> ruby1.8 | ruby1.9, libjson-ruby1.8 | ruby1.9
#ubuntu-devel 2010-03-01
<tlp> should hald be running (or even installed) on lucid?
<persia> tlp: Depends on what else is installed.  pitivi is one of the packages that seems a current common candidate.
<tlp> ah
<tlp> that would probably be it, then
<zgreg> hi.
<zgreg> what's the right way to get a package updated in ubuntu?
<zgreg> just file a bug about it in launchpad?
<lifeless> doing the update yourself is a much more reliable way to make it happen
<zgreg> how so? I'm not maintaining the package for debian or ubuntu.
<zgreg> I'm the author of the software though and I'd like to have it integrated into lucid if possible as the new version includes important bugfixes
<crimsun> zgreg: https://wiki.ubuntu.com/FreezeExceptionProcess#Exceptions for Universe/Multiverse
<zgreg> crimsun: thanks
<ebroder> Where does the definition of the Vcs-* debian/control fields come from? I know it's not actually in policy...
<AnAnt> Hello, is xsplash still used in lucid ?
<AnAnt> or plymouth replaces it too ?
<RAOF> Is there a way in an apport hook to attempt to escalate to root privileges?
<nigelb> RAOF: I believe there is
<RAOF> nigelb: You wouldn't happen to know what it is?
<RAOF> :)
<nigelb> RAOF: gimme a minute.  after a week of hacking, I have the notes somwhere
<nigelb> RAOF: root_command_output(command, input=None, stderr=-2)
<nigelb> I suggest using *python -c 'import apport.hookutils; help(apport.hookutils)'* when you want to look for some feature.  Helped me a great deal :)
<RAOF> nigelb: That's what I've been doing.
<RAOF> I must have missed root_command_output, though.
<nigelb> and you missed this?
<nigelb> haha
<lifeless> nigelb: 'pydoc apport.hookutils'
<RAOF> In return, I'll tell you that âpydoc apport.hookutilsâ will do the same thing.
<lifeless> RAOF: tsk, slow :P
<nigelb> and I would tell you, it isn't updated on wiki
<lifeless> nigelb: what wiki
<nigelb> the apport developer how to wiki
<nigelb> the one that I close to by-hearted when making the rhythmbox hook
<lifeless> ah
<lifeless> well, its got awkward advice then :)
<DaemonFC> Hello everyone. I have a case to make about the version of libvorbis that is currently shipping in Ubuntu and jono suggested I might bring it here. Who would be the best person to discuss this with?
<persia> DaemonFC: Better to just ask your questions: those able to do so will answer if they are around.
<DaemonFC> Ahh, I filed a bug about it. The case is that libvorbis as provided by upstream (Xiph.org) has not been meaningfully improved save for some minor bug fixes since 2004. Pretty much all the development work on it takes place in a fine-tuned fork known as AoTuv. It's possible to build Ubuntu packages which replace Xiph.org Vorbis with AoTuv vorbis, but I don't think that's optimal and not something most users would do. I also feel
<DaemonFC> that since upstream has waffled about merging this patch set for 6 years that maybe Ubuntu should treat Xiph.org as a dead upstream unless and until they merge. The changes involve 3 packages and can be reverted easily if needs be.
<DaemonFC> My bug is here https://bugs.launchpad.net/ubuntu/+source/libvorbis/+bug/529807 and has been marked duplicate of one from 4 years ago here; https://bugs.launchpad.net/ubuntu/+source/libvorbis/+bug/57797
<ubottu> Launchpad bug 529807 in libvorbis "Make aoTuv the libvorbis shipped in Ubuntu (dup-of: 57797)" [Undecided,Confirmed]
<ubottu> Launchpad bug 57797 in libvorbis "Should include aoTuV Release 1 patch" [Wishlist,Confirmed]
<DaemonFC> additionally, there's been a PPA that has been tracking AoTuv for a while; https://launchpad.net/~towolf/+archive/codecs
<persia> Hrm.  Are there any high-impact outstanding bugs that would be fixed by such a transition?
<DaemonFC> Just an across the board quality improvement, AoTuv also integrated some patches from the Vorbis acceleration project that make it ~10% faster at encoding
<DaemonFC> It's not going to fix any horrid deficiencies but it will make quality and speed noticeably better at every level
<persia> OK.  We're past FeatureFreeze for our next release, so would need to process a freeze exception, etc.
<DaemonFC> is that realistic?
<persia> Not unless there's a *really* good reason.
<DaemonFC> right now I'm overriding the packaged in Lucid by forcing a "downgrade" to the packages in that Karmic PPA and locking the version
<persia> I believe Debian Squeeze is not yet frozen, and would suggest attempting to make the transition there.
<persia> The following release of Ubuntu would likely adopt it if accepted there.
<DaemonFC> is there a way to put it on the table for Ubuntu 10.10 failing that?
<DaemonFC> Debian had the same problem (bug filed there in 2007) and same answer as Ubuntu gave in 2006, "Wait for upstream."
<persia> Absolutely.  The fancy way to do it is to write up a spec and get it reviewed at UDS.  The less fancy way is to convince some subset of developers to just do it.
<AnAnt> Hello, is xsplash still used in lucid ? or is  plymouth  replacing it too ?
<DaemonFC> whatever gets it pushed in :)
<persia> DaemonFC: Send a note to the Debian bug asking if the issue could be reconsidered after this time has passed.
<AnAnt> or, if the answer isn't here, where can I ask ?
<DaemonFC> persia, I just sent an email to that debian bug, it's quite old though so I hope there's someone that sees it :P
<pitti> Good morning
<pitti> ogra_cmpc: I did; I noticed it wasn't automounted, do you mean that? I'm going to debug that soon
<persia> DaemonFC: The age of a bug in Debian has little relevance to whether people see updates.  The response should be more interesting.
<pitti> ogra_cmpc: other devices are,mmy first suspicion is due to the ebook reader using the raw partition
<DaemonFC> persia, It's a shame that it's out of the question for Lucid simply because it's an LTS and even if Monty does merge, the Vorbis is Lucid will be 9 years without improvement by the time it's out of support
<DaemonFC> *in
<persia> DaemonFC: I didn't say it's out of the question, simply that it's late for such a change, and would need approval.
<persia> Had you asked a month ago, the answer would likely have been quite different.
<DaemonFC> well, Lucid is getting libtheora 1.1, and I just think that AoTuv going along with that would have made quite the pairing
<DaemonFC> especially with stacked up to commercial solutions
<persia> Then apply for an exception
 * persia is very much not authoritative on these matters
<DaemonFC> where do I ask for an exception?
<persia> https://wiki.ubuntu.com/FreezeExceptionProcess
<persia> Note that there's still a bit of flux happening due to the merging of motu-release into ubuntu-release, but requests shouldn't just get lost.
<DaemonFC> persia, I can see why there are so many PPAs, lol
<persia> DaemonFC: Personally speaking, I'd rather more people tried to collaborate to make something that works for everyone than just go off and use third-party repositories (which are often mutually incompatible).  There's a large overhead to wide-scale collaboration, but it tends to be less work overall as there is a smaller merge penalty for each change to whatever one derives from.
<persia> That's why I suggested working towards fixing it in Debian: that affects the largest number of people, although it does mean that it probably takes the longest time for the changes to become generally available.
<DaemonFC> the merge into Xiph.org's Vorbis is probably taking so long because many companies (including Red Hat) are paying Monty a lot to work on Theora
<DaemonFC> maybe now that libtheora 1.1 is out, he'll fix this upstream and Ubuntu will have to take it
<DaemonFC> that would be nice
<DaemonFC> ahhh, here's jono. jono will approve the freeze exception for me ;) hehehe
<jono> DaemonFC, heh, unfortunately I am not allowed to do that :)
<DaemonFC> of course you are, I have faith in you :)
<persia> It's not a matter of faith.  It's a matter of jono being far too busy with other things to be a release manager.
<DaemonFC> I was joking with him
<slytherin> Anyone from SRU team around? I wish to discuss new pre-release of gst-plugins-ugly-multiverse0.10
<zgreg> slytherin: well, all of the new gstreamer (pre)releases are quite interesting
<slytherin> oops. My mistake, I am really looking people from ubuntu-release team to discuss FFE.
<ebroder> Any core-devs that could look at bug #497606? It's got an ubuntu-sru ACK and just needs sponsorship
<ubottu> Launchpad bug 497606 in cupsys "lpstat in CUPS 1.3 can't list jobs on CUPS 1.4 servers" [Undecided,New] https://launchpad.net/bugs/497606
<DaemonFC> hey, would anyone happen to know why my Alt+F2 isn't working?
<zgreg> everything related to multimedia is still seriously lacking in ubuntu
<ebroder> (Also, if somebody would accept the nominations for cupsys+hardy, cups+intrepid, and cups+jaunty, and reject the rest of them, I could milestone everything correctly)
<persia> DaemonFC: That class of question is better asked in #ubuntu (or #ubuntu+1 if running a development release)
<DaemonFC> k, thanks
<persia> ebroder: All the nominations appear accepted to me.  I don't know how to reject once already accepted (perhaps you could set status to "Invalid")
<ebroder> persia: Hmm...oh - there we go. Looks like Till is looking at it now
<ebroder> When I loaded the page a second ago, only Jaunty was accepted
<persia> mvo: regarding bug #82436 : is my comment (#14) correct?  Also, do we still need this package in the presence of software-center?
<ubottu> Launchpad bug 82436 in gnome-app-install "wesnoth-all meta-package request (for gnome-app-install)" [Undecided,Confirmed] https://launchpad.net/bugs/82436
<mvo> persia: thanks, indeed. I fix it in the metadata
<persia> mvo: Cool, thanks :)
<cjwatson> ooh, openssh upstream completely redid its smartcard handling recently such that we'll be able to compile it in by default after the next upstream release
 * cjwatson is glad he's been consistently refusing requests for a new binary package, which he now doesn't have to migrate away from ;-)
<RAOF> james_w: Can I bzr import-dsc into the sid packaging branch safely?  I'd like t omenge gjs 0.5-1, but it hasn't yet been imported.
<pecisk> Hi people, what are Ubuntu dev thoughts about this? https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2010-February/010730.html Upstream agrees that usb-modeswitch is way to go. So maybe it can still be included in main and by default. Of course feature freeze exception is serious thing, but it would be nice to have working out of box mobile broadband modems.
<DaemonFC> ikonia, If you want to be thorough now, I'm right here. :)
<ikonia> DaemonFC: there is no ban on you here. So no issue
<DaemonFC> functionaries. oh well.
<james_w> RAOF: you want 0.5-1?
<RAOF> james_w: Yes.  And to know whether or not it's safe to go behind the package importer's back.
<RAOF> For future reference.
<james_w> RAOF: so yes, you can do it
<james_w> you can't push to the sid branch though
<james_w> but I think if you push to the Ubuntu branch it will re-use what you have done when it notices that the new upload is available
<RAOF> Ok.
<james_w> and the reason it hasn't done that yet is that launchpad hasn't imported the Debian version yet
<cjwatson> directhex: mono should be sorted now
<directhex> cjwatson, thanks, i noticed it was gone from the queue
<directhex> the kdebindings folks wanted it for actual reasons, i just wanted a ppa build to work...
<ogra> seb128, evo starts to eat 80-90% CPU after a while of running, i cant see a bug open for that
<ogra> it goes away after i run evolution --force-shutdown (just closing the UI doesnt help) and returns after it ran for 10-20 min
<seb128> ogra: I've seen a bug about that and evo didn't change since karmic
<seb128> so it's likely something else impacting on it
<ogra> well, probably a lib or something
<ogra> i didnt see it before the gtk issues appeared but i'm not sure the two are related
<ogra> i saw it though even when i rolled back to the non-broken gtk version during the time gtw was broken
<ogra> so i dont really think its gtk itself
<ogra> s/gtw/gtk/
<ogra> beyond that evo is running fine too ... its just that it massively eats CPU
<cjwatson> ArneGoetje: ibus-pinyin-db-open-phrase now depends on pinyin-database, which is in universe.  Somebody needs to either file an MIR for it or remove the dependency; could you take care of one or the other?
<cjwatson> ArneGoetje: (I haven't looked at the situation at all, I just know that DVD builds are failing as a result)
<seb128> ogra: dunno
<mark__> I've created a local package which installs a diversion for /etc/ssh/sshd_config. I'm trying to figure out how to reload sshd config *after* the file is changed. right now it reloads right before (from postinst). Any hints?
<cjwatson> probably best to just reload ssh ('/etc/init.d/ssh reload' in <=karmic, 'reload ssh' in lucid)
<cjwatson> diverting sshd_config is totally ineffective though
<cjwatson> it's not installed by dpkg - it's managed by the openssh-server maintainer scripts
<mark__> cjwatson: oh. I see. I'll have to take a close look at how that's being set up. I have a reload call in my postinst now. I was assuming /etc/ssh/sshd_config was a conffile.
<maja87_> hello
<hyperair> hello
<maja87_> i want to be an ubuntu developer. how can ibe?
<mark__> cjwatson, so it's not 'owned' by openssh-server but it's still known to apt, cause I get a conffile-like prompt. So how do I go about replacing it?
<mark__> says "File on system created by you or by a script"
<persia> maja87_: https://wiki.ubuntu.com/MOTU/Contributing is getting increasingly out of date, but provides some ideas of how to help.  Also see https://wiki.ubuntu.com/UbuntuDevelopers
<cjwatson> mark__: I have no idea how you managed that
<cjwatson> mark__: perhaps something to do with your own diverting package
<cjwatson> mark__: the openssh package I maintain does nothing that would cause that ...
<cjwatson> indeed it's a long-standing bug that it doesn't, sort of
<maja87_> cjwatson the bug is only stand in 9.04 and 9.10
<maja87_> if i install the system touchpad works good
<cjwatson> maja87_: huh?
<cjwatson> maja87_: I wasn't talking to you :)
<maja87_> but if i disconnect ac charger nothing wrong
<mark__> cjwatson, oh, yeah I had a leftover .dpkg-dist sitting there, my bad
<maja87_> ok
<maja87_> :)
<ogra> pitti, did you notice that some plug events arent catched by udisks ?
<ogra> i.e. plugging in a SD card on my laptop or my ebook reader doesnt mount them
<pitti> ogra: as I said earlier, I get the effect with raw devices such as my ebook reaer
<pitti> ogra: I'll have a look at this
<pitti> ogra: if you wish, feel free to "ubuntu-bug storage", for some log comparison and tracking
<ogra> pitti, oh, funny, after i used udisks --mount once with that SD it gets automounted now
<ogra> oops, sorry, didnt see you replied to my weekend ping
<pecisk> anyone have run into problems with nouveau and LiveCD Alpha 3? CD spews lot of reading errors and in the end doesn't work correctly (launching Firefox crashed desktop). CD-RW is allright, I burned it with several other distros and they worked fine.
<pecisk> it happened on two computers
<persia> pecisk: I'll suggest you ask on #ubuntu+1
<apw> we have a number of keyboard quirks in karmic which say "n 2.6.32, a /sys interface is provided to handle setting from userspace." ... so we have the userspace support for these?
<smb> (quirks being to generate missing key release events)
<didrocks> cjwatson: hey, we need a 5 line bin to create a wallpaper cache for GNOME as ubiquity doesn't use g-s-d for drawing the background in install mode. The bin is called in casper and we agreed with pitti and seb128 that the bin should be there too. The drawback is that it will make casper depends on glib and libgnome-desktop. Just want to check that it's ok with you too before doing the change :)
<cjwatson> didrocks: casper itself can't have those dependencies - it can use them if they're available, but it can't actually depend on them.  it's used by more than just Ubuntu images
<didrocks> seb128: pitti: idea where we can put it so? ^
<didrocks> cjwatson: thanks
<cjwatson> didrocks: I think it would be more appropriate to put the binary in ubiquity-frontend-gtk
<cjwatson> perhaps?
<cjwatson> actually it would be better if we could find some other place - I don't want ubiquity-frontend-gtk to be architecture: any
<seb128> didrocks, ok, just upload in gsd
<smb> slangasek, pitti, To be specific, do you know whether user-space modifies /sys/devices/platform/i8042/serio0/force_release
<seb128> we wasted too much time for that already I think
<seb128> I don't like but that's minor, let's do it this way
<cjwatson> didrocks: I don't understand why casper is involved here
<cjwatson> didrocks: casper isn't responsible for ubiquity's install-only mode?
<didrocks> seb128: if you are ok on it. In any case, it's now in debian/â¦.c and build is in debian/rules, so, not an added patch
<cjwatson> didrocks: shouldn't it be called in ubiquity-dm or something?
<didrocks> cjwatson: casper has an ubiquity-hooks which will call that binary
<cjwatson> didrocks: uh, that's after installation ...?
<didrocks> cjwatson: right, to push something to the $HOME/.cache/wallpaper
<cjwatson> didrocks: why not just put it in ubiquity/scripts/install.py?  putting it in casper's ubiquity-hooks seems an artificial separation, given that it isn't something that casper is otherwise involved in
<cjwatson> didrocks: the point of casper's ubiquity-hooks is specifically to reproduce things that are done by casper at live CD boot time, and need to be repeated after installation
<cjwatson> it isn't meant to be a grab-bag of post-install scripts
<didrocks> cjwatson: there is already some hooks like that like accessibility, etc. ev told me to put the first version there (which works in live mode)
<cjwatson> didrocks: accessibility is there because casper does accessibility stuff at boot time
<cjwatson> didrocks: I don't think things should go in casper's ubiquity-hooks unless they're also done at boot time in casper
<cjwatson> otherwise the result is that we end up with code spread around between casper and ubiquity when it doesn't need to be
<cjwatson> you could install a ubiquity-hooks file in gnome-desktop if you want, but it might be better to just have it in ubiquity
<didrocks> cjwatson: ok, so, I should convert 35copy_wallpaper_cache to python to some code in install.py?
<cjwatson> I think so
<didrocks> cjwatson: the script will do "bad thing" that we refused to do on upgrade but on install as it's in a controlled environment, we decided it's ok. Not sure you want that in ubiquity itself I can pastebin it: http://paste.ubuntu.com/386311/
<cjwatson> I think that would be OK in ubiquity itself
<cjwatson> but I also think it would be OK in a hook in gnome-desktop
<cjwatson> up to you really
<didrocks> cjwatson: I can try to convert it to ubiquity itself and propose you for a review
<cjwatson> you might think that using hooks is in general more elegant; or you might not want to carry the code in gnome-desktop :)
<cjwatson> it might be easier all round to use a hook
<cjwatson> that way, you only have to change one package, and it's all self-contained
<didrocks> cjwatson: I think it'll be more logical to have the call into ubiquity TBH
<pitti> smb: yes, that's a new helper in udev, part of the keymaps
<pitti> smb: any particular question about that one?
<pitti> slangasek: ^ FYI
<cjwatson> didrocks: I'm easy either way
<smb> pitti, Just wondered whether we have that support (as some kernel drivers have quirks for that as well)
<smb> apw, ^
<didrocks> cjwatson: thanks, I'll try to have some time to propose you a merge for that later
<apw> smb, pitti thanks, so sounds like we don't need the kernel quirks any more, thanks
<pitti> apw, smb: udev grew that support in lucid
<pitti> apw: beware that we just have two quirks in udev so far; if hte kernel has more, we need to convert them to udev rules instead of just dropping them
<apw> pitti, where are they so i can confirm
<apw> pitti, and presumably bugs against the quirk package when they are missing?
<pitti> apw: /lib/udev/rules.d/95-keyboard-force-release.rules maps machines to tables
<pitti> and the tables themselves are in /lib/udev/keymaps/force-release/
<pitti> apw: "quirk package" == udev
<apw> pitti, thanks
<pitti> apw: if you have some, it would be nice if you could assign them to me right away
<smb> pitti, apw Likely atm, we just need to make sure we have no dups and future changes go to there instead of a kernel driver
<apw> i have three i was just looking at whether they need to come over to lucid, looks like two are already in
<pitti> if you do that work, I can commit the new quirks upstream right away
<apw> ack
<pitti> (I guess you want to get the removal from the kernel upstream as well)
<apw> they never made it upstream in the kernel
<pitti> oh, so much the better
<pitti> wrt. reducing delta, I mean
<seb128> cjwatson, the enchant version uploaded should fix the ubiquity crash, I cleaned some bugs there too
<seb128> cjwatson, let me know if you still get one of those after tomorrow's iso update
<apw> pitti, its a much much better game all round ...
<seb128> cjwatson, I'm pretty sure that was it but in case there is still some other issue
<cjwatson> seb128: great, thanks a lot
<seb128> cjwatson, np
<jdstrand> cjwatson: hi! I noticed when you adjusted libvirt to build against parted 2.1, it ftbfs on all architectures. are you looking at this?
<cjwatson> jdstrand: yes
<cjwatson> I need to make a change in Debian experimental and merge it across
<jdstrand> ok, excellent
<jdstrand> cjwatson: thanks :)
<jdstrand> kirkland: fyi ^
<cjwatson> likewise pyparted
<cjwatson> (change in Debian> in parted, I mean)
<kirkland> jdstrand: thanks
<jdstrand> cjwatson: re change in Debian> in parted-- gotcha (that is what I figured)
<cjwatson> I think it only affects packages that build against parted *and make use of libparted.la*8
<cjwatson> s/8$//
<mpt> mvo, tremolux: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/426999
<ubottu> Launchpad bug 426999 in software-center "Navigating to application via search doesn't show its department" [Medium,Triaged]
<apw> pitti, this dell quirk is for the volume keys, in the kernle they renamed it simply volume as it was used a lot, one of the missing ones also wants the same three keys ... would it be reasonable to rename that to like basic-volume as well?
<pitti> apw: "renamed it" -> what is "it" in particular?
<pitti> apw: certainly not the linux/input.h constants?
<ebroder> Any core-devs around that could sponsor bug #497606? It's already got an ack from ubuntu-sru
<ubottu> Launchpad bug 497606 in cupsys "lpstat in CUPS 1.3 can't list jobs on CUPS 1.4 servers" [Undecided,Invalid] https://launchpad.net/bugs/497606
<apw> pitti, you have a quirk in udev called dell-studio-1557 which quirks a0, ae and b0.  in the kernel they renamed that list to a generic name 'volume' or similar as it is a common set of keys to be bust ... one of the new quirks is for the same three keys
<apw> pitti, so i either need to make a new file with the same three keys, or share it, in sharing a generic name may be appropriate ... just wondering
<apw> which you though was more approprate here
<pitti> apw: oh, you can address sets of keys by name? I didn't know that
<apw> pitti, no ... i am just talking about the files in udev
<apw> there are perhaps 5 machiens which have the same three binary numbered keys, all for mute/volume up/voume down with the same fault
<apw> (according to the kernel)
<apw> i am adding a second one which needs the same file as the dell
<pitti> apw: ah, ok; I'm fine with that file being renamed to dell-volume
<apw> you already added.  and it seems silly to not share the file
<apw> its actually not just dell
<pitti> and referenced by multiple udev matches (or generalizing the existing one)
<pitti> apw: but the particular scan codes are probably dell specific?
<apw> i was thinking generic-volume-mute or common-v-m
<pitti> apw: in general, if the map files are the same, I either change the file name to include another model number or, if there are too many, just drop the model and make it a generic file name
<apw> i assume they are bios specific or something as the same codes on the dell affect amilo as well
<apw> hrmm
<apw> i'll pull in the amilo for now and it can evolve over time
<mpt> mvo, tremolux: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/524379
<ubottu> Launchpad bug 524379 in software-center ""Installed Software" item doesn't have children" [Undecided,Confirmed]
<ArneGoetje> cjwatson: I will take a look
<cjwatson> ArneGoetje: thanks
<tremolux> mpt, mvo: https://bugs.edge.launchpad.net/ubuntu/+source/software-center/+bug/528043
<ubottu> Launchpad bug 528043 in software-center ""provided by Ubuntu" incomplete" [Undecided,New]
<tremolux> mpt, mvo: https://bugs.edge.launchpad.net/ubuntu/+source/software-center/+bug/528057
<ubottu> Launchpad bug 528057 in software-center "view menu inactive in 'per source' view" [Undecided,New]
<apw> Keybuk, is this the right stacking branch being picked here:
<apw> Using default stacking branch /~scott/udev/master at lp-64605456:///~apw/udev
<apw> when pushing a new udev branch ?
<Keybuk> apw: sodomy non sapiens
<Keybuk> that branch is where I import the GIT HEAD into
 * apw suspects that is a new
<Keybuk> lp:ubuntu/udev is based off that
<apw> no
<jdstrand> apw: fyi, I installed that kernel with the backported drm fro .33 and will be testing it extensively
<apw> ... ahh, well its pushing one hell of a heap of stuff as a result... i guess i'll blame LP
<Keybuk> sorry lp:~ubuntu-core-dev/udev/ubuntu
<Keybuk> yeah
<apw> 8MB so far and counting, for two 2 line changes :(
<apw> jdstrand, sounds good ...
<Keybuk> apw: it's a kinda pointless message really
<apw> i thought it was meant to chose a base which it could steal the packs from ... seems not
<apw> 16MB ... and couting
<cjwatson> it chooses a base, it's just not necessarily the closest one
<cjwatson> indeed it's sometimes possible for there to be no common history at all :( I think it just uses the "development focus"
<apw> seems that it chose that today
<cjwatson> for branches in the distribution namespace rather than the product namespace, it'll use lp:ubuntu/<package>, I believe
<Keybuk> cjwatson: that still has the whole chicken/egg problem
<Keybuk> though that's weird
<Keybuk> lp:ubuntu/udev looks like lp:~ubuntu-core-dev/udev/ubuntu
<Keybuk> I've never pushed it there :
<Keybuk> :p
<jdstrand> apw: well, that was quick. compiz crashed (see report), but differently. Only thing in dmesg related to the crash is:
<jdstrand> [ 738.880732] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation
<jdstrand> apw: do you need more info? an apport-collect or is this enough?
 * apw has no idea.  the more infor the merrier
<apw> pitti, as requested i have filed a bug for each quirk, they are assigned to you, i've linked a branch with possible patches for them both
<pitti> apw: cheers!
<lucas> james_w: hi, is there a way to make your life better for the next round of ruby syncs? or should I continue with 1 bug per sync? (yes, there's another round coming :( )
<james_w> lucas: you don't have to file a bug per-sync for transitions
<james_w> lucas: you can provide instructions directly if they won't require in-depth checking
<james_w> (one bug with a list of packages is actually the worst way to provide it, so please no-one do that :-)
<lucas> what do you mean by instructions, then?
<james_w> one line per source package
<james_w> -S <suite> [-f] <source package name>
<james_w> where suite is testing/unstable/experimental
<james_w> and -f is to overwrite Ubuntu changes
<lucas> ok, thanks
<james_w> and source package name is... well you can probably figure that one out
<lucas> I think so
<james_w> hand that list to an archive admin and they can fire them all through for you
<james_w> please only use it for transitions though, it doesn't scale if everyone does this for every sync :-)
<lucas> sure
<Riddell> mvo: rgreening is testing upgrade but getting " The package 'update-manager-kde' is marked for removal but it is in the removal blacklist" errors, we don't use update-manager-kde in lucid, where's this blacklist?
<hyperair> any ubuntu-release people around?
<mvo> Riddell: should it go away? I can fix that, its currently shying away from removing anything that starts with update-manager
<Riddell> mvo: yes it gets replaced by kubuntu-notification-helper and kpackagekit distro notification in lucid
<mvo> Riddell: ok
<superm1> mvo, re bug 529740, i'm a bit confused.  what's the most appropriate section for the themes metapackage to prevent this problem?
<ubottu> Launchpad bug 529740 in mythtv "I uninstalled MythTV, but I can still run the software" [Medium,Confirmed] https://launchpad.net/bugs/529740
<Riddell> hyperair: what do you need a release person for?
<mvo> Riddell: commited to bzr, should I remove update-manager-kde from the u-m source too?
<hyperair> Riddell: i'd like to discuss about banshee, banshee-community-extensions and taglib-sharp.
<mvo> superm1: well, the way we use metapackage is that anything directly under metapackage will not get marked as auto-installed. this has the nice effect that removing ubuntu-desktop does not remove half your system. now for the themese that is probably not what we want, so I would suggest to put it into a different section
<rgreening> ty Riddell, mvo
<superm1> mvo, ah i see. Ok.
<Riddell> mvo: where is it in u-m source?
<Riddell> hyperair: doesn't sound like my area I'm afraid
<hyperair> Riddell: oh well.
<hyperair> Riddell: who handles the GNOME freeze exception?
<mvo> Riddell: thre is debian/control update-manager-kde
<mvo> Riddell: if that should go away, just let me know and I remove it
<Riddell> mvo: oh yes.  I'm pretty sure we still need those, they get called by packagekit to do the tests
<Riddell> hyperair: #ubuntu-desktop probably best for Gnome packages issues
<hyperair> thanks
<mvo> Riddell: eh, if those are still needed, then u-m should also keep it in the the removal blacklist, no?
<Riddell> mvo: it's update-notifier-kde we want to go, update-manager-kde keep
<Riddell> mvo: hum wait, this is confusing
<mvo> Riddell: I'm confused too
<Riddell> mvo: I need to look into this properly and get back to you
<Riddell> not today I'm afraid
<mvo> Riddell: sure, just let me know
<ArneGoetje> cjwatson: I will check with LiDaobing tomorrow if we really need pinyin-database as a Depends or if it should rather be a Build-Depends
<cjwatson> cool.  if it's a build-depends it will still need to live in main, though.
<ArneGoetje> cjwatson: it is definetely needed to build ibus-pinyin-db-open-phrase... since pinyin-database is really just a sql database file, which gets packed into a tarball, what is to check there for the MIR?
<cjwatson> you're allowed to write an MIR bug that indicates that it's trivial.  the thing is that you cannot expect archive admins to do that check for all of the dozens of packages currently awaiting promotion to main - somebody needs to actively request it and keep on top of it
<cjwatson> https://wiki.ubuntu.com/MainInclusionProcess
<ArneGoetje> cjwatson: okay
<ArneGoetje> cjwatson: done. Bug #530178
<ubottu> Launchpad bug 530178 in pinyin-database "[MIR] pinyin-database" [Undecided,New] https://launchpad.net/bugs/530178
<mpt> tremolux, I've triaged both bug 528043 and bug 528057
<ubottu> Launchpad bug 528043 in software-center ""provided by Ubuntu" incomplete" [Medium,Triaged] https://launchpad.net/bugs/528043
<ubottu> Launchpad bug 528057 in software-center "Canonical maintenance filter unavailable in "Provided by Ubuntu"" [Wishlist,Triaged] https://launchpad.net/bugs/528057
<cjwatson> ArneGoetje: thanks
<tremolux> mpt: thanks!  looking...
<cyphermox> is there a specific reason why ifupdown is still at version 0.6.8
<cyphermox> ah, I should rephrase that
<cyphermox> is there a specific reason why ifupdown is still at version 0.6.8 (admittedly, -0ubuntu29), while 0.6.9 is now available? would there be a benefit or an issue with merging that to match what's currently in debian testing (since last September)?
<tremolux> mpt: so, the issue for bug 528043 is that we are currently filtering the "Provided by Ubuntu" list to show applications only, rather than all 30K+ available packages
<ubottu> Launchpad bug 528043 in software-center ""provided by Ubuntu" incomplete" [Medium,Triaged] https://launchpad.net/bugs/528043
<mpt> tremolux, so I see
<tremolux> mpt: originally, I had them all in there, but that long list was pretty painfully unusable and, iirc, mvo added the filter for apps only
<mpt> mvo, is it easy to produce a list of applications that have .desktop files using the categories "2DGraphics", "VectorGraphics", "RasterGraphics", "3DGraphics", "Scanning", "OCR", "Photography", "Viewer"? (For bonus points, is there an easy way to advise someone other than you on how to generate that list, so it doesn't take up your time?:-)
<mpt> mvo, because whether they're currently being used influences whether we should expose them in the 2.0 categorization (that I'm finishing right now)
<mpt> tremolux, my "Deleted Messages" folder has 121634 messages in it and scrolls fine. :-) Any idea why that 32000 is painfully unusable?
<mpt> tremolux, is it just because of the resizing of the selected row?
<tremolux> mpt: I think it's due to the fixed-height bug
<tremolux> mpt: p.s.  you should clear out your "Deleted Messages" folder  ;)
<mpt> Other people call it "Archive"
<tremolux> mpt: haha
<mpt> tremolux, so maybe someone (mvo? bratsche?) could give bug 524567 some love first
<ubottu> Launchpad bug 524567 in software-center "Software list views with variable-height rows scroll slowly" [Undecided,New] https://launchpad.net/bugs/524567
<mpt> tremolux, but it's pretty fundamental to the mental model here that the parent item (e.g. "Get Software") == the union of the child items.
<tremolux> mpt: agreed
<mpt> tremolux, and this is something we'll need to solve anyway because I'm about to nuke (specificationally-speaking) the subcategories of "System Packages"
<tremolux> mpt: ah
<tremolux> mpt: yeah, we need to solve this anyway, it causes lots of problems
<tremolux> mpt: we should let mvo weigh in, he's spent a fair amount of time on this
<mpt> mvo, in the absence of debtags, what's the best way to tell which packages are fonts?
<mpt> Package name starts with "ttf-" or "otf-"?
<mpt> ArneGoetje, ^^
<didrocks> cjwatson: when you have some time, if you can review lp:~didrocks/ubiquity/copy_wallpaper_cache, thanks :)
<mvo> mpt: re categories> I can write you a tool for that tomorrow (need to leave in a bit) - could you mail me the exact requirements please?
<mvo> mpt: re speed> what are you using? evo? thunderbird?
<mvo> mpt: re speed 2> we have some code in the fastapp branch, but its a lot of code in order to work around the gtktreeview performance problems
<mpt> mvo, thunderbird, so, not the same implementation :-)
<mvo> mpt: I spend a bit of time on gtk thing, we need to solve it for final one way or the other, but its not trivial (either via fastapp workaround or gtk patching)
<mpt> mvo, thanks, I'll mail you
<mvo> mpt: my preference is to fix it upstream, but that requires some effort (ond, two days, unless bratsche does it, then ~4h ;)
<mvo> s/ond/one/
<mvo> so yeah, its on the list, but its painful
<mvo> mpt: mail> thanks, I will reply in the morning first thing
<mpt> mvo, UI freeze doesn't affect that bug unless we're really uncertain we'll be able to fix it at all, I guess
<mvo> right
<jdstrand> ccheney: hey, do you have a minute to discuss webkit in #ubuntu-meeting right now?
<jdstrand> ccheney: we have a few questions
<jdstrand> ccheney: if not, we can schedule for another time
<ccheney> jdstrand: ok
<kirkland> pitti: i have another eucalyptus (*-7.6) uploaded to karmic-proposed ... could you accept at your convenience?
<LaserJock> hmm quilt 3.0 source packages don't work in Karmic PPAs?
<soreau> In the output of 'dpkg -l' ii means installed. What does rc mean?
<elmo> soreau: there's a legend at the top of the dpkg -l output
<elmo> LaserJock: apparently dpkg in karmic doesn't work 100% with them
<LaserJock> elmo: darn, that does make backports a pain
<geser> LaserJock: v3 source packages are only accepted for lucid and lucid PPAs
<soreau> elmo: This is all I see http://pastebin.com/pn7kU3y8
<LaserJock> geser: you know of any doc on how to "un-v3" a source package?
<soreau> Not seeing a legend, and the man page doesn't reveal anything interesting
<geser> LaserJock: no (I haven't worked much with v3 packages). but if you don't use any fancy features from v3 it might be enough to remove debian/source/format (that's what I've heard)
<elmo> soreau: r == Desired == Remove
<elmo> soreau c == Status == Cfg-files
<LaserJock> geser: that's the only thing mentioned in the changelog for it so maybe that'd be enough
<elmo> soreau: it is a legend, just quite a dense one
<soreau> elmo: I would hardly call that a valid legend
<soreau> I do not see how one could reasonably assume that another could deduce what 'rc' means from that
<elmo> soreau: err, ok, dude, whatever.  I was just trying to help you
<elmo> clearly, my bad
<soreau> elmo: I still want to know what rc means though :P
<cjwatson> it means that the package has been removed but configuration files remain
<soreau> Ahh
<soreau> Thanks cjwatson
<soreau> elmo: Thanks for your help too man
<zul> slangasek: ping have you had a chance to look at the php ffe?
<pitti> slangasek, Keybuk: is it correct that upstart jobs don't do anything like sourcing /etc/environment, /etc/default/locale, etc.?
<pitti> ah, apparently it is, looking at gdm.conf
<slangasek> zul: granted now, sorry for the delay
<slangasek> pitti: upstart jobs *can* do this, but Keybuk doesn't like it when you do (he says sourcing files is too slow :)
<zul> slangasek: thanks
<pitti> slangasek: we can also soure /etc/default/locale in /etc/gdm/failsafeXServer, so that's fine
<pitti> slangasek: I just wanted to know why translations were broken
<pitti> slangasek: thanks
<siretart> I'd like to contact the technical board, but would prefer to use a non archived mailing list. is there a better adress than technical-board@l.u.c?
<maco2> superm1: have you had a look at the price for the Dell Mini 10n when you click "Shop For Ubuntu" on dell.com/ubuntu ?
<maco2> (it's $100,278)
<jdong> maco2: it's the *designer* edition :)
<ScottK> maco2: Nice.
<maco2> jdong: oh and here i was thinking it was a typo!
<jdong> maco2: no no, it's a symbol of social elitism to be able to afford that one!
<LaserJock> I thought maybe it was the "donate to Hati relief" model
<jdong> forget that M5 I was saving up for...
<tkamppeter> pitti, hi
<superm1> maco2, haha, looks like quite a typo.  i'll forward that to the website folks.  at least when you click configure it comes up right
<maco2> superm1: thanks
<jcole> is the java viewer enabled in remote desktop (vino)
<jcole> im searching all over gconf and cant figure out how to enable http access
<kees> NCommander: do you have access to a running mips system?  I'm trying to debug a build failure in Debian, but all the mips porters are down.
<NCommander> kees: mips or mipsel?
<NCommander> I can probably get the former if you can tolerate 166Mhz/32 MiB :-)
<kees> NCommander: either, mipsel preferred
<kees> I don't mind :)
<NCommander> kees: mipsel is easy. 800Mhz, 512MiB :-)
<NCommander> kees: I need to reinstall that box though, and there may be instabilities; what package?
<jcole> we use hp virtual rooms (rooms.hp.com) for windows and mac users right now, but it would be nicer to use ubuntu's built in to use remote desktop
<kees> NCommander: I'm trying to figure out why "readelf -r" fails.  https://buildd.debian.org/fetch.cgi?pkg=hardening-wrapper;ver=1.24;arch=mipsel;stamp=1267403604  "There are no relocations in this file."
<jcole> bleh
<NCommander> kees: I'll jot reinstalling that box on my TODO list
<kees> NCommander: okay, cool.  don't burn a lot of time on it.  )
<kees> :)
<DnaX> pitti: https://bugs.launchpad.net/ubuntu/+source/udisks/+bug/526524
<ubottu> Launchpad bug 526524 in udisks "Benchmarking in palimpsest fails with "Error seeking to position -1734254592 for (null): Invalid argument"" [Unknown,Confirmed]
<DnaX> pitti: https://edge.launchpad.net/~dnax88/+archive/ppa/+sourcepub/982085/+listing-archive-extra
<kirkland> nixternal: howdy, around?
<kirkland> nixternal: can you reproduce https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/500218 on the latest Lucid kvm?
<ubottu> Launchpad bug 500218 in qemu-kvm "*** glibc detected *** qemu: free(): invalid pointer: 0x0000000000e44b10 ***" [Medium,Confirmed]
<nixternal> kirkland: it is now fixed
<nixternal> ie. I can't reproduce that now...I thought I closed it out a few weeks back
<kirkland> nixternal: \o/
<nixternal> and what fixed it, I have no clue...I do not remember updating anything that broke it or fixed it :)
<kirkland> nixternal: cool, would you close it?
<kirkland> nixternal: ;-)
<nixternal> roger that
<kirkland> nixternal: rock on with your bad self
<nixternal> haha, quit stealing my lines :)
<nixternal> done
<blueyed> bug 530295 - am I missing something?
<ubottu> Launchpad bug 530295 in dbus "Missing debug symbols for libdbus-1-3" [Undecided,New] https://launchpad.net/bugs/530295
<blueyed> (except the debug symbols ;)
<Caesar> lucas: yt?
<lucas> Caesar: yt?
<Caesar> lucas: yeah
<Caesar> How are you?
<Caesar> lucas: I'm trying to help out Nigel with https://bugs.launchpad.net/ubuntu/+source/ruby1.8/+bug/520715 because he's busy
<ubottu> Launchpad bug 520715 in ruby1.8 "building ruby1.8 with pthread support causes puppet hangs" [Undecided,Triaged]
<Caesar> Basically what he was trying to say was that he's not seeing that timeout code work as intended
<Caesar> The thread is not getting killed, aiui
<lucas> Caesar: a test case could be great, because I can't reproduce it
<Caesar> lucas: that would be coment #13
<Caesar> comment even
<Caesar> https://bugs.launchpad.net/ubuntu/+source/ruby1.8/+bug/520715/comments/13
<ubottu> Launchpad bug 520715 in ruby1.8 "building ruby1.8 with pthread support causes puppet hangs" [Undecided,Triaged]
<lucas> Caesar: yes, but as I wrote, the timeout class is a pure-ruby class. so it should be very easy to reduce the testcase further
<lucas> to something not involving the Timeout module/class
<Caesar> Have you tried to reproduce it on Ubuntu or only Debian?
<lucas> Debian, and an ubuntu chroot. but I admit I've not tried very hard in the chroot.
<Caesar> ok
<cjwatson> siretart: you'll have to mail the members individually
<lucas> Caesar: gah. I can see it now.
<lucas> which is good. now I can blame Ubuntu :->
<Caesar> lucas: :-)
<lucas> Caesar: it's clearly not reproducible on Debian. Switch to Debian? :-)
<Caesar> lucas: heh
<TheMuso> 8/c
<Caesar> So I have this sneaking suspicion it might be a glibc issue
<lucas> me too
<Caesar> I saw something else (can't remember what) that was crashing in libpthread
<Caesar> lucas: so are you going to update the bug with what you've seen/found/not found?
<lucas> Caesar: no, I first want to try with experimental's libc
<Caesar> ok
<Caesar> It might be a 2.11 thing
<lucas> ok; crashes with libc 2.11.0 from debian experimental
<Caesar> \o/
<Caesar> slangasek: why does Lucid have a newer glibc than is in Debian's testing?
<kees> NCommander: no worries about the mips system; I've got qemu working locally now.
<persia> Caesar: There are a few sets of packages that are typically newer in Ubuntu.  These include X, GNOME, KDE, gcc, glibc, python, etc.
<Caesar> persia: I know, there was just a general air of conservatism about Lucid since it was an LTS
<bryceh> Caesar, not really
<Caesar> bryceh: orly, so why is it syncing from testing and not unstable then?
<lucas> persia: that's not true for X, gcc and python
<bryceh> Caesar, the S in LTS stands for 'support' not 'stable' - the idea is to have versions of things that can be supported for a long period
<Caesar> heh
<bryceh> sometimes newer bits are going to be more suitable to support for a longer period
<Caesar> I am so going to put that on a t-shirt
<slangasek> Caesar: syncing generally applies to all those packages that aren't actively attended by anyone in Ubuntu; packages that have maintainers in Ubuntu are certainly more likely to be out of sync.  I don't know specifically why eglibc is out of sync
<Caesar> slangasek: FYI, it sounds like bug #520715 is a glibc bug
<ubottu> Launchpad bug 520715 in ruby1.8 "building ruby1.8 with pthread support causes puppet hangs" [Undecided,Triaged] https://launchpad.net/bugs/520715
<slangasek> ah, well then
<Caesar> Just so you know
<Caesar> And that's impacting on Puppet
<Caesar> yadda yadda yadda
<persia> There's lots of bugs :)
<slangasek> Caesar: reassign it to the eglibc package, subscribe doko to it?
<lucas> I'm not 100% sure it's a glibc bug.
<Caesar> lucas: you want to update it with your most recent findings first?
<slangasek> lucas: try to reproduce in Debian pulling eglibc from experimental?
<Caesar> slangasek: he did
<Caesar> and he succeeded
<slangasek> ah
<lucas> ruby1.8 is known to sometimes make assumptions about pthread. it was a problem on hppa before the NPTL switch.
<Caesar> Hence my "it sounds like a glibc bug"
<lucas> anyway, we need someone with glibc knowledge to look at this, so it's probably better to reassign
<Caesar> Okay
<Caesar> I will do that then
<lucas> (I've subscribed directly)
<Caesar> Thanks lucas, slangasek
<Caesar> I'll try to remember what else I saw failing in libphtread
<Keybuk> slangasek: no, Keybuk doesn't like it because there should be one place to configure jobs (the /etc/init conf file - I'm quite happy with the env FOO=bar stuff at the top)
<slangasek> well, ok
<slangasek> in the case of /etc/default/locale, this would be contrary to the intent of that file
<cjwatson> if somebody moves the canonical location of system locale configuration again, I may go postal
#ubuntu-devel 2010-03-02
<ArneGoetje> mpt: yep, filter for ttf-* and otf-* should find all the relevant font packages.
<mpt> thanks ArneGoetje
<tgm4883> slangasek, can I bug you for a minute about an archive question?
<persia> tgm4883: Just ask :)
<tgm4883> persia, heh, was just getting to that
<persia> (people may be absent or long-term idle, but waiting for response is often futile and wastes a context switch)
<tgm4883> I have a package showing up in multiverse/metapackages which is causing issues when trying to remove it from the software center (leaves a bunch of stuff leftover). persia checked debian/control and everything looks ok there. debian/control for the mythtv-themes package is http://pastebin.com/qEHHs2Zg
 * persia suspects an override
<slangasek> which is the package in metapackages that you think shouldn't be?
<slangasek> mythtv-themes, I guess
<tgm4883> yea mythtv-themes
<tgm4883> it's not that it shouldn't be in there, but it apparently causes issues when trying to remove it via software center
<slangasek> tgm4883: if you think this is the wrong behavior, I can go ahead and change the override.  I'd suggest double-checking with the other mythbuntu folks to confirm this wasn't intentional, if you haven't already
<slangasek> oh
<tgm4883> specifically for bug 529740
<ubottu> Launchpad bug 529740 in myththemes "mythtv-themes metapackage needs to be != metapackages section" [Medium,Triaged] https://launchpad.net/bugs/529740
<slangasek> "shouldn't be there" meaning "shouldn't be in section metapackages", or?
<tgm4883> yea, shouldn't be in section metapackages
<tgm4883> superm1 had a discussion with mvo regarding how it works in the software center
<slangasek> ok, override changed (metapackages->graphics)
<tgm4883> slangasek, awesome, thanks. Is there anything I need to do to the packaging to reflect that?
<persia> ArneGoetje: I'm seeing lots of traffic in bug #197537 again.  I thought you had a good solution for this for lucid.  Would you mind commenting with current plans when you have a chance?
<tgm4883> it's already in section graphics in there
<ubottu> Launchpad bug 197537 in poppler "[MASTER] Can't read PDF file with CJK (Chinese/Japanese/Korean) text" [Unknown,Confirmed] https://launchpad.net/bugs/197537
<slangasek> tgm4883: nope - I think you can go ahead and close the bug
<tgm4883> slangasek, awesome, thanks again
<wgrant> persia: Is there a good reason that NEW upload rights shouldn't be granted to package(set)-specific uploaders?
<StevenK> wgrant: Yes. They have a conflict of interest since they may have uploaded the package in the first place.
<persia> wgrant: No, there isn't.  The issue is that such behaviour isn't currently supported by Soyuz.
<persia> Specifically that the ACL for source NEW happens to be MOTU.
<wgrant> There are some issues involved, but the fix is technically easy.
<persia> StevenK: We're talking about different things: uploading to source NEW != reviewing source NEW.
<wgrant> At the moment, I believe that any component upload right is sufficient.
<persia> wgrant: That's good to hear.  How do you think it ought be implemented so that all source NEW packages land in packagesets?
<crypt-0> any movement on the upcoming appaurmor patch in karmic-backports?
<wgrant> persia: Arrrrrgh queue UI.
<wgrant> it scares me.
<persia> wgrant: I may have misunderstood previously.  I had thought I remembered cjwatson saying that it defaulted those with component-based upload rights, rather than packageset-based upload rights.
<persia> wgrant: I don't care about UI.  At a pure conceptual level: how can Soyuz allow arbitrary packages to land in NEW, even for folk that do not have upload rights to any component?
<persia> If that's trivial, then my issues are solved.  Archive Admins can land stuff as appropriate, and the rest is social.
<wgrant> Ah. So. At the moment you need to have upload rights to the upload component. That's a bit of a strange definition, since the upload component is always universe. As I suspected, that can be easily relaxed to any privilege at all if people agree.
<persia> wgrant: So theoretically we could grant ~ubuntu-dev upload rights to the upload component, assuming agreement?
<wgrant> persia: Better to fix the code.
<wgrant> The potential social problem is that archive admins would have to verify permissions themselves.
<wgrant> Unless LP did a nice highlighting thing for this case.
<persia> wgrant: What do you mean by "fix the code"?
<wgrant> persia: Adjust the code to permit a NEW upload if the signer holds any upload privilege to the archive.
<wgrant> Rather than requiring permissions to the default component.
<persia> OK.  This makes sense.  Now, that sorted, what can we do for archive admins to reduce the chance that someone uploads something to NEW and can never upload it again?
<persia> I'd prefer that not to require an application to the TB for an extended package set
<persia> (although the entire proposal *does* need TB approval)
<wgrant> Very difficult.
<persia> Any ideas?  I'd rather not implement something that coudl so easily lead to that social failure.
<persia> wgrant: So, to get back to your original question: the good reason that NEW upload rights shouldn't be gratned to package(set)-specific developers is that we have no idea how to model that sanely yet :)
<wgrant> persia: So it seems :/
<persia> wgrant: Depending on one's philosophy, this may not be a real issue.  Many package-specific developers are not yet trusted with wider scope.  Many packageset teams can be expected to have at least one MOTU or core-dev with an understanding of archive-wide implications of adding packages.
<wgrant> persia: That's true.
<persia> So, where a packageset team needs something new, they get their capable member to push it, and then apply to the TB for a change.
<persia> We get reduced vanity packages from non-developers, and more stuff flowing through Debian.
<persia> It's suboptimal, but it's not yet terrible.
<wgrant> Then can we please revoke NEW uploads rights from just about everyone? :)
 * wgrant forces everything through Debian.
<persia> I'd support someone else's presentation to the TB of an argument blocking NEW upload rights to all but core-dev.
<persia> I wouldn't support the argument that everything needs to go through Debian.  Some stuff doesn't belong there (e.g. ubuntu-meta)
<wgrant> Right.
<pwnguin> psh, then i'd have to upload my mozilla weave minimal server package to debian instead
<wgrant> (hence "just about everyone")
<persia> Right.  Make a proposal :)
<ScottK> persia: The web U/I would also need some rework for archive admins that don't have shell access.
<persia> ScottK: Would that need change for the class of source NEW?  I thought source NEW didn't have useful web UI already.
<ScottK> I can do source New just fine.
<ScottK> It's just that I only have the 4 existing componenents as targets for the package (Universe being default)
<persia> packagesets and components are distinct layers.
<persia> Can you also use the LP API to flip bits between packagesets?
<ScottK> dunno
<persia> OK.  Let me ask differently: what do you think you can't do in the Web UI that would be required to allow other folk to upload NEW sources?
<ScottK> Select a packageset in the U/I.
<ScottK> Also some identifiable way to know what package set it was aimed at.
<persia> I think packagesets are entirely managed via the LP API (whether one has shell or not).
<persia> No reason it can't be exposed in the UI, but I'm not sure that shell/no-shell matters for that.
<persia> The identifiable way to know what package set is the right target is the hard problem that meant wgrant didn't just go fix this in Soyuz today.
<wgrant> ScottK, persia: Packagesets are indeed managed through the API. One must be a TB member to create them, or the owner of the packageset to alter them.
<persia> wgrant: Is there any necessary relation between a packageset owner and people with access to a packageset?
<wgrant> persia: None.
<persia> Cool.  I was worried there for a bit.
<wgrant> The current owner is in all cases the techboard.
<persia> That matches my expectations.
<lifeless> when does motu lose upload-everywhere-but-main ?
<lifeless> e.g. when should I make a push for core dev
<persia> lifeless: As soon as it can be implemented.  The necessary decisions have already been taken.
<lifeless> would you cheer for me?
<persia> lifeless: Realise that in practice when this is implemented MOTU will gain upload access to some of main, and lose upload access to mono packages in universe (at the present time).
 * lifeless isn't about to cry over mono
<wgrant> So some of the mono stuff will be in the core exclusive set?
<persia> lifeless: I've sponsored none of your uploads to main, nor done close code review on any of them, so no.
<persia> wgrant: No, it's that the Mono/CLI team got approved at the last TB meeting, so MOTU will lose access to that in addition to the packagesets in main.
<lifeless> persia: :(. You know there is the 'good person' aspect :P
<persia> lifeless: Don't try to convince me to change my criteria for approving core devs :p
<lifeless> persia: not going to!
<persia> lifeless: But really, apply to core-dev if you want to be core-dev, as you might apply to any packageset.  Don't let the changes in MOTU drive that decision.
<lifeless> persia: my feeling is I don't do enough regular work; I've been kindof-meaning-to for ages
<wgrant> persia: So membership in a package set now excludes generalists? I thought it was explicitly decided that that was a bad thing.
<persia> For the medium future, MOTU will only get access to *more* packages when components go away.
<persia> wgrant: No, it specifically excludes MOTU, based on the spec providing a definition for MOTU in the new world.
<wgrant> Ah, I guess I should keep more up to date with TB minutes.
 * wgrant reads.
<persia> wgrant: More concretely, a sufficiency of folk (including myself) felt that there were enough developers who would be *glad* to have less responsibility and focus on QA and archive-health for packages inherited from Debian that it made sense to have that be separate from the "Generalist Developer" category/
<wgrant> persia: Good. That had always been my largest concern about the reorg.
<persia> So the idea being that MOTU can have smaller scope and focus on making the unseeded stuff really work, rather than that these people are losing access (because access only goes away when someone else steps up to help enough that MOTU no longer needs access).
<wgrant> But I guess it needs Soyuz changes.
<wgrant> Definitely.
<persia> Yep, but that's the future.
<persia> The hard part (and part of why the discussion took over a year) was in finding a way to frame the definition of MOTU as a positive thing.
<lifeless> also, we should get the bzr packaging team in debian to have access to bzr packages in ubuntu nder a packageset
<persia> lifeless: Just apply to the TB.  I'd like the DMB to vet any suggested members of the packageset maintainance team that aren't already UbuntuDevelopers, but that's not strictly necessary.
<lifeless> persia: packagesets aren't active yet though, right?
 * dmb growls
<persia> lifeless: They are indeed, and have been since December, at least.
<lifeless> \o/
<persia> lifeless: But the first packageset not based on an Ubuntu Flavour was approved last Tuesday.
<wgrant> There are lots of LP glitches, too.
<persia> Well, second actually.  The first was kernel stuff, but that's kinda special (and kernel stuff was technically the first ever packageset)
<persia> (that was about a year ago, I think, but I'd have to check logs for a precise timing)
<pitti> Good morning
<pitti> tkamppeter_: o/
<lifeless> persia: so is mono a 'restricted package set'
<lifeless> ?
<persia> lifeless: No.  There are currently no restricted package sets.  I hope we can continue with that.
<persia> A restricted packageset implies we have failed in our selection criteria for core-dev.
<lifeless> persia: so I don't understand why motu wouldn't be able to upload to them, if we wante dto.
<lifeless> https://wiki.ubuntu.com/ArchiveReorganisation/Permissions
<wgrant> Because MOTU will be redefined.
<lifeless> claims two things:
<wgrant> That page is out of date
<lifeless> restriced package sets allow looser criteria for core-dev
<wgrant> This is what I hadn't realised until a few minutes ago.
<persia> https://wiki.ubuntu.com/Specs/LucidMOTU
<lifeless>  /argh/
<persia> wgrant: *was* redefined.
<wgrant> persia: Well, the definition is approved but not in place.
<persia> wgrant: Soyuz bugs aside it is :)
<persia> But yeah.
<persia> Anyway, MOTU needs another month or two to adjust to the new team model anyway.
 * persia repeatedly advocates redundancy with favor and encourages repetition
<persia> And one can hope that we have some clear definition of what to do in Soyuz first.
<lifeless> persia: I cannot parse the 'definition of responsibility' section
<persia> As we discussed earlier, the issue of NEW source packages is still messy.
<persia> lifeless: So, given a set of packages, there's a larger set needed to build those packages from source or install those packages.
<lifeless> (build || run)-deps
<persia> MOTU doesn't have responsibility for any of that: it belongs to people who volunteered to make that stuff work.
<lifeless> transitive, I presume
<persia> I'd hope so, although without any Soyuz implementation yet, or even a detailed spec, it's hard to say how it will finally be defined.
<lifeless> what is a 'explicit separated upload permission'
<lifeless> and how is it different to 'per-package upload rights'
<persia> It's upload rights for a packageset
<lifeless> the set-of-package language isn't a problem to parse
<lifeless> its the undefined terms
<lifeless> AIUI a packageset is the result of seed processing
<persia> Yeah well.  I wrote that in the middle of the night one night because the people who volunteered to write it hadn't yet, and it perhaps was insufficiently edited :)
<lifeless> but what is a 'non explicit' seperated upload perission
<persia> lifeless: Yes, but not all seeds generate packagesets.
<persia> Or rather packagesets that have separate upload permission.
<lifeless> what would an 'explicit unified upload permission' be
<persia> Two examples that come to mind immediately are ubuntustudio and lubuntu
<persia> lifeless: the permission granted to core-dev in the absence of restricted packagesets, or the permission granted to some whole-archive-upload team in the presence of restricted package sets.
<lifeless> persia: I would like you to do something like the permissions page referenced before. It was easy to understand: it defined its primitives, then used them.
<lifeless> I neither have enough confidence that I understand what you mean, nor enough definitions on that page [or unambiguously imported from some other page] to interpret the page correctly.
<ArneGoetje> persia: done
<persia> ArneGoetje: Thank you :)
<lifeless> you seem to imply *at least two* distinct mechanisms to get upload rights to a package, and that some of them will cut MOTU off, and  others will not cut MOTU off.
<persia> lifeless: I'm not tempted to edit a document approved by the TB, but I agree that would be a good edit.  I only wish you'd told me about it sometime in December or January :)
<lifeless> I think understanding is important, so that folk wanting to work on a package do not exclude MOTU by mistake.
<lifeless> persia: I was on leave in december, and horribly sick in january
<lifeless> persia: no internet == no feedback
<persia> lifeless: If a package has someone looking after it in any organised way, MOTU isn't responsible for it.
<persia> lifeless: Understand.  Please consider my comment a lament rather than criticism.
<ArneGoetje> persia: I have issued a MIR for poppler-data
<lifeless> anyhow, you could add an 'interpretation' section at the botto, e xplicit note the TB hasn't reviewed it, and once happy ask for blessing.
<lifeless> please excuse my keyboard
<persia> I'd really rather ignore it, continue the mailing list discussion on "Future of MOTU", and define a clear spec for how it is to be implemented in Soyuz at the next UDS.
<lifeless> ok
<lifeless> up to you
<lifeless> my concrete issue is this:
<persia> lifeless: Do you think the lack of an interpretation section is blocking in some way?
<lifeless> I can't decide if its better for bzr packages to have a [type 1] or [type 2] or [type N] request made
<lifeless> persia: I think its blocking in two ways; the first way is that what is being decided on may be subject to misinterpretations - so we're not agreeing to what we thought we were.
<lifeless> the dropping of restricted sets seems to imply keeping the generalist bar very high, [/me stops going down that path righ now. later. different channel too]
<persia> lifeless: What are the request types?  I only know of one: requesting the definition of a packageset.  That makes the uploaders the union of generalists (core-dev) and specialists (bzr-dev).  MOTU will no longer have interest in the package.
<lifeless> the second way is that unless people know what the options are - clearly and fully - they can't figure out the implications
<lifeless> persia: the lucid spec implies at least two types
<lifeless> seeds-with-explicit-seperated-upload-permission
<persia> lifeless: Hrm.  I think I need your help to understand.  I don't think I disagree: I just don't know what you mean.  Would you be amenable to helping me understand the confusion in a /query, and we can return here once we have a model?
<lifeless> per-package-upload-rights
<lifeless> + seed management is shaded as a different thing
<lifeless> sure
<persia> Oh, right.  Those are different.  per-package-upload only applies to a person: it doesn't otherwise affect a package.
<slangasek> jpds, cjwatson: seems the latest cdimage change to create trace files doesn't account for the directory already existing, causing every build to send mail; fixxoring now
<dholbach> good morning
<didrocks> cjwatson: I've rebase the changes with the last few hours one and made a merge a proposal for ubiquity (https://code.edge.launchpad.net/~didrocks/ubiquity/copy_wallpaper_cache/+merge/20434)
<tkamppeter> pitti, hi
<zgreg> https://bugs.launchpad.net/ubuntu/+source/libass/+bug/529860
<ubottu> Launchpad bug 529860 in libass "Update libass to bugfix release 0.9.9" [Undecided,New]
<zgreg> am I doing anything wrong or does nobody care because the package isn't really maintained from Ubuntu's side?
<cjwatson> slangasek: thanks
<lifeless> there are more bugs than people to solve them.
<zgreg> of course.
<lifeless> so to make the update happen quicker, prepare the change and propose it to ubuntu-sponsors
<zgreg> I'd do it myself if I had the necessary privileges
<lifeless> you can do everything except the upload itself
<zgreg> how so? put it into a PPA, for example?
<lifeless> do the update on your machine and check it builds, installs properly etc
<lifeless> you could use a PPA to do this
<lifeless> then attach the necessary new files to the bug report
<lifeless> and follow the normal sponsorship process to get a -sponsor to upload it
<arand> zgreg: The attached debdiff is the key point, PPA allows for easy testing
<persia> Generally we look for a diff.gz (or similar) that includes the packaging of the new vesion.
<lifeless> for a new upstream, that probably means a  new orig tarball and a new diff.gz. A debdiff will help make it easy to review.
<arand> zgreg: Hang on, ignore me...
<persia> I generally don't like to see the new orig tarball, preferring to use a watch file or get-orig-source rule.
<Laney> I usually construct the diff for review myself using interdiff
<zgreg> is this procedure documented somewhere?
<lifeless> there are two parts
<lifeless> standard development - thats documented under the packaging docs
<lifeless> and sponsorship - also documented
<lifeless> all on the wiki
<slangasek> cjwatson: btw, do you know why component-mismatches is empty?
<cjwatson> IOError: [Errno 2] No such file or directory: '/srv/launchpad.net/ubuntu-archive/ubuntu-germinate//all_netbook_lucid_i386'
<pitti> apw: FYI, -15 kernel NEWed now
<cjwatson> Running germinate... ..gzip: /srv/launchpad.net/ubuntu-archive/ubuntu/dists/lucid/main/binary-lpia/Packages.gz: No such file or directory
<cjwatson> D'OH
<didrocks> asac: StevenK: I want to add gthumb for having a photo importer into UNE, do you want I add it too for armel?
<apw> pitti, most excellent thanks for the heads up
<cjwatson> brought up with soyuz folks
<persia> didrocks: Unless there's a really good reason for something to be arch-specific, it's probably better to just add for everything.  How many rdepds does it pull?
<didrocks> persia: 4, for 3 Mib of deb. The most issue is that it has been demoted, I should have a look there.
<persia> didrocks: IIRC it got demoted for no longer being seeded
<persia> didrocks: But yeah, just stick it in: otherwise the experience will be poorer only for people with a single architecture.
<didrocks> persia: ok, I'll try to look if we can put gthumb back as it now depends on libopenrawgnome which has always been in universe
<persia> Have fun with MIRs :)
<cjwatson> slangasek: fixed for next publisher run, thanks to mthaddon and bigjools
<didrocks> persia: ahah, I got used to ^^
<asac> didrocks: does it use mono?
<asac> ;)
<cjwatson> whoops, I broke 'man -l' for uncompressed files
<didrocks> asac: if you really want, I can bring f-spot back :p
<didrocks> less work for me ;)
<asac> lol
<ogra> seb128, fyi, with todays upgrade evo seems to behave again, no 100% CPU usage anymore for me
<seb128> ogra: ok good
<nigel_nb> siretart, siretart`: just letting you know about bug 530481 has nvidia-185-libvdpau-dev as build-dep which is causing the issue
<ubottu> Launchpad bug 530481 in mplayer "nvidia-current build-dep breaks libgl if hardware isn't nvidia" [Undecided,In progress] https://launchpad.net/bugs/530481
<cjwatson> right, 'man -l' fixed
<tkamppeter> pitti, hi
<pitti> hi tkamppeter, wie gehts?
<tkamppeter> pitti, everything OK, you asked for me in the morning.
<pitti> tkamppeter: ah, because you pinged me in the evening when I was already away :)
<tkamppeter> pitti, it is about CUPS, Red Hat's patch still does not support DNS-SD-based broadcasting. We have really a regression against CUPS 1.4.
<tkamppeter> s/1.4/1.3/
<pitti> hm, wasn't this the entire point of that avahi patch?
<pitti> tkamppeter: would it work without the patch, when using the compat api (as upstream does)?
<tkamppeter> pitti, is there really no chance to compile CUPS using its native DNS-SD support?
<mpt> mvo, good morning, thanks for the instructions about how to try the subcategories
<tkamppeter> pitti, one should try it. Perhaps it works with patches (also on the Avahi side).
<pitti> tkamppeter: well, you tell me :) you added it in the first place
<pitti> but the changelog says that cups doesn't build with avahi
<pitti> without the patch
<tkamppeter> I have quickly taken this Red Hat solution because we were shortly before Karmic's FF and wanted to get CUPS 1.4 in.
<tkamppeter> pitti, perhaps one can get it to work with the compat API, perhaps now where the compat API development went on.
<tkamppeter> pitti, The Red Hat patch does only half the business, it only makes the DNS-SD backend work, so that printers can be discovered and used via DNS-SD.
<pitti> tkamppeter: ah, so that's for client-side detection, but not for server-side broadcasting; understood
<ogra> seb128, sorry, i take back the above ... back to 100% cpu usage, now its sitting at "recieving mail" since a while
 * ogra wonders if there is an issue with POP3 handling
<Q-FUNK> pitti: morning!  is there any way you could help with https://bugs.launchpad.net/ubuntu/+source/apport/+bug/528680
<ubottu> Launchpad bug 528680 in apport "apport-collect repeatedly crashes" [Undecided,New]
<tkamppeter> pitti, .configure finds my installed compat API.
<tkamppeter> pitti, problem is that it cannot determine the version of the dns_sd API.
<tkamppeter> pitti, config.log says 'kDNSServiceFlagsShareConnection' undeclared
<mvo> mpt: sure, np - I hope it helps you to get started, if anything is odd, please let me know (might be bugs etc)
<pitti> tkamppeter: seems the old avahi compat interface simply doesn't implement this?
<pitti> Q-FUNK: the error message can presumably be made more friendly, yes
<Q-FUNK> pitti: actually, the issue is that apport-collect is currently borken.
<pitti> Q-FUNK: I just ran apport-collect 528680, and it worked fine
<Q-FUNK> pitti: ok, so what do I and 10 other people (found in a duplicate bug) are missing?
<pitti> it still doesn't work for you?
<pitti> Q-FUNK: it's ultimately bug 336866; I already have lots of workarounds for that, but apparently not enough
<ubottu> Launchpad bug 336866 in lazr.restful "When adding tag or updating description, lp_save() gives "HTTP Error 412: Precondition Failed"" [High,Confirmed] https://launchpad.net/bugs/336866
<Q-FUNK> pitti: ok.  recommendations to work around the issue and succeed at attaching the extra debug info?
<pitti> Q-FUNK: I'm afraid there's no workaround; it needs a code change to apply a workaround in apport
<Q-FUNK> ok
<Q-FUNK> so the only other alternative is to file a new bug, with the new apport hooks for that particular package added?
<pitti> that should work, yes
<tkamppeter> pitti, is it possible that the DNS-SD API which CUPS is using does not exist as free software?
<pitti> tkamppeter: could be; after all, it's written against Apple's APIs
<tkamppeter> pitti, this would mean that fom CUPS 1.3 top 1.4 the DNS-SD broadcasting feature got removed from Linux.
<tkamppeter> pitti, how should such a regression be handles?
<pitti> tkamppeter: (1) shrugging, (2) adding the new API to avahi; I don't see another way?
<mpt> mvo, sorry, I forgot how to update the index after changing the categorization. ./utils/update-software-center returns "ImportError: No module named softwarecenter.enums"
<tkamppeter> pitti, it seems that SUSE has stopped at CUPS 1.3.11, I do not find any SUSE RPMS of CUPS 1.4.x.
<pitti> tkamppeter: how much API is it missing? if it's just missing one symbol, perhaps cups can be patched to not use it; after all, it didn't need it in 1.3 either
<pitti> tkamppeter: svn blame should find the patch which introduced the usage of that symbol
<mvo> mpt: the system one should work fine, or use PYTHONPATH=. utils/update-software-center - but running that should not be needed, it should pick up changes in the .menu file after a restart of s-c
<mvo> mpt: bad news btw, xapian does not support "*foo*", only "foo*", I'm investigating (with upstream) what can be done. maybe we need to postpone it. sorry for that
<mvo> (wildcard searches)
<mpt> mvo, what do we need "*foo*" searches for?
<mvo> background picutres are speced as "*-backgrounds*"
<mvo> themes as "*-themes"
<mpt> mvo, that doesn't need to be a live search, that's a one-time categorization whenever Packages.gz changes, right?
<mvo> the ttf* and otf* is no problem
<mpt> I thought xapian was just for when you're typing stuff in the search field
<mvo> mpt: all categories are mapped to xapian querries internally, that is not impossible to change, but the current design is nice and elegant, I would really like to keep it
<mpt> mvo, if you kept them all as xapian queries, I imagine the query involved in fixing bug 507042 would be hideous :-)
<ubottu> Launchpad bug 507042 in software-center "All graphical packages are listed in 'Get free software > System packages'" [Medium,Triaged] https://launchpad.net/bugs/507042
<mvo> mpt: not really, its the "Type" that we can use to filter out graphical vs non-graphical.
<mvo> i.e. there is a property attached to each items for this
<mpt> mvo, well the summary is a bit out of date, it's more about "appears in any other department vs. doesn't"
<mpt> e.g. fonts shouldn't appear in "System" because they're appearing in "Fonts"
<mpt> (actually, the summary is correct, but it's only a subset of the problem)
<mvo> correct, for this using live querries is tricky
<mvo> (see also the mapping of other->system)
<mvo> same problem
<mvo> mpt: constructing the category list at update-xapian-index time opens up new problems like mapping a search in a departement to a query. this gets really ugly really quick (in the code)
<mpt> mvo, sorry I'm not familiar with the internal structure, but if you follow the #Genre algorithm for any new/changed packages whenever Packages.gz changes, then each item should have a static primary-department attribute
<mpt> mvo, so whenever anyone does a search in a department, the live query would be "show me items that have this primary-department value and that also match this search:"
<mvo> mpt: right, its not a question of "possible" vs "impossible" - its a question of how to map it to the code structure. its simpler to describe a solution than to implement it
<mpt> undoubtedly :-)
<didrocks> cjwatson: in fact, the function "casper user" doesn't work in ubiquity for install mode (it's root) as there is no SUDO_USER variable. As I need the gconf value for the ubuntu user, I don't get the wallpaper cache, any idea?
<cjwatson> hm, really?  that's odd
<cjwatson> didrocks: ok, just do what you were doing then, we'll refactor it later
<didrocks> cjwatson: ok, I'll update the merge proposal then in few minutes (it took me some time to find why the caching wasn't working with that code in install mode :))
<pecisk> hi people, will NetworkManager 0.8 will make a cut into Lucid, or you will stick with 0.7.x?
<asac> pecisk: huh?
<asac> pecisk: 0.8 final is in already
<asac> and we had 0.8-pre in karmic already (e.g. 0.7.9xx)
<pecisk> missed that
<pecisk> allright, thanks for answer
<tjaalton> looks like the dhclient-{enter,exit}-hooks aren't run when network-manager is used?
<tjaalton> though it appears to use dhclient
<tjaalton> also, mounting network shares is racy, since the DNS isn't necessarily functional yet
<tjaalton> but where to file a bug?
<pecisk> Huh, seems like CD reading errors isn't because of CD-RW https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/461815 Kernel boots up fine, then comes CD errors and then very long waiting for squashfs and friends to load, as CD drive seemingly struggles to read it
<ubottu> Launchpad bug 461815 in linux "9.10 rc livecd takes a long time to boot, showing errors" [Undecided,New]
<tjaalton> ok so mountall is racy by design.. how confusing
<ogra> makes booting more exciting that way :)
<tjaalton> and debugging too
<zul> is it possible for someone to binary new for php 5.3?
<zul> Riddell: ping can you binary new php 5.3 for me?
<Riddell> oh aye, it's my admin day so it is
<Riddell> 151 packages in New queue, good to know we take feature freeze seriously
<Riddell> zul: where's the feature freeze exception for this?
<zul> Riddell: https://bugs.launchpad.net/bugs/527286
<ubottu> Launchpad bug 527286 in php5 "FFE for PHP 5.3" [Wishlist,Fix released]
<Riddell> groovy, accepted
<zul> Riddell: thanks
<persia> geser: nixternal: soren: We'd like your help in -meeting :)
<tkamppeter> pitti, I succeeded to compile CUPS 1.4 without RH patch and without adding any new or Universe package.
<pitti> tkamppeter: yay! you could drop teh usage of the new symbols?
<tkamppeter> pitti, I simply do s/kDNSServiceFlagsShareConnection/kDNSServiceFlagsShared/ on the whole source tree and CUPS compiles.
<tkamppeter> There was only one offending symbol.
<pitti> sweet
<tkamppeter> pitti, kDNSServiceFlagsShareConnection is for an additional functionality which Avahi does not have bug apples (free software) mDNSResponder has. Probably one would need to add Apple's mDNSResponder to our distro. License is BSD.
<Keybuk> tkamppeter: BZZT
<Keybuk> mDNSResponder is Apache 2.0
<Keybuk> like most of Apple's open source stuff
<Keybuk> we already have a Multicast DNS responder though, Avahi
<Keybuk> if that's missing a feature, get it added to Avahi
<ogra> Keybuk, is there some guarantee that if i boot lucid with devtmpfs.mount=0 udev will cope ?
<Keybuk> ogra: udev should cope just fine
<ogra> cool !
<Keybuk> udev doesn't really care
<Keybuk> you may encounter bugs with other things
<Keybuk> but they are bugs, and you should file them, and I'll fix them
<ogra> well, i'm trying to use the same kernel across all VMs for rootstock for karmic and jaunty that needs devtmpfs.mount=0 ... i was wondering if i need to special case it for lucid, but that sounds good
<Keybuk> ogra: why devtmpfs.mount=0 ?
<Keybuk> that doesn't really make sense
<Keybuk> that's only used if you don't have an initramfs
<Keybuk> and even with that, devtmpfs is still "supported" so will be just mounted by mountall
<ogra> because qemu doesnt boot without setting it and i dont use initramfs *and* use jaunty/karmic
<Keybuk> why doesn't qemu boot?
<Keybuk> all that option does is cause /dev to be mounted by the kernel
<ogra> it moans about /dev ... i dont have the exact error handy atm
<ogra> right, i suspect udev tries to create device nodes that are already there
<Keybuk> no, udev copes perfectly with devtmpfs being mounted
<ogra> if you really want to support that case i can file a bug
<ogra> but its a very special corner case
<Keybuk> in fact, even if you use devtmpfs.mount=0 - devtmpfs is mounted *before* udevd starts
<ogra> and devtmpfs.mount=0 works just fine
<Keybuk> right, but I want to understand this issue
<Keybuk> you're telling me something *very* strange
<ogra> by what is it mounted ?
<Keybuk> ogra: mountall
<ogra> hmm, but not in karmic
<ogra> or jaunty
<ogra> my probs are in jaunty and karmic with a lucid kernel and no initramfs
<Keybuk> karmic and jaunty won't understand devtmpfs.mount=0 either
<ogra> the kernel does
<Keybuk> oh, sorry
<ogra> apparently
<Keybuk> you did not make *that* clear
<ogra> i just wanted to know if lucid would cope if i keep devtmpfs.mount=0 a permanent setting :)
<ogra> so i dont have to special case karmic and jaunty
<ogra> but you answered that already
<ogra> :)
<Keybuk> I'm just wondering why jaunty and karmic fail here
<Keybuk> karmic should see that /dev is already in the mount table
<ogra> i think i had some bug with error messages ...
<Keybuk> aha!
 * ogra digs
<Keybuk> but then karmic won't copy /lib/udev/devices over I guess
<Keybuk> so you might be missing /dev/pts and /dev/shm
<ogra> yeah, something like that was in the error msg
<Keybuk> yeah that makes sense
<Keybuk> not sure why jaunty would fail
<ogra> sigh, why did LP drop the "show all bugs ever reported" thingie
<Keybuk> lucid with devtmpfs.mount=0 and no initramfs will have a brief period where you don't know what *is* on /dev
<Keybuk> as long as you have a /dev/null and /dev/console node in there, you should be ok
<ogra> http://ynezz.true.cz/qemu.png
<Keybuk> mountall will mount devtmpfs on /dev and then carry on
<ogra> thats the error i got for the karmic bug
<Keybuk> Upstart uses /proc/self/fd now, rather than /dev/fd, to avoid other complications
<Keybuk> ogra: yay, yeah that fits my understanding of what karmic would do -- I'd be interested in seeing the jaunty error too
<ogra> i dont have a report for jaunty atm
<ogra> just IRC reports where i told people to try devtmpfs.mount=0 which helped
<tkamppeter> Keybuk, in Avahi the kDNSServiceFlagsShareConnection functionality is not included, an upstream bug is already reported (http://www.avahi.org/ticket/303) but not fixed.
<Keybuk> tkamppeter: I'm sure upstream welcomes patches
 * ogra really hopes people will soon stop building jaunty rootfses with rootstock ... 
<Keybuk> ogra: I wonder whether jaunty fails in Upstart somewhere
<Keybuk> Upstart in jaunty does rely on /dev/fd being a symlink to /proc/self/fd
<ogra> i'll try a testbuild
<Keybuk> devtmpfs won't have that symlink
<shtylman_> \sh: anything new on bug: #522106 ? its a blocker for #519996 and likewise the freeze exception request for perftools
<Laney> Can TB members please comment on the proposed CLI/Mono packages that I emailed out last week?
<Keybuk> ogra: of course, Upstart should then just pipe the whole shell script on the command-line - but there may be an issue there somewhere
<Keybuk> oh, hmm, jaunty has 0.3.9 ... wonder whether that didn't do that
<ogra> Keybuk, i'm building an ubuntu-minimal now ... will take 30min or so
<ogra> i'll tell you waht i see with or without devtmpfs
<Keybuk> thanks
<james_w> mvo: we won't be having the new python-apt API in lucid?
<mvo> james_w: I hope so, I did a bunch of work on this last week, but there are some small compat issues left
<james_w> oh ok
<james_w> I got a patch to use it, and wondered if I should implement compatibility with the old one so not to diverge from Debian
<mvo> james_w: lets talk tomorrow or so about it, its definitely a goal of me, because it will make the next LTS upgrade much less painful
<mvo> a bit unfortunate timing
<james_w> yeah
<mvo> (after FF, I will need a FFe)
<james_w> not a problem my end
<james_w> I'll probably do it either way to facilitate backporty
<pitti> slangasek, Keybuk: is the hard plymouth dependency in cryptsetup really necessary? wouldn't it just ask for the password on VT if plymouth isn't installed? (it used to in the past)
<Keybuk> pitti: I would argue cryptsetup's VT code should be ripped out
<Keybuk> and it should hard-depend on Plymouth
<Keybuk> otherwise it's always going to be running the risk of stealing VTs from other things, including X!
<pitti> Keybuk: X?
<pitti> X should certainly not start yet if things in /etc/crypttab (root, /home) aren't mounted yet
<ogra> Keybuk, jaunty seems to cope even without devtmpfs.mount=0 being set
<Keybuk> ogra: cool, that makes sense
<Keybuk> pitti: why?
<pitti> Keybuk: either way, once the scripts only talk to plymouth and nothing else, the depedency is probably justified; but I thuoght the text fallback was still in
<Keybuk> pitti: you could put nobootwait in fstab for /home
<Keybuk> then have cryptsetup crash X :)
<pitti> how would you enter the home password while gdm is already up?
<Keybuk> one of the whole reasons for picking plymouth was that it solves the entire "we need to ask for things during boot" problem
<Keybuk> so why is the hard dependency a problem?
<ogra> Keybuk, btw, id /dev/root responsibility of the kernel or udev ? (its missing in lucid and forces me to add an entry for / to fstab to boot)
<ogra> s/id/is/
<pitti> I can't purge plymouth, at least not without purging cryptsetup
<pitti> Keybuk: so plymouth has a kind of X overlay where cryptsetup could ask for the password while X is already running?
<apw> is there a process for getting people approved to be ops on specific channels?
<Keybuk> pitti: it's supposed to have
<pitti> but I need cryptsetup to do udisks development and encrypted usb keys, etc., so it's inconvenient to have it not installed
<pitti> Keybuk: interesting
<Keybuk> pitti: why do you want to purge plymouth?
<pitti> Keybuk: I want to have bootable systems? :-)
<Keybuk> ogra: nothing makes /dev/root
<Keybuk> pitti: you could help *fix* things instead, y'know :p
<ogra> it used to be there in karmic
<Keybuk> ogra: probably by chance/accident/fluke
<ogra> hmm
<zgreg> what does plymouth do without a framebuffer, anyway?
<Keybuk> zgreg: there's always a framebuffer
<apw> Keybuk, ogra isn't /dev/root the fake name of the device that the original ramfs is mounted from?
<persia> Keybuk: Even on systems with no video out?
<ogra> apw, i thought so too
<Keybuk> persia: systems with no video out have a serial console - and plymouth can do text on that
<ogra> apw, which is why i'm surprised that its gone in lucid
<Keybuk> apw: only if you use lilo and have ROOT=8:1 or something
<ogra> even mountall has it in its defaults
<apw> ogra, i am not sure i ever existed did it?
<persia> Keybuk: Not necessarily
 * ogra boots the jaunty install he just built 
<ogra> lets see
<pitti> Keybuk: can't be everywhere... I got as far as checking fuser, but beyond that I have no clue where to start; any suggestions?
 * persia has a system with neither video out nor serial console
<apw> ogra, it doesn't represent the real root filesystem
<Keybuk> ogra: mountall always gets root from mountinfo - whatever is in fstab as the device means nothing ;-)
<Keybuk> persia: you have some kind of console :p
<ogra> Keybuk, well, all i can say is that lucid doesnt boot my qemu armel images if i dont have an entry in fstab, karmic and jaunty didnt need it
<apw> ogra, i don't even see it mentioned in /proc/mounts any more ...so its not clear why you'd be needng it when booted
<Keybuk> ogra: kernel mounts root, not mountall ;-)
<persia> Keybuk: Really, I don't.  I can solder in a serial console, but it's an optional extra kit to buy.
<ogra> god, jaunty booted sloooow
<Keybuk> persia: you have a console device in the kernel, even if it's being faked
<persia> And plymouth spits text at that, and all is good?
<ogra> hmm, right, jaunty doesnt have /dev/root either
<persia> (even if I never see it)
<Keybuk> ogra: to my knowledge, the only thing that ever made /dev/root is initramfs-tools if you boot with the really old boot protocol
<apw> so where the heck is anyone getting that string from
<ogra> so what prevents me from booting lucid without fstab entry
<Keybuk> we support it still
<Keybuk> but nothing *makes* it if you're using anything more recent
<Keybuk> like, say, grub
<Keybuk> or grub2
<apw> Keybuk, ogra i bet its initrd format things which use it
<Keybuk> possibly
<Keybuk> but again, it's up to them to mknod it
<zgreg> I don't like that plymouth has so many dependencies
<ogra> i dont use initrd with qemu ... so that might be
<apw> don't your arm things use that crap?
<ogra> but still i didnt use initrd with jaunty/karmic either
<ogra> and there i could boot without fstab entry
<Keybuk> ogra: which filesystem is fstab on?
<apw> ogra, is it in your /proc/mounts list?
<ogra> Keybuk, ext2
<Keybuk> ogra: no, I mean which filesystem
<Keybuk> is it on the "root filesystem" by any chance?
<ogra>  /dev/sda
 * ogra doesnt get the question
<Keybuk> because you're telling me that you can't mount the root filesystem unless details of it are in a file which you can't access until it's mounted ;-)
<apw> cirtainly that must be occuring in userspace
<ogra> Keybuk, i cant *boot* :) unless i add a fstab entry
<apw> if mountall is complaining about it ... as we mounted it to talk to it
<ogra> so / doesnt get mounted ...
<Keybuk> mountall won't care
<Keybuk> it's possible it won't get remounted rw without an fstab entry
<ogra> and i looked at mountall defaults where i found 7dev/root
<apw> now that is believeable
<Keybuk> and won't get fsck run ;)
<ogra> which made me think its that ...
<Keybuk> nah, that field for the root filesystem is utterly ignored
<Keybuk> I just stuck /dev/root in there to support lilo booters
<Keybuk> which will have /dev/root in mountinfo for it, so it matches
<apw> Keybuk, of course the world is utterly different on lucid if you don't have an initramfs right ... as we do that devtmpfs automount magic
<Keybuk> apw: I still want the kernel to automount /proc and /sys ;-_)
<apw> Keybuk, heh
<ogra> apw, well, it works fine without initrd ... apart from the fstab entry i need now
<Keybuk> apw: though I've worked around that now by having init mount /proc and /sys ,g>
<Keybuk> ogra: what happens without the fstab entry?
<ogra> let me fins a lucid qemu image :)
<ogra> *find even
<Keybuk> because without an entry in /etc/fstab mountall will use the one in /lib/init/fstab instead
<Keybuk> and without that, it'll use what's in /proc/self/mountinfo
<Keybuk> so it's utterly impossible to end up without something ;)
<apw> ogra, also what is the entry as you need it to be to be able to boot?
<ogra> apw, any entry for / works ... (device/partition or uuid)
<Keybuk> ogra: what if you just copy the entry from /lib/init/fstab ?
<Keybuk> does that work?
<ogra> let me quickly try to reproduce i currenbtly only have images with ftsab entries
<flower> I tried to build the devel package fluid for ubuntu on the opensuse buildservice, but it looks like something is wrong in the code:
<flower> https://build.opensuse.org/package/live_build_log?arch=i586&package=fluid&project=home%3Aroooz%3Akarmic&repository=xUbuntu_9.10
<ogra> Keybuk, first thing i see is that ureadahead terminates with 3
<ogra> Keybuk, and it hangs forever afterwards ... likely because it cant remount rw
<Keybuk> if it hasn't been told to remount rw, it won't wait to do it
<ogra> how would i tell it to ?
<ogra> apart from fstab
<Keybuk> that's my point
<ogra> or better, how do karmic and jaunty do handle that
<ogra> since it doesnt occur there
<Keybuk> add --debug to mountall
<ogra> god !
<ogra> can i make it log somewhere ?
<ogra> it ends with:
<mathiaz> could some from ubuntu-archive unsubscribe ubuntu-archive from bug 530468?
<ubottu> Launchpad bug 530468 in vlan "[FFE] Build udeb for vlan" [Undecided,New] https://launchpad.net/bugs/530468
<ogra> try_mount / waiting for device
<ogra> try_mount /tmp waiting for device
<ogra> err waiting for / in the last line
<Keybuk> ok, interesting
<Keybuk> could you boot with init=/bin/bash
<Keybuk> mount /proc
<Keybuk> and grab the root line out of /proc/self/mountinfo and paste it here
<ScottK> mathiaz: Done.
<nixternal> cjwatson, persia: sorry for not being at the meeting...I am quite busy this week due to my aunt passing away
<mathiaz> ScottK: thank you
<ogra> Keybuk, btw i boot with: root=/dev/sda mem=256M ro (/me goes grabbing proc, one sec)
<ogra> Keybuk, 14 1 8:0 / / ro,relatime - ext3 /dev/root ro,errors=continue,data=ordered
<Keybuk> ok, interesting
<Keybuk> is /dev mounted?
<ogra> ls /dev
<ogra> bah, damned focus !
<Keybuk> and is there a /dev/root in there?
<ogra> devtmpfs is mounted on dev
<ogra> (init=/bin/bash ...)
<Keybuk> and is there a /dev/root in there?
<ogra> nope
<Keybuk> ok, great
<Keybuk> so your problem is:
<Keybuk> - you had the kernel mount the root filesystem directly
<Keybuk> - rather than passing the actual root= argument, the kernel just claims it mounted /dev/root
<ogra> right with the root= line
<Keybuk> - there is no /dev/root in the devtmpfs the kernel created
<Keybuk> - there is no root fs entry in /etc/fstab
<Keybuk> - mountall has no idea what to wait for (it's waiting for /dev/root)
<ogra> so itz kernel bug ?
<Keybuk> - udev can't create the /dev/root symlink because it doesn't know what you mounted (the kernel isn't telling)
<Keybuk> no, not really
<Keybuk> I think this is behaving correctly
<persia> Um, root=(device) is very common as a boot argument for some bootloaders
<Keybuk> the missing link is that if the root filesystem is still listed as /dev/root by the time mountall gets to it, it should make that
<getxsick> hi, i don't know if it's a correct channe, but could you tell me which source package format is adequate for ubuntu? 3.0? or 1.0?
<Keybuk> persia: sure, but you also tend to have a line in /etc/fstab that tells the system the same thing ;-)
<persia> Keybuk: Not on the the retail device I use daily.
<cjwatson> nixternal: sorry to hear that
<ogra> Keybuk, well, it will confuse users coming from jaunty or karmic ... indeed i can mount with rw or hack rootstock to add a fstab entry (which is my current workaround) ... but i wanted to find the initial cause of it
<persia> Keybuk: The specific reason for this is that it's common for a rootfs to be copied between devices so the contents of the filesystem don't know how they are being mounted (and it's desired that it's portable).
<Keybuk> yes, yes
<Keybuk> you don't need to convince me this is a bug
<persia> In what is it a bug?
<Keybuk> you can tell I think it's a bug because I'm trying to triage it
<persia> heh :)
<ogra> :)
<Keybuk> rather than pointing at you and laughing ;-)
<Keybuk> we clearly have a gap here where if the kernel mounts the root filesystem, and it's not listed in /etc/fstab, we fail to boot
<Keybuk> but we can trivially find out what the kernel mounted
<Keybuk> stat("/") would tell us the dev_t
<Keybuk> it's also given in plain numbers in /proc/self/mountinfo
<persia> Keybuk: What if we're using something like ubifs where it doesn't necessarily have an associated /dev node?
<persia> (so mounted as none in the output of `mount`)
<Keybuk> persia: can you boot one of those as above and tell me what stat("/") and /proc/self/mountinfo say?
<ogra> then /proc/self/mountinfo should still have the info
<persia> Keybuk: Only with a jaunty kernel (I don't have a lucid kernel for such a device yet)
<Keybuk> persia: either kernel should be fine
<Keybuk> I'd like to know the answer, since it may affect the fix
<persia> Keybuk: /proc/self/mountinfo has "11 1 252:1 / / rw - ubifs ubi0:rootfs rw"
<persia> stat() requires me to write a program :)
<Keybuk> persia: there's a /usr/bin/stat
<Keybuk> persia: is ubifs listed in /proc/filesystems ?
 * ogra would assume such a kernel has it compiled in
<ogra> i.e. if its supposed to boot from ubifs
 * persia wants a faster device on which to check stuff
<ogra> heh
<ogra> i thought you like the netwalker :)
<persia> I do, but it can't keep up with Keybuk asking good questions whilst running firefox :)
<nixternal> cjwatson: thanks
<ogra> lol, run chromium :)
<persia> Keybuk: http://paste.ubuntu.com/387108/
<Keybuk> persia: and grep ubifs /proc/filesystems
<persia> Keybuk: http://paste.ubuntu.com/387109/
<persia> It's there, with nodev
<Keybuk> persia: it's nodev - so should work fine
<persia> Ah, so it's only an issue if it's not nodev?
<persia> OK.
<Keybuk> yes
<Keybuk> mountall doesn't wait for the device of a nodev filesystem ;-)
 * persia puts away the exotic use case
<Keybuk> I just wanted to make sure that your "exotic" case was properly dressed
<persia> Seems to be.  When I get a kernel, I'll file a bug if there's something funny.
<ogra> who knows, might not be *that* exotic anymore in the nearer future if more arm devices show up
<Keybuk> ok
<Keybuk> so back to me
<Keybuk> root=/dev/sdXY on kernel command-line, no initrd/initramfs, and root not listed in /etc/fstab
<Keybuk> we have the dev_t from mountinfo and from stat("/")
<Keybuk> but mountinfo says /dev/root, which is not created
<Keybuk> either
<Keybuk>  1) something should create /dev/root
<Keybuk>  2) mountall should mentally substitute /dev/root for /dev/block/MAJOR:MINOR
<ogra> 1) has to be devtmpfs, no ?
<Keybuk> I'm inclined to say that #1 is correct - since it means everything will work
<Keybuk> no, udev can create it as a symlink
<Keybuk> and if udev does that, it'll be in the SYMLINKS= list of the uevent
<Keybuk> which means mountall will just work
<ogra> where does udev come from before / is there ?
<Keybuk> (and other things piled on top will just work)
<Keybuk> ogra: / is there - it's mounted by the kernel <g>
<ogra> oh, right
 * ogra slaps forehead ... we try to remount :)
<Keybuk> so we basically need a udev rule that creates /dev/root
<Keybuk> it should be something like: if the root fs is listed as /dev/root in mountinfo, and the MAJOR/MINOR in mountinfo matches this block device, SYMLINK+="root"
<ogra> Keybuk, so the initial question still stands, why did it work in jaunty/karmic without /dev/root ? did mountall change that much ?
<Keybuk> ogra: jaunty/karmic had a bug that would have caused the root to be ignored
<Keybuk> which broke other things (nbd roots, etc.)
<ogra> ah
<ogra> yeah i remember ltsp bugs about that
<Keybuk> so I'm thinking
<Keybuk> mountall already parses mountinfo and already has all the information to make the decision
<Keybuk> we don't want a permanent udev rule to make a particular device /dev/root - it'll only go wrong
<Keybuk> and a rule that queries mountinfo for every block device would be slow
<Keybuk> so why not just have mountall write a temporary udev rule out
<Keybuk> if it sees that the root device (which it always has a pointer to) is on /dev/root
<Keybuk> it can write a /dev/.udev/rules.d/root.rules that contains:
<Keybuk>   SUBSYSTEM=="block", ENV{MAJOR}=="X", ENV{MINOR}=="Y", SYMLINK+="root"
<persia> Where X and Y are set based on the actual device detected as / ?
<ogra> if that works
<Keybuk> persia: exactly
<ogra> makes sense
<Keybuk> ogra: could you try this for me
<Keybuk> add to your test case a file /etc/udev/rules.d/root.rules
<Keybuk> with the content
<persia> Sounds sane, because the "I can't boot" is mountall being confused, and mountall would be resolving it's own confusion.
<persia> udev just sees another rule, and implements it, and presto, it works.
<Keybuk> SUBSYSTEM=="block", ENV{MAJOR}=="8", ENV{MINOR}=="0", SYMLINK+="root"
<Keybuk> ogra: ^ and then let me know whether that works
<Keybuk> persia: right, mountall writes a udev rule out so that it resolves its own confusion later
<Keybuk> and that same rule file solves any other program ever having the same confusion either :p
<persia> Right, but none of them ought have a chance to get confused before mountall
<ogra> takes a min
<Keybuk> persia: indeed, because udevd is started by mountall ;-)
<Keybuk> we could do this without mountall by something like:
<Keybuk>   SUBSYSTEM=="block", PROGRAM="is-this-dev-root", SYMLINK+="root"
<Keybuk> where is-this-dev-root contained code to grep through mountinfo, matching major/minor and checking against /dev/root
<Keybuk> but that's fairly expensive for every block device, and would be the same code as in mountall
<persia> Presumably that would get added by the package containing is-this-dev-root
<persia> And only be used if there was some reason *not* to use mountall in a particular installation.
<Keybuk> and really, we only need to do this once, and mountall already happens to do that
<Keybuk> well, if you're not using mountall, you won't have the bug where mountall is waiting for /dev/root to show up in /dev ;-)
<Keybuk> and one assumes you've already solved the remounting root issue, probably just by ignoring the problem
<ogra> it boots, i missed possible mountall errors though (forgot to take out --debug)
<Keybuk> ogra: it boots sounds like a win to me
<ogra> yeah
<ogra> yup, no mountall errors on second boot
 * ogra gets dinner ... bbl
<Keybuk> ogra: could you file a bug on mountall with the above for me
<ogra> Keybuk, oh, i think lool was so kind to do that already
 * ogra looks for it
<ogra> Keybuk, bug 527216
<ubottu> Launchpad bug 527216 in mountall "Boot hangs waiting for local filesystems if / isn't in fstab and / is only mounted ro" [Low,New] https://launchpad.net/bugs/527216
<\sh> shtylman_: nope...nothing...the patch from fedora is there..it removes the FTBFS bugger but I can't say, if this will break ABI with google-perftools...if you are more knowledged on this matter, please take over
<ogra> Keybuk, want it assigned ? i added the info about the rules file and its content
<shtylman_> \sh: won't perftools be compiled against it? what is the ABI problem then?
<ogra> Keybuk, assigned it to you ...
<shtylman_> \sh: I can compile both fo them... is there some set of actions I can take to move the process along? if libunwind builds and then perftools builds...
 * ogra really needs to go for that dinner else i get slayn ...
<Keybuk> thanks
<shtylman_> I am just unclear about what I can do ... cause from my end it seemed like it was just blocked on things to build
<\sh> shtylman_: if libunwind builds without changes (ftbfs because of some magic in glibc not liking what libunwind does or so)...and google-perftools builds with libunwind...please go ahead and force the FFe
<shtylman_> \sh: alright... I will try building both on my end here and see what happens.. (what do you mean builds without changes? does the patch to fix the first FTBFS count as cahnges?)
<\sh> 16:39:09  shtylman_ | \sh: anything new on bug: #522106 ? its a blocker for #519996 and likewise the freeze exception request for perftools                                                     â a|wen
<\sh> argl
<shtylman_> heh
<\sh> http://cvs.fedoraproject.org/viewvc/devel/libunwind/libunwind-disable-setjmp.patch?view=log <- this patch fixes the ftbfs but removes some lines
<\sh> s/lines/features??/
<shtylman_> \sh: right.. so if it builds with that and likewise if perftools builds on top of that... I should?
<\sh> shtylman_: read the comment from stefanpotyra...the fix from fedora fixes it...but stefan is right about what he says
<shtylman_> \sh: I see .. ok that makes sense... I will take a look
<\sh> shtylman_: feel free to invest more work into that matter..I'm a bit busy with work to deal with this right now..
<shtylman_> \sh: no problem... will let you know how it goes
<qense> What if you're compiling two or three binaries -- including a shared library -- from one source project and you want to link to that library inside the other two projects? What do you add to binaryname_SOURCES in the Makefile? Or should you add something elsewhere? I don't want include the library code in three binaries, that's a bit overkill.
<cjwatson> asac: sun-java6 is in the partner archive now.  is now a good time to remind you about the WI assigned to you on https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-dropping-sun-java6?
<cjwatson> slangasek: foundations-lucid-gfxboot-update is ready to land, pending the FFE request in bug 530713; would appreciate your comments
<ubottu> Launchpad bug 530713 in gfxboot-theme-ubuntu "[FFe] move live CD greeter functionality into ubiquity." [Undecided,Fix committed] https://launchpad.net/bugs/530713
<shtylman_> \sh: perftools is fine without the setjmp library so it is ok to not build that
<shtylman_> \sh: how should I indicate this on the various bug reports? I figure it needs to start with libunwind and that needs to build first
<mdeslaur> tjaalton: do you mind if I merge xserver-xorg-input-vmmouse? The current one in lucid is broken and the merge will fix it...
<mdeslaur> tjaalton: actually, scratch that, I'll just add the appropriate patch
<slangasek> cjwatson: FFe ack
<sebner> jdstrand: around?
<jdstrand> sebner: yes
<sebner> jdstrand: I just wanted to debdiff moin but found serveral issues, our cdbs is too old so some parts of the 1.9.2 debian/ update needs to be reverted and as I'm really am no cdbs expert (I hate it and don't use it) I'm wondering if you can give me a hand
<jdstrand> sebner: this is for the lucid merge?
<sebner> jdstrand: aye
<slangasek> pitti: the reason cryptsetup now depends on plymouth is that I removed 'console output' from the upstart job because this was generating console noise; and if we're no longer allowed to use the console, the non-plymouth fallback doesn't work
<slangasek> pitti: (aside from all the other reasons Keybuk gave)
<jdstrand> sebner: does MoM not work for you?
<sebner> jdstrand: I stopped using MoM a long time ago because most of the time (on more complex merges) fixing the MoM result took me more time than doing it by hand (partly automatically) :\
<lucas> hi, does an archive admin have time for a bunch of ruby-related syncs? (all 1.9->1.9.1 transition, universe, minor packages) list: ruby_syncs.txt
<lucas> oops, http://blop.info/pub/ruby_syncs.txt
<jdstrand> sebner: I am not familiar with the packaging issues you are facing and have not merged it in the past. I am working on the moin security updates for stable releases atm. I don't think I can help right now. I suggest asking the last person who merged it or if the FFe has been granted, I can just do it after I'm done with my updates
<sebner> jdstrand: I haven't touched it at all in the past and I'm wondering if the last uploader is capable of doing it. Nvm, I have no other plans for the evening anyways ;D
<sebner> pitti: is this a known issue when dmesg shows the external harddrive but doesn't mount it? Mounting by hand is possible but the folder is only browsable with root then :\
<mathiaz> what could cause the following error: useradd: cannot lock /etc/passwd; try again later.?
<mathiaz> happening during a package installation
<persia> mathiaz: Did you implement some cool parallel dpkg?  Aside from that, do you have other things that are locking /etc/passwd?
<mathiaz> persia: bug 523896
<ubottu> Launchpad bug 523896 in postfix "package postfix 2.6.5-3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/523896
<persia> It *shouldn't* happen for a quiescent system just running dpkg.
<mathiaz> persia: when installing jetty the error started to appear
<james_w> mathiaz: possibly bug 432964
<persia> mathiaz: Sorry.  Nothing obvious.  I'm curious if comment #6 implies chromium-browser
<ubottu> Launchpad bug 432964 in shadow "System crash in guest session locks /etc/passwd forever" [Medium,Confirmed] https://launchpad.net/bugs/432964
<highvoltage> is it just my imagination or is the ubuntu wiki way faster than usual today?
<mathiaz> james_w: hm - ok. I've reassigned the bug to the shadow package
<sabdfl> highvoltage: maybe those cables are starting to land in SA?
<highvoltage> sabdfl: seems so!
<JordiGH> We're considering using Launchpad for BTS. Does it have an email interface? Our BDFL is used to an email interface, doesn't like web.
<RAOF> JordiGH: You'd be better served in #launchpad, and yes.  It does have an email interface.
<JordiGH> Thanks!
<jono> didrocks, around?
<highvoltage> didrocks: congrats on making core-dev!
<stgraber> didrocks: congrats and sorry for not being there, I was somewhere between London and Geneva at the time ... (and for some reason I forgot to e-mail the DMB about it as I did for EMEA)
<persia> Could someone approve my mail to ubuntu-devel-announce@ please?
<persia> Err, or not.
 * persia fiddles sender addresses and tries again
<persia> OK.  Could someone approve my mail to ubuntu-devel-announce@ (really this time :) )
<cjwatson> persia: done
<persia> cjwatson: Thanks.
#ubuntu-devel 2010-03-03
<YokoZar> Is the new volume control applet an Ubuntu-originated thing or an upstream thing?
<YokoZar> (or both)
<persia> I was under the impression there was a new upstream for it that had so far only been adopted in Ubuntu.
<TheMuso> YokoZar: The new volume control is a DX team thing afaik.
<lfuser-119> hello.
<jdong> *scratches head*
<jdong> what are the new lucid compiz bindings?
<jdong> I just noticed super-a seems to do what alt-shift-up used to do
<jdong> never mind, ccsm answered that question
<RoAkSoAx> jdong, shoudl bug 530945 stay as backport or should be a SRU ?
<ubottu> Launchpad bug 530945 in keepalived "Please backport keepalived 1.1.17-2 to Karmic from Lucid" [Medium,Confirmed] https://launchpad.net/bugs/530945
<jdong> RoAkSoAx: if the debdiff in #5 on the orig bug is correct, then SRU
<jdong> or something equally trivial
<RoAkSoAx> jdong, ok thanks. I'll change the bug report then :)
<arose> Is there anyone who is even remotely responsible for maintaining xfonts-base, and more specifically the misc-fixed fonts? It's kind of frustrating to see that 4 (or 2 depending on perspective) old changes from upstream haven't been integrated
<crimsun> arose: X Strike Force <debian-x at lists dot debian>
<arose> Seems it finally has been merged... Would be nice to know not to waste time reporting bugs in launchpad in the future...
<TheMuso> 7/c
<robert_ancell> TheMuso, are you familiar with the new package process to add a package to Universe?
<robert_ancell> growlf (one of the developers of gdm2setup) is working on getting that into Universe (bug #531138)
<ubottu> Launchpad bug 531138 in ubuntu "[needs-packaging] python-gdm2setup" [Wishlist,Triaged] https://launchpad.net/bugs/531138
<robert_ancell> growlf, it should be called "gdm2setup" not "python-gdm2setup".  The "python-" prefix is only required for libraries
<growlf> Ahh.  ty.  Shall I change that in the bug?
<ScottK> Also we're past feature freeze for Lucid, so it'll need a compelling justification for getting in now.
<growlf> Do you want that here and now - or in an email?
<ScottK> In the bug.  It needs to get made into a feature freeze exception request
<robert_ancell> ScottK, does that apply for packages in Universe?
<ScottK> robert_ancell: Absolutely.
<robert_ancell> ok
<growlf> Ah. ok.
<growlf> Thank you.  Once I have that in - what is the next step I should take?
<robert_ancell> growlf, So my guess is that this wouldn't be included in Lucid (as it is easily installable from the PPA)
<robert_ancell> ScottK, Should the bug subscribe any groups? There doesn't seem to be any info in https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages as to who to pass the bug to
<ScottK> Subscribe ubuntu-release.  Look for general feature freeze exception information.
<robert_ancell> ScottK, and if it wasn't in feature freeze?
<ScottK> New packages get reviewed on REVU
<ScottK> !REVU
<ubottu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
<robert_ancell> growlf, ok, next step upload to revu as in the above comment
<dupondje> linux-backports-modules-nouveau-2.6.32-15-generic still in NEW ?
<dupondje> yep seems so :( and now nouveau is broken because of it :
<dupondje> :(
<StevenK> I'm working on it
<ejat> how about the other php-* ?
<Chipzz>  
<StevenK> dupondje: Accepted. It will take around 90 minutes, at best, to hit archive.u.c
<ejat> StevenK: owh ok thanks .. how bout the other php-* package?
 * persia highly suggests leaving archive admins to their work unless something is blocking a critical development workflow or is exceptional.  Time spent on IRC is time not spent processing the queues.
<lifeless> I suggest replacing archive admins with a small cron script.
<StevenK> ejat: No php-* packages are in NEW, the only one I can find is mapserver
<persia> lifeless: For some AA work, I think we can replace with a python script, but some of it still requires human intelligence (although the tools are slowly improving).
<lifeless> persia: indeed
<ejat> StevenK: but it will remove some other package rite?
<persia> (but there's 3 bugs that need be sorted before the python script can be deployed)
<StevenK> ejat: I'm not sure I understand what you mean.
<ejat> StevenK: http://paste.ubuntu.com/387442/
<StevenK> ejat: I have no idea why that is.
<persia> ejat: Those packages need porting.  That needs a developer, not an archive-admin.
<persia> (or else your archive is out of date)
<ejat> StevenK + persia .. ok thanks for the acknowledgement ..
<kirkland`> pitti: could you accept the most recent eucalyptus package for karmic-proposed?
<dupondje> StevenK: thanks :)
<lucent_> innocent question here, where to learn modern methods for adding Ubuntu package generation from a project source code?
<lifeless> #ubuntu-motu is a good place to chat about that
<lucent> thanks!
<lucent> lifeless: it's kind of quiet in -motu
<lucent> I wonder if the process is any different than http://www.debian.org/doc/maint-guide/
<didrocks> highvoltage: stgraber: thanks :)
<pitti> Good morning
<pitti> sebner: in that generality, no; please file a bug with "ubuntu-bug storage"
<pitti> kirkland`: will do SRUs soon again
<dholbach> good morning
<mtx_init> Good Night here in NY
<dholbach> ArneGoetje, Riddell: I was having a look at bug 463181 - seems like kde-i18n-zhcn is not in lucid any more?
<ubottu> Launchpad bug 463181 in ubuntu-translations "wrong dependency on language-pack-kde-zh" [Medium,Fix committed] https://launchpad.net/bugs/463181
 * cjwatson speeds up grub-probe filesystem queries by a factor of >10
<cjwatson> I like lots-of-bang-for-your-buck work
<ev> nice!
<tseliot> mvo: I think bug #467490 is really bug #459829 which should be fixed, at least in theory. Any ideas?
<ubottu> Launchpad bug 467490 in nvidia-common "nvidia drivers don't work due to -Q in obsolete /etc/modprobe.d/lrm-video" [High,In progress] https://launchpad.net/bugs/467490
<ubottu> Launchpad bug 459829 in nvidia-common "Upgrade from hardy to Karmic didn't remove lrm-video" [Medium,Fix released] https://launchpad.net/bugs/459829
<Riddell> dholbach: yes kde-i18n-zhtw isn't in lucid, it was translations for KDE 3
<dholbach> ArneGoetje: ^
<dholbach> thanks Riddell
<tseliot> cjwatson: is it ok to perform other operations after doing a db_stop in postinst scripts?
<cjwatson> what kind of operations?
<cjwatson> you should, in general, not use db_stop at all unless you are absolutely sure you know what it does
<tseliot> cjwatson: even things such as rm -f some_file
<cjwatson> it's a workaround for things better handled in other ways
<cjwatson> rm -f is fine
<pitti> cjwatson: oh, it's that much "not recommended"?
<cjwatson> but db_stop can break things you really don't expect
<cjwatson> pitti: yes
<pitti> cjwatson: I usually do it after I know I'm done with it, since later stderr output used to confuse it
<cjwatson> please don't - I can advise on other, better approaches
<cjwatson> it doesn't even really help much with that
<cjwatson> in many situations, STOP is effectively ignored (e.g. within the installer), so you need to make sure output doesn't go to debconf anyway
<pitti> cjwatson: ok, thanks; it's been years since I touched debconf, should I ever get to that case again, I'll do RTFM
<cjwatson> the only thing STOP was ever really useful for was making sure to disconnect debconf fds from daemons, and it's better to close fds explicitly at daemon startup
<cjwatson> basically it's nothing but trouble :)
<tseliot> cjwatson: I was asking as this script doesn't seem to remove the file (possibly because of dpkg --compare-version): http://pastebin.ubuntu.com/387535/
<cjwatson> that's completely wrong
<cjwatson> just delete the db_stop, what's it for anyway!
<cjwatson> I don't think it would cause the script not to remove the file, though
<tseliot> cjwatson: so if I remove db_stop will debconf require user interaction and execute my .config script? (just to be sure)
<cjwatson> tseliot: after calling db_stop, any following debconf commands may *break*.  it's not a clean shutdown
<cjwatson> tseliot: in any case, if that's in a postinst, the config script is executed before that db_stop - so it won't make any difference to that
<cjwatson> tseliot: if you don't want the config script to interact with the user, then don't call db_input/db_go in it :-)
<tseliot> cjwatson: ah, so is it wrong to call db_stop at the end of the .config script too? http://pastebin.ubuntu.com/387542/
<tseliot> (this is in nvidia-common)
<tseliot> it seemed to make sense when I read the documentation (a long time ago)
<cjwatson> it's almost always wrong to call db_stop at all
<cjwatson> yes, it's wrong there
<tseliot> cjwatson: ok, thanks
<cjwatson> just remove it from both your config and postinst, and things will probably work better with no downside :)
<tseliot> sure
<tseliot> cjwatson: I get no debconf prompt if I remove db_stop
<cjwatson> run with DEBCONF_DEBUG=developer to see what it's doing
<cjwatson> the question's probably just marked as seen from a previous run, or something
<tseliot> cjwatson: do you mean export DEBCONF_DEBUG=developer and install the package?
<tseliot> as it doesn't show anything this way
<tseliot> or is it something that I have to put in either the .config script or in the postinst script?
<cjwatson> I mean export DEBCONF_DEBUG=developer; if that isn't showing anything then perhaps your sudo configuration is eating the environment variable.  Try 'sudo DEBCONF_DEBUG=developer ...'
<tseliot> ah, ok
<tseliot> cjwatson: yes, that worked: http://pastebin.ubuntu.com/387559/
<tseliot> cjwatson: I guess it's my fault. Thanks for your suggestion
<cjwatson> tseliot: right, so by the looks of things either /usr/bin/nvidia-detector doesn't exist or nvidia-detector returns none
<tseliot> the latter
<cjwatson> tseliot: that config script has another serious bug right now
<tseliot> cjwatson: oh, what is it?
<cjwatson> tseliot: config scripts may only use things on the filesystem that are in Essential packages, plus debconf itself
<cjwatson> because they're run at preconfiguration time
<tseliot> oh
<cjwatson> tseliot: if you have to use nvidia-detector, then you need to move all that stuff to the postinst; the cost is that you lose preconfiguration
<cjwatson> if nvidia-detector is a relatively simple shell script then you might be able to embed it in the config script as an alternative, or something
<tseliot> cjwatson: what do you mean? I'm already sourcing /usr/share/debconf/confmodule in the postinst
<tseliot> nvidia-detector is a python script which relies on a library included in the same package
<cjwatson> tseliot: but when the config script is executed, your package may not have been unpacked yet
<cjwatson> /usr/share/debconf/confmodule is safe because it's in debconf; config scripts may rely on Essential packages *plus debconf*
<tseliot> cjwatson: right. Is there a way to call the config script in the postinst?
<cjwatson> tseliot: if you want that, just move the contents of the config script into the postinst, and delete the config script
<tseliot> I need to warn users about the fact that they're using an obsolete driver with a UI
<cjwatson> the only purpose of having a separate config script is to enable preconfiguration; if the structure of your questions is such that you can't use preconfiguration, then there's no point having a separate config script
<cjwatson> as long as you know that doing it this way means that upgrades will be interrupted in the middle to ask a question
<cjwatson> that said I suppose you're testing whether the binary exists
<tseliot> cjwatson: yes, this shouldn't interrupt upgrades with update manager as u-m deals with these things first (right mvo?)
<cjwatson> but what happens if this is a new installation?
<cjwatson> tseliot: er, no!
<cjwatson> tseliot: update-manager isn't special in this regard
<cjwatson> it doesn't magically reach in and run config scripts in a screwy way
<tseliot> cjwatson: I think update-manager includes part of nvidia-common already
<cjwatson> that is done by debconf, in the manner I described
<cjwatson> tseliot: we can't have correctness depend on people using update-manager
<tseliot> cjwatson: so the debconf UI will be used only for example if users dist-upgrade from the command line
<cjwatson> tseliot: the way you have it written right now, any upgrade using apt will use (at best) the version of nvidia-detector from the previous installed version of the package
<mvo> tseliot: sorry, I was not following the discussion. u-m includes parts of nvidia-common to do detection and removal of old drivers. but it should still work for people without (as cjwatson said). but if that means that people using apt-get see a debconf dialog in the middle of the upgrade that is IMO acceptable
<cjwatson> mvo: the thing is that it will get the logic wrong ... it'll use the previous version of nvidia-detector, etc.
<tseliot> right
<cjwatson> or maybe no version at all
<mvo> cjwatson: oh, sorry. I missed that bit of the discussion
<cjwatson> so it really needs to be moved into the postinst
<cjwatson> if update-manager has special nvidia-specific logic to make sure obsolete drivers go away before this question is even asked, basically duplicating the logic, then that's fine
<tseliot> yes, I assume that's the way it works now
<cjwatson> I agree that it's acceptable for people using apt-get to see a debconf dialog in the middle, if there's no alternative and if update-manager works around that bit specially.  what isn't acceptable is for upgrades using apt-get to actually be *wrong*
<tseliot> mvo: is this correct?
<cjwatson> so in that case, the correct fix is indeed to move the config script contents into the postinst
<tseliot> yes, definitely, that's a bug
<mvo> tseliot: update-manager has this logic, it embeds bits of nvidia-common from lucid on build and runs in on karmic->lucid (and hardy->lucid of coruse)
<mvo> I have not tested if its still working, but if the interfaces have not changed it should
<mvo> the code around it in u-m has not changed
<tseliot> cjwatson: so I should get rid of the config script and use this as the postinst script, right? http://pastebin.ubuntu.com/387565/
<mvo> tseliot: I'm happy to look at the u-m integration/test it after UI freeze
<tseliot> mvo: so that should work and I only have to fix the bug in nvidia-common so that we cover both cases correctly
<mvo> tseliot: ok, cool
<cjwatson> tseliot: you need to put '. /usr/share/debconf/confmodule' on the second line, and you can maybe get rid of the [ -x /usr/bin/nvidia-detector ] test now if that binary is in the same package or a package you depend on; otherwise, yes, that looks fine
<tseliot> cjwatson: yes I forgot to paste the line that sources debconf
<tseliot> ok, let me try again
<tseliot> cjwatson: it works great now. Thanks for your help
<cjwatson> np
<apw> cjwatson, we looked at the kernel package section use and fixed them sometime back with a patch from you irrc, are you happy with that
 * apw is trying to get our debian standard compliance up to the latest
<zul> morning
<zul> pitti: can you also approve php-interbase as well?
 * dholbach hugs pedro_!!!
 * pedro_ hugs dholbach back
<highvoltage> ok you guys can let go now
<pitti> zul: what's the bug#? I didn't get mail about it apparently
<zul> pitti: 530932
<pitti> zul: done
<pitti> zul: btw, I don't think you need to ask for individual packages -- there's no doubt for packages which are now uninstallable and need a 5.3 version
<sebner> pitti: did you get my message about my external harddrive? if not I'd be glad to remessage
<pitti> sebner: I answered with "please ubuntu-bug storage"
<pitti> sebner: without further information there's nothign I can do, I'm afraid (it seems to work well for most people)
<zul> pitti: ok ill do that in the future with regards to php
<sebner> pitti: didn't get that :), running that while the exterinal drive is attached right?
<pitti> sebner: not quite; it'll tell you
<pitti> it's an interactive process
<sebner> pitti: grr, before you waste your time and energy on me: It's magically working now
<sebner> pitti: just tried it, 2 days ago it wasn't and wasn't workingit :(
<pitti> :)
<sebner> pitti: I'm really sorry
 * pitti isn't sorry about things working :)
<sebner> pitti: sure but wasting time is not nice, next time I'll try again right before contacting you :)
<pitti> sebner: no prob, didn't take any time
 * sebner hugs pitti :)
<ogra> and wasting time with success messages cant be that bad :)
<sebner> heh
<didrocks> persia: asac: StevenK: finally, I'll have to add f-spot again, gthumb is too much work to put again in main and fit netbook screens. As it brings mono, do you want it on the armel version too?
<cjwatson> apw: I think it's OK these days; I haven't noticed any problems at the NEW-queue stage for a while
<apw> cjwatson, thanks, i think that covers all the items
<apw> the kernel has a perf tool which is kernel version tied and as we can install multiple kerenls must produce binaries with version number ... for the manuals i am thinking that just the latest version would do ... whats the best way to achieve that
<Keybuk> apw: didn't we already work this out?
<apw> Keybuk, we decided to install binaries as /usr/bin/perf-2.6.32-15-generic ... thats is ok, its the manuals i am wondering about
<Keybuk> "the manuals" ?
<apw> man perf stat ... manuals
<Keybuk> yeah they just say "perf"
<Keybuk> because we said we'd put a /usr/bin/perf that had
<Keybuk> #!/bin/sh
<Keybuk> exec $0-$(uname -r)
<Keybuk> in it :p
<apw> right ... so happy with that ... looking for advice as to how to package the manuals for it
<Keybuk> whatever ships that can ship the man page :)
<Keybuk> I doubt it'll change much
<Keybuk> after all, the kernel package doesn't actually include its own manuals either
<apw> well t
<apw> the manuals are pretty estensive for perf
<apw> i guess i could include the perf script in the main kernel source package and package that too l ike t
<apw> the linux-doc package which seems to be self-replacing
<apw> Keybuk, ok will try that than
<directhex> where do the u1ms people live on irc?
<dholbach> directhex: /j #ubuntuone
<Omahn> mvo: Have you seen bug #530632? ttx suggested I made you aware.
<ubottu> Launchpad bug 530632 in initramfs-tools "Upgrading from 8.04 to 10.04 fails on update-initramfs" [Undecided,New] https://launchpad.net/bugs/530632
<mvo> Omahn: I haven't, let me check
<mvo> Omahn: so this happend during the upgrade? or after the upgrade was completted? could you please attach the logs from /var/log/dist-upgrade/* ?
<Omahn> mvo: It's during the upgrade.
<Omahn> mvo: I'll upload the contents of /var/log/dist-upgrade/* shortly.
<mvo> Omahn: thanks!
<Omahn> mvo: Uploaded.
<pitti> $ cat /etc/default/locale
<pitti> LANG="de_DE.UTF-8"
<pitti> $ echo $LANG
<pitti> de_DE.utf8
<pitti> so, does anybody know what magic rewrites $LANG on login?
<ogra> gdm ?
<ogra> (guessing)
<ArneGoetje> yes, gdm does
<cjwatson> better question: why does anything care about the difference, given that they're aliases
<pitti> hm, on a VT it's not rewritten
<pitti> cjwatson: oh, I have a bug to fix in gnome-menus, which cares
<pitti> ArneGoetje, ogra: thanks
<cjwatson> pitti: I'm almost happy that gdm is doing this, because it's shaking out bugs like that
<pitti> I'm still not quite up to date why lucid suddenly switched to .utf8; /usr/share/i18n/SUPPORTED still has them in "UTF-8" form
<pitti> I'm going to make the gnome-menus cache robust against that, I was just curious
<cjwatson> .utf8 is glibc's canonical internal form; .UTF-8 is the form it advertises in SUPPORTED
<cjwatson> (.utf8 is what you always got from 'locale -a')
<ArneGoetje> pitti: anyways, .utf8 and .UTF-8 work both
<cjwatson> so I don't know exactly why it changed but I can imagine things like something trying to canonicalise the name
<cjwatson> I don't know exactly why the canonical internal form isn't the same as SUPPORTED, though it's been that way for a long time so presumably historical
<ogra> ArneGoetje, many scripts and tools blindly rely on UTF-8
<cjwatson> ogra: they're buggy and always needed to be fixed anyway
<ArneGoetje> ogra: yep, it was the common way to write the locale codes until recently
<ogra> cjwatson, i didnt say they dont need fixing :)
<cjwatson> (and I don't think it's all *that* many, though I know there are some common ones; most applications just use setlocale and are done with it)
<Omahn> mvo: On a different note, is it possible to get my application for the sru-verification team from 2008 approved? :-)
<mvo> Omahn: probably :) bdmurray is now in charge I think
<ogra> cjwatson, well, tha fact that locale-gen doesnt/didnt (i dont know if it was fixed yet) accept .utf8 is a bit strange
<cjwatson> yes
<cjwatson> that's just one tool though :)
<ogra> well, a quite essential one
<cjwatson> sure
<ogra> :)
<cjwatson> I was just debating the "many", by way of indicating that I don't think the problem is a very serious one if we pull our fingers out and fix the handful of places where it causes major problems
<ogra> true
<Omahn> mvo: Your automatic build system appears to have already replicated my initramfs upgrade issue
<Omahn> http://people.ubuntu.com/~mvo/automatic-upgrade-testing/2010-03-01-09:08:07/dapper-hardy-lucid-ubuntu/apt-term.log
<mvo> Omahn: thanks, I targeted the bug now
<mvo> Omahn: just there? or in the normal lts-ubuntu profile as well?
<mvo> Omahn: was your upgrade a dapper install before ?or is it just coincidence?
<ArneGoetje> BTW: can anyone here help me to debug my gdm? I cannot log into my system anymore and I don't know where to start looking... :(
<Omahn> mvo: Conincidence. Our machines are all hardy originally.
<seb128> ArneGoetje, what happens when you try to log in exactly?
<Omahn> mvo: Do you publish the scripts to perform those tests BTW? I would be very interested in having a copy running locally in our environment.
<mvo> Omahn: oh yes - its in the auto-upgrade-tester package, and in bzr under lp:update-manager (in the AutoUpgradeTester subdir)
<mvo> Omahn: its pretty flexible, but not well documented, I'm happy to help you if you have specific questions
<Omahn> mvo: Thanks, I'll check it out.
<ArneGoetje> seb128: when gdm starts up, I see my username, then select it. Then gdm does some checking in the background and fails with something, then resets the screen and I get the same screen as before. Then I select my username again and the bottom bar changes to display the comboboxes for selecting language and stuff... normally it should also display the Password field, but it never shows. This only happens on my account, another test account is fine, even
<seb128> weird
<seb128> do you have anything special for your account like protected userdir?
<ArneGoetje> seb128: no
<ArneGoetje> seb128: I have one suspicion...
<seb128> ArneGoetje, which is?
<ArneGoetje> seb128: I have tried what happens if I put a language code in an invalid format into ~/.dmrc. gdm just restarted and that's when this weird behaviour started. After that I restored the ~/.dmrc entry to the correct form and even moved the whole file out of the way... didn't fix the problem... dies gdm store the buggy entry somewhere else?
<seb128> ArneGoetje, /var/cache/gdm
<ArneGoetje> s/dies/does/
<seb128> it does store the .dmrc there to handle protected userdirs
<seb128> so it can read the config before asking the password
<ArneGoetje> seb128: thanks! Yes, it still has the buggy file there.
<seb128> np
<seb128> please open a bug saying that gdm breaks when you break that file content
<ArneGoetje> seb128: ok, will do
<seb128> thanks
<ArneGoetje> seb128: yay, works again! :)
<seb128> good!
<cjwatson> mvo: re http://lists.debian.org/debian-devel/2010/02/msg00424.html, is the new API going to land in lucid (soon)?
<cjwatson> or indeed
<cjwatson> juliank: ^-
<juliank> cjwatson: Well, mvo said he would like to do it. But there are some compatibility issues wrt progress reporting which I am going to fix today.
<juliank> In the end, it depends on whether a freeze exception is granted for it
<cjwatson> right - it would just be rather easier for me to merge a germinate patch right now if I knew it was going to land in lucid
<cjwatson> since then I won't have so much skew to deal with
<mvo> cjwatson: its the goal, it will make the next lts upgrade much simpler as well
<cjwatson> right
<mvo> lots of balls to juggle currently, I want to look at it tomorrow (when UI freeze is over)
<mvo> I looked last week and it was 98% there, some compat issues with the progress (as juliank said)
<mvo> but nothing that looks like a real blocker
<juliank> The only things that are a bit broken are InstallProgress & CdromProgress; some other issues I noticed while writing the >20 patches for the packages will be fixed in 0.7.93.4.
<mvo> juliank: thanks, please let me know and I have another look
<cjwatson> poo.  I got rid of "GRUB loading" and left the dot and newline in
<cjwatson> more tedious boot testing ...
 * apw just tried to install a package and apt has decided to remove a heap of stuff listing them as foo{u}, isi think previously they were marked as auto installed and not required and told me how to remove them, but suddently its removing them, is that expected?
<apw> either that or my machine is toast
<mvo> apw: this sounds more like aptitude, apt just informs about autoremovalbles
<apw> ahh crap so it is, damn a typeo on my behalf, why is aptitude installed anyhow
<cjwatson> aptitude is in ubuntu-minimal because tasksel needs it if you select manual package selection in the server installer
<cjwatson> it's not ideal but the cost is tolerable
<cjwatson> might sort that out one day
<cjwatson> the alternate and desktop CDs could live without it
<ion> seb128: How can the CSD patch for Gtk be tested? I take it thereâs a theme that uses the functionality.
<seb128> ion, GtkWindow::client-side-decorated = 1 in your gtkrc
<seb128> but it will not look correct without a specific theme
<ion> Thanks
<seb128> I think people are working on making a theme using it
<ion> Alright
<seb128> wait a few extra days I would say
<seb128> I will try to check and let you know
<ion> Thanks
<ogra> bah, gtk is still building on armel
<ogra> bloat ! 3h buildtime are to much for a toolkit !
<seb128> ogra: gtk doesn't take that long to build
<seb128> it's just built several times
<ogra> ah
<seb128> static, udeb, directfb
<seb128> + normal
<ogra> (i wasnt seriously ranting :) )
<seb128> it's something which annoys me too
<seb128> I would like to drop the static build at least
<ogra> for what is that ? d-i in debian ?
<seb128> no, udeb is for d-i
<seb128> and directfb somewhat
<ogra> and directfb i guess
<ogra> yeah
<ogra> we should probably just switch the whole distro to fltk :)
<ogra> would also prevent all kde vs gnome discussions :)
<seb128> lol
<juliank> mvo: I pushed the changes to debian-sid; if you could run some tests with it I can prepare the merge as well (the only difference now being that Python 3.1 is disabled here; because python3.1 is in universe, whereas python-apt is in main)
<mvo> juliank: great
<cjwatson> seb128: sounds like directfb is going to go away in the not too distant future
<cjwatson> at least the d-i uses of it
<seb128> yeah, I've read some blog posts about that
<Keybuk> I have learned that the Linux VT layer was not so much designed, as vomited into the existance from the bowels of the earth
<tseliot> lol
<Keybuk> it was apparently written to roughly match what they thought the X code assumed BSD/SVR did at the time
<Riddell> siretart: are you able to advise on http://thread.gmane.org/gmane.comp.kde.devel.general/60401 ?  are we behind on our ffmpeg?
<cjwatson> 16:12 <Keybuk> cjwatson: will it matter whether the VT is in VT_AUTO or VT_PROCESS ?
<cjwatson> Keybuk: moo
<cjwatson> (dunno yet)
<cjwatson> I don't think so, but I could be missing something
<Keybuk> the confusion I had was whether there was a font-per-VC
<Keybuk> or whether the font applied to every console
<Keybuk> the code appears confused on this issue too ;-)
<siretart> Riddell: we have backported the av_lockmgr stuff to 0.5 because we were asked by the geexbox guys at fosdem
<siretart> Riddell: it is included in the 0.5.1 release, which we published yesterday
<siretart> Riddell: I'm currently working on the package, and will upload it to lucid shortly
<siretart> Riddell: as for that specific question, it was decided to bump MICRO instead of MINOR in libavcodec for that feature backport
<siretart> Riddell: does this answer your question?
<Riddell> siretart: so this AVLockOp enum will appear in your upload today?
<cjwatson> Keybuk: "depends"
<cjwatson> Keybuk: vgacon is one-font-to-rule-them-all, currently; fbcon is font-per-VC
<siretart> Riddell: today I'm not sure, I don't feel very well today. But I should manage it this week
<cjwatson> Keybuk: BTW what's the current best way to blacklist fbcon so that I can test this properly
<cjwatson> ?
<Keybuk> cjwatson: blacklist=fbcon ?
<Keybuk> though you'd need <driver>.modeset=0 and blacklist=vga16fb I guess too
<cjwatson> juliank: in your transition plan, you mentioned applying Breaks to python-apt for anything that isn't yet converted; have you considered just applying Breaks for everything using the old API, with appropriate versioning?  I think that would be nicer to partial upgrades
<cjwatson> Keybuk: ok, thanks
<Riddell> siretart: lovely thanks
<juliank> cjwatson: In fact I meant that if pkg p version v still uses the old API, python-apt gets a Breaks: p (<< v+1).
<cjwatson> juliank: right, just clarifying whether there'll be a Breaks even if squeeze has >= v+1
<cjwatson> I think there should be
<Keybuk> cjwatson: all the current ioctl()s seem to ignore whatever tty you use
<Keybuk> and just fiddle with vc_cons[fg_console]
<Keybuk> which is somewhat scary
 * Keybuk thinking what if you do that ioctl mid-vt-switch for example <g>
<juliank> cjwatson: Do you want a package with Breaks: against more than 20 other packages?
<cjwatson> juliank: I don't see why not, if it's accurate
<cjwatson> I don't subscribe to the theory that upgrade compatibility should be dropped after each release :-)
<cjwatson> one of my packages still (theoretically) has some code for upgrades from Debian 1.2; it's easier to leave it there than to remove it
<Riddell> shtylman: seen my conversation with siretart above?
<cjwatson> Keybuk: I was sort of hoping there was a VT lock somewhere, but haven't looked too hard ...
<Keybuk> cjwatson: HAHAHAHA
<Keybuk> no such thing
<cjwatson> there's vga_lock at least
<cjwatson> but I think that's for the VGA hardware
<Keybuk> it may not matter
<Keybuk> if it's not storing anything inside vc-> ?
<Keybuk> it could just want a reference to any vc
<cjwatson> I used a separate font_data structure fairly deliberately
<cjwatson> s/structure/array/
<cjwatson> and all the vgacon_ functions take a struct vc_data *
<cjwatson> so fg_console is probably only examined once
<shtylman> Riddell: ahh
<Keybuk> where do they get that vc_data ?
<shtylman> Riddell: for that mailing list question...
<Keybuk> cjwatson: if there's a vc_data-per-vc this implies that there's a font-per-vc
<Keybuk> which means in order to set the fonts, you need to first chvt
<Keybuk> chvt 1 ; set font ; chvt 2 ; set font ; chvt 3 ; set font ; etc.
<cjwatson> no, KDFONTOP takes a structure that includes the vt number
<Riddell> shtylman: yes, seems like he'll need to wait for siretart to do that upload
<cjwatson> at least I think it does
<Keybuk> ah, KDFONTOP seems to be the one that operates on the vc you open
<Keybuk> [PG]IO_FONT[X] seem to operate on vc_cons[fg_console]
<cjwatson> oh yes that's right
<cjwatson> right, there are old ioctls that are fgconsole only
<cjwatson> but they shouldn't be used any more if KDFONTOP is available
<cjwatson> which it always is nowadays
<Keybuk> in which case, does it matter if KDFONTOP checks vc->vc_mode ?
<shtylman> Riddell: should we comment as such? I imagine he will try again or something...
<Keybuk> if vt7 is in KD_GRAPHICS, do we really need to set a font for it?
<Keybuk> it's only ever going to have plymouth and X on it
<cjwatson> isn't there sometimes graphics stuff on vt1?
<Keybuk> I guess
<cjwatson> that was certainly the original problem way back when
<Keybuk> if you try and set the font while an svgalib app is running
<Keybuk> or a framebuffer app
<Keybuk> etc.
<cjwatson> having vgacon not store the font only in video memory is probably more important than the mode check
<Keybuk> yeah
<cjwatson> you're right that removing the KD_TEXT check might not strictly matter since we don't nowadays put the splash screen on vt1; I think there was a point at which we did and it mattered
<Riddell> shtylman: it would seem like a good idea to tell him what he needs to do
<cjwatson> I think I wanted to do it just so that I never had to think about KD_TEXT vs. KD_GRAPHICS ever again
<Keybuk> indeed
<cjwatson> p.s. you can *really* screw up your console by copying font data around incorrectly within the kernel
<Keybuk> and like you say, the other consoles (fbcon) already handle this
<Keybuk> making vgacon consistent would be a good thing
<cjwatson> one question I had was whether vgacon is being kept deliberately memory-light
<cjwatson> that would mean it's desirable to stick with one-font-to-rule-them-all
<cjwatson> OTOH the code I have would share memory if you put the same font on all VCs ...
<Keybuk> or whether it puts it in vga memory because you can only have one font
<Keybuk> and because the ioctls only let you set it for whatever is the active console right now
<cjwatson> so I think the footprint is no more than about 1KB for a 256-char font
<Keybuk> so they never bothered extending it to support multiple
<Keybuk> and the newer ioctls came along later
<cjwatson> yeah, it's quite possible
<cjwatson> given the general maintenance level of VT code
<cjwatson> "we didn't need anything else in 1995"
<cjwatson> I certainly *hope* people see that putting the font in VGA memory and forgetting about it is a horrible mistake nowadays, once I get as far as LKML
<smoser> slangasek, Keybuk somewhere between my 20100224 build and 20100228, ramdiskless boot started failing on eucalyptus.  Between those 2 builds, the big differences are mountall-2.6 and upstart 0.6.5-4
<mvo> juliank: InstallProgress.writefd  seems to be broken again (I'm pretty sure I fixed that earlier). could you please have a look?
<Keybuk> smoser: started failing how?
<smoser> booting with a ramdisk "fixes" the problem.
<smoser> well, the cloud-init job doesn't run (MOUNTED=/ ...)
<smoser> i can get debug output if i add a job to turn it on
<mvo> juliank: the release upgrade tries to access it and crashes http://paste.ubuntu.com/387717/
<smoser> so there are 2 interesting pieces of information : 1.) ec2 instances still boot without ramdisk (its just eucalyptus that fail) 2.) eucalyptus can be worked around by giving a ramdisk
<smoser> the kernel is the same in 20100224 and 20100228
<Keybuk> how does it fail?
<Keybuk> the mountall and upstart changes are minor
<Keybuk> largely consisting of Depends changes
<smoser> well, no messages after kernel messages
<Keybuk> in fact, the only change not a Depends change is a change to Upstart that should make it *more* likely to work with a ramdisk
<juliank> mvo: should be fixed now
<juliank> Forgot to call the constructor of the parent class.
<shtylman> Riddell: I myself an unclear on what he needs to do... other than wait :)
<smoser> Keybuk, i'll get you some info with a 'initctl log-priority X' job. but i dont really know what else to do.
<Keybuk> smoser: that'd be a great start
<smoser> what X do you want?
<mvo> juliank: cool, thanks
<Keybuk> along with --debug from mountall as well
 * mvo updates
<smoser> Keybuk, how to add --debug in mountall ?
<Keybuk> edit the job
<smoser> k
<smoser> Keybuk, you want 'debug' or 'info' ?
<juliank> mvo: If it works for you, I'll update the timestamp, upload it; and could post a merge bundle for the ubuntu branch as a merge request bug.
<Keybuk> info is fine for upstart
<Keybuk> debug for mountall
<mvo> juliank: ok, also that is not needed, I have a local merge ready here
<mvo> juliank: let me test again
<juliank> mvo: I also have one ready here, and debian/changelog and debian/control are the only changed files compared to Debian.
<mvo> juliank: ok
<juliank> I do this to check if there are some things in the Ubuntu branch which could also be in the Debian branch without problems.
<juliank> So, once your tests are done; report back and I'll do a "dch -r" and upload 0.7.93.4; then you can merge the timestamp change and upload 0.7.93.4ubuntu1
<mvo> juliank: sounds good, its currently running a big upgrade, when that is done I check with gdebi again
<mvo> juliank: about ~1h (need to get some dinner too while the upgrade runs)
<smoser> Keybuk, what if i told you it doesn't seem to want to fail with debug enabled :(
<Keybuk> smoser: then I would cry
<smoser> Keybuk, i'm fighting eucalyptus stability demons now. i'll open a bug and subscribe you. if you had to guess, which package at this point, upstart or mountall
<mathiaz> zul: bug 531454 - 3.4.6 is a bug fix only release
<ubottu> Launchpad bug 531454 in samba "FFE for samba 3.4.6" [High,New] https://launchpad.net/bugs/531454
<mathiaz> zul: not sure you need to ask a FFe for this
<zul> mathiaz: not sure either better safer than sorry
<smoser> Keybuk, bug opened 531494 . I did get a recreate with debug, the serial console output is attached there.
<smoser> bug 531494
<ubottu> Launchpad bug 531494 in upstart "cloud-init job not running in eucalyptus without ramdisk" [Undecided,New] https://launchpad.net/bugs/531494
<sebner> jdstrand: I'm making some progress but I'm kinda stuck with a FTBFS. This is the most b0rken I've ever seen (mostly because it uses *huuuge* cdbs)
<jdstrand> sebner: can you paste how it breaks?
<sebner> jdstrand:
<sebner> jdstrand: http://pastebin.com/qap0AJEh
<jdstrand> sebner: you can't use ln in that manner
<sebner> jdstrand: I have to hardcode python2.6?
<jdstrand> sebner: well, unless the globs resolve to one place
<jdstrand> sebner: is it hardcoding 2.5 currently?
<sebner> jdstrand: aye
<jdstrand> sebner: I would just hardcode it at 2.6 then
<sebner> jdstrand: I'll give it a try
<sebner> jdstrand: ho ho ho I have a deb! I'll polish it a little bit and upload it then. I need a core-dev anyways for uploading but would you mind taking a look later?
<jdstrand> \o/
<jdstrand> sebner: attach it to the bug, I'm subscribed and can look at it
<sebner> jdstrand: .. and you better accept it as I don't ever want to touch such a crappy package (crappy cdbs package with huuge b0rken rules file) ever again in my life :P *muahaha*
<jdstrand> hehe
<sebner> jdstrand: If somebody would have told me earlier that the DM of moin is the DM of cdbs ....
<sebner> jdstrand: are you happy with a debdiff or do you prefer a .diff.gz (debian.tar.gz) as the update isn't trivial. A debdiff might be a lot easier to review imho though
<jdstrand> sebner: the debdiff should be between the Debian's 1.9.2-1 and your version-- am I missing something?
<jdstrand> sebner: that is what I would prefer
<juliank> mvo: BTW: gdebi should be ported to apt.debfile sometime.
<sebner> jdstrand: Nah, I know what a debdiff is .. but sometimes sponsors want a .diff.gz/interdiff whatever on big new new upstream versions when Ubuntu version is far behind. Debdiff also makes me happy ;)
<mvo> juliank: and the other way around too, the DebPackage code contians a bunch of fixes that need to be re-imported
<mpt_> tremolux, hi, I'm very impressed by the Back+Forward buttons :-)
<tremolux> mpt_: cool!  I'm very glad
<sebner> jdstrand: do you know that's the IRC nick of the maintainer?
<mvo> juliank: gdebi-gtk is complaining about http://paste.ubuntu.com/387771/
<mpt_> tremolux, any chance to fix bug 426999 now?
<ubottu> Launchpad bug 426999 in software-center "Navigating to application via search doesn't show its department" [Medium,Triaged] https://launchpad.net/bugs/426999
<jdstrand> sebner: sorry, no
<tremolux> mpt_: agreed, that would be a very nice one to fix, I will look at it now
<mpt_> thanks
<sebner> jdstrand: np
<tremolux> mpt_: sure!
<juliank> mvo: It should be fixed now.
<juliank> mvo: I just added all the missing returns in front of the commands I called.
<mvo> juliank: thanks, checking again. "apt_pkg.Dependency.UntranslatedDepType we did not bother, right?
<juliank> mvo: Added it to the list of renaming exceptions in python/generic.cc.
<juliank> i.e. in _PyApt_NewNameForAttribute
<juliank> mvo: I still have some large documentation updates planned for 0.7.94; but I guess as they are not-to-be-translated developer docs, they are not affected by the documentation string freeze.
<juliank> The main part is adding short docstrings to the stuff in apt_pkg.
<juliank> You can see how this should look like in apt_inst; it's full with documentation strings.
<juliank> Planned for the week starting Mar 22.
<mvo> juliank: yeah, I think devel docs like this are fine
<mvo> juliank: nice work, progress looks good
<juliank> mvo: I still need to port the quiet progress mode from apt-get to the python implementation.
<mvo> juliank: bug #531518 (fyi)
<ubottu> Launchpad bug 531518 in python-apt "Feature Freeze exception request" [Undecided,New] https://launchpad.net/bugs/531518
<juliank> mvo: Yes, I already added 3 comments to it (added one, fogot something, added second one, forgot something, added third one)
<mvo> heh :)
<mpt_> tremolux, how's it going?
<tremolux> mpt_: the bug you mean?  unfortunately I haven't dug into it too deeply yet, had lunch and then two intervening things, sorry
<mpt_> ok, np
<jibel> mvo, hi, I've been working on the xapian search today with some interesting results http://pastebin.com/LhHnVQNn
<smoser> slangasek, around ?
<mvo> jibel: oh, interessting
<mvo> jibel: are you working on the "-" problem?
<jibel> yes, finally I search for an exact match on the package name with the hyphen, replace the '-' by a space to search in the description.
<jibel> It's working because the package name is indexed by word in the term list
<jibel> mvo, the code is there http://pastebin.com/f36HKtas
<mvo> jibel: sweet, you rock!
<jibel> mvo, there are other improvements but apt-xapian-index generates poor metadata
<jibel> mvo, an since we search for few terms amongst a large list (the description) the relevancy if not relevant
<jibel> s/an/and
<mvo> jibel: that makes me wonder if we should not simple eascape "-" to something that can be inxed properly when writing the a-x-i and doing the same escaping in the searches. then we can at least exact match on XPpkgname - or am I missing something?
<mvo> (its been a long day)
<jibel> the exact match is working.
<jibel> even with an hyphen. But you cannot use wildcarding with boolean prefix or search with an hyphen with a probabilistic prefix.
<jibel> mvo, we could add a new prefix to the index and split the package name. If the boolean search returns nothing, use this prefix instead ?
<jibel> mvo, the order of the resultset would be: exact package name, package name containing the query string and finally document matching the query string.
<mvo> jibel: I think that is sensible - best is problably to ask in #xapian for a second opinion just to be sure we are on the right track
<jibel> mvo, sure. Enrico is not inclined to change the way the index is generated.
<mvo> jibel: we could add this as a additional plugin I guess
<jibel> mvo, anyhow the result is not that bad and there are ways to improve it a bit.
<mvo> but why not?
<mvo> ok
<jibel> mvo, I'm currently adding the plugin.
<jibel> mvo, I'll see if it gives positive result.
<jibel> or not.
<mvo> ok, thanks
<sebner> slangasek: around?
<slangasek> smoser: contentless pong
<slangasek> sebner: contentless pong :)
<smoser> i'm begging for help for bug 531494 (and also, now that i've pinged you, mail i sent thursday PM named "531494")
<ubottu> Launchpad bug 531494 in upstart "cloud-init job not running in eucalyptus without ramdisk" [Critical,New] https://launchpad.net/bugs/531494
<smoser> oops... mail was subject "questions from today" not 531494
 * slangasek nods
<sebner> slangasek: ;), Do you (by any chance) know why you introducted "* Demote fckeditor from Recommends to Suggests; the code was
<sebner>     previously embedded in moin, but it was also disabled, so there's no
<sebner>     reason for us to pull this in by default currently.
<sebner> " in moin 1.8.2-2ubuntu2 , a year ago? Upstream told me that fckeditor was *never* disabled by default
<slangasek> sebner: because someone told me that was the case, and I was avoiding having to do a run of MIRs
<sebner> slangasek: Ic, well, I guess for now it's fine if we keep that change and tackle the MIR stuff for lucid+1?
<slangasek> sebner: it was maxb who said this
 * sebner summons maxb *hehehehe*
<slangasek> if you prefer to do an MIR sooner, that's your choice
<sebner> slangasek: well, I didn't want to work on the package (python + cdbs) but I somehow slipped into it so I'm happy if you agree to postpone it (I'll leave a note in changelog)
<slangasek> smoser: have you tried downgrading just the upstart package in your build, to see if that fixes the problem?
<slangasek> smoser: and I don't have any good ideas how to debug this, if it is an upstart problem but turning on debugging makes it disappear :/
<smoser> slangasek, oh comon... suggesting logical steps to reducing scope of problem is not fair!
<smoser> no i've not done it.
<smoser> slangasek, i did reproduce with debugging on (the attached log shows that), but it does sometimes make it go away.
<slangasek> oh, you got one with debug, ok
<slangasek> smoser: have posted some analysis of the logs; I think you're going to need Keybuk for further debugging, because I really don't have a clue there
<sebner> jdstrand: debdiff is up
<micahg> kees: which greasemonkey, upstream or from archvie?
* Chex changed the topic of #ubuntu-devel to: Launchpad will be down/in read-only from 23:00 UTC until 00:30 UTC for a code update | Lucid Alpha 3 released | Archive: Feature 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 |
<kees> micahg: upstream
<micahg> kees: is it the latest (2010 release)?
<kees> 0.8.20100211.5
<micahg> ugh
<cjwatson> Keybuk: so blacklist=fbcon i915.nomodeset=0 blacklist=vga16fb didn't do it - but making sure FRAMEBUFFER was disabled in /usr/share/initramfs-tools/conf-hooks.d/* and booting with init=/bin/bash did. :-)
<cjwatson> Keybuk: incidentally, init=/bin/bash is not friends with FRAMEBUFFER=y
<micahg> kees: I'll have to look more tonight...seems other users are affected on Arch and Red Hat so probably not an ubuntu issue, but either GM or FF, I'll update the bug with what I find
<cjwatson> you get plymouth starting and then nothing ever stops it
<kees> micahg: cool, thanks.
<cjwatson> we could probably do with an initramfs option to avoid starting plymouth just in case it's built into the initramfs, or something
<kees> cjwatson: +1
<cjwatson> in any case, I have discovered that my kernel is buggered - it blanks the font entirely on tty switches - so more work required
<cjwatson> pitti: https://launchpad.net/ubuntu/+source/grub2/1.98~20100128-1ubuntu4/+build/1541925/+files/buildlog_ubuntu-lucid-powerpc.grub2_1.98~20100128-1ubuntu4_FAILEDTOBUILD.txt.gz - do I remember something vaguely about this being a pkgbinarymangler bug, by any chance?  grub2 doesn't create the control directory manually so it's very odd for it to have wrong permissions
<pitti> cjwatson: hm, does the buildd have a bad umask or so? LP seems to be down ATM, but I'll have a look tomorrow
<kees> any idea what's going on here?  I can't convince apt-get to install a recommended package: http://paste.ubuntu.com/387905/
<superm1> kees, did you try whispering sweet nothings in it's ear? :)
<kees> superm1: I even specified --install-recommends.  :P
<micahg> kees: try installing smbclient in aptitude and manually add samba-common-bin and see what it says or use whatever -o option tells you package compatability
<crimsun> or, aptitude why-not samba-common-bin
<kees> micahg: hrm?  it'll install samba-common-bin if I tell it to, but I'm expecting it to install samba-common-bin _without_ me specifying it.
<micahg> kees: k, just was thinking there might be an unspoken conflict
<micahg> crimsun: that's a cool option :)
<kees> yeah, no conflict
<kees> oh, is it because it's a recommend of samba-common that is already installed (but is being upgraded?)
<cjwatson> pitti: not sure - I couldn't see anything in the build that would be setting umask
<ebroder> Is the Librarian supposed to be actually down, or just r/o?
<cjwatson> pitti: and indeed my local build looks fine
<kees> cjwatson: I'm baffled by apt-get -- it lists "Recommended packages" yet it does not install them even if I use --install-recommends
<cjwatson> kees: not a behaviour I'm familiar with ... doesn't do that here
 * kees attempts to reproduce in chroots
<ScottK> cjwatson: I had the same failure for quassel on powerpc (and only powerpc).
<ScottK> So it's not specific to one package.
<cjwatson> ScottK: oh good, I thought I was going mad
 * ScottK too
<cjwatson> I'm sure I saw this problem go by on #u-d a while back though.  I wonder if powerpc is using an out-of-date version of pkgbinarymangler or something
<ScottK> In my case it said it was skipping pkgbinarymangler as requested.
<ScottK> I thought that was odd.
<cjwatson> I don't see anything in the changelog though
<kees> are recommends only installed on package install and not package upgrade?
<cjwatson> kees: new recommends are installed on upgrade (but not 'apt-get upgrade' as opposed to dist-upgrade, since it never installs new packages)
<cjwatson> kees: but if the previous version of the package recommended the package too, apt will assume that you meant not to install it the last time
<persia> kees: My understanding is that apt-get ... tries to make the minimum changes required to fulfill the stated requirements.
<cjwatson> I'm not sure about 'apt-get install' of an individual package as an upgrade
<kees> cjwatson: aaah, so if the prior version also recommended, then it's not a change, so it does nothing.
<kees> apt-get install output matches the apt-get dist-upgrade output
<kees> here's the state and example: http://paste.ubuntu.com/387921/
<kees> it just means that taking a system with install-recommends=false to =true means things will kind of stay not installing recommends.
<cjwatson> yeah, you need something a bit more sophisticated than apt-get I imagine
<cjwatson> grr, I hate wasting time accidentally building a kernel for the wrong architecture
<kees> ugh, that sucks
<kees> (building time-waste)
<kees> I'll write something to look at all Recommends: for currently installed packages and install those.  :)
<lifeless> kees: aptitude
<lifeless> kees: has a list at the bottom, of uninstalled but recommended packages
<ion> kees: aptitude â View â Audit Recommendations
<lifeless> kees: so running that up, go down to recommendations, install at that level - done.
<kees> oh my, I see perhaps why I turned this off originally now.  :P
<kees> lifeless: cool; this is exactly what I needed.  :)
<lifeless> de nada
#ubuntu-devel 2010-03-04
* Chex changed the topic of #ubuntu-devel to: Lucid Alpha 3 released | Archive: Feature 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
<superm1> didrocks, pitti re netbook.lucid r 1451,  not having those headers installed by default is going to aggravate bug 318727
<ubottu> Launchpad bug 318727 in dkms "dkms wrong version of linux-headers" [Medium,Triaged] https://launchpad.net/bugs/318727
<ebroder> Any core devs that could sponsor bug #497606 for me?
<ubottu> Launchpad bug 497606 in cupsys "lpstat in CUPS 1.3 can't list jobs on CUPS 1.4 servers" [Undecided,Invalid] https://launchpad.net/bugs/497606
<persia> "Invalid"?
<ebroder> It's an SRU
<persia> Ah, right.
<ebroder> So it doesn't affect all releases
<ebroder> I...guess ubottu looked at cupsys+jaunty? Sort of a weird pairing to pick, but *shrug*
<persia> Does it still need the cpus fix in lucid?
<ebroder> No. Karmic and Lucid have CUPS 1.4 and aren't affected
<persia> Err, "cups"
<persia> And cupsys?
<ebroder> The package was renamed in the Hardy -> Intrepid transition
<persia> So just "cups" in jaunty and "cupsys" in hardy?
<ebroder> And cups in Intrepid, so there's not a Hardy -> Intrepid regression
<ebroder> There are debdiffs linked in the description for all 3
 * persia fiddles statuses, although unable to upload.
<superm1> persia, i was able to just upload, uploading appears alive again
<persia> superm1: I need to file a core dev application first :)
<persia> superm1: Maybe you'd like to upload?
<superm1> persia, oh for some reason i thought you already were
<persia> Only due to administrative quirk, and applying to either be or not be core-dev is near the top if my todo list.
<superm1> i dont have the resources necessary to sponsor (test/build) available atm
<ScottK> cjwatson: I retried quassel on powerpc (which was having a problem like the one you were having) and it built.  Dunno if stuff happens or someone fixed something.
<persia> Could an archive-admin binary NEW adium-theme-ubuntu?  Currently both ubuntu-netbook and ubuntu-desktop cannot be installed.  It probably needs promotion to main as well.
<persia> (the other option is to undo recent changes to ubuntu-artwork, but that seems like unnecessary archive churn for the sake of an upload war)
<StevenK> persia: The source is currently in universe
<persia> StevenK: Yeah, but I can make images also with universe if I want :)  The source needs an MIR, but has no history.
 * persia goes to find appropriate folk to file the MIR
<StevenK> persia: I'm promoting it in the first place just to unbreak images.
<persia> Should it get a retroactive MIR?
<StevenK> Yes
<persia> kenvandine: Could you please file that?
<StevenK> The MIR should state it has been shoved to main to unbreak image builds
<StevenK> persia: Source promoted, binary promoted and accepted
<persia> kenvandine: If you can't in the next few hours, I'll file a placeholder for it (with the note about early promotion).
<persia> StevenK: Thank you.
<kenvandine> persia, i thought pitti already did that
<kenvandine> i'll file the MIR bug though
<kenvandine> thx
<persia> kenvandine: I can't find the MIR even with advanced search.
<kenvandine> i didn't file a bug for it
<persia> Might just be missing the source package assignment in the bug though.
<kenvandine> i thought he already promoted it though
<StevenK> adium-theme-ubuntu | 0.1-0ubuntu1 | lucid/universe | source
<persia> No, it won't be available for another 114 minutes or so.
<persia> (publisher run at the top of the hour taking about 3/4 of an hour)
<StevenK> Actually, it didn't.
<persia> ?
<StevenK> Contents generation runs at 4am GMT, and trumps the publisher
<ebroder> Any core-devs around I can con into sponsoring bug #497606? (It's got ubuntu-sru approval, and tested patches with PPA builds)
<ubottu> Launchpad bug 497606 in cups "lpstat in CUPS 1.3 can't list jobs on CUPS 1.4 servers" [Undecided,Fix released] https://launchpad.net/bugs/497606
<persia> StevenK: Isn't it 4:30 GMT? so we can expect that the next publisher will run, and we'll have the package available around 5:45 GMT?
<persia> (so ~75 minutes I just failed at math before)
<persia> ebroder: This is one of the quietest times of day.  You've subscribed all the right folk, and I'm sure they'll get to it when they have a chance.
<kenvandine> persia, bug 531718
<ubottu> Launchpad bug 531718 in adium-theme-ubuntu "[MIR] adium-theme-ubuntu" [Undecided,New] https://launchpad.net/bugs/531718
<persia> kenvandine: Thanks.  Now I have a justification for requesting promotion :)
<ebroder> persia: I've traditionally had a *really* hard time getting main sponsorship without poking the hell out of people here
<persia> kenvandine: But you also want to indicate a team that will be taking responsibility for it (ubuntu-desktop?)
<kenvandine> ok, will do
<kenvandine> the art team actually
<kenvandine> i just did the package for them :)
<persia> ebroder: Do you have any good ideas how to convince folk to look at the queue?  Because I think it's a waste of your time and a waste of everyone unable to sponsor's time for you to keep promoting on IRC until someone gets to it.
<persia> kenvandine: Then you: I don't think the art team is best positioned to deal with packaging bugs :)
<persia> (and most of them don't happen to be developers)
<ebroder> persia: I really don't know what to suggest. I'm hosed with classes, so I don't have time to try and flare up about it on -devel@ or anything liek that right now, but maybe that's somewhere to start?
<persia> I'm currently active in a thread about that stuff on -devel@ :)  But yeah, I think so.
<persia> I just don't think you should have to complain on IRC.
<ebroder> persia: I...saw that thread, but haven't been able to follow it because there's too much traffic
<ebroder> Yeah, I don't disagree, I just go with what has worked for me in the past
<micahg> kees, have you tested the firefox profile patch?
<micahg> kees: unping
<kenvandine> persia, they maintain all the art packages currently
<kenvandine> well kwwii does i think :)
<kenvandine> but i am here to help of course
<kenvandine> ~ubuntu-art-pkg actually
<persia> kenvandine: Then get kwwii to sign up for this one too :)
<persia> The point being that some team *should* be a bug contact for the package for it to be in main.
<persia> Some stuff got in way back when without this, but for new stuff, it's worth making sure someone volunteers to care.
<persia> (otherwise it suffers bitrot, and the archive consistency folk need to discover it and eject it from main)
<lifeless> I remember the headache after we put all of python in main
<lifeless> then slowly ejected it again
<lifeless> do we need this one? hmm, not sure, lets see who screams.
<persia> That was a bit painful, really.
<ScottK> persia: An Ubuntu bug contact is not a MIR requirement.  Perhaps it should be.
<persia> ScottK: Isn't it?  The JACK MIR got stalled waiting for one.
 * persia checks
<ScottK> I don't think so.
<ScottK> I could be wrong.
<lifeless> a sponsoring org is
<persia> lifeless: Hrm?
<lifeless> which isn't quite the same thing, it could be interpreted that you aren't really interested if you don't make a bug contact though ;P
<lifeless> the old template - https://wiki.ubuntu.com/MainInclusionReportTemplate mentions bug contat
<ScottK> It asks if there is one, doesn't require one.
<persia> ScottK: It's not a strict requirement, but it's item 8, which asks that packages either be simple and in sync with Debian (where it is maintained) or have commitment from Ubuntu Developers willing to spend substantial time on them (and need a package bug contact set)
<persia> (on the new process: https://wiki.ubuntu.com/UbuntuMainInclusionRequirements )
<lifeless> ignore my comment about org; I was going waaaay back to some original discussions
<persia> lifeless: Oh, right.  That stopped being a requirement in Hoary or Breezy, I think.
<lifeless> <- old skool
<crimsun> kees: nice catch with chmod
<kees> crimsun: hrm?
<kees> crimsun: oh, yeah.  hm
<tedg> What tool adds the "X-Ubuntu-Gettext-Domain" at the end of desktop files?
<lifeless> tedg: probably binpkg mangler or something like that.
 * lifeless defers to pitti
<tedg> Heh, I need to file a bug on it.  Unfortunately LP doesn't take fuzzy package names yet ;)
<persia> tedg: Check the pkgbinarymangler source.  I think that does langpack stuff.
<tedg> persia: Hmm, that seems to pull the translations out... but I don't see where it adds the line.
<persia> Maybe it doesn't?  Ask pitti :)
<maxb> I said something about moin/fckeditor? Hmm.
<maxb> I'm guessing it might have been something along the lines of "It's already disabled by Debian" ?
<dholbach> good morning
<thekorn> good morning dholbach
<dholbach> hey thekorn!
<dholbach> hola mvo!
<didrocks> good morning mr Holbach ;)
<dholbach> heya didrocks
<pitti> Good morning
<pitti> cjwatson: I could just add an explicit umask 022 and see whether it helps -- otherwise I have no idea
<mvo> hey dholbach
<didrocks> good morning pitti
<didrocks> hi mvo
<mvo> hey didrocks
<pitti> superm1: I know, but the CD is hopelessly overflown otherwise :( we were required to get back both OO.o as well as the entire mono stack with tomboy and f-spot on netbook
<didrocks> pitti: do you thing this issue worths investigate other options?
<didrocks> think*
<didrocks> (we have 14 MB free on the daily image)
<pitti> persia, StevenK, kenvandine: I wanted to binary NEW it last night, but LP went offline underneath me; thanks for sorting out
<persia> pitti: Are you still ubuntu-MIR?  Maybe you can do the review?
<pitti> superm1: as a compromise, we could maybe put back the headers, but leave out gcc/make/etc.; the headers are the by far biggest part of the chain, though :(
<pitti> lifeless: X-Ubuntu-Gettext-Domain> that's cdbs' langpack.mk module; I'll tell tedg when he's back online this evening
<pitti> hey didrocks, bonjour!
<pitti> didrocks: as I said, we could put back the linux headers only?
<didrocks> pitti: let's have a try
<pitti> didrocks: I think that would solve the "pick right headers" problem, and still get rid of some 3 MB
<didrocks> ok, should *just* fine considering the size
<pitti> persia: yes, I'm in the MIR team; I source NEWed the adium thing yesterday, so I already reviewed it; looked fine
<didrocks> +be
<pitti> didrocks: merci
<didrocks> pitti: y/w :)
<persia> pitti: Would you mind swatting bug #531718 with your staff of authority then?
<ubottu> Launchpad bug 531718 in adium-theme-ubuntu "[MIR] adium-theme-ubuntu" [Undecided,New] https://launchpad.net/bugs/531718
<persia> (because you source NEWed it into universe)
<csurbhi> good morning #kernel
<pitti> persia: wow, that bug is burning!
 * pitti is a bit puzzled about LP's "hotness" calculation
<RAOF> Is armel a supported arch for Lucid?  How much do I need to care that gjs FTBFS on armel?
<pitti> hey RAOF
<RAOF> Good eventide, pitti :)
<pitti> RAOF: it is supported; usually the mobile team cares about the porting, but I'm sure they appreciate any help
<persia> RAOF: Please care lots.  You can set up a local armel emulated build environment with lucid pbuilder-dist or mk-sbuild{-lv,}
<RAOF> persia: I've just done so.  It builds, but is failing in the test-suite, which means it's probably not built correctly.
<pitti> RAOF: is that a regression from the previous upload?
<RAOF> pitti: I think it is, yes.
<RAOF> I'll check
<RAOF> persia: Any tips on making the emulated environment less achingly slow?
<persia> RAOF: I don't know of any.  You can purchase hardware if you like.
<dehqan>  after upgrading libc6 and reboot , ubuntu 9.04 does not boot completely and gives this error in the middle of boot http://imagebin.org/87436
<persia> (current available stuff is a small netbook and a tiny home server)
<RAOF> Right.  There's no magical kernel kvm-make-armel-super-fast switch, then ;)
<persia> RAOF: Hardware isn't that much faster though.
<persia> Not that I've heard about :)
<dehqan> any opinion ?
<persia> dehqan: Please file a bug and try to get someone in #ubuntu-bugs to verify and escalate.  That is potentially a devastating regression.
<dehqan>  after upgrading libc6 and reboot , ubuntu 9.04 does not boot completely and gives this error in the middle of boot http://imagebin.org/87436  , how to fix it ? will downgrading libc6 solve it ?
<persia> dehqan: Why repost here after going to -bugs?
<dehqan>  will downgrading libc6 solve it ?
<persia> This is not the right forum for this discussion.  Please follow-up in #ubuntu-bugs
<dehqan> ok thanks
<persia> Just in case anyone is worred about a libc6 regression: apparently there's a boot failure if one installed the libc6 from 9.10 on a 9.04 system when not otherwise upgrading the system.
<lifeless> persia: thats a sign of a missing package relationship
<lifeless> persia: if you can get any hint of what it is and file a bug please do: I suspect libc should breaks ([thing that breaks] << [some version])
<lifeless> persia: this may be useful to do now, in lucid if its not already done
<lifeless> and perhaps an SRU if libc is changed again for karmic
<persia> I'll try to replicate when the jaunty CD finishes downloading, but I don't think I want to try to get that remotely from the user.
<sabdfl> folks, is usb-creator-gtk known-borked?
<pitti> sabdfl: oh, what happens?
<dholbach> bug 529366 looks like it
<ubottu> Launchpad bug 529366 in usb-creator "Regression: usb-creator-gtk doesn't work as of 0.2.16" [High,Triaged] https://launchpad.net/bugs/529366
<sabdfl> fails to install bootloader
<sabdfl> ah, seems like 529366 affects me too
<pitti> right, seems to be that one
<sabdfl> luckily we have a nice ajaxy way for me to say that :-)
 * pitti approves for lucid and targets for beta-1
<pitti> but once we approach beta, it'll annoy enough folks for it to be fixed quickly :)
<pitti> (I mean, who is still burning CDs these days..)
<sabdfl> is there a manual workaround?
<pitti> sabdfl: I suppose it happened with the new parted
<\sh> pitti: /me ;)
<pitti> sabdfl: sudo gedit /usr/share/usb-creator/usb-creator-helper, comment out line 96 (with the popen parted)
<pitti> sabdfl: that requires the partition to be bootable already, but if you ever used that USB stick to boot before, it should be alright
<\sh> kwwii: any timeframe when the new "look" will land in lucid these days?
<\sh> oh dear...something removed my ubuntu-desktop
<kwwii> \sh: sometime between today and release ;-)
<mtx_init> why isn't a xorg.conf included anymore?
<\sh> kwwii: good answer so ok...it's there when it's there ;)
<persia> mtx_init: Most folk don't need one?
<mtx_init> so how is the resolution and stuff set without one?
<persia> autodetection and EDID, but we're drifting off-topic.
<pitti> cjwatson: hah, I just got a similar failure on cups/jaunty: http://launchpadlibrarian.net/40141304/buildlog_ubuntu-jaunty-powerpc.cups_1.3.9-17ubuntu3.7_FAILEDTOBUILD.txt.gz
<kwwii> \sh: actually it should be later today
<pitti> lamont: did ross (powerpc buildd) recently get an umask change? packages fail to build due to what could be umask 0700 (http://launchpadlibrarian.net/40104136/buildlog_ubuntu-lucid-powerpc.grub2_1.98%7E20100128-1ubuntu4_FAILEDTOBUILD.txt.gz for example)
<\sh> kwwii: cool :) I'm keen to try out the new gnome decoration...it looks "interesting" :)
<kwwii> ;)
<\sh> kwwii: btw...branding looks very refreshing, trendy and professional...well done, you graphics guys :)
<kwwii> \sh: thanks! I am really impressed with what our team has come up with ;)
<\sh> kwwii: hopefully I can make it to the upcoming UDS...I just requested some bucks for the trip from our company...we (we as in Linux Architecture + Operations Team) would like to do some more distro server work and company needs to contribute some workingtime for it..97% of all servers are running ubuntu only :)
<kwwii> \sh: hehe, that would be cool, I'll buy you a beer ;)
<\sh> kwwii: and if not...requesting some holidays, driving with family to our relatives in st. vith (belgium) and then coming to you guys, that's an alternative :)
<ogra> \sh, *you* at UDS ?!?!
<\sh> ogra: looks like...
<ogra> cool !!
<pitti> slangasek: is the current acpi-support bzr head ok to upload? I just committed a fix from TeTeT, but the other changes in head say "this needs to be handled directly by the kernel" -- is that blocked on a kernel upload?
<slangasek> pitti: hrm.  checking
<\sh> ogra: yeah...after 5 years it's time again to meet all the new folks :) and of course more important the old folks ;)
<slangasek> pitti: sorry, 0.132 was already uploaded - apparently I forgot a push
<pitti> slangasek: oh, oops; seems bzr was just missing a dch -r/debcommit -r
<slangasek> yah
<pitti> slangasek: if you already have that in bzr, please feel free to push --overwrite, and I'll rebase
<slangasek> ok
<pitti> slangasek: otherwise I can just fiddle in the dch -r/debcommit -r myself
<ogra> \sh, hehe, great
<slangasek> pitti: done
<pitti> cheers
<dehqan> any opinion http://pastebin.com/n3bs4Yhi?
<lamont> pitti: ah, yes. that
<lamont> pitti: ross got a change from dapper->karmic
<lamont> and I apparently need one more tweak
<lamont> pitti: did you want to give-back the failed, or shall I?
<lamont> pitti: and I'll push the fix to https://bugs.edge.launchpad.net/launchpad-buildd/+bug/517802 this week
<ubottu> Launchpad bug 517802 in launchpad-buildd "on karmic, winds up launching sbuild with umask of 077" [Undecided,Confirmed]
<lamont> \sh: I shall look forward to seeing you at UDS
<\sh> lamont: :) /me too :)
<pitti> lamont: ah, thanks a lot! I was already afraid having to do pkg-create-dbgsym SRUs for all releases
<pitti> lamont: I know of grub2 and brasero, I can give them back
<pitti> but it probably affected a lot of other builds
<pitti> lamont: grub2/brasero given back
<lamont> https://edge.launchpad.net/builders/ross/+history <-- pitti
<lamont> you wanna start at the top, and I'll start at the bottom, and we'll meet in the middle?
<pitti> lamont: ack
<pitti> lamont: I'm up to ktorrent
<pitti> or "down to"
<lamont> and FIN
<pitti> I think we're done
<pitti> lamont: thanks a lot!
<pitti> cjwatson: so, grub2 should build now
<lamont> given that the queue was basically empty, I'm not going to bother rescoring those builds unless they become an issue
<cjwatson> pitti: thanks
<\sh> hmm...does anybody has problems with lucid server mounting lvm devices during bootup ?
 * persia has no such issues with desktop mounting lvm devices
<\sh> strange
<didrocks> neither do I with desktop too
<\sh> my server setup waits for the lvm devices coming up..and waits and waits and waits...
<\sh> just checked the /etc/fstab syntax so that I'm not mistaken...very strange
<\sh> mounting via cli does work fine *bah*
<tjaalton> who is in charge of wpasupplicant?
<tjaalton> it spams the log constantly, there's a new version in squeeze that could be synced
<pitti> chrisccoulson: ^ sounds a bit like your new hat?
<chrisccoulson> yeah, possibly!
<chrisccoulson> what does it spam the log with?
<chrisccoulson> oh, right, i can see it too
<tjaalton> chrisccoulson: bug 352118
<ubottu> Launchpad bug 352118 in wpasupplicant "WPA writes possibly unnecessary messages to the system log" [Unknown,Fix committed] https://launchpad.net/bugs/352118
<chrisccoulson> tjaalton - thanks
<tjaalton> there's 0.6.10-2 in unstable that could be synced
<tjaalton> only change in lucid was to change the libkreadline build-dep
<tjaalton> -k
<chrisccoulson> tjaalton, i'll take a look at that later, i've got some other things to do first
<chrisccoulson> thanks anyway
<tjaalton> chrisccoulson: ok, thanks
<pitti> so it's primarily a "check 0.6.10 for FF compatibility" exercise?
<tjaalton> that too
<\sh> soren: why does vmbuilder kvm ... --debug doesn't work anymore?
<soren> \sh: What doesn't work?
<\sh> soren: no debug output... just the standard blabla of vmbuilder...but no "debootstrap output" or anything which was there before...tried to set --debug and --verbose but no change
<soren> \sh: I see plenty of output.
<soren> \sh: Pastebin your commandline along with the output, please.
<james_w> StevenK: did you sync mongodb and xmonad-contrib? OK to flush them?
<StevenK> james_w: No, mass-sync died horribly
<james_w> ah
<StevenK> james_w: With a 412 error
<james_w> heh
<\sh> soren: http://paste.ubuntu.com/388237/ <- cli | http://paste.ubuntu.com/388238/ <- output on karmic | http://paste.ubuntu.com/388239/ <- output on lucid
<james_w> StevenK: are you retrying?
<ogra> mvo, your last fix to python-apt wont work ... ports uses the /ubuntu-ports subdir
<soren> \sh: Don't pass both --debug and --verbose.
<soren> \sh: --debug will first set verbosity to debug. Then --verbose will reduce it to verbose.
<\sh> soren: ok...let's try :)
<\sh> soren: btw...how to I tell vmbuilder to use a VDE instead of a bridge device?
<\sh> didn't find anything useful on the interwebs
<\sh> soren: btw..works..thx..that somehow changed between karmic and lucid :) nice
<mvo> ogra: ok
<pitti> ogra: I don't see a bug about "sudo locale-gen ru_RU.utf8" not working; I'm going to fix it now, I just wondered whether it was perhaps filed against somethign else than langpack-locales?
<ogra> pitti, ??
 * ogra misses the context
<pitti> ogra: .UTF-8 vs. .utf8
<pitti> what we discussed yesterday
<ogra> i didnt file any bugs about it
<pitti> ok, thanks
<ogra> i know the issue from LTSP ... and there it was fixed
<pitti> ok, fixed in bzr
<ScottK> zul: Please use build1 instead of ubuntu1 for rebuilds so it can get sync'ed over automatically in the next cycle (see https://launchpad.net/ubuntu/lucid/+source/sqlrelay/1:0.39.4-9ubuntu1 for an example).
<zul> k
<slangasek> zul: you uploaded php-imlib as a rebuild-only upload, but there's a serious bug report in Debian that it FTBFS with php 5.3...
<zul> slangasek: yeah im looking at it now
<siretart`> Riddell: shtylman: ffmpeg 0.5.1 has reached lucid now
<Riddell> siretart`: lovely thanks
<crow_> how I can  boot alfa 3 ? my lap top asus k50in with nvidia chipset and 102m graphic not respondig
<ScottK> crow_: Help for Lucid is in #ubuntu+1
<pecisk> crow_: when booting with LiveCD, press F6 and turn on nomodeset parameter, and then check out why LiveCD stops to load
<crow_> i try with F6 and install OS, and when I boot OS from HD lap top is freez. mixup the picture of bios and desktop :(
<jiboumans> odd question perhaps; anyone happen to know what hte current footprint (disk+ram) is for the lucid mimimal virtual machine?
<highvoltage> slangasek: following the brand changes announced yesterday, wouldn't it have made sense to postpone the UI freeze a little?
<persia> jiboumans: How minimal?  Just ubuntu-minimal?
<highvoltage> slangasek: for edubuntu, for instance, we're waiting on new logos and other items required to complete the artwork packages for 10.04, wouldn't other teams also have the same problem?
<jiboumans> persia: specifically the installer option 'minimal virtual machine'
<persia> jiboumans: My buildd chroots are 416808k
<persia> (which is probably a little larger than that)
<jiboumans> that's pretty big
<persia> jiboumans: What sort of number were you looking for?  That's 400MB.
<jiboumans> persia: something much smaller I suppose. Our EC2 images are 200mb, although that's probably involving compression
<zul> jiboumans: the ec2 images are the standard seed + plus some additional packages fyi
<matti> jiboumans: IIRC there is Ubuntu JeOS project...
<matti> jiboumans: http://www.ubuntu.com/products/whatisubuntu/serveredition/jeos
<jiboumans> matti: right, and as of 8.10, 'JeOS' is obtained picking 'minimal virtual machine' from the installer.. which is what i was asking about :)
<matti> Oh :)
<persia> jiboumans: The number I gave you was completely uncompressed.  It ought be minimal+build-essential+pkgbinarymangler+pkg-create-dbgsyms+sudo+vim-tiny
<persia> I'd guess somewhere in the 300-350MB range without all that (uncompressed).
<jiboumans> persia: alright, fair enough.. thanks for checking for me
<matti> jiboumans: It would be nice to have Ubuntu Studio -- something like SuSE Studio http://susestudio.com/.
<persia> matti: Ubuntu Studio means something entirely different: http://ubuntustudio.org/
<matti> persia: Yes, I know... henve I've added "something like ..." :)
<slangasek> highvoltage: er; I wasn't aware that there would be logo changes affecting edubuntu, but all the same, we need to move forward on stabilizing this stuff so that the doc and translation teams can cover the bases on their side.  The UI freeze doesn't generally prevent changes, it just requires coordinating with those teams when you have them
<slangasek> highvoltage: what exactly will be changing in Edubuntu's artwork?
<pitti> hm, with dh7 and dh, how would I say "run these additional commands in install"
<pitti> (I don't want to override the dh_install command, just do extra stuff)
<pitti> man dh is blissfully ignorant of this use case apparently
<persia> pitti: override_dh_auto_install:\n\tdh_auto_install\n\t${MORE_COMMANDS}
<highvoltage> slangasek: mostly the logo everywhere that it is currently displayed, Canonical will be providing us with a new one RSN. if changes are allowed then it's probably no biggie.
<pitti> persia: ah, thanks
<persia> pitti: And now that you know, you'll see it's in the manpage, just obfuscated :)
<persia> (specifically in the override_dh_fixperms: example)
<slangasek> highvoltage: right - you might want to mail ubuntu-doc preemptively, and let them know to hold off on edubuntu screenshots until this change is done
<cjwatson> slangasek: same applies to the Ubuntu boot screen
<cjwatson> I have mockups from michaelforrest which I need to process into gfxboot input
<highvoltage> slangasek: will do, thanks for the input
<slangasek> cjwatson: ah, didn't realize those were still outstanding - ok
<slangasek> cjwatson: do you want to warn ubuntu-doc as well, on the off chance that someone is trying to take screenshots of this using either the pre-UI-freeze alpha-3, or a current daily? :)
<highvoltage> slangasek: I could include the link to the new branding page in the message I sent and also tell the doc team that they should be careful when seeing an old Ubuntu logo anywhere. It should probably be filed as bugs when there are?
<slangasek> highvoltage: yes, I imagine so
<cjwatson> highvoltage: ah yes - thanks
<ogra> hmm
<ogra> Keybuk, pitti, whom can i blame for that ? udisks or udev ? http://paste.ubuntu.com/388309/
<Keybuk> blame?
<Keybuk> that looks correct to me
<ogra> huh ?
<pitti> ogra: what's the problem?
<Keybuk> you have a disk, you ejected it
<ogra> the partition device nodes are all gone
<Keybuk> and the partition nodes are gone
<Keybuk> you ejected it
<pitti> ogra: if you want to remove the entire device, you have to use "safe removal"
<Keybuk> "<here i unmounted klicking the eject button in nautilus>"
<ogra> i just wanted to mount it to /mnt
<pitti> ogra: then you unmount, not eject
<ogra> because nautilus uses insane settings so i cant chroot
<Keybuk> so Unmount in nautilus, don't Eject or Safely Remove
<ogra> well, i only click the button in the treeview
<pitti> right, that's "eject"
<ogra> its not clear to me it removes the partitions
<ogra> especially since that behavior changed
<Keybuk> I was always disappointed that Eject didn't activate some kind of spring in the USB port and fire the drive across the room
<pitti> it did?
<pitti> it's been like that for ages
 * ogra just used finger memory 
<Keybuk> definitely been like that since Eject actually worked on USB devices
<Keybuk> Eject powers down the USB device
<ogra> i do it ten times a day with SD cards
<pitti> Keybuk: we disabled that patch, it killed too many small pets
<Keybuk> the disk node remains so you can power it back on again
<pitti> or flower pots
<researcher1> Installed  Ubuntu 10.04 LTS- the Lucid Lynx. Applications are opening slowly. Is it correctable ?
<Keybuk> pitti: I understood that they're suspended now again?
<ogra> i admit i didnt use USB keys for a while ... so it did only change for USB ?
<Keybuk> ogra: yes, this is a USB core feature
<ogra> aha
<pitti> Keybuk: "suspend"?
<persia> ogra: SD cards work differently then USB deivces, because of how the hardware is implemented.
<Keybuk> pitti: USB autosuspend
<Keybuk> pitti: I'm not entirely sure I'm up to date on this though
<pitti> Keybuk: I'm not sure; do we enable this these days?
<Keybuk> not sure either ;)
<pitti> I saw it go back and forth for some particular devices
<pitti> it caused a lot of grief with input devices
<Keybuk> I *think* we suspend the devices, not the port
<Keybuk> and before we actually powered off the port in a way that meant it wouldn't come back for some people
<Keybuk> but again, not 100%, check with a kernel team member :p
<Keybuk> either way, it's utterly correct that Ejecting a device makes the partition nodes vanish <g>
<ogra> yeah, i'm just to used to SDs it seems :)
<Keybuk> you don't usually partition SD cards, do you?
<ogra> sure i do
<Keybuk> why?
<ogra> we have to for our armel images
<ogra> because the bootloader sits in a raw partition
<Keybuk> that's like partitioning a floppy disk
<ogra> well ...
<ogra> tell that to arm manufacturers :)
<ogra> make them implement a BIOS ;)
<persia> Keybuk: Why?  You can get 64GB SD cards these days.
<persia> ogra: Just stuff the bootloader in NOR, and you don't have to do that.  Provide a shim solution for folks that have vendors that didn't put the right bootloader in NOR>
<ogra> persia, doesnt work with livfefs images ... even our CDs have isolinux
<Keybuk> persia: those are SDHC cards
<ogra> Keybuk, oh, sorry, i generalized to much ... indeed i use SDHC cards here too ... if it starts with SD* its an SD for me :)
<superm1> pitti, yes i think adding the headers should help, gcc/make can stay out and just get conditionally installed
<Keybuk> oh, sorry, my SD spec knowledge is wrong - I thought it was rarely partitioned - but the spec says SD should have an MBR partition table on it
<ogra> can you even buy plain SD still ?
<pitti> superm1: that's what didrocks did now; thanks
<superm1> cool; good
<didrocks> yeah, it's done :)
<didrocks> just cross fingers for tomorrow CD size :)
<persia> ogra: They are sold in a separate section at most electronics shops here.  There's still lots of stuff that can't understand SDHC
<ogra> ah, well ... i havent seen them for a while around here
<persia> ogra: Works on my Netwalker :p
<ogra> yeah, your netwalker is just missing a 24" display :)
<Keybuk> ogra: I had to buy a plain-old SD card a while back; device didn't support SDHC
<ogra> wow
<nigelb> As per the discussion in the -devel ML, it was okayed to change 'short name' field to 'username', I had uploaded a debdiff, can one of the main sponsors look into this?
<nigelb> bug 529744
<ubottu> Launchpad bug 529744 in gnome-system-tools "When creating a new user, "Shortname" should really be "Username" ." [Low,Triaged] https://launchpad.net/bugs/529744
<pitti> ogra: BTW, if you want special mount options/path for this SD card, add it to /etc/fstab (with /dev/disk/by-{uuid,id,label})
<pitti> that's the official way, and udisks/gnome will respect it
<hyperair> is it me or did wiki.u.c just get owned by the digg effect?
<ogra> pitti, oh, for chrooting you mean ?
<ogra> that sounds helpful
<cjwatson> Keybuk: sigh, every time I look at bits of this vga patch, it gets more complicated
<cjwatson> now I realise that I'm going to have to copy the default font out of the hardware at vgacon startup
<Keybuk> heh
<cjwatson> because BROKEN_GRAPHICS_PROGRAMS is defined by default
<Keybuk> maybe you need to disable CONFIG_BAD_KERNEL_CODE_NOBODY_TOUCHES_ANYMORE
<cjwatson> I think this is more a metaphysical assertion
<cjwatson> "graphics programs are broken"
<pitti> bdmurray: any idea why http://qa.ubuntu.com/reports/bug-fixing/lucid-fixes-report.html suddenly stops at 2010-01-06 ?
<jibel> mvo hi, I talked to enrico about searching package names with an '-' , he sees no better way to do this.
<jibel> mvo, I've been playing with the index too, but the results are not more relevant and sometimes worse. The index is also much bigger (+50%)
<jibel> I believe we've reached a good level, we could add some refinements but I need more detailed specs.
<jibel> mvo, what are the plans regarding quick search issues in synaptic ?
<mvo> jibel: my current plan is to merge your fixes :)
<persia> Anyone have a really long memory about ports status?  My memory is that we always had ports.ubuntu.com, and that powerpc moved from archive to ports in edgy, and the rest have always been where they were.  Does anyone remember differently?  Was sparc ever on archive.ubuntu.com?
<siretart`> persia: I'm pretty sure I've installed spooky from archive.ubuntu.com
<jibel> mvo, great !
<LaserJock> I thought sparc was "official" for a while
<persia> Yeah, that was what I thought, but I can't remember when it was official.
<persia> It's not official for anything supported now, but that doesn't matter for my current activity.
<bdmurray> pitti: it likely was running when lp went down yesterday
<persia> No, it was on archive for dapper.
<persia> For dapper ports is just ia64/hppa
<mvo> jibel: probably tomorrow because of outstanding merges today
<mvo> jibel: what is the scope - just the synaptic fix or does it require changes to the indexer (sorry for my forgetfulness)
<jibel> mvo, np. I don't want to stress you.
<jibel> The scope is only synaptic.
<mvo> jibel: ok, cool. yeah, I will just merge, its on my todo list (anlong with the other pending fixes)
<mvo> jibel: and no worries, you don't stress me, just the opposite, I'm very happy about the fixes :)
<jibel> I'll integrate the latest search code tonight, so tomorrow is ok.
<jibel> mvo, btw I cleaned the synaptic bug reports down to a reasonable level.
<kwwii> hrm, anyone else experiencing file system errors on lucid? two machines in an hour went down
<jibel> mvo, could we organize a session to decide which ones are worth fixing before lucid, later and won't fix ?
<ogra> kwwii, all fine over here
<mvo> jibel: absoutely, either tomorrow or monday. or you can mail me the candidates and I'm happy to mail feedback back
<jibel> mvo, I'll prepare a wiki page with the bug list then.
<mvo> jibel: cool, many thanks!
<persia> After some digging, it appears powerpc first released on ports for feisty and sparc first released on ports for hardy.  If anyone has a good idea when we *first* supported these architectures, please let me know.
<ogra> why do you care for pre-hardy ?
<ogra> it wont get SRUs or anything anyway
<ogra> so its irrelevant for your fix i guess
<persia> Um, no.
<persia> SRUs go back to Dapper.
<ogra> dapper is EOL on the desktop, no ?
<persia> And I need even more information for my current activity, although I won't cause regression if I don't have it.
<LaserJock> are Dapper and Hardy the only LTS releases so far?
<persia> Yes.
<Keybuk> yes
<persia> pre-Dapper was still in wild development.
<LaserJock> I could have sworn sparc was added as official for an LTS release
<persia> LaserJock: New for Dapper maybe?
<ogra> yes, dapper
 * persia reads ubuntu-announce harder
<LaserJock> that would be my guess
<ogra> it was added before to the official releases iirc
<Keybuk> LaserJock: not sure it was new for an LTS
<Keybuk> LaserJock: it was certainly an official port for dapper
<LaserJock> not new as an arch
<persia> Keybuk: Do you know if it was an official port pre-Dapper?
<LaserJock> but I thought there was a big "thing" with Sun over Ubuntu Server and part of that was making sparc official
<Keybuk> persia: not sure on that one
<persia> Ah, the days when new LoCo teams showed up on ubuntu-announce@ :)
<Keybuk> I blame jono
<jono> lol
<nigelb> anyone from the release team around to discuss an ffe?
<Keybuk> jono: you're too good at your job; encourage fewer teams, so we can announce them again! :p
<Keybuk> nigelb: try #ubuntu-release
<nigelb> thanks Keybuk :)
<jono> Keybuk, hehe, I will do if you stop my computer booting so quick
<Keybuk> jono: tell me about it
<jono> I use computer booting time as a good opportunity to make a coffee usually
<Keybuk> both pitti and I have had issues where we've rebooted
<jono> fast boot = no coffee
<Keybuk> turned away for a few seconds, looked back, and thought "now, why haven't you rebooted?" when it already has
<jono> Keybuk, so damn cool
<jono> :)
<azeem_> did you consider to have the boot splash be a screenshot of the gdm login?
<azeem_> like they do for starting up iPhone apps I heard
<persia> azeem_: Please, no?  I *like* that I know which password to enter.
<ogra> for autologin your would ahve to make it a screenshot of the desktop then
<LaserJock> hmm, then it'd be just like Windows
<LaserJock> stare at your screen for a little bit before you actually get to do any work
<ogra> if it would be like windows you could just use a permanent screenshot
<andreasn> let the system take a screenshot when you're turning off the machine and hope it's nothing inappropriate :)
<LaserJock> ogra: well, Windows would be a permanent BSOD, no? ;-)
<ogra> well, i would probably add a little animation that pretends it to upgrade at random times and replace different BSOD's
<ogra> -it
<LaserJock> heh
<LaserJock> ogra: I had totally forgotten how "wonderful" the windows update experience was until I got my new job
<ogra> lol
<persia> Anyone with retroactive moderation rights to ubuntu-announce want to kill https://lists.ubuntu.com/archives/ubuntu-announce/2006-February/000052.html ?
<LaserJock> ogra: my coworker had problems where his computer would never log in
<LaserJock> ogra: we waited 8 hrs one day while it looked like it was updating
<LaserJock> ogra: we called the help desk and they said "yeah, it does that sometimes"
<ogra> sometimes ... heh
<ogra> persia, but ... but ... we won !
<dpm> pitti, is it possible to have an apport hook for a project in LP, even if there isn't a source package available? We are using the ubuntu-translations project to track translation bugs, and I was thinking if it would be possible to have something like 'ubuntu-bug translations' and file a bug against ubuntu-translations
<jcastro> lifeless: +patches has landed in lp, please go bang on it.
<dehqan> a package is installed from 9.10 rep , but now it can not be downloaded and reinstalled from 9.04 rep , why ?
<thiblahute> Hi everyone, I am getting an issue with the RTL8187 module on all the kernel of the 2.6.32. I looked for a bug but didn't find anything so I think it's maybe due to my install which is a bit old and I upgraded from 9.10. What happens is that I can't activate the wifi, like my wlan is down at but and "sudo ifconfig wlan0 up" return "SIOCSIFFLAGS: Unknown error 132".
<thiblahute> I am now using the 2.6.31-17 kernel.
<thiblahute> What do you think I should do?
<thiblahute> Here are some more infos: http://pastebin.com/HUc9kgym
<pitti> dpm: yes, we could arrange that; it sounds like a good symptom to have
<pitti> dpm: a symptom script is not related to a package; however, right now it has to figure out an affected package name
<pitti> dpm: but this could just be language-pack-$LANG, and the symptom code could instruct Apport to file the bug against a project instead
<pitti> dpm: can we discuss details of that in a bug report? I think it's possible in general
<pitti> dpm: (bug against apport-symptoms)
<sitsofe> ok quick question
<sitsofe> a friend and myself are seeing the same problem in Lucid wrt to pulseaudio and the left right balance
<sitsofe> the problem is simple: changing the left/right balance in the gnome-volume control
<sitsofe> is causing the main volume to be reduced to 0
<sitsofe> highly reproducible
<sitsofe> reproduced on laptops and desktops
<sitsofe> and it doesn't happen in Fedora 12
<sitsofe> however folks seeing the problem are reluctant to file any more bugs on sound as their existing sound bugs don't see attention
<sitsofe> is it worth filing?
<LucidFox> Are the branding changes already introduced in Lucid?
<pitti> LucidFox: several uploads landed today, yes
<persia> sitsofe: It's always worth filing sound bugs.  They get reviewed and fixed at a rate of 10s of bugs a day, and some days 100s (I think the most I saw in a day was 327).  This doesn't keep up with the filing rate, unfortunately, but the unfiled bug will never be fixed, whereas the filed bug has a chance.
<LucidFox> Hmm, perhaps I could overwrite Karmic with a fresh Lucid install on my home machine...
<dehqan> how apt-get determines what version the distro is  ?
<sitsofe> persia: ok I'll give it go
<sitsofe> dehqan: why? :)
<dehqan> sitsofe:  apt-get --reinstall install $(cat /2) can not download packages from jaunty reps
<sitsofe> dehqan: I thought it just used repos listed in /etc/apt/sources.list
<dehqan> sitsofe: lsb_release -a says it is jaunty nut apt-get can not download packages from jaunty reps
<sitsofe> are you sure the problem is on the repo end?
<sitsofe> s/is/isn't
<sitsofe> dehqan: but strace says it does peek inside /etc/debian_version (who knows what it does with that info)
<dehqan>  /etc/debian_version ?
<dehqan> sitsofe:  /etc/debian_version ?
<sitsofe> dehqan: I don't know what it does with it though. Maybe it just stores that info for later. You can run strace with apt-get and see for yourself
<dehqan> sitsofe:  would you give command ?
<sitsofe> strace apt-get
<persia> Um, this discussion really belongs on #ubuntu.
<sitsofe> persia: my bad
<sitsofe> sorry
<persia> No worries, but do take it there or to /query please.
<sitsofe> persia: Ok I'll be quiet :) Thank you.
<persia> No need to be quiet: just on topic :)
<dehqan> persia: non dev didn not know  strace apt-get command it is useful
<dehqan> where does this command show distro ? strace apt-get
<dehqan> persia:  where to ask this ?  lsb_release -a says it is jaunty nut apt-get can not download packages from jaunty reps
<persia> dehqan: As I told you in /query 15 minutes ago when you asked me directly instead of the channel, apt-get selects download files based on /etc/apt/sources.list.  Please do take this discussion to another location.  It is off-topic for this channel.
<dehqan> persia: am saying source file includes jaunty reps http://pastebin.com/hLYWSXHS
<dehqan> but persia maybe this is cause of that libc6 upgrade
<sitsofe> dehqan: I'll answer you privately but here's probably not the place to ask
<persia> The cause of the libc upgrade was the change in sources.list from jaunty to karmic.
<persia> I shall not answer any more questions on this topic in this channel.
<dehqan> persia: see it is jaunty now http://pastebin.com/hLYWSXHS
<dehqan> maybe we should talk un bugs channel persia
<dehqan> persia:  how to make apt-get download from jaunty  with force ?
<Laney> You have been asked to take this topic elsewhere. Please do so.#
<dehqan>  how to make apt-get download from jaunty repo ?
<dehqan> sorry sorry my bad
<sitsofe> persia: for what it's worth bug 532095
<ubottu> Launchpad bug 532095 in pulseaudio "Changing left/right balance in sound-preferences changes the output volume slider" [Undecided,New] https://launchpad.net/bugs/532095
<sitsofe> persia: we'll see how it goes :)
<persia> sistolfe: Thanks for filing.  Good luck.
<jono> quick q
<jono> I am moving systems, and I would prefer if I didnt need to set up all my keys for LP again for uploading to my PPA
<jono> what do I need to back up to make the move?
<jdong> jono: back up your ~/.gnupg and ~/.ssh
<jono> jdong, thanks!
<jdong> sure thing!
<jono> and if I just back them up and restore them on the new syste, everything should just work?
<jcastro> yeah
<jdong> yep, that'll preserve the two ways Launchpad cares about your identity/keys
<jcastro> seahorse also lets you export and import keys
<jono> cool
<jono> thanks!
<jdong> and of course, be careful what you do with the backup medium transporting those files
<jono> yes indeed
<jdong> they are considered somewhat secretive and generally bad (tm) to lose :)
<mpt> thanks for the quick fix, micahg
<micahg> mpt: no problem
<jdong> jono: and for convenience you may want to take a quick glance at your ~/.dput.cf to see if you configured any shorthand nicknames for your PPA's
<jono> thanks jdong
<lifeless> jcastro: so I see
<mdeslaur> cr3: sorry about that...first thing tomorrow morning, I'll look at it
<cr3> mdeslaur: don't feel too bad, you're not alone :)
<neurochrome> Hi folks, can anyone else confirm that gvfsd-metadata process is hogging 100% cpu?  With a recent update in Karmic my system has become very unstable and nautilus frequently hangs/crashes
<SparkieGeek> hi, what's the best way of getting an SRU reviewed? I followed the steps on the wiki as best I could but haven't heard anything..
<JFo> SparkieGeek, when did you finish doing the steps?
<JFo> It can take some time for the review and approval
<SparkieGeek> couple of weeks ago
<SparkieGeek> to start with i'd just associated a Bzr branch instead of attaching Debdiff - rectified that last week
<SparkieGeek> wasn't sure what the expected timelines are, so figured i'd come on here and test the waters
<neurochrome> Hi folks, can anyone else confirm that gvfsd-metadata process is hogging 100% cpu?  With a recent update in Karmic my system has become very unstable and nautilus frequently hangs/crashes
<jdong> superm1: do you have any juicy details about when we expect fglrx for xorg 7.5?
<jdong> superm1: it's really fun to watch radeonhd deadlock during convenient times, but eventually I'll want to get work done :)
<jdong> (yeah yeah I'll try to capture a backtrace eventually)
<superm1> jdong, i only help with the packaging on it, and even then, tseliot is doing more of the work now
<superm1> so no idea
<jdong> ah, ok :)
<jdong> awww thought you'd have some juicy details.
<chrisccoulson> kees, re bug 531583 - are you using greasemonkey from the archive?
<ubottu> Launchpad bug 531583 in firefox "greasemonkey causes ff 3.6 to not load, without errors" [High,Confirmed] https://launchpad.net/bugs/531583
<ccheney> so what do i need to change to fix the button order in gconf?
<ccheney> ah i found it
<chrisccoulson> ccheney, /apps/metacity/general/button_layout
<chrisccoulson> oh
<ccheney> chrisccoulson: thx
<kees> chrisccoulson: no, external.
<chrisccoulson> kees, oh, and you can still recreate the issue?
<kees> chrisccoulson: totally.
#ubuntu-devel 2010-03-05
<asac> slangasek: http://pastebin.com/psqA6BAL ... thats the rebuild list for thumb2 + main ...
<asac> slangasek: you want me those chunks to stage in an empty native PPA or rather directly in archive?
<asac> for me native PPA would feel safer, but its your say
<DaemonFC> Why is the terminal now purple? Who could have thought that was cute?
<DaemonFC> https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/532355
<ubottu> Launchpad bug 532355 in gnome-terminal "Making the terminal purple is not appropriate after the user changes the wallpaper." [Undecided,New]
<slangasek> asac: I don't see any benefit to staging it in a PPA
<persia> Excellent.  320 packages to keep the buildds humming over the weekend.
<Sarvatt> was mesa-utils recently demoted to universe or something? I was just trying out a kubuntu livecd from today and it looks like kwin desktop effects need glxinfo installed which is in universe and not on the cd
<persia> glxinfo is in universe, but it doesn't show at http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<Sarvatt> was just thinking maybe it got demoted after compiz stopped needing it in early lucid
<Sarvatt> its part of the mesa source package
<persia> Potentially.  I suspect the kwin desktop effects need to recommend or depend on it if they don't.
<persia> Do you know which package is breaking without it?
<Sarvatt> it's not really breaking, its just that you cant enable opengl compositing in KDE without mesa-utils installed and it's not on the cd and it doesn't seem like that was intentional
<persia> OK.  I'll go see if I can find someone who knows, and maybe it can be sorted.
<ejat> anyone here know the issue networkmanager in lucid alpha3 ? which is its keep connecting ... either wired @ wireless ?
<persia> ejat: You probably wanted to ask that question in #ubuntu+1 or #ubuntu-bugs
<ejat> persia: owh ok .. going there ..
<jayvee> Anyone here that has a vague idea of how Wubi works? Iâm âremasteringâ a 9.10 live CD, which works beautifully with Ubiquity. But when I launch Wubi from my remastered disc, the âInstall inside Windowsâ button is gone from the splash screen, whereas it shows up on the 9.10 âgoldâ image.
<jayvee> So there is some logic in Wubi that makes it check for whether to enable the âInstall inside Windowsâ button or not. Iâd like help trying to find out where and what that logic is. :)
<persia> jayvee: Your best contact is xivulon, who can sometimes be found in #ubuntu-installer
<jayvee> will ping him
<jayvee> cheers
<persia> (which is generally a good place to ask installer questions, but not so much at this time of day: tends to be on a UTC+0 schedule)
<jayvee> UTC+10 here
<jayvee> +11 actually â daylight savings.
<persia> Yep.  Your IP gives you away (even though you're using the good kind of network)
<StevenK> Ahhh, another SLUG person :-)
<jayvee> xivulon isn't on at the moment, but I'll try asking anyways.
<crimsun> slangasek: are you still experiencing #382440?
<MindVirus> Where can I find the code for the logout dialog box?
<MindVirus> Would Alpha 3 accept a patch for a checkbox on the logout box to save settings?
<MindVirus> I'm sorry, Alpha 4..
<micahg> MindVirus: no alpha 4, patches always welcome, no guarantee when they'll land :)
<micahg> MindVirus: beta 1 is the next release
<MindVirus> OK.
<MindVirus> Where can I find the code?
<micahg> MindVirus: might want to file a bug first to make sure it's accepted before putting a lot of time into it
<MindVirus> micahg: OK.
<micahg> MindVirus: bug 44010
<ubottu> Launchpad bug 44010 in gnome-session "Feature request : shortcut to save session while logging out" [Wishlist,Confirmed] https://launchpad.net/bugs/44010
<MindVirus> micahg: Should I send a patch even though it's been 4 years?
<micahg> MindVirus: yes!  those are great bugs to be able to close if it's not resolved :)
<micahg> MindVirus: actually, I spoke too soon
<lamalex> Is there a way to apply debian/patches so that new patches that need generated are relative to the patched source?
<micahg> MindVirus: check with seb128 to make sure it's still wanted :)
<lamalex> other than just running a loop with patch <
<micahg> MindVirus: you could actually just ask in the bug
<RAOF> lamalex: Depends on the patch system.
<RAOF> lamalex: Generally, âdebian/rules patchâ will do the right thing
<lamalex> i know there's a command to see what patch system is in use..
<RAOF> what-patch, yeah.
<lamalex> thanks
<lamalex> cdbs
<lamalex> RAOF, ^
<RAOF> Oh, sorry.  âdebian/rules patchâ should work, I think.
<persia> It does.
<RAOF> I'm also pretty sure you can pass a patch to apply first to cdbs-edit-patch.
<lamalex> and it will modify the patch based on the other patches?
<lamalex> oh, nevermind
<persia> for cdbs it's generally best to just use cdbs-edit-patch, do stuff, and edit.
<persia> (at least for cdbs+simple-patchsys)
<persia> I'm getting a FTBFS of python-apt on i386, using the source in the archive.  That source was uploaded on 1st February (and build successfully).  The errors are mostly of the class "error: 'string' was not declared in this scope" (where 'string' is replaced by other things).  Does anyone happen to know what toolchain changes may have caused this, or a strategy to work around it?
<DaemonFC> Is there a way to restore proper minimize/maximize behavior?
<persia> DaemonFC: That's really a question for #ubuntu or #ubuntu+1 (yes, I know)
<DaemonFC> how can they step in and change the maximize/minimize order to be different from not only every GUI since the mid 1980's to every other GUI that currently exists?
<DaemonFC> this is not going to be popular
<DaemonFC> why do they want to make people re-learn basic GUI manipulation that they've known for 25 years or more?
<DaemonFC> what does this gain Ubuntu other than frustrated users?
<mtx_init> to be honest you are not being very clear.
<DaemonFC> it's not like this is a cure cancer patch, it's shift stuff around for no reason
<DaemonFC> mtx_init, They changed it from minimize,maximize,close to maximize,minimize,close
<RAOF> mtx_init: I assume that the complaint is that the new Metacity theme switches the order of the minimise and maximise buttons.
<mtx_init> i use clearlooks
<DaemonFC> this is stupid, actually stupid is too mild a word but I'll leave it at stupid
<persia> DaemonFC: You could always select a different theme, but really, this isn't the best channel.
<DaemonFC> persia, It puts them in the wrong order regardless of theme
 * persia was fairly certain the order was determined by the theme
<DaemonFC> that was actually the first thing I tried before poking around in gconf-editor and changing it back
<mtx_init> DaemonFC: if you are so very dissatisfied, why not just write a patch
<mtx_init> DaemonFC: can you change the setting easily ?
<DaemonFC> a restore sane and conventional GUI behavior of the last two decades patch
<RAOF> persia: It's actually in /apps/metacity/general/button_order, for some reason.  You'd think it'd be in the theme, though.
<DaemonFC> yeah, flip a gconf key
<persia> RAOF: Odd.
<RAOF> +1 metacity theme format weirdness.
<DaemonFC> reboot and find yourself in the mirror universe
<mtx_init> is this a theme change or a overall change to gnome?
<DaemonFC> they should render fonts backwards too to enhancereadability
<DaemonFC> change to GNOME :P
<mtx_init> To be honest if somebody is minimizing their app, they are implying at the time being they dont need it.  So if they accidentily hid the close button, it would be less troublesome.  Compared to if they were maximizing and accidentally hit close.
<mtx_init> hit
<mtx_init> thats likely the reason.
<Mirv> if someone happens to be in search of a challenge, find out how on earth to compile git://git.debian.org/collab-maint/ffmpeg2theora.git (0.26) on Ubuntu... would be welcome for the tool to be useful (two-pass), but might be too hard
<DaemonFC> mtx_init, No, it's not like that. You'll minimize when you want to maximize and maximize when you mean to minimize it
<Mirv> (and yes it doesn't compile on Debian either)
<DaemonFC> there's no reason for this behavior and it's a practical joke I hope
<DaemonFC> this is the kind of thing you do to a co-worker while they're out to lunch to be mean
<mtx_init> DaemonFC: what I mean is that it makes more sense the new way.  It is mess up prone.
<mtx_init> less
<mtx_init> less mess up prone.
<persia> Um, really.  This isn't the best place.
<DaemonFC> in that case, why not do close,minimize,maximize?
<persia> If you want to talk about a theme, and you don't want to use support or social channels, try -artwork.
<mtx_init> DaemonFC: start writing some emails I guess, get a petition going if you are so concerned.
<persia> Bother.  It's not even arch-specific.  I can get the same build-failure for powerpc :(
<bigon> how can I resent a bug with apport? I still have the .crash file but the upload failed the first time?
<pitti> Good morning
<superm1> bigon, apport-bug /var/crash/file
<bigon> superm1: thx
<dholbach> good morning
<GheRivero> morning
<mtx_init> will dump(8) work on ext4?
<GheRivero> offcial release of dump from june has ext4 support included
<mtx_init> GheRivero: should the man page be updated?
<GheRivero> i think so, anyway is still experimental, like ext3 support :!
<mtx_init> lol, ok.
<mtx_init> as of now though have tests shown it is moderately safe?
<GheRivero> not any real test so far, anyway all the hard work is done by e2fsprogs
<mtx_init> ok, seems like many people dont use dump anymore.  I think its great.
<GheRivero> i doubt anybody rely on it already
<mtx_init> what do they use instead?
<GheRivero> some backup system, tar, rsync... who knows
<GheRivero> for personal use i will stay with rsync
<mtx_init> yeah, but its not really incremental like dump.
<GheRivero> it can be done incremental with rsync
<mtx_init> i thought the delta algo needed to see the files.
<mtx_init> il have to look that up
<ev> bdmurray: thanks for the apport hook in usb-creator!
<ion> Iâm using rsnapshot.
<mtx_init> how is that working out ion
<ion> Iâm very happy with it. It does need to see the older snapshots, though. But this is offtopic. :-)
<GheRivero> it's an rsync with steroids :)
<mtx_init> GheRivero: is that what you use as well?
<mtx_init> there is also rdiff
<GheRivero> i use privative backup software on the servers (enterprise policy) an rsync-scripts at home
<kees> cjwatson: was removing the Ubuntu version number from the generated menu when moving to grub-pc intentional?
<\sh> mvo: why does python-apt recommends a javascript lib (libjs-jquery)?
<mvo> \sh: for the html documentation
<mvo> \sh: if that is a problem I can move it to suggests
<cjwatson> kees: somewhat.  in part it was just that nobody implemented that bit, but (as I wrote in a bug report on the subject recently) the Ubuntu version numbers were often wrong in edge cases anyway and I think there's an argument that no version numbers are better than wrong ones
<cjwatson> so it's kind of "I never really liked the old way anyway"
<\sh> mvo: it installs by default during a server install...I wonder if this is necessary...
<mvo> \sh: no, I guess best is to move the html to python-apt-docs - could you file a debian bug about this please?
<\sh> mvo: sure will do :)
<mvo> thanks
<\sh> mvo: after my meeting there will be a bug
<dpm> Hey pitti, good morning. Thanks for coming back to me on the apport symptom and ubuntu-translations last night. There seemed to be bug 448335 already for that, so I added a comment and opened a task for apport-symptoms
<ubottu> Launchpad bug 448335 in apport-symptoms "Support apport hooks for translation reports" [Undecided,New] https://launchpad.net/bugs/448335
<pitti> dpm: ah, good
<pitti> I'll answer to that asap
<dpm> pitti, thanks!
<dpm> pitti, as a general thought, would it be possible to make langpack-o-matic build the translated xml files from PO files for documentation exposed for translation in LP? I know it might be difficult to find out which PO files actually correspond to translation and thus need xml output instead of mo output, but now that ubuntu-docs are in language packs, would perhaps not be a good compromise to build (well, convert) the xml files from the ubuntu-docs pac
<dpm> kage only?
<dpm> (which PO files actually correspond to documentation, I meant)
<didrocks> cjwatson: hey, about the ubiquity merge for wallpaper caching on install, I've uploaded the new proposal some days ago (https://code.edge.launchpad.net/~didrocks/ubiquity/copy_wallpaper_cache/+merge/20527). I don't know the workflow, do you want me to push it or make a new review first?
<cjwatson> didrocks: no that's fine, it's in my queue, I've just been buried in kernel work for the last two days
<didrocks> cjwatson: perfect, I just wanted to ensure you didn't wait for anything on my side. Thanks :)
<slangasek> crimsun: 382440> nope
<\sh> mvo: BTS -> Bug#572617: Acknowledgement (python-apt recommends libjs-jquery)
<pitti> dpm: langpack-o-matic doesn't process anything in those right now (just shuffles the files around), but in principle I guess it could do it
<dpm> pitti, I think it would make a lot easier the work of the docs team, and would allow docs translations to be updated regularly. Do you think it would make sense to open a bug in langpack-o-matic for that?
<mvo> \sh: thanks
<pitti> dpm: sure, you can do that; I'm just afraid I won't have time to actually work on it
<dpm> pitti, sure, I don't want to load you with more work :) I just want to make sure it's recorded and we can at least discuss it if it makes sense
<pitti> dpm: I think it would (either in LP itself or in langpack-o-matic); it's a step closer to seamless intregration of translations
<dpm> Yeah, I think we can start with langpack-o-matic and ubuntu-docs only, which would already offer a great benefit. Thanks pitti
<ogra> hmm, my gnome-terminal profiles were trashed with the recent theme upgrade ... thats not nice
<pitti> ogra: bug 532511
<ubottu> Launchpad bug 532511 in gnome-terminal "terminal settings messed up after upgrade due to forced profile change" [High,Triaged] https://launchpad.net/bugs/532511
<ogra> ah, thanks pitti
<pitti> I'm glad I'm not the only one
<pitti> ogra: please confirm/affects me too/etc
<asac> what is up with cdrdao and cdrkit ... do we use those by default?
<directhex> asac, yes, cdrikit is afaik. not that anything promped that question, of course
<ogra> asac, cdrdao is a direct dep of kubuntu-desktop
<ogra> cdrkit should be a virtual package iirc wodim should replace it, no ?
<directhex> ogra, wodim is the binary package from cdrkit
<ogra> oh, right
<ogra> i looked at binaries
<directhex> and it's a depends for xubuntu-desktop and brasero, for non-kubuntu users
<directhex> and ubuntu-desktop and you get the idea
<directhex> lots and lots of cdrkit and cdrdao
<asac> directhex: cdrkit fails to build on all archs in lucid ;)
<asac> same for cdrdao
<asac> Richie: ^^
<asac> err Riddell ^
<mok0> jdong: ping
<ogra> The following packages have unmet dependencies:
<ogra> libgtk2.0-bin: Depends: libgtk2.0-0 (>= 2.19.6-1ubuntu4) but 2.19.6-1ubuntu3 is to be installed
<ogra> hrm
<ogra> couldnt the publisher be changed to hold back "Arch: all" packages until all arhes have built
<ogra> i think that would be saner than having stuff randomly fail until the "Arch: any" packages are published
<seb128> ogra: so if powerpc takes one month to build gtk or gtk fails there we will get no update until it's fixed?
<seb128> just taking powerpc as $randomarch
<ogra> seb128, well, one could special case it for ports
<seb128> well same difference
<seb128> gtk build did segfault a zillion times on armel
<ogra> i dont really care for i386 and amd64 ...
<seb128> it would block i386 and amd64 for days
<ogra> i mean for the ports.ubuntu-com archive
<ogra> i assume there is special casing in the publisher code already given its a different server etc
<ogra> so holding back _all.deb from publishing until the arch dependednt packages are there shouldnt be to hard imho ...
<ogra> and we'd never have broken images due to all/any differences
<cjwatson> ogra: no, ports.u.c is split out at mirroring time.  holding back architectures would create all sorts of new problems though.  the proper fix is to publish different versions of _all.deb on different architectures, based on what version of the architecture-dependent binaries are current
<ogra> but that would increase the disk needs massively i suspect
<ogra> since you would multiply the _all.deb packages ...
<cjwatson> ogra: no
<cjwatson> no, you don't store multiple copies when they're all identical
<ogra> ah, you link them ?
<cjwatson> I'm talking about the references in Packages
<ogra> ah, k
<cjwatson> no file name changes
<ogra> yup, i understand now
<geser> cjwatson: but wouldn't publishing several _all.deb increase the chance of packages being build against different versions on different archs?
<cjwatson> geser: it's silly to try to defend against that only for packages with both any and all components, imo.  if it matters, use strict build-deps
<geser> true
<cjwatson> and the current situation isn't explicitly a defence against that or anything
<pitti> kirkland: muhaha! http://qa.ubuntu.com/reports/bug-fixing/lucid-fixes-report.html
 * pitti is reminded of the Go-Kart race in Berlin
<pitti> kirkland: quick, fix 4 bugs!
<kirkland> pitti: i'm sitting on two big bugfix uploads :-)
<kirkland> pitti: just waiting for you to go to sleep :-D
<pitti> ah, darn, and I have to prepare the release meeting
<kirkland> pitti: hehe
<pitti> but it didn't count my 10 fixes from yesterday yet
<kirkland> pitti: yeah, it's kinda funny when and how it counts
 * pitti ^5s kirkland
<kirkland> pitti: i need to look at that source code :-)
 * kirkland high fives pitti back
<pitti> kirkland: probably it's just lagging a bit; I think it updates once a day, and parses the -chagnes ML archive
 * pitti gets a telescope to watch seb128 at the pole position
<kirkland> :-)
<pitti> go, seb128, go!
<kirkland> pitti: http://www.youtube.com/watch?v=71e_TxmCaxk
<seb128> pitti, oh, stats fixed!
<seb128> pitti, I've a good margin apparently ;-)
<pitti> kirkland: ouch!
<kirkland> pitti: hehe!
<ttx> pedro_: around ?
<pedro_> ttx, hello!
<ttx> pedro_: hey !
<ttx> pedro_: zul and I are planning a bugzapping session on samba next week
<ttx> https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-bug-zapping
<ttx> pedro_: given that samba work is mostly triaging...
<ttx> pedro_: I was wondering if we could plug a samba bugday to start it.
<ttx> like Wednesday we do the bug day
<ttx> and Thursday we work on bugfixes
<ttx> pedro_: would that bugday slot be free ?
<pedro_> ttx, we were planning a bug day on gwibber on Thursday so Wednesdays is still free
<pedro_> ttx, i'll coordinate with hggdh and set up everything
<pedro_> hggdh, ^
<ttx> pedro_: we could do tuesday... but I fugured some lead time to announce it would be better ?
 * hggdh sees...
<pedro_> ttx, I'd prefer Wednesday to announce on a week day (Monday) and don't lost the announcement during the weekend
<ttx> pedro_: ack.
<ttx> pedro_: we are mostly after people confirming issues with weird software like Windows 7 :)
<pedro_> ttx, ok noted ;-)
<cjwatson> Keybuk: I've been working on the console-setup upstart conversion, having got as far as I want to get with the kernel for now (and I don't think I'm going to get that kernel change into lucid, I just want to get the ball rolling on it).  Things sort of work, but the font gets reset to the default somewhere around the point where plymouth-splash starts
<cjwatson> Keybuk: do I need to have console-setup start on graphics-device-added or drm-device-added, or something?
<cjwatson> I think part of the problem may be that, while fbcon will copy the font from a previous fbcon, it won't copy from a previous vgacon
<cjwatson> so the font gets set up (I can see it) and then gets reset as the console driver switches over
<Keybuk> cjwatson: that could be possible
<Keybuk> there's a "graphics-device-added fbcon" event
<Keybuk> I'd be concerned about a boot time impact of repeatedly setting a console font, of course
<cjwatson> me too
<cjwatson> I was just about to say the same thing
<cjwatson> I think it's rather fewer syscalls than setting the keymap
<Keybuk> yeah, that's my understanding
<Keybuk> what does "time" say? :)
<cjwatson> keymap seems to be one ioctl per key :-(
<cjwatson> 0.03s for font, 0.11s for keymap
<Keybuk> setupcon -f is 0.03s user 0.04s system
<Keybuk> right
<cjwatson> once the cache is hot
<cjwatson> which it will be the second time
<Keybuk> I guess you only need to set the keyboard once?
<cjwatson> yeah, I believe so
<cjwatson> keymap is working for me now
<cjwatson> you have to set the keymap while not in raw mode, and the font while not in graphics mode
<Keybuk> so the font is per-vc then?
<Keybuk> which doesn't make a huge amount of sense given there's only one font ;-)
<cjwatson> on fbcon yes, on vgacon no
<cjwatson> the patch I sent to kernel-team makes it per-vc in the process of fixing the other problems
<Keybuk> if you set the vgacon font for tty1 when that's in KD_TEXT, but the fg_console is tty7 in KD_GRAPHICS ...
<Keybuk> what happens then?
<cjwatson> but doesn't quite work properly yet
<cjwatson> boom
<cjwatson> almost certainly
<Keybuk> biiiig bada boom
<Keybuk> 'cause obviously what I really don't want to introduce into the boot is VT switches
<cjwatson> console-setup currently checks fgconsole; it's racy, but not much to be done about it right now
<cjwatson> if we can set the font strictly between fbcon loading and plymouth-splash switching mode ...
<Keybuk> I think plymouth leaves the vt in K_XLATE but KD_GRAPHICS
<cjwatson> plymouth sets raw mode
<Keybuk> cjwatson: that doesn't work if fbcon is built-in to the kernel
<cjwatson> or at least calls cfmakeraw
<Keybuk> cjwatson: oh, I stand corrected then
<cjwatson> but setting the keymap 'on starting plymouth-splash' (and other bits to cope if plymouth never runs) appears sufficient
<Keybuk> you'd have to do it on starting plymouthd too :-/
<cjwatson> plymouthd?  I don't have that ...
<Keybuk> err, plymouth.conf
<cjwatson> how come?  it doesn't set raw mode until the splash comes up, AFAICS
<cjwatson> nor does it switch to graphics mode until then
<Keybuk> that will bring the splash up if fbcon is already loaded
<cjwatson> oh
<cjwatson> actually it looks like I just did 'on starting plymouth'; if plymouth is started in the initramfs, then the initramfs scripts already take care of setting up the console
<Keybuk> right
 * cjwatson goes to check the KD_TEXT/KD_GRAPHICS question above in the kernel
<Keybuk> hmm
<Keybuk> do you need /dev/tty stuff to set the keymap or font?
<cjwatson> confirmed; AFAICS, KDFONTOP on a non-foreground VC will cause vgacon to write to video memory and explode if the fgconsole is in fact (say) X
<Keybuk> *cry*
<cjwatson> yes, need /dev/tty*
<Keybuk> argh!
<cjwatson> well, [1-6]
<Keybuk> that makes things even more complicated
<Keybuk> if you need /dev/tty* then you have to also wait for virtual-filesystems
<Keybuk> but plymouth will be started before that
<cjwatson> *blink*
<cjwatson> oh, I was unclear above: we can set the keymap at any time, as long as the console we're actually setting the keymap on isn't in raw mode
<cjwatson> font is the one that depends on the state of the foreground console as well
<cjwatson> it's very tempting to just mknod /dev/tty[1-6] if they don't exist yet
<Keybuk> argh!
<Keybuk> please don't
<cjwatson> boot time?
<Keybuk> partly, plus conflict with udev, devtmpfs, etc.
<cjwatson> mm.
<cjwatson> I guess there's no way to pull tty device creation earlier?
<Keybuk> if using devtmpfs, they'll always be there
<Keybuk> but there's the following case:
<Keybuk>  - older kernel (no devtmpfs)
<Keybuk>  - no ramdisk (so nothing mounted on /dev early)
<Keybuk> so you might have /dev/tty1-6 there as you start, but /dev gets mounted as an empty tmpfs by mountall as you're setting things up, so the device nodes vanish on you
<cjwatson> as long as it doesn't actually explode, I could live with that not managing to set console keymap and font, if that's the price
<cjwatson> until such time as we fix the kernel to not have these painful limitations
<Keybuk> ok, how about this then
<Keybuk> you need the foreground console in KD_TEXT, and most consoles in K_XLATE
<Keybuk> assume we're using fbcon
<Keybuk> so when the fbcon driver is loaded, set up the consoles keymap and font
<Keybuk> that'll cover the majority of cases
<cjwatson> what hardware's going to end up in vgacon for lucid?
<Keybuk> none
<Keybuk> the only way to get that I suspect is using video= on the command-line
<cjwatson> oh, because we use vga16fb and fbcon on top
<Keybuk> exactly
<cjwatson> (hm, I'm not actually entirely sure I'm correct about my assertion regarding the keymap.  we appear to set it on /dev/tty0)
<Keybuk> haha :)
<Keybuk> wonder what happens if you VT switch while doing that :D
<cjwatson> that said, you can do loadkeys --console=/dev/tty1,/dev/tty2,/dev/tty3,/dev/tty4,/dev/tty5,/dev/tty6 and time says it takes no longer here, despite all those ioctls
<cjwatson> I guess the time might just be parsing the cache keymap
<cjwatson> *cached
<cjwatson> Keybuk: so, if I just do this 'on graphics-device-added fbcon', and make sure it guards against the tty being in raw mode or the vc being in graphics mode, that should be enough even if fbcon is built-in?
<Keybuk> I think so
<cjwatson> I have a feeling that there's in fact just one keymap to rule them all
<cjwatson> I'm not seeing much in the way of VC-dependency in here
<Keybuk> probably
<Keybuk> easy well to tell
<Keybuk> set funky keymap
<Keybuk> switch VT :)
<soren> Is there a klingon keymap?
<cjwatson> confirmed, just the one
<soren> If there is, is it just like an English one, but with needle and acid and stuff on the keys?
<Keybuk> cjwatson: so for both you just need tty0 ?
<ion> http://www.slashgear.com/wp-content/uploads/2009/01/klingon_keyboard1.jpg
<Keybuk> or do you need to set font-per-vc ?
<cjwatson> you do need to set font-per-vc
<Keybuk> when VCs are created, does it copy the font from an existing one?
<soren> ion: I thought klingon used an English^WEarth character set?
<soren> Perhaps it's just usually transliterated.
<cjwatson> fbcon at least doesn't seem to
<cjwatson> it copies from a previous fb on the same console if it can, but that's all
<cjwatson> keymap: a hack occurs to me
<cjwatson> it matters if the tty you happen to pick is in raw mode
<cjwatson> therefore, iterate through ttys until you find one in unicode mode, and use that
<Keybuk> that'd work ;)
<cjwatson> they almost certainly won't *all* be raw
<Keybuk> just wondering what happens then
<qense> I've got a project of which multiple binaries are compiled, including a shared library. I would like to link to that library inside those other binaries, but the only working solution I found was adding the source files of the library to the SOURCES of the other binaries in the Makefile.am. Using #include "path/to/file.h" doesn't work, the compiler keeps complaining about non-defined/existing functions.
<Keybuk> you start with VT1
<Keybuk> plymouth creates VT7
<Keybuk> does that mean that VT2-6 exist or not?
<cjwatson> what does it do to create vt7?  openvt?
<Keybuk> cjwatson: VT_SETACTIVE
<cjwatson> YM VT_ACTIVATE?  ok.
<Keybuk> no, VT_SETACTIVE ;)
<cjwatson> no such ioctl
<Keybuk> it's VM_ACTIVATE combined with VT_SETMODE in one ioctl
<Keybuk> err, VT_SETACTIVATE sorry
<cjwatson> ah.  no match for that in plymouth source though
<Keybuk> cjwatson: you're looking at the unfixed plymouth source remember
<Keybuk> the plymouth source with lots and lots of issues around VTs :)
<cjwatson> anyway, no matter, both call vc_allocate
<Keybuk> like doing all the ioctl()s on /dev/console instead of the right VT
<Keybuk> yeah
<Keybuk> does that allocate the intermediate ones?
<cjwatson> I'm just looking
<Keybuk> because that would mean only VT1 exists at the point your stuff gets run
<cjwatson> it doesn't appear to
<Keybuk> then plymouth would make either VT7 only or VT2-7
<Keybuk> so would that not mean that getty 2-6 don't have a font
<cjwatson> hmm.  so what *does* allocate those vts?
<Keybuk> getty I suspect
<cjwatson> I *think* that the act of opening the tty device allocates the VC on it
<Keybuk> cjwatson: the act of observing them calls them into existance?
<Keybuk> how quantum
<gadeynebram> Hoi! Excuse me if i'm in the wrong channel. I'm looking for some information to start contributing with ubuntu as a developer. Can anyone point me in the right direction?
<pitti> gadeynebram: https://wiki.ubuntu.com/ContributeToUbuntu has quite a lot of pointers and is a good "signpost" page
<gadeynebram> tnx pitti
<pitti> cjwatson, ev: hm, what's the magic key to select keyboard/language in the gfxboot screen now? would it be possible/prudent to add a "press F1 to select keyboard" or so?
<ev> any key
<ev> you just have to be quick
<pitti> ah, that gets me back to the old gfxboot
<ev> right
<pitti> yes, not much time
<ev> is that not what you're after?
<pitti> I was trying to make sense of the "keyboard equals human" equation :)
<ev> hahaha
<ev> I think it was the best of a long list of bad options
<\sh> kwwii: dude, how can someone change the window border buttons from left to right, and when do we get the window menu button back? ;)
 * sebner waves at \sh :)
<pitti> ev: hm, maybe I'm just dense, but I find it a bit confusing
<didrocks> cjwatson: thanks for the merge :)
<\sh> hey sebner :)
<cjwatson> pitti: the timeout is five seconds; we couldn't put any text there because it's pre-language-selection
<cjwatson> so the best we could do was hope that people would grok the keyboard icon
<cjwatson> the rebus is supposed to be "press a key for accessibility options", since that's the primary thing left that you can't do any other way
<pitti> ah
<cjwatson> (though not by any means the only thing left and I think the design team over-focus on that part, but ...)
<pitti> would "F1 = <keyboard> <human>" be too evil?
<cjwatson> the idea was to cause fewer people to see the full boot screen
<pitti> I know that it's "any key", but F1 is F1 in many languages at least
<cjwatson> well, talk with Michael Forrest maybe?
<pitti> ah, sure
<pitti> bryceh, tjaalton: can I just upload -vmmouse with a working udev rule, or should I send you a patch, for review/git commit/sponsoring?
<pitti> (I'll send a patch to Debian, too)
<ogra> kirkland, is there any way to create a qemu image that automatically grows without having to specify the imagesize at creation time ?
<kirkland> ogra: sort of
 * ogra thought qcow2 would do it but i'm apparently wrong
<kirkland> ogra: kvm-img create -f qcow2 foo.img 10000G
<kirkland> ogra: that's a 10TB backing disk
<kirkland> ogra: though it shouldn't take that much space
<ogra> indeed
<kirkland> ogra: pick your size
<kirkland> ogra: you have to give it *some* size
<kirkland> ogra: but qcow2 shouldn't use it all
<ogra> well, if i give it 1G and install ubuntu-desktop in it i run out of space
<ogra> at least in qemu-system-arm
<kirkland> ogra: how big is a desktop install now?
<kirkland> ogra: i thought it was 4+G ?
<pitti> nah
<pitti> in two releases ago we were at 2.3 GB
<ogra> should be below 3
<pitti> perhaps 2.5 now
<ogra> i like to keep some buffer space for package cache etc thats why i usually pick 4
<ogra> but for my qcow2 tests i just defined 1 and expected it to auto-grow
<pitti> mdeslaur: thanks for fixing vmmouse_detect!
<pitti> mdeslaur: I have an udevified package now, currently testing in kvm
<ogra> though my prob is that i need to mount the image and converted it back and forth from/to raw ... i only just discovered qemu-nbd ...
<ogra> kirkland, could converting it be my issue ?
<kirkland> ogra: what are you converting it to/from?
<ogra> kirkland, i create it raw, run debootsrap in it in qemu-user ... then convert it to qcow2 and use it as disk for the rest of the install in qemu-system
<mdeslaur> pitti: cool! can't wait to try it out!
<tjaalton> pitti: just upload
<tjaalton> pitti: and thanks!
<pitti> tjaalton: ok, I'll send the debdiff to debian and the rule to an upstream bug
<pitti> thanks
<kirkland> ogra: oh, yeah, DFDT
<kirkland> ogra: :-)  create it qcow2 to start with
<ogra> yeah, i only did find qemu-nbd now ... i need to mount it somehow for the debootstrap run :)
 * ogra is trying to find a proper workaround for bug 532733
<ubottu> Launchpad bug 532733 in qemu-kvm "apt/dpkg in qemu-system-arm hangs if a big task is installed" [Undecided,New] https://launchpad.net/bugs/532733
<ogra> qcow2 sadly isnt loop mountable
<slangasek> geser: if you use LP: instead of lp: in your changelog, there's no need to update bugs by hand to say you've committed :)
<slangasek> geser: this appears to be a bug in bzr's changelog regexp, which curiously doesn't match the dpkg-dev one
<pitti> tjaalton: meh, the first time I blamed my stupidity, but the second time I really triple-checked: building the -vmmouse source kills the .postinst I just wrote.. WTH?
<geser> slangasek: so "lp: #xxx" only works for Launchpad-Bugs-Fixed in .changes files but not for LP itself?
<pitti> argh, "cleanscripts" in xsfbs.mk
<ogra> pitti, eaten by the virtual mouse :)
<tjaalton> pitti: hmm, heh
 * pitti rewrites it a third time, and tries with .in
<geser> slangasek: thanks, will remember that. is there a bug about this filed in LP itself?
<slangasek> geser: probably not filed yet, getting there
<dpm> bryceh, thanks for integrating the patch to load translations from failsafeXinit!
<Keybuk> slangasek: http://pastebin.ubuntu.com/389103/ - was that you?
<slangasek> Keybuk: looks familiar; I'm perfectly willing to believe it's wrong
<Keybuk> it could well be right
<Keybuk> it just wasn't sent upstream
<Keybuk> *spanks*
<slangasek> yes, sorry
<slangasek> tseliot told me he usually interacts with upstream via IRC; so I joined the channel and have seen no activity there since
<slangasek> so the submission got backburnered until I could figure out what I'm supposed to do
<Keybuk> the channel is mostly "bug halfline about things" ;-)
<Keybuk> s'ok, I shall commit for you
<bryceh> dpm, thanks for making it :-)
<Keybuk> grr @ bzr
<Keybuk> I wish the colon would stay put
<Keybuk> bzr diff --old :submit SOME-FILE
<slangasek> sounds like a medical problem
<Keybuk> "ah yes, I need the upstream version"
<Keybuk> bzr diff -r submit: SOME-FILE
<Keybuk> why does the colon dance like that?
<Keybuk> *fumes*
<slangasek> irritable colon syndrome
<Keybuk> lifeless: I blame you
<Keybuk> at least GIT is consistent
<Keybuk> consistent unbearable torture
<jdong> wait when did the colon dislocate like that??
<ion> At least the rectum is still where itâs supposed to be.
<ScottK> You've checked?
<ion> Yeah, i have, your rectum is fine.
<ScottK> That's a compliment I don't often hear.
<Keybuk> http://www.youtube.com/watch?v=xHKTE75dgE4
<ion> keybuk: :-)
<Keybuk> oh, wow
<Keybuk> bzr revert -r submit: FILE
<Keybuk> and
<Keybuk> bzr revert -r :submit FILE
<Keybuk> DO DIFFERENT THINGS
 * Keybuk weeps
<jdong> Keybuk: eeek, is one of the colons acting as a revno separator?
<Keybuk> no, I think one of them means
<Keybuk> "the branch you merged from RIGHT NOW"
<Keybuk> and the other means
<Keybuk> "the branch you merged from AT SOME ARBITRARY POINT IN THE PAST THAT YOU DON'T WANT"
<jdong> what???
<jdong> sheesh
<ScottK> bzr revert -r :submit: FILE probably ends the Universe.
<ion> Whenever someone does that, the universe simply reboots and repeats in an infinite loop.
<ScottK> Cool.  Resolves the open/closed question then.
<Keybuk> bzr: ERROR: ":submit:" is not a valid location alias.
<ScottK> I knew someone would try it ....
<kirkland> ogra: oh, right, qcow2 isn't loop mountable
<jibel> any cups maintainer could have a look at bug 532053 ?
<ubottu> Launchpad bug 532053 in cups "package cups 1.3.9-17ubuntu3.6 failed to install/upgrade: subprocess post-installation script returned error exit status 1 - chown: changing ownership of `/etc/cups/printers.conf': Operation not pe..." [Undecided,New] https://launchpad.net/bugs/532053
<jibel> It appears 3 times today. The latest jaunty upload seems to be broken.
<ScottK> tkamppeter: ^^^
<jmdault> A quick question for the gurus: how do you deal with a FTBFS for lpia?
<jmdault> Is there a way to tell launchpad *not* to build a package for this arch?
<slangasek> jmdault: um... at this point, you generally don't, as lpia is not a supported arch in lucid :)
<jmdault> slacker_nl: I'm backporting to hardy
<slangasek> well, if the only way you were planning to deal with it was by telling Launchpad not to build it, then I think you can ignore it anyway
<jmdault> I thought by having "Architecture: i386 amd64" in debian/control, that it would not build for lpia, but it stubbornly tries to
<Keybuk> that's more of a guideline
<jmdault> I guess I can ignore idt, but it leaves a red X in my PPA and it looks bad ;-)
<Keybuk> I'm not entirely sure whether PPAs even know P-a-s
<lifeless> Keybuk: I don't like that they are different
<lifeless> Keybuk: one means 'the branch you submit to'
<lifeless> Keybuk: the other means 'the common ancestor of the branch you submit to'
<kees> cjwatson: I couldn't even figure out how it was done before.  ucf, I think?  since the os-prober actually examines root filesystems, maybe we can do something similar.
<cjwatson> kees: I'd rather leave it out
<cjwatson> it was a source of trouble, and I don't have time to fix it up
<cjwatson> one problem was that it had no way to spot that some other OS on the disk had been upgraded unless you reran update-grub
<cjwatson> and I think there may have been other problems too
<kees> cjwatson: fair enough.  I'll shed quiet tears.  :)
<kwwii> \sh: gconf and never. :P
<ScottK> \sh: There's a post on planet.ubuntu.com about it.
<cjwatson> Riddell: I'm more than a little bit lost with this ubiquity KDE startup thing
<cjwatson> Riddell: I've been trying to find my way around mazes of KDE startup code for an hour or two now, and it may be time for me to admit defeat
<cjwatson> Riddell: I imagine we just need to start up a couple more bits of KDE ... I could try guesswork
<cjwatson> Riddell: something is getting confused about not being able to talk to the session bus, because I can see in strace that the session bus is running
<cjwatson> hmm, I wonder if it's just kdesudo eating environment variables or something?
<cjwatson> no, can't be that, we're already running as root here
<cjwatson> and ubiquity definitely has DBUS_SESSION_BUS_ADDRESS in its environment
<tkamppeter> ScottK, this is strange, package installation is done as root, so chown should work. In addition, I did not do the latest Jaunty upload. I think it was pitti, but I am not sure. Check Launchpad for who uploaded and see the debian/changelog for what bug got fixed by the SRU and/or security update.
<ScottK> tkamppeter: I just know you have a general interest in the package.
<mdeslaur> jcastro: is anyone working on application indicator support for liferea?
<jcastro> not afaik
<Riddell> cjwatson: what's the best way to play with the stand alone ubiquity startup?
<cjwatson> Riddell: I've been booting with break=casper-bottom and playing with it there
<cjwatson> it's a bit time-consuming, but at least fairly reliable
<cjwatson> Riddell: my current thought is that I could use setresuid() to confuse KApplication into thinking that we aren't running setuid
<cjwatson> but without confusing dbus into thinking the euid is root
<cjwatson> however, this involves writing osextras.setresuid, since python itself doesn't have that until 2.7
<Riddell> cjwatson: it's weird because nothing much has changed in that area since karmic
<Riddell> might be worth trying with an old kdesudo to see if that's it
<Riddell> or even kdesu
<cjwatson> we're not using either
<cjwatson> the install-only mode starts ubiquity up directly as root
<cjwatson> I'm wondering if the change might have been in something like dbus
<cjwatson> I agree not a lot has changed; OTOH if I can fix it with setresuid that might be a win all round :)
<cjwatson> I'm speculating slightly - the strace was hard to make out
<cjwatson> actually I'm speculating a lot
<cjwatson> might be reproducible by starting an arbitrary KDE application as real-root (setuid not seteuid, so su not sudo) though, making sure that DBUS_SESSION_BUS_ADDRESS is passed through
<cjwatson> with any luck it would crash in the same way
<gtlz> any work being done on the "encrypted home directory" stuff to allow users to pick from the different algos? i'd love to be able to pick twofish with a 32 keybit for example...
<gtlz> without having to do it manually
<Caesar> So I have this theory that autofs5-ldap isn't behaving because it's being started prior to the network coming up (it has no upstart job)
<Caesar> Is that possibly what's happening?
<sebner> jdstrand: it makes me pretty sad to say this but please don't sync supertux today (FFe, just subscribed ubuntu-archive) as it's still in incomming *hahah* xD
<jdstrand> sebner: heh, ok
<sebner> jdstrand: thanks :)
<slangasek> Caesar: sysvinit scripts will not be run before localhost is up, but other network interfaces aren't guaranteed to be up
<Caesar> Hmm, so that may well be the problem then
<Caesar> I shall try to write an upstart job for autofs5
<Caesar> How do I specify "when a non-lo interface has started"?
<slangasek> Caesar: cf. /etc/init/nmbd.conf in samba
<Caesar> Very good
<cjwatson> Riddell: I've confirmed that the same thing happens under su
<cjwatson> (admittedly with konqueror rather than ubiquity, but the failure is in the same place)
<Caesar> Hmm, with either expect fork or expect daemon I end up with two automount processes, whereas with start-stop-daemon, I only had one
<cjwatson> Riddell: also confirmed that using setres[ug]id fixes it for launching konqueror in a suitably configured environment
<cjwatson> so I think I'll go ahead with this approach
<kees> tedg: so, I have indicator-applet on my panel.  it has a little envelope thing that implies it's related to pidgin.  how do I get rid of that?
<tedg> kees: Pidgin or the applet?
<tedg> kees: There is xchat messaging menu integration now...
 * tedg hugs kenvandine
<kees> tedg: then envelope itself.  it's an icon on my desktop that is meaningless for me, so I don't want it showing up.
<kees> tedg: also, the volume control icons are busted; how do I fix that?
<tedg> kees: If you really want it gone you can apt-get remove indicator-messages
<tedg> kees: But if you just want the icon to leave you can copy /usr/share/indicators/messages/applications/* to ~/.config/indicators/messages/application-blacklist
<tedg> Hell you could probably sym link it... but I haven't tried that.
<kees> tedg: so, just having a file there causes an icon to appear?  I'm running neither pidgin nor evolution, so I wouldn't expect an indicator for it.
<tedg> kees: The idea is that you don't need to know if the program is running or not to find the messaging menu useful.
<persia> kees: The trick is that it's not trivial to tell what might send DBus messages.
<superm1> but if you close pidgin buddy list it doesn't stay running?
 * persia is gleefully removing indicator-messages and indicator-me
<kees> how about having it only show up if pidgin or evolution sends a message?
<tedg> persia: That's actually not an issue, we do lots of crazy things to make it so we can discover that :)
<persia> tedg: Can you do more crazy things, because I'd like my panel space back :)
<tedg> kees: We do, only if they're installed.  By installing them you're sending a message :)
<persia> tedg: Except I've gone through and purged all of evolution and pidgin, and I still have it.
<tedg> persia: That is probably because you were on devel release for karmic.
<persia> tedg: No, this is in lucid.
<tedg> persia: There's probably a file in /etc/indicators/* that was installed.
<kees> tedg: no, i mean, it's fine that the files are there and installed, but why show the icon before the application has sent a notification?
<tedg> persia: We couldn't remove them in /etc, so that's why it's /usr/share now.
<persia> ls: cannot access /etc/indi*: No such file or directory
<kees> tedg: to confirm, ~/.config/indicators/messages/application-blacklist  (singular, not plural "application") should be a directory contiains the files from  /usr/share/indicators/messages/applications/ ?
<tedg> kees: I realize what you're saying.  And I'm saying that we can't really figure out whether you're using an application or not.  We want to have an entry there whether it's running or not.
<kees> tedg: so far, symlinks, copying, plural and singular, has not worked
<kees> tedg: can you explain why?  (i.e. it's never sent a message, so why is there an icon?)
<tedg> kees: ~/.config/indicators/messages/applications-blacklist/
<tedg> kees: Sorry, I think that was wrong before
<persia> tedg: blacklisting is great, but the complaint is that it shows by default even if clients aren't installed.
<kees> tedg: blacklist doesn't work.  can you confirm it works for you?
<tedg> kees: You could say that the same about the Applications menu :)
<tedg> kees: Yeah, I have Empathy blacklisted
<kees> tedg: no, that's for applications I want to start.  the notification area is for messages that are waiting for my attention.
<tedg> persia: If it's not installed, that's a bug.
<kees> tedg: do I need to restart something for it to notice?
<tedg> kees: Your clock wants your attention?
<tedg> kees: No they're all watches.
<kees> tedg: my clock is running.  it's a separate applet completely.
<kees> tedg: update manager sends a notification, an icon appears.
<persia> tedg: Just to confirm, I should be able to have indicator-messages installed and not see an icon if I have neither of pidgin or evolution installed, right?
<tedg> kees: Think of the messaging menu more like your clock.  It's a place for messages to go, and a place for you to find messaging applications.
<kees> tedg: can you pastebin this for me: find ~/.config/indicators/messages/applications-blacklist | xargs grep -H .
<tedg> persia: Yes.
<tedg> persia: Do you have anything in /usr/share/indicators/messages/applications ?
<persia> tedg: Thanks.  I'll reconfirm with a fresh lucid install, and file a bug from there.
<kees> tedg: but how do I configure (GUI) what I want for messaging?  not everyone uses evolution and pidgin
<cjwatson> Riddell: I've committed what should be a fix for this
<kees> tedg: for example, rhythmbox doesn't show up there until I run it.
<tedg> kees: I don't get anything from that command...
<Riddell> cjwatson: I owe you beer
<kees> tedg: then I don't understand how you're blacklisting.  can you walk me through it?
<tedg> kees: $ cp /usr/share/indicators/messages/applications/empathy /home/ted/.config/indicators/messages/applications-blacklist/
<kees> cp: cannot stat `/usr/share/indicators/messages/applications/empathy': No such file or directory
<tedg> kees: Okay, replace with pidgin or what ever you want to blacklist
<kees> cp /usr/share/indicators/messages/applications/* ~/.config/indicators/messages/applications-blacklist/
<persia> tedg: "ls: cannot access /usr/share/indicators/mes*: No such file or directory" (indicator-messages is installed)
<cjwatson> Riddell: wait until it provably works :) I only tested it out of context ...
<kees> tedg: after the above cp, I still have the icon
<tedg> persia: Hmm, ls ~/.config/indicators/messages/applications ?
<tedg> kees: Is it in the menu?
<tedg> kees: Are there entries in the menu?
<kees> tedg: yes.
<cjwatson> Riddell: would have been a hell of a lot less work if we were using python 2.7 :-/
<kees> $ ls ~/.config/indicators/messages/applications-blacklist
<kees> evolution  pidgin
<kees> and I still have the envelope icon and when clicking the icon, it has pidgin and evolution stuff listed
<persia> tedg: ls: cannot access .config/indicators/mess*: No such file or directory
<kees> persia: I had to create the directory
<persia> kees: Right, which makes the contents of the directory unlikely to affect the issue :)
<tedg> kees: Hmm, Oh, I guess it couldn't create a watch because the dir didn't exist.  You'll have to restart your session.
<kees> _session_!?
<tedg> kees: Or killall indicator-messages-service indicator-applet
<kees> I've restarted the applet a few times, but yeah, I'll try messages-service instead
<kees> tedg: still there.
<tedg> persia: I have no idea where your entries are coming from then.  That's very odd.  There's no hardcoded entries.
<tedg> kees: Entries in the menus?
<persia> tedg: OK.  Do you need a clean install for me to file a bug, or shall I just file from my workstation?
<kees> tedg: oddly, evolution is gone, but pidgin remains.
<tedg> persia: If you could start indicator-messages-service on the console and give the output that'd be best.
<tedg> persia: It's very chatty
<tedg> kees: Heh, Pidgins, can't get rid of them.
<kees> :P
<tedg> kees: Do you have any entries in ~/.config/indicators/messages/applications ?
<persia> tedg: I get a coredump :)
<Riddell> cjwatson: I'll give it a test on the CDs tomorrow, many thanks for looking into it
<kees> tedg: nope
<tedg> persia: After you killed the running one?
<persia> tedg: do I need to start it in a special way, or shall I just send an apport report with the coredump?
<tedg> persia: So special way, but it might not handle not getting it's name gracefully (which should be a bug also)
<tedg> kees: Hmm, interesting.  Are you sure Pidgin isn't running?
<kees> $ pidof pidgin | wc -l
<kees> 0
<kees> other notes: symlink doesn't work.
<tedg> kees: I guess file a bug, I'm unsure why that'd be.
<kees> tedg: also, watches don't seem to work.
<tedg> Okay guys, I need to run to make dinner.
<kees> tedg: thanks!
<tedg> Please file bugs, it should go away too :)
<cjwatson> Riddell: guess I'd better upload then :)
<persia> kees: You're filing the bug?
<kees> persia: yup
<kees> persia: 3 actually
<persia> kees: Excellent, then I'll refrain.
<kees> persia: bug 533021 if you want to confirm/subscribe
<ubottu> Launchpad bug 533021 in indicator-messages "cannot blacklist all messages indicators" [Undecided,New] https://launchpad.net/bugs/533021
<kees> and bug 533023
<ubottu> Launchpad bug 533023 in indicator-messages "blacklist watch does not notice removed files" [Undecided,New] https://launchpad.net/bugs/533023
<persia> purging indicator-messages also seems to work, but that seems a less ideal solution (as I *do* want it to suddenly magically pop up if I happen to use a supported client)
#ubuntu-devel 2010-03-06
<cjohnston> Can someone please take a look at bug 532633 and confirm that this is now the intended look?
<ubottu> Launchpad bug 532633 in light-themes "[light-theme] please centre window title and order window controls" [Undecided,Confirmed] https://launchpad.net/bugs/532633
<bhundven> a quick question about version in changelog. why would package-1.0.0+20100101-1ubuntu1 be newer then package-1.0.1+20100305-1. Is it because of the 1ubuntu1 part at the end?
<Caesar> bhundven: you can use dpkg --compare-versions to test
<Caesar> But the answer to your question is yes
<Caesar> slangasek: Upstart is hurting my brane
<slangasek> Caesar: oh?
<Caesar> So I tried to write an upstart job for autofs5
<Caesar> But it seems very unreliable
<Caesar> I can get start and stop to just hang
<Caesar> I can get upstart to think it's started the process when it's not running, and get all bitter and twisted when I try to stop it when it's already stopped
<Caesar> I've put my upstart job spec in #533029
<slangasek> you probably need a different option for 'expect'
<bhundven> ah. it wasn't the 1ubuntu1 at the end that was throwing me... it was the 1: before the version that I didn't see before.
<Caesar> I tried both
<slangasek> expect fork, expect daemon, expect the-unexpected, etc
<Caesar> Yeah, I've tried both fork and daemon
<Caesar> I'm currently getting the unexpected :-)
<slangasek> does automount have an option to run in the foreground?
<slangasek> you may have to do that
<Caesar> Yes, I can try that I guess
<slangasek> smbd similarly behaves in a way that upstart is unable to trace
<Caesar> That always strikes me as a crude hack
<Caesar> It makes me sad that start and stop can just totally hang though
<cjwatson> FWIW there is an outstanding upstart bug where you can get it permanently into a confused state by the wrong 'expect' value - if you've done that, you'll have to reboot before you can evaluate whether the other setting works
<Caesar> cjwatson: ok, I'll give it a reboot
<cjwatson> bug 406397
<ubottu> Launchpad bug 406397 in upstart "init: job stuck with expect fork/daemon when parent reaps child" [Low,Triaged] https://launchpad.net/bugs/406397
<Caesar> Lame-o, automount with -f also wants to log to stderr
<cjwatson> BTW you have 'if !modprobe ...' which is an error
<cjwatson> (missing space)
<Caesar> Gar
<Caesar> I do love the idea of Upstart
<Caesar> The jobs are very clean
<Caesar> I dislike the current inability to have a good handle on what the bootup process is like
<cjwatson> I've seen job graphs, although I'm not sure what produces them
<cjwatson> brushing that up might be an interesting way to tackle the problem
<Caesar> Yes
<cjwatson> I agree that you have to have a very, very clear idea of the state machine in your head
<Caesar> Booting with --verbose may help, provided it's logged somewhere
<cjwatson> mostly ends up in /var/log/syslog, with the possible exception of early stuff
<cjwatson> I think not absolutely everything is logged, but it's usually enough for the sort of things users would be writing
<Caesar> I imagine if the PID of the process doesn't match what Upstart's status says it is, I'm in for a world of pain?
<cjwatson> yeah, it's probably lost track per the bug above and you're toast
<Caesar> Okay, I'll try the other value of expect after a reboot
<cjwatson> bit me with ssh a while back
<Caesar> Did you run it in the foreground to get around it?
<cjwatson> no
<cjwatson> I used 'expect fork' rather than 'expect daemon', since the main process only forks once
<Caesar> That's what I'm trying now post reboot
<Caesar> \o/
<Caesar> I've at least got reality and Upstart to agree
<Caesar> Yep, that's a winner
<Caesar> Now if only switching to an upstart job had actually solved the problem I was trying to solve...
<Caesar> cjwatson: so OpenSSH isn't using Upstart in Lucid?
<cjwatson> OpenSSH is using Upstart in Lucid
<Caesar> Hmm
<cjwatson> $ status ssh
<cjwatson> ssh start/running, process 999
<Caesar> Bah, I'm an idiot, don't mind me
<cjwatson> you noticed that the init script was still there?
<Caesar> We're not using Ubuntu's OpenSSH (duh)
<cjwatson> ah :)
<Caesar> I'm currently trying to figure out why syslog-ng isn't starting
<cjwatson> well, you should be able to now ;-)
<Caesar> No syslog, no logs, makes debugging very hard
<Caesar> syslog-ng is using old-style init scripts though
<cjwatson> I thought you guys were using rsyslog
<Caesar> Not at the current time
<Caesar> We've always used syslog-ng
<Caesar> I've yet to investigate the feasibility of switching to rsyslog
<Caesar> But the fact that syslog-ng isn't even starting for me is helping expedite that
<Caesar> Ooh, I wonder if it's also network related
<Caesar> It may be throwing up its hands because it can't resolve the remote host it's being told to log to
 * Caesar gets to write another upstart job
<RoAkSoAx> cjwatson, what are -p, -i, or -a in dh_apport?
<cjwatson> RoAkSoAx: same as in any other debhelper command, I guess?
<slangasek> RoAkSoAx: debhelper(7)
<cjwatson> select the set of packages to operate on in various ways
<RoAkSoAx> ok thanks
<RoAkSoAx> and where hsould it be placed? dh_install?
<RoAkSoAx> i mean
<RoAkSoAx> install rule
<RoAkSoAx> or when overriding a dh_install for example?
<cjwatson> normally binary-{arch,indep}
<cjwatson> if you're using dh(1), you don't need to do anything
<cjwatson> well, you do
<cjwatson> but you just need to do 'dh --with apport $@'
<cjwatson> see openssh for an example of doing it manually
<RoAkSoAx> cjwatson, awesome thanks!!
<cjwatson> and you can run (e.g.) 'dh --with apport --no-act binary' in a package's working tree to get the canonical command sequence, though not broken up by debian/rules target.  though in most cases you don't want to call all of them and the ordering between dh_installdocs down to dh_link (or thereabouts) usually doesn't matter much
<RoAkSoAx> ok :)
 * Keybuk wonders how long he should let update-manager calculate the upgrade to lucid before killing it
<LaserJock> perhaps it's gotten a little debianified, "you'll get your new release when it's ready"
 * Caesar <3 how easy it easy to write upstart jobs
<Caesar> (once you know the event names)
<Keybuk> ooh, finally, update-manager is on its awy
<jdong> pitti: did I ever tell you how much I love you? [thanks for vmmouse lucid magic!] :)
<jdong> and *giggles* plymouth just gave me the fedora-esque blue stripes racing across the screen bootsplash... confused me for a moment as to which VM I started.
<Caesar> Are there any plans to make Plymouth do something useful with nvidia graphics for 10.04?
<alabd> good day all
<alabd> for pkg in *deb ; do <what should be here?> "$pkg" && mv "$pkg" Karmic || mv "$pkg" Jaunty ; done
<alabd> <what should be here?> =  a command that returns 0 for juanty 1 for others .....such thing ?
<alabd> do you know such command ?
<mtx_init> are there any hellanzb devs in here?
<geser> slangasek: Could you please tag the new ubuntu-dev-tools upload in bzr. Thanks
<slangasek> geser: hmm, yes - pushed now
<slangasek> (well, pushing)
<dehqan> there is a folder containing jaunty and karmic packages how to separate the jaunty packages from the karmic packages?
<lifeless> dehqan: you can look at the changelog in the package, though its not guaranteedd for packages that haven't been uploaded again
<lifeless> dehqan: generally speaking you need the Packages file to sort that out
<dehqan> ok they are in /var/cahce/apt/archives
<dehqan> how to sort that out ?
<lifeless> This is a channel for development of ubuntu itself. We direct people to #ubuntu for support questions
<dehqan> you should asked it there some time but no proper answer
<dehqan> lifeless: ^
<dehqan> anyway thanks
<tjaalton> so the music store should be availble in finland? rb just says "coming soon"
<emgent> Riddell, ping.
<lifeless> cjwatson: ping; wondering if you know anything about the mini.img in the ubuntu-installer dir of a.u.c : it doesn't seem to have the ath9k driver in it.
<dehqan>  there is a folder containing jaunty and karmic packages how to separate the jaunty packages from the karmic packages? packges in .deb format in /var/cache/apt/archives
<sebner> Please tell me that there is a gconf value for the changing the windows controls back (from the left to the right) or /me waves goodbye
<elleuca> could someone test if patch to bug #436887 is fine?
<ubottu> Launchpad bug 436887 in indicator-session "Log out, shutdown and reboot confirmation alerts don't follow GNOME HIG" [Low,Triaged] https://launchpad.net/bugs/436887
<persia> sebner: There is.
 * sebner hugs persia and calls him a god
<persia> sebner: By the tenets of the religion I impose on my believers, it is blasphemy to imply that I have deistic properties.
<sebner> hahaha
<sebner> persia: now, would you mind telling me how to fix this "ohmy!" thing?
<persia> grep the logs for the past 48 hours for gconf.  Flip that setting.
<persia> (this channel)
 * sebner greps
<sebner> persia: I flipped the colon but it's still not working (did a X-restart)
<persia> sebner: You have as much information as I then.
<sebner> persia: heh, at least I hope whoever did this upload, did this change by accident. If not ....
<Ng> there are many blog posts about how to move the window controls back to the right, check Planet Ubuntu
<persia> sebner: I believe there exists a bug about it.  you can also select a different theme.
<sebner> persia: Well, I'm not using standard-theme anyways
<sebner> Ng: grr, I already did the change proposed but it magically happens *not*
 * sebner kicks his XServer once again
<sebner> Woo, it's now on the right side but I want maximize in the middle which is not working xD
<sebner> interesting, restarting Xserver a hundred times and doing the change over and over again in gconf (resets somehow) fixed it for me xD
<fmarl> elleuca, your patch doesn't apply cleanly against indicator-session package in lucid?
<mdeslaur> ccheney: I've backported GtkStatusIcon support to lucid's pidgin to fix the tray icon transparency. If you could try it, out of my "testing" PPA, that would be great.
<mdeslaur> After a couple of people test it, I'll see if anyone minds if I upload it.
<mdeslaur> Same with liferea
<elleuca> fmarl, dunno, I simply wrote it, but currently I've not time to test is; it seems fine to me...
<Riddell> cjwatson: live CDs not booting today, at least on virtualbox, so can't test installer
<cjwatson> odd, I'll take a look at some point
<dehqan> we have list of packages with their version how to know if one package is from jaunty repo or karmic repo , for example a package with version of 1:1.10.2-2ubuntu7
<crimsun> apt-cache policy foo
<crimsun> (foo is the binary package name)
<crimsun> if you want to poll LP directly, use rmadison
<dehqan> crimsun: no package name package address like /ddf/dfdf/ds.deb
<geser> try the package name not the filename
<geser> so you have only the filename and not the package name?
<dehqan> geser:  yes
<dehqan> a folder with packages
<geser> dpkg-deb -I filename.deb | grep Package
<geser> perhaps some sed too to get the package name of a file
<geser> and if a package didn't change between jaunty and karmic, the same version can be in both
<dehqan> geser:  no dpkg-deb -I
<dehqan> dpkg-deb: unknown option -l
<geser> -I (big i)
<crimsun> (use a better font! ;-)
 * jdong prepares to break his machine with the help of btrfs... again...
<dehqan> geser:  no ubuntu version in info
<dehqan> geser:  ok now we have package name and apt-cache policy gives         500 http://archive.ubuntu.com jaunty/main Packages
<dehqan>  that's nice now imagine a folder with a packages how to seprate jaunty packages from them ?
<ikonia> dehqan: this is not a support channel
<ccheney> mdeslaur: it worked
<cjwatson> dehqan: there is in general *no way*.  as you've been told, it's perfectly possible for the same package to be in both jaunty and karmic.  you are supposed to track this separately, not by examining the .deb files.
<cjwatson> dehqan: the .changes file has a Distribution file that says where the package was originally uploaded.  (if you've thrown that file away, well ...)
<cjwatson> *Distribution field
<T`> anyone here know much about upstart?
<T`> start on interface-up br0  <-- wondering if this is supposed to work
<slangasek> T`: not with that syntax, no
<slangasek> T`: 'start on net-device-up IFACE=br0' would be the right syntax
<bluefoxicy> rhythmbox "add to musicbrainz" opens a web browser with a web page that's unhelpful
<bluefoxicy> it doesn't even open it to a filled-in form with all the information Rhythmbox has (it has all the track titles for the CD)
<slangasek> geser: hmm, so, clarification: debcommit uses the same implementation of the changelog bug parser as dpkg-dev when generating the --fixes args to bzr, so I guess you just weren't using debcommit?
<slangasek> geser: (bzr itself doesn't attempt to parse changelogs, dunno what I was thinking when I said that)
<dehqan> cjwatson: where is .changes file ?
<cjwatson> dehqan: it's generated alongside the .deb files when building packages in the normal way
<dehqan> how to read it ? cjwatson
<cjwatson> slangasek: there's a plugin somewhere that makes bzr ci pick it up from the changelog I think ...
<slangasek> cjwatson: oh?  even when not using debcommit?
<cjwatson> dehqan: please use your initiative and look at the file; if you'd looked at it, you wouldn't need to ask
<cjwatson> slangasek: I believe so.  not in a place where I can check just now
<dehqan> cjwatson: thanks
<geser> slangasek: I used "bzr ci --fixes lp:xxx". Is that wrong?
<less1> Hi, I am looking for someone who is working on ubuntu boot process to fire few question, may I know where I can find them?
<slangasek> geser: huh, that's right... so ... ignore me, I guess
<slangasek> geser: apparently I don't know what I'm talking about :)
<geser> slangasek: I see only that this makes LP add a link to the branch with the commit (here ubuntu-dev-tools trunk) but doesn't update the bug status or add a comment. I usually add a comment with the revision, so it later easily to spot which rev contains the fix (e.g. for backporting for a SRU).
<slangasek> geser: ack
<geser> slangasek: you don't have by chance some time to review and sponsor bug #509900?
<ubottu> Launchpad bug 509900 in vim "Merge vim 2:7.2.330-1 from Debian unstable" [Wishlist,New] https://launchpad.net/bugs/509900
<sistpoty> lamont: if you have some spare time, fpc needs bootstrapping on armel and powerpc
<sistpoty> (not too high priority though)
<slangasek> geser: new upstream version, no FFe needed?  Could you document why in the bug?
<slangasek> geser: also, I don't suppose you'd want to do that as a bzr branch I can just pull into lp:ubuntu/vim?
<slangasek> (i.e., merge lp:debian/vim, push somewhere, etc)
<cjwatson> merging lp:debian/vim ran into hideous bzr problems
<cjwatson> been there done that :(
<slangasek> cjwatson: drat
<geser> slangasek: do the additional (upstream) patches count as a new upstream version? it's still version 7.2 but with the collected patches till patch 330
<geser> and I tried to get it reviewed before FFe but cjwatson told me that there is no hurry as it won't need a FFe
<geser> but I can add the missing bits if needed
<sistpoty> asac: mind sharing some wisdom for FFe bug #482890?
<ubottu> Launchpad bug 482890 in mozilla-noscript "Please sync mozilla-noscript 1.9.9.27-1 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/482890
<cjwatson> I don't remember saying that in particular, though it's possible that I did
<cjwatson> I may have said that I didn't think it would be a major problem, or something
<geser> you might be right, don't remember your exact wording
<sistpoty> hm, anyone got a clue why this is a FTBFS (build log says it built fine!): http://launchpadlibrarian.net/40376516/buildlog_ubuntu-lucid-amd64.mksh_39.3-1ubuntu1_FAILEDTOBUILD.txt.gz
<slangasek> sistpoty: the problem is detailed at the bottom of the log file...
<sistpoty> slangasek: you mean the conftest pointer conversion?
<slangasek> yes
<wgrant> I thought that was now meant to be non-fatal except on ia64.
 * wgrant checks.
<slangasek> wgrant: eh?  amd64 has the same issue, and it certainly shouldn't be given a pass there
<slangasek> (now in this case it's a false positive since the error comes from a check for the *existence* of this function)
<wgrant> Ah, right, it's only definitely going to break on ia64, but might still break on amd64.
<slangasek> it's always a bug on both ia64 and amd64, it just won't always strike on amd64
<slangasek> which, if anything, makes it harder to track down after the fact
<wgrant> Right.
<sistpoty> so how can I work around the broken buildds?
<slangasek> sistpoty: the test case that's throwing this error should be rewritten to include its own strcasestr prototype
<sistpoty> slangasek: ok, thanks for the hint
<slangasek> (or upstream could use autoconf, which doesn't have this problem...)
<crypt-0> does kcryptd support SMP?
<slangasek> geser: vim> well, it's packaged with a new upstream version number; I'm not familiar with the versioning on this package, but the main point is whether it includes new features or not
<jdong> in non-KMS-mode, is the fedora-like plymouth bootsplash intended?
<cjwatson> jdong: not according to bug 526892
<ubottu> Launchpad bug 526892 in plymouth "No graphical splash on VGA16fb, plymouth uses fallback blue ASCII progress bar" [Medium,In progress] https://launchpad.net/bugs/526892
<jdong> cjwatson: ah, thank you. Kind of feels like booting Fedora for a moment until *boom* purple :)
#ubuntu-devel 2010-03-07
<sistpoty> crack, finally finding the details, the mksh build failuer is actually caused by a false positive (gcc) of a non-reproducible false-positive (LP buildd). :(
<RoAkSoAx> hey guys I was wondering if i can create a temp file in an apport hook and then attach it to the report with attach_file?
<RoAkSoAx> or we should not be creating temp files in apport hooks
<hdon> hmm, i think 2.6.31-20 broke my nic
<RoAkSoAx> cjwatson, do apport hooks have to be under both binary-{arch,indep}
<micahg> kees: ping re firefox
<RoAkSoAx> is apport already running hooks via attach_related_packages?
<lamont> sistpoty: does this mean it will actually bootstrap this time?  because it didn't the last time I was told it would... (fpc)
<m4t> i'm trying to do a make-kpkg build of 2.6.33, and at the end it fails with: The UTS Release version in include/linux/version.h "" does not match current version: 2.6.33
<ion> Iâm reading the topic.
<m4t> works fine if i change $fh->sysread to $fh->read
<m4t> even with the eof
<kees> micahg: hi! sup?
<m4t> oh, it was moved to generated/utsrelease.h?
<m4t> from 2.6.33 changelog:     kbuild: move utsrelease.h to include/generated
<persia> m4t: You may find that the folks in #ubuntu-kernel are more likely to have individual knowledge about this sort of thing (although some folk here do as well)
<m4t> persia , i found a existing bug on debian, http://osdir.com/ml/debian-bugs-dist/2010-02/msg09866.html
<persia> m4t: That works too :)
<m4t> http://launchpadlibrarian.net/37497839/kernel-package-2.6.33.patch
<persia> although the syntax "Debian bug #571716" tends to be more informative with our channel bots.
<ubottu> Debian bug 571716 in kernel-package "/usr/bin/make-kpkg: make-kpkg fails building .deb for linux 2.6.33" [Important,Open] http://bugs.debian.org/571716
<m4t> ah cool
<m4t> i mostly idle ;/
<persia> For ports architectures, we use the ports.ubuntu.com mirror, even for arch:all packages.  Is there a way to construct a sources.list file that would pull arch:all packages from a local mirror, and arch:any packages from ports.ubuntu.com ?
<m4t> make-kpkg patch per launchpad seems to fix issue.
<micahg> kees: do you have the daily prism build installed?
<kees> micahg: since I don't know what that is, no. :)
<micahg> kees: when I removed prism, I was able to start your profile again
<persia> lamont: How didn't fpc bootstrap?  It really worked for me.
<kees> $ apt-cache policy prism
<kees> prism:
<kees>   Installed: (none)
<kees>   Candidate: 1.0~b2+svn20090813r49078-0ubuntu2
<kees> micahg: were you able to start it twice in a row?
<micahg> ugh, no, not after reinstalling greasemonkey, sorry
<micahg> but prism seems to exhibit the same issue
<persia> lamont: On an unrelated note, do you happen to know when the ia64 and hppa ports were first introduced on ports.ubuntu.com?
<lamont> ia64: warty
<lamont> or maybe hoary
<lamont> though ISTR it was live for warty - thanks to some incredible effort by Thibaut
<persia> I put warty in the code I used, so I think I'll leave it there in case you remember correctly (not that I expect anyone is actually planning an upgrade from a warty install any time soon)
<lamont> hppa/sparc showed up in hoary, but didn't get into the DC until we got hardware in - ISTR hppa was there for breezy/dapper (or not in dapper - don't recall when LP started building everything), and then back in feisty IIRC
<persia> Was sparc on p.u.c for hoary?  I know it was on archive by dapper.
<lamont> amusingly, I just nuked the hoary archive of hppa off of people.u.c within the last 9 months or so - finally noticed it was chewing up space
<persia> heh
<lamont> we bootstrapped both architectures together, using hoary
<lamont> but not sure when sparc actually landed in the archive - hppa was way late landing for hoary, so it came in with breezy
<lamont> and even that was broken when we shifted to LP
<lamont> and on that note, I think it's time for me to sleep
<persia> Right.  Seems like I do have to adjust the code after all.  Do you know if there exists an authoritative resource, or is it all just left in human memory now?
<persia> lamont: tell me about your fpc issue first :)
<lamont> old-releases.ubuntu.com comes to mind...
<lamont> persia: with the best understanding of which packages to grab from sid, it was FTBFS - I wasn't actually the one flying that, so not sure what the actual error was.
<persia> Doesn't differentiate ports vs. archive, but I'll take a look there.  Thanks.
<lamont> a clearer "install the following packages from sid and it _WILL_ build from source" would be wonderful
<persia> I'll retry, and go chase Ng then.  Do you have a preferred format, or would another entry like "Installing fp-compiler, fp-units-base, fp-utils, and fp-units-rtl from Debian sid on a lucid machine permitted this build" work.
<lamont> I have dapper/sparc and {warty-dapper}/powerpc as non-ports, ia64 and hppa as ports regardless of release
<lamont> bonus points if you include version numbers
<persia> I'll do that.  Thanks.  Have a good night.
<lamont> see also bzr brnach lp:~lamont/launchpad-buildd/chroot-scripts
<persia> I also have edgy powerpc as non-port, and edgy/feisty/gutsy sparc.
<persia> Oh excellent!
<lamont> ah, well... to be fair, that script kinda went lalalalala DO NOT CARE when it comes to edgy-gutsy
<lamont> corrections welcome
<lamont> persia: and yeah, Ng was pilot testing my instructions for doing the bootstrap, so he would be the right one to push on
<persia> Assuming it makes sense to me, I'll send a patch.  I'm hoping to have both python-apt and mk-sbuild be correct.
<persia> And I'll probably want to try to encourage you to use mk-sbuild for future chroot scripts :)
<lamont> that code is how I build lp and non-lp chroots, fwiw
<persia> (assuming I can bring it to feature parity)
<lamont> pretty sure you don't want to grow all the limbs that scriptage has
<lamont> no sane coder would
<lamont> but yeah, I'd definitely be interested
<persia> But I do want to have a tool in-archive that lets developers mimic the buildd chroots for local builds, so ... :)
<lamont> that's part of why I published the branch...
<lamont> didn't feel up to packaging it though
<persia> Oh my!  That is a lot of limbs.
<lamont> yes, it very certainly is
<lamont> the debian and xdebian swtiches are probably the most bizarre
<wgrant> persia: Why not grab the real buildd chroots for local builds?
<lamont> wgrant: sometimes it's quicker to just build new ones based on a local mirror
<persia> wgrant: I don't know how.  Is there a stable way to pull them from an API and shove them somewhere for sbuild to eat?
 * lamont sleeps
<wgrant> persia: Retrieving them from LP was convoluted until a week ago, when I exported the URL on the API. The URL to the current tarball is now available at https://launchpad.net/api/devel/ubuntu/lucid/i386/chroot_url
<persia> wgrant: I get an error loading that page.
<persia> error on line 1 at column 1: Document is empty
<wgrant> persia: Yeah, LP for some reason serves it as XHTML when it's actually plain text.
<wgrant> View the source.
<wgrant> Although I guess that tarball will have internal hosts in sources.list, and stock sbuild won't override them, so it's not that easy.
<persia> Oh excellent.  So I should be able to construct a script that discovers the current URL, pulls it, unpacks/repacks/renames as needed for the local build tool, etc. ?
<wgrant> Yep.
<wgrant> Previously you had to dig through build logs and use an undocumented librarian search feature to get the real tarball.
<persia> That's fine.  It oughtn't be hard to use some sane defaults.  I only wish pbuilder-dist and mk-sbuild were written in the same language: it makes it easier for them to share code.
<wgrant> And I've had to do that a few times in the past, so I thought I'd make it easy.
<persia> Thanks!
<persia> I know we've had lots of issues in the past with stuff building fine locally and not in LP, and being able to do local tests to hunt down why helps.
<persia> Mind you, we do have to make in-distro schroot/sbuild have the necessary features for them to be useful/used on the buildds, but that's presumably less painful.
<wgrant> And a while away.
<persia> Why?  It's too late for lucid, but is there a structural reason for the delay, or is LTS+1 sensible?
<wgrant> It's Soyuz/buildd stuff. It will take forever.
<persia> Ah.  I like to assume that's a factor of the number of available developers, rather than an axiom, but I'll take your word for it, as you're surely more informed.
<wgrant> It is indeed a function of the number of available developers, but that is itself near to an axiom.
<persia> 0^n == 0 kinda thing?
<wgrant> Something like that.
<Keybuk> less1: feel free to fire any questions at me, I'll answer when I'm by the computer
<dehqan>  /var files permission , all have been 644 with my bad , is there anyway to restore permissions to default ?
<dehqan> any opinion ?
<jdong> is it intended that the empathy client be separate from the presence menubar [in lucid]?
<jdong> I set up a chat client (jabber/gtalk) using the presence menu and afterwards it seems to have signed me into google talk
<jdong> but it was not immediately obvious that for me to start a chat, I had to start Empathy separately to get my buddy list
<ion> The panel item that looks like a snailmail letter provides a menu item for the Empathy main window.
<jdong> ah, you're right.
<jdong> but that seems a little bit unintuitive
<jdong> the menu that I set my presence status seems like where I should be able to do other chat-related things
<jdong> especially since AIUI the little textbox is for tweeting and such
<persia> jdong: You're probably seeing rough edges.  indicator-me *should* abstract the client entirely, so that an arbitrary (set of) client(s) can use it effectively.  There may be a need for a richer feedback mechanism to ensure that things work as expected.
<jdong> persia: *nods* ok, just want to make sure that is the case, and there's not some philosophical usability disparity
<persia> jdong: There *is* a philosophical usability disparity, which needs changes to the underlying code in order to bring into alignment :)
<persia> jdong: The difference being "We recommend this by default", and "This is how this is done".
<jdong> ah :)
<persia> jdong: So, if something doesn't work, please try to extend the flexibility inherent in the system so that it *does* work.  While this may have little apparent impact at the current time, it will significantly ease the adoption of new technologies as they become available.
<jdong> with that said, is it intended that Lucid is going to ship without further improvements to indicator-menu?
<jdong> and/or the presence menu
 * persia suspects it to be the same as any other package: fix it if it's broken, but hope it works so that it doesn't need to be fixed
<jdong> lovely
<jdong> I just am concerned that this is going to confuse novice users
<persia> Well fix it then.
<ScottK> Depends on your definition of fix.
 * ScottK suspects jdong's would collide with someone else's definition of feature removal.
<jdong> what I don't understand is what "fix" means for the people who actually care about this new presence stuff.
<persia> See, that's why I talked about the architecture.  If the DBus communication is extended, that doesn't affect user-perceived features, but it allows one to enable other use cases.
 * persia actively works to separate presence from use of any given device, so is perhaps not an authority on what "fix" means in that context
<less1> Keybuk: I am working on Internet booting for Ubuntu, and I want to find out if there is any work going on? and where and whom to contact for details and help for this work.  any pointers about this will be helpful.
<persia> cjwatson: I end up referencing your packagesets reference often, but don't mean to highlight you with every reference.  Is that something that could be moved to ~ubuntu-archive (or do you have scripts that ignore highlights in URIs)?
<cjwatson> persia: the fact that you highlight me serves as a periodic reminder to me to move it somewhere more sensible
<persia> cjwatson: OK :)
<geser> slangasek: re vim: I've updated the debdiff, added a comment why it IMHO doesn't need a FFe (and also a diffstat between the current version and the merged one). Let me know if I should add something else to improve the chances to get it sponsored.
<kitallis> Ubuntu not applying for GSoC'10?
<geser> cjwatson, slangasek: I gave a bzr merge of vim a try again and it worked this time (with bzr 2.1.0). A merge proposal is attached to the bug.
<Keybuk> less1: I don't know what "Internet booting" is?
<ogra_cmpc> Keybuk, boot through http ?
<Keybuk> IP over Facebook!
<ogra_cmpc> hehe
<Nafallo> IPv6 over Facebook actually...
<ogra_cmpc> wait until you have to maintain the ubuntuone initramfs hook for booting a shared image and make it boot in 10sec
<Keybuk> Nafallo: why not go for IPv6 over Myspace; then you have double the irrelevance to the real world :p
<Nafallo> Keybuk: lol. good one :-)
<sebner> Keybuk: better you tell me how to get this shiny new bootsplash :P
<ogra_cmpc> what for ... its gone before it can even be displayed ...
<ogra_cmpc> we boot way to fast now
<Keybuk> ogra_cmpc: ironically, that's one of the main bugs
<Keybuk> the "Enter kills X" thing is because Plymouth hasn't switched to VT7 yet
<Keybuk> because YOU BOOTED TOO DAMNED FAST
<ogra_cmpc> yeah
<ogra_cmpc> why dit we switch to plymouth again instead of just dropping usplash without replacement ?
<sebner> ogra_cmpc: shiny animations \o/
<ogra_cmpc> lol
<sebner> Keybuk: nah, really. I still have the blue progress bares (yeah 2 of them) :\
<Keybuk> ogra_cmpc: still needed something to deal with asking for passphrases, doing fsck progress, etc.
<ogra_cmpc> i agree they make sense for livecd boots
<Keybuk> sebner: stop using nvidia-glx? :P
<ogra_cmpc> Keybuk, ah, yes ... silly encryption stuff and fsck ...
<sebner> Keybuk: ahaha, right. Especially since the driver b0rkens the cards
<Nafallo> is my santa rosa based lenovo actually allowed me to use the full bus, maybe I could boot fast too :-/
<Nafallo> s/is/if/
<Keybuk> sebner: you're not using glx?
<sebner> Keybuk: As it doesn't seem to break my card, yes I'm still using it because as a MOTU I have the responsibility to perform deep checks on FFe packages (especially on games) *muahaha* :P
<Keybuk> sebner: tseliot is working on the fix for you
<Keybuk> which is to draw the splash in 16-color low-res vga mode
<sebner> Keybuk: hmm correct me if you want but do we have 2010 now or 1990? :P
<ogra_cmpc> ask your HW vendor :)
<Keybuk> sebner: correct me if you want but are you using a non-free driver which we don't have the source to, so can't do anything about? :p
<Keybuk> want decent graphics, kernel mode setting, etc.?  stop hating freedom <g>
<sebner> Keybuk: want proper 3D, stop loving freedom :P
 * Keybuk hides the face he's using nvidia-glx here
<Nafallo> heh. I remember when infinity hex hacked the ati driver to use the correct Xorg paths ;-)
<Nafallo> so clearly, we can do things with the closed source drivers :-P
<sebner> Keybuk: hahah! :P
<Keybuk> sebner: though I actually do intend to test nouveau/gallium stuff
<Keybuk> I just only dist-upgraded my desktop to lucid yesterday
<Keybuk> so haven't had a chance yet
<sebner> Keybuk: I'm using lucid since ever but I really love to play games to I need the blob. It's just crazy that the blob drivers have 3D and much more but are not capable of doing that plymouth stuff. Maybe it's the other way round. plymouth intentionally uses technologies these don't have :P
<ogra_cmpc> funny, every linux 3D game i ever tried worked fine on intel
<Keybuk> sebner: oh, I don't care about the blob
<Keybuk> the only reason I was using glx before is that nv didn't support the 7800
<Keybuk> nouveau apparently does
<Keybuk> enough basic 3D to run mutter or compiz is fine for me
<Keybuk> if I want to play games I use a non-free operating system on a different partition ;)
<sebner> Keybuk: nexuiz ftw! :P
<sebner> uuhhh
<sebner> Even worse :P
<Keybuk> actually
<Keybuk> mostly if I want to play games, I use the non-free operating system on the non-free hardware plugged into the TV downstairs :p
<ogra_cmpc> ++
<Keybuk> I'd hug my PS3 if it wasn't for the risk of burning
<sebner> Keybuk: at least you don't have a XBOX so it's fine :D
<Keybuk> no, I have some standards
<ogra_cmpc> hey, the first gen xbox was fully sponsored by MS
<sebner> heh
<Nafallo> Keybuk: probably a non-free TV as well? ;-)
<ScottK> Not if he's paid his license fees
<ScottK> Oops, just notice how long ago that was ...
<xnox> =)
<bigon> when patching debian native packages should I use a diff system?
<less1> Keybuk: its an attempt to boot ubuntu without having Ubuntu image on cd or usb, you boot ubuntu using the image over Internet using http.  Initial boot is done by gpxe
<Chipzz> less1: that actually has 0 to do with the /boot/ process
<Chipzz> or very little
<ogra_cmpc> i thought that exists since quite a wile anyway
<Chipzz> Keybuk is the maintainer of upstart, which is not what you want to work on
<less1> Chipzz: humm.. so may I know where can I get more links about it?
<Chipzz> less1: you need a way to get a root filesystem (which you may for example get over NFS), and make sure you don't write to i
<ogra_cmpc> there was someone regulary posting to ubunt-devel-discuss about the implementation ... it exists since a while ... hardy i think
<Chipzz> t
<less1> thanks, I will try and search in their archive
<lamalex> Is there a wiki page with a process of how to get a patch applied to a package?
<lamalex> I've filed a bug and attached the patch
<geser> there are several wiki pages that describe parts of the process
<geser> does the package in question use a patch system?
<lamalex> yeah, and I've used it to create the patch that I've posted on lp
<geser> so you are at the step to create a debdiff (https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff) or doing the same with bzr (https://wiki.ubuntu.com/DistributedDevelopment/Documentation/WorkingOnAPackage and https://wiki.ubuntu.com/DistributedDevelopment/Documentation/SeekingSponsorship)?
<lamalex> cool
<lamalex> thanks genii
<lamalex> er
<lamalex> geser
<cjwatson> bigon: no, don't use patch systems with native packages
<cjwatson> lamalex: contrary to popular belief, any sort of patch is fine, since any self-respecting person with upload privileges can mangle it into the right form trivially - anyone who makes you reformat it into a debdiff is bureaucratically wasting your time :)
<lamalex> I mean, a diff is a diff imo, I guess I'm mostly asking "how do I get my patch noticed/sponsored"
<cjwatson> http://wiki.ubuntu.com/SponsorshipProcess and wait :-/
<cjwatson> (obviously if you're seeking upload privileges yourself then you need to be able to put the patch in exactly the right form)
<lamalex> yeah, I'm not at this time although I may try to get motu later
<lamalex> proposed for merging, thanks cjohnston
<lamalex> erg, cjwatson
<crimsun> lamalex: which source package?
<lamalex> crimsun, gnome-control-center
<lamalex> lp 533888
<ubottu> Launchpad bug 533888 in gnome-control-center "default applications capplet doesn't recognize banshee" [Undecided,New] https://launchpad.net/bugs/533888
<Sarvatt> Keybuk: you might be a little disappointed because nouveau in lucid is not going to have any 3D acceleration support with the archive packages. lucid+1 will though and I already have it working in xorg-edgers
<Sarvatt> but its in flux since we're changing how nouveau is brought into lucid yet again and blacklisting nouveau so lbm-nouveau continues working will be needed once the -16 kernel hits
<Sarvatt> (for xorg-edgers nouveau 3D support that is)
<crimsun> lamalex: merged, thanks for your contribution
<lamalex> crimsun, thanks for yours :)
<crimsun> unimatrix: apologies for the delay; applied and uploaded. Thanks for your contribution!
<lamalex> Will gstreamer be updated to the new upstream release that was pushed out a day or two ago? we've got a prerelease version currently so I assume yes, but is there any way to get confirmation?
<TheMuso> lamalex: I suspect so, but you'd best ask the desktop package maintainers, who are not around at the moment.
<TheMuso> lamalex: They are in Europe for the most par.
<TheMuso> part
<lamalex> there seems to be a bug in the current packages which breaks dvd playback, so I'm hoping the new release fixes it
<lamalex> TheMuso, thanks for the info though
<TheMuso> lamalex: np
<andreasn> anyone happens to have the template for mpt's "dotted paper"?
<jibel> cjwatson, hey, did you talked with guillem about the fsync patch for bug 512096 ?
<ubottu> Launchpad bug 512096 in dpkg "[MASTER] Exec format error : package failed to install/remove : installation/removal script returned error exit status 2" [High,In progress] https://launchpad.net/bugs/512096
<jibel> cjwatson, there was an important performance loss.
<cjwatson> jibel: no, please point me to the thread
#ubuntu-devel 2011-02-28
<RAOF> @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:
<Laibsch> I've been trying to recompile thunderbird source in a pbuilder environment and ran into a strange error: http://paste.debian.net/109094/ What is this execvp permission error?
<c2tarun> Laibsch: can you paste the ouput of ls -al
<c2tarun> Laibsch: pastebin the output of ls -al debian/migrator/
<Laibsch> c2tarun: from the source directory or from inside the pbuilder?  source dir: http://paste.debian.net/109095/
<c2tarun> Laibsch: actually I want to see ls -al  from inside of debian/migrator
<Laibsch> http://paste.debian.net/109096/
<Laibsch> there you go
<Laibsch> not sure if that is different when pbuilder runs
 * Laibsch points to line 61 in http://paste.debian.net/109094/
<Laibsch> maybe a path problem with some obscure cc file lying around somewhere?
<micahg> Laibsch: are you sure your pbuilder is set up correctly?  although, I can't say I've used pbuilder to test this on lucid, but I believe it works for natty
<c2tarun> Laibsch: sorry I got disconnected, you still there?
<Laibsch> sure, I'm still here
<Laibsch> micahg: that's always a hard question to answer.  If I were aware of any defects, I'd fix them (or at the very least point them out) ;-)
<Laibsch> micahg: if you can be more specific, I can have a look
<micahg> Laibsch: well, have you tried recreating it from scratch
<Laibsch> OK, I'll do that now
<micahg> Laibsch: also, which "release" are you trying this in pbuilder for?
<Laibsch> lucid host and lucid pbuilder.
<micahg> Laibsch: also, you could try logging in and seeing what's actually fails
<c2tarun> micahg: can you please help me with this error http://paste.ubuntu.com/573321/ I know how to fix this error, but I dont know where to link the libraries to fix the error.
<Laibsch> I'm going to recreate the pbuilder first and see if that works, then.  I know how to log in to a pbuilder to update the system, etc. But I've never logged in to pbuilder with source unpacked.  How does one do that?
<micahg> c2tarun: no, sorry
<micahg> Laibsch: set it to not clean the environment and login fter the failure
<pitti> Good morning
<c2tarun> can anyone please help me with this error http://paste.ubuntu.com/573321/ I know how to fix this error, but I dont know where to link the libraries to fix the error.
<pitti> c2tarun: you have to add -lkio to barcode_LDADD (or similar) in the Makefile.am
<c2tarun> pitti: are you sure about Makefile.am?
<pitti> c2tarun: if it's using automake; I don't know at all about cmake, qmake, etc.
<pitti> but they certainly must have an equivalent of that
<c2tarun> pitti: here is Makefile.am http://paste.ubuntu.com/573348/
<pitti> c2tarun: kbarcode/Makefile.am, not the one in the root dir
<c2tarun> pitti: it worked thanks :)
<c2tarun> pitti: but how did you know which file to change?
<pitti> c2tarun: linked libs are always specified in Makefile.am with automake
<c2tarun> pitti: hmm.....
<pitti> unless they come from pkg-config, of course
<dholbach> good morning
<c2tarun> pitti: should I use a patch for this change? and can i use the variable LIBS ?
<pitti> but even with pkg-config you need to add them there, just not directly with -lname, but with something like $(KIO_LIBS)
<pitti> c2tarun: you should send that upstream and have it fixed there as well
<pitti> and patch it in the meantime, yes
<c2tarun> dholbach: good evening :)
<pitti> c2tarun: the variable shouldn't be called "LIBS", it sohuld be kbarcode_LDADD
<c2tarun> pitti: thanks :)
<c2tarun> pitti: kbarcode_LDADD or KIO_LIBS
<dholbach> hi c2tarun
<pitti> ah
<pitti> c2tarun: those are two differnet things; I just made up KIO_LIBS, I don't know whether it's defined (that's done in configure.ac)
<c2tarun> pitti: ok, so finally what should I use? kbarcode_LDADD?
<pitti> c2tarun: usually configure.ac slurps in various pkg-config queries to get the required libraries for a particular module like kio, and then you write something like kbarcode_LDADD = $(KIO_LIBS) $(QT_LIBS) ...
<pitti> but if you don't have these, then specify them directly with kbarcode_LDADD = -lkio -lqt ...
<didrocks> good morning
<brendand> hi
<brendand> i need to find the url for the rsync server for old-releases
<brendand> particularly i want to rsync this image : http://old-releases.ubuntu.com/releases/10.04.1/ubuntu-10.04.1-alternate-i386.iso
<StevenK> brendand: Why not 10.04.2?
<brendand> StevenK - It's for debugging purposes
<c2tarun> pitti: ping
<pitti> still here..
<c2tarun> pitti: I made that changed and it build succesfully, but dont know why my debdiff is extremely large. How can i show it to you?
<Laibsch> c2tarun: try piping it through lsdiff first
<Laibsch> you will likely see some changed files that maybe you did not intend to change?
<c2tarun> Laibsch: what is lsdiff?
<Laibsch> a program
<pitti> c2tarun: presumably it caused an autoreconf run
<pitti> c2tarun: if you want to minimize it, apply the same change to Makefile.in in your patch
<Laibsch> c2tarun: debdiff $dsc1 $dsc2 | lsdiff
<pitti> this will avoid calling automake
<Laibsch> c2tarun: just try it
<StevenK> brendand: Poking around with rsync got me rsync://old-releases.ubuntu.com/old-releases/releases/10.04.1/
<pitti> Laibsch, c2tarun: lsdiff doesn't show the actual changes any more
<Laibsch> which is a good thing
<Laibsch> IMHO
<StevenK> brendand: The way I found it was 'rsync rsync://old-releases.ubuntu.com/' which gave me a listing
<Laibsch> I only want to know which files a patch touches
<janimo> @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: janimo
<al-maisan> One of my machines seems afflicted with bug #723482; when I try SysRq-i as described in comment #24 I only get to the SysRq HELP string ..
<ubottu> Launchpad bug 723482 in mountall (Ubuntu) "system hangs on boot after updates from 2011-02-22" [High,New] https://launchpad.net/bugs/723482
<c2tarun> pitti: the biggest entry in debdiff starts with this header http://paste.ubuntu.com/573361/
<brendand> SteveK Ah. It's not rsync://rsync. like the other ones
<StevenK> brendand: No, but host could have told you that. :-)
<Laibsch> al-maisan: try #ubuntu+1 instead
<al-maisan> Laibsch: ?
<al-maisan> ah
<al-maisan> ok
<pitti> c2tarun: right, you need to create a proper patch
<pitti> don't just modify it inline
<c2tarun> I created proper patch, take a look http://paste.ubuntu.com/573362/
<c2tarun> pitti: ^^
<pitti> c2tarun: "Origin: upstream, http://www.kbarcode.net/
<pitti> "
<pitti> c2tarun: that's not what Origin: is for; it's for the origin of the patch, which is you
<c2tarun> pitti: than what is From for?
<pitti> c2tarun: yes, you should drop Origin: from the patch
<pitti> c2tarun: and as I said, you either need to apply the change to Makefile.in as well (in your patch), or create a separate 99_autoreconf.patch, etc.
<c2tarun> pitti: what do you mean by applying change in Makefile.in as well as in patch? I am not getting.
<pitti> c2tarun: I think you really need to read an autotools tutorial at some point..
<pitti> c2tarun: if you change Makefile.am, the next package build will re-run automake to update Makefile.in, since it's outdated
<c2tarun> pitti: may be I do :( where can I get that?
<pitti> c2tarun: so you should also patch Makefile.in for the additional library, so that it is not out of date; this will avoid all the autoreconf noise
<c2tarun> pitti: ok, so my patch should modify Makefile.am and Makefile.in. but which file to modify first, as outdation will be checked by time-stamp(I guess)
<pitti> c2tarun: usually you can change them both in the same patch
<c2tarun> pitti: which file to modify first in patch? I think Makefile.am please correct me if I am wrong
<pitti> c2tarun: right
<c2tarun> pitti: I made a patch changing both files., but while building the source package it failed.
<c2tarun> pitti: here is the patch http://paste.ubuntu.com/573367/
<c2tarun> pitti: wait a sec something is wrng
<c2tarun> pitti: hey, I am facing one problem with that patch, please reply when you are free.
<pitti> c2tarun: the patch looks fine -- what's the problem?
<c2tarun> pitti: after building the binary package when I trying to build the source package I am getting the error patch failed.
<pitti> c2tarun: did you reapply the patch to a freshly unpackaged source package? if not, then presumably the autogenerated debian-changes-blabla patch and the automatically modified source will conflict
<c2tarun> pitti: I pulled completely fresh source package, modified changelog created patch pushed it, made changes, refresh it and then build the binary package.
<c2tarun> pitti: then when I tried to build the source package I got the error.
<pitti> "the error" == ?
<c2tarun> pitti: http://paste.ubuntu.com/573377/
<pitti> c2tarun: I suppose building the source package works if you didn't build the binary package yet?
<pitti> c2tarun: in general I recommend building the source package first, as binary builds often leave behind cruft
<pitti> c2tarun: as I already said, I suppose that the binary build still called automake at some point and thus changed the Makefile.in
<c2tarun> pitti: actually I wasn't aware that there is a squence for building the source and binary package. :( I just wanted to test my patch so I build it first. I'll repeat again
<Riddell> c2tarun: patching Makefile.in files is a bad idea, those are generated files
<c2tarun> Riddell: I have to make a patch to add libraries to Makefile.am what should I do?
<pitti> Riddell: I think he tried that first, but then ended up with a huge debian/patches/debian-changes-blabla
<c2tarun> Riddell: yup ^^
<Riddell> ending up with a huge debian/patches/debian-changes-blabla patch is the easiest way in my experience of autotools, it's not elegant but then neither is autotools
<Riddell> that's what we did for kde 3 packages, trying to keep the Makefile.in changes in sync with a patch is just fiddly for no gain
<c2tarun> Riddell: so I do upload a debdiff with debian-changes-* patch?
<Riddell> that would be my approach yes
<c2tarun> Riddell: sure I'll do that
<cjwatson> Riddell: nowadays you can use dh-autoreconf
<cjwatson> c2tarun: ^-
<c2tarun> cjwatson: what is that for?
<cjwatson> c2tarun: 'apt-cache show dh-autoreconf' before asking questions ;-)
<cjwatson> it solves your problem
<c2tarun> cjwatson: ok, I got it, this may solve the problem but I dont know how to use it. (My guess place them in rules file)?
<cjwatson> can I suggest reading its documentation
<cjwatson> you can run 'man dh-autoreconf' after installing it and you'll get a page explaining how it works
<ion> also http://manpages.ubuntu.com/manpages/natty/en/man7/dh-autoreconf.7.html
<c2tarun> cjwatson: thanks :) one more question, do I have to add dh-autoreconf into build-depends?
<tumbleweed> can a core-dev please open lucid and maverick tasks on bug 623342 for me?
<ubottu> Launchpad bug 623342 in samba "ntlm_auth returns invalid NT_KEY" [Critical,Confirmed] https://launchpad.net/bugs/623342
<c2tarun> cjwatson: ping
<pitti> c2tarun: yes, you need to add dh-autoreconf build-dep
<pitti> tumbleweed: done
<c2tarun> pitti: here is the rules file http://paste.ubuntu.com/573397/ I added lines 10 and 11 is it correct?
<pitti> c2tarun: no, this will convert cdbs to dh
<pitti> c2tarun: add an include /usr/share/cdbs/1/rules/autoreconf.mk
<c2tarun> pitti: done, anything else I should add?
<pitti> should work
<c2tarun> pitti: it is building, I didn't understood the stuff we did with rules file, can you please explain me a bit?
<cjwatson> c2tarun: FYI if I haven't replied to a question on IRC it's because I'm doing something else - pinging won't help
<c2tarun> cjwatson: sorry
<joaopinto> mvo, hi, is the lintian check during .deb installs on aptdaemon planned to be enabled on Natty ?
<pitti> c2tarun: the main point is to call dh_autoreconf during build; with using cdbs, this is done with what I wrote above; calling dh is incompatible with cdbs (it's a different build system)
<cjwatson> pitti: jockey in natty seems to have moved nvidia-common from Recommends to Depends, which breaks architectures other than amd64 and i386
<cjwatson> if it has to be Depends, then jockey-common is going to have to be Architecture: any ...
<pitti> cjwatson: ah; and we can't do arch specific depends
<pitti> cjwatson: I think we can move it back for now, it's not that importnat
<cjwatson> you can do arch-specific depends but only with Architecture: any
<cjwatson> you'd have to reopen bug 704597 if you moved it back :-/
<ubottu> Launchpad bug 704597 in jockey (Ubuntu) "Depend on nvidia-common" [Medium,Fix released] https://launchpad.net/bugs/704597
<pitti> we can replace ^ with explicitly seeding it, too
<pitti> cjwatson: uploading a fix now
<cjwatson> pitti: thanks!
<pitti> thanks for pointing out
<mvo> joaopinto: is it a problem? we got a lot of crash reports due to nasty debs
<pitti> cjwatson: nvidia-common is arch: i386/amd64; if I seed it, I don't need to specify this, as this will ignore nonavailable packages anyway, right?
<cjwatson> you don't need to, although it reduces the number of noisy warnings from germinate if you do
<pitti> ok, will do then
<joaopinto> mvo, at the current state yes, a) it does not provide an override button, b) IMHO it should have been better communicate because it affects many 3rd parties which do not provide nasty debs
<mvo> joaopinto: thanks, could you please help me with that by pointing to debs where its doing the wrong thing? this sounds like something worth discussing with glatzor (upstream) and we can figure out how to change it in a way that still catches the nasty ones without affecting the rest
<dholbach> janimo, happy patch pilot day
<directhex> mvo, blocking on usage of /opt is a huge no-no IMHO. plenty of third-party debs segregate themselves there
<janimo> dholbach, happy patch pilot puppetmaster day to you too :)
<joaopinto> mvo, thanks, that's already happening at bug 712377 , I am trying to understand if that is a planned feature for Natty
<ubottu> Launchpad bug 712377 in software-center (Ubuntu) "Opening a known good *.deb with software centre, fails to install as lintian errors cannot be overidden" [High,Triaged] https://launchpad.net/bugs/712377
<mvo> directhex: indeed, that is a bug
<dholbach> :-D
<c2tarun> pitti: I got this error, Can you please take a look, http://paste.ubuntu.com/573407/
<directhex> mvo, using lintian for the check is cheap, and lintian correctness is rarely the problem. bigger issue is validating anything in pre*/post* which may mangle the system horribly
<ion> Ooh, s-c uses lintian. Awesome.
<pitti> c2tarun: hm, this usually means that some part of dh_autoreconf failed; do you have the full build log?
<mvo> directhex: right, I agree here. still, lintian is a first step (even if its a bit over the top currently)
<c2tarun> pitti: yes I have but its quite long, may not be fit for pastebin
<mvo> directhex, joaopinto: I think the solution is to pass a list of checks to lintian instead of running them all
<directhex> mvo, yeah, that sounds reasonable imho
<c2tarun> pitti: how can I show you the build log/
<joaopinto> mvo, apart from the improvements maybe someone could write a short summary about the change ? Probably due to the lack of information I have already seen some comments about eventual Canonical interference
<pitti> c2tarun: pastebin should work
<mvo> joaopinto: that sounds reasonable, I can blog about it
<joaopinto> great :)
<c2tarun> pitti: this is how much I got, 1000 lines approx http://paste.ubuntu.com/573411/
<mvo> joaopinto: cheers
<pitti> c2tarun: please check the start of the build log whehre it calls dh_autoreconf, and check if it has errors
<c2tarun> pitti: its very messy :( my terminal only giving me 1000 lines when I tried to rebuild it I got this error http://paste.ubuntu.com/573412/
<zyga> I have a PPA for for lucid, I want one library from maverick, I can bzr get lp:ubuntu/maverick/sourcepackagename and then dpkg-buildpackage -S, but that will leave my package unsigned, should I just hack-add myself to Uploaders or is there a better way to do this?
<zyga> my goal is to be able to dput ppa:zkrynicki/myppaname *.dsc of the package I want to "backport" from maverick to my lucid ppa
<zyga> doko_, ^^ ?
 * zyga just added a changelog entry and ~zyga1 to version so that a normal package can be built
<doko_> zyga: debsign -k should work
<zyga> doko_, so it's best not to add another changelog entry and just sign with my own key instead?
<zyga> doko_, and push that to a PPA?
<doko_> no extra changelog entry required, but ~zyga1 works too
<zyga> ok, thanks
<kirkland> i can't seem to adjust my date/time settings from the date/time menu in unity
<kirkland> can anyone help me with that?
<chrisccoulson> mdz - can you remember what you were upgrading when you got bug 724202?
<ubottu> Launchpad bug 724202 in libdbusmenu (Ubuntu) "nautilus crashed with SIGSEGV in image_notify_cb()" [Medium,Confirmed] https://launchpad.net/bugs/724202
<mdz> chrisccoulson, I don't think so, but I can't check timestamps at the moment as that computer is on another continent
<hunger> How long dues bzr take to checkout bzr?
<hunger> Sorry, wrong channel.
<ev> mterry: might I ask you put on your MIR hat and have a look at https://launchpad.net/bugs/726453 ? I mistakenly thought dpkg-repack was already in main, and it's a dependency of some installer stuff I'd like to land.
<ubottu> Ubuntu bug 726453 in dpkg-repack (Ubuntu) "[MIR] dpkg-repack" [Undecided,New]
<mterry> ev, ok
<ev> thanks
<soren> ev: What do you need dpkg-repack for? (Just curious)
<ev> soren: http://bazaar.launchpad.net/~mvo/+junk/apt-clone/view/head:/apt_clone.py
<mterry> ev, approved
<ev> mterry: thanks bunches
<mvo> ev: I adress the points you raised last friday today, the msg is not lost :)
<soren> ev: Oh, I see. Thanks.
<ev> mvo: oh, brilliant.  Thanks a lot!
<ev> soren: sure thing
<hallyn> jbernard: the upstart script seems to be working for libcgroup.  I'm not sure how you want to handle the cgroup mountpoint (keep it always at /mnt, use /sys/fs/cgroup for maverick and natty, use something else).  Do you mind if I hand bug 644669 over to you?
<ubottu> Launchpad bug 644669 in libcgroup (Ubuntu) "cgred should be started before libvirt-bin" [Medium,Triaged] https://launchpad.net/bugs/644669
<janimo> @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:
<siretart> doko_: would it be possible to copy sun-java6 from maverick/partner to natty/partner?
<doko_> siretart: I don't have partner upload rights anymore. will forward the request
<siretart> doko_: thanks
<siretart> I've added natty to our fai infrastructure here, and so far this is the only issue in our 'error.log' :-)
<siretart> unity still doesn't work though, but I need to debug that further
<mterry> cjwatson, could you please add libappindicator to desktop set?
<cjwatson> mterry: done
<mterry> cjwatson, thank you!
<zyga> how can I list valid options to debhelper --buildsystem=?
<cjwatson> zyga: 'dh_auto_configure -l' in a source tree
<zyga> thanks, I needed python_distutils
<janimo> any known issues with cowbuilder-dist on natty? create and update works but a build does not, complaining about pbuilder-satisfydepends-dummy
 * ogra grins about the changelog of cjwatson's recent upload 
<ogra> unknown (unknown1) unknown; urgency=unknown
<highvoltage> I guess that was not to the archives
<ogra> its a mis-entry that apparently was in debian
<ogra> between biosdevname 0.3.1 and 0.3.3
<cjwatson> it was from the upstream changelog - I didn't want to redact it
<ogra> yeah
<ogra> just found it funny
<cjwatson> it was actually a missing header line
<cjwatson> dpkg-genchanges or something made up the line you quoted
<ogra> ah, i didnt kno wit is that clever
<cjwatson> kees: does your comment in bug 723870 indicate approval of the MIR once biosdevname is available?
<ubottu> Launchpad bug 723870 in biosdevname (Ubuntu Natty) "[MIR] biosdevname" [High,In progress] https://launchpad.net/bugs/723870
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in #ubuntu-classroom in 20 minutes!
<pitti> tseliot: thanks a lot for adding the ABIs to nv/fglrx!
<zumbi> someone knows what is going on with gobby.ubuntu.com, I cannot log into it, is it a problem on my side or is the server down?
<ogra> zumbi, works fine here
<zumbi> ogra: maybe you could email me the Emdebian/ docs?
<ogra> zumbi, sure, no prob
<zumbi> thanks
<ogra> zumbi, sent
<tseliot> pitti: np ;)
<zumbi> ogra: got it! thanks
<ogra> :)
<ogra> pitti, can we do something against jockey-common not being installable on armel due to nvidia-common being nonexistent
<pitti> ogra: yes, fixed this morning
<ogra> hmm
<cjwatson> beat you to it ogra ;-)
<ogra> heh
 * ogra should apt-get update his chroots before asking 
<ogra> works fine
<cr3> anyone happen to know where the revision number of a pci device is supposed to be stored in sysfs?
<pitti> cr3: I don't think it is; I think you need to use libpci to find out
<cr3> pitti: thanks for the tip, I'll have a look there
<amitk> unity noobie question: how does one start an application not on the dock? Search doesn't seem to work...
<pitti> amitk: it works here (if it doesn't crash..); what's the app you are looking for?
<amitk> pitti: mumble (or any other really). Currently I start it the terminal and then tell unity to keep it in the launcher
<amitk> unoptimal
<amitk> IIUC, clicking on the Ubuntu logo in top left and typing in the search box should do magic, somewhat like Apple's spotlight?
<charlie-tca> amitk: I navigate to /usr/share/applications and use the files there when nothing else seems to work
<amitk> charlie-tca: eeekkk!! It's a brave new world :)
<pitti> amitk: hm, works here; but that only really started to work a few days ago, are you running current natty?
<pitti> amitk: before that, ctrl+alt+t and launch from there :)
<amitk> pitti: up to date as of a few minutes ago, but using unity for the first time since nvidia binary became available today
<amitk> ok, so terminal it is then :)
<artfwo> mterry, is it okay to ask you about your latest libappindicator package here?
<amitk> nice, 35Mb crash report (compiz) for launchpad to gulp down :)
<ogra> we love details :)
<amitk> pitti: so apport dialog says "Report Problem", "Restart Program". What if I want to do both?
<amitk> ogra: I'm just hoping that it isn't processing my ubuntuone and dropbox folders :)
<ogra> lol
 * ogra pulls amitk's crash report for some new music
<Daviey> cjwatson / pitti / kees / sabdfl  : I sent a mail to the TB last week, is it still in moderation?
<cjwatson> probably, I'll look now
<Daviey> oh, or mdz
 * amitk adds output from /dev/random to the crash report to introduce ogra to a new genre
<Daviey> cjwatson, thanks
<ogra> LOL
<mdz> Daviey, if it's the one you sent last Thursday, it went through
<mdz> I saw it over the weekend
<mdz> Daviey, regarding bind9?
<Daviey> mdz, ah yes, thassim
<Daviey> Thanks.
<cjwatson> yep, I've just flushed the moderation queue and it wasn't there
<amitk> compiz really doesn't like a HUP signal
<Daviey> thanks cjwatson
<till_> hi
<kshadeslayer> till_: hi :)
<till_> i'm building a package and i keep my 'debian/' dir in a git repository. so whenever i debuild, i have to copy my debian/ dir into the source dir of my package. i tried symlinking it but then debuild complains. is there a way to make it work so i don't go crazy? ;)
<raphink> till_, have you considered git-buildpackage?
<raphink> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
<till_> raphink: i have not! i just figured out the rest, i'd really just like to symlink the folder though
<raphink> I don't think that's possible, but git-buildpackage probably provides similar solutions
<natschil> Hello. I am trying to write a multitouch virtual driver that gets some input from somewhere and then translates this into multi-touch input to the kernel. What apis do I have available to pass this on to the kernel?
<natschil> this would only need to work in ubuntu. Preferrably 10.10 but 11.04 is ok too.
<oubiwann> natschil: you should join #ubuntu-touch and re-ask that question
<natschil> oubiwann: oh cool, I didn't know that existed. will do.
<oubiwann> natschil: no prob! I mention it because that's where the experts are hanging out, not here ;-)
<mterry> artfwo, yeah, what's up about libappindicator?
<artfwo> mterry, I meant to ask about uploading a change to ubuntu-desktop branch, but figured it out already
<pitti> amitk: you can't right now, I'm afraid
<pitti> Daviey: I did a moderation run  few hours ago, should be here now
<mterry> artfwo, k, cool
<mterry> @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: mterry
<Daviey> pitti, yup, thanks
<artfwo> mterry, take a look at bug 724917 if you have time
<ubottu> Launchpad bug 724917 in libappindicator (Ubuntu Natty) "Importing appindicator from python crashes with ImportError on undefined symbol" [Medium,Triaged] https://launchpad.net/bugs/724917
<artfwo> I've prepared an upstream merge proposal and a package merge, 'cause upstream didn't review the change for several days already
<seb128> artfwo, mterry: kenvandine is on it, I've pinged him about that on #ubuntu-desktop a bit earlier
<mterry> seb128, k, cool.  kenvandine: i'm on patch duty, can gladly take that if you're busy
<seb128> artfwo, several days already", you filed that on saturday and upstream is working on it during it paid job time
<kenvandine> mterry, if you can, please do
<kenvandine> debugging datetime atm
<seb128> artfwo, it's just monday morning in the u.s
<mterry> kenvandine, hopefully nothing I did with my preference dialog
<kenvandine> nope
<artfwo> seb128, understood it indeed
<kenvandine> mterry, it isn't showing events in the right order, so pretty easy to missing something important :)
<mterry> artfwo, k, I'm looking now
<kenvandine> thx mterry
<seb128> kenvandine, seems it's showing recurrent events first then others
<kenvandine> yeah
<mterry> artfwo, how'd you generate the new .defs file?  by hand?
<artfwo> mterry, yes, but I checked it later against h2defs output
<artfwo> mterry, the new .defs is fully compliant with appindicator.h, and once built, fixes all the python indicators' crashes
<mterry> artfwo, yeah, looks right, just confirming one thing manually
<amitk> pitti: its kinda required for things like compiz that don't have an icon i can click on to restart.
<kees> cjwatson: biosdevname> yes
<kees> cjwatson: I looked through the package out of the NEW queue
<cjwatson> ok, cool, thanks - if somebody wants to push that through binary NEW then, I can promote it
<pitti> cjwatson: want me to review?
<cjwatson> yes please
<pitti> cjwatson: do you have the MIR bug # handy? (so that I can close it)
<soreau> ev: I am in a live session trying to install natty and I patched in http://paste.ubuntu.com/572185/ but it's still just sitting there with busy cursor after clicking forward
<cjwatson> pitti: bug 723870
<ubottu> Launchpad bug 723870 in biosdevname (Ubuntu Natty) "[MIR] biosdevname" [High,In progress] https://launchpad.net/bugs/723870
<pitti> cjwatson: NEWed, promoted, bug closed
<cjwatson> soreau: try patching in http://bazaar.launchpad.net/~ubuntu-core-dev/partman-auto/ubuntu/revision/595 (with appropriate filename adjustments) too
<cjwatson> pitti: yay, thank you
<pitti> cjwatson: not relevant for MIR, but I noticed that the udev rules do ACTION!="add", GOTO end
<pitti> cjwatson: coudl that be an issue with coldplugging, i. e. if the action is "change"?
<cjwatson> pitti: would you want to set NAME on action==change?
<pitti> it would be wrong in general, I just wonder about the initial udevadm trigger during boot, after initramfs
<pitti> ah, ignore me, we do --action=add there
<mterry> artfwo, pushed, thanks so much!
<artfwo> mterry, thanks!
<artfwo> mterry, got a couple of minutes to explain why a) your upload was in ~ubuntu-desktop branch, and b) should I propose merges upstream or in ubuntu in the future?
<soreau> cjwatson: It still 'hangs' and there's no output from ubiquity in the terminal
<cjwatson> did you reboot after the previous test?
<soreau> no
<mterry> artfwo, sure.  I'm not a member of the upstream team.  But I am a member of the Desktop team that tries to make sure the package in Ubuntu is in good shape
<mterry> artfwo, so while I couldn't approve the merge for upstream
<cjwatson> I wouldn't recommend attempting to rerun ubiquity without rebooting after it's fallen over in a heap
<mterry> artfwo, I could approve the merge for Ubuntu
<soreau> cjwatson: ok
<artfwo> mterry, got it, thanks
<mterry> artfwo, in future, you did right thing.  It should always be sent to upstream.  Whether you bother to create a separate merge request for Ubuntu just depends on how urgently you want it in
<mterry> artfwo, so you did the right thing here
<artfwo> mterry, does the ubuntu branch matter here? (lp:ubuntu or lp:~ubuntu-desktop I mean)
<artfwo> mterry, i.e. I want my fix in ubuntu ASAP, and what's the right ubuntu branch, if there are many?
<mterry> artfwo, so since the package has the Vcs-Bzr field in its debian/control file pointing at lp:~ubuntu-desktop, it indicates that the packaging is handled in a non-typical place (i.e. not lp:ubuntu)
<mterry> artfwo, so ~ubuntu-desktop was the right place, because historically, that's where the Desktop team maintains lots of packages (this behavior predates the whole lp:ubuntu thing)
<mterry> artfwo, when in doubt, the command 'debcheckout' will check for Vcs-Bzr and give you that if it exists
<artfwo> mterry, I see it now, thanks so much!
<mterry> yw
<till_> raphink: so i checked out git-buildpackage, but i'm not sure how to integrate it into my workflow. right now my biggest 'problem' is that i have to keep the 'debian/' dir inside the source in sync with the actual i have a in git repository. is there a jumpstart guide?
<soreau> cjwatson: I couldn't get it to work. It gets stuck on the screen that checks if your connection is working and asks to install 3rd party software. Then I press forward and it sits on busy cursor forever or until I click quit
<bryce_> ev, cjwatson, bug #714829 is suitable for your attention.  The issue is a serious OOM situation caused by ubiquity during LiveCD that ends up crashing X.  (Thus, we're getting tons of reports of this issue).  I've posted a patch that reverts a recent ubiquity change and is seen to stop the OOM occurring, but it needs further analysis by one of you two to find a real fix.
<ubottu> Launchpad bug 714829 in xserver-xorg-video-intel (Ubuntu Natty) "Xorg segfaults during LiveCD installation using preseed file" [High,Triaged] https://launchpad.net/bugs/714829
<cjwatson> good timing, I was just preparing a ubiquity upload
<cjwatson> bryce_: what do you think of Mario's later patch?
<bryce_> cjwatson, I think it probably can't hurt, but sounds like you'd want both patches
<cjwatson> and then we reopen bug 693300, yes?
<ubottu> Launchpad bug 693300 in ubiquity (Ubuntu) "Top white bar in oem-config (ubiquity) when choosing CJK." [Undecided,Fix released] https://launchpad.net/bugs/693300
<cjwatson> (whch I agree is less serious)
<bryce_> cjwatson, that's right
<bryce_> fwiw, the original patch to that bug looks sort of like a sledgehammer solution (screen isn't updating?  let's update it ALL THE TIME) ;-)
<cjwatson> OK, I'll go ahead with that since nobody seems to have any better ideas in the short term
<bryce_> ok cool, thanks
<mterry> cjwatson, can you also add ubuntuone-control-panel to the ubuntu-desktop set?
<cjwatson> mterry: done
<mterry> cjwatson, thanks!
<psusi> ScottK: found question about package qt-sdk.  Links to a bug report you filed asking for the amd64 binary to be removed from the archive, which seems to have been an error.  original question at https://bugs.launchpad.net/ubuntu/+source/qt-sdk/+bug/618075
<ubottu> Ubuntu bug 618075 in qt-sdk (Ubuntu) "Please remove arch any binaries" [Medium,Fix released]
<psusi> iirc, Architecutre: all means it should be built for all archs, as opposed to Architecture: any, meaning the results are architecture independant, is that correct?
<ScottK> Yes, but the old arch any binaries were still there.
<psusi> err, that was the removal bug, original question was https://answers.launchpad.net/ubuntu/+source/qt-sdk/+question/147275
<psusi> that's because it is targeted to arch: all
<psusi> so now there is only the i386 build in the archive
<psusi> at least according to http://launchpadlibrarian.net/53715084/qt-sdk_2ubuntu2_i386.changes
<cjwatson> psusi: you have it backwards.
<psusi> hrm... then what's wrong with this package?  according to the build log, it was only built for i386, which generated a _all, but it seems to have only been put in the i386 archive?
<ScottK>  qt-sdk |   2ubuntu2 | maverick/universe | source, all is what's in the archive.
<ScottK> You are misunderstanding how arch all packages work.  It's as it should be.
<psusi> ScottK: it isn't though since the binary is only found in the archive for i386.  Users of amd64 can't install it.
<ScottK> I'm not sure what you mean.
<ScottK> http://archive.ubuntu.com/ubuntu/pool/universe/q/qt-sdk/
<slangasek> ScottK: he's right, actually; somehow the package isn't published in the amd64 Packages file
<psusi> lp lists only the i386 build, and qt-sdk does not appear in Contents-amd64.gz.  https://launchpad.net/ubuntu/+source/qt-sdk
<ScottK> slangasek: Oh.  Weird.
<slangasek> in fact, it's only published on i386
<ScottK> Is a no change upload the easiest fix for that?
<slangasek> it's correctly published for lucid, so it must have been a publisher bug in the maverick timeframe
<slangasek> ScottK: yep
<psusi> probably
<ScottK> I'll take care of it.
<ScottK> psusi: Thanks for bringing it up.
<psusi> no problem... kinda curious how it got weirded like that now though
<psusi> like, shouldn't the lp page say it was built for arch: all, not i386?
<ScottK> Should.
<slangasek> which lp page?
<psusi> https://launchpad.net/ubuntu/+source/qt-sdk
<slangasek> https://launchpad.net/ubuntu/+source/qt-sdk/2ubuntu2 correctly shows the i386 build, which is the build that outputs the arch: all package
<psusi> so that is normal?  you  build for i386, and get an _all instead of _i386?  which should be added to the contents of the other archs automatically?
<psusi> I figured it would say it built it for the all arch, rather than i386 ( and got a result for all instead )
<slangasek> https://launchpad.net/ubuntu/maverick/amd64/qt-sdk/ shows the disappearance of the binary from amd64
<slangasek> ScottK: ^^ you did it ;)
<ScottK> IIRC it was a leftover amd64 binary or something.
<slangasek> psusi: yes, that's normal and correct.  That's the i386 build which can result in packages of arch: i386 and/or arch: all;
<slangasek> that page is the wrong place to look to see which architecture a given package is
<slangasek> ScottK: ok - in general the arch: all package should smoothly supersede an arch: any package of the same name in the archive
<slangasek> so maybe there was an underlying bug here
<ScottK> I don't recall why I thought it didn't.
<psusi> it looks like this package has always been an arch: all
<psusi> so there should never have been an _amd64?
<psusi> unless it was there before karmic and lp just doesn't show it...
<cjwatson> I suspect somebody processed that removal after the arch: all-ness had already been applied.
<cjwatson> I have a feeling that regrettably lp-remove-package.py doesn't catch that.
<smoser> cjwatson, If i were interested in putting a static entry into grub menu, would you recommend just packaging a file in '/etc/grub.d/XX_cloud' ? or is there a better way.
<slangasek> didrocks: hi, why is unity getting a dependency on libnux-0.9-0 (<< 0.9.28)?  If nux is changing its ABI, that should be reflected in the package name...
<didrocks> slangasek: nux is not near ABI or API stable
<didrocks> slangasek: basically, it's broken every week
<slangasek> didrocks: so this is a convenience to avoid going through NEW each time?
<didrocks> that's why we force everyweek latest nux and latest unity
<slangasek> didrocks: will it be ABI-stable by beta?
<didrocks> slangasek: hoping so, better to discuss with the dx team about it
<slangasek> hmm
<cjwatson> smoser: that sounds fine
<smoser> you have a suggestion on the 'XX' ?
<cjwatson> no, pick it however you want the order to fall
<cnd> Riddell, I'm looking at the upload of qt4-x11
<cnd> the difference you pushed is the one we determined to be incorrect :)
<jelmer> hmm, in http://reports.qa.ubuntu.com/reports/sponsoring/, how is "Origin" determined?
<james_w> jelmer, using packagesets somehow I think
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<Riddell> cnd: oh foo, really?
<cnd> Riddell, yeah, you're casting a double * to a float * on arm
<cnd> which means that when you advance the variable using values++
<cnd> you're only advancing 4 bytes instead of the requried 8 bytes
<cnd> all that needs to change is to make the values variable a double * instead of a qreal *
<cnd> no casting necessary :)
<Riddell> cnd: http://bazaar.launchpad.net/~kubuntu-members/qt/ubuntu/revision/153 ok?
<cnd> Riddell, yep!
<Riddell> cnd: ok uploading, sorry for the hassle, well spotted
<cnd> Riddell, np
<cnd> thanks for working with me on it :)
<slangasek> pitti: hi, cjwatson suggests that Friday (i.e., immediately after a3) is better for dpkg-multiarch than to land it right now; would you be ok with this?
<cjwatson> pitti: this is mainly because we're currently 25 minutes from when skaet wants alpha-3 freeze to start and it seems to me to be cutting it pretty fine
<slangasek> is it?  I thought skaet_ wrote that the freeze started 23.5h ago
<ogra> i understood she said 23:00 UTC
<cjwatson> what ogra said
<slangasek> yes, the mail said 2300 UTC on 2/27
<cjwatson> blink
<ogra> heh
<cjwatson> OK, that's not what I thought skaet and I had agreed
<ogra> and not how she sounded in -release
<xrdodrx> the gnome-paint package is broken
<slangasek> a typo in the mail seems possible - I was just going by the mail though :)
<xrdodrx> it's 0.3-2
<xrdodrx> had to install 0.4
<xrdodrx> from https://launchpad.net/gnome-paint
<slangasek> cjwatson: the mail is why I was asking at all; if we're not actually /frozen/ yet, I can certainly get it done :-)
<xrdodrx> I seem to run in to a lot of broken pkgs on ubuntu
<broder> slangasek: whoa....dpkg-multiarch is actually landing in natty? *awesome*
<xrdodrx> So far this, beep, and gnibbles
<slangasek> broder: subject to the ongoing negotiations with the release team ;)
<broder> hehe
<cjwatson> backlog of -release was clearly for 2300 on Monday
<slangasek> cjwatson: so I actually have 15 minutes to get this done? :-)
<ogra> 17 even :)
<cjwatson> this is my understanding, but you get to apologise to skaet and clean up if it goes wrong ...
<slangasek> yep
<Ampelbein> xrdodrx: the current version of gnome-paint in maverick (ubuntu 10.10) is 0.3-2, in natty (ubuntu 11.04, not released yet) the version is 0.4
<cjwatson> xrdodrx: well, all those packages install fine here on natty (this is #ubuntu-devel, support for older releases would be on-topic on some other channel)
<xrdodrx> Ampelbein, yeah, I fixed it by finding an updated deb...it just bothers me how packages are broken :<
<xrdodrx> cjwatson, this is #ubuntu-development, no?
<xrdodrx> or am i missing something
<Ampelbein> xrdodrx: it isn't broken.
<cjwatson> xrdodrx: where we work on the next release
<cjwatson> xrdodrx: it's not a bug reporting channel, though - IRC doesn't make a good medium for tracking bugs
<xrdodrx> Ampelbein, just because it launches doesn't mean it's not broken
<cjwatson> it's a channel for developers to coordinate among themselves and discuss problems
<xrdodrx> and gnibbles is broken, so is beep
<cjwatson> but we can't take bug reports here
<xrdodrx> oh, ok
<xrdodrx> sorry cjwatson
<cjwatson> the flow would be impossible
<cjwatson> np
<xrdodrx> I thought this was a place to report because of -devel :<
<cjwatson> https://help.ubuntu.com/community/ReportingBugs
<cjwatson> uninstallable or non-functional packages would be one reason for us to do stable updates, so it's certainly worth reporting that kind of thing even if it's fixed in natty
<xrdodrx> cjwatson, yeah, I've found unaddressed bug reports for each of these packages...guess I'll just wait for natty as it's coming in April :)
<cjwatson> I certainly don't mean to discourage you from reporting bugs (quite the opposite), just steering you towards a more effective place to do it :)
 * cjwatson -> bed
<ari-tczew> jdstrand: * debian/control: update Vcs for natty <- it doesn't need to be mentioned in d/changelog
<micahg> ari-tczew: no, VCs changes should be mentioned
<micahg> Vcs
<jdstrand> ari-tczew: I like to document everything
<jdstrand> I changed from trunk to its own tree
<micahg> if every package had a uniform Vcs-* in Ubuntu, it would be a different story (like update-maintainer in theory)
<ari-tczew> micahg: cjwatson told me that doesn't because d/changelog should include only informations which can't be dropped till sync. vcs can be dropped for sync, so it's not necessary in d/changelog
<jdstrand> ari-tczew: that one cannot be dropped for sync
 * ari-tczew hopes that cjwatson will answer for it to jdstrand and micahg cause ari-tczew is not going to be unreliable.
<jdstrand> ari-tczew: Debian uses ufw-debian, natty has ufw-natty, trunk was ufw-trunk
<ari-tczew> jdstrand: I see source name just 'ufw'.
<jdstrand> actually, I did use ufw-debian
<jdstrand> ari-tczew: I am talking about the Vcs branch name
<ari-tczew> jdstrand: and you will keep this change if it's only remaining change
<ari-tczew> ?
<jdstrand> ari-tczew: that wasn't the case here. if I sync from debian, I'd drop everything
<jdstrand> ari-tczew: I am not saying you are wrong, I am saying that I haven't seen policy stating that I shouldn't include it in my merges
<jdstrand> ari-tczew: I maintain this package in both Debian and Ubuntu, and it is a way for me to keep my sanity
<ScottK> ari-tczew: I think that where someone is doing all the work on a package in Debian and Ubuntu they have a great deal of freedom to do it in  a way that suites their work.
<ari-tczew> jdstrand: sorry, I can't give you a link to policy which I was talking about, maybe cjwatson will give you tomorrow.
<ari-tczew> ScottK: does it mean that I can;t say anything?
<ScottK> ari-tczew: No, but their may be more productive uses of your time than nit picking other people's work.
<xrdodrx> can someone test the packages gnibbles in natty for me?
<xrdodrx> I don't have the time to install a vm atm :<
<cody-somerville> That being said, peer review and the discussions it can produce are usually quite valuable to all parties involved. :)
<ari-tczew> ScottK: It's not nitpick. I just say it because I was poked for it in the past and I remember it was in official policy.
<ari-tczew> And I guess I'm not that strict as micahg.
#ubuntu-devel 2011-03-01
<soreau> I still can't seem to get natty's partitioner running from a live session. I tried the mini.iso this time from usb and it still stops working when going to load the partitioner
<TheMuso> soreau: Is this with the latest daily build?
<soreau> TheMuso: yes
<TheMuso> soreau: Ok have you checked the logs in /var/log/installer to see what might be going on?
<soreau> no
<soreau> It seems this is busybox shell for mini.iso
<TheMuso> soreau: Well either from the mini.iso or a live CD, you should grab the logs in /var/log/installer and file a bug with those logs attached.
<soreau> TheMuso: Ok
<soreau> TheMuso: I'm here in the live session now, here is everything from /var/log/installer debug: http://sprunge.us/VGLF version: http://sprunge.us/GbBa
<TheMuso> soreau: Please file a bug with that information attached.
<soreau> TheMuso: Where?
<TheMuso> soreau: You can do so by running "ubuntu-bug ubiquity" in the live session.
<soreau> ok
<soreau> TheMuso: 726908 filed
<TheMuso> soreau: Thanks, I won't be the one who attends to it, but I just wanted to make sure it was filed in the first place. :)
<soreau> Yea, I hope this isnt a real bug. Others have said it's broken until they fix it
<skaet_> slangasek, there was a typo in the mail. (a couple actually... :P)  freeze was today at 2/28 2300 UTC.
<slangasek> skaet_: ok :)
<slangasek> that's good, means I'm not in trouble for uploading dpkg ;)
<skaet_> heh, as long as it works in the  builds tomorrow ;)
<Keybuk> slangasek: I could upload dpkg again if you like ;-)
<slangasek> Keybuk: cool, then I can blame all the bugs on you
<slangasek> and I get multiarch support
<slangasek> win-win!
<Keybuk> it's not like I can be fired
<Keybuk> or that it would affect my next performance review in any way
<Keybuk> being a community contributor has numerous advantages
<lifeless> Keybuk: how much ubuntu time are you getting in your new job?
<psusi> cjwatson, if you are still up, no, that change to partman-auto did not fix things... though there may be a new clue.. it now hangs while the target partition is still mounted.  It didn't do that before.
<Keybuk> lifeless: none
<Keybuk> however not working from home means I have rather less "job time" in my life ;-)
<lifeless> Keybuk: cool
<psusi> Keybuk, still not had a chance to review my ureadahead patches then eh? ;)
<lifeless> Keybuk: for some reason i thought you were going to get upstart time (or are you, just not ubuntu time) ?
<Keybuk> lifeless: correct; upstart time, not ubuntu time
<Keybuk> psusi: I told you who you need to speak to about those ;-)
<psusi> Keybuk, you also write plymouth didn't you?  I started using uswsusp the other day and noticed that it has support for some other splash systems, but not plymouth... thought it might be nice to add that if I find time... and wondered why it isn't part of a default Ubuntu install
<Keybuk> psusi: I deny any accusations you might make
 * Keybuk points wildly at cjwatson
<Keybuk> HE TOUCHED IT LAST
<psusi> ohh, you are working full time now on upstart?
<psusi> lol
<Keybuk> psusi: not currently, upstart is my 20% time project
<psusi> Keybuk, you're still upstream maintainer of ureadahead according to lp ;)
<Keybuk> psusi: am I? are you sure "canonical-scott" isn't?
<Keybuk> canonical-scott died
<Keybuk> there was a funeral and everything
<psusi> Keybuk, says Scott James Remnant ;)
<psusi> lol
<Keybuk> psusi: it says "Scott James Remnant (Canonical)"
<psusi> https://wiki.ubuntu.com/ScottJamesRemnant
<psusi> ;)
<Keybuk> haha
<Keybuk> well, that can't possibly be me
<Keybuk> I'm not a Canonical Ltd employee
<psusi> maybe you are and just don't know it, hehe...
<Keybuk> heh, we haven't bought them yet ;-)
<psusi> ahh, I know what I can bug you about now... go fix the google phone ;)
<Keybuk> hehe
 * Keybuk loses all your e-mail
<psusi> and a tablet while you're at it.. the new samsung galaxy tab has no usb
<psusi> hehe
<Keybuk> anyway, clearly I've reached a BAD POINT in the day, and I'm going to go home
<Keybuk> bash: /tmp/stateful_update: /bin/sh: bad interpreter: Permission denied
<Keybuk> ERROR  : Stateful update was not successful.
<Keybuk> ^ BAD
 * psusi stares blankly
<StevenK> Keybuk: /tmp/stateful_update doesn't have +x ?
<Keybuk> no I think /bin/sh has lost its +x
<psusi> trying to execute something in /tmp?  this will end in tears
<StevenK> Oooh, he's right. Doesn't /tmp have noexec?
<Keybuk> StevenK: not on Chrome OS
 * StevenK goes to wash
<psusi> so chrome os is using upstart eh?
<Keybuk> yes... obviously
<Keybuk> anyway, dinner *gone*
 * psusi kicks the stinking radeon driver for running it up to 83 C again
<slangasek> Keybuk: who are you kidding, making the release team miserable has never impacted performance reviews :P
<ion> slangasek: Woot! dpkg multiarch! Will i fry my desktop box if i migrate from i386 to amd64 with the current versions of dpkg, apt et al?
<slangasek> you will fry it without hope of repair
<slangasek> fyi :)
<ion> hehe
<Hock> test
<Hock> if I fix a reported bug, how do I get the changes accepted?
<micahg> Hock: https://wiki.ubuntu.com/SponsorshipProcess
<Hock> micahg: thanks. even a simple debconf postinst scipt change require sponsorship?
<micahg> Hock: sponsorship is a means to get your fix uploaded, if you just want to attach a patch to a bug, it will eventually be reviewed, but there's no guarantee when, the sponsorship queue is reviewed regularly
<micahg> Hock: which package?
<Hock> micahg: yes, i realise now that no one really have the time to look at attached patch especially of low importance. its for lirc
<Hock> micahg: if the right process is not follow
<Hock> micahg: I have seen in forum/mailing list that patch dont ever get update sometime
<micahg> Hock: patches of all importance are welcome
<Hock> micahg: thanks for the link. it look simple enough to follow. :) I will try it.
<micahg> Hock: yes, that's why I was mentioning the difference between the sponsorship queue and just attaching a patch to a bug, we have over 2k patches that need review vs about 40 items in the sponsorship queue
<micahg> Hock: feel free to ask if you run into issues
<Hock> micahg: i have another fix for lric that involve adding a new remote that affect upstream. can i use the same process?
<micahg> Hock: you can propose it, depending on the fix, they might ask it to go through upstream review first
<Hock> micahg: ok. I will try out the sponsorship and get a hang of it first
<Hock> micahg: the thing i find about the difficulty of patches going in is that it too complicated. there is one particular fixed of a pvr in v4l2 which many have been using
<Hock> micahg: but it never get into upstream even after many follow-up
<Hock> micahg: i am using gmail account. What should i be entering for system mail name?
<micahg> Hock: well, sometimes we take patches ahead of upstream, it depends on the specific upstream
<micahg> Hock: system mail name?
<Hock> micahg: sudo apt-get install bzr bzr-builddeb
<Hock> micahg: as part of the postfix configuration
<micahg> Hock: that's for a local mail server
<Hock> micahg: yes. but i am not sure if its important for the sponsorship
<micahg> Hock: it's not
<Hock> micahg: anyway. i just dump the hostname in
<soreau> Would the fact that one of my drives is GPT contribute to the partitioner failing to start?
<Hock> micahg: if this the correct branch? bzr branch lp:ubuntu/lirc lirc
 * micahg checks if the branch is up to date
<micahg> Hock: yes, that looks correct
<Hock> micahg: would doing that get patch in natty or maverick?
<micahg> Hock: natty
<micahg> Hock: to update maverick you need a stable release update: https://wiki.ubuntu.com/StableReleaseUpdates
<Hock> micahg: i see. thanks.
<Hock> micahg: do I then need to be on natty to use bzr?
<Hock> micahg: currently running it on maverick
<micahg> Hock: nope
<Hock> micahg: pardon all the noob questions. have always wanted to help out but find it difficult to do so
<micahg> Hock: feel free to ask as many questions as you like
<soreau> This kinda sucks having natty running live in several different ways and not have the ability to install
<TheMuso> soreau: No I don't think so.
<soreau> TheMuso: It's always handled GPT fine in the past so I think I will wait a few more weeks and try again
<pitti> slangasek: too late now anyway, so I guess it's decided :)
<slangasek> pitti: yep!  and it didn't break the world too badly
<slangasek> debootstrap almost works again
<slangasek> <cough>
<Hock> micahg: thanks for your help. have managed to submit the patch via sponsership
<micahg> Hock: great, thank you for your contribution to Ubuntu
<Hock> micahg: looking forward to contribute more if i can
<pitti> slangasek: I just got the livefs-base build failure, could this have anything to do with the new dpkg? rsyslog hasn't changed in 1.5 montsh
<slangasek> pitti: yes, see above - "debootstrap almost works again" :)
<slangasek> pitti: just waiting for the publisher now
<pitti> slangasek: ah, I overlooked that in the log, sorry; just looked at the "Upgrading" stage
<pitti> cool
<slangasek> pitti: two packages broke with the change, python-central and ucf, which both poke around in /var/lib/dpkg/info directly; multiarch changes the dpkg db paths
<slangasek> I've fixed and uploaded both, should finish publishing any minute now
<didrocks> good morning
<dholbach> good morning
<pitti> Riddell: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt has quite a few Qtish packages (qtmobility, telepathy-qt4, kubuntu-mobile-default-settings) which want to go to universe; is that intended?
 * pitti hugs dholbach
 * dholbach hugs pitti back
<apw> pitti, is the retracer ok?  i have a bug filed 9 hours ago which is still not retraced: bug #726840
<ubottu> Bug 726840 on http://launchpad.net/bugs/726840 is private
<pitti> apw: I just restarted it, it crashed last  night
<apw> pitti, thank you sir ... she is a fragile lady, we must remember to complement her more often
<pitti> indeed..
<pitti> Riddell: for bug 712061 , that merge was done; should this work now?
<ubottu> Launchpad bug 712061 in kubuntu-mobile-default-settings (Ubuntu Natty) "kubuntu mobile images fail to load" [Undecided,In progress] https://launchpad.net/bugs/712061
<Riddell> pitti: bug 712061 is waiting on deployment to cocoplum
<ubottu> Launchpad bug 712061 in kubuntu-mobile-default-settings (Ubuntu Natty) "kubuntu mobile images fail to load" [Undecided,In progress] https://launchpad.net/bugs/712061
<zyga> jdstrand, ping
<\sh> what was the channel for canonical sysadmins?
<zyga> \sh, #is
<StevenK> That's not it, #canonical-sysadmins on this network
<\sh> #canonical-sysadmin is more correct ;)
<\sh> found it already on some gnome pages
* pitti changed the topic of #ubuntu-devel to: Archive: feature freeze, Alpha 3 soft 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:
<amitk> is ubuntu-desktop still the meta package that'll ensure I've got everything equivalent to a fresh natty install?
<pitti> amitk: mostly; it won't reinstall recommends which you uninstalled manually
<smoser> anyone able to help explain http://uec-images.ubuntu.com/server/natty/20110301.3/log.stdout.stderr .
<smoser> i'm seeing build errors on last night uec image builds.  the first errors mention lsb_release
<pitti> smoser: pycentral failure due to new multiarch dpkg; shoudl have been fixed over night
<smoser> and pycentral
<smoser> ah.
<smoser> ok.
<pitti> smoser: can you trigger a rebuild? it should have been fixed for about 2 hours now
<pitti> smoser: (I am rebuilding all 'regular' alternates/desktops for that ATM)
<smoser> can, do. thank you pitti.
<smoser> my other question... i think i'm in need of an archive admin to process bug 725127
<ubottu> Launchpad bug 725127 in Ubuntu "FFE: add 'cloud-initramfs-tools' package and cloud-utils update" [Wishlist,Confirmed] https://launchpad.net/bugs/725127
<smoser> kirkland, had thought he did, but it does not appear to have taken, there is no cloud-initramfs-rescuevol or cloud-initramfs-growroot in the archive.
<techbreak> bzr branch lp:ubuntu/maverick .... shows Permission Denied (public key)
<techbreak> what to do ?
<pitti> techbreak: ubuntu/maverick/what?
<Riddell> ogra: [Qt-announce] Qt 4.7.2 has now been released
<techbreak> pitti, am I supposed to do more than that ?/ I just runned "bzr branch lp:ubuntu/maverick "
<cjwatson> techbreak: you can't do that
<cjwatson> you need to pick a specific package to branch
<techbreak> cjwatson, oh oh
<techbreak> cjwatson, for example ? pitti
<pitti> techbreak: lp:ubuntu/maverick/coreutils
<techbreak> pitti, oh i see :) thanks :)
<techbreak> thanks cjwatson too :)
<cjwatson> I sort of assumed that you already knew which package you were interested in :-)
<techbreak> pitti, cjwatson , bzr branch lp:ubuntu/maverick/computer-janitor
<techbreak> Permission denied (publickey).
<techbreak> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<smoser> pitti, i think i'm still seeing the error.
<pitti> techbreak: did you upload your ssh key to launchpad?
<techbreak> pitti, yes
<pitti> techbreak: (also note that this is not the canonical branch of computer-janitor, as it's got a custom one -- see Vcs-Bzr: field)
<pitti> techbreak: you could start wiht "debcheckout computer-janitor"
<smoser> looks like python-central > 0.6.11 not in the archive yet
<cjwatson> and did you run 'bzr launchpad-login YOUR-LP-USER-NAME'?
<cjwatson> Get:1 http://gb.archive.ubuntu.com/ubuntu/ natty/main python-central all 0.6.15ubuntu5 [40.9 kB]
<cjwatson> smoser: ^-
<techbreak> cjwatson, yes i logged in
<smoser> cjwatson, hm... yes.
<smoser> http://paste.ubuntu.com/573880/
<smoser> cjwatson, that log is what lead me to my obviously incorrect statement.
<cjwatson> 2011-03-01 10:48:14,315 DEBUG   : I: Retrieving python-central
<cjwatson> 2011-03-01 10:48:14,370 DEBUG   : W: Couldn't download package python-central
<cjwatson> odd
<smoser> yeah, thats the first time i've ever seen that.
<cjwatson> that might be an "apt-get update and try again shortly" kind of thing
<smoser> (this machine is sitting lan connected to the archive)
<smoser> Riddell, are you able to archive admin for me ? bug 725127
<ubottu> Launchpad bug 725127 in Ubuntu "FFE: add 'cloud-initramfs-tools' package and cloud-utils update" [Wishlist,Confirmed] https://launchpad.net/bugs/725127
<cjwatson> oh whoops
<cjwatson> multiarch dpkg makes d-i fail to build :-)
<pitti> eek
<genux> lo all, I was wondering for next week is there any parts of the of 11.04 that would require testing ? or is there going to be a testing phrase next week ?
<pitti> genux: we actually just started testing a few hours ago, for alpha-3
<pitti> http://iso.qa.ubuntu.com/qatracker/
<genux> pitti : doh!!. I have next week off work and was going to test out 11.04. when is the next test ?
<pitti> genux: we get new unity/compiz/etc releases every Thursday, so there'll still be plenty of testing :)
<pitti> genux: but for the whole CD images/installation, next round will be for beta-1, March 31st
<genux> cool :). is this a good place to "view" the development of ubuntu whilst I am at work ? to see what is happening etc.
<genux> thanks pitti
<cjwatson> slangasek: if I'm not much mistaken, the /var/lib/dpkg/info/$(dpkg --print-architecture) symlink will be missing for all new installs
<cjwatson> slangasek: it's only installed on upgrade
<genux> pitti: is the new release every Thursday, is that every Thursday throughout the year ? or for release cycles (aplha/beta)
<pitti> genux: so far they happened every week throughout natty
<pitti> and are supposed to continue to do so
<genux> pitti: thanks, shall leave part of my partition to install :)
<cjwatson> hm, brltty mismerge
<smoser> debootstrap --verbose --download-only --arch=i386 natty ./out.d http://archive.ubuntu.com/ubuntu
<techbreak> techbreak@techbreak:~/Computer/janitor$ bzr branch lp:computer-janitorPermission denied (publickey).
<techbreak> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<cjwatson> FYI I recommend not installing from current daily images
<genux> cywaston : why is that ? I just download it.
<cjwatson> genux: bug 727106
<ubottu> Launchpad bug 727106 in dpkg (Ubuntu Natty) "multiarch symlink not present in fresh installs" [Undecided,New] https://launchpad.net/bugs/727106
<genux> cjwatson : thanks. shall download the other one :)
<cjwatson> what other one?
<genux> cjwaston: the aplha 2 ? kinder assuming that it will upgrade to the latest ?
<cjwatson> alpha 2 will be fine
<cjwatson> well, probably
<genux> arh. k.
<genux> shall give it a go :)
<proti> cjwatson: bug 723482
<ubottu> Launchpad bug 723482 in mountall (Ubuntu) "system hangs on boot after updates from 2011-02-22" [High,New] https://launchpad.net/bugs/723482
<proti> Manage to reproduce the problem in a Virtualbox VM.
<proti> See comment #29.
<proti> Happens only when upgrading from maverick.
<cjwatson> ok, thanks, I will look at that today
<cjwatson> that's exactly the kind of directions I need, thank you
<genux> is it best to install from disk ? or upgrade from maverick ? for testing reasons.
<genux> or just both.
<cjwatson> genux: good testing requires a variety of scenarios
<cjwatson> so it would be foolish of us to recommend one of those :)
<genux> cjwatson: k ;). was not sure which one was at present the best solution to get up and running ? or which one was requiring more "attention" :)
<proti> cjwatson: The problem is down to linux-image, grub-pc, mountall, libc6.
<cjwatson> installing fresh from alpha-2 should be reasonably OK and is likely to be quicker than an upgrade
<genux> cjwatson: I have a problem with my present setup in that I have to alter the pci memory allocation for the linux-image to work, (alter i386.c and re-compile) so will that effect the testing ? because I would be adding into the linux-image about 5 lines extra for it to work with my setup ?
<proti> cjwatson: Problem lies in grub-pc.
<cjwatson> genux: I'm sure it would be interesting, but I can't help you :)
<cjwatson> proti: oh?  is that just by bisecting package versions?
<proti> I took a snapshoot before. And upgraded packages one by one. Rebooted between each.
<proti> Mountall ok.
<proti> Then grub-pc.
<proti> grub-pc=hang.
<genux> cjwatson: nps.. I am happy to recompile the kernel, was just wondering if I said about any issues if it would be k to report them since I would be using a none standard ubuntu linux-image
<cjwatson> proti: ok, thanks
<pitti> cjwatson, ev: are the current strings in the initial ubiquity partitioner screen supposed to stay like that?
<cjwatson> genux: that depends on the bug, I imagine
<genux> cjwatson: k thanks :)
<cjwatson> pitti: I defer to ev
<kirkland> smoser: done
<pitti> whee, the slideshow is back on amd64
<davmor2> pitti: do you have time to run a quick test?
<pitti> davmor2: of what? (currently doing amd64 desktop smoketest)
<davmor2> pitti: import a cd in banshee.  It seems to of duped every track
<davmor2> audio cd that is
<pitti> davmor2: ok, it's not that quick, though (need to install banshee, and more importantly, I need to roam the flat to find an audio CD)
<davmor2> pitti: nevermind then I'll ask someone else thanks though
<pitti> davmor2: found one
<pitti> "OpenMusic" CD from LInuxTag 2008, yummy ;)
<ogra> Riddell, bah, now thats what i call timing
<davmor2> pitti: why would you need to install banshee is it not the default anymore?
<pitti> davmor2: it is, but I like RB more (and thus don't have mono installed)
<davmor2> pitti: I just don't like banshee so will be installing RB on my full system
<pitti> banshee is too slow and too crashy, and the album view confuses me
<davmor2> pitti: oh yes,  the only thing I like is the miro built in till I found a flaw with that :)
<pitti> davmor2: how do I even do this? I don't see the audio CD anywhere in banshee
<davmor2> pitti: it appears at the bottom of the list eventually
<davmor2> under last.fm
<pitti> davmor2: aah, in "online media"
<pitti> hard to see
<davmor2> pitti: yes cause obviously a cd is online media
<davmor2> pitti: click on the cd, and the option is displayed at the top to import it
<pitti> right, running now
<zyga> hi, is there an easy way to get pbuilder "offline" during the build process? So that I can make sure it will not work by accident (blame python setuptools) because it could download a missing dependency?
<pitti> davmor2: so, as each song on this CD has a different artist, it now imports each song into a different album view
<pitti> but I don't see duplication
<davmor2> pitti: http://ubuntuone.com/p/fSj/ this is what I got
<pitti> davmor2: I don't get that one then
<davmor2> hmm I just noticed the time is ever so slightly different on each
<cjwatson> slangasek: have you thought about how dpkg-reconfigure ought to work in a multiarch world?
<geser> zyga: yes, but you have to patch pbuilder for it
<zyga> geser, can it be done with hooks or is there some ppa with a patched pbuilder?
<zyga> geser, it's more tricky than "no network" as it should be able to reach the archive first
<geser> zyga: you need a small "sandbox" program from stgraber which needs to be chained before the dpkg-buildpackage call in one of the pbuilder shell scripts, I don't know of any patched pbuilder yet (I've patched my pbuilder manually)
<debfx> zyga: you could try using iptables to filter network connections by process user id
<geser> zyga: that one http://bazaar.launchpad.net/~arkose-devel/arkose/trunk/view/head:/arkose-raw-nonetwork.c
<geser> zyga: compile it and put it into /usr/local/bin (or somewhere else)
<geser> zyga: modify /usr/lib/pbuilder/pbuilder-buildpackage at line 128: put it between the "|" and the "$CHROOTEXEC"
<geser> that should give you a pbuilder which can still use network to download build-dependencies, but not during build (network is available again in hooks)
<zyga> thanks, I'll check it out
<geser> I hope I remember correctly what I did (don't have access to my patched pbuilder right now to look it up)
<bdrung> geser: i have added Daviey to core-dev
<geser> bdrung: thanks, wanted to process it all today (was too late yesterday after the meeting)
<bdrung> i leave the rest for you ;)
<Daviey> geser, Thanks!
<ev> pitti: stay like what?
<jdstrand> smoser: re cloud-init-utils-- you still need help?
<mterry_> Is anyone else getting 404s from us.archive.ubuntu.com?
<pitti> mterry_: we have a broken master mirror (which might also be an archive server), perhaps that's the reason
<mterry_> pitti, ah probs.  non-us archive server works fine
<lool> jhunt: Hey there; I have an upstart job question: I'm starting multiple instances of a daemon which itself will start some command (a bit like inetd); currently, on stop only the daemon itselfs is killed, but not its subprocesses
<lool> jhunt: I don't know how to stop this daemon properly, so I wouldn't mind if upstart ripped the whole tree of process; I tried stopping the daemon manually by sending a kill -HUP as the upstream init script is doing, and that only kills some sub-processes (e.g. it kills a configured netcat subprocess, but not a configured vim subprocess)
<jhunt> lool: sounds like the sub-processes have forked twice/called setsid? upstart can only trace the "parent" daemon process (0-2 forks).
<jhunt> lool: what is this daemon?
<lool> jhunt: It's conmux; it's a perl script which starts processes
<lool> and shares their input/output with multiple clients; a bit like screen
<jhunt> lool: Surely if conmux is starting processes, *it* should be controlling them? Having just googled what it is, I'd say speak to apw :-)
<lool> jhunt: hehe
<lool> jhunt: Ok
<lool> jhunt: upstart sends a SIGTERM by default, right?
<apw> jhunt, yep it expects to beable to close their input and output and for that to make them go away mostly, and i think it then HUP's them
<apw> but blimey its a long time since i wrote that!
<lool> apw: with the netcat example, it will stay running if conmux gets killed; it needs an explicit kill -HUP to be able to kill netcat
<apw> i guess it would die when the next input came in and it had nowhere to put it
<apw> cirtainly it would not be unreasonable to hammer hard on the children
<apw> if it does not do so already, not illogical to catch more signals in conmux itself if needed to pass them on
<jhunt> lool: yes, it sends SIGTERM, waits 5 seconds, then if the pid is still there sends SIGKILL. This is now documented in the natty version of upstart ("man 5 init" search for "kill timeout").
<lool> apw: I didn't find where conmux listens for SIGHUP
<lool> jhunt: Thanks
<apw> lool got a source tree with the version you are using ?
<lool> jhunt: is there a way to send a HUP instead?
<lool> apw: http://test.kernel.org/releases/0.12.0/
<lool> apw: it's in the conmux subdir
<jhunt> lool: not currently.
<lool> apw: BTW, I only intend to package conmux, but this tarball contains much more; is there a direct distribution of conmux, perhaps with more up-to-date sources?
<lool> jhunt: Ok; I was mostly hoping I could tell upstart to kill the whole process tree, but I agree it's kind of the job of the daemon
<apw> lool nope, that is the place it 'lives' ...
<lool> apw: I see there's a conmux/.version file with release version information, but that doesn't match the version of autotest; do you mind if I use the version of the autotest tarball to offer a conmux package?
<lool> that is, the conmux .deb would be 0.12.0 even if conmux .version says something else
<lool> It says: conmux 1 00 00 1000
<lool> name major minor patch build; so 1.00.00 is its version
<slangasek> cjwatson: missing symlink> right, I expected that to only be for compatibility with existing installs; it doesn't hurt anything to have it there for initial installs, at least for right now
<slangasek> cjwatson: dpkg-reconfigure> not thought too hard about it, I expect buxy may have thought harder
<apw> lool, yeah there was only one official release, that was a mechanism to get legal to sign off on it to let it out ... it had to be bounded and versioned
<apw> lool, so it does not look like we do handle signals
<apw> to do so one would likely want to use a class method on Payload to run the list of payloads and pass it on to them
<lool> apw: As an upstream, could I tempt you to do that in some way?  :-)
<apw> if we were to catch SIGHUP and then essentially call mux_close on all the payloads I think that would do it
<apw> as that sends signals if we have a pid
<apw> lool it'd have to be tommorow
<lool> apw: Ok; I hve meetings until the end of the day, I might give it a try tonight and send you the patch, or if I don't I'd be happy if you tride
<lool> tried
<apw> lool as a first stab you might arrange for the DESTROY on the class Payload, to call $self->mux_close(...)
<apw> you may need to generally 'catch' SIGHUP to do like 'exit' to maek the destructors work
<proti> cjwatson: ping
<cjwatson> proti: hi
<proti> hi I got it all wrong
<cjwatson> (please don't send contentless pings)
<proti> sorry, the set of packages causing the hangs are : near alsa-utils
<cjwatson> proti: it may be easiest for me to just try the upgrade here and debug directly, at this point.  I'm in the middle of that ...
<proti> I means either linux-sound-base alsa-util libasound2 alsa-base
<proti> cjwatson: How to debug this ?
<cjwatson> I will figure it out when I get that far :)
<proti> How far are you ?
<cjwatson> doing the maverick-updates upgrade
<proti> So, after natty upgrade, do apt-get install alsa-utils
<proti> The package alsa-utils are causing the hang.
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek day 2 starting in 25 minutes in #ubuntu-classroom
<proti> cjwatson: /etc/init/alsa-restore.conf  is doing something wrong.
<cjwatson> in principle it looks fine.  could be a knock-on failure.
<cjwatson> I don't see why that should block anything else, either.
<proti> (mounted MOUNTPOINT=/usr and mounted MOUNTPOINT=/var) is the only cause I can see.
<cjwatson> but that should be fine.
<cjwatson> that just means that job won't start until those conditions are true.
<proti> How does upstart manage the *.conf files ? The fact is this file is the first in alphabetical order of the directory.
<cjwatson> man 5 init
<cjwatson> how did you determine that this file was doing something wrong?
<proti> I renamed  it to alsa-restore.disabled and then the system came back to life.
<cjwatson> let me look then please
<cjwatson> waiting for the natty upgrade now
<proti> np
<barry> is security.ubuntu.com really slow for anyone else?  updates from that server are taking a really long time, but us.archive.ubuntu.com seems fine
<jdstrand> barry: yes, it is known. it should start resolving itself soonish hopefully
<barry> jdstrand: cool, thanks
<apw> bryce_, i have some further updates for lpltk for your consideration: lp:~apw/arsenal/python-launchpadlib-toolkit-milestones-etal
<proti> barry: I confirm.
<barry> proti: thanks, see jdstrand's reply above
 * proti saw that after hitting return key.
<c2tarun> can anyone please help me with this error. http://paste.ubuntu.com/574005/
<cjwatson> proti: reproduced; debugging ...
<proti> cjwatson: go on. Not sure that 723482 is really related to mountall, neither alsa-utils.
<psusi> seb128: you marked bug #247909 as triaged for gtk.  It seems that claws has been building just fine for several releases, and the claws target was marked fix released.  Do you know if there any reason for it to still be open on gtk?  I can't tell if it was a bug in gtk that claws worked around, or if it was a bug in claws and the gtk task is invalid.
<ubottu> Error: Could not parse data returned by Launchpad: list.index(x): x not in list (https://launchpad.net/bugs/247909)
<seb128> psusi, the triaged was because someone send it to GNOME
<seb128> check the status of the upstream bug
<seb128> it's likely fine to close
<psusi> expired... ok, I'll close it then
<Riddell> NCommander: florence-applet .debs are empty, presumably that's a bug?
<nigelb> 17:14 < hiemanshu> tazz: but you forget, lifemac is the sexiest person alive on earth
<nigelb> ugh, sorry
<nigelb> wrote paste
<ogra> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze, Alpha 3 soft 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
<cjwatson> proti: my tests so far suggest that mountall is getting stuck in libudev somewhere; but I have to go away for a few hours now, so I'll resume debugging when I get back
<proti> ok, maybe a dep problem.
<proti> mountall executed before udev ??
<cjwatson> no
<cjwatson> I'll work on it in a few hours
<cjwatson> I think that guessing is unlikely to be fruitful at this point
<cjwatson> I have strace dumps to study, which are much better for directed debugging
<ogra> cnd, looking at bug 702976, it isnt clear to me if you want the patch merged or not
<ubottu> Launchpad bug 702976 in input-utils (Ubuntu) "kernel event channel protocol version has changed" [Medium,New] https://launchpad.net/bugs/702976
<cnd> ogra, I attached an entire new source package
<cnd> that's what should be uploaded
<cnd> the debdiff is informational
<proti> Don't get me wrong, I did that first.
<ogra> cnd, ok, will do
<cnd> ogra, thanks!
<proti> But stuck process and unreliable behavior proved to be hard to get a good track.
<proti> So I went to the black box test to remove some deps.
<proti> I'll be around if you need information.
<Riddell> cnd: bug 725959 seems to be caused by the xinput patch
<ubottu> Launchpad bug 725959 in qt4-x11 (Ubuntu) "libqt4 4:4.7.1-0ubuntu10, 11 and 12 produce segfault in VirtualBox (libqtgui4)" [Undecided,Confirmed] https://launchpad.net/bugs/725959
<Riddell> debfx: ^^
<cnd> Riddell, I'll take a look
<Wubbbi> Hey guys. I have got a question. I am from the mageia project and maybe you could help me/us? Did you make the current pyxfce of xfce4.8 build? It only fails here. Do you have got a patch maybe?
<Riddell> Wubbbi: remove with bug 329735
<ubottu> Launchpad bug 329735 in xfce-mcs-plugins-extra (Ubuntu) "[jaunty] Please remove MCS from the archive" [Undecided,Fix released] https://launchpad.net/bugs/329735
<Bravewolf> security.ubuntu.com seems really overloaded and/or offline. is it supposed to be round-robin?
<pitti> Bravewolf: it is, but it's still getting hammered by yesterday's security updates
<Wubbbi> Riddell: that means? pyxfce depends on mcs?
<Riddell> Wubbbi: I don't know, you'd need to ask an xfce packager, maybe people in #xubuntu know
<Wubbbi> ok thx anyway
<didrocks> ev: hey, just saw your update in the wiki
<ev> oh?
<didrocks> well wiki/lauchpad
<didrocks> ev: so now ubiquity proposes nvidia driver?
<ev> didrocks: yes.  I still need to make it change the text accordingly, but if you check the third-party software box on the prepare page it will call jockey-text -C in the target filesystem during install
<didrocks> ev: excellent! thanks a lot for that :)
<ev> but of course
<Bravewolf> pitti: ok, thanks. still wondering however why "dig" shows me only two ip addresses for this server (91.189.92.166/7), and why the load is not distributed among the mirrors carring *-security
<jdstrand> security.ubuntu.com is not mirrored
<jdstrand> well, let me put it this way
<jdstrand> sources.list has security.ubuntu.com, and mirrors are typically for archivel.ubuntu.com
<jdstrand> what is supposed to happen is that -security updates are pocket copied to -updates
<jdstrand> that didn't happen for openjdk and sun-java6
<jdstrand> that has happened now, and all but karmic/openjdk is in archive.ubuntu.com, and therefore making their way to the mirrors
<jdstrand> (karmic/openjdk is pending)
<Bravewolf> jdstrand: take a look at na.mirror.garr.it/ubuntu. it has *-security (e.g. lucid-security)
<Bravewolf> jdstrand: so apparently it seems that there are mirrors carring -security (and not security copied into updates)
<jdstrand> Bravewolf: that is because the packages in lucid-security are pocket-copied to the -updates pocket
<jdstrand> Bravewolf: but the distribution name is still lucid-security in the changelog
<jdstrand> Bravewolf: and that pocket copy is what didn't happen for openjdk, so everyone downloaded from security.ubuntu.com, not all the mirrors
<Bravewolf> jdstrand: mmmh... let me understand. what do you mean with pocket copy? because it seems that the content of -updates is different respect to -security in the GARR mirror
<jdstrand> Bravewolf: ubuntu is split up into pockets: release, -security, -proposed, -updates and -backports
<jdstrand> Bravewolf: the release pocket never changes after release
<jdstrand> Bravewolf: if you look at sources.list you see things like:
<jdstrand> deb http://archive.../ubuntu lucid
<jdstrand> deb http://archive.../ubuntu lucid-security
<jdstrand> deb http://archive.../ubuntu lucid-updates
<jdstrand> all security updates go to -security
<Bravewolf> jdstrand: right. no problems here
<jdstrand> then all those updates are supposed to by copied to the -updates pocket
<jdstrand> so everything in lucid-security should be in lucid-updates
<jdstrand> (slight white lie that you'll see in a moment)
<jdstrand> high impact bug fixes go through the SRU process
<jdstrand> those are upload to -proposed first
<jdstrand> after they are deemed to fix the bug and be safe, things from -proposed are copied to -updates
<jdstrand> so the updates pocket typically has more than what is in -security
<jdstrand> when you set up a mirror via the installer, update-manager, whatever, it is typically for only archive.ubuntu.com
<jdstrand> eg, us.archive.ubuntu.com
<jdstrand> but security.ubuntu.com is always in there
<jdstrand> this is to make sure that if a mirror fails, the security update is still available
<sebner> didrocks: Are you aware that compiz is quite crashy the last few days? If not I'll file a bug about it later :)
<jdstrand> security.ubuntu.com only has -security (it may also have release, not sure, but doesn't matter)
<jdstrand> it does not have -update though
<Bravewolf> jdstrand: right. perfect. it's clear. what is not clear is the fact that na.mirror.garr.it/ubuntu has "-security", which in turn it is supposed not to be mirrored. and this mirror has openjdk updates
<didrocks> sebner: compiz itself or the decorations?
<jdstrand> so, if the pocket copy from -security to -updates doesn't happen, the mirrors don't get the package that is in security.ubuntu.com, and everyone downloads from security.u.c
<geser> cjwatson: have you a minute to moderate my mails to u-d-a and the TB and do a quick check on the TB mails if you need any additional info (they are about PPU upload rights and a new package set)?
<Bravewolf> jdstrand: by the way I learned that having "-updates" is supposed to be safe in the long term (everythinh reach -updates in the end)
<jdstrand> Bravewolf: a mirror can mirror security.ubuntu.com. it is up to them. but there is no automation that I am aware of that changes security.ubuntu.com in sources.list to be something else
<pitti> geser, cjwatson: will moderate
<sebner> didrocks: THAT is a good question :D
<jdstrand> Bravewolf: also, when the security team uploads a package, it uses something like 'lucid-security' as the distribution name
<jdstrand> Bravewolf: so everything in the security pocket has '-security' in the distribution name
<didrocks> sebner: when it crashes, can you still change the workspaces, for instance?
<geser> pitti: thx
<didrocks> sebner: and do you still see unity?
<Bravewolf> jdstrand: yes, in fact I have security.u.c in my sources.list. The point is that since security.u.c is overloaded two guys in the italian channel suggested to me to use a mirror. And I objected that it's not safe to do that. then I came here to get more details
<jdstrand> Bravewolf: but when we pocket copy, it is a bit for bit copy, therefore copying openjdk-6 for lucid-security to the lucid updates pocket means that openjdk-6 in -updates has 'lucid-updates' as the distribution name
<jdstrand> Bravewolf: assuming you trust the mirror, it is no less safe than using that mirror for archive.ubuntu.com, assuming you realize you are always at the mercy of how quickly that mirror updates itself
<sebner> didrocks: not using unity :( but docky is still usable IIRC which means the decorations?!
<didrocks> sebner: yeah, so there are been some crashes recently, there were a compiz update yesterday, did you get it?
<didrocks> sebner: there is still one known crasher, but feel free to report it with apport, it will be duplicated if needed
<sebner> didrocks: just updated to compiz 1:0.9.4-0ubuntu3, let's see if this does some magic :)
<didrocks> sebner: you have to logout/login then
<sebner> I know :)
<didrocks> sebner: to ensure running the new decorator :)
<didrocks> sebner: keep me in touch!
<sebner> sure
 * sebner hugs didrocks :)
 * didrocks hugs sebner back
<jdstrand> err
<jdstrand> Bravewolf: I typed to fast. I meant to say:
<jdstrand> "but when we pocket copy, it is a bit for bit copy, therefore copying openjdk-6 for lucid-security to the lucid updates pocket means that openjdk-6 in -updates has 'lucid-security' as the distribution name
<cnd> Riddell, when you want to provide test packages of qt with fixes for bug reporters to test, how do you do it?
<cnd> qt has so many packages
<cnd> for this xi 2.1 change, all you technically need is to update libqtcore4 and libqtgui4, but if you update them separately you're dpkg state gets broken
<Riddell> cnd: I'd put them in a PPA
<cnd> Riddell, ok, I'll try that
<ogra> james_w, around ?`
<james_w> hi ogra
<ogra> james_w, so Daviey and i challenged UDD and were wondering what will happen now that both of us used different ways to sponsor a package
<ogra> i applied a debdiff to a package and dput'ed it while at the same time Daviey committed the same debdiff to the UDD branch
<ogra> which indeed results in differences now
<maco> daviey needs to do "bzr mark-uploaded"
<Daviey> (the problem is that they aren't the same debdiff)
<maco> oh
<ogra> right
<ogra> its the same stuff but differently formatted
<Daviey> bug #726405
<ubottu> Launchpad bug 726405 in kbarcode (Ubuntu) "package kbarcode_2.0.7-3 failed to build from source" [Undecided,Fix released] https://launchpad.net/bugs/726405
<anon^_^> any issues persisting with latest updates in update manager?
<ogra> james_w, so the question we came up with was, surely one will overrule the other, but which (teh dput upload or the bzr merge)
<micahg> if the UDD branch isn't tagged with the uploaded revision, the revision will overwrite
<anon^_^> dummy files are listed for a kernel update, images aren't showing, so those updates are not selected by default
<Daviey> I dputted, then pushed to the bzr branch once that was successful
<james_w> ogra, the package in the archive wins
<Daviey> ogra, dputted 10 mins or so before me
<micahg> Daviey: should go in the other order
<anon^_^> regarding 10.04 LTS
<ogra> james_w, sure
<Daviey> micahg, it was seconds between each other... In either case, the same situation would have happend
<ogra> james_w, but how does the UDD branch look like now
<james_w> ogra, what's the package?
<Daviey> james_w, will the package-importer uncommit my push then?
<ogra> will it revert Daviey's change or just be out of sync forever etc etc
<ogra> james_w, kbarcode
<Daviey> see the bug # above ^^
<james_w> lp:ubuntu/kbarcode still has Daviey's change, and kbarcode is in the package importer's queue
<ogra> i would expect the package in archive to rule and revert the bzr change
<ogra> but then i dont know and am just guessing
 * Daviey suspects the importer isn't that clever, but hopes he is wrong
<ogra> it *should* be that clever :)
<james_w> ogra, Daviey, the package importer just crashed, I'm getting it restarted then we can see how clever it is
<ogra> LOL
<Daviey> heh :D
<Chipzz> james_w: that would be a lot funnier if it were the retracer ;)
<pitti> does anyone have a main package ready for upload? I need a small and harmless one
<pitti> (just changed live seeds, which requires a task update)
<pitti> I could sync upower
<psusi> pitti: do you think it would be worth fixing uswsusp to integrate with plymouth, and do you think it could be then added to the desktop see for natty+1?  it seems to make hibernation faster, and if it worked with plymouth instead of slplashy, would provide a better desktop experience
<pitti> psusi: I don't know uswsusp at all, I'm afraid, so I can't tell how well it works; but sounds interesting indeed
<bryce_> apw, thanks, good to see milestone support go in.  Merged and pushed
<apw> bryce_, :)  thanks
<cr3> hi folks, is there any particular reason why /var/lib/dpkg/info now has a subdirectory for the architecture?
<cr3> as a follow up question, is there a proper way to get the path of the templates file for a given package programmatically, ideally using the debconf python package
<ogra> cr3, multiarch \o/
<cr3> ogra: and there was much rejoicing!
<cr3> ogra: where is the arch taken from? I would expect it to be taken from the package but, in this particular case, the package has architecture: all. so, is it taken from the distro, ie dpkg --print-architecture?
<james_w> Daviey, ogra: ok, it's been restarted now, and is chewing on kbarcode
 * Daviey waits with hope
<slangasek> architecture: all packages are treated as equivalent to the host arch for all intents and purposes
<ogra> james_w, so what will it do ?
<james_w> let's find out :-)
<Daviey> lol
<ogra> cr3, meet slangasek, the ,master of da multiarch ;)
<cr3> ogra: awesome, I'm in the presence of the right person to do the right thing :)
<ogra> *g*
<slangasek> cr3: the proper way to get the templates file path is with 'dpkg-query --control-path $pkg templates'
<cr3> slangasek: so, I have an install script in python that had /var/lib/dpkg/info hard coded in order to obtain the templates file for a given package. might there be an appropriate way to get that path short of /var/lib/dpkg/info/$(dpkg --print-architecture)/...?
<cr3> slangasek: thanks, you answered quicker than I could ask the question more clearly :)
<slangasek> ;)
<slangasek> note that the current architecture subdirectories are probably not sticking around after all, per followup discussions with dpkg upstream today
<slangasek> so definitely don't hardcode any architecture paths - but 'dpkg-query --control-path' is a stable interface
<james_w> Daviey, ogra: it saw that the branch didn't match the upload, and when to uncommit in the branch, replace it with an import of the upload, and then propose a merge on Launchpad to include Daviey's changes in to the next upload
<james_w> however, somewhere in the middle of that it hit a bzr bug :-(
<Daviey> james_w, it all sounded so awesome :)
<ogra> yeah
<james_w> so it worked as designed, and would have noticed the problem and dealt with it appropriately, we just need to get that fix rolled out
 * ogra comforts james_w 
<Daviey> james_w, I am honestly impressed you planned for this scenario :)
<james_w> it was going to happen one day :-)
<Daviey> heh
 * ogra expected such planning ... we have the most awesome people around ;)
<james_w> https://code.launchpad.net/~spiv/bzr/repository-user-url-false-alarm-726584-2.3/+merge/51702 if you care
<Daviey> james_w, so package-importer has access to the raw branches on bazaar.lp.net ?
<james_w> so, I'll do it by hand for now so that we don't get confusion from that branch
<james_w> yeah
<Daviey> james_w, ahhhh!
<Daviey> i just assumed it was a totally seperate entity with the same access as us
<james_w> Daviey, well, it doesn't go behind the scenes or anything, but it has write access to all Ubuntu branches
<Daviey> sometimes I wish i had uncommit access to branches :)
<ogra> you do
<ogra> you should use it, but we all do :)
<Daviey> like the feeling of, 0.05msec after typing rm -rf /
<ogra> err s/should/shouldnt/
<Daviey> so we do!  I didn't know that
<james_w> https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/kbarcode/collision/+merge/51809
<Daviey> james_w, you create it by hand?
<james_w> unfortunately I just beat the importer so Launchpad hasn't seen the new revision yet
<james_w> yeah, I just did that by hand because of the bug
<Daviey> james_w, /me Disapproves it :) ...   Out of interest, who should have been invited to review if it had of worked automagically?
<james_w> Daviey, I think no-one currently actually, it should be ~ubuntu-dev
 * james_w checks the code
<maco> is there a way to tell launchpad "when a merge request is made for an ubuntu packaging branch, email me"?
<maco> or is going to sponsor queue webpage the only way to find out?
<Daviey> james_w, I wonder if directly inviting the latest uploader, and the uploader of the one that lost the race (me), makes sense to help people identify it?
<james_w> Daviey, yeah. We don't have their LP accounts readily available at that point I don't think
<james_w> we could get the uploader, but not the pusher, as I don't think LP stores that
<micahg> maco: if it's a specific package, I think you can subscribe to the branch
<james_w> we could do email address lookup as a heuristic
<Daviey> james_w, Person.getByEmail() ?
<ogra> but you would need the adress attached to your gpg key in LP
<ogra> assuming you look for the signing person
<james_w> Daviey, yeah, but that's not 100% is it?
<james_w> Daviey, and the email address known to bzr isn't guaranteed to be known by LP either
<Daviey> I guess not... esp if people don't use DEBEMAIL in commits
<Daviey> james_w, best effort++
<micahg> warning the uploader should be sufficient, if the uploader won't follow up, I think we have bigger issues
<Daviey> james_w, launchpad *does* have a pretty good idea who uploaded (last entry in d/changelog) and the signer for a given archive package tho.
<Daviey> I suspect you knew that. :)
<james_w> yeah, and we can actually get that without email address lookup I think
<Daviey> yup
<james_w> I'm just doing the two minute thing right now, and leaving a comment for the improvements
<james_w> I'll file a bug and see if someone on the bzr team can pick it up as well
<Daviey> james_w, you are a hero!
<ogra> he is, isnt he !!!
<poolie> hi james_w
<james_w> hi poolie
<poolie> and all
<maco> micahg: im subscribed in lp to packages i maintain in debian, but subscribing to all of universe seems....time consuming
<james_w> https://code.launchpad.net/~james-w/udd/ubuntu-dev-review/+merge/51815
<micahg> maco: yeah, that wouldn't be good
<james_w> maco, there is the ubuntu-reviews mailing list
 * poolie looks
<ogra> maco, slacker !
<james_w> https://lists.ubuntu.com/archives/ubuntu-reviews/2011-March/thread.html
<james_w> which isn't exactly what it says on the tin, but will get mail about lots of merge proposals
<james_w> for subscribing to universe that would be an LP change I think
<ogra> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze, Alpha 3 soft 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:
<poolie> james_w, maco, so the basic thing is you want a kind of subscription just to packages you recently touched?
<james_w> poolie, I won't speak for maco, but that would be a useful thing to have
<james_w> poolie, but I can see a use for e.g. subscribing to everything in a package set
<poolie> maco, can you tell me more about what you'd want lp to do?
<poolie> james_w, that patch looks fine of course, though i wonder if people will think it generates too much spam
<james_w> poolie, email spam?
<poolie> yes
<poolie> but if you think it's a good incremental step that's ok with me
<poolie> shall i file a bug for the full thing?
<poolie> was maco talking specifically about mps from udd?
<james_w> poolie, as noted in the merge proposal this should only generate new email to a catch-all mailing list, except if people have opted in to specific branches
<james_w> so I don't think that will be a concern
<cjwatson> gah, if libnih made stderr line-buffered at high debug levels or something, this would be a lot easier
<poolie> isn't it by default? or does it replace the standard c behaviour?
<cjwatson> hm, stderr is unbuffered by default, but I'm definitely not seeing that heere
<cjwatson> *here
<cjwatson> this is but a yak I'm shaving, so I don't want to focus on it too much
<RoAkSoAx> sdsdf/win 3
<maco> poolie: i dont know what mps means
<maco> poolie: im talking about merge requests on launchpad for udd branches resulting in emails without manually subscribing to 15,000 packages
<maco> poolie: recently touched would be handy, yeah, but i was just thinking about a "email me for merge requests on things i can upload" checkbox, though i dont really know if lp is aware of PPUs and such
<poolie> i think it is
<poolie> _can_ upload would be interesting
<poolie> so core-dev would get mail about everything if they tick that box?
<maco> or have a list of your can-uploads and a list of existing package sets and a "select all" button
<maco> erm a list of package sets to which you have access, i mean
<maco> so you can mass-subscribe to chunks
<maco> or in core-dev's case, they could have as one of their options "main only" if they wanted
<cjwatson> ah, there, nih debug output goes to stdout not stderr
<cjwatson> that would explain the lack of buffering
<chrisccoulson> seb128, were you still having menu issues in pidgin btw?
<seb128> chrisccoulson, yes, corner case though
<seb128> chrisccoulson, if you open the dialog which lists the accounts and try to enable one which doesn't have it pwd stored
<seb128> you get a password dialog
<seb128> then close it and or enter a pwd as you want
<seb128> then go back to the buggy list
<seb128> the account menu then only lists one menu entry
#ubuntu-devel 2011-03-02
<psusi> say umm... since plymouth is now a required component of an Ubuntu system, and it conflicts with usplash, shouldn't usplash be dropped?
<BeeHock> what is the proper way to resubmit proposal to merge?
<smoser> I'm in need of some debugging help.
<smoser> uec images build succeeded on 20101228 (~ 01:00 UTC). but fails now.
<smoser> there were some changes of my doing, but I believe I've removed them as potential for cause of build failure.
<smoser> at this present time if I build with the archive pointed at archive.ubuntu.com, i will fail. but if I point at us-east-1.ec2.archive.ubuntu.com (slightly out of date), it will succeed.
<smoser> the failure occurs in a postinstall of grub-legacy-ec2. on a call to
<smoser>   db_x_loadtemplatefile /var/lib/dpkg/info/grub-legacy-ec2.templates grub
<smoser> that file does not exist in the failure scenario.
<smoser> logs at http://pastebin.com/c62P67Kn (good) and http://pastebin.com/1uWJzGuL (bad)
<smoser> between those two, the only change is the archive that is being used.
<smoser> if anyone has ideas, i could really use suggestions. i really need a uec build for alpha-3 :-(
<smoser> http://pastebin.com/RkFU5keb is a diff of manifests for failed and successful.
<broder> smoser: sounds like dpkg multiarch issues
<smoser> yeah, the debconf stuck out to me.
<broder> smoser: go, uh, hunt down whatever slangasek changed recently, and that'll probably be a good example for what you should be doing
<broder> (the multiarch stuff changed the layout of /var/lib/dpkg/info, which it really seems like you shouldn't have to interact with in the first place, honestly)
<broder> but if you really must do that, i'd look at https://launchpad.net/ubuntu/+source/ucf/3.0025+nmu1ubuntu1
<smoser> broder, well, i didn't write it. i yanked it from grub (0.97).
 * broder shrugs
<broder> in any case, looks like you can probably just make the same change
<smoser> yeah.
<smoser> thank you broder. that does look like a strong hit.
<slangasek> smoser: what version of dpkg do you have installed in this case?  /var/lib/dpkg/info/* should exist again, as of cjwatson's most recent dpkg upload
<smoser> dpkg 1.16.0~ubuntu3
<smoser> -dpkg 1.15.8.10ubuntu1
<smoser> +dpkg 1.16.0~ubuntu3
<slangasek> smoser: note that grub-legacy-ec2 should be fixed in any case to look at 'dpkg-query --control-path grub-legacy-ec2 templates' rather than hard-coding a path; but that shouldn't be an issue with current dpkg
<smoser> -GOOD-BUILD
<smoser> +BAD-BUILD
<smoser> slangasek, right. i'll fix that. that is fine.
<slangasek> smoser: ok, I see why this error is still there; fixing grub-legacy-ec2's invocation will work around it for now
<slangasek> and now to fix dpkg harder
<smoser> http://paste.ubuntu.com/574278/
<smoser> that look sane ?
<slangasek> smoser: yep
<slangasek> and sorry for the breakage :/
<smoser> it would have been caught yesterday or hours ago if the archives werent misbehaving
<smoser> it was just 5 hours ago that i could get a build to not fail on archive consistency/download.
 * slangasek nods
<smoser> slangasek, broder thank you.
 * smoser heads to bed
<smoser> theres no freeze on right now, right ? my upload will get into archive without anyone needing to allow it in. right ?
<slangasek> smoser: packages that don't need uploaded to make a3 releasable are frozen
<slangasek> so grub-legacy-ec2, you can upload :)
<smoser> ok. its uploaded.
<smoser> but no buttons have to be pushed to let it into archive, right?
<slangasek> smoser: nope, none
<pitti> Good morning
<dholbach> good morning
<Ampelbein> pitti: bug 727633 - has this something to do with your latest upload? I can't reproduce on i386 (don't have amd64).
<ubottu> Launchpad bug 727633 in udev (Ubuntu) "Failed upgrade to udev" [Undecided,New] https://launchpad.net/bugs/727633
<didrocks> good morning
<apw> cjwatson, is there a report against the archive which shows dependancy issues; i have a report of a 'partial upgrade' being reported against lucid -updates and suspect a kernel component is missing ... but only have a screenshot of update-manager to work with currently
<pitti> hi Ampelbein
<Ampelbein> pitti: hi!
<pitti> Ampelbein: it's the very bug that ubuntu3 fixes
<pitti> but it's nontrivial to pull yourself out of that swamp
<Ampelbein> pitti: ok. so it's good that it's not a new bug but bad for the reporter because he can't get out easy.
<pitti> Ampelbein: I followed up with cleanup instructions
<Ampelbein> pitti: thank you very much!
<pitti> Ampelbein: thanks for pointing out
<ion> Removing the diversion manually is quite trivial in my book. :-)
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze, Alpha 3 soft 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
<didrocks> pitti: \o/ happy piloting!
<lag> Are there any fbdev gurus out there?
<lag> Who would be kind enough to spot any problems they see in this Xorg.0.log dump: https://pastebin.linaro.org/37/
<lag> Or if there's a better channel for this?
 * dholbach hugs pitti
 * pitti hugs dholbck
<pitti> dholback
<dholbach> lag, maybe in #ubuntu-x?
<lag> dholbach: I'll try that, thanks Daniel
<dholbach> lag, how's life? :)
<lag> dholbach: Still ticking along
<lag> dholbach: :)
<lag> dholbach: How about you?
<dholbach> it's excellent :)
<apw> lag that pastebin is private anyhow
<jml> pitti: thanks!
<pitti> jml: sorry for the hassle
<lag> Sorry: http://paste.ubuntu.com/574353/
<jml> pitti: np.
<lag> dholbach: I'm pleased you're enjoying life :)
<dholbach> :-)
<lag> apw: I'm assuming that link works better?
<apw> yep
<pitti> why didn't I know about pull-lp-source before?
<pitti> it's really neat
<tumbleweed> everyone seems to say that :)
<pitti> I have chroots for lucid and hardy, so for those it's easy; but for the others this is really handy :)
<mok0> pitti, also pull-debian-source
<pitti> *nod*
<pitti> mok0: I know of that as well now, but I got too used to "dchsid apt-get source"..
<mok0> Although these two really ought to be merged: pull-source --lp, pull-source --debian
<pitti> mok0: it should default to Ubuntu dev release, and then DTRT if you specify "sid" instead of "maverick"
<cjwatson> smoser: I suspect the other thing that's happening is that you're using a sufficiently old debootstrap that it doesn't create the /var/lib/dpkg/info/ARCH -> . symlink
<proti> cjwatson: Congrats for figuring out the bug. though one.
<Daviey> pitti, These tools, and UDD, are really starting to making a local mirror pointless... :(
<pitti> Daviey: I gave up having a local mirror years ago -- I found it too much hassle to keep it up to date for little benefit
<Daviey> pitti, The only advantage i feel which is still partly valid is speed advantage on larger packages... but with faster broadband, even this is a minor gain
<Daviey> Tempted to switch to caching proxy.
<Chipzz> Daviey: except all the caching proxies are crap
<Chipzz> (apt-cacher and apt-proxy I mean)
<Daviey> Chipzz, Hmm... have you tried squid-deb-proxy?
<Chipzz> no not yet
<Chipzz> although I'm not sure I want the overhead of squid for taht
<Daviey> Chipzz, I do use apt-cacher-ng in production on hardy, and that has been pretty solid for a few years... but considering switching for local network.
<Chipzz> Daviey: maybe I should take a look again
<Chipzz> I remember trying it and not liking it (but don't recall the reason)
<Chipzz> and apt-proxy... well, meh. just meh.
<Daviey> Chipzz, One of the nice things with squid-deb-proxy is the avahi advertisement... which should mean it's picked up locally automagically.
<Chipzz> Daviey: since all the boxen I use it for are servers, that shouldn't matter
<Daviey> ^^ If you do try it, comments welcome - as we are looking to make it a core part of one of the server metapackages.
<Chipzz> if anything, I do NOT want avahi in a server environment ;)
<Chipzz> but that might just be me
<cjwatson> proti: sorry I said that it wasn't alsa-restore's fault ...
<Daviey> (infact, for Natty, it /is/ a core part of a server metapackage)
<cjwatson> was obvious once I saw it :-/
 * cjwatson still keeps a local mirror.  Given my poor bandwidth it's a real efficiency win
 * Daviey ponders.
<Chipzz> cjwatson: really? I'ld say if you're on poor bandwith, the less you have to transfer the better
<Chipzz> and since a proxy only transfers what you need, as opposed to the whole archive with a mirror..
<Chipzz> (or parts of the archive if you have your mirror script configured differently)
<soren> I suppose it's about when the time to download is spent. And whose time it is.
<Chipzz> hrmyeah
<Chipzz> if you sync during night
<Chipzz> you'll probably be asleep and not notice it
<soren> If it takes a lot of time for the system to do it automatically during the night, it's ok. If it takes cjwatson's time to wait for it to download the first time, it's less ok.
<soren> Even though the amount of time in the latter case is way less.
<Daviey> I have been tempted to do more of my development via ssh in a machine in a datacentre... faster compiling than local machine and no bandwidth issues.
 * soren too
<soren> Only problem is when I travel.
<soren> I'd hate to be stuck on an airplane and be missing something because I forgot to sync something to my laptop.
<soren> If I always use my laptop, that's not an issue.
<Daviey> soren, Not having internet access sounds like a perfect excuse for not being able to work. :)
<soren> Daviey: I find it a great excuse to actually get some work done without having to pay attention to e-mail, irc, etc.
<soren> Daviey: ...but I totally see where you're coming from.
 * soren wanders off for lunch
<cjwatson> Chipzz: what soren said.  The mirror updates at night when I'm not waiting for it.
<cjwatson> A proxy is no use for this since typically it's the first download of a given resource that I'm waiting for.
<Chipzz> cjwatson: ah well, makes sense I suppose
<jamespage> cjwatson: have you got time for a question re package version numbers and dpkg?
<soren> jamespage: Or you could just ask. People in this channel are surprisingly proficient with those things :)
<jamespage> soren: OK
<cjwatson> go ahead
<cjwatson> if my answer on -server wasn't sufficient :)
<jamespage> cjwatson: reading now
<Daviey> pitti, How often does the burndown chart cron run?
<pitti> Daviey: hourly
<Daviey> pitti, thanks
<fta2> Subject: Cron <root@xxx> start -q anacron || :
<fta2> start: Job is already running: anacron
<fta2> pitti, ^^
<c2tarun> pitti: ping
<pitti> hi c2tarun
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze, Alpha 3 soft 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> that brought the queue down from 41 to 17 \o/
<c2tarun> hi pitti :) whats an overly long changelog?
<c2tarun> pitti: I mean what could have been dropped?
<pitti> c2tarun: lines in debian/changelog shouldn't be longer than 79 characters
<pitti> c2tarun: I mean break the line
<pitti> c2tarun: not that it had too much content, of course (that was just fine)
<c2tarun> pitti: oh... got it. I'll keep in mind from next time :) Thanks
<smoser> slangasek, so i have part of my "post image fixups" (http://bazaar.launchpad.net/%7Eubuntu-on-ec2/vmbuilder/automated-ec2-builds/annotate/head%3A/vmbuilder-uec-ec2-fixes)
<smoser> in line 262, that does not seem to have taken.
<Daviey> slangasek, Is it okay to upload your staged UNRELEASED package of portmap with the addition of https://code.launchpad.net/~clint-fewbar/ubuntu/natty/portmap/stop-portmap/+merge/50047 ?
<Daviey> (ie, what were you waiting for, aswell)
<ari-tczew> pitti: man you rox
<ari-tczew> reducing the queue from 41 to 15:
<janimo> is there an easy to search DB of all ubuntu package metainfo? For example searching for certain text patterns across all debian/rules files
<ari-tczew> janimo: good question, I'd like to get that tool as well.
<ari-tczew> janimo: workaround, I was looking for changes in d/rules by searching on bazaar via launchpad.
<janimo> ari-tczew, that is a bit heavy on LP isn't it? I have not tried though. LP would be a good place to have such an index as it has all packages passing through it
<pitti> ari-tczew: thanks :)
<dholbach> pitti, good work
<ari-tczew> tsimpson: oh man, is it true? Terence Simpson probably started hacking IRC bots when he was 5 years old.
<slangasek> Daviey: yes, my portmap changes were staged because they don't justify an upload, but you can upload any time if you have occasion to
<tsimpson> ari-tczew: huh?
<ari-tczew> tsimpson: http://daniel.holba.ch/blog/?p=928
<slangasek> smoser: sorry, were you wanting me to look at those vmbuilder changes for any particular reason?
<shadeslayer> so there's a mail on the ubuntu-in mailing list asking of the Intel 82845g chip will support a hardware accelerated Unity
<smoser> um, no. i'm all sorted now.
<shadeslayer> any idea's on that?
<smoser> that dpkg-reconfigure was failing
<smoser> that will be fixed by getting a newer debootstrap on my build machine
<tsimpson> ari-tczew: ah, well the answer is "no" ;)
<ari-tczew> tsimpson: okok :P
<tumbleweed> ari-tczew: hacking on IRC bots is fun (and it's actually what finally pulled me into debian/ubuntu development) (different bots to tsimpson's, though)
<ari-tczew> tumbleweed: maybe when I got time in future, I'd try to hack something related to bots.
<cjwatson> smoser: hopefully I'll get dpkg-reconfigure fixed too over the next few days
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 starting in 25 minutes in #ubuntu-classroom
<dholbach> andreserl, can you change your nick to RoAkSoAx and join #ubuntu-classroom?
<nigelb> ahh
<mterry> Do other people see a bug where sometimes you can't click on non-Unity apps?   That they all stop responding until unity is restarted?
<highvoltage> slangasek: I think bug 727839 should've had a new bug for what you renamed the bug to (bugjacking), since they are really two seperate issues imho
<ubottu> Launchpad bug 727839 in plymouth (Ubuntu) "Plymouth dies with ABRT signal on shutdown on liveCD" [Undecided,New] https://launchpad.net/bugs/727839
<mterry> whoops, meant mine for #ubuntu-desktop
<highvoltage> slangasek: (as illustrated in the comment/screenshot I added from i386)
<slangasek> highvoltage: fair enough; though I was trying to turn this into an objective bug report instead of 'ugly'
<davmor2> kenvandine: ping I think there is a bug in " Take screenshot" 's unity behaviour.  If you select "Take a shot of the current window" from the quick menu it only ever takes shots of the app launcher :)
<kenvandine> davmor2, haha
<kenvandine> davmor2, humm... i can't reproduce that
<davmor2> kenvandine: I'll do a video and a bug so you can see.
<kenvandine> thx
<kenvandine> i suspect it is a bug where it thinks the launcher is a window
<kenvandine> it is working here, i just get the window
<kenvandine> but we have had cases where it has been confused before
<highvoltage> slangasek: indeed, thanks for that, I meant "ugly" as a technical term though instead of insulting it. I changed it to "Plymouth should display less unimportant information on shutdown", I guess it sounds somewhat better than "ugly", even though less terse
<davmor2> kenvandine: this is a fresh install from this mornings iso
<kenvandine> davmor2, yeah, please file the bug
<davmor2> will do
<slangasek> highvoltage: well, I'd like a precise report that says what information you think is unimportant; at which point I think this will probably become a wontfix issue given that plymouth has been recently changed *to* display progress information about jobs, but that'll be for others to decide
<pitti> wohoo! new landscape-client is the last hal rdepends in main; buh-bye!
<pitti> s/is/removes/
<highvoltage> slangasek: ok. I'll object a wontfix for it on the livecd since that information is undesireble for the vast majority of use cases there, but thanks for the feedback anyway
<slangasek> highvoltage: I'm not sure we have the flexibility to handle it differently on livecd than elsewhere, so we may have conflicting use cases.  I guess it's not so ugly when not using the text interface?
<davmor2> kenvandine: bug #727890
<ubottu> Launchpad bug 727890 in unity (Ubuntu) "Snapshot Quicklist for current window shoots the app launcher" [Undecided,New] https://launchpad.net/bugs/727890
<kenvandine> davmor2, thx
<davmor2> np's
<cnd> pitti, is qt on the daily iso's?
<cnd> I'm trying to use testdrive
<cnd> and I expected qt to be there already
<pitti> cnd: on Kubuntu certainly, not on Ubuntu
<cnd> pitti, ahh, ok
<cnd> thanks
<cnd> pitti, maybe I misunderstood though, isn't qt going to be on the natty ubuntu install?
<cjwatson> err - Mark's comments were about natty+1 last I checked
<pitti> cnd: no -- we are oversized enough as it is ..
<cnd> ohhh...
<cnd> I was all mistaken then :)
<pitti> on amd64 we are down to 2 languages
<pitti> yeah, natty+1 will be fun -- no idea yet how to fit Qt in addition
<zyga> barry, ping
<zyga> barry, does this smell like a python bug or is this expected good behavior?
<zyga> >>> from decimal import Decimal
<zyga> >>> Decimal(1) < 1e20
<zyga> False
<kklimonda> zyga: looks like bug to me
<zyga> yup
<zyga> my feeling as well
<zyga> it works when you do
<kklimonda> especially because
<kklimonda> In [1]: from decimal import Decimal
<kklimonda> In [2]: Decimal(1) < 1e20
<kklimonda> Out[2]: True
<zyga> >>> Decimal(1) < Decimal("%s" % 1e20)
<zyga> hm?
<kklimonda> what arch is that?
<zyga> amd64
<zyga> kklimonda, it worked for you?!
<zyga> kklimonda, this is maverick, amd64
<kklimonda> it works on natty, i386
<geser> I also get True (Py 2.7, natty, amd64)
<zyga> kklimonda, if I don't depend on implicit coertion then it also works
 * zyga checks 2.7
<kklimonda> lets see if 2.6 behaves differently
<zyga> kklimonda, it works for small values, the ones that can be converted to float
<geser> yes, 2.6 returns False for me
<kklimonda> and I'm still installing 2.6.. oh, the fsync() madness..
<zyga> kklimonda, on 2.7 maverick/amd64 it also works
<kklimonda> I'm tempted to alias both apt-get and aptitude to eatmydata ;)
<zyga> looks like 2.6 bug to me
<zyga> kklimonda, get an SSD :-)
<zyga> kklimonda, I started doing pbuilder work in ramdisk, man that's fast
<kklimonda> zyga: I did that too for some time - but then some packages didn't build because 4GB is not nearly enough ;)
<geser> zyga: looks like Decimal() can't be compared against float in Py2.6
<geser> Decimal(1) < 100 => True, Decimal(1) < 100.0 => False
<kklimonda> indeed
<kklimonda> good catch
<geser> both return True in 2.7
<zyga> geser, hmm
<zyga> yup
<zyga> ugly
<zyga> I see two bugs here though
<zyga> 1) decimal fails to compare to largish ints that cannot be converted to floats
<zyga> 2) decimal fails to compare to floats
<zyga> perhaps 2) is by design
<zyga> but 1) is bug for sure
<zyga> it should raise OverflowError or something similar
<zyga> there are some coercion rules changed in 2.7 isn't that righT?
<kklimonda> apparently
 * zyga would love to hear what barry thinks 
<zyga> is barry US or EU?
<ogra> US
<zyga> so he should be up
<ogra> if he's not travelling ;)
<cjwatson> he was around earlier today
<geser> zyga: have you a test case for 1) ?
<zyga> geser, yes, see my original example
<zyga>  Decimal(1) < 1e20
<zyga>  Decimal(1) <  Decimal("%s" % 1e20)
<zyga> first fails, second works
<geser> but that's a float (according to type)
<zyga> uh!
 * zyga is dumb
<zyga> you are right
<zyga> sorry
 * zyga calls of 1) then
<geser> the second one works as you convert it to a Decimal, and comparisan between two Decimal works
<zyga> right
<kklimonda> zyga: http://mail.python.org/pipermail/python-dev/2010-March/098437.html is on the topic.
<geser> Decimal(1) < 10**100 => True (and 10**100 is a big number)
<kklimonda> zyga: most likely it has been decided that such comparisons are good idea, implemented in 3k and then backported to 2.7..
<zyga> right, seems that way
<Daviey> Spads (and slangasek): Do you know what the verification status of SRU bug #717397... we are still getting lots of duplicate bug reports... seems somewhat urgent to get a fix out.
<ubottu> Launchpad bug 717397 in squid-deb-proxy (Ubuntu Lucid) "package squid 2.7.STABLE7-1ubuntu12.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/717397
<Daviey> erm, s/Spads/SpamapS/ - sorry Spads
<geser> zyga: just curious: did you managed to get your no-network pbuilder running?
<zyga> geser, no, still on my TODO list, I need to release the final crown jewel package before I can move on though ;/
<zyga> I'm still debugging app issues
<yofel> cnd: hi, I was told to poke you for  QETWidget::translateXI2Event crashes, I get http://paste.kde.org/6211/ in kubuntu natty a lot, can't really reliably reproduce it though (started a few days ago)
<cnd> yofel, hi, I'm working on a fix right now
<cnd> building qt as we speak
<yofel> :)
<cnd> there's a bug open about it: https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/725959
<ubottu> Ubuntu bug 725959 in qt4-x11 (Ubuntu) "libqt4 4:4.7.1-0ubuntu10, 11 and 12 produce segfault in VirtualBox (libqtgui4)" [Medium,In progress]
<slangasek> Daviey: if the latest issue is not a regression, then I guess it's verification-done
<nigelb> ogra: Lovely session :)
<ogra> thanks :)
<highvoltage> oh no! I missed it!
<ogra> highvoltage, no arms for you then :)
<highvoltage> ogra: well... the genesi smarttop is now $129 (https://www.genesi-usa.com/press/2011/2/25/) so that's very tempting :)
<ogra> buy it in â¬ its cheaper :)
<highvoltage> (or even the smartbook, considering it comes with a screen and keyboard and built-in UPS for just a little more)
 * highvoltage checks by how much (I guess shipping to canada will be more expensive from europe than US)
<highvoltage> ogra: where would I buy it in â¬? I can't find a eurostore
<ogra> highvoltage, that was a joke, its 95â¬ or $129
<highvoltage> ogra: ah, I get it (d'oh)
<bdrung> cjwatson, james_w: can you change the status to rejected for the merge proposal https://code.launchpad.net/~legolas/ubuntu/natty/php5/5.3.5/+merge/48128 ?
<james_w> bdrung, done
<james_w> any core dev should be able to do it though?
<mdeslaur> james_w: I couldn't when I tried yesterday
<bdrung> james_w: nope. only Ubuntu branches members can do it. i can only set it to "work in progress", "needs review", and "merged"
<james_w> that's not the intent, please file a bug
<james_w> if you can upload php5 you should be able to change the merge proposal
<james_w> in fact I think I've fixed this once already
<cnd> Riddell, I believe I've fixed the qt bug 725959
<ubottu> Launchpad bug 725959 in qt4-x11 (Ubuntu) "libqt4 4:4.7.1-0ubuntu10, 11 and 12 produce segfault in VirtualBox (libqtgui4)" [Medium,In progress] https://launchpad.net/bugs/725959
<bdrung> james_w: against what?
<cnd> after verification, I'll leave it up to you to decide if this warrants pushing in to ubuntu before alpha 3 release
<cnd> I'd advocate pushing it, but I don't know the full extent of the bug (such as how many applications are crashing and how many people are hitting the bug)
<james_w> bdrung, launchpad
<bdrung> james_w, ari-tczew: i filed bug #728012
<ubottu> Launchpad bug 728012 in Launchpad itself "Missing permission to reject a Ubuntu merge proposal" [Undecided,New] https://launchpad.net/bugs/728012
<james_w> thanks bdrung
<pitti> kees, jdstrand: publishing linux-ec2 and -meta for lucid to -updates and -security
<kees> pitti: great, thanks!
<pitti> sconklin: any chance you could fix your script to generate the tracking bugs to create a proper release task?
<pitti> I always need to add it by hand, and close the natty one as invalid
<sconklin> pitti: I think that's possible. We generate release tasks now in the CVE tracker bugs we create, so I don't see why not
<bjf> pitti, point me at a specific bug and i'll make the changes
<pitti> that's what I thought
<sconklin> and here's the expert . . . ;-)
<pitti> bjf: I just updated bug 725138
<ubottu> Launchpad bug 725138 in linux (Ubuntu Hardy) "linux: 2.6.24-29.87 -proposed tracker" [Undecided,New] https://launchpad.net/bugs/725138
<pitti> bjf: before it just had one floating "in progress" task and no stable release tassk
<bjf> pitti, i'll look at what you had to do and try to make the script do it
<pitti> bjf: thanks
<bjf> pitti, i was looking at that and was thinking someone was going to task me for that
<bjf> pitti, it's on my todo list
<pitti> great!
<sconklin> pitti: dapper lbm is building now and can be copied as soon as it's done
<pitti> yup, starting with hardy, and walking through the others
<sconklin> pitti: it's done, actually
<sconklin> pitti: thanks
<pitti> bjf, sconklin: do you know why bug 726786 has the wrong source package? is that hardcoded, or a bug?
<ubottu> Launchpad bug 726786 in linux (Ubuntu) "linux-ec2: 2.6.31-308.28 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/726786
 * pitti fixes to reassign to linux-ec2
<sconklin> pitti: looks like a bug
<sconklin> thanks for pointing it out
<pitti> kees, jdstrand: copied linux-lts-backport-maverick (and -meta) to -updates/-security for lucid
<kees> pitti: great, thanks!
<pitti> . o O { next time I do all this review/copy thing I'll write a script to generate the invocation of my three other scripts for all available packages.. }
<pitti> sconklin, skaet_: I replied to the kernel-sru mail, but I'm held in moderation; whoever created that list, can you please whitelist my @ubuntu address?
<sconklin> pitti: I'll fix it and moderate
<pitti> sconklin: thanks!
<pitti> sconklin: all copied, btw; and lucid -ec2 is out now, so feel free to upload to PPA
<pitti> and with that, good night everyone!
<sconklin> thianks, working on that right now
<kees> pitti: did you look at the kernel-abi-checker script I pointed you at a while ago?
<kees> pitti: it has the list of package combinations in it already
<broder> any core-devs want to mark the ubiquity merge proposal at the top of the queue to "work in progress"?
<cyphermox> !regression-alert  -- I'm hoping this was already reported, but it seems like there's an issue with loading firmware for iwlagn introduced by kernel 2.6.32-29 on lucid, see bug 727653
<ubottu> Launchpad bug 727653 in linux (Ubuntu) "initrd.img-2.6.32-29-generic breaks iwlwifi-6050" [Undecided,New] https://launchpad.net/bugs/727653
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<cyphermox> !regression-alert
<ubottu> cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<cyphermox> I'm hoping I'm not ringing bells for nothing here :/
<ScottK> JFo: ^^^
<JFo> hmmm, must have missed something
<cyphermox> JFo, bug 727653
<ubottu> Launchpad bug 727653 in linux (Ubuntu) "initrd.img-2.6.32-29-generic breaks iwlwifi-6050" [Undecided,New] https://launchpad.net/bugs/727653
<JFo> thanks cyphermox :)
<cyphermox> this user mentions not being able to load some iwlagn firmware with 2.6.32-29
<JFo> ok
<ScottK> JFo: If a package needs to be blocked or something I suspext jdstrand is the most likely available timezone wise.
 * ScottK needs to go retrieve kids from day care.
<cyphermox> huh, almost late for dinner
<kees> it's a single driver, so it almost certainly shouldn't trigger a full package block.
<kees> cyphermox: but yeah, the kernel team should see it
<apw> sconklin, bjf ^^
<cyphermox> JFo, not sure if I'm still needed, but I have to get to a dinner we organized, I'm logging back on my phone shortly
<sconklin> pitti: still handy?
<TheMuso> sconklin: Scrollback shows that he went offline a while back.
<sconklin> TheMuso: no biggie, thanks.
<apw> cyphermox, ok it seems to only affect one specific intel wifi part, and as its an update they have a previous kernel which does work, so its not world ending.  we are working with the reporter to confirm isolate the fix, but it does not seem necessary to hold the package
<cyphermox> apw, thanks for letting me know
<apw> cyphermox, thank you for the heads up
<kees> I would like to review the diff between two remote branches in bzr. bzr diff lp:... lp:... does not work.
<kees> better yet, I'd like to review the diff of a pending merge.
<RAOF> That should be available on the merge page, no?
<kees> RAOF: but it wasn't proposed for a merge.
<RAOF> Ah.  I think âbzr diff --old=lp:â¦ --new=lp:â¦â should work.
 * kees looks up --old
<kees> RAOF: ah-ha, nice! yes, that works exactly.
<sconklin> cyphermox: I've attached the firmware version 4 to the bug, and requested a test. We'll continue to look at it. In the meantime, I don't think it calls for a package block. Thanks for bringing this to our attention and helping us get a fast response on this
<cyphermox> sconklin, thx. i didn't believe it worth blocking either.
#ubuntu-devel 2011-03-03
<Daviey> Anyone from foundations around?
<nixternal> go to bed
<Daviey> nixternal, no you :)
<nixternal> i will in a bit :)
<didrocks> good morning
<dholbach> good morning
<pitti> Good morning
<pitti> sconklin-gone: we need a matching linux-ubuntu-modules for hardy
<pitti> jhunt: good morning
<jhunt> pitti: morning
<pitti> jhunt: would you like to write a short paragraph about new upstart features in alpha-3, in https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview ?
<jhunt> pitti: certainly! I'll do that today.
<pitti> jhunt: thanks; we'd like to finish the text soon
<jhunt> pitti: in which case, I'll do it now :)
<jhunt> pitti: should I add the detail to the "Ubuntu Desktop Edition" section, or do you think a new subsection in the "New Features" section is appropriate (since it affects all derivates?)
<pitti> jhunt: there's already a 3.1.3 upstart section
<jhunt> pitti: doh - where's that cup of coffee..
 * pitti collects some "known bugs" documentation, but won't touch the wiki for now
<pitti> jhunt: in fact, it doesn't actually need to be limited to a3 -- over time this page will become the full natty release notes
<jhunt> pitti: gotcha
<jhunt> pitti, cjwatson: how much detail do we want for user sessions (since we've disabled them by default)?
<pitti> jhunt: I think leave them out for now, and add them for beta-1, when they'll actually work?
<jhunt> pitti: ok. The good news is that they seem to work pretty well for me, but more testing is required.
<jhunt> pitti: wiki updated. The styling on that page might need some work - look at how the heading "Override Files" displays in the body of the page.
<pitti> jhunt: great, thanks! wow, that got quite detailled
<jhunt> pitti: feel free to dilute it if necessary - my brain is currently stuck in "man page mode" :)
<apw> jhunt, this tech overview for upstart is very good ...
<jhunt> apw: thx! (I'll pay you later... ;)
<apw> jhunt, upstart Q, where is virtual-filesystems emitted ?
<jhunt> apw: mountall.
<jhunt> apw: Here's a preview of the new upstart-events summary that'll be in natty next week - http://people.canonical.com/~jhunt/upstart/man/upstart-events.pdf
<jhunt> apw: pdf rendering isn't perfect - looks much better in a console! :-)
<apw> jhunt, awsome.  i am looking at how we might inject a fallback framebuffer load without unduly slowing boot
<apw> as having vesafb and drm loaded at the same time is causing GPU hangs, and upstream just think we are mad loading both
<apw> jhunt, nice information though ... good stuff
<apw> jhunt, now 'graphics-device-added' etc are presumably created by the udev-upstart bridge ?
<jhunt> apw: indeed
<apw> those could do with being on your new page :)
<jhunt> well, the trouble is - there are a lot of possible events there: "*-device-*". I have listed some common ones.
<seb128> pitti, we should perhaps discuss cd use here
<apw> jhunt, yeah i would prolly add just the two graphics ones as they are of interest in start sequence
<seb128> pitti, so /usr/lib/gcc won a cc1plus binary between a2 and a3 it seems
<seb128> pitti, the /usr/lib/egl dir was not in a2 and add an extra 6 as well
<seb128> pitti, those are the obvious things I see
<jhunt> apw: ok - I'll add graphics-device-added and drm-device-added. Would that cover it? See "Note K" (Tables 1 and 4) for what I have so far wrt the *-device-* issue.
<apw> jhunt, yeah there are clearly infinite numbers of actual events, but those two as they appear comonly in the most complex upstart interactions seem appropriate
<jhunt> apw: right
<pitti> seb128: seems libcairo pulls in libegl
<seb128> pitti, that's because we enabled the gl backend which is needed for wayland
<pitti> seb128: I think we could safely drop g++; for building drivers (which is the primary reason we have this), gcc should be enough?
<apw> jhunt, what sort of upstart job would i want to use to run a single modprobe
<seb128> pitti, well, do you know why we g++ got added to the cd?
<pitti> I don't know
<pitti> seb128: I think it has been there all the time, it just grew?
<jhunt> apw: not quite sure what you mean. There are existing jobs which do modprobes (gssd, autofs, cups, qemu-kvm, etc).
<seb128> pitti, seems a2 didn't have build-essential or g++
<pitti> seb128: ok, then that's new indeed
<cjwatson> if the modprobe is triggered solely by a udev event, a udev rule should be sufficient for the modprobe
<seb128> or the fact that it was missing in a2 was buggy
<cjwatson> you'd use an upstart job for that if the start conditions are more complex
<seb128> pitti, well in any case g++ and elg is most of the difference
<seb128> they add an extra 16
<apw> jhunt, i should better ask if i know which event woke a job ... as i want this job to basically start if a framebuffer appears or cold plug is complete ... but i want it to no-op itself if we woke on framebuffer
<pitti> seb128: we'll drop 2.8 MB from libreoffice-style-tango
<apw> cjwatson, yeah indeed.  this is going to me much more complex i fear
<apw> this is vesafb fallback fixup
<pitti> seb128: apparently build-essential is a new recommends, I can purge it
<seb128> pitti, I've no strong opinion, I just tried to help by having a look at what changed between a2 and a3
<seb128> works for me
<cjwatson> apw: LESS=+/UPSTART_ man 5 init
<seb128> let's try to drop it and see if it creates any issue?
<pitti> seb128: did we have dpkg-dev previously?
<seb128> pitti, no
<seb128> it's all part of what ev added with dpkg-repack to ubiquity
<pitti> aah
<seb128> https://bugs.launchpad.net/ubuntu/+source/dpkg-repack/+bug/726453
<ubottu> Ubuntu bug 726453 in dpkg-repack (Ubuntu) "[MIR] dpkg-repack" [Undecided,Fix released]
<seb128> ev: dpkg-repack is tiny but it's bringing g++ on the CD ;-)
<seb128> ok so dpkg-repacks Depends on dpkg-dev which Recommends build-essential which depends on g++
<seb128> pitti, ^
<ev> oh, I mistakenly thought that was a recommends
<pitti> right
<seb128> not sure if we can lower the recommends to a suggest
<ev> err yes
<ev> suggest
<pitti> dpkg --build needs dpkg-dev, I take it?
<pitti> seb128: dpkg-dev suggests: b-e?
<pitti> it doesn't really sound correct for a developer installing it, but then again the recommended package to install is b-e anyway
<seb128> well that's the only thing we can lower in those
<pitti> and it would certainly fix that
<seb128> that seems wrong though
<pitti> seb128: what?
<seb128> if dpkg-dev recommends build-essential there is probably a reason
<seb128> let me check
<cjwatson> I think the dpkg-dev Recommendation needs to stay TBH
<cjwatson> we already have enough confusion from users wondering why packages don't build
<cjwatson> but I'm not sure of a better solution
<cjwatson> hm, added in dpkg 1.14.16
<cjwatson> one thing here is that we had *just* got to the point where all the Ubuntu-local dpkg changes had been accepted upstream
<pitti> dpkg-dev itself is already .5 MB packaged, which we can cope with, but not b-e
<cjwatson> it would be really very irritating indeed to add another source of long-term divergence
<cjwatson> I wanted to get dpkg synced
<seb128> ev: do you really need dpkg-repack?
<pitti> would it be possible to copy /usr/bin/dpkg-buildpackage into dpkg-repack? (also hackish, I know)
<cjwatson> ick, no!
<seb128> or could you just copy what you need in ubiquity?
<pitti> seb128: you mean copy the package's files, isntead of dpkg-repack'ing it and installing it again?
<cjwatson> I don't actually understand why dpkg-repack needs dpkg-dev
<cjwatson> it doesn't, AFAICS, use it
<seb128> pitti, yeah, not sure what ubiquity was doing before dpkg-unpack started being used recently
<pitti> cjwatson: it calls dpkg-buildpackage
<pitti> cjwatson: well, it calls dpkg --build, which does AFAIK?
<cjwatson> no
<seb128> cjwatson, well, https://bugs.launchpad.net/ubuntu/+source/dpkg-repack/+bug/726453
<ubottu> Ubuntu bug 726453 in dpkg-repack (Ubuntu) "[MIR] dpkg-repack" [Undecided,Fix released]
<cjwatson> dpkg --build does not call dpkg-buildpackage, that would be infinite recursion
<cjwatson> dpkg --build is what dh_builddeb calls
<seb128> hum
<pitti> ah, it calls dpkg-deb -b, I figure (which is in dpkg)
<cjwatson> indeed
<pitti> perfect
<pitti> I went through the dpkg-repack code, and that's the only place which could potentially use
<pitti> ... dpkg-deb
<pitti> dpkg-dev, I mean
<cjwatson> likewise
<cjwatson> dpkg-repack (1.19) unstable; urgency=low
<cjwatson>   * Add missing dependency on dpkg-dev.
<cjwatson>  -- Joey Hess <joeyh@debian.org>  Fri, 20 Aug 2004 13:42:03 +0100
<cjwatson> ah, I think it may have been because it used to use 822-date
<cjwatson> that was in dpkg-dev; but that was deprecated and replaced with date -R
<cjwatson> I think that was the source of the dependency, but it's no longer relevant
<pitti> \o/
<cjwatson> pitti,seb128: ubiquity> the dpkg-repack stuff is a new feature in ubiquity
<cjwatson> it's for trying to do a neater job of installing over an existing system I believe (I haven't actually kept up, bad me)
<seb128> ok
<seb128> in any case if we can drop the depends problem solved ;-)
<cjwatson> yep
<ev> neater job of installing over an existing system> yes, the original option was buried in the advanced partitioner and only preserved files in /home.  This cycle we've pushed it to an automatic partitioning option (as probably noticed) and added the functionality to preserve the set of applications previously installed (thus apt-clone and in turn, dpkg-repack).
<Daviey> Hi, would a member of foundations mind looking at the debdiff for bug #711425 , comment 10.  Thanks.
<ubottu> Launchpad bug 711425 in sysvinit (Ubuntu) "portmap does not stop during shutdown, causing possible root fs corruption" [High,In progress] https://launchpad.net/bugs/711425
<seb128> ev: nice option ;-)
<ev> seb128: thanks, much thanks to mvo for the apt-clone code.
<seb128> pitti, so I'm not sure what to do about cairo, the only reason we turn on the gl backend (which is not a stable one) is to be able to get wayland in universe
<pitti> seb128: it's 1.5 MB packaged, I guess we'll need to leave it for now? Or can we split out the backend in cairo?
<seb128> we can't
<seb128> it's not a separate file
<seb128> pitti, it's likely bryce would not be happy if we said that wayland needs to go, he just got it in universe
<seb128> pitti, though I doubt it's really useful for any users right now
<seb128> it's rather a tech demo thing
<pitti> seb128: so at most we could build a libcairo-egl (Providing libcairo)
<seb128> it's likely people who want it will want to do work on it and will need updated builds
<pitti> but no, libraries often have versioned rdepends, so nevermind
<pitti> seb128: I think getting off g++ and b-e, and libreoffice-style-tango should already buy us quite a bit
<seb128> right
<pitti> I chopped of 20 MB worth of langpacks
<pitti> 'off'
<seb128> dropping egl will not win us an extra language pack it seems
<pitti> ghostscript also grew quite a bit, that might be worth investigating, too
<seb128> speaking of language-pakcs
<seb128> the current one is 1.5 months old
<seb128> is there any chance to get new ones in natty?
<pitti> seb128: yeah, I'm still working on fixing up the firefox langpacks
<seb128> so it's firefox blocking us?
<seb128> it's not translated anyway in natty
<seb128> can't we just do an update with firefox still broken?
<seb128> ok, lunch time
<seb128> brb
<pitti> seb128: we can, but not now, when we're still rebuilding CDs :)
<pitti> (also, we need a full export now)
<ogra> to get messages on the splash using 'plymouth message --text"..."', do i need to drop quiet from the cmdline ?
 * ogra wonders how mountall enforces that
<apw> can someone remind me the magic command which one uses in a 'packaging only' bzr branch to make it packageable as a source package
 * apw goes quietly mad trying to remember
<pitti> seb128, cjwatson: FYI, opened bug 728424 to track this, and sent a bug to Debian as well (will link once ack comes in)
<ubottu> Launchpad bug 728424 in dpkg-repack (Ubuntu Natty) "Drop dpkg-dev dependency" [High,Triaged] https://launchpad.net/bugs/728424
<cjwatson> pitti: thanks
<pitti> I can upload this after a3 if you want me to
<cjwatson> apw: bzr bd -S
<seb128> pitti, thanks
<seb128> pitti, it doesn't seem to be any hurry there, maybe wait for debian to comment
<apw> cjwatson, thanks ... no wonder i didn't remember
<cjwatson> I think it would be OK to go ahead, but either way
<pitti> seb128: it's a simple change, I'd like to do it to see where we are space-wise
<cjwatson> apw: you should be able to use that (or a variation) for any source package in bzr, packaging-only or not
<cjwatson> if that helps
<apw> cjwatson, nice
<seb128> pitti, seems safe enough to just upload as well yeah
<cjwatson> jhunt: hm, are all those upstart changes in the technical overview actually in alpha-3?  I think perhaps it would be worth commenting out ones like visualisation which aren't, for now
<janimo> fta, is there an easy way to build selected third-party modules under the chromium tree?
<janimo> without having the whole package built once
<janimo> I can probably look at the build log and copy paste the config/make equivalent bits but am wondering if the debian rules file provides some help in this regard
<jhunt> cjwatson: do you know the magic to comment out chunks? I could just remove the vis sections until next week I guess.
<cjwatson> jhunt: https://wiki.ubuntu.com/HelpOnProcessingInstructions has it
<cjwatson> (and other useful stuff)
<cjwatson> (the root of that is HelpOnEditing)
<ricotz> pitti, hello, i think gobject-introspection could be synced from experimental http://packages.qa.debian.org/g/gobject-introspection/news/20110228T205151Z.html
<jhunt> cjwatson: thx! I'd tried 3 other MoinMoin comment techniques, but they either didn't do what I wanted, or broke the parser horribly :)
<jhunt> grr - am I the only one seeing lots of server errors when editing pages on wiki.ubuntu.com?
<cjwatson> jhunt: no, it's common unfortunately; however, it's usually on redisplay *after* your changes have been committed, IME
<jhunt> cjwatson: yes, I'd noticed that after attempting to re-apply changes and getting conflicts :)
<ari-tczew> does anybody know when Robert is sponsoring today?
<pitti> ari-tczew: Robert Ancell? He's currently off for some days
<ari-tczew> pitti: I thought today is his piloting...
<ari-tczew> pitti: https://www.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com&ctz=Europe/Berlin&gsessionid=OK
<fta> janimo, not really, depends on which modules, some are buildable independently, like v8 and nacl. what do you have in mind?
<pitti> ari-tczew: yes, it wasn't a planned absence
<janimo> fta, never mind I managed to get a build
<janimo> ffmpeg. I am looking into the arm ftbfs
<fta> janimo, i know the problem and the fix, it's my fault
<fta> janimo, when i merged the codecs into the browser source package, i dropped a flag (arm_neon=0) inadvertently
<ari-tczew> pitti: OK, thanks for info,
<janimo> fta ah ok
<janimo> fta also why is armv7=0 ?
<fta> janimo, i will re-add it soon, but i need to check something else too
<janimo> was that too dropped?
<ogra> just dont set arm_neon=1 :)
<ogra> unless there is runtime detection in the code
<fta> exactly, that armv7=0 is troubling, it's enabled in the codecs and desabled in the browser, or the opposite, that's wrong
<janimo> I saw armv7=0 is set in debian/rules
<janimo> but if you are on it ok, I'll live it :)
<fta> yeah, i'm on it, but more generally, as i said in my blog post yesterday, i suck at supporting arm, by lack of h/w
<fta> can't build, can't test
<fta> there's a problem with the PIE hardening on arm leading to a crash, i can't investigate
<fta> so i disabled it :(
<janimo> fta, do you want me to enable hardening (is this the PIE part then?) and see what happens?
<fta> janimo, it was enabled for a while, but someone reported a crash. see bug 716703
<ubottu> Launchpad bug 716703 in chromium-browser (Ubuntu Natty) "chromium-browser not built PIE on ARM" [Medium,Confirmed] https://launchpad.net/bugs/716703
<didrocks> pitti: needs your lights right now, got a few minutes?
<pitti> didrocks: my lights?
<pitti> didrocks: in a bit, need to finish the alpha-3 images
<didrocks> ok, that's not translatable :)
<didrocks> pitti: sure
<didrocks> pitti: then, can you join #ubuntu-touch?
<sconklin> pitti: lucid ec2 and meta-ec2 may be copied from the PPEA to -proposed when you have time, thanks
<mvo> ev: re bug 722758 (debconf db locked in apt-clone). I like the idea of clong the debconf db, I will add code for that and (for savety) chroot into the targetdir when invoking dpkg - does that sound reaonsonable?
<ubottu> Launchpad bug 722758 in openjdk-6 (Ubuntu) "package openjdk-6-jre-headless 6b20-1.9.5-0ubuntu1~9.10.1 failed to install/upgrade: problemas de dependÃªncia - deixando desconfigurado" [Undecided,New] https://launchpad.net/bugs/722758
<ev> mvo: it does
<ev> the installer does employ debconf-copydb at the end, but only for questions that wouldn't impact packages pulled in by apt-clone, if I remember correctly
<ev> well, console-setup, but we'd want to overwrite that anyway.
<cjwatson> SpamapS: do you want to deal with the SRUs for bug 531912?
<ubottu> Launchpad bug 531912 in openssh (Ubuntu Maverick) "/etc/init.d/ssh seems to work, but actually upstart is used." [Medium,Triaged] https://launchpad.net/bugs/531912
<cjwatson> SpamapS: (and sorry for the long review delay)
<cjwatson> SpamapS: note that I applied a few tweaks on top of your merge, so you'd want to backport from lp:ubuntu/openssh
<janimo> fta, the chormium rules file were much easier to read and modify if those nested ifdefs were indented :)
<janimo> less chance to make mistakes too  I guess
<fta> janimo, well, Makefiles and indentations..
<psusi> cjwatson: got any hints on how I could try to debug that partman-auto reuse script problem?  like maybe running the scripts outside of ubiquity maybe with set -x?
<cjwatson> psusi: bug#?
<cjwatson> psusi: don't bother trying to run them outside of ubiquity
<cjwatson> you will waste your time and get confused :)
<psusi> cjwatson: bug #725408
<ubottu> Launchpad bug 725408 in partman-auto (Ubuntu) "installer hangs detecting existing partitions" [Undecided,New] https://launchpad.net/bugs/725408
<cjwatson> psusi: please attach the syslog and partman logs to the bug
<cjwatson> I can normally analyse from there
<psusi> will do.. any others?
<cjwatson> no
<SpamapS> cjwatson: ack .. I will look at doing the SRU very soon.. don't want to commit just yet though.
<cjwatson> SpamapS: np, thank you!
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 4 starting in 25 minutes in #ubuntu-classroom
<dholbach> chrisccoulson, micahg, how hard is it to fix thunderbird's click-on-a-link problem?
<chrisccoulson> dholbach, hard
<chrisccoulson> i'm going to work on it, but it's going to be a non-trivial patch
<chrisccoulson> it's basically:
<chrisccoulson> 1) Add gio support to mozilla-1.9.2
<chrisccoulson> 2) Wire it in :)
<dholbach> just put a "os.system('gnome-open %s' % link)" in there ;-P
<dholbach> chrisccoulson, and that's something nobody upstream is interested in?
<seb128> dholbach: will teach you to not sure what we ship with ubuntu ;-)
<mr_pouit> s/gnome-open/xdg-open/ at least
<chrisccoulson> i've been talking to upstream about it, it's not the sort of thing that's ever going to get fixed upstream in thunderbird 3.1
<chrisccoulson> but we will fix it in comm-central and then carry a distro-patch
<chrisccoulson> comm-central already has gio support though
<chrisccoulson> comm-1.9.2 doesn't ;)
<dholbach> mr_pouit, I was not really serious, but thanks for reminding me of xdg-open :)
<chrisccoulson> i don't think the thunderbird guys are particularly pleased with things being broken like this
<chrisccoulson> i will work on it next week, but i suspect it will be quite a substantial distro-patch to fix it
<cjwatson> dholbach: subprocess.call(['gnome-open', link]) please ;-)
<cjwatson> or in fact, probably webbrowser.open(link) ...
<dholbach> ok ok ok ok, I better shut up before I make it worse
<chrisccoulson> lol
<cjwatson> heh
<chrisccoulson> dholbach, it's also semi-broken in firefox too
<chrisccoulson> but not as bad
<ogra> pitti, are there any known issues with the WI tracker atm ?
<pitti> ogra: not known to me, anyway
<ogra> https://blueprints.launchpad.net/ubuntu/+spec/other-arm-n-handle-core-boot-files-update doesnt show up for ubuntu-armel at all
<chrisccoulson> dholbach, have you seen https://mozillalabs.com/messaging/messaging-menu/ btw?
<chrisccoulson> you might be interested, as a tbird user ;)
<seb128> we should stop shipping emails client and use web emails
<chrisccoulson> heh
<chrisccoulson> we should stop shipping everything, and just provide a console for users to install software with ;)
<nigelb> hehe
<nigelb> then we'd have big troll wars over whether emacs or vim is the default editor :P
<dholbach> chrisccoulson, awesome
<chrisccoulson> lol
<chrisccoulson> it's nice they're using launchpad too :)
<dholbach> it's not packaged yet?
<chrisccoulson> dholbach, it's not packaged yet. i'll probably do that soon though
<dholbach> nice
<pitti> ogra: there are no work item s:)
<pitti> ogra: I'm removing the empty line now, which will fix it
<pitti> ... some more green on your charts now
<ogra> hmm, it doesnt look any different than the other specs we have
<pitti> ogra: there was an empty line after "work items:', which finishes the WI paragraph
<ogra> oh
<ogra> yeah
<ogra> heh
<ogra> thats why i didnt get error mail either then
* pitti 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> a3 freeze lifted, go wild
<jelmer> broder: thanks for sponsoring, much appreciated! :)
<broder> jelmer: no problem. thanks for putting the patch together
<pitti> wow -changes@ is fun again :)
<pitti> sconklin: linux-ec2 lucid copied
<sconklin> pitti: thank you!
<ev> mvo: any preference on what the software center screenshot in the installer slideshow should show? The design team intern is updating them.
<ev> how rude of me, Rollo, the intern for the design team.
<mvo> ev: I have no preferences here
<ev> okay
<bjf> pitti, at your convenience, could the linux-firmware packages for lucid and maverick get promoted from -proposed to -updates ?
<eitch0000> hello everyone. I'm trying to cross compile iperf from source. I'm on an amd64 machine and want to compile it for a i386 machine. Can someone help me with the ./configure script?
<Daviey> Is an AA available to process SRU -proposed -> -updates for bug #717397... the duplicate reports are starting to build :(
<ubottu> Launchpad bug 717397 in squid-deb-proxy (Ubuntu Lucid) "package squid 2.7.STABLE7-1ubuntu12.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/717397
<fisch246> besides #ubuntu-bugs is there room for bite size bugs? or any other form of bug fixing?
<fisch246> hm... that question might be considered support i suppose...
<fisch246> nvm got my question answered :D
<ari-tczew> Daviey: please be patient, pitti regularry takes care about SRUs
<micahg> ari-tczew: if lots of people are affected, it's appropriate to attempt to escalate something
<chrisccoulson> is someone available to approve firefox-globalmenu in NEW? :)
<chrisccoulson> https://launchpad.net/ubuntu/+source/firefox/4.0~b12+build1+nobinonly-0ubuntu3
<chrisccoulson> perrrrrlease :)
<ari-tczew> micahg: is there any problem with SRUs? maybe I'm not up-to-date
<micahg> ari-tczew: normally not, but he said additional reports were coming in which could mean a need to push things out faster
<ari-tczew> micahg: ah, so urgent is high
<ari-tczew> how can I check which lib is needed for Objectpath::toString() ?
<Daviey> ari-tczew, see the duplicate count :)
<ari-tczew> Daviey: duplicate count?
<notch> in some changelog files i see "Automated backport upload; no source changes". What is the tool used for this?
<ari-tczew> notch: backportpackage
<notch> ari-tczew: thx
<ari-tczew> np
<micahg> ari-tczew: no, it's an AA script that currently does this for official backports, backportpackage is different
<micahg> one can use backportpackage to do something similar for oneself
<Daviey> ari-tczew, For the SRU bug i quoted, how many bugs have been marked duplicate.
<ari-tczew> Daviey: then poke pitti tomorrow
<ari-tczew> ;)
<ari-tczew> micahg: I know.
<TheMuso> @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: TheMuso
<jderose> Question: in theory the Python Gobject Introspection bindings should work with traditional bindings, shouldn't they? They used to, but as of updated today `gi.repository.WebKit` isn't playing nice with plain ol `gtk` anymore... suggestions?
#ubuntu-devel 2011-03-04
<TheMuso> Is dbus still failing in chroots for anyone else?
<TheMuso> @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:
<achiang> what's the proper shorthand to refer to a debian BTS bug in a changelog?
<StevenK> achiang: (Closes: #....)
<achiang> StevenK: hm, ok... so, LP: #.... for ubuntu bugs, and just plain ol' #.... for debian bugs?
<StevenK> Not really. (LP: #...) for Ubuntu bugs, (Closes: #...) for Debian bugs.
<achiang> StevenK: got it, thanks
<achiang> and... there we go. vim highlights the (Closes: #...) for me, similar to how it highlights (LP: #....)
<StevenK> achiang: You're welcome :-)
<achiang> computers are truly magical
 * achiang wonders how network-manager-applet builds in maverick; during link phase, i get: /bin/sed: can't read /usr/lib/libgdk_pixbuf-2.0.la: No such file or directory
<achiang> we don't ship *.la files anymore, as per #665768
<achiang> (although debian does -- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607000)
<achiang> very mysterious
<micahg> achiang: Debian policy says new ones shouldn't be added and the old ones phased out over time IIRC
<achiang> micahg: sure, i have no quarrel with policy. i'm just wondering how nm-applet physically built at all, since the libgdk-pixbuf-dev in maverick doesn't ship those files, and the maverick nm-applet seems to need them
<micahg> achiang: it was removed, readded, reremoved IIRC
<achiang> must've been.
<c2tarun> what does this mean in a Makefile LIBS=@LIBS@
<didrocks> good morning
<pitti> Good morning
<sladen> morning pitti
<dholbach> good morning
<ion> that
<janimo> Riddell, how would you prefer the armv7 atomic SMP safety patch, a separate one or merged with the thumb build fix (the latter is a detail in the former)
<Riddell> janimo: I don't think I know what you're talking about, I'm also away for the next week
<janimo> Riddell, there's a kubuntu_22_fix_armel_ftbfs or similar now in qt4-x11
<janimo> there's also a request to fix the arm atomics code in qt4, which touches (replaces) the same file that patch affects
<Riddell> kubuntu_22_thumb2_support.diff ?
<janimo> Riddell, who else can upload qt4-x11 if you're missing?
<janimo> Riddell, right
<janimo> that patch touches two lines in a file
<janimo> which a new patch would replace completely.
<janimo> well not completely but with many more changes
<Riddell> mobile folks like ogra or NCommander could upload, kubuntu folks like ScottK or apachelogger or debfx too
<Riddell> I just uploaded 4.7.2
<janimo> Riddell, saw that, I'll rebase the patch I prepared for the previous version
<janimo> Riddell, someone needs to commit to debian-git packaging before uploading to ubuntu?
<Riddell> janimo: no, although fabo is the guy to poke if you want them to pick it up
<janimo> Riddell, ok thanks, have a nice next week
<Riddell> thanks janimo
<NCommander> Riddell: what needs an upload?
<mvo> doko: apt FTBFS because doxygen-latex is in universe - we don't actually need the latex stuff in apt so I don't need a MIR. what is the best way to get apt building again?
<mvo> (and doxygen depends on doxygen-latex)
<Daviey> Riddell, Would you mind finishing an SRU mv from -proposed to -updates?  bug #717397 has had 39 duplicates and they still keep coming.
<ubottu> Launchpad bug 717397 in squid-deb-proxy (Ubuntu Lucid) "package squid 2.7.STABLE7-1ubuntu12.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/717397
<Daviey> (Or any other AA)
<mvo> if a AA could move doxygen-latex to main, that would be good for now, its just a split out from doxygen, so no harm here
<Riddell> Daviey: needs ubuntu-sru to approve
<Daviey> Riddell, I guess you wouldn't accept - "<slangasek> Daviey: if the latest issue is not a regression, then I guess it's verification-done"   :)
<nigelb> nice try :p
<cjwatson> Daviey: I'll look at it
<cjwatson> well, the code mentioned in the latest issue isn't in the updates->proposed diff
<cjwatson> so I think it's OK to track that in bug 726348
<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
<pecisk_darbs> hi people, I wanted to ask - what are Ubuntu/Canonical plans with GNOME 3 (except GNOME Shell of course, as Canonical moves forward with Unity)?
<cjwatson> Daviey: released
<pecisk_darbs> will it be available in main or universe in 11.10?
<Daviey> cjwatson, hurray!  Thanks... hopefully my inbox will thank you aswell :)
<Daviey> cjwatson, Whilst i've got you.. can you look at bug #711425... I have a debdiff on the bottom, but didn't want to upload sysvinit without talking to your team first.
<ubottu> Launchpad bug 711425 in sysvinit (Ubuntu) "portmap does not stop during shutdown, causing possible root fs corruption" [High,In progress] https://launchpad.net/bugs/711425
<Daviey> Currently a rebuild FTBFS.
<Daviey> pecisk_darbs, You might get a faster response in #ubuntu-desktop.
<ogra> Riddell, janimo, is that the fix that works around the toolchain bug ?
<cjwatson> Daviey: sure, that's fine
<cjwatson> go ahead
<janimo> ogra, no, the SMP-safety one
<ogra> ah, k
<janimo> the toolchain workaround stays until new gcc is here - I see it is in linaro 2011.3 gcc
<pecisk_darbs> Daviey, thanks ;)
<ogra> janimo, right, i thought it was that one
<Daviey> cjwatson, thanks
<Daviey> cjwatson, As it turns out, mvo uploaded the same fix an hour ago :)
<pitti> change-override.py -S -c universe hal hal-info
<pitti> go hal, and never come back *evil face* :)
<cjwatson> Daviey: heh
<ev> pitti: yay! Now lets pretend it never existed.
<rolloperson> ev
<debfx> cjwatson: are you aware of bug #728764?
<ubottu> Launchpad bug 728764 in console-setup (Ubuntu) "package keyboard-configuration 1.57ubuntu9 failed to install/upgrade: subprocess installed post-installation script returned error exit status 255" [Undecided,New] https://launchpad.net/bugs/728764
<cjwatson> debfx: thanks, will look
<ari-tczew> cjwatson: around?
<pitti> seb128: sizes of http://cdimage.ubuntu.com/daily-live/20110304/ look a lot better :)
<seb128> pitti, \o/
<pitti> mvo: are you still running the automatic upgrade tests, or is that QA now? I wonder if we can just close bug 711896, it looks like a temporary uninstallability during X.org transition?
<ubottu> Launchpad bug 711896 in update-manager (Ubuntu Natty) "Upgrade to Natty fails to install xserver-xorg-core" [Undecided,Incomplete] https://launchpad.net/bugs/711896
<mvo> pitti: I still run it, it did not show up there (this particular failure)
<pitti> mvo: ok, thanks; I'll close it
<mdz> did anyone else have nautilus and gnome-terminal crash with today's updates?
<mdz> for me, apport was upgraded in the same run, so there were no crash reports left :-/
<pitti> mdz: I did see terminal crashes during dist-upgrade (and only then); it was already reported on LP, so I didn't file another one
<pitti> not today, but a few days/weeks ago
<mdz> pitti, hmm, I installed updates yesterday morning and didn't have a problem, but when I installed updates today, I had both crash
<mdz> [175077.487871] gnome-terminal[2001] general protection ip:7f9ddc1dfcfd sp:7fff32b76770 error:0 in libgobject-2.0.so.0.2800.1[7f9ddc1ac000+4e000]
<mdz> [175082.019491] nautilus[8873]: segfault at fe82 ip 00007f5bd0773d28 sp 00007fff784ec690 error 4 in libgobject-2.0.so.0.2800.1[7f5bd0740000+4e000]
<mdz> almost simultaneously
<mdz> pitti, so most likely it's not caused by the same update
<mdz> pitti, I'm having trouble finding the bug, do you happen to have it around?
<pitti> mdz: hm, I don't remember any more in which function it crashed, I'm afraid
<seb128> pitti, what bug?
<mdz> seb128, gnome-terminal (and in my case nautilus) crashing while installing updates
<pitti> seb128: terminals crashing during dist-upgrade
<seb128> urg
<seb128> mdz, pitti: do you have a stacktrace?
<mdz> seb128, I don't. apport was being upgraded at the same time, so it was turned off :-(
<seb128> hum
<seb128> upgrading apport turns it off?
<pitti> seb128: dh_installnit stops/starts during dist-upgrade
<pitti> seb128: it was already reported on LP, and I forgot the signature, sorry
<seb128> ok
<pitti> seb128: I recently looked at bug 718098
<ubottu> Launchpad bug 718098 in nautilus (Ubuntu) "nautilus crashed with SIGSEGV in g_str_hash()" [Medium,Fix released] https://launchpad.net/bugs/718098
<pitti> which got fixed recently
<seb128> no worry, I was rather curious
<pitti> could have been that, but not sure
<scott-upstairs> ScottK, ping
<pitti> argh, silly me, I was looking at gnome-terminal
<pitti> seb128, mdz: I got bug 721915
<ubottu> Launchpad bug 721915 in libdbusmenu (Ubuntu) "gnome-terminal crashed with SIGSEGV in g_type_check_instance_cast()" [Medium,Confirmed] https://launchpad.net/bugs/721915
<pitti> definitively, I confirmed it
<ScottK> scott-upstairs: Pong
<scott-upstairs> ScottK, we spoke several weeks ago backporting ubuntu studio applications and wanted to follow up with a few questions
<seb128> pitti, is that still happening?
<scott-upstairs> originally i had already intended to start but was delayed
<ScottK> OK
<pitti> seb128: I got several crashes during upgrade in the last week or two; didn't see it in this week though, I think
<seb128> we got pretty much all libdbusmenu known crashers fixed for the a3 image
<seb128> bug some of the fixes landed only tuesday this week
<seb128> but if you still have issues on current versions let us know
<mdz> ah, I've experienced similar crashes as in bug 721915 but hadn't noticed it being correlated with installing updates
<ubottu> Launchpad bug 721915 in libdbusmenu (Ubuntu) "gnome-terminal crashed with SIGSEGV in g_type_check_instance_cast()" [Medium,Confirmed] https://launchpad.net/bugs/721915
<pitti> seb128: above bug is still open
<seb128> chrisccoulson fixed it I think
<scott-upstairs> ScottK, in working with luke i usually built stuff in ppa with a ppa version number (e.g. -1ubuntu1~ppa1) and luke corrected it when pushing to the repos
<scott-upstairs> ScottK, i want to make this closer to what is expect so...
<seb128> it's just that sometimes launchpad cleaning is not done
<seb128> chrisccoulson, ^
<scott-upstairs> ScottK, i need to build in ppa for others to test but i was going to update the changelog with 'dch -i'
<pitti> seb128: so I guess mdz still had an older libdbusmenu running at the time of the upgrade?
<scott-upstairs> ScottK, will this be acceptable as a version number or would you prefer something else?
<mdz> pitti, that's possible
<seb128> well in any case if anyone get libdbusmenu issues with current version let us know
<ScottK> scott-upstairs: If the thing you want to backport is (for example) 1.2.0-1ubuntu1 it will be backported to maverick as 1.2.0-1ubuntu1~maverick1.  You should put it in the PPA as 1.2.0-1ubuntu1~maverick1~ppa1 so that people can upgrade to the proper backport once it's done.
<ScottK> You can do this with dch -bv1.2.0-1ubuntu1~maverick1~ppa1
<scott-upstairs> ScottK, oustanding!  the plan again is for me to build in ppa, two others to test and report in bug report, and i will include a debdiff to the report
<scott-upstairs> ScottK, i should start either today or during this weekend :)
<ScottK> scott-upstairs: OK.  One other tester is sufficient.  Two doesn't hurt though.
<scott-upstairs> ScottK, even better :)  thank you
<smoser> anyone locale knowledgeable here ?
<smoser> i am completely not
<smoser> after installing something like 'language-pack-fr language-pack-gnome-fr'
<smoser> is there anything else i have to do?  my goal is to get functional french gnome-desktop.
<pitti> smoser: that should work
<pitti> that'll take care of creating the necessary locales, then you just need to pick the language in gdm
<smoser> do i need to run locale-gen ?
<pitti> smoser: no, it should happen autoamtically
<pitti> after installation, locale -a should have the French ones
<smoser> ok.
<hallyn_> interesting - I just did 'debcommit -r -R --changelog=changelog', and ended up with
<hallyn_> committer: Serge Hallyn <serge@peq>
<hallyn_> even though my ubuntu.com address is in both the changelog and $DEBEMAIL
<mvo> doko: apt FTBFS because doxygen-latex is in universe - we don't actually need the latex stuff in apt so I don't need a MIR. what is the best way to get apt building again? does a archive-admin need to move it to main?
<doko> mvo: no, should be main. I thought I had accepted it as such
<mvo> doko: rmadison still tells me universe, does it take a while to propergate?
<cjwatson> it says universe on the master archive too
<doko> just promoted
<mvo> cool, thanks
<doko> mvo: so in about 90min
<dholbach> Last day of https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 15 minutes in #ubuntu-classroom
<nemo> http://m8y.org/tmp/temp.txt - worth a bug?
<ev> mvo: http://bazaar.launchpad.net/~mvo/+junk/apt-clone/revision/21 - couldn't you do that with fakechroot, to avoid the root dependency?  Just a thought, if it's fine as uid 0 with you, it doesn't bother me one bit :)
<mvo> ev: excellent idea, let me try that
<ev> cool
<hallyn> mvo: I pushed a new commit to lp:~vmbuilder-dev/vmbuilder/packaging.  Is there anything else I need to do to make a build happen?  (it has the upstream bzr commit id in it, ...)
<hallyn> mvo: nm, i was thinking the buidl would get automatically triggered, but i recon i need to build a src package and dput it
<mdz> hallyn, yes, eventually we want that to trigger a build but we're not quite there yet
<mvo> hallyn: bzr-buildpackage -S in the meantime :)
<mdz> hallyn, you want bzr builddeb
<mdz> mvo, or that, bzr builddeb is shorter :-)
<mvo> mdz: heh :) bzr bd trumps all!
<mdz> mvo, ah! didn't know about that :-)
<mvo> mdz: a bit too terse for my taste. I guess i use bzr-buildpackage because it allows bzr-<tab>
<hallyn> mdz: mvo: thanks :)
<mvo> yw!
<hallyn> I'm never quite sure about the subtle differences between aliases, so I went ahead with 'bzr-buildpackage -S' this time
<mdz> bdmurray, I was thinking of writing a script to semi-automatically fix the bugpattern tags on bugs for which bugpatterns exist. or is that something you have already?
<bdmurray> mdz: no that is not but it sounds useful
<bdmurray> @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
<mdz> bdmurray, do you see any reason for https://bugs.launchpad.net/ubuntu/+source/desktopcouch/+bug/451767 to be private?
<ubottu> Error: Bug 451767 is private
<mdz> I think it's a mistake
<ari-tczew> is there anyone who is familiar with udev?
<Ampelbein> ari-tczew: there sure is anyone.
<ari-tczew> Ampelbein: you?
<Ampelbein> ari-tczew: unless you ask the question you have, I don't know if I can help.
<ari-tczew> if Debian has blocked dh_installudev in d/rules and we have in delta changes related to udev, should do I enable dh_installudev in d/rules?
<nigelb> kirkland: ping, re:lightning talks
<nigelb> stgraber: ping, you around?
<Ampelbein> ari-tczew: you only need dh_installudev if you have a udev rule file to install. what package are you looking at?
<ari-tczew> Ampelbein: sane-backends-extras
<mdeslaur> c2tarun: fyi, last time you merged sbuild, you appear to have dropped a whole revision from it
<nigelb> highvolt1ge: hey, you around?
<mdeslaur> c2tarun: ie: 0.60.8-1ubuntu3
<kees> c2tarun: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/sbuild/natty/revision/39#debian/changelog
<nigelb> ok, does anyone have a way of getting to stgraber and kirkland? phone number perhaps?
 * nigelb prays and quickly sends an email
<Ampelbein> ari-tczew: in that package, the debian way of not installing the empty udev rule seems ok and as long as you don't add devices you don't need to install the rule file. But there should be some documentation for the enduser to have an easy way of adding devices
<cody-somerville> nigelb, Sent kirkland a text message for you.
<stgraber> nigelb: yep
<stgraber> nigelb: what's up ?
<nigelb> cody-somerville: thank you!
<ari-tczew> mdeslaur: you shall send grievances to sponsor as well
<nigelb> stgraber: lightning talks at UDW :)
<stgraber> nigelb: yep, in 7 minutes right ?
<nigelb> stgraber: could you join #ubuntu-classroom-backstage so I can coordinate the show better? :)
<nigelb> stgraber: yup, 7 and a few more
<nigelb> I'll go in order
<mdeslaur> ari-tczew: ah, yes, good idea
<nigelb> cody-somerville: I owe you :)
<ari-tczew> Ampelbein: so if user wants to add device, he has to change d/rules and rebuild package?
<c2tarun> mdeslaur: ping
<mdeslaur> c2tarun: yes6
<Ampelbein> ari-tczew: no, he has to create an udev rule
<c2tarun> mdeslaur: what do you mean by revision?
<ari-tczew> Ampelbein: if we keep enabled dh_installudev, does still user need to create an udev rule?
<mdeslaur> c2tarun: 0.60.8-1ubuntu3 was already in the archive, and you did a merge, but started with 0.60.8-1ubuntu2
<ari-tczew> c2tarun: 0.60.8-1ubuntu3 <- that's Ubuntu revision of sbuild package.
<Ampelbein> ari-tczew: no, then he only has to enter device id in the rulefile
<ari-tczew> Ampelbein: It looks like Ubuntu is very problematic system for common user.
<c2tarun> I am extremely sorry for that, but I can't merge by myself, I mean I dont have merging rights. Anyway thanks for telling :) I'll keep that in mind from next time. What can I do about it now?
<Ampelbein> ari-tczew: not really. the cases where a script has to be run for a hardware device to work are rather rare.
<Ampelbein> ari-tczew: in most cases it should work out of the box
<ari-tczew> Ampelbein: Yep, I just wanted to write about out of the box.
<ari-tczew> Ampelbein: Anyway, I'll stick with Debian. Thanks! ;-)
<mdeslaur> c2tarun: nothing, I have fixed it. Just make sure that your merge requests are against the current package. Your sponsor should have caught that, but apparently didn't.
<mdeslaur> c2tarun: I just wanted to let you know so you know to look for that in the future.
<c2tarun> mdeslaur: I am very sorry about that mistake, I am new and the time I have asked for that merge I might be a bit confuse, but  I have a pretty good idea how thing works now, Thanks a lot for telling, I'll keep that in mind
<highvolt1ge> nigelb: yup
<mdeslaur> c2tarun: it's ok :)
<nigelb> highvolt1ge: I wanted to get to stg raber, but found him :D
<highvolt1ge> nigelb: yeah sorry I guess I should've caught up with backlog before answering :)
<nigelb> highvoltage: heh, no no.  Thanks for the pong :)
<ari-tczew> mdeslaur: don't you merge sbuild with Debian?
<mdeslaur> ari-tczew: what do you mean?
<ari-tczew> mdeslaur: There is newer version in Debian unstable.
<mdeslaur> ari-tczew: what's your point?
<ari-tczew> mdeslaur: Merge with Debian unstable. I thought that you're going to merge with Debian unstable.
<mdeslaur> ari-tczew: no, I just added back a ubuntu-specific change that got left out during the last merge
<ari-tczew> mdeslaur: I know why c2tarun has forgot about *ubuntu3 changes.
<mdeslaur> ari-tczew: why
<ari-tczew> mdeslaur: c2tarun used Merge-o-Matic for merge. ubuntu3 was uploaded by kees 17th Feb, but last MoM update was 15th Feb. So merge delivered by MoM bases on ubuntu2.
<ari-tczew> mdeslaur: look https://lists.ubuntu.com/archives/ubuntu-devel/2011-March/032627.html
<mdeslaur> ari-tczew: yes, and either he or his sponsor should have noticed that before uploading
<ari-tczew> mdeslaur: probably sponsor based on MoM as well.
<kees> a proper debdiff between what was in the archive (or bzr tree) vs the pending upload should have caught that.
<mdeslaur> Don't we usually turn MoM off after feature freeze?
<ari-tczew> kees: Well, I understand that contributor and his sponsor (developer) should be more careful, but if you would work day-to-day with MoM, you would trust it, so I would like to forget they as human error.
<ari-tczew> mdeslaur: why?
<ScottK> mdeslaur: Canonical used to do that, but that hasn't been the intent for some time.  Merges can be bug fix, so it makes sense to keep it running.
<kees> ari-tczew: sure, it's human error. however, doing good checks before upload reduces those chances of error.
<mdeslaur> ScottK: yeah, that makes sense
<ari-tczew> ScottK: +1, I mentioned it on lists.
<GunnarHj> bdmurray: Hi Brian, do you possibly have time to help with a couple of uploads to lucid-backports and maverick-backports? It's bug 719815.
<ubottu> Launchpad bug 719815 in maverick-backports "Please backport gdm and language-selector to Lucid and Maverick" [Wishlist,In progress] https://launchpad.net/bugs/719815
<bdmurray> GunnarHj: I'll take a look
<bdmurray> GunnarHj: actually I don't have upload rights for gdm.  Sorry!
<GunnarHj> bdmurray: Ok, I see.
<bdmurray> GunnarHj: you might check with micahg or NCommander
<GunnarHj> bdmurray: Thanks for the tips; will do.
<bdmurray> GunnarHj: Either of them are likely to be around now. I'd htink.
<GunnarHj> NCommander: Hi Michael, looking for somebody with gdm upload rights. Do you possibly have time to help with a couple of backports uploads? It's bug 719815.
<ubottu> Launchpad bug 719815 in maverick-backports "Please backport gdm and language-selector to Lucid and Maverick" [Wishlist,In progress] https://launchpad.net/bugs/719815
<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:
<cnd> stgraber, one of the packages in the utouch package set is libgrip, which isn't in universe yet
<cnd> it's now ready to be uploaded
<cnd> am I able to help out with this initial upload?
<cnd> or does that require a motu?
<cnd> bdrung, cody-somerville ^^?
<broder_> cnd: the last comment on the bug was that it looks like it needs an FFe
<cnd> broder_, yeah, we're working on that
<cnd> will have that done shortly
<broder> cnd: cool. i don't know how the lp permissions work in this case, but i'm happy to take your word that it's ready to be sponsored as someone who has permissions on that set if you can't upload it
<cnd> broder, ok
<cnd> I suppose it probably doesn't hurt for me to try to dput it when the time comes
<cnd> worst that should happen is a reject
<bdmurray> @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
 * ari-tczew got sponsors overview less to 6.
<cyphermox> ari-tczew, would you mind looking at my merge again, please?
<ari-tczew> cyphermox: yes
<cyphermox> ari-tczew, thanks
<stgraber> cnd: what's your LP login ? (just to check you upload acls)
<cnd> stgraber, chasedouglas
<ari-tczew> pitti: could you take a look on bug 729352 as well?
<ubottu> Launchpad bug 729352 in sane-backends-extras (Ubuntu) "[FFe] Merge sane-backends-extras 1.0.22.1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/729352
<cnd> stgraber, are the acls publicly viewable?
<ari-tczew> cyphermox: looks fine. however, lack of time for sponsor it today. it will go tomorrow.
<cyphermox> ari-tczew, np, thanks a bunch
#ubuntu-devel 2011-03-05
<slangasek> pitti: would there be a problem with me uploading gtk+2.0 tonight?  you and I both have staged changes in bzr now, and I'd like to get mine to the archive :)
<psusi> TheMuso, ping
 * c2tarun don't miss me too much ;) â¥
 * c2tarun is back.
<ion> eh
<hyperair> so the launchpad bug acronym is LP:, and bugzilla.gnome.org is BGO, so is code.google.com CGC?
<tumbleweed> hyperair: aren't google code bug numbers project-specific?
<hyperair> oh whoops
<hyperair> you're right.
<petn-randall> Hello, I'm looking for what's needed to get ureadahead working with the vanilla kernel. To my knowledge it needs a kernel patch, but I can't find it on the launchpad page of ureadahead or the usual documentation. Can someone give me any pointers?
<hyperair> petn-randall: if you download the source tarball, it's there.
<hyperair> petn-randall: if you clone the zen-kernel git tree it's there in the ureadahead branch
<petn-randall> hyperair: The source tarball of ureadahead? Yeah, I've seen the patch, but it has too much fuzz on recent kernels. I'll try the zen-kernel git tree, thanks.
<hyperair> petn-randall: if you like, i can export the patch so you don't need to clone the entire tree
<hyperair> zen-kernel's git is pretty slow
<petn-randall> hyperair: that would be great, thanks
<hyperair> http://paste.debian.net/109639/
<hyperair> petn-randall: ^ that's it
<petn-randall> hyperair: Hmm ... it has too much fuzz against linus' tree. I'll have to patch it in by hand if nobody has done that yet.
<hyperair> petn-randall: really? i thought it worked.
<hyperair> lemme check
<hyperair> my kernel's 2.6.37 and has the patch applied
<hyperair> petn-randall: oh sorry i think i generated the wrong patch
<hyperair> petn-randall: http://paste.debian.net/109642/
<petn-randall> hyperair: awesome. It works against the dev tree of 2.6.38+. Thanks!
<hyperair> =)
<Haegin> hi, would the retarded behaviour of rubygems installing to /var/lib/gems (which requires root) and then making the installed apps which are symlinked in /usr/bin only readable by the owner (which is, of course, root) be considered a bug?
<Chipzz> Haegin: I would call the retarded behaviour of the ruby community as a whole a bug :P
<Chipzz> Haegin: but I guess it depends wether you're talking about the packaged version of rubygems or not
<Ampelbein> Haegin: there is debian bug 585838 but it has no further activity
<ubottu> Debian bug 585838 in rubygems1.8 "rubygems1.8: writes gems only readable by root" [Normal,Open] http://bugs.debian.org/585838
<Haegin> Chipzz: true, and yes, it's just the default rubygems with ubuntu that I'm using
<stefwal1> QUESTION:I'm using ubuntu maverick meerkat and python 2.6  I am totally new to debugging and wanted to test something out.  in my directory  /usr/lib/python2.6/dist-packages/desktopcouch/records I had a link to a server.py file. Problem is I deleted de link. Can anyone give me the location to where the link was pointing??
<beuno> stefwal1, I dont' have that dir, but desktop couch lives here for me: /usr/share/pyshared/desktopcouch/
<beuno> and here, apparently: /usr/lib/pymodules/python2.6/desktopcouch/
<beuno> which just points to /usr/share/pyshared/desktopcouch/
<stefwal1> beuno: I think you saved my day.
<beuno> good, I like easy wins  :)
<stefwal1> QUESTION: book A byte of python from swaroop ch. In this book, there's written that import sys looks for a file called sys.py, how comes I don't find that file anywhere?
<Chipzz> stefwal1: this is not the channel for such question (cfr topic)
<Chipzz> stefwal1: and the answer to your question is likely that since sys is a wrapper around libc functions, the module is a .so instead of normal python code
<stefwal1> Chipzz: thanks for the answer and sorry for the inconvenience.
<aroman> hey, I'm trying to run `debuild -S -sa`, and it fails after a little bit saying that my secret key is not available. Why is this?
<arand> aroman: Do you have your key in ~/.gnupg/ ?
<aroman> arand: I think so, what file would I be looking for there?
<Ampelbein> aroman: and the emailadress in the changelog must match one of the IDs of your key
<Ampelbein> aroman: 'gpg --list-secret-keys'
<aroman> wow
<aroman> guess what, my name is actually "Avi Romanoff (Final PGP key)"
<aroman> and it won't work unless I use exactly that string as my name :O
<aroman> is there any way to change that to remove the stuff in the parenthesis without breaking things?
<Ampelbein> aroman: you can use '-k KEYID' as argument
<aroman> Ampelbein: what would that do?
<aroman> the original command does work now, i just have to type in that silly name
<Ampelbein> aroman: it gives debsign (called by debuild) the info on what key to use instead of comparing name/adress string
<aroman> ahh
<aroman> so then I could leave my name in `changelog` as I want?
<Ampelbein> aroman: yeah
<Ampelbein> aroman: you could also add a new user id to your key via seahorse (graphical) or gpg --edit-key KEYID
<aroman> Ampelbein: right, and would that break anything that I've already signed with the old name with?
<Ampelbein> aroman: no
<aroman> alright then I think i'll do that
<aroman> Ampelbein: alright, I added the new user id to seahorse, and it worked great. thanks a bunch! :)
<aroman> the new elementary-wallpapers just finished building :D
<dom0do> I read most of the Developers Week logs, and I just noticed a typo in a package description. How can I report this to Debian?
<Ampelbein> dom0do: if there is a patch already in ubuntu, use 'submittodebian' from ubuntu-dev-tools
<Ampelbein> dom0do: if there is no patch, you can use reportbug.
<dom0do> Ampelbein: so I shouldn't report upstream first? okie
<Ampelbein> dom0do: well, that depends. if there is no ubuntu changes yet, it isn't worth it to introduce a change just for a typo.
#ubuntu-devel 2011-03-06
<kais58> is there any further support planned for the mobility HD5470 in the near future?
<stefanlsd> trying to install natty alpha 3 and overwrite partitions, partman says refusing to create as its mounted, umount says cant umount: invalid argument. this a known bug?
<mrintegrity> how do you remove a ppa when ppa-purge doesn't work?
<mrintegrity> nm
<aroman> how long does it take for users to get upgrades visible when changing a package in a PPA?
<Ampelbein> aroman: usually as soon as the binary packages are published
<aroman> Ampelbein: I actually figured out why it wasn't showing; i published it to Lucid and I'm on maverick :/
<aroman> is there any better way of adding that to maverick too other than repacking/uploading?
<Ampelbein> aroman: you can use the copy packages feature in the ppa
<aroman> oh wow
<aroman> yeah that's exactly what I want, thanks :P
<belak> I've been trying to change a few things in ubiquity and I was wondering how I can change the text of the english language for the install? I'm helping with an ubuntu derivitive and we'd like it to say Thank you for installing X in stead of Ubuntu at the end of the install in the box that asks you to reboot. I found the file in source, debian/ubiquity.templates. but how would I go about replacing the default?
<ScottK> That's not really on topic here since this channel is about development of Ubuntu.  You might have more luck, in any case, in #ubuntu-installer.
<belak> Thanks, didn't know about that channel
<belak> Just figured this would be better than #ubuntu
<heere> Hi, this question may not be appropriate for the development team, but I am not getting much support from the help channel.
<heere> I am trying to boot an old install of 10.4, but it is segfaulting on init in ld-2.11.1.so
<heere> how can i modify the init to use the latest version of this .so
<heere> ?
<XiX> hello
<XiX> can someone explain why the fuck zeitgeist is automatically installed and enabled on ubuntu karmic + ?
<XiX> its an invasion of privacy
<kklimonda> !ohmy
<ubottu> Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
<seiflotfy_> XiX, how is it an invasion of privacy
<seiflotfy_> ur info is not being sent anywhere
<XiX> im offended that a desktop activity logging program would be automatically installed
<seiflotfy_> it is used by other applications to provde you with better experience
<XiX> and active
<seiflotfy_> then deinstall it
<seiflotfy_> u do want better search results dont you
<XiX> i did, but im pretty sure most typical ubuntu users dont even know it exists
<seiflotfy_> how is it invading privacy
<seiflotfy_> i mean firefox logs your history
<seiflotfy_> and pidgin stores your password in a plain text file
<seiflotfy_> zeitgeist logs activities to make menus more adaptive
<seiflotfy_> etc.
<seiflotfy_> and this info is not sent out anywhere
<XiX> *Rejection of Zeitgeist by GNOME. from Wikipedia: âZeitgeist is a service which logs the usersâs activities and events, anywhere from files opened to websites visited and conversations[.
<XiX> how is it NOT an invasion of privacy?
<seiflotfy_> because its not sending it anywhere
<seiflotfy_> its for your own usage
<seiflotfy_> nobody knows about your zeitgeist logging
<seiflotfy_> its for oyur computer only
<seiflotfy_> just like firefox history
<XiX> firefox atleast gives you the option to delete history
<seiflotfy_> so does zeitgeist
<XiX> sure
<XiX> lets just open up bash
<XiX> and shred activity.sqlite
<seiflotfy_> or use GNOME Activity Journal
<m4n1sh> XiX: rm ~/.local/share/zeitgeist/activity.sqlite
<seiflotfy_> and delete stuff you dont want other to see
<seiflotfy_> :)
<m4n1sh> XiX: even stock gnome logs your recently opened files
<XiX> i am aware manish, and you should know rm doesnt delete data effectively
<m4n1sh> in recently_used.xbel I think
<m4n1sh> and windows also
<m4n1sh> and bash also
<m4n1sh> in .bash_history
<seiflotfy_> XiX zeitgeist basically gets most of its info at the moment form gtk.recentlyused
<XiX> ok
<m4n1sh> yes
<seiflotfy_> we just store them in a more convinient way
<XiX> i think typical users would be OK with those histories
<XiX> but given the option
<XiX> how many users would accept
<m4n1sh> there is a fine line between privacy and usability, confusion is bound to happen
<XiX> zeitgeist logging activities, events, files opened, websites viewed, and conversations
<m4n1sh> if there is no logging or history remembering then it makes your experience of desktop even worse
<m4n1sh> websites opened logging is not enabled by defauly
<seiflotfy_> XiX look at how many ppl like using docky + zeitgeist
<m4n1sh> XiX: that browser plugin is not even in ubuntu till Maverick
<seiflotfy_> XiX, you need to allow firefox to send info to zeitgeist
<m4n1sh> conversations are also not logged
<m4n1sh> till now
<m4n1sh> you need plugins which need to be installed explicitly
<XiX> and thats getting better how?
<m4n1sh> XiX: what getting better how? context?
<XiX> <m4n1sh> XiX: that browser plugin is not even in ubuntu till Maverick
<m4n1sh> it is not packaged in ubuntu till maverick
<m4n1sh> it is there in natty and onwards
<m4n1sh> so there is no chance that it can be enabled by defaulty
<seiflotfy_> u need to install the plugin urself for the logging to happen
<seiflotfy_> and it is not enabled by default
<m4n1sh> out of box logging is very minimal
<seiflotfy_> the only thing enabled by default is logging ur "gtk.recentlyused"
<m4n1sh> only those which are already logged by gtk.recentlyused
<seiflotfy_> which is done by gtk anyhow
<m4n1sh> same thing seiflotfy_ :)
<seiflotfy_> we just avoid overwriting info
<seiflotfy_> yeah
<seiflotfy_> lol
<XiX> ok
<XiX> so i am in activity.sqlite
<XiX> correct
<m4n1sh> yes
<seiflotfy_> yeah
<XiX> why does it reference http://zeitgeist-project.com/ontologies/2010/01/27/zg#UserActivity often
<m4n1sh> the default out of box logging only gets events from gtk.recentlyused
<seiflotfy_> XiX its called ontology
<m4n1sh> and anything extra which needs to be logged requires plugin
<seiflotfy_> to define if the event was a user activity or a notification
<seiflotfy_> user activity is then defined by  http://zeitgeist-project.com/ontologies/2010/01/27/zg#UserActivity
<seiflotfy_> its not a link
<seiflotfy_> its just a definition
<m4n1sh> it is a URI if i am not wrong
<seiflotfy_> m4n1sh, its an ontology definition
<m4n1sh> yeah
<m4n1sh> but it is not a link
<m4n1sh> simply a URI
<m4n1sh> I = identifier
<XiX> there should be an option at least
<m4n1sh> for?
<XiX> for opting in using zeitgeist
<m4n1sh> just purge the packages
<XiX> does a typical ubuntu user know about zeitgeist, much less how to purge packages?
<XiX> sure, we do
<XiX> but how about we wait
<XiX> for the next guy to come in
<XiX> to #ubuntu
<m4n1sh> XiX: so what is your solution?
<heere> remove the package
<heere> from the instaler
<m4n1sh> heere: cant happen
<m4n1sh> unity depends on zeitgeist
<XiX> in the ubuntu installation, opt in unity and zeitgeist
<heere> well there you go, its just like the firefox awesomebar
<heere> its fine
<XiX> you could even poll users
<m4n1sh> heere: people will cry a lot, but later settle
<heere> unity is canonical's new WM
<m4n1sh> heere: factual mistake
<m4n1sh> " unity is canonical's new WM" <-- factual mistake
<m4n1sh> when awesome bar came people, cried and later got used to it
<heere> eehhh fork of gnome?
<m4n1sh> heere: even more stupid answer
<m4n1sh> how on earth can it be a fork?
<m4n1sh> unless you are a sensational journalist
<XiX> <XiX> joseph__, do you know anything about zeitgeist
<XiX> <joseph__> No XiX I do not
<m4n1sh> XiX: not possible to poll users
<heere> describe unity as a piece of software in one sentence
<m4n1sh> we dont even have a list
<m4n1sh> heere: it is a shell
<m4n1sh> that it is
<m4n1sh> implemented as a plugin of compiz (which is the WM)
<m4n1sh> XiX: good. end-users dont care
<m4n1sh> they just need to get their work done
<XiX> i believe they do
<m4n1sh> mostly they done care
<XiX> i am an end-user
<heere> XiX do you use firefox?
<m4n1sh> good, then I will put that claim to be  "95% of the end-userd dont care"
<XiX> and i didnt even know about this until yesterday
<m4n1sh> *users
<XiX> i think they dont care because they dont know
<m4n1sh> end-users just want to get their work done
<m4n1sh> that's all
<m4n1sh> like I am an end-user for LibreOffice, i don't care how the whole thing works
<m4n1sh> even though I can hack on it, but still I have other things to do
<XiX> im sure end-users care about privacy
<XiX> and logs
<m4n1sh> XiX: okay for last time, it isnt a privacy issue
<XiX> if i rootkitted your machine, and you didnt know about it, and the information was going nowhere, would you still feel ok about it?
<m4n1sh> XiX: have you attended Ubuntu developer week's Zeitgeist session
<seiflotfy_> XiX, same thing with pidgin, Firefox, Chrome, and more
<seiflotfy_> ur point is invalid
<m4n1sh> XiX: you use a phone? does it show you a list of recently recieved calls? missed calls? dialled numbers
<XiX> no i have not, as i stated i have only found out about this yesterday
<seiflotfy_> get rid of the other log files first
<m4n1sh> then your phone also has secrutiy issues
<m4n1sh> privacy issues
<XiX> and those programs, seiflotfy_, only log minimal activity, within themselves
<m4n1sh> XiX: zeitgeist doesnt log your chat content
<m4n1sh> only when you logged in
<m4n1sh> logged out
<m4n1sh> miminal info
<XiX> i would count that as logging
<m4n1sh> no text stored
<m4n1sh> yes
<m4n1sh> it is minimal
<m4n1sh> lesser than what your apps do
<XiX> for one, how do you disable zeitgeist logging certain things
<Ampelbein> XiX: there is the ksyslogd daemon that logs your login/logouts on every linux system.
<XiX> from a factory installation
<m4n1sh> firefox logs your web browsing history, zeitgeist logs your desktop browsing history
<seiflotfy_> m4n1sh, deinstall the loggers
<seiflotfy_> in this case datahub
<XiX> i can disable firefox logs
<seiflotfy_> datahub is the one that relogs from gtk.recentlyused
<m4n1sh> XiX: you can even disable zeitgeist
<seiflotfy_> firefox has its own plugin
<XiX> explain please
<m4n1sh> just purge the package
<seiflotfy_> that is not installed by default
<XiX> m4n1sh, this is not intuitive
<seiflotfy_> we dont log fiefox logs
<XiX> and not 'disabling'
<seiflotfy_> if firefox is set to incognito we respect that
<m4n1sh> XiX: you still want something to be logged?
<seiflotfy_> since the firefox plugin resides in firefox
<seiflotfy_> zeitgeist itself doesnt d othe logging
<seiflotfy_> but a set of plugins for apps send the info to zeitgeist
<m4n1sh> it relies on other applications to tell it
<seiflotfy_> m4n1sh, ok i am letting oyu take over
<m4n1sh> seiflotfy_: where you going?
<kklimonda> seiflotfy_: are you working on chromium integration?
<m4n1sh> kklimonda: AFAIK chrome plugin exists
<m4n1sh> is the extension API same?
<m4n1sh> for chromium
<kklimonda> probably
<kklimonda> I don't see why would they change it
<m4n1sh> XiX: you can uninstall zeitgeist-datahub package
<XiX> ok, so im typical ubuntu user on a typical factory installation. i just heard about zeitgeist and i want to disable certain functionality after hearing about it, but i think its ok to work with unity. you tell me to purge the package. what does that mean to me ?
<heere> where can I download a copy of a binary ld-2.11.1.so?
<m4n1sh> heere: that should be part of the default install if I am not wrong
<heere> mine is corrupted i think
<kklimonda> heere: you can get it from libc deb package
<heere> its segfaulting my init
<m4n1sh> XiX: apt-get remove zeitgeist-datahub
<kklimonda> heere: and you can download deb package from http://packages.ubuntu.com/ or directly from Launchpad
<XiX> <m4n1sh> XiX: apt-get remove zeitgeist-datahub
<m4n1sh> kklimonda: yeah. AFAIK npapi is the extension api followed
<XiX> this is,again,not disabling certain functionality, and not intuitive
<XiX> you are never informed about zeitgeist
<m4n1sh> the point being which certain functionality?
<XiX> working with unity
<m4n1sh> XiX: then you want a huge gigantic popup telling "Hey, I am zeitgeist here"
<XiX> in fact
<m4n1sh> the aim is to get out of the way
<m4n1sh> and help the end-users
<m4n1sh> in making his experience better
<XiX> maybe im OK with it working with unity
<XiX> but
<XiX> keeping a history?
<kklimonda> XiX: you are not informed about Firefox logging your history, or empathy logging your discussions either.
<XiX> however
<XiX> firefox makes it intuitive
<m4n1sh> wait.. you want it to work with unity but not keeping history?
<XiX> to remove logs
<m4n1sh> what about empathy?
<m4n1sh> it doesnt
<m4n1sh> i cant find
<m4n1sh> nor pidgin
<m4n1sh> and openoffice also saves last used documents
<m4n1sh> so does gedit
<XiX> ah
<XiX> here is the difference
<m4n1sh> so does bash (in .bash_history )
<XiX> you PERMIT those applications by using them
<XiX> whenever did you permit zeitgeist to log all this sht
<heere> ok i just replaced my ld.so with the i386 binary, even though its an x64 install
<heere> i hope it works....
<heere> reboot
<m4n1sh> same here too
<kklimonda> heere: doesn't make much sense
<m4n1sh> you permit ubuntu by using it
<XiX> your right
<m4n1sh> the work of balancing of "Asking user if you want to enabled this feature" v/s making it easy
<XiX> herein lies the flaw
<XiX> im using ubuntu
<XiX> :|
<m4n1sh> XiX: by installing ubuntu you permitted it
<m4n1sh> he he
<XiX> great, time to get another OS then. one that doesnt log everything I do
<m4n1sh> you can use gentoo
<m4n1sh> compile everything
<m4n1sh> select everything you want to install :)
<kklimonda> I hardly see how the list of recently accessed documents and applications is a privacy breach.
<m4n1sh> nothing bad in it.. people use it and love it
<XiX> accessed?
<Ampelbein> kklimonda: it is, if you want to troll the channel.
<XiX> hold on a minute
<m4n1sh> XiX: every OS does
<m4n1sh> kklimonda: it isnt
<m4n1sh> even bash does
<m4n1sh> lots of apps do it
<XiX> i like how every time someone has a genuine problem with ubuntu, it is dismissed as a 'troll' Ampelbein
<m4n1sh> singling out zeitgeist is what i find weird
<m4n1sh> XiX: get other OS, I am sure they also have logging
<m4n1sh> the oens you wont even kow
<m4n1sh> XiX: you are not a troll
<XiX> ive tried many OS's m4n1sh
<m4n1sh> you are discussing it via points
<m4n1sh> trolls just run around in circles
<m4n1sh> we are using valid points to debate
<m4n1sh> yeah
<m4n1sh> all of them log
<Ampelbein> XiX: Every linux logs user activity such as date and time of logins, issueing commands, accessing filesystems
<XiX> of course
<XiX> but logging activities, events, files opened, websites viewed, and login to chat sessions
<m4n1sh> XiX: check your /var/log
<m4n1sh> and you will understand
<m4n1sh> not much difference
<XiX> m4n1sh, im not new to linux :|
<m4n1sh> yes
<m4n1sh> good
<m4n1sh> when I logged in
<m4n1sh> when i connected to interney
<m4n1sh> when i put in my pen drive
<m4n1sh> everything is logged
<m4n1sh> i cant find much difference
<Ampelbein> XiX: what information does zeitgeist log that isn't logged by other programs?
<XiX> i just stated it
<kklimonda> XiX: do you mean that zeiteist logs websites and chats, even after you disable logging in firefox and empathy?
<XiX> activities, events, files opened, login to chat sessions, and it is sometimes extended to websites viewed and conversations
<m4n1sh> kklimonda: out of box instal of ubuntu doesnt log firefox and empathy events
<XiX> you know what that sounds like?
<m4n1sh> not websites
<XiX> a rootkit to me
<m4n1sh> kklimonda: only file opening and closing
<m4n1sh> thats; it
<m4n1sh> actually only opening
<m4n1sh> out of box install of ubuntu with zeitgeist installed only supports this much
<m4n1sh> nothing else
<m4n1sh> and you install plugins explicitly
<XiX> how about on Natty?
<m4n1sh> to log firefox
<m4n1sh> another for chrome
<m4n1sh> other for empathy
<m4n1sh> XiX: same as of now
<Ampelbein> XiX: only the accessed documents is logged at standard install. and even that is something that other programs do for a long time already.
<m4n1sh> Ampelbein: zeitgeist is like a central logger instead of all apps having their own loggers with recently used files
<m4n1sh> they can remove their lastest file functionality and use zeitgeist
<m4n1sh> if they want
<Ampelbein> m4n1sh: I know.
<XiX> you guys are right, maybe im just concerned about how much ubuntu logs its users
<m4n1sh> XiX: out of box only opening files
<m4n1sh> which you already find in Places>Recent Documents
<m4n1sh> want more logging? install plugins
<Ampelbein> XiX: it isn't ubuntu, it's every gnome installation in the whole world that logs the same information.
<XiX> maybe thats the problem
<m4n1sh> XiX: so what is your solution?
<m4n1sh> I think even KDE logs information
<m4n1sh> latest opened files
<m4n1sh> etc
<Ampelbein> XiX: then you should talk to the gnome developers to remove the "recent document"-functions, talk to the syslogd developers to stop logging logins/logouts, talk to the firefox developers to stop logging visited websites. why come to ubuntu?
<XiX> idk, i dont have all of the answers
<XiX> m4n1sh
<m4n1sh> yes
<m4n1sh> right now zeitgeist only extracts out file logs from gtk.recentlyused
<m4n1sh> sort of duplicating right now
<seiflotfy_> XiX, your out of luck since Zeitgeist is being integrated with the next KDE per default
<seiflotfy_> there are very good uses to it
<m4n1sh> XiX: the good uses outnumber the bad uses
<seiflotfy_> and GNOME and KDE wouldn't have been cooperative if they did not see the benfits form it
<XiX> this reminds me of how windows integrets shit and nobody has a voice in it
<m4n1sh> every technology can be misused
<m4n1sh> "and GNOME and KDE wouldn't have been cooperative if they did not see the benfits form it" THIS ----> +100
<m4n1sh> XiX: I don't think any OS is spared in that
<m4n1sh> except in linux you can uninstall it
<XiX> today, how can someone run a powerful OS that does not infringe on your privacy
<m4n1sh> i dont think it is possible
<m4n1sh> unless I package shit myself
<m4n1sh> means take source.. strip out things i dnt need
<m4n1sh> and compile
<XiX> very well :\
<m4n1sh> possible but time consuming
<m4n1sh> and there are only 24 hours in a day :)
<XiX> ill just write a script to shred all of these logs
<XiX> and run it in cron
<m4n1sh> XiX: actually you can set blacklists too
<m4n1sh> but right now the functionality is not so good
<m4n1sh> to do it
<XiX> i dont like how this is all going, thats all
<XiX> idk, ur right about the usability thing
<m4n1sh> XiX: yeah
<m4n1sh> if we ask the user in the installer "You want zeitgeist to be installed"
<XiX> its hard to make an OS thats easy for the end users yet adaptive for the adept
<m4n1sh> most users wont understand that question
<seiflotfy_> XiX, i love your points btw and i would be happy if you could join us on #zeitgeist
<m4n1sh> XiX: people who know can customize
<seiflotfy_> u know poinit out any security and privacy concerns
<seiflotfy_> and help us have an easy way to deal with it
<m4n1sh> XiX: the dilemma of default-settings and customization
<seiflotfy_> to ensure maximum usability with minimum exposure of information
<XiX> exactly
<m4n1sh> XiX: I am working on the blacklist plugin in the next zeitgeist release
 * kklimonda wonders if it's time to create some sort of "no services written in anything but C and C++" policy.. I've got 12 python binaries running, and the suck memory like crazy..
<kklimonda> even unity is launched using python..
<aroman> why did my package that builds perfectly on lucid, fail to build when I changed it to maverick in debian/control? http://launchpadlibrarian.net/65759906/buildlog_ubuntu-maverick-i386.elementary-wallpapers_0.2.1_FAILEDTOBUILD.txt.gz
<ampelbein_> aroman: it could be that in the lucid environment pkgbinarymangler isn't being run.
<ampelbein_> aroman: did you upload both packages to your ppa?
<aroman> ampelbein_: yeah lucid has always worked
<tumbleweed> aroman: as the error says, it's dist-packages in python2.6, not site-packages
<aroman> this package is just based on ubuntu-wallpapers
<aroman> tumbleweed: i dont know what that means I'm afraid
<aroman> i thought i'd see how ubuntu-wallpapers from the maverick series does it
<tumbleweed> aroman: you are installing python modules into the wrong location
<aroman> and its identical
<aroman> tumbleweed:  I dont see how I can change that
<aroman> Build-Depends: debhelper (>= 5), cdbs, python, python-central
<aroman> Build-Depends-Indep: python-distutils-extra, xsltproc
<ampelbein_> aroman: it works on lucid because pkgbinarymangler is disabled there
<aroman> ampelbein_: okay, so what should I do t rectify the situation?
<ampelbein_> aroman: i'll have a look
<aroman> ampelbein_: great, thanks
<ampelbein_> aroman: ugh, 60MB
<aroman> ampelbein_: :/ it's just wallpapers
<aroman> if you have a really slow connection, i can strip them out and upload the tar.gz somewhere
<ampelbein_> aroman: nah, it's ok
<tumbleweed> aroman: hmm, can't see any mistake you've made
<aroman> tumbleweed: yeah i can't imagine whats gone wrong either
<aroman> especially since the actual ubuntu-wallpapers package from maverick, that obviously works, does nothing different
<aroman> is it remotely possible this is a launchpad bug?
<genux> lo
<genux> I am getting a error when trying to compile the 11.04 kernel alpha 3
<ampelbein_> aroman: no, if you manually build you will see files end up in site-packages
<genux> /usr/src/linux-2.6.38/arch/x86/kernel/entry_64.S:1544: Error: .size expression does not evaluate to a constant
<genux> just wondering if there is any ideas ?
<aroman> ampelbein_: okay, how do I tell it to put them in the proper place then?
<ampelbein_> normally with 'python setup.py install --root=$(CURDIR) --install-layout=deb'
<ampelbein_> cdbs should include the correct calls
<aroman> well, how can I _launchpad_ to do that?
<tumbleweed> aroman: not a launchpad bug, cdbs. ampelbein_ yeah, cdbs seems to be forcing site-packages (/me digs)
<aroman> interesting
<ampelbein_> unfortunately I don't know cdbs too good. I like debhelper far more ;-)
<aroman> hmm
<tumbleweed> yeah I also avoid cdbs. aroman: easy answer. You really don't need that .egg-info file that's being installed. (This isn't a python module, just a theme using python's distutils to install it)
<aroman> what .egg-info file?
<tumbleweed> duh, s/ubuntu-wallpapers/elementary-wallpapers/ in your rules
<aroman> o.O..?
<tumbleweed> aroman: the one that's causing the error. It's deleted in the binary-post-install bit
<tumbleweed> but that wasn't being called due because it was waiting for the wrong package
<aroman> derp
<aroman> megafail
<ampelbein_> oh, lol.
<aroman> as much of a novice as I am to packaging, that just makes me feel bad
<aroman> i inherited this elementary-wallpapers package anyway :/
<aroman> and this didn't break on lucid because as ampelbein_ pointed out, pkgbinarymangler is disabled?
<tumbleweed> probably, yes
<StevenK> It didn't break on Lucid since the policy changed for Maverick?
<tumbleweed> pkgbinarymangler does sanity checks (amongst other things)
<tumbleweed> this could have also been a new check
<StevenK> For Maverick, I suspect it was.
<ampelbein_> nah, the transition was in karmic.
<ampelbein_> but for lucid, pkgbinarymangler is disabled, see the succesful build log
<aroman> Ampelbein: tumbleweed: thanks to your help, launchpad just informed me that elementary-wallpapers finished building :D
<TheMuso> psusi: Just ask, and I'll respond when I'm around. Whats up?
<psusi> TheMuso, hey, was wondering if you could help me understand 02_disable_dmreg.patch in dmraid
<psusi> wait, that's not the one you wrote...
 * psusi looks for which patch he was thinking about
<psusi> TheMuso, ahh, was dmraid.patch in parted
#ubuntu-devel 2012-02-27
<slangasek> broder: blast, follow-up to bug #858122 shows that I missed /etc/rc6.d/S35networking... not sure how important that is
<ubottu> Launchpad bug 858122 in insserv (Ubuntu Oneiric) "incomplete migration to /run (shutdown script order has been demolished)" [High,Fix committed] https://launchpad.net/bugs/858122
<L3top> anyone got an explanation why deb mirror://mirrors.ubuntu.com/mirrors.txt lucid main restricted universe multiverse might throw CD-ROM errors?
<L3top> no cd references in the sources.list
<L3top> nm... nothing to do with the mirrors.
<broder> slangasek: i bet there are unfortunate nfs interactions
<pitti> Good morning
<ajmitch> morning pitti
<hrw> hi
<hrw> can we change one thing related to compatibility with lts? Lucid has libmpfr1ldbl package which is present in all next releases up to oneiric (which lacks it). This way packages built for lucid (aka 'last LTS') work on maverick/natty but fail to install on oneiric ;(
<hrw> would be nice to have such compatibility for all <(lts+1) releases
<micahg> hrw: the source was removed
<micahg> not in Debian either
<hrw> micahg: Debian has longer release time
<hrw> micahg: to provide binaries for oneiric I need now bump 8 packages versions, build them in order - with ppa builders queue it will take another 3 days
<micahg> hrw: it's not in squeeze
<hrw> or will grab older mprf from lucid and recompile under oneiric and check will it work
<hrw> ok
<micahg> hrw: ah, was migrated to mpfr4
<hrw> micahg: maverick migrated to mpfr4 but kept old version.
<hrw> in oneiric it got dropped
<micahg> right, until the migration was complete
<micahg> hrw: if there are specific LTS -> LTS upgrade issues, we can address those, but we won't add back the old source
<hrw> micahg: I am fine with lack of old library in new lts. I complain about lack of in in lts-1
<micahg> hrw: we remove libraries basically when Debian does unless we need them for something, it was removed for squeeze, so we removed it for oneiric
<micahg> hrw: is something specific broken in oneiric because of this?
<micahg> the only thing we try to guarantee between upgrades is a stable upgrade path, not that a specific version of something is available
<infinity> hrw: Keeping libraries around just so people only need to build a binary once for 4 releases isn't sane.
<infinity> hrw: There's a reason the PPAs build for all releases.
<infinity> hrw: If you want to provide oneiric packages, build them on oneiric.
<micahg> I'm wondering why the packages are needed in the first place unless something outside the archive was using it
<infinity> micahg: That's what he's saying.  He wants to build on lucid and have it work on lucid->oneiric, so yes, not archive packages.
<micahg> well, we generally don't advise that anyways AIUI, each release usually brings toolchain improvements and extra security hardening
<hrw> micahg, infinity: if package build for lucid works under next releases then why bother with rebuilding?
<hrw> and toolchain improvements are not something important for cross toolchain backport
<infinity> hrw: No one's saying you must rebuild it if it works.  We don't rebuild things "just cause" either.
<infinity> (There are still packages in precise that were built on natty)
<hrw> yep
<micahg> although in the above case we probably should to pick up --as-needed :)
<infinity> But we're not going to guarantee compatibility like you're asking for, that's all.
<hrw> infinity: ok
<infinity> micahg: It'll all get rebuilt in time.  *shrug*
<infinity> micahg: Most of us don't like gratuitous archive/mirror churn for tiny gains.
<micahg> well, we still have packages from warty :)
<hrw> building mpfr under oneiric now - will provide it in ppa
<infinity> hrw: Why would you do that?
<infinity> hrw: Why not just build your package against the new library?
<micahg> sure, not for gratuitous purposes, but some packages can really simplify the dependency change
<micahg> infinity: you just answered that question when I asked it :)
<hrw> infinity: it took me 3 days of building for lucid
<hrw> infinity: with 21h queues I prefer to build one instead of 8
<infinity> (The PPA queues are empty right now)
<hrw> ok, worth try
<hrw> be back in 1h
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Freeze in effect.  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: dholbach
<dholbach> can somebody please reject https://code.launchpad.net/~l3on/ubuntu/precise/rawstudio/fix-ftbfs/+merge/94701 - the bug in question was solved differently already
<pitti> done
<dholbach> thanks pitti
<hrw> can someone push vwstreams to archive to get it built on armel/armhf? This will make wvdial buildable on armhf. I built both on mx53/armel in armhf chroot.
<Sweetshark> dholbach: Hey! If I forget to say that to jono when he is back online, please say a big thanks to jono for his kudos to LibreOffice.
<dholbach> Sweetshark, you could comment on his blog post! ;-)
<dholbach> but yeah I have a call with him later on and if I don't forget it, I'll let him know :)
<pitti> hrw: what do you mean by "push to archive"?
<dholbach> Sweetshark, how is your upload rights application coming together?
<mpt> mvo, I got "Not all updates can be installed" and "Do you want to start the upgrade?" dialogs opening at the same time. Does that mean I should upgrade, or not? :-)
<dholbach> pitti, could it be it never built for armel/armhf?
<pitti> https://launchpad.net/ubuntu/+source/wvstreams/4.6.1-2build1
<pitti> it didn't
<pitti> but even doko's rebuild didn't
<pitti> so a mere rebuild won't help; not sure why
<micahg> pitti: http://bazaar.launchpad.net/~ubuntu-core-dev/packages-arch-specific/ubuntu/view/head:/Packages-arch-specific#L276
<doko> hrw, pitti: needs porting, and now it's in P-a-S. do you volunteer?
<pitti> right, was just looking there
<pitti> doko: hrw says it's working for him?
<micahg> Debian seems to be building wvdial on armhf at least
<hrw> p-a-s?
<Sweetshark> dholbach: I google+ shared his blog with a big thanks already.
<pitti> hrw: it's an architecture blacklist for packages which don't limit the architectures in debian/control
<dholbach> Sweetshark, ah cool
<hrw> pitti: thx
<pitti> infinity: can we just change Packages-arch-specific, or is this still fully in sync with Debian?
<mvo> mpt: *urgh* could you make a screenshot please and show it to me?
<Sweetshark> dholbach: not much happening with the application. but didrocks did a upload for me, so he might comment on that too, once he finished answering "where is my workspace switcher?" questions ...
<micahg> if someone's rebuilding wvstreams, can you drop the Qt package, it's unused and built against qt3
<hrw> I never owned normal modem so have no knowledge of wvdial and how to use/test it. Just saw that it is in ftfbs queue for armhf so decided to take a look
<dholbach> Sweetshark, all the best with the application then :)
<mpt> mvo, http://i.imgur.com/oBotI.png
<mvo> mpt: this is indeed pretty ugly
<mpt> mvo, anything you want me to capture before I click "Cancel"?
<mvo> mpt: no, thanks. but if you could run "apt-get dist-upgrade --simulate -o Debug::pkgProblemResolver=true" and paste/mail me the output, that would be nice
<seb128> mvo, mpt: hey, while you are around, small question, is the fact the update-manager standard "install upgrades" dialog keep resizing according to the package name length, known/going to be worked this cycle?
<mpt> mvo, nothing informative: http://paste.ubuntu.com/858969/
<mpt> seb128, I doubt it -- mvo is pretty busy, :-) and update-manager doesn't attract volunteers for reasons I haven't figured out yet
<seb128> mpt, what would be the fix for that? just ellipsize the package names...?
<mvo> mpt: that is confusing, its giving a error that it can not install all updates first, but apt-get does not show any trace of this :/
<mvo> seb128: the download/install dialog? in the release upgrader ? or for regular updates?
<seb128> mvo, regular updates
<seb128> mvo, the one which makes "downloading <package>"
<mpt> seb128, I think you're right, just ellipsizing the name
<seb128> mvo, it's width change with the <package> string length
<seb128> mvo, which makes lot of bouncing, especially on the "unpackaging" steps
<seb128> unpacking
<seb128> mpt, thanks, that seems trivial enough, I might have a look if mvo doesn't ;-)
<mvo> seb128: ok, that should be straightforward indeed, aptdaemon is the package
<mvo> seb128: maybe a gtk3 regression
<seb128> mvo, ...!!!
<mvo> seb128: self.set_ellipsize(Pango.EllipsizeMode.END) is in the code
<seb128> mvo, I will have a look, thanks
<seb128> mvo, mpt: sorry I didn't mean to hijack your discussion
<mvo> seb128: thanks, look at lp:aptdaemon and there aptdaemon/gtk3widgets.py in AptProgressBar
<pitti> ev: hm, bug 901675 seems to be from introducing threading into the GTK GUI :/
<ubottu> Launchpad bug 901675 in apport (Ubuntu) "apport-gtk assert failure: python: ../../src/xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed." [Medium,Confirmed] https://launchpad.net/bugs/901675
<seb128> mvo, thanks
<pitti> ev: can we avoid using GTK from more than one thread?
<mvo> seb128: maybe something missing there
<mpt> mvo, unfortunately it's not reproducible -- second time I tried it I just got the "Do you want to start the upgrade?"
<mvo> mpt: there must be a law or something that bugs are 10x harder to reproduce for developers or something :/ but thanks a bunch for letting me know about it
<mpt> mvo, if all three of those windows were a single window, the bug would be fixed one way or another :-)
<seb128> ups
<seb128> mvo, I wonder if that's because you don't force any max geometry on the dialog, so rather than ellipsizing it just shows to resize
<seb128> mvo, i.e you "        self.progress.set_size_request(350, -1)" but I don't think set_size_request block it to upscale
<dholbach> pitti, regarding bug 940566 it seems like libquvi-scripts will need a MIR :-/
<ubottu> Launchpad bug 940566 in libquvi (Ubuntu) "FFe: Sync libquvi 0.4.0-1 (main) from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/940566
<mvo> seb128: oh, that could well be it
<pitti> dholbach: was this a splitout like "quvi", or a new build dep?
<ansgar> pitti: Also splitout.
<pitti> that's fine then
<dholbach> ok
<dholbach> then I'll go ahead with the sync and everything around it
<dholbach> thanks pitti, thanks ansgar
<pitti> mvo: do you see what apt complains about in https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-oneiric-universe/lastFailedBuild/ARCH=amd64,LTS=non-lts,PROFILE=universe,label=upgrade-test/artifact/universe-amd64/apt.log ?
<pitti> mvo: libcv-dev was split into several packages, which breaks:/replaces: the older versions; this seems not unusual to me
<dholbach> seb128, didrocks, did you have a chance to talk to mhall119 about the quicklist additions?
<seb128> dholbach, yes
<seb128> dholbach, and to jono
<dholbach> I'm on duty as patch pilot today and wonder what to do about the merge proposals
<seb128> dholbach, which ones ?
<seb128> dholbach, if that's universe we agreed to postpone those to next cycle and discuss at UDS
<dholbach> http://reqorts.qa.ubuntu.com/reports/sponsoring/ â all the ones saying "add_quicklist"
<pitti> mvo: in general, what do you look out for first in these logs? "Holding back" lines?
<seb128> dholbach, let me review those
<pitti> Riddell, mvo: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-oneiric-universe/lastFailedBuild/ARCH=amd64,LTS=non-lts,PROFILE=universe,label=upgrade-test/artifact/universe-amd64/apt.log also seems to have trouble with replacing koffice-data (which has zero rdepends left) wit calligra-data; would it help to move "Conflicts: kformula, koffice-data" to "Breaks: kformula, koffice-data"?
<pitti> I still don't understand why apt is so hesitant to remove a package which doesn't even exist any more and has no rdepends
<mvo> pitti: I usually start by looking at the last few lines and walk my way backwards to figure out what exactly is going on
<pitti> and holds it back instead of replacing it with the superseding pacakge
<Riddell> pitti, mvo: or should we just make transitional packages?
<pitti> Riddell: seems a little exaggerated for -data packages to me; but perhaps Breaks: will help
<Riddell> yes
<pitti> but still, it seems to me that apt is overly picky here
<smb> pitti, Hm, apport retracer just marked a crash I had this morning as a duplicate of a bug expired two months ago and then got rid of all the evidence... That seems a bit unhelpful to me... :/
<mvo> transitional will fix it for sure, the log shows that the "score" of koffice-data is 4 but calligra-data:amd64 only 3 - if its a 1-to-1 exchange of the name the score should be equal and if koffice-data is no longer in the archive it gets a penality
<pitti> smb: can you please file a bug against apport for this and assign to me? I guess it doesn't handle the "Expired" state, it's relatively new
<mvo> pitti: its a tradeoff, its hard for apt to know what is important to the user but yeah, in this case its not doing the right thing
<mvo>   Installing koffice-data as Depends of koffice-libs
<mvo> looks odd
<pitti> mvo: oh, where do you see the score?
<smb> pitti, Ok, will do. thanks
<mvo> pitti: its the integer in the following lines:
<mvo>   Considering koffice-data:amd64 4 as a solution to calligra-data:amd64 3
<mvo> eh, line
<mvo> sorry, I know that the output is really hard to read
<pitti> mvo: koffice-libs is also gone, hmm
<mvo>   Installing koffice-libs as Depends of kpresenter
<mvo> was the transition still in progress when this happend maybe?
<pitti> hm, I think kpresenter and friends should have a transitional package
<pitti> it went away as well
<pitti> which probably causes the upgrade confusion
<pitti> mvo: no, that test upgrade is very recent
<mvo> pitti: odd, if its just a transitional package, why would it cause the libs to get installed
<pitti> Riddell: so it should help to add transitional packages for the applications like kpresenter
<pitti> mvo: it's not; kpresenter was also dropped apparently
<pitti> so the existing kpresenter package keeps koffice-{libs,data}
<pitti> Riddell: hm, is there a calligra equivalent for kpresenter?
<Riddell> yes
<Riddell> calligrastage
<pitti> Riddell: so we'll need a transitional package for at least that one
<Riddell> ok, can do
<pitti> for kspread apparently as well
<Riddell> pitti: why that one?
<pitti> and kword
<Riddell> all the apps?
<pitti> Riddell: these are top-level application packages that users have installed
<pitti> which need to be transitioned to their equivalent of calligra
<pitti> otherwise apt woudln't know what to do and just keep them instead of upgrading
<pitti> Riddell: want a bug report for it?
<Riddell> pitti: a bug is handy yes
<Riddell> pitti: but there are other applications in koffice, don't they need transitionals too?
<pitti> Riddell: yes
<pitti> ah, bug 915431
<ubottu> Launchpad bug 915431 in calligra (Ubuntu) "kexi can not be dist-upgraded" [Undecided,New] https://launchpad.net/bugs/915431
<pitti> I'll generalize this
<Riddell> thanks
<pitti> mvo: ok, that covers calligra; I'm still baffled whaht's going on with the opencv stuff
<mvo>   Considering libopencv-features2d-dev:amd64 8 as a solution to libcv-dev:amd64 1
<dholbach> rickspencer3, hey - how are you doing?
<mvo> that seems to be the crucial bit
<rickspencer3> hi dholbach
<rickspencer3> doing well
<dholbach> rickspencer3, I noticed the quickly patches in the sponsoring queue (929417, 929572, 929420) - how do you want to go about them?
<rickspencer3> hi dholbach funny you should mention tat
<rickspencer3> I'm working on 929417 at this very moment
<rickspencer3> dholbach_, for the others, could you please ask didrocks/mterry in #quickly?
<dholbach_> sorry, just had the network kick me out
<mvo> pitti: hm, no, actually "Broken libopencv-features2d-dev:amd64 Depends on libopencv-highgui-dev [ amd64 ] < none -> 2.3.1-7 > ( universe/libdevel ) (= 2.3.1-7)"
<dholbach_> rickspencer3, I noticed the quickly patches in the sponsoring queue (929417, 929572, 929420) - how do you want to go about them?
<dholbach_> rickspencer3, merge them upstream, roll a release, then get it in precise?
<dholbach_> sure
<dholbach_> thanks
<didrocks> rickspencer3: dholbach_: I'm piloting on wednesday, I planned to review them by then
<rickspencer3> thanks didrocks
<rickspencer3> didrocks, I'll strive to get the tutorial updated by then
<didrocks> thanks rickspencer3 ;)
<mvo> pitti: and that leads to "Broken libopencv-highgui-dev:amd64 Depends on libjpeg-dev [ amd64 ] < none > ( none )" and that to "Broken r-base-dev:amd64 Depends on libjpeg-dev [ amd64 ] < none > ( none )" which seems to be the root of it
<pitti> Riddell: I updated bug 915431, and added a list of all (hopefully) missing transitionals
<ubottu> Launchpad bug 915431 in calligra (Ubuntu Precise) "needs transitional packages for old koffice application names" [High,Triaged] https://launchpad.net/bugs/915431
<pitti> jibel: ^ FYI (I think I tagged it as you do)
<pitti> mvo: we so much need to graphviz-ize this :)
<mvo> pitti: oh yes!
<jibel> pitti, excellent. thanks!
<pitti> mvo: oh, thanks! so if we just fix that dependency, it shoudl be better
<pitti> mvo: odd, I thought that libjpeg62-dev and libjpeg8-dev ought to Provide: libjpeg-dev, but seems they don't
<mvo> pitti: there is some fishy stuff here "Broken libjpeg-turbo8-dev:amd64 Conflicts on libjpeg62-dev [ amd64 ] < 6b1-1ubuntu2 -> 6b1-2ubuntu1 > ( libdevel )" too
<micahg> pitti: no, having both libjpeg*-dev packages provide libjpeg-dev creates depwaits
<mvo> pitti: it maybe enough to have a addition "provides: libjpeg62-dev" in libjpeg-utrbo8-dev" - but I don't know why we have the two different ones and why they conflict etc
<smb> pitti, bug 941854
<soren> Uh oh..
<ubottu> Launchpad bug 941854 in apport (Ubuntu) "Apport retraces marks bug report a duplicate of an expired bug" [Undecided,New] https://launchpad.net/bugs/941854
<pitti> smb: thanks
<soren> http://archive.ubuntu.com/ubuntu/dists/oneiric/Release has checksums for Packages and Sources files (uncompressed ones), but they're missing for at least Oneiric.
<soren> It makes my sbuild really unhappy and my tiny brain really confused.
<micahg> mvo: that would be wrong though as libjpeg-turbo8-dev doesn't provide libjpeg62-dev
<pitti> mvo: oh, indeed -- libjpeg-turbo8-dev provides our libjpeg-dev, so I wonder why it's not just installing that one
<soren> Could they have gone missing or were they never there?
<mvo> micahg: hm, good point - so "    Installing libjpeg-turbo8-dev as Depends of libopencv-highgui-dev" - does that really need this paritcular jpeg lib or could it just pick libjpeg-dev instead?
<micahg> mvo: it's asking for libjpeg-dev
<micahg> which is provided by libjpeg-turbo8-dev
<pitti> so we should fix all remaining reverse dependencies of libjpeg62-dev?
<pitti> we even have three packages in main which b-dep on libjpeg62-dev,
<mvo> micahg: aha, that explains it and libjpeg62-dev does not provide libjpeg-dev so it picks the other one.
<pitti> such as compiz-plugins-main
<pitti> didrocks: ^ is that an oversight, or does it really fail with libjpeg8?
<mvo> so the new libjpeg-dev is libjpeg-turbo8-dev is that the summary?
<micahg> for precise, yes
<mvo> ta
<didrocks> pitti: i think this dep comes from 0.8 area
<micahg> pitti: it's just the dev packages that aren't co-installable, the binaries are fine, maybe we just need to make the upgrader smarter about this
<mvo> so that is the root of the problem then: "  Considering libjpeg62-dev:amd64 0 as a solution to libjpeg-turbo8-dev:amd64 -1
<mvo>   Holding Back libjpeg-turbo8-dev:amd64 rather than change libjpeg62-dev:amd64" this transition is not working and that causes the other havoc
<didrocks> so can probably be tried with a newer one, care to open a bug and assign me so that I test? (we will have soon a new compiz upload)
<soren> mvo: Any idea why  "apt-get update" would attempt to fetch uncompressed Packages and Sources files?
<pitti> micahg: hm, the only package which explicitly depends: (not build-deps) on libjpeg62-dev is libspandsp-dev
<pitti> and that doesn't even appear on https://launchpadlibrarian.net/94128035/apt.log
<mvo> soren: it might to that as a fallback if it can not find any compressed ones or any compressor (but the later is really odd)
<pitti> micahg: nevertheless, if people have it installed, then it breaks upgrades
<soren> mvo: In the former case, I should see it trying to fetch the compressed ones and failing somehow?
<micahg> pitti: right, so maybe we should just make the upgrader smarter and remove it or replace it (perhaps even with a warning)
<mvo> one thing we could do is to play with the priority, e.g. libjpeg62-dev becoming extra will be one less point for it
<pitti> but there's > 20 universe packages with Depends: libjpeg-dev, and as this isn't actually wrong, moving them all to libjpeg8-dev sounds just wrong to me
<mvo> soren: yeah, you should see in the apache logs that it tries to hit the compressed ones first
<micahg> pitti: right, we want the build-depends to be libjpeg-dev to make transitions easier (like Debian)
<pitti> micahg: no, binary depends I mean
<pitti> micahg: i. e. foo-dev depends: libjpeg-dev
<pitti> which still looks right to me
<micahg> yeah, that's right too :)
<mvo> yeah, we should not change them if possible, it looks like the score code in apt is not taking the fact into account that the provides changes between the two packages
<pitti> Broken libmng-dev:amd64 Depends on libjpeg-dev [ amd64 ] < none > ( none )
<pitti>   Considering libjpeg62-dev:amd64 235 as a solution to libmng-dev:amd64 4
<pitti>   Removing libmng-dev:amd64 rather than change libjpeg-dev:amd64
<pitti> mvo: ^ with a score like that (235), one more or less hardly seems to make a difference?
<pitti> oh, hang on
<pitti>  Considering libjpeg62-dev:amd64 0 as a solution to libjpeg-turbo8-dev:amd64 -1
<mvo> pitti: yeah, that was the line I was looking at
<pitti> there the difference is -1, but would "extra" help here?
<soren> mvo: Awesome, thanks.
<mvo> yeah, that might help then but apt will still prefer installed packages over new ones, so it may not be good enough
<soren> mvo: Turns out I had a screwed up approx cache.
<mvo> soren: ok
<pitti> it seems feasible to drop all remaining explicit libjpeg62-dev dependencies; would that help, if we remove it from the archive? or doesn't the upgrader look at thaht anyway?
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<tkamppeter> pitti, it is about bug 938669.
<ubottu> Launchpad bug 938669 in upstart (Ubuntu) "Can not increase MaxClients in cups (Max clients reached, holding new connections...)" [Undecided,New] https://launchpad.net/bugs/938669
<pitti> mvo: would it help if libjpeg-turbo built a real libjpeg-dev package?
<pitti> these purely virtual dependencies are prone to failure anyway
<tkamppeter> pitti, should we do as the user suggested, adding the line "limit nofile 4096 4096" to /etc/init/cups.conf or should there be fixed something on upstart, for example supporting /etc/security/limits.conf?
<mvo> pitti: yeah, I think that should work
<pitti> tkamppeter: this doesn't sound like an upstart bug
<pitti> tkamppeter: the default limit is set by pam
<apw> jodh, i have a report of a machine which is hanging during boot, after upstart has started, now --debug is puking too much so i loose output.  any suggestions on how to debug ?
<pitti> doko: are you ok with me adding a real libjpeg-dev package to libjpeg-turbo, to unbreak upgrades?
<doko> pitti: maybe in the libjepg-empty source?
<pitti> doko: libjpeg-empty doesn't seem to exist?
<doko> libjpeg8-empty
<pitti> ah, got it
<pitti> doko: yep, fine for me
<pitti> doko: it would then get a much higher version number then, though
<pitti> doko: but I guess that's ok?
<jodh> apw: What's the last message it displays? You could try '--verbose' for less spew. What version of
<jodh> Upstart is it? Is the hang repeatable? Any new jobs installed recently?
<jodh>  
<apw> i believe this is latest precise, but not confirmed as they are resisting filing a bug as usual
<apw> yes its repeatable, hard to tell what might have started recent as the console is a mess of mixed messages
<tkamppeter> pitti, does this mean that the bug needs to get assigned to PAM?
<pitti> tkamppeter: I'm still not sure it is a bug
<pitti> tkamppeter: the default limits are quite sensible
<pitti> tkamppeter: if you have a special case where thousands of connections are made, then the admin can set this locally
<jodh> apw: can you get a dump/screenshot of the console though?
<apw> jodh, what was the nolog option, --no-log or --nolog ?
<jodh> apw: '--no-log'
<pitti> doko: I see, I agree that -empty makes more sense
<micahg> pitti: it needs to go in libjpeg8-empty or it won't be a viable upgrade from version 6ubuntu* or libjpeg62 (which I assume is the same conclusion you just came to)
<pitti> micahg: it doesn't matter for that as the package has always been virtual, and thus lower than any real package
<pitti> micahg: but conceptually -turbo is just an implementation detail
<pitti> I think -empty shoudl build a libjpeg-dev that (currently) depends on libjpeg8-dev
<pitti> mvo: thanks muchly for your help! I uploaded a fix now
<mvo> pitti: awsome, thank you
<mvo> pitti: I get some lunch now
<apw> jodh, ok here is the log they have with --verbose: http://sprunge.us/BiSi
<apw> jodh, see anyting indicative ?
<apw> jodh, am i right in thinking that procps is stuck in 'post-start'
<jodh> apw: actually, probably not - procps doesn't have a post-start by
<jodh> default (although check to see if someone added this to the system in
<jodh> question). I'm wondering if sysctl is hanging here. Try "echo
<jodh> manual|sudo tee /etc/init/procps.override" and reboot.
 * doko is staring at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661424 ... 
<ubottu> Debian bug 661424 in icedtea-netx "icedtea-netx: warning on upgrade - binary operator expected" [Normal,Open]
<ansgar> doko: Maybe the `...` returns something including whitespace?
<ansgar> doko: [ -z foo bar ] -> bash: [: foo: binary operator expected
<pitti> dholbach: hm, you didn't sync quvi and libquvi-scripts and cclive, right? or did I look into the wrong queue?
<micahg> doko: does the shell
<micahg> doko: does the shell's return output need to be quoted
<dholbach> pitti, I'm happy to do it - I thought I'd wait for libquvi to get in first, no? :)
<pitti> dholbach: sounds fine, as long as it doesn't need the others for building
<dholbach> pitti, libquvi-scripts is the most recent - cclive I can sync as it will likely DEPWAIT
<pitti> dholbach: ah, then it sounds you could as well sync it now
<dholbach> pitti, cclive and quvi synced now too - thanks for looking it up and letting me know
 * pitti hugs dholbach, danke
 * dholbach hugs pitti back
<fraviofii> hello, Is it possible to have an ubuntu-core for arm-v4? Can I prepare it myself?
<tkamppeter> pitti, can you comment on bug 938669?
<ubottu> Launchpad bug 938669 in upstart (Ubuntu) "Can not increase MaxClients in cups (Max clients reached, holding new connections...)" [Undecided,New] https://launchpad.net/bugs/938669
<pitti> tkamppeter: will do after lunch
<mpt> "One or more running instances of xscreensaver or xlockmore have been detected on this system. Because of incompatible library changes, the upgrade of the GNU libc library will leave you unable to authenticate to these programs. You should arrange for these programs to be restarted or stopped before continuing this upgrade, to avoid locking your users out of their current sessions."
<mpt> How do I restart/stop xscreensaver without being logged out and therefore cancelling the upgrade? :-)
<tjaalton> mpt: killing the screensaver shouldn't log you out
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Freeze in effect.  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> uh, ppa build queue 6h?
<pitti> some of the PPA builders were taken offline to do other things apparently
<tjaalton> yeah
<jelmer> hi tjaalton
<tjaalton> jelmer: hi
<zul> mterry: ping
<mterry> zul, hi
<zul> mterry:  i have a couple of MIR that i just filed that is blocking nova from buidling s bug #941920, bug #941916, and bug #941913 can we get them taken care of today? they are pretty easy they are just python modules and they should all be ready
<ubottu> Launchpad bug 941920 in python-iso8601 (Ubuntu) "[MIR] python-iso8601" [Undecided,New] https://launchpad.net/bugs/941920
<ubottu> Launchpad bug 941916 in python-tz (Ubuntu) "[MIR] python-tz" [Undecided,New] https://launchpad.net/bugs/941916
<ubottu> Launchpad bug 941913 in python-babel (Ubuntu) "[MIR] python-babel" [Undecided,New] https://launchpad.net/bugs/941913
<mterry> zul, will look
<zul> mterry: thanks!
<mpt> tjaalton, you were right, thanks :-)
<tjaalton> mpt: np :)
<Daviey> mterry: for info, these are beta release critical issues. :/  Thanks
<geser> pitti: is there a (good) reason to keep postgresql-9.0 (universe) in the archive while we have postgresql-9.1 in the archive too?
<pitti> geser: uh, no; I thought I already removed it ages ago
<pitti> geser: thanks for pointing out, I'll remove
<pitti> there are 4 rdepends left in Debian
<pitti> I'll sync them when/if they update to 9.1
<mterry> Daviey, k, am in the middle of doing them.
<mterry> zul, FYI, I generally find it easier to have one bug for a chain of dependencies like this (python-babel and below) and adding tasks for the separate packages.  No big deal to have them separate, but you may find it easier too, for keeping track
<zul> mterry: ill do that in the future
<pitti> ev: you saw the whoopsie FTBFS?
<pitti> geser: thanks, removed
<Sweetshark> pitti: any good idea about Bug #938582 ?
<ubottu> Launchpad bug 938582 in libexttextcat (Ubuntu) "[MIR] libexttextcat" [Undecided,Fix released] https://launchpad.net/bugs/938582
<Sweetshark> chrisccoulson: ping?
<pitti> Sweetshark: sorry, I don't understand -- which package depends on which?
<pitti> Sweetshark: libexttextcat0's dependencies look fine to me
<Sweetshark> pitti: libexttextcat0-dev*ubuntu1 depended on libtextcat0-dev*ubuntu1 (although that one isnt ubuntufied) IIRC from my pbuilder failures.
<mterry> zul, question for you in bug 941916
<ubottu> Launchpad bug 941916 in python-tz (Ubuntu) "[MIR] python-tz" [Undecided,Incomplete] https://launchpad.net/bugs/941916
 * Sweetshark rechecks
<zul> mterry: yep
<Sweetshark> pitti: libexttextcat-dev : Depends: libexttextcat0 (= 3.2.0-1ubuntu1) but it is not going to be installed <- from my pbuilder log.
<pitti> Sweetshark: hm, no idea why that would be; the versions are identical
<pitti> libexttextcat0 | 3.2.0-1ubuntu1 |       precise | amd64, armel, armhf, i386, powerpc
<pitti> libexttextcat-dev | 3.2.0-1ubuntu1 |       precise | amd64, armel, armhf, i386, powerpc
<Sweetshark> pitti: does libexttextcat0  3.2.0-1ubuntu1 depend on libtextcat0  3.2.0-1ubuntu1 by chance?
<pitti> Depends: libc6 (>= 2.14), libexttextcat-data (= 3.2.0-1ubuntu1)
<pitti> Sweetshark: no, should it?
<pitti> and libexttextcat-data is built by the libexttextcat source, so all seems fine
<Sweetshark> pitti: hmmm, so what is wrong my pbuilder?
 * Sweetshark goes hunting there.
<zul> mterry: i think it might be feasable to look at it after ff
<mterry> zul, you mean after Beta1?  We're after FF
<zul> mterry: sorry beta1
<mterry> zul, this (and the tests, see my new comment) are normally MIR blockers.  What's the story with the urgency here?
<zul> mterry:  pretty urgent
<zul> its a blocker right now
<mterry> zul, for the nova stack?
<zul> mterry: correct
<mterry> zul, well, as a MIR reviewer, it's not approved until those get fixed.  But I'll subscribe ubuntu-release (who has to sign off anyway post-FF) if they want to promote it anyway/temporarily for the beta
<zul> this is babel right?
<Daviey> mterry: sorry, what is the blocker?
<mterry> zul, -tz
<mterry> Daviey, bug 941916
<ubottu> Launchpad bug 941916 in python-tz (Ubuntu) "[MIR] python-tz" [Undecided,Incomplete] https://launchpad.net/bugs/941916
<mterry> Daviey, tests and a hardcoded timezone list
<zul> Daviey: er..http://paste.ubuntu.com/859292/
<mterry> zul, the tests can be run manually, but not sure how they are intended to be run, because yeah, setup.py doesn't call 'em
<Daviey> mterry: ah, i wrote a patch to enable the test suite at runtime.
<Daviey> err build time
<Daviey> oh, that was for python-iso8601.
<Daviey> mterry: Can i suggest that, if nothing inherently scares you, that they get promoted, with open bug tasks to resolve the niggles?
<mterry> Daviey, ah yeah, I was going to file a bug for that one with Debian.  It's test suite seemed awkward to run, so wasn't going to block on it.  But that patch would be super welcome too!  :)
<dholbach> hey mterry - did seb128 ping you about the lightdm sponsoring item? :)
<mterry> dholbach, no?
<dholbach> hang out, let me dig it out
<dholbach> ah no, sorry - unity-greeter
<dholbach> bug 884366
<ubottu> Launchpad bug 884366 in unity-greeter (Ubuntu) "Theme is not customizable by downstream (derivative) distros" [Undecided,Confirmed] https://launchpad.net/bugs/884366
<zul> mterry: k tz is running the tests now
<mterry> Daviey, it's just a matter of process.  Issues of release schedule timing aside, these would be blockers.  ubuntu-release will probably take your stance too (pitti?), in which case I'm on board
<pitti> we could also revert to the previous nova
<pitti> as it was uploaded a bit hastily anyway
 * pitti needs to run out for a bit, bbl
<zul> previous version of nova had a big nasty memory bug i rather not revert it either
<mterry> dholbach, ah, we made it easier for derivatives by moving to gsettings instead of an /etc/ config file.  So they can just ship gsettings overrides
<mterry> dholbach, I'll comment in bug and close out
<dholbach> mterry, excellent
<dholbach> thanks a lot
<dholbach> seb128, ^
<soren> zul: Memory bug?
<zul> soren: scheduler bug
<zul> soren: that just sucks alot of memory from nova-compute
<soren> zul: Do you have a bug ref?
<zul> soren: yeah gimme a sec
<seb128> dholbach, mterry: thanks
<ogzy> i am trying to pack libaudiere-1.9.4 for oneiric, i tried to use te source files from hardy and downloaded the dsc, diff.gz and tar.gz files and run sudo pbuilder build *.dsc here is what i got as error: Dependency is not satisfiable: libdumb1-dev but i have this package installed, any idea?
<ogra_> inside your pbiulder chroot ?
<ogzy> ogra_: yes
<ogra_> might it be that there is a versioned dep on the package ?
<ogzy> i checked the control file after i dpkg-source -x *.dsc, it only says the package name, no version
<goganchic> hi2all
<mterry> zul, I'm looking at python-babel now and it includes a bunch of binary info about locales.   So what does nova even use python-babel for?  Is it anything it could just use python-pyicu for instead, since it's already in main and has a boat-load of included locale info?
<zul> mterry: i nor probably wasnt aware of it...its something that i will definently have to look at
<goganchic> can anybody tell me where can I find code of hiding/showing global menu? I want to show it always. There are no settings for this function in unity interface and no code in indicator-appmenu package
<mterry> zul, I can't even find where nova is importing babel
<zul> mterry: are you looking at the package in the archive?
<mterry> zul, yeah
<zul> mterry: yeah youll have to look at the upstream source
<mterry> zul, ok.  we are depending on python-babel in anticipation then?
<zul> mterry: yes
<zul> mterry: its a dependency of the nova waiting to build in the buildds
<chrisccoulson> hi Sweetshark
<goganchic> is indicator-appmenu the package which display menu in the top panel in unity?
<mterry> zul, all I see in nova trunk is a babel.cfg
<zul> mterry: https://github.com/openstack/nova/commit/4a4c274c834728a03bce7e5384c562321821eaf8
<mterry> zul, ah...  babel is a build tool as well as a library
<mterry> zul, missed that bit
<mterry> So not so easy to replace with pyicu
<mterry> goganchic, yes
<goganchic> merry, and what about code for hiding/showing global menu? Is this code in indicator-appmenu package too? Or this code belongs to main unity package (libunity or smith like this)&
<goganchic> mterry, and what about code for hiding/showing global menu? Is this code in indicator-appmenu package too? Or this code belongs to main unity package (libunity or smith like this)?
<stgraber> mvo: any thought on bug 937196?
<ubottu> Launchpad bug 937196 in ifupdown (Ubuntu) "10.04 LTS -> 12.04 upgrade failed: ifupdown depends on upstart and initscripts but they are not configured" [High,Confirmed] https://launchpad.net/bugs/937196
<mterry> goganchic, well, that gets a bit complicated.  unity hosts the appmenu indicator, sure.  But appmenu-gtk which is a gtk+ module that all client apps load is responsible for sometimes showing it (like when user holds down ALT I believe)
<mterry> goganchic, what's your goal?
<mterry> goganchic, this might be better fodder for #ubuntu-unity?
<goganchic> merry, my goal is to show global menu by default, always, not only when mouse pointer is over it. I'll try #ubuntu-unity channel, thanks
<goganchic> mterry, my goal is to show global menu by default, always, not only when mouse pointer is over it. I'll try #ubuntu-unity channel, thanks
<pitti> jibel: would it take much effort to re-run precise-upgrade-lucid-universe, now that we have the libjpeg-dev fix?
<pitti> jibel: ah, nevermind
<pitti> jibel: we need calligra fixed first
<mpt> ev, hi, can we kill the bubbles that say "An application has crashed on your system (now or in the past). Click on the notification icon to display details."?
<jml> my precise install is being ground to a halt, I think by dconf-settings
<jml> can I just kill it, please?
<seb128> jml, don't blame the messenger
<infinity> pitti: Oh, checking scrollback, our P-a-s is forked from Debian's and we can change it, but wvstreams (and thus wvdial) just plain didn't work on ARM last time anyone checked.
<seb128> jml, it probably means something loop write to gsettings
<infinity> pitti: Not from a building POV, but from a runtime one.
<seb128> jml, strace it maybe to figure what key is being written?
<infinity> pitti: If that's no longer true, I'm happy to build them again.
<pitti> infinity: right; I saw that you already PaSed wvdial, but http://qa.ubuntuwire.org/ftbfs/ doesn't take that into account
<pitti> infinity: thanks
<infinity> pitti: (If you're just trying to get wvdial out of the yellow block on the qa report, that's an LP bug, and would be resolved by uploading the source again). :P
<pitti> infinity: *nod*
<jml> seb128: what am I looking for in the strace output?
<infinity> pitti: Alternately, fix qa/ftbfs to parse P-a-s, so it can ignore builds that LP shouldn't have. ;)
<infinity> pitti: (Which seems saner than re-uploading source just to remove a build record)
<jml> write(12, "GVariant\0\0\0\0\0\0\0\0\30\0\0\0\20\31\0\0\0\0\0(\344\0\0\0"..., 12288) = 12288
<jml> write(12, "elay\0\0\0\0\350\3\0\0\0imaximized\0\1\0bcache"..., 348) = 348
<jml> to .config/dconf/user.DF597V, which then gets renamed to .config/dconf/user
<seb128> jml, maybe try to gsettings list-recursively > log and diff the logs
<seb128> i.e 2 calls to those
<bluefoxicy> so
<bluefoxicy> I asked Ubuntu to upgrade yesterday
<bluefoxicy> it hasn't.
<bluefoxicy> It got one package in, then asked me about which services to restart for a glibc upgrade and waited.
<bluefoxicy> might I suggest making apt a bit more intelligent, such that it can look at packages which will pause apt and defer them until later in the process (i.e. when things can't be installed without the offending package first)
<bluefoxicy> and also, marking such packages where you can install and defer any such questions until later so that it simply doesn't ask until later in the process
<jml> -org.gnome.settings-daemon.peripherals.keyboard numlock-state 'on'
<jml> +org.gnome.settings-daemon.peripherals.keyboard numlock-state 'off'
 * bluefoxicy hates babysitting things.  Would rather come back to a stalled process when it's almost done than when it's just started.
<seb128> jml, it seems g-s-d is spammed gsettings with numlock status changes
<jml> hmm.
<jml> I've seen some people mention issues with apple keyboard & numlock...
<seb128> jml, do you have any service or anything dealin with numlock status for you?
<jml> but I haven't paid attention to details
<seb128> jml, when did that start?
<jml> seb128: I don't think so.
<jml> seb128: within the last hour
<seb128> jml, you can probably "gsettings set org.gnome.settings-daemon.peripherals.keyboard remember-numlock-state false"
<seb128> or kill gnome-settings-daemon
<seb128> it seems stuff fight over your numlock status
<jml> seb128: setting remember-numlock-state off seemed to stop the spinning.
<jml> seb128: thanks.
<seb128> jml, yw, still weird that stuff keep changing the status of numlock and a bug somewhere
<seb128> could be xorg or virtualbox or something
<seb128> jml, the gsettings stuff was only a side effect, g-s-d only stores the status
<seb128> it seems something keeps changing the status though
<seb128> jml, oh, and no, I've no idea how to debug what is the something ;-)
<jml> seb128: heh
<jml> seb128: well, tbh, I'd rather get on with other things than spend time debugging OS issues :)
<jdstrand> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Freeze in effect.  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: jdstrand
<seb128> jdstrand, hey, please ignore merge request about unity_quicklists, those have issue and are being sorted
<jdstrand> seb128: ok
<hrw> tkamppeter: thx for activity in bug 932882
<ubottu> Launchpad bug 932882 in gutenprint (Ubuntu) "The PPD version (5.2.7) is not compatible with Gutenprint 5.2.8-pre1." [Undecided,Opinion] https://launchpad.net/bugs/932882
<hrw> have a nice rest of day
<broder> can somebody on ~ubuntu-branches set https://code.launchpad.net/~pali/ubuntu/natty/plymouth/plymouth/+merge/61897 back to work in progress?
<broder> hmm, is it deliberate or accidental that packages that were removed still have udd branches?
<slangasek> broder: I think it's deliberate
<slangasek> we don't want to lose the history; so the question is how do you want to represent a package removal
<broder> backports just got a bug from a user checking out a package that was removed several releases ago
<broder> which is clearly confused on several levels
<slangasek> heh
<slangasek> foreports
<broder> but possibly indicates some real potential problems, especially with things like developer.ubuntu.com now pointing at udd
 * slangasek suggests filing a bug on udd
 * broder nods
<broder> slangasek: what do you want to do about insserv, by the way? based on my experience with afs, i'm suspicious that stopping networking before umountnfs.sh will cause nfs to hang on shutdown, but i haven't used nfs so i don't know
<infinity> broder: Why would you stop networking before umounting network filesystems?
<infinity> (I mean, why should that be discussed instead of just fixed?)
<ogra_> more excitement !
<micahg> maybe the lp:ubuntu/foo branch "symlink" can be removed for packages that have been removed from the dev release?
<mterry> zul, do we even need python-babel if all it does is manage gettext files?  Won't those be managed by the langpacks?
<zul> mterry: im not sure its something we need to look at
<broder> micahg: yeah, maybe. i don't feel like i understand the relevant issues well enough to do much more than raise it with the udd team and let them figure it out
<broder> but i went ahead and filed bug #942138
<ubottu> Launchpad bug 942138 in Ubuntu Distributed Development "Removed packages still have udd branches" [Undecided,New] https://launchpad.net/bugs/942138
 * micahg comments on the bug
<mterry> zul, ok, well added comment to python-babel bug with review there, including that question
<bdmurray> zyga: have you put the command-not-found change for bug 938992 on to Launchpad yet?
<ubottu> Launchpad bug 938992 in command-not-found (Ubuntu) "crash_guard routine should be changed" [Medium,Confirmed] https://launchpad.net/bugs/938992
<infinity> TheMuso: *pokity poke*
<infinity> TheMuso: When you're around, can you add me (adconrad) to ~ubuntustudio-dev?  Kthx.
<smoser> slangasek, ping
<zyga> bdmurray: nope
<slangasek> smoser: hey there
<zyga> bdmurray: let me find that branch
<smoser> i'm looking at bug 937352
<slangasek> SpamapS: say, do you have any packages using wait-for-state in the wild?
<ubottu> Launchpad bug 937352 in cloud-initramfs-tools (Ubuntu) "root partition in may not be grown" [Undecided,Fix released] https://launchpad.net/bugs/937352
<smoser> and wondering if you have some insite
<bluefoxicy> question.
<slangasek> smoser: that one's marked fix released, is that the one you mean?
<smoser> slangasek, yeah, it wasn't fixed. i need to change that.
<bluefoxicy> By convention in init scripts, if you have multiple things to turn on
<bluefoxicy> is it preferred to have settings like "NETWORK0={0,1}", "NETWORK0={on,off}", or "NETWORK0={enabled,disabled}"?
<smoser> slangasek, so basically what happens:
<smoser>  1.) normal initramfs mount of /
<bluefoxicy> or, you know.  y/n
<smoser>  2.) growpart initramfs plugin (in local-bottom) umounts /
<smoser>  3.) calls growpart , which runs 'sfdisk' which calls BLKRPART
<smoser>  4.) sometimes, blkrrpart gets device or resource busy
<smoser> slangasek, at http://paste.ubuntu.com/859573/, i've modified the initramfs to collect 'ps -w' output before and after the sfdisk command
<slangasek> bluefoxicy: I wouldn't consider any of these things to be best practice, really
<smoser> i'mi wondering what could be causing the busy.  smb was fairly certain the only thing he could think of was udev events, so we added a 'udevadm settle' before running growpart (to  make sure any initial events from the normal boot had finished)
<slangasek> smoser: what's this 'blkid' call in the ps output?
<slangasek> smoser: remember that "udevadm settle" doesn't mean "no more events will happen", it means "the event queue is currently empty".
<slangasek> (empty, and all events that were in it have been processed)
<smoser> slangasek, yeah, that is probably the thing that is the issue.
<smoser> i'm assuming it jsut came from udev seeing the vda1 event.
<SpamapS> slangasek: I don't believe there are any using it yet no
<SpamapS> slangasek: I've been meaning to write up how to use it at some point. :p
<smoser> right, obviously it doesn't mean "no more events will happen". but i had assumed that in that point in the boot, where / had already been mounted (on /dev/vda1), that such events would have already occurred.
<SpamapS> slangasek: I've recommended its use on askubuntu.com a few times
<smoser> but one way or another , I need to block until or somehow assert that nothing will have /dev/vda open in the initramfs.
<slangasek> smoser: can I see the udev log from this system?  I want to see what attributes are on /dev/vda1
<smoser> slangasek, can i get that from the booted system ?
<slangasek> smoser: /var/log/udev.log
<smoser> i can give you access to the system just as easily
<slangasek> (thanks to coldplugging)
<slangasek> either way then :)
<slangasek> SpamapS: do you have a pointer handy to one of those recommendations?  I'm specifically interested at the moment in the context of bug #569757
<ubottu> Launchpad bug 569757 in nis (Ubuntu) "NIS upstart dependency broken for lucid" [High,Triaged] https://launchpad.net/bugs/569757
<slangasek> SpamapS: dunno if you're following the debian-devel upstart thread?
<smoser> udev log is at http://paste.ubuntu.com/859585/
<smoser> and, slangasek you can get to ubuntu@10.55.60.153 via chinstrap
<slangasek> smoser: ok; so it's line 75 of /lib/udev/rules.d/60-persistent-storage.rules
<slangasek> which seems legitimate here
<slangasek> smoser: I think the problem is your initramfs script is not event driven, and hasn't waited for the kernel to say the disk is ready
<slangasek> sorry, for udev to say
<SpamapS> slangasek: no, I am woefully behind on debian-devel.. ;)
<smoser> slangasek, i dont know.
<smoser> it runs at local-bttom
<smoser> after rootfs has been mounted once already
<smoser> and mounted via LABEL also
<slangasek> smoser: hmm!
<smoser> so i would have thought that that would have already occurred
<slangasek> yes
<slangasek> except the main mounting script is also not event driven AFAIK :)
<smoser> slangasek, well it uses wait-for-root
<smoser> which is linked to udev i think
<smoser> (verified it is linked to udev)
<SpamapS> slangasek: probably the best example of how it can be used is bug #643289 .. recommended it in comment 14
<ubottu> Launchpad bug 643289 in nfs-utils (Ubuntu Lucid) "idmapd does not starts to work after system reboot" [High,Triaged] https://launchpad.net/bugs/643289
<slangasek> SpamapS: so the nis case is interesting, because what we need to implement here is the equivalent of an LSB "Should-Start" rule
<slangasek> SpamapS: wait-for-state doesn't DT"R"T for non-existent jobs
<slangasek> so I can't just call start wait-for-state WAITER=autofs WAIT_FOR=ypbind in the autofs pre-start
<infinity> smoser: Wait, why are you growing root in local-bottom?
<slangasek> infinity: clouuuud
<infinity> smoser: That would be where your code differs from jasper, we do it in local-premount.
<slangasek> SpamapS: I *can* create a job in the nis package called start-ypbind that's 'start on starting autofs' and calls 'start wait-for-state', but that's kinda the wrong place for it to live
<infinity> smoser: Doing it post-mount just seems to be asking for this sort of trouble.
<slangasek> infinity: why?  I'm not seeing why unmounting the partition should generate new udev events
<infinity> slangasek: No, but why mount/umount/resize/remount?
<smoser> infinity, i chose post-mount because i could guarantee that at that point the device was available
<smoser> othe rthan that , i'd have to do the wait-for-root before the real wait-for-root
<smoser> but... same problem would occur i think.
<slangasek> smoser: 'premount' is called from /usr/share/initramfs-tools/scripts/local right before it's about to mount the device.
<slangasek> smoser: so you don't need to wait-for-root because the script's already done it for you
<smoser> slangasek, right. i dont at *that* point
<smoser> but i do have to afterwards
<smoser> as the sfdisk generates events that might delete it temporarily
<smoser> slangasek, well, i forget why i did premount
<infinity> Do you go straight from resizing into mounting and starting?
<smoser> er... why i did not do premount
<smoser> but really, why would that be any different
<infinity> We do premount-resize, then trigger a reboot in bottom.
<smoser> mount and umount should not create events to udev, and the one that runs earlier just seems *more* prone to errors.
<smoser> infinity, i dont want to reboot
<infinity> Fair enough.
<infinity> But there's a solution for that too.
<slangasek> smoser: I don't see any reason for errors in either case, but if you do it in premount, you're doing it at precisely the point that initramfs-tools says the device is ready for use
<infinity> Your resize script (if it were in premount) could re-scan for partitions/devices before exiting.
<slangasek> infinity: does that, that's why we're getting the error ;)
<smoser> slangasek, i can try the local-premount (or look into why i didn't use that originally)
<smoser> but i don tthink its going to change much really.
<SpamapS> slangasek: roger. I think we can make it react more appropriately for a job that does not exist.
<SpamapS> slangasek: have to work on some other stuff for a while today.. will return to this later
<slangasek> smoser: well, it reduces complexity a little bit, you don't have to umount / remount... you just have to resize, reread, probably call wait-for-root again for the benefit of the local script, and exit
<slangasek> smoser: this may fix the bug in which case it's an easy win, and if it doesn't it gives us less to search through
<slangasek> SpamapS: ok - mostly wanted to check that you agree it should be done by adjusting wait-for-state
<slangasek> SpamapS: if so, I'll go ahead with uploading nis
<infinity> slangasek: The error may be coming from the partition scan, but that's only because the device was previously busy anyway (it threw an error on resize too).
<infinity> slangasek / smoser: My gut feeling is that growing and rescanning in premount will Just Work (and I don't see why you'd need to retrigger wait-for-root after the rescan, we already know the device is there).
<slangasek> infinity: we know the device was there before fiddling with the partitions again; I don't know if we get new events for the partitions when resized
<slangasek> infinity: and the resize failed only in that it failed to reread the partition table afterwards
<slangasek> the actual resizing succeeded (as it should)
<smoser> slangasek, i'm reading init from the initramfs
<smoser> and it seems to me that local-premount is before wait-for-root
<slangasek> smoser: no, local-premount isn't called from init at all.  *local*-premount, not *init*-premount
<slangasek> smoser: the difference is critical here :)
<slangasek> local-foo are "the set of scripts run when the root filesystem is a local filesystem"
<slangasek> and are all run from scripts/local
<infinity> local does, basically, wait-for-root && premount && mount
<smoser> yeah, i see that.
<slangasek> well, it does top && wait-for-root && premount && mount
<slangasek> && bottom :P
<infinity> Still, if premount successfully re-rereads the table, I don't see need for a second wait-for-root.
 * infinity shrugs.
<slangasek> because the ioctl for the table reread is not going to wait for udev before returning
<slangasek> (because it a) can't, b) shouldn't)
<infinity> Oh, there's that.
<infinity> Fair enough.
<slangasek> so if udev goes mucking about in /dev afterwards, it's racy
<infinity> Not onerous to add a wait-for-root to the premount mucking script anyway.
<slangasek> yes; there's already one in there as it is
<slangasek> just the umount/mount need to be dropped
<bdmurray> ScottK: Do you think bug 940789 is a duplicate of bug 927855?
<ubottu> Launchpad bug 940789 in update-manager (Ubuntu) ""Obsolete packages will be removed" dialogue is too tall for netbook screen with KDE front end" [Undecided,New] https://launchpad.net/bugs/940789
<ubottu> Launchpad bug 927855 in update-manager (Ubuntu) "window size too large to see buttons after expanding details" [Undecided,Confirmed] https://launchpad.net/bugs/927855
<smoser> hm..
<smoser> i really think this is a goose chase
<smoser> but i will oblige and try in local-premount, making necessary changes.
<infinity> smoser: I'm not sure it's a goose chase at all.  Not mounting the FS certainly leads to one less possible way that the device could be busy, right?
<bluefoxicy> so
<slangasek> smoser: even if it doesn't fix it, infinity is right that this is the better and simpler way to do what you're doing
<bluefoxicy> I am playing with zram
<infinity> smoser: (And umounting doesn't guarantee a device isn't busy)
<bluefoxicy> is there any interest in this?
<infinity> bluefoxicy: We use it on the ac100 images.
<slangasek> so if it doesn't fix it, we have less of an area remaining to search for the bug in :)
<bluefoxicy> infinity:  I think it's appropriate roughly "everywhere" to use compressed memory because of the CPU/swap trade-off inequality.
<bluefoxicy> in other words I think my desktop doesn't give a crap that it's squeezing 4, 8, 16 kilobytes of data into a compressed swap area, but it sure takes a beating thrashing disk
<infinity> bluefoxicy: Except that most modern desktops really don't swap often at all.
<smoser> slangasek, infinity ah.
<smoser> i see at least one reason i used post-mount
<bluefoxicy> infinity:  servers?
<infinity> bluefoxicy: The reason we use it on the ac100 is a combination of limited RAM and slow/fagile storage.
<smoser> i check some files in the mount that may indicate "do not grow this"
<smoser> (ie, to be configurable)
<bluefoxicy> infinity:  the real problem with all this to me is no hibernate file
<infinity> bluefoxicy: I'd contend that any server that swaps frequently has admins that need to look at fixing it. :P
<bluefoxicy> your desktop has 16 gigs of RAM, you don't have to swap, good for you.  You can't hibernate :P
<bluefoxicy> infinity:  I'd contend that a software fix that extends performance without requiring additional money sunk into additional hardware is a fix :)
<slangasek> smoser: oh, ok :/
<smoser> its also something i would like to not lose.
<infinity> bluefoxicy: But it doesn't extend performance on a system with an appropriate amount of RAM for the workload, it degrades it.
<bluefoxicy> Only if it gets used.
<infinity> smoser: What's the use-case for that?
<smoser> but... if i have to in order to acutally have functional code in the default case i'd drop it.
<bluefoxicy> That's the thing:  if you don't extend past the end of memory, you never use any of this
<infinity> bluefoxicy: But your zram swap is more likely to be hit if you, say, have 1/2 your RAM configured as zram swap.
<infinity> bluefoxicy: zram doesn't come from thin air.
<slangasek> smoser: well, shot in the dark - how about another wait-for-root call after your umount and before your growpart?
<smoser> infinity, i'm not really sure, othe rthan to allow this code to be disabled without re-building the image
<infinity> bluefoxicy: If you use part of RAM for zram, you lose it as RAM.
<bluefoxicy> infinity:  not true.  If you have 4GB of RAM and set 2GB as zram swap, you can use 3.5GB of physical RAM without swapping to zram.
<infinity> smoser: boot argument?
<slangasek> smoser: if you had to lose that config code, I guess you could offer configuration via kernel ^^ infinity fast
<smoser> initially, the idea was that we would only run this once per "instance", but then we ended up changing that because on ec2, you can 'start instance', 'stop instance', 'grow volunme', 'start instance'
<bluefoxicy> infinity: zram doesn't preallocate memory; it dynamically allocates it in the same way as tmpfs.  So if you're storing nothing on the device, it doesn't use any RAM.
<bluefoxicy> bluefox@icebox:~$ cat /sys/block/zram0/disksize
<bluefoxicy> 1073741824  [In bytes]
<bluefoxicy> bluefox@icebox:~$ cat /sys/block/zram0/mem_used_total
<bluefoxicy> 270336
<ScottK> bdmurray: It could be.  I'm not sure if the code that drives window size is -common or front end unique.
<smoser> yeah, slangasek infinity kernel command line update is actually significantly more difficult in many ways that adding a file
<slangasek> yeah, I was afraid of that
<infinity> It is?
<infinity> Mmkay.
<smoser> well, at very least it means updating grub config rather than touching a file
<broder> smoser: how are people supposed to create that flagfile? publishing their own ami?
<broder> oh wait, right, you still can't customize the initrd. nvm
<smoser> broder, yeah, that is really the only way. you're right, thats not terribly easy.
<smoser> you can customize the initramfs now, broder, it is read and loaded via pv-grub
<smoser> but yeah, that is possibly one reason i did it that way...
<smoser> history
<smoser> i'll try this now and see.
<broder> smoser: oh, ok. so then, if people already have to publish their own ami, could they disable the expansion at initrd-build time?
<slangasek> you can simply omit the cloud-initramfs-tools package then?
<smoser> broder, yeah, its definitely doable. i'm surprised i didn't actually add anything that would allow you to do that.
<smoser> but yeah, just removing woudl do it.
<exarkun> Anyone want to talk about https://bugs.launchpad.net/ubuntu/+source/twisted/+bug/668955 https://bugs.launchpad.net/ubuntu/+source/twisted/+bug/788965 https://bugs.launchpad.net/ubuntu/+source/twisted/+bug/810405 https://bugs.launchpad.net/ubuntu/+source/twisted/+bug/814933 https://bugs.launchpad.net/ubuntu/+source/twisted/+bug/815130 https://bugs.launchpad.net/ubuntu/+source/twisted/+bug/627654 ?
<ubottu> Launchpad bug 668955 in twisted (Ubuntu) "package python-twisted-core 10.1.0-2 failed to install/upgrade: el subproceso script post-installation instalado devolviÃ³ el cÃ³digo de salida de error 2" [Undecided,New]
<ubottu> Launchpad bug 788965 in twisted (Ubuntu) "package python-twisted-core 10.2.0-1 failed to install/upgrade: ErrorMessage: subproces installed post-installation script gaf een foutwaarde 1 terug" [Undecided,New]
<ubottu> Launchpad bug 810405 in twisted (Ubuntu) "package python-twisted-core 10.2.0-1 failed to install/upgrade: subproces installed post-installation script gaf een foutwaarde 1 terug" [Undecided,New]
<ubottu> Launchpad bug 814933 in twisted (Ubuntu) "package python-twisted-core 10.0.0-2ubuntu2 [modified: usr/share/pyshared/twisted/python/dxprofile.py] failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New]
<ubottu> Launchpad bug 815130 in twisted (Ubuntu) "package python-twisted-core 10.2.0-1 failed to install/upgrade: ErrorMessage: Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurÃ¼ck" [Undecided,New]
<slangasek> would perhaps be nice to have it configurable, since c-i-t ships two scripts (growroot + rescuevol)
<smoser> slangasek, well they're thir own packages.
<smoser> each could be deleted
<slangasek> oh
<slangasek> well there you go then
<smoser> yea.
<slangasek> seems sufficient to me
<seb128> could some buildds admin bump the score for https://launchpad.net/~sil2100/+archive/ppa/+build/3244412 https://launchpad.net/~sil2100/+archive/ppa/+build/3244413
<smoser> but, same as grub config, removing a package is obviosly more diffiicult than touchign a file.
<smoser> but i'll go down this route
<smoser> hoping that it will allow us to undertsand what is going wrong.
<stgraber> seb128: done
<seb128> thanks
<slangasek> exarkun: what specifically would you like to talk about?
<exarkun> slangasek: whether I should mark them all as duplicates.  which I just did, because I'm not always very patient.
<slangasek> exarkun: they're not duplicates at all, please undo this
<slangasek> one of them doesn't even have the same exit code as the others, and aside from two from the same user, they each have different error messages in the log
<exarkun> slangasek: They're all caused by failing hardware corrupting package data, and then the failure being incorrectly handled by the installation tools.
<slangasek> exarkun: please don't consider "post-installation script returned error exit status 1" sufficient reason to dupe bugs
<exarkun> Packages can be corrupted in a lot of different ways, I'm sure
<slangasek> no
<slangasek> where do you see evidence of hardware corruption in each of these?
<exarkun> lack of evidence to the contrary, behavior unreproducable by anyone else
<exarkun> "Illegal Instruction" from an executable
<exarkun> Looks pretty hardware-faily to me.  Actually I didn't link to that one, sorry: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/941269
<ubottu> Launchpad bug 941269 in software-center (Ubuntu) "package software-center 5.1.9 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Undecided,Confirmed]
<slangasek> exarkun: there has been no analysis at all on bug #788965 that supports this theory that it's hardware corruption.
<ubottu> Launchpad bug 941269 in software-center (Ubuntu) "duplicate for #788965 package software-center 5.1.9 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Undecided,Confirmed] https://launchpad.net/bugs/941269
<exarkun> slangasek: I offered my analysis.
<slangasek> Sorry: TypeError: ('compile() expected string without null bytes',)
<slangasek> there's no evidence that anyone even tried to reproduce the bug with the set of packages the user had installed
<slangasek> jumping to the conclusion that it's filesystem corruption just because there are other bugs reported against this package which are caused by filesystem corruption isn't logical
<exarkun> Okay, I'm sure you're right.  I'll go back to ignoring these bug reports.
<exarkun> (so they can sit for years with no comment)
<infinity> geser: Did you decide not to resurrect vim's changelog history, or did someone else sponsor your upload before you could? :P
<infinity> geser: I was entirely serious about that particular changelog having sentimental value to a lot of developers.  I think I'll just reject that upload and re-sponsor it with the changelog intact. ;)
<slangasek> SpamapS: I'm having second thoughts about putting the wait-for-state check in autofs, because that means running extra scripts at boot time that are *only* useful when nis is installed
<slangasek> if you don't have nis installed, they just slow the boot down for no reason
<slangasek> so blah
<SpamapS> slangasek: yeah, seems like nis should have that script
<SpamapS> slangasek: you can always cancel a starting job and take it over with start on starting...
<SpamapS> slangasek: though I haven't thought this through, and I need caffeine/food so ignore me ;)
<slangasek> :)
<slangasek> SpamapS: my current thoughts: http://paste.ubuntu.com/859688/
<slangasek> the "cron" part should maybe go away though, because cron is smart enough now to detect when names become resolvable
<slangasek> broder: can I easily get access to the lintian lab?
<broder> slangasek: uh, i don't have anything setup for it at the moment. if you'd like to wait 20-30 minutes, i can get off my rear and finally set something up. otherwise, i can run things for you
<slangasek> broder: I'm looking for 'grep -l 'Should-Start:.*ypbind' /etc/init.d/*'
<slangasek> but I may have another way to run it that's nearly as fast
<smoser> slangasek, well, in so far 3 tries, i've yet to make the it fail at local-premount
<smoser> i'm running some more... as 3 isn't very definitive
<slangasek> smoser: sure :)
<smoser> can you come up with any reason why that blkid would have been running though?
<broder> slangasek: running now
<smoser> i'm really not interested in changing code without a reason, as
<smoser> a.) i already did that once for this bug :)
<slangasek> smoser: sure, something generating a change event on the kernel device
<smoser> b.) it seems that 11.10, 11.04, 10.10 are also vulnerable to this
<slangasek> smoser: as part of the blkrrpart ioctl
<smoser> but what would have done that?
<slangasek> some aspect of the kernel driver
<smoser> and why would we think that prior to mount of root anything would be different for *that*
<slangasek> oh no, sorry
<slangasek> this is blkid running *while* we're trying to call blkrrpart
<smoser> right.
<slangasek> so what would cause the event, hmm
<slangasek> you can probably argue that it's a kernel bug
<smoser> because if we dont know what would have done it, then i have a hard time coming up with a reason it can't happen during premount either.
<smoser> s/either/also/
<slangasek> well, the only thing going on here that *could* do it, AFAICS, is the mount/umount
<slangasek> and if it is, I think that's a kernel bug
<slangasek> but of a sort that's probably hard to isolate and fix
<smoser> slangasek, well, i can't seem to trigger the mount/umount in a loop in user space
<smoser> (unfortunately i cant reproduce any of this cleanly outside of first boot)
<smoser> and it only started showing up withen we upgraded to precise kvm and openstack
<smoser> which obviously changed a bunch of timings
<smoser> slangasek, if it were triggered by mount/umount, you would think that it could be triggeref by somethin glike:
<smoser>  while : ; do mount ext4-dev /mnt && umount ext4-dev /mnt ; done
<smoser> and watching udev
<smoser> and i think that nothing happens
<smoser> (i can test that, but basically ou'r asserting that some udev event would fire based on that)
<smoser> (i think)
<smoser> unless you have some reason that that mount/umount early in boot would trigger something that subsequent mount/umount wouldnt
<slangasek> smoser: nope
<smoser> so then at this point, the best justification for a change from local-bottom to local-premount is that "it seems simpler"
<smoser> (and testing seems to change the race conditions)
<slangasek> no, it's that the *only possible* thing we've found that could be racing is something triggered off by the mount/umount
<slangasek> even if we don't understand it
<smoser> do udev events have timestamps on them?
<smoser> ie, when the kenrel fired this event, could i get a timestamp of when it did it ?
<smoser> because then, if i could, and verify that no events came from the kernel *after* mount/umount, then i'd know that it wasn't during that
<slangasek> smoser: what you see in /var/log/udev is what you get
<slangasek> so there's a "time since boot" in the header line
<smoser> but is that udev recieved ?
<smoser> or kernel generated
<slangasek> udev received
<smoser> well, at least its something
<slangasek> broder: so on second thought, I think I actually want this scan done against Debian unstable anyway :-)
<smoser> i'll add some 'cat /proc/uptime' and see if i cant dgrock anything from it.
<smoser> slangasek, thank you for your help, btw
<broder> slangasek: ah, can't help you there
<slangasek> broder: yep - no worries
<TheMuso> infinity: Done.
<infinity> TheMuso: \o/
<smoser> slangasek, http://paste.ubuntu.com/859728/
<smoser> thats pastebin of console output of this instance at
<slangasek> smoser: doesn't let me in
<smoser> ubuntu@10.55.60.167
<smoser> (sorry, was slow)
<smoser> slangasek, ^
<smoser> but that one didn't catch the blkid in 'ps'
<slangasek> pulled the IP from the log :)
<slangasek> but it's still not letting me ssh in
<smoser> slangasek, vorlon@dario.dodds.net as your ssh id ?
<smoser> slangasek, and i did get a failed resize
<smoser> after move to pre-mount
<smoser> 2 out of 29
<slangasek> smoser: yes - it lets me in now where it didn't before
<slangasek> hmm, curiouser and curiouser
<smoser> unfortunately, that ami doesn't have the 'ps -w' in it
<smoser> so i dont have ps output
<smoser> hm..
<smoser> slangasek, one thing.
<smoser> i did not 'udevadm settle' before sfdisk in pre-mount
<ricotz> slangasek, hello
<ricotz> slangasek, do you know why libpst wasnt updated since karmic? https://launchpad.net/ubuntu/+source/libpst
<ricotz> i am pinging you because you are one who touched it ;)
<seb128> ricotz, because nobod maintains it in Ubuntu and Debian doesn't have a newer version so most likely nobody noticed it was outdated
<slangasek> smoser: just a hunch... can you call sfdisk with --no-reread?
<seb128> ricotz, there is no bug open asking for an update either
<smoser> we had another bug on that.
<slangasek> ricotz: what seb128 said; the only thing I touched on the package was to fix a build failure
<infinity> slangasek: Oh hey, jasper does that too.
<ricotz> seb128, i see, i guess this is worth an update
<infinity> slangasek: I wonder if there may have been a reason. :P
<seb128> ricotz, you are welcome to work on that, I would be happy to review,sponsor your update ;-)
<seb128> ricotz, it might require a ffe if the update is not only bug fix though
<smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/906722 slangasek <--
<ricotz> seb128, alright, this version is from karmic ;)
<ubottu> Launchpad bug 906722 in cloud-initramfs-tools (Ubuntu) "root partition is not being grown" [High,Fix released]
<ricotz> seb128, fta updated it for some testbuilds of evolution 3.3 which requires this newer version
<seb128> ok
<slangasek> smoser, infinity: by default, sfdisk calls ioctl(BLKRRPART) before it edits things, and again *after*... and if the ioctl is itself triggering a udev change, then there's nowhere in your script to intercept it because it's happening while a single sfdisk command is running
<ricotz> seb128, alright, i have a look
<seb128> ricotz, thanks
<smoser> slangasek, oh. yuck.
<smoser> i didn't realize that.
<smoser> that sucks.
<smoser> so that is a general issue with sfdisk then
<smoser> that will fail at other times also
<smoser> as the first will *cause* the second to fail
<smoser> slangasek, so i'm guessing you're looking at code
<slangasek> smoser: again, if there haven't been any geometry changes, and the ioctl causes this problem, I think you're looking at a kernel bug
<slangasek> (and the first time we call the ioctl, there shouldn't be any geometry changes)
<slangasek> yep
<smoser> slangasek, actually i'm almost certain that it does cause udev events
<smoser> hold on. thats easy to check
<slangasek> it shouldn't, because nothing has changed
<slangasek> you only want change events when the geometry has actually changed; the kernel should be smarter about that
<slangasek> anyway, --no-reread is correct for what you're doing
<slangasek> the extra reread is pointless here because you know the state of the system in the initramfs
<smoser> yeah.
<smoser> and it doesn't seem to.
<smoser> slangasek, so your theory here is that if i add '--no-reread', and that fixes it
<smoser> then all we're doing is masking a kernel bug
<slangasek> well, we're fixing a minor bug in the invocation of sfdisk, and confirming a bug in the kernel
<smoser> ok. so, i'll poke at this a bit later.
<smoser> you think 'growpart' should generically pass that ?
<slangasek> yes
<smoser> as it is accounting for failure, and replacing it
<smoser> (ie, growpart wont always only be called from initramfs, or at least that was a goal in writing it)
<slangasek> well
<slangasek> I think I would assume that the disks are in a sane state before someone's called growpart on them anyway
<slangasek> but if you think that's not a safe assumption, growpart can grow an option itself
<smoser> right. i think probably sane, or maybe add a '--no-no-reread'
<smoser> :)
<broder> jdstrand: ah, sorry bug #884402 got left in the queue - i've been meaning to deal based on russ's feedbac
<ubottu> Launchpad bug 884402 in shibboleth-sp2 (Ubuntu) "package libapache2-mod-shib2 2.4.3+dfsg-1ubuntu1 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [Undecided,Triaged] https://launchpad.net/bugs/884402
<broder> (we managed to convince him that his postinst was wrong, but we can't just sync it because there are significant pending changes on the debian side)
<geser> infinity: it got sponsored before I could add a debdiff with a complete changelog, so I didn't replace the debdiff afterwards
<geser> infinity: I'll update the debdiff if you reject the current upload
<infinity> geser: I already fixed it.
<geser> thx
<geser> will remember on future merges to keep old changelog entries forever
<seb128> geser, why so?
<geser> seb128: I dropped old changelog entries (800 lines of Ubuntu changelog entries from lucid back to warty) in my last vim merge which infinity prefers to keep
<seb128> ok, we drop those for desktop and I do the same for other stuff I merge usually
<seb128> so I take a not to not merge stuff infinity's maintains ;-)
<infinity> geser: I'm not sure that's necessary (or even desirable) for most packages/mergs, but vim's a special and weird case. ;)
<infinity> seb128: Surely, you remember the upload wars to all get in in the same 5-minute window and see whose vim would get accepted? :P
<seb128> lol
<infinity> geser: Anyhow, yeah.  Not a big deal, and not a policy, per se, to retain changelogs for ever (unless they actually still reference our delta in some meaningful way), but there's some old skool project nostalgia with vim specifically.
<infinity> geser: And possibly base-files. ;)
<geser> infinity: I would have expected setting background=dark for vim by default would cause more discussion than my trimming of old changelog entries
<infinity> geser: Nah, because background=dark is the One True Way.
<infinity> geser: People with white terminals are wrong.  Full stop.
<infinity> geser: (And as this is clearly a religious argument, not a scientific one, there's no need for me to back up that assertion with evidence, and it's protected by various constitutions!)
<infinity> geser: Of course, it could also be that it's still sitting in the unapproved queue.
<geser> infinity: so no objections for background=light for gvim either (or do you don't care about gvim)?
<infinity> geser: That seems reasonable as a default, but I don't use gvim, which is probably why I don't care. ;)
<slangasek> infinity: can you think of a way offhand to get dash to read contents from a file and pass the contents to another command on the commandline, without forking to get the file contents?
<slangasek> ( $(< /path/to/file) is a bashism )
<broder> slangasek: doesn't $(< /path/to/file) fork?
<slangasek> broder: shouldn't
<broder> oh i see. i didn't realize that was special-cased syntax
<slangasek> there's no command
<slangasek> you're just asking for the contents of the file
<broder> i figured it was a shortcut for $(exec </path/to/file) or something
<slangasek> broder: I don't suppose you can think of a more posix-y way to do this? :)
<broder> i assume the lack of forking is important?
<slangasek> broder: upstart :/
<broder> expect daemon and add another fork somewhere? :)
<slangasek> it already needs to be expect daemon
<jdstrand> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Freeze in effect.  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:
<broder> aren't you good, then? i thought upstart was fine with several forks before the actual double-fork happened
<slangasek> broder: no, it counts forks
<SpamapS> broder: nope, 1 or 2.. or 'tis broken
<SpamapS> I really wish we could just trust daemons to tell us what their main pid is (i.e., pidfiles)
<broder> err, i wasn't clear. i meant rather that you could fork off stuff in the script section as long as none of them forked again
<infinity> slangasek: Of the top of my head, I can't think of a way to do that without forking. :/
 * slangasek nods
<infinity> slangasek: http://paste.ubuntu.com/859877/ ?
<infinity> slangasek: Or is FD manipulation out too?
<slangasek> infinity: no, that's acceptable as long as it doesn't trigger a fork :)
<slangasek> let's see, can I just do while read ... do done < $FILE without generating a subshell?
<infinity> slangasek: Maybe?
<infinity> strace doesn't look forky to me.
<slangasek> yep, that does the trick
<slangasek> evil
<slangasek> infinity: thanks :)
#ubuntu-devel 2012-02-28
<slangasek> SpamapS: so I have an experimental myodbc package now that will build against mysql-5.5 finally
<SpamapS> slangasek: !!
<SpamapS> slangasek: I've been shunning even looking at that hoping you'd figure it out
<slangasek> upon prodding, I've disabled building the testsuite... since we can't run the darn thing anyway at build time :P
<slangasek> SpamapS: where did we leave off?  Do I need to sponsor mysql-5.5 in with the _r.so compat fix?
<SpamapS> slangasek: for Debian there's additional work needed to push back the stuff I've done for precise.
<slangasek> mmk
<SpamapS> slangasek: I think actually all of it is legitimate ubuntu-only delta
<SpamapS> slangasek: though eventually I'd like to get back in sync.. maybe after precise releases.
<SpamapS> slangasek: I am working on preparing 5.1.61 packaging for stable as well.. since we're forced to release that as the security update
<SpamapS> slangasek: meanwhile my DD app drips through the process like mollasses on a cold day.
<slangasek> heh
<broder> from my read of the new livecd-rootfs, it looks like we're not actually using the .iso that live-build generates, but just grabbing the stuff out of binary/ and reusing it somewhere else. is that right?
<SpamapS> slangasek: anyway, it would appear that we're down then to just sphinxseach for libmysqlclient..
<SpamapS> I believe a new upstream version came out recently that might address the last few issues.
<slangasek> broder: yes, we feed live-build artifacts into debian-cd so it can stick a germinated archive on the side
<slangasek> SpamapS: ah, ok
<slangasek> SpamapS: as for nis, I've dropped a comment on bug #569757... wondering what you think we should do
<ubottu> Launchpad bug 569757 in nis (Ubuntu) "NIS upstart dependency broken for lucid" [High,Triaged] https://launchpad.net/bugs/569757
<slangasek> (looking for feedback before I upload this to precise, since if you don't want us to go this route, it makes the SRU upgrade path harder)
<SpamapS> slangasek: reviewing
<SpamapS> slangasek: just a thought that I keep having.. we should look at patching portmap/rpcbind to use 'start on socket' in the next release. It would make this *much* simpler.
<SpamapS> slangasek: same goes for the NFS jobs too.. no more ON_BOOT thingy
<slangasek> the NFS stuff isn't going to be that easy
<slangasek> in part because it has to wait for /usr
<slangasek> I suppose it shouldn't hurt to make portmap 'start on socket'
<SpamapS> slangasek: ugh.. I just noticed.. upstart-socket-bridge isn't really built in.. so we'd have to start on started that anyway.. argh.
<slangasek> hah
<SpamapS> was that one of those TODO's still left on Keybuk's plate?
<slangasek> I don't know
<SpamapS> Seems like upstart is already watching a few sockets.. :-P
<broder> i think it was deliberate that the socket bridge live as a separate binary
<broder> you shouldn't have to wait for the socket bridge to start though
<broder> err, the thing that wanted to use the socket would have to, though
<SpamapS> broder: right, thats the point
<slangasek> yes, and that's exactly what has to wait on portmap now :)
<slangasek> SpamapS: I'm guessing this was an overlooked bug
 * broder promises to stop jumping in mid-conversation without thinking for at *least* the next 5 minutes
<SpamapS> :)
<SpamapS> broder: at least you *thought* at one point. :)
<SpamapS> I'm having a harder and harder time doing that today..
<SpamapS> slangasek: your loop in the ypbind post-start hits a bug I recently discovered in polling post-starts ..
<slangasek> oh?
<SpamapS> slangasek: mysql had it too. If the job respawns or is stopped .. the polling doesn't stop.
<slangasek> hmm, I think there's a bug report for that already
<slangasek> possibly from you
<SpamapS> slangasek: but the respawn doesn't actually get tried until post-start exits
<SpamapS> slangasek: yeah there is
<SpamapS> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/mysql-5.5/precise/revision/16
<SpamapS> bug 711635
<ubottu> Launchpad bug 711635 in mysql-5.5 (Ubuntu) "init: post-start can cause respawn to hang" [High,In progress] https://launchpad.net/bugs/711635
<SpamapS> slangasek: in the workaround.. you have to drop the respawn limit lower.. because that sleep 1 always gets hit at least one time
<slangasek> ah, I meant an open bug on upstart
<SpamapS> slangasek: 711635 is also against upstart :)
<slangasek> ah right
<SpamapS> I don't actually know what upstart should do.. but its definitely confusing the way it works right now.
<SpamapS> I'm kind of hoping the 'expect exit' stuff will do away with most of the times where people use post-start to poll like that.
<slangasek> oh hah, yes, this is the bit where it will never *hit* the respawn limit because the post-start script takes too long, blah
<slangasek> well, none of the usual 'expect's work for ypbind
<slangasek> it daemonizes and then goes looking for a directory source
<SpamapS> heh, so it also has races already?
<slangasek> built in
<slangasek> this post-start is copied from the init script
<SpamapS> slangasek: are we in danger of breaking shutdown for some daemons by stopping on runlevel [!2345] ?
<SpamapS> slangasek: like if a daemon needs to lookup users to run its shutdown..  would we be breaking it?
<slangasek> potentially, but that's not a regression vs. pre-lucid or debian so I figured I'd let someone else sort that out
<SpamapS> slangasek: agreed. Other than the looping bug I'd say this is good to go.
<slangasek> ok
<slangasek> looking to see if there's a way I can make the post-start fail faster in the case where ypbind isn't running
<SpamapS> slangasek: well you could actually check for respawn before the check for the socket....
<SpamapS> slangasek: that would give a better chance at hitting the default 10 respawns in 5 seconds limit
<slangasek> SpamapS: hmm? how would I check for respawn within the script?
<pitti> Good morning
<ajmitch> morning pitti
<pitti> stgraber: accepting ltsp-cluster-agent for now, but please convert to dh_python2; it currently b-deps on pycentral, although I'm not sure that it actually uses that
<SpamapS> slangasek: status shows it as a status.. start/respawn
<slangasek> SpamapS: hmm?  how are you forcing it to respawn, just killing the process?
<SpamapS> slangasek: if the process dies, upstart notes that and marks state as "respawn".. but it does not do another state transition until the post-start exits
<slangasek> SpamapS: sure - you're seeing this in the wild, or you're testing it by killing the process?
<SpamapS> slangasek: so in post-start at any time you can see if the process has died and is going to be respawned, and react
<SpamapS> slangasek: I saw this with mysql when it had an invalid configuration
<slangasek> oh, you're responding to my earlier question, aren't you :)
<slangasek> right, so we could call status to get the info, cool
<SpamapS> slangasek: mysql already does this to hasten the reaction time to horribly broken mysql configs
<dholbach> good morning
<dholbach> geser's merge of vim seems to have been rejected and I can't find an explanation in https://lists.ubuntu.com/archives/ubuntu-archive/2012-February/thread.html or in the mail I received
<pitti> dholbach: there is one in unapproved: https://launchpad.net/ubuntu/precise/+queue?queue_state=1
<dholbach> aha
<dholbach> thanks pitti
<micahg> dholbach: there was a sacrilegious removal of a sentimental comment apparently :)
<dholbach> :-)
<dholbach> pitti, do you think you could move libquvi-scripts to main, so we can get libquvi to build?
<pitti> dholbach: I just did
<dholbach> ah, sweet :)
<geser> dholbach: see this channel around 23:00 (local time), infinity had feelings about the removed changelog entries and re-uploaded my vim merge with complete changelog
<geser> dholbach: http://irclogs.ubuntu.com/2012/02/27/%23ubuntu-devel.html#t20:27 and http://irclogs.ubuntu.com/2012/02/27/%23ubuntu-devel.html#t22:25
<dholbach> geser, ok, I see
<AnAnt> Hello, Debian has a new revision of fribidi which is multi-arch enabled (it should be in testing within a day or two), would it be possible to sync it after beta release ?
<tumbleweed> AnAnt: file an FFe
<AnAnt> ok
<tumbleweed> there are a fair number of reverse-depends, you'll need to check that they don't have hardcoded paths
<jokerdino> hey devs, just a question regarding https://bugs.launchpad.net/ubuntu/+source/usermode/+bug/602680
<ubottu> Launchpad bug 602680 in One Hundred Paper Cuts "Description: About Myself" [Low,Triaged]
<jokerdino> the original assignee has gone awol for quite some time. and I don't mind fixing it. anything that i can do about that?
<dholbach> Laney, goocanvas and gda bindings are in now - it looks like the way is clear to get glom in again too
<dholbach> I'm going to be a busy in the next days - do you think either you or seb128 could take a look at the current package in the openismus ppa?
<pitti> Laney: btw, now would be an excellent time to start a haskell transition -- all buildds are idling
<Laney> dholbach: nice, will see if I can get time but others are more than free to do it
<Laney> pitti: aye, now would be good indeed to get ghc itself built in time for freeze ending
<Laney> iulian is going to do the ghc upload
<seb128> Laney, seems you are busy, I will try to have a look, ping me before looking at it in case you do so we don't dup work
<seb128> dholbach, ^
<janimo`> micahg, chrisccoulson hi, is either of you looking at the armhf chromium ftbfs?
<ogra_> janimo`, i think micahg and infinity looked into it recently, seems to be a multiarch/naming issue
<ogra_> not sure thesy came to any result, i just saw them discussion the issue
<ogra_> *discussing
<janimo`> ogra_, ok, indeed looks like an include path not being set to the gnueabihf dir
<ogra_> if you have a quick fix, please go ahead ;)
<janimo`> no idea if the fix sits committed somewhere though.
 * ogra_ thinks then we would have also seen an upload
<janimo`> no quick fix, just wondering whether I should start investigating myself, there's no bug discussion
<ogra_> i think they planned to revisit it after B1
 * dholbach hugs seb128 and Laney
 * seb128 hugs back
<jokerdino> hmm guys is branching from lp:gedit same as lp:lp:~ubuntu-desktop/gedit/ubuntu
<jokerdino> ?
<seb128> jokerdino, no
<seb128> lp:gedit is an upstream import of full source without packaging
<jokerdino> i see.
<seb128> lp:~ubuntu-desktop/gedit/ubuntu is the packaging vcs which contains de debian dir only
<jokerdino> so, if i want to submit a patch, i will be using the ubuntu-desktop branch..
<jokerdino> what if ubuntu is the main stream?
<jokerdino> (for software-center, unity, etc)
<seb128> jokerdino, you usually want to use debcheckout
<seb128> jokerdino, or apt-get source
<seb128> jokerdino, i.e
<seb128> $ apt-get source gedit
<seb128> ...
<seb128> NOTICE: 'gedit' packaging is maintained in the 'Bzr' version control system at:
<seb128> https://code.launchpad.net/~ubuntu-desktop/gedit/ubuntu
<jokerdino> ah, i have been doing this incorrectly the whole time :/
<seb128> jokerdino, the "standard" location for packages is ubuntu:<source> but if there a vcs in the control you should use this one
<seb128> debcheckout has this logic and should give you the right source
<jokerdino> hmm, thanks!
<jokerdino> so, if i want to patch something, how do i proceed?
<seb128> jokerdino, desktop thing?
<seb128> jokerdino, https://wiki.ubuntu.com/DesktopTeam/Bzr
<jokerdino> i proposed a patch for gedit quicklist earlier.
<jokerdino> i branched from lp:gedit and made the changes by branching locally and deriving a diff file
<seb128> jokerdino, basically bzr get lp:~ubuntu-desktop/gedit/ubuntu; cd ubuntu; bzr bd-do; edit patch; exit 0
<jokerdino> and then i attached the patch to the bug report.
<seb128> jokerdino, you can just add a debdiff or diff to a bug if you prefer
<seb128> that works fine
<seb128> jokerdino, I put those patches review on hold since we are frozen for beta1 and we need to sort of some details on those unity list instructions
<seb128> jokerdino, especially we need to sort out what's the standard wording we want and a minor detail with the syntax, I will review your patch in a few days
<jokerdino> ah, cool.
<seb128> jokerdino, sorry about that, we noticed some issues in consistency when we started reviewing patches, especially on capitalization of the text used
<seb128> so we need to sort those out before merging in
<jokerdino> i am fine, either way.
<jokerdino> and, one small addition.
<jokerdino> custom groups in a desktop file should have a X- in front. please do update the unity quicklist api..
<seb128> jokerdino, yeah, sorry, the syntax is about to change, I will fix those when merging
<seb128> jokerdino, see https://wiki.ubuntu.com/Unity/LauncherAPI?action=diff&rev2=32&rev1=31
<seb128> jokerdino, the wiki got updated yesterday
<jokerdino> oh awesome, i didn't check it yet.
<seb128> jokerdino, it's an accepted xdg spec now, and the syntax has changed a bit, the code supports both though
<jokerdino> well yeah the code supports both, but desktop-file-validate invalidates it, as you pointed out in the bug report.
<jokerdino> X-Ayatana-Desktop-Shortcuts=X-Screen;X-Window
<jokerdino> [X-Screen Shortcut Group]
<seb128> jokerdino, right, using the updated way should work fine
<jokerdino> should be like that ^
<seb128> ie with action groups
<jokerdino> so, the proposed way is to do like [Desktop Action Screen], right?
<jokerdino> i mean recommended, not proposed.
<seb128> jokerdino, yes, what the current wiki describe
<jokerdino> seb128: there should be a colon (;) after the last Actions entry.
<seb128> jokerdino, thanks, it's a wiki feel free to add it
<seb128> i.e you can probably edit the page ;-)
<jokerdino> Heh :)
<jokerdino> wiki has been updated.
<jokerdino> (by adding a single character)
<jokerdino> should I then proceed to update my patch?
<seb128> jokerdino, yes ;-)
<jokerdino> cheers seb128, patch has been updated.
<jokerdino> and i have removed the older patches.
<seb128> jokerdino, thanks, I will review it a bit later
<doko> zul, python-tz tries to test the installed pytz, ... and ftbfs ...
<zul> doko: ok ill have a look
<larsduesing> Hi together
<larsduesing> Short question, how to get a patch I wrote and put to a ppa into ubuntu?
<larsduesing> (I think I made some error in launchpad...)
<larsduesing> (hopefully, this is the right place...)
<ScottK> barry: Would you have time to look at Bug 942408?
<ubottu> Launchpad bug 942408 in python-support (Ubuntu) "python-support not cleaning up during Lucid -> Precise upgrade" [Undecided,New] https://launchpad.net/bugs/942408
<ScottK> larsduesing: File a bug (or find an existing one), attach the patch to it, and then subscribe the ubuntu-sponsors team to the bug.  Someone will review it for inclusion.
<larsduesing> ah...
<larsduesing> thanks ScottK ... #223825
<larsduesing> Oh.. 223825 is the bug
<larsduesing> (i made it fix released
<larsduesing> in error...
<larsduesing> hmm... ubottu is not liking me..
<apw> jodh, wondering what inotify events upstart uses to monitor its configurations
<ScottK> larsduesing: I moved it back to Triaged.
<brendand> bug 223825
<ubottu> Launchpad bug 223825 in aiccu (Ubuntu) "aiccu init.d script will race dhclient (upstart issue?)" [Undecided,Triaged] https://launchpad.net/bugs/223825
<larsduesing> thanks ScottK
<ScottK> You're welcome.
<larsduesing> ah you have to add bug in front of the number to get ubottu like you... *learn*
<jodh> apw: (IN_CREATE | IN_DELETE | IN_CLOSE_WRITE| IN_MOVE | IN_MOVE_SELF)
<apw> jodh, against /etc/init ?
<jodh> apw: yes.
<stgraber> pitti: thanks
<stgraber> highvoltage: saw pitti's comment above on ltsp-cluster-agent* and pycentral?
<highvoltage> stgraber: I have now. I was planning on doing that a few weeks back but got hasty when feature freeze approached. (I uploaded them 8s before FF). I can still fix that, right?
<barry> ScottK: sure
<ScottK> barry: Thanks.
<pitti> highvoltage: yes, of course
<stgraber> highvoltage: yes, though you may need a FFe for that (easy one to get though) as changing the build system may trigger side effects
<highvoltage> stgraber: ok
<pitti> is it using pycentral anyway?
<pitti> debian/rules had no indication of this
<pitti> it might just be an obsolete build depends
<stgraber> pitti: I'd have to look at exactly what highvoltage uploaded as I believe he made some changes on my initial packaging. ltsp-cluster-agent definitely ships a python module so it might be using pycentral (was using python-support before) and would need a switch to dh_python2 if that's the case. ltsp-cluster-agent-weblive just ships a bunch of files, no python modules so shouldn't need pycentral/pysupport anyway.
<stgraber> (ouch, that was a long line, wondering if it got cut...)
<highvoltage> it seems to have made it. last part was "pycentral/pysupport anyway."
<barry> is anybody look at the python-tz ftbfs? https://launchpadlibrarian.net/94621468/buildlog_ubuntu-precise-i386.python-tz_2011k-0ubuntu4_FAILEDTOBUILD.txt.gz
<ScottK> barry: zul is supposed to look into it.
<barry> ScottK, zul: okay
<siretart> Is the beta freeze a soft freeze or are all uploads moderated? I've prepared a fix for lightdm and would like to upload it to the archive. I'm OK for it to hit the archive after beta release
<ogra_> siretart, all uploads are moderated atm. and i'm not sure putting lightdm into the queue would be a clever thing, in the case wheer we might find a serious bug during testing in lightdm your upload would have to be recected before the fix goes in if we dont want it on the image
<ogra_> siretart, but better ask the release manager :) (skaet) in #ubuntu-release
<seb128> siretart, what fix?
<skaet> siretart, its a hard freeze - we're only letting release critical fixes through for the seeded images.
<seb128> siretart, better to get review for lightdm changes, it's not like we didn't have active maintainers
<siretart> seb128: https://bugs.launchpad.net/lightdm/+bug/877766
<ubottu> Launchpad bug 877766 in lightdm (Ubuntu Oneiric) "lightdm login fails with NFS home and strict (mode 0700) permissions" [Medium,Triaged]
<siretart> the patch is obvious, and I have personally tested it on a spare machine at our lab
<siretart> and we really should SRU that patch
<siretart> the patch is in the linked bzr branch
<seb128> siretart, can you put a merge request against lp:lightdm on? I mentioned that to robert_ancell before and he looked at it but I think he had some concerns
<seb128> siretart, or it was breaking some tests in the testsuit
<seb128> he said he needed to do some work before landing it I think
<siretart> seb128: is having the patch as quilt in my packaging branch a problem for requesting a merge for lp:lightdm?
<seb128> siretart, yes, can you bzr branch lp:lightdm, apply you patch, bzr commit, bzr push lp:~sirestart/lightdm/nfs and propose it for merging?
<seb128> siretart, I'm not sure robert_ancell keeps up with bug emails, he does with merge requests though
<siretart> how annoying :/
<siretart> I'll put that on my todo list
<seb128> siretart, it's not that hard...
<seb128> siretart, I will ping him again about the patch
<seb128> siretart, but I'm sure review would be easier in a merge request
<siretart> let's please don't argue about necessary or silly burocracy
<seb128> siretart, it's not "silly burocracy"
<seb128> siretart, it's "people don't keep up with thousand of bug emails a week so don't see your comments"
<Sweetshark> dammit launchpad! *shaking-angry-grandpa-fist*
<Sweetshark> how do I get rid of this stupid duplicate libreoffice (openSUSE) tracker on bug 562027
<ubottu> Launchpad bug 562027 in libreoffice (Ubuntu Lucid) "[Upstream] Unable to shutdown / reboot / logout when quickstarter is active" [Undecided,Confirmed] https://launchpad.net/bugs/562027
<Sweetshark> ?
<ScottK> Sweetshark: I think you want #launchpad.
<ScottK> siretart: I'd upload it, but I'm not a fan of silly bureaucray either.
<stgraber> Sweetshark: so you want to drop the opensuse task entirely?
<Sweetshark> stgraber: at least get rid of the duplicate tracked bug at freedesktop ...
<Sweetshark> stgraber: funny thing is: there is a minus button behind almost all the other remote trackers, but not behind baltix and opensuse ....
<stgraber> Sweetshark: hmm, yeah, the UI is confusing and forcing it gives me a LP oops ... you'll need #launchpad
<ScottK> Anyone having trouble with pbuilder on a oneiric host system.  With --debug, I get "ignoring trap saveaptcache_umountproc_cleanbuildplace_trap exit sighup"
<ScottK> (right before it dies with E: Invalide operation)
<smoser> slangasek, bug 942788
<ubottu> Launchpad bug 942788 in util-linux (Ubuntu) "sfdisk without --no-reread is likely to cause race conditions" [Undecided,New] https://launchpad.net/bugs/942788
<smoser> slangasek, your hunch on --no-reread is correct. sfdisk is broken-by-design if udev is running and you do not pass --no-reread.
<smoser> infinity, ^
<slangasek> smoser: does this affects disks other than vda?
<smoser> if you're using sfdisk, you need to be using --no-reread.
<smoser> slangasek, yes.
<slangasek> interesting
<smoser> theres a shell snippet in the bug there.
<smoser> just run that somewhere and it will fail eventually.
<infinity> smoser: I wonder if we're using no-reread in jasper because we ran into that problem, or by sheer luck of cargo-culting from elsewhere. :P
<infinity> smoser: And as I mentioned yesterday, we're using no-reread already. :)
<smoser> ah.
<slangasek> smoser: oh, but your snippet uses /dev/vdb ;)  My question is, does this affect other storage backends or is there something about this driver (virtio?) causing the issue
<smoser> slangasek, i think its all backends.
<slangasek> tested though?
<smoser> (i thought your question about vda was "root")
<smoser> well, smb has seen it on xvdb
<slangasek> ok
<smoser> err.. a xenblock device.
<smoser> its very clearly broken.
<smoser> basically: blockdev --rereadpt; blockdev --rereadpt;
<smoser> the second one is almost certain to fail at some point.
<smoser> i dont have a non-virtual system with an un-used block device or i would test
<slangasek> smoser: could you do one more test and capture 'udevadm monitor -e' output while you're running sfdisk?
<smb> Given that there will be an event for each partition and the main device for remove and then for each partition and the main device after scanning, it could be "worse" the more partitions there are...
<slangasek> smoser: n/m, found a usb stick here to test with - confirmed that I get change events on reread even when there are no changes to the table
<slangasek> so yeah, it's universal
<smb> slangasek, Right, this is not intelligent, it just drops all knowledge and re-iterates
<smoser> slangasek, attached to bug.
<smoser> slangasek, smb, thank you both for your help.
 * smoser goes to fix bug 937352 the right way
<ubottu> Launchpad bug 937352 in cloud-initramfs-tools (Ubuntu) "root partition may not be grown" [Undecided,In progress] https://launchpad.net/bugs/937352
<smoser> smb, so what do we think about the 'udevadm settle' that we added to growroot before invoking growpart (which in turn invokes sfdisk)
<smoser> after the disk is mounted, do we think we need that settle?
<smoser> or do we think, since a partition on $DEV has been mounted, that udev events related to it have been finished.
<smoser> i guess it might just be safest to leave it there.
<smb> smoser, Well, I think it jsut should not hurt much and at least helps to ensure anything that began before has sort of quieted down
<smoser> yeah.
<kklimonda> is there something in debian policy preventing packages from shipping scripts that meddle with files in /usr/share (creating new ones) in the directories owned by those packages?
<kklimonda> for some reason I don't like it ;)
<kklimonda> (freeipa server install script configures apache to use /usr/share/ipa/wsgi.py which will serve a custom html file (and some other things)
<slangasek> kklimonda: the FHS says /usr is for static files; scripts generating data there are generally non-compliant
<iulian> pitti, Laney: Do you want me to upload GHC now? I have it ready, just need to push the button and fire the missiles.
<iulian> We'd have to apply the two patches from http://hackage.haskell.org/trac/ghc/ticket/5824 in order to fix the arm{el,hf} build failures.
<micahg> janimo`: no, I don't have a fix, if you have one verified, I'm happy to commit it an upload (chromium is seeded in mythbuntu and lubuntu though, so we'd have to be sure that it builds and won't affect the other archs)
<janimo`> micahg, no fix here. I touched chromium only once before and its build system is not the easiest to grok. No idea where the cflags are figured out
<micahg> janimo`: should be in the gyp files, unfortunately, I have more pressing things to look at ATM, I can poke Debian's build to see if they have a fix (but  don't remember seeing one)
<janimo`> micahg, I did not see one either in debian, no prob though
<micahg> janimo`: will multiarch allow you to run the armel builds for now?
<janimo`> yes
<micahg> \o/ progress :)
<janimo`> you mean armel chromium on armhf right?
<micahg> yes :)
<janimo`> then s/yes/probably/. Never tested :)
<micahg> I wish armel would build on the stable releases, but that's another story :)
<janimo`> I do not particularly need chromium on armhf now, just going through the FTBFS
<micahg> janimo`: you have time to bootstrap gnat-4.6? :D
 * janimo` runs away in horror
<janimo`> infinity is the masochistic one, he should do it
<micahg> wow, something more scary than chromium's build system :)
<smoser> stgraber, hallyn how bad is this:
<smoser> http://paste.ubuntu.com/861085/
<smoser> should i even bother checking /proc/1/cgroup ?
<smoser> i realize its very limited
<hallyn> smoser: well, you might do that *after* the other checks.  i.e. if running-in-container is available, use it.
<hallyn> if it isn't available,
<hallyn> then chances are init hasn't moved itself toanother cgroup
<smoser> k
<stgraber> hallyn: +1
<hallyn> that's not to say initramfs couldn't be messing with you, so it's not 100%
<hallyn> systemd moves itself to /systemd very early on
<hallyn> (i think.  maybe not.  maybe it just sets it up for user sessions)
<smoser> hallyn,
<smoser> i just created a container
<smoser> logged in with ubuntu ubuntu
<smoser> and then tried sudo
<smoser> oh..
<smoser> and its prompting me for a password
<smoser> (i justrealized i had a password)
<smoser> duh
<infinity> micahg, janimo`: gnat's being worked on.
<micahg> infinity: ah, good :)
<doko> infinity, if you build gnat for armhf, you might want to disable multilibs
<elmo> where do the modules in a d-i rescuse environment come from?
<elmo> and are any more available?
<elmo> hmm *-modules-* udebs, butthey're not in Contents
<infinity> elmo: They're in main/debian-installer/binary-*/Packages*, I assume.
<elmo> infinity: sure, but not the individual files
<infinity> Oh, no.
<elmo> but a for loop and dpkg -c confirms ipmi isn't any of them
<Daviey> elmo: http://archive.ubuntu.com/ubuntu/dists/lucid/main/installer-amd64/current/images/udeb.list ?
<elmo> what would be the right package for a bug asking for new modules?  the kernel?
<infinity> elmo: If it's kernel modules you're after, yeah.
<elmo> infinity: cool, thanks
<elmo> Daviey: ta also
<bryceh> elmo, can you give me `lspci -vn | grep VGA` on the box you saw the compiz crash on a couple hours ago?  want to verify this is sandybridge specific
<elmo> 00:02.0 0300: 8086:0126 (rev 09) (prog-if 00 [VGA controller])
<elmo> bryceh: ^--
<elmo> bryceh: deej (Canonical) also saw it, FWIW
<bryceh> elmo, thanks.  snb-m-gt2+ in your case
<bryceh> elmo, also was this with a dual head or external monitor set up by chance?
<elmo> bryceh: nope, vanilla laptop display
<bryceh> hmm!  interesting
<bryceh> elmo, ok thanks.
<elmo> bryceh: no prob
<mahmoh> are armhf precise containers working? What I'm doing wrong?  If I enter the container it appears to work fine but I'm trying to execute commands externally to get info. from within - http://paste.ubuntu.com/861153/
<stgraber> mahmoh: lxc-attach isn't supported by our kernel
<stgraber> mahmoh: and lxc-execute is only for single application container, not for system containers
<stgraber> mahmoh: in your case you'll want "lxc-console -n <container>" then login and run whatever you want
<mahmoh> stgraber: ok, thank you for that info.; is there a plan to support -attach or no?
<mahmoh> stgraber: and shouldn't it emit a message like, unsupported kernel feature?
<stgraber> mahmoh: we're waiting on the patches to enter the upstream kernel, so that won't be there for 12.04 at least
<mahmoh> Daniel's patches?
<stgraber> mahmoh: hallyn is working on the new server guide which will mention what commands work and what don't and why, I agree lxc-attach could print something slightly more useful though :)
<mahmoh> stgraber: :) thx again
<stgraber> mahmoh: yeah, IIRC the pid_ns attach patch is a patch from Daniel and reworked by Eric Biederman
<stgraber> mahmoh: http://git.kernel.org/?p=linux/kernel/git/ebiederm/linux-namespace-control-devel.git;a=summary
<mahmoh> I saw that for Natty and just imagined it would have been in by now
<mahmoh> stgraber: btw, thx for that blog post earlier this month ;)
<elmo> bryceh: I have an up to date stacktrace in #942799 but the duplicate checker deleted all the data :)
<elmo> bryceh: is there any easy way for me to re-submit the data?
<seb128> elmo, tag the "master" bug "apport-request-retrace"
<seb128> elmo, that will make the retracer attach the stacktrace of the next duplicate to the master rather than clean it
<bryceh> seb128, that was already done
<seb128> elmo, well tag the master and then resubmit
<seb128> bryceh, and it didn't work?
<bryceh> checking
<bryceh> doesn't look like it
<seb128> bryceh, elmo's bug was retraced before you tagged
<seb128> elmo, can you resubmit it?
<bryceh> ah
<elmo> seb128: as in, just rerun apport and open a new bug?
<seb128> elmo, yes
<elmo> cool, will do
<elmo> thanks
<seb128> elmo, the master bug got tagged so next retrace will be attached rather than cleaned
<seb128> elmo, thank you
<bryceh> seb128, is this a changed behavior?  Seems like it used to do retracing on dupes too, but am I just remembering wrong?
<seb128> bryceh, you are remembering wrong
<seb128> bryceh, we can't make apport retracing public without checking for password etc
<seb128> bryceh, so duplicates always got cleaned and set to public
<elmo> damn, apport-bug's tab complete is hella slow
<seb128> bryceh, it's not ideal but the alternative is to get somebody to manually review all the duplicates to mark them public if appropriate
<seb128> which is often tedious and not that useful
<elmo> should I retarget this at mesa?
<elmo> it's trying to report it against unity
<seb128> elmo, no
<elmo> (sorry for all the dumb questions)
<elmo> ok
<seb128> elmo, worth case it doesn't dup it and you get a new stacktrace anyway :p
<bryceh> actually targeting at mesa would be nice; it would collect a lot of the missing X files we're currently missing on this one
<elmo> doh
<elmo> bryceh: what files do you want?  I'll just add them by hand
<seb128> bryceh, I don't think you can do that for segfaults
<elmo> ah, I see in your reply to salgado
<elmo> adding
<seb128> bryceh, like you can change the component once you are on launchpad but that will not change the collecting job
<seb128> bryceh, it always collects the infos for the package which did hit the segfault
<bryceh> elmo, yep, thanks
<bryceh> seb128, you keep making me sadder ;-)
<seb128> bryceh, sorry :(
<seb128> bryceh, good news is that apport is open source and the maintainer is responsive so we can get it improved ;-)
<bryceh> seb128, well seems you're right about dupe crashes having their useful info excised, now that I look.  Probably I'm thinking of gpu lockup bugs where we collect register dumps (that won't ever have passwords or other such stuff.)
<bryceh> seb128, that is cold comfort; from what you say most of these issues are policy not lack-of-fix
<seb128> bryceh, well that's why we got that tag telling the retracer to get an updated stacktrace
<seb128> that should cover most cases, like if you care about the bug it's likely because users still hit it
<bryceh> seb128, but yes it's open source.  I've sent in a patch to fix one of our more annoying issues we see but am still waiting (for some months) on the branch to get picked up.
<bryceh> seb128, yes, it's good to know about that tag.
<seb128> bryceh, on apport?
<bryceh> seb128, yeah
<seb128> bryceh, https://code.launchpad.net/~bryce/apport/source_lookup/+merge/81172 ?
<seb128> bryceh, pitti wrong a long reply, it seems blocked on you to write back ?
<bryceh> seb128, no, I spoke to him in person about it at UDS
<seb128> oh ok
<bryceh> guess it can't hurt to add a comment though.
<elmo> bryceh: added to 942966
<bryceh> elmo,  thanks.  lp isn't displaying it, but will try again in a bit
<elmo> bryceh: meh, publicized
<seb128> bryceh, elmo: it's private until retracer picks it up
<bryceh> bingo, there we go
<bryceh> hoho, and a core dump!  lucky day
<seb128> bryceh, get the coredump saved before the retracer gets there if you need it ;-)
<elmo> I'd only just booted my machine, there can't possibly be anything interesting in that coredump
<elmo> (that would require privacy I mean)
<bryceh> seb128, trust me, I know
<bryceh> elmo, I have it locally and will not be posting it anywhere.
<bryceh> (and it will be deleted when I'm done with it)
<seb128> bryceh, elmo: retracing done, it updated the master bug as wanted: https://launchpadlibrarian.net/94731013/Stacktrace.txt
#ubuntu-devel 2012-02-29
<bryceh> hud sure spews a lot of errors and warnings
<bryceh> think those are all subsequent to the crash though
<bryceh> interesting; elmo's stacktrace does not match the one upstream
<smoser> if someone can help, i *just now* uploaded a cloudinit at http://paste.ubuntu.com/861292/
<smoser> it fixes 2 bugs that i'd like to have fixed in beta1
<smoser> but i am willing to have someone say "no, not important enough" or "no, too late".
<lynxman> jdstrand: ping
 * smoser is out. if anyone can ACK that though, i'd appreciate it. but otherwise, it can just land the other side of beta.
<dachary> Hi, I wonder how long it takes for a package in Debian testing ( http://qa.debian.org/developer.php?packages=libbpp-core ) reach ubuntu ( https://launchpad.net/ubuntu/+source/libbpp-core ) ? Does it require a manual operation ?
<RAOF> dachary: It depends on the time of the Ubuntu cycle.
<dachary> RAOF: at this time does it require a manual intervention ?
<RAOF> dachary: At *this* point in the cycle (after DebianImportFreeze) it's manual.  Also, we're after FeatureFreeze, so if the package introduces a new feature it needs justification.
<dachary> it's not about https://wiki.ubuntu.com/StableReleaseUpdates just yet, I guess ;-)
<dachary> oh
<RAOF> Finally, we're currently in BetaFreeze, so there's basically no chance until the Beta is released.
<broder> that's not true for packages in universe/multiverse
<dachary> broder: I should have mentionned these packages are in universe. The rule is different there ?
<broder> as long as they're not on an image, beta freeze mostly doesn't apply (they have to be approved, but it's virtually automatic)
<broder> but FF and DIF are still relevant
<dachary> There are a few new features in this set of bioinformatics packages http://biopp.univ-montp2.fr/wiki/index.php/Packaging
<dachary> broder: does that mean they will be rejected even if they are in universe ?
<dachary> I would like to make sure I'm not missing an opportunity to have them in the next ubuntu release. But if the rules say it can't, they will have to be obeyed ;-)
<broder> dachary: it means that you have to manually request the sync (because it's post-DIF), and get a FeatureFreezeException approved (because it's post-FF), and that if the sync was sponsored right now, it would be held for approval (due to BF), but that it would with high certainty get waved through the beta freeze queue
<dachary> broder: that's hopefull :-)
<dachary> border thanks for the help. I'll proceed with https://wiki.ubuntu.com/SyncRequestProcess and https://wiki.ubuntu.com/FreezeExceptionProcess
<bryceh> elmo, thanks again for your help.  I've been in contact with Intel and it's marked as a priority issue for investigation with them.
<slangasek> smoser: please use #ubuntu-release for such questions rather than relying on someone to catch it in scrollback on #ubuntu-devel... :)
<pitti> Good morning
<pitti> iulian: you can upload stuff at any time; during the freeze it'll be caught in unapproved, and you should poke in #ubuntu-release to get it through quickly; but yes, ghc seems fine now
<micahg> I think that was discussed on Friday and it was decided that after beta 1 would be easiest
<pitti> ok
<pitti> well, I guess I can use the buildds to do some rebuilds for bug 875466
<ubottu> Launchpad bug 875466 in libxt (Ubuntu Precise) "Lots of packages shipping with broken md5sums" [Medium,In progress] https://launchpad.net/bugs/875466
<larsduesing> hi together
<larsduesing> a small question about creating patches
<larsduesing> in a project there is a patch named "01_no-shipped-init-script.patch"
<larsduesing> which uses debian/$PROJECT.init.debian to be copied
<larsduesing> now I am building an upstart patch
<pitti> that sounds overly complicated
<larsduesing> so this patch is no longer neccesary...
<larsduesing> Is it advisable to kill this 01_patch alltogether?
<pitti> a patch that creates debian/project.init.d ?
<larsduesing> no
<larsduesing> it is more funny
<larsduesing> --
<pitti> larsduesing: it's a little vague, but just build the package and see what comes out of it
<larsduesing> 01_no-shipped-init-script.patch:-	@echo "Installing Debian-style init.d"
<larsduesing> 01_no-shipped-init-script.patch:-	@mkdir -p ${DESTDIR}${diretc}init.d
<larsduesing> 01_no-shipped-init-script.patch:-	@cp doc/${PROJECT}.init.debian ${DESTDIR}${diretc}init.d/${PROJECT}
<larsduesing> 01_no-shipped-init-script.patch:+#	@echo "Installing Debian-style init.d"
<larsduesing> 01_no-shipped-init-script.patch:+#	@mkdir -p ${DESTDIR}${diretc}init.d
<larsduesing> 01_no-shipped-init-script.patch:+#	@cp doc/${PROJECT}.init.debian ${DESTDIR}${diretc}init.d/${PROJECT}
<larsduesing> ---
<pitti> larsduesing: in general, if you just have debian/project.upstart, dh_installinit will do the right thing
<larsduesing> it is even commented out... :)
<pitti> larsduesing: no, the patch comments it out, i. e. disables it
<pitti> so you need to keep that
<larsduesing> ah... yes
<pitti> as you still don't want the init script
<larsduesing> i saw this NOW... sorry
<larsduesing> :)
<larsduesing> yes, it's about Makefile
<larsduesing> sorry
<larsduesing> sorry, another question...
<larsduesing> in ubuntu i cannot use dch --nmu --close bug#, correct?
<larsduesing> (it querries the debian bug-database...)
<RAOF> larsduesing: I think you can, but (a) we don't have NMUs (because we don't have maintainers), and (b) --close will add a closes tag for the BTS, rather than Launchpad; that's probably not what you're after.
<rickspencer3> good morning/evening all
<pitti> hey rickspencer3
<rickspencer3> pitti, Daviey what's the word on the street for beta1? looking good?
<pitti> rickspencer3: no catastrophes that I could see, anyway
 * rickspencer3 eyes precice_probs and smoke tests
<rickspencer3> pitti, good to hear ... it's nice to see the archive and smoke tests are in good shape
<pitti> rickspencer3: ISO tracker for ubuntu images has just one red bug, which is a xubuntu bug and already fixed; it seems it just got mis-placed
<pitti> rickspencer3: precise_probs has that long-standing problem of the new armadaxp kernel, but it's not really user-visible
<pitti> rickspencer3: openjdk will be fixed once it finishes building on arm*
<pitti> rickspencer3: upgrades are a bit unstable unfortunately, bug 927993
<ubottu> Launchpad bug 927993 in apt (Ubuntu Precise) "distribution upgrade from lucid to precise failed with : package dpkg is already installed and configured" [High,Triaged] https://launchpad.net/bugs/927993
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Freeze in effect.  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: didrocks
<YokoZar> larsduesing: btw, the Ubuntu equivalent of Debian's Closes is to put (LP: #123456) in a changelog entry
<YokoZar> This will automatically fix-released the bug when the package hits the archive (provided the bug is filed against that package)
<larsduesing> YokoZar: thanks
<larsduesing> hmm...
<larsduesing> sorry...
<larsduesing> how to get quilt to delete a file?
<larsduesing> (not a patch, but a file in debian/ )
<larsduesing> (I think I am in a complete wrong way... I want to make a patch which exchanges init.d to upstart... ONE Change out of the debian-dir, all others are in debian...)
<larsduesing> (this patch is to be given to ubuntu-sponsors
<pitti> larsduesing: just delete the file
<pitti> we don't patch files in debian/
<larsduesing> ok, so a patch for sponsors should be a normal diff?
<larsduesing> (and nothing with quilt ?
<pitti> yes, ideally a debdiff between the current package and your new one
<pitti> i. e. debdiff foo_current.dsc foo_new.dsc
<larsduesing> ok
<larsduesing> but in new should be a changelog-entry?
<pitti> yes, of course; any change you need to make
<larsduesing> ok
<larsduesing> thanks
<dholbach> good morning
<dholbach> pitti, nothing like a few rebuilds in the morning, right? :)
<pitti> dholbach: yeah, felt like the buildds needed to produce some heat :)
<pitti> they were getting bored and crummy
<dholbach> can somebody please reject https://code.launchpad.net/~maxolasersquad/ubuntu/precise/stellarium/add_quicklist/+merge/94312?
<pitti> dholbach: *zap*
<dholbach> thanks pitti :)
<larsduesing> is anybody able to set bug 223825 to triaged?
<ubottu> Launchpad bug 223825 in aiccu (Ubuntu) "aiccu init.d script will race dhclient (upstart issue?)" [Undecided,In progress] https://launchpad.net/bugs/223825
<pitti> larsduesing: yes, but "in progress" seems appropriate as there is a patch now and you are workign on it?
<larsduesing> pitti: patch is completed... (and working since more than half a year in my ppa)
<larsduesing> so what type is to be set?
<larsduesing> *sorry* I'm rather new to all this :(
<pitti> larsduesing: ah, sponsors are subscribed already
<pitti> larsduesing: that's pretty much it then
<larsduesing> sponsors and sru
<larsduesing> ok
<pitti> larsduesing: btw, no need to remove debian/aiccu.init.d
<larsduesing> thanks for your help
<pitti> larsduesing: instead, you should call dh_installinit with --upstart-only
<pitti> (smaller diff)
<larsduesing> so I should put a new diff?
<pitti> larsduesing: hang on, you don't even need --upstart-only; if .upstart exists, that will be used
<pitti> larsduesing: would make it easier for sponsors, yes (and you can do another final test build)
<larsduesing> but the init.d is the source of that bug
<larsduesing> (I did a build - but interestingly on updating /etc/init.d/aiccu WON'T be deleted :( )
<pitti> larsduesing: yes, but that's not because you removed debian/init.d
<pitti> larsduesing: the init script is a dpkg-managed configuration file, and you need to remove it manually in maintainer scripts
<pitti> larsduesing: see man dpkg-maintscript-helper
<larsduesing> arghs, so I have to edit these, too?
<pitti> larsduesing: if you don't feel up to this, please mention it in the bug, so that the sponsor can add the necessary bis
<pitti> bits
<larsduesing> I'm able, but I'm learning still
<larsduesing> (and if I do it not myself, I will never learn...)
<pitti> larsduesing: no, it's actually enough to add a debian/aiccu.maintscript with something like "rm_conffile /etc/init.d/aiccu 20070115-14.1"
<pitti> larsduesing: the dpkg-maintscript-helper manpage explains the problem with conffiles, and how to remove them on upgrade
<larsduesing> ok
<pitti> fortunately it's relatively easy to do this these days with .maintscript
<larsduesing> there is no debian/*.maintscript
<larsduesing> only .postrm
<larsduesing> (and pre*/post*.debhelper)
<pitti> yes, you need to create it
<larsduesing> ok
<larsduesing> *reading*
<larsduesing> :)
<larsduesing> thanks pitti
<pitti> larsduesing: kein Problem :)
<larsduesing> *g*
<larsduesing> pitti - so I should leave the buggy init.d-script in place?
<pitti> larsduesing: yes, it won't be installed if there is an .upstart script as well (see man dh_installinit)
<larsduesing> ok
<pitti> that reduces the delta with debian
<pitti> i. e. the packaging difference
<larsduesing> yes
<larsduesing> I understand
<larsduesing> still one question - should I update debian/control Standads-Version: 3.9.1 to 3.9.2 ?
<larsduesing> lintian mentions it...
<infinity> No.
<infinity> Not unless you're planning to take over upstream maintenance too.
<larsduesing> ok
<pitti> larsduesing: that'd be unnecessarily diverging from Debian, indeed, so we leave it
<infinity> Also, rm_conffile surely isn't enough in this case, you'd also want an update-rc.d remove?
<infinity> Or you leave a mess of dangling symlinks.
<larsduesing> oh
<larsduesing> that's right...
<larsduesing> so somewhere put an "update-rc.d aiccu disable"?
<infinity> larsduesing: Not disable, remove.
<larsduesing> ah, yes...
<larsduesing> sure
<larsduesing> infinity: aiccu.postinst.debhelper DOES that
<larsduesing> # Automatically added by dh_installinit
<larsduesing> update-rc.d -f aiccu remove >/dev/null || exit $?
<pitti> isn't that just on "remove", not on "upgrade"?
<larsduesing> "aiccu.postinst.debhelper"
<larsduesing> I read that, do that after installing
<pitti> larsduesing: righht, but this line is usually surrounded by if [ "$1" = "purge" ]
<infinity> I'd actually be shocked if it's there at all after dh_installinit switches to installing an upstart script instead.
<infinity> (Have you made that change yet?)
<larsduesing> pitti: no dependencies for that line
<pitti> nice, magic
<pitti> so perhaps dh_installinit is clever enough to do that by itself then
<broder> uh, are you guys sure? it makes perfect sense for dh_installinit to cleanup the rc*.d symlinks if you start shipping an upstart job
<larsduesing> I HATE magic, esp. if I don't understand it
<pitti> broder: yes, it does, but I wasn't aware that it does that by itself
<infinity> broder: I don't think it makes sense at all for it to universally have that in every upstart-using package (and I'm betting it doesn't).
<larsduesing> so, I'll try an update.. let's see
<larsduesing> :)
<broder> looks like it adds it unless you specify --upstart-only
<broder> err, wait, and unless some other things
<pitti> so that was probably added so that maintainers don't have to add the same snippet over and over again
<infinity> I suppose.  But then they'll be there "forever".  I guess it doesn't hurt, unless the user adds their own init script with the same name, assuming some silly maintainer script that doesn't own the file won't mess with them.
 * infinity shrugs.
<pitti> infinity: remove only removes symlinks if the script doesn't exist
<infinity> True.
<infinity> So, it's just a lot of unnecessary noops.
<infinity> Good thing it's Perl instead of Python, so it doesn't take 5 seconds to run and do nothing? ;)
<larsduesing> hmm
<larsduesing> I am running into problems...
<larsduesing> *checking again*
<larsduesing> nothing had been deleted
<larsduesing> *checking*
<larsduesing> arghs
<larsduesing> in postinst there is an "exit 0" - and dh_installinit is in the last lines
<larsduesing> (and I enterered nothing in the config, therefore I ran into the exit 0)
<larsduesing> with correct settings it is ok
<larsduesing> thanks
<larsduesing> so, I'll publish new patch
<larsduesing> thanks infinity and pitti (and sorry for so many newbie-questions and -errors... :) )
<pitti> larsduesing: np; conffile handling isn't exactly a newbie topic
<larsduesing> I learned a bunch of new things... mission accomplished :)
<didrocks> dholbach: guten morgen, how are you?
<dholbach> hey didrocks
<dholbach> good good
<dholbach> how about you?
<didrocks> dholbach: piloting, seeing that all keywords patch have no changelog, inline patches, not to the correct branch, but well, in easy brain-off mode :)
<didrocks> dholbach: I'm trying to get a good text for commenting on them, do you have wiki page handy explaining shortly having a patch in quilt + changelog?
<dholbach> didrocks, here's what I did: https://code.launchpad.net/~maxolasersquad/ubuntu/precise/smplayer/add_quicklist/+merge/94500
<didrocks> dholbach: ah excellent! was looking for a model :)
<didrocks> dholbach: was exactly what I needed, thanks!
 * dholbach hugs didrocks
 * didrocks hugs dholbach back
<dholbach> didrocks, one thing I was wondering about: how are you going to do it? are you going to use their email address or yours?
<dholbach> personally, I used theirs, so it would be indicated as their contribution in LP - but I'm not sure how everybody else does it
<didrocks> dholbach: well, we will only upload that part of GNOME .91
<didrocks> dholbach: as*
<dholbach> aha!
<didrocks> dholbach: so I'm adding the [ â¦ ]
<dholbach> ok :)
<didrocks> yeah, the one making the .91 update on the component will win the sponsoring :)
<didrocks> not me on the chart :p
<didrocks> dholbach: I'm also sending that upstream FYI
<didrocks> (as there is no indication it has been done)
<dholbach> didrocks, for future reference , I would give them a link to a "forwarding patches to gnome" wiki page, so they do it themselves next time
<didrocks> dholbach: yeah, and stating in the merge that it was done :)
<dholbach> yeah
 * dholbach hugs didrocks
<didrocks> right now, doing the call for help is easy and we are taking all the extra load :/
<didrocks> so anything in that regard will be appreciate!
<didrocks> appreciated :)
<dholbach> yes
<larsduesing> oh, I'm sort of late, ubuntu is in freeze already...
<dholbach> SpamapS, smoser: are you going to figure out https://code.launchpad.net/~smoser/ubuntu/precise/sysvinit/rc.local.d/+merge/88323? (I'm trying to get older merge proposals off the list :-))
<dholbach> pitti, do you think it'd be OK to reject https://code.launchpad.net/~pali/ubuntu/natty/plymouth/plymouth/+merge/61897 based on broder's comment?
<pitti> dholbach: yes, absolutely; there is no chance that we'll upload this
<pitti> and not for oneiric anyway
<pitti> (rejected)
<dholbach> stgraber, are we still going to get https://code.launchpad.net/~sdeziel/ubuntu/oneiric/openvpn/subnet-icmp-disable/+merge/90740 into precise?
<dholbach> thanks a lot pitti
<Amoz> dholbach, oh hai
<dholbach> hey Amoz
<Amoz> I'm running precise with latest updates, I think the battery indicator in gnome-shell is freezing, upower reports correct values, restart gnome-shell, batteryindicator shows correct values again
<Amoz> how can one debug the indicator?
<dholbach> Amoz, you could try asking in #ubuntu-desktop
<seb128> dholbach, Amoz: ask #gnome-hackers on irc.gnome.org
<seb128> we don't have gnome-shell hackers on #ubuntu-desktop
<seb128> oh
<seb128> that might be a distro issue, I will respond there
<didrocks> can someone reject https://code.launchpad.net/~nik90/ubuntu/precise/vlc/keywords/+merge/95085 please? need to go upstream first
<pitti> done
<didrocks> thanks pitti :)
<dholbach> I'm currently putting together tasks for Fix It Friday (coinciding with Ubuntu Global Jam) - any requests? I was think of http://qa.ubuntuwire.com/ftbfs/ and https://bugs.launchpad.net/ubuntu/+bugs?field.status_upstream=resolved_upstream for now
<pitti> presumably most of the older bugs on that list have been fixed ages ago; but working on that starting from the newest bugs sounds interesting
<nigelb> 24
<nigelb> urgh
<dholbach> pitti, yeah, and if we can close some of the older bugs during the process, then that's cool too :)
<dholbach> "just" a matter of making the instructions clear enough :)
<didrocks> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Freeze in effect.  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:
<bdrung> didrocks: bug #943014
<ubottu> Launchpad bug 943014 in vlc (Ubuntu) "[Need upstream first] Update desktop file with latest keyword specification" [Undecided,Triaged] https://launchpad.net/bugs/943014
<didrocks> bdrung: thanks for the notice
<smoser> dholbach, well, slangasek was fairly anti rc.local.d
<dholbach> smoser, maybe it should be discussed on the mailing list then? *shrug*
<smoser> dholbach, my feelings will not be hurt if you make that disappear from the queeu
<smoser> i agree it isn't worht other pilots looking at really.
<dholbach> I don't have the necessary powers
<smoser> what do you need me to do then?
<dholbach> can somebody please reject https://code.launchpad.net/~smoser/ubuntu/precise/sysvinit/rc.local.d/+merge/88323? (based on the discussion above)
<dholbach> thanks a lot smoser
<smoser> work in progress ?
<smoser> is that good enough ?
<dholbach> it will make it drop off the list
<infinity> smoser: I can delete the proposal, is that the sort of rejection you're looking for?
<infinity> smoser: Surely you can do that too...
<smoser> infinity, i moved it to "workin progress" an that is good enough.
<smoser> please do not delete.
<infinity> smoser: Alright. ;)
<stgraber> dholbach: yes, I have a package ready for upload, waiting for beta-1 freeze to be lifted
<stgraber> dholbach: it's in my PPA and already tested
<dholbach> awesome
<dholbach> :)
<Amoz> dholbach, you want a merge proposal or a patch in the bugreport?
<Amoz> for the upg
<dholbach> Amoz, as you like it - whatever is easier for you
<Amoz> dholbach, http://paste.ubuntu.com/861948/
<dholbach> thanks Amoz
<Amoz> np
<Amoz> my bad for not checking it more carefully
<Amoz> we fixed it this way last time as well I suppose
<dholbach> Amoz, ah, cool
<dholbach> Amoz, applied, tested and committed :)
<dholbach> good work
<Amoz> dholbach, nah you did the work ^^
<dholbach> no no
<dholbach> I had no idea what I was doing
<dholbach> Amoz, did you get your indicator-power query sorted out?
<kenvandine> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Freeze in effect.  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: kenvandine
<Amoz> dholbach, filed a bug
 * dholbach hugs kenvandine
<dholbach> Amoz, ok cool
 * kenvandine hugs dholbach
<stgraber> dholbach: the merge proposal can probably be killed though as the real fix is a merge from Debian
<dholbach> stgraber, excellent
<dholbach> an somebody please reject https://code.launchpad.net/~sdeziel/ubuntu/oneiric/openvpn/subnet-icmp-disable/+merge/90740?
<dholbach> ^ based on the discussion above
<pitti> done
<tsdgeos> who do i need to ask to move to a newer openjpeg?
<tsdgeos> we are two releases behind
<tsdgeos> in a project that releases every year or more
<slangasek> smoser: I'm not anti rc.local.d, I'm anti putting this in sysvinit ;)
<smoser> i kind of realized that when i re-read the conversation
<smoser> and updated the bug with a summary in its final comment.
<jokerdino> anyone wants to submit a branch on my behalf? (https://bugs.launchpad.net/ubuntu/+source/unity/+bug/942476)
<ubottu> Launchpad bug 937334 in unity "duplicate for #942476 Unity shortcut overlay needs to include shortcut for video lens" [Undecided,Confirmed]
<jokerdino> i can't ssh in here, the network blocks any port other than 80.
<bdmurray> pitti: I've noticed that some python tracebacks reported by apport are missing information bug 942439 is an example
<ubottu> Launchpad bug 942106 in mdadm (Ubuntu) "duplicate for #942439 mdadm-functions missing udevadm settle (?)" [Undecided,Confirmed] https://launchpad.net/bugs/942106
<bdmurray> pitti: is missing the source package, version and distrorelease bits at least
<pitti> hm, curious -- no idea how this would happen
<bdmurray> bug 942888 is another example
<ubottu> Launchpad bug 942888 in Ubuntu "unity-scope-contacts-desktop crashed with NoSuchDatabase in _reconnect(): Database contacts does not exist on this server. (Create it by passing create=True)" [Undecided,New] https://launchpad.net/bugs/942888
<bdmurray> this is rather recent
<pitti> that at least has a rather weird Dependencies: field
<bdmurray> pitti: if you need it another example is bug 940800
<ubottu> Launchpad bug 940800 in Ubuntu "pyclean crashed with Exception in from_package(): cannot get content of python-wadllib" [Undecided,New] https://launchpad.net/bugs/940800
<pitti> bdmurray: oh, I believe that it's happening now, I just don't know why :/
<pitti> I guess something weird with the new async way of collecting information
<pitti> ah, no Evan
<bdmurray> he's at a conference this week
<pitti> so apparently there's some way of sending the report without collecting all the information
<diwic> pitti, can I borrow your expert brain for a moment?
<pitti> hey diwic, what's up?
<diwic> pitti, the stacktrace given by apport seems inconsistent and I'm not sure what I can trust or not
<diwic> pitti, in bug 924416, stack trace top is at "drop_block (bq=0xfd6170, q=0x7fede800f440) at pulsecore/memblockq.c:180"
<ubottu> Launchpad bug 924416 in pulseaudio (Ubuntu) "pulseaudio crashed with SIGABRT in drop_block()" [Medium,Confirmed] https://launchpad.net/bugs/924416
<diwic> pitti, it says that q=0x7fede800f440 when the function was called. However, at line "pulsecore/memblockq.c:18" is "pa_assert(q)"
<diwic> pitti, which should succeed if q is non-zero.
<diwic> pulsecore/memblockq.c:180
<diwic> pitti, so how should I go about this?
<pitti> hm, I'm as baffled as you; sometimes optimization plays dirty tricks, but SIGABRT very much does sound like an assert failure
 * pitti downloads and looks at source
<pitti> diwic: hm, it doesn't show the value of bq, is there any chance that it really hits the next assertion, pa_assert(bq->n_blocks >= 1); ?
<pitti> diwic: is pa_assert() even active, i. e. do we not build with NDEBUG?
<diwic> pitti, I'm pretty certain pa_assert() is active
<diwic> pitti, but what technique would I use to verify? I assume gdb is involved somehow :-)
<pitti> diwic: at this point it'd be good to get a core dump
<diwic> pitti, can we get one from launchpad or is it forever lost?
<pitti> it's already a month old, so I think it's gone for good
<diwic> pitti, bug 932178 is from 14 feb if that helps (it's a duplicate)
<pitti> diwic: if I read macros.h correctly, pa_assert_se should drop a log message into pulse's log; is that anywhere in teh attachments?
<ubottu> Launchpad bug 924416 in pulseaudio (Ubuntu) "duplicate for #932178 pulseaudio crashed with SIGABRT in drop_block()" [Medium,Confirmed] https://launchpad.net/bugs/924416
<diwic> pitti, no, I think it should be in /var/log/syslog though, we might want to apport-collect that...
<pitti> diwic: Eric says he gets it a few times a day; perhaps he can attach the .crash report the next time it happens, then we'll have it for closer inspection
<pitti> diwic: oh, I had expected ~/.xsession-errors
<diwic> pitti, good idea. that would be in /var/crash/apport something?
<pitti> diwic: yes, /var/crash/_usr_bin_pulseaudio.1000.crash presumably
<pitti> cd
<diwic> cd ?
<Amoz> compact disc
<Amoz> or see directory ? :)
<diwic> pitti, ok, I will update the bug and ask for this information. Thanks!
<pitti> diwic: thanks; sorry that I cannot be more helpful
<diwic> pitti, both you and apport is already very helpful, so don't feel bad about it :-)
<PaoloRotolo> Hi all!
<cnd> bdmurray, do you have instructions on how to use set_serial for wacom touchscreens?
<slangasek> pitti: bug #828731> no, kexec-tools hasn't been accepted into lucid-proposed...
<ubottu> Launchpad bug 828731 in kexec-tools (Ubuntu Natty) "kdump functionality not working as expected when /boot is a separate partition" [Medium,In progress] https://launchpad.net/bugs/828731
<slangasek> pitti: should I go ahead and accept the lucid/natty versions?
<pitti> slangasek: odd, it had a comment; click failure :/ please do, thanks
<bdmurray> cnd: this is all I have http://www.murraytwins.com/blog/?p=103
<cnd> bdmurray, ok, thanks!
<slangasek> bdmurray: so I can comment on bug #659438, but hit a timeout trying to move the bug to 'triaged', bah
<ubottu> Launchpad bug 659438 in apt (Ubuntu) "Installation/Removal fails because of package which could not be located (failure in apt.Cache.required_download)" [High,Triaged] https://launchpad.net/bugs/659438
<bdmurray> slangasek: might work via the api which task?
<slangasek> bdmurray: the devel task for aptdaemon (Ubuntu)
<bdmurray> slangasek: re bug 937638 its duplicate bug 937630 also seems to have hardware errors
<ubottu> Launchpad bug 937638 in sysvinit (Ubuntu) "package initscripts 2.88dsf-13.10ubuntu4.1 failed to install/upgrade: ln: accessing `/etc/nologin': Input/output error" [High,Invalid] https://launchpad.net/bugs/937638
<ubottu> Launchpad bug 937638 in sysvinit (Ubuntu) "duplicate for #937630 package initscripts 2.88dsf-13.10ubuntu4.1 failed to install/upgrade: ln: accessing `/etc/nologin': Input/output error" [High,Invalid] https://launchpad.net/bugs/937638
<slangasek> bdmurray: right, those two are from the same submitter; there was another one, let me find it
<bdmurray> ah, got it
<slangasek> bdmurray: bug #938306
<ubottu> Launchpad bug 938306 in sysvinit (Ubuntu) "package initscripts 2.88dsf-13.10ubuntu4.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Medium,Incomplete] https://launchpad.net/bugs/938306
<bdmurray> slangasek: what about EXT2-fs (loop1): error: ext2_lookup: deleted inode referenced: 64092 ?
<slangasek> bdmurray: well, it's not a hardware error in that case - may simply be fs corruption
<SpamapS> I just love mdadm.. 44,000 lines of C, about 9 lines of comment
<SpamapS>     if (ioctl(fd, GET_ARRAY_INFO, &array) != 0 ||
<SpamapS>         array.raid_disks <= 0)
<SpamapS>         return 0;
<SpamapS> So.. either there aren't enough disks, or the ioctl exploded. Either way.. lets just fail the same way. <sigh>
<infinity> SpamapS: By "not enough disks", you mean "no disks", which is equavalent to "no array at all", which may well be about the same as GET_ARRAY_INFO returning a failure.
<infinity> SpamapS: Looks more like just covering their bases for all the different "vaguely undefined" ways that an array can not exist.
<infinity> SpamapS: (I do like that the check accepts the possibility that there may be a negative number of disks, though)
<SpamapS> infinity: I'm fairly certain that in this case the ioctl is complaining because the array is degraded.. but I really have no good way to prove that. :-P
<infinity> SpamapS: GET_ARRAY_INFO should return info on a valid array, surely.
<infinity> SpamapS: Even a degraded one.
<SpamapS> infinity: in that case, it should have set the number of disks to 1, not 0
<infinity> You'd think.
<infinity> Unless the array just plain doesn't exist from mdadm's POV.
<SpamapS> its also possible the disc.major != 0 or the disc.minor != 0
<SpamapS> thats in another part of the code
 * SpamapS is writing a tiny version of mdadm's ioctls to determine that right now. :p
<SpamapS> would be nice if the program actually reported *why* it can't re-add this disk
<bdmurray> mvo: so I was unable to recreate bug 659438 do you have any other ideas on how to test it?
<ubottu> Launchpad bug 659438 in aptdaemon (Ubuntu) "Installation/Removal fails because of package which could not be located (failure in apt.Cache.required_download)" [Critical,Triaged] https://launchpad.net/bugs/659438
<SpamapS> [  172.326867] mdadm: sending ioctl 1261 to a partition!
<SpamapS> Interesting..
<mvo> bdmurray: unfortunately not
<mvo> bdmurray: thanks a bunch for the test though
<bdmurray> mvo: do you think the bug should be left open?
<dupondje> pitti: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/936629 why is this marked incomplete?
<ubottu> Launchpad bug 936629 in cups (Ubuntu) "Printing fails after printing first document " [High,Incomplete]
<dupondje> got the same issue today
<dupondje> if you need some debugging
<mvo> bdmurray: if its still collecting dupes then I would say yes :/
<dupondje> tkamppeter: seems like you set it on inc
<kenvandine> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Freeze in effect.  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<tkamppeter> dupondje, you are welcome to helpon the bug, simply answer my questions and supply the information which I have asked for from the original poster.
<dupondje> tkamppeter: tried it again, but unable to simulate it now
<dupondje> btw, I have the gs command that was executed
<dupondje> http://paste.ubuntu.com/862514/
<bdmurray> slangasek: regarding bug 849414 is there anyway to just make 'plymouth:debug' the default for a while?
<ubottu> Launchpad bug 849414 in plymouth (Ubuntu Precise) "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events()" [High,Incomplete] https://launchpad.net/bugs/849414
<slangasek> bdmurray: we could, but I don't believe that would actually help us narrow it down
<slangasek> the backtraces all point to a signal handler gone rogue
<slangasek> and we know we have an Ubuntu-specific signal handler that we need to get rid of
<barry> slangasek: so bug 941172.  i can easily update the version numbers, but i think it would be useful to link to bryceh 's description in comment #4.  only i'm not sure whether to move that text to the wiki and add a link to that, or just link to the comment in the bug.  thoughts?
<ubottu> Launchpad bug 941172 in update-manager (Ubuntu Precise) "do-release-update to Precise produces a hardware-not-support-in-Natty warning" [Medium,Triaged] https://launchpad.net/bugs/941172
<slangasek> barry: I guess the wiki would be better
<barry> slangasek: agreed. i'm inclined to just copy that whole text to the wiki, mark it up minimally, and link to that
<bryceh> barry, yeah put it in wiki.  the text should be trimmed down a lot, it was just a brain dump and is probably TMI
<barry> bryceh: okay, i'll do that, thanks.  i'll follow up with the wiki url once that's done
<dupondje> apport-bug is broken - https://bugs.launchpad.net/bugs/943661
<ubottu> Launchpad bug 943661 in apport (Ubuntu) "apport-gtk crashed with SIGSEGV in get_gsubgpos_table()" [Medium,New]
<tkamppeter> dupondje, thanks. I have subscribed you to the bug now. Please provide any further information through the bug report, especially whether "sudo aa-complain cupsd" eliminates your problem completely.
<micahg> tkamppeter: that also removes apparmor protection from the cups daemon and is not recommended
<seb128> it's seems fair enough to run once to see if that workaround a bug to know if the bug is due to restrictions
<tkamppeter> micahg, I ask the users only for doing this to determine whether their printing got really blocked by AppArmor. I do not consider the bug fixed when it works with aa-complain.
<micahg> sure
<micahg> tkamppeter: ok, but I didn't see that note :)
<SpamapS> slangasek: opinion sought.. mdadm has added some checks that prevent one from re-hot-adding out of sync former-members of a RAID array without zeroing the superblock..
<SpamapS> slangasek: I have a feeling this is unintended consequences of some other check...
<SpamapS> slangasek: 1) how much do we care (at worst, this means people will always have to do a full sync instead of a catch up), and b) if we care, do we push back to Debian or ???
<slangasek> er, I think all my information about mdadm is out of date.  what's the difference between a full sync and a catch-up, here?
<slangasek> I mean, doesn't mdadm just know that they're out of sync, and has no choice but to overwrite?
<SpamapS> slangasek: yes, so this may be a kernel issue too.
<SpamapS> slangasek: mdadm tells the kernel to re-add a disk to an array
<SpamapS> slangasek: in the past that was fine. but in this case, mdadm looks at the disk and says "no, its no good for adding, please zero the superblock"
<slangasek> right
<SpamapS> slangasek: I'm more looking for how much we care about this, because the debugging effort will be brutal.
<SpamapS> slangasek: in the new case.. it seems mdadm is being more careful, so I'm ok with it.
<slangasek> we care about mdadm working smoothly
<slangasek> but I'm deathly afraid of touching that code at all this cycle
<SpamapS> slangasek: the scenario that has bothered me for a while is where I break a mirror temporarily, and the put the disk back in. I've always felt md should re-sync that, but it never seems to
<slangasek> well
<slangasek> in past cycles, you would have counted yourself fortunate to have it just fail to resync
<slangasek> because we have had some data corruption bugs related to hot remove/add
<SpamapS> Yeah, I think its more careful now
<slangasek> so I wouldn't recommend trying to address this without coordinating with upstream+Debian
<SpamapS> I'm not really looking to touch it at all
#ubuntu-devel 2012-03-01
<SpamapS> but I feel that the experience has gotten less smooth, but probably more safe
<slangasek> well, all things considered, I'd rather we leave the needle there for this release
<SpamapS> agreed
<bdmurray> I think its worth release noting though as my experience was more surprising
<slangasek> true
<bdmurray> I thought it used to boot degraded which didn't happen to me
<slangasek> SpamapS: can you open a release notes task for this?
<slangasek> oh, booting in degraded mode shouldn't have changed :/
<slangasek> bdmurray: bug #?
<bdmurray> I was looking at bug 925280
<ubottu> Launchpad bug 925280 in mdadm (Ubuntu) "Software RAID fails to rebuild after testing degraded cold boot" [Medium,Confirmed] https://launchpad.net/bugs/925280
<bdmurray> hmm, that doesn't say anything about getting a busy box shell though
<SpamapS> bdmurray: the default is to not boot degraded.. and that has been the default since, IIRC, Jaunty
<SpamapS> bdmurray: its a High priority question in the installer, so you should get a question and have the option to boot degraded
<SpamapS> bdmurray: the error message explains that you need to zero the superblock
<SpamapS> bdmurray: the code that introduced that change is new, coming with the latest mdadm (3.2.x) ..
<SpamapS> bdmurray: its being extra careful because there is a superblock on that device that is not consistent with the array that is active.
<SpamapS> Ahh, I wish I had found this bug 6 hours ago. :)
<ubottu> Launchpad bug 6 in Launchpad itself ""next 10 entries" at bottom of page" [Medium,Invalid] https://launchpad.net/bugs/6
<slangasek> heh
<stgraber> skaet: if we're going to allow for some rebuild, any chance someone can review the ldm in the queue? it's not critical but it'd be nice to have in Edubuntu if we rebuild
<skaet> stgraber, if you can line up a reviewer - ok.   we'll fall back to the current image set as backups if there's any issues.
<skaet> stgraber,  bug #?
<stgraber> skaet: When using LTSP, it's possible unity 3D will start on a client that's not 3D capable, in such case, make sure to select "Ubuntu 2D" in the session list at login time. (820417)
<stgraber> that's what I put in the technical overview
<skaet> thanks. stgraber,
<stgraber> oh, right, sync requests don't have diffs on LP, let me build one quickly then...
<micahg> stgraber: if it's from testing, you can request it âwith +localpackagediffs
<stgraber> micahg: that's still in unstable at the moment (released upstream only a few days ago
<stgraber> http://paste.ubuntu.com/862747/ is the debdiff for ldm. As mentioned earlier, the new background won't affect Ubuntu as we ship ours in ldm-ubuntu-theme (always installed with LTSP)
<stgraber> ldm-2.2.6/rc.d/X50-dmrc-processing is the bit I care about the most, mostly the change from the broken TryExec to Exec and the logic for parsing LDM_SESSION that actually works now (.dmrc reading/writting in LDM has been broken for years ...)
<pitti> dupondje: set to "in progress", thanks
<pitti> Good morning
<micahg> pitti: I discovered if we demote the packagekit andpackagekit-backend-aptcc binaries, we can demote gdebi, is this desirable?
<pitti> micahg: we don't actually want -aptcc indeed; the apt backend works slightly better, but I don't know if that also needs gdebi
<micahg> pitti: the aptcc backend depends on gdebi-core
<micahg> the apt one doesn't seem to
<pitti> hm, I'm not even sure why it is in main
<pitti> there only seem to be alternative dependencies to it
<pitti> we need the source in main for the library, though
<micahg> right
<pitti> micahg: let me try to demote these two binaries and see what happens in c-m
<micahg> sounds good
<micahg> pitti: I forgot about packagekit-dbg, needs to be demoted as well
<pitti> doing
<dupondje> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/943661 could somebody check this with quite high priority ? :) Quite annoying you can't use ubuntu-bug/apport-bug atm :)
<ubottu> Launchpad bug 943661 in apport (Ubuntu) "apport-gtk crashed with SIGSEGV in get_gsubgpos_table()" [Medium,New]
<pitti> micahg: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<pitti> micahg: hm, "rescued from packagekit", sounds like extra-include; I'll try sorting this out in the seeds
<micahg> pitti: ah, right, *-dbg :)
<pitti> micahg: ok, seeds committed, let's wait for the next round
<micahg> pitti: thanks
<micahg> pitti: the reverse recommends has the alternate on python-aptdaemon.pkcompat
<pitti> micahg: ah, I think we need to swap that
<micahg> why should it matter, it's a recommends?
<pitti> component-mismatches checks these as well, as we install them by default
<micahg> right, but if the first alternative is in universe (i.e. not available), why wouldn't it just install the alternative?
<micahg> it violates policy for depends, but AFAIK doesn't for recommends
<pitti> micahg: well, britney just isn't clever enough for this
<pitti> but anyway, usually you have universe enabled, so it should really prefer what we want users to install
<pitti> unless they explicitly choose PK
<pitti> so I think it's not just a c-m workaround to swap it
<micahg> pitti: well, that'll give us a diff on packagekit, but I guess that's worth a source in universe at least for the LTS
<micahg> pitti: should I take care of that after beta 1?
<pitti> micahg: that'd be appreciated
<micahg> ok, will do
<pitti> micahg: perhaps we can talk Matthias into using ${daemon-Recommends} and setting that accordingly depending on dpkg-vendor --is ubuntu
<micahg> pitti: I'll ask next time I see him online
<pitti> dupondje: fun, can reproduce
<dupondje> pitti: good :)
<pitti> dupondje: in fact, in gdb this reproduces the other weird bug 901675, so plusgood
<ubottu> Launchpad bug 901675 in apport (Ubuntu) "apport-gtk assert failure: python: ../../src/xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed." [Medium,Confirmed] https://launchpad.net/bugs/901675
<dupondje> pitti: well this morning I got that error indeed also
<dupondje> without anything changed
<dupondje> weird :)
<pitti> seems it's sometimes one or the other
<bkerensa> https://code.launchpad.net/~nathwill/ubuntu/precise/ubuntu-mono/fix-for-927606
<bkerensa> dholbach: If your feeling bored want to have a look at my friends merge proposal
<bkerensa> https://code.launchpad.net/~nathwill/ubuntu/precise/ubuntu-mono/fix-for-927606
<dholbach> good morning
<dholbach> hi bkerensa
<dholbach> I need to get a few other things done first, but if nobody beats me to it, I'll take a look
<bkerensa> dholbach: good morning
<broder> bkerensa: that should probably wait until after the beta comes out to get uploaded
<broder> but looks obviously correct other than that
<pitti> bdmurray: would you mind filing an apport bug about the missing info, with the three bugs as a pointer?
<soren> I'm having trouble working out a problem with grub. I'm using the cloud images and after install the generic kernel image, it doesn't show up in the grub menu.
<soren> ..and it's not making any sense to me, to be honest. I see it in the grub.cfg, but not in the grub menu.
<soren> Any hints for debugging?
<soren> Does grub directly go and read /boot/grub/grub.cfg?
<soren> and how does it know which partition to look at?
<soren> Is that set at grub-install time?
 * soren fetches grub2 source and tissues (tears are always involved when I read grub code)
<pitti> soren: or padding your table before you *headdesk*?
<wcchandler> is the beta 1 build == today's daily build?
<valavanisalex> Hi Everyone - a quick packaging question.  I want to set build dependency for Inkscape so that it can be built against either liblcms1-dev or liblcms2-dev.  Should I use an alternative dependency format "liblcms1-dev | liblcms2-dev" or should I use the virtual package "liblcms-dev"?
<janimo`> jamesh, slangasek do you know what the status of upstart is in Debian as far as they accepting upstart scripts in packages is concerned only (not making it default or anything like that)
<ScottK> janimo`: It's up to the package maintainer.
<janimo`> the former if settled, would be enough to eliminate a few deltas
<janimo`> ScottK, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577040 I was pointed at this bug
<ubottu> Debian bug 577040 in debhelper "dh_installinit: don't force upstart when both .init and .upstart exist." [Wishlist,Open]
<janimo`> while asking mongodb maintainer to take our upstart script. He took the Replaces:: so less delta \o/, only upstart remains
<nunod> anyone here related with the ubuntu-android project?
<valavanisalex> [repost from 13:47] Hi Everyone - a quick packaging question.  I want to set build dependency for Inkscape so that it can be built against either liblcms1-dev or liblcms2-dev.  Should I use an alternative dependency format "liblcms1-dev | liblcms2-dev" or should I use the virtual package "liblcms-dev"?
<cyphermox> valavanisalex: you'll probably want the alternate dependency rather than using the virtual package
<janimo`> ScottK, anhy further comment re upstart scripts in Debian?
<ScottK> No.  It really depends on the maintainer.  AFAIK there's no policy.
<janimo`> ScottK, but does it not cause such breakage as the (admittedly one year old) bug describes?
<janimo`> the last comment there (hi soren) makes it sound serious
<ScottK> It's clear upstart scripts can be put in Debian without causing harm.
<janimo`> someone who knows more about this than me should update that bug then :)
<janimo`> there's no need for policy, but if there are bugs like this maintainers with no experience with upstart  may simply avoid adding upstart scripts.
<Daviey> Anyone happy to know the max length in chars an ssh public key can be?
<ogra_> stgraber, hmm, wrt bug 942572, metacity uses composite by default nowadays (using SW rendering), it works fine on all arm devices here using xfbved as driver, the setting is hnadled in gconf, i wonder if just gconfd is missing un the ubiquity-dm session or something similar
<ubottu> Launchpad bug 942572 in ubiquity (Ubuntu) "Notify OSD panel is opaque when shown in the installer" [Medium,New] https://launchpad.net/bugs/942572
<ogra_> *xfbdev
<brendand> ogra_, stgraber - the system runs unity 3d. always has
<brendand> maybe the bug is not strictly that it's opaque, but this whole colour block in the middle
<brendand> sorry i can't get a screen
<stgraber> brendand: ok, so maybe you're just experiencing the difference between notify-osd with and without compositing
<ogra_> brendand, ubiquity-dm doesnt run 3d
<ogra_> (ubiquity-dm is what you run if choosing install directly at the beginning)
<brendand> ogra_, alright - but it should be solid grey. not grey border + random colour
<stgraber> yeah, that sounds like a notify-osd bug ;)
<ogra_> right
<brendand> stgraber, ok, no problem. feel free to move it
<slangasek> janimo`: the current iteration of debhelper doesn't cope with including upstart scripts in packages; patch to debhelper is pending
<janimo`> slangasek, so waiting with the inclusion of an upstart script is a wise choice then for Debian maintainer right?
<slangasek> janimo`: yes
<bdmurray> pitti: bug 944078
<ubottu> Launchpad bug 944078 in apport (Ubuntu) "bugs reported by apport missing essential information" [Undecided,New] https://launchpad.net/bugs/944078
<pitti> bdmurray: thanks
<valavanisalex> cyphermox: Thanks :)
<doko> apw, ogasawara: 4.6.3 upload is prepared, will upload after the freeze, or around 22:00 UTC, whichever is later
<ogasawara> doko: ack, thanks for the note.  I'll hold our kernel upload until after 4.6.3 finishes building
<doko> hmm, will start building in a ppa, then it there faster
<sladen> tkamppeter: your new 'cups-filter'  Are you able to queue that for 22:00
<sladen> tkamppeter: then I can follow it up with a blog post saying it's done
<SpamapS> is there a python library that makes it easy to get the latest stable release of ubuntu?
<SpamapS> when I say "get" I mean, identify
<brendand> SpamapS, heh. interesting idea
<broder> SpamapS: distro-info
<broder> SpamapS: http://paste.ubuntu.com/863695/
<SpamapS> broder: thanks!
<tkamppeter> sladen, still there?
<gregsan123> hi all, I'm writing some software for automatic bug detection and I would need to know how many bugs are marked as duplicates on ubuntu launchpad. Can somebody help me, please, with this? How can I get this info on launchpad?
<sladen> tkamppeter: yup
<tkamppeter> sladen, I finished packaging and testing the package. I will upload it, so that it is in the queue waiting for approval due to beta freeze. Simply grab it from the queue, or if needed do a beta freeze exception approving it or get it approved by someone.
<Ampelbein> gregsan123: Do you mean how many duplicates a certain bug has? Or just in general how many duplicates there are?
<Ampelbein> gregsan123: Maybe #launchpad is a better channel for those questions?
<sladen> tkamppeter: awesome++ danke! :)
<tkamppeter> sladen, I have tested it with several paper sizes, even wider than high (paper inserted long-edge first), viaa
<tkamppeter> lpr -P OJP8500 -o PageSize=Custom.595x421pt /usr/share/cups/data/testprint
<gregsan123> Amaranth: thanks for the info. What I need is the total number of reports that have been marked as duplicates
<tkamppeter> on the HP OfficeJet Pro 8500A (any HP inkjet or generally any A4 printer with custom paper size support will do it).
<tkamppeter> sladen, ^^
<gregsan123> Amaranth: currently there are 800.000+ reports there and I need to know the percentage of duplicates
<tkamppeter> sladen, package uploaded.
<sladen> Amaranth: known duplicates, or unknown duplicates ;-)
<gregsan123> known duplicates, the ones that are already marked as duplicates
<bdmurray> stgraber: bug 914038 is friendly-recovery right?
<ubottu> Launchpad bug 914038 in Ubuntu "Can't use keyboard on "What would you like to do?" "Run Ubuntu in low-graphics mode for just one session" menu." [Undecided,New] https://launchpad.net/bugs/914038
<stgraber> bdmurray: sounds more like failsafeX
<PaoloRotolo> Hi all!
<slangasek> bdmurray: do you know why the kernel apport hook includes a whole lot of information about the audio stack, and nothing about video?  (bug #942846)
<ubottu> Launchpad bug 942846 in linux (Ubuntu) "encrypted install fails to boot as long as vt.handoff=7 is used" [High,Confirmed] https://launchpad.net/bugs/942846
<bdmurray> slangasek: nope, not really.  ogasawara might as shes worked on that some
<slangasek> ogasawara: ^^ should the kernel apport hook include things like, say, /proc/fb?
<bdmurray> I'm happy to fix it if something is needed though
 * SpamapS ponders reinstalling on his MBA 4,1 rather than trying to debug why his trackpad and suspend/resume has ceased functioning. :-/
<ogasawara> slangasek, bdmurray: apport kernel hook is likely missing video specific debug info because we've probably not had a video domain expert to indicate which video debug info would be generally useful.  if there is additional information which is currently missing that would be generally useful for debugging, we should add it.
<slangasek> ogasawara: I think the only thing missing vs. the plymouth hook that's going to be generally useful on kernel bug reports is going to be /proc/fb
<slangasek>     attach_file(report, '/proc/fb', 'ProcFB')
<ogasawara> slangasek: ack.  I'm fine with having that added.
<bdmurray> slangasek, ogasawara: pushed to the precise branch
<ogasawara> bdmurray: awesome, thanks
<slangasek> bdmurray: thank you :)
<cnd> has beta 1 been released?
<cnd> slashdot says so, but I've not seen anything on ubuntu-devel-announce and the topic still says the freeze is in effect...
<stgraber> cnd: nope
<stgraber> cnd: omgubuntu and slashdot are both wrong (for now)
<cnd> hmm, so they jumped the gun...
<cnd> ok
<cnd> thanks :)
<ScottK> When have they not?
<micahg> FWIW, omgbuntu also release Firefox 9 before Mozilla did
#ubuntu-devel 2012-03-02
<Riddell> tsimpson: how do I change the topic with udevbot ?
<broder> Riddell: you can just change it directly
<broder> in here at least
* Riddell 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:
<Riddell> cor, so I can
<Riddell> Beta 1 released https://lists.ubuntu.com/archives/ubuntu-announce/2012-March/000156.html
<Riddell> thanks all who helped testing
<bemagri> Hello
<Kano> hi, i read about special mac iso images, can i see the changes done specific to those images somewhere?
<Q-FUNK> say, could anyone get around implementing bug #930703 ? :)
<ubottu> Launchpad bug 930703 in pulseaudio (Ubuntu) "wishlist: demote pulseaudio-esound-compat to Suggests" [Low,Triaged] https://launchpad.net/bugs/930703
<Q-FUNK> yet another PA upload took place without this being actioned upon.
<cody-somerville> When filing a bug against Debian, is the version pseduo-header required?
<pitti> Good morning
<ajmitch> morning pitti
<mbiebl> cody-somerville: do you mean filing the bug in the Debian BTS?
<cody-somerville> mbiebl, Aye.
<cody-somerville> mbiebl, Looks like no, right?
<mbiebl> cody-somerville: in that case, Version is not strictly required
<cody-somerville> Cool. Thanks.
<mbiebl> but for proper version-tracking, you should consider adding it
<SpamapS> cody-somerville: its almost always useful
<sladen> morning pitti, would you be able to approve 'cups-filters' if things are open again
<pitti> oh, seems the queue wasn't flushed completely
<pitti> sure
<dholbach> good morning
<dholbach> happy fix-it friday
<tjaalton> have we started to require dep-3 patch headers at some point?
<pitti> let's say "strongly encourage", and yes, for quite a while now
<pitti> it's so much easier to have the metadata in one place than having to dig it out of changelogs and merge delta summaries
<tjaalton> ok, I'll try to remember that in the future then :)
<dholbach> didrocks, salut mon ami - did you plan an activity-log-manager upload? is there anything I need to bear in mind when uploading it?
<didrocks> dholbach: bonjour bonjour :) non, rien de spÃ©cial de prÃ©vu, vas-y, upload :)
<dholbach> didrocks, merci beaucoup
<didrocks> dholbach: merci Ã  toi :)
<dholbach> de rien - merci Ã  Gabor Kelemen :)
<smb> Too much friendliness to handle before first cup of coffee error...
<dholbach> smb, that must be a kernel-team-specific error
<dholbach> :)
<smb> dholbach, Maybe even a smb specific one. Just too much world to bear in the mornings. :)
<dholbach> sometimes I know the feeling :)
<mpt> mvo, hi, since I upgraded to Pangolin I've been getting a "There are N updates" available" menu in the menu bar. Why does that exist? I thought we got rid of it in 2009.
<dholbach> didrocks, one of the activity-log-manager fixes should be merged upstream - for now I put it in there as a distro fix (i18n fixes)
<didrocks> dholbach: you can ping m4n1sh or seif, they are often on #ubuntu-desktop
<seb128> dholbach, is that the 2 letters inverted typo I assigned to Seif yesterday?
<dholbach> seb128, no
<seb128> oh no, you missed that one, too bad
<seb128> just saw your upload
<mvo> mpt: hm, confusing - what does it look like? does it contain additional items like "show updates", "install all updates" and the like?
<dholbach> seb128, sorry, the bug only linked 2 MPs
<seb128> dholbach, no worry ;-)
 * seb128 hugs dholbach
<mvo> mpt: there is a setting to allow this menu, but it should be off by default
<dholbach> seb128, at least it's better than it was before ;-)
<seb128> dholbach, yeah, shaking fist at those new software not properly translatable
<seb128> same for remmina
<dholbach> kelemeng finds all of those :)
<mpt> mvo, that's the one
<mpt> mvo, where is the setting for it? I'm pretty sure I've never turned it on
<mvo> mpt: its under dconf-editor com.ubuntu.update-notifier.auto-luanch and the default should be true
<mvo> mpt: what do you see there?
<mpt> mvo, a checked checkbox
<mvo> mpt: ok
<mvo> mpt: let me try to reproduce here
<mpt> mvo, so if the setting worked I shouldn't get the menu when it's checked?
<mpt> (when that setting is checked, I mean)
<didrocks> dholbach: hum, are you sure that using dh_translation is needed?
<didrocks> dholbach: I thought it was run automatically by pkgbinarymangler in packages in main, am I wrong?
<mvo> mpt: yes, thats the case. the odd thing is that when I set it and restart update-notifier its not visible for me
<dholbach> didrocks, pkgbinarymangler does not depends on dh-translations
<seb128> dholbach, didrocks: I think the mangler just do the langpack side of side, it doesn't do the "add gettext to desktop files" no strip the .desktop translations
<seb128> side of "things"
<didrocks> yeah, just looked again at the code and the debhelper integration, you're right :)
<mvo> mpt: re bug #789596 could you write up a postive version of the string? or is "Updates for %s may be provided by the third party vendor. Canonical does not provide updates for it." good enough?
<ubottu> Launchpad bug 789596 in software-center (Ubuntu) ""Canonical doesn't provide updates" is a scary message, especially for customers" [Undecided,Confirmed] https://launchpad.net/bugs/789596
<mpt> mvo, will do
<mvo> mpt: thanks
<micahg> pitti: Bug #944632
<ubottu> Launchpad bug 944632 in postgresql-9.1 (Ubuntu) "package postgresql-client-9.1 9.1.3-0ubuntu0.11.10 failed to install/upgrade: trying to overwrite '/usr/lib/postgresql/9.1/bin/pg_basebackup', which is also in package postgresql-9.1 9.1.3-0ubuntu0.11.10" [Undecided,New] https://launchpad.net/bugs/944632
<pitti> micahg: uh, thanks for pointing out; that's not somethign that changed in teh security update, so I guess the package upgrade just triggered this; I'll fix it ASAP
<hrw> guys: what is priority when it comes to 'friday fixit'?
<hrw> especcially when it comes to armhf stuff
<micahg> hrw: I think it's a free for all, so you fix whatever you want
<hrw> micahg: mkey
<hrw> ok, xf86-video-msm then
<tjaalton> hrw: ?
<RAOF> hrw: Oh, if you're in the mood for arm, then another one of those xf86-video-obscure needs some patches to build on armhf.  At least the makefiles need to not pass abi=softfloat :)
 * RAOF forgets precisely which one that is.  It might even be -msm :)
<hrw> RAOF: at Linaro we have arm porting jam today to help armhf build
<tjaalton> RAOF: should we track it's bugs?
<tjaalton> probably.. will subscribe x-swat
<RAOF> tjaalton: No one's asked us to, and I wasn't joking when I called it xf86-video-obscure.
<tjaalton> :)
<RAOF> I think it's for freerunner hardware?
<tjaalton> well, no bugs so far, doesn't add to the queue of ~3000 bugs :)
<hrw> RAOF: -msm is qualcomm
<hrw> hi oli
<ogra_> yo
 * ogra_ wonders why X got so crashy since a week or two
<hrw> RAOF: what for you need this xf86-video-msm?
<RAOF> hrw: Oh, I don't need it at all; I just ran into it when doing the Xserver transition this cycle.
<hrw> ok
<hrw> its quite old version
<RAOF> Because I've got no hardware I kinda assume that you guys have the arm-specific graphics drivers under control.
<hrw> but compiled fine on armhf
<RAOF> Ah, maybe it was the other one.
<hrw> RAOF: Linaro does not support Qualcomm, I do not know how it is with Ubuntu/ARM team
<RAOF> There were 3 video drivers that I missed in my first sweep through, because they were arm specific; there was -omapfb, -msm, and something else.
<ogra_> hrw, there is no ubuntu arm team anymore
<hrw> ogra_: I had to miss announcement
<hrw> ogra_: when there will be no ports.ubuntu.com then?
<ogra_> arm is supposed to be handled by the different teams now ... so i.e. if RAOF has ftbfs on armhf he would have to care himself (or find the arm specialist in his team)
<ogra_> hrw, there was no announcement yet ... and ports.u.c will persist
<hrw> RAOF: http://paste.ubuntu.com/864882/ is debdiff for you
<ogra_> as well as the arm port in ubnuntu
<ogra_> its just that the resopnsibility is in the different teams now, there is no team you can offload your arm bugs to anymore
<hrw> cool
 * RAOF heads to bed
<micahg> ogra_: IIRC, he has no specialist on his team :)
<hrw> RAOF: will open bug with debdiff
<ogra_> micahg, then its about time to talk to his manager to get one (and the necessary HW)
<tkamppeter> sladen, hi
<hrw> RAOF: bug 944709
<ubottu> Launchpad bug 944709 in xf86-video-msm (Ubuntu) "ftfbs on armhf" [Undecided,New] https://launchpad.net/bugs/944709
<hrw> ubuntu-sponsors subscribed
<zyga> is the super-key-triggers-unity-keybinding-pane thing annoying anyone when switching workspaces or is it just me?
<hrw> yabause will be next
<htorque> hello all! is rebuilding glib2.0 with --enable-systemtap all i need to do to make it work with systemtap (i'm on precise)?
<doko> apw, ogasawara: gcc-4.6 published, will be available in about 20min
<apw> doko, thanks
<seb128> htorque, I think some people mentioned our kernel hasn't support for systemtap, so not likely enough
<seb128> htorque, try asking mhr3 on #ubuntu-unity, he got it working I think
<htorque> seb128: thanks
<apw> seb128, i think cking uses systemtap, so i'd be supprised if it wasn't supported
<cking> was using it in precise ~8 or so weeks ago quite happily
<hyperair> the canonical contributor agreement form is broken. who can i poke regarding this?
<seb128> cking, apw: ok, I was reading http://oli4444.wordpress.com/category/programming/ who stated "The first idea was to use systemtap, but since there is no useful kernel for systemtap available for Ubunt" and I think other people mentioned issues with it as well, dunno the specifics
<cking> nice that it's dissed with no explanation - I will see if it works on my scripts
<seb128> one of the comments state "Due to -Bsymbolic use, people neew to rebuild their libs to use refdbg"
<seb128> so maybe that's the issue...
<cking> ah, so are we talking about systemtap on user space rather than kernel then?
<seb128> yes, the question was glib systemtap
<apw> seb128, got a bug number for it ?
<seb128> glib like the GNOME glib
<cking> in which case, I've not tested that - I only do kernel related system tap hackery
<seb128> apw, no but I didn't try myself, I will try to get infos and open a bug
<seb128> <mhr3> seb128, our kernel doesn't have required component
<seb128> (he's checking what exactly)
<seb128> <mhr3> seb128, right, UTRACE
<seb128> https://bugs.launchpad.net/ubuntu/+source/systemtap/+bug/529313
<ubottu> Launchpad bug 529313 in systemtap (Ubuntu) "user probes do not compiler because of missing linux/utrace.h file" [Undecided,Invalid]
<seb128> cking, apw: that seems the issue, for systemtap userland stuff to work kernel needs to have utrace support which is not in the stock upstream kernel?
<seb128> <mhr3> it's not merged in upstream kernel
<seb128>  almost all of the other distros are shipping it
<apw> ok so we haven't got something which isn't upstream
<apw> shame someone didn't mention it before FF
<micahg> pitti: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt \o/
<pitti> yay! demoting
<seb128> apw, there is a bug open for a year there: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/727160
<ubottu> Launchpad bug 727160 in linux (Ubuntu) "systemtap process probes requires CONFIG_UTRACE enabled" [Undecided,Confirmed]
<apw> seb128, so there is, shame it didn't get to our triager
<seb128> apw, yeah...
<apw> no that the bug even points to the required code
<apw> seb128, indeed that patches are only on a server which no longer exists
<seb128> apw, seems it's there: https://github.com/utrace/
<apw> seb128, that is a massive heap of code
<sladen> tkamppeter: yo
<hrw> is ubuntu-sugar-remix-meta maintained at all?
<hrw> source package mentions only lucid and maverick
<tkamppeter> sladen, is all OK with the test page for you now? When will you post the blog?
<mhall119> pitti: dholbach has asked that https://code.launchpad.net/~arthur-talpaert/ubuntu/precise/supertuxkart/add_quicklist/+merge/94961 and https://code.launchpad.net/~taltos/ubuntu/precise/scribes/add_quicklist/+merge/95289 be rejected, I've already commented on them as to why
<stgraber> mhall119: done
<hrw> bug 935450 looks like semi solved - package needs to be reuploaded
<ubottu> Launchpad bug 935450 in stressapptest (Ubuntu Precise) "stressapptest version 1.0.3-2ubuntu2 FTBFS on armhf in precise" [High,New] https://launchpad.net/bugs/935450
<hrw> built fine on my pandaboard
<mhall119> thanks stgraber
<pitti> mhall119: ah, stgraber beat me to it
<mhall119> yup, he's quick
<mhall119> thanks anyway though
<hrw> ~curse authors which search for library by scanning few dirs
<hrw> ok, slang-slirp looks more like fixed
<hrw> nope, fails in examples ;(
<dupondje> https://launchpad.net/ubuntu/+source/cryptsetup -> is there a change a merge of this would still be accepted now ?
<dupondje> cause we're running a quite old version
<zyga> rsalveti: https://bugs.launchpad.net/linux-linaro/+bug/944796
<ubottu> Launchpad bug 944796 in Linaro Linux "Beagle C4 crashes on reboot" [Undecided,New]
<rsalveti> zyga: thanks
<zyga> rsalveti: I'll get you the full manifest in a second (package versions)
<zyga> rsalveti: done, bug updated with dmesg and /var/lib/dpkg/status
<rsalveti> zyga: thanks
<zyga> :)
<hrw> bug 935435 got fix
<ubottu> Launchpad bug 935435 in scim-chewing (Ubuntu Precise) "scim-chewing version 0.3.3-2ubuntu1 FTBFS on i386 in precise" [High,In progress] https://launchpad.net/bugs/935435
<RiotingPacifist> I just generated a diff for a 1 file simple change to a config file ( http://pastebin.com/eZP4JZg7 ) 1) is that the right format, 2) do I just attach it to the bug report or do I need to do some .deb related stuff debdiff in order to be usefull?
<dupondje> anyone?
<hallyn> doko: SpamapS: is it safe to assume that ceph merge won
<hallyn> 't be happening this cycle (bug 932898)
<ubottu> Launchpad bug 932898 in ceph (Ubuntu) "[MIR] ceph" [Undecided,Confirmed] https://launchpad.net/bugs/932898
<hallyn> sorry, MIR, not merge
<doko> hallyn, is there a FFe?
<hallyn> doko: probably not, it was filed long before ff.  really i don't know who is babysitting that request
<hallyn> i thought it was SpamapS I guess
<nunod> Totem doesnt show up in the alt-tab window switcher, is this a bug?
<sladen> tkamppeter: did it this morning
<sladen> tkamppeter: http://design.canonical.com/2012/03/printer-test-page/
<sladen> tkamppeter: I confused to having rushed it out.  We can perhaps do a follow-up talking about general printing improvements and the other stuff you mentioned
<hrw> bug 935440 got one patch so now it fails same as in debian
<ubottu> Launchpad bug 935440 in setools (Ubuntu Precise) "setools version 3.3.6.ds-7.2ubuntu4 FTBFS on i386 in precise" [High,New] https://launchpad.net/bugs/935440
<tkamppeter> sladen, I have seen it now. nice. What is also important with this test page is that it is used for any paper format, not only A4 and Letter as the old one. And it looks decent with any format.
<smb> didrocks, Is there any chance that the hud key will change before release?
<didrocks> smb: not really, design request. Why?
<sladen> tkamppeter: thanks for the reminder.  adjusted it to add that
<smb> didrocks, Cause the alt tap drives me mental to the point I want to grab a pitch fork to make a design change request. I hit that key often enough for other things and get the hud, especially when you use vinagre or the vnx viewer of virt-manager (those use ctrl+alt to grab ungrab the keyboard and mouse).
<didrocks> smb: this is a bug, and it's fixed in the incoming 5.6
<didrocks> smb: basically taping alt + something else won't bring the hud
<smb> didrocks, Hope I will survive until then. But at least something to look forward to.
<smb> didrocks, Thanks
<didrocks> smb: yw ;) you can it in *hem* ccsm, meanwhile
<didrocks> (or gconf of course)
<smb> didrocks, Then gconf maybe... I try to avoid ccsm because one is not supposed to use it anyway. :)
<didrocks> smb: /apps/compiz-1/plugins/unityshell/screen0/options/show_hud
 * smb puts the pitch fork back into the storage room... :)
<nunod> I have window ocasionally not showing up in the alt-tab switcher, but can't isolate the problem :/ hints?
<mfisch> zul: I was going to fix python-tz today for bug fix friday
<mfisch> zul: looks like you beat me to it
<dholbach> geser, you should have upload rights for main too :)
<mfisch> zul: would it be worth it to re-enable the tests and just modify the path so that the tests work?
<zul> mfisch: be my guest
<tkamppeter> pitti, can you upload cups?
<bdmurray> barry_: I was looking at bug 556293 again and don't think there is any work to be done
<ubottu> Launchpad bug 556293 in apt (Ubuntu) "apt/aptitude need to take global proxy settings into account" [Undecided,Confirmed] https://launchpad.net/bugs/556293
<tkamppeter> pitti, thanks.
<pitti> tkamppeter: darn, failed to build
<pitti> tkamppeter: due to the cups-deviced usb backend crash again
<barry_> bdmurray, cool.  do you want to just close it then?
<bdmurray> barry_: well, when I was testing it I noticed something odd so I'm not positive.  While I configured apt to use a proxy server, which didn't exist, apt-get update was still working.
<pitti> hm, I just dist-upgraded, and colors in vim are all broken now
<barry_> bdmurray, it might be better to unassign this from me for now.  no way will i have time for it until after pycon
<pitti> argh!
<pitti> oh, I bet it's due to bug 871907
<ubottu> Launchpad bug 871907 in vim (Ubuntu) "vim should have "set bg=dark" by default" [Wishlist,Fix released] https://launchpad.net/bugs/871907
<dholbach> pitti, do you know who's the cryptsetup expert?
<dholbach> I'm asking because of 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]
<tkamppeter> pitti, Artifex is about to buy enhanced CJK fonts which distros will then be able to ship in their non-free parts free-of-charge, do you know whom to contact (non-free part, Japanese/CJK people) for whether this is interesting for Ubuntu?
<hallyn> @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: hallyn
<hallyn> SpamapS: for bug 928501, should that be assigned to huats and ubuntu-sponsors be unsubscribed for now?
<ubottu> Launchpad bug 928501 in ebox (Ubuntu) "Precise will ship totally broken ebox packages" [Undecided,Confirmed] https://launchpad.net/bugs/928501
<SpamapS> hallyn: I'm thinking at this point we just need to review/upload .. huats has clearly not been able to complete the review.
<hallyn> <nod>
<hallyn> wasn't sure if you'd continued to talk with him privately or not
<hallyn> thanks
<barry_> slangasek, i have to hand off bug 828731 to someone else i think
<ubottu> Launchpad bug 828731 in kexec-tools (Ubuntu Lucid) "kdump functionality not working as expected when /boot is a separate partition" [Medium,In progress] https://launchpad.net/bugs/828731
<slangasek> barry_: as ENOTIME?
<barry_> slangasek, exactly.  i lost most of today with a broken desktop :(
<slangasek> doh
<barry_> slangasek, still not fixed but i think the main bug is understood now and the fix is in progress
<slangasek> what's the bug?
<slangasek> so I know when to reboot ;)
<barry_> slangasek, i think it will only hit you if you don't use unity 3d
<barry_> slangasek, but unity 3d has other problems for me, like broken emacs, broken gnome-do ;)  so i use unity 2d and its start up from lightdm was busted
<barry_> slangasek, at least, that's my understanding of the issue
<slangasek> ok
<slangasek> do you know a bug #?
<slangasek> I guess this is the issue seb128 mentioned on #ubuntu-release earlier, but would be good to track
<barry_> slangasek, yep.  let me track that down for you
<barry_> slangasek, bug 944865 is the one i reported, but that may end up being a dup of an earlier bug
<ubottu> Launchpad bug 944865 in unity-2d (Ubuntu) "regression: no dock or menu bar after login" [Undecided,Confirmed] https://launchpad.net/bugs/944865
<PaoloRotolo> Hi all!
<slangasek> barry_: bug reproduced here in all its glory ;)
<seb128> slangasek, which one?
<slangasek> seb128: getting no session at login
<slangasek> not sure if this is the lightdm regression you described
<slangasek> bug #944865 was the one barry had filed
<ubottu> Launchpad bug 944865 in unity-2d (Ubuntu Precise) "regression: no dock or menu bar after login" [Critical,Confirmed] https://launchpad.net/bugs/944865
<slangasek> I'm seeing problems with both Ubuntu and Ubuntu 2D sessions though
<seb128> slangasek, hum, we tracked bug #944736
<ubottu> Launchpad bug 944736 in lightdm (Ubuntu) "Fails to load any session" [High,Incomplete] https://launchpad.net/bugs/944736
<seb128> slangasek, if you can debug it that would be welcome
<seb128> slangasek, what we figure so far is that lightdm was calling gnome-session --session=<session> rather than "gnome-session --..."
<seb128> what we figured*
<seb128> slangasek, which the x11-common script doesn't like and it ignored the --session extra argument and call "gnome-session"
<seb128> which leads to "I always get the default session"
<seb128> slangasek, unity-3d not started is another issue I would like to see debugged, some people had similar issues on the bug
<seb128> where guest session, other user sessions worked and where the .xsession-errors looked like xorg was closed while the session started
<stgraber> slangasek: do you know if it's expected of apt-get clean to wipe /var/cache/apt/*.bin too? that's causing a relatively high load on a few of my machines where apt-get clean is called hourly (configuration manager) and where rebuilding the cache can take a few minutes (apparently it gets rebuilt the first time you try to use it)
<stgraber> I'm happy to change my scripts to run apt-get update after apt-get clean rather than before (as they do currently) which would fix the issue for me, but I'm wondering if it was indeed intended...
<stgraber> oh, apparently vagrantc beat me to it :) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661947
<ubottu> Debian bug 661947 in apt "apt-get clean deletes /var/cache/apt/*.bin" [Normal,Open]
<hallyn> my LORD it's been like an hour i've been waiting for ubuntu:samba to fetch
<stgraber> hallyn: that's why we have DC machines for ;) took 2 minutes for me, the total size of the branch is of 562MB
<hallyn> sigh
<hallyn> yeah, i just figured i'd do it here since i don't want my keys pushed there...  next time i think i'll do it differently
<slangasek> stgraber: yeah, I have no idea if that's intended
<stgraber> hallyn: if you just need the last revision, "bzr co --lightweight ubuntu:samba" could do the trick for you and should use as much space and bandwidth as a regular apt-get source
<stgraber> but doing that will make bzr go online every time you want to access anything from the history so depending on what you want to do it can be slower than waiting for bzr branch to complete
<SpamapS> jdstrand: how do you guys handle CVE's in the dev release? I notice http://people.canonical.com/~ubuntu-security/cve/2012/CVE-2012-1054.html needs a new version in precise... but there are no visible bugs open against puppet in precise.
<ubottu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1054)
<jdstrand> SpamapS: we just fix them with a changelog entry of the form of https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging. we will only file a bug if it is required for some other reason
<jdstrand> SpamapS: in this case, lynxman said he was working on the merge of 2.7.11-1
<jdstrand> so there didn't seem a need to file a bug
<SpamapS> jdstrand: ahh ok, just wanted to make sure there's something that makes it a blocker for the release team.
<SpamapS> jdstrand: agreed, if its already in progress, no need
<SpamapS> debugging puzzle.. if you wanted to remove *dates* from a log file.. why wouldn't this sed pattern work:
<SpamapS> sQ[0-9]\{1,2\} .* 200[0-9] [0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\},[0-9]\{3\}QQg
 * SpamapS is giddy that he found it just now
<bdmurray> because its 2012?
<SpamapS> bdmurray: ding ding
<SpamapS> Whats really annoying about this..
<SpamapS> is it was fixed upstream..
<SpamapS> in 2010
<SpamapS> unfortunately.. upstream decided to stop making releases :-/
<SpamapS> or something :-P
<hallyn> @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:
<stgraber> jdstrand: https://launchpadlibrarian.net/95049916/buildlog_ubuntu-precise-i386.ubiquity_2.9.24_FAILEDTOBUILD.txt.gz?
<stgraber> looks like it might be breaking all the builds at the moment :)
<stgraber> Filename: pool/universe/a/apparmor/dh-apparmor_2.7.99-0ubuntu3_all.deb
<stgraber> looks like jdstrand isn't around...
<stgraber> slangasek: around? ^
<slangasek> yeah
<slangasek> overridden
<stgraber> thanks
<stgraber> slangasek: I'll be heading out in a few minutes, can you also do a mass give back once the publisher has run?
<slangasek> no, I'm not a buildd admin
<stgraber> ok, I'll do it when I get back unless someone does it before
#ubuntu-devel 2012-03-03
<jdstrand> hmm, I thought I did that last week
<jdstrand> slangasek: thanks
<jdstrand> there shouldn't be many failures-- it only got uploaded a while ago
<slangasek> jdstrand: if you did it last week, then surely someone would've swept it off of component-mismatches again and back into universe :)
<jdstrand> right, so looking at http://people.canonical.com/~ubuntu-archive/testing/precise_outdate.html, there wasn't much. I poked ubiquity
<jdstrand> probably what happened
<jdstrand> incidentally, I reviewed the kernel in NEW. I'm just waiting on i386
 * jdstrand wanders off to check back in a bit
<rsalveti> janimo`: seems bug 935450 just need a rebuild
<ubottu> Launchpad bug 935450 in stressapptest (Ubuntu Precise) "stressapptest version 1.0.3-2ubuntu2 FTBFS on armhf in precise" [High,New] https://launchpad.net/bugs/935450
<ScottK> rsalveti: Retried.  https://launchpad.net/ubuntu/+source/stressapptest/1.0.3-2ubuntu2
<rsalveti> ScottK: thanks
<ScottK> rsalveti: You're welcome.  Please don't forget to mark the bug fixed if it works.
<rsalveti> sure
<shake> is anyone here? How does this work? I'm a complete noob to IRC
<bryceh> shake, pretty much everyone's off for the weekend
<shake> Wait, then why does it say 299 people are online?
<bryceh> shake, lots of people leave themselves logged in even if they're not watching the channel
<shake> Oh, ok, sorry I don't know these things, I've literally never used Xchat or any other IRC client up until this point
<bryceh> :-)
<bryceh> shake, don't worry you'll catch on quick
<shake> Ight
<arek_deepinit> hey Everyone, i got a question. Is gcc-4.7 to be default in Precise?
<PaoloRotolo> Hi all!
<gotwig> hey
<gotwig> I have an idea for ubuntu, explicit for the handling of applications in programms like the "Startup Applications" Service in the Control Center
<gotwig> why does ubuntu dont use the same method for picking applications from the privacy settings dialog , for other dialogs, like the startup applications one?
<gotwig> "doesnt"
<broder> @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: broder
<broder> in case anybody wants help with stuff :)
<jcole> i just bought a dual core motorolla droid 4 phone today running android 2.3.5... are there and alpha/beta releases of "Ubuntu for Android" for this device i could test?
<popey> jcole: no
<jcole> popey: is it just not released for this phone or is "Ubuntu for Android" it self not released
<popey> jcole: nothing has been released yet
<jcole> popey: hmm, thought it was already released since its featured all over ubuntu.com (ie: ubuntu.com/devices/android).. where is the release information for it (dates/phones to be supported/etc)?
<popey> jcole: we dont have dates yet
<jcole> popey: ok, thanks for the information
<broder> the way gizmodo covered it, it sounded like ubuntu for android would be launched when there was a phone to launch it on/manufacturer to launch it with
#ubuntu-devel 2012-03-04
<broder> hallyn: ping? around?
<broder> actually, unping
<broder> we need a better way to keep track of contributors than the changed-by line. it sucks that i can only give one person credit for a change in a way that we can easily collate automatically
<broder> anybody with some upstart-fu around? i'm trying to figure out the semantics of calling "stop;" from within an upstart script
<User_007> hello, i made some changes in a package source and i want to upload it to my ppa, how can i generate a .changes so i can upload it?
<broder> User_007: you can run "bzr bd -S" if you're using a bzr branch, or "debuild -S" otherwise
<User_007> broder, i only have the modified code, how do i create a .changes?
<broder> User_007: do you mean that you only have a diff, as opposed to a full package?
<crossfader> hi
<crossfader> ich weiss ja nicht, ob grad jemand da ist, der sich damit auskennt...
<broder> !de | crossfader
<ubottu> crossfader: In den meisten Ubuntu-KanÃ¤len wird nur Englisch gesprochen. FÃ¼r deutschsprachige Hilfe besuche bitte #ubuntu-de, #kubuntu-de, #edubuntu-de oder #ubuntu-at. Einfach "/join #ubuntu-de" eingeben. Danke fÃ¼r Dein VerstÃ¤ndnis!
<crossfader> ich will meinem kernel klar machen, dass er das root-fs Ã¼ber nfs zu ist
<crossfader> oops
<crossfader> sorry
<crossfader> joined the wrong channel
<broder> no problem :)
<crossfader> anyway, meybe you can help me
<broder> just wasn't sure whether you spoke english, and the bot's german is better than mine :-P
<crossfader> i try to boot my kernel into an nfs root-filesystem
<DawnLight> how come user processes are children of init directly? i would expect them to be children of gnome-session of unity or whatever
<User_007> broder,  sorry i only have the modified source, i mean, i downloaded the .orig.tar.bz extracted it and made my changes. Can you point me a step-by-step?
<broder> User_007: have you looked at http://developer.ubuntu.com/packaging/html/fixing-a-bug.html ? it has a good walkthrough for how to get the source and make a change to it
<broder> you need more than just the orig.tar.bz
<User_007> thanks, i will read it.
<broder> DawnLight: there are a lot of ways that user processes can be started, and lots of reasons that they might end up parented to init. any process whose parents dies, for instance, is automatically reparented
<DawnLight> broder, thanks
<DawnLight> i want to make a modification in ubuntu that whenever a user's locale is one of the several RTL locales and he tries to log into a unity session, he falls back to unity-2d, instead. where would i insert the code to that?
<DawnLight> in unity? in gnome-session?
<crossfader> i use the linux 2.6.24-30-generic kernel... as provided most actual kernel in Hardy
<crossfader> can i use the kernel-boot-parameter root=/dev/nfs with that kernel? does somebody know?
<broder> DawnLight: good question. i'm not really sure. my guess would be either in lightdm, but i don't know
<broder> you might want to send mail to ubuntu-desktop and ask for help
<broder> crossfader: sorry, i don't know anything about nfs-root. this channel is mostly for development, not support. you should try asking in #ubuntu (or possibly #ubuntu-de - i don't know how occupied that channel is)
<stgraber> broder, DawnLight: lightdm would be the wrong place for this, gnome-session sounds better or wherever the current 3d/2d check is. #ubuntu-desktop or ubuntu-desktop@lists.ubuntu.com is probably the best place to ask.
<crossfader> thanx broder
<crossfader> i try that
<crossfader> cu
<DawnLight> thanks a lot!
<broder> stgraber: hmm, ok. i thought lightdm hooked into that, but *shrug*
<stgraber> broder: it does indeed call the nux check and cache it to make login faster but that's on top of the existing gnome-session hook
 * broder nods
<stgraber> broder: doing it in lightdm would mean the code wouldn't work with LTSP or with KDM which are the biggest reason why the check is currently being done in both lightdm (for speed reason) and gnome-session (if no cached result from lightdm)
<broder> got it
<stgraber> broder: did you find the answer to your upstart question (related to "stop" IIRC)?
<broder> stgraber: nope. i'm trying to evaluate https://code.launchpad.net/~serge-hallyn/ubuntu/precise/bluez/bluez-respawn/+merge/95667
<stgraber> patch looks sane
<stgraber> stop + exit 0 will have upstart keep the job as stopped and not issue any error message
<broder> the stop is in the pre-start, incidentally
<stgraber> exit 1 + respawn would likely make upstart try to spawn it again a few times for no good reason
<stgraber> yep, that's fine, "stop" is usually done in pre-start to prevent the job from starting
<stgraber> I believe hallyn made that change based on what he did in the lxc.conf and lxc-net.conf jobs that have a similar check
<broder> cool. i'll go ahead and upload, then
<broder> thanks for the help
<stgraber> np
<slangasek> stgraber, broder: FWIW I don't consider variables like BLUETOOTH_ENABLED to be a very good reason to support /etc/default files
<slangasek> I would rather see that cleaned up entirely
<slangasek> (I've railed against such /etc/default usage even in Debian where everyone's still using init scripts; and with upstart jobs it's just silly to use such a method to disable jobs)
<broder> slangasek: hmm, what's your preferred approach for avoiding regression for users that are currently using the variable?
<stgraber> slangasek: well, in this case /etc/default/bluetooth contains a bit more than just that single variable, but I definitely agree we should never introduce a /etc/default/blah file just for that. Though handling the upgrade path is a bit tricky if we want to start removing these.
<broder> (it predates bluetooth being an upstart job)
<broder> there are also other variables in /etc/default/bluetooth
<slangasek> broder: well, I don't consider it a regression in any meaningful sense; but if you care about preserving that admin preference, I'd rather see it converted to an upstart override on upgrade
<slangasek> stgraber: yes, /etc/default/bluetooth contains *three* variables for disabling services, two of which are obsolete no-ops ;)
<slangasek> ah, no, perhaps the other two aren't obsolete, but they're just unrelated to the current upstart job
<stgraber> btw, do we have a tool to easily enable/disable upstart jobs (writting the override file for us) or is that still on the todo?
<slangasek> still on the todo
<slangasek> but for a one-time upgrade issue, it's easy enough to do echo manual >> /etc/init/bluetooth.conf.override
<slangasek> (or is that /etc/init/bluetooth.override?)
<broder> bluetooth.override
 * slangasek nods
<broder> ok, i guess i'll work on adjusting the initscript and adding some upgrade logic, and probably a NEWS.Debian entry?
<slangasek> initscript?  maintainer script?
<broder> well, removing the variable from the .default file and upstart job
<slangasek> right
<slangasek> I wouldn't personally bother with a NEWS.Debian, but I guess there's nothing wrong with that
<stgraber> right, so have a preinst source /etc/default/bluetooth, if disabled, write the override file (and print something for the user), then ship a new /etc/default/bluetooth without the BLUETOOTH_ENABLED part
<slangasek> postinst, not preinst
<slangasek> no need to do it before unpacking the new version of the package - that just makes rollbacks more complicated
<broder> slangasek: i'd like to leave a note somewhere for people who expect the variable to be there, and if i set a precedent of putting it in the .default file, it makes it harder to delete the .default file if the other 2 variables are ever obsoleted
<slangasek> oh, except this is a conffile and we want to avoid a conffile prompt, don't we
<stgraber> I guess you could even go as far as checking the checksum of /etc/default/bluetooth with BLUETOOTH_ENABLED=0 to avoid the config update prompt
<broder> oh yeah, i'd prefer to avoid the conffile prompt if i can
<stgraber> slangasek: right, my understanding was that we need the old /etc/default/bluetooth to do the check, so we need preinst
<stgraber> slangasek: (same for the checksuming)
<slangasek> broder: sure; my personal inclination would be to just spit a message out about it on stdout when the package is upgraded if this needed to be done and otherwise be silent, but NEWS.Debian isn't clearly a *wrong* thing to do
 * broder hates dealing with conffile upgrades
<broder> can we just leave it for now and deal during q? :)
<slangasek> if you wish ;)
<broder> i'm not exceptionally confident in my ability to get this right, and i'd like to focus on getting things out of the sponsorship queue today
<slangasek> broder, stgraber: checked bluez source, the other two default vars are no-ops in the current package
<slangasek> so that reduces the upgrade logic to preinst: source, check var, write override file, remove conffile
<stgraber> I think it'd be best to wait to have a tool to write/remove override files before we start converting things to them. Granted it's very easy to write (just one line) and it's documented in init(5) but I think it could do with a bit more visibility and having a tool to update the override should fix that.
<stgraber> so my opinion is that we should keep the current /etc/default/bluetooth for 12.04 and maybe start being aggressive (and consistent) on how to disable the jobs starting in 12.10
<slangasek> stgraber: well in that case, I would argue to just drop support for /etc/default/bluetooth from the package entirely *without* a transition to a .override, which is generally what we've done in upstart conversions
<stgraber> so that's not just bluetooth but anything using a similar hack (which AFAIK is a fair amount of packages)
<slangasek> no, almost all packages that have preserved /etc/default handling when converted to upstart jobs have done so because of non-trivial variables
<slangasek> not just for enable/disable handling
<broder> i'm inclined to agree with stgraber just because it decreases the flame coefficient
<broder> but i will also likely not be writing much/any of the code involved, so that's easy for me to say :-P
<slangasek> bluetooth is the package that's inconsistent here
<slangasek> bluez rather
<slangasek> it's spawning a pre-start script for no reason other than to check whether the service should be started.  That's unidiomatic in upstart, and slows the boot down
<broder> is that actually true in practice? i'd expect ureadahead to mostly nullify the impact
<broder> (performancewise - i accept that it's unidiomatic)
<slangasek> you still have the cpu cost of spawning another shell and doing stuff
<slangasek> I'm not saying "this script kills our boot performance" - but boot performance is why on the whole we don't do this
<stgraber> slangasek: I see that on my system apport, cryptdisks, irqbalance and qemu-kvm all have kept their ENABLE/DISABLE variables in /etc/default/ when converted to upstart, though indeed most of them have at least another variable coming from the file
<stgraber> so I think if we want to make the switch to .override (which is perfectly fine with me, I'm happy to see it used), we should do it consistently for all packages using upstart
<stgraber> s/using upstart/shipping an upstart job/
<stgraber> and only keep /etc/default/<package> for other variables (if any is left)
<slangasek> stgraber: the line I'm drawing is with jobs spawning an extra pre-start process *just* to check whether to start the service.  There are other incremental improvements we can make elsewhere to reduce the use of /etc/default, but they're in general a lot harder
<slangasek> cryptdisks and irqbalance parse their files for other variables and do it as part of a 'task' script; apport is a special case because the file is being regularly modified by the package (because we change whether to enable apport at different times in the release cycle); qemu-kvm actually doesn't use it to disable the service at all
<stgraber> doing that parsing in a task script sounds wrong to me though, it'll indeed avoid spawning an extra shell but will result in the job marked as running even though it's not
<slangasek> I don't think so, not if the job exits non-zero?
<stgraber> anyway, I understand your interest in saving a bit of boot time but I'd really much prefer doing something consistent and not have bluetooth be the only one doing it right as I think it'd just confuse our users...
<stgraber> if the exit non-zero it should be then marked as stopped indeed and will log a failure
<stgraber> the logging a failure part is the one that would be avoided with a check in pre-start + call to stop
<stgraber> (though I guess you can call "stop" from the task script too)
<slangasek> stgraber: as far as I'm concerned, "doing it right" is to drop the variable from /etc/default/bluetooth, period.
<slangasek> whether the maintainer script helpfully migrates that setting to a .override for the user is secondary
<slangasek> we never should have been using /etc/default for this in the first place, and there's no justification for carrying it forward with upstart
<User_007> broder, i installed bzr, got the branch, made my changes, commited... and now how to make a .changes? (i tried bzr -bd -S and it said -bd is unknow command)
<broder> User_007: bzr bd -S - no dash before the bd
<User_007> ok
<User_007> still unknow
<broder> User_007: you may need to install the bzr-builddeb package if you haven't already
<User_007> ok
<broder> slangasek: ok, say i decided to handle transition the /etc/default variable to an override file in the preinst. do i need to roll that back somewhere in the case of an upgrade failure?
<broder> http://paste.ubuntu.com/867621/ is what i have so far
<broder> http://wiki.debian.org/MaintainerScripts is kind of short on information on what to do if the unpack fails
<mbiebl> broder: I probably wouldn't do it on every upgrade and check if the override file already exists
<mbiebl> so you don't overwrite any custom local configuration
<broder> mbiebl: ah, sure. good point. let me adjust
<broder> mbiebl: ok, i think http://paste.ubuntu.com/867637/ should better handle the .override file existing already
<broder> (and it will only run on one upgrade)
<User_007> broder, i got some problems with signing the .changes
<broder> User_007: if you haven't already created a gpg key, you should probably read through http://developer.ubuntu.com/packaging/html/getting-set-up.html
<mbiebl> broder: looking at the Architecture: line, I'm wondering why it doesn't use linux-any
<broder> mbiebl: eh, that's not the sort of thing i'd generally introduce as an ubuntu change
<User_007> broder, i have already done everithing.... it seems bzr wants to use my computer name (user@computer) to find my gpg key
<broder> User_007: it uses the debian/changelog entry to figure out which key to use
<broder> so you probably didn't have DEBEMAIL set at the time you created the changelog entry
<mbiebl> broder: going to file a bug against the Debian package
<User_007> humm
<broder> mbiebl: cool, sounds like a good plan. do my changes seem correct to you?
<broder> (given slangasek's design goals)
<mbiebl> haven't checked the updated pastebin yet
<broder> k
<User_007> thanks a lot broder !
<broder> glad to help :)
<User_007> :)
<slangasek> broder: if it's done in the preinst, yes, you need to roll it back in the prerm
<broder> slangasek: the failed-upgrade case?
<slangasek> yep
<broder> i guess i need some sort of flagfile to tell if i was the one to edit the override
<broder> is there a convention on where i would do that?
<micahg> doko: you seemed  to have dropped my fix for icedtea-web with the new upload, someone already has a merge proposal with the same fix as last time, so I"m going to sponsor it
<broder> @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:
<shnatsel> cjwatson: I've patched Casper for elementary OS recently and discovered that recent additions are under-documented. Here's a fix: https://code.launchpad.net/~shnatsel/ubuntu/precise/casper/comments-on-flavour/+merge/95788
<fishor> hallo all, i currently have some linker dependensies problems on ubuntu12.04, the problems are with *.la files
<fishor> my question is. should actually *.la files be included to the packages or not
<fishor> becouse some are missing, some included
<PaoloRotolo> Hi all!
<Ampelbein> fishor: la files shouldn't be included in new packages. For existing packages they should be removed once no other package references them.
<JontheEchidna> on
<JontheEchidna> oops
<JontheEchidna> (hit konversation w/ my mousepad accidentally mid-typing)
<fishor> Ampelbein,  thx.. i trying to compile cheese from source bat there are still some not existing la dependencies. how can i find package with making me troubles
<fishor> i mean not existing la is not problem, but why configure script still include it?
<Ampelbein> fishor: 'grep "NAME_OF_THE_LA_NOT_FOUND" /usr/include -r'
<Ampelbein> fishor: Can you pastebin the error?
<fishor> Ampelbein, http://paste.ubuntu.com/868763/
<Ampelbein> fishor: try 'grep libatk-1.0.la /usr/lib -r"
<Ampelbein> fishor: Btw, I can build cheese fine in current precise.
<fishor> Ampelbein, thx... i found the files. thay are not from precise
<chromaticwt> will 12.04 be 64 bit?
<JanC> chromaticwt: Ubuntu has been available as both 32-bits & 64-bits since 2004...
<JanC> and that won't change for 12.04
<chromaticwt> wow, I don't know why I didn't realize this.
<micahg> it was discussed to make it 64 bit by default
<JanC> well, it has been 64-bit by default for servers
<JanC> I don't think 64-bit makes sense for desktops right now
<JanC> 64-bit kernel + 32-bit userspace might make more sense for most users...
<chromaticwt> JanC: If 12.04 is 64 bit by default will I still be able to run all of my favorite apps on it?
<JanC> chromaticwt: you can run 32-bit apps on a 64-bit system, so it shouldn't be a problem really
<chromaticwt> ok
<JanC> but AFAIK the default for 12.04 desktop will still be 32-bit (but with PAE required)
<chromaticwt> ok, I noticed that beta1 is available for download, so I'm going to upgrade to 64 bit beta1.
<chromaticwt> when 12.04 stable is released will I only need to issue apt-get upgrade to upgrade to the stable release?
<micahg> dist-upgrade, but yes
<stgraber> yes, if you do upgrades regularly, you'll always be on whatever is the current milestone
<stgraber> if you installed alpha-2 and did your updates, you're currently on something a bit newer than beta1
<chromaticwt> micahg: I need to do dist-upgrade even when upgrading from beta to release?
<JanC> actually, you need to do dist-upgrade even after the release  :P
<micahg> chromaticwt: yes, as there will likely be new packages
<chromaticwt> ok
<JanC> e.g. new kernel packages
<micahg> and dist-upgrade is preferable, but you need to be careful during the dev release or you can accidentally remove half your system at some points (update-manager is usually safer)
<chromaticwt> ok
 * JanC prefers Synaptic  ;)
<chromaticwt> so this is my plan. I want to upgrade to beta1 by doing a clean 64 bit install. then I will issue apt-get upgrade to update until release. once 12.04R is released I will use update-manager to upgrade to release.
<chromaticwt> I want the most stable system possible. should I just wait until release to upgrade?
<chromaticwt> I don't mind testing beta.
<chromaticwt> not to flood anymore about this.
<JanC> chromaticwt: no reason to use apt-get upgrade if you prefer a GUI...
<chromaticwt> JanC: personally I prefer the command line for most tasks.
<JanC> well, no need for update-manager to get the final release then  ;)
<chromaticwt> JanC: so I should use apt-get dist-upgrade or whatever?
<JanC> use apt-get dist-upgrade, but be sure to check what it wants to do before you allow it to remove packages
<chromaticwt> ok
#ubuntu-devel 2013-02-25
<ogra_> haha, xnox uploaded the cj<tab> fix :)
<infinity> ogra_: Hahaha.  I should upload that same default change for irssi.  I set it locally, but never though to do it globally.
<ogra_> :)
<uki> Hello everyone. I'd like to perform two tasks using apt-get/aptitude. 1. Generate a list of all packages present in the Ubuntu repositories. 2. Given a package name, get a list of the packages it depends on(preferably without having to download the package source),
<uki> Could someone help me on how I could go about doing that? Thanks in advance
<infinity> uki: See /var/lib/apt/lists and check out dctrl-tools
<uki> infinity: will do, thanks!
<infinity> uki: (And those sorts of questions probably belong in #ubuntu, not here)
<uki> ah okay, sure :)
<uki> infinity: Just to confirm, isnt /var/lib/apt/lists a list of packages that have been installed?
<infinity> uki: No, that's all the Packages/Sources files from the archive, listing everything you *can* install.
<uki> infinity: I see. Thank you!
 * infinity curses cmake.
<psusi> ohh, I feel as though I may have just had a brilliant stroke of insight...
<infinity> psusi: Does it involve why cmake's testsuite fails in raring?
<infinity> *hopeful look*
<psusi> ok... so the importer storing quilt patches already applied in the bzr branch causes many problems
<psusi> but not doing that makes bzr blame a problem
<psusi> so how about have the importer replay the quilt patches one at a time into separate commits in a new branch based on the unpatched branch, then merge that branch back into the master
<infinity> I didn't think bzr blame was the motivator at all, but just making a checkout the same as an unpacked source package.
<psusi> wait, no... maybe I'm drunk
<psusi> I just hate the packages already being applied
<psusi> patches rather
<infinity> I'm not a big fan of the udd workflow at all, so I'm not arguing for or against here. :P
<psusi> I find it fantastic when the quilt patches aren't applied
<infinity> jbicha: Well, I've transitioned everything for libarchive13 except cmake.  The cmake testsuite is sad in raring, and I'm not sure I want to spend any more of my Sunday trying to figure out why.
<jbicha> infinity: thanks again
<infinity> jbicha: Also, not to be picky, but actually fixing rdup correctly was easier than ignoring the deprecation warnings. :P
<infinity> jbicha: (Uploading the proper fix now and forwarding to Debian)
<infinity> jbicha: Was that the only package where you ignored the deprecation warnings?
<lifeless> infinity: rdup?
<infinity> lifeless: Yes...?
<lifeless> infinity: was that a typo for rdep ?
<lifeless> infinity: or a package name ?
<infinity> lifeless: It was a package name.
<infinity> https://launchpad.net/ubuntu/+source/rdup/1.1.11-1ubuntu2
<lifeless> heh, its very specific
<jbicha> infinity: I think so, I found the proper fix for pixz
<infinity> xnox: I know how much you *love* cmake.  I'll give you a shiny nickel if you can figure out why it FTBFS in current raring, but the same source builds fine against quantal.
<pitti> Good morning
<Sarvatt> xnox: so many lols, thanks for fixing xchat that way as someone hit by sa<tab> too much :)
<dholbach> good morning
<wooo> hey guys I have a doubt about vnode. I think the inode for a specific file system is the vnode for virtual file system. Am I right?
<lifeless> wooo: you might get a better answer in #ubuntu-kernel
<lifeless> wooo: but - http://www.linuxquestions.org/questions/linux-kernel-70/difference-between-inode-and-vnode-657954/
<lifeless> is what google tells me :>
<xnox> Sarvatt: heh =) well there is no way to auto-migrate people, so existing users will need to change settings. I will be blogging about it ;-)
<seb128> hum
<seb128> xnox, Laney, slangasek: is bug #1129157 the whoopsie/nm/ck one? did that got fixed/workedaround?
<ubottu> bug 1129157 in lightdm (Ubuntu) "lightdm pausing a long time at boot" [Undecided,Confirmed] https://launchpad.net/bugs/1129157
 * xnox thought the whoopsie/nm/ck was bug 1124330
<ubottu> bug 1124330 in whoopsie (Ubuntu) "[raring] Latest whoopsie 0.2.13 slows down boot process by 29 seconds!" [High,Confirmed] https://launchpad.net/bugs/1124330
<seb128> xnox, I'm asking if the one I pointed at is likely a duplicate or if you think it's a different issue ;-)
<xnox> ah.
<Laney> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1123798
<ubottu> Ubuntu bug 1123798 in whoopsie (Ubuntu) "ubiquity-dm crashed with dbus.exceptions.DBusException in call_blocking(): org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.ConsoleKit timed out" [High,Confirmed]
<Laney> I suppose it could be a dupe
<seb128> I wonder how many different bugs we have for the issue :p
<Laney> I wonder if we should revert that libnm-glib stuff for now
<Laney> it was supposed to fix some leak but the problems it introduces seem to be worse
<seb128> yeah
<seb128> I'm still unsure how it does manage to screw ck though
<seb128> it's weird that a buggy dbus service manages to break ck
<Laney> ev: â
<ev> Laney: I'm worried that we're just kicking the can
<seb128> ev, well, we can't keep raring broken for users, we either need somebody to focus on it and fix it soon or to revert until we can come with a fix
<seb128> it seems like nobody has a good understanding of the issue and that it might take a while so maybe best to revert
<ev> fair point
<ev> adding it to my todo list for today
<jamespage> doko, re the zookeeper FTBFS with gcc-4.8 and glibc-2.17 - I think that is glibc as I've been hitting those same test failures in raring
<seb128> ev, thanks
<doko> jamespage, ok, could you change the user/usertag ?
<jamespage> doko, sure
<xnox> doko: ... and you are expecting me to fix all the debian-med gcc4.8 failures?! =))))
 * xnox got spammed by doko
<Laney> what changed to make my VMs reeeeeeeeallly sloooooooooooooooooooooowww?
<diwic> if you'd like one FTBFS less, feel free to sponsor bug 1074673
<ubottu> bug 1074673 in ubuntu-nexus7 "JACK server fails to start" [Medium,Triaged] https://launchpad.net/bugs/1074673
<Laney> qemu-system-x86 is using all of one core
<tumbleweed> no kvm?
<Laney> there should be
<seb128> diwic, are those fixes including in jackd upstream? Debian has a new version, maybe we should sync that?
<diwic> seb128, the FTBFS fix is is upstream. Also in Debian, but I tried the git version, but it has other FTBFSes instead
<seb128> diwic, ok
<diwic> seb128, the fix for arm is still under debate upstream, but I figure it would be better to have something with a theoretical issue, than not working at all
<seb128> diwic, I was just asking in case, I saw that our version is older than the Debian one and was wondering if it would make sense to sync the new one
<seb128> diwic, right
<diwic> seb128, sure, that's a fair question, I tried that too, first, and it failed with FTBFS even earlier :-)
<Laney> yeah "kvm support: disabled"
<Laney> permissions on /dev/kvm seem ok
<Laney> hmm or maybe not
<Laney> ah yes, reboot â correct now
<seb128> Laney, :-(
<seb128> starting sounding like old time win, stuff don't work, let's reboot
<Laney> it's a bug where after you upgrade qemu the permissions of /dev/kvm are set to root:root
<Laney> if you get the udev event to fire (e.g. by rebooting) then they are set correctly
<Laney> hallyn is trying to fix it
<seb128> ok
<ev> mpt: the quote on my desk comes from this book: http://www.amazon.com/Controlling-Software-Projects-Management-Measurement/dp/0131717111
<ev> was just reading a slide deck that referenced it and remembered that I never gave you a link to the book
<ev> I've never read it myself - I came by it via an article he wrote for the IEEE
<shakaran> Hi, there are some plan for fix nvidia drivers before to raring release? I am worry for don't get a working driver at time of 13.04 https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/1083925
<ubottu> Ubuntu bug 1083925 in nvidia-graphics-drivers-updates (Ubuntu) "nvidia kernel module failed to build on kernel >= 3.7 [error: #error remap_page_range() conftest failed!]" [Undecided,Confirmed]
<bdrung> xnox: thanks for fixing bug #189222
<ubottu> bug 189222 in xchat (Ubuntu) "Xchat changes focus to new channels after automatic joins on connect and clears highlight" [Low,Fix released] https://launchpad.net/bugs/189222
<xnox> bdrung: thank you =)
 * xnox feels like a rock-star. This is second Kudos about a single upload on irc ;-)
<Laney> next stop LWN
 * bdrung looks at the bug again.
<xnox> Laney: I'm yet to be featured on LWN =)
<bdrung> xnox: ah, you just enabled my workaround :)
 * xnox is quite happy with 3 appearances in "3Touch" magazine (the only UK volleyball magazine)
<Laney> get you
<Laney> (hope you forwarded these changes to debian)
<xnox> bdrung: yeah, so no manual migration. But I was sick of that bug to the point of almost switching to *gasp* quassel (no libmessaging) or smuxi (mono/no channel tree view)
<xnox> Laney: well....
 * xnox has a backlog of stuff to forward.
 * Laney glares at (mono)
<xnox> My library is in /lib should the dev .so be in /lib or can it stay in /usr/lib ?
<xnox> What's the best practice?
<xnox> (or it doesn't really matter as long as pkg-config works correctly)
<lool> cjwatson: -proposed migration currently considers installability with Depends/Conflicts etc., but do we have a way to detect that a package misses conflicts/replaces?  I've got an upgrade error with latest gtk+2.0 and am thinking that we ought to have some kind of check to avoid this to users of the rolling release
<lool> (this seems to involve :amd64 and :i386 packages on the same system, so might be trickier than just within one arch)
<seb128> lool, if you can debug that one I would welcome that, it seems the file that ough to be the same between archs is different
<cjwatson> lool: No, there's no code to do that at the moment
<cjwatson> (And it's pretty hard)
<cjwatson> Multiarch file differences are indeed not a matter of missing Replaces
<lool> cjwatson: Yeah, it wasn't actually a conflict/replace issue but rather a difference between files wihch should be identical
<lool> cjwatson: I wonder whether we ought to run a separate service generating hints to not allow promotion of broken updates tough
<lool> *though
<seb128> lool, before that upload in seems like the amd64 binary had a symlink for /usr/share/doc/gtk2-engines-pixbuf/README.gz
<seb128> Laney, ^
<seb128> -	dh_compress -s -X.sgml -X.devhelp -XNEWS -Xchangelog.Debian -XREADME
<seb128> +	dh_compress -s -X.sgml -X.devhelp
<seb128> in the update's diff
<seb128> not sure why that would lead to that though
<lool> -	dh_compress -s -X.sgml -X.devhelp -XNEWS -Xchangelog.Debian -XREADME
<lool> +	dh_compress -s -X.sgml -X.devhelp
<lool> Yes
<lool> seb128: clearly just a change to the arch dep packages rather the arch-indep ones for one
<seb128> right
<lool> seb128: Funny we've found it at the same time :)
<seb128> lool, do you want to fix it or should I?
<lool> seb128: I'm happy if you do
<seb128> lool, ok
<seb128> lool, hum, weird, the -i call is identic
<seb128> 	dh_compress -i -X.sgml -X.devhelp
<lool> seb128: got changed in r15782
<lool> * Apply multiarch patch by Javier Serrano Polo, replacing all
<lool>   occurrences of usr/lib by $(LIBDIR). Closes: #468100.
<lool> * rules: don't compress .sgml and .devhelp files.
<lool> seb128: Sorry, wrong branch
<seb128> lool, we had
<seb128> -    - Use -XNEWS -Xchangelog.Debian -XREADME to dh_compress calls to
<seb128> -      workaround a gzip issue leading to different md5sum between builds
<lool> seb128: It seems like a merge error
<seb128> but I though that gzip issue got fixed in between
<lool> seb128: Was it actually so that it was a gzip issue?
<seb128> yes
<lool> seb128: perhaps it was hiding this other issue with pkgbinarymangler interfering
<seb128> the .gz were getting different md5 on i386 and amd64 for sure
<seb128> but maybe it was hiding a second issue as well
<xnox> interesting.
<lool> seb128: I guess because of the difference of checksums we had -X for a while, but it wouldn't have worked with pkgbinarymangler also interfering and making files to symlinks only in some builds
<Laney> it's weird that the symlinke from e.g. libgtk2.0-0 works
<seb128> yeah, and symlinks from previous built worked
<seb128> builds
<Laney> ah
<Laney> they're done manually
<Laney> see debian/*.links.in
<lool> that's even weirder, why wouldn't it have symlinks in one case?
<lool> ah I guess they get generated the same, but then pkgbinarymangler outsmarts them
<seb128> but why wasn't it doing that before then?
<lool> if that's the issue, we could set NO_DOC_PKG_MANGLE to avoid this
<seb128> or just drop the .links.in and let pkgbinarymangler does its job?
<seb128> do*
<lool> seb128: that might be more delta with Debian though
<seb128> yeah
<seb128> lool, I'm still not sure to understand what's happening exactly there though
<seb128> Laney, are you working on it? (no need to be several debugging the issue, I'm happy to let you investigate if you are already doing that)
<seb128> I'm over the "read the diff to spot a potential merge error"
<seb128> that needs some debugging
<Laney> sure I'll look at it
<lool> seb128: clearly I see why pkgbinarymangler wouldn't work the same on amd64
<seb128> lool, oh, why?
<seb128> Laney, thanks
<lool> it walks all deps, and skips the ones where test -d ../$dep/usr/share/doc fails
<xnox> missing arch_all package build?! but how would that matter.
<lool> so it wont go through the same candidates
<lool> hmm actually it discards deps on arch: all entirely anyway
<seb128> the easiest way seems to add back those files to the dh_compress
<seb128> though I'm still unsure if that's this change who leads to the issue, and why we had a compressed file before if we were excluding them from dh_compress
<lool> seb128: So one difference between libgtk2.0-0 and gtk-pixbuf is that both have a .links.in file, but dh_installdocs is only called on gtk-pixbuf
<lool> *gdk
<lool> (search for DH_INSTALLDOCS_FILES in rules)
<Laney> bah, I got a symlink in my test build
<seb128> Laney, did you build the arch all?
<Laney> no
<seb128> :-(
<Laney> perhaps pkgbinarymangler didnt run though
<Laney> ah, whoops I did build with -A (stupid muscle memory)
<Laney> that's better
<Riddell> doko: I've a probably fix for qtwebkit on powerpc
<Riddell> doko: qtwebkit-source_2.3-0ubuntu5.debdiff
<Riddell> doko: think I can just upload or does it need testing somehow?
<doko> Riddell, just upload
<Riddell> doko: can you eye it over for syntax sanity? http://paste.kde.org/680882/
<doko> Riddell, ok. just curious why build-webkit is called twice ...
<Riddell> doko: I don't even remember, I just know it broke on the first run :(
<doko> Riddell, could something similiar be done with qt5?
<Riddell> doko: similar to what?
<Riddell> doko: it's waiting on qtlocation5-dev
<doko> Riddell, yes, building qtlocation5-dev without the js dependency
<Riddell> mm qtjsbackend broken
<doko> ScottK, are you involved with boost in Debian?
<ScottK> doko: No.
 * xnox hides
<Riddell> doko: hmm syntax failed, it added the ENABLE_JIT=0 on i386 https://launchpadlibrarian.net/132300747/buildlog_ubuntu-raring-i386.qtwebkit-source_2.3-0ubuntu5_FAILEDTOBUILD.txt.gz
<doko> Riddell, you asked me to check syntax, not semantices ;-p
<Riddell> ifneq (,$(filter $(DEB_HOST_ARCH),powerpc))  that's true on i386?
<Riddell> make is scary foo
<seb128> diwic, was there any issue with syncing jackd2 from debian? I saw that bdrung did that rather than using your patch, but this morning you seemed to imply your patch was still needed?
<diwic> seb128, argh
<seb128> diwic, it built, not sure if it will work
<bdrung> i checked the diff and saw that the proposed patches were included
<diwic> bdrung, the ARM patch too?
<diwic> bdrung, the one with PACKED something
<bdrung> diwic: yes, both
<diwic> bdrung, ok, found it.
<diwic> bdrung, seb128 thanks for looking it up. Let's try this version then and see if it works.
<seb128> diwic, thanks
<steven____> hey all
<steven____> is this the correct channel for questions about developing applications?
<xnox> steven____: #ubuntu-app-devel is a better place =)
<steven____> ok, then ill go there
<steven____> thx :)
<xnox> steven____: #ubuntu-packaging for creating a deb from a ready application
<xnox> steven____: np.
<steven____> nah, will take some time before its ready to be packed...
<psusi> smoser: I backported the online resize patches to our parted and pushed the branch if you are interested in testing it.  Not sure if it's a little late in the cycle to merge it or not.
<smoser> psusi, https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1096999 ?
<ubottu> Ubuntu bug 1096999 in util-linux (Ubuntu) "add new partx update and resize upstream features" [Low,Fix released]
<smoser> that shows fix-released. ie, i thought i uploaded that for you.
<smoser> oh.  *parted*. gotcha.
<smoser> psusi, i dont think its too late in the cycle.
<smoser> but i'd ask someone else who has been active in parted package.
<mterry> @pilot in
* udevbot 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: mterry
<xnox> smoser: psusi: sounds like we should find resources to port d-i then continuing to backport parted features.
<xnox> s/then/than/
 * dholbach hugs mterry
<psusi> xnox: that would be nice
<psusi> does anyone know if landscape-client release 13.02 is planned to make it into raring?
<xnox> psusi: it should, why do you ask? anything interesting you are after?
<SpamapS> Unpacking replacement gtk2-engines-pixbuf:amd64 ...
<SpamapS> dpkg: error processing /var/cache/apt/archives/gtk2-engines-pixbuf_2.24.16-1ubuntu1_amd64.deb (--unpack): trying to overwrite shared '/usr/share/doc/gtk2-engines-pixbuf/README.gz', which is different from other instances of package gtk2-engines-pixbuf:amd64
<SpamapS> known bug?
<Laney> yes
<SpamapS> Ok, will just move on. :)
<psusi> xnox: yes, I patched it to report the *correct* memory usage.. it was merged upstream, just wondering if I can delete the merge request to ubuntu since upstream will have it next time it releases and is merged
<xnox> psusi: if it landed in the upstream branch, there is no need for any other merge proposals / branches.
<jbicha> pitti: do you know of a way to enable apport for just specific PPAs? I was just using this basic code http://paste.ubuntu.com/5565457/
<dobey> xorg has SIGABRTed on me 3 times in the last 18 hours or so, so far. :( same crash as a bug report i filed a few weeks ago. who can i bribe to fix it?
<tumbleweed> mterry: you can leave Logan_ to upload his own packages now - he just joined MOTU
<mterry> tumbleweed, oh nice  :)
<mterry> Logan_, congrats; I'll leave you to it
<Logan_> Thanks! :)
<infinity> dobey: You can bribe me.
<infinity> dobey: I won't fix it, but I could use some spending money.
<dobey> here's a nickel kid. :)
<infinity> dobey: I wonder if that's the same nickel I was offering to get someone to fix cmake's testsuite on raring.  That thing gets around.
<mterry> @pilot out
* udevbot 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> could be
<infinity> kenvandine: Say, you're TIL on cmake.  Any urge to sort out WTF it doesn't pass its testsuite anymore?
<kenvandine> infinity, ugh... not really
<kenvandine> i haven't done much with cmake
<infinity> kenvandine: Probably more than I have.
<kenvandine> just re-applied a patch that someone had accidentally dropped
<kenvandine> i can take a look
<kenvandine> but no promises :)
<infinity> Yeah.  I was doing the same "I'll look, but no promises" thing this week, but clearly someone needs to hunt it down.
<infinity> I haven't dug far enough to determine if it's a cmake bug, a testsuite bug, or if something fundamentally broke in the toolchain or a dependency that broke it.
<infinity> But a simple rebuild fails now.
<infinity> (And it needs a rebuild for the libarchive transition)
 * kenvandine grabs the source
<infinity> kenvandine: For the record, it's not libarchive that breaks it, cause building against only the release pocket also breaks, no need for proposed to reproduce.
<infinity> (Not that I'd expect libarchive to be the culprit, as the test that fails is some xmlrpc submission thing)
<infinity> There has been a new version of cURL, which seems a likely candidate.
<infinity> mdeslaur: So maybe this is your problem. :P
 * infinity has a thought...
<xnox> infinity: where do you see cmake not passing it's testsuite ?!
<infinity> I wonder if it's double-linking two different libcurls or something.
<infinity> xnox: On a rebuild.
<xnox> infinity: ah.
 * infinity spins up another test build here to save the binaries.
 * xnox looks at his +1 maintainance availability and notices that has None =))))
<infinity> pitti: Around?
<mterry> zul, I'm looking at the rtslib MIR.  Why the fb27 version suffix?
<barry> tumbleweed: ping
<kenvandine> infinity, indeed i libcurl looks suspicious
<tumbleweed> barry: yeah?
<kenvandine> there is a crash in some xmlrpc test that says libcurl in the output
<kenvandine>  Submission problem: libcurl failed to execute the HTTP POST transaction, explaining:  <url> malformed (-504)
<barry> tumbleweed: hi.  i just merged a fix to trunk and uploaded to pypi for bug 1132125.  i want to get this into ubuntu, but i am happy to update the debian package to wadllib 1.3.2 first.  you're the maintainer, is this cool with you?
<ubottu> bug 1132125 in python-wadllib (Ubuntu Raring) "python-wadllib ftbfs in raring" [High,Fix released] https://launchpad.net/bugs/1132125
<tumbleweed> barry: please go ahead
<barry> tumbleweed: if you want to review the svn changes first, that's also fine
<tumbleweed> happy to review & sponsor it
<barry> tumbleweed: awesome, thanks.  i'll ping you after i test the rebuild and commit svn (should be soon-ish)
<kenvandine> infinity, although i can't make heads or tails of how to isolate that test right now...
<kenvandine> i gotta head out
<kenvandine> infinity, make test succeeds in the /Build/Tests/CTestTestFailedSubmits/xmlrpc dir
<kenvandine> which looks like where it blew up
<mdeslaur> infinity: hum, what now?
<mdeslaur> infinity: what'd I break?
<infinity> mdeslaur: Shot in the dark, but it seems that the new cURL broke cmake's testsuite somehow.
<infinity> mdeslaur: None of us being terribly familiar with cmake or its tests, it's a bit of a learning curve to hunt. :P
<mdeslaur> infinity: the cmake that's currently in raring, or a new one from debian?
<infinity> kenvandine: Yeah, make test gives the same output as the build log, minus the next bit...
<infinity> mdeslaur: The current one in raring.  Rebuilding it breaks.
 * mdeslaur tries now
<infinity> mdeslaur: And it built fine less than a month ago, so that limits the options for what broke it.
<jtaylor> barry: mind looking over the patch in https://bugreports.qt-project.org/browse/PYSIDE-145 if you happen to know details about the mechanism and change
<jtaylor> barry: a generated file looks like this: http://paste.ubuntu.com/5566184/   *_nonstatic is added
<barry> jtaylor: sure.  i'm sitting on my thumbs anyway until svn.debian.org's fail2ban lockout expires ;)
<jtaylor> barry: related to bug 1070772
<ubottu> bug 1070772 in shiboken (Ubuntu) "modelview_test.py segfaults python" [High,Confirmed] https://launchpad.net/bugs/1070772
<jtaylor> barry: the context is shiboken adds some kind of wrapper which works for static and nonstatic overloads
<jtaylor> barry:  e.g. obj.exists() calls the nonstatic one, and class.exists('filename') the static one
<jtaylor> apparently the nonstatic one is found over the getattro, so I added the new PyDef and used it there
<jtaylor> PyMethodDe
<barry> jtaylor: i see nothing in py33's Misc/NEWS file about the change (doesn't mean it didn't happen of course).  what exactly is the behavior change?
<jtaylor> barry: previously it used the same METH_STATIC function for both and it passed NULL for self in the first case nevertheless
<jtaylor> barry: now both calls get NULL
<jtaylor> barry: not sure why but its not surprising me, defining a function static is certainly not part up pythons api
<jtaylor> so they can break it without documenting
<jtaylor> defining static when its not
<barry> jtaylor: interesting!
<barry> jtaylor: i don't even see any mention of METH_STATIC in upstream `hg -v -b 3.3 log` output
<jtaylor> hm
<jtaylor> it might have been broken in older python3
<jtaylor> I think older versions did not run the testsuite
<barry> jtaylor: but definitely a py2/py3 change?
<jtaylor> hm no it worked in debian with 3.2
<barry> hmm, maybe the change didn't happen in Objects/methodobject.c
 * xnox was sure to be able to reproduce the shiboken fail with other pythons.
 * xnox quickly scans my local build logs
<jtaylor> xnox: the segfaults happens with all
<jtaylor> xnox: the static fail only with python3
<xnox> ah, ok.
<barry> jtaylor: http://paste.ubuntu.com/5566184/
<barry> jtaylor: i'm wondering if lines 355-356 should be out side of the if(self) test?
<jtaylor> barry: you mean if self is null it should return the static one?
<barry> jtaylor: just guessing, but maybe the PyObject_GGA() will dtrt anyway
<barry> jtaylor: nm
<barry> jtaylor: i'm reading static/nonstatic backwards
<barry> _exists is the class version _exists_nonstatic is the instance version
<jtaylor> barry:  my irc server seems to be down :/
<jtaylor> barry did you say something since line 355-... ?
<barry> <barry> jtaylor: nm
<barry> <barry> jtaylor: i'm reading static/nonstatic backwards
<barry> <barry> _exists is the class version _exists_nonstatic is the instance version
<barry>  
<barry> jtaylor: so i think it looks sane
<barry> jtaylor: the diff in qt-project.org is a bit hard to read due to lack of context and my unfamiliarity with the code, but the generated file doesn't look bad
<barry> tumbleweed: r23595
<jtaylor> yey im back
<jtaylor> the ttests all succeed so the diff is probably ok, the segfault is more problematic
<barry> jtaylor: it stops segfaulting after that patch though right?
<jtaylor> one could add an intentional memleak or ignore the test, possibly having a broken py3 package
<jtaylor> don't know whats better
<jtaylor> barry: no that patch fixes to other failures
<barry> oh ;)
<barry> i hate memleaks, but sometimes those things are really horribly painful to track down.  is it in a high traffic section?  (like, leak 1k every time you type the letter 'e'? ;)
<jtaylor> good question, no idea
<jtaylor> I wanted to try it, but I fail since ages to install raring
<jtaylor> the test is named modelview so its probably a core component
 * xnox wants to hear the 1k leak on 'e' story, as it sounds so hilarious that it may have been actually true.
<jtaylor> the code is horrible, its full of races even without the crash line
<barry> xnox: mostly fictional, but i do have another fun one that is kind of similar.  for another time perhaps :)
<barry> jtaylor: that makes me sad
<jtaylor> xnox: there is a bug on OS X if you type 8 characters almost every app will crash :) I think its fixed no though
<barry> jtaylor: yeah, i think they released a fix for that.  it was like a file://// path typed somewhere
<jtaylor> < offline, lets hope upstream replies to one of the bugs soon :/
<jtaylor> barry, thx for the check
<xnox> bug 248619 was fun, especially it's consequences of not being able to print on tuesdays, see bug 255161 with "it works today" "it stopped working" "it works yet again!"
<ubottu> bug 248619 in file (Ubuntu Karmic) "file incorrectly labeled as Erlang JAM file (OOo does not print on Tuesdays)" [High,Fix released] https://launchpad.net/bugs/248619
<ubottu> bug 248619 in file (Ubuntu Karmic) "duplicate for #255161 file incorrectly labeled as Erlang JAM file (OOo does not print on Tuesdays)" [High,Fix released] https://launchpad.net/bugs/248619
<xnox> jtaylor: well upstream does mention that all patches should go via geritt code review instance, which has a few old pyside patches lingering.
<xnox> I wonder if we can find to poke some people about them.
#ubuntu-devel 2013-02-26
<cjohnston> nice work xnox! cjwatson did you see the xchat change?
<infinity> cjohnston: Most important change in the distro in years? :P
<infinity> cjohnston: I need to make the same change for irssi.
<cjohnston> infinity: probably. lol
<infinity> Actually, that may already be the irssi default, it may just not always keep enough history to remember who my last-tabbed cj was.
<infinity> I'll have to experiment.
<cjohnston> jtaylor: how did the work go with shiboken? ever figure it out?
<infinity> cjwatson: Testing, ignore.
<infinity> Yeah, my irrsi does the last-tabbed cj correctly on this machne.
<infinity> irssi, too.
<cjohnston> mine defaults to cjw.. :-)  lucky me! lol
<cjohnston> Glad I don't ping myself
<infinity> I still get messed up on ogra/ogasawara though, since I talk to both of them alternately.  Oh well.
<infinity> Need a telepathic IRC client.  Or to not be lazy and type 3 chars.
<StevenK> infinity: You? Not lazy?
<TheMuso> I've trained myself to type 3 chars now, tends to help.
<cjohnston> hehe.. 1 2 3 tab works in two cases
<infinity> StevenK: Hush, you.
<slangasek> infinity: instead of just hitting tab twice when it autocompletes wrong?  same number of keypresses ;)
<infinity> slangasek: Cycling through hurts my tiny brain.  All that flashing text.
<slangasek> cycling is good exercise
<infinity> *rimshot*
<cjohnston> I could say I finally made a changelog.. lol
<infinity> Although, that may have been more deserving of a sadtrombone.com
<cjwatson> cjohnston: Yeah, I noticed - hopefully it'll trickle down to people's configuration eventually ...
 * infinity ponders changing his name to cjfinity.
<cjohnston> go for it
<infinity> cjwatson: You could have avoided this whole mess by going back to Kamion.
 * StevenK waits for infinity to say "See, this is all your fault. Not mine for being inflexible, at all."
<infinity> StevenK: Absolutely.  And I'm infinity, not inflexible.  Your tab-completion sucks.
<cjwatson> I got lazy and wanted same username everywhere.  Spare neurons are in shorter supply nowadays.
<StevenK> Or is awesome for tab-completing a word that doesn't appear in the nick list?
<cjohnston> cjwatson: in that case I should change to chrisjohnston
<infinity> StevenK: It's the new gmail tab completion that scans your email and offers suggestions based on your grandmother's eulogy.
<cjohnston> cjohnston was taken on LP :-(
<StevenK> infinity: Good job that I don't use gmail, then.
<StevenK> And my grandmother's eulogy was in Polish only.
<infinity> You sure can ruin a joke.
<StevenK> I try.
<infinity> StevenK: I think this is an appropriate time to point out that when Pete and I were doing some budgeting earlier, we only budgeted for one Soyuz developer.
<infinity> StevenK: You and William will be expected to battle to the death.
<StevenK> Hah
<cjohnston> lol
<Logan_> bdrung: Hey, mind if I PM?
<jbicha> pitti: I figured out my apport question: http://paste.ubuntu.com/5566568/
<psusi> ps will show WCHAN while a task is blocked... how can I get a full kernel stack backtrace instead?
<sarnold> psusi: there's a sysrq key for that...
<sarnold> psusi:
<sarnold> psusi: 'l' will dump the stack for all cpus
<sarnold> psusi: 't' will dump a list of current tasks "and their information" -- whatever that is. it might be more useful (and also likely much uch more data)
<psusi> sarnold, right, I was hoping for a way to just get the stack trace of the one task
<sarnold> psusi: hehe yeah :) I just don't know the way to do that
<psusi> blargh... damn recent kernels and their disabling magic-sqreq functions by default
<hyperair> sarnold: tasks == processes + kthreads.
<hyperair> psusi: it's not a recent kernel thing. it's a sysctl.d thing
<sarnold> hyperair: sorry, I meant it in the sense of, "I don't know if that includes the stack dumps or just eip"...
<psusi> yea, but where's the defaults set?  not sure if it's an Ubuntu thing or an upstream change that changed the defaults
<psusi> but it's annoying as all hell
<hyperair> psusi: /etc/sysctl.d/10-magic-sysrq.conf
<hyperair> i agree it's annoying.
 * hyperair uses alt+sysrq+k all the time
<psusi> yea, same
<psusi> well, not all the time, but... when things go wrong, which is not all that infrequently
<hyperair> well the idea was that if you trigger the OOM killer enough, you might accidentally kill the screensaver (but not the rest of the X session), allowing you to gain access into the X session
<hyperair> and from there, possibly an open sudo session..
<hyperair> or cached sudo session, for that matter
<infinity> Not an entirely implausible situation.
<hyperair> infinity: yeah, but i'd prefer for gnome-screensaver to just poke oom_adj itself
<infinity> screensavers swap out quickly, and as children of other more interesting things, would likely die early in the reaping.
<psusi> seems to me you could still do that by hogging memory, so the proper fix is to make the screensaver immune to oom
<infinity> Nothing's immune to the oom killer, is it?
<psusi> iirc, there were knobs you could tune to tell it not to consider certain processes
<hyperair> infinity: well, it's enough to make gnome-session or X11 go out before gnome-screensaver.
<sarnold> /proc/self/oom_*adj
<psusi> if you kill those then you end the X session
<hyperair> https://lwn.net/Articles/317814/
<hyperair> set oom_adj to -17, and it isn't considered for OOM killing
<hyperair> bingo
 * hyperair dpkg-divert's gnome-screensaver
<hyperair> psusi: well that's the idea, right? you don't want it to unlock your screen -- you want it to take out your X session, which is much more useful when a program goes into a runaway memory allocation loop
<hyperair> which does happen.
<psusi> hyperair, indeed
<hyperair> and unity deals *very* badly with such situations
<psusi> or when you are trying to play an opengl game and the gpu goes apeshit ;)
<hyperair> the whole display just freezes up because unity can't draw anything
<hyperair> psusi: that's alt+sysrq+k, not f
<psusi> ohh, thought that's what you were talking about
<hyperair> speaking of which, i wonder how ubuntu phone deals with application lifetime?
<hyperair> does it also do the android oom-killer thing
<hyperair> ?
<lifeless> hyperair: 'phone-home' :P
<hyperair> lifeless: phone-home?
<lifeless> hyperair: bad joke
<hyperair> heh
<hyperair> the unity amazon issue, was it?
<psusi> no idea, but I was doing a kernel config today and saw the opportunistic system sleep and wakelocks that android introduced and wondered if that might be a nice thing for my server to do... automatically enter S3 when nobody is connected
<lifeless> hyperair: nah, referencing ET
<hyperair> oh.
<psusi> wake on lan when someone connects...
<hyperair> wasn't that S4 or something?
<psusi> well, it certainly isn't hibernation on androids ;)
<hyperair> well yes
<hyperair> er wait, is S4 hibernation?
<psusi> not sure if it's S1 or S3, but generally I think S1 died
<psusi> yea
<hyperair> ah, S4 is hibernate.
<psusi> way back before power supplies supported standby mode, S1 was kind of a useless state that stopped everything executing but since the psu didn't go to standby, about the only power it saved was putting the hard drive to sleep
<hyperair> lol
<hyperair> surely it's up to the individual devices to draw power from the PSU?
<hyperair> the CPU is powered down isn't it? and iirc that's a significant amount of power
<psusi> not really.. for most devices, if psu gives them power, they are on
<hyperair> oh
<hyperair> interesting.
<psusi> these days the CPU powers off while the system in in S0, via deep C states
<hyperair> but not completely
<psusi> does at least with Intel deep C6
<hyperair> oh
<hyperair> what about C7?
<psusi> deep C6 is the bottom
<hyperair> hmm, it says C7-SNB on mine.
<psusi> hrm... last I read the Intel specs, they did C0, C1, C3, C6, and in C6 vcc to the cpu was 0
<hyperair> hmm
<psusi> well, the sysrq full task info turned out to be sufficient... I found the bug in ext4
<pitti> Good morning
<pitti> jbicha: indeed, that seems right
<pitti> jbicha: but NB that this will still use the default configuration which crashes to send to LP and which not
<pitti> jbicha: if you want to keep crash reports even if "main" ubuntu disables LP reports by default, you can do that, too; let me know what you need
<pitti> infinity: I am now
<erickLee> hello. pbuilder-dist <realease> create command not working for precise pangolin.
<infinity> pitti: I know we've been over this a few dozen times in the past, but do you have a reasonable estimate for growth-over-time of ddebs, so we can capacity plan for the librarian shift?
<pitti> infinity: no precise numbers for each release, as /pool overlaps, etc. but let me try an estimate how much we would have if I hadn't removed older releases
<jbicha> pitti: I think that will be fine for now, it was annoying not to be able to use ubuntu-bug
<pitti> jbicha: ah yes, for bug reporting your stanza is perfectly fine
<pitti> jbicha: btw, I take it we want to put that into /usr/share/apport/general-hooks/ubuntu.py, not into every single GNOME package?
<jbicha> pitti: oh wow that would be a lot nicer
<pitti> infinity: so http://paste.ubuntu.com/5566793/ is what we have today
<pitti> infinity: NB that none of the releases have powerpc ddebs
<infinity> pitti: Okay, well, that's much (much) smaller than I initially budgeted for, so we should be alright for a little while once we get this sorted.
<pitti> infinity: /pool gets a bit fatter due to pulling ddebs from magic PPAs, and we currently keep old ddebs around for 30 days
<infinity> pitti: Yeah, but I have to account for PPA storage too, so...
<pitti> infinity: so assuming we keep 3 arches and stop removing packages for still supported releases, and assume that we stop losing ddebs, my guesstimate would be that with 1 TB we should be okay
<pitti> infinity: but again, that's with removing old ddebs after 30 days, which I'm not sure we'd be doing on the librarian?
<infinity> pitti: No, we won't be culling nearly as aggressively to start with, though we might have to eventually.
<pitti> but removing old ddebs seems prudent to me, given how fat they are
<infinity> pitti: But I budgeted for 10TB, so we'll see.
<infinity> pitti: See, in my ideal world, we'd have ddebs matching every deb in the librarian.  But we'll find out if that's untenable later, and we can twiddle some knobs to make them expire more aggressively.
<pitti> infinity: do we have expiry knobs in LP?
<infinity> pitti: Vaguely hardcoded, but yes.
<infinity> pitti: Also, raring really has no PPC ddebs? :/
<pitti> infinity: they were "first against the wall" while we had them on macquarie
<pitti> infinity: I can enable them now, if anyone wants to use them
<StevenK> Which is probably infinity and BenC. Only.
<infinity> Well, to be fair, I tend to just rebuild things when I need to debug anyway (or, frankly, read gdb backtraces from stripped binaries half the time).
<infinity> But if ddebs were actually 100% reliably available, my workflow would likely change, on all arches. :P
<infinity> I get so used to stripped backtraces, unstripped ones sometimes seem like information overload.
<infinity> "WHOA, HOW DO YOU KNOW ALL THESE THINGS ABOUT MY SOURCE, GDB, ARE YOU SOME SORT OF WIZARD?!"
<vibhav> Arent backtraces from striped binaries only "???"?
<infinity> vibhav: Assuming they don't end in corrupted frames, stripped backtraces still give me function names, and I can still examine registers and such, it's enough.
<infinity> vibhav: And if they do end in corrupted frames, debug symbols won't help you much.
<infinity> When I was your age, we used to debug in the snow, uphill, both ways.
<erickLee> infinity:pitti:vibhav: can any of you take time out to help a beginner?
<vibhav> erickLee: Never ask to ask :)
<erickLee> vibhav:well i clearly asked and no one has responded
<vibhav> erickLee: Can you tell me the arguments to pbuilder-dist?
<erickLee> pbuilder -dist <release> create, not working for precise pangolin
<erickLee> or precise-pangolin
<erickLee> or Precise-Pangolin
<vibhav> erickLee: You typed <release>?
<erickLee> no
<StevenK> erickLee: 'precise'
<erickLee> i typed the distro without <>
<erickLee> also tried precise
<erickLee> also tried pangolin
<erickLee> also googled
<StevenK> erickLee: Pastebin the output of 'pbuilder-dist precise create' ?
<erickLee> Warning: Unknown distribution "Precise". Do you want to continue [y|N]? n
<vibhav> infinity: You used to debug at the age of 15?
<vibhav> erickLee: Its "precise", not "Precise"
<infinity> vibhav: Much younger.
<pitti> infinity: you used protection, I hope?
<pitti> like efence?
<StevenK> Bad pbuilder-dist, that's a series, not a distribution.
<infinity> Bad docs still recommending pbuilder. :/
<vibhav> infinity: :O
<erickLee> vibhav:thank you. sorry. could have sworn i tried the lower case.
<infinity> Can we somehow burn them all with fire and get people standardized on schroot/sbuild and mk-sbuild?
<vibhav> clearly, people in the older days were geniuses
<infinity> vibhav: Not a genius, I just had cruel parents.
<infinity> vibhav: They bought us a computer instead of a Nintendo and said "if you want to play video games, learn to write them first".
<vibhav> That aint cruel
<pitti> infinity: OOI, do we have some scriptery which sets up schroots with ephemeral tmpfs overlays automatically?
<vibhav> infinity: Thats excellent parenting :)
<infinity> vibhav: It is when you're 4.
<pitti> infinity: that would be the one thing that would finally cause me to move away from plain schroots
<infinity> pitti: mk-sbuild sets up ephemeral schroots by default.
<StevenK> I quite like LVM plus snapshots for sbuild, it's handy
<infinity> pitti: The overlay 'area' is just a directory, and I mount a tmpfs there.
<infinity> schroot        /var/lib/schroot/union/overlay/            tmpfs   size=75%          0       0
<infinity> schroot          12G  1.6G   11G  14% /var/lib/schroot/union/overlay
<pitti> infinity: sweet, that's just what I'm looking for
<pitti> infinity: can you get an interactive shell in these, too? (for running tests etc. manually)
<infinity> pitti: Of course.  It's just an schroot like any other.
<infinity> pitti: Just that when you leave the session, the overlay goes away.
<infinity> pitti: But you can start schroot sessions and make them long-running, and kill them later.
<pitti> infinity: I'm sold, I think
<infinity> (By default, entering and exiting starts and kills a session, though, which is also the mode that sbuild uses)
<pitti> old habits die hard, but that does sound much nicer than repeatedly installing and uninstalling packages from experimental in my sid chroot
<infinity> But you can ask sbuild not to do that, etc.
<infinity> pitti: And, on top of that, there's some fancy from Andy to keep schroots pocket-free.
<infinity> pitti: Witness the subtle difference when I enter a source chroot or an ephemeral one: http://paste.ubuntu.com/5566819/
<pitti> oh, sweet
<pitti> infinity: what does "source:" mean in that context?
<pitti> it sounds like "release-only:"
<infinity> pitti: The on-disk underlay.
<pitti> oh
<infinity> pitti: As in, the chroot you'd actually upgrade occasionally, rather than the ephemeral overlay you play in.
<pitti> i. e. that's what you log into for running dist-upgrade and initial setup
 * infinity nods.
<infinity> I find combining tmpfs-overlay schroots, sbuild, and a local apt-cacher-ng on my laptop makes sbuild pretty much the most pleasant experience ever.
<infinity> Build-deps "download" and install in a matter of seconds.
<infinity> So, repeated fresh builds don't annoy you.
<StevenK> infinity: Your local mirror is unloved?
<pitti> yeah, it's always a pleasure to see how fast stuff installs in kvms that run an overlay in tmpfs
<infinity> StevenK: My local mirror is dead right now, but that's not really relevant.  The laptop has a cache regardless, so it can travel to conferences and make me not want to stab small children with forks.
<micahg> that only works if your mirror is *.ubuntu.com and redirected to the conference mirror
<infinity> micahg: You assume I only travel places with Canonical IS in a back room...
<StevenK> Which is a UDS only thing, and isn't what infinity said.
<micahg> infinity: heh, right, well, nevermind, I use mirror.anl.gov from conferences, so ignore me
<infinity> micahg: Well, that's another bonus for apt-cacher-ng.  You can just have your sources.list always say archive.ubuntu.com and then twiddle the backend config to aim it at different mirrors if you georelocate.
<micahg> ooh, haven't tried that one yet
<infinity> I don't tend to muck with the Ubuntu configs much, but my Debian mirror du jour seems to change every few months, when I find a better one. :P
<vibhav>  /win 15
<pitti> infinity: I set up a fresh one, and it complains about "union-type" in the config file; do you have that in there as well? (/etc/schroot/chroot.d/sbuild-lucid-amd64 says union-type=overlayfs)
<infinity> pitti: Mine are set to aufs, because overlayfs bugs annoy me, but both should work.
<pitti> $ LANG= schroot -c lucid-amd64
<pitti> W: line 10 [lucid-amd64] union-type: Configuration key name âunion-typeâ is not a permitted name.
<pitti> hmm
<infinity> How... Odd.
<infinity> http://paste.ubuntu.com/5566870/ <-- schroot likes that one just fine.
<infinity> On raring here, but I'm sure precise would be happy too.
<pitti> ah, I created it as type=filel
<pitti> "file", too
<infinity> Ahh.
<pitti> that is an implied overlay, I guess :)
<pitti> I want to keep the rarely used ones compressed
<infinity> Well, not an overlay, but implied ephemeral, cause it unpacks a fresh copy every time.
<infinity> You could just have your underlays on a compressed filesystem.
<infinity> Get fancy and make it a readonly lzma squashfs or something.
<infinity> Bit of a pain to maintain and upgrade, though.
<pitti> *shrug* untar into tmpfs is fine for the four times in a year I have to build a lucid package
<infinity> Perhaps, but an uncompressed base chroot isn't exactly big.
<infinity> pitti: http://paste.ubuntu.com/5566879/ <-- 6G total isn't much, is it?
<infinity> Unless you're on a 64G SSD or something.
<pitti> indeed
<infinity> Then everything looks big.
<pitti> 128 GB here
<lifeless> you could use a qcow2 file as your base
<lifeless> mount with a throwaway overlay
<pitti> that's what I use for kvm
<erickLee> bzr branch ubuntu:kdetoys
<erickLee> Agent admitted failure to sign using the key.
<erickLee> Permission denied (publickey).
<erickLee> ConnectionReset reading response for 'BzrDir.open_2.1', retrying
<erickLee> Agent admitted failure to sign using the key.
<erickLee> Permission denied (publickey).
<erickLee> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<erickLee> help please
<StevenK> erickLee: lp:ubuntu/kdetoys
<erickLee> Stevenk: what is lp
<lifeless> StevenK: Isn't ubuntu an alias to lp:ubuntu, added by buildded?
<StevenK> lifeless: I hadn't been exposed to it, but it does look that way
<lifeless> erickLee: lp: is the actual name that bzr is using.
<lifeless> erickLee: looks like an ssh key issue with your configured username on Launchpad
<lifeless> erickLee: that, or your agent error - forgetten your passphrase perhaps ?
<erickLee> lifeless:okay i'm on launchpad. what must i change?
<lifeless> I don't know, I'm not you.
<lifeless> erickLee: you need to figure out your ssh key issue
<erickLee> lifeless: i imported it to launchpad.
<ScottK> erickLee: Also, if you're interested in kdetoys, the Kubuntu team doesn't use those branches.  https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/kdetoys
<erickLee> ScottK: i'm not exactly instrest in them i am simple trying to follow te steps in setting up.
<ScottK> OK.
<erickLee> scottK: it would e okay if things worked as they are apparently suppose to.
<erickLee> honestly i can't complain. i've gotten this far.
<erickLee> what is suppose to happen when you click on your own ssh key?
<ScottK> You're supposed to see the key.
<ScottK> https://launchpad.net/~kitterman/+sshkeys
<erickLee> Stevenk: lifeless: apparent fix was turning my computer off and then on again.
<dholbach> good morning
<darkxst> didrocks, Hi
<didrocks> hey darkxst
<darkxst> just wondering if you are able to add an endorsement for my membership application
<didrocks> darkxst: do you have the list of packages I sponsored for you? I need to have a look again :)
<darkxst> didrocks, there are a few on this list, http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=*Lunn*&sponsoree_search=name
<didrocks> darkxst: hum, I only sponsored very trivial things, I unfortunately can't give an endorsement with the few work I sponsored for you, I can add a comment if you want me to :)
<darkxst> there might have been a couple more, but I am having a hard time tracking down all packages I have done
<darkxst> didrocks, sure that is fine
<didrocks> darkxst: doing then :)
<darkxst> I will just blame jbicha for sponsoring too much of my work ;)
<didrocks> heh
<doko> main.c: In function 'main':
<doko> main.c:391:2: error: 'g_type_init' is deprecated (declared at /usr/include/glib-2.0/gobject/gtype.h:669) [-Werror=deprecated-declarations]
<doko>   g_type_init();
<doko>   ^
<doko> cc1: all warnings being treated as errors
<doko> seb128, didrocks: there are a lot of these ... how should these be fixed?
<seb128> doko, by dropping the g_type_init() call or not use Werrror
<doko> seb128, just dropping?
<seb128> doko, yes
<seb128> doko, e.g http://git.gnome.org/browse/gedit/commit/?id=a68100b607f165497bcc05ce48d11694e2f795ed
<doko> ok
<Laney> doko: You can forward patches to only call that #if !GLIB_CHECK_VERSION(2,35,0)
<doko> mehh
<Laney> upstreams might be concerned with keeping backwards compatibility
<Laney> where's that common FTBFS causes wiki page?
<Laney> oh yeah, Debian wiki passwords got compromised, didn't they?
<seb128> doko, https://mail.gnome.org/archives/commits-list/2012-December/msg04044.html for an example of version check as Laney mentioned
<seb128> if you want your code to work on both old and new glib
<Laney> yeah added it to http://wiki.debian.org/qa.debian.org/FTBFS
<seb128> Laney, thanks
<seb128> doko, btw, would be nice if you could do a merge request against lp:remote-login-service for your fix there
<seb128> doko, same for ubuntu-geoip?
<mlankhorst> hmmz
<mlankhorst> https://launchpad.net/ubuntu/+source/mesa-lts-quantal 'pending publication' what does that mean?
<doko> infinity, pdl: ...
<doko>   int pipes[2];
<doko>   if(pid==0) {
<doko>     dup2(pipes[1],1);
<doko>     dup2(pipes[2],2);
<mlankhorst> RAOF: ^
<geser> mlankhorst: it means the debs are in binary NEW (an archive admin needs to check and approve them)
<mlankhorst> oh
<mlankhorst> well that explains why bug description didn't update then
<doko> Daviey, do you have any plans for ruby? e.g. dropping 1.8?
<doko> and adding 2.0?
 * doko ducks
<seb128> doko, do you plan to file the merge requests/upstream the patches for the stuff you fix? ;-)
<Daviey> doko: I have no plans for ruby at all :)
<doko> Daviey, I did fear that ...
<doko> seb128, if you do want to have it now, please could you merge it?
<seb128> doko, I'm not upstream for those and I don't plan to touch them soon, but I would prefer to see those fix go upstream so nobody else duplicate the work you are doing
<seb128> doko, otherwise we just waste time/resources redoing the same things at different places
<wookey> I'm doing second stage of a multistrapped filesystem image and ifupdown puts a line into /var/lib/dpkg/status which is a conffile with no md5sum
<wookey> this is an illeghal entry and breaks dpkg
<wookey> what should be there is apparently:  /etc/init.d/networking ce96a6f22cc836088eef6673d853a765 obsolete
<zyga> wookey: why on earth would ifupdown want to mess with dpkg/status?
<wookey>  /etc/init.d/networking f5a562ab343f7e58dd7cb21636429332
<wookey> zyga: werll I don';t suppose it does it itself
<wookey> I mean that if that package is included then the status file ends up looking like that
<wookey> I don;t know what/who is responsible fo creating those entreis
<wookey> that was kind of my question.
<wookey> presumably dpkg is, so packages can;t screw it up
<zyga> wookey: smells like some dpkg internal or debian config file helper
<wookey> hmm. mind you . I think multistrap may mess with it. Maybe it's not getting obsoleted conffiles right...
<wookey> I'll check to see if it's bust before I even boot. I assumed it was something int eh dpkg --configure -a stage that was going wrong, but maybe not
<wookey> that file is a link to /lib/init/upstart-job
<wookey> so I guess the database is updated when a package replaces a conffile in this way?
<zyga> wookey: sounds sensible but I don't know dpkg that much
<apw> pitti, i seem to have an apport recursion issue with ccsm
<apw> pitti, obviosly apport won't file a bug on it :/
<apw> didrocks, hey ... pidgin in raring seems to have gone to hell for me, is this known
<didrocks> apw: hum, not really (I don't use it), the last upload I did was only linked to the IRC client plugin
<didrocks> maybe seb128 will know a little bit more, he's using it ^
<apw> arse
<apw> just hangs dead mostly, not a well bunny
<didrocks> apw: did you try to remove the IRC plugin? would be a first step to find if this is the guilty part
<didrocks> apw: do you have IRC configured?
<apw> didrocks, i have irc accounts in my config, but disabled
<apw> for emergency use, but not being used activly
<didrocks> ok, shouldn't be the guilty then, let's wait if seb128 knows more about it
<apw> didrocks,   /usr/lib/purple-2/libirc.so ?
<apw> is that the plugin?
<didrocks> apw: yep, you can try rename it
<didrocks> and restart pidgin
<apw> didrocks, this is more serious, it is ticklng someting which is bustin compiz or X
<apw> sigh
<apw> i knew i should have kept this machine on quantal
<didrocks> apw: I just tried again, don't have anything, let's see if the latest gtk/gnome stack my impact
<didrocks> may*
<apw> didrocks, yeah this is a fresh upgrade q->r though pidgin is broken on another R i have as well it seems
<seb128> didrocks, apw: I'm back from lunch
<seb128> apw, what's the issue exactly? pidgin works fine here
<apw> seb128, when i start it it just greys out, typically starting when i hit a second account enable
<Laney> blame the kernel
 * Laney runs
<apw> though .. i have just discovered i am having issues with flipping, so perhaps compiz is being broke by that and its just what pidgin displays
<seb128> apw, can you gdb pidgin and ctrl-C, bt when it hangs?
<apw> seb128, will do
<seb128> thanks
<seb128> I had an issue yesterday with dbus
<seb128> stuff would hang for like 15 seconds in dbus calls
<seb128> I'm wondering if you have something similar, though mine was affecting random apps, like xchat when clicking on an url, firefox, etc
<apw> bt shows it polling
<apw> seb128, but it has 5 threads, and only one stack trace
<seb128> apw, can you pastebin the bt?
<apw> http://paste.ubuntu.com/5567518/
<apw> oh now it wants to be raised all the time
<seb128> #6  0xb75a1374 in g_spawn_command_line_sync () from /lib/i386-linux-gnu/libglib-2.0.so.0
<apw> ?
<seb128> apw, can you install the dbg package for glib? would be nice to see what commands it calls which is hanging
<apw> seb128, why is it so hard to find the name of the debug packages
<seb128> apw, I tend to dpkg -S <binary> and append -dbgsym to the name it gives me
<apw> seb128, ok ... isntaling the -dbg version of that made the issue go away
<seb128> hum
<seb128> I guess time made it go away
<seb128> no reason the dbg should change anything
<apw> libglib2.0-0-dbg
<apw> was what i installed
<apw> seb128, ahh no just sometimes ione gets lucky
<apw> seb128, http://paste.ubuntu.com/5567533/
<seb128> apw, "gsettings get org.gnome.system.proxy mode" ... does that hang the same way?
<seb128> or takes time to return?
<mlankhorst> bregma: I pushed packaging for xorg-gtest 0.7.1 to the xorg-gtest git tree in debian
<apw> seb128, nope
<mlankhorst> oh looks like you put it in collab-maint :/
<seb128> apw, weird, did you try a few times?
<seb128> apw, it seems like the issue I had yesterday where dbus call where randomly hanging for a while
<seb128> that impacted several apps for me
<seb128> apw, in any case I doubt it's a pidgin issue, I'm pretty sure that if you look at the processes running when you get the issue the gsettings get command will be running and hanging a dbus call (if you gdb to it you can check)
<apw> seb128, just tried several 1000 and nothing unusual
<seb128> apw, can you get pidgin to hang, look at ps afx | grep gsettings and gdb to the gsettings get if there is one?
<apw> seb128, even seems fine when pidgin is stuck
<seb128> apw, no gsettings get process?
<seb128> apw, that stacktrace doesn't make sense then...
<apw> seb128, 18734 pts/8    Z+     0:00              \_ [gsettings] <defunct>
<apw> so there was and it is dead
<seb128> that's pretty weird
<apw> seb128, the pdigin thread which ran it has also exited, and not been reaped
<seb128> there is something weird going on at the low level
<apw> seb128, can i get gdb to give me bts on the other threaads
<seb128> not sure what though
<seb128> apw, you can "thread apply all bt"
<apw> seb128, http://paste.ubuntu.com/5567558/
<apw> (this is a new repoduce)
<seb128> apw, well, thread 1 is waiting for the command_line=0xb74cc214 "gsettings get org.gnome.system.proxy mode", to return
<seb128> can you see if that one is running/defunct/...?
<seb128> apw, do you have hangs in other commands, e.g gvfs-ls ?
<apw> seb128, it is defunct
<seb128> or gvfs-mount -li
<apw> gvfs-ls works fine
<apw> nope that works too
<seb128> apw, nothing weird in system log, syslog, dmesg, etc?
<seb128> apw, the bottom of the issue is that those gsettings call go defunct and that pidgin has a sync call waiting on the output of those commands
<seb128> I've no idea why would that happen though :-(
<apw> seb128, implies there is a bug in there, that the glib call is not noticing that the other end is gone
<seb128> but I hit a similar bug yesterday with firefox
<apw> seb128, classic fail there is to not close your copy of the other end of the pipe
<apw> so that you don't get an eof on exit
<seb128> apw, well, is "defunct" really "gone"?
<apw> yes, that means it is a zombie, the process slot only has the exit status for the parent
<apw> there is no process any more
<apw> that means someone asked for the exit to be reported and didn't wait for it yet
<apw> and the thread being in poll tends to fit witht hat
<seb128> apw, did you do an upgrade before the issue started? what did it include?
<seb128> apw, yeah, there might be a bug there in the handling of the buggy situation, still the bottom of the issue to me is that those gsettings process get defunct
<apw> seb128, that is a normal part of life for a process, if you run something it always goes defunct
<apw> seb128, then either the parent or init reads the exit value and releases it
<cjwatson> right, the problem is that it's not being reaped, not that it's defunct
<apw> the issue is that the parent is stuck in poll whne we might expect it to be reaping the exit
<cjwatson> (though I think that's probably what seb128 meant ...)
<apw> oh heh, language barriers :)
<seb128> cjwatson, right
<seb128> sorry for the confusion
<apw> now to guess which source pacakge that g_spawn_sync hides in
<cjwatson> IME tracking that down is a matter of staring at an strace until enlightenment arrives
<cjwatson> apw: glib2.0
<cjwatson> g_spawn_sync is used all over the place - it's rather unlikely to be broken itself, I think?
<seb128> right, and it didn't get any change upstream since novembre
<apw> cjwatson, well we could have changed a kernel semantic within the valid ranges and found a bug
<cjwatson> true
<seb128> apw, is that bug persistant across reboots?
<apw> seb128, yep
<apw> seb128, though in gdb i get away with it sometimes
<seb128> apw, do you use the raring kernel? can you try booting an older one?
<apw> so it must be a race
<apw> seb128, i could try that i suspect in a bit yeah
<apw> this has a nasty comment about a second child to prevent zombies ... sounds racy
<seb128> apw, when did the issue start? can you try if downgrading libglib2.0-0 to the previous version fixes it for you?
<Quintasan> dholbach: ping
<dholbach> Quintasan, pong
 * Laney 
<Laney> @pilot in
* udevbot 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: Laney
<Quintasan> dholbach: hmmm, actually mind if I query?
 * dholbach hugs Laney
<dholbach> not at all, please do
 * Laney prods xnox https://code.launchpad.net/~brightbox/ubuntu/raring/lvm2/fix-for-1075994/+merge/142531
<Laney> top item in the queue(!)
<xnox> Laney: sure, but it needs ideally thin_provisioning package & update to much newer lvm2
<xnox> (ahead of debian)
<Laney> xnox: then could you reply to the MP saying so and set it to WIP?
<xnox> ok.
<Laney> merci
<xnox> although, I could just apply, as it literally makes no difference to the archive as it is, but does help testing thin provisioning.
<Quintasan> Laney: urgh, first two weeks at my uni are a nightmare, I will look at this im-{config,switch} magic now
<Laney> awesome
<Quintasan> Laney: in short, im-switch works but im-config does not, right?
 * Quintasan downloads the Debian source instead
<Laney> right, im-config needs special work (I understand in the im-config source package itself)
<Laney> you should get maliit-{framework,plugins} from raring-proposed
<Laney> it's newer - I'll update Debian once it gets out of NEW
<Quintasan> okay
<Quintasan> Laney: well, this looks like "make patch; send upstream; wait" procedure, writing patch then
<Quintasan> Laney: One thing, shouldn't maliit-framework binary package Recommend maliit-dbus-activation as well?
<Laney> no, we don't want that by default
<Quintasan> I see
<Laney> we/upstream
<Laney> otherwise you get it all the time which is annoying
<Laney> you're supposed to select it as your input method if you want it
<Laney> or install that package
<Laney> like some types of image (tablets) might seed that package too
<Quintasan> Laney: Yeah, now that I look at it, it's a great idea
 * Quintasan woulnd't think about it until he go Mallit on all the time
<Quintasan> s/go/get
<mitya57> hi barry, I wonder if you have an opinion on http://lists.debian.org/debian-python/2013/02/msg00209.html and what should we do in Ubuntu?
<mitya57> I propose that we keep the patch this cycle but try to fix as many packages as we can (there are more in Ubuntu than in Debian)
<barry> mitya57: hi.  i have to admit, i'm uncomfortable with removing those scripts, but tumbleweed makes a persuasive argument (esp. w.r.t. the -dbg flavors).  i should follow up on that thread, but ubuntu should follow debian (i'd rather not have them behave differently)
<mitya57> and get rid of it next cycle
<barry> mitya57: how many do we have?
<tumbleweed> barry: those weren't actually all my arguments - I just summarised :)
<barry> tumbleweed: ah ;)
<barry> tumbleweed: i wish we could do #4 though ;)
<tumbleweed> I was in favour of 4, but the tide seemed against me
<tumbleweed> als, -dbg...
<tumbleweed> *also
<barry> yeah
 * barry should at least follow up on the mlist
<mitya57> so do you like my plan (above)?
<barry> mitya57: how many do we have to fix in ubuntu?
<mitya57> barry: some ubuntuone/signon/software-center stuff b-d's on python3-nose, but I haven't yet looked at that
 * mitya57 wonders why upstream hasn't yet released 1.3 (they promised it last week)
<mitya57> barry: it was actually jcristau who was against #4
<barry> mitya57: oh, then we should just do #4 then :)
<doko> seb128, Vcs-Bzr: https://code.launchpad.net/~ubuntu-desktop/remote-login-service/trunk doesn't exist
<mitya57> barry: feel free to commit that or wait until I have time for that (probably on weekend)
<tumbleweed> barry: of course, it's also the kind of thing that we were trying to get away from, in python-support
<barry> tumbleweed: they don't have to be symlinks ;)  but yeah, i get the larger point.  it bothers me less for targetted command line scripts like this, but otoh, it might be setting a bad precedent (what about other python scripts that are version dependent?)
<seb128> doko, I guess it's being transitioned to inline packaging, just submit to lp:remote-login-service
<barry> tumbleweed: maybe nose really needs a driver script that isn't version dependent but invokes a version dependent subprocess, kind of like the way virtualenv takes a -p option
<doko> seb128, well, you could fix the header and submit it too ;)
<tumbleweed> barry: that kind of thing would probably be useful
<barry> tumbleweed, mitya57 then /usr/bin/nosetest could even be a shell script
<tumbleweed> (and this applies to all the tools like this - mostely test runners, I guess)
<barry> i suppose we should engage with upstream about it
<seb128> doko, I could ;-)
<doko> barry, tumbleweed: you mean, creating the scripts in the maintainer scripts?
<barry> doko: yes
 * doko reset's barry's karma to -5000
<barry> :-D
<tumbleweed> I guess doko has strong opinions on this :)
<doko> THATS INSANE!
<barry> i'll bring the issue up on the tip list to see what suggestions they might have
<mitya57> the current patch doesn't look sane as well
 * barry is starting to like `nose -p python3.3`
<doko> well, we are trying to go away with creation of files in the maintainer scripts (besides the bytecode), so why add another one?
<mitya57> python3.3 -m nose?
<tumbleweed> doko: yes, which is why we are talking about alternatives
<barry> mitya57: hmm, i suppose so, yes
<barry> % python3.3 -m nose
<barry> /usr/bin/python3.3: No module named nose.__main__; 'nose' is a package and cannot be directly executed
<tumbleweed> we could encourage upstreams to support usage like that
<tumbleweed> (it's painful to implement in 2.6, though)
<tumbleweed> err impossible
<barry> tumbleweed: what's this "2.6" you speak of? <wink>
<tumbleweed> debian still has it
<tumbleweed> but hopefully soon :)
<barry> :)
<mitya57> nose itself still supports 2.4 :)
<barry> mitya57: why do you make me cry?
<mitya57> barry: https://github.com/nose-devs/nose/commit/e1de7970df7a03e49fe3305394bf92020d3944ef
<doko> jodh, the upstart build hangs on sagari/powerpc. I'm asking to kill it
<barry> sigh
<tumbleweed> people use redhat...
<tumbleweed> still, nothing wrong with trying to get this supported for the pythons that support it
<vibhav> Does glibc in arm have gets() undeclared?
<timrc> hallyn, would lxc-ssh -n <name_of_container> be a completely dumb feature?  I find myself start'ing lxc containers and hating the console and I'm not aware of a way of easily getting the IP of the container without logging into the console, first
<timrc> in via the console, rather
<hallyn> timrc: i thought we had somethinglike that, actually,
<hallyn> timrc: what i use is a ~/.ssh/config section to do 'ssh container@lxc'
<hallyn> stgraber: didn't we have 'lxc-ip' at one point?
<timrc> hallyn, ah, yeah I don't see lxc-ssh or lxc-ip with lxc  0.9.0~alpha3-0ubuntu2 (in Raring)
<stgraber> hallyn: very briefly
<Laney> hyperair: are you aware jockey is universe?
<hallyn> timrc: http://paste.ubuntu.com/5567956/
<Laney> re: bug #1130684
<ubottu> bug 1130684 in jockey (Ubuntu) "jockey-common needs to be multiarched" [Undecided,Confirmed] https://launchpad.net/bugs/1130684
<hallyn> timrc: gotta run, server mtg - ttyl
<stgraber> timrc: https://www.stgraber.org/2012/07/17/easily-ssh-to-your-containers-and-vms-on-ubuntu-12-04-lts/
<stgraber> timrc: doesn't work terribly well on 13.04 at the moment because of some dnsmasq weirdness (randomly fails to resolve here)
<timrc> stgraber, cool, this will be useful :)
<barry> tumbleweed, mitya57, doko https://github.com/nose-devs/nose/issues/634
<cjwatson> vibhav: I expect you've run into a gnulib bug for which there's a fairly standard patch you can backport - look at any of m4, cpio, diffutils, parted (off the top of my head)
<mitya57> barry: subscribed, thanks
<tumbleweed> that sounds like it'd be a trivial patch, maybe in an hour or two...
<vibhav> cjwatson: apparently, guile ftbfses on arm with this message
<vibhav> stdio.h: gets() undeclared
<cjwatson> vibhav: bet it'd fail on i386 if rebuilt nowadays
<cjwatson> vibhav: sounds like the same thing fixed in those other packages I mentioned
<vibhav> cjwatson: Wait, so the bug is not platform specific?
<infinity> vibhav: Nope.
<infinity> vibhav: gets() jas been deprecated for a decade, and was removed entirely in C11.
<vibhav> Ah, I forgot the standard
<infinity> vibhav: The irony here being that gnulib tries to check for the use of gets() to warn you not to use it. :P
<infinity> vibhav: But fails if it's not defined at all (oops).
<vibhav> Yeah, there is some code which warns you for using gets
<vibhav> Not secure, or something
<vibhav> cjwatson, infinity: Thanks. I will have a look ASAP then.
<infinity> vibhav: Upstream has probably already fixed it.
<infinity> vibhav: So, I'd start by looking there.
<vibhav> infinity: just a question. Shouldn't gnulib fix the bug rather than the apps using it?
<cjwatson> gnulib has fixed the bug
<cjwatson> But the model for using gnulib involves copying files into other package sources, because the point of gnulib is to supply compatibility for systems lacking things
<infinity> vibhav: gnulib tends to be embedded (and in a variety of ways) in other people's source, it's not a standalone build-dependency.
<vibhav> Ah, I see
<didrocks> hey barry! seems bug #1105215 is due to python3 piston, right?
<ubottu> bug 1105215 in oneconf (Ubuntu) "oneconf-service crashed with AttributeError in request_url(): 'gaierror' object has no attribute 'message'" [Medium,Confirmed] https://launchpad.net/bugs/1105215
<mitya57> didrocks: s/message/strerror/g should work
<didrocks> mitya57: thanks for the pointer!
<mitya57> and btw socket.gaierror is subclass of socket.error so no need to catch both
<didrocks> mitya57: it seems you are way more knowledge than I am here (especially in piston that I don't know at all), do you have time/mind prepping a patch for it? dobey maybe can review as well as piston-mini-client is part of what software-center used/produced, maybe?
<Riddell> ogra_: don't forget your promise to make kubuntu nexus images last week :)
<ogra_> Riddell, oh, ah ... whats the flavour name ? kubuntu-active ?
<mitya57> didrocks: ok, will propose merge now ;)
<didrocks> mitya57: thanks a million :-)
<Riddell> ogra_: yep
<ogra_> ok
<ogra_> fiddling with it now
<ogra_> Riddell, running a manual build with what i think is the right command, lets see what comes out, if it works i'll add it to the crontab
<Riddell> ogra_: groovy
<dobey> pitti: can you accept tomboy into precise-proposed? looks like it got uploaded, and accepted everywhere but on precise. thanks
<didrocks> dobey: do you want to look at the piston branch?
<barry> @pilot in
* udevbot 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: barry, Laney
<GridCube> hi, if someone wanted to help translating the ubuntu documentation to spanish, who would he have to contact?
<didrocks> barry: I have a branch for you to sponsor I guess (see my above ping ;)): https://code.launchpad.net/~mitya57/piston-mini-client/lp1105215/+merge/150619
<didrocks> thanks mitya57 :)
<barry> didrocks: i'll take a look after lunch
<didrocks> thanks barry :)
<Laney> @pilot out
* udevbot 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: barry
<mitya57> GridCube: if you mean https://help.ubuntu.com/12.10/ubuntu-help/index.html, then it looks fully translated
<GridCube> where?
<mitya57> https://translations.launchpad.net/ubuntu/raring/+source/ubuntu-docs/
<GridCube> :) good
<GridCube> in any case, they want to help contributing with documentation, if its not translations then something else could be done
<mitya57> GridCube: they can ask on #ubuntu-doc probably
<GridCube> C: i recommended them that too
<psusi> smoser: ping
<smoser> psusi, here.
<psusi> smoser: I saw you merged the kpartx -u patch... I got the parted version backported if you were interested in that
<psusi> err, partx... I keep wanting to add that darn k ;)
<smoser> psusi, i'm ok to look at that and sponsor that if you want
<smoser> but i dont have a real need for it.
<psusi> smoser: ok... just wasnt sure if it should go in this cycle or wait... but if you're up for it I'll propose merge and request yuo on it?
<smoser> sure.
<smoser> its upstream, right?
<smoser> and doens't have any fallout (ie, all new feature?)
<psusi> smoser: all new feature, patches been posted on the upstream ml for a while now but the old maintainer is kind of stepping down and hasn't had time to review and apply it
<psusi> or anything else for that matter
<psusi> smoser: do you think it should wait for that?
<smoser> psusi, well, if we dont have anything that would use it, then there isn't a lot of pressing need for it.
<smoser> thats just my opinion, though.
<psusi> well, I'm using it right now ;)
<smoser> i'm definitely grateful for your work there, and hope not to sound ungrateful.
<psusi> to split my raid5 array and use half the space for a raid0 to test if the problem I'm seeing is specific to raid5
<psusi> no worries there, just figured now is the time to do it before the freeze if it is going to make it into raring
<psusi> I also have worked up a patch to gparted so it can take advantage of it as well
<zyga> hi, I'm looking for a way to file bugs on ubuntu vagrant images
<zyga> does anyone know where they are hosted (on launchpad) as a project
<cjohnston> zyga: talk to utlemming
<zyga> cjohnston: thanks
<zyga> utlemming: ping
<cjohnston> np
<zyga> utlemming: I'm using vagrant more and more and one thing starts to bug me, our images have linux-source installed (a whooping 85MB), is that really needed or just an artifact from development stage?
<utlemming> zyga: required due to Virtualbox
<utlemming> zyga: virtual box won't build the dkms without it
<zyga> utlemming: oh? I thought vms only need -headers?
<zyga> utlemming: I mean, I have a number of VMs and I'm almost sure they don't have linux-source at all
<zyga> (and they all use fs sharing features and other vbox things)
<utlemming> zyga: there was a reason for it...and I believe it precise only
<zyga> utlemming: ah, might be
<zyga> utlemming: is it only on precise, I also have quantal images (though that may be lost in the logs)
<utlemming> zyga: precise is bigger...
<zyga> utlemming: one more question, is raring working yet? I had to stop using it because vboxfs was not supported at the time
<utlemming> zyga: virtualbox is pretty foobar'd at the moment. amd64 might work, but 32-bit won't
<zyga> (using raring images)
<zyga> utlemming: is that upstream fault or something we can do?
<utlemming> zyga: loog at Bug #1101867
<ubottu> bug 1101867 in virtualbox (Ubuntu) "virtualbox-guest-dkms 4.1.22-dfsg-0ubuntu2: virtualbox-guest kernel module failed to build [VBoxGuest-linux.c:206:49: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âg_VBoxGuestPciIdâ]" [High,Confirmed] https://launchpad.net/bugs/1101867
<zyga> utlemming: it seems there's an upstream patch for that already
<zyga> utlemming: any chance raring could get 4.2 with all the patches?
<utlemming> zyga: well, I do cloud images...and I'm not a motu. I think that getting a motu to look at importing it would be a first step
<zyga> utlemming: I see, perhaps that issue could be escalated if we spend time on getting our vagrant images to work we really need to spend the same time on vagrant and dependencies (so virtualbox) in the same manner for the first expense to be meaningful outside of ubuntu
<infinity> Getting 4.2 in Debian would be the path of least resistance.
<zyga> utlemming: thanks a lot for the info though
<utlemming> zyga: the virtualbox dependency is the _exact_ reason why the images are not officially supported.
<zyga> utlemming: I see
<utlemming> zyga: you said there were other annoyances...what are they?
<zyga> :-)
<zyga> utlemming: ah, apart from lack of 4.2 in the archive, vagrant 1.0.6, raring vboxfs and linux-source, vagrant is really a joy to use
<utlemming> zyga: looks like I'll have a build that doesn't include linux-source
<utlemming> zyga: 12.04 should exit building in ~20 minutes
<zyga> utlemming: I'll gladly test that
<utlemming> zyga: go ahead and try 12.04
<zyga> utlemming: ping me when you know those images are ready please
<utlemming> zyga: 12.04 is ready
<zyga> utlemming: ok
<barry> @pilot out
* udevbot 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:
<TheMuso> @pilot in
* udevbot 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: TheMuso
#ubuntu-devel 2013-02-27
<wigs> bug #831768
<wigs> three months and still no comment from ~ubuntu-sru
<ubottu> bug 831768 in aptitude (Ubuntu Precise) "aptitude cannot handle conflicts with multiarch enabled" [High,Confirmed] https://launchpad.net/bugs/831768
<wigs> no contact details for that team?
<cjwatson> I've commented.
<cjwatson> xnox: FWIW I don't generally think the workflow of "wait for SRU team to comment on the bug" is a good one; keeping up with bug mail on ~ubuntu-sru's subscriptions is a horrific firehose and it's better just to have one queue
<RAOF> Likewise
<wigs> cjwatson: yes, though not pertaining to the sru issue
<wigs> it was mterry who decided that workflow, xnox was only attempting to facilitate it
<cjwatson> Either way
<cjwatson> And mterry's not here :)
<xnox> cjwatson: RAOF: ok. I guess I should have pinged people about that bug. To me it's a risky yet useful feature cherry-pick, and I don't want to maintain / fix subsequent bugs in aptitude's multiarch support in precise.
<wigs> feature?
<wigs> its a bug fix
<cjwatson> We could argue about feature vs. bug-fix all day; better to look at the impact
<xnox> (I don't want, as in I don't think we should)
<wigs> no regressions reported and at least several people are using the patch as supplied on precise
<wigs> impact of bug: aptitude more-or-less unusable on precise
<cjwatson> The precise patch there is definitely worth a try in -proposed; we can worry about future bugs in the future
<cjwatson> And evaluate them based on their impact, not based on some kind of notion of precedent
<xnox> ok.
<wigs> cjwatson: will you make a similar comment on the report, and I can then take it back to -sponsors?
<wigs> oh, n/m :-)
<cjwatson> Yeah, as I say, I did that first
<wigs> thanks now
<cjwatson> tjaalton: commented on bug 1093974 for you
<ubottu> bug 1093974 in libapache2-mod-nss (Ubuntu Precise) "Request header field is missing ':' separator." [Undecided,In progress] https://launchpad.net/bugs/1093974
<TheMuso> @pilot out
* udevbot 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:
<doko> Riddell, qtwebkit-source failed again, maybe add DEFINES+=ENABLE_ASSEMBLER=0 too?
<pitti> Good morning
<pitti> dobey: tomboy> I left ~ubuntu-sru some 8 months ago, so I can't accept it
<doko> jbicha, will you finish the cogl transition?
<dholbach> good morning
<pitti> wookey: wow, congrats to that great arm64 milestone!
<doko> didrocks, pitti (and seb128), I'm tired about https://launchpadlibrarian.net/132463304/buildlog_ubuntu-raring-amd64.network-manager-iodine_0.0.3-1ubuntu1_FAILEDTOBUILD.txt.gz
<doko> please can we disable that warning?
<didrocks> doko: we shouldn't use -Werror in the projects rather
<didrocks> doko: and do the transition upstream
<didrocks> or fix every projects, one by one
<doko> didrocks, then please do
<didrocks> doko: ? rather please report the failure and we'll task the team to fix those
<pitti> yeah, -DG_DISABLE_DEPRECATED + -Werror is literally crying for "please break me"
<pitti> that's just wrong
<tjaalton> cjwatson: ah, thanks. I'll update it for quantal
<tjaalton> cjwatson: also, you've merged gnutls26 last, mind if I merge 2.12.23-1 from experimental? the unstable version (.20-4) merges bunch of stuff from the new upstream, thought it would make sense to just merge from exp
<tkamppeter> pitti, glatzor, hi
<pitti> hello tkamppeter
<tkamppeter> pitti, I have a problem with aptdaemons fake PackageKit which prevents unsigned PPD-only packages from being installed.
<tkamppeter> pitti, see my Python interactive sessions on http://pastebin.ubuntu.com/5568436/
<tuxinator> hi all
<tuxinator> on 12.04 is there a convienent way of displaying current boot order of processes? i have a issue when i use multipathing+iscsi i get the message on boot that my partition on multipathd cannot be mounted, if i skip and the system boots i can however mount it, also if i want to reboot the system it does never proceed as it seems to wait for something (i think the same order issue perhaps not...
<tuxinator> ...umounting)
<pitti> tkamppeter: the last error seems quite clear (package already installed)
<pitti> tkamppeter: for the others, do you have the matching GPG key installed in apt?
<pitti> tkamppeter: can you try installing an Ubuntu package with the same API,?
<darkxst> seb128, chrisccoulson, what would need to be done to land the forthcoming spidermonkey update in raring?
<seb128> darkxst, what is it useful/needed for?
<darkxst> at this stage mainly gnome-shell
<darkxst> it fixes many memory leaks and GC deadlocks
<darkxst> unfortunately most of the other rdepends (apart from probably cinnamon) will still require the old version
<seb128> darkxst, good that we are not going for GNOME 3.8 this cycle I guess ;-)
<darkxst> seb128, oh but I want to land this with gnome-shell 3.6 ;)
<seb128> darkxst, anyway, let's way for chrisccoulson to reply, not sure if he has time for that atm
<chrisccoulson> i don't ;)
<seb128> darkxst, you would probably take over maintaining spidermonkey if you have interest in it...
<darkxst> seb128, I guess that would be ok, I basically did all the upstream work to make this release happen
<seb128> chrisccoulson, ^
<darkxst> and ricotz has initial packages on his ppa btw
<seb128> I'm not surprised, ricotz has all the broken crack of the day stuff in his ppa :p
<darkxst> anyway RC will be out shortly (i.e. within the next day)
<darkxst> seb128, maybe, but in this case (and I have been running it for several months) the new spidermonkey engine is solid and stable
<darkxst> basically I would like to get spidermoneky update and gjs 1.36 landed before freeze if possible
<seb128> darkxst, yeah, well I've to say I don't really know about the topic and it's not a priority at the moment for us
<seb128> if you are wanting to do the work and that it's fully compatible and breaks nothing why not
<seb128> there is no api/abi change right?
<darkxst> huge api/abi change in spidermonkey (hence why we would need to keep the old version)
<seb128> darkxst, so you suggest adding another version rather than upgrading the one we have?
<darkxst> seb128, yes
<seb128> darkxst, how much work would it take to port everything we have and drop the old one?
<seb128> I don't think we want yet another version
<seb128> we should either go for the new one and deal with the transition
<seb128> or wait next cycle
<darkxst> seb128, oh lots of work
<darkxst> but the main killer is CouchDB, they are using illegal javascript in their user scripts
<seb128> seems like a good topic for ubuntu-devel@ list
<darkxst> seb128, the porting itself is relatively straightforward, but results in quite large diffs, so not something would want to carry as distro patches probably
<darkxst> its all a catch22 I guess, no (other) upstream is going port to a spidermonkey that doesnt exist in distros
<tkamppeter> pitti, all these packages install correctly with "sudo apt-get install ...", the unsigned ones need confirmation.
<pitti> tkamppeter: I guess it needs confirmation because it cannot be authenticated?
<tkamppeter> pitti, the epson package is signed and this I can install, the error occures only for unsigned PPDF-only packages.
<pitti> tkamppeter: that's what's breaking it; please try installing an Ubuntu package, that should work
<pitti> tkamppeter: ah, I see; I don't know whether aptdaemo allows you to install unsigned packages somehow, that's a question for glatzor (he's not online ATM)
<tkamppeter> pitti, formerly I could install the unsigned packages with this method without problem, is there a way to get this working again?
<darkxst> seb128, chrisccoulson, would it be so bad to have a second version of spidermonkey in universe?
<darkxst> given the massive improvements to gnome-shell?
<seb128> darkxst, better to ask ubuntu-devel@ to collect opinions on the topic, that source is security sensitive and the less copies we have the better
<tkamppeter> pitti, all signed packaghes (which are currently not already installed) install perfectly with my Python commands, independent whether they are from Ubuntu (tried "foo2zjs") or from third party (here Epson).
<darkxst> seb128, ok will do
<seb128> thanks
<doko> staring at the libgc ftbfs ...
<tkamppeter> pitti, problem is actually that the Python calls do not install unsigned packages any more. Perhaps one needs some special parameters to tell that unsigned packages are OK.
<pitti> tkamppeter: yes, that's what I meant "this is a question for glatzor"
<tkamppeter> pitti, I have reported bug 1134320 now, thank you for your help.
<ubottu> bug 1134320 in aptdaemon (Ubuntu) "Need to install unsigned packages with aptdamon's PackageKit emulation" [Critical,New] https://launchpad.net/bugs/1134320
<tkamppeter> mdeslaur, I need some help to create a signature key for OpenPrinting.
<mdeslaur> tkamppeter: hi!
<mdeslaur> tkamppeter: aren't the binary packages on openprinting signed?
<tkamppeter> mdeslaur, on OpenPrinting there are no signed packages at all, the binary packages for the Epson printers are on Epson's servers.
<tkamppeter> mdeslaur, for development I have created a signature: gpg --recv-keys DCACEA71CDC01CD4995C34687A4B44C2D2A2203E
<mdeslaur> tkamppeter: are the PPD packages in an apt repository, or are they just downloaded directly from the server?
<tkamppeter> mdeslaur, I have created it some time ago.
<tkamppeter> mdeslaur, they are in an apt repo.
<mdeslaur> where is it located?
<mdeslaur> (what's the url?)
<tuxinator> multipath-tools and iscsi seem to stop before umount of my iscsi partition, is this a known bug of 12.04?
<tuxinator> lets explain like that, when multipath runs and open-iscsi i can reboot my server and shutdown
<tuxinator> if i do mount the partition additionaly to multipath daemon and open-iscsi daemons running i can't reboot and halt
<tkamppeter> mdeslaur, https://www.openprinting.org/download/printdriver/keys/fingerprint-test
<tkamppeter> mdeslaur, repo is http://www.openprinting.org/download/printdriver/debian/
<tkamppeter> mdeslaur, in http://www.openprinting.org/download/printdriver/debian/dists/lsb3.2/ contains a Release.gpg
<mdeslaur> tkamppeter: right, but it's older than the Release file, so presumably it hasn't been signed in a long time
<mdeslaur> every time you regenerate the Release file, you need to create the Release.gpg that goes with it
<cjwatson> tjaalton: gnutls26> go ahead
<mdeslaur> tkamppeter: with something like "gpg -abs -o Release.gpg Release"
<seb128> slangasek, hey, we were discussing systemd-helpers on #ubuntu-desktop, there are some issues
<seb128> slangasek, desrt said he copied that to you
<seb128> slangasek, just as a fyi, we are going to look at doing the needed change so it's not work for you, I just wanted to check you are not working on it already
<desrt> slangasek: also give you a chance to tell me that my approach is insane :)
 * desrt can never sense these things for himself before his first cup of coffee
<matttbe> Hello Ubuntu devs!
<matttbe> With a fresh install of Ubuntu 12.04.2 (64bits), if we try to install ia32-libs, it will replace a lot of mesa and x11 packages (which ends with '-lts-quantal' ; full list here: http://paste.ubuntu.com/5570521/) by a previous version (without: -lts-quantal).
<matttbe> The big problem is that some drivers are no longer available, e.g. xserver-xorg-input-synaptics (yes... which means no touchpad on a netbook).
<matttbe> According to the 'debian/control' file of ia32-libs, ia32-libs-multiarch depends of 'libglapi-mesa' and 'libglu1-mesa'.
<matttbe> 'libglapi-mesa' is a virtual package provided by 'libglapi-mesa-lts-quantal' and 'libglu1-mesa' depends of 'libgl1-mesa-glx' or 'libgl1' which are also virtual packages provided by 'libgl1-mesa-glx-lts-quantal'.
<matttbe> But why all '*-lts-quantal' are uninstalled?
<matttbe> in fact, I don't know where can I report this bug
<matttbe> is it due to  ia32-livs? mesa? x11 packages?
<matttbe> *libs
<doko> ScottK, any update on qscintilla2? anything to help with?
<ScottK> Should have it done in the next day or two.
<cjwatson> matttbe: Probably bug 1130419.
<ubottu> bug 1130419 in apt (Ubuntu Precise) "apt resolver doesn't do sensible things when satisfying a cross-dependency on a virtual package (steam, wine)" [Critical,Triaged] https://launchpad.net/bugs/1130419
<matttbe> cjwatson, yes it seems it's this bug!
<matttbe> thank you, I didn't know that it was a bug in apt
<dholbach> slangasek, would you be interested in uploading https://bugs.launchpad.net/ubuntu/+source/sqsh/+bug/1134233 to Debian? :)
<ubottu> Launchpad bug 1134233 in sqsh (Ubuntu) "sqsh FTBFS in Raring" [Undecided,New]
<tkamppeter> mdeslaur, I have found the problem, on the server the Release.gpg was not up to date. I have updated it and now I am able to use signed packages.
<cjwatson> bdmurray: BPPH.changeOverride(new_phased_update_percentage=) will work as of the next LP deployment
<mdeslaur> tkamppeter: great!
<mdeslaur> tkamppeter: remember, you need to regenerate it every single time you update Releases
<mdeslaur> s/Releases/Release/
<slangasek> seb128, desrt: hey, so I guess my only concern with implementing org.freedesktop.systemd would be if other things besides timedated use it and it turns out down the line to cause bugs due to incompatible semantics or incompatible namespacing of service names
<slangasek> dholbach: hmm, bug not reproducible in Debian unstable; checking to see what's going on here
<dholbach> slangasek, gracias!
<hallyn> stgraber: so the report on lxc-users about 12.04.1 kernel not decrementing inotify watch counts - does that explain the problem someone was reporting here last week?
<stgraber> hallyn: definitely looks like the same thing, though IIRC in jibel/pitti's case it was on 12.10 (3.5 kernel, not 3.2)
<hallyn> stgraber: who knows when it actually got fixed...
<stgraber> hallyn: if it ever did
<hallyn> stgraber: it did, bc my raring box is not affected
<stgraber> hallyn: neither was my quantal box when I tried with the python script, so I'm wondering if it's not our testcase that's broken :)
<hallyn> well that coudl be :)  or they were running a slightly older quantal kernel.  i never saw a kernel version from them
<hallyn> but the guy on lxc-devel says a newer kernel did fix it for him
<slangasek> doko: is bug #1134233 a deliberate behavior change in gcc / binutils?
<ubottu> bug 1134233 in sqsh (Ubuntu) "sqsh FTBFS in Raring" [Undecided,New] https://launchpad.net/bugs/1134233
<stgraber> hallyn: doing a quick test run on 12.04
<cjwatson> slangasek: Pretty sure that's http://wiki.debian.org/ToolChain/DSOLinking#Not_resolving_symbols_in_indirect_dependent_shared_libraries, isn't it?
<slangasek> cjwatson: I would think so, but the package doesn't fail to build in sid, only in raring
<doko> slangasek, yes, I think so. looks plausible
<stgraber> hallyn: can't reproduce on 3.2.0-38
<stgraber> hallyn: -37 and -38 contain some inotify/fsnotify fixes though
<stgraber> jibel, pitti: can you confirm that your server is running the latest kernel from quantal?
<jibel> stgraber, it's running 3.5.0-25-generic #38-Ubuntu
<hallyn> stgraber: interesting
<jibel> stgraber, wait, it was running 3.5.0.23.29 when the bug occurred
<jibel> but I bumped max_user_instances to 4096 so it may take a while before it happens again
<stgraber> jibel: .24 included a bunch of notify fixes, including changes in the way the locking is done and the release of the watches
<stgraber> jibel: any chance you can restore the sysctls to their initial values and see if the bug occurs again?
<pitti> stgraber: thanks for the heads-up! so if it stops overflowing now, the new kernel worked
<pitti> stgraber: so we have something to watch out for
<jibel> stgraber, sure but not right now
<stgraber> jibel: sure, no hurry, would just be nice to confirm so we can tell anyone else reporting a similar issue to just update to the latest kernel and reboot
<jibel> stgraber, do you think it's enough to restart the container after setting sysctl to its initial value?
<stgraber> jibel: yep
<jibel> stgraber, done. we'll see how it goes.
<arges> Hello. I was wondering if a patch pilot can look at bug 982961 and see why the precise task was marked 'Fix Committed', but it was never committed to the bzr branch. Thanks
<ubottu> bug 982961 in iptables (Ubuntu Precise) ""RATEEST" and "statistic" modules are broken " [Medium,Fix committed] https://launchpad.net/bugs/982961
<stgraber> jibel: cool, thanks
<bdrung> tumbleweed: anything needs to be done before i upload ubuntu-dev-tools 0.146 to experimental?
<tumbleweed> bdrung: looking
<doko> afk, firefox buildd time anyway
<arges> bryce: hi. I noticed you uploaded https://launchpad.net/ubuntu/+source/iptables/1.4.12-2ubuntu2.1 for me in quantal. I was wondering what happened to the same bug/patch for precise. thanks
<|Anthony|> I've been watching Session Management & Multiseat blueprints
<|Anthony|> https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-session-management
<|Anthony|> and have noticed that it seems to be going in the direction of systemd
<|Anthony|> is there anyone here that is familiar with this blueprint or topic?
<slangasek> yes
<|Anthony|> i'm concerned with the use of systemd for multiseat
<Sarvatt> arges: bryce isn't around today but it's unapproved still - https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text= , as for why I don't know
<|Anthony|> using systemd will exclude nvidia users to some extent
<arges> Sarvatt: ok thanks. Yea i'm trying to figure it out too. : )
<slangasek> |Anthony|: I don't follow why that would be the case
<slangasek> |Anthony|: but in any event, we have no plans to invest in any other solution for multiseat
<xnox> |Anthony|: also that blueprint talks about using only logind daemon from the systemd package.
<xnox> not all of systemd.
<|Anthony|> slangasek, the systemd multiseat solution is incompatible with nvidia binary
<slangasek> we can either use systemd-logind to have a multiseat solution for some hardware, or we can not have any real multiseat solution at all (the current situation)
<|Anthony|> there is a branch of console kit and gdm that is designed for multiseat
<xnox> seems like it was fixed in fedora:
<xnox> https://bugzilla.redhat.com/show_bug.cgi?id=878605
<ubottu> bugzilla.redhat.com bug 878605 in systemd "systemd-logind: No way to setup multi-seat with two nvidia cards using proprietary drivers" [Medium,Closed: rawhide]
<|Anthony|> oh?
 * |Anthony| opens link
<slangasek> well, we don't use gdm and consolekit is dead upstream
<|Anthony|> it' been a little while since i updated https://help.ubuntu.com/community/MultiseatX
<|Anthony|> thanks for the link xnox
<|Anthony|> last i chatted with lenart poettering he said that the nvidia binary didn't expose something required for compatibility... i argued that it should be as simple as a proper udev rule. he assured me i was wrong. lol
<|Anthony|> i suppose i gave up in frustration too easily
<xnox> i'd be surprise if this was not going to be resolved, it's hard to ignore half of graphics cards in the world.
<|Anthony|> right?
<xnox> and not surprisingly neither can nvidia ignore a good chunk of the linux market.
<|Anthony|> and the open source driver options for nvidia are still not ready (last i checked)
<|Anthony|> well this is good news then :) should users expect a seat management UI?
<slangasek> we don't have plans for creating one
<|Anthony|> pulseaudio, another poettering creation, is quite a chore to configure in multiseat and entirely unstable between reboots.
<|Anthony|> but that is largely due to consolekit not being seat aware
<|Anthony|> acls and such
<vibhav> Does one need a .pbuilderrc for using pbuilder-dist?
<tumbleweed> no
<vibhav> tumbleweed: A friend says  that pbuilder-dist whines that .pbuilderrc ain't there
<vibhav> Probably  a warning
<vibhav> tumbleweed: Am I missing something here ^?
<tumbleweed> vibhav: yes, concrente information from the friend, such as command + output
<vibhav> tumbleweed: never mind, he didn't describe the problem well. Fixed
<vibhav> Turns out he was building something and thought it something he not done with pbuilder-dist create
<vibhav> Thanks tumbleweed
<tumbleweed> np
<tumbleweed> Laney: any news on bug 1088423?
<ubottu> bug 1088423 in ubuntu-dev-tools (Ubuntu) "[backportpackage] Make it look a bit less like the backporter is responsible for the upload" [Low,New] https://launchpad.net/bugs/1088423
<tumbleweed> bdrung: can't see any any reason not to
<bdrung> tumbleweed: uploaded
<zul> mterry:  ping we should be good for rtslib now
<mterry> zul, ok, let me relook
<mterry> zul, why the version fb27 suffix?  We're sure they won't release a 2.1.x?
<zul> mterry:  its the upstream naming version
<Laney> tumbleweed: nein
<Laney> micahg: ScottK: ^^^
<ScottK> ?
<zul> mterry:  https://github.com/agrover/rtslib-fb/tags
<tumbleweed> ScottK: bug 1088423
<ubottu> bug 1088423 in ubuntu-dev-tools (Ubuntu) "[backportpackage] Make it look a bit less like the backporter is responsible for the upload" [Low,New] https://launchpad.net/bugs/1088423
 * ScottK looks
<Laney> s/should/shouldn't/ in the description, evidently
<mterry> zul, ah OK.  I hadn't seen those
<Laney> I wonder if we can open backport uploading up to general sponsorship now that we're able to review that stuff in queue
<ScottK> Laney: Commented.
<Laney> ty
<ScottK> Not sure if that would really improve things.
<ScottK> You'd see a stack of uploads in queue instead of a stack of bugs waiting for upload.
<ScottK> Additionally, most sponsors (probably) don't know what to look for.
<Laney> I suppose you'd have to do the same checking anyway
<Laney> I just know I'm crappy at actually processing the bugs
<seb128> is there any buildd admin around?
<seb128> can we kick the score of https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/4332170 slightly raised? ;-)
<stgraber> seb128: done
<seb128> stgraber, thanks!
<smoser> psusi, is there some beter way to decide "is 'update' supported" than "is kernel > 3.8.0" ?
<psusi> smoser: runtime, or compile time check?
<smoser> runtime
<psusi> not that I know of, why?
<smoser> i'm looking at making growpart just do the right thing if it can
<psusi> you can always try the ioctl and if it isn't supported, it just fails
<psusi> good idea
<psusi> I'd say don't worry about it then... issue the ioctl, if it works, great, if not... you're no worse off than you are now
<micahg> Laney: ScottK: re sponsoring backports, AIUI the idea was that uploaders are responsible for backports moreso than regular archive uploads
<micahg> I think part of the thinking was that a limited number of people could upload these, so some ownership was required, I guess I'd be fine with sponsored uploads (assuming backportpackage grows support for it), but I think there should still be the same sense of ownership in that failures require push back on the person being sponsored to fix (as should happen in regular archive uploads)
<dupondje> damn build queue :(
#ubuntu-devel 2013-02-28
<vibhav> cjwatson: I had a look at the gnulibc bug you were talking about. Is it true that the program assumes that gets is detected?
<vibhav> s/program/source/
<darkxst> cjwatson, hey, can you approve my spidermonkey post on ubuntu-devel?
<cheshair> Hi! (hope that's not ot) I can't find how to change my ubuntu single sign-on username. Here https://login.ubuntu.com/ I can only change full name, email or pwd.
<cheshair> Any tips?
<cheshair> I found this post which sounds similar to my scenario: http://askubuntu.com/questions/162435/changing-user-name-on-https-myapps-developer-ubuntu-com-dev
<cheshair> Ah! I found the way! It's reported here: https://answers.launchpad.net/launchpad/+faq/53 (quite tricky to find indeed)
<sarnold> cheshair: nice :) I just got there..
<cheshair> sarnold: thanks for your interest! i appreciate, did you find it quick?
<sarnold> cheshair: no, you found it first, it would have taken me several more minutes at the least
<sarnold> (i started getting there via /topic #launchpad and seeing the answers url...)
<cheshair> sarnold: oh i see, thanks again! :-)
<cjwatson> vibhav: gnulib, not gnulibc - and no, not really, the bug was that gnulib was trying to install a wrapper for gets that warned when you tried to use it, but it was doing so using typeof to detect the original libc type of gets and this broke when gets was absent from libc
<cjwatson> vibhav: this is fairly complex and you aren't necessarily expected to understand it, which is why I just pointed to a few packages that I knew had been temporarily distro-patched to fix the problem :)
<cjwatson> (as in, typeof is moderately obscure to start with and understanding gnulib requires a fairly clear understanding of autoconf and libc)
<cjwatson> darkxst: done
<vibhav> cjwatson: Ah, I get it now. Well learning something new never does any harm :)
<doko> query cjwatson
<doko> cjwatson, heh, still awake, or already?
<vibhav> doko: btw, I had a look at kasumi. Would it be better to file a MIR or lower the recommends?
<vibhav> (It should be noted that kasumi is simple dictionary utility for anthy)
<cjwatson> doko: already :-/
<vibhav> cjwatson: Actually, I know what typeof does :D
<cjwatson> vibhav: I stand corrected, sorry :)
<vibhav> :)
<vibhav> doko: Could you have a look at https://code.launchpad.net/~vibhavp/ubuntu/raring/anthy/fix-component-mismatch/+merge/150961 ?
<pitti> Good morning
<cjwatson> bdmurray,ev: phased update support is now live in LP; you can see the column for it in https://launchpad.net/ubuntu/raring/i386/man-db
<cjwatson> (e.g.)
<cjwatson> I suggest memorising how to get to those binary package publishing history pages, as it's hard to find them by navigation alone
<dholbach> good morning
<tomreyn> hi
<tomreyn> the canonical-partner repository is pretty slow. where's the proper place to report this?
<ev> cjwatson: awesome, thanks!
<Laney> tomreyn: #canonical-sysadmin i suppose
<tomreyn> thanks Laney
<Laney> tomreyn: I believe there were flash and/or java updates though, so it's likely to be due to higher than average traffic
<tomreyn> is java in there, too?
<tomreyn> there surely were flash updates, which is why i noticed
<tomreyn> but that's like 5 or 6 MB
<Laney> sorry, not java
<Laney> but 5/6 * <lots of users> is surely a lot
<tomreyn> maybe 2 mirrors are not enough then
<xnox> doko: boost1.53 is being prepared in svn but it apperantly has some packaging restructuring in progress and hence is not uploaded yet.
<xnox> i guess you'd want me to drive that to an upload ;-)
<doko> well, if 1.53 will be the next debian default, yes, that would be good
<doko> seb128, does gnome-calculator need a MIR?
<seb128> doko, no, it's a rename of gcalctool
<seb128> ev, hey, is filtering on a source/binary known to be broken (e.u.c)?
<seb128> ev, I'm trying to see telepathy-gabble bugs but it seems to never finish "Loading..."
<ev> seb128: think I've spotted the bug. Fixing.
<seb128> ev, thanks
<Guest89798> http://www.ubuntu.com/testing is very outdated
<czajkowski> aloha
<doko> diwic, which alsa-tools version is this?
<diwic> doko, hmm, 1.0.25-2ubuntu1
<diwic> doko, I tried packaging 1.0.26.1, that's when I discovered it and found it present in current version as well
<czajkowski> Laney: anyone else I should poke re my partial upgrade ?
<czajkowski> http://pastebin.ubuntu.com/5573162/
<Laney> I'm not sure what the intended behaviour is
<Laney> jbicha: is the Breaks strictly necessary?
<jbicha> Laney: we can't run two different cogl libraries at the same time so we don't want the old library to be present at all...
<Laney> doesn't britney ensure this?
<jbicha> I basically copied what Debian did the last time we had to do the cogl transition
<jbicha> so I believe Debian needs the breaks, I have no idea whether Ubuntu upgrades can work without it
<Laney> I can see how it would be a problem if you're running unstable (or raring-proposed)
<Laney> i.e. if the transition is in progress
<xnox> Laney: http://paste.ubuntu.com/5573220/
<Laney> haha, classy
<Laney> why keep them?
<xnox> Laney: such that they match the attic/ folder in the branch.
<xnox> why are those kept?
<Laney> because they might be useful in the future
<Laney> for the next transition of that library, for example
<Laney> or as examples for some future transition
<xnox> same. if transition finished 3 days ago, but I am confused why something is borked, one can look at it.
<Laney> can't say i've done that
<Laney> but whatevs
<xnox> =)
<seb128_> Laney, what's the issue exactly there? (sorry I disconnected), is the partial upgrade because the old soname needs to be removed?
<mlankhorst> tkamppeter_: mind if I close https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1029865 as WONTFIX since from your description it seems to be a hardware issue?
<ubottu> Launchpad bug 1029865 in linux (Ubuntu) "Intel HD graphics: Starts always with 1024x768 resolution on a 1920x1080 monitor (HDMI and DisplayPort)" [High,Confirmed]
<Laney> seb128: right, because there's a Breaks from clutter-something to libcogl<oldsoname>
<xnox> czajkowski: we shouldn't have partial upgrades in raring =(
<Laney> feels like u-m should allow this, but I don't know how to capture the situation
<Laney> and I do think we could remove the Breaks but there wouldn't be anything to stop things like this coming from Debian
<czajkowski> xnox: hence me joining here to find out whuy :)
<xnox> thanks ;-)
<xnox> Laney: you can -delete them, I'm not fussed.
<Laney> xnox: I think that should be done in the 'go' script
<Laney> to remove them before they're rsynced to public
 * Laney JFDI
<mpt> ev, foreach uuid, {foreach percentage bucket, {calculate the absolute value of the difference, if you put the uuid in that bucket, between its resulting percentage and its target percentage}; total those absolute values; put the uuid in the bucket that results in the lowest total, using the earliest if there's a tie}.
<Laney> xnox: OK it's in place
<Laney> we can expose the attic later if it's wanted
<Laney> jbicha: I'll upload to remove the Breaks now and we can decide whether u-m should be able to handle this situation at our leisure later
<mpt> ev, a simpler version that would probably work just as well: foreach uuid, {foreach percentage bucket, {calculate the absolute value of the difference, if you put the uuid in that bucket, between its resulting percentage and its target percentage}; put the uuid in the bucket that has the lowest absolute difference, using the earliest if there's a tie}.
<Laney> czajkowski: jbicha: OK, uploaded - please see if the partial upgrade goes away when that's rolled out in a couple of hours
<Laney> seb128: â fyi
<mpt> Laney, perhaps "Breaks" in update-manager is (or would best be) covered by bug 1038113?
<ubottu> bug 1038113 in update-manager (Ubuntu Raring) "support conflicts/provides/replaces and allow removal in this case" [High,Fix released] https://launchpad.net/bugs/1038113
<seb128> Laney, how did you fix it?
<Laney> I just dropped the breaks
<Laney> I don't think we need it
<seb128> Laney, it seems like that breaking on an old package that needs to be removed should be a normal/supported upgrade case
<mpt> oh, maybe not, that's fixed in Raring already apparently
<Laney> mpt: that was fixed and seems to me to be about a rather more specific case (complete replacement as expressed by the Provides)
<Laney> seb128: It was intended to stop users doing partial upgrades in the middle of the transition
<seb128> Laney, right, but it seems like at the end of the transition it should be ok
<seb128> not sure why we need to drop it
<seb128> shouldn't update-manager just do the right thing
<Laney> because u-m refuses to remove packages like that
<seb128> e.g remove the old package
<seb128> which means we pile old cruft...
<Laney> I don't know if it has any autoremoval support
<seb128> ok
<seb128> Laney, anyway, thanks for fixing it
<seb128> it seems like it's going to bite us again in the futur though
<Laney> and I do think it behaves a bit differently wrt removals when doing a release upgrade (there must be other packages being forced out in that case, surely)
<seb128> sometimes we do require removal from the old soname because there is a file conflict or something
<Laney> yeah
<Laney> and sometimes we'll just plain want to get rid of packages for some reason
<Laney> mpt: do you know how update-manager handles this?
<Laney> i.e. what is the specification that determines when you get a partial upgrade?
<Laney> perhaps it's just unreasonable; after all, you do sometimes use dist-upgrade instead of upgrade (apt-get upgrade also didn't handle this case)
<seb128> Laney, fwded you a recent email which is discussing killing the partial upgrade button
<Laney> cool, ty
<seb128> yw
<ev> the background is for each uuid representing a core file coming in, we need to assign it to a specific bucket such that the total number of uuids processed into a bucket over time matches the percentage assigned to that bucket
<ev> oh, the first part of what I wrote didn't send
<ev> [13:27:11] <ev>	 mpt: we don't know the set of uuids ahead of time. The solution I've come up with is to drop the deterministic requirement and just use random.randint(1,100) which each bucket mapping to a portion of that range
<ev> [13:27:42] <ev>	 we then pass the bucket information along with the uuid so that it doesn't need to be run again using the uuid as input, thus dropping the deterministic requirement
<Laney> xnox: http://people.canonical.com/~ubuntu-archive/transitions/ much cleaner now :-)
<xnox> Laney: all media files are gone, no css /js
<Laney> oh yeah :P
<Laney> already putting that back
<Laney> *too* clean ;)
<mpt> ev, you don't need to know the set of uuids ahead of time.
<xnox> Laney: is it croned to wipe media files? =)
<Laney> blame xnox
<xnox> Laney: i had a careful -max-depth 1
<Laney> symlink
<Laney> adding a -type f
<xnox> *sigh*
<mpt> Laney, not really. If it turns out to require UI, please assign a bug to me, and I'll extend either <https://wiki.ubuntu.com/SoftwareUpdates#uninstallable> or <https://wiki.ubuntu.com/SoftwarePackageOperations> to cover it.
<Laney> xnox: that's better, yes?
<Laney> hopefully it will all work after a cron run
<ev> mpt: oh, but it requires knowing how many uuids are in each bucket?
<Laney> mpt: I would think that, if anything, we'll extend update-manager to understand that some types of removals are OK when upgrading (so no new UI)
<Laney> automatically installed libraries only, no other relationships broken or something like that
<mpt> ev, how many you've put in each bucket so far, sure.
<mpt> Laney, sounds good.
<ev> mpt: yeah, that's not ideal. Requires persistent storage for those totals.
<ev> I'd much rather use something that gets close to accurate but doesn't require knowledge of any step before
<mpt> ev: Forgetful, deterministic, and accurate, pick two. You can demonstrate this with the simplest useful example: two buckets which you want 50% full each. A forgetful and deterministic algorithm would incorrectly either put every uuid into the first bucket, or every uuid into the second.
<ev> mpt: forgetful and accurate
<mpt> So, use random numbers :-)
<ev> mpt: "The solution I've come up with is to drop the deterministic requirement and just use random.randint(1,100) which each bucket mapping to a portion of that range" :)
<mpt> yep
<ev> but you're absolutely right about first defining the constraints, and thanks for the pointers
<sladen> ev: mpt: whenever I see you both discussing topics on here it is incredibly reassuring
<sladen> mpt: ev: continuing kudos to you
<mpt> sladen, not as reassuring as it might appear, because we aren't sitting next to each other at the moment. I haven't seen ev in days. :-)
<ev> sladen: thanks :)
<ev> mpt: yeah, I really must get back into the office
<ev> but this whole working until midnight thing is addictive
<sladen> miaow!  though it's a fair point, I didn't find Bluefin to be as inspiring an office as Millbank and I can see reasons for avoiding it ;-)
<ev> it at least has better coffee than I (suddenly) do at home
<ev> I think my transition to the UK can be considered complete when I now prefer Monmouth to Dunkin Donuts
<seb128> pitti, can you mark https://code.launchpad.net/~johnv/ubuntu/precise/libappindicator/bug-1122596/+merge/148027 as merged?
<pitti> seb128: done
<seb128> pitti, danke
<brendand> can debian/rules work from a different directory than root?
<brendand> i'm trying to get around a limitation of launchpad recipes
<seb128> pitti, I noticed that your reviewed the l-s MR, did you look at https://launchpadlibrarian.net/132004936/accountsservice_lp-1130690.diff as well and didn't like or were you just letting that for someone else
<pitti> seb128: I didn't get to that one
<seb128> pitti, I don't like that stack of scripts but at this point that small addition is not going to make a difference
<pitti> seb128: yeah, same here; it has become a terrible mess
<seb128> pitti, ok, I'm going to upload it then, I just wanted to check with you first to not step on your toes
<seb128> pitti, danke ;-)
<pitti> merci
<mpt> jodh, do I understand correctly that the Upstart user session will replace update-notifier completely? Or would it just be launching update-notifier periodically?
<mpt> Oh, I should have read the work items: "[seb128] replace update-notifier with upstart jobs: BLOCKED"
<seb128> mpt, define "update-notifier" :p
<mpt> seb128, the bane of ev's existence
<brendand> pitti - any idea ^?
<seb128> mpt, https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-reduced-power-ram has
<seb128>  [brian-murray] change update-notifier to be running on demand, from an upstart job, does the action it has been called for and exit: BLOCKED
<mpt> seb128, because it includes various bits of Apport too
<seb128> mpt, right, update-notifier evolved to be collection of different things over time
<mpt> And, unimportantly, but my focus right this minute, the cause of bug 399591
<ubottu> bug 399591 in One Hundred Paper Cuts "System Monitor shows unfriendly name "update-notifier"" [Low,Triaged] https://launchpad.net/bugs/399591
<seb128> mpt, we plan to separate those in "logical units"
<doko> xnox, I don't intend to drop guile-1.8, just demote it
<mpt> seb128, would the update part of it just be merged with update-manager, or would it stay separate?
<seb128> mpt, that's a good question, update-manager doesn't have a nonUI part atm afaik, but we could teach it to do "silent" updates and only display the ui if there are updates then
<jodh> mpt/seb128: I thought that the upstart-time-bridge would mean update-notifier would not need to run constantly, but we probably won't have that bridge in the first iteration.
<seb128> mpt, no concrete plan atm though
<seb128> jodh, right
<mlankhorst> hm seems I was still on a rc1 kernel :P
<ev> mpt, seb128: :D
<ev> seb128: RT 59730 should fix that problem
<zyga> dusty42: hi
<seb128> ev, thanks a lot for the quick fix!
<zyga> dusty42: let's talk here about the problem
<ev> seb128: sorry it took as long as it did - got pulled aside for other things
<ev> trying to get webops on it now
<zyga> (for context if anyone wants to help) - dusty42 is looking at a situation where a user is ssh-ing from macosx and inherits some of the environment from osx, that in turn causes issues with setlocale()
<zyga> we're not sure if what osx is doing is correct
<dusty42> OS X is doing it the wrong way for sure
<zyga> just that it causes actual problems that gives the impression that "ubuntu is broken
<zyga> dusty42: so you said that LC_CTYPE from osx is set to "UTF-8"
<dusty42> OS sets environment variable LC_CTYPE=UTF-8
<dusty42> when you ssh to remote host, ssh client sets LC_CTYPE=UTF-8 on remote system as well
<zyga> I mentioned that we can either fix this in one specific case (in the app that is affected now)
<zyga> or look at fixing it somewhere globally in ubuntu
<xnox> doko: why not? fedora supposedly has everything on 2.0
<zyga> if that's possible to fix reliably
<zyga> dusty42: for now I'd see if we can work around it at the app level but as I said earlier it'd be good to bring this topic up in the ubuntu-devel mailing list
<zyga> as it probably affects everything
<zyga> and mac developers sshing to ubuntu servers would get the bad impression that things don't work in certain cases
<zyga> dusty42: what does putty/windows does if you have a means to check that?
<dusty42> This snippet demonstrates how locale module in Python behaves on different LC_CTYPE env variables: http://pastie.org/6354504
<dusty42> zyga: yes, I'll check that for sure
<timrc> infinity, Hi... so I back-ported a piece of lb_binary_rootfs from 3.0.1-1 to enable ext3 and ext4 rootfs's and I noticed a peculiar line "Chroot chroot "ln -s /proc/mounts/mtab /etc/mtab" (line 128)... this caused us to hit a bug in precise but was silent in quantal... /proc/mounts/mtab... is that... valid? (I had to change back to /proc/mounts to get it working)
<timrc> infinity, wondering if you've encountered this at all
<zyga> dusty42: cool, I suspect it is safe to just blindly change 'UTF-8' to 'C.UTF-8' since the magic C.UTF-8 locale was added to glibc
<dusty42> zyga: yes, that's right
<dusty42> zyga: however, where should this env variable be corrected?
<zyga> dusty42: I would encourage you to document this, which osx version, what kind of settings (defaults matter) etc
<zyga> dusty42: so if we do for just-the-app fix then we can simply change how we call setlocale
<zyga> dusty42: if we want to do some bigger changes we'd have to ask someone else
<zyga> pitti: ^^ do you know if it would be sane/good to fix broken env that comes from osx uses sshing into ubuntu?
<zyga> pitti: like doing some tests in the early environment files that (hopefully) all the shells source, or even straight in the ssh package
<pitti> zyga: I wouldn't quite know where, though
<pitti> in general I have always found it rather questionable to forward locale env through ssh as well
<pitti> it causes at least as much unintended damage as it does good
<zyga> yeah, especially since there is no agreed-upon meaning for any of the values
<zyga> I suspect that LC_TYPE=UTF-8 is valid somewhere but it just breaks us
<dusty42> pitti: in case with OS X, the defaults are broken (well, at least with regard to Ubuntu settings)
<zyga> pitti: alternatively
<zyga> pitti: we could do it at libc level
<zyga> pitti: where it would be an alias of C.UTF-8
<dusty42> zyga: this sounds like the nicest workaround, actually
<pitti> well, the names of locales are defined by the local localedef conventions and thus by the distro/OS
<zyga> but I don't know if that's sensible actually -- can LC_CTYPE carry language definition?
<pitti> that's one major reason why they don't belong forwarded
<pitti> (the other is that in many cases the locale doesn't even exist on the remote machine)
<zyga> it sure makes sense in LC_MESSAGES but for LC_CTYPE?
<zyga> pitti: yeah, that's another valid problem
<zyga> pitti: we track that separately
<pitti> it's much better to use the remote computer's .bashrc or .pam_environment or whatever IMHO
<pitti> no, it doesn't make sense for any LC_*
<zyga> pitti: so do you think that what osx does is correct? sending us LC_CTYPE=UTF-8?
<pitti> IMHO we should drop SendEnv from /etc/ssh/ssh_config, but I guess cjwatson feels otherwise
<zyga> pitti: do you think we should move this to the mailing list to get feedback from more people?
<pitti> zyga: well, UTF-8 is not a locale, but if OSX defines a locale with that name (presumably based on en_US), it's valid within an OSX context
<zyga> pitti: the topic is certainly interesting but perhaps invisible to us, since we don't use windows/osx typically
<pitti> oh, there is perhaps a workaround, see bug 313317
<ubottu> bug 313317 in Ikarus Scheme "guard should allow definitions in its body" [Low,Fix committed] https://launchpad.net/bugs/313317
<pitti> err, debian bug 313317
<ubottu> Debian bug 313317 in openssh-server "openssh-server: PAM environment takes precedence over SendEnv" [Normal,Open] http://bugs.debian.org/313317
<pitti> (which I actually consider a good thing)
<pitti> debian bug 391964 and debian bug 558171 are also related
<ubottu> Debian bug 391964 in openssh-client "warn if client-requested locale not available on server?" [Important,Open] http://bugs.debian.org/391964
<ubottu> Debian bug 558171 in openssh-client "openssh-client: some LC_LOCALE settings make ssh fail to open a shell" [Important,Open] http://bugs.debian.org/558171
<pitti> debian bug 573316 is probably the closes thing
<ubottu> Debian bug 573316 in openssh-client "request for new UnSendEnv directive (or change SendEnv)" [Wishlist,Open] http://bugs.debian.org/573316
<zyga> pitti: yeah, that does sound right a lot
<pitti> zyga: ^ in case you want to refer to some bugs in your mail
<zyga> dusty42: ^^ would you mind looking at those as possible general solutions to this problem?
<zyga> pitti: thanks a lot
<pitti> well, these are not solutions, they are bugs which happen because of the locale forwarding
<dusty42> Sure
<pitti> I have more, like people create postgresql clusters with wrong encodings, and get tons of perl errors due to wrong locales
<doko> xnox, well, in this case maybe consider moving the headers into a location where guile-1.8-dev had them
<pitti> zyga, dusty42: so it seems cjwatson went off IRC for the first time in years, so bad time to discuss this :/
<zyga> :D
<zyga> pitti: I came across the postgresql bug myself, IIRC our cloud images were affected by tyhat
<zyga> that
<zyga> pitti: sorry, I misunderstood then, I'ms till reading the bugs you've referenced
<dusty42> It's actually not that hard to handle this at app level
<pitti> dusty42: so either fix it on the client ssh side by dropping SendEnv, or on the server side by adding a .pam_environment file with the correct locale for the remote system
<zyga> dusty42: true but then each app has to do it
<zyga> pitti: note that we cannot fix the client, this is osx that's causing the problem (and putty)
<dusty42> zyga: of course, and this aint' cool at all
<pitti> nah, fixing a broken environment really shouldn't be done by-app
<zyga> pitti: although putty is broken in different way
<zyga> IIRC putty uses some silly old encoding by default but does not actually specifies it as such in any of the environment variables it sends
<Kano> hi, is there a lightdm channel or is it here?
<zyga> like sending ISO8859-2 over the wire (and interpreting that locally for display) and not sending anything at all as environment
<zyga> this causes issues with backspace and how it is interpreted
<dusty42> pitti: so, as I understand, those bugs should be closed because it's the problem on the client system, not Ubuntu itself, correct?
<pitti> dusty42: no, Debian/Ubuntu's ssh also defaults to forwarding these environment vars
<zyga> dusty42: also note that most users don't understand that and just see broken ubuntu
<dusty42> pitti: fixing the LC_CTYPE globally via /etc/.profile is a bad idea, right? E.g. detect if it's "UTF-8" and change to "C.UTF-8"?
<zyga> dusty42: so if we can get a workaround that just makes things work right when we see broken input, that's good
<dusty42> maybe not /etc/.profile, somewhere else (not yet sure where)
<brendand> zyga, you're needed :)
<hallyn> plars: hey, are you by any chance expert at building crosstools on recent ubuntu ?
<zyga> :)
 * zyga -> meeting
<plars> hallyn: nope, sorry :(
<hallyn> i've wasted like a day now trying to get it to compile, always ends up failing somewhere.  (used linaro releases 2012.10 and 2012.12 before, now using upstream )
<hallyn> ok - thanks
<zyga> plars: hey, long time no see, how are you  doing?
<mitya57> Mirv: can you please apply https://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtsvg-opensource-src/revision/22 to Debian git?
<mitya57> I've been doing some icon themes testing in Debian, and without that change SVG themes don't work
<mitya57> Mirv: and while we are at it, please also apply http://paste.ubuntu.com/5573584/
<mitya57> rickspencer3: Friday 27th Feb???
<rickspencer3> hi mitya57
<rickspencer3> did I put a weird typo in my email?
<rickspencer3> *sigh*
<rickspencer3> maybe I mean tomorrow :)
<mitya57> hopefully everyone will understand that
<Laney> rickspencer3: Friday 27th Feb? ;-)
<rickspencer3> Laney,  I know I know
<Laney> :P
<rickspencer3> I spent *days* working on that email
<rickspencer3> and I missed that one thing
<rickspencer3> I am such a bad proof reader
<Laney> yeah, the letters stop going in
<Laney> you mean tomorrow, I guess?
<jpds> Laney: Clearly, yesterday.
<Laney> jpds: Ah, OK.
 * Laney speeds up to 88mph
<rickspencer3> thanks Laney
<rickspencer3> :)
<ogra_> only 88 ?
<ogra_> ah, you're in an autobahn-less country ... /me forgot :P
<Laney> rickspencer3: At least I just exposed that I didn't read the few lines immediately prior to my saying it ...
<Laney> ogra_ hasn't seen back to the future?
<rickspencer3> clearly
<ogra_> oh, i missed the referral
<ogra_> :P
<plars> zyga: sorry, was in a meeting. I'm doing well, lots going on as always :)
<zyga> plars: :-)
<CalvinKlein> Laney, ^ that's for you
<Laney> :D
<Laney> stgraber: Hey ho
<Laney> so, trying out user session jobs ... what's the compiz one for?
<Laney> That should be started by gnome-session if needed shouldn't it?
<doko> Sweetshark, online?
<Laney> If I remove it I can start other gnome sessions (trying shell) under upstart
<stgraber> Laney: right, compiz, nautilus, gnome-settings-daemon and pulseaudio are all example jobs to show what we could to if the plan was to phase out some parts of gnome-session
<Sweetshark> doko: yes and in call
<Laney> stgraber: ah
<stgraber> Laney: I don't think we should push those to the archive as they're indeed not needed in the current state of things
<Laney> but since we still call gnome-session then they can get in the way sometimes
<xnox> Laney: but e.g. it would be nice to at least have gtk-window-decorators as an upstart job, cause it crashes a lot and we can respawn it. Similar with compiz. I'm not sure about gnome-session's respawing capabilities.
<stgraber> Laney: compiz and nautilus might, gnome-settings-daemon and pulseaudio won't
<Laney> right
<stgraber> Laney: as gnome-settings-daemon and pulseaudio are overriden by /usr/share/upstart/xdg/autostart/
<xnox> Laney: if you can point me which piece of gnome-session starts compiz i'd like to know, cause I failed to find the right place to override.
<Laney> xnox: AFAIK the .session file for unity tells it to start
<Laney> gnome-session searches for a matching .desktop file
<xnox> Laney: we nifty prepend /usr/share/upstart/xdg to XDG_CONFIG_DIRS to shadow a few autostart/*.desktop files in favor of upstart jobs.
<Laney> right
<xnox> And I'd like to shadow compiz for example, in a similar fashion if possible.
<Laney> so we'd want some kind of interfacing with .session files maybe
<Laney> or something
<xnox> cause imho having upstart manage the window manager would be awesome.
<Laney> to only start compiz in a session which wants it
<xnox> or we do it by default where ubuntu.session has upstart in it instead of compiz.
<xnox> (wait that won't work)
<Laney> see Required* in /usr/share/gnome-session/sessions/*.session and gnome-session(1)
<stgraber> as long as we're in a world that mixes upstart and gnome-session, we're going to have to live with some hardcoded values in the jobs. It should however be possible to do something along the lines of "start on starting gnome-session DESKTOP_SESSION=ubuntu
<tkamppeter> mlankhorst, you can close the bug, it is in fact some hardware problem.
<stgraber> "
<Laney> does that work?
<Laney> could you have some thing which reads the .session files and emits some events based on what they'd cause to be started?
<Laney> s/files/file to be loaded/
<bochecha> hi, somebody opened a bug report against my project, that it doesn't install in the right place on Ubuntu 12.04
<bochecha> looking closer, it turns out that the autotools stuff runs this code, to find where to install the Python module: http://paste.fedoraproject.org/3987/
<bochecha> and as you can see in the paste, the returned folder is wrong (it should be python3.2, not python3)
<bochecha> any idea on how to fix this properly?
<stgraber> Laney: we may need an extra "export DESKTOP_SESSION" in gnome-session.conf, but yes, it's easy enough to get DESKTOP_SESSION to be exported to other jobs so they can start depending on that
<Laney> I didn't know you could have "start on <some environment variable>" - that's useful for now indeed
<didrocks> barry: doko: maybe you would have any idea on bochecha's question? ^
<barry> bochecha: hi.  let me look
<bochecha> barry, hi, thanks :)
<stgraber> Laney: writing a parser for gnome-session should be possible too but I guess this really depends on the plans for the desktop, because it may be quite a bit of work to get something that's flexible enough and I don't think we want to invest that kind of time if there are chances we'd move away from gnome-session
<stgraber> (not that I really know anything about your plans, hence why I ask ;))
<Laney> right, I don't know that that's planned
<Laney> or how much work it would be to nick parts of it out of gnome-session itself
<barry> bochecha: well, actually, the path in line #2 looks right.  dist-packages is correct for debian/ubuntu (instead of site-packages), and because of pep 3147/3149 file tagging, we can install all python3 modules in the same location without conflict
<bochecha> barry, but then, the module can't be imported in python3
<barry> bochecha: line #1 does look a little weird in that sysconfig is imported but not used ;)
<xnox> bochecha: hm why not? all python3.X look in python3/ location.
<barry> bochecha: hmm, do you know why it can't be imported?  have you tried using -v?  can it not be imported because it can't be found, or because of some other problem on import?
<bochecha> barry, actually, it can be imported, you're right that /usr/lib/python3/dist-packages is in sys.path
<bochecha> I incorrectly  tried to reproduce the bug
<bochecha> the reporter had used /usr/local as his prefix
<bochecha> and /usr/local/lib/python3/dist-packages is not in sys.path
<bochecha> barry, only /usr/local/lib/python3.2/dist-packages is
<barry> bochecha: ah, yes, that's true
<barry> bochecha: i guess if they're doing a source install, it has to go to /usr/local and not /usr
<doko> correct, because we can't guarantee what the user installs there, and if it's compatible for different python versions
<bochecha> barry, yes, that's the default with autotools anyway when you don't specify --prefix
<bochecha> but then... what can I do?
<barry> bochecha: agreed :)
<bochecha> is my only choice to tell people Â« if you install on Ubuntu 12.04, use --prefix=/usr Â» ?
<barry> bochecha: are you "distutils-based"?  setup.py and setuptools or distribute?
<bochecha> pure autotools
<bochecha> the command I pasted is what the configure script ends up running to find where to install modules
<vibhav> doko: Thanks for sponsoring my merge :)
<xxiao> i have a headless ubuntu 12.10, it pauses for a few minutes during boot, bootlogd showed Starting load fallback graphics devices                               [fail]
<barry> bochecha: sorry, i was trying to see if we had any specific recommendation in our wikis, but it doesn't look like it
<bochecha> :-/
<xxiao> this is from udev-allback-graphics.conf, how can I disable this safely
<barry> bochecha: give me just a few minutes...
<bochecha> barry, of course :)
<bochecha> barry, by the way, the code is at https://github.com/bochecha/pycangjie if that helps
 * bochecha realizes he probably should have started with this...
<barry> bochecha: ;)  let me try something with your trunk to make sure i don't recommend something that doesn't work
<bochecha> barry, I don't want to bother you too much, there's a bunch of stuff you'd have to install beforehand
<bochecha> like a more recent version of Cython
<bochecha> or libcangjie
<barry> bochecha: ah, okay.  try --prefix=/usr/local and if that doesn't work, probably hard coding installation into /usr/local/lib/pythonX.Y/dist-packages will be the most expedient thing
<xxiao> is there a verbose mode of upstart that I can see more info at startup, even timestamps?
<bochecha> barry, specifying --prefix=/usr/local gives the same result as not specifying it: /usr/local/lib/python3/dist-packages
<barry> bochecha: i guess the code is in configure.ac?
<bochecha> barry, yes
<bochecha> barry, https://github.com/bochecha/pycangjie/blob/master/configure.ac#L24
<bochecha> but the automatically generated configure contains this: http://paste.ubuntu.com/5567643/
<bochecha> the code which ends up being executed is what I had pasted earlier: $PYTHON -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='$am_py_prefix'))"
<xnox> barry: I half wish pkgconfig files for python would specify the default locations.
<xnox> barry: cause above would fail to cross-compile.
<barry> xnox: agreed.  this really should be easier and better documented
<barry> (for non-distutils stuff)
<barry> bochecha: well, this won't make you happy, but probably the generic thing to do is scan sys.path for the first /usr/local path and use that :/
<barry> sysconfig won't help you because there are no /usr/local paths there
<doko> jodh, stgraber:  I still see https://launchpad.net/~canonical-foundations/+archive/upstart-daily/+build/4333370 hanging. I thought that was fixed in the ppa?
<bochecha> barry, hmmm, but that's all automatically generated by the autotools, I'm not sure I want to interfere with what they do :-/
<stgraber> doko: I don't see enough context in that part of the log to know if it's the same bug
<jodh> doko: that 'tail' doesn't show what test failed.
<stgraber> doko: and it worked on all other architectures, so it's not the same bug
<stgraber> oh, and the previous daily worked on armhf too, so it may just be some kind of race
<barry> bochecha: you may not have a choice but to override this.  i suspect that really autotools needs to learn about this.  maybe doko has some opinion about that
<bochecha> barry, what I don't understand is that on 12.04, sys.path contains /usr/local/lib/python3.2/dist-packages
<bochecha> but then, what's the point of containing that folder if it's not where stuff gets installed?
<barry> bochecha: the problem is that autotools doesn't know about that installation location.  i'm fairly sure that a setup.py based install would dtrt
<bochecha> well, autotools is only returning what that python code I pasted above returns
<bochecha> on Fedora, that Python code returns the right thing
<bochecha> and when run with --prefix=/usr, that Python code also returns the right thing on Ubuntu 12.04
<bochecha> so to me, it looks like Ubuntu is doing something fishy with its Python paths
<bochecha> or rather, with the path in /usr/local that ends up in sys.path
<pitti> mdeslaur: so it actually is planned to put USNs into the previous monthly snapshot?
<pitti> mdeslaur: I wonder, wouldn't these people just upgrade to the latest daily packages anyway the first time update-notifier pops up?
<pitti> mdeslaur: i. e. as soon as we fix stuff in the devel release together with stables, wouldn't that already fix it for everyone?
<pitti> mdeslaur: otherwise we would actually need a new series each month
<Daviey> pitti: I wonder if there is a way a new series could be avoided.
<pitti> mdeslaur: ah, maybe I'll reply to your mail instead, to keep discussion at one place
<bochecha> barry, what is the reason for sys.path containing /usr/lib/python3/dist-packages but /usr/local/lib/python3.2/dist-packages ?
<mdeslaur> pitti: I don't know the exact details of how the monthly snapshots will be handled with regards to pockets and such, but for security updates that are urgent, such as the sudo CVE that just came out, I'll be pushing that in both places
<mdeslaur> pitti: ah, yes, we can discuss on the list
<zyga> pitti: exciting times ahead :-)
<pitti> mdeslaur: posted
<barry> bochecha: doko said earlier: <doko> correct, because we can't guarantee what the user installs there, and
<barry>        if it's compatible for different python versions
<pitti> Daviey: yeah, IMHO new series each month would be just mad
<bochecha> barry, but for stuff in /usr/lib/... you can?
<pitti> Daviey: I understood the monthly things as blessed snapshots, not full releasese
<barry> bochecha: yes, because apt controls /usr/lib :)
<bochecha> sure, but are packages actually tested to work with other Python 3 versions?
<bochecha> or is it Â« compatible with all Python 3 versions installed in /usr, and no version other than the one provided by apt should ever be installed in /usr Â» ?
<barry> bochecha: if they are packaged correctly, and they have a test suite, then they will be tested against all supported python3 versions for the distro-version. (autopkgtests can also be added to tests for simple stuff like importability).
<barry> bochecha: correct
<bochecha> honestly, that's annoying
<barry> bochecha: "that's" == ?
<bochecha> about just as annoying as the result of --prefix=/usr/local on Fedora (there is nothing in /usr/local in the default sys.path, so modules must be installed in /usr :P)
<bochecha> barry, the situation with installing Python modules in /usr/local in Ubuntu
<bochecha> (but then again, it's annoying on Fedora too, for different reasons)
<barry> bochecha: i'd amend that to be "non-setuptools based modules" and i agree
<bochecha> :)
<barry> bochecha: at the very least, we should have clear documentation about best practices here, which we don't, and that also sucks
<bochecha> barry, I'll try to figure out a not-too-dirty way to test for the distro, and if it's Ubuntu and prefix=/usr/local then use py3versions to find the right path
<barry> bochecha: unfortunately, right now i don't have any time to push that forward.  if you have time and inclination, a discussion on the debian-python mailing list would be fantastic, and it's always possible i'm missing something obvious
<barry> bochecha: fwiw, ubuntu inherits all this behavior from debian, so pushing this upstream will give the best results
<bochecha> barry, well, I'm just a FOSS developer, and a Fedora user/contributor, so you'll understand that improving the Debian/Ubuntu Python stack is not necessarily my highest priority ;)
<barry> bochecha: i do ;)
<bochecha> I'm just very interested in having my stuff install and run cleanly on Ubuntu
<bochecha> because it turns out most people who are likely to use my software are running Ubuntu
<barry> bochecha: tell toshio, dave malcolm, or nick coghlan to bug me at pycon :)
<bochecha> heh :)
<bochecha> anyway, thanks a lot for all the pointers, the issue is now much clearer in my mind
<jbicha> hmm, I wonder how I magically became unsubscribed to ubuntu-devel, I've been missing all the excitement
<bochecha> I'll try to fin a way to fix it tomorrow though, it's 1am here
<barry> bochecha: another low bandwidth thing you could do is to file a bug here: http://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=python3-defaults or https://bugs.launchpad.net/ubuntu/+source/python3-defaults and while they may not be the ultimate best place to fix them, at least the issue doesn't fall off the radar by being in irc
<barry> bochecha: sure, sorry i don't have better news
<bochecha> no problem, I'm much better off than before coming in here: now I understand what the problem is :)
<bochecha> anyway, going to bed now
<bochecha> thanks again barry
<barry> bochecha: cheers
<tedg> Does anyone know if someone has tried to use the abi-compliance-checker to create something like a symbols file, but with more coverage?
<sladen>  /join #ubuntu-community
<tedg> slangasek, ^ this seems like something you'd know :-)
<slangasek> tedg: I don't know anything about the abi-compliance-checker package in particular.  What do you mean by "like a symbols file"?
<tedg> slangasek, It can do a dump.  So and then compare.  So I could do an acc dump, and see if the ABI has changed since that dump.  Basically the way a symbols file is checked for new/removed symbols.
<slangasek> tedg: a long, long time ago I was familiar with icheck, which had a similar kind of "cache the current api" interface
 * slangasek nods
<slangasek> tedg: so icheck may be a better starting point?
<xnox> tedg: I did.
<xnox> tedg: and it did catch abi breakage in my package.
 * tedg is looking at icheck
<tedg> xnox, Used icheck or acc?
<xnox> acc
<tedg> xnox, Did you do it as part of the package build?
<xnox> tedg: yes, but I ended up storing the processed /old/ reports in the source package.
<xnox> tedg: i have a workitem to implement this genericly for "core desktopy / graphical libraries" as needed by steam. But no such list emerged so far.
<xnox> tedg: what would you like to track abi off?
<tedg> xnox, Everything!  :-)
<tedg> xnox, Specifically we were looking at the Unity-ish libraries we maintain.
<xnox> and in the cloud?!
<seb128> tedg, did you come to that topic on your own or as part of some team thinking? just asking because it's something that tvoss discussed a bit with lool and slangasek recently, they took an action item to look at it
<seb128> tedg, in any case if you are just looking at the same problem by coincidence, maybe talk to lool ;-)
<tedg> xnox, But for some more general solution, than us just doing it for fun.
<Laney> have you seen http://upstream-tracker.org/ ?
<xnox> tedg: there is some code to run it as a service against many opensource libraries as in upstream-tracker,
<tedg> seb128, We'd talked about it before.  I didn't realize anyone else had started looking into it more than chat.
<xnox> but that obviously lacks ubuntu-applied patches.
<tedg> Sure, and I'd like to fail a build if it changes unknowingly.  Daily quality and all that.
<tedg> So a webservice doesn't really work there.
<xnox> i was thinking to have it run in jenkins / adt test
<seb128> tedg, we had an hangout where we discussed that either, lool/slangasek have an action item to investigate, talk to them ;-)
<xnox> but I'm not sure where / how to store previous result for comparison with just built one.
<tedg> xnox, Why not in the debian/ directory just like the symbols file?
<xnox> something like ship it in-the package and then before britney migrates stuff grab one from -release and one from -proposed and fail if abi is broken and package is not renamed.
<tedg> seb128, Will do, but thinking they might have already seen your ping ;-)
<seb128> tedg, yeah, it was sort of the point
<seb128> tedg, just making sure that you guys talk and don't do twice the same investigation work ;-)
<xnox> tedg: generate the first one, commit and have hooks to check at build time. Ok, sounds like a good enough start.
<xnox> tedg: I can write a dh_helper to do that.
<tedg> xnox, That'd be awesome!
<tedg> I'll use it :-)
<xnox> ack.
<slangasek> tedg, xnox: I think the api manifest should be generated at source package prep time and shipped in the source package
<slangasek> then checked at package build time
<xnox> slangasek: no. because current manifest will always match current built. one wants to compare the first shipped version of the package (n) with current api/abi no make sure this new (n+3) version is compatible.
<slangasek> xnox: by "at source package prep time" I don't mean "each time you build the source package"
<slangasek> just like .symbols
<xnox> i see what you mean. yes.
<xnox> after adding config file, one would not get a comparison but just initial manifest on first build.
<xnox> if it's stored in the source package subsequent builds will do comparison.
 * slangasek nods
<xnox> pitti: new gtk doesn't know what a green color is? =) http://paste.ubuntu.com/5573983/
 * xnox investigates.
<lool> tedg, seb128: Yup; essentially this comes from tvoss proposing that we adhere to API and ABI stability policies and we need tools to enforce that; slangasek brought up icheck and we need to investigate how to leverage which tools where
<lool> other things that came up for the ABI were e.g. use of symbol versioning
<slangasek> lool: right... the question is, why is tedg worrying about it if we have the action item :)
 * tedg didn't know slangasek and lool had the action item :-)
<lool> I think tedg has a microphone in my home somewhere
<ev> any ubuntu-devel@lists.u.c moderators around? Keybuk's post is apparently stuck in the queue.
 * tedg would ask lool to please speak softer, you're hurting my ears!
<slangasek> I was going to point to cjwatson, but his network apparently ate itself 6 hours ago
<xnox> slangasek: yeah, he did mention restructuring his network ;-)
<slangasek> yah, he'd mentioned to me he was going to be doing that... guess it's not going so well :-P
<xnox> stgraber: u-d@lists.u.c can you moderate Keybuk's message?
<stgraber> xnox: I don't think I have moderation access for u-d
<micahg> one was already let through
 * Laney is happy to volunteer to mod if manpower is needed
<chrisccoulson> slangasek, xnox, he did post on twitter a short while ago https://twitter.com/colmmacuait/status/307185273924616192
<slangasek> :-)
<xnox> ev: I like how to ride the wave to advertise phased updates & errors work ;-)
<ev> xnox: it was more to reassure people
<ogra_> Laney, i guess manpower is needed ... ast cjwatsons place :)
<ogra_> *at
<Laney> ain't sysadminry fun?
<ev> if we didn't have a way to keep tabs on the development over the two years or so, a way to measure ourselves against the previous LTS, it'd be a much harder sell
<davmor2> is there a known issue with the battery meter saying crazy stuff, like 12.47 to charge when it has been on charge most of the day?
<slangasek> davmor2: yes; this known issue is that you can never reliably know how long a charge will take, and also that batteries are mixed in how good of information they give
<slangasek> however, it's possible this is not the same issue you're seeing
<davmor2> slangasek: well it's been on charge for 5 hours-ish and says 86% full for a laptop that I got in January, the time down is all over the place and then the time to charge is the same.  However a couple of days or so ago it seemed a lot more accurate
<slangasek> davmor2: yep - unfortunately I can't say from that whether it's a software bug, a battery physical failure, or a battery firmware failure
 * ogra_ guesses for a SW bug .... it started for me on the nexus7 with the switch to raring
<slangasek> ah, well then
<ogra_> my chromebook had it too until i switched to a differet desktop
<davmor2> ogra_: thanks
<slangasek> bug report to gnome-power-manager, maybe?
<ogra_> so i would blame upower here
<ogra_> g-p-m only has some UI bits left, upower is the new stuff
<ogra_> check if "upower -d" also gets you odd values
<davmor2> slangasek: so u-b upower  any info that would be useful to you guys ?
<davmor2> ogra_: will do one second
<slangasek> davmor2: ubuntu-bug should do it
<ogra_> yeah
<davmor2> ogra_: yeap upower currently says 2 hours to total charge for the last 14% of the battery :)
<ogra_> :)
<davmor2> ogra_: bug #1136227
<ubottu> bug 1136227 in upower (Ubuntu) "upower is reporting really odd stats for battery charge time" [Undecided,New] https://launchpad.net/bugs/1136227
<bdmurray> Daviey: you might be interested in https://errors.ubuntu.com/?user=ubuntu-server
<Daviey> bdmurray: I bet my left arm those are all ubuntu desktop installs :)
<bdmurray> Daviey: the point isn't those crashes but that you can see crashes associated with packages to which the ubuntu-server team is subscribed
<slangasek> Daviey: hmm, does that mean you don't care about frequent crasher bugs in packages you maintain if the data comes from people installing them on the desktop?
 * slangasek loads the page -ooh, pretty graph
<Daviey> slangasek: it more likely means people will put words in my mouth.
<slangasek> oh, the top crashers are all in samba
<slangasek> yeah, run away ;)
<slangasek> bdmurray: drive-by bug report: the table of packages on this crash page doesn't seem to know that precise-security and precise-updates versions are part of Ubuntu 12.04?  https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fsbin%2Fsmbd%3A6%3Adump_core%3Asmb_panic%3Aset_unix_security_ctx%3Aset_sec_ctx%3Achange_to_user_internal
<bdmurray> arges: there are 2 uploads of iptables by you to the precise-proposed queue
<arges> bdmurray: hi
<bdmurray> slangasek: that'll get sorted out when we have the new bucketversion column famly
<slangasek> bdmurray: ok
<arges> bdmurray: yes. these fix two differnt bugs
<bdmurray> arges: right but neither includes fixes from the other
<arges> bdmurray: ok how should i approach this? I can't upload myself, should I submit a debdiff with both fixes applied?
<bdmurray> arges: yes, let me know and I'll upload it for you.  in the mean time I'm going to reject the existing ones
<arges> bdmurray: ok one debdiff comin right up. thanks
 * mpt wonders if there is a count of how many SRUs 12.10 has had so far
<slangasek> you could tally from the mails on quantal-changes for everything that post-dates the release
<slangasek> IIRC, that would give you the count of successfully completed SRUs, but not those that failed out or are in progress (or stalled)
<mpt> ...hundreds :-)
<mpt> ok
 * slangasek nods
<arges> bdmurray: http://people.canonical.com/~arges/iptables/ , I have the debdiff, dsc files in this directory. I have verified that this package fixes the two bugs on my amd64 machine.
<bdmurray> arges: uploaded
<arges> bdmurray: thanks
<barry> would a pythonista care to review this m-p?  i'm most interested in reviewing my thinking behind the change (since it's just a one line change) and offer insights into how to reproduce/test it: https://code.launchpad.net/~barry/aptdaemon/lp1120322/+merge/151083
<lifeless> barry: looking
<barry> lifeless: thanks.  there might be a little more context in the linked bug discussion
<lifeless> there are 7 pending branches
<lifeless> might want to look at cleaning that up as you go ;0
<barry> heh, yeah
<lifeless> what version of python are the reporters running
<lifeless> 2.7's difflib physically cannot yield lines other than ---/+++/@@ without including the @@
<barry> lifeless: 3.2 and 3.3 i think
<lifeless> difflib.py line 1211
<lifeless> ah, I see the issue
<lifeless> your analysis is wrong
<lifeless> the action might be correct.
<barry> lifeless: hmm, i guess REGEX_RANGE check could fail, causing the @@ match to never get to the line_number assignment
<lifeless> right
<lifeless> I'm just explaining the situation that will happen in
<barry> lifeless: excellent, that will help produce a test case :)
<lifeless> barry: https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/1120322/comments/8
<ubottu> Launchpad bug 1120322 in aptdaemon (Ubuntu Precise) "update-manager crashed with UnboundLocalError in show_diff(): local variable 'line_number' referenced before assignment" [High,Triaged]
<barry> lifeless: nice catch, thanks.  makes sense and should be testable.
<lifeless> barry: thats why they pay me the big bucks
<barry> :)
<lifeless> barry: its special cases like this that make many specs horrendous to implement
<barry> lifeless: python -c "import this" | grep special
<lifeless> yeah
<hallyn> slangasek: do you think shipping a symlink from /usr/bin/kvm-spice -> /usr/bin/kvm in qemu-system-x86 for all users is no big deal?  (it feels heavyhanded to me as the only people who need it are people who had qemu-kvm-spice installed before)
<hallyn> but it *is* just one symlink...
<lifeless> hallyn: update-alternatives
<lifeless> hallyn: perhaps ?
<hallyn> lifeless: i'm not worried about people who type it by hand - only people who have a libvirt VM defined with /usr/bin/kvm-spice as the hardcoded path to the emulator
<hallyn> do alternatives help with that?
<slangasek> hallyn: sorry, are you asking me if it's ok to provide the symlink?
<hallyn> oh, i guess so?  they'll put a  symlink into place?
<hallyn> slangasek: yeah.
<lifeless> hallyn: yeah, alternatives provide symlinks to binaries when multiple packages might supply the binary
<hallyn> slangasek: given that kvm-spice was provided by a universe package, and kvm by main
<hallyn> lifeless: there aren't multiple packages though
<lifeless> ah
<lifeless> possibly not useful here then
<slangasek> hallyn: if you do, you should also add Conflicts/Replaces/Provides to the package metadata against the old qemu-spice package, whatever it was called?
<slangasek> (qemu-kvm-spice)
<hallyn> slangasek: that's already there
<slangasek> hallyn: and taken as a whole, I think that's a good idea
<hallyn> to force qemu-kvm-spice off the system
<slangasek> hallyn: ah, not according to my apt-cache :)
<hallyn> slangasek: oh, it's on qemu-kvm
<hallyn> not on qemu-system-x86
<slangasek> hallyn: ok, in that case I'd put the symlink in qemu-kvm
<hallyn> slangasek: ok will do, thanks.
<smoser> anyone know...
<smoser> when i do: losetup --show --find /tmp/my.img
<smoser> something sets up /dev/loop0p1
<smoser> what is that? because sometimes it seems not to work for me.
<cody-somerville> smoser: kpartx can do that
<smoser> it can do that.
<smoser> but sometimes something magically *does* do that.
<czajkowski> cjwatson: welcome back
<czajkowski> Laney: think it's safe for me to do an update now ?
<Laney> try it
<czajkowski> if it breaks I'll come find you ;)
<Laney> it would have worked anyway; my upload was just to try and stop you getting a partial upgrade
<soren> smoser: And you're sure it's not kpartx?
<smoser> soren, well, i'm not sure at the moment...
<smoser> but 'apt-get install kpartx' doesn't just make it star tworking
<cody-somerville> smoser: I think it happens if max_part is set on loop  kernel module
<soren> smoser: It was a udev rule that's supposed to do exactly that.
<soren> *has
<smoser> soren, yeah, i think that udev is not recognizing the rule on install
<czajkowski> Laney: http://pastebin.ubuntu.com/5574632/
<Laney> czajkowski: do you get a partial upgrade?
<smoser> soren, well, i somewhat verified its not kpartx.
<smoser> apt-get --purge remove kpartx
<Laney> i don't know what's going on with ibus-table there
<smoser> and i'm still getting the devices
<cody-somerville> smoser: do modprobe -r loop && modprove loop max_part=63
<cody-somerville> smoser: and then see if it sets up the /dev/loopNpN after setting up loop device again on disk image
<czajkowski> Laney: nope all good now
<smoser> cody-somerville, but what would have changed that in these 2 settings?
<smoser> i'll try though
<smoser> cody-somerville,
<smoser> FATAL: Module loop is builtin.
<Laney> czajkowski: cool beans
<Laney> thanks for reporting
<czajkowski> np
<cody-somerville> smoser: ok, you can set the option then by passing option using the kernel command line then: loop.max_part=63
<smoser> cody-somerville, i've not done that on either system. same kernel.
<smoser> (they're both raring instances...)
<cody-somerville> does 'cat /sys/module/loop/parameters/max_part' spit something different out between the two of them?
<smoser> soren, '0' on both
<cody-somerville> but one will automatically create /dev/loopNpN files for the same disk image when you loop mount it and the other doesn't?
<soren> smoser: max_part needs to be > 0 at init time for it to matter here.
<soren> I think, however, that doing a blockdev --rereadpt /dev/loop/X will cause the /dev/loopXpY devices to be created.
<smoser> soren, what would make 'max_part' > 0 ? (which is not the case on either of my systems)
<soren> So something might be doing that (or issuing the corresponding ioctl's by some other means) separately.
<soren> smoser: kernel cmdline parameter.
<soren> Since it's a builtin module, it has to be set that early.
<soren> This is based on reading the driver code. I could be reading it wrong, but it looks fairly straight forward.
<smoser> http://paste.ubuntu.com/5574669/
<smoser> well,
<smoser> $ cat /sys/module/loop/parameters/max_part
<smoser> 0
<smoser> on both systems
<soren> Gotcha.
<soren> Can you trigger their creation by issuing a "blockdev --rereadpt /dev/loopX"?
<smoser> $ sudo blockdev --rereadpt /dev/loop0
<smoser> BLKRRPART: Invalid argument
<smoser> on both
<smoser> i'm not sure how i got the one system actiing this way.
<soren> Interesting.
<smoser> actually..
<smoser> i think i know what it is
<smoser> its related to partx --update
<smoser> yeah, it is.
<smoser> because i can actually drop the 'sfdisk' in that pastebin
<smoser> and i still get /dev/loop0p1 on one system
<smoser> and if i change it to not use '--find'
<smoser> and specify losetup //dev/loop3
<smoser> then it does not get /dev/loop3p1  created
<smoser> yep.
<smoser> so on the working system..
<smoser> "working"
<smoser> i did:
<smoser> i ran that pastebin. then in the subshell did:
<smoser> partx --delete 1 /dev/loop0
<smoser> and i no longer get it magically created.
<smoser> it seems that if you partx --update, then the kernel somehow remembers.
<smoser> (incorrectly)
<mpt> achiang, oh snap
<mpt> We posted the same thing :-)
<achiang> mpt: my biggest accomplishment for the day! :)
<mpt> heh
<achiang> it's kinda late in london, no?
<xnox> mpt: achiang: I thought monthly _iso_ is meant as a checkpoint to do extensive hw verification and installer testing.
 * xnox is not expecting actually user visible "monthly upgrades"
<slangasek> xnox: the proposal on the table includes monthly upgrades
<xnox> slangasek: yeah, I noticed =)))) i'm still pondering on how it will affect me, my packages, my machine(s) and people I provide support for.
 * xnox remembers setting most of windows software to auto-update using beta channels if available. Nobody noticed anything broken.
<xnox> e.g. openSUSE has a rolling factory release, some/most things go directly there, but other groups of strongly connected components are overlays on top of factory, e.g. GNOME:Factory and KDE:Factory. Once api/abi transitions and shaken out, those packages are promoted into Factory.
<xnox> many people enable the overlays they care about.
<xnox> the major difference that their overlays can completly include dependency overlays such that one simply needs to enable GNOME:Factory to get latest gnome packages which are actually spit into further 2 overlays behind that one.
<xnox> quantal... in more ways than in knew it's going to be.
#ubuntu-devel 2013-03-01
<vibhav> God morning
<vibhav> Good*
<smoser> cody-somerville, soren if you're interested, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136781 describes the issue i was seeing.
<ubottu> Launchpad bug 1136781 in linux (Ubuntu) "partx information not cleared on loop device detach" [Undecided,Incomplete]
<psusi> smoser, thanks for subscribing me to the bug report about loop partitions not being cleaned up after detach.. I duped it against the one I filed at the tail end of 2011 with patch attached ;)
<smoser> nice
<smoser> psusi, i jsut committed the 'update' spuport to growpart
<smoser> but now realize it has an issue.
<smoser> sfdisk is annoying.
<smoser> it insists on calling the re-read blockdevice action
<smoser> which fails
<smoser> if there is a mounted partition on the block device
<smoser> psusi, can you think of anything clever that i can do to avoid that ?
<smoser> outside of patching sfdisk to actually not invoke the reread ?
<psusi> smoser, and growpart runs sfdisk to make the change?  can't you just ignore that error and then run kpartx -u or invoke the ioctl directly?
<smoser> well, i can't just ignore the error, becauase i can't differenciate the error from any other.
<psusi> smoser, you could use parted instead and it will take care of both steps ;)
<smoser> this is true.
<smoser> funny, sfdisk actually has a '--no-reread' flag.
<psusi> https://code.launchpad.net/~psusi/ubuntu/raring/parted/resize
<smoser> which, one might think would say "do not issue re-read"
<smoser> but it doesn't mean that.
<smoser> it only means "dont issue it before re-writing partition table as a safety check"
<psusi> build/install that ( build copy in my ppa ) and you can just parted /dev/sda resizepart 1 100%
<smoser> that is pretty nice..
<smoser> that is really nice, psusi
<psusi> you think that's nice, you should play with my patches for gparted to do online expand and shrink ( shrink on btrfs only )
<psusi> grab root partition, make bigger.. make smaller... apply, done..
<psusi> I was using parted this week to resize my partitions on my server that were components of a raid5 array to shrink them down, use the new space to make partitions and build them into a raid0 array, all without rebooting with root on lvm on the original raid5
<smoser> psusi, can i use parted command line to do what i want ?
<smoser> (without your patches)
<psusi> smoser, need my patches
<smoser> ie, can i have it just write the partition table the way i want it to
<smoser> all i need it to do is write the table
<smoser> and *not* call 'reread'
<psusi> you could make it write a new table without my patches, but you would have to explicitly rm the existing partition, then create a new one, then ignore the error syncing the table
<psusi> which means grepping for that specific message in the output and choosing to ignore it
<smoser> :-(
<psusi> so, better to just use my patches ;)
<psusi> much easier to just say parted /dev/sda resize 1 100% and be done with it
<psusi> err, resizepart, not resize
<psusi> ( the old resize command also tries to resize the fs, which won't work and has been removed )
<smoser> right.
<smoser> whats the situation with your patches?
<psusi> so you just do the resizepart, it fixes the partition table, fixes the in kernel partition table, then you run resize2fs and you're all set
<smoser> you've submitted upstream, but they're not accepted because its languished at the moment?
<smoser> i'm just afraid of pulling code that isn't upstream.
<psusi> the situation is that parted is in a bit of limbo atm... the old maintainer has left redhat and no longer seems to have time to work on it.. he appointed me and another as co-maintainers... my patches have been sitting in limbo thus far... at some point I'm going to have to give up on waiting and push them and make a new release if the original maintainer and my new fellow co-maintainer don't have time
<smoser> hmm..
<psusi> my patches were initially based on some rough work by peter uzel who I have been hoping will find the time to review my improvements, add a bit better commentary to his original patches that I started with, add a few more test cases, and then we could move forward
<pitti> Good morning
<smoser> you have an ubuntu bug for this?
<psusi> the original maintainer asked him to be a third co-maintainer but he said he didn't have time for that responsibility
<psusi> a bug for which part exactly? ;)
<psusi> pitti, morning Martin
<psusi> smoser, so far the only concern raised since posting the original patch set to the parted mailing list way back when has been resolve... that was that originally the new command was resize, which is the same command that used to also resize the filesystem contained within the partition, so I changed the new command to resizepart to avoid the conflict
<smoser> psusi, just a "please pull this patch" bug.
<smoser> right. i remember that.
<psusi> in the upstream patches, I also added a "resize" command that yells at you for trying to use a removed command and exits with failure to catch scripts using the old command... when I backported it to Ubuntu, our old parted still has the original resize command so I left that part out
<psusi> of course, our old resize command basically doesn't work worth a damn, which is why it was removed upstream
<psusi> which is a shame, and something I hope to fix at some point....
<smoser> psusi, is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/899717 fixed upstream?
<ubottu> Launchpad bug 899717 in linux (Ubuntu) "[PATCH] Loopback device partition cleanup on detach" [Medium,Triaged]
<psusi> smoser, afaik, it never got applied upstream... I'll have to repost it
<smoser> well, psusi i'm sure i've lost some of your respect.
<smoser> http://bazaar.launchpad.net/~cloud-utils-dev/cloud-utils/trunk/revision/219
<psusi> I can't believe it's been that long... time  flies when you have a newborn
<smoser> that seems reasonable as a "we'll do this right with parted at some point"
<psusi> now 1 year old today... sheesh...
<smoser> well happy birthday.
<psusi> well, yesterday I guess since it's after midnight
<psusi> happy march 1st
<psusi> smoser, yea, you can either detect the sfdisk error from trying to BLKRRPART and run partx -u, or instead you can just apply my parted patches, and run parted /dev/sda resizepart 1 100% instead
<psusi> or /dev/xvda for xen
<pitti> am I the only one who cannot see https://blueprints.launchpad.net/ubuntu/+spec/release-r-monthly-snapshots ?
<pitti> it keeps coming up in the u-devel@ thread, but nobody except me seems to complain
<psusi> pitti, gives me the lost something page
<pitti> ok, thanks for confirming
<pitti> I was just wondering as at least wendar and ScottK seem to be able to see it
<ScottK> pitti: I can't see it now.  I could before.
<wendar> pitti: gone for me too
<wendar> pitti: though I still have it open in another tab
<pitti> thanks for confirming
<psusi> ok, wife says it's time for bed.. night all
<pitti> night psusi
<ScottK> So if this whole process had been a model of transparency, I'd probably credit it to an LP glitch.
<micahg> maybe someone got mad since I added a comment to the whiteboard :-/
<micahg> slangasek: ^^ know anything about the blueprint disappearing?
<pitti> or maybe it got renamed?
<pitti> hm no, still first result on https://launchpad.net/+search?field.text=monthly+snapshots
<pitti> curious that I can see it in the search results, but not the page itself
<pitti> ScottK: well, I certainly hope it wasn't deliberate to hide the page now
<pitti> with Rick's discussion kick-off this wouldn't make any sense
<ScottK> People sometimes make poor choices under stress.
<ScottK> No idea really.
<micahg> slangasek: nevermind
<micahg> blueprint here: https://blueprints.launchpad.net/ubuntu/+spec/client-1303-monthly-snapshots
 * micahg hugs wgrant for finding it
<wgrant> (I found it by searching for 'rolling' on https://blueprints.launchpad.net/ubuntu, which unlike the global search page doesn't rely on Google to have updated its index)
<micahg> right, I was thinking to do that, but it's late here :)
<ScottK> So is the secret sauce for spec naming public?
 * micahg would think track-UDS_Code-Name_Goes_Here
<wgrant> That seems to be it.
<ScottK> What does client mean as a track?
<ScottK> Is there a list of tracks?
<micahg> ScottK: http://summit.ubuntu.com/uds-1303/
<ScottK> So "Ubuntu" is now reduced to "Client" at an Ubuntu Developer Summit.
<wgrant> I would guess client == the old desktop track + mobile and tablet
<wgrant> Hence the lack of a desktop track.
<ScottK> And platform
<ScottK> Ah, I see it's downgrades all around.  No sabdfl for the intro either.
<pitti> TBH I'm still rather sceptical about hangouts
<pitti> their limit to 10 people and its rather bad audio quality don't seem to make it a first choice for a virtual summit
<pitti> the live on-air videos work really great, but don't allow participating
<wgrant> The plugin also has a bad habit of hanging any browser I throw at it :)
<pitti> but I guess we have to try with something and then see how it goes
<pitti> I yet have to find something which scales as well and is as robust as mumble
<micahg> why can't we use mumble?
<pitti> so https://blueprints.launchpad.net/ubuntu/+spec/client-1303-monthly-snapshots is the "monthly" thing, do we have a spec for "rolling release" where we can bring up things like library transitions, ARM PPA builders, and the like?
<pitti> micahg: I guess we could; I just seem to remember having heard "hangout"
<micahg> well, Canonical folk seem to be keen on hangouts, but 10 people at a time seems to be quite limiting
<pitti> video is nice
<micahg> sure, but personally, I'd rather have 100 people on audio and have people raising their "hands" in an IRC channel than video limited to 10 people
<pitti> so audio-only in mumble would make the experience even worse (compared to IRL) than with hangout, but that won't help much if most of the listeners can't talk/show up at all
<pitti> *nod*
 * tumbleweed *really* dislikes that use of the word client
<czajkowski> ScottK: naming for the blurptints is on the wiki. https://wiki.ubuntu.com/UDS/Create#Filling_Out_the_Blueprint_Fields
<czajkowski> Laney: am still getting promted for partial upgrades again today.
<Whoopie> arges: Hi, regarding bug 1074923, my debdiff also included a cleanup of the debian-changes which were maybe done unintended. Could you have a look again? Thanks!
<ubottu> bug 1074923 in iptables (Ubuntu Quantal) "iptables-save doesn't write --hex-string pattern correctly" [Medium,In progress] https://launchpad.net/bugs/1074923
<geser> does somebody know where https://blueprints.launchpad.net/ubuntu/+spec/release-r-monthly-snapshots moved too? I get a 404
<pitti> geser: https://blueprints.launchpad.net/ubuntu/+spec/client-1303-monthly-snapshots
<geser> thanks
<mitya57> geser: https://blueprints.launchpad.net/ubuntu/+spec/client-1303-monthly-snapshots
<Laney> czajkowski: you said it worked yesterday?
<zequence> I'm not considered a developer on the ubuntu-devel list. Is that a strict category? I'm a developer for Ubuntu Studio, but not a "Ubuntu Developer"
<zequence> I'm referring to the list being moderated
<zequence> cjwatson: You're the list admin, right?
<maxb> zequence: My guess would be "someone who has upload rights to at least one package"
<maxb> But that's just a guess
<cjwatson> zequence: The category is "member of the ~ubuntu-dev team"
<cjwatson> (Plus case-by-case whitelisting)
<cjwatson> I've accepted your post in any case
<zequence> cjwatson: Thanks
 * mpt is disappointed to discover that en-GB doesn't translate "Display every two weeks" as "Display fortnightly"
<pitti> mpt: I guess its LC_TIME also doesn't display 16:00 as "teatime"?
<xnox> pitti: yeah and 11am as elevenses speaking of which.
 * xnox goes to make tea.
<xnox> mpt: which package?
<xnox> mpt: seems like a bug cause it's "Every fortnight" for one string but not the other.
<xnox> fixed, should be part of next lang-pack update.
<Laney> see how fast we are to fix critical bugs?
<xnox> I'm sure some people will find controversial for eastern european translating software into English GB locale. Something to do with taking away jobs from british or the like.
 * xnox likes the fact that en_gb translation team is an open one.
<Laney> that's what we're like over here
<mpt> haha
<mpt> xnox, and now we've got you suckered in to hacking software-properties-gtk, we'll get you to port it to a gnome-control-center panel
<mpt> You know, just while you're there.
<mlankhorst> Wait why does it need british translations?
<mpt> Because America and Britain are divided by a common language
<xnox> mpt: I totally did in launchpad with no source code branches locally =))))
<highvoltage> Amerian English is the most different English though, most of the English in the rest of the world is pretty similar.
<mpt> Be that as it may, Ubuntu is translated out of American English into other languages and variants, including en_CA, en_GB, en_AU, and even en_NZ.
<Riddell> ogra_: any ideas on why this nexus won't talk to a computer any more?  plugging in usb all I get is this in syslog "unable to enumerate USB device on port 2" http://paste.kde.org/684758/
<ogra_> Riddell, is it charged ? the n7 HW behaves very odd on low battery
<Riddell> ogra_: maybe not, should I just leave it plugged in and hope it fixes itself?
<ogra_> you need to charge it ewith the wall charger, an USB port of the PC only provides 500ma, thats about as much as the device actually usue when on
<ogra_> the charger should provide something like 2A or above
<Riddell> oh that might explain it, how unintuitive
<ogra_> well, its fine if you have a desktop running that properly tells you the battery is low :)
<ogra_> fi you dont have any measure because working on cmdline all the time or flashing over and over, it will fall over
<davmor2> Riddell, ogra_: it will charge from the pc but an entire day gives you about 37% battery charge iirc,  from the wall will do it in about 1hour or so
<ogra_> right, and if it runs while you charge it largely eats all that comes from the PC
<ogra_> i would be surprised if more than 100mA get into the battery
<cjwatson> bdmurray: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-r-tracking-bug-tasks.html seems to have lost its mind^Wteam mapping
<xnox> jodh: it's not like infinity and I compete on a number of badges, but it is one he doesn't have yet ;-)
 * Laney blinks xnox 
 * xnox Upstart Developers, Joined 17 minutes ago
<Laney> very fancy
<jodh> xnox: :-)
<seb128> xnox, hum, can we trick you in doing extra desktop work if there is a chance to get a nice badge for it? :p
<xnox> seb128: maybe...
<seb128> ;-)
<seb128> Laney, quick, find some work for xnox!
 * xnox finds no artistic value in a haskell badge, just saying.
<ogra_> seb128, a badge and a virtual beer at the virtual UDS
<ogra_> vitually ...
<jpds> ogra_: Nothing like that virtual German beer.
<ogra_> ++
<xnox> carlsberg probably the best virtual beer in the world
<ogra_> lol
<cjwatson> Better than actually drinking it for real
 * xnox doesn't like beer anyway and not many places have cider outside of the Isles.
<pitti> cjwatson: objection!
<cjwatson> pitti: I'm sure we can find some common ground, just not with Carlsberg :)
<xnox> pitti: you can raise that objection... virtually  =)))))
<pitti> cjwatson: ah, that I can agree with :) I thought you meant beer in general
<cjwatson> Oh, goodness me no
<pitti> . o O { merci dieu c'est vendredi }
<Nafallo> sooo. people will stop owe each other beers now? :-)
<xnox> Nafallo: offlicense stores in UK accept orders over the internet with home delivery.
<pitti> I tried pouring some into a hangout, but it didn't go well
<pitti> even though I served it on a tablet!
<ogra_> you didnt use the Gfunnel then
<ogra_> only works with google provided devices :)
<xnox> pitti: did it come with phablets as little salty snacks to go with beer?
<jbicha> xnox: here have a badge: https://launchpad.net/~desktop-bugs
<Nafallo> xnox: truth... but that would totally exclude Swedish people
<pitti> xnox: that might have been the problem
<geser> xnox: drinking virtual beer during a virtual UDS?
<xnox> virtually yes
<sladen> that's virtually a joke
<tvoss> czajkowski, ping
<bdcomp> Hi, I am trying to backport LibreOffice 4.0.1 to Precise and got this error "ERROR: error 512 occurred while making /build/buildd/libreoffice-4.0.1~rc1/tail_build/prj"
<bdcomp> Any hints what is the issue?
<bdcomp> The last output before the error is "[build LNK] Executable/idlc make[4]: *** No rule to make target `/build/buildd/libreoffice-4.0.1~rc1/src/0168229624cfac409e766913506961a8-ucpp-1.3.2.tar.gz', needed by `/build/buildd/libreoffice-4.0.1~rc1/workdir/unxlngi6.pro/UnpackedTarget/0168229624cfac409e766913506961a8-ucpp-1.3.2.tar.gz'.  Stop."
<dholbach> cjwatson, pitti, soren, stgraber, kees, mdz: can one of you add me to ~uds-organizers? I'm going to be track lead together with Jono for the community track - cjohnston made the other necessary changes in summit already
<stgraber> dholbach: doing that now
<dholbach> thanks stgraber
<stgraber> dholbach: done
<dholbach> thanks a bunch
<BenC> what's the URL for rootfs tar balls?
<cjohnston> zyga: ping
<BenC> Nm, found it
<zyga> cjohnston: hey
<cjohnston> zyga: your blueprints don't follow the correct naming convention, and more than likely won't get scheduled unless they are fixed.
<zyga> cjohnston: where is the naming convention announced?
<zyga> cjohnston: and is renaming them the only required thing?
<cjohnston> https://wiki.ubuntu.com/UDS/Create   the naming convention is the same as its always been..   and yes
<cjohnston> jodh: ^
<zyga> cjohnston: the naming convention differs each time as in $CURRENT_PREFIX-$THE_STUFF_I_CARE_ABOUT
<zyga> cjohnston: thanks for the tip though
 * zyga finds it totally silly that this is even important
<zyga> cjohnston: so which should I select, my blueprint fits the first three options (client, servercloud and community)
<cjohnston> <track>-<cycle>-<name>, is how its always been
<zyga> cjohnston: where track and cycle are totally irrelevant (launchpad knows which sprint I target it for) and I only care about name, the rest is arbitrary limitation from the scheduling system.
<zyga> cjohnston: but let's get back to the point
<cjohnston> zyga: that I couldn't tell you.. I would think probably client, but I am not sure..
<zyga> cjohnston: ok, I'll pick client
<cjohnston> your more than welcome to come up with another way for Summit to randomly guess which track it should be for if you don't like the naming convention requirement
<zyga> cjohnston: thanks for the help and don't get my comments personally, I'm just pointing out the absurd abehind some of those choices
<zyga> cjohnston: renamed
<Laney> cjohnston: is http://fridge.ubuntu.com/2013/02/26/ubuntu-developer-summits-now-online-and-every-three-months/ or http://summit.ubuntu.com/ right wrt times?
<cjohnston> I don't know of any other way to make summit guess which track it should be for. And since we use tracks, it has to be assigned to one.
<Laney> I assume the latter
<cjohnston> Laney: 1400-2000
<Laney> rararrhgh
<Laney> who can fix the fridge post?
<cjohnston> I just pinged jono_
<Laney> someone should correct me on -devel :-)
<jono_> the fridge post is updated
<zyga> cjohnston: I guess the trakc is something I could select on the scheduler, the identifier is really an implementation detail but that's just IMHO
<jono_> it was updated a few days ago
<Laney> only the start time
<cjohnston> jono_: "2pm UTC â 10pm UTC"
<jono_> yeah fixing now
<jono_> thanks
<jono_> Laney, fixed
<Laney> merci
<cjwatson> cjohnston: when you say "always" ... :)
<cjohnston> cjwatson: atleast as long as I've been involved in Ubuntu... :-P
<cjwatson> cjohnston: IIRC we started using tracks in spec names for the Natty UDS
<cjohnston> http://summit.ubuntu.com/uds-l/meeting/14749/server-lucid-puppet-etckeeper-integration/  it appears as though 'l' followed it
<mitya57> why do we have two blueprints for the same thing?
<mitya57> https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-logind-migration
<mitya57> https://blueprints.launchpad.net/ubuntu/+spec/client-1303-consolekit-logind-migration
<mitya57> jodh: ^^
<cjohnston> it would appear as such
<jodh> mitya57: the 1st you mention can be deleted - summit failed to show either earlier, but now does :)
<cjohnston> jodh: can you please mark the first one superseeded by the second
<jodh> cjohnston: done. what happened to delete I wonder? :)
<cjohnston> I don't remember there being a deleted
<cjohnston> or delete
<cjohnston> there may have been, I just never used it
<xxiao> on ppc 12.10 when I do: qemu-nbd -c /dev/nbd0 raw.img and always says /build/buildd/qemu-kvm-1.2.0+noroms/nbd.c:nbd_init():L414: Failed setting flags
<xxiao> redo it right way: qemu-nbd -c /dev/nbd0 raw.img  now it says /build/buildd/qemu-kvm-1.2.0+noroms/nbd.c:nbd_init():L382: Failed to set NBD socket
<xxiao> looks like the first command failed meanwhile left nbd0 unusable for later on commands
<xxiao> similar steps on x86 worked well
<sarnold> xxiao: (what was the difference between the wrong-way and the right-way?)
<xxiao> sarnold: sorry, i meant "right away"
<sarnold> xxiao: ah! :D
<sarnold> xxiao: does qemu-nbd by chance create sockets without using the SO_REUSEADDR socket option?
<xxiao> sarnold: don't really know yet
<sarnold> xxiao: in that case you may need to wait a little while for the socket to fall out the CLOSE_WAIT state (iirc)
<xxiao> sarnold: i waited 10 mins and it's the same :(
<xxiao> ioctl32(qemu-nbd:6441): Unknown cmd fd(13) cmd(2000ab0a){t:'\xffffffab';sz:0} arg(0000002d) on /dev/nbd2
<xxiao> that's from dmesg when i do 'qemu-nbd -c /dev/nbd0 raw.img'
<sarnold> xxiao: eek
<xxiao> some ioctl thing?
<xxiao> both have "ii  qemu-utils                         1.2.0+noroms-0ubuntu2.12.10.2                amd64        qemu utilities"
<xxiao> ii  qemu-utils                       1.2.0+noroms-0ubuntu2.12.10.2                powerpc      qemu utilities
<sarnold> xxiao: the error in dmesg seems to tell me something bigger has gone wrong, outside of my experience by a lot... (when I thought it was just tcp, well, that's one thing.. :)
<czajkowski> tvoss: pong
<xxiao> anyone that has ppc machine can do me a favor. on 12.10 run qemu-nbd -c /dev/nbd0 raw.img?
<xxiao> per the suggestion from qemu guys, qemu-nbd 32bit running on 64bit kernel could have strange issues
<xxiao> http://paste.ubuntu.com/5577430/  strace qemu-nbd
<slangasek> xxiao: um, you can't strace sudo and expect it to do anything useful
<xxiao> http://paste.ubuntu.com/5577449/
<xxiao> slangasek: thanks ;)
<xxiao> this time runs with root permission
<xxiao> http://paste.ubuntu.com/5577454/  x86 working version
 * xxiao hopes to see a diff button on paste.ubuntu.com that can diff two pastes
<sarnold> xxiao: heh, the error may be happening on the other side of that clone() call
<sarnold> xxiao: strace -f   :)
<xxiao> http://paste.ubuntu.com/5577466/  strace -f
<sarnold> aha now it got your error, line 676
<xxiao> sarnold: right
<xxiao> ioctl 13 does not know the magic number 0x2000ab0a
<xxiao> seems like hand-coded magic #
<xxiao> that kernel has no idea?
<sarnold> I wonder, 0x20 is space, 0x00 is ascii NUL, 0xab is (nothing, really), 0x0a is a newline ...
<xxiao> kernel/include/linux/nbd.h
<xxiao> did not see that magic # of course
<xxiao> #define NBD_SET_BLKSIZE_IO( 0xab, 1 )
<sarnold> hmm :)
<xxiao> #define NBD_SET_TIMEOUT _IO( 0xab, 9 )
<xxiao> so they just  bypass the define and directly supply the number to kernel
<xxiao> and kernel did not recognize
<xxiao> actually the kernel definition stops at 0xab, 9, so next one is ab0a then
<sarnold> maybe it is in newer kernel sources?
<xxiao> sarnold: checking that...
<xxiao> it is
<xxiao> let me check when it's in
<sarnold> #define NBD_SET_FLAGS   _IO( 0xab, 10)
<xxiao> right, they moved it to uapi/linux/nbd.h
<xxiao> now i have to find out the ioctl call and back-port it...
<xxiao> yes it's in nbd.c, the driver
<zyga> barry: thanks for working on command-not-found
<lool> slangasek: what kind of tests do we run before updating /current in the livefs builds?
<barry> zyga: np
<kees> hallyn: around?
<stgraber> lool: none, /current simply means the build succeeded
<slangasek> lool: none; in the case of livefs builds, if the build succeeds it's "current"
<lool> ok
<toordog> I created my gpg key 2h ago and ran this command : gpg --keyserver keyserver.ubuntu.com --send-keys  I still cannot import my gpg key on launchpad
<toordog> Launchpad could not import your OpenPGP key
<zyga> toordog: you need to pass the ID of the key to export
<zyga> toordog: see man gpg
<zyga> toordog: search for '--send-keys'
<zyga> toordog: you may want to use seahorse, a graphical wrapper around gpg instead
<toordog> i use console only
<zyga> toordog: then send the key you created and launchpad will be able to import it soon thereafter
<sarnold> toordog: what key did you send? can you see it on any other other keyservers yet? https://sks-keyservers.net/status/
<toordog> ok, i think it's going to work, i didn't put the ID.
<hallyn> kees: what's up?
<xxiao> strange with a new kernel that built with that ioctl i'mstill getting the same error
<xxiao> #define NBD_SET_FLAGS   _IO( 0xab, 10)
<xxiao> #define NBD_SET_FLAGS   _IO( 0xab, 10)
<xxiao>  #define NBD_SET_FLAGS   _IO( 0xab, 10)
<xxiao> in ubuntu's qemu-utils, qemu-kvm-1.2.0+noroms/nbd.c
<xxiao> if (ioctl(fd, NBD_SET_FLAGS, flags) < 0
<xxiao> failed, other similar code are shown like
<xxiao> ioctl(13, NBD_SET_SOCK, 0xa) = 0
<xxiao> why the failing line shown as ioctl(13, 0x2000ab0a, 0x2d) = -1 EINVAL (Invalid argument)
<xxiao> not sure when the 0x2000ab0a happened, that does not happen to other args
<xxiao> wierd
<xxiao> I would expect it's something like ioctl(13, NBD_SET_FLAGS,0xa) = -1 EINVAL (Invalid argument)
<xxiao> search ubuntu source code found no such hex either, all are using NBD_SET_FLAGS instead, how could this happen?
<xxiao> case NBD_SET_FLAGS: lo->flags = arg;
<xxiao> the kernel just sets a flag, that's it, easy to back port
<xxiao> case NBD_SET_FLAGS:
<xxiao> lo->flags = arg; return 0;
<jcastro> slangasek: hey so I'm watching the video you guys had ... how do I explain to normal people what britney is
<slangasek> oh man
<slangasek> jcastro: I'm sure there are some suitable results if you search for 'britney' on youtube
<stgraber> do "normal people" need to know what britney is? :)
<jcastro> stgraber: no, they don't need to know, but it helps people understand when you say "oh don't worry britney will handle that for us..." or whatever
<slangasek> jcastro: "the software that makes sure packages are built on all architectures and don't cause installability problems before we push them out for the whole world to see"?
<barry> jcastro: there's something on youtube about britney???
<jcastro> slangasek: good enough.
<jcastro> barry: yeah, but they're not very good. :p
<jcastro> slangasek: so also the thing that makes sure when I dist-upgrade that half my desktop doesn't get removed?
<jcastro> like the old sid days
<slangasek> it doesn't guarantee that at all ;)
<stgraber> barry: actually: http://www.youtube.com/watch?v=3ctC4VQVh-Q appears to be relevant for the Debian implementation
<jcastro> that's another woman's name isn't it.
<slangasek> jcastro: nope, there's just nothing that guarantees you won't still hit such a problem... there are plenty of client-side bugs, or confusing local packages, that could still cause that
<kees> hallyn: hi! I've been playing with user namespaces, and I was trying to figure out how to actually gain capabilities in them.
<kees> hallyn: from what i can tell, it requires a uid mapping be in place, but that requires having had CAP_SETUID at some point.
<hallyn> kees: yes, hence setuid-root binary to set up mappings.  did you see eric's shadow patchset?
<hallyn> see lp:/~serge-hallyn/ubuntu/raring/shadow/shadow-userns/
<hallyn> that is, lp:~serge-hallyn/ubuntu/raring/shadow/shadow-userns/
<hallyn> i need to push that set, soon.
<kees> ah, hm
<hallyn> kees: if you could review that set too that'd be helpful for dure :)
<hallyn> sure
<kees> hallyn: yeah, reading now...
<hallyn> (also see Pkg-shadow-devel@lists.alioth.debian.org m-l)
<kees> hallyn: is there any overview anywhere for what the "expected" behavior should look like?
<kees> hallyn: hrm, it looks like "newuidmap" is called by... the parent?
<hallyn> kees: overviews in several places - man page updates (from eric), s3hh.wordpress.com, lwn.net user_namespace summary (this week)
<hallyn> kees: without privilege you should be able to (i *think*) just map uid 0 in the container to your unpriv userid on the host
<hallyn> (range of 1)
<kees> hallyn: oh?
<hallyn> but indeed, ISTR you may end up without privileges - need to straighten that out with eric one day if that's the case
 * hallyn goes to reread emails
<kees>         /* Require the appropriate privilege CAP_SETUID or CAP_SETGID
<kees>          * over the user namespace in order to set the id mapping.
<kees>          */
<kees>         if (cap_valid(cap_setid) && !ns_capable(ns, cap_setid))
<kees>                 goto out;
<kees> that's what I see at the top of map_write() handling the uidmap file writes
<hallyn> yup, ok, so nm
<hallyn> guess i was wrong :)
<hallyn> offhand it seems like it would be a safe and useful thing to allow
<hallyn> but we're not exactly looking to live on the edge here :)
<hallyn> and if shadow will auto-generate subuid ranges for all users, then it becomes moot pretty much
<kees> I don't see how to call newuidmap, though. I guess from the parent.
<hallyn> kees: you're talkinga bout the program?
<hallyn> sorry, i've not really *used* eric's tools much...  but yes, from the parent, or anyone in the parent ns
<kees> yeah, something needs to call newuidmap. right now, a process will perform the clone(CLONE_NEWUSER); wait().
<hallyn> kees: you can look at lxc for an example :0  it does it by hand...
<kees> I love that user ns isn't available if you build NFS. ;)
<slangasek> eew what?
<hallyn> kees: which source are you using
<kees> 3.8
<kees> config USER_NS
<kees>         depends on UIDGID_CONVERTED
<kees> config UIDGID_CONVERTED
<kees>         default y
<kees>         depends on NFS_FS = n
<hallyn> kees: yeah 3.8 is not complete
<kees> yup
<hallyn> there's a kernel at https://launchpad.net/~ubuntu-lxc/+archive/kernel you can use,
<hallyn> or grab eric's sources from kernel.org
<kees> I'm cool; I'm just playing with this under kvm.
<hallyn> it should all go into 3.9 though
<hallyn> well you're missing other things,
<kees> took me a while to figure out why clone() kept failing, though :)
<hallyn> but ok :)
<kees> hallyn: I take it the default is to not create any subxid mappings?
<hallyn> kees: hm, i'm not sure.
<hallyn> it *really* is meant to be safe to allocate them by default
<kees> ... :)
<hallyn> but yeah, i suspect
<kees> is there any ETA for the userns patch series landing in raring?
<hallyn> kees: it'll go in with 3.9.  in other words, not into raring
<kees> okay
<hallyn> that's why i finally put up the ubuntu-lxc/kernel ppa :(
<hallyn> (before that i just pointed to my personal ppa)
<kees> this build behavior means that 3.8 actually regresses for anyone that _was_ using CLONE_NEWUSER ...
<stgraber> was anyone actually using CLONE_NEWUSER?
<kees> no idea! :) I doubt it.
<hallyn> kees: we went to great lengths to warn people, over a period of years
<kees> hallyn: hehe
<hallyn> some ppl may ahve used it for separating peruser quotas at one point, but i think 2008 or 2009 was when i warned ppl first
<hallyn> kees: let me know how it goes!  ttyl
<kees> hallyn: thank, I'll Cc you on this (weak) vulnerability report...
<hallyn> d'oh.  thanks :)
<stgraber> hallyn: what did you expect, you're talking with kees ;)
<kees> hehe
<kees> stgraber: so, where does lxc do the uid mapping? I don't see anything in 0.9.0~alpha3-0ubuntu2
<hallyn> kees: see src/lxc/conf.c:add_id_mapping
<kees> hallyn: ha ha, grep failed ... %cid_map ;)
<hallyn> yeah :)  i almost feel bad about that
<hallyn> :)
<kees> ... %s", idtype == ID_TYPE_UID ? "uid_map" : "gid_map") ...  ?  :)
<cjwatson> jcastro: This is why I always call it "proposed-migration" (which is actually the directory under which our installation runs), not "britney"
<cjwatson> jcastro: It does make it much less *likely* that half your desktop will get removed on upgrade - and especially it insulates us against *most* multiarch library-sync problems, which are incredibly confusing for normal people to resolve
<cjwatson> well, s/especially/also/
<kees> hallyn: actually, you need to check the return code of fclose() too.
#ubuntu-devel 2013-03-02
<xxiao> why is package rebuild giving me permission errors?
<xxiao> http://paste.ubuntu.com/5577868/
<xxiao> dpkg-source -x qemu-kvm_1.2.0+noroms-0ubuntu2.12.10.2.dsc  gave me same errors, permission denied
<sarnold> xxiao: any change if you leave off the 'fakeroot'?
<xxiao> sarnold: dpkg-buildpackage -rfakeroot -b messed it up
<xxiao> rebuilding qemu-nbd and see if that helps
<xxiao> how do I pass -j12 to apt-get -b?
<sarnold> xxiao: try DEB_BUILD_OPTIONS=-j12
<slangasek> sarnold: DEB_BUILD_OPTIONS=parallel=12
<slangasek> $DEB_BUILD_OPTIONS is keyword-based
<sarnold> slangasek: ah! thanks :D
<hallyn> kees: I assume you mean at add_id_mapping, to check for delayed write errors?
<hallyn> not sure the id_mapping file would do that, though, in this case.  (haven't checked)
<xxiao> is it ok to disable beam.smp. the cpu sucker?
<xxiao> is  ubuntu-12.10-server-powerpc.iso 32 or 64 bit?
<xxiao> i mean the filesystem
<xxiao> i'm having trouble with 64bit kernel / 32bit ubuntu 12.10 on ppc
<xxiao> guess it's 32bit, as it's not named ubuntu-12.10-server-powerpc64.iso, the 'server' lable confuses me...
<xxiao> my issue is that 32bit qemu-nbd dislikes 32bit filesystem
<xxiao> while runnning a 64bit kernel
<cjwatson> xxiao: 32-bit userspace, indeed
<jtaylor> are old daily builds of compiz somewhere?
<jtaylor> looks like the one from feb 26 broke java apps
<vibhav> 21:20 < KHendrik> did I seriously just brick two phones ...
<vibhav> Oops, wrong window
<ejat> anyone can verify this : http://paste.ubuntu.com/5579567/
<kees> hallyn: yup, and it does.
<kees> i noticed while trying to write without cap_setuid
<IDWMaster> How do I recommend a package (library) for inclusion in one of the Ubuntu repositories?
<mlankhorst> best would be to get it in debian first, then request inclusion for ubuntu
<IDWMaster> So I should probably dual-boot a Debian installation?
<IDWMaster> Or is there a better way
<IDWMaster> Why Debian first?
<slangasek> Ubuntu derives most of its packages from Debian, and getting it into Debian usually provides for more sustainable maintenance over the long term
<slangasek> and if it's in Debian, more people benefit from the package's availability - Ubuntu users, but also Debian users
<slangasek> but there's no need to dual-boot to get a package into Debian; you can do most development work in a chroot
<slangasek> (or VM)
<IDWMaster> OK
<IDWMaster> So pbuilder would be a good tool for this
<slangasek> https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers
<runeks> anyone know why gdb is not loading symbols from files placed in /usr/lib/debug/usr/lib/x86_64-linux-gnu/ ?
<runeks> installed via the freerdp-dbg package
<chilicuil> NCommander: hi there, sorry to bother, I was wondering if you could be able to help with bug #1113648
<ubottu> bug 1113648 in nautilus (Ubuntu) "Add a context menu entry to create a new blank file" [Undecided,Confirmed] https://launchpad.net/bugs/1113648
<Maccer> Anyone know where I can look up the maintainer for a certain package or what guidelines I need to follow so I can take over? There's a package here that hasn't been updated in quite a bit even though both there is a higher stable and unstable version. (It's an audio player)
<penguin42> Maccer: apt-cache show   will show you the maintainers
<Maccer> I found out through launchpad, but apparently the Debian Multimedia Maintainers group maintains this package... hrm.
<penguin42> ah, I think they have a mailing list
<Maccer> But it looks like they maintain the unstable version if it. Yeah they do. Is there a way to add their unstable repository or can I only get their files through a .deb package?
<penguin42> Maccer: does packages.debian.org show a newer version ?
<Maccer> Using debian unstable (sid), it shows 3.2.4 for the i386/i686/amd64 version, and I have 3.2.3, and I'm using a non-LTS Ubuntu 12.10
<penguin42> Maccer: What does packages.ubuntu.org say ?
<Maccer> What surprises though is why they don't upgrade Quantal (12.10?) to 3.3.4. It's a media player.
<penguin42> Maccer: It's probably just not happened in time; if it's in debian sid it'll probably make it into Raring (depending when it landed)
<Maccer> penguin42: http://i.imgur.com/biwF6c9.png
<penguin42> erm what's that got to do with anything?
<Maccer> That's packages.ubuntu.org.
<Maccer> I have no idea why that's displaying.
<penguin42> oops - .com!
<Maccer> For a second there I thought my DNS server was hijacked. Seems like they rewrite the URL so as to make it work with the subdomain.
 * xnox ponders how does doko make source packages with @ubuntu.com without updating Maintainer fields to say Ubuntu Developers, and whether that's bad or just ugly.
<Maccer> Seems like quantal is 3.2.3. Yeah but this is odd because 3.2.4 came out more than 4 months ago I believe.
<Maccer> Plus I'd expect the unstable version 3.3.x to be on Quantal.
<penguin42> Maccer: That's not how it works
<penguin42> Maccer: So quantal came out in October, and it's version won't be updated
<penguin42> Maccer: Quantal will have taken the 'current' debian version a month or so before that, probably around August-September
<Maccer> Mh, so what are the release cycles for ubuntu then? It's just like debian but more frequently updated? I thought that was LTS.
<penguin42> Maccer: Every 6 months and there's a timetable soemwhere where you can see when the sync's happen
<penguin42> Maccer: There's talk of moving to a rolling release; the details I don't know
<Maccer> Ah, that's a shame. Has there been a release model in linux distributions that's a hybrid bleeding edge or rolling?
<penguin42> Maccer: https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule  so the sync from Debian happened in Feb
<Maccer> Stable libraries and core libraries, but unstable things like music players.
<xnox> Maccer: apart from at the moment we are actively discussing on ubuntu-devel to turn raring into a rolling release.
#ubuntu-devel 2013-03-03
<Maccer> I feel dirty for upgrading to raring. Oh well it's only xubuntu.
<penguin42> hey raring is ok
<Maccer> 1.2GB upgrade. Must have changed a lot. And probably some of my PPA-derived software probably was downgraded/upgraded.
<Maccer> Am I redownloading everything or something? I already have firefox 19.0.
<xnox> Maccer: do you have firefox 19 build against quantal libraries, or against raring libraries?!
<xnox> each release gets its own firefox.....
<xnox> apart from like first couple of week of the new release.
<Maccer> I can't check at the moment, I just caught a glimpse. I was surprised the libraries weren't backwards compatible or something like that.
<hallyn> kees: jinkeys, that's unkind (delaying error) - thanks :)
<mether> is there a way to get the split out patches from http://packages.ubuntu.com/source/raring/subtitleripper
<mether> this diff http://archive.ubuntu.com/ubuntu/pool/multiverse/s/subtitleripper/subtitleripper_0.3.4-0.5ubuntu2.diff.gz seems to have all the patches together
<geofft> mether: there are three patches in debian/patches in that diff
<geofft> mether: i.e., that (top-level) diff creates three patch files.
<geofft> mether: if you extract the source package (`apt-get source subtitleripper`, or dget the .dsc and then dpkg-source -x), it'll be easier
<mether> geofft,  thanks but i am not running ubuntu/debian now. is there an alternative way?
<Chipzz> mether: yes
<mether> Chipzz, can you elaborate?
<Chipzz> mether: get the .tar.(gz|bz2), extract, get the .diff.gz, patch the extracted directory
<geofft> mether: sure, download the .orig.tar.gz and .diff.gz, untar the former, unzip the latter | patch -p1 or something
<mether> ok. thanks!
<Chipzz> (sorry, on a crappy connection, serious lag on my ssh connection)
<geofft> mether: dpkg-dev also may or may not exist on your distro, if you're on non-Ubuntu Linux
<mether> geofft, in fact, i do seem to have it.  i will take a look
<mether> Chipzz, geofft, got it.  thanks again
<mitya57> Mirv: hi, here?
<dirtyfreebooter> I am building a custom kernel via make-kpkg but my symlinks in /lib/modules/*/build are never correct on the installed system, they always point to build directory on the system I built the kernel on
<dirtyfreebooter> and I noticed the postinst/preinst/etc scripts from /usr/share/kernel-package are different then the ones inside the official ubuntu kernel packages
<dirtyfreebooter> is there any recommended approach here when building a custom kernel to get those symlinks correct ? its cause dkms to hate me
<dirtyfreebooter> i've also tried different options in /etc/kernel-img.conf, but it doesn't seem to matter
<Chipzz> dirtyfreebooter: I doubt this qualifies as the right channel for your questions. Your questions are support questions, this channel is for the development OF ubuntu only.
<penguin42> dirtyfreebooter: Perhaps #ubuntu-kernel ?
<Chipzz> and what penguin42 said
<dirtyfreebooter> k, thanks
<Chipzz> dirtyfreebooter: as an aside, I don't think make-kpkg is a supprted way of building kernels
<dirtyfreebooter> ok, that is strange, as multiple pages on ubuntu.com show make-kpkg as the way to build ubuntu kernel from ubuntu git repo.. I'll ask in #ubuntu-kernel though. thanks
<Chipzz> I *think* the correct way of doing things is apt-get source linux-... and rebuilding that
<Chipzz> correct as in: officially supported
<Chipzz> although I must say the whole situation *IS* confusing
<TheMuso> c
<melodie> hello
<melodie> sorry
<melodie> I would like to ask this one question : I work on both Ubuntu box and Debian box, and I was seeking for a "language-selector-gnome" package at Debian when I realized it's an Ubuntu only package. How come is that ? Aren't programs supposed to be packaged at Debian before being brought to Ubuntu ? and aren't Ubuntu packages supposed to be also available at Debian ?
<sarnold> melodie: see e.g. unity for another counter-example :)
<melodie> sarnold could you explain to the non English native I am ?
<melodie> do you mean:
<melodie> Unity is not available at Debian either ?
<sarnold> melodie: correct
<melodie> ok, but that is a very special desktop environment, whereas having an easy tool to switch language can be more than handy : a matter of being able to use a distro, a spin, whatever ?
<sarnold> (I _am_ a little surprised about it, I expected someone would have packaged it for debian.. but it doesn't happen on at least one "core" ubuntu package...)
<melodie> :s
<melodie> do you know of a chan where Debian developers/packagers go preferably ?
<sarnold> melodie: hrm. I thought dpkg-reconfigure locales   was supposed to provide a nice interface for changing the system-wide locales, but that just rebuilt the locales :/
<melodie> I would like to ask them the same question
<melodie> configuring the language in Debian is a pain in the bottom
<melodie> here my testimonial: Scorpio RC4 - obsession - languages - http://beta.linuxvillage.net/index.php/topic,171.0.html
<jbicha> melodie: http://wiki.debian.org/IRC/
<melodie> I had reconfigured the install completely, and the apps get back to English for at any time, after an update, and such
<melodie> jbicha thank you!
<sarnold> melodie: heh, /list #debian-* scrolled outside of my scrollback on OFTC. I'd try just #debian on irc.oftc.net first...
<melodie> I am not sure... some there just yell about "frankendebian" spins. :-(
<sarnold> heh, that's not very helpful :(
<melodie> not helpful, and not polite.
<sarnold> melodie: are you confident your application is supposed to have up-to-date french translations?
<melodie> I happened to ask something about hem, antiX once, that's how I was welcome.
<sarnold> melodie: maybe #debian-fr would be nicer?
<sarnold> it is smaller, anyway, that sometimes leads to more polite.
<melodie> well, confident yes, because I have the same in Archlinux and because when I reinstall the app after checking all configs, it's in French again.
<melodie> sarnold this is a good idea. thank you
<melodie> I'll add it to my favorites and go tomorrow as it begins to be really late here now
<sarnold> melodie: I would expect the application to check your LC_* and LANG environment variables and select the language to show right then and there -- does your locale environment variables change away from french?
<sarnold> ah, yes, so it is. :) better luck on monday vs sunday, too...
<melodie> no, locale is fr-FR_UTF8
<melodie> yes, that's right
<jbicha> I believe language-selector-gnome is designed around Ubuntu's language packs which aren't used by most other distros
<melodie> jbicha possible - well another example,
<melodie> software center is Ubuntu made, but is available at Debian too
<melodie> I'll look for some package from Semplice if none is available specifically for Debian
<melodie> I heard about a tool
<melodie> thanks a lot. :)
<sarnold> have fun :)
<melodie> I guess we do; at linuxvillage we make spins of Debian and Ubuntu to create ready to use versions with Openbox and not much more around. we like to go light, but easy to use. :)
<Chipzz> melodie: #debian-devel on irc.debian.org iirc
#ubuntu-devel 2014-02-24
<Noskcaj> Is anyone able to sponsor a few things for xubuntu?
<Noskcaj> bug 1282734 and bug 1282937
<ubottu> bug 1282734 in xubuntu-artwork (Ubuntu) "Please update xubuntu-artwork" [Wishlist,In progress] https://launchpad.net/bugs/1282734
<ubottu> bug 1282937 in xfburn (Ubuntu) "Please package xfburn 0.5.0" [Undecided,In progress] https://launchpad.net/bugs/1282937
<LinuxPC> xnox????
<infinity> LinuxPC: It's 1:20am Monday morning for xnox, there's a fair chance he's not around.
<LinuxPC> oh, ok, I didn't know what time it is where he is.
<infinity> LinuxPC: London.
<jtaylor> infinity: can you build glibc without optimizations?
<jtaylor> I tried just replacing O2 with O0 and it complained cannot build without optimizations
<infinity> jtaylor: Dunno, never tried.  It could be a mismatch of -O and -DFORTIFY that's tripping you up.
<jtaylor> it was an actual error message telling me I need to optimize
<jtaylor> but I wonder how do you debug it properly then
<infinity> jtaylor: Right, but what was the error message?  -DFORTIFY_SOURCE will yell at you at -O0, I believe.
<jtaylor> hm ok, I'll try without fortify thx
<infinity> Most people, I believe, debug it by getting good at reading optimized gdb backtraces, since an -O0 build would be sufficiently different from -O2 to not always be helpful.
<jtaylor> I'm reasonably familiar with it too by now but for some code its just much faster to ahve O0 code
 * infinity nods.
<jtaylor> if its not serial code usually you get the same results
<jtaylor> s/not//
<jtaylor> though I should give the new Og flag a try once
<LinuxPC> infinity: Thanks for the info, I'll check back at a better time. What I wanted to tell him, is, I really appreciated his help. I was getting errors trying to install Ubuntu onto a new drive and then loading dual-boot so that I could still have access to my windows drive. He was an awesome help to me and I wanted him to know it.
<infinity> doko_: Should gcc-4.8 depend on libgcc-4.8-dev?
<infinity> doko_: Without it, <stddef.h> doesn't exist, and pretty much nothing useful can be compiled.
<infinity> doko_: (g++ pulls it in transitively through g++ -> libstdc++-dev -> libgcc-dev, hence why build-essential and the buildds are fine and don't show the problem)
<infinity> doko_: And, indeed, saucy's gcc-4.8 has the dependency, so I assume maybe it got lost during the libgcc 4.8/4.9 shuffle?
<slangasek> infinity: no idea what's going on with libnih, but pitti mentioned libnih autopkgtest timing out on ppc64el too, so maybe that's related and it's an across-the-board regression
<infinity> doko_: https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1283850
<ubottu> Launchpad bug 1283850 in gcc-4.8 (Ubuntu) "Spamassassin update broke Ubuntu GNOME daily builds" [High,Incomplete]
<infinity> slangasek: The libnih thing is another incarnation of https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1266492
<ubottu> Launchpad bug 1266492 in binutils (Ubuntu Trusty) "ld:i386 crashes with -static -fPIE -pie" [High,Confirmed]
<infinity> slangasek: Seems like a bit of a random fluke on default build flags or something that it triggers in a sid userspace and not a trusty one.
<slangasek> infinity: and adsb seems to think it's a toolchain bug - right
<RAOF> In related gcc news, why do we now have a gcc-4.9-base package that does nothing but provide a gcc
<slangasek> (toolchain/libc)
<RAOF> In related gcc news, why do we now have a gcc-4.9-base package that does nothing but provide a gcc-4.9 binary that says âyou don't have gcc-4.9 installedâ?
<slangasek> RAOF: because any compiler we build comes with a corresponding -base, but gcc-4.9 is only supported for go, not for C
<infinity> RAOF: RAOF Erm, gcc-*-base don't provide any binaries...
<slangasek> right, there is no gcc-4.9 binary in that package
<slangasek> how did you come to find this out, exactly? :)
<infinity> RAOF: gcc-*-base is a tiny (very tiny) package that just provides common docs for all packages built from that GCC source.
<RAOF> slangasek: Ah, that makes sense. It's just a bit surprising that we've got /usr/bin/gcc-4.9 that, if you call it, says âyou don't have gcc-4.9 installedâ
<RAOF> Looks like it's hardening-wrapper providing a diversion.
<infinity> RAOF: So, it exists to provide the changelog and copyright for libgcc1_4.9, basically.
<infinity> RAOF: Yeah, hardening-wrapper always did that to you. :P
<RAOF> slangasek: I found out because I noticed an upgrade install gcc-4.9-$SOMETHING and thought âooh, I like trying newer compilers to see if they bring up any new and interesting warningsâ
<infinity> slangasek: So, the bug with the configure test is a binutils bug.  But the part where it subsequently hangs is a glibc bug.  I'm uploading a workaround to just skip past the whole mess right now, since the glibc bug is Really Hard to fix, and the binutils bug seems to have seen no traction.
<infinity> slangasek: http://deb.li/3DdiR (thanks to sbeattie)
<mwhudson> er\
<mwhudson> anyone willing to admit to knowing anything about setcontext?
 * mwhudson now knows why his go process is crashing but isn't really sure about who is to blame
<mwhudson> (on arm64)
<infinity> mwhudson: Marcus Shawcroft would be your best bet.
<mwhudson> yeah i think so too probably
<infinity> mwhudson: Have you tested with the glibc 2.19 in -proposed?
<mwhudson> no, but i looked at pretty recent glibc sources
<infinity> mwhudson: Err, assuming this uses glibc at all.  If you're talking directly to the kernel, then... Not sure who to talk to.
<mwhudson> yeah, this is gccgo so glibc is involved
<mwhudson> basically: setcontext copies the uc_stack of the context to the task's sigaltstack settings
<mwhudson> which seems a bit strange
<mwhudson> and certainly not what the gccgo runtime is expecting...
<infinity> Guessing this isn't how it works on armv7?
<mwhudson> had started to look at that but no idea at this stage
<infinity> mwhudson: 402a76b62dded0ee93cfec0471aaeccb989196d2 is the ARM setcontext implementation, modulo later cleanups and bugfixes.
<mwhudson> yeah i think that probably doesn't have the odd behaviour that's causing problems
<mwhudson> unexpected croissant break, brb
<infinity> Unexpected?  Did you just get thwacked in the head by a wild croissant?
<mwhudson> someone walked in with a tray of them
<mwhudson> so yes, i'm feeling like this is a glibc bug
<mwhudson> cool! i haven't found one of them recently
<infinity> mwhudson: There are no glibc bugs, only features that you're using incorrectly.
<mwhudson> infinity: i thought mr drepper was doing other things now
<infinity> mwhudson: (On a more serious note, the aarch64 port is still pretty immature, and really only has the one guy working on it, so please do file bugs and annoy Marcus if you sort out solid testcases and the like)
<mwhudson> it could also be a kernel bug, it depends how you squint
<mwhudson> infinity: oh, i am definitely going to annoy people
<infinity> mwhudson: Marcus comes back from VAC in ~6h, and will no doubt be flooded by people annoying him (including me)... Get in line. :)
<mwhudson> haha
<mwhudson> infinity: i presume there is a glibc bugzilla somewhere?
 * infinity looks forward to arm64 kit being more widely available and the general hacker community banging on it and finding all the problems with the port.
<infinity> mwhudson: https://sourceware.org/bugzilla/
<mwhudson> would be nice if that happened before T...
<mwhudson> looking unlikely i guess now
<infinity> Yeah, even if people start getting their hands on AMD dev boards, it's a bit too late for that to influence trusty in any meaningful way.
<infinity> But some bugfixes will likely be backportable.
<infinity> mwhudson: Want to CC me (adconrad@0c3.net) on your bug report, so I can keep tabs on what's going on?
<mwhudson> infinity: sure
<infinity> mwhudson: Do be sure to test with my 2.19 packages before you report bugs, though.
<infinity> We're so dangerously close to mainline right now that you can almost pretend that's testing against mainline. :P
<infinity> Almost.
<mwhudson> oh heh look at that
<mwhudson> i am already :)
<mwhudson> (t-mwhudson)mwhudson@am1:~/gccgo-4.9-4.9-20140222$ dpkg-query -W libc6
<mwhudson> libc6:arm64     2.19-0ubuntu1
<infinity> Shiny.
<infinity> I need to find the round tuits to set up a PPA for actual mainline builds.
<infinity> So I can be warned in advanace of new testsuite failures, etc.
<infinity> Instead of the post-release "hey, all this stuff is broken and I need to fix it" panic. :/
<infinity> Probably also much easier to rebase patches one day at a time instead of 6 months at a time.
<mwhudson> er
<mwhudson> paste.ubuntu.com is down?
<mwhudson> infinity: test case: http://hastebin.com/qunasobobo.c
<mwhudson> infinity: output http://hastebin.com/kacilipepi.sm
<Takyoji> paste.ubuntu.com appears to be up
<mwhudson> Takyoji: not accepting new pastes though
<Takyoji> ahh, understood
<mwhudson> anyway, have got a sysadmins attention now
<hyperair> what's the common practice for handling changelog entries for debian revisions in x.y.z+reallyA.B.C releases?
<hyperair> do i just put the intermediate A.B.D-1 changelog entry in between the x.y.z+reallyA.B.C-0ubuntu1 and x.y.z+reallyA.B.D-1ubuntu1 entries?
<hyperair> or do i just leave it out?
<infinity> hyperair: Up to you.  But if it implies bug closures and such, it might be less confusing to leave it out.
<hyperair> hmm, why would it be less confusing in that case?
<infinity> Because people parsing a changelog for the bug might think it's closed.
<infinity> *shrug*
<hyperair> but it is closed, is it not?
<infinity> I mean if the interim new upstream release closed bugs.
<hyperair> i mean the bugs closed in the A.B.D-1 changelog entry
<infinity> If that closed bugs, you should reopen them.
<hyperair> why?
<infinity> ...
<infinity> Because they're no longer fixed by code you're not shipping?
<hyperair> why wouldn't they?
<hyperair> the bugfixes are from A.B.C..A.B.D
<hyperair> i'm merging these changes into x.y.z+reallyA.B.C so that it's x.y.z+reallyA.B.D.
<infinity> Oh, I may not be seeing your usecase here.  I'm thinking that you're reverting from x.y.z to A.B.D, not just upgrading from A.B.C to A.B.D
<hyperair> i've already reverted from x.y.z to A.B.C
<hyperair> now i'd like to upgrade from A.B.C to A.B.D
<infinity> So, if this is about us having messed up and reverted in the past and now merging with Debian's A.B.C->A.B.D, then yeah, I'd keep the Debian changelog entries in between.
<hyperair> rigth, and should i renumber the entries?
<hyperair> so that debian's A.B.C-1 entry is now x.y.z+reallyA.B.C?
<infinity> Nah.
<hyperair> okay
<infinity> What's the actual package in question here?
<infinity> Is x.y.z close enough to A.B.D that the mistake will sort itself soon?
<infinity> Or are we talking an order of magnitude where it might be worth begging the Debian maintainer to add an epoch to get you out of your mess? :P
<hyperair> banshee
<hyperair> i'm the debian maintainer
<hyperair> no epoch necessary
<infinity> Ahh, yeah, that'll sort itself soon enough.
<hyperair> yeah
<infinity> So, yeah, I'd just stuff the interim versions in there unchanged in your merge.
<hyperair> okay cool
<mwhudson> infinity: https://sourceware.org/bugzilla/show_bug.cgi?id=16629
<ubottu> sourceware.org bug 16629 in libc "[aarch64] setcontext clobbers alternate signal stack" [Normal,New]
<infinity> "Merge changes from 2.6.1-5"
<infinity> hyperair: For sanity's sake, I probably would have called that 2.9.0+really2.6.1-5ubuntu1 instead of 2.9.0+really2.6.1-0ubuntu1, as a better indication of the relationship with the Debian packaging.
<hyperair> infinity: yeah i realized that a little too late, and didn't think it warranted another upload
 * infinity nods.
<Noskcaj> How can i check locally if a package supports building on ppc64el?
<sarnold> check build logs on launchpad?
<Noskcaj> For a merge i'm doing
<Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/trusty/garcon/merge/+merge/207861
<Noskcaj> and two more in progress
<RAOF> Noskcaj: I believe the current status is âupload it and seeâ; it doesn't seem that qemu has grown support yet.
<Noskcaj> ok
<Noskcaj> And chance you could do some sponsoring then?
<RAOF> That said, we're in feature freeze now; does it have an exception?
<Noskcaj> bugfix releases
<RAOF> (Or is purely bugfix?)
<Unit193> Trusty has a git snapshot, it's now actually released with a bugfix or two.  (Garcon)
<Noskcaj> one is bugfix + translation, the other we have a git snapshot of so it's just re-enabling docs and more translations
<infinity> Noskcaj: If it has a configure script, you can make an educated guess on support.
<Noskcaj> how?
<infinity> Noskcaj: Also, it might not matter unless it builds a library...
<infinity> Ahh, it does.
<Noskcaj> libxfce4ui does, i'm not sure about garcon
<infinity> Noskcaj: So, search for "powerpc64" in libtool.m4 and configure, and other places that have that construct.  Compare the /usr/share/aclocal/libtool.m4 ... Note that your is wrong.
<Noskcaj> "your is" ?
<infinity> Noskcaj: If you run dh-autoreconf, it might just solve itself, assuming autoreconf on that package relibtoolizes.
<infinity> Noskcaj: The merge you linked to has old libtool macros.
<Noskcaj> garcon is also a library
<infinity> s/your/yours/
<Noskcaj> ok
<Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/trusty/libxfce4ui/4.11.1 is the other merge
<infinity> In other news, why do people still do Debian merges as MPs?  It's completely unreadable and unparseable.
<Noskcaj> infinity, How should i be doing it?
<Noskcaj> (debian merges)
<infinity> Noskcaj: Well, that merge explicitly claims it's using dh-autoreconf for ppc64el, so I assume that works. :P
<infinity> Noskcaj: I dunno.  I prefer the sort of patches that MoM spits out.  Delta against Debian is much more helpful (usually tiny) than delta against previous Ubuntu (can be several megs of unauditable goop).
<infinity> Plus, you can interdiff deltas between Debian nicely.
<infinity> Old delta was foo, new delta was bar, quick interdiff shows the 5 lines you had to change to make the merge work.
<Noskcaj> makes sense, issue being MoM makes a lot of files and clutter, which get's confusing to new people trying to merge
<infinity> Surely nowhere near as confusing as a massive MP no one's going to read before committing. :P
<Noskcaj> although i should be on the reviewing end soon-ish
<infinity> (And if no one's going to review it, you'd just subverted the whole point of getting a sponsor to upload)
<infinity> s/you'd/you've/
<Noskcaj> yep
<Noskcaj> my current issue being, i have both sorts of merge up, and no sponsoring anywhere
<Noskcaj> e.g. bug 1282937
<ubottu> bug 1282937 in xfburn (Ubuntu) "Please package xfburn 0.5.0" [Undecided,In progress] https://launchpad.net/bugs/1282937
<Noskcaj> (bugfix only, all major changes are already in ubuntu as patches)
<infinity> Noskcaj: Well, now that feature freeze has come and gone, you might be able to find sponsors who aren't crazy busy. :)
 * Noskcaj looks at sponsoring queue, 51 packages.
<pitti> Good morning
<dholbach> good morning
<pitti> hey dholbach, wie gehts?
<dholbach> pitti, sehr gut - und dir? :)
<pitti> dholbach: still feeling a bit zombie-like with the jetlag, but ok; at least no ubuflu :)
<pitti> infinity, slangasek: yes, libnih keeps getting eternally stuck on ppc64 and armhf; it even seems to reset autopkgtest's timeout timer, so not even that kicks in
<pitti> infinity, slangasek: so I had to kill all of them at some point
<Noskcaj> Could someone please sponsor https://code.launchpad.net/~noskcaj/ubuntu/trusty/clutter-1.0/1.16.4/+merge/207778 ?
<Noskcaj> It's bugfixes, so it shouldn't need an FFe
<pitti> infinity: ah, gunnarhj reminded me that we should refresh the -base langpacks, as we just got a new ubuntu-docs; I'm doing that now, does that still work out for beta-1?
<pitti> (will also make the images smaller)
<infinity> pitti: Yeahp, should be fine, b1 freeze is later todayish.
<infinity> Noskcaj: Can you find out where clutter upstream got their libtool from?
<infinity> Noskcaj: It's buggy. :/
<infinity> Noskcaj: If Fedora's shipping that, they need to stop.
<Noskcaj> looking now
<infinity> Noskcaj: See this bit from your diff: http://paste.ubuntu.com/6985749/
<infinity> Noskcaj: That top set should say powerpc64le and powerpc64 (as the libtool.m4 on your Ubuntu system does).
<Noskcaj> ok
<infinity> Noskcaj: So, they obviously relibtoolized with a broken libtool, we should hunt down where that's coming from before it infects more upstream projects.
<Noskcaj> the git log doesn't seem to have a libtool change since 2011, but i've seen that issue before in something
<pitti> doko_: I've seen 'Exception ignored in: <bound method Popen.__del__ of <subprocess.Popen object at 0x7fc66afe24e0>>
<infinity> pitti: Everyone's seen it.  Happens on every python postinst. :P
<pitti> doko_: from /usr/lib/python3.4/subprocess.py in a lot of places; postinst scripts, tests, etc.; do you know where that's coming from? that's something since the py3.4 default
<infinity> Noskcaj: libtool and configure bits might not be in git at all, autogen might be part of the tarball release process.
<Noskcaj> looks like your right, i can't see libtool in the source
<infinity> Noskcaj: Right, hence hunting down the guy who did the release tarball to find out what distro he made it on to see if their libtool can be fixed would be awesome.
<infinity> (My guess is Fedora, since it's a fairly GNOMEish thing, but who knows)
<Noskcaj> just let my computer unfreeze from my current compiling and i'll look
<tseliot> pitti: apparently the kernel API broke again and fglrx doesn't build any more in Trusty. I wasn't notified. Is there a way to get the system to send me an email about it?
<pitti> tseliot: we don't currenlty have anything which triggers the ubuntu-drivers-common autopkgtest on kernel uploads
<pitti> tseliot: jibel is doing separate DKMS tests, they might be able to give you an email notification
<pitti> tseliot: http://d-jenkins.ubuntu-ci:8080/view/DKMS/view/Trusty%20Release%20-generic/job/dkms-trusty-release-generic-fglrx/ ran on Saturday and succeeded
<tseliot> pitti: err... I think it would be useful to do that when the kernel is uploaded, so that if the API breaks we know about it
<pitti> http://d-jenkins.ubuntu-ci:8080/view/DKMS/view/Trusty%20Release%20-generic/job/dkms-trusty-release-generic-fglrx_updates/ ran on Sat as well and failed
<pitti> yes, it would; we could perhaps add a linux-libc-dev build dependency to u-d-common, so that the reverse dependency check mechanism kicks in?
<pitti> tseliot: https://jenkins.qa.ubuntu.com/job/trusty-adt-ubuntu-drivers-common/58/ ran yesterday, did we get a new kernel since yesterday?
<pitti> (and succeeded)
<Noskcaj> infinity, The developer's name is Emmanuele Bassi, i have to go and have dinner, than i'll email him
<infinity> pitti: How would ubuntu-drivers-common help identify if fglrx or nvidia have stopped building?
<tseliot> pitti: I updated my system on Saturday and the build failed. I'm not sure if they fixed it over the weekend.
<tseliot> apw: ^^
<infinity> pitti: Or is its autopkgtest an attempt to build everything it knows about?
<pitti> infinity: its autopkgtests check our most popular dkms packages (nvidia, fglrx, bcmwl)
<infinity> tseliot: There have been no new kernels over the weekend, though there is one in proposed since Friday.
<pitti> infinity: https://jenkins.qa.ubuntu.com/view/DKMS/? is a more comprehensive approach to testing DKMS packages, but it doesn't hold back new kernels on failures
<tseliot> let me check what kernel version caused the problem
<tseliot> 3.13.0-11-generic
<infinity> pitti: I don't know if it should hold back new kernels necessarily, but it certainly needs a notification system that isn't "refresh the page once in a while".
<pitti> infinity: I'm not sure whether it has notifications; jibel and the kernel team discussed how notifications should look like back then, but I forgot what the result was
<pitti> adding email notifications to jenkins is trivial, but I don't know any more whether the kernel team actually wanted them
<tseliot> the failure: http://paste.ubuntu.com/6985814/
<zyga> good morning
<tseliot> pitti: is this a good log? http://d-jenkins.ubuntu-ci:8080/view/DKMS/view/Trusty%20Release%20-generic/job/dkms-trusty-release-generic-fglrx/24/ARCH=amd64,label=wazn-adt/artifact/results/fglrx/13.350/3.13.0-12-generic/x86_64/log/make.log
<tseliot> pitti: "build succeeded with return value 0 duplication skipped - generator was not called from regular lib tree done."
<tseliot> pitti: the log from "successful" builds looks exactly like the one from the failed build (19 February)
<pitti> at least it seems the compilation worked?
<tseliot> pitti: it still doesn't here
<tseliot> let's try the kernel in -proposed
<Wnt> I'm having problems installing Skype on my 64 bit Trusty machine. Is this the right place to as for help? Output of "apt-get install skype" and "apt-get install skype-bin" and some other commands at: http://upload.egarden.fi/apt-get_install_skype_failed.txt
<infinity> Wnt: You want #ubnutu, this isn't a support channel.
<tseliot> yes, #ubuntu
<phanimahesh> Hello guys! I need help with a FTBFS issue on trusty.
<phanimahesh> anyone has a few minutes to spare?
<infinity> phanimahesh: Depends on the issue and the minutes.  Just ask.
<phanimahesh> unity-tweak-tool is a package in the repos, and I am a member of its dev team.
<Noskcaj> python3.4 transition issues
<phanimahesh> And due to a python transition issue, tha package fails to build on trusty.
<phanimahesh> and i'm not able to figure out how to fix it.
<infinity> Wasn't that fixed in the archive 4 days ago?
<phanimahesh> + python3.3 setup.py build --executable=/usr/bin/python3
<phanimahesh> /bin/sh: 2: python3.3: not found
<phanimahesh> that is the relevant error message in the failed build log
<infinity> phanimahesh: That should just be python3, not python3.3
<phanimahesh> https://github.com/freyja-dev/unity-tweak-tool/blob/master/debian/rules
<phanimahesh> That is our debian/rules
<infinity> http://launchpadlibrarian.net/167142991/unity-tweak-tool_0.0.6_0.0.6ubuntu1.diff.gz
<infinity> phanimahesh: Like I said, this was already fixed in the archive, afaict.
<infinity> Andrew should probably have forwarded you the patches, but there you go.  The last build in trusty was against python3.4 as default, and worked fine.
<phanimahesh> Oh.
<phanimahesh> Thanks. :)
<phanimahesh> I did see that he backported a crash fix,
<phanimahesh> but did not notice the change to debian/rules.
<infinity> And debian/control.
<phanimahesh> I'll pull in the changes.
<phanimahesh> Thanks.
<infinity> Equally important.
<phanimahesh> yup. just looked at the changelog.
<phanimahesh> thanks!
<imapados> Hey guys! I have to geplace gksudo by pkexec. But how can i display a special message to the user like gksudo --message "Hey you"?
<imapados> replace
<pitti> imapados: it uses the polkit .policy's message, see e. g. /usr/share/polkit-1/actions/com.ubuntu.update-notifier.policy
<imapados> thx, pitti!
<pitti> imapados: the pkexec caller can't set an arbitrary message
<pitti> that's quite by design
<imapados> Hmmppff..
<phanimahesh> Noskcaj: infinity: thanks for your help.
<Noskcaj> no problem
<imapados> But you won't use gksudo in future?
<phanimahesh> I should have noticed it earlier, though.
<pitti> imapados: we have dropped gksudo for almost everything many cycles ago already, so yes
<imapados> so, i will follow you! ;)
<pitti> infinity: ok, built and tested; upload ahoi
<infinity> pitti: Should all build before stgraber wakes up, so yay. :)
<infinity> Especially with that massive army of x86 builders you now have...
<pitti> infinity: indeed; I wonder whether they can keep up with debuild/dputting them :)
<pitti> hm, probably should have updated the chroots before, but *shrug* too late
<infinity> You mean the LP buildd chroot?
<pitti> yes
<infinity> pitti: The largest portion of that upgrade (libc6 and gcc) is in -proposed, which isn't in the chroots, so wouldn't win you much.
<pitti> ah, ok
<pitti> 54 upgraded packages
<infinity> Not like 2m builds are a big deal. :P
<pitti> langpack pwned! https://launchpad.net/builders
<zyga> doko_: hey, I'd like to understand https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732703 better
<ubottu> Debian bug 732703 in python3.4 "python3.4: cannot create a virtualenv" [Normal,Open]
<zyga> doko_: that effectively breaks virtualenv on python3.4
<zyga> doko_: is that the status quo for the next 5 years or is this still something we can fix for trusty?
<doko> zyga, mind adding something constructive to the bug report?
<zyga> doko: I try to understand what's the current status first, is ensurepip deliberaltely disabled?
<zyga> I just found that it is, what is the reason for that?
<doko> zyga, see debian-devel about shipping pip. debian wants to use the pip shipped by debian. and I don't want to have the ensurepip interfer with the system python
<zyga> doko: I see, that makes sense, so pyvenv-3.4 should link to the local copy of pip, right?
<zyga> doko: (currently you just get a relatively useless virtualenv as you know, with just bare python)
<doko> zyga, yes, but it is currently my highest priority
<zyga> doko: so you are working on this?
<doko> no
<zyga> doko: can I help you somehow?
<zyga> doko: it is your highest priority or isnt?
<doko> ahh, typo. no, not my highes prio
<zyga> ah
<zyga> doko: do you have a preferred solution to this problem? is it just as simpe as symlinking pip pip-3 pip-3.4 in the right place?
<zyga> *simple
<doko> zyga, if you have patch, please send it
<zyga> doko: I'm willing to work on it if I know that's the right solution you will accept
<doko> you'll need to find this solution. I just outlined the requirements
<zyga> doko: ok, thankyou
<zyga> doko: can you tell me if the older version of python3-pip is a part of the story? upstream released 1.5.4, debian (and trusty) is at 1.4.1
<zyga> doko: is that deliberate due to wheels or is that just lack of manpower?
<Laney> infinity: cjwatson: Can I have a slither of moderation in the direction of u-d-a please?
<pitti> can do, too
<Laney> oh really?
<pitti> done
<Laney> you should be on here then https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
<Laney> thanks!
<pitti> Laney: well, I don't admin the ML, I just have a moderation pw
<Laney> mmm, "run by"
<infinity> It's a hard (hah!) password to forget.
<Laney> anyway, happy voting
<pitti> *shrug* ~/.listadmin.ini FTW :)
<infinity> Laney: Is it bad if I put everyone below None of the Above?
<pitti> *chuckle*
<infinity> Or, I guess, none of the below...
<Laney> it's NOTB
<xnox> infinity: haha =)
<Laney> if that expresses your thoughts :-)
<infinity> Nah.  Not this time around. :)
<pitti> Snow-Man: hey
<pitti> Snow-Man: you asked me about http://www.postgresql.org/message-id/52D6D914.8090207%40agliodbs.com the other day
<pitti> Snow-Man: FWIW, I think that features like conf.d are rather useless if you can disable them
<pitti> Snow-Man: especially if you can do so at runtime
<pitti> Snow-Man: for Debian I'd enable it in the packages, and we can then change p-common to use those instead of always modifying the default one in-place
<seb128> ev, bdmurray_: the e.u.c trusty retracing have quite some issues, is there anything we can do help figuring out what is wrong? like the ranking shows we have new compiz/unity segfaults but the reports are of no use since retracing doesn't work
<pitti> Snow-Man: while configurability doesn't hurt distros so much, it entirely breaks configuration tools/GUIs that are supposed to work everywhere
<darkxst> doko, I suppose you have already seen this, but Bug 1283850 is blocking all things beta1-ish like QA for ubuntu GNOME, would be great if you can take a look today ;)
<ubottu> bug 1283850 in gcc-4.8 (Ubuntu) "Spamassassin update broke Ubuntu GNOME daily builds" [High,Triaged] https://launchpad.net/bugs/1283850
<pitti> Snow-Man: so if you want to make it configurable, you can just as well drop the feature entirely; halves the testing space and avoids trouble
<seb128> ev, bdmurray_: e.g https://errors.ubuntu.com/problem/44226fe8b2fa8e16ed82ac4469f9b26e726420a0
<doko> darkxst, please ask ScottK, I didn't update spamassassin
<xnox> doko: well commentry on the bug report, suggests gcc missing a build-dep on libgcc-x.y-dev.
<xnox> doko: unless that was intentional...
<doko> hmm, no
<doko> hmm, more gccgo fallout
<seb128> pitti, we don't have detailed logs of retracings anymore?
<pitti> seb128: on the porter box? nothing changed wrt. logging for a long time
<seb128> I didn't look at those for ages
<pitti> seb128: I still saw proper logs a few days ago; which logs do you mean?
<seb128> pitti, I'm trying a retracing by hand, trying to figure out why https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1283885 is missing unity symbols
<ubottu> Launchpad bug 1283885 in unity (Ubuntu) "compiz crashed with SIGSEGV in __dynamic_cast()" [Undecided,New]
<seb128> "dynamically loaded /usr/lib/compiz/libunityshell.so needs package unity, queueing
<seb128> "
<seb128> that part looks ok
<seb128> pitti, I only see "retracing <...>" in the log, not the logs of the actual retrace (that would hint on why symbols are missing)
<seb128> shrug
<seb128> #4  0x00007f5b7c526b3a in ?? () from /tmp/s/usr/lib/compiz/libunityshell.so
<seb128> No symbol table info available.
<seb128> but no indication why that's missing
<pitti> the package looks current at least
<darkxst> doko, it was the gcc update that killed it, read the bug ;)
<seb128> pitti, is there any way to tell apport-retrace to display infos about the ddebs it fetches?
<seb128> the log has
<seb128> "dynamically loaded /usr/lib/compiz/libunityshell.so needs package unity, queueing"
<seb128> then the gdb bt
<seb128> no debug in between
<pitti> WARNING: /home/townsend/.compiz-1/plugins/libunityshell.so is needed, but cannot be mapped to a package
<pitti> seb128: ^
<pitti> seb128: ah sorry, different bug
<pitti> seb128: that's your local log? because I don't see that on the porter bos
<seb128> pitti, on osageorange
<seb128> $ ls cache-amd64/Ubuntu\ 14.04/apt/var/cache/apt/archives/*unity_*ddeb*
<pitti> box
<seb128> pitti, I ran the command manually on porter to have the log
<seb128> $ apport/bin/apport-retrace -sv --auth launchpad-credentials -S config --sandbox-dir=/tmp/s  1283885
<tseliot> doko: that broke fglrx too here (trusty amd64). The module won't build although the relevant headers are included: http://paste.ubuntu.com/6985814/
<seb128> bah
<seb128> pitti, ddebs are missing from http://ddebs.ubuntu.com/pool/main/u/unity/
<pitti> go ddeb-retriever!
<seb128> pitti, that version is 4 days old, can we rescue them?
<pitti> seb128: yes, hang on
<seb128> thanks
<pitti> err, buildds don't have ddebs any more from Feb 20?
<seb128> pitti, https://launchpadlibrarian.net/166943400/buildlog_ubuntu-trusty-i386.unity_7.1.2%2B14.04.20140220-0ubuntu1_UPLOADING.txt.gz
<seb128> "unity has no unstripped objects, ignoring
<seb128> find: `/build/buildd/unity-7.1.2+14.04.20140220/debian/unity-dbgsym': No such file or directory
<seb128> /usr/bin/pkg_create_dbgsym: nothing in /build/buildd/unity-7.1.2+14.04.20140220/debian/unity-dbgsym and no dbgdepends, ignoring"
<seb128>  
<seb128> I guess upstream bug/lack of -ggdb
<pitti> http://klock.buildd/~buildd/ddebs/20140220/
<pitti> empty
<pitti> it seems that we don't have ddebs up to 2040220/ on the buildds any more
<seb128> pitti, yeah, seems like the upstream build generates stripped binaries
<pitti> 20140221 and on still have ddebs
<pitti> seb128: so, two bugs here
<pitti> although I guess infinity's ppc64 rebuild and temporarily changing the apaches has got something to do with the missing ddebs
<pitti> so, missing -g for unity and the manual cleanup
<seb128> pitti, thanks for helping debugging that
<seb128> pitti, I've opened https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1284047 about the unity issue
<ubottu> Launchpad bug 1284047 in unity (Ubuntu) "Build stripped binaries, lead to missing debug symbols" [Undecided,New]
<pitti> seb128: wasn't that helpful after all :/, but yw
<pitti> thanks
<seb128> hum
<seb128> seems like they have none of the standard build flags
<pitti> infinity: so we'll do the locales change in 14.10?
<seb128> e.g no -fstack-protector
<seb128> debdiff between saucy and trusty has
<seb128> -CFLAGS=$(shell echo $$CFLAGS | sed -e 's/\-Wall//')
<seb128> +export CFLAGS=$(shell echo $$CFLAGS | sed -e 's/\-Wall//') -Wno-error=deprecated-declarations
<infinity> pitti: Nope, I'll do it soon in trusty and get an FFe for it.  Just wanted 2.19 in first.
<pitti> infinity: ah, godo
<pitti> good, too
<seb128> is that buggy?
<infinity> pitti: As for ddebs, I didn't touch anything on !ppc64el buildds...
<pitti> infinity: hm, so do the ddebs not keep the last 7 days of ddebs any more, but perhaps only 3?
<infinity> pitti: It's been 3 for... Ever.
<pitti> infinity: oh, was it? I had the impression it was 7
<pitti> so, nevermind
<seb128> it was 7 iirc
<infinity> You can remember all you want, but it's not correctly. :P
<infinity> It's been 3 for years.
<seb128> lol
<seb128> that's not ever :p
<infinity> Well, it's been 3 ever since the project was split from LP in 2011.  And was 3 before that too, just too lazy to go find the old tree and see how far back.
<seb128> shrug, I wonder why unity doesn't get the standard build flags :/
<seb128> cmake issue?
<doko> jtaylor, what is the status of the qhull transition? looks like a lot of octave updates are needed too. maybe merge octave from unstable first?
<xnox> seb128: debhelper changed to BuildType=None, that might affect cmake based projects...
<xnox> seb128: i was personally against that change...
<seb128> xnox, what is BuildType? can I change that just to see if that restore the flags?
<xnox> seb128: dh_auto_configure -- -DCMAKE_BUILD_TYPE=Release
<xnox> seb128: but... previously it was not defined at all. which is different from defining it to any value... your mileage may vary...
<seb128> xnox, no luck, anyway I'm going to let that to the unity team/cmake people to debug
<seb128> xnox, "-g -O2 -fstack-protector" are missing, do you know where they are supposed to come from
<seb128> commented on https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1284047 anyway
<ubottu> Launchpad bug 1284047 in unity (Ubuntu) "Build stripped binaries, lead to missing debug symbols" [High,Confirmed]
<xnox> seb128: let me poke that a bit.
<seb128> xnox, thanks
<xnox> seb128: i have a fix. do you want it as a branch to lp:unity? or direct upload...
<xnox> seb128: http://paste.ubuntu.com/6986427/
<xnox> seb128: or the two export lines should be gone, and unity fixed to build with -Wall and -Werror=deprecated-declarations ;-)
<xnox> (but still keep DPKG_EXPORT_BUILDFLAGS & include line)
<infinity> xnox: Isn't it a bit redundant to include the flags and then use dpkg-buildflags?
<xnox> infinity: i know.... but i'm hoping the two overrides will be dropped. And first include gets me cppflags & ldflags, which i'm not overriding.
<infinity> xnox: My point is that you already have the environment, why are you running dpkg-buildflags at all?
<infinity> xnox: http://paste.ubuntu.com/6986456/
<infinity> xnox: In fact, you also don't need to export twice either.  This is all sorts of sloppy. :P
<seb128> xnox, sorry, got a timeout, please merge request, that can be batched with other fixes that need to be uploaded today
<infinity> xnox: http://paste.ubuntu.com/6986466/ <-- See?
<xnox> infinity: ah, ok. I was getting make variable references itself =/ yours looks better indeed.
<infinity> xnox: You got the self reference if you used = instead of := at some point.
<xnox> infinity: ack. wanna merge propose your fix to lp:unity ? =)
<infinity> xnox: Nope.  I'm going to bed.  It's all yours.
<xnox> infinity: ok, good night.
<seb128> infinity, night
<infinity> xnox: Out of curiosity, what sort of irresponsible project are we running that removes -Wall? :/
<infinity> Shouldn't they, I dunno, fix the warnings?
<xnox> infinity: unity7
<xnox> infinity: ditto deprecated-warnings.
<xnox> infinity: actually, i'll just give them the dpkg-buildflags, and they should fix the other two.
<pitti> removing -Wall sounds weird, though; is that meant to remove -Werror perhaps?
<xnox> infinity: pitti: and given that i now fetch flags from dpkg-buildflags, in fact, neither Wall nor Werror will be present by default....
<infinity> Actually, wait.  Why is this madness being done this way at all? :P
<pitti> ah, so this is moot then
<xnox> thus the whole "fix" reduces to removing custom processing of CFLAGS/CXXFLAGS....
<seb128> the "don't use Wall" seems to be from didrocks in 2010
<seb128> that could probably be revisited
<didrocks> well, it's from time of unity7 in vala
<didrocks> so unity1 :)
<didrocks> can probably be revisted for sure
<seb128> yeah, could/should probably be revisited ;-)
<infinity> xnox: Here.  Use dpkg-buildflags how it's meant to be used: http://paste.ubuntu.com/6986490/
<xnox> infinity: i didn't know it can do _STRIP
<infinity> xnox: Yeahp.  Though, as you point out, -Wall isn't in the default flags anyway, so those two lines are unnecessary, and you could just use the APPEND.
<xnox> didrocks: we had unity in vala! =) lolz.
<xnox> i didn't know that.
<didrocks> xnox: yeah, we even shipped it! :)
<seb128> hum
<seb128> (ignore that)
<seb128> what's the best way to see what keeps something in main?
<pitti> it used to be http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.trusty
<pitti> but that now redirects to http://people.canonical.com/germinate-output/ubuntu.trusty/ and is 404
<pitti> cjwatson: ^ is that supposed to exist still?
<Laney> put a / on the end
<Laney> ...
<pitti> aah :)
<pitti> seb128: e. g. http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.trusty/rdepends/udisks2/
<pitti> seb128: you get a file for each binary of that source, and an rdepends tree
 * apw is seening a few python blammos during apt-get dist-upgrades ... are these known
<apw> Exception ignored in: <bound method Popen.__del__ of <subprocess.Popen object at 0x7f7809bfb2b0>>
<apw> that sort of thing
<Laney> yep
<apw> ok cool
<seb128> pitti, the 404 is the "hum" I just had before :p
<seb128> pitti, I was looking at that, but it's not really "digest"
<seb128> e.f http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.trusty/rdepends/gnome-control-center/gnome-control-center
<seb128> e.g
<seb128> lot of those are "depends: u-c-c | g-c-c"
<pitti> grep for "seed"?
<pitti> oh, ok
<seb128> g-c-c dropped from the daily iso
<Laney> I like this table better, although it only lists one thing at a time
<seb128> so I guess that's something out of the iso that keeps it in main
<Laney> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.trusty/all
<seb128> gnome-media (Recommends)
<seb128> hum
<pitti> but gnome-media is in universe
<Laney> hmm, indeed
<seb128> compiz (Build-Depend)    as well
<seb128> oh, and some apps like deja-dup build-depends on libgnome-control-center-dev
<seb128> ok, I guess we are not being able to demote it then
<Laney> yeah those would do it
<xnox> seb128: Laney: i think the point was that "gnome-settings-daemon" / "gnome-control-center" binaries could be demoted to universe, whilst the source/dev/lib packages will stay in main.
<xnox> and security would like "gnome-settings-daemon" / "gnome-control-center" bin packages to be demoted.
<seb128> xnox, yeah, that should work
<xnox> seb128: gnome-control-center-unity: gnome-control-center-unity seems to want to go into universe, i guess it's safe to remove from the archive now?
<seb128> xnox, yeah, let me do that
<xnox> Laney: seb128: and all the gnome-media / gnome-panel is probably coming from ppc64el/arm64 pulling in a desktop into main... since unity is not built?!
<seb128> still not?
<xnox> well, let's check.
<seb128> https://launchpad.net/ubuntu/+source/unity/7.1.2+14.04.20140220-0ubuntu1 has all archs
<xnox> seb128: looking at http://people.canonical.com/~ubuntu-archive/component-mismatches.svg something is odd in the indicator-datetime chain.
<seb128> Recommends: indicator-applet | indicator-renderer
<seb128> should the default be changed?
<seb128> though other indicators do the same thing
<xnox> seb128: who provides indicator-renderer?!
<seb128> unity
<seb128> and indicator-applet
<mitya57> I believe some Xfce applet provides it as well.
<seb128> $ apt-cache showpkg indicator-renderer
<seb128> http://paste.ubuntu.com/6986720/
<xnox> seb128: in that case i'm failing to understand why gnome-panel is still pulled in by components missmatches.
<xnox> well indicator-applet to be precise.
<seb128> could it be that unity is not installable on some arch?
<seb128> built != installable
<xnox> seb128: but it migrated to release pocket.... britney would tell us that.
<xnox> let's check that output.
<seb128> britney prevents regressions no?
<xnox> seb128: http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty_uninst_full.txt
<seb128> e.g if unity had never been installable on e.g ppc64el, would it prevent it to migrate?
<xnox> seb128: unity appears to be installable.
<seb128> I don't know then
<xnox> seb128: actually....
<seb128>   unity (7.1.2+14.04.20131106.1-0ubuntu4): libunity-core-6.0-8
<seb128> in the ppc64el section
<xnox> yeap. greping for "unity (7" helped.
<seb128> xnox, btw, let me know when your unity cflags fix is up for review, I can ack it
<xnox> seb128: oh, i get a hallarious internal compiler error =)
<Laney> it should be -6.0-9 no?
<xnox> seb128: but not when building twice =)
<Laney> ah not ubuntu4, that's an old version
<seb128> Laney, yeah, I'm not sure why that version is listed
<seb128> I wonder if that's a side effect of the ppc64el new boostrap/rebuild
<seb128> infinity hinted that component mismatch might be buggy for some days due to that
<doko> seb128, defaults to O3 now
<doko> please get the preprocessed source if possible
<xnox> seb128: in a ppc64el chroot, unity7 is installable.
<xnox> (well it's downloading packages at the moment...)
<Laney> the report refers to an old version
<xnox> Laney: well, it's been generated twenty minutes ago... looks like britney is full of lies then.
<xnox> doko: is 03 default on i386/amd64 as well?!
<Laney> weird isn't it
<doko> xnox, no
<Laney> xnox: I see some hack for ppc64el in britney
<Laney> https://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/revision/221
<Laney> it's probably the full of lies that we should ignore
<xnox> cjwatson: infinity: ppc64el rebuild is complete, can we drop the snapshot archive from britney? it's now actively generating lies for us =)
<xnox> ditto elsewhere, e.g. components-mismatches if that was tricked into snpashot archive as well.
<Laney> I don't see where it was done for c-m though
 * xnox loves launchpad without CSS loading
<smoser> asac, sure. i think tomcat test failure might be bug 1269073
<ubottu> bug 1269073 in tomcat7 (Ubuntu) "test_tomcat_daemon smoke test failure on images with 3.13 kernel " [High,Confirmed] https://launchpad.net/bugs/1269073
<zyga> doko: sorry to bother you with that again, I had some unrelated fire-fighting to do, back to virtualenv problem. Do you think it is the same code that disables 'ensurepip' which makes `virtualenv -p python3 --system-site-packages` *not* install pip as it did before?
<doko> zyga, I don't know. maybe barry could have a look? he uses venv much more than me
<zyga> doko: it seems that python2.7 is affected too
<barry> zyga: what's going on?
<zyga> doko: i think this is a very serious issue now
<zyga> barry: hey
<zyga> barry: please run `virtualenv -p python2.7 --system-site-packages /tmp/py27-sys` and confirm that you *don* have pip inside your new venv
<zyga> barry: also affects 3.3 and 3.4
<zyga> barry: I'm trying to understand what caused that, initially I assumed that is --without-pip which disables 'ensurepip' on 3.4 but I don't understand how that affects 2.7
<zyga> *dont*
<barry> zyga: looks like that's the case.  pip still comes from /usr/bin/pip
<barry> and there's no pip in the venv
<zyga> barry: this is a change of beahavior, is that expected?
<barry> zyga: that's *despite* the fact that the log message says it's installing it :/
<zyga> barry: in particular, the outer pip cannot install anything into my venv now
<zyga> barry: yes
<barry> zyga: i think that's a bug, yes
<zyga> barry: ok, I'd love to file and follow it till it gets fixed (I can help) because it blocks all of my work
<zyga> barry: on python-defaults or what? I still don't understand how it might have happened
<barry> zyga: if you de-install system pip, does it work?
<barry> zyga: i would file it on python-virtualenv.  we can always reassign it later
<zyga> barry: yes
<zyga> barry: ok, on it
<barry> tumbleweed: ^^  you did the last few updates on python-virtualenv in debian (which ubuntu syncs unchanged).  i wonder if something broke in upstream's 1.11?
<smoser> is this expected ?
<smoser> $ du -hs ~/.cache/upstart
<smoser> 454M    /home/smoser/.cache/upstart
<smoser> $ ls -altrh ~/.cache/upstart/dbus.log
<smoser> -rw-r----- 1 smoser smoser 410M Feb 24 09:58 /home/smoser/.cache/upstart/dbus.log
<barry> zyga, tumbleweed, doko: nope, it's an upstream bug:
<barry> 1.11.1 (2014-01-20)
<barry>  
<barry> Fixed an issue where pip and setuptools were not getting installed when using the --system-site-packages flag.
<barry> i will upload a new version to debian and sync it over
<zyga> barry: thanks for the quick reaction :)
<zyga> barry: will we also get latest pip through that?
<smoser> jodh, ^
<barry> zyga: yes, inside the venv i think, but outside it, that's a separate package
<barry> of course, i never use outside-the-venv pip anyway (that's crazy talk)
<smoser> now that i look at the contents, its not upstarts fault i'd guess, but bamfdaemon seems to like to log glib-critical messages a bunch.
<zyga> barry: I'm sadly forced to work with things that require system-wide packages installed so that's not an option
<smoser> (bamfdaemon:3853): GLib-CRITICAL **: Source ID 163665 was not found when attempting to remove it
<barry> zyga: no, what i mean is that /usr/bin/pip is a separate thing, which i don't think sane people on a distro like debuntu should be using if they can help it ;)
<tumbleweed> it'd be very nice to not bundle pip in virtualenv
<tumbleweed> but I can't figure that one out
<zyga> barry: ah, sure
<zyga> barry: we use it to get some level of consistency between 12.04 and 14.04 where we are willing to use things not available on 12.04
<jodh> smoser: I don't see that locally. What does tailing the log show? Reminds me, we could do with https://code.launchpad.net/~jamesodhunt/ubuntu/trusty/upstart/periodic-logrotate being reviewed some time ;)
<zyga> (but only inside that virtualenv)
<barry> zyga: right.  it should work inside venv with --system-site-packages
<zyga> barry: so is there a bug still needed or is the sync the only thing that is required? can I help somehow?
<barry> zyga: no, you don't need to file a bug.  i could build a test .deb if you want
<zyga> barry: absolutely, is it just a rebuild of python-virtualenv from debian?
<smoser> jodh, theres a bunch of bamfdaemon warnings in it at the end, but that accounts for only a tiny piece.
<smoser> its quite possible this is just grown forever an dnever been truncated
<smoser> i surely have never manually cleaned it and hope that isnt expected :)
<barry> zyga: well, first i have to update the version in debian ;)  i could put up some .debs for you to install and test before it clears debian and gets sync'd into ubuntu
<barry> zyga: i *am* going to test the new debian version first
<zyga> barry: fix it in debian svn
<zyga> barry: and I'll build and test that
<xnox> barry: ! =) hello.
<jodh> smoser: if you haven't restarted your session that could be true - the current session logrotate job only rotates once, soon after login (hence my [o/s] MP to run periodically)
<barry> zyga: watch #debian-python :)
<barry> xnox: hello!
<xnox> barry: so unity8, ubuntu-ui-toolkit, and a few core-apps clicks fully pass under python3.
<xnox> barry: i'm running through the rest of clicks.
<barry> xnox: i've seen your blueprint updates, thanks!
<zyga> barry: ok
<xnox> barry: the bits which will hold up python2 on the phone are: gdebi-core, ofono-scripts.
<barry> xnox: what's the status if your phablet-tools branch?
<xnox> barry: i'm in the mean time going through other clicks.
<xnox> barry: my phablet-tools branch is wonderful =) and fully works as needed.
<barry> xnox: how do we land it? :)
<xnox> barry: as in, it does proper python2/python3 setups and can execute either tests.
<xnox> sergiusens: can we land phablet-tools branch? it's now been fully tested with both deb and click based tests both under python2 and python3 and it's wonderful.
<smoser> jodh, you have a suggestion on how to determine when i logged in ?
<barry> xnox: so, gdebi-core and ofono-scripts.  what's up with them?
<xnox> barry: gdebi-core is pulled in by packagekit-backend-aptcc, which cjwatson expressed desire to keep (as it's useful to query system installed package info)
<xnox> barry: and that's not used on the desktop, cause we seed python3 "fake-packagekit api" instead.
<xnox> barry: and gdebi-core appears to be python2 only at the moment. We could drop the dep from packagekit-backend-aptcc, but i'd rather not.
<sergiusens> xnox, sure, let me give it a silo
<xnox> barry: ofono-scripts, are used for testing/manually driving the GSM/SIM stack, and they are python2 only upstream at the moment.
<xnox> barry: porting them to python3 only or bilingual would be nice, and pushing that upstream / do a distro-patch.
<sergiusens> xnox, you can probably remove them from the default build
<sergiusens> if in a hurry
<xnox> sergiusens: correct, at the moment we are attempting to keep them.
<sergiusens> it's not an exposed interface
<xnox> sergiusens: we have a few other things to release, before ofono-scripts becomes dead-last one.
<xnox> sergiusens: barry: so yeah, with both gdebi-core and ofono-scripts => we could just drop them from the seed, but it would be nice to port them anyway.
<barry> xnox: i see LP: #1283571 attached to the blueprint.  is there a bug or task for gdebi-core?
<ubottu> Launchpad bug 1283571 in ofono (Ubuntu) "ofono-scripts must be ported to python3" [High,Confirmed] https://launchpad.net/bugs/1283571
<xnox> barry: yes, one sec.
<xnox> bug #1283574
<ubottu> bug 1283574 in packagekit (Ubuntu) "packagekit-backend-aptcc pulls in python2" [Undecided,New] https://launchpad.net/bugs/1283574
<xnox> now linked on the blueprint.
<barry> xnox: excellent, thanks
<barry> Laney, sergiusens: so landing-010.  can you test those packages according to the si test plan?  if i can get a second +1, then i think we'll be safe to land it
<bdmurray_> seb128: thanks for looking into the retracer issue, it'll be the same problem with errors
<Laney> barry: I added another UI fix to u-s-s & seb128 is going to test it
<barry> Laney: ack
<Laney> I tested it myself earlier without that UI fix and it mostly worked
<Laney> just showed a buggy state while the update was downloading
<barry> mostly? ;)
<seb128> bdmurray_, how come e.u.c gives no bt at all where launchpad retracing had some useful functions (even if some symbols are missing)
<Laney> hopefully this additional thing fixes that
<barry> Laney: and that's with the previous behavior re-enabled right? (i.e. starts update when s-s panel is open, tries to start again when Updates is clicked)
<Laney> ya
<Laney> basically it said "Checking for updates" with a spinner instead of something more useful
<Laney> as it actually was downloading the update
<Laney> then the popover came up correctly and I could install it
<barry> cool
<doko> pitti, are autopkg tests really running? don't see much progress ...
<bdmurray> seb128: probably because it is marked as failing, but I'll double check.
<pitti> doko: they are, but there's a rather huge backlog, mostly due to eglibc triggering the world twice
<jodh> smoser: try "ps -ostart,comm,pid -p$(initctl list-sessions|awk '{print $1}')". You can run the logrotate session job any time fwiw ("start logrotate").
<smoser> jodh, i just opened bug 1284164 and am currently uploading 'dbus.log.bz2'.
<ubottu> bug 1284164 in upstart (Ubuntu) "~/.cache/upstart grows enormous" [Undecided,New] https://launchpad.net/bugs/1284164
<seb128> bdmurray, thanks
<jodh> smoser: thanks - bug updated.
<smoser> jodh, note, that while bamf is the *last* annoyance listed
<smoser> it is i think ~ 1%
<Laney> barry: did you kill --testing?
<barry> Laney: no, but you do need system-image-dev installed
<Laney> hmm
<barry> i'm pretty sure that *has* to work, otherwise the test suite would fail ;)
<Laney> like this: sudo system-image-dbus --testing=update-manual-success right?
<barry> should be, yes
<Laney> system-image-dbus: error: unrecognized arguments: --testing=update-manual-success
<barry> Laney: system-image-dbus --help ?
<jodh> smoser: bug updated again
<seb128> Laney, do you have system-image-dev installed?
<barry> Laney: well, that's interesting. i get the same bug
<Laney> ruh roh
<barry> i'm also seeing the weird NoneType error on package install that doko observed last week
<barry> Laney: looks like we have a missing dep
<barry> Laney: the workaround is to apt-get install python3-psutil.   i'll update the packaging branch and mp.  we'll need another silo build
<Laney> ack
<Laney> barry: is there a testing mode which simulates a long-running download?
<Laney> so I can reproduce this other bug
 * barry looks
<Laney> I think under testing the first CheckForUpdate finishes before you get to click on the entry
<barry> Laney: there isn't.  i do two things: a non --testing update against the real server is slow enough (given a sufficiently old flash revision) to take a long time to download.  in my test suite, i create a bunch of 100MB data files, and use the --testing=live with a client.ini that points to my test suite's http/https server.  that test takes long enough to trigger the issue (before the patch).  you could use the same technique.  it's a
<barry> bit tricky to set up all the keyrings and signed files, but systemimage.testing.helpers has lots of methods to do just that
<barry> Laney: tl;dr: doable, but takes a little work ;)
 * Laney whispers "sleep()"
 * barry mutters feature request bug
<dobey> barry: hey. do you have any idea how much work it would be to get a python3 version of launchpadlib? or is lazr.restfulclient a huge problem?
<Laney> oh look, a small bug appears
<barry> dobey: "a lot" :(
<dobey> :(
<barry> dobey: last time i looked at it (admittedly a cycle or so ago) i thought it would be less work to ditch the whole stack and write it again from scratch without all those dependencies
<barry> dobey: but we may just be talking about different degrees of infinity here
<dobey> well, wadllib appears to be ported, and seems like a necessity here. i think lazr.restfulclient is the big remaining roadblock
<barry> dobey: yes
<barry> dobey: unfortunately, i don't think it's a trivial port
<dobey> yeah, probably not
<dobey> :-/
<dobey> ah well
<Snow-Man> pitti: Really surprised to hear that as I feel that it makes management much easier if conf.d-style directories exist and are enabled by default.
<dobey> wow. indicator-datetime keeps crashing constantly for me now :(
<barry> i may tackle it again... someday.  but as i said, i'm really tempted to just rewrite it.  then again, i'll be tempted to fix its api too, so that's probably not a recipe for success ;)
<Snow-Man> pitti: Being enabled by default should allow most users to use it and configured things through the conf.d dir instead of having to hack up the .conf files directly.
<Snow-Man> pitti: I don't see any situation where we would force the user to have a conf.d directory- is there anything which does that?
<seb128> dobey, bt?
<dobey> seb128: https://bugs.launchpad.net/bugs/1284172
<ubottu> Launchpad bug 1280341 in indicator-datetime (Ubuntu) "duplicate for #1284172 indicator-datetime-service crashed with SIGSEGV in strlen()" [Medium,Confirmed]
<seb128> charles, tedg: ^ saw that one?
<dobey> barry: yeah. it might be easier to write a new lib on top of wadllib that doesn't use lazr stuff
<charles> seb128, got it
<dobey> anyway, time to get some lunch
<seb128> charles, thanks
<seb128> dobey, seems charles is on it ;-)
<dobey> thanks
<zyga-afk> re
<charles> seb128: I see the bug, datetime isn't testing the ecalcomponent's summary for NULL before stuffing it into a std::string
<charles> strange to have a NULL summary, but still, not bounds-checking isn't cool
<seb128> is the e-d-s api supposed to return NULL? in that an error case?
<xnox> is there a cli for packagekit? i need to trigger distro-upgrade
<charles> dobey, is 1284172 repeatable for you s.t. you can test a patch?
<charles> seb128: there are two places where we're using strings in that function -- one is to get the color hint from an ECalClient, and one where we get the summary
<charles> so one of those is returning NULL and we're putting it into a std::string
<charles> It probably is possible to have a component without a summary. I'm not sure how you'd do it via, say, the Evolution gui
<charles> but these components can be created anywhere
<seb128> charles, k
<seb128> charles, in any case seems like it's worth putting the fix up for review, dobey can test from the ppa later on when somebody does a landing request
<charles> seb128, dobey: https://code.launchpad.net/~charlesk/indicator-datetime/lp-1280341/+merge/207970
<rsalveti> awe: pitti: ogra: is there a way for phonesim to not export the data call capability in touch?
<rsalveti> NM takes a while to settle down because it tries to connect a few times
<rsalveti> http://paste.ubuntu.com/6987869/
<rsalveti> and that happens for every reboot in our CI environment
<ogra> do we use it for anything ?
 * ogra guesses thats a cyphermox question ... he will know how to suppress it in NM
<cyphermox> not without code.
<cyphermox> phonesim is meant to export these things, so that it can simulate them
<ogra> well, we want to get rid of all the preinstalled testing stuff on the images anyway
<ogra> could we probably have a switch in phonesim to turn it off except when we are actually testing ?
<ogra> pitti, ^^^
<xnox> ogra: oh, oh, remove ofono-scripts first!
<ogra> (like an /etc/default/phonesim
<xnox> ogra: it's testing stuff.... =)
<ogra> )
<ogra> xnox, no it is debugging stuff :P
<xnox> ogra: LOL!
<ogra> xnox, and thats awe's decision, not mine :)
<ogra> i know that they are needed for people that want to use features we havent got a UI for though
<xnox> ogra: i'd love to see the line between debugging and testing =) it's even more blurry than sysadmin and devops.
<xnox> or ci and qa.
<ogra> haha, yeah
<ogra> well, but i think the point is, get the designers to design us teeh UIs and we can quickly drop it
<ogra> (if you accidentially lock your SIM by typing your PIN false several times, i think the only way to enter the PUK is these scripts)
<ogra> (not sure though)
<seb128_> doko, https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/1273779 ... does it mean we can dropped the workaround? (not sure you saw my question before, there was an irc split)
<ubottu> Launchpad bug 1273779 in poppler (Ubuntu Trusty) "poppler in trusty lets packages ftbfs when building pdf docs" [High,Invalid]
<seb128> doko, just saw you did it, thanks
<pitti> rsalveti, ogra: I suppose you could call it with a different XML with the data/call capabilities ripped out, but I haven't tried that
<pitti> ogra: ofono-phonesim should not be installed by default; tests should pull ofono-phonesim-autostart as a test dependency only
<ogra> pitti, right, we found the problem lies elsewhere
<ogra> pitti, the test ppulls it in, but never uninstalls it
<ogra> which then makes it hog some CPU in later tests
<rsalveti> ogra: pitti: problem is that it's installed when setting up the test build
<rsalveti> then at every reboot we get that issue
<ogra> rsalveti, right, we need to uninstall it
<dobey> charles: evolution-calendar-factory (i think) was eating up ~35% cpu when the crash occurred. the crash isn't happening again for me when i open the indicator rihgt now, but i'm also not getting any events shown in it; even though i have multiple calendars with daily events
<jtaylor> doko: why did you sync octave?
<jtaylor> its a relatively large unfinished transition
<jtaylor> I'm really unhappy about it but its weird after ff
<jtaylor> but I'm not happy that it now seems to collides with my qhull transition which I hoped have to finish yesterday :(
* stgraber changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: feature freeze (+ beta1 migration block) | 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:
<doko> jtaylor, was looking at support for ppc64 and arm64. currently syncing and uploading
<jtaylor> is octave really important for that?
<Laney> I don't know of any blanked FFe for that kind of thing
<mapreri> Hi! I'm about merging varnish, and I'm wondering if I can/should apply this: https://bugs.launchpad.net/ubuntu/+source/varnish/+bug/1284095
<ubottu> Launchpad bug 1284095 in varnish (Ubuntu) "add configtest action to init.d script" [Undecided,New]
<jtaylor> mapreri: it would be better to bring it up in debian first
<jtaylor> if its good for ubuntu its most likely good there too and we don't need to maintain another diff
<mapreri> jtaylor: bringing change to debian is always better, but often debian maintainer are not responsive on bugs: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661602
<ubottu> Debian bug 661602 in varnish "varnish init script leaves pid file behind" [Normal,Open]
<mapreri> I don't think this worths a NMU...
<jtaylor> maybe just ping the bug again, its possibly just been overlooked
<mapreri> jtaylor: so, I'm emailing the bug, let's see what happen
<infinity> jtaylor: Hrm, did you see Andrea's followup to your sin() bug?  Might need to dig deeper. :/
<infinity> jtaylor: Can you reduce a smaller testcase that doesn't involve python/ffi?
<jtaylor> I wanted to check it again soon
<jtaylor> can you reproduce it?
<jtaylor> the testcase is quite easy to run in an trusty chroot
<infinity> jtaylor: Haven't tried, but I assume I can reproduce it on Ubuntu, where you did.
 * infinity does so now.
<jtaylor> I can try changing compiler
<infinity> jtaylor: Your debugging instructions leave something to be desired.  If you're sure it's sin() acting up, you'd think a 2-line testcase in C would be less hassle than indirection through python?
<jtaylor> you'd think
<jtaylor> I failed to create a C testcase
<jtaylor> I'm guessing something run during cffi tests changes the rounding mode and screws things up
<jtaylor> I didn't find what
<jtaylor> regardless of rounding mode change the result should not be that wrong
<jtaylor> I guess I could try and hunt down all libc calls done by cffi
<jtaylor> but the time might be better spent by someone knowing this code just running cffi maybe he/she sees the issue a lot faster
<directhex> how often does update_output update?
<infinity> directhex: Same frequency as update_excuses.
<directhex> ...
<infinity> directhex: Whenever the publisher runs and the archive changes is the correct answer.
<infinity> directhex: Which is anywhere from once every 5 minutes to once every half hour, to once every many hours on lazy weekends.
<Laney> directhex: Look at excuses first, anyways
<Laney> (which will be confused until mono gets out of NEW on i386)
<Laney> (also blocked by the freeze)
<Noskcaj> Do we want to sync http://packages.qa.debian.org/r/ruby-tilt.html ?
<Noskcaj> Apparently the 2.0 release broke a lot of things
<Noskcaj> slangasek, the glm ftbfs is fixed in the new upstream bugfix release. It requires manual refreshing of a patch, so i can't package it.
<Noskcaj> (i pinged you since you were the last ubuntu uploader of it)
<slangasek> Noskcaj: I may have uploaded the package in the past, but it's in sync now, so there's no reason to look at me in particular :)
<Noskcaj> just wondering if you new the package very well.
<Noskcaj> Can someone please update glm? should fix the ftbfs
<slangasek> what testing have you done of the new version of the package?  Have you checked whether a FFe is needed for the new upstream version?
<Noskcaj> Just test building both versions in a PPA. And it's a very minor release change, i'll find the changelog now
<slangasek> have you checked whether the problem is reproducible on Debian unstable?
<Noskcaj> debian built fine two weeks ago, so i doubt it
<doko> kenvandine, the bug submitter for bug #1269978 did ping me. could you have a look?
<ubottu> bug 1269978 in Adium Theme Ubuntu "automatic scrolling to new messages broken with recent webkit" [Undecided,New] https://launchpad.net/bugs/1269978
<kenvandine> doko, sure
<Noskcaj> My only point is the current release failed to build in my PPA, the new release built, and http://paste.ubuntu.com/6991073/ is the changelog
<slangasek> Noskcaj: well, #5 is already listed as having been cherry-picked into the current package, and I don't see how any of the other changes listed there would have fixed this build failure... and the current version of the package doesn't fail to build for me locally either
<Noskcaj> strange
<Noskcaj> How much memory did the build use for you? The ftbfs log seems to be that the build froze for some reason
<Noskcaj> as was my failure, and building it locally made my pc crash
<slangasek> the memory usage isn't problematic; 1.2G or so
<slangasek> well, and growing
<slangasek> but that's for the 'matrix' test, which isn't where it broke in the build test
<slangasek> Noskcaj: so at this point I would conclude that the build failure is intermittent, and unless someone can reproduce it locally I don't think we should conclude that a new upstream version is a proper fix
<Noskcaj> makes sense
<directhex> can someone please purge the ppc64el binary packages from src:mono? it isn't usable, and should never have been considered ready for an LTS
<jtaylor> infinity: fwiw I just build package libc with -Og and the issue is gone :(
<infinity> directhex: Perhaps if the packaging didn't ignore its testsuite...?
<infinity> directhex: That would seem much saner than arch-restricting it, then people could SEE the problems and put in the porting effort.
<directhex> infinity, i could make some specific test failures critical
<infinity> directhex: pinvoke*?
<infinity> Anyhow, "just removing mono" isn't as simple as that.
<directhex> infinity, pinvoke.exe is the main one, the others are edge casey
<infinity> It has a ton of rdeps.
<directhex> &*^&(%^%
<infinity> directhex: So, we can clean this up.  I'm just multitasking a bit too hard right now.
<infinity> directhex: But, while you could yell at doko for enabling it in the packaging, I think it's pretty sane to suggest that your package shouldn't ship kown-broken binaries.
<infinity> Running a testsuite and then ignoring it is a bit pointless. :/
<jtaylor> can one emulate ppc64el somehow now?
<jtaylor> still would like to know whats going on with numpy on tat platform
<jtaylor> (it ignores its testsuite result ...)
<mwhudson> how is the platform with mis-aligned accesses?
<infinity> qemu-system-ppc64 doesn't seem to quite do the trick on x86, last I tried.
<mwhudson> i think numpy luurves mis-aligned access
<jtaylor> mwhudson: yes but it works on platforms which bus error on missaligned
<mwhudson> ok
<jtaylor> considerable effort is spent on keeping it working
<jtaylor> (too much in my opinion but ...)
<jtaylor> I guess its actually the long double patch ubuntu carries
<jtaylor> but thats just guessing
<jtaylor> if someone can give me a backtrace I can have a look
<jtaylor> hm latest log doesn'T show a crash anymore :O
<jtaylor> nice probably was an issue somewhere else then
<Unit193> https://launchpadlibrarian.net/166777028/dropbear_2013.60-1ubuntu1_2013.60-1ubuntu2.diff.gz That presumes the only reason to put dropbear in the initramfs is if you have something in crypttab, not taking into account if DROPBEAR is set to y or n.
<Unit193> http://paste.openstack.org/show/x2OknRbbgwzf0Fyov8u8/ perhaps something like that would be better?
#ubuntu-devel 2014-02-25
<xnox> cjwatson: is there any way to run memtest on an uefi based machine?
<xnox> or should i force it booting with bios? (not sure if it can)
<psusi> xnox, there was a multiboot build of memtest iirc... maybe grub-efi can load a multiboot image?
<cjwatson> memtest upstream isn't willing to build both bios and uefi support into the same version, afaict
<cjwatson> so I think the answer is no
<cjwatson> multiboot might let you start the binary, but I don't think it makes it work :-)
<psusi> is there a uefi build of memtest then?
<cjwatson> I don't think so :(
<cjwatson> not one I've seen anyway, been a while since I cared to look
<xnox> cjwatson: http://www.memtest86.com/download.htm appears to claim uefi support. I'll try that one out.
<cjwatson> ok ...
<xnox> cjwatson: blimey, it has bling and 3d mouse pointer and everything.
<xnox> cjwatson: it's an efi executable by the looks of things.
<xnox> =(((( errors are popping up....
<hallyn> slangasek: hi, regarding the move of OVMF.fd.  Does that require a Replaces: ?
<hallyn> Or is it ok bc it's from the same source pkg?
<hallyn> no i guess it'll need it.  that's for tomorrow i think
<hallyn> slangasek: d'oh, nm - I was looking at the wrong version.  I see you did it.  sorry.
<slangasek> hallyn: it does require replaces: - but see mjt's request to put the symlink in the ovmf package
<pitti> Good morning
<RAOF> pitti: Good morning!
<ion> that
<Unit193> mvo: Hello.
<mvo> hey Unit193 - uhhh, I still have a upload that needs to be done, right?
<mvo> (sorry!)
<Unit193> mvo: Just needed to make sure a desktop file was fit for the package, yep: https://bugs.launchpad.net/bugs/1060543
<ubottu> Launchpad bug 1060543 in software-properties (Ubuntu) "Additional Drivers is not discoverable in Quantal" [Critical,In progress]
<Unit193> (Anywho, shower now)
<pitti> infinity, slangasek: FYI, I changed the ppc64el tests to run with apt clone; so no aufs/overlayfs any more
<Mirv> zyga: you should find bug #1282257 fixed now with 12.04 + SDK PPA
<ubottu> bug 1282257 in qtchooser (Ubuntu) "qt4 and qt5 dev tools can't be installed together on 12.04 from the ubuntu-sdk-team PPA" [High,Fix released] https://launchpad.net/bugs/1282257
<darkxst> xnox, bug 1284496: any idea what is causing that "half" gear, its surely not GNOME
<ubottu> bug 1284496 in casper (Ubuntu) "Booting the Ubuntu GNOME live DE from the advanced boot menu results in a largely unusable DE" [Undecided,New] https://launchpad.net/bugs/1284496
<dholbach> good morning
<ion> that
<zyga> Mirv: thank you
<pitti> doko: I fixed python3.4's autopkgtest to also work in containers (i. e. on ppc64el): http://paste.ubuntu.com/6993709/
<pitti> doko: do you want me to upload that, or do you just want to stage it in the Debian VCS?
<pitti> doko: same problems/fix on 2.7 and 3.3, I can prepare and test debdiffs if you want
<doko> pitti, would like to fix it in debian. will take your patch, and stgraber is scared by python anyway ...
<pitti> doko: stgraber? :-)
<pitti> doko: oh, I'm not planning to ask for a freeze exception for this; it's irrelevant for beta-1, I'm just walking through the ppc64el failures
<doko> he has a cold ;p
<pitti> doko: I'll prepare/test corresponding patches for 2.7 and 3.3 and hand them to you then, ok?
<doko> pitti, yes, that would be nice. can you change this for the two other tests as well?
<pitti> doko: sorry, which two other tests?
<doko> ahh, only in 2.7 and 3.3
<pitti> doko: in 3.4 there's just testsuite and testsuite-dbg
<doko> yep, should be added there. using this to catch progressions
<doko> applied for 3.4 locally
<pitti> doko: ah, I see the "failing-tests" in 3.3; yes, will apply to those as well of course
<pitti> doko: these aren't in 3.4, so I didn't know what you mean at first
<doko> pitti, now added in 3.4
<pitti> doko: thanks; I confirmed that it still works in qemu, too
<pitti> doko: btw, would you mind fixing Vcs-* for python3.4? the ones at http://packages.qa.debian.org/p/python3.4.html don't work any more
<doko> ohh, not yet created
<pitti> doko: http://people.canonical.com/~pitti/tmp/python2.7.lxc-autopkgtest.debdiff and http://people.canonical.com/~pitti/tmp/python3.3.lxc-autopkgtest.debdiff
<MacSlow> mhall119, hey there... do we have a developer-doc publishing process? I'm asking because I want know where to put my developer-docs for UbuntuTouch notifications.
<MacSlow> mhall119, or can I just use the wiki as usual
<doko> pitti, thanks, applied
<xnox> pitti: so i did a mechanical port of ofono-scripts from python2 to python3. https://code.launchpad.net/~xnox/ubuntu/trusty/ofono/python3/+merge/208117 and it seems to mostly work.
<xnox> pitti: can you test it a bit more? i don't quite know how to drive them and/or what the expected results should be.
<pitti> xnox: oh, I'm currently at porting them
<pitti> xnox: yes, the mechanical import is overzealous
<pitti> I want to keep them bilingual to submit them to upstream
<pitti> (I assigned the bug to me earlier)
<pitti> xnox: yes, I'll test them
<pitti> xnox: did you send anything upstream already? AFAICS there is only the ML, no bug tracker
<pitti> xnox: I'll send my formatted patches, just want to refer to your post if you did already
<xnox> pitti: nah, i didn't send it through.
<xnox> pitti: i was not convinced about keeping them bilingual.
<pitti> might be more palatable for upstream though, and not hard to do
<xnox> pitti: looking at the port however, adding "from __future__ import print_function" below all shebangs should be sufficient to keep them bilingual.
<pitti> I didn't do that, I just converted the few examples of print "foo", e to print("foo %s" % e)
<pitti> (in the except: clauses); everywhere else it was already ok
<xnox> pitti: also a few scripts used pygobject, so i've ported that go gi
<xnox> pitti: i see =) fair enough.
<pitti> *nod*
<xnox> pitti: i think in like apparmor, i kept compat from 2.3 - 3.2 by using sys.stdout.write("%s\n" % foo)
<xnox> but that was pain =)
<pitti> xnox: yeah, I usually do that to replace print >> sys.stderr, "..."
<pitti> i. e. sys.stderr.write("...\n")
<xnox> yeap.
<OdyX> tkamppeter: I've uploaded cups-filters 1.0.46-1 and cups 1.7.1-6 to unstable. They both have code to migrate the LOAD_LP_MODULES handling to cups-filters where they belong and there's quite a bunch of work for the systemd socket activation + exit-on-idle (which I took from you, but renamed according to upstream feedback). I'm interested in merging reasonable patches for the upstart support in Debian (although I have hard time seeing who would r
<pitti> xnox: it seems  lp:~phablet-team/ofono/ubuntu is the official branch?
<xnox> pitti: i dunno =) but looks like it might be.
<pitti> rsalveti: ok, now I'm confused :)
<xnox> pitti: i'd ask sergiusens =)
<pitti> so confused that I'm even pinging the wrong person
<pitti> sergiusens: so now I'm confused; I did the py3 port against git://git.kernel.org/pub/scm/network/ofono/ofono.git
<pitti> sergiusens: and I'm about to port it to lp:~phablet-team/ofono/ubuntu
<sergiusens> pitti, we moved to git to share with jolla
<pitti> sergiusens: (older version, packaging changes, and I want to sneak in a fix for making it possible to purge ofono-phonesim-autostart)
<pitti> sergiusens: so what is that github branch?
<sergiusens> pitti, and have something that syncs in to our bzr branch
<tkamppeter> OdyX, great. For Upstart the main problem is bug 1276713, I hope, xnox can help here.
<ubottu> bug 1276713 in upstart "upstart socket activation for cups" [Undecided,Confirmed] https://launchpad.net/bugs/1276713
<sergiusens> pitti, that github branch is the ofono/ril spinoff (awe is trying to keep the code sane to propose an upstream merge sometime)
<pitti> sergiusens: but apparently our packaging branch isn't based off that rilmodem github branch? at least our packaging branch doesn't have test/rilmodem/
<OdyX> tkamppeter: ideally, prepare these patches in a master-ubuntu branch that has the current master branch merged; I'd review and include them
<pitti> sergiusens: so you need the tests ported (and extended to cover test/rilmodem/) against that github branch, plus backporting the test to our bzr packaging branch?
<sergiusens> pitti, one sec, looking for the documentation for this (it's a big sync mess)
<OdyX> tkamppeter: I've also done the same patch replacement than you did for -5ubuntu3
<sergiusens> pitti, lp:~phablet-team/ofono/rilmodem that's where the github repo is imported to
<sergiusens> I'm plus 1 for an ofono-ril source package; but you need to take that to rsalveti ;)
<pitti> sergiusens: ok, so I'll port the bits to the github branch and do a pull request; then, how does this get into the packaging branch?
<sergiusens> pitti, and this is the https://code.launchpad.net/~phablet-team/ofono/ubuntu
<sergiusens> packaging
<sergiusens> pitti, this may be a bit outdated, but goes over the flow https://docs.google.com/a/canonical.com/document/d/1Sigl_2iJyNc7VDC3HMVylSEDRLGoKncVAMNAhkicqW8/edit#heading=h.myx0y9f6p5ah
<pitti> sergiusens: ok, thanks; I'll look a that after lunch
<sergiusens> pitti, in any case; if you make the pull request on github, awe and rsalveti will make it land into the archives
<cjwatson> Hm.  Is there really no way to throw an exception from a finally block in Vala?
<cjwatson> That's less than helpful when your finally block consists of things that might fail ...
 * cjwatson redesigns a bit
<tkd> hm, i'm trying to track down the source of a SIGABRT in ldconfig (saucy), but the binary is stripped and the libc6-dbg package no longer ships the symbols for /sbin/ldconfig.real. is this intentional?
<mhall119> MacSlow|lunch: API docs?
<MacSlow> mhall119, yes... API/guideline docs
<kgunn> doko: ping
<mhall119> MacSlow: you can publish them using the JSON API if can get them in the right format
<mhall119> MacSlow: are they qdoc?
<MacSlow> mhall119, ehm... nope
<MacSlow> mhall119, what's a good example of how that should look like... and can it deal with images... as pure text would be  a bit "dry" :)
<mhall119> MacSlow: no image support yet, I need to learn ceph or whatever we use internally
<MacSlow> mhall119, old / NotifyOSD docs are https://wiki.ubuntu.com/NotifyOSD and I kind of assume knowledge of that and mainly point out differences, provide examples... it's not written like plain API doc as that would be just replicating libnotify's doc.
<MacSlow> mhall119, but I can see how far I can get with that JSON API stuff
<MacSlow> mhall119, another "issue" is the fact that we don't have QML-bindings for notifications yet. So it doesn't blend well with the regular SDK-doc
<mhall119> MacSlow: ah, ok, those aren't really "API Docs" the way I think of them
<mhall119> MacSlow: really the only think we'd want in the API docs website is QML bindings API docs
<MacSlow> mhall119, so would a dedicated wiki-page be sufficient then?
<mhall119> yeah, I think so
<mhall119> this doesn't look like is for app developer consumption for the most part
<MacSlow> mhall119, ok... at least I know where to go once we have QML-bindings
<mhall119> yup
<mhall119> and we would very much like to get those QML bindings :)
<MacSlow> mhall119, notifications are meant to be used by 3rd-party developers
<MacSlow> :)
<pitti> sergiusens: ok, sent https://github.com/rilmodem/ofono/pull/56
<mhall119> MacSlow: right, but 3rd party developers don't care about the spacing inside the bubble or how they are stacked on screen
<MacSlow> mhall119, still they want to be able to trigger notifications... so they need some guidance/examples to copy&paste from :)
<sergiusens> pitti, fwiw I'm ok with py3 only
<sergiusens> pitti, out of curiosity, you don't need to import print_function anymore for py2?
<pitti> sergiusens: in py2 it's just a statement which prints a tuple with a single element :)
<sergiusens> ah
<pitti> or rather, just a parenthesized expression, not a tuple
<pitti> sergiusens: which is why print(a, b) doesn't work (looks odd) in py2, and thus I avoided that syntax
<pitti> sergiusens: and replaced it with "foo %s" % exception
<sergiusens> ok, that works for me
<cjwatson> I still prefer using print_function anyway
<cjwatson> Since I have nothing that cares about pre-2.6 any more
<cjwatson> (And, honestly, I'd be quite surprised if anyone else here *really* did)
<doko> pitti: gobject-introspection should run autreconf
<cjwatson> Well, aside from launchpad-buildd.  Hopefully that'll be fixed soon...ish
<doko> checking whether the gcc linker (/usr/bin/ld -m elf64ppc) supports shared libraries... no
<pitti> doko: yes, sorry; that's done in -3, I thought it already imported -3 but LP didn't yet
<pitti> doko: I'll sync -3 once it's imported, until then it'll get stuck in -proposed
<kgunn> doko: i understand you might be a good person to talk to about this bug https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1284653
<ubottu> Launchpad bug 1284653 in valgrind (Ubuntu) "valgrind packages ouf of sync with current glibc version (2.19)" [Undecided,New]
<kgunn> just shew me away if its something you're already working on...
<slangasek> pitti: apt-clone> ok, cool.  Are the failed ppc64el tests going to be re-run?
<slangasek> doko: can you please take a look at the valgrind bug kgunn mentions above?
<doko> slangasek, sure, might be tomorrow
<kgunn> doko: appreciate it....our ci is blocked until then...thanks
<slangasek> doko: if this is blocking CI, we need to get it addressed today.  Do you know if this should be fixable with a valgrind rebuild?  (seems unlikely to me)
<doko> ave to look
<pitti> slangasek: I re-ran a lot of them already, but if I missed some I'm happy to retry more
<pitti> slangasek: I didn't really see any which failed specifically for overlayfs
<pitti> slangasek: I retried upstart, eglibc, and some usual  suspects
<slangasek> pitti: ok, so the latest runs of https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest%20ppc64el/job/trusty-adt-coreutils-ppc64el/ were done with the new setup?
<pitti> slangasek: right
<slangasek> ok, thanks
<pitti> slangasek: as I said, the failures are independent of the overlay
<pitti> slangasek: we'll probably just drop these two tests, if they don't work in LXC; this is already just a subset of the upstream tests anyway
<pitti> slangasek: I fixed some 5 other tests yesterday and today, but I can't do that single-handedly
<pitti> slangasek: FYI, I fixed the python{2.7,3.3,3.4} issues, doko committed the patch to Debian; so the next upload should fix those
<slangasek> pitti: spiff
<pitti> slangasek: also, there's quite a lot of failures which are due to nonexisting packages, such as valgrind or odbc
<pitti> I guess these already count as "real" problems
<bdmurray> mpt: your addition of the milestones adds empty space in the graph for the future milestones, is that intended?
<pitti> slangasek: I haven't yet walked through all of the failures, just perhaps 1/4; most failures are indeed due to missing dependencies, not really ppc specific (aside from the uninstallabilities)
<pitti> slangasek: so generally this is looking mostly good
<slangasek> pitti: valgrind would need porting, and tests should probably do something sensible on architectures where it doesn't exist
<pitti> slangasek: ah, ok
<slangasek> pitti: what's the odbc problem?
<slangasek> unixodbc is certainly available
<pitti> e. g. http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest%20ppc64el/job/trusty-adt-psqlodbc-ppc64el/4/console
<pitti> E: Package 'odbc-postgresql' has no installation candidate
<pitti> https://launchpadlibrarian.net/167155126/buildlog_ubuntu-trusty-ppc64el.psqlodbc_1%3A09.02.0100-2ubuntu1_FAILEDTOBUILD.txt.gz
<pitti> test failures
<pitti> psqlodbcw.so' : file not found
<pitti> or rather, some build failure
<slangasek> pitti: ah, well, the problem is trying to run the autopkgtest for a package which has itself not been built for the arch :)
<pitti> right
<cjwatson> .so file not found> /me guesses out-of-date libtool macros without even looking at the log :)
<pitti> cjwatson: *nod*
<cjwatson> Grr, https://bugzilla.gnome.org/show_bug.cgi?id=558620 is annoying
<ubottu> Gnome bug 558620 in introspection "Add default values" [Enhancement,Assigned]
<doko> slangasek, valgrind uploaded, untested. afk now until the late evening
<slangasek> doko: ok, thanks
<pitti> YokoZar: is there any progress with getting 1.6 out of -proposed? AFAIK that required some hinting in britney?
<pitti> slangasek: e. g. the exim4 one is easy, just missing dependency; exactly the same problem in http://ci.debian.net/data/unstable-amd64/packages/e/exim4/2014-02-22.log
 * pitti goes to fix and file a bug to Debian
<seb128> hum, why is britney (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#empathy) saying
<seb128> out of date on ppc64el: empathy, empathy-dbg, mcp-account-manager-goa, nautilus-sendto-empathy (from 3.8.6-0ubuntu4)
<seb128> where
<seb128> https://launchpad.net/ubuntu/+source/empathy/3.8.6-0ubuntu4
<seb128> https://launchpad.net/ubuntu/+source/empathy/3.8.6-0ubuntu5
<seb128> it's depwait on ppc64el on both versions
<pitti> so out-of-date sounds quite right?
<cjwatson> britney's still looking at the bootstrap archive for its "before" state
<cjwatson> I mean, the pre-rebuild archive
<seb128> so it needs an overwrite?
<xnox> cjwatson: shouldn't that be reverted now...
<cjwatson> No, it means it used to build before we rebuilt the world and now doesn't
<seb128> pitti, well, the error suggests it think it's a regression and is blocking it due to that
<cjwatson> So this is actually one of the things it *should* be catching IMO
<seb128> cjwatson, it briefly built when we changed the arch lists from a limited set to "all", but that created uninstallable binaries (depending in qtdeclarative)
<xnox> cjwatson: i think it's a false positive, as the chain of dependencies gained a depwait on qml.
<cjwatson> Oh, mind you, gnome-control-center-signon ... yeah
<seb128> cjwatson, we reverted to the old archs list
<seb128> but we might have binaries leftover to delete then?
<cjwatson> No
 * seb128 wants qt5.2
<cjwatson> Anyway, infinity said he was going to look through the list of differences ASAP and check whether anything needed to be saved to avoid rebootstrapping
<cjwatson> Because it's not just proposed-migration, the chroots are still pointed at the pre-rebuild archive for build-deps AIUI
<cjwatson> So I'd prefer to let him finish tha
<cjwatson> t
<seb128> ok
<seb128> empathy is blocked by beta freeze anyway
<seb128> so no hurry
<seb128> cjwatson, thanks
<doko> 5.2 is an odyssey
<cjwatson> Does anyone actually have a current list of what's blocking 5.2?
<Laney> thought I saw something go by in my release mailbox
<seb128> Mirv send status updates on the phone list
<Laney> https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1278329
<ubottu> Launchpad bug 1278329 in qtxmlpatterns-opensource-src (Ubuntu) "[FFe] Qt 5.2" [Undecided,New]
<mitya57> cjwatson: two bold items in http://pad.ubuntu.com/qt52-dependencies
<seb128> ah, the bug Laney pointed has a the update from yesterday
<seb128> "multimedia on Ubuntu Touch"
<seb128> we need to get rsalveti & co look at that :p
<Laney> it's not really precise
<seb128> https://bugs.launchpad.net/ubuntu/+source/qtmultimedia-opensource-src-touch/+bug/1271192
<ubottu> Launchpad bug 1271192 in ubuntu-touch-meta (Ubuntu) "Update qtmultimedia dependencies for Qt 5.2" [High,Confirmed]
<seb128> but that doesn't have lot of details either
<seb128> out of "need to be ported to qt 5.2"
<doko> what worries me more is that we have absolutely no status what else besides the phone will break
<sergiusens> pitti, didrocks hey, if wanted debug syms for https://launchpad.net/ubuntu/+source/qtubuntu-camera how would I get them (if created at all)
<seb128> doko, not a lot out of the phone is using qt5
<seb128> sergiusens, http://ddebs.ubuntu.com/pool/universe/q/qtubuntu-camera/
<seb128> sergiusens, seems like they are in the normal ddebs archive?
<sergiusens> seb128, thanks
<seb128> sergiusens, yw!
<pitti> sergiusens: they are in ... what seb128 said
<pitti> doko: ah, LP imported it, fixed in https://launchpad.net/ubuntu/+source/gobject-introspection/1.39.90-3
<pitti> slangasek: https://jenkins.qa.ubuntu.com/job/trusty-adt-bluez-ppc64el/6/console is an interesting failure, that smells like an actual problem
<xnox> doko: there only are like 5 things outside of ubuntu phone that use qt5.
<xnox> in the archive...
<Laney> currently
<xnox> Laney: doko: but they are also known to work, since debian is on 5.2 for a long time.
<Laney> does Debian have a KDE which uses Qt 5?
<Laney> & that's in exp only isn't it?
<xnox> Laney: nobody has it, and neither will we. Framework5 is aimed to be released after 14.04 is released, and kubuntu is planning to provide a backport/ppa to be able to run framework on top of 14.04 base.
<xnox> Laney: thus if either of the two turns out to be incompatible, framework5 has time to fix it in devel, and qt5.2 will need srus. but that's a given. It is known that Framework5 will ideally want 5.2, thus having 5.2 by default is desired by all parties involved in trusty.
<Riddell> 5.2++
<Laney> I'm not denying that it is a desirable state to aim for. The point is that it's quite late and all of the testing so far has been phone focused.
<Riddell> from the KDE side we need 5.2, 5.0 doesn't work with our stuff
<xnox> Laney: correct, there is no other testing we can do to be honest, as there just aren't anything out there that uses qt5 yet. I mean, you can try running pokerth, but that thing is like always borked =))))
<xnox> Riddell: did you try running it against the canonical-edgers ppa with 5.2 ?
<xnox> (or at least rebuild against it)
<xnox> the whichever Neon builds out there?
<Riddell> xnox: yes, it only builds if using that ppa
<xnox> Riddell: perfect! ship it! =)
<zteam> Hi guys!
<zteam> I just wanna ask a simple question
<zteam> I have a quite annoying bug in Ubuntu 13 (I assume) with Lightdm which I'm unable to resolve would it make sense to file a bug-report on that  considering 14.04 is just a around the corner, or would that just waste the developers time?
<ogra> zteam, is it fixed in 14.04 ?
<xnox> zteam: you should just ask / describe your bug straight off the bat. there is little benefit discussing "what ifs" =)
<zteam> ogra,  I have no idea, and I don't have powerful enough hardware to test in a Virtualbox either :-)
<ogra> zteam, well then you should file it in any case to make sure it can get fixed in 14.04 (if it is still present there)
<xnox> zteam: there are like ~300 people here running 14.04.... and we are yet to hear what the bug is =)
<ogra> and that :)
<zteam> xnox, sure my problem is that my Ubuntu 13.10 installation sometimes forgets to start up LightDM, and instead just give me a black screen it, so I have to go to a terminal and run "sudo service lightdm restart" to get LightDM to run
<xnox> zteam: are you using Ubuntu / Unity, or e.g. Lubuntu, Xubuntu, Mint, etc?
<zteam> xnox,  I have been asking about this in the Ubuutu channel and people have examined my logfiles, but no one have been  able to give me a working solution
<zteam> xnox, I'm using Unity, but I also have XBMC installed (and selectable from LightDM)
<xnox> zteam: please file a bug using: ubuntu-bug unity-greeter
<xnox> zteam: that should attach everything that's necessory.
<zteam> xnox, Okey, I should add that this happens quite rarely, last time it happend was about one week.
<zteam> xnox, will that tool collect the .old logfiles as well?
<xnox> zteam: it should collect all that's useful.
<c_korn> hello, if a website uses gzip for delivering the content, how can I debian/watch to do this properly? e.g. wget "http://byuu.org/" -O- -q | zcat
<roaksoax> cjwatson: howdy! I think you can help me with this. Is there a way to preseed a value from a package we are installing to one of its dependencies"?
<roaksoax> cjwatson: for example, i want to install: sudo apt-get install X, but X depends on Y, and I want to preseed the value of Y so it does not show a particular debconf note
<cjwatson> roaksoax: No, use some method other than preseeding
<roaksoax> cjwatson: what method would that be?
<cjwatson> No idea, depends on the package
<cjwatson> If X depends on Y then there's no guarantee whatsoever that any of X's code would run before Y is installed
<cjwatson> Much less before Y's preconfiguration happens, which could be arbitrarily early
<roaksoax> cjwatson: Right. makes sense.
<cjwatson> (dpkg-preconfigure doesn't sort packages in any kind of dependency order, and doesn't really have the information needed to do so anyway)
<cjwatson> pitti: Do you have any recommendations for doing some kind of equivalent of unittest.mock in Vala unit tests?
<cjwatson> Google is not helping
<roaksoax> cjwatson: thanks!
<cjwatson> roaksoax: (your problem may be insoluble, or at least may require significant reworking of how Y does things)
<cjwatson> I'm not aware of people being particularly successful at this in the past - it's generally been a mess when people have tried IIRC
<roaksoax> cjwatson: so, what if I change the priority of such debconf note to medium. Would it still be shown in the installer but not on an apt-get install?
<Saviq> any idea why I can't launch empathy recently, which is complaining about non-existent libwayland-egl.so.1?
<Saviq> had to symlink libwayland-egl.so
<Noskcaj> Can someone look at https://code.launchpad.net/~noskcaj/ubuntu/trusty/ekiga/ftbfs/+merge/208221 ? It should fix the i386 and ppc64el build failures
<zteam_> So I created a bug report about my LightDM issue, would apprcieate very much if someone can have a look at it :-) https://bugs.launchpad.net/ubuntu/+bug/1284826
<ubottu> Launchpad bug 1284826 in Ubuntu "LightDM fails to start randomly" [Undecided,New]
<Noskcaj> zteam_, I've changed it so it actually affects lightdm
<hallyn> just curious, does anyone do anything with workman (https://gitorious.org/workman/pages/Home) ?
<hallyn> hm, maybe workman is obsoleted by systemd
<hallyn> oh, yes it was - https://www.redhat.com/archives/workman-devel/2013-July/msg00007.html
<zteam_> Noskcaj, thanks, I personally have no idea, whetever, LightDM or unity-greeter is the root of my problem :-)
<Noskcaj> zteam_, Next time you file a bug, use "ubuntu-bug PACKAGE". But it's good you attached the logs.
<zteam_> Noskcaj, belive me I trieed too...
<Noskcaj> ok
<zteam_> Noskcaj, sudo ubuntu-bug unity-greeter
<zteam_> [sudo] password for zteam:
<zteam_> (process:8032): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
<Noskcaj> oh
<zteam_> yep, that's what I felt too, a crasing bug-report tool :P
<infinity> zteam_: Why would you run it as root?
<zteam_> infinity, becuase I assumed the reeson it crashed the first time was it didn't had permission to read some logfiles
<zteam_> infinity, the first time I ran it I just I did ran ubuntu-bug unity-greeter, but then it didn't worked I thought, it was uable to reach some logfiles
<zteam_> infinity, :-)
<Noskcaj> Could someone please do some work on the sponsoring queue? It's getting fairly full, mostly with bugfixes
<cjwatson> roaksoax: the installer uses the same debconf priority as the regular system (high), so no
<slangasek> pitti: https://jenkins.qa.ubuntu.com/job/trusty-adt-bluez-ppc64el/6/console > does module loading work in the test env, and do you have linux-image-extra installed (or better, the linux-image-generic metapackage)?  I reproduced a failure here, but only because bluetooth.ko was missing
<infinity> pitti: Should I be seeing armhf and ppc64el configurations on https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-eglibc/
<infinity> pitti: Or is that coming $later?
<infinity> Oh, maybe that's just the britney-triggered ones?
<infinity> Where do I find the non-britney runs?
<infinity> pitti: Ahh, nevermind.  Going up one level, I found armhf and ppc64el in their own little worlds.
<infinity> pitti: Okay, so the eglibc/armhf failure looks like armhf is still using overlayfs?
<infinity> pitti: The ppc64el failure, though, is completely unexpected and weird...
#ubuntu-devel 2014-02-26
<LinuxPC> Does anyone know of an app to use to connect my LG cell phone to my HP Laptop, so that I can transfer files between the 2 devices?
<LinuxPC> I am using Ubuntu 12.04 on my laptop
<sarnold> LinuxPC: if you have bluetooth in both you can probably use a bluez-provided obex transfer mechanism
<sarnold> LinuxPC: there are a variety of webserver kinds of applications available for many cell phone operating systems, if you can configure one of those you may be able to then use wget --mirror or similar on your laptop..
<LinuxPC> i will give that a try
<LinuxPC> thanks
<YokoZar> pitti: Err I hadn't looked into it further, I suppose that means I'm supposed to nudge you
<Noskcaj> what happened to qa.ubuntuwire.com ?
<geser> Noskcaj: what's wrong with it? It's available for me
<pitti> Good morning
<pitti> cjwatson: vala mocks> I'm afraid I don't have a recommendation; I haven't used mocks in Vala myself yet, but you might be able to use cmocka?
<pitti> slangasek: I figure containers can't do modprobe
<pitti> slangasek: so that's a test which we need to mark as "does not work in containers" then
<Noskcaj> geser, all the parts pointed to qa.ubuntuwire.org no longer work. e.g. reverse-depends
<Noskcaj> and my bookmark of the ftbfs list
<pitti> infinity: right, ppc64 is using clone, no overlays; arm is using overlayfs still
<pitti> infinity: yes, the arm/ppc64 jobs live in their own sections instead of being part of the matrix job, mostly because we don't gate on them yet
<infinity> pitti: Right, okay, then the armhf/eglibc failure is an overlayfs grump (and why I use aufs instead of overlayfs for my sbuild schroots).
<infinity> pitti: I'll have to look at that bizarre ppc64el failure sometime though.
<pitti> infinity: aufs completely broke all ppc builds on Monday, so I reverted it
<infinity> pitti: Oh, super fun.  Can't win, I guess.
<infinity> (I use it on all arches here, but that's all arches except ppc64el, maybe there's a bug there that needs sorting)
<pitti> infinity: wiht that, upgrading python3.3 in the chroot failed with a dpkg "cannot rename file" error
<infinity> I guess I should test it in a ppc64el VM and whine at Andy.
<pitti> infinity: then I gave up and just use cloning; much slower, but avoids that kind of fun
<infinity> pitti: What was the backing store for your aufs?  ext4 on ext4?  tmpfs on ext4?  Any LVM in play?
<pitti> infinity: I had expected tmpfs on ext4
<pitti> no LVM
<infinity> LVM snapshots are, really, the least dangerous way to do what you're trying to do here, to be fair, it's just far more of a pain to set up.
<infinity> (Pot calling the kettle black, cause I should be using LVM for my sbuild/schroot setup too, and don't)
<pitti> infinity: well, everything which actually hits the disk is already slow
<pitti> infinity: on my laptop I build everything on tmpfs overlays (containers, schroots, etc.); way to go
<infinity> pitti: Yeah, I use tmpfs-aufs-on-ext4 on my laptop.
<dholbach> good morning
<Noskcaj> evening dholbach
<dholbach> hi Noskcaj
<Noskcaj> Could you please send another call for sponsors email sometime soon?
<dholbach> Noskcaj, you could send one as well? :)
<Noskcaj> i wasn't sure i was allowed to, plus you saying it will probably be heard by more
<dholbach> of course you are
<dholbach> I'm going to run around like a headless chicken for the rest of the day, because I have quite a lot of work ahead of me
<dholbach> so feel free to send the mail
<dholbach> and I'll follow up to it
<Noskcaj> ok, which list(s)?
<dholbach> ubuntu-devel@ should be good
<Noskcaj> ok
<geser> Noskcaj: I just checked again and for me both qa.ubuntuwire.com and .org work
<Noskcaj> strange
<seb128> infinity, thanks for fixing firefox/ppc!
<infinity> seb128: NP.  Tomorrow sometime (I hope), there should be a ppc porter back online too (that's where I did all my iterative test builds to burn it in)
<seb128> infinity, nice
<cjwatson> pitti: Mm, yeah, cmocka is the closest I've seen.  I suspect that I might actually end up borrowing ideas from it rather than using it directly
<cjwatson> pitti: Since I'm translating selected code from Python to Vala (this is in click), I was actually thinking of writing a crazy Python decorator which generates LD_PRELOADable libraries on the fly and re-execs single tests with them :-)
<cjwatson> pitti: But still need to experiment ...
<pitti> cjwatson: I'm not aware of anything resembling python-mock for Vala (would probably be rather difficult to do as C doesn't have the dynamism of py)
<pitti> cjwatson: what do you want to mock in particular?
<cjwatson> pitti: The equivalent of things in Python like (a) faking up os.stat/os.chown so that I can run ensure-file-ownership tests without root (b) installing a mock subprocess.call so that I can test which subprocesses a method would run
<cjwatson> http://paste.ubuntu.com/6998847/
<pitti> cjwatson: ah, that indeed sounds like LD_PRELOAD
<cjwatson> Yeah.  I was toying with translating the relevant bits of the test suite to Vala too, but I'm not sure that actually helps a whole lot, and I'd be more comfortable leaving the test suite in more or less its original state
<cjwatson> Dynamically generated LD_PRELOAD isn't going to be as convenient as mock.patch, but I *might* be able to get it to the point where it isn't a horrible wart
<cjwatson> Maybe
<pitti> cjwatson: crap's uid_wrapper (http://cwrap.org/#learnmore) provides something like this, but not for chown; but we don't have a package for cwrap anyway
<pitti> cjwatson: I guess you'd just need some extension of fakeroot which logs the calls and simply ignores them?
<cjwatson> Background: I'm translating bits of click from Python to Vala (could also be C but Vala worked out much easier) so that I can export a libclick to other bits of the phone middleware stack so that they don't have to use the slow exec("/usr/bin/click") path for certain queries - this is expected to save anything up to a second from app startup time
<pitti> cjwatson: actually, if you test this in-process instead of a separate process, you might just be able to define chown() etc. in your test, instead of going through the LD_LIBRARY dance?
<cjwatson> I have indeed also thought about the approach of making all the relevant calls go through some kind of function pointer scheme that I can substitute in the tests
<cjwatson> That's a bit more invasive though
<pitti> ah, like introducing a FileOp class with wrappers, which the test can subclass; but that would still only work in-process
<cjwatson> Yeah, and also it seems distinctly non-trivial to do in Vala
<cjwatson> It doesn't really want to assign to non-delegate functions
<pitti> cjwatson: so your tests are in-process?
<cjwatson> Yes
<pitti> cjwatson: if so, perhaps a cheap trick would be to link it to a test_posix.vapi which re-routes Posix.chown() and friends to your test wrapper?
<cjwatson> So, I only want to do this for certain tests, and I'd like to avoid having to relink libclick.so all the time
<pitti> (I haven't tried that myself, you might get some "already defined" error)
<cjwatson> i.e. I'd like to be able to run the tests against the genuine as-will-be-shipped libclick.so
<pitti> cjwatson: hmm; I think in the end a standalone LD_PRELOAD lib which logs the calls instead of executing them might be best
<pitti> it's not hard to do, and it will work for any programming language you might port click to in the future
<pitti> and it's very flexible as you can load it or not in different scenarios
<cjwatson> Yeah, provided relevant function names are reasonably stable anyway
<pitti> cjwatson: it's mostly chown, execve(), stat, and getpwnam()?
<cjwatson> I actually really like Vala, mostly, and I can sort of imagine how one might do a better mocking framework in it, but I think it needs extensions to the core language
<pitti> *nod*
<pitti> cjwatson: I like the language and design of Vala too; it just feels like its development got stuck halfway in, one hits rough corners quite often
<pitti> too bad
<pitti> it's quite understaffed as not that many projects are using it; chicken-egg
<cjwatson> Well, I sent a couple of trivial patches for it anyway :)
<xnox> since it's C# inspired, using similar syntax to established mock libs, e.g. https://github.com/Moq/moq4
<pitti> well, C# uses bytecode and a runtime interpreter/compiler, so there's more places to stuff in mocks
<pitti> vala is by and large just a transpiler to C, so there's no extra runtime layer to do modifications
<tvoss> cjwatson, is there a specific reason you have chosen Vala for libclick?
<pitti> but you can certainly do that in pricinple at compile time, by allowing vapis to get swapped out or partially overridden
<cjwatson> tvoss: Yes, I wanted gobject-introspection so that I had trivial bindings in Python because I'm only rewriting part of click, not all of it; I tried both C and Vala and the latter came out much more readable and compact
<cjwatson> I wanted to put just about zero effort into bindings
<cjwatson> pitti: Well, you could also switch around symbols at run-time in the kind of way cmocka does; doing that at the Vala layer would be helpful because it could make it type-safe
<cjwatson> And automatically clean up, etc.
<tvoss> cjwatson, well, we were rewriting the scopes engine to get rid of Vala. As pitti pointed out, it's kind of half finished
<cjwatson> tvoss: Different contexts, I think
<pitti> I use vala in umockdev for pretty much the same reasons: It's much more compact, utterly fast (essentially C speed), and I get automatic bindings
<pitti> and it effortlessly mixes C anc Vala code, so I can write the tricky bits (the preload library) in C
<cjwatson> tvoss: While I do need to solve the test-suite issues, this is mostly a matter of Vala failing to help me out rather than a matter of Vala getting in my way - I'd have the same basic set of things to solve in C
<cjwatson> tvoss: And I'm not prepared to use C++ for anything ever, sorry :-)
<pitti> yeah, C++ is an utter pain for libraries (aside from being comparatively hard to grasp)
<cjwatson> I'm also simply not skilled in it
<cjwatson> And I know better than to think I can teach myself it properly in a short time
<tvoss> pitti, I'm not sure that I agree that C++ is a pain for libraries
<cjwatson> As I say, I'm very happy with how the core libclick code looks in Vala
<tvoss> cjwatson, ack
<pitti> tvoss: well, it combines "brittle ABI" with "zero bindings for other languages"
<cjwatson> Also, I need to interface with code currently written in C/GObject; one of those projects is the most important client for this
<tvoss> pitti, define brittle ABI please, I think that's one of the most common misconceptions about C++
<pitti> I also find it comparatively hard to grasp, but I'm well aware that this may just be a personal grudge, and it's certainly not an objective argument
<tvoss> cjohnston, which one is that?
<cjwatson> tvoss: upstart-app-launch
<tvoss> cjwatson, ack
<cjwatson> tvoss: So you won't ever be asking us about symbol management issues again, then? :-)
<pitti> tvoss: it's way too easy to break the ABI inadvertently, unless you are really careful
<tvoss> pitti, zero bindings is not true, specifically generating python bindings for C++ and Javascript is super easy
<tvoss> cjwatson, I think the symbol mgmt. issue arises from our tools not being fit for the job
<cjwatson> I think that's simplistic
<tvoss> cjwatson, that's not a question or language property
<tvoss> cjwatson, I have to argue against that. I spent a fair amount of time on the symbols topic and dpkg-gensymbols is tailored towards a C world
 * pitti pulls himself out of the "my language is better" discussion before getting too deep in it; we all have our preferences ;)
<tvoss> cjwatson, which is perfectly fine, not argueing about that
<cjwatson> I think it would be more accurate to say that dpkg-gensymbols is tailored towards the ELF representation of the binary
<infinity> pitti: That python-cffi upload of yours, jtaylor thinks it's a toolchain bug.
<pitti> infinity: this one drives me crazy; I sbuilt it in trusty-i386, and I can't reproduce it
<infinity> https://sourceware.org/bugzilla/show_bug.cgi?id=16625
<ubottu> sourceware.org bug 16625 in libc "sin gives wrong result with 2.19 on i386" [Normal,New]
<infinity> pitti: Really?
<pitti> infinity: even without the most recent patch (which sounded related, but apparently wasn't)
<pitti> infinity: ooh, 2.19; I didn't build it in trusty-proposed
<pitti> infinity: so I guess that's what the difference was
<tvoss> cjwatson, well, it certainly does not take into account that all the stl symbols are weak, which leads to the massive blow-up in symbol file size
<pitti> infinity: ah, so -O0 helps, too?
<pitti> infinity: thanks for pointing out
<cjwatson> tvoss: Yeah, that's apparently subtle, did we point you at https://lists.debian.org/debian-devel/2012/01/msg00759.html ?
<infinity> pitti: Rebuilding glibc with -Og made the bug go away.  Not sure how much we can divine from that (and I haven't tried myself).
<pitti> infinity: well, it's not like I urgently need that cffi upload in release, I just need it in -proposed to stop DoSing the armhf/ppc64el test boxes; so it can just wait until that eglibc/gcc bug gets fixed
<cjwatson> And the followup  https://lists.debian.org/debian-devel/2012/01/msg00760.html
<tvoss> cjwatson, nope, no one pointed me there
<cjwatson> tvoss: (anyway, I actually think that's a relatively shallow issue, I only haven't dug into it myself because as I said my C++ experience is fairly weak, or more accurately I have a chunk of C++ experience but it predates the STL so isn't very useful in a modern world)
<Riddell> am I right in thinking you can't become and ubuntu-dev in whatever flaour without first being an ubuntu-member in whatever flavour?
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: feature freeze (+ beta1 migration block) | 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: seb12
<pitti> seb12, haha
<cjwatson> Riddell: when I was last involved with this, being a developer was considered to grant membership, rather than membership being a prerequisite
<Laney> Indeed, it's not a prerequisite
<ogra> yeah
<seb128> pitti, shrug :p
<cjwatson> Riddell: i.e. you must meet the criteria for membership to be in ubuntu-dev (or similar), but that doesn't mean you have to separately acquire membership first
* cjwatson changed the topic of #ubuntu-devel to: Trusty Alpha 2 released! | Archive: feature freeze (+ beta1 migration block) | 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
<ogra> it comes alongside though
<seb128> cjwatson, thanks ;-)
<Riddell> cjwatson: hmm, so if membership needs to wait 6 months minimum does that mean 6 months before you can become a developer?
<cjwatson> Riddell: now you're outside the set of things I remember from when I was on the DMB :)
<pitti> ah, I had a trimmed /topic halfway typed in, but cjwatson beat me to it
<cjwatson> the criteria for membership was traditionally "sustained and significant contribution", and six months was maybe a guideline for sustained I suppose
<xnox> Riddell: to become a developer, one needs to show a sustained contribution for more than one cycle, so yeah 6+ months is requirement for developers.
<cjwatson> criteria *were, sigh
<Laney> We recently changed the requirements so that you don't have to get membership to become a developer
<cjwatson> or *criterion was :)
<Laney> In some circumstances etc
<xnox> Riddell: i've seen that e.g. contributions to Debian could count as sustained contribution to ubuntu.
<seb128> is syncing on new packages to universe subject to feature freeze?
 * seb128 unsure
<Laney> One of the exclusions which might apply to Riddell is that flavour packagesets still require membership
<Laney> yes it is
<seb128> Laney, thanks
<Laney> np
 * dholbach hugs seb128
 * seb128 hugs dholbach back
<infinity> seb128: Subject to, but likely to get quick verbal exceptions for things that don't look super scary.
<seb128> infinity, noted, it turned out that this package was already in and the sponsoring request buggy, but good to know for the next time ;-)
<shadeslayer> jibel: any news on those lxc issues?
<jibel> shadeslayer, I didn't fix your code because it is based on an old version of the upgrader that has largely evolved
<jibel> shadeslayer, instead I deployed 3 profiles https://jenkins.qa.ubuntu.com/search/?q=upgrade-kubuntu
<jibel> shadeslayer, there S->T, P->T and P+backports ->T
<pitti> nice, and they all succeed!
<Saviq> pitti, you said ppa-sourced -dbgsym packages should be in their respective PPAs, is that something that should work already, or just a thing that "should be like that"?
<infinity> Saviq: Depends on how the PPA is set up but, yes, they can be set up to publish ddebs to the PPA.
<infinity> Saviq: That's mutually exclusive with the PPA being used as a copy source to the primary archive, though.
<Saviq> infinity, that'd be fine - so we need to ask for it per-PPA to be enabled?
<Saviq> Mirv, think we want that enabled for qt5-beta2Â â?
<shadeslayer> jibel: <3
<Mirv> Saviq: 1. there are already manually build -dbg in the PPA, 2. in the past it was found out neither those or .ddebs were enough in case qt not built with debug options, 3. I'm offering the qt5-proper PPA with debug options enabled (non-tested) now that I enabled full release mode for qt5-beta2
<Mirv> Saviq: so, I'm not really sure if it would get anything extra to enable ddebs there
<Mirv> Saviq: or the 2. is what you know about more and because of which at some point I switched to building everything in debug mode earlier
<Saviq> Mirv, hmm ok
 * Saviq just assumed I needed -dbgsym, but if everything's there in -dbg, then we're good
<jibel> shadeslayer, and now available on https://jenkins.qa.ubuntu.com/view/Upgrade/
<shadeslayer> :D
<doko> jtaylor, qhull and octave did migrate
<slangasek> pitti: bluez doesn't do a modprobe, it only relies on udev loading the module
<pitti> slangasek: ok, same thing in a container, I guess
<slangasek> pitti: hmm, would it be?  I would expect the request to be handled by the host udev
<pitti> slangasek: the host doesn't have bluetooth hardware I expect (it's just a ppc64el vm), and isn't running bluez; woudl such a request somehow be propagated to the host's udev? that sounds odd
<slangasek> pitti: bluez tries to start and asks for an AF_BLUETOOTH socket; the kernel doesn't have this address family and goes looking for it; the host udev sees the request and loads bluetooth.ko
<slangasek> pitti: this isn't hardware support, but address family support
<slangasek> bluez will run with or without bluetooth hardware present
<pitti> slangasek: it still seems odd to me that we'd allow a container to cause modprobes in the hosts? but maybe that's supposed to work, I don't know really
<stgraber> pitti: containers can't load modules, we block that through appear and capability drop
<stgraber> pitti: /me reads the rest of backscroll
<stgraber> pitti: hmm, right, that auto-loading bits for network families may still work though. So yeah, ignore me, whatever slangasek said ;)
<pitti> stgraber, slangasek: FWIW, it also fails locally on amd64:
<pitti> apt0t-bluez_response FAIL status: 0, stderr: Can't open HCI socket.: Address family not supported by protocol
<pitti> (in LXC)
<pitti> exactly the same as on ppc64el, so I'll keep it in the "does not work in container" category
 * pitti waves good night
<stgraber> pitti: interesting, so one thing you could do is load whatever modules it needs from the host
<stgraber> pitti: similar to what you have to do when you want iptables to work in a container
<pitti> barry: please don't review https://code.launchpad.net/~xnox/ubuntu/trusty/ofono/python3/+merge/208117, it's superseded by https://github.com/rilmodem/ofono/pull/56
<stgraber> pitti: I guess the "bluetooth" module ought to load everything that's needed for the test.
<barry> pitti: i'll forward my comments there (it's much easier for me to review branches in my inbox ;)
<xnox> barry: well, i think pitti didn't do my mistakes there with wrapping everything in list()
<xnox> barry: why does 2to3 is list() overzealous? just to be on the save side?
<barry> xnox: exactly
<barry> which is another reason i don't much like 2to3 ;)
<cyphermox> stgraber: if you want to do anything useful with bluez though, you'll need a hardware driver too
<cyphermox> stgraber: I don't remember seeing a mock bluetooth device driver
<stgraber> cyphermox: does kvm provide a fake bluetooth device then? (we're talking about adt here, I'm guessing those actually pass in kvm)
<cyphermox> figured it was adt.
<cyphermox> I don't know
<cyphermox> I could search a bit, I did find a fake-rfkill driver after all :)
<cyphermox> stgraber: ignore me, I guess pitti found and uses that already: http://www.spinics.net/lists/linux-bluetooth/msg03127.html
<Saviq> Mirv, just remembered... -dbgsym in qt5-beta2 could be useful for other packages :)
<tseliot> slangasek: can you approve bug #1282796 , please?
<ubottu> bug 1282796 in nvidia-prime (Ubuntu Precise) "prime-xconfig can write an invalid BusID string" [High,In progress] https://launchpad.net/bugs/1282796
<barry> pitti: commented
<hallyn> hm, apt-get install software-properties-common in trusty contaienr gives me http://paste.ubuntu.com/7000799/
<hallyn> actually that's python3-dbus
 * hallyn tries installing apport
<stgraber> hallyn: that's a python3.4 bug
<hallyn> stgraber: ok thx
<hallyn> (i thought it had stopped the pkg install but i see now it didn't)
<xnox> barry: can you help with http://paste.ubuntu.com/7000830/ ?
<xnox> barry: python3.4 specific failure.
<xnox> doko: is this known http://paste.ubuntu.com/7000830/ ?
<Saviq> xnox, hey, cross-build issue of qmenumodel: http://paste.ubuntu.com/7000839/ - not sure what should be done about this...
<Saviq> (or can, for that matter)
<xnox> Saviq: something somewhere build-depends on "python3" instead of "python3:any"
<xnox> Saviq: let me check it out.
<Saviq> xnox, thanks
<Saviq> xnox, looks like it's qmenumodel itself
<Saviq> xnox, yeah http://bazaar.launchpad.net/~indicator-applet-developers/qmenumodel/trunk/view/head:/debian/control
<xnox> Saviq: i believe all three should be moved to Build-Depends-Indep to be honest.
<Saviq> xnox, mhm
<xnox> Saviq: also it will probably fail due to dependency on qt5-qmake anyway.
<Saviq> xnox, ugh, it probably uses it to determine the qml install dir :/
<Saviq> yeah
<xnox> Saviq: there are stock install locations for those...
<Saviq> xnox, https://bugreports.qt-project.org/browse/QTBUG-29987
 * Saviq wonders where others are taking it from these days
<xnox> Saviq: i bet they just stick it into "CMAKE_LIBDIR/qt5/qml/"
<Saviq> xnox, looks like it, yeah
<Saviq> xnox, actually most query qmake still...
<xnox> Saviq: i know a lot of _our_ code does, what about non-ubuntu code?
<Saviq> xnox, they don't cross-build ;)
<Saviq> xnox, so what do they care
<barry> xnox: did you figure it out?
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Alpha 2 released! | Archive: feature freeze (+ beta1 migration block) | 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:
<stokachu> anyone come across "postrm-does-not-call-updaterc.d-for-init.d" even though we only have <package>.upstart in our dist
<stokachu> i looked through dh_installinit and it seems to handle all the magic automatically, at one point you could force --upstart-only but that was deprecated
<stokachu> ive tried adding <package>.postrm with the updaterc.d to attempt to silence that error but no go
<directhex> so what's the quickest way to get mono ppc64el removed from the archive? it's a blocker for -proposed transition, and i *really* want that unblocked for FFe reasons
<directhex> i recognise that critical test suite failures should cause package build aborts. i'm discussing the best way to do that with upstream
<Noskcaj> seb128, I thought Bug 1282937 doesn't need an FFe since all non-bugfix changes we already have as patches
<ubottu> bug 1282937 in xfburn (Ubuntu) "Please package xfburn 0.5.0" [Undecided,In progress] https://launchpad.net/bugs/1282937
<seb128> Noskcaj, 480k of diff isn't something I'm wanting to wave through as "bug fix only", but maybe some other sponsors want to do that...
<Noskcaj> ok, i'll file an FFe now
<seb128> thanks
<Noskcaj> Also, the libxfce4ui merge needs the tarball from http://archive.xfce.org/src/xfce/libxfce4ui/4.11/libxfce4ui-4.11.1.tar.bz2
<seb128> Noskcaj, is Debian using the same tarballs?
<Noskcaj> yep
<seb128> the libxfceui one wasn't happy with the upstream tarball
<seb128> or I did something wrong
<Noskcaj> strange
<seb128> well, I got the tarball from Debian and it was fine, but maybe I got something wrong on the first try
<Noskcaj_school> seb128: The clutter new release builds fine, i said might need exta symbols since i wasn't sure of other arches
<Noskcaj_school> seb128_: Did you see my message?
<seb128_> Noskcaj_school, which one? having flacky internet there, I don't think so
<Noskcaj_school> seb128: The clutter new release builds fine, i said might need exta symbols since i wasn't sure of other arches
<seb128> Noskcaj_school, oh, ok, maybe you can try in a ppa to see if that's the case?
<Noskcaj_school> I did, build's just finished, ppa is fine.
<seb128> good
<stgraber> doko, infinity: does that mean something to either of you? http://paste.ubuntu.com/7002151/
<doko> is systemd happening that fast?
<stgraber> I'm working on patching our logind to work with cgmanager
<doko> anyway, afk now
<stgraber> I started getting this today, first thought it was my patch, then noticed that a no change rebuild of systemd reproduces it too
#ubuntu-devel 2014-02-27
<xnox> barry: nope.... it looks like a regression inside python3.4 to me.
<xnox> barry: possibly related to http://bugs.python.org/issue11798 ?
<xnox> stokachu: it's mostly harmless, in debian there must be matching init.d scripts for upstart jobs, it's not a requirement in ubuntu (as we've been using upstart for many releases by default now)
<xnox> stokachu: however, if the package is in debian and should be usable with sysv-init, it's a serious bug that must be fixed.
<stokachu> xnox: ah ok
<stokachu> xnox: this is ubuntu only package so i just put a lintian override for it
<xnox> stokachu: yeap.
<stokachu> cool thanks man
<infinity> stokachu: Needs more context, but I'm assuming it's including <linux/xattr.h> before <sys/xattr.h>
<infinity> Err..
<infinity> stgraber: ^
<infinity> stokachu: Ignore me. :P
<stgraber> infinity: yeah, it somehow is. I worked around by always adding an include of sys/xattr.h early enough in all failing files until it actually built... systemd never includes linux/xattr.h directly, but it indirectly does from somewhere (not exactly sure where though...)
<infinity> stgraber: Hunting down where would be nice.  We obviously need to fix the conflict at the root (linux/glibc), but fixing underlying libraries to paper over it (like I did with libcap2) is still "saner" than patching applications a dozen times.
<stgraber> infinity: yeah, I first thought it was libcap because there's a bug report about systemd failing to build on arch because of it, but then I noticed that you already fixed it...
<pitti> xnox, barry: yeah, I usually -x that conversion, and just pick out the necessary bits; also, the gobject -> GI changes were incomplete
<pitti> hallyn: yes, that error message happens all over the place, python3.4 regression
<pitti> Good morning
<darkxst> seeded-in-ubuntu working for anyone?
<darkxst> IOError: [Errno socket error] [Errno -2] Name or service not known
<Unit193> Works for meâ¢
<sarnold> wfm
<Noskcaj> darkxst, broken here
 * Noskcaj blames australia
<darkxst> Noskcaj, or telstra?
<sarnold> nono, blame canada
<Noskcaj> probably telstra
<Noskcaj> although i might (finally) get the nbn
<Noskcaj> even if only in fixed wireless form
<darkxst> apparently ubuntuwire.org is not listed in telstra DNS servers ...
<Noskcaj> what about .com ?
<darkxst> nope
<Unit193> darkxst: dig @8.8.8.8
<Unit193> If that works, switch to an OpenNIC DNS server.  Welp.
<sarnold> or run your own recursor?
<Unit193> I run bind9, it also serves OpenNIC domains. :D
<dholbach> good morning
<tvoss> good morning
<tvoss> cjwatson, for benchmarking purposes (no load test, time series scenarios), what statistical tests for result checking do you usually use? I was thinking about something parametric like one-sample-t or a z test
<tvoss> together with a previous check if variances are comparable
<tvoss> cjwatson, do you have an opinion on that?
<mardy> Laney: ping
<mardy> (about newer syncevolution)
<tseliot> slangasek: thanks
<Laney> mardy: yeah?
<Laney> We are past feature freeze now so if you want to sync that then you'll need to file an exception
<mardy> Laney: so, upstream released SE 1.4
<mardy> Laney: OK. Besides the bug, should I provide a branch with the debian packaging, or how does it work?
<Laney> http://packages.qa.debian.org/s/syncevolution.html has it already
<Laney> so, we'd probably just sync it from there
<mardy> Laney: we need an extra parameter in debian/rules to enable the Online Accounts integration
<Laney> okay, attach a diff on top of that package then
<Laney> and preferably send Debian a bug report asking them to enable it
<mardy> Laney: OK, will do, thanks
<mardy> Laney: no, AFAIK, the OA packages are not in Debian
<Laney> they have goa
<mardy> Laney: doesn't help, we need libaccounts-glib and libsignon-glib
<Laney> ya, the readme says it has GOA support though
<Laney> one day I'll understand why we have this Ubuntu-only online accounts stack
<seb128> Laney, it would be more fair to say "why GNOME is having their GNOME-only accounts stack"
<mardy> Laney: it's a nice story, indeed. https://debarshiray.wordpress.com/2012/10/06/goa-why-it-is-the-way-it-is/
<Laney> Not really, because "GNOME" isn't a distribution
<seb128> Laney, the one we are using was used at Nokia, shipping on products, Intel still uses it/work on it, and I think KDE is standardizing on the same techs
<seb128> Laney, well, KDE is not using goa
<seb128> Laney, well, doesn't change the fact that the tech we use was there first and is used in more place that the one GNOME invented
<mardy> Laney, seb128: Sailfish OS is also using our framework, and people from Elementary OS are working on it as well (I'm not sure whether they use it already)
<seb128> it's somewhat baffling to me pointed out as the one who did their own stuff there
<Laney> Dunno why nobody has brought it to Debian then
<mardy> Laney: it's in fedora, curiously
<seb128> yeah, it's even actively maintained in fedora it seems, http://pkgs.fedoraproject.org/cgit/libaccounts-glib.git/
<seb128> they had an update yesterday
<zequence> Hi. I got a package uploaded, ubuntustudio-live, but it's yet not accepted by the archive admins. How does that work? I got it in before feature freeze, and it's supposed to replace our current ubiquity package, ubuntustudio-live-settings. Need time to test it and fix any bugs
<Riddell> zequence: I'll take a look
<Riddell> zequence: how come it conflicts with ubiquity-slideshow-kubuntu et al and kubuntu-debug-installer ?
<Riddell> zequence: how come it doesn't conflict with ubuntustudio-live-settings.
<zequence> Riddell: I will remove ubuntustudio-live-settings once ubuntustudio-live is available
<zequence> It's a part of the ubuntustudio-default-settings source
<zequence> The conflicts I mostly copied from the edubuntu-live source, which I based it on. Might not be complete. edububuntu-live didn't conflict with everything else
<Riddell> zequence: it seems to conflict on random packages like hal and also depend on random packages like ldap, I don't think this is what you want
<Riddell> zequence: rejecting, please fix depends to be what it must have and conflicts to be what it can not work with
<zequence> Riddell: Alright, thanks
<ogra> xnox, i'm looking for an upstart specialist ...
 * xnox franticly looks around....
<xnox> ..
<xnox> ogra: ok, what's up?
<soren> xnox: Run away!
<pitti> jodh was faster with the "need to run out" :)
<ogra> xnox, i have something like "env FOO='' at the top of an upstart job ... then later i want to stuff the return of a getprop command into that var from pre-start ... export it to the exec stanza so that it ends up as options to the command i exec
<ogra> it seems something like FOO=$(mycommand) doesn work in the pre-start script
<ogra> is there any trick i could use to get the output of "mycommand" into the var ?
<ogra> (i know i could split the job and export from the first one or echo into a file that i read later, but both feel really ugly)
<xnox> ogra: no environment can be passed between stanzas. E.g. pre-start, post-start, pre-stop, pre-start, exec, script - all get fresh environment, and thus FOO=''
<xnox> ogra: can you show me your full job?
<ogra> right, but export should work around that, no ?
<xnox> ogra: pre-start and exec are, well just like lines in a makefile all started in a separate shell.
<ogra> xnox, well, its in the middle of a rewrite ... http://paste.ubuntu.com/7004801/
<xnox> (well exec may start in shell, and may be execed directly)
<ogra> what i get in the log is the "ril" i set at the top
<ogra> but not the "stopped" that the getprop returns
<xnox> ogra: merge pre-start and exec, into a single
<xnox> script
<ogra> uuh
<xnox>      opt=$(get opts)
<xnox>     ril $opt
<xnox> end script
<ogra> i thought exec should never live inside a script block ?
<xnox> ogra: remove "exec".
<ogra> slangasek once held me a lecture about that :)
<ogra> ah !
<ogra> heh, now *that* didnt strike me :P
<xnox> ogra: is this system or user job?
<ogra> system
<ogra> its ofonos start job
<xnox> ogra: with user jobs, you could do "initctl set-env OFONO_OPTS=ril"
<ogra> we want to get the list of modules from the android side now ... they live in an android property
<xnox> ogra: http://paste.ubuntu.com/7004817/
<ogra> right, thats what we use in plenty of places
<xnox> ogra: alternatively. you can start an instance.
<ogra> by splitting the job, yeah
<xnox> e.g. have ofono-boot.conf which is task and does "initctl start ofonod OPTS="stuff you got from prop""
<xnox> (probably --no-wait as well
<xnox> )
<ogra> i think dropping the exec and firing everything from the script is the beast though
<ogra> *best
<xnox> ogra: do check that it gets the right pid...
<ogra> yep, will do
<ogra> thanks !!
<ogra> root@ubuntu-phablet:/# tail -1 /var/log/upstart/ofono.log
<ogra> stopped
<ogra> yay
<xnox> ogra: check "pgrep ofonod"
<xnox> after stop
<xnox> or compare status, with pgrep.
<ogra> oot@ubuntu-phablet:/# initctl list |grep ofono
<ogra> ofono start/running, process 1820
<ogra> root@ubuntu-phablet:/# pgrep ofonod
<ogra> 1820
<ogra> looks fine
<ogra> (though i dont actually start ofono atm)
<ogra> (it is just the echo)
 * ogra goes to test on an actual phone now 
<cff> How can I purge Qt Edgers repo?
<cff> I've tried with ppa:canonical-qt5-edgers/qt5-proper but it gives PPA to be removed: canonical-qt5-edgers qt5-proper Warning:  Could not find package list for PPA: canonical-qt5-edgers qt5-proper
<cff> ppa-purge ppa:canonical-qt5-edgers/qt5-proper
<zequence> Ridell: I made changes in dependencies and conflicts, to the best of my understanding. Would you be able to accept this version? lp:ubuntustudio-live
<ogra> xnox, hmm, using the real ofonod on a phone doesnt give me the right pid if the command lives inside the script block
<ogra> seems that only worked with the echo ... but not with a forked daemon :/
<zequence> Riddell: (reposting, as I can't spell) I made changes in dependencies and conflicts, to the best of my understanding. Would you be able to accept this version? lp:ubuntustudio-live
<Riddell> zequence: looking
<Riddell> zequence: why does it conflict with other ubiquity slideshows and with mythbuntu-live-autostart ?
<Riddell> zequence: lintian errors a-plenty http://paste.kde.org/pfq7goadb
<zequence> Riddell: I guess the conflicts are more for testing, then otherwise. I saw that edubuntu-live had them, so I kept them. As for the lintian errors, I need to fix that, absolutely.
<zequence> I'll need a day to go through that
<zequence> Thanks for the help
<xnox> zequence: Riddell: correct seeds should be used to seed new slideshow, and replace the other one.
<xnox> zequence: using conflicts is abuse here, since everything depends on "provides" package (ubiquity-slideshow) and thus typically only one is pulled in anyway.
<xnox> zequence: no slideshows should encode the names.... of all the other slideshows as that's a lot.
<xnox> zequence: for testing you should do: $ apt-get install your-slideshow.deb ubiquity-frontend-[gtk|kde] ubiquity
<xnox> zequence: if you do install ubiquity, it can pull in kde frontend with kubuntu slideshow by default without any hints =))))
<xnox> zequence: is there a matching branch to adjust studio seeds to use new packages?
<xnox> zequence: the two should go in together (-meta update + your new packages)
<mpt> bdmurray, I guess the X axis for a graph showing any series should extend to whichever is later: the release date of that series, or (whichever is earlier: today, or EOL for the series)
<zequence> xnox: I wanted to wait until all the packages were available. Then do the switch. If that meant one broken ISO build, I thought that would be fine, while adjusting it all.
<xnox> thus a: Breaks: studio-meta (<< first-version-that-pulls-in-new-slideshows-et-al)
<zequence> I don't have upload rights, so I need someone to help do the switch
<zequence> I can only edit the seeds
<xnox> zequence: no, just declare the above breaks, and your new packages can be staged in -proposed, and you can test them by dist-upgrading live cd.
<xnox> zequence: onces you are happy, the whole lot can migrate to release. Thus both giving you test playground, and no broken cds.
<xnox> zequence: well, you can work with Riddell or myself to stage the uploads correctly =)
<zequence> xnox: Alright, thanks.
<mpt> bdmurray, so for the 14.04 milestones to extend the default graph is a good thing, it shows the âflight pathâ for finalizing 14.04. Not so much if itâs a graph just showing 12.10 or whatever.
<infinity> xnox: A Breaks really seems unnecessary.  Who upgrades the live set?
<xnox> infinity: for britney to migrate them together?
<xnox> infinity: of is that abusive as well?! =)
<infinity> xnox: I don't see as it makes a massive difference in this case.  It's just control cruft.
<mpt> bdmurray, Iâve added some details of the graph design for future reference. <https://wiki.ubuntu.com/ErrorTracker?action=diff&rev2=177&rev1=176>
<infinity> (And it doesn't *actually* break that package, you're just abusing it to get both together, which is a non-issue for CD builds that always pull the latest anyway)
<xnox> zequence: right, so tag bug block-proposed, upload the packages you need. From live cd upgrade and test them out. Once happy, remove the tag let all packages migrate and the cd after that, will be all beautiful.
<xnox> zequence: where are your sponsorship / merge proposal requests?
<zequence> xnox: bug 946591
<ubottu> bug 946591 in ubuntustudio-live "Add ubuntustudio-live to trusty repositories" [Undecided,Confirmed] https://launchpad.net/bugs/946591
<mpt> bdmurray, to implement that exactly the error tracker would need to start knowing which milestone belongs to which Ubuntu version, so it can show only those milestones relevant to the currently shown versions.
<zequence> It's an old bug, which I updated
<xnox> zequence: ack. will look into it later.
<ximion> hughsie: hi :) did you try libappstream yet?
<ximion> wtf...
<ximion> sorry for the noise... irc client issue
<barry> dobey: i've seen this, but haven't had time to investigate yet.  thanks for pointing me to the bug
<hallyn> pitti: thanks much for the bug reports on qemu-2.0!
<slangasek> ogra, xnox: note that you can't use 'expect fork' if you are calling getprop for env setup, because getprop will fork
<ogra> oh !
<ogra> slangasek, thanks ...
<xnox> slangasek: yeah, we got there, eventually. Also we agreed that android-event-bridge should just sent event when ril is ready, with all the right params in the event variable.
<slangasek> ok :)
<xnox> slangasek: and the ofono.conf job just use that var, or have a sensible fallback.
<pitti> jodh: is there a way to disable e. g. /usr/share/upstart/sessions/update-notifier-crash.conf (file-triggered, so you can't just "stop" it) without removing/touching that file?
<pitti> jodh: i. e. some counterpart to .override files in /etc/ for /etc/init?
<pitti> perhaps in ~/.config or so?
<pitti> there's a ~/.config/upstart/ which sounds promising
<pitti> om26er: ^ FYI
<jodh> pitti: yep - "echo manual >> /.config/upstart/update-notifier-crash.override"
<xnox> pitti: user-session jobs, can be overridden in any XDG_CONFIG_DIRS/upstart and XDG_CONFIG_HOME/upstart.
<pitti> jodh: splendid, thank you!
<pitti> om26er: ^
<xnox> pitti: documented in man 5 init, under user-session jobs.
<om26er> pitti, so it will disable it instantly ? or the next run ?
<jodh> om26er: it should of course be "echo manual >> ~/.config/upstart/update-notifier-crash.override" :)
<pitti> om26er: should be instant
<xnox> pitti: om26er: in essence, we take highest priority .conf, and .override from higher priority down to the one where .conf is.
<pitti> om26er: well, there is no "run" really, it just will stop getting triggered
<xnox> pitti: so, e.g. /etc/xdg/upstart/foo.conf, can override completed /usr/share/upstart/session/foo.conf, and user can further tweak it with ~/.config/upstart/foo.override.
<jodh> om26er: well the override file you create will be applied instantly, but if that service is already running it won't be stoppe (hence really only applies to next session startup).
<xnox> (and since desktop envrionments get their own XDG_CONFIG_DIR you can even override jobs on-per session types)
<om26er> jodh, understood, thanks
<pitti> jodh: it's a file trigger; so as soon as that override is in place, it should stop getting triggered, right? or does the session upstart only read ~/.config/upstart/ on startup? (I had expected an inotify watch)
<jodh> pitti, om26er: ah - forgot that /usr/share/upstart/sessions/update-notifier-crash.conf uses the file bridge, so yes, the .override will apply immediately (ie no further crash files will cause that job to run).
<om26er> jodh, ack
<xnox> Laney: did you upload the gstreamer package split? as far I understand, nothing will change as long as the full-ugly one still depends on the two split ones. and we'll just need to change the touch-seed (when that's allowed to land) to land the switch and drop.
<Laney> xnox: Nobody ever tested it
<xnox> Laney: hm. ok. Let me hunt that down and report back to you.
<Laney> I already asked rsalvet_i
<pitti> stgraber: jodh and I are fighting with the sbuild autopkgtest in LXC
<stgraber> pitti: ok, what's going on exactly?
<pitti> stgraber: both with the standard lxc-container-default-with-mounting and with your magic custom lxc-adt profile it still fails on
<pitti> W: Failure trying to run: chroot /tmp/adt-run.bnodMI/ubtree0t-build_procenv-testtmp/adttmp/schroot-trusty mount -t proc proc /proc
<pitti> [77539.290066] type=1400 audit(1393521100.343:60): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxc-container-adt" name="/tmp/adt-run.bnodMI/ubtree0t-build_procenv-testtmp/adttmp/schroot-trusty/proc/" pid=18110 comm="mount" fstype="proc" srcname="proc" flags="ro"
<pitti> stgraber: it only works when running with "unconfined"
<pitti> stgraber: could we relax the AA profiles to allow mounting /proc?
<pitti> stgraber: at least in the custom profile
<stgraber> pitti: yeah, sounds like if you want this to pass, you'll need to allow add:
<pitti> stgraber: oh, I see some /var/lib/lxc** in the profile
<stgraber> mount options=(rw,bind),
<stgraber> mount fstype=devpts,
<stgraber> mount fstype=proc,
<stgraber> mount fstype=sysfs,
<pitti> stgraber: I have containers in /srv/lxc/
<stgraber> pitti: those paths are relative to the container's rootfs, not your host. These entires are needed for LXC inside LXC.
<pitti> ah
<stgraber> pitti: add those 4 mount entries to the adt apparmor profile, reload apparmor and try again, that should help (makes the whole thing horribly unsafe, but we already agreed to ignore that ;))
<pitti> stgraber: mounting /proc is unsafe?
<pitti> stgraber: thanks, trying that
<stgraber> pitti: mounting /proc somewhere other than /proc is unsafe because apparmor won't prevent writes to dangerous files
<stgraber> pitti: so you can do "echo b > /tmp/proc/sysrq-trigger" for example, or set some of the hooks (crash handler for example), trigger them and run command as root on the host as a result.
<pitti> stgraber: ah, I understand
<bdmurray> pitti: can you have a look at bug 1283303?
<ubottu> bug 1283303 in udev (Ubuntu) "ATA drive /dev/disk/by-path/ incorrect due to kernel change" [Undecided,New] https://launchpad.net/bugs/1283303
<pitti> bdmurray: queued, I'll check tomorrow
<bdmurray> pitti: thanks
<jtaylor> infinity: will we get updates from the 2.19 branch of glibc "automatically" or do I need to file a bug to get an issue fixed? (upstream #16623 is the context)
<bdmurray> My wireless mouse (connected via bluetooth) repeatedly says it is at 0% but then I reconnect it and it is fine for some period of time, and the bluetooth applet says the status is Good now.  How can I dig into this?
<infinity> jtaylor: I'll do some updates from the 2.19 master branch over the next month or two before final freeze.
<infinity> jtaylor: Does this possibly also fix 16625?
<jtaylor> infinity: I don't think so
<infinity> A man can dream.
<jtaylor> :)
<infinity> jtaylor: Anyhow, I'll make sure at least that fix makes it into my next upload.
<jtaylor> thx
* stgraber changed the topic of #ubuntu-devel to: Trusty Alpha 2 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<arges> bdmurray: hey
<bdmurray> arges: hi
<arges> bdmurray: looking at the pending-sru queue now
<cyphermox> bdmurray: see if upower has some kind of debugging there you could find how how it asks the mouse for battery
<bdmurray> cyphermox: okay, thanks
<Logan_> bdmurray: yeah so I apparently suck at SRUs
<Logan_> what's the best way to push a fix to multiple stable releases, version-wise? :P
<bdmurray> Logan_: well if I'd been on top of things we could of copied it from Precise to later releases
<sarnold> Logan_: the security team has some version number examples here that might be uesful: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<Logan_> sarnold: I pushed ubuntu0.1 to all four releases at once
<bdmurray> Logan_: otherwise versioning like 0.12.04 and 0.12.10 would work as 10 > 04
<Logan_> bdmurray: in the future, should I just push to, say, precise?
<Logan_> and then have the SRU team copy up?
<bdmurray> Logan_: no this is an exception because the version of d-rats was the same in all releases
<Logan_> oh
<Logan_> but, in that scenario, should I just push to the oldest?
<bdmurray> its probably best to just use follow the security team recommendations
<Logan_> I thought I was :(
<bdmurray> so in this case 0.3.3-3ubuntu0.12.04.1
<Logan_> ok
<bdmurray> 0.3.3-3ubuntu0.12.10.1
<bdmurray> etc...
<infinity> Logan_: Uploading thr same to all won't work cause you'd get mismatched binary builds.
<Logan_> gtocha
<Logan_> infinity: oh right
<Logan_> *gotcha
<infinity> Logan_: In the rare case of "the same version is everywhere", then yes, if you upload to the oldest release, it can be copied.
<Logan_> okay, cool
<bdmurray> infinity: but not all SRU team members have the ability to copy though correct?
<infinity> bdmurray: Don't see why not.
<infinity> bdmurray: If you can copy from precise-proposed to precise-updates (which is what an sru release is), yo ushould be able to copy to quantal-updates too.
<infinity> bdmurray: ACL checks don't care about the source, just the target.
* stgraber 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:
<_zap_> hi. i have a question about the efi boot process in ubuntu. there is a single grub efi binary in the ESP partition and another grub efi binary in the boot partition which contains the kernel. I appears that the ESP grub loads the boot partition grub but there is no config file for the ESP grub. so i am wondering how was the ESP grub built?
#ubuntu-devel 2014-02-28
<sarnold> rbasak,teward, https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1262710/comments/6 -- I sure hope "please add a new binary package" isn't too large a hurdle for nginx. the core code looked really good.
<ubottu> Launchpad bug 1262710 in nginx (Ubuntu) "[MIR] nginx" [Undecided,Confirmed]
<teward> sarnold, the source of the problems will be the large number of users who have come to rely on the non-core modules.
<teward> sarnold, that, and you're basically asking for a duplicate of upstream's repository
<teward> which is broken at that
<teward> s/broken/in violation of many policies/
<sarnold> teward: those users can continue to rely upon the universe-supported package
<sarnold> teward: I'd be content to support nginx-tiny if it dropped 'echo' -- if that's the easiest way to get nginx in main, that's fine by me.
<teward> sarnold, as an aside, "those users" consists of a very large portion of the userbase of the debian packages, by my observations.
<sarnold> teward: that's fine :)
<sarnold> teward: they all use universe packages now..
<sarnold> teward: .. and they can continue to use universe packages if they wish.
<sarnold> teward: but we need some clear demarcation between what we can and can't support, and whatever we -can- support should go into 'main'.
 * teward yawns
<teward> sarnold, agreed, but i'm already imagining there being people being... I think the correct wording is "extremely displeased to an uncivil degree" if we drop, and Debian already has a... "poor view" of Ubuntu's support for nginx as it is.
<teward> earliest i'd be starting to work on this is... what, saturday, I think...?
<teward> i'm kinda busy with the new job so meh
<sarnold> teward: I'm not saying -drop- the package -- I just want one new binary package with nothing but upstream nginx code. :)
<teward> speaking of which, i need to get some sleep...
<sarnold> teward: oh cool! congratulations :)
<sarnold> teward: good night :)
 * sarnold -> dinner
<teward> sarnold, when you return, poke around at the nginx.org debian repository and look there.  that's upstream-only code, but that package breaks policies and user-friendliness
<teward> sarnold, if the code base there is more to your liking I can *try* and replicate the admin-friendliness of nginx that the Debian packages have in a separate binary
<sarnold> teward: ahhhhhh I think this might explain some of the disconnect...
<sarnold> teward: I just hope that we can add a new paragraph to debian/control for a new nginx-upstream package, add a new debian/nginx-upstream.install file with a few paths, and get this thing done right quick :)
<sarnold> I'm hoping the debdiff is ~75 lines, tops.
<teward> probably gonna be higher than that
<sarnold> probably, I'm always too optimistic :)
<sarnold> teward: anywa, you need sleep ad I need food. :) have fun at the new job!
<teward> sarnold, you're probably looking at the entire debian/ folder, butchered up from Debian, minus the third-party modules, plus the Ubuntu specific branding, and me slicing and dicing the debdiffs around to get something functional
<teward> but by that point even I wouldn't run that :P
<teward> not without MASSIVE amounts of testing
<sarnold> haha
 * teward volunteers YOU to run the testing :P
<sarnold> oh believe me, we'll need some test cases. i'm sure I'll be writing plenty of tests.
<sarnold> supporting this thing for five years ain't going to come cheap :)
<teward> bleh, i've got enough crap with high-level sec reviews of 20 or so system updates for the *shudders* windows systems at work
 * teward shivers
<sarnold> teward: ugh. my condolances.
<teward> sarnold, FORTUNATELY i only have to deal with the dell deployment appliance.  it's still windows though, so eurgh
<teward> ANYWAYS
<teward> good night
<sarnold> eurgh indeed :)
<sarnold> goodnight, thanks!
<teward> sarnold, and forgive me if, say, i start condemning you over the next few days as i butcher down debian's debian/ directory a bit... that's no small feat.
<teward> (and it's necessary to maintain the sites-available / sites-enabled admin friendliness that already exists in universe)
<infinity> teward: What would be wrong with just dropping 'echo' from nginx-light and calling it done?  Or is that somehow required to make the other bits work?
<pitti> Good morning
<pitti> shadeslayer, Riddell, apachelogger, debfx_: just to triple-check, Kubuntu is not using jockey any more, but u-d-common, right?
<pitti> I'm going to remove jockey from trusty
<pitti> Task: kubuntu-active
<pitti> is that still relevant?
<dholbach> good morning
<cff> Is Qt 4.8.x available in Ubuntu 12.04.x ?
<cff> ubuntu backports, canonical qt edgers, ubuntu sdk ppa, don't have it
<didrocks> cff: seems to be 4.8.5
<cff> didrocks: where?
<didrocks> on 14.04
<cff> didrocks: I'm asking in 12.04
<didrocks> not sure that we backport Qt on 12.04
<cff> http://packages.ubuntu.com/precise-backports/allpackages no qt here
<didrocks> cff: you can see the version of Qt4 for all supported ubuntu releases here: https://launchpad.net/ubuntu/+source/qt4-x11
<didrocks> so, it's 4.8.1 in precise
<infinity> We don't tend to backport libraries like that.  It's just asking for trouble.
<infinity> If there's a reason you need bleeding edge versions, you likely don't want to be running an LTS.
<apachelogger> pitti: kubuntu-active isn't built right now I think, and yes, jockey was replaced by kubuntu-driver-manager; good to remove
<cff> alright thanks
<pitti> apachelogger: thanks
<soren> mdeslaur: A quick heads up: curl has a unit test that fails since Feb 1st, due to a cookie timing out on that day, so for the next security update, you'll need to update that as well.
<soren> mdeslaur: I just spent way too much time thinking I caused a unit test to fail only to realise it also failed without my patch applied. I thought I'd save you the same trouble since you seem to be the one who does most of the curl security updates.
<pitti> cjwatson: does https://code.launchpad.net/~pitti/britney/britney2-autopkgtest-fixes/+merge/208657 look sane, or would that need a different approach? (first time I looked at britney admittedly, some state keeping is rather confusing)
<rbasak> sarnold: it seems reasonable, though I suppose we need an FFe now. Thank you for the review!
<rbasak> teward: ^^ - let's chat about this when you're next online. Note that I'm away Mon-Wed next week.
<ogra> doko, i see you added a new dep on libtasn1-6, but  it seems there was no older dep dropped (see http://people.canonical.com/~ogra/touch-image-stats/20140228.changes) is that wanted ?
<doko> ogra: libtasn1-3-dev is now built form libtasn1-6
<doko> not sure why libtasn1-3 wasn't there before
<ogra> doko, it still is there i was just expecting it to be traded for the new binary (there are no "dropped packages" in the list as there usually are in transitions)
<Laney> oh, we got 1-6 in main, cool
<cjwatson> pitti: I haven't reviewed it quite yet, planning to look today.  I don't want to give a knee-jerk opinion as I'll need to stare at the context for a while
<Laney> there was something we had a delta on to keep it at 3. /me tries to remember what that was
<cjwatson> pitti: Thanks in advance of review for diving into that though :)
<pitti> cjwatson: ack; yes, no knee-jerk patches into britney :)
<Laney> p11-kit
<pitti> cjwatson: next week I'll look into fixing that "binary taken over by new source" bug (the gccgo-4.9 fun that we had)
<pitti> cjwatson: but I wanted to start with something easier first
<tkamppeter> mdeslaur, hi
<xnox> cjwatson: if a package drops things into /etc/default/grub.d does it need to do anything special to trigger "update-grub" or do grub packages have file trigger for those? (looking quickly through triggers, i don't see one)
<xnox> cjwatson: or should one just do "update-grub || true" in postinst? (given that grub might be installed, but not in use)
<cjwatson> xnox: Just conditionally do update-grub like lupin-support.postinst does, I think
<xnox> cjwatson: thanks for pointer.
<pitti> hm, did anyone see this error with the new kernel already?
<pitti> In file included from ../src/core/socket.c:32:0:
<pitti> /usr/include/x86_64-linux-gnu/sys/xattr.h:31:3: error: expected identifier before numeric constant
<pitti>    XATTR_CREATE = 1, /* set value, fail if attr already exists.  */
<mdeslaur> soren: cool, thanks!
<mdeslaur> tkamppeter: hi!
<mdeslaur> tkamppeter: ah, got your email, thanks
<xnox> plars: psivaa: server images should be back to green. By the way, why are floodlight jobs not triggered? the referenced bug was fixed, no?!
<psivaa> xnox: thanks for the server image fix. floodlight was disabled as per server team request. let me see the exact convo
<xnox> psivaa: if it's disabled, why is it (a) red, (b) published on jenkins.qa.ubuntu.com ?
<psivaa> xnox: <jamespage>     psivaa, where do I find the utah smoke tests again? going to convert the floodlight test into a DEP-8 test instead
<psivaa> psivaa, https://code.launchpad.net/~james-page/ubuntu-test-cases/server-drop-floodlight/+merge/196511
<xnox> psivaa: maybe i'm looking at the wrong views?
<xnox> psivaa: ah, sounds excellent! can it be cleaned up from jenkins.qa.ubuntu.com (trusty series at least)?
<xnox> psivaa: or do a last green run ;-)
<psivaa> xnox: http://ci.ubuntu.com/smokeng/trusty/server/amd64/20140228/6872/ is the right place. but i'll report a ticket to clean up floodlight
<xnox> psivaa: ok, thanks! will bookmark those pages then.
<Saviq> jibel, hey, I saw you were enabling some autopkgtests for uitk, I was wondering recently - we have a bunch of QML UI tests that we only run on CI on a real machine these days, I'd love to put that into autopkgtest, but they require OpenGL, is that something we could get with xvfb via gallium / llvm / whatever-its-called?
<xnox> Saviq: ubuntu-emulator-runtime runs under xvfb with gallium on cloud instances / virtual machines, and it requires gl accelaration.
<ogra> urgh
<brendand> dholbach, hey - do you have any idea how to create a mailing list on lists.ubuntu.com?
<xnox> Saviq: libgl1-mesa-glx, xvfb, xinit is all you need I believe.
<Saviq> xnox, ok, I tried that locally recently, didn't seem to work - will try again :)
<Saviq> xnox, thanks for the confirmation that it should
<xnox> Saviq: best boot into ubuntu-desktop livecd in a VM. that should have all the gallium bits, et. al. and try running the tests there.
<xnox> Saviq: distilling down from that should be easy.
<xnox> Saviq: oh, for some tests we had to increase the default xvfb screenresolution and pixel depth.
<Saviq> xnox, good to know
<jibel> Saviq, as xnox said you need libgl1-mesa-glx and set screen to a minimum of 1024x768x24, by default xvfb uses 800x600x8 IIRC
<xnox> jibel: should we just bump xvfb default, no a more reasonable default?! the world has moved on from 800x600x8....
<jibel> xnox, it is even worst than that, the default is 640x480x8
<jibel> bdmurray, any opinion about bug 1286161? it looks like a real issue but first time I see it from S to T
<ubottu> bug 1286161 in ubuntu-release-upgrader (Ubuntu) "13.10 -> 14.04 upgrade failed: initramfs failed to ugprade, udev is not configured yet" [High,New] https://launchpad.net/bugs/1286161
<bdmurray> jibel: this looks suspcious Unpacking udev (204-5ubuntu11) over (204-0ubuntu19.1) ...^M
<bdmurray> Preparing to unpack .../libblkid1_2.20.1-5.1ubuntu14_amd64.deb ...^M
<bdmurray> jibel: whoops, sorry its still early
<dholbach> brendand, https://wiki.ubuntu.com/MailingLists#Requesting_a_list
<guest6019532> hello
<guest6019532> i came here because of the following bug:
<guest6019532> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/932834
<ubottu> Launchpad bug 932834 in pulseaudio (Ubuntu Raring) "Enable equalizer" [Wishlist,Triaged]
<guest6019532> is anyone here who could comment on this? is there any chance this bug could be fixed for trusty (14.04)?
<guest6019532> some more info:
<guest6019532> http://www.webupd8.org/2013/03/install-pulseaudio-with-built-in-system.html
<guest6019532> https://sites.google.com/site/nevion/projects/qpaeq
<guest6019532> http://ubuntuforums.org/showthread.php?t=1378087
<guest6019532> it would be much appreciated
<seb128> guest6019532, you can try to talk to TheMuso, but he's based in Australia and it's friday night there, so maybe better to try next week either earlier or later in the day
<guest6019532> seb128: thx for your reply. i already approached TheMuso in #ubuntu-accessibility a few minutes ago. but he didn't reply.
<seb128> guest6019532, it's 3am for him, he's probably sleeping
<Laney> You could also email him
<seb128> or that
<guest6019532> seb128: ok, thx anyway
<seb128> yw
<guest6019532> Laney: to see email adresses on launchpad, one needs to log in first, as far as i can see. however, i am not registered on launchpad ;p
<Laney> guest6019532: <username>@ubuntu.com works for ubuntu members
<guest6019532> Laney: ok, thx
<Saviq> xnox, jibel, so with xvfb-run I'm getting:
<Saviq> libGL error: failed to load driver: swrast
<Saviq> Could not initialize GLX
<Saviq> and crash
<Saviq> even though unity itself runs under gallium in the VM where I'm trying that
<Saviq> ah
<Saviq> xnox, jibel, unping, seems the resolution/colorspace change helps
<jibel> Saviq, yes, without a depth of 24 it fails with Error: couldn't get an RGB, Double-buffered visual
<Saviq> jibel, awesome, we're getting somewhere, thanks!
<xnox> Saviq: start with trying to run "glxinfo" and nux_test utilities, to make sure they say it's all good.
<Saviq> xnox, yup, that's what I did, even managed to get it to load gallium on my nvidia
<xnox> Saviq: excellent.
<Saviq> xnox, so all looks great, we'll be having some new autopkgtest soon :]
<pranith__> Hi, can someone help me in packaging the latest GNU global package for Ubuntu 14.04? The package in debian is 6 years old and the maintainer is not interested in packaging the latest upstream because of some issues
<Noskcaj> pranith__, link the bug you made
<Laney> why do we want the issues in Ubuntu?
<pranith__> upstream debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947
<ubottu> Debian bug 574947 in global "global: newer release (5.9.2) is available" [Wishlist,Open]
<pranith__> ubuntu bug: https://bugs.launchpad.net/debian/+source/global/+bug/1275029
<ubottu> Launchpad bug 1275029 in global (Ubuntu) "Update global to 6.2.10 for Ubuntu Trusty Tahr" [Undecided,Confirmed]
<pranith__> what is the front-end package which I need to use with bzr-fastimport?
<pranith__> on 12.04 I get an error of no such package for front-end
<ockham> hi, i'm trying to set up a sid pbuilder under saucy, but it fails with
<ockham> Err file: saucy/ Packages
<ockham>   File not found
<ockham> ~/.pbuilderrc is at http://paste.ubuntu.com/7012360/
<ockham> can anyone help?
<sarnold> ockham: you can take raring out of your UBUNTU_SUITES -- it's EOL -- but that likely won't fix your problem, which I can't spot. good luck :)
<ockham> sarnold: thx
<ockham> i think i found it. i had to touch /var/cache/archive/sid/Packages and /var/cache/archive/sid/Sources
<teward> sarnold, when yo uwake up, or are not busy, ping.
<sarnold> hey teward :)
<teward> sarnold, wrt nginx and the mir, would you want a separate source package, or an nginx-tiny added to the existing source to build an upstream-core-modules-only binary that would get into main?
<sarnold> teward: existing source package would be great
<teward> that makes my work considerably LESS evil
<teward> it's easier to add to the current debian/ than it is to trim down the current debian/ and still make everything work xD
<sarnold> teward: oh absolutely
<sarnold> teward: I just need some clear demarcation for the users about which modules we can support and which modules we can't support. I certainly don't want to discard all the hard work you've put into the package over the years :)
<teward> sarnold, debian put the effort into the package :p
<teward> not me
 * teward has only been on this for about a year with the PPAs
<sarnold> teward: do you think debian upstream would be willing to accept these changes too? it'd also be nice to avoid an ubuntu delta here
<teward> sarnold, if by "upstream" you mean "debian"
<sarnold> teward: oh no, I know you've put work into it :P
<teward> then ask Debian
<teward> i have no say in what debian does/doesn't do
<teward> i just yell things at them and they sometimes listen xD
<sarnold> :)D
#ubuntu-devel 2014-03-01
<teward> sarnold, for the most part, "upstream" for the nginx package in relation to Ubuntu is Debian
<teward> in relation to Debian, "upstream" is nginx.org
<teward> and nginx.org *has* their own packages
<teward> they're  not as admin-friendly though
<teward> sarnold, i don't *mind* an Ubuntu delta for this addition of an extra binary that builds nginx.org-upstream-only modules.
<teward> it's not *that* bad of a delta for me to keep working
<sarnold> I expect the nginx.org packages are designed to work identically regardless if you're on debian, ubuntu, gentoo, arch, or centos, right? :) hehe
<teward> since that's just adding a control entry and an extra ruleset for the modules
<teward> "identically"?
<teward> probably
<teward> but "identically" is an obscure statement if you are including centos in that list
<teward> since selinux can be evil there with ngixn
<teward> nginx*
 * teward kicks his keyboard from here to /dev/null and back
<sarnold> oh sure, but that's not nginx's job to sort out :) hehe
<teward> :P
<teward> no, that's the centos people's job
<sarnold> bingo
<teward> it's also not "nginx"'s job to maintain the debian package
<teward> that's mostly maintained by non-nginx-upstream people afaict
<teward> sarnold, do we have anywhere on the wiki where we can document these things about certain packages?
<sarnold> teward: not that I know of
<teward> if all else fails I'll make an "NginxInMain" page in my own namespace regarding this, but...
<teward> i want *somewhere* publicly listed the reasoning for this
<sarnold> teward: very good idea.
<teward> even if I have to create a page for it in wiki.u.c
<teward> actually, how does one subscribe to notices for wiki edits in a given page/section of the wiki? (if you know)
<sarnold> hrm, the 'new starter' page just says "subscribe to these regexs", doesn't mention how to do it..
<sarnold> .. and clicking 'subscribe' on the front page of wiki.ubuntu.com just hangs
<teward> so does logging in right now
<teward> maybe someone should poke sysadmin about that?
<teward> (laggggggggggg)
<sarnold> teward: hey, the wiki is responsive again
<sarnold> teward: once you're logged in you can click on your username, then notification, and add regexs as you need; or, you can subscribe to an individual page with the 'subscribe' link
<infinity> teward: As I asked before, why do we need yet another ngingx binary, why not just drop the offending module(s) from -light and call it done?
<infinity> Then if we just reverse the full|light depends for the 'nginx' metapackage, we can toss that in main too.
<infinity> sarnold: ^
<infinity> Looks like light only ships one third-party module, so that would seem the easiest course of action.
<sarnold> infinity: I had considered suggesting that first, but -light is lacking UWSGI, spdy, and webdav; I figured the first two are mighty important, and the last one is perhaps convenient for someone..
<infinity> sarnold: Oh.  So you want, basically, -full or -extras, minus third-party?
<infinity> (Can modules not be distributed as DSOs, do they really need to be built in?  That would make this so much easier to deal with)
<sarnold> infinity: sure, I didn't notice much difference among all the standard modules, but things felt -different- in the third-party modules.
<infinity> Then you'd just have nginx-core and modules-extra modules-full modules-third-party...
<sarnold> infinity: no idea there, but that would feel so much intuitive to me :)
<infinity> Man, these really are all statically linked.
<infinity> Ick.
<infinity> So much ick.
<infinity> "Nginx modules must be selected during compile, run-time selection of modules is not currently supported."
<infinity> \o/
<infinity> I guess we're stuck with the current state of affairs, then.
<infinity> At least the rules looks like it would take 30 seconds to hack to support more flavours.
<teward> infinity, if you mean like apache does
<teward> that's planned
<teward> but not implemented
<teward> (yet)
<teward> while on the topic of apache, it increases disk i/o crazily, which is why people kinda like nginx :p
<teward> and other servers (still)
<teward> but meh
 * teward was busy and didn't see your messages until now
<teward> infinity, it does take about 30 seconds to hack, but to match waht sarnold wants... i have to go poke the upstream package and get a list of what they compile in
<teward> (nginx *has* an upstream package, but it's not as administrator friendly)
<teward> i'm also stuck on windows until tomorrow
<teward> so i can't do squat until then
<sarnold> teward: no no, don't bother with checking the nginx.org packages, that's too much work :)
<teward> :P
<sarnold> teward: just disable the modules listed in the debian/control file as "third party modules" in a new binary package
<teward> sarnold, ... right...
<teward> sarnold, i still have to poke around to see if certain things're enabled or not :p
 * teward yawns
<teward> sarnold, what about the metapackage
<teward> do we leave that in universe, or do we put nginx-core or w/e i name the new binary as the dependency on that
<teward> since i know enoug hpeople use just `apt-get install nginx` and expect it to work
<sarnold> teward: very good question. If I interpret infinity's suggestion loosely, we'd put nginx-main (or whatever) first in the list, then put the nginx metapackage in main also. but I really don't want to break existing users who might have installed 'nginx' but rely upon features from nginx-full
<teward> sarnold, i was considering naming it nginx-core, because it's just the core packages.
<teward> sarnold, in theory, could we do nginx-core|nginx-full|nginx-light?
<sarnold> teward: ah, that's a good name.
<sarnold> teward: yeah
<teward> that way it doesn't break already-installed nginx-full/nginx-light + nginx metapackage installs
<teward> but on new ones forces the use of -core
<sarnold> I don't know what will happen on dist-upgrade.
<teward> well, this is why sbuild exists
<teward> and my staging ppa
<sarnold> :)
<teward> and the five other testing PPAs I have
<teward> oh that reminds me, note to self, update my trusty VM
<teward> since that's WAY behind and needs poked upwards before i can test
<teward> sarnold, i'm probably gonna do two forms of testing...
<teward> the first making sure that i put the rules in in such a way that i can get the -core one to build
<teward> before I even get to testing the metapackage
<sarnold> tell me about it, my testing trusty vm just downloaded 600 packages. sigh. :)
<teward> (the packaging isn't exactly "neat" or "easy" here)
<teward> sarnold, eww.
<teward> sarnold, i might just nuke the VM I have now and install with the latest beta image or smth o.o
<teward> sarnold, what's the timeline for the MIR changes, though, in terms of freezes I need to be aware of?
<teward> I know feature freeze already happened, but...
<sarnold> teward: we'll need to ask for a feature freeze exception; the fact that i didn't finish the MIR review ought to help encourage the release team to grant an ffe -- afterall, everyone -wants- nginx in, and this isn't exactly adding new features, just a few build-rules fiddling.
<teward> sarnold, right...
<teward> sarnold, you're gonna have to support the debdiff then when we ask for an FFe for this MIR...
<teward> and note we got in 1.4.5 to trusty while you were reviewing 1.4.4
<sarnold> teward: yeah, it seemed easier to continue where I was :)
<teward> so any debdiffs're gonna be based off of 1.4.5
<sarnold> though they had fixed the only bug I found. haha.
<teward> heh
<teward> sarnold, ooo i forgot about the rest of the packaging
<teward> sarnold, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/nginx/trusty/files/head:/debian/
<teward> sarnold, this is far more than just 30 seconds of work
 * teward points at the other files
<teward> such as install, preinst, postinst, etc.
 * teward has a headache already >.<
<sarnold> teward: definitely, it'd take me most of an afternoon before I think I'd have built packages to test. and I'm ususally too optimistic.
<teward> sarnold, you were expecting about a ~50 lines debdiff?  probably safer to say closer to ~500 lines
<teward> that much harder to get an FFe, maybe?
<sarnold> teward: well, 75 lines. but I hope it's not too bad..
<teward> i'm exaggerating, with 500
<teward> but still
<teward> it's not gonna be "small" like some security debdiffs or segfault debdiffs
<sarnold> *nod*
<teward> it's substantially larger :/
<sarnold> I just finished doing some 'new library' debdiffs for apparmor; despite how much time it took, the changes were actually surprisingly small..
<teward> i'm probably gonna end up cloning the nginx-full stuff and just tweaking it.
<teward> rename things to nginx-core and such
<teward> trim out stuff that doesn't apply, and what not
<infinity> sarnold: dist-upgrade will be fine, it's an OR dep.
<infinity> sarnold: Sort of the whole point of OR deps is to give the user choice.
<sarnold> infinity: thanks
<sarnold> infinity: well, okay, it feels a bit more obvious when you put it that way :)
<infinity> teward: It should be tiny... Add a package to debian/control, a new configure stanza in rules, and copy the .install files.
<infinity> (Well, okay, not "tiny", but obvious and small from a reviewability perspective)
<teward> infinity, true.  my only concern is if, like, something bad happens and it ends up turning into a hack job
<teward> which it *shouldn't* if i base it off what already exists for -full
<teward> infinity, the debdiff's gonna catch all the new .install, .pre* etc. files though
<infinity> Yeah, that's fine.
<teward> that's what i mean by being "more than would normally be expected"
<teward> but this is a project for tomorrow, i'm still stuck on this [WORDS REMOVED] Windows system.
<infinity> I could just whip it up now. :P
<teward> infinity, i'd like to put my name on the debdiff though :p
<teward> infinity, besides, i need something to do tomorrow
<teward> rather than sit on my butt doing nothign
<teward> oh good this ISO's done downloading (finally, after 4 hours)
 * teward boots into Linux
<infinity> teward: I'm kinda halfway done.  But you're welcome to have it when I am. :P
<infinity> teward: http://paste.ubuntu.com/7013893/
<infinity> teward: Merry Christmas, you get to write a changelog that doesn't suck. ;)
<infinity> sarnold: ^-- That look like what you had in mind?
<sarnold> "stuff and things" :) haha
<sarnold> teward: hey you were closer, 297 line debdiff
<sarnold> infinity: ACK. looks great. :)
<infinity> sarnold: Builds fine, debdiffs of the binaries look sane.
<teward> sarnold: infinity: yeah, that's about what I get, i'm test-building in sbuild before i make the debdiff uploaded with my name on it instead
<teward> because I'm crazy paranoid
<teward> and i want to make sure it actually builds here too
<teward> since i have two custom builds that'd be based off of this in a private apt repository on my network
<teward> (so I need to know it builds :P)
<infinity> teward: Did diff I gave you builds and produces sane binaries, already tested.  But do test again.
<infinity> teward: And if your diff is significantly different from mine, I'd be curious why.
<infinity> (Note, if you were tempted to reproduce the Breaks/Replaces bits, those are unnecessary, since that old version of -core never existed)
<teward> infinity: yeah i did add that, but i can remove that from the debdiff before i submit it
<teward> (it may be unnecessary, but i added it in because consistency)
<teward> they look basically identical, save for the debian/changelog entry
<teward> ... note to self, don't let sbuild chroots go for weeks without updating >.>
<teward> infinity: there will be minor differences, like, in the rules, I put the core build-dir after the existing config rules and builddir rules, and put it at the end of flavours.  i could easily switch them around to match your changes
<pranith__> can someone point me how to create a package from source? I am trying to package gnu global which is here: https://code.launchpad.net/~bobby-prani/gnuglobal/global-6.2
<pranith__> I am following instructions here but getting errors: http://packaging.ubuntu.com/html/packaging-new-software.html
<teward> sarnold: infinity: Am I being too verbose in my changelog entry here?  http://paste.ubuntu.com/7013991/
<teward> (opinions and suggestions welcome)
<darkxst> pranith__, we are not mind readers, post logs of the failure ;)
<sarnold> teward: perhaps modify the nginx-core.* line to say which ones you copied from -- but looks good to me, thanks
<teward> sarnold: that one's easy :p
<pranith__> darkxst, I created a branch of upstream source on launchpad and I am not seeing the source files in it...
<pranith__> so when I try to compile it.. it is erroring out when applying the patches
<teward> sarnold: infinity: this look about right to ya?  http://paste.ubuntu.com/7014014/
<teward> (that's the entire debdiff I have)
<Noskcaj> pranith__, Please link us a build log
<sarnold> teward: line 85 looks off, nginx-core-dbg Depends: on nginx-full, not nginx-core
<sarnold> teward: line 269 looks off, it does a cd $(BUILDDIR_full) instead of $(BUILDDIR_core)
<teward> sarnold: oops
<teward> sarnold: that it?
<sarnold> teward: it's all I spotted :)
<teward> sarnold: http://paste.ubuntu.com/7014046/ is the version that includes those fixes, if you'd like to go over it or have others go over it before i upload the .debdiff and attach to the MIR, feel free to.  :)
<sarnold> teward: both nginx-full and nginx-core have a Description that includes "(standard version)" -- it might be worth changing the nginx-core and nginx-core-dbg Descriptions to say "(core version)" so that apt-cache search nginx | grep ^nginx  will show a difference between the packages
<infinity> teward: ubuntu2, not ubuntu1.1 ... And all the diffs between mine and yours look to be mistakes.
 * teward grumbles
<infinity> http://paste.ubuntu.com/7014075/
<infinity> So, description issues, line-wrap issues, and whitespace issues.
<teward> yeah...
<teward> that's probably a side effect of me being tired >.>
<infinity> Small mistakes, mind you, but I'm anal. :P
<teward> infinity: the whitespace issue on the rules file i don't see
<teward> i think i actually *fixed* that...
<infinity> teward: The diff you pasted has an extra tab there that doesn't need to be.
<infinity> Which doesn't break GNU make anyway, but meh.
<teward> ahhh
<teward> infinity: okay, see, if there is an extra tab in there, gedit can't find it.  http://paste.ubuntu.com/7014088/ doesn't seem to have that extra tab where your diff of the diffs says it should be
 * teward yawns
<teward> i should seriously probably go to bed >.>
<teward> (and thanks for checking these things though)
<Noskcaj> Could someone please sponsor a few packages? The queue is now on 50 different things
<teward> infinity: i do kinda want to get this uploaded, though, so hopefully there's nothing wrong with this debdiff (i've remade it enough xD)
<teward> s/uploaded/debdiff uploaded to the Launchpad bug/
<infinity> teward: That's missing the extra tab, but has an s/core/full/ bug.
<teward> grrrr
<infinity> teward: Do you need a sponsor for this?
<infinity> http://paste.ubuntu.com/7014124/
<infinity> If so, I'll just fix the three issues there and upload.
<teward> infinity: the procedure is upload to the Launchpad bug, get FFe (if nobody yells at the debdiff), then upload
<teward> unless you can also approve an FFe
<teward> s/upload/find a sponsor to upload to trusty/
<infinity> I can.
<infinity> My sponsoring would be tacitly approving the FFe at the same time. :P
 * Noskcaj directs infinity to bug 1282937
<ubottu> bug 1282937 in xfburn (Ubuntu) "FFe: Please package xfburn 0.5.0" [Undecided,New] https://launchpad.net/bugs/1282937
<teward> infinity: http://paste.ubuntu.com/7014141/ is the latest iteration, please check
<teward> infinity: and i will need a sponsor, I have yet to finish a PPU application and file it
<teward> because (1) lazy, (2) work, (3) [secret reasons]
<teward> infinity: at least, i think that last iteration is right
<teward> it may not have copied right :/
 * teward yanws
<teward> bleh, i can't even type "yawns" right >.>
<infinity> teward: That iteration's better, except for the space in control that's driving me nuts that I'll strip before I upload. :)
<teward> infinity: heheh, the extra space in the control file is really irking you isn't it xD
<infinity> You have no idea.
<infinity> Anyhow, if you're happy with this, I'll upload it.
<YokoZar> infinity: Were you the one I was supposed to poke ~ wine1.6 being stuck in proposed
<YokoZar> due to britney not liking the cross-arch wine1.6 dependency
<teward> infinity: lemme upload it to the launchpad bug
<teward> because i'm in on a temporary folder that'll get nuked after a while
<teward> so i want this debdiff to be visible there :P
<infinity> YokoZar: Maybe.
<infinity> teward: Oh, the MIR also mentions that this needs to be bumped to the lua version in main while we're at it.
 * infinity test builds with s/5.1/5.2/
<teward> infinity: say what now?
<teward> infinity: did I miss that?
<infinity> teward: Yes.
 * infinity test builds with lua5.2.
<pranith__> Noskcaj, I created a local branch from lp:global and added the necessary debian files
<pranith__> when I try to give the command bzr builddeb ... it errors out saying not able to get orig-source
<teward> infinity: if that works i'll bump the build-deps, but the lua dep is for the universe package :/
<teward> infinity: and do let me know if it works, as i can add the change to the changelog and the debdiff
<infinity> Nope, it's going to need a patch, probably.
<pranith__> where do I added the upstream source info so that bzr get-source-package does not fail?
<teward> infinity: if and only if the Lua module, which is third party, works with 5.2
<pranith__> add*
<infinity> teward: That sentence didn't make a whole lot of sense. :P
<pranith__> or create a source tar ball from my current tree while packaging?
<teward> infinity: you're right, i'm tired, it happens
<teward> infinity: your "it's going to need a patch, probably" statement is throwing me off, which needs the patch, the nginx lua module? or something else?
<pranith__> darkxst,
<pranith__> ?
<teward> infinity: actually, I checked the upstream source for that module - https://github.com/chaoslawful/lua-nginx-module
<teward> infinity: it doesn't support 5.2 yet.
<infinity> Where there's a will, there's a way.
<teward> infinity: the only option to address that would be to disable the module, which means I think we can then drop the Lua build-dep
<infinity> That's hardly the only option. :)
<sarnold> how bad is the breakage?
<teward> infinity: if you've got a better option i'll take it :P
<teward> infinity: i expect, though, that there'll be a FTBFS, and unless you can recode the module for 5.2, well...
<teward> then there is no patch to fix it
<teward> (yet)
<teward> okay, i can't stay up any more without running the risk of passing out over my keyboard, if you find a fix let me know, infinity, but use a privmsg, because otherwise I might miss it
 * teward is going to bed
<sarnold> wow, looks like lua5.2 dropped a -lot- of stuff: http://www.lua.org/manual/5.2/manual.html#8
<sarnold> g'night teward, have a good weekend
<teward> is this channel logged on the irclogs?
<teward> if it is then i'll go digging tomorrow for any highlights i got :/
<teward> ... i answered my own question
<teward> g'night.
<Noskcaj> pranith__, Make the bzr branch with bzr branch lp:ubuntu/global
<infinity> teward: Okay, I took a stab at porting it, but it's a more significant effort than I have time for tonight.
<infinity> teward: Talk to me on Monday if you want some pointers, or nag upstream to fix it. :P
<toclax> Hi, I want contribute to ubuntu with code and repair packages but I don't know how start... someone could guide me?
<teward> infinity: upstream fixing it would be lovely, but I don't think they're even taking a stab at it yet based on their github
<teward> infinity: i poked upstream for that lua module and they said they'd take a look at getting it ported to 5.2 today, or at least compatible.  I hope upstream knows what evil they're going to be facint
<Laney> mlankhorst: Do you have some useful way to identify wine fixes? 1.6 broke an application for me vs. 1.4 which works again with 1.7.13 from the ppa
<Noskcaj> Can someone please review https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfdesktop4/merge ? It fixes a bug with over 140 affected users
<rbasak> infinity, sarnold, teward: just reading scrollback. I'm interested to hear opinions (from upstream, maybe) about how useful the pieces that we'll have in main will be to end users. Will they all end up having to the bits in universe instead, and in that case, how useful is the MIR? I don't mean to imply one answer or another; I'm just asking the question.
<mlankhorst> Laney: no, in general wine has weird cycles :\
<Laney> so it'd be good to get this fix, whatever it is, into 1.6 ...
<mlankhorst> yeah but without a reverse regression test.. no idea
<mlankhorst> maybe wine appdb has information
<Laney> nein
<mlankhorst> doesn't even say which wine version started working? in that case you're on your own :x
<jtaylor> I also have a wine fix for 1.4 I'd like in but I'm very confused with the current status
<jtaylor> do I stillm need to bother with 1.4?
<Laney> trusty has 1.6 now
<jtaylor> oh it migrated
<jtaylor> nice
<mlankhorst> Laney: what application?
<jtaylor> but the 1.4 still is in the archive?
<Laney> mlankhorst: http://appdb.winehq.org/objectManager.php?sClass=version&iId=26410
<mlankhorst> so what broke?
<Laney> It could launch the application but it'd just give me a dialog saying "YNAB has encountered a problem"
<Laney> there was a 'more details' button but it had 'null' for the stack trace so that's not very useful
<knocte> do the unity devs hang out here?
<mlankhorst> yeah, installing wine1.6-dbg{,:i386} package might help
<mlankhorst> but it seems like it's using its internal handler which makes things harder
<mlankhorst> is there anything useful in the console when it crashes?
<Laney> this dialog was internal to the application
<Laney> it was handling the crash somehow
<mlankhorst> yeah, anything in the console window at the time of crash?
<Laney> nothing useful
<Laney> can I downgrade back to 1.6?
<Laney> it did some 'upgrading .wine' thing
<mlankhorst> no idea then, I would try to install older wine1.7 packages, find the first workng one
<mlankhorst> yeah usuall
<mlankhorst> usually*
<Laney> getting those is going to be a pain
<Laney> oh actually they're here https://launchpad.net/~ubuntu-wine/+archive/ppa/+packages?field.name_filter=&field.status_filter=superseded&field.series_filter=trusty
<mlankhorst> try the oldest one for saucy first
<mlankhorst> then you know how much of a pain it will be :p
<Laney> launchpadlib is a beautiful thing
<Laney> mlankhorst: bad news, 1.7.8 is the oldest available and it works
<mlankhorst> fun
<Laney> can you give me 1.7.4 debs?
<Laney> or older
<alberts> Hi! Maybe someone here are able to help me regarding gtk? http://stackoverflow.com/questions/21969436/how-to-make-gtkplug-transparent-so-that-gtksocket-background-is-seen.
<knocte> where's the source code of unity that checks the UBUNTU_MENUPROXY env var? https://launchpad.net/unity doesn't contain this check
<knocte> alberts: I guess you would have better luck in irc.gnome.org/gtk+
<Noskcaj> debfx, Is it worth packaging the latest steam bugfix release for trusty? Changes are at http://paste.ubuntu.com/7018443/
<Noskcaj> bdrung, Could you package python-versiontools for debian? It's needed to fix the gevent-socketio ftbfs in ubuntu (and should be a build-depend of gevent-socketio in debian)
<bdrung> Noskcaj: yeah, i could do that. can you send me a reminder to benjamin.drung@profitbricks.com?
<knocte> where's the source code of unity that checks the UBUNTU_MENUPROXY env var? neither https://launchpad.net/unity nor https://code.launchpad.net/~ubuntu-branches/ubuntu/trusty/indicator-appmenu/trusty contain this check
<mdeslaur> knocte: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/unity-gtk-module/trusty/view/head:/src/main.c#L826
<knocte> mdeslaur: great! thanks
<mdeslaur> yw
<teward> rbasak, I think some people rely on the third-party stuff, but rely on nginx-extras for that.  Ultimately, you may be right, people're going to use the bits in Universe over the stuff in Main.  Either way, I'll keep on maintaining it, but I think jcastro is gonna look like an idiot for saying it is likely to get into Main in his blog post (which has now ended up pretty much everywhere)
<teward> in the instance that we don't ahve something in main
<teward> infinity, sarnold: ^
<stgraber> well, people shouldn't blog about a package getting moved into main until the MIR has actually been approved ;)
<teward> stgraber, tell that to jcastro
<teward> i think there's a log about it in the community team channel, where I called him out on that
#ubuntu-devel 2014-03-02
<xnox> teward: yeah, jcastro definately jumped the gun on the announcement. Just because a MIR is filed, doesn't mean it will be approved as is, partially, or rejected.
<xnox> stgraber: i always thought that apache would stay default, the one and only in main, simply by sabdfl's heritage (first debian maintainer) in that package.
<teward> xnox, that's what I told him.
<teward> the same day he made that post
 * teward hasn't let him forget it, yet.
<teward> infinity, sarnold: the nginx MIR is going to be blocked by Lua, upstream has said basically they can't support 5.2.
<teward> they *have* suggested linking against LuaJIT 2+ but... I haven't investigated that path
<teward> infinity, so either someone who understands the module more than I needs to test this, or we drop the Lua module... :/
<teward> unless you've had any progress on your porting?
<teward> rbasak, in case you're curious... ^
<debfx> Noskcaj: I don't know, those changes don't look very important to me.
<Noskcaj> ok
<Noskcaj> and as always, please sponsor stuff :)
<saiarcot895> How hard would it be to create a personal port of existing packages to the i586 architecture?
<infinity> teward: Dropping the lua stuff seems less than ideal.  I made a tiny bit of progress on porting to 5.2, but that was in the wee hours of the morning before hopping a plane.
<infinity> teward: Sitting in the Hong Kong airport now, and not really much interest in porting random packages I don't use to new language versions while I wait for a ferry. :P
<maxb> jamespage: Hello, you are assigned to bug 894302 since 2011, are you still involved with it?
<ubottu> bug 894302 in apache-log4j1.2 (Ubuntu) "log4j jar files do not include OSGi metadata" [High,Confirmed] https://launchpad.net/bugs/894302
<jamespage> maxb, indeed
<jamespage> I'll try to get that fixed this week
<maxb> That would be nice :-) I had an "interesting" time with jitsi until I found the true problem
<ktosiek> is this the right channel for questions about creating Ubuntu packages?
<ktosiek> (I hadn't had any luck on #ubuntu, and was pointed here)
<ktosiek> anyway, how should vim plugins be packaged?
<ktosiek> ok, found how it's done by python-jinja2
<cjwatson> ktosiek: http://pkg-vim.alioth.debian.org/vim-policy.html/
<Laney> The files should be shipped as a file and directory tree isomorphic to what you want to see in a runtime Vim directory.
<Laney> definitely written by a cs academic
<ktosiek> thanks!
<ktosiek> and is there any guide to make Launchpad build from git? I'd love if it could rebase my "debian" branch on external branch, and build from that
<mitya57> You can import a git branch into a bzr branch
<ktosiek> so, I'd do "bzr init", then import, and then push that to Launchpad?
 * ktosiek has never used bzr before
<cjwatson> https://help.launchpad.net/VcsImports
<teward> infinity, yeah, well, upstream's not going to port to 5.2
<teward> they even said that for that module
<ahoneybun> is their any official trusty artwork?
#ubuntu-devel 2015-02-23
<aeoril> In the following webpage there is a section entitled "bzr-builddeb" that tells me to install bzr-builddeb.  I do not have that installed, but I do have bzr-debbuild.  I just wanted ot make sure that was correct, and if so, see what to do about getting the wiki updated (I would be glad to do it, but need to know how):  https://wiki.ubuntu.com/SimpleSbuild#bzr-debuild
<aeoril> darkxst sarnold ^
<aeoril> (to see if bzr-debbuild is correct, not bzr-builddeb)
<aeoril> also, it does not say how to install schroots for different versions - I am assuming for vivid, for instance, it would be "mk-sbuild vivid"?
<aeoril> or, is are there other steps I need to do to make an schroot for other versions before that?
<darkxst> aeoril, bzr-builddeb is correct
<darkxst> easiest make to make schroots is with sbuild-launchpad-chroot
<aeoril> darkxst ok, i thought so - should I e-mail the owner of that page to inform them it is mis-spelled?
<darkxst> aeoril, no, that is something else
<aeoril> darkxst what is something else?
<aeoril> oh, youi said builddeb is correct, not debbuild ... sorry
<darkxst> aeoril, they are 2 different tools
<darkxst> by the looks of it
<aeoril> darkxst yes, I understand now - I guess I need to install bzr-builddeb?  This is a fresh machine and I did not install any build or developer tools other than what were in the directions on that page.  Apparently, I was supposed to know to install bzr-builddeb - are there other things I am missing on a fresh machine for development?  is there a wiki to follow to get set up for building
<aeoril> properly?  I am familiar with the BeginnerTeam wiki, but know that that team has not been active for quite some time
<darkxst> aeoril, there is this http://packaging.ubuntu.com/html/getting-set-up.html
<darkxst> but there is no definitive guide since they are multiple ways to do every step of packaging
<aeoril> darkxst ok, I will follow that - I guess once I get everything set up correctly, I need to remake my schroot to reflect the changes in my machine?
<darkxst> your schroot is isolated from your machine
<aeoril> darkxst where did it pull its packages from?  I guess not my machine, but the "magic appropriate place on the web???"
<darkxst> if you used sbuild-launchpad-chroot, it pulls an image off launchpad
<darkxst> if you use mk-sbuild, I suspect it would use debbootstrap to make a minimal environment
<darkxst> anyway gtg
<aeoril> hmmmm ... on that wiki page, it just had me do 'mk-sbuild trusty'
<aeoril> ok, thanks
<darkxst> sbuild-launchpad-chroot, gives  you an schroot almost identical to the archive builders
<aeoril> darkxst yes, I have used it now and will experiement - thanks!  I think this will really help!
<pitti> Good morning
<pitti> mitya57: it's already gone from private jenkins, the public one needs an RT to clean up
<aeoril> I have set up schroots with sbuild-launchpad-chroot on a trusty 14.04.1 LTS machine.  After successfully running sbuild-launchpad-chroot create and and creating a local repo of ubiquity with "bzr branch lp:ubiquity" I ran the sbuild command to build for vivid from the ubiquity directory.  Unfortunately, it did not complete successfully and failed as follows:  http://paste.ubuntu.com/10367718
<aeoril> /  The isntructions had a final parameter "<dsc>" I left off - not sure what to put there.  Any ideas why this is failing?
<aeoril> darkxst sarnold ^
<aeoril> Do I need to do the following first? "dch -i; update-maintainer; debuild -S"
<darkxst> aeoril, yes build the sauce package, then pass that .dsc file to sbuild
<darkxst> source even
<aeoril> darkxst debuild -S failed with the same error as sbuild as well as the following:  "dpkg-buildpackage -rfakeroot -d -us -uc -S failed"
<darkxst> aeoril, do you have pyflakes installed?
<aeoril> I think ./test/run-pyflakes is failing
<aeoril> oh, maybe not - just a minute
<aeoril> darkxst ok, got past pyflakes and pep8 install and run, but failing here.  I don't understand why it is doing this since that directory does not appear to exist:  http://paste.ubuntu.com/10367924/
<darkxst> aeoril, are you building from a bzr branch? use bzr builddeb -S if so
<aeoril> darkxst yes, I am building from a bzr branch thanks
<aeoril> darkxst well, it went a lot better, much more stuff happened, but I got an error that included the text "you may need to install the Debian::Debhelper::Sequence::d_i module" - I can give you the entire error if you need it
<aeoril> dh: unable to load addon d-i: Can't locate Debian/Debhelper/Sequence/d_i.pm in @INC (you may need to install the Debian::Debhelper::Sequence::d_i module) ...
<darkxst> aeoril, I am going to guess you are missing some debhelper tool
<aeoril> darkxst yes, I figured that, but I don't know which one ...
<darkxst> apt-get build-dep ubiquity (should hopefully get it)
<darkxst> or try apt-file find d_i.pm
<aeoril> darkxst hmmmm ... I thought the whole idea was to do this using sbuild in an schroot as close to the build environment on launchpad as possible?  I am confused as to exactly what I am accomplishing right now ...
<darkxst> aeoril, some tools are required to build source packages (sbuild can't help there)
<darkxst> sbuild is for building the binaries
<aeoril> darkxst wouldn't it be better just to find the tools necessary to build the source packages, rather than getting *all* the build dependencies?  Wouldn't getting build dependencies gunck up my regular machine?
<aeoril> (in other words, do your second suggestion?)
<darkxst> aeoril, do whichever way you prefer
<aeoril> darkxst I think everything built, but now I have a gpg error.  I thought I set up GPG right - is there a way to test it?:  http://paste.ubuntu.com/10368218/
<darkxst> aeoril, you need to set a default key (or add your own changelog entry)
<aeoril> darkxst oh, in .bashrc?
<darkxst> aeoril, in ~/.gnupg/gpg.conf I think
<dholbach> good morning
<aeoril> darkxst this says to do it in .bashrc? https://help.ubuntu.com/community/GnuPrivacyGuardHowto (search for "default key")
<aeoril> dholbach good morning :)
<dholbach> hi aeoril
<darkxst> aeoril, I imagine either would work
<hyperair> so i've got a bluetooth mouse here that refuses to reconnect after going into powersave mode
<hyperair> how do i debug this?
<hyperair> hmm it keeps failing with bluetoothd[25955]: plugins/hciops.c:link_key_request() Matching key not found
<mariel> darkxst thanks, everything is working now.  Setting the default gpg id in both .bashrc and .gpg.conf did not work - I had to add a new changelog entry for my new version
<DrTobbe> Hi, I've been in Laos and I told people there that Ubuntu is very great because it tries to be available for everyone (disabled people, all languages, and so on). Then, I found out that Lao language is not correctly supported by the default-fonts in Ubuntu (for example Ubuntu or Sans). Shouldn't we/Ubuntu implement this to keep our/its promise?
<DrTobbe> Or ... Who shold I talk to to tackle this problem?
<pete-woods> cjwatson: hi! I was wondering if you might be able to help me figure out / tell me what commands I might use on my phone to install a click package into the preinstalled db at /usr/share/click/preinstalled/
<cjwatson> pete-woods: Odd to do that on the phone rather than in a chroot elsewhere while preparing an image!
<cjwatson> pete-woods: Should be something like "sudo click install --all-users --root=/usr/share/click/preinstalled foo.click"
<pete-woods> cjwatson: yeah, just testing something out. thanks for the help!
<cjwatson> np
<caribou> Q: Am I wasting my time trying to fix FTBS 'Ã  la' PlusOneMaintenance ?
<rbasak> caribou: why do you ask?
<rbasak> It's generally useful, assuming you send fixes upstream.
<rbasak> Though I did find it generally unending and thankless, and didn't feel it made that much of an impact when I did it - particularly for packages in universe.
<caribou> rbasak: because there doesn't seem to be any formal activity with the PlusOne Maintenance team anymore
<rbasak> It did make my application for MOTU much more useful though :)
<rbasak> s/useful/credible/ perhaps
<caribou> rbasak: it is also partly my intent : get exposure for all sort of packaging problems to gain experience
<caribou> rbasak: for instance, the deja-dup FTBS is peculiar as it does build as PPA and locally and not in the builder
<rbasak> That certainly is useful for experience :)
<rbasak> I think that doing universe FTBFSes helped me more than I thought at the time.
<caribou> rbasak: so what should I do with this one ? open a bug & attach the debdiff ? branch & MP ?
<caribou> rbasak: since I cannot upload myself
<caribou> maybe mterry will want to sponsor it
<mterry> caribou, rbasak: a deja-dup ftbfs?  fun.  Point me at bug and I'll try to get to it
<caribou> mterry: oh, I fixed it
<mterry> caribou, but you need a sponsor, right?
<caribou> mterry: ok, I'll create the bug & attach the debdiff. Or maybe you prefer a branch
<caribou> mterry: yep
<mterry> caribou, either is fine, but don't bother with a branch if you already have a debdiff
<caribou> mterry: hmm, it'll have to be a debdiff, there's an in-flight source modification into -proposed
<caribou> matter of fact, this is what introduced the FTBS
<caribou> Noskcaj: you have the deja-dup uploaded into -proposed
<caribou> mterry: ok, I'll create a bug & attach the debdiff against the source in -proposed
<rbasak> caribou: I'll leave you with mterry. Just FYI, when I was doing +1 and had a bunch of FTBFS fixes, rather than creating a branch I just stuck all the updated source packages online somewhere. Sponsors were happy to use that, rather than doing the busywork of creating a ton of bugs.
<caribou> rbasak: good to kwow, thanks
<rbasak> caribou: I guess the MP/bug debdiff workflow works better for actually putting things in the sponsorship queue though
<rbasak> But if you have a sponsor lined up, they usually don't mind how they get the work.
<caribou> rbasak: it always depend if the sponsor is already identified (as it is in the current case)
<rbasak> Right
<caribou> rbasak: i was just surprized by the difference of build behavior b/w local & the archive builder
<rbasak> Ah.
<rbasak> That surprised me too when I started.
<caribou> rbasak: I did have a previous situation where it was a parallelism issue involved
<rbasak> Apparently it's quite difficult to replicate the archive builder exactly, so most devs don't bother and it works in the majority of cases.
<rbasak> In the odd cases where it doesn't, comparing the build logs can often identify the issue (I use meld)
<rbasak> And when that still doesn't work, I get help here from the devs who are closer to the builders (generally archive admins, etc)
<aeoril> darkxst I found two equivalent .deb files created by the ubiquity build (same name but different version as oem-config_2.21.13_all.deb and oem-config-gtk_2.21.13_all.deb) in the Ubuntu .iso for the livecd in the following directory:  pool/main/u/ubiquity Do I just replace those two package files with the ones I made with my compiled changes in the .iso then use that .iso to create a
<aeoril> bootable live cd to test the install?
<mterry> caribou, yeah I can take debdiff however you like, if you don't want to bother with bug
<aeoril> or whoever knows
<caribou> mterry: no worry, bug is done already, just doing a bit of description there
<caribou> mterry: it's all there LP: #1424652
<ubottu> Launchpad bug 1424652 in deja-dup (Ubuntu) "deja-dup 32.0-0ubuntu3 fails to build following change in Build-dep" [Low,Confirmed] https://launchpad.net/bugs/1424652
<xnox> pitti: i love the typo you made re:mtab vs mountinfo "Yes, it arses it just fine"
<xnox> vs parses =)
<pitti> xnox: that was a case of SCNR indeed :)
<xnox> pitti: so given the new enough util-linux with that toggle enabled, can the /etc/mtab symlink be dropped?
<xnox> pitti: or is there anything else that reads it?
<pitti> xnox: no, there's still lots of other things which look at that
<xnox> pitti: name one
<pitti> or, let's rather say, we don't know
<xnox> udev, systemd, util-linux no longer do.....
<pitti> we could drop it and see what happens, but that's not a good idea post-FF
<pitti> indeed, any well-behaved program/script ought to parse /proc/self/mounts or the output of "mount"
<pitti> http://codesearch.debian.net/results/%2Fetc%2Fmtab/page_0 has 186 pages, ugh
<pitti> xnox: the last page has a few
<pitti> http://codesearch.debian.net/results/%2Fetc%2Fmtab/page_185
<pitti> xnox: so cleaning those up sounds like a nice vivid+1 project
<xnox> where is KMTAB defined?!
<xnox> nevermind non-linux codepath....
<rbasak> infinity: FYI, a fix for percona-galera-3 !Intel FTBFS is in progress.
<rbasak> Once done, I'll poke you to review all the binNEWs.
<rbasak> And to process bug 1417328
<ubottu> bug 1417328 in percona-xtradb-cluster-5.5 (Ubuntu) "Please remove 5.5 versioned MySQL and variants from vivid" [Undecided,New] https://launchpad.net/bugs/1417328
<xnox> pitti: glibc seems to be using /etc/mtab =(
<Laney> second CfV sent to u-d-a@ if someone could moderate
<pitti> Laney: done
<Laney> cheers!
<smoser> anyone else reported menus living in their windows title bar rather than the top unity panel?
<Laney> that happened on purpose
<smoser> oh. really
<didrocks> smoser: http://www.webupd8.org/2015/02/locally-integrated-menus-lim-set-as.html
<Laney> http://www.webupd8.org/2015/02/locally-integrated-menus-lim-set-as.html
<Laney> DAMN!
<didrocks> \o/
<Laney> read my link, it's better
<didrocks> coming from UK, so closer to you, obviously :)
<smoser> Laney, thanks.
<Laney> yw
<mterry> caribou, uploaded, only change was adding bug number to changelog
<caribou> mterry: oh right, I built the debdiff before opening the bug
<caribou> mterry: thanks !
<mterry> caribou, I'm curious why it fails in archive but not locally
<caribou> mterry: couldn't figure it out either since appdata-validate still works but throw the DEPRECATED message
<caribou> mterry: I'll be attentive to the next build
<caribou> mterry: ok, I know why it worked locally : appdata-validate was not the reason it was failing
<mterry> caribou, yeah, we need to pass --nonet
<mterry> caribou, just saw the failure myself
<mterry> caribou, I can do that myself real quick
<caribou> mterry: ok, but I'd like to know what you changed. It'll outline why it didn't work on the builder to me
<mterry> caribou, http://bazaar.launchpad.net/~ubuntu-desktop/deja-dup/ubuntu/revision/42
<mterry> caribou, the validate tool was hitting network and couldn't, so it failed validation
<caribou> mterry: ah, ok I get it
<mterry> caribou, though I would have expected the PPA builds to fail then?
<mterry> caribou, and I think that was a behavior difference in the tool too -- it didn't used to try to hit the network to test the screenshots in the file.  But they added a feature that does that I guess
<caribou> mterry: me too, that's why I built both .3 & .4 in my PPA prior to going for sponsor
<mterry> caribou, well...  maybe .5 will fail for some other reason  ;)
<mterry> caribou, .5 worked on i386...  so that's good
<caribou> mterry: good !
<caribou> mterry: builds fine on amd64 as well
<mterry> caribou, OK.  Chalk that up to mysterious network access in the PPA...?
<mterry> caribou, it was hitting launchpad.net
<mterry> caribou, maybe PPAs allow doing that because they sometimes pull from other PPAs
<caribou> mterry: yes, most probably
<cjwatson> Shouldn't be any difference.
<caribou> mterry: & the previous behavior of appdata-validate changed as well
<cjwatson> launchpad.net itself, or a subdomain?
<mterry> cjwatson, https://launchpad.net
<cjwatson> Other PPAs aren't on launchpad.net, neither the same physical host nor the same DNS name
<cjwatson> So that's not the reason
<cjwatson> And in any case the distinction is not likely to be PPA vs. Ubuntu, but non-virtual vs. virtual
<cjwatson> And non-virtual builders build some specialised PPAs too
<cjwatson> "url not found" hides some underlying error, so it's hard to say.
<pitti> PSA: d-jenkins is unhappy again, so if you see a bunch of autopkgtest failurs which look weird, we're on it
<pitti> Laney, Mirv, etc. ^
<cjwatson> 91.189.89.30 - "10.122.37.20, 127.0.0.1" "launchpad.net:443" [23/Feb/2015:16:19:21 +0000] "GET /deja-dup/32/32.0/+download/screenshot-2.png HTTP/1.0" 302 526 9 0.105017185211 594 102 "Anonymous" "LibraryFileAlias:+index" "" "libappstream-glib"
<cjwatson> I wonder why that's getting a 302
<cjwatson> Oh, of course, 302 to the librarian
<cjwatson> Then AFAICS the librarian never sees the redirected request.
<cjwatson> But that's odd since buildds explicitly have librarian access.
<pitti> infinity, cjwatson, wgrant: FYI, fisher03's apache hasn't responded in 2 days for ddeb retrieval; if that keeps being broken, we'll lose ddebs in 5 days
<cjwatson> pitti: Needs infinity; wgrant and I can't help, but thanks for the heads-up
<pitti> cjwatson: yeah, I figured; it was more an FYI for you
<cjwatson> wgrant: Do you know if we have access to the specialised buildd DNS code, and if it's the same for non-virt buildds and scalingstack?  Surely it should be, but I can't see why the deja-dup thing above would have broken on non-virt builders but apparently not on scalingstack.
<infinity> cjwatson: I'd be willing to bet scalingstack's DNS setup isn't the same, actually (and that should be fixed).
<infinity> pitti: Looking.
<infinity> [602822.116012] sd 0:0:0:0: rejecting I/O to offline device
<infinity> ^-- qemu emulating real hardware a bit TOO well.
<ogra_> just online it :P
<cjwatson> infinity: I'm a little surprised that anyone would have bothered to do it differently.
<cjwatson> There's a nagios test defined in canonical-is-openstack-deploy to the effect that hp.com returns NXDOMAIN.
<cjwatson> So there's definitely something similar in spirit in place.
<infinity> Hrm.  Curious.
<infinity> Well, it's going to be a different view (or a different server entirely) because it's not the same subnet, or possibly even network, but yeah, you'd have expected it to be either a straight cargo-cult or wide open.
<flexiondotorg> infinity, Do you have a sec?
<cjwatson> It's the same server, according to puppet.
<cjwatson> (salmonberry)
<cjwatson> Oh, no, that's the puppeteer
<infinity> flexiondotorg: Perhaps.
<cjwatson> I think ... don't know this stuff very well
<flexiondotorg> infinity, I'd just like to ask when it might be possible to try build Ubuntu MATE images?
<infinity> flexiondotorg: Oh.  This week.  Maybe even today.  Let me wake up a bit and confer with cyphermox on what he believes the status of things are.
<cjwatson> flexiondotorg: We can kick off another attempt any time.
<infinity> flexiondotorg: Or, if Colin has context, what he said. :P
<cjwatson> I mean, if the necessary packages are in place.
<flexiondotorg> cjwatson, Another attempt?
<flexiondotorg> Has it been tried before?
<cjwatson> flexiondotorg: Yes.
<flexiondotorg> cjwatson, I didn't know that.
<cjwatson> It failed, fairly obscurely but I think you were known to be missing some packages at the time.
<flexiondotorg> Are there some error logs I can look at? If there is stuff to be fixed I'll get stuck in.
<cjwatson> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-mate/vivid/daily-live-20150220.log
<flexiondotorg> Thanks.
<cjwatson> But https://launchpadlibrarian.net/198284153/buildlog_ubuntu_vivid_amd64_ubuntu-mate_BUILDING.txt.gz doesn't really have much to go on.
<infinity> That's not the most informative failure...
<flexiondotorg> cjwatson, infinity Reading both logs.
<flexiondotorg> Yeah, the first log I can't do anything with.
<cjwatson> The first just links (indirectly) to the second.
<infinity> I meant the livefs log wasn't informative. :P
<cyphermox> right, that failure tells me nothing as to what might have gone wrong
<infinity> The cdimage log is totally informative, just brief.
<cjwatson> infinity: It's a bit opaque ...
<infinity> cjwatson: "a bit".
<cyphermox> next step for me was to ask you cjwatson or infinity for help
<infinity> cjwatson: I think we're log past due cranking up the verbosity on live-build.
<cjwatson> Wait.  Does the ubuntu-mate-core task actually exist?
<infinity> cjwatson: As in, for the love of god, tell me what command you were trying to run.
<cjwatson> Nobody ever changed ubuntu-archive-publishing to generate it ...
<cyphermox> ah, that's something we didn't know about
 * cjwatson fixes that
<flexiondotorg> Thanks guys.
<flexiondotorg> cyphermox, Hi ð
<cjwatson> Should be better in a couple of publisher cycles.
<cyphermox> cjwatson: was that something we could change in a code branch or did that require special access?
<flexiondotorg> cyphermox, mate-tweak and mate-menu are still in the Upload Queue.
<cjwatson> cyphermox: lp:ubuntu-archive-publishing
<cyphermox> flexiondotorg: that won't help
<cyphermox> cjwatson: thanks
<infinity> Yeah, I didn't have time to look at them on Friday, I'll poke today.
<infinity> Oh, wait.  I looked a bit.
<infinity> flexiondotorg: I had a copyright complaint about mate-menu. :P
<cjwatson> https://code.launchpad.net/~acidburn0/+recipe/ubuntu-archive-publishing-daily  WTF
<infinity> Copyright: *No copyright*
<infinity> License: GPL-2+
<infinity> ^-- That is literally impossible.
<infinity> You can't have a copyright license and assert no copyright.  And "no copyright" is almost certainly a lie anyway.
<infinity> Given that all creative works (in most jurisdictions) have copyright attached to them just by being created.
<infinity> pitti: The fishers should be marginally less grumpy.
<flexiondotorg> infinity, OK. That copyright stuff is what was recommended by the DD I am working with.
<cyphermox> infinity: that may have rather meant that the file itself didn't have a copyright notice but there is COPYING there
<pitti> infinity: cheers!
<cyphermox> I thought there was a "assuming blah blah" line just below or in Comment: or something
<infinity> cyphermox: I know exactly what it means, but it also won't do.
<infinity> cyphermox: "I don't know who owns the copyright and who supposedly gave me the license to distribute" isn't a helpful license.
<cyphermox> infinity: fortunately flexiondotorg here is supposed to be the upstream and able to explain
<infinity> cyphermox: They're asserting the license is probably the one in COPYING (a fair assumption), but no copyright.
<infinity> flexiondotorg: So, uhm... Who owns the copyright on those files? :P
<cyphermox> oh
<cyphermox> the copyright *owner*
<infinity> Yes.
<cyphermox> I see now
<flexiondotorg> infinity, I forked another project. They did not provide copyright headers in all the sources.
<infinity> A copyright license without provenance isn't a license.
<cyphermox> infinity: of course not
<infinity> flexiondotorg: Headers in all the files aren't necessary, but a statement of copyright ownership on the copyrightable bits is important.
<infinity> flexiondotorg: Certainly, some of this junk is just glue and not subject to copyright anyway, but I see logos and such under this non-copyright, which won't do at all.
<flexiondotorg> infinity, OK. One sec then.
<flexiondotorg> Copyright: 2007-2014, Clement Lefebvre <root@linuxmint.com>
<flexiondotorg>            2015, Martin Wimpress <code@ubuntu-mate.org>
<flexiondotorg> That ^^^^^ is the suitable copyright. Given that it include the original author and myself (new upstream maintainer).
<infinity> flexiondotorg: And that applies to, say, data/icons/mate-logo.svg ?
<cyphermox> flexiondotorg: Clement is the person who designed the logos (for example) originally in the project you forked?
<flexiondotorg> infinity, Do you want me to resubmit or can/will you make the required change?
<infinity> flexiondotorg: If so, get someone to fix the copyright file to be sane in that regard (and perhaps also note correct copyrights in the upstream project too)
<flexiondotorg> cyphermox, No, that particualr file was created by myself and Sam Hewitt.
<flexiondotorg> infinity, Updating the upstream project won't happen. I've tried that already.
<flexiondotorg> Not upstream
<infinity> flexiondotorg: I mean your upstream project. ;)
<infinity> flexiondotorg: Not the one you derived from.
<flexiondotorg> infinity, Understood (eventually) ð
<flexiondotorg> OK, I will update the copyright now...
<infinity> flexiondotorg: As in, you just said that data/icons/mate-logo.svg comes from you, not from your upstream, so "I don't know who owns the copyright" isn't even a factual answer. :)
<infinity> flexiondotorg: So, yeah.  Please sort.  Make sure things are sanely attributed.
<flexiondotorg> infinity, Like I say. That copyright file was prepared my the DD I'm working with.
<infinity> flexiondotorg: I'll reject that one from the queue now, and expect a shinier version.  And I'll go review the other one.
<infinity> flexiondotorg: Check.  Pass on my ire to him about the senselessness of "no copyright" then. :)
<bdmurray> Riddell: can you have someone look at these PEP8 failures? http://pastebin.ubuntu.com/10375047/
<Riddell> bdmurray: hmm? I was able to build and upload it from my laptop was I not?
<bdmurray> Riddell: did you use bzr-buildpackage or debuild?
<flexiondotorg> infinity, Would you accept this debian/copyright?
<flexiondotorg> http://paste.ubuntu.com/10375062/
<infinity> flexiondotorg: If it's factually correct.
<infinity> flexiondotorg: I see no mention of Sam Hewitt in there, who you highlighted above, for instance.
<flexiondotorg> I've just added that ð
<flexiondotorg> Files: data/icons/mate-logo.svg
<flexiondotorg> Copyright: 2014, Sam Hewitt <hewittsamuel@gmail.com>
<flexiondotorg> License: GPL-3+
<Riddell> bdmurray: I think I used bzr-buildpackage, let me try again
<infinity> flexiondotorg: 3+, not 2+ like everything else?  Whee.
<flexiondotorg> infinity, Sam releases everything as GPL 3+.
<flexiondotorg> I've include the GPL3+ license bioler plate too.
<infinity> flexiondotorg: Kay.  So, that also means the PNG produced from it is 3+
<infinity> flexiondotorg: But yes, that looks better. :)
<flexiondotorg> infinity, Yes, the original artwork is GPL3+ licensed.
<flexiondotorg> infinity, http://paste.ubuntu.com/10375144/
<infinity> flexiondotorg: mate-tweak has the same problematic "no copyright" clause.
<flexiondotorg> infinity, On it..
<infinity> flexiondotorg: Oh, also, the copyright on COPYING isn't you (and, really, you shouldn't bother including it in the list of files at all).
<infinity> Unless you'd like to pretend you wrote the GPL. ;)
<Riddell> bdmurray: ok I can recreate it, do you know what all the problems are with all the "'from PyQt5.QtCore import *' used; unable to detect undefined names" messages? does it just not  like wildcard imports?
<infinity> flexiondotorg: Oh, also, for future maintainability, it's MUCH simpler to collapse all those Clement/Martin copyrights down to "Files: *" and then just highlight the ones that differ.
<infinity> flexiondotorg: Since having to adust the copyright file for every new added bit is painful and error-prone.
<bdmurray> Riddell: yeah, it'd prefer from PyQt4 import QtCore instead of from PyQt5.QtCore import *
<bdmurray> s/Qt4/Qt5/
<cjwatson> https://www.python.org/dev/peps/pep-0008/ has reasoning on why wildcard imports should be avoided
<flexiondotorg> infinity, Shall I update the original packaging request bugs and direct you to them?
<Riddell> bdmurray: commited some fixes, let me know if that works or breaks
<bdmurray> Riddell: looks good, thanks!
<flexiondotorg> cyphermox, I've updated mate-menu and mate-tweak based on the feedback from infinity.
<flexiondotorg> cyphermox, Can you upload them again?
<cyphermox> flexiondotorg: sure
<flexiondotorg> cyphermox, Thanks ð
<darkxst> aeoril, easiest way to test ubiquity is probably to boot a live session, update ubiquity with your packages, then run the installer
<aeoril> darkxst what do you mean by "live session"?
<aeoril> just boot from livecd?
<darkxst> yes
<darkxst> "try ubuntu"
<aeoril> I do not have a thumb drive to boot with - can I somehow do it with just the .iso from cdimage.ubuntu.com?
<aeoril> darkxst ^
<aeoril> (I can always buy a small thumb drive for a few dollars though)
<darkxst> aeoril, use a VM
<aeoril> darkxst how do I get my ubizuity .debs into the live session though?
<aeoril> I could always just add them directly onto the livecd with iso master ...
<aeoril> ubiquity*
<darkxst> aeoril, scp, or network share
<darkxst> or ppa
<darkxst> there is no need to remaster ISO to test
<aeoril> darkxst actually, maybe adding to the iso would be easiest - it is just a copy/paste, save the iso then boot from it, I think
<aeoril> the iso from cdimage.ubuntu.com
<aeoril> iso master has a simple gui
<darkxst> aeoril, you can't just copy package files into the ISO
<stgraber> pitti: FYI, I've had someone report that the ureadahead upload broke the upgrade on their box as ureadahead would exit immediately on their box, leading to "start ureadahead" to fail
<stgraber> not sure if that's a common/normal case for ureadahead (I thought it might be for ssds and other case where ureadahead can't work)
<aeoril> darkxst I meant just to have them available after bootup, rather than scp or network share or ppa - don't I have access to the mounted .iso image from the live session?  I could use dpkg to install them into my live session from the .iso image (I assume it will be mounted as a cd?)
<aeoril> darkxst but is scp is available, that would be very easy i guess - I guess the scp client is available default in the live session?
<darkxst> it should be but if not, you can just install it
<aeoril> darkxst I was just thinking I might have to set up ssh keys and such
<darkxst> ssh can use passwords too (unless you have disabled them)
<aeoril> ok, cool - that seems simplest then.  I will try this now.  Thanks.
<aeoril> darkxst thanks for all the help - watching the sbuild go to work was amazing yesterday.  But, I had to make my own entry in changelog though to get around the gpg failure
<flexiondotorg> cjwatson, What is the correct way to instruct the image build process to "--no-install-recommends"?
<aeoril> darkxst there are a bunch of .deb files created from the build process - how do I know which one to use to install the package?
<darkxst> install all except -dbg and -dev
<aeoril> darkxst ok, that would be all of them then ...
<infinity> flexiondotorg: You'd want to make your tasks not follow recommends in that case, though it's better if you can avoid having to do that.
<infinity> flexiondotorg: What problem is recommends causing you?
<aeoril> darkxst as an fyi, I found several places where icon names needed to be fixed - there was also a warning icon that needed to be renamed, not just the "finished" icon
<aeoril> well, "info"
<aeoril> darkxst I vaguely remember maybe that using the .dsc file will install them all appropriately?  Is that just my own fantasy?
<aeoril> darkxst or is that just for source?
<aeoril> darkxst nm, looked it up myself
<aeoril> darkxst if I make a ppa, will "sudo apt-get install ..." automatically install all the .deb files for me that sbuild created?
<aeoril> darkxst also, would that be a good way to attach the fix to the bug?
<aeoril> (just reference the ppa?)
<darkxst> aeoril, yes, but you don't use sbuild in that case
<aeoril> darkxst would I build it with a recipe then?
<darkxst> aeoril, no, create a branch on your launchpad page and link to the bug
<darkxst> you can then create a merge proposal
<aeoril> darkxst how would I build/test it though?
<darkxst> you just did didnt you?
<aeoril> no, not yet - apparently, I am slow ...
<aeoril> darkxst you said I would not use sbuild ... so I thought there was some other way to build/test if i made a ppa - you mentioned installing it from a ppa to test from a live session
<aeoril> earlier
<ricotz_> bdmurray, hi, please test-install your uploads ;)
<aeoril> darkxst so, now I am confused
<aeoril> darkxst I was thinking I could do the whole process using a ppa or something
<aeoril> darkxst you mentioned I could install my compiled ubiquity from a ppa - what exactly did you mean by that please?
<darkxst> aeoril, you can use a ppa to test, but not to submit your changes for review
<darkxst> aeoril, dput you package to a ppa, boot a livecd, install the ppa and update
<darkxst> then run the installer
<aeoril> darkxst ok, cool - what exactly do you mean by "install the ppa and update" please?
<darkxst> apt-add-repository ppa:
<bdmurray> ricotz_: Could you elaborate?
<ricotz_> bdmurray, try to install https://launchpad.net/ubuntu/+source/ubuntu-release-upgrader/1:15.04.8
<ricotz_> python3-distupgrade (1:15.04.8) wird eingerichtet ...
<ricotz_>   File "/usr/lib/python3/dist-packages/DistUpgrade/DistUpgradeViewKDE.py", line 37
<ricotz_>     from PyQt5.QtGui import QTextOption, QPixmap, QIcon,
<ricotz_>                                ^
<ricotz_> SyntaxError: trailing comma not allowed without surrounding parentheses
<aeoril> then just apt-get update then apt-get upgrade? darkxst
<darkxst> aeoril, yes
<aeoril> and that will add all the necessary debs from the sbuild?
<aeoril> (so it would not install -dev or -dbg?)
<darkxst> aeoril, yes
<aeoril> darkxst ok, I will do that then.  Thanks.
<aeoril> darkxst I am going to dput the ppa with the following command line:  "dput ppa:aeoril/ubiquity-bug-1422113" However, do I do it from the directory where the .dsc file is, or from the package directory where the .deb files are?
<darkxst> aeoril, dput uploads source packages
<aeoril> oh, ok - so not from the bzr repo where the .deb files are, but one directory up where the .dsc is?
<aeoril> (created by debuild?)
<darkxst> aeoril, I'm sure you can work it out
<aeoril> ok, thanks
<dobey> http://pastebin.ubuntu.com/10378082/ <- i'm getting this trying to set up a vivid lxc. anyone know the best way to resolve this? :-/
<sarnold> dobey: stgraber mentioned it to pitti perhaps two hours ago, perhaps one or the other knows a bugnumber for the ureadahead issue..
<dobey> ah ok
<dobey> i thought it was just me; i recall having this same problem forever ago when i set up a utopic lxc or with some sbuild chroot
#ubuntu-devel 2015-02-24
<aeoril> darkxst arrrggghhh!  All this time I have been working on the icon bug with plain old Ubuntu, not Ubuntu-Gnome!  Anyway, I got everything to boot and ran a compiled Ubiquity install from the live CD in a VM, but the info icon was fine *before* I included the fix in my compile for regular Ubuntu - now I have to do it all for Ubuntu-Gnome!  Teach me to read the bug report better ... I'll
<aeoril> work on it again tomorrow.  Made good progress on learning the ropes, though
<aeoril> darkxst note that I had to do "sudo apt-get -f install" to fix up the ubiquity dependencies after "dpkg -i ..." for the compiled .deb files
<aeoril> (but it seemed to work fine)
<aeoril> darkxst can I use a ubiquity build done with debuild/sbuild on an Ubuntu machine (the .debs) to test out ubiquity on an Ubuntu-Gnome livecd?  Or do I have to do the build originally on a Ubuntu-Gnome machine?
<ScottK> aeoril: You can do it on an Ubuntu machine.
<aeoril> ScottK ok, thanks - then my problem now is trivial.  What a relief! How does sbuild determine "flavours" for builds?  Or does that only matter if you are building the livecd for the "flavour?"
<ScottK> It determines if the package build dependencies in debian/control have been satisfied.
<ScottK> Ubiquity is built with different front ends sometimes for different flavors, but it's all one build from the same source.
<aeoril> ScottK speaking of dependencies, when I ran "bzr debuild" to get the source package built before I could run sbuild, it could not find some dependencies.  However, I looked in debian/control and the missing packages seemed to be there (pyflakes, pep8 and d-i, I think - something like that).  I had to manually install them before I could do the build.  I wonder why?  When I made a recipe
<aeoril> on launchpad, it failed as well because of dependency issues.
<aeoril> "bzr debuild -S" actually ...
<ScottK> debuild won't install build-deps.  You have to do that yourself.
<aeoril> ScottK I wonder why the recipe failed though?
<aeoril> (I could paste the log)
<ScottK> No idea.  I've never done anything with LP recipes.
<aeoril> well, just point you to it ...
<aeoril> oh, ok
<aeoril> ScottK do many people use recipes at all?
<ScottK> I've known of a few.
<ScottK> I think they are mainly used by upstreams trying to do things like nightly builds on LP.
<aeoril> oh, ok - do most people use sbuild?
<aeoril> darn, my VM seems to have locked up installing dependencies using "sudo apt-get -f install"
<aeoril> (for the ubiquity I compiled)
<pitti> stgraber: ah yes, that must be an ancient bug which nobody saw so far as we install it by default
<pitti> Good morning
<pitti> sarnold, stgraber, dobey: bug 777224 sounds like ^, I duped/triaged it
<ubottu> bug 777224 in ureadahead (Ubuntu) "package ureadahead 0.100.0-11 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Triaged] https://launchpad.net/bugs/777224
<pitti> stgraber: ureadahead does work on an SSD in principle, it just doesn't make much sense
<pitti> bdmurray: hm, ubuntu-release-upgrader build failure, why does it build-dep on itself?
 * pitti removes the -proposed version
<pitti> I removed all of its  binaries from -proposed
<Mirv> pitti: I rekicked khtml autopkgtest, it showed as "Test in progress" since yesterday while it was not
<pitti> *nod*
<darkxst> aeoril, the only real difference in ubiquity between Ubuntu and Ubuntu GNOME is the slideshow, the icon issue will be the same for both
<pitti> bdmurray: FYI, https://launchpad.net/ubuntu/+source/ubuntu-release-upgrader/1:15.04.9 built now, after cleaning up the previous botched binaries
<dholbach> good morning
<ari-tczew> hello dholbach
<dholbach> hi ari-tczew
<LocutusOfBorg1> hi folks!
<LocutusOfBorg1> do you have any advice for bug 1424769 ?
<ubottu> bug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [Undecided,Confirmed] https://launchpad.net/bugs/1424769
<LocutusOfBorg1> the problem is that it needs a rebuild
<mlankhorst> LocutusOfBorg1: in general vm's should use the unrenamed stack, and trusty 14.04.1
<mlankhorst> you can still use the lts-utopic kernel if you want
<LocutusOfBorg1> mlankhorst, I'm the virtualbox maintainer lol
<LocutusOfBorg1> I'm asking how to (if possible) fix the "bug"
<mlankhorst> create a virtualbox-x11-lts-utopic :P
<LocutusOfBorg1> yes, I was thinking about something like that, how to trigger the rebuild with the -lts-utopic packages?
<LocutusOfBorg1> and how can I be sure users will pick up it?
<LocutusOfBorg1> seems a big trouble
<mlankhorst> they won't pick it up, you need to create a rename for the -lts-utopic package
<mlankhorst> you need to create a separate virtualbox-lts-utopic package
<LocutusOfBorg1> and maintain it ;)
<mlankhorst> or advise users to stay on 14.04.1, they can upgrade the kernel if they want
<mlankhorst> the problem is that newer xorg may break the x11 api, so you can't just rebuild the old virtualbox against a newer xorg in some cases
<LocutusOfBorg1> I guess I need (in case of breakage) to patch the code like I do with the kernel
<LocutusOfBorg1> can I quote the irc conversation or can you please just reply there?
<mlankhorst> sure quote if you want
<ricotz> LocutusOfBorg1, hi, what is up with the vbox driver inclusion in vivid kernel?
<LocutusOfBorg1> ricotz, sorry I don't get the question
<ricotz> LocutusOfBorg1, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-vivid.git;a=commit;h=8180b966d33c0551503f6cd362d573c69d9b7d80
<LocutusOfBorg1> thanks I saw on -devel mail list something about it, apw what is that supposed to do?
<LocutusOfBorg1> to avoid the dkms package?
<ricotz> meaning how are you dealing with that? (regardless the network module is failing here)
<ricotz> tainting the kernel by default doesnt seem a good idea
<LocutusOfBorg1> nobody ping'd me about it, so I presume if they want to integrate the driver in the kernel, they will also patch vbox to stop producing the dkms package
<LocutusOfBorg1> I guess once the kernel team finished the work somebody will ping me about it
<LocutusOfBorg1> (I hope at least)
<ricotz> right, and of course slipping out the ddx as well
<ricotz> which i would assume mlankhorst heard of ;)
<ricotz> *even "splitting out"
<ricotz> LocutusOfBorg1, i see, i was hoping you are already aware of it
<LocutusOfBorg1> (un)fortunately I really try to avoid the kernel stuff, and the dkms is already making me loose so much time in rebuild and patch vbox at each kernel-lts update
<LocutusOfBorg1> I have a new breakage with kernel 4.0rc1
<ricotz> not much of a surprise ;)
<apw> LocutusOfBorg1, that is to do with vagrant images, to have a single image which works on all clouds you need those drivers without a compiler
<apw> LocutusOfBorg1, those are exactly the same as the dkms module and built literally from it
<LocutusOfBorg1> so apw should I change something on virtualbox side? I presume not
<apw> LocutusOfBorg1, no i don't think we would want anything to change with how that works no as things are
<LocutusOfBorg1> ;) wonderful! thanks
<apw> LocutusOfBorg1, things seem to be working rather well with it to be honest, and i assume that is all your hard work
<LocutusOfBorg1> s/hard/cherry-picks/ :)
<apw> :) that is the kind of work i like
<LocutusOfBorg1> I hope one day I'll be an ubuntu developer, to stop bothering people about my cherry-picks
<apw> LocutusOfBorg1, sponsors you mean?  do feel free to poke me with them
<LocutusOfBorg1> fortunately dholbach is a nice sponsor ;)
<LocutusOfBorg1> (and I started my debian NM process, so I hope to become a DD soon and start soonafter the ubuntu process)
<mlankhorst> DD can take a while :P
<tjaalton> yep..
<LocutusOfBorg1> if my AM doesn't send me the questions I presume yes ;)
<pitti> sarnold, dobey, stgraber: ureadahead -19 uploaded with the upgrade fix
<mlankhorst> took me half a year even after AM was done
<LocutusOfBorg1> ough
<LocutusOfBorg1> so you think I have any chance to start also the ubuntu one?
<Riddell> ricotz: bdmurray: looks like there were still problems from the pyflakes tidying I did in release-upgrader, I'll fix and do an upload
<apw> LocutusOfBorg1, there is no reason you can't start ubuntu in parallel imo
<LocutusOfBorg1> I guess I need some advocate, right?I guess there isn't anything for Debian Maintainers, even if in DM list
<apw> LocutusOfBorg1, normally you work with a sponsor or two for a bit, and they then recommend whne you should go for rights for yourself, mostly when you annoy them by being right all the time
<mlankhorst> what if they start uploading without checking? :P
<xnox> mlankhorst: then i will notice that.
<LocutusOfBorg1> thanks
<flexiondotorg> infinity, Are you available?
* Laney changed the topic of #ubuntu-devel to: Archive: beta 1 freeze, 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> cjwatson, Can I pick your brains for a sec?
<cjwatson> flexiondotorg: Better to just ask rather than asking to ask
<flexiondotorg> cjwatson, There are some new packages in the official Ubuntu MATE images.
<flexiondotorg> cjwatson, I'd like to try an understand how they've been pulled in.
<flexiondotorg> For example, xterm is included. 'aptitude why' tell mes it is required 'xorg'
<flexiondotorg> xorg says is can be satisfied by 'xterm | x-terminal-emulator'
<flexiondotorg> mate-terminal provides x-terminal-emulator.
<darkxst> flexiondotorg, they only work with tasks
<flexiondotorg> What only work with tasks?
<darkxst> 'xterm | x-terminal-emulator'
<flexiondotorg> So the livefs is not built using tasks?
<cjwatson> It is built using tasks
<cjwatson> germinate output is better than aptitude why for investigating this stuff
<flexiondotorg> cjwatson, I've read your comment about blacklisting.
<flexiondotorg> cjwatson, Does blakclisting actually do anything?
<cjwatson> No
<cjwatson> I mean only in very subtle ways that you should not attempt to use
<flexiondotorg> cjwatson, Can you elaborate a little?
<cjwatson> You can read germinate(1) in which I elaborated
<darkxst> flexiondotorg, you should really be fixing the deps that cause problems
<flexiondotorg> cjwatson, OK.
<darkxst> hacks, will just break again sometime
<cjwatson> They probably won't even work to start with :)
<cjwatson> Anyway let me actually investigate please
<cjwatson> So your problem here is that you're attempting to use your "core" seed to provide things that are needed by the desktop-common seed
<cjwatson> Such as mate-terminal, which is in ubuntu-mate.vivid/core, but satisfies a dependency of xorg which is in platform.vivid/desktop-common
<cjwatson> But germinate works seed by seed from the inside out
<flexiondotorg> cjwatson, Ah. So I should fold core into desktop to resolve this?
<cjwatson> No
<cjwatson> That won't make the slightest difference
<cjwatson> Can you give me a few minutes please?
<flexiondotorg> cjwatson, Sure.
<cjwatson> There's something very confusing going on here
<cjwatson> flexiondotorg: I don't know yet whether this is connected, but why does your cloudtop seed declare the exact same Task-* headers as desktop?  That isn't legitimate and can only cause confusion.
<flexiondotorg> cjwatson, I'll just take a peek...
<cjwatson> flexiondotorg: It should surely at least declare that it generates a different task name with a different key package and description.
<flexiondotorg> cjwatson, Yes, that is an error.
<flexiondotorg> cjwatson, I am more than happy to make some changes to the seeds.
<flexiondotorg> cjwatson, Or are you still looking at the Ubuntu MATE seeds?
<cjwatson> flexiondotorg: I'm still working on it, pdb on germinate is slow
<flexiondotorg> cjwatson, Thanks very much for helping.
<cjwatson> flexiondotorg: ah, here we go, I see the problem
<cjwatson> flexiondotorg: so mate-terminal is only in core indirectly, rather than being seeded explicitly: it's a dependency of mate-desktop-environment-core
<flexiondotorg> cjwatson, Ah.
<cjwatson> flexiondotorg: when germinate is processing desktop-common and encounters xorg Depends: xterm | x-terminal-emulator, it does look through "nearby" seeds to find something it can promote to satisfy that, for preference
<flexiondotorg> Understood.
<cjwatson> flexiondotorg: but it only looks through directly-seeded entries (this is sort of analogous to some similar behaviour in apt)
<cjwatson> flexiondotorg: adding an explicit entry for mate-terminal to your core seed fixes this
<flexiondotorg> cjwatson, OK.
<cjwatson> so I suggest you do that, and fix up the cloudtop seed headers
<flexiondotorg> cjwatson, What is the authoritative bzr repository for Ubuntu MATE seeds now that Ubuntu MATE is official?
<flexiondotorg> cjwatson, Do I also need to submit a new meta package for upload?
<cjwatson> flexiondotorg: hasn't changed, lp:~ubuntu-mate-dev/ubuntu-seeds/ubuntu-mate.vivid
<flexiondotorg> If I change the seeds.
<cjwatson> flexiondotorg: in general you should do that reasonably frequently, although I believe that it happens not to be necessary in this case
<flexiondotorg> cjwatson, I'll make those changes now.
<cjwatson> just changing the seeds and waiting a bit should be enough to fix the Task fields in the archive, which should be sufficient here
<flexiondotorg> cjwatson, We'd like to target PowerPC for Ubuntu MATE 15.04. My merge proposal include PowerPC. What needs to be done to enable PowerPC images?
<cjwatson> (because apt will mark all the packages with matching Task fields for installation and only then attempt to fix any broken dependencies, and by that point mate-terminal will be marked for installation so it won't consider xterm | x-terminal-emulator as broken)
<cjwatson> flexiondotorg: http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/revision/1499, done now
<flexiondotorg> cjwatson, Thanks!
<strikov> Hi guys. Should this be theoretically possible to run daily 15.04 inside virtualbox? I just pulled the latest bits from cdimage.ubuntu.com but display is broken with and without 3d acceleration enabled in vbox. Display is broken == pixels of different colors fill the screen, resolution is very low (300x200 or something). Does it make sense to try older
<strikov> images or just forget about vbox?
<flexiondotorg> cjwatson, I've pushed those seed changes.
<flexiondotorg> cjwatson, I've also noticed that some packages are being pulled in a 'recommends' even though I believe I've requested recommends should not be followed.
<cjwatson> flexiondotorg: Not following Recommends is usually a recipe for pain.  Are you sure?
<cjwatson> flexiondotorg: Some of the lightweight flavours do it, but it seems a bit odd for MATE.
<flexiondotorg> cjwatson, Well, if recommends are followed I ended up with most of Unity and GNOME3 being pulled in.
<cjwatson> And you can't fix the recommends to avoid that?
<flexiondotorg> cjwatson, Well, I could but that might break Ubuntu proper.
<cjwatson> We can make livecd-rootfs handle this if necessary (it needs more than just the seed configuration), but I'd like to make sure there's no plausible alternative.
<flexiondotorg> cjwatson, Are you saying that currently the livefs will follow recommends, regardless of my seed headers?
<cjwatson> Yes.
<flexiondotorg> cjwatson, OK. Then this is interesting.
<cjwatson> Also, "feature no-follow-recommends" in STRUCTURE doesn't actually work yet, although this is a germinate bug IMO.  It'll need " * Feature: no-follow-recommends" in at least some individual seeds too (probably core, desktop, cloudtop).  Compare lubuntu.
<flexiondotorg> cjwatson, In which case there are only a few packages being pulled in that Ubuntu MATE really doesn't need.
<flexiondotorg> cjwatson, I did follow what lubuntu did.
<cjwatson> No, you didn't.
<cjwatson> Or at least not successfully. :-)
<cjwatson> <cjwatson@amber ~/src/ubuntu/seeds/lubuntu.vivid>$ grep follow-recommends *
<cjwatson> STRUCTURE:feature no-follow-recommends
<cjwatson> core: * Feature: no-follow-recommends
<cjwatson> desktop: * Feature: no-follow-recommends
<cjwatson> <cjwatson@amber ~/src/ubuntu/seeds/ubuntu-mate.vivid>$ grep follow-recommends *
<cjwatson> STRUCTURE:feature no-follow-recommends
<cjwatson> flexiondotorg: BTW there is no need to remove packages not yet in the official archive from your seeds, if you intend them to be in the official archive in the nearish future.
<flexiondotorg> cjwatson, That is the hope but the upstream Debian team are super busy so it may not happen.
<flexiondotorg> cjwatson, I've pushed the no-follow-recommends changes.
<cjwatson> flexiondotorg: Ah, I see that livecd-rootfs in fact already has the necessary --no-install-recommends code.
<cjwatson> So this may be enough.
<flexiondotorg> cjwatson, Should I revent my change to the seeds?
<cjwatson> flexiondotorg: No, I mean that this may be enough in combination with your seed change.
<cjwatson> Don't revert it.
<aeoril> darkxst no, the icon issue does not appear to happen in Ubuntu.  Witness:  http://i.imgur.com/rI96eJP.png It does in Ubuntu-Gnome, however.  Witness: http://i.imgur.com/QTyVJ1W.png
<flexiondotorg> cjwatson, OK
<mlankhorst> I uploaded a package to debian-experimental, but it's stuck in the NEW queue there, can I sync this package to ubuntu somehow?
<mitya57> mlankhorst: unfortunately no
<mlankhorst> meh I'll just upload 0ubuntu1 for now then
<aeoril> darkxst this is the new icon for gnome info, I guess:  http://i.imgur.com/MbotQ24.png  A lightbulb?  That seems odd ...
<aeoril> darkxst looks like that is correct:  http://commons.wikimedia.org/wiki/GNOME_Desktop_icons#mediaviewer/File:Gnome-dialog-information.svg
<flexiondotorg> Laney, regarding debdiffs for GTK2 in Trusty etc. Do you want complete debdiffs which debian/changelog updated?
<Laney> flexiondotorg: that's easiest
<flexiondotorg> Laney, Thanks.
<cyphermox> flexiondotorg: did you get my message yesterday about mate-tweak missing an upstream branch for 3.4.4 ?
<flexiondotorg> cyphermox, No, I missed that.
<flexiondotorg> cyphermox, Morning BTW ð
<cyphermox> makes it a little hard to build ;)
<cyphermox> morning ;)
<flexiondotorg> cyphermox, Crap http://status.bitbucket.org/
<flexiondotorg> cyphermox, When they are back I'll make sure the build is tagged.
<cyphermox> ok
<jfmcarreira> heyyy guys
<jfmcarreira> can anyone guide me on how to build nightly package for a personal app
<jfmcarreira> i would like them to be compatible with lauchpad
<flexiondotorg> cyphermox, I see a tarball for mate-tweak 3.4.4 here - https://bitbucket.org/flexiondotorg/mate-tweak/get/3.4.4.tar.gz
<flexiondotorg> cyphermox, Upstrem releases are tagged, not branched.
<flexiondotorg> Only the 'debian/' folder is in a branch.
<cyphermox> ok, but I meant on the git branch on alioth -- you should have a upstream/3.4.4 import of the upstream git version 3.4.4
<caribou> bdmurray: Hi, any chance of having the CUPS SRU completed for trusty ? it got released to -updates only for Utopic
<caribou> bdmurray: LP: #1352809
<ubottu> Launchpad bug 1352809 in cups (Ubuntu Trusty) "/usr/bin/lp on Trusty using -h option doesn't work as expected" [Medium,Fix committed] https://launchpad.net/bugs/1352809
<stgraber> utlemming: ubuntu-cloud packageset created
<utlemming> stgraber: most appreciated :), thank you
<flexiondotorg> cyphermox, The upstream branch is 'ubuntu/15.04' and just includes the 'debian' folder.
<flexiondotorg> cyphermox, The upstream branch on alioth that is.
<cyphermox> flexiondotorg: right, you also need an upstream/3.4.4 branch if you want to release 3.4.4, otherwise we can stick to 3.4.3
<cyphermox> anyway, for releasing with git-buildpackage
<flexiondotorg> cyphermox, Only the 'debian' folder comes from git. The upstream project is a tarball.
<flexiondotorg> cyphermox, Excuse my ignorance.
<flexiondotorg> sunweaver, Can you interpret for me? ^^^^^^^
<cyphermox> there's also an import of the upstream code so that there tarball can be generated :)
<bdmurray> caribou: bug 1386241 needs verification too.
<ubottu> bug 1386241 in system-config-printer (Ubuntu Trusty) "Add the full IPP Everywhere support from Utopic to Trusty" [High,Triaged] https://launchpad.net/bugs/1386241
<bdmurray> caribou: oh, no sru-report is wrong. Okay, I'll sort it out.
<caribou> bdmurray: np
<LocutusOfBorg1> shame on you ubuntu developers!
<LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1424769/comments/10
<ubottu> Launchpad bug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [Undecided,Confirmed]
<LocutusOfBorg1> ^^^^^
<LocutusOfBorg1> :)
<plm> Hi all
<plm> This is right place for ubuntu core? Anyway, how I install vim on it?
<ogra_> plm, do you mean snappy ?
<ogra_> there is a #snappy channel
<josepht> plm: #snappy might be better
<plm> ogra_: yes.
<plm> josepht: ok
 * ejat brb
<infinity> flexiondotorg: I'm around now, but I'm guessing Colin sorted out what you were going to ask me?
<flexiondotorg> infinity, Yes Colin did help with some stuff ð
<flexiondotorg> infinity, mate-menu is in the upload queue is it possible for you to review it? It has the updated copyright.
<infinity> flexiondotorg: Yup, I'll look at it in a second.
<flexiondotorg> infinity, Many thanks.
<alexbligh1> rbasak, any chance you got anywhere with https://bugs.launchpad.net/ubuntu/trusty/+source/apache2/+bug/1366174 ?
<ubottu> Launchpad bug 1366174 in apache2 (Ubuntu Trusty) "apache2 SEGV with multiple SSL sites" [High,Triaged]
<rbasak> alexbligh1: thank you for the reminder. It's now top of my list.
<alexbligh1> rbasak, thanks :-)
<rbasak> I'm not sure it's worth starting it right now as I finish in half an hour, but I'll do it tomorrow.
<alexbligh1> rbasak, thanks once more
<xnox> elmo: if i can get ipv6 tunnel, configure it and use it to get ipv6 internets, so can you. Could you please please make http://start.ubuntu.com/ ipv6 accessible? This should unbreak ubiquity on ipv6-only networks.
<elmo> xnox: dude, are you high?
<elmo> xnox: the problem isn't me needing to get an IPv6 tunnel
<xnox> elmo: i didn't do tunnel however. I vpn in native ipv6 =)
<elmo> xnox: as should be evidenced by the fact that things like archive.ubuntu.com are IPv6 enabled already
<xnox> elmo: i'm not high, but clueless.
<xnox> elmo: the start.ubuntu.com search box default provider is google which also has ipv6 connectivity.
<elmo> xnox: well I'm just not sure why you'd choose to start a conversation with such an aggressive tone ("If even *I* can do this, surely you can too").  it's not constructive
<xnox> elmo: right, a constructive feedback would be - given that there is ipv6 on some *.ubuntu.com could you please serve http://start.ubuntu.com/connectivity-check over ipv6
<xnox> ?
<xnox> elmo: sorry about the non-constructive opening.
<elmo> xnox: so, there's several bugs an RTs about this; but I can't find a public one right now.  unfortunately adding v6 support for stuff behind our firewalls is non-trivial; ti's been on our todo list, but it's not been a huge priority
<mdeslaur> xnox: please don't get elmo mad :)
<elmo> xnox: part of that is because I'm not convinced anyone actually uses IPv6 only networks in the real world.  I mean what could you do with a v6 only internet connected machine?  go to google and look at all the sites you can't visit?
<xnox> elmo: ok. i think connectivity-check lives there out of convenience rather than necessity.
<elmo> xnox: it lives there because it's a URL we (Canonical IS) have committed to holding to a very high SLA
<xnox> elmo: how hard would be to serve the file http://start.ubuntu.com/connectivity-check somewhere else which has ipv6 & ipv4?
<xnox> elmo: hm, right.
<xnox> elmo: i also believe there are very little ipv6 only machines, but there are some that are ipv6 only at install time, as there are bug reports that did tickle down to ubiquity about that.
<elmo> xnox: well
<elmo> xnox: the thing is I would argue that ubiquity is doing the right thing
<xnox> elmo: and it didn't look like "i am a hipster who finished growing beards and testing ipv6-only environment for giggles"
<elmo> if the check is "Do you have access to the general internet?" and your connectivity is v6 only, I would say "no" is the correct response
<sarnold> but ipv6 is sufficient to get ubuntu updates, right?
<xnox> elmo: in practice we use it to do $ apt-get update; download language packs; download updates; possibly live ugprade installer
<elmo> sarnold: only if you have a v4 to v6 DNS translation; our nameservers also don't do v6
<sarnold> elmo: ahhh
<elmo> this is what I mean
<xnox> elmo: thus accessing archive.ubuntu.com only.
<elmo> the whole 'v6 only' thing strikes me as house of cards built on a bed of lies
<elmo> you're already not true v6 only if you can resolve start.ubuntu.com
<xnox> elmo: at the moment failure to resolve start.ubuntu.com -> prevents in ubiquity to access archive.ubuntu.com on ipv6-only.
<elmo> xnox: well, hang on
<xnox> elmo: and archive.ubuntu.com has ipv6 resolution.
<elmo> xnox: which is it?
<elmo> xnox: no, dude, it doesn't
<elmo> xnox: you're confusing different things
<elmo> xnox: archive.ubuntu.com has quad-A records
<elmo> xnox: but ns{1,2,3}.c.c don't
<infinity> archive.ubuntu... What he said.
<elmo> xnox: so in a true v6 only environment you can't even *resolve* archive.u.c's AAAA
<infinity> So, arguably, one shouldn't make connectivity-check available over v6 until after the nameservers also are, or it's a bit of a lie for our use-case.
<xnox> elmo: i see - $ host archive.ubuntu.com -> shows ipv6 address; $ host -6 archive.ubuntu.com does not
<maswan> elmo: you might have a dual stacked resolver on a v6-only host though
<xnox> elmo: are 2001:67c:1360:8c01::18 2001:67c:1360:8c01::19 some kind of special v4->v6 things?
<xnox> elmo: i'm seriously considering to change ubiquity connectivity check to curl http://archive.ubuntu.com/ubuntu/dists/$release/Release.gpg and check that it starts with -----BEGIN PGP SIGNATURE-----
<elmo> maswan: sure and I think most people do.  but again, my overarching point is that I believe a true 'v6 only' environment is a magical unicorn.  it's a nice idea, but they're not useful in practice and I'm not even sure they exist
<xnox> elmo: because all i need is downloadable archive.ubuntu.com rather than working start.ubuntu.com
<elmo> maswan: because you inevitably add compromises like "oh, we're v6 but, we need v4 to actually resolve stuff"
 * maswan has a few non-production servers on v6 only, v4 space getting constricted in a few places. but can put in a proxy and reslover and stuff in place when needed. real servers are dual-stacked.
<maswan> elmo: yeah
<xnox> maswan: yeah, i haven't seen things ipv6-native and _without_ NAT64 gateway -> thus start.ubuntu.com would work for those.
<elmo> xnox: well, you can do what you like to ubiquity, but personally I think it's a bit silly.  the connectivity-check thing is well established and adding load of all ubiquity users to archive.u.c for this tiny handful of v6 only people because you're not patient enough to wait for a proper fix, is, IMO a bad trade off
<xnox> elmo: i just think that start.ubuntu.com will never bubble up the priority to get ipv6 connectivity. =(
<maswan> xnox: yeah, at least for proper end users. If I bring up a few v6-only VMs, I should be clueful enough to know which archive mirror to point them to, etc.
<infinity> It's also mostly a non-bug, since ubiquity works Just Fine offline.
<infinity> And then you reboot, and if you can see archive.ubuntu.com, you can update.  No big deal.
<elmo> xnox: well, I don't know what you want me to say.  it almost sounds like you're threatening to make a bad decision unless I somehow commit to fixing your issue in a specific time.  if that's what's happening, I'm afraid I'm not going to play that game
<xnox> elmo: i don't think causing mischief will get things moving either.
<elmo> xnox: I mean do you have *any* way to quantify this?
<elmo> because my gut feeling is that this is a tiny fraction of our userbase
<elmo> and if that's true, I don't think it not being a priority to fix is actually the wrong call
<xnox> elmo: well, i want to say - i could log a recoverable ubiquity bug report, and whoopsie would upload it post install..... but daily.ubuntu.com is ipv4 only as well.
<xnox> elmo: i think daisy.ubuntu.com is actually a bigger one - we get no info from ipv6 users.
<xnox> ev: ^
<xnox> elmo: i concur. if it becomes a priority, and start.ubuntu.com gets enabled all releases will retroactively work.
<smoser> pitti, are you still around ?
<aeoril> darkxst I have fixed the bug, and am preparing to do a merge proposal.  I get the following lintian error as I check the build one last time:  "E: ubiquity changes: bad-distribution-in-changes-file vivid" - here is I believe the line it does not like I added:  "ubiquity (2.21.13) vivid; urgency=medium" - I assume I can ignore this error because vivid is a valid, but new, distribution?
<aeoril> Here are the full lintian errors and warnings - should I worry about any of them?  http://paste.ubuntu.com/10395889/
<aeoril> darkxst that line is in debian/changelog ...
<darkxst> aeoril, maybe because you are building source on trusty
<darkxst> other warnings are harmless
<aeoril> darkxst should I build on vivid to make sure?
<aeoril> or just submit
<darkxst> its probably ok
<darkxst> aeoril, and the ubuntu icon theme still has legacy icons I suppose,
<aeoril> darkxst well, I have not tested that - I could always check ... it did before the fix ...
<aeoril> I assume therefore it will now ...
<darkxst> aeoril, just check that all icon names you are replacing are symlinks to your new names (in Ubuntu icon theme)
<aeoril> in /usr/share/icons? darkxst
<darkxst> aeoril, ^icons/Humanity
<jdstrand> sarnold: thanks for the review! fyi, the loop you mentioned is actually basically the same as before, except now it is now under the 'for ext in ["additional", "override"]:' loop
<aeoril> darkxst all the Ubuntu icons for dialog-information.svg point to legacy icons (gtk-info.svg).  I changed from gtk-dialog-info.svg to dialog-information.svg.  However, all the icons for dialog-warning.svg appear to be correct, which I changed from gtk-dialog-warning.svg
<jdstrand> sarnold: but yes, I had to look at the 'for i in tmp_json' bit too. the idea is it will skip individual keys but still try ok ones
<aeoril> darkxst I guess nothing breaks, then, just that the Ubuntu icons remain legacy ...
<jdstrand> sarnold: really, I could just drop the 'invalid entry' bit, but I wanted to be helpful. Ill give the issubset() some thought
<aeoril> darkxst all of the original referenced icons (gtk-dialog-info.svg) point to dialog-information.svg except two, which specifically point to gtk-info.svg, so really I think for Ubuntu my changes have no impact, all the info icons will remain legacy ... from what I can tell
<aeoril> darkxst I am getting nervous!  I have commitment issues!
<aeoril> lol
<darkxst> aeoril, ok create a bzr branch with your changes and link to the bug
<darkxst>  aeoril humanity does use icon-naming-utils, so should be fine
<sarnold> jdstrand: yeah, it's not exactly -new- code, but it does take some time to think it through, and that often leads to problems ;)
<jfmcarreira> heyy guys
<jfmcarreira> is it possible to make bzr branch lp:playuver for example in a branch that was imported from git?
<aeoril> darkxst should I follow these instructions?  http://packaging.ubuntu.com/html/fixing-a-bug.html#committing-the-fix
<aeoril> (just want to make sure because of my fear of committment)
<darkxst> aeoril, yes
<aeoril> darkxst ok, cool - will do.  Thanks.
#ubuntu-devel 2015-02-25
<nagromlt> ne1 on?
<aeoril> darkxst I believe I have successfully created the merge proposal, and it is awaiting review.  Thank you.  Next bug suggestion?
<aeoril> darkxst oh crap - I put "Mon, 24 Feb ..." in the changelog - that should be "Tue, 24 Feb ..." - how do I fix the merge proposal?  Just fix it and do another one?  Or can I back it out somehow?
<darkxst> aeoril, just fix it and push the extra commit, btw you should use 'dch -i' normally so you don't need to worry about date etc...
<aeoril> darkxst yes, I saw that but only after I had made the changes - will do next time (dch -i)
<darkxst> but you completely stuffed that branch by the looks of it
<aeoril> darkxst what do you mean by "completely stuffed"?
<darkxst> 573 files modified
<darkxst> I supposed you push a branch that you had run debuild from within?
<aeoril> hmmmm .... I must have made a mistake then ... yes, i did
<aeoril> debuild in it - when I did bzr status, it only showed my two files changed ... what happened?
<darkxst> aeoril, start with a clean branch, apply your icon changes (no debian changelog is actually required for ubiquity, or most ubuntu upstream branches)
<aeoril> oh, I know - debcommit added the files before the commit - I did not want to do that - how do I clean it up before recommitting?
<aeoril> ok, what is the best way to clean the branch?  debclean?
<aeoril> darkxst ^
<darkxst> (and in that case, I guess debcommit won't work without a changelog, so you would just use bzr commit)
<darkxst> aeoril, best to start with a clean branch, debclean might work, but is often unreliable
<aeoril> darkxst bzr commit --fixed ... ???
<darkxst> yes that would do
<darkxst> and once it fixed, bzr push --force-overwrite
<aeoril> ok, will do - what is the best way to clean the branch?  In the past, I have just been deleting all the files/folders except .bzr and .bzrignore then "bzr revert" - is that as good a way as any?
<aeoril> darkxst ^
<darkxst> aeoril, really the best way is to start with a clean branch
<darkxst> make a debdiff of your changes from dirty branch, and apply it to the clean branch
<aeoril> not sure how to do either of those things, but I can look on the web
<aeoril> (new to bzr)
<darkxst> if there is extra stuff in the debdiff just delete it from the debdiff
<darkxst> you make it with debdiff and apply it with patch
<aeoril> darkxst when you say "start with a clean branch" what commands are you talking about in bzr?  I am having trouble finding out how to do that on the web
<sarnold> bzr branch lp:... new-directory-name
<sarnold> I think :)
<aeoril> sarnold oh, so he is talking about creating a brand new directory and pulling fresh from lp? darkxst?
<sarnold> aeoril: that's how I'd do it. there might be something easier but unless it's gigabytes that's pretty quick..
<aeoril> darkxst debdiff wants the .dsc from the last version - not sure how to get that
<aeoril> oh well, I'll just do my best
<aeoril> sarnold darkxst so, just to make sure before I push to lp, I am going to push the clean branch with my fixes applied with: "bzr push --force-overwrite lp:~aeoril/ubuntu/vivid/ubiquity/fix-for-1422113" then go to launchpad and submit for merge?
<aeoril> I have already downloaded the clean branch from launchpad and applied my fixes ...
<darkxst> aeoril, yes
<aeoril> darkxst I deleted the merge proposal.  Can you look here to see if this is good enough to merge?  Unfortunately, the commit message is lame, but I could redo that before submitting it for a merge proposal.  Also, I noticed other people are tagging their branches, so do i need to do that as well?  See here: http://bazaar.launchpad.net/~aeoril/ubuntu/vivid/ubiquity/fix-for-1422113/changes
<aeoril> darkxst once I get it good enough to merge, I will resubmit the merge proposal again
<aeoril> darkxst fyi it was not "--force-overwrite", just "--overwrite" ...
<aeoril> darkxst ok, I think it is fine now.  If you do not mind looking it over, I would appreciate it before I propose it for merge:  http://bazaar.launchpad.net/~aeoril/ubuntu/vivid/ubiquity/fix-for-1422113/changes
<darkxst> aeoril, looks fine
<darkxst> tags are normally used when making releases, no point for you to do that
<aeoril> ok, thanks - I'll submit for merge.  I really appreciate all the help! :)
<darkxst> commit message could mention the reason for patch though ".... to fix missing icons on Ubuntu GNOME" or something
<aeoril> darkxst I submitted for merge, but for some reason the merge proposal included all the crap previously in the branch - wat?
<aeoril> darkxst so, I deleted it again
<darkxst> aeoril, it may have just shown you the old diff (they are not generated instantly I think)? that branch is certainly fine
<aeoril> darkxst hmmm ... it took a while and said "generating diff" - then it showed it after about ten minutes, but it was the old diff
<darkxst> no idea then
<aeoril> darkxst anyway, I'll worry about it tomorrow.  Thanks again
<pitti> Good morning
<pitti> smoser: I am now
<dholbach> good morning
<seb128> hey dho
<seb128> l
<seb128> grrr
<seb128> hey dholbach :-)
<dholbach> hey s
<dholbach> eb
<dholbach> 128
<dholbach> 8
<dholbach> 8
<seb128> dholbach, :-)
<pitti> Laney: can you please add a force-badtest for linux 3.16.0-23.31? that added some new tests, and one needs fixing
<pitti> apw ^ FYI
<pitti> Laney: if you would rather want to hold back that new kernel, I'm also happy to override it on my side, to let initramfs-tools through
<Laney> pitti: I could, there's beta freeze on though so it won't make a difference today
<pitti> Laney: ah, ok
<Laney> pitti: is someone looking at the linux test, OOI?
<pitti> Laney: still, not sure when the test will be fixed, but I doubt it's by Friday, so the override would still be appreciated
<pitti> Laney: AFAIUI yes, the kernel team knows about this problem
<Laney> *nod*
<ev> xnox: ipv6? Is that still a thing?
<flexiondotorg> Morning
<xnox> ev: i guess you use this thing http://tnx.nl/legacy-ip-only.svg
<ev> ha!
<flexiondotorg> cjwatson, Can you just clrify the role of seeds and meta-packages (derived from seeds) in building the livefs and installing Ubuntu?
<flexiondotorg> cjwatson, My understanding is that seeds are used to determine what goes into the livefs? But I am unclear what the meta packages are for.
<ev> xnox: yeah, ubuntu and osx got full of hipsters, so I've gone back to this http://www.groupe-arcole.net/img/bagueAs400.jpg
<mitya57> ev: that is a very cool dark Gtk+ theme, and I also like the auto-hidden desktop panels :-)
<ev> hahaha
<Laney> flashbacks to a job I had back in school
<aeoril> Does anyone know why the diff for this merge proposal is so huge when I have only made minor changes to one file? https://code.launchpad.net/~aeoril/ubuntu/vivid/ubiquity/fix-for-1422113/+merge/250894
<mlankhorst> pitti: hm I've noticed that mesa + gmsh has a pass now in update-excuses, instead of FAILED..
<mlankhorst> though it's still failing on i386 obviously
<pitti> mlankhorst: yes, I overrode it some 30 mins ago
<mlankhorst> ah
<cjwatson> flexiondotorg: it varies a bit, but normally metapackages are less important for actually building the livefs, but they're important to end up on the installed system because it gives people an indication of what they shouldn't remove because it's part of their baseline desktop environment; also it's useful for people who already have an installed system to be able to "apt-get install ubuntu-mate-core ubuntu-mate-desktop" and get ...
<cjwatson> ... something reasonable
<flexiondotorg> cjwatson, Thanks.
<flexiondotorg> So, if I am purely concerned with building the livefs the seeds are king. The meta packages if slightly different from the seeds is not super critical. Does that sounds fair.
<cjwatson> flexiondotorg: seeds aren't used as you describe *directly*, but they're used in the process of generating tasks (basically corresponding to dependency-expanded seed output) which are used directly
<flexiondotorg> cjwatson, Understood.
<flexiondotorg> Great. Thanks.
<cjwatson> flexiondotorg: more or less, but note that the metapackages are themselves part of the task, so if you allow them to drift too much you will have problems
<cjwatson> oh, except they're not part of the task yet.  they should be, that's a bug in your seeds
<cjwatson> how about I fix that :)
<cjwatson> flexiondotorg: BTW you probably shouldn't have an ubuntu-mate-live metapackage.  We don't use the metapackage there
<aeoril> darkxst well, everything seems in place now and the merge proposal is ready for review.  I had to got to #ubuntu-motu to get help.  Also, there is a #ubuntu-installer channel.  I had to upload to lp:ubiquity, not lp:ubuntu/ubiquity.  That was the entire problem from the beginning.
<aeoril> s/upload/do the merge proposal to/
<darkxst> aeoril, didnt I tell you already that the branch was lp:ubiquity
<aeoril> darkxst yes, that is where I pulled the branch from.  But the merge proposal gui automatically filled in lp:/ubuntu/ubiquity because I used the package style branch naming when I pushed to lp.  So, I just took the default, and it was wrong.  Laney on #ubuntu-motu pointed out what I did wrong immediately
<aeoril> (used package style branch name but this is upstream)
<darkxst> aeoril, ok, good you got it solved
<flexiondotorg> cjwatson, I don't intend on letting them drift. Although the seeds and meta packages for Ubuntu MATE are ever so slightly different.
<cjwatson> Why?
<flexiondotorg> cjwatson, I'll remove the ubuntu-mate-live meta package. That is a hangover from my unofficial builds.
<aeoril> darkxst if you are curious:  https://code.launchpad.net/~aeoril/ubuntu/vivid/ubiquity/fix-for-1422113/+merge/250896
<MSHELL> mint is awsome
<cjwatson> Right, thought so.
<flexiondotorg> cjwatson, Beta 1 freeze I guess.
<cjwatson> flexiondotorg: Oh, so just lagging a bit rather than an ongoing difference?
<flexiondotorg> cjwatson, Indeed.
<cjwatson> I should add MATE to tasksel.
<flexiondotorg> cjwatson, Yes, please.
<darkxst> aeoril, no almost bed time here
<aeoril> darkxst well, thank you so much for helping me do my first fix!  I am very excited!  I hope it is acceptable and makes it into Ubuntu
<aeoril> !
<aeoril> darkxst I cannot tell you how much I appreciate all your help!
<darkxst> aeoril, it will, night
<aeoril> night, darkxst!
<cjwatson> flexiondotorg: done, will filter its way in in time.  https://launchpad.net/ubuntu/+source/tasksel/2.88ubuntu17
<flexiondotorg> cjwatson, Thanks.
<flexiondotorg> cjwatson, What triggers germinate to regenerate this? -> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-mate.vivid/
<cjwatson> flexiondotorg: A cron job.  It's purely for debugging - that output isn't used by anything automatic.
<flexiondotorg> cjwatson, Ah. OK. So it is a development aide.
<flexiondotorg> cjwatson, Are the seeds regerminated when a build runs?
<cjwatson> flexiondotorg: Right, it's mainly because generating the reverse-dependency analysis takes a while and it's useful to have it to hand.
<cjwatson> flexiondotorg: Yes.
<cjwatson> flexiondotorg: Also (more relevantly for live filesystems) at the end of every archive publisher run.
<flexiondotorg> So, if I've pushed a seed change and rebuild. The resulting iso will incorporate those changes?
<cjwatson> flexiondotorg: You need to wait for a couple of publisher runs, but it's usually fairly quick.
<flexiondotorg> cjwatson, OK. What roughtly is the publisher interval?
<cjwatson> flexiondotorg: Basically wait until the Task fields in the published Packages files have synced up.
<cjwatson> flexiondotorg: Roughly, a few times an hour.
<flexiondotorg> cjwatson, Thanks.
<cjwatson> flexiondotorg: But it depends on load.
<cjwatson> There's a slight hysteresis here: we run germinate at the end of each publisher run, and then incorporate its output into the results of the *next* run, provided that the suite in question has been marked dirty by something else - upload or override change.  But it's tricky to eliminate that without serious performance problems.
<cjwatson> If you really need something quickly then #ubuntu-release can normally help you navigate the stormy waters. :-)
<flexiondotorg> cjwatson, I will respin Ubuntu MATE beta 1 later today. I am happy to wait.
<flexiondotorg> cjwatson, The no-install-recommends feature works a treat.
<flexiondotorg> cjwatson, So I am exploiting it for the time being.
<flexiondotorg> cjwatson, But I reviewed the packages last night.
<flexiondotorg> cjwatson, There are half a dozen I will add MATE support to and update the Recommends in debian/control, so longer term I won't require no-install-recommends.
<flexiondotorg> cjwatson, Thanks for explain how all this stuff is interconnected. Really appreciate it.
<cjwatson> Sure.  Mostly this stuff just churns away in the background, but setting up a new flavour is one of the times it needs to be poked.
<flexiondotorg> cjwatson, You enabled powerpc for Ubuntu MATE yesterday. Will this show up the in QA tracker or do I need to get a QA admin to do something?
<cjwatson> flexiondotorg: Hm, I don't understand why the last build didn't produce a powerpc image, which is the first thing to investigate.  I'll have a look.
<cjwatson> flexiondotorg: It may need a member of ubuntu-release to go and create an "Ubuntu Mate Desktop powerpc" entry on iso.qa.
<cjwatson> Can't quite remember.  But that's after getting the build to happen at all.
<cjwatson> Oh, in fact, I bet that this build was triggered from the tracker ...
<cjwatson> Laney: ^- could you add "Ubuntu Mate Desktop powerpc" to iso.qa?
<cjwatson> I forgot about the tracker often being the thing that drives this nowadays.
<Laney> cjwatson: OK. You adding it to qa-products?
<Laney> Huh. Someone else just added "Ubuntu MATE powerpc"
<cjwatson> Laney: oh yeah, can do
<cjwatson> Laney: rename, I guess?
<cjwatson> flexiondotorg: ^- was that you?
<flexiondotorg> Not me.
<Laney> I'd already added it so I had to disable one of them
<cjwatson> Laney: qa-products done
<Laney> Ta
<Laney> Think it's easiest to do the first build manually
<cjwatson> shall I kick that off then?
<Laney> Go for it
<cjwatson> flexiondotorg: are you OK with me running an Ubuntu MATE build now, even if you might need another later?
<flexiondotorg> cjwatson, Sure.
<cjwatson> flexiondotorg: OK, that's running.  Should hopefully produce powerpc.
<flexiondotorg> cjwatson, Thanks.
<rbasak> Is reverse-depends looking at vivid as opposed to vivid-proposed?
<rbasak> I was expecting the latter but am a bit confused by its results (eg. wrt. src:mysql-5.5 and src:mysql-5.6)
<xnox> rbasak: i thought Laney made it look at both at one point.
<xnox> rbasak: however reverse-depends uses server side cache, thus can be stale.
<rbasak> The data I'm expecting is at least a week old.
<rbasak> But the results would be different between vivid and vivid-proposed, so maybe it's just resolving the differences differently.
<xnox> rbasak: you can commit a tracker to http://people.canonical.com/~ubuntu-archive/transitions/ which will be up to date.
<xnox> runs every hour or so.
<xnox> rbasak: i have access to the branch to commit trackers there, and I think so does Laney
<rbasak> xnox: thanks. But I think I'm done with the MySQL work now anyway. I was just checking up on Galera.
<rbasak> It's not really a full transition because the soname/sovers are the same.
<rbasak> (no ABI bump)
<xnox> rbasak: locally you can use apt-rdepends with "-r" to do reverse
<xnox> (apt-rdepends -> is recurrsive, -r makes it reverse)
<rbasak> Thanks - I didn't know about apt-rdepends somehow
<smoser> pitti, i was going to ask about ubuntu-meta and systemd. i had thought that that change had landed and somehow the cloud images didn't get it, but now (i think) i realized that it just hadnt landed.
<smoser> are you planning that change soon ?
<smoser> and can you confirm for me that you'd expedt cloud images to get it ?
<pitti> smoser: so far it's blocked on fixing NFS, which slangasek has meant to do for a while
<pitti> slangasek: ^ is that still on your list?
<smoser> oh my.
<pitti> smoser: https://launchpad.net/~pitti/+archive/ubuntu/systemd/+packages has an ubuntu-meta with flipped init
<pitti> smoser: that was mostly for my upgrade tests
<smoser> right. i saw that.
<smoser> link to "fixing nfs" bug ?
<pitti> smoser: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1312976
<ubottu> Launchpad bug 1312976 in nfs-utils (Ubuntu) "nfs-utils needs systemd unit or init.d script" [High,Triaged]
<smoser> thanks.
<pitti> smoser: OOI, why do you ask? testing/fixing cloud-init for systemd?
<smoser> well, cloud-init does have systemd jobs, and those run in snappy
<smoser> so it does work to some extent. i'm guessing there are issues, but seems functional.
<smoser> i was just kind of trackign overall "systemd by default".
<pitti> smoser: https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration has the remaining work
<smoser> someone told me it was turned on byd efauult
<smoser> right.
<smoser> thanks
<pitti> smoser: it's basically NFS (the above) and updating juju and maas, but we could work around the latter two
<didrocks> pitti: btw, not sure if you noticed, by I updated all flavors plymouth themes to support the fsck messages (I linked the bug to the blueprint)
<fabbione> imcleod: tsk....
<fabbione> pitti: hey man
<imcleod> fabbione: :-)
<fabbione> roaksoax: ping
<fabbione> imcleod: busted :P
<pitti> didrocks: yeah, I just saw, thanks!
<imcleod> fabbione: Ecumenical dialogue....
<didrocks> yw ;)
<pitti> hey fabbione, long time no see! come stai?
<fabbione> pitti: not too bad and you?
<pitti> fabbione: quite well, thanks
<fabbione> pitti: do you have any clue of who is in charge of the HA stack in ubuntu?
<fabbione> pitti: i recall ante k and roaksoax at some point.. maybe it's change
<fabbione> d
<pitti> fabbione: I don't know for sure, I'm afraid; but server team sounds right, i. e. roaksoax should at least know who
<fabbione> pitti: ack thanks
<jamespage> fabbione, what do you need to know re HA stack?
<caribou> bdmurray: just got pinged regarding an icrease in CUPS errors since my upload but there's ony one report & I'm not entitled to look at it
<caribou> bdmurray: should I be worried about that ?
<fabbione> jamespage: i don't really need to know.. i am curious when you guys will pull in latest versions of corosync/pacemaker. the onces you are shipping are "old"
<lamont> should I be concerned that when I boot the livecd on my nVidia GeForce 80400 GS that the video is completely trashed?
<lamont> or do we just hate that nvidia card?
<fabbione> lamont: i thought you were more of a serial console guy ;)
<lamont> fabbione: :p
<jamespage> fabbione, well they are in released versions of Ubuntu - don't expect new versions there
<lamont> fabbione: my real issue is trying to debug why I seem to have completely lost my window decorrations and top-bar
<jamespage> fabbione,vivid should be relatively up-to-date - I think I pushed updates to at least one point release off the latests releases from upstream for pacemaker/corosync
<fabbione> jamespage: what version is in vivid?
<jamespage> corosync 2.3.4 pacemaker 1.1.11
<fabbione> corosync is fine, pacemkaer is "old"
<fabbione> 1.1.12 is out
<fabbione> soon 1.1.13
<jamespage> well I said within a point release of latest :-)
<tinoco> jamespage: 1.1.12 would be a good goal
<tinoco> i've been asking debian-ha to update for a long time
<jamespage> tinoco, I don't doubt that - how active is debian-ha?
<roaksoax> fabbione: pong
<tinoco> jamespage: almost dead i would say
<tinoco> jamespage: i've cherry-picked several fixes for pacemaker/corosync
<tinoco> and asked them long time to go to 1.1.12
<tinoco> i think we went to 1.1.11 if im not mistaken
<tinoco> but still.. for the next LST 1.1.12 would be awesome
<fabbione> roaksoax: all sorted.. you are too slow ;)
<roaksoax> haha :)
<fabbione> tinoco: 1.1.13 is going out soon'ish
<tinoco> fabbione: yep. in between 1.1.x and 1.1.12 i've seen several fixes
<tinoco> regarding to lrmd and stonithd segfaults and this
<fabbione> tinoco: yes i know
<tinoco> anyway, going up will be good and fix the "HA" stale
<tinoco> we are having at the moment
<slangasek> pitti: it is still on my list, but if someone were to take it off my list that might not be a horrible thing
<pitti> slangasek: ah, last time you seemed to want to do it yourself, and also reorg it a bit in Debian; I can try and have a look at it later
<pitti> slangasek: but aside from that, switching the default after beta might get a bit late? do you still aim for 15.04, or should we postpone to 15.10 at this point?
<slangasek> pitti: that's true, but at this point we need to just get it done and not block on me as maintainer
<pitti> or we switch it late, and switch back if it causes too many problems?
<slangasek> pitti: I think it should still be switched for 15.04
<pitti> xnox: ah, so I was chasing apport's code for a while, and then discovered another py3-lp issue :-( filed as bug 1425575
<ubottu> bug 1425575 in python-launchpadlib (Ubuntu) "[py3] corrupts binary bug attachments" [Undecided,New] https://launchpad.net/bugs/1425575
<xnox> pitti: hm, i was testing those and i believe binary attachments should come out bit identical....
<xnox> pitti: i'll look into it.
<pitti> xnox: curiously, b'\x80\xFF' * 250 (or any lower value) works fine
<pitti> xnox: but 300 or longer starts failing
<pitti> xnox: indeed some work, but the attached reproducer has one that fails
<xnox> pitti: HTTP ERROR 418
<pitti> ?
<xnox> pitti: that's my response to "values below 300 work, higher no" =) saving explicit language.
<xnox> pitti: http://tools.ietf.org/html/rfc7168#section-2.3.3 418 -> I'm a teapot =)
<pitti> xnox: ah, haha!
<pitti> xnox: on the bright side, if I fake report['CoreDump'] to something simple, I get some test passes now \o/
<pitti> and I have some failures which I need to fix on teh apport side
<bdmurray> pitti: I've a couple of apport merge proposals for you...
<dkessel> ChrisTownsend: you can reach me here if you need any further info for bug 1425494. i just attached the log file
<ubottu> bug 1425494 in unity8-lxc (Ubuntu) "unity8-lxc session fails to start, returns to non-reacting lightdm greeter" [Undecided,Incomplete] https://launchpad.net/bugs/1425494
<ChrisTownsend> dkessel: Sure thing and thanks!  I'm looking at it now.
<pitti> bdmurray: yeah, I saw one, and another one from Chad; crawling through my backlog, I'll get to it ASAP
<pitti> xnox: bug 1425609 too, but that one is trivial at lest
<ubottu> bug 1425609 in lazr.restfulclient (Ubuntu) "urllib.urlencode() does not exist for python3" [Undecided,New] https://launchpad.net/bugs/1425609
<pitti> least
<xnox> pitti: do assign all of them to me.
<pitti> xnox: done; many thanks for keeping up with them!
<xnox> pitti: if we ever finish this one, making openstack ported to python3 will be my next goal. i'll leave porting lp itself to py3 to wgrant/cjwatson.
<xnox> =)
<pitti> xnox: down to 2 failures and 2 errors, good progress! (with the last bug fixed locally)
<cjwatson> xnox: one of these days
<xnox> cjwatson: probably after implementing RFC 2324 =))))
<alexbligh1> what is the proper way to handle config.sub and config.guess within an package that uses autoconf? If I delete them, it won't build. If I leave them there, it modifies them. This is with cdbs.
<alexbligh1> & I have include /usr/share/cdbs/1/class/autotools.mk obviously
<infinity> alexbligh1: Assuming the package also uses automake, and assuming it autoreconfs cleanly, you just want https://wiki.debian.org/Autoreconf#CDBS-using_packages
<alexbligh1> infinity, I have that, plus "include /usr/share/cdbs/1/rules/autoreconf.mk"
<infinity> alexbligh1: If one or both of those isn't true, you might want to do something more like dh_autotools-dev_updateconfig/dh_autotools-dev_restoreconfig on build/clean
<alexbligh1> infinity, the issue is 'what do I put in git'? It appears to need the file in git in order to build, but then modifies it :-/
<alexbligh1> infinity, or do I just let it modify it, and put the modified version in git?
<dkessel> ChrisTownsend: btw, the unity8-lxc package from the PPA is not selected by default when using the PPA in vivid, because of the versioning scheme used. It would make it easier to test changes the numbering would be changed
<alexbligh1> infinity, this is https://github.com/abligh/ocfs2-tools/tree/ubuntu-trusty-1.8.4 if that's interesting.
<infinity> alexbligh1: If you're using one of the autotools helpers correctly, it should be backing up the files and restoring them on clean.
<infinity> alexbligh1: If you're not running "fakeroot debian/rules clean" before you commit to git, you'd definitely have cruft.
<alexbligh1> infinity, ahhh, that may well be it, thanks.
<alexbligh1> infinity, that works - thx
<pitti> xnox: awesome, I'm down to two failures now; it seems I now filed all remaining issues as bugs
<rbasak> alexbligh1: so I've been looking at bug 1366174 in depth today. Looks good so far - I've been trying to poke holes in your backported patch but can't find any :)
<ubottu> bug 1366174 in apache2 (Ubuntu Trusty) "apache2 SEGV with multiple SSL sites" [High,Triaged] https://launchpad.net/bugs/1366174
<alexbligh1> rbasak, great :-)
<rbasak> alexbligh1: next I'm going to compare against upstream.
<alexbligh1> rbasak, thanks
<rbasak> alexbligh1: for testing, it seems to me that there are three cases.
<rbasak> Certificate with no OCSP support served OK?
<rbasak> Certificate with OCSP support served OK in the normal case.
<rbasak> And revoked certificate with OCSP support causing client failure.
<rbasak> The third might not matter from the server perspective maybe.
<alexbligh1> rbasak, and of course 'lots of SSL sites don't crash'
<rbasak> alexbligh1: of course :)
<rbasak> alexbligh1: do you have thoughts on the first two? Should we be verifying both of those cases from trusty-proposed?
<alexbligh1> rbasak, I tested (1), and yes we should test that
<alexbligh1> rbasak, one of the apache devs tested (2) as I felt I didn't know sufficient about OSCP to test it :-)
<rbasak> alexbligh1: thanks. I just wanted to check that my thoughts were sane. You know much more about this area than I do.
<alexbligh1> rbasak, yes I think so.
<rbasak> alexbligh1: I'm impressed by your patch, BTW. Deep knowledge of APR and OpenSSL's interfaces is not common. OpenSSL's API in particular.
<alexbligh1> rbasak, OpenSSL cert handling scariness learnt on the job :-) But I wrote a non-blocking SSL handler which steeled me to the weirdness of openssl.
<rbasak> I've written code against the DTLS API before. I understand the OpenSSL pain :)
<ChrisTownsend> dkessel: Hey, yeah, I changed the version on an upload today:)
<ChrisTownsend> dkessel: btw, do you have some special /home setup on your machine.  The log is claiming that it doesn't exist when trying to bind mount it, which is strange.
<dkessel> I have /home on a separate partition from /. Nothing that special I believe, ChrisTownsend
<ChrisTownsend> dkessel: Hmm, ok.  I'll think about why a separate partition would affect this.
<Noskcaj> stgraber, Anything i could be doing to get a +1?
<Suudy> So, the latest Ubuntu ABI change for 14.04 moves from 3.13.0-45 to 3.13.0-46.  Unfortunately, this change breaks my MVFS driver (for Clearcase).  It looks like they have the 3.19 version of dcache.h sucked into a 3.13.0 kernel.  Is there a way to detect this sub version (e.g. -46)?
<dobey> Suudy: is it an ABI issue and not an API issue? is the driver closed source and not rebuildable?
<infinity> Suudy: You might want to ask that in #ubuntu-kernel
<dobey> also that
<Suudy> No, I have the source.
<Suudy> Ah!  Thanks for the pointer to #ubuntu-kernel
<bdmurray> tumbleweed: Could the ubuntu sponsorship miner be sorted by date?
<bdmurray> tumbleweed: Ah, I see you can sort it but could the default be date?
<flexiondotorg> I've got some merge proposal for indicator-sound and indicator-power.
<flexiondotorg> What is the correct repo to merge with? Because if I use lp:indicator-sound and lp:indicator-power (where I branch from) the MP generate a bazzilion changes.
#ubuntu-devel 2015-02-26
<tumbleweed> bdmurray: sure, that's probably simple enough
<pitti> Good morning
<doko> pitti, test mess ...
<pitti> doko: yup, on it
<doko> thanks
<pitti> doko: we have a few actual regressions (linux, click, etc.); I'll wave through gcc etc. after the beta freeze
<doko> jamespage, good morning
<infinity> pitti: The linux failure isn't a regression, it can be badtested.  I'll do that.
<pitti> infinity: right, thanks; I talked about badtest'ing it with Laney yesterday, and he agreed too
<pitti> infinity: I meant a regression in the britney sense, in that it's not just a CI glitch (it's not a regression in the actual kernel, just new tests)
<infinity> pitti: Right.  badtest committed now.
<infinity> cjwatson: Seems to be some version confusion between series' ... vivid's update_excuses is talking about linux_3.16 (utopic's version).  Fallout from integrating SRU britney?
<flexiondotorg> Would it be possible to add powerpc sub-architectures, much like arm+xx and the old amd64+mac builds?
<ochosi> ev: hi! i saw that you originally wrote the ubiquity panel a few years back and i have a question related to the struts it sets, do you still recall that part?
<flexiondotorg> I don't want to do this for 15.04, bit would be interested for 15.10.
<flexiondotorg> The reason being Ubuntu MATE has a vibrant (and growing) PowerPC user community. I'd particularly like to add supprt for Amiga X500 and X1000 architectures, which as far as I understand require a slightly different initial ram disk to iBooks, Powermacs etc.
<flexiondotorg> cjwatson, ^^^^^^ Thoughts?
<tumbleweed> Laney: chmod -R g+w /home/groups/ubuntu-dev/htdocs/ubuntu-sponsorships on alioth, please
<dholbach> good morning
<infinity> flexiondotorg: I'd rather work with people to figure out why they need a different initrd and consolidate.
<infinity> flexiondotorg: Can you figure out what level of "different" is required?
<flexiondotorg> infinity, Agreed.
<flexiondotorg> infinity, If there is a willingness to support the hardware. I can do the leg work ð
<infinity> flexiondotorg: Or ask someone who knows to talk to me about it?
<flexiondotorg> infinity, OK.
<flexiondotorg> Thanks.
<infinity> flexiondotorg: All my PPC kit is IBM and very, very, very ancient Apple, so most of my non-server PPC work is blind, but I'm happy to make it go with help.
<flexiondotorg> infinity, At some point I'd like to get PPC64 builgs going for POWER 8.
<flexiondotorg> MATE with X2go is a platform IBM are pushing for remote terminal server solutions.
<flexiondotorg> In 15.10 we are going to get Ubuntu MATE fully X2go ready.
<flexiondotorg> IBM sponsor the X2go gatherings.
<flexiondotorg> I talking with a vendor to get sometime of POWER 8 servers for testing.
<Laney> tumbleweed: oho!
<Laney> why is that even owned by me?
<pitti> hm, launchpad.net seems AWOL from here; is that just me?
<pitti> ah, as usual asking helps, it just came back
<wgrant> One of the DCs was AWOL.
 * apw has the feeling it was "bigger" than a DC
<ev> ochosi: unfortunately not - that was years and two jobs ago
<tumbleweed> bdmurray: done
<tumbleweed> Laney: ta
<ochosi> ev: very understandable :) thanks for your answer anyway!
<mlankhorst> can someone look at the xorg-server 1.17 ffe?
<cjwatson> infinity: best ask jibel about that, I think, since it's in the autopkgtest layer
<infinity> jibel: Any idea why update_excuses for vivid seems to list tests for linux_3.16 instead of linux_3.18?
<jibel> infinity, no idea, but I'll have a look.
<infinity> jibel: As a hint, the version it's talking about (3.16.0-23.31) is from utopic-release, rather than what I'd expect, which would be vivid-proposed.
<infinity> jibel: Though the actual tests linked are vivid's.  So, whee.
<cjwatson> The links are hardcoded by britney.py.
<cjwatson> They don't have very much to do with the versions that get passed back by adt-britney :)
<infinity> Fair enough.
<flexiondotorg> I have been maintaining ubuntu-mate-settings here - lp:~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-settings
<flexiondotorg> But there is now also - lp:ubuntu/ubuntu-mate-settings
<flexiondotorg> What is the correct way for me to merge with lp:ubuntu/ubuntu-mate-settings
<flexiondotorg> Or request a merge with?
<cjwatson> lp:ubuntu/ubuntu-mate-settings is auto-imported; you can just ignore it if you prefer
<flexiondotorg> cjwatson, Auto imported from where?
<cjwatson> The archive
<flexiondotorg> Should I just file needs-packaging bugs to create a new version?
<cjwatson> What?  No.
<cjwatson> needs-packaging is for entirely new versions.
<flexiondotorg> So, if I've got a new version of the package what is the process for requesting an update?
<cjwatson> You can subscribe ubuntu-sponsors to ask for new uploads.
<cjwatson> But you should be working to get upload privileges yourself.
<cjwatson> It's not sustainable to have an entire flavour maintained solely through sponsorship.
<flexiondotorg> cjwatson, I have been. But I was told I needed to do work with sponsors before that process can start.
<cjwatson> My comment above was confusing, sorry.  What I meant to say was that needs-packaging is for entirely new *packages* - ones not in the archive at all.
<cjwatson> Certainly.
<cjwatson> Anyway, you can request updates by subscribing ubuntu-sponsors or working directly with sponsors in the same way you've been doing.
<cjwatson> lp:ubuntu/ubuntu-mate-settings probably has unhelpful history that has nothing in common with your existing branch.  I'd ignore it.
<cjwatson> We should be able to do better once we have git hosting support.
<flexiondotorg> cjwatson, Thanks. Understood. Git. Oooh, lovely.
<flexiondotorg> Trevinho, Please could you take a peek at https://code.launchpad.net/~ubuntu-mate-dev/compiz/mate-recommends/+merge/250855
<Trevinho> flexiondotorg: ok
<flexiondotorg> Trevinho, Thanks.
<aeoril> Good morning
<rbasak> mvo: https://bugs.launchpad.net/ubuntu/+source/freeradius/+bug/1187742/comments/11 looks right to me. Do you want to apply it?
<ubottu> Launchpad bug 1187742 in freeradius (Debian) "[patch] upstart job for freeradius" [Unknown,New]
<rbasak> As long as we're carrying the upstart delta...
<mvo> rbasak: sure, I take care of it
<rbasak> Thanks!
<rbasak> mvo: did you mean vivid?
<rbasak> (freeradius upload)
<mvo> rbasak: *cough* yes
<mvo> rbasak: if you are an archive-admin, please reject
<mvo> rbasak: but I guess we could SRU this fix actually
<rbasak> mvo: no, I'm not an archive admin. I just spotted the unapproved notice in #ubuntu-release. We could SRU I guess. I'm not sure it's worth it unless people actually want it though.
<didrocks> mvo: need a reject or want to keep in the SRU queue?
<mvo> didrocks: please reject
 * didrocks flushes
<mvo> didrocks: even if it gets a SRU it needs a proper version number
<mvo> thanks didrocks!
<didrocks> mvo: yeah, proper version seems it worths it, yw!
<aeoril> darkxst now that I have used gnome, I like it better at first blush - do you have any other good bugs I can work on?  That last one was great!
<bdmurray> tumbleweed: thanks
<Riddell> bdmurray: I'm trying to upload release-upgrader but it fails on a test test_sources_list.py", line 161, in test_extras_removal
<Riddell> bdmurray: this is needed for beta upgrades to work so I could do with it uploaded toot sweet, are you able to take a look and see if you can work out what's wrong?
<Riddell> #
<bdmurray> Riddell: sure, I guess
<Riddell> bdmurray: also some of the imports in the current version in the archive don't seem to match the bzr repository, are you sure you did a bzr update?
<bdmurray> Riddell: gah, it looks like I didn't
* Laney 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:
<bdmurray> seb128: Do you have a versioning plan in libpwquality needs another SRU?
<seb128> bdmurray, yeah, 1.1utopic1
<seb128> could have done that for this one
<bdmurray> seb128: okay
<atlaspaine> hello
<atlaspaine> who here is 'jml?'
<sarnold> atlaspaine: jml isn't in this channel; /wii jml  will show you if you share any channels in common with him. (I don't have any in common..)
<rbasak> arges: I know it's not your SRU day, but FYI I just uploaded the SRU for bug 1366174 that we discussed in Austin (finally!). I can't imagine a few days will make a difference now, so please could you review when you can?
<ubottu> bug 1366174 in apache2 (Ubuntu Trusty) "apache2 SEGV with multiple SSL sites" [High,In progress] https://launchpad.net/bugs/1366174
<rbasak> arges: it would probably be easiest for you to look at it as you're familiar with the issue already,.
<rbasak> alexbligh1: ^^
<atlaspaine> who here is jml?
<rbasak> alexbligh1: thank you again for your work and your patience. I'm still busy training up teammates so we'll be able to process these without getting blocked on me.
<rbasak> alexbligh1: although based on the quality of this patch, I don't feel that I'll need to review your patches any more :)
<atlaspaine> hello all humans!
<atlaspaine> and computers
<atlaspaine> I am requesting assistance for a terminal 'add-on' called "undistract-me"
<atlaspaine> Anyone familiar with  it? I was told to 'ping on Freenode' and know not what it mean.
<atlaspaine> Requesting system guidance.
<bdmurray> hallyn: is the vd2 upload in the lucid SRU queue still relevant?
<atlaspaine> unknown @bdmurray
<hallyn> bdmurray: vd2?
<hallyn> vde?
 * hallyn looking
<bdmurray> vde2 actually
<hallyn> oh i see :)
<hallyn> bdmurray: yeah i think it is
<bdmurray> okay
<bdmurray> hallyn: oh then, the version number will need to be changed
<hallyn> oh i see.  that exist sin precise
<hallyn> on it
<hallyn> tricky one.  should it be 2.2.3-3ubuntu1~12.0.4.1 ?
<hallyn> heh
<hallyn> 2.2.3-3ubuntu1~10.0.4.1
<hallyn> 2.2.3-3ubuntu1~10.04.1  <sheesh>
<hallyn> bdmurray: uploaded
<darkxst> aeoril, bug 1422176
<ubottu> bug 1422176 in Ubuntu GNOME "Missing icon for new bug report" [Medium,Triaged] https://launchpad.net/bugs/1422176
<darkxst> aeoril, and bug 1425349
<ubottu> bug 1425349 in mutter (Ubuntu) "Don't pass configure events on the composite overlay window to MetaStackTracker (aka: STACK_OP_RAISE_ABOVE: window not in stack)" [Undecided,New] https://launchpad.net/bugs/1425349
<aeoril> darkxst ok, thanks - You'll make a GNOMEer of me yet ... :)
<flexiondotorg> cyphermox, cjwatson, Laney, infinity, stokachu, pitti - Thank you! https://ubuntu-mate.org/blog/ubuntu-mate-vivid-beta1/
<flexiondotorg> didrocks and dholbach are not onlin, but thanks to them too.
<cjwatson> yw
<cjwatson> good luck with ongoing development :)
<cyphermox> flexiondotorg: awesome!
<stokachu> flexiondotorg: cool!
<flexiondotorg> ð
<flexiondotorg> cyphermox, Thanks man.
<flexiondotorg> Really, thank you!
<stokachu> i like that achievement unlocked
<stokachu> :)
<hallyn> slangasek: man that bugproxy on bug 1358835 is annoying
<ubottu> bug 1358835 in numactl (Ubuntu Trusty) "numa_node_of_cpu() returns warning when cpu_index > 79" [High,New] https://launchpad.net/bugs/1358835
<flexiondotorg> Someone go a jab distrowatch. Even with Marks personal assurance Canonical weren't going to sue Ubuntu MATE or anyone covering them they point blank refused to list the distro ;-/
<stokachu> wow really...
<stokachu> they list every distro under the sun
<flexiondotorg> I know.
<stokachu> wish i could help i dont know anyone at distrowatch :(
<slangasek> hallyn: heh sorry
<dobey> distrowatch is so irrelevant now anyway
<infinity> dobey: Was it ever not?
<infinity> dobey: At least, the "popularity" thing always was just a fanboy challenge, not a metric.
<dobey> infinity: it was slightly more useful 10-15 years ago.
<dobey> yeah, the popularity thing was always completely worthless
<simosx> there are people that do not understand what the stats at distrowatch represent. A CS lecturer at a local uni recommended Mint "because distrowatch"...
<simosx> probably an excuse, really.
<flexiondotorg> Agree with you say about Distrowatch. But, for a new dstro it is about discovery.
#ubuntu-devel 2015-02-27
<lamont> what does it mean when .xsession-errors has: upstart: at-spi2-registryd respawning too fast, stopped
<pitti> Good morning
<pitti> flexiondotorg: wow, congratulations!
<pitti> infinity: seems your linux force-badtest isn't working? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<mardy> seb128: Hi! A friend is affected by bug 1286779 in trusty
<ubottu> bug 1286779 in jetty (Ubuntu) "Please migrate libjetty-extra-java to tomcat7" [Critical,Fix released] https://launchpad.net/bugs/1286779
<mardy> seb128: as seen from other comments, it seems that the bug was fixed in utopic, but the fix was not backported yet
<mardy> seb128: do you know how one can mark the bug as still being in Confirmed state for a series?
<mardy> seb128: because the problem is that users who look at this bug page, are led to think that the bug is fixed in all versions, and they get confused
<mardy> Mirv: or do you know? ^
<Mirv> mardy: you can propose it for a series
<Mirv> mardy: use the "Nominate for series"
<Mirv> which should be on the right of "Also affects distribution/package" unless it requires some rights
<infinity> pitti: The linux badtest was superseded by a newer linux.
<mardy> Mirv: I think it does, I don't see it
<infinity> pitti: Which, I hope, also fixes the test...
<Mirv> mardy: ok, nominated. since there's a patch and there's the impact/testcase/regressionpotential trio (as per https://wiki.ubuntu.com/StableReleaseUpdates), can you subscribe ubuntu-sponsors to the bug?
<seb128> mardy, Mirv, what Mirv said, you should be able to propose it for nominations even if you can't approve those (or is that restricted to ubuntu bugsquad?)
<Mirv> seb128: I think even nomination might be bugsquad only, "Ask the Ubuntu bug control team to nominate the bug"
<mardy> seb128: there's just no "Nominate for series" link anywhere for me
<seb128> mardy, I guess you are not in ubuntu bug control, I though you would be, sorry
<Mirv> mardy: ok it should be all set and be visible at http://reqorts.qa.ubuntu.com/reports/sponsoring/ soonish
<mardy> seb128: np. Should I be in that group?
<seb128> mardy, well, apparently you are not missing not being in it? I though you were triaging the ubuntu bugs for the packages you maintain, and without that team memberships you don't have full triaging rights, do you?
<mardy> Mirv: thanks
<mardy> seb128: correct. I generally don't need these permissions, but sometimes I feel the need of editing the status of bugs for the software I maintain, when they are filed on the source package
<seb128> mardy, yeah, other teams tend to ask for bugsquad memberships because most team standardize on using the ubuntu package buglist as their main buglist, since that's where most users are going to file bugs
<seb128> mardy, anyway, if you want to be added just talk to bdmurray about it
<mardy> seb128: OK, thanks!
<seb128> yw!
<mardy> seb128: just to be safe: if I get that membership, will I get notifications for all Ubuntu bugs, even those I don't care about?
<seb128> mardy, no, bugsquad has a list, emails go to the list, if you don't subscribe to the list you don't get any email
<mardy> seb128: cool, thanks
<seb128> yw :-)
<doko> pitti, autopkgtest for zope.session 3.9.5-0ubuntu2: Regression (Jenkins: public, private)
<doko> but the link shows success ...
<pitti> doko: erk, public jenkins fail, it's missing the log from #6; see http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-zope.session/lastBuild/?
<doko> pitti, ahh, thanks
<seb128> didrocks, pitti, slangasek: btw what's the status of the systemd transition? still looked at for vivid? do we have a bug/ffe recording the status, what's still needed, etc?
<didrocks> seb128: IIRC, slangasek told to pitti the other day to go ahead on the NFS systemd porting
<didrocks> as he didn't get the time to catch it
<didrocks> and NFS upstream has a systemd unit
<seb128> k
<pitti> yeah, that's the status now -- we need to find someone to fix NFS
<seb128> do we still plan to do it/have a ffe filed for it?
<didrocks> that's all about my knowledge, getting back some butter to spread on bread (like my knowledge :p)
<pitti> (and get familiar enough with it to test)
<pitti> didrocks: so I guess you aren't interested in looking at it?
<pitti> I need to work on some other urgent things today/Monday, but I'll try to find some time to set up a test system and get familiar with our split upstart jobs and the NFS components
<didrocks> pitti: I don't have enough knowledge apart from having used it for a while (and not anymore), but it seems to be quite tricky, no, like /home or /usr on NFSâ¦?
<didrocks> I can give a look on Monday if needed
<pitti> didrocks: let's not start /usr on NFS :)
<didrocks> but I would clearly need double checking :)
<pitti> /home or /srv or so are quite reasonable, though
<pitti> didrocks: yeah, we can team up, to add our (so far) nonexistant knowledge :)
<didrocks> pitti: let's do that, I'll start on Monday
<pitti> didrocks: I propose we first figure out a bunch of scripts/VMs to test this under upstart, then port the server (NFS server should be really simple, compared to client), and then tackle the client bits
<pitti> didrocks: nice, thanks! the two of us should figure this out hopefully
<didrocks> pitti: let's cross fingers! (and sounds like a good plan)
<pitti> didrocks: right, upstream git has systemd units, let's see how well they match up with our upstart job / existing config files
<pitti> although I'd hope that we didn't change upstream's config files in Ubuntu
<didrocks> yeah, I guess a new week with fresh brain will help :)
<pitti> meh, systemd's tests take aaages now; but oh well, ++confidence
<pitti> speaking of that, we don't have an fsck test yet
 * didrocks always prefer long running tests (especially when you don't have to run on your machine itself) than no confidence :)
<didrocks> yeah, I want to tackle this
<didrocks> I think I would have to go to integration tests, not sure about unitsâ¦
<didrocks> and having a mock plymouth socket, listening to events
<pitti> didrocks: nah, an integration autopkgtest
<didrocks> that wouldn't do it for upstream though, right?
<pitti> didrocks: like, plug in the mock fsck, check that the systemd still starts and that fsckd ran and finished, somethign like that?
<didrocks> oh, no more fine-grained?
<didrocks> maybe sending at least a Control+C and seeing it being intterupt?
<didrocks> (if it's easy to do that in autopkgtests)
<didrocks> interrupt*
<pitti> didrocks: well, something that guards against boot failure is already valuable; verifying that it displays the expected stuff is harder, but also much easier to recover from if we screw that up
<pitti> didrocks: upstream also has these VM tests; the same approach ought to work there, too
<didrocks> yeah, I would still like that we check cancellations works
<didrocks> oh nice
<didrocks> just need to ensure it's easy to send key press to the vm
<pitti> didrocks: hm, injecting ^C into plymouth in a VM without screen or keyboard, we have to think about that
<didrocks> yeah
<pitti> didrocks: we could talk to the monitor, but an autopkgtest doesn't have access to that
<didrocks> right, as it's inside the vmâ¦
<pitti> didrocks: oh, perhaps via uinput
 * didrocks doesn't know that, but noting downâ¦
<pitti> didrocks: http://thiemonge.org/getting-started-with-uinput
<didrocks> pitti: first google result ;)
<pitti> didrocks: it's what autopilot uses as well to fake keypresses and mouse moves
<pitti> ah, /me pats firefox awesome bar :)
<didrocks> heh :)
<didrocks> pitti: ok, if it works, just need to ensure I can get the right timing (when checking for process)
<didrocks> and having a flag in the mock fsck to tell "fsck ended properly"
<didrocks> and just checking the flag file isn't prevent when cancelled and no more process
<didrocks> sounds easy enough
<pitti> didrocks: so you'd need to create a unit which runs on boot Before=systemd-fsck-root.service and then sets up uinput and polls for /sbin/fsck? (or just fsckd running)
<pitti> didrocks: the autopkgtest will only resume after the boot finished, so you can't do it right there; but adding such a helper unit before reboot should work
<didrocks> pitti: yeah, the unit approach for this sounds the easiest and putting flags
<dholbach> good morning
 * pitti waves to dholbach
<dholbach> hi pitti
<darkxst> hey pitti, didrocks
<darkxst> is systemd init still happening this cycle?
<didrocks> darkxst: hey! backlog here, we discussed about NFS ^ I guess once it's done, we can discuss the FFe
<pitti> we still aim for it, yes
<darkxst> ok we have a really bad bug (some sort of race) with upstart init atm and that will need to be fixed if systemd doesnt land
<darkxst> bug 1424731
<ubottu> bug 1424731 in gdm (Ubuntu) "gdm appears to have cycle problem/only works after using sudo service gdm restart in terminal" [Undecided,New] https://launchpad.net/bugs/1424731
<pitti> doko: ah, missing pkg_resources.component_re is indeed related to new setuptools, right? is that intended, and zope.session needs to be updated, or is that a setuptools bug?
<infinity> pitti, jibel: Seeing tests for "glibc_2.19-10ubuntu2" on vivid's update_excuses, which is utopic's version.  I assume the same as the linux_3.16 thing I saw yesterday...
<pitti> infinity: right
<infinity> pitti: Any idea what's up with that? :P
<pitti> infinity: not immediately, I'm afraid; this code is horrible, and I had hoped it would have died several months ago :/
<pitti> so the version is correct in results.history
<doko> pitti: van.pydeb fixed
<pitti> doko: ah, that's what zope.session used? thanks
<pitti> doko: if it doesn't re-trigger the test automatically, I'll kick it in about an hour
<doko> pitti, van.pydeb is now in the release pocket
<pitti> ah, great (doesn't even need to be, proposed is enough); zope.session test requeued
<pitti> but the queue is full, will take a bit
<jibel> infinity, I think it's the same thing than linux yesterday, but didn't find what it is yet.
<jibel> +1 to make this code die quickly
<doko> infinity, what is the status of the two disabled ppc64el buildds? besides being disabled
<apw> doko, would the curent failure on the glibc test regarding relocs be related to the binutils fix you uploaded this hour ? (see pm for the errors)
<doko> apw, that was updated on Tuesday, not now. it just migrated
<apw> doko, ahh so it did, fooled me
<doko> apw, but honestly, let's wait until infinity uploads glibc-2.21 built with GCC 4.9 ...
<apw> doko, you think that will ever build :)
<doko> the limiting factor is infinity, not GCC ;-P
<infinity> doko: How does waiting for a new glibc change that the current binutils broke glibc's testsuite? :P
<doko> infinity, is it binutils?
<infinity> doko: It sure looks like it at a glance.
<infinity> /usr/bin/ld: copy reloc against protected `protvaritcpt' is invalid
<infinity> /usr/bin/ld: failed to set dynamic section sizes: Bad value
<infinity> collect2: error: ld returned 1 exit status
<doko> and you are sure that gcc-4.8 is still correct?
<infinity> No code changes in glibc, hard to blame anyone else but binutils or gcc.
<doko> I like makefiles like these:
<doko> # Beautified output
<doko> quiet_GEN = @echo "  GEN        $@"; $(GEN)
<doko> quiet_CC  = @echo "  CC $@"; $(CC)
<doko> quiet_LD  = @echo "  LD $@"; $(LD)
<doko> quiet_INSTALL = @echo "  INSTALL        $?"; $(INSTALL)
<infinity> doko: Erm, I'm sure we should move to 4.9 at some point, but "the toolchain we're using stopped working correctly" is the bug being reported here.
<doko> infinity, what is the status of the two disabled ppc64el buildds? besides being disabled
<infinity> doko: Non existant, except in the UI.  They will exist again some day.
<doko> ugh
<infinity> https://sourceware.org/bugzilla/show_bug.cgi?id=17709 <-- binutils regression that hjl is blaming on glibc, and no fix in either project.  Yay.
<ubottu> sourceware.org bug 17709 in ld "[2.26 Regression] elf/vismain test in glibc failed" [Normal,New]
<doko> he's blaming it on glibc ...
<doko> apw, is there a build log in launchpad?
<infinity> doko: Yes, I said he's blaming it on glibc. :P
<infinity> doko: Still, bisecting the offending breakage in binutils (that was backported from 2.26 to 2.25, apparently, yay cowboys) shouldn't be too hard?  I don't think it's unreasonable to expect to be able to build current glibc with our binutils.
<apw> doko, it is in the adt builders, i'll paste the log urls in pm for you
<infinity> pitti: Can we revisit the concept of artificial rdeps for triggering tests that we want despite no direct dependencies?  (ie: glibc/binutils)
<pitti> infinity: yes; that's somewhere in the big stack of things to do, create a Tests.gz index (like Packages.gz, but for all debian/tests/control)
<pitti> with that we can do reverse test dependency triggering
<pitti> infinity: binutils ought to trigger on glibc uploads already, though?
<infinity> pitti: If it does, someone forced binutils in...
<infinity> pitti: Err, no.  The other way around.
<infinity> pitti: binutils needed to trigger a glibc test.
<infinity> pitti: And glibc doesn't depend on binutils (why would it?)
<pitti> right; I think that's the direction which isn't currently happening
<pitti> actually it does
<pitti> Build-Depends: ... binutils (>= 2.21)
<infinity> pitti: Some of this would be caught if we were also testing rbuilddeps along with rdeps, but that doesn't really help for build-essential. :P
<infinity> pitti: We don't test rbuilddeps, do we?
<pitti> infinity: we do; at least the code makes an effort to
<pitti> and we most certainly want to
<infinity> pitti: Well, I'm going to go with "no, you really don't".
<infinity> pitti: Cause the last glibc test was Feb 19, and binutils was uploaded way after that.
<infinity> pitti: And it migrated without fuss.
<pitti> infinity: maybe, but that's a bug then, and not intended
<pitti> infinity: no, I have a "Jenkins Failure - vivid-adt-glibc 32" from this morning
<pitti> http://d-jenkins.ubuntu-ci:8080/job/vivid-adt-glibc/32/? clearly failed
<infinity> pitti: Is it really a bug, though?  The number of people who build-dep on build-essential packages when they shouldn't would blow up the reverse test map, I'd guess.
<infinity> pitti: Yes, 32 was after binutils had migrated.
<doko> infinity, there's a lot of the copy-relocs changes ... will need to do that manually
<pitti> infinity: hm, digging through http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses/vivid/2015-02-27/ to see excuses; whee, we run it every 10 mins now?
<pitti> er, what is that
<pitti> are they double-gzip'ed?
<pitti> so they are
<jamespage> pitti, morning - the latest python2.7 update had a slightly bad effect on gobject-2 - see bug 1426294
<ubottu> bug 1426294 in terminator (Ubuntu) "unable to import gtk.Window -> gio: TypeError: type 'gio.MemoryOutputStream' is not dynamically allocated but its base type '__main__.GPollableOutputStream' is dynamically allocated" [Undecided,New] https://launchpad.net/bugs/1426294
<pitti> infinity: confirmed, bintuils only triggered a handful of packages, not glibc
<pitti> argh bug :/ /me piles on TODO to investigate
<pitti> jibel: reverse build deps triggering not working doesn't happen to ring a bell, I figure?
<jibel> pitti, no it's new.
<jamespage> pitti, related to:
<jamespage> Issue #22079: PyType_Ready() now checks that statically allocated type has
<jamespage>       no dynamically allocated bases.
<pitti> jibel: ack, so TODO it is
<jibel> pitti, I can have a look in 1hour or so
<infinity> pitti: I'm still not positive we *want* reverse build-deps to trigger.  You might want to build a map of what that would look like before doing it.
<doko> jamespage, any update on the required gccgo-go changes?
<jamespage> doko, switching to use the go stuff provided by gccgo right?
<doko> yes
<doko> if it works ...
<doko> jamespage, I can add go and gofmt symlinks too in gccgo for those architectures where go and gofmt don't exist (arm64, powerpc, ppc64el?)
<jamespage> doko, both golang-go and gccgo-go use alternatives for the various binary conflicts - maybe follow that approach? then we can switch between them for comparison
<jamespage> if all is good then we can just drop gccgo-go
<jamespage> I'm all up for that - it was a temporary hack I was never that happy with
<doko> jamespage, so both go and gofmt are handled by alternatives?
<jamespage> let me check
<jamespage> I think it might just be go
<flexiondotorg> Morning
<flexiondotorg> pitti, dholbach Just wanted to say thanks for your help getting Ubuntu MATE official.
<flexiondotorg> You went online last night when I thanked the others.
<flexiondotorg> Oh, and didrocks. Thanks.
<flexiondotorg> https://ubuntu-mate.org/blog/ubuntu-mate-vivid-beta1/
<dholbach> thanks a lot for working on Ubuntu MATE :-)
<dholbach> great work!
<pitti> flexiondotorg: ^5s, great work!
<didrocks> you're welcome flexiondotorg, nice work on Ubuntu MATE! ;)
<darkxst> hey flexiondotorg
<flexiondotorg> darkxst, 'sup?
<darkxst> flexiondotorg, winding down for the night, built a deck today so a little sore
<jamespage> doko, just go atm
<doko> jamespage, can we do that for gofmt too, or isn't that installed by golang?
<xnox> hallyn: where is shadow upstream?
<Mirv> pitti: is that the bot of yours or are you manually rekicking autopkgtest jobs? thanks, regardless of which :)
<pitti> Mirv: it's the jenkins -> imap -> mutt -> pitti -> jenkins pipeline :)
<Mirv> oh, that automation :)
<pitti> our CI machines are melting again, and we get the usual random fallout
<mardy> pete-woods: hi! Do I understand correctly, that libqtdbusmock is something that makes it easier to use python-dbusmock from Qt apps?
<mardy> pete-woods: I'm having a look at the code, but despite seeing python3-dbusmock in the deps, I don't find where it's using it
<pete-woods> mardy: there are two related libraries. libqtdbusmock and libqtdbustest. the former makes talking to dbusmock easier, while the latter simplifies testing dbus stuff in Qt much easier
<pitti> tseliot: hm, ubuntu-drivers-common's tests recently started to fail on the -304 versions; are you aware of any recent changes there?
<pete-woods> mardy: each time you register a mock in qtdbusmock, it registers a binary, and associated dbus stuff to look for against libqtdbustest
<pete-woods> so it's actually the test lib that starts dbusmock
<pete-woods> but the mock lib that configures it
<tseliot> pitti: maybe I forgot to patch it to work with linux 3.19. That would explain it (if you're talking about vivid)
<pitti> tseliot: yes, vivid
<pitti> tseliot: ah, could have been triggered by the new kernel, indeed
<tseliot> pitti: I'm trying to install it in my chroot to see if I can reproduce the problem
<pitti> tseliot: note the new kernel is still in vivid-proposed
<pete-woods> mardy: http://bazaar.launchpad.net/~unity-api-team/indicator-network/integration-testing/view/head:/tests/integration/indicator/TestIndicatorNetworkService.cpp is a reasonably detailed example of usage
<tseliot> pitti: is it possible that we are getting the failure from vivid-proposed?
<pitti> tseliot: yes, we run all tests in -proposed
<pitti> tseliot: we want to detect regressions in -proposed already after all, not only when they already landed
<pitti> ... usually
 * pitti waves at binutils and sighs
<pete-woods> mardy: http://bazaar.launchpad.net/~indicator-applet-developers/hud/trunk.15.04/view/head:/tests/unit/service/TestVoice.cpp is a simpler example, with more usage of the dbusmock interface
<tseliot> pitti: ok, good, that's what I remembered but I wasn't sure
 * tseliot -> lunch
<mardy> pete-woods: thanks a lot, that's very useful!
<diwic> Hi. It seems PulseAudio 1:6.0-0ubuntu4 is stuck in proposed? I thought this was due to beta freeze, but the beta freeze should be over, and thus PA should migrate to the release pocket?
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pulseaudio
<pitti> looks like another jenkins hiccup, I restarted fluidsynth
<diwic> pitti, ok, thanks
<infinity> pitti: While people are being whiney about autpkgtest, the public mirror sure seems to be laggy...
<pitti> retoaded, psivaa_ ^ that's something I can't help with; can you?
<pitti> publishing queue of public jenkins?
<infinity> pitti: I assume (hope?) that in the magical jenkins-free debci future, this will all be real-time via a public interface, instead of the user-hostile private/public split?
<pitti> infinity: yes, should be; the cloud will save us all (famous last words..)
<psivaa_> pitti: i've resurrected publisher plugin, i'll also watch it for some time
<pitti> psivaa_: thanks
<hallyn> xnox: github.com/shadow-maint/shadow
 * hallyn mostly afk today - \o
<xnox> hallyn: why that history is disjoint from git://anonscm.debian.org/pkg-shadow/shadow.git ?
<hallyn> bc that one is the packaging tree.  (used to be separate mercurial branches)
<hallyn> xnox: i thought there was a new github.com/shadow-maint tree for that one, buti don't see it...  hm
<xnox> hallyn: i'll send patches to both, and mailing list.... i guess....
<hallyn> xnox: thx.  i'll be back in on monday;  we can discuss more then if you like, especially if you have time/inclination to help out :)
<hallyn> (the maintainers are pretty busy)
<xnox> hallyn: i have a bunch of patches....
<hallyn> cool.  i can help review and push upsream, but i don't touch the packaging tree
<hallyn> anyway, i'll be in on monday - ttyl
<rbasak> cjwatson: I've just come across bug 669481 and 872244 and am concerned about the default server headless case. utlemming thinks that you had a concern about desktop so didn't want to change the default.
<ubottu> bug 797544 in grub2 (Ubuntu) "duplicate for #872244 grub2 waits forever for keystroke before booting default OS. headless server. hang." [High,Fix released] https://launchpad.net/bugs/797544
<ubottu> bug 669481 in grub2 (Ubuntu Precise) "Timeout should not be -1 if $recordfail" [Medium,Fix released] https://launchpad.net/bugs/669481
<rbasak> (this is about GRUB_RECORDFAIL_TIMEOUT)
<rbasak> cjwatson: do you remember what the concern was please? I can't find any record of it.
<infinity> rbasak: I ran into that with my parents' firewall a coulpe of months ago and had a conversation with Colin about it where, I *think* we concluded that an infinite timeout is bad, *but* the proper solution should probably involve a loop counter.
<rbasak> infinity: in the shorter time, how about 30 or 60 seconds or something? Definitely on headless servers. I don't mind about desktops.
<rbasak> shorter term
<rbasak> infinity: it this necessitates server being different from desktop, I'd like to sort that out. I feel quite strongly that this is a critical bug in server LTS releases.
<infinity> rbasak: I think the conversation (and the right answer) applies to both, TBH.  I don't really want to see a forked config here based on some heuristic about what a "server" is.
<infinity> rbasak: Check, say, Win7/8, where a failed boot or unclean shutdown will present you with a menu with a 30s timeout.  I suspect most people think this is reasonable.
<rbasak> infinity: so we can just set GRUB_RECORDFAIL_TIMEOUT=30 by default, no?
<infinity> rbasak: But, ideally, we also don't want people in an infinite reboot loop either, which could happen with the right sort of breakage.
<infinity> rbasak: But yeah, I think catering to the edge "what if there's a loop" case is probably being obtuse, and setting the timeout to 30 is probably a good first step.
<cjwatson> rbasak: I'm afraid I don't remember the details.  I may have been acting under instructions from design or something.
<rbasak> cjwatson: OK, no worries. Any objection to setting the default to 30 in Vivid now?
<cjwatson> rbasak: 30s doesn't seem unreasonable, but please don't change the default config file if you can possibly avoid it to avoid potential upgrade prompts; it can be changed in 00_header instead.
<cjwatson> rbasak: My only objection would be if it were done in an Ubuntu patch, rather than changing it in Debian.
<rbasak> OK
<cjwatson> Since it took me literally years to get the packages back in sync ...
<cjwatson> (I haven't been able to find any record of this past conversation in my IRC logs.)
<cjwatson> rbasak: If somebody sends me a patch I'd be happy to integrate it into the packaging in unstable.
<rbasak> cjwatson: OK thanks. I'll see what I can do.
<cjwatson> Don't worry too much about it being in exactly the right form, since it'll need to be several items deep in a git-dpm stack anyhow.
<infinity> cjwatson: The conversation that led to the current behaviour, or the conversation with a grumpy me when I ran into it? :P
<cjwatson> I just want something tested to have the right kind of behaviour.
<cjwatson> infinity: The one utlemming thinks I had with them.
<infinity> Or that.
<cjwatson> Could've been at a sprint, I guess.
<rbasak> utlemming thinks there was a reason that the default wasn't set to something positive in the first place.
<infinity> cjwatson: Anyhow, I vaguely recall you and I agreeing that the current default was crap, but I don't recall if we mapped out what we thought the Right Thing was.
<cjwatson> The best guess I have would have been concerns about infinite reboot loops, or possibly something to do with picking an appropriate default.
<infinity> But a 30s delay seems like an okay compromise for now.
<cjwatson> (that people could react to in reasonable time, since most people read slower than geeks who've seen the boot screen a thousand times)
<cjwatson> But, hey, if it's wrong for everyone, I don't have a problem with trying a change.
<infinity> I don't think "infinite" or "long enough to read all the text on the screen" are appreciably different for desktop users, especially when most of them will hit <enter> without reading it anyway.
<infinity> And infinite is clearly wrong for unattended rebooting.
<infinity> cjwatson: Oh, I remember how I was bitten by this.  Brownouts.  Machine bounced twice in under a minute, and the second one killed it.
<cjwatson> Yeah, that'd do it
<infinity> cjwatson: Which seems like a not unlikely scenario for power loss in general.
<rbasak> That fits my understanding. Second failure after grub but before /etc/init.d/grub-common runs.
<infinity> rbasak: That exact scenario on a Windows machine (for instance) will land you at either a 30s or 60s (I think 30, but I'd have to bounce a machine to see) timeout that says "we failed to boot completely on the last attempt, how do you feel about maybe trying safe mode?"
<infinity> Ahh, youtube to the rescue, it's 30s.
<infinity> rbasak: https://www.youtube.com/watch?v=WcLDch_OO3k#t=110 <-- For reference.
<infinity> rbasak: And they have a fair bit of text to read, so I think 30s would be fine for us.
<infinity> cjwatson: ^
<infinity> Now, the difference is that they default to "recovery mode", and I think that would still be wrong for us, since our recovery mode doesn't have networking.
<infinity> Or startup repair, even.  Which we don't have.
<rbasak> Our most likely failure mode is a kernel upgrade.
<rbasak> So ideally maybe default to the last known working kernel? That sounds non-trivial though.
<pitti> doko: FYI, http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-zope.session/8/ARCH=amd64,label=adt/console now fails because van.pydeb's module doesn't import "re"
<doko> pitti, ouch!
<xnox> pitti: nice catch =)
<aeoril> I am trying to debug apport, so I have made a small application that just SIGSEGVs itself.  I have checked and apport seems to be fully enabled on trusty.  Why might this not bring up apport? https://gist.github.com/aeoril/7d2538d3db393d4b28a3
<mardy> pitti: hi! About python-dbusmock: I'm adding a method which returns "a(ua{sv})", but I'm not sure how to code the return value ("ret = ...")
<mardy> pitti: should I use GVariant, or just python types?
<pitti> aeoril: probably because it's not a packaged application
<pitti> aeoril: check /var/log/apport.log
<pitti> aeoril: my favourite crash test is to call sh -c 'kill -SEGV $$'
<pitti> aeoril: that'll create a report for dash
<aeoril> pitti ok, thanks - what is dash?
<pitti> aeoril: our default /bin/sh; you can also call bash -c ... of course, if you prefer
<pitti> mardy: there is no automatic conversion, this is using dbus-python
<aeoril> pitti ok, got it - thanks!  That will really help I am sure!
<pitti> mardy: so you have to return something like dbus.Array([], signature='v')
<aeoril> pitti just out of curiosity, what do the $$s do on that line?
<pitti> aeoril: it's a magic variable whose value is the current pid
<aeoril> pitti I figured, but was just checking - thanks!
<pitti> aeoril: i. e. that starts a shell, and sends a SIGSEGV signal to itself
<aeoril> gotcha! :)
<mardy> pitti: ok, thanks
<aeoril> pitti worked like a charm! :) thanks!
<doko> pitti, van.pydeb in -release
<pitti> doko: zope.session running
<Laney> doko: do you know how to fix https://bugs.launchpad.net/ubuntu/+source/terminator/+bug/1426294 ?
<ubottu> Launchpad bug 1426294 in terminator (Ubuntu) "unable to import gtk.Window -> gio: TypeError: type 'gio.MemoryOutputStream' is not dynamically allocated but its base type '__main__.GPollableOutputStream' is dynamically allocated" [Undecided,Confirmed]
<doko> Laney, no, hoped for pitti ... in the worst case, we'll have to revert the upstream python fix
<doko> but it's in the 3.4.3 release too
<pitti> Laney: oh -- git-buildpackage screams the same thing at me now when it tries to notify me
<pitti> python? that rather looked like "new glib" or so? but I haven't investigated it at all yet
<pitti> doko: http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-zope.session/9/ green!
<pitti> thanks
<pitti> that shold clear setuptools
<pitti> Laney, doko: btw, "gio" isn't introspection, it's the old static bindings
<Laney> indeed
<doko> hmm
<lamont> why is it that my dist-upgrade today has cause ctl-alt-T to stop launching a terminal?
<lamont> (yes, vivid)
<Laney> what terminal emulator?
<lamont> terminator, actually
<Laney> see immediately above
<lamont> interestingly, right-click, "open terminal" works just fine
<pitti> hm, still works here
<Laney> did you get new python?
<pitti> but I dist-upgraded this morning (11 hours ago)
<pitti> Laney: python2.7? or literally the metapackage?
<pitti> Laney: I do have teh broken gio bits, if that's the same
<Laney> I think 2.7, just trying to downgrade now to check
<lamont> 2.7.9-1ubuntu1
<pitti> also works in a guest session
<pitti> lamont: got that
<Laney> changelog mentions this identified upstream bug
<lamont> I want to say that it's gtk2 vs 3 or some such ancient crack
<attente_> hi, has anyone tried using Qt5LinguistTools in a cmake file? i'm encountering https://bugs.launchpad.net/ubuntu/+source/qttools-opensource-src/+bug/1292986, but it says that the fix was released
<ubottu> Launchpad bug 1292986 in qttools-opensource-src (Ubuntu) "Qt5: Incorrect lrelease path with CMake" [Undecided,Fix released]
<lamont> (handwavy half-recollection of a previous discussion about terminator not having migrated to some new rev of something, about a year ago)
<lamont> and by "about" I mean give or take 6-12 months
<Laney> http://paste.ubuntu.com/10450739/
<Laney> (& happy terminator)
<lamont> Laney: what all debs did you reinstall?
<Laney> lamont: enough of these guys to please dpkg https://launchpad.net/ubuntu/+source/python2.7/2.7.9-1/+build/6635827
<lamont> ok
<Laney> libpython* python2.7 python-minimal
<lamont> sadly, terminator became somewhat less useful to my workmodel when changing font size meant that it went bug-nutso if you created a new tile.
<lamont> my remaining question is wtf happened to my window manager at the home machine
<lamont> what passes for a top-bar is nothing but the nautilus menu
<lamont> s/menu/topbar/
<lamont> and none of the shortcuts seem to interest the computer anymore
<lamont> current plan is to see if a reinstall makes it happier
<lamont> (sving the old root, of course)
<Odd_Bloke> How can I see what IP address apt-get is resolving archives to?
<doko> Laney, pitti: should we revert this one bug fix for now? if yes, please do it. I'll have to leave soonish
<Laney> doko: I have NFC about python modules so there's not much chance I can fix pygobject-2
<doko> Laney, no, revert the fix that one issue in python2.7
<Laney> Yeah, but I'm guessing that a real fix is preferable
<Laney> Happy to revert in the meanwhile though
<doko> sure
<Laney> see if pitti has a bright idea, otherwise I'll do that before EODing
<doko> Laney, leave me a message on irc, will be back very late tonight
<flexiondotorg> Is there anyone here who would sponsor the update of a couple of package for Ubuntu MATE?
<flexiondotorg> One is the meta package, the other is the settings.
<flexiondotorg> infinity, Could you update a couple of packages for me?
<aeoril> I am trying to figure out how to build apport from source (bzr branch lp:apport).  I saw "setup.py" and looked at it and it looked like a likely suspect.  I ran it, but got this error and am not sure where to go from here:  https://bugs.launchpad.net/ubuntu/+source/apport/+bug/348250 Google search unfortunately led me nowhere
<ubottu> Launchpad bug 348250 in apport (Ubuntu) "ImportError: No module named apport.packaging_impl" [Low,Fix released]
<aeoril> oh, I guess that is fixed now
<aeoril> nm, i was confused by the ubottu message - it is not fixed yet
<aeoril> pitti ^
<aeoril> whoops, I meant to link to my gist:  https://gist.github.com/aeoril/4084dc205732a553044c not just the bug report
<aeoril> (and that was the wrong bug report anyway)
<flexiondotorg> Could someone please tell me what the correct merge target for indicator-sound is please?
<flexiondotorg> Because I've just generate a massive MP from just a couple of lines change?
<flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/indicator-sound/mate/+merge/251295
<cjwatson> the correct merge target is typically whatever you branched from in the first place.
<aeoril> flexiondotorg uggghh - that happened to me!
<flexiondotorg> cjwatson, I branched from lp:indicator-sound and tried to merge back to it.
<cjwatson> No, you didn't
<cjwatson> You branched from lp:ubuntu/indicator-sound
<flexiondotorg> Ooops.
<cjwatson> But I'm pretty sure that's not used; I suggest rebranching from lp:indicator-sound and reapplying your change
<flexiondotorg> I'm an idiot.
<flexiondotorg> cjwatson, Thanks.
<flexiondotorg> I need a drink.
<aeoril> flexiondotorg you are not an idiot :)
<cjwatson> lp:indicator-sound is AFAIK the usual merge target
<Laney> doko: uploading it
<alexbligh1> packaging question: I have a package X, that depended on a package foo-open-isci, which was an alternate build of open-iscsi. I now want to bring in stock open-iscsi instead. So I have made X' (new version of X) depend on a transitional package T, T depends on open-iscsi, and Conflicts, Provides, Replaces, Breaks foo-open-iscsi. However, as the two open-iscsi packages contain the same files, dpkg complains it c
<alexbligh1> an't overwrite files in foo-open-iscsi with a file from open-iscsi of the same name. I thought Breaks: was meant to ensure foo-open-iscsi was removed first, but perhaps that only ensures it is removed before T is installed, not T's dependencies. Any ideas?
<aeoril> oh, its python - I don't compile it, I guess
<Noskcaj> xnox, Is there anything in particular i should be doing to get a +1 from you for MOTU?
<aeoril> pitti you around?  I have been dinking all around the apport source from lp:apport and just cannot figure out how to test the gui.  I am trying to fix:  https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1422176 and beleive I already know how to fix it (seems simple) but have no idea how to test my changes.  Would you be willing to help me with this fix?
<ubottu> Launchpad bug 1422176 in Ubuntu GNOME "Missing icon for new bug report" [Medium,Triaged]
<aeoril> pitti oh, I think I see how to test - change them live in the installed directory, then test them, then update the source branch ... does that sound reasonable?
<smoser> slangasek, https://launchpadlibrarian.net/195014257/cloud-init_0.7.7%7Esnappy%7Ebzr1045-0ubuntu2_0.7.7%7Esnappy%7Ebzr1045-0ubuntu3.diff.gz
<smoser> is that appropriate for cloud-init upstream ?
<smoser> you had previously submitted systemd-user-sessions.service
<smoser> ah. nevermind. i see that you fixed with systemd-user-sessions.service
#ubuntu-devel 2015-02-28
<aeoril> darkxst would you be willing to help me a little with how to test this bug?  I think I know how to fix it, but have been unable to test it successfully:  https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1422176
<ubottu> Launchpad bug 1422176 in Ubuntu GNOME "Missing icon for new bug report" [Medium,Triaged]
<aeoril> pitti helped me a little, and I asked him for further help, but I guess he is unable to respond
<aeoril> darkxst I made the changes I think are necessary to /usr/share/apport/apport-gtk to test, but the apport gui failed to start when I did.  I am not sure if there is a way to test the gui from the source branch I downloaded from lp:apport
<aeoril> darkxst also, for some reason apport only starts for the first bug, even if I do not muck with it - I think that may be a bug in apport
<aeoril> (the gui, even for different executables that crash)
<Snow-Man> oh, come *on*.  ipv6 is busted *again*? :(
<stgraber> Snow-Man: if you mean bug 1426618, then yes
<ubottu> bug 1426618 in linux (Ubuntu) "Latest 3.13 kernel update (3.13.0-46) is causing kernel panics related to IPv6" [Critical,Triaged] https://launchpad.net/bugs/1426618
<Snow-Man> stgraber: yes, I was on 1404558
<stgraber> not really busted though, works great for about 24h, then you panic and reboot :)
<Snow-Man> :Ã¾
<stgraber> problem is, in either bug it's not very easy to reproduce. The last time around we considered 24+ hours without a panic to be "fixed". So no easy reproducer typically means no good testcase to make sure that kind of stuff doesn't happen again.
<stgraber> anyway, -45 works fine and I'm sure apw or someone else on the kernel team will figure it out quickly...
<Snow-Man> I expect -46 probably included some security updates or something tho. :/
<stgraber> it had one CVE related to KVM on x86 and it's backporting a bunch of security-related userns changes, no obvious remote security flaw fixes that I can see at least
<ScottK> I guess I'm glad I didn't reboot yet.
<Snow-Man> ScottK: see, that's the situation I'm in
<Snow-Man> I just installed -46 earlier today, in fact.
<darkxst> aeoril, use something like `ubuntu-bug gnome-shell`
<aeoril> darkxst ok, thanks
<aeoril> darkxst well, I fixed and tested the error icons but there is a function call that has deprecated constants in it in apport-gtk (STOCK_CANCEL and STOCK_OPEN).  Should I fix those as well?  If so, how to test?: https://gist.github.com/aeoril/5c906f901a1021594d78#file-gistfile1-txt
<darkxst> aeoril, I think you would do something like gtk.button_new_with_label ("_Cancel");
<darkxst> not sure how to test though, don't ever recall seeing a filechooser in apport
<darkxst> however they are only Deprecated, so probably still there in Gtk?
<darkxst> in which case you don't need to fix it
<darkxst> aeoril, actually seems the filechooser is not used by any package hooks at all, so don't worry about it ;)
<doko> Laney, can you/desktop forward this issue to gnome (?) ?
<aeoril> darkxst I am ready to commit my fix for apport LP: #1422176 However, I wanted to make sure I pushed correctly this time.  The command on apport's launchpad page to push is as follows.  Do use this?  bzr push lp:~aeoril/apport/apport I was wondering if I just just do:  bzr push lp:~aeoril/apport instead?  Once you let me know, I will push and do a merge proposal.  Thanks for your help -
<aeoril> againg :)
<ubottu> Launchpad bug 1422176 in Ubuntu GNOME "Missing icon for new bug report" [Medium,Triaged] https://launchpad.net/bugs/1422176
<aeoril> Also, when I do the merge proposal, I am assuming I fill in "lp:apport" ...
<aeoril> (just making sure before I do all this)
<hjd> aeoril: When you create a merge proposal, it should pick the trunk of the project as default, unless you specify something else. (So yes, lp:apport will likely be the default option)
<aeoril> hjd what I am really not sure about is the push command though - does that appear correct for lp:apport? bzr push lp:~aeoril/apport/apport
<aeoril> (and thanks :
<aeoril> :)
<aeoril> not sure about the "double apports"
<aeoril> Sorry about all the typos - it is cold here - at least I hope it is just that!
<hjd> aeoril: I understand your question. To break it down a bit, it's really lp:~username/project/branchname. So it will store the branch under your username, but know that it is linked to a particular project (I would guess this is the part that makes it turn up on https://code.launchpad.net/apport) and the last part is basically some descriptive name so that you (and others) can see what the branch is about. For instance
<hjd> ~username/apport/fixes-typos or ~username/apport/stop-crashing-on-startup
<hjd> aeoril: Does that make sense? :)
<aeoril> hjd oh, yes - I remember now from my first bug - yes, of course - so, for my fix, a good push command would be "bzr push lp:~aeoril/apport/fixes-bug-1422176"
<aeoril> thanks!  I had already forgotten!
<aeoril> hjd you explained it very well.  Thank you.
<hjd> aeoril: You're welcome. Yes, that branchname sounds good.
<aeoril> hjd ok, cool!
<hjd> aeoril: Did you push your changes? :)
<aeoril> hjd no, not yet - I am hunting around for the code I fixed for my first bug - lp: #1422113 to see what exactly I did with it, but cannot find it yet - it has been committed, but I am not having much luck finding the actually code diffs and stuff and how I phrased the commit message, etc. on launchpad - very frustrating!
<ubottu> Launchpad bug 1422113 in ubiquity (Ubuntu Vivid) "Missing complete icon" [Medium,Fix committed] https://launchpad.net/bugs/1422113
<aeoril> hjd I guess the merge proposals "disappear" once they are accepted and integrated?  I viewed all the merge proposals on lp:ubiquity, and did not find mine
<hjd> aeoril: Yes closed ones are hidden. But fear no, if you go to you user page, and look under "Code" you should be able to toggle branches with any status which you have added to Launchpad. You should find it there.
<aeoril> hjd ok, will do
<hjd> aeoril: Another small trick is, on the branch page, you can click to link it up to a bug report. Then it will appear just below the description and tags (included the related merge proposal. This makes it easier to find, and also let's other people see that someone has a suggested fix for the issue in question. :))
<aeoril> hjd doesn't "bzr commit --fixes lp:1422176" do that?  That is what I have been doing, and what I am about to do with this bug in my local repo before pushing ...
<aeoril> but, I saw that link to click you are talking about previously - I thought that bzr commit option did that though
<hjd> I'm not familiar with the --fixes option, so I'm not actually sure what it does. The ubiquity-bug you linked to only lists lp:ubiquity under Related branches, though.
<aeoril> hjd ok, I pushed the branch.  Looks ok to me:  https://code.launchpad.net/~aeoril/apport/fixes-bug-1422176
<aeoril> hjd darkxst ok, I linked the branch to the bug like you taught me, then did the merge proposal.  I hope the reviewer finds it acceptable!
<aeoril> hjd - nice!  I see the "related branches" links now under the bug report - thanks! :)
<hjd> aeoril: Yes, looks good.
<aeoril> hjd cool, thanks for the help - my second one! :D
<hjd> aeoril: Yes, it shows up there now. You may also want to change the status of the bug report to "In progress" and assign it to yourself to indicate that the bug is being actively worked on.
<aeoril> hjd I can actually just do that?
<aeoril> I figured I would have to have some kind of special status or something ...
<hjd> No, there's only a couple of statuses are restricted (Triaged and Won't Fix, see also https://wiki.ubuntu.com/Bugs/Bug%20statuses).
<hjd> It's a good habit to always leave a comment when changing status to explain why it was changed though. And if in doubt which status applies, just ask :)
<aeoril> hjd I see that there are two places I can change the status - one for "Ubuntu GNOME" and one for "apport (Ubuntu)" - the Ubuntu GNOME was in "triage" so I changed it, but not sure if I should change "apport (Ubuntu)" since it is still "new" ...
<aeoril> Unfortunately, I did not leave a comment - can I fix that?
<hjd> Sure, it's just like leaving a normal comment at the end.
<hjd> I don't know if Ubuntu GNOME has a specific workflow, but if you read the wikipage I linked to about the statuses above, things should hopefully become a bit clearer.
<hjd> (I know there's a diagram showing how a bug goes from one status to the next, but couldn't find it right now)
<aeoril> hjd ok, i'll read the link - right now I am going to take a break because I this process is still nerve wracking for me since I am new!
<darkxst> aeoril, looks good
<aeoril> darkxst thanks! :)  My second one!
<hjd> aeoril: No problem. Just take it gradually, it can be a lot to digest all at once. :)
<aeoril> darkxst would you still suggest looking at that second one you gave me along with this one as my third?
<darkxst> aeoril, we mainly use the ubuntu GNOME project for milestone tracking (so they show up here https://launchpad.net/ubuntu-gnome/+milestone/vivid)
<darkxst> aeoril, yes, that would be a good introduction to using quilt ;)
<aeoril> darkxst ok, will do - if you have the bug number off the top of your head, could you give i to me again?  It will save me from having to look in my IRC logs ...
<aeoril> why can't I type anymore?????
<darkxst> bug 1425349
<ubottu> bug 1425349 in mutter (Ubuntu) "Don't pass configure events on the composite overlay window to MetaStackTracker (aka: STACK_OP_RAISE_ABOVE: window not in stack)" [Medium,Triaged] https://launchpad.net/bugs/1425349
<aeoril> I'll blame it on my keyboard...
<aeoril> darkxst cool, bookmarked - now for a break!
#ubuntu-devel 2015-03-01
<doko> jtaylor, fyi, https://bugs.launchpad.net/ubuntu/+source/python-scipy/+bug/1426841
<ubottu> Launchpad bug 1426841 in python-scipy (Ubuntu) "python-scipy autopkg test fails in vivid" [Undecided,New]
<doko> any idea?
<aeoril> darkxst I did this for bug 1425349 :  https://gist.github.com/aeoril/45d72cf33fdccfae4df3  It said it was out of date, but he revision I branched seems to be newer - did I do that correctly?
<ubottu> bug 1425349 in mutter (Ubuntu) "Don't pass configure events on the composite overlay window to MetaStackTracker (aka: STACK_OP_RAISE_ABOVE: window not in stack)" [Medium,Triaged] https://launchpad.net/bugs/1425349
<aeoril> darkxst oh, I guess the branch I downloaded is older - version 3.2 vs. branch 3.14
<aeoril> darkxst not sure how to get the right branch then
<mitya57> aeoril: UDD branch for gnome-shell is outdated, see http://package-import.ubuntu.com/status/gnome-shell.html
<mitya57> There is lp:~ubuntu-desktop/gnome-shell/ubuntu but it also looks abandoned :(
<mitya57> So if you want to submit a patch, you will have to use traditional techniques
<mitya57> Oh, you were needing mutter, not gnome-shell... But no much difference: http://package-import.ubuntu.com/status/mutter.html
<darkxst> aeoril, use pull-lp-source and create a debdiff with the fix for mutter
<aeoril> darkxst oh, reading about I see pull-lp-source pulls the latest version - I had thought it would pull the version in my distro.  I had already thought of that, but thought it would not pull the latest.  Thanks.
<aeoril> darkxst I seem to be missing something - code already seems updated in latest Ubuntu mutter code:  https://gist.github.com/aeoril/8f00a26d369fec544330
<aeoril> darkxst you mentioned quilt - is there something other than updating this code that needs to be done with patches somehow?
<aeoril> darkxst oh, am I to apply these new Ubuntu changes upstream?  Is that what this is all about?
<aeoril> I guess in debian?
<aeoril> (not upstream - they are already in gnome - but in debian?)
<aeoril> well, new gnome changes ...
<darkxst> aeoril, ok, I didnt actaually check that was already there
<darkxst> clearly that commit does not fix this bug
<aeoril> darkxst yes, I was thinking that ... :)
<darkxst> quilt is used to apply upstream (or custom) patches via packaging
<darkxst> patches go into debian/patches/ folder
<aeoril> darkxst upstream -> quilt -> Ubuntu right?  In that direction?
<darkxst> no quilt is a tool, used to add patches to an Ubuntu package
<aeoril> darkxst yes, sorry for my unclear visual - that is what I meant ...
<aeoril> (I have already read about quilt some)
<darkxst> aeoril, yes
<aeoril> darkxst I was just trying to show "quilt is a tool that applies upstream (or custom) patches via packaging *to* ubuntu" - verifying the direction (ie, quilt is not used to apply Ubuntu patches to upstream, if that even ever makes any sense)
<aeoril> darkxst I am sure this bug is too much for me then, at this stage ...
<aeoril> (if the fix is not known)
<aeoril> darkxst unless I am hunt around for a different commit for the fix?
<aeoril> bisecting and whatnot again ...
<darkxst> aeoril, if its even fixed
<darkxst> I actually don't see it here even on 3.14 (well I have a few but not exactly flooded)
<aeoril> darkxst wouldn't it be more appropriate to give it to upstream to fix then, if it is not fixed?
<aeoril> (I learned from my first bug try how difficult things can get)
<darkxst> aeoril, I wouldn't worry about it, only linked it since it looked like it was an easy fix
<aeoril> darkxst ok - if you have any other good ones for me, just let me know.  Thanks!
<darkxst> aeoril, see https://launchpad.net/ubuntu-gnome/+milestone/vivid
<aeoril> darkxst ok, cool - will do ... :)
<darkxst> aeoril, bug 1315442
<ubottu> bug 1315442 in gdm (Ubuntu) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] https://launchpad.net/bugs/1315442
<aeoril> darkxst I was looking at the bugs in the link you gave, but you seem to have given me another nice one!  Thanks! :)
<aeoril> darkxst bug 1315442 appears in trusty, but the code is redone in vivid and the bug no longer appears to happen - line 79 no longer refers to the same code, and testing has no problem in Ubuntu GNOME vivid - this is just booting off a liveCD in a vm from around 02/27/2015.  the trusty I tested was ubuntu, the vivid I tested was Ubuntu GNOME, however - should I go ahead and thoroughly check
<aeoril> from trusty forwards?  (Ubuntu 14.04, Ubuntu/Ubuntu GNOME 14.10, Ubuntu 15.04) - it looks like it just needs to be fixed for 14.04[.x] and maybe 14.10 but may be OK for vivid ... would the script be different for Ubuntu GNOME vs. Ubuntu regular?  If you don't know, I can go ahead and load up in various VMs and see.  Also, where would that script live on launchpad?  I did not find it in
<aeoril> the source directory when I branched from lp:gdm???
<ubottu> bug 1315442 in gdm (Ubuntu) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] https://launchpad.net/bugs/1315442
<aeoril> darkxst I re-verified problem/fix worked in trusty Ubuntu GNOME though
<aeoril> (my vivid test was a daily build for vivid Ubuntu GNOME from around 2/27/2015 in a vm)
<aeoril> darkxst I guess I need to do all that testing and see when the bug went away, but I would really like to know where to get my hands on the script from launchpad - I have no idea at this point
<darkxst> if its fixed in vivid, then it atleast needs to be fixed via SRU to trusty
<darkxst> the file is in the debian folder of gdm package
<darkxst> aeoril, except it isnt fixed in vivid yet
<darkxst> so you would fix in vivid, then SRU to trusty
<aeoril> darkxst I tried in vivid from the live cd - it did not seem to have the problem???
<darkxst> the syntax error is definitely there though
<aeoril> darkxst the code isn't even the same in that area ...
<darkxst> its just a different line number
<aeoril> really?  I counted the then/fi's - I can check again ...
<aeoril> darkxst maybe I was in the wrong place ...
<aeoril> darkxst gosh darn it!  I was looking down a little - no wonder the code looked all different!  Yes, will fix - where does that script live where I can fix it on launchpad?  What source package or branch do I use?
<aeoril> (it is not in the gdm source from what I could grep)
<darkxst> pull-lp-source gdm
<darkxst> its in the debian folder
<aeoril> darkxst hmmm ... I did "bzr branch lp:gdm" - I'll do that instead
<darkxst> aeoril, many of the udd branches are dead and/or broken
<aeoril> darkxst so, I should generally use pull-lp-source?
<aeoril> not bzr branch?
<darkxst> aeoril, well if the bzr branch is upto date that is fine to use
<darkxst> if the package lists a Vcs-bzr in control then you should use that branch
<aeoril> darkxst ok, I'll remember that then - do you mean if it has a line in it that says "To get the code use 'bzr branch lp:ubiquity" for instance (paraphrasing) on the launchpad web page?
<aeoril> darkxst or do you mean in debian/control?
<darkxst> aeoril, yes in debian/control
<aeoril> darkxst ok, sure thing - thanks for the tip.  Will do the fix then.
<aeoril> darkxst should I be worried about this? gpgv: Can't check signature: public key not found | dpkg-source: warning: failed to verify signature on ./gdm_3.14.1-0ubuntu2.dsc
<aeoril> (when I did pull-lp-source)
<aeoril> darkxst uggghhh ... no source control!
<darkxst> aeoril, no that doesnt really matter
<aeoril> darkxst but it makes it more painful!
<darkxst> aeoril, why? its a very simple fix, just make a debdiff
<aeoril> darkxst how do I push to launchpad without bzr?
<darkxst> attach a debdiff to the bug report
<aeoril> darkxst oh, ok - so no problem then.  So, just to make sure, 'dhc -i' (add my comment to ChangeLog), (make my code change), 'sudo apt-get build-dep gdm', 'builddeb -S', 'debdiff old.dsc new.dsc > debdiff_name.debdiff', then attach debdiff to bug ... /??
<darkxst> you shouldnt need build-dep in this case, but everything else is correct
<aeoril> darkxst oh, since I am working on trusty, I guess I need to do sbuild before debdiff?
<aeoril> or not?
<darkxst> no
<darkxst> but you should fix vivid first
<aeoril> darkxst so I need to do all this from a vivid vm?  I was going to build on my trusty build machine then scp over the .debs and install on a vivid LiveCD to test ...
<aeoril> hence, sbuild
<darkxst> yes then sbuild it
<aeoril> darkxst do you typically have a vivid vm and do fixes for vivid on it, then have a trusty vm and do fixes on it, have a 14.10, etc?  As opposed to a single machine using sbuild?
<darkxst> aeoril, I build everying in sbuild, then mostly test in vm's
<darkxst> or jhbuild when writing  GNOME patches
<aeoril> darkxst so, that is what I am doing - good to know.  I will continue to do that then.  My sbuild machine is 14.04.1, with various sbuilds for diffferent releases to build/test, then shoot over .debs and install on vms to test
<aeoril> darkxst just as an fyi, I have to stop for today, but should be able to get the fix in and tested for tomorrow.  Thanks.
#ubuntu-devel 2016-02-29
<dragonbite> I have a problem when trying to run the Ubuntu-SDK...
<dragonbite> It comes up with updates available for my kits and the option to select "ubuntu-sdk-15.04-amd64"
<dragonbite> I check it, let it run and get the following error message
<dragonbite> "You might want to run 'apt-get -f install' to correct these. The following packages have unmet dependencies:
<dragonbite> qtdeclarative5-ubuntu-ui-toolkit-plugin : Depends: libubuntugestures5 (= 1.3.1795+15.04.20160106-0ubuntu1)
<dragonbite> E: Unmet dependencies. Try using -f.
<dragonbite> Command returned 100: schroot -u root -c source:click-ubuntu-sdk-15.04-amd64 -- apt-get dist-upgrade --yes
<dragonbite> ---Click exited with errors, please check the output---"
<dragonbite> qtdeclarative5-ubuntu-ui-toolkit-plugin is already installed
<dragonbite> libubuntugestures5 it cannot find  to install
<Son_Goku> does Unity 8 have a hard dependency on Mir, or is that dependency abstracted out through its usage of Qt and QML?
<RAOF> Son_Goku: I think it's still capable of being run without Mir, yes.
<RAOF> There was certainly a time where you could run a Unity8 session under X11; I don't think we're making any particular effort to preserve that, though, so it might not work anymore :)
<hallyn> hm, so both 'shut down' and 'restart' from the menu lead to the same popup with the two 'restart' and 'shut down' options
<pitti> Good morning
<cpaelzer> good morning
<slangasek> morning ;)
<ginggs> Pharaoh_Atem, nacc: I sync'd pcre3 from Debian. Is someone going to look at php?
<slangasek> ginggs: once pcre3 has been built in xenial-proposed, we can try to build https://launchpad.net/ubuntu/+source/twig/1.23.1-1ubuntu3/+build/9275887 again and see if it's fixed
<slangasek> pitti: problems creating nova instances for ppc64el autopkgtests this morning? http://autopkgtest.ubuntu.com/running.shtml
<pitti> slangasek: yes, see #is
<slangasek> ok :)
<pitti> slangasek: buildds are down too
<pitti> slangasek: I just filed bug #89226
<ubottu> bug 89226 in tracker (Ubuntu) "Please sync tracker 0.5.4-4 from debian unstable main" [Wishlist,Fix released] https://launchpad.net/bugs/89226
<pitti> slangasek: err, RT #89226
<slangasek> pitti: got it, thanks
<pitti> I suppose they saw the 30.000 test rebuild requests, cried, and died
<slangasek> I don't imagine I should wait up for the test results, then
<pitti> I can temporarily disable ppc64el in britney
<pitti> that doesn't help with getting builds on ppc64el, but might unblock at least some stuff
<pitti> slangasek: force-skiptest php-zend-code> it's more elegant to re-run the test against all of -proposed
<pitti> slangasek: run-autopkgtest --all-proposed [...]; or specify both packages as --trigger, but --all-proposed is simpler
<pitti> as you can just copy&paste it from ALL_PROPOSED=1 retry-autopkgtest-regressions
<slangasek> pitti: oh, you can pass --trigger multiple times; that's the thing I forgot.  Would love to have an example of that on the wiki page :)
<pitti> slangasek: I did document --all-proposed
<slangasek> yeah, but I don't like --all-proposed ;)
<pitti> slangasek: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure?action=diff&rev2=57&rev1=56
<pitti> ppc64el autopkgtests temporarily disabled
<slangasek> nacc: looks like phpunit, php-defaults, php7.0 are now wedged in -proposed because of the missing php7.0-zip; what's the plan for getting that restored?
<loop> guys why you do not  write anything?
<loop> anyone is active?
<loop> Guys wake up. I want to share with you my advice and opinion about ubuntu as regular user.
<dholbach> good morning
<loop> yo
<loop> I suggest: Make the new app store (that will operate on the principle of Steam and will be the most important program in the system). With him will could download any application (eg. steam, vokoscreen, audacity ...). There will be no need to add the repo when u want install sth. Only each application exists on Linux will be there to download. Now, after the installation of ubuntu then you have big problems with the installation o
<loop> Go on askubuntu and see how many different problems people have with installing steam (omg: /). Close to ~ 80% of the problems of people with askubuntu is installation problems with the program - which will solve the new ubuappstore. Remember that the majority of users are simple people in matters of IT - as I do. All is more difficult cuz of model-behavior of the system.
<loop> Get rid of the .deb file type and substitute is an  .uni typ file that will be associated with the shop and it will be installed as 2 clicks in windows. You have a problem with the quality and popularity of software, bugs, and causing it lack of the store (model: Play Store, Steam) and install with performance based management system through apt - which are outdated and fit into the shell text.
<loop> To graphical shell fits only app store and the type of executable file .uni. Listen to me and soon show the streamergamers, YouTubers who are you doing free advertising and will promote your free system as for Valve tournaments esports promoted the CS GO which in 2012 was at the bottom. Now it is no. 1 eSports on world. For example look at YT gamers scene in EU at the moment.
<infinity> loop: This not a channel for complaints and walls of suggestion text.
<loop> I leave your system. By the described disadvantages. You want to start gaining users, in first care in order for the players and the people who use specialized software, creators programmed into .uni. I know that the closed software does slowly in digital society  slaves of men, but I will sit on the windows  if you really are idiots and do not see that what i wrote.
<loop> The small things make the difference, and those I have described are enough to your system was popular, like Windows is now popular.
<loop> I leave your chat too bye.
<loop> ban me :)
<dholbach> nobody said they'd like to ban you... this is just not a good way of making yourself heard
<infinity> loop: As a general rule, wandering into a room with a bunch of people and suggesting that they're all idiots if they don't immediately implement your idea is likely not the best way to be heard.
<infinity> loop: For the record, we're toying with new appstore models (see: snappy), and indeed, some third party software will be delivered that way in the near future.
<infinity> loop: You'll be happier to know that we read your comment, were appropriate shamed by your tone, invented a time machine, and started working on it a year ago.
<infinity> s/appropriate/appropriately/
<loop> I ll read about yout work.
<loop> Have politely :) Have fun.
<loop> bb
<dholbach> @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: dholbach
<mapreri> dholbach: fancy syncing libeatmydata ? :)
<mapreri> i did an upload yesterday in debian
<dholbach> mapreri, taking a look
<darkxst> pitti, vmware no longer gets "splash" on the kernel command line, was that intended?
<pitti> darkxst: I don't know, but I doubt that's vmware specifc
<pitti> darkxst: it should be specific to the kind of image (cloud/server/desktop)
<dholbach> mapreri, done
<darkxst> pitti, it happend on installed xenial ubuntu-gnome's
<mapreri> dholbach: â¥
<darkxst> but not on my laptop
<dholbach> :)
<pitti> xnox: hmm, is https://launchpadlibrarian.net/243987535/buildlog_ubuntu-xenial-amd64.upstart_1.13.2-0ubuntu20_BUILDING.txt.gz due to a new coreutils or something such?
<pitti> not ok 38 - with single-line command that writes 1 line to stderr
<pitti> wrong content in file 0x7f0d28045740 (output), expected '0 bytes (0 B) copied,*
<pitti> ' got '0 bytes copied, 2.9651e-05 s, 0.0 kB/s
<ogra_> at least it is fast
<darkxst> pitti, it doesnt seem to affect the live images
<Odd_Bloke> xnox: Does the latest kernel (with its modified initrd handling) mean that we can drop your s390x-specific hack from livecd-rootfs?
<davmor2> cyphermox, seb128: upgrade from 14.04 â 16.04 really hates us, it broke again bug #1551198
<ubottu> bug 1551198 in ubuntu-release-upgrader (Ubuntu) "14.04â16.04 upgrade failed" [Undecided,New] https://launchpad.net/bugs/1551198
<LocutusOfBorg> what did happen to ppc64el buildds?
<cpaelzer> LocutusOfBorg: for ppc64el see this channel around 5h before now between pitti and slangasek as well as #is
<LocutusOfBorg> thansk cpaelzer
<LocutusOfBorg> please seb128 can you retry https://launchpad.net/ubuntu/+source/inkscape/0.91-7ubuntu2/+build/9276902 ?
<LocutusOfBorg> :)
<seb128> LocutusOfBorg, why is there no build log?
<seb128> LocutusOfBorg, retried
<LocutusOfBorg> seb128, ppc64el disabled
<LocutusOfBorg> so it will be retried when they will become online again, and thanks BTW
<seb128> LocutusOfBorg, yw
<seb128> ppc64el disabled? do we know what's the issue?
<LocutusOfBorg> scroll above ^^
<LocutusOfBorg> :)
<seb128> I looked to the logs and I didn't see much useful
<seb128> oh, well, let's wait then
<rbasak> If using dh_install with --fail-missing to better manage a complex package (mysql-5.7), how should we handle files that we deliberately don't want installed? dh_install -X, or some other way?
<rbasak> Also, Skuggen reports that --list-missing is reporting manpages installed correctly by dh_installman, and so needs to explicitly exclude those too.. Is that expected?
<dholbach> @pilot out
<xnox> pitti, looks like it. open a bug and assign to me?!
* 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:
<xnox> Odd_Bloke, possibly, needs testing. I'll spin a rebuild in my ppa and see what happens.
<jibel> stgraber, Hi, could you have a look at bug 1551150? lxc is a primary suspect.
<ubottu> bug 1551150 in Canonical System Image "devel-proposed doesn't boot" [Critical,New] https://launchpad.net/bugs/1551150
<cjwatson> pitti: is ppc64el happier for you now?
<cjwatson> ah yes, the RT was updated too
<pitti> cjwatson: it is indeed, thanks
<pitti> l
<cyphermox> davmor2: it says module-init-tools in unauthenticated, does it come from some other testing?
<davmor2> cyphermox: nope default install of 14.04.4 + updates and then running update-manager -d in atl+F2
<tjaalton> anyone know what changed the default monospace font?
<tjaalton> in xenial
<tjaalton> it's much wider than the old
<rbasak> tjaalton: https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039224.html maybe?
<tjaalton> rbasak: exactly
<tjaalton> before I had a split terminator instance with four columns, 125+94+94+94 wide (roughly). Now they are 125+94+64+64..
<tjaalton> unusable :/
<tjaalton> smaller font size is not an option
<pitti> xnox: I pushed http://bazaar.launchpad.net/~ubuntu-core-dev/upstart/ubuntu/revision/1628 now, this seems to work fine
<xnox> pitti, cool!
<pitti> xnox: while I'm at it, do you have an idea about that flaky test:
<pitti> not ok 26 - with single-line script that is killed
<pitti>  wrong value for WIFSIGNALED (status), expected TRUE got FALSE
<pitti>  at tests/test_job_process.c:1760 (test_start).
<pitti> 1..153
<pitti> FAIL: test_job_process
<pitti> xnox: this seems to fail in most autopkgtset runs
<pitti> and currently we force-badtest the entire thing, which is a shame
<pitti> as we don't hear about other regressions that way
<xnox> pitti, yes -> it is possible that a short lived process exits faster than we manage to kill it, and catch the signal.
<pitti> xnox: would it be okay to disable that particular test for now, so that the others become useful again?
<xnox> i wonder if we should "loop" / re-attempt the test a few times before giving up.
<xnox> ok.
<pitti> xnox: I think the rest of the test is okay, so http://paste.ubuntu.com/15244176/
<xnox> doko, please RM unity-scope-snappy as per bug #1542451 which also fixes bug #1542376 and bug #1534346
<ubottu> bug 1542451 in unity-scope-snappy (Ubuntu) "RM: unity-scope-snappy" [Critical,Triaged] https://launchpad.net/bugs/1542451
<ubottu> bug 1542376 in unity-scope-snappy (Ubuntu) "invalid golang-go.tools Built-Using dependency generated" [Critical,Confirmed] https://launchpad.net/bugs/1542376
<ubottu> bug 1534346 in unity-scope-snappy (Ubuntu) "FTBFS with golang-go 1.6 beta2" [Undecided,New] https://launchpad.net/bugs/1534346
<xnox> pitti, yeap, looks good.
<pitti> xnox: thanks
<nacc> ginggs: hey, pcre3 question for you, when you have a moment
<ginggs> nacc: just ask
<nacc> ginggs: ok, we've deduced that the twig testsuite is failing with php7 due to a pcre bug. Thanks to Pharaoh_Atem's debugging with the SCL maintainer, we know that FC23 doesn't have this problem, but both SCL and Ubuntu do. I'm trying to understand how Debian/Ubuntu pull in the fixes normally? There are a lot of upstream bugfixes since 8.38 that Debian & Ubuntu seem to be missing. I just noticed you did
<nacc> the last merge, and wasn't sure if you had more context.
<ginggs> nacc: i would say normally fixes come in upstream releases, which get packaged in debian and then make their way into ubuntu. sometimes, a bug may be filed in debian (e.g. debian #815921) and it may be important enough for the maintainer to upload a new debian release.
<ubottu> Debian bug 815921 in src:pcre3 "pcre3: workspace overflow for (*ACCEPT) with deeply nested parentheses" [Important,Fixed] http://bugs.debian.org/815921
<ginggs> nacc: do you know which bug it is? http://vcs.pcre.org/pcre/code/trunk/ChangeLog?view=markup
<nacc> ginggs: ok, thanks -- I figured that was the case, but wasn't sure, I might just have hit a window where the debian bug wasn't fixed yet.
<nacc> ginggs: sadly not yet :/ i'm trying with all of fc23's patches applied just to get a bseline, but i know it's just not the abvoe-mentioned issue
<nacc> ginggs: it's something to do with the jit (as if we disable pcre.jit in PHP, it goes away)
<nacc> ginggs: the tricky part is i have to rebuild php7 to test :)
<seb128> bdmurray, you said that https://code.launchpad.net/~seb128/software-properties/newtab-enable-proposed/+merge/286626 looked fine to you, could you comment on it saying so?
<bdmurray> seb128: Yep
<seb128> bdmurray, thanks
<jderose> cyphermox: so i'm taking a stab at https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1508865 today... sometime during the 15.10 cycle this was introduced. something is different about how the first-run DM is setup compared to the normal installation DM... any ideas?
<ubottu> Launchpad bug 1508865 in ubiquity (Ubuntu) "oem-config: networking not enabled during user config" [High,Confirmed]
<jderose> cyphermox: i've been looking the the changes in bzr, but nothing has stood out to me yet
<xnox> jderose, the networking page steps got re-arranged, maybe that affected things?! (e.g. the step that oem-config starts from should be like -1 or some such?!)
<xnox> jderose, however i thought networking is generally not enabled at all during user config.
<jderose> xnox: it used to be, because that's how ubiquity could guess your timezone using your IP
<xnox> ok.
<jderose> xnox: happen to know where in the ubiquity code said networking setup happens?
<xnox> it's a separate page/plugin.
<xnox> a stand-alone file i believe.
<cyphermox> jderose: what do you mean by "DM" ?
<ginggs> cjwatson: where can I find the specs of the powerpc buildds sagari, denneed* and fisher* please?
<jderose> cyphermox: my terminology might be wrong... i'm looking at, for example, bin/ubiquity-dm
<cyphermox> this isn't a new change; oem-config needs to get rid of any oem-specific networking config; NM would re-write new config files as necessary
<cyphermox> but I see what might be wrong
<cyphermox> for wired you probably need to go an click on nm-applet and pick the wired device for it to connect, and it's not doing so automatically
<jderose> cyphermox: i do recall a bug about prepare for shipping to end user should delete stuffs in /etc/NetworkManager/system-connections/... could that have resulted in networking being completely disabled during the user first-run?
<cjwatson> ginggs: What in particular are you trying to figure out?
<cyphermox> not disabled, but NM gets confused because "Ethernet 1" gets deleted and it won't just automatically recreate it, because reasons
<jderose> cyphermox: in my experience, th nm applet is only shown when on wifi... otherwise it silently connects to ethernet without displaying the nm applet
<ginggs> cjwatson: still trying to figure out the openmpi failures with powerpc LP: #1550863 / Debian #814183
<ubottu> Launchpad bug 1550863 in petsc (Ubuntu) "openmpi 1.10.2 is broken on powerpc" [Undecided,Triaged] https://launchpad.net/bugs/1550863
<ubottu> Debian bug 814183 in src:openmpi "openmpi 1.10.2 is broken on powerpc" [Serious,Open] http://bugs.debian.org/814183
<jderose> ubiquity also no longer prompts to connect to wifi during the user first-run
<cjwatson> ginggs: they're all POWER7; sagari is bare metal, denneed*/fisher* are VMs
<cyphermox> jderose: no, the applet should always show
<cyphermox> jderose: wifi should not try to connect automatically to anything
<cjwatson> ginggs: the usual relevant difference is that sagari has something like 15GB of RAM while the VMs have somewhat less (don't know exactly how much)
<cjwatson> ginggs: for more details ask infinity
<jderose> cyphermox: it didn't do it automatically... when there was no ethernet, it would prompt you to connect to wifi. it still does this during the initial install, but doesn't anymore during the first-run user config
<cyphermox> I'm not sure it ever did in the oem context
<ginggs> cjwatson: thanks (again)
<cyphermox> but that should be easy enough to fix
<cjwatson> ginggs: (something more like denneed*/fisher* should be considered future direction, though we can adjust available RAM a bit just as we recently did on ppc64el)
<cyphermox> jderose: I'll look as soon as I'm done eating lunch :)
<jderose> cyphermox: i'm 100% certain it used to do this during the oem first-run user setup. this is a bug that flexiondotorg found just prior to the 15.10 release during his ISO testing
<ginggs> cjwatson: I was just looking for a pattern, in Debian it appeared that things FTBFS on POWER8, but built on PPC970FX
<jderose> cyphermox: no rush, enjoy your lunch! :)
<jderose> cyphermox: just confirmed to make sure i'm not talking crazy... when no ethernet is plugged it but you have a wifi card, 14.04.4 prompts you to join a wifi network during oem first-run user config on the 2nd page; 15.10 and xenial go directly to the timezone selection page, without networking enabled
<nacc> ginggs: another question, if you happen to know, does libpcre3 allow for runtime disabling of JIT?
<cyphermox> jderose: sounds like maybe the network screen crashes when running in oem
<cyphermox> jderose: that would show up in /var/log/syslog, or /var/log/installer/debug (or /var/log/ubiquity/debug, I think)
<jderose> cyphermox: for wired, 14.04.4 automatically connects to the network, but doesn't show the nm applet; 15.10 and xenial never show the nm applet, neither for wireless nor weired
<jderose> okay, i'll check the logs...
<cyphermox> well, much of this is wrong then, nm-applet should always show
<cyphermox> jderose: please file bugs for each different thing, and I'll get to them as soon as I can
<nacc_> Pharaoh_Atem: hrm, so i built a version of pcre3 that compile-time had jit disabled. still get a segfault unless i tell php pcre.jit=0 (which all it does is not call pcre_study, afaict).
<ginggs> nacc_: don't know, sorry
<vooze> Hello dear devs ;) I have reported this bug, but I can't figure what what package is responsible to setting the wallpaper. https://bugs.launchpad.net/ubuntu/+bug/1550815 - The issue is it changes the colors on the wallpaper from the original image
<ubottu> Launchpad bug 1550815 in Ubuntu "Wallpaper changes colors?" [Undecided,New]
<nacc_> ginggs: np, i'm figuring it out as i go ... it is a pcre bug, but i think one that may not yet have been found upstream (as i can reproduce it with the latest svn)
<nacc_> Pharaoh_Atem: --^ which is confusing to me that fc23 works at all
<nacc_> Pharaoh_Atem: fc23 doesn't happen to use the php7 src pcrelib, does it?
<nacc_> Pharaoh_Atem: but in more positive news, i've reduced the twig segfault to a one line change in the testcase, so i know *why* it's failing (as in what particular test in the testcase)
<cjwatson> nacc_: sorry if you've talked about this already, but I keep seeing you talking about pcre3, is there a reason you aren't using the (newer!) pcre2?
<cjwatson> if upstream only works with pcre3 then that's a valid reason of course
<Pharaoh_Atem> nacc_: that's awesome
<Pharaoh_Atem> and horrifying
<Pharaoh_Atem> maybe Fedora is optimizing out the issue with its more aggressive gcc flags?
<Pharaoh_Atem> cjwatson: someone needs to kill that soversion mutation in Debian for pcre
<Pharaoh_Atem> it *should* be pcre1
<ginggs> Pharaoh_Atem: hopefully pcre3 will disappear soon, and then we'll only have pcre2
<dobey> hmm, why is "do-release-upgrade -d" complaining that it can't authenticate module-init-tools from us.archive.u.c on my laptop?
<nacc_> cjwatson: php7 only supports building against pcre3 (afaict) ... i guess i could try and move the build-dep, but i think that's how upstream is too
<dobey> vooze: what ubuntu is that?
<vooze> dobey: on the images: ubuntu 14.04 (unity) but I have found the "bug?" in Linux Mint, Ubuntu Gnome 15.10, Ubuntu 16.04 and Xubuntu as well.
<nacc_> Pharaoh_Atem: it could be ... it does sound like php & pcre have had issues int he past, i'm filing a pcre bug now to see if they can help debug
<dobey> vooze: what resolution is your screen?
<vooze> dobey: 1920x1080 on laptop and 2560x1440 on desktop (bug present on both)
<vooze> Also Laptop uses Intel GPU and Desktop Nvidia
<dobey> vooze: nautilus is what renders the background; i moved the bug there; but when i open the image in eog on my computer, it is not as orange as you claim it should be
<cjwatson> Pharaoh_Atem: about a decade too late
<cjwatson> Pharaoh_Atem: no point going through a painful transition when we want to end up on pcre2 anyway
<vooze> dobey: maybe a different color profile (or just different tuned monitor?) Would it be possible for you to set it as wallpaper while having it open in eog to see if there is a difference?
<dobey> vooze: this is intel with a dell 4k monitor that is 100% rgb
<vooze> It is different from image to image "how much" it changes I think. That is just the "best" image I could find to show the difference.
<vooze> dobey: okay. Could you possible try to apply it as wallpaper? Also thanks for taking the time to help me.
<dobey> vooze: for me it seems slightly more orange there when applied as a wallpaper; perhaps due to a different scaling method used for the background, versus for eog
<dobey> granted, i also have redshift running
<vooze> dobey: Could be. But at least now the bug is open and maybe some nautilus-devs? (But thats gnome devs I guess? Can take a look at it. Otherwise I will just have to wait for Unity 8 :)
<vooze> Maybe that will handle it differently with mir.
<dobey> well, if you want gnome devs to look at it, probably also needs to be forwarded upstream
<vooze> dobey: Well, I checked on Ubuntu Gnome and the issue is there as well, so could not hurt I guess.
<vooze> dobey: is this something I can do from the bugtracker on launchpad or should I post elsewhere and link it on launchpad?
<dobey> i don't recall the exact procedure for pushing bugs upstream, sorry
<dobey> ask in #ubuntu-bugs perhaps
<vooze> dobey: Okay, I will try to figure it out. Thank you again for your time.
<stefanct> hm, is there a lp: containing the xenial package that i can use for a nest-part packaging directive in a recipe?
<stefanct> i have seen lp:debian/sid which is almost as good, but referring to the "real" thing seems better
<cjwatson> not in general, the bzr importer was creakingly bad and we haven't turned it on for xenial
<dobey> stefanct: there are no source imports of xenial packages, no
<dobey> ah i see cjwatson is still here :)
<cjwatson> I'm three hours west of usual this week
<dobey> ah
<dobey> at the ols sprint?
<cjwatson> yep
<stefanct> ok thanks
<dobey> cool. bet the weather is nice there :)
<sarnold> coreycb: congratulations :)
<coreycb> sarnold, thanks!
<slangasek> nacc_: hi, did you see my follow-up on bug #1549942 yesterday?
<ubottu> bug 1549942 in php-imagick (Ubuntu) "php-imagick failing autopkgtests" [Low,New] https://launchpad.net/bugs/1549942
<slangasek> nacc_: I believe that's the last blocker for getting php7.0/phpunit/php-defaults migrated now
<stefanct> is there an easy way to exclude a directory (e.g. debian/patches) when using nest-part?
<ScottK> caribou: If you care about armv5 at all (not sure if Ubuntu does, but its derivatives might) you should definitely merge clamav again.
<teward> ScottK: I don't think there's any Ubuntu supporting anything less than armv7 right now?  Unless I misread the architectures documentation
<ScottK> I think that's right, but I don't know about derivatives.
<ScottK> That or sparc, which is definitely at most a derivative's concern.
<teward> ScottK: i hate to be argumentative, but with Xenial sparc's not even on our arch list - at that point would it not be up to the derivatives alone to provide support/fixes for those patches?  (And I am excluding officially recognized flavors of *buntu from "derivatives")
<teward> s/our arch/the arch/
<teward> (basically, how much do we need to provide support for unsupported archs for derivatives)
<teward> my two cents though, i have no say ultimately :)
<ScottK> Since Debian's already fixed the bug and all it takes is a merge, meh.
 * teward shrugs
<Pharaoh_Atem> cjwatson: then someone should probably port php to use pcre2 :/
#ubuntu-devel 2016-03-01
<nacc_> Pharaoh_Atem: i found an open bug about it, i think
<nacc_> slangasek: sorry, was working through my backlog, will look at that now
<Pharaoh_Atem> nacc_: oh?
<nacc_> slangasek: right and then we'll need to fix php-imagick :) which i have a diff for but am still working w/ debian on ... i'll test now with that patch backported and update the bug
<nacc_> Pharaoh_Atem: yeah ... php-general post, actually
<nacc_> Pharaoh_Atem: http://grokbase.com/t/php/php-general/15bgdvqds0/any-roadmap-for-php-with-pcre2-version-support
<nacc_> Pharaoh_Atem: but it will require "porting" as I don't think they are API compatible
<smoser> anyone able to help.
<smoser> having an issue with tox and setuptools on xenial
<smoser> http://paste.ubuntu.com/15249068/
<smoser> the same thing works fine on trusty
<smoser> hm..
<smoser> well sort of good news. only fails on my development environment. not in a fresh container
<nacc_> slangasek: php-imagick is at least running the tests now, trying to get it to pass them, then will post debdiff
<smoser> wonder what could have done that .
<smoser> bah. thank you for fixing my problem before i came upon it barry.
<smoser> python-virtualenv: d/patches/use-wheels.patch: Also install _markerlib in the virtual environment.
<sarnold> infinity: 1551522 is yet-another-dpkg "already installed and configured" bug, but the logs show some ~40 packages with this error -- I point this one out because I'm hopelessly naive and wonder if _this_ is the bug report that will explain all the others :)
<infinity> sarnold: If you see anything attempting to configure more than once in the log, it's an apt bug, not a dpkg bug.  And some day, maybe we'll figure out how to unwind it.  It's Hard(tm).
<sarnold> infinity: hmm does that mean the thousand-odd dpkg bugs on this should be retargeted? :) (not volunteering to do it :)
<infinity> sarnold: Probably, yes.
<infinity> sarnold: I suppose one could consider a dpkg workaround, where it ignores requests to configure already-configured packages, but the bug is definitely that apt is asking it to do that when it shouldn't.
<sarnold> that might be a good idea even if it is somewhat unsatisfying
<infinity> sarnold: Yeah, I'm trying to decide if that would potentially break anything.
<sarnold> if only we had some kind of reproducer that we could test with .. :)
 * sarnold wishful thinks his way to dinner
<infinity> sarnold: Should certainly not be silent, at any rate, you still want to know that your higher level package manager is being stupid, but perhaps turning the error into a warning with a 0 exit code would be acceptable.
<sarnold> infinity: *nod* agreed on both counts
<sarnold> thanks infinity :) have a good night
<infinity> sarnold: If you can ever create a rootfs with an actual reproducer for the apt issue, I'd love to see it.  I've literally never seen this in wild, nor been able to reproduce it locally.  The bugs are, indeed, real, but by the time they've been filed, the systems no longer are in a reproduction state, so...
<infinity> Obviously, reproducing the dpkg behaviour is simple (dpkg --configure libc6), but tracing the stupid apt decisions that get there without manual intervention is tough.
<juliank> sarnold: That looks like an aptdaemon bug. It apparently calculated the transaction while the other transaction (the apt install) was still ongoing.
<juliank> So, it saw those packages as unconfigured at that point and thus scheduled configure calls
<infinity> juliank: Feel free to reassign if you understand it.  I *think* we've seen logs with just pure apt tripping on the same thing too (ie: in N dpkg runs, where N > 1, apt seems to sometimes try to --configure something it already configured in a previous run)
<pitti> Good morning
<cpaelzer> good Morning
<pitti> infinity: what's the usual  buildd timeout? https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu21 ppc64el and s390x have been building for 15 hours and did not make any progress
<pitti> I already cancelled a stuck s390x yesterday and restarted it, but it got stuck at the same place again
<pitti> ppc64el is stuck at 'dpkg-buildpackage: binary-only upload (no source included)', hmm
 * pitti cancels them
<infinity> pitti: It's got a hung dbus from the failed testsuite that hasn't cleaned up.  I'll just kill it so the build can fail gracefully.
<pitti> infinity: ah thanks, ppc64el built now
<pitti> s390x still failed, but is also hung
<infinity> pitti: Yeah, that's the one I cleaned up just now.
<infinity> pitti: Good thing the s390x maintainer also happens to be an upstart hacker. :P
<infinity> xnox: ^
<pitti> ah, so ppc64 built by itself this time
<dholbach> good morning
<cpaelzer> Hi, I didn't find an explicit statement about it in the Debian policy or on Ubuntu pages - but I guess for init scripts and such we prefer spaces before tabs right?
<cpaelzer> because the files I have here are mixed and I want to unify it to one or the other
<rbanffy> Good morning. What would it take to update http://packages.ubuntu.com/xenial/fonts/fonts-3270 to the same release as upstream (v1.2.11)?
<seb128> hallyn, arges, jamespage, hey, you have your names on the libvirt package, do you know why we divert from Debian on binary names? like why we don't have a libvirt-daemon?
<seb128> other packages depwait on libvirt-daemon(-system)
<infinity> cpaelzer: There's no Debian or Ubuntu coding policy, generally you want to match the style of your upstream project.  Or, if writing init scripts from scratch, perhaps match /etc/init.d/skeleton
<smb> seb128, because we did in the past when there was no such thing and now we did not want to change just before a stable release (libvirt)
<seb128> smb, should we maybe have libvirt-bin to Provides the new names?
<seb128> or we can delete the few things depwaiting in proposed, since it seems the updates are mostly Depends libvirt-bin -> libvirt-daemon
<smb> seb128, I might add that in parallel for the next upload
<seb128> e.g https://launchpad.net/ubuntu/+source/gnome-boxes/3.18.1-1.1
<seb128> smb, thanks for the replies!
<cpaelzer> infinity: thank you the  /etc/init.d/skeleton hint will be the one I chose
<smb> seb128, yw. Thanks for bringing it up. I guess for the transition phase it will be good to have both. Do you know whether there is already a bug report filed about it that I should refer to?
<seb128> smb, not afaik, but I can open on if you want
<smb> seb128, Oh I can do that myself, just in case there already were one open. Not strictly require one but given the interrupt driven workflow I better have some reminder. :)
<seb128> right, no bug open that know about then :-)
<tjaalton> hmm, upgraded to xenial and now can't run sudo inside schroots: "sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?"
<xnox> infinity, all i did last year for upstart is try to push ChromeOS & Ubuntu Touch to stop using upstart.... =)
<xnox> infinity, would you like a glibc bug for s390x? =) https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1549850
<ubottu> Launchpad bug 1549850 in bsdmainutils (Ubuntu) "ncal crashes with segmentation fault" [Undecided,Confirmed]
<xnox> infinity, however probably not glibc bug
<xnox> infinity, nope not a bug.
<Saviq> pitti, hey, we've come upon a problem with britney - we can't locally reproduce a test failure that happens there reliably, is there a way we could get access to a node similar to what britney uses?
<pitti> Saviq: yes, should be; which arch?
<Saviq> pitti, amd64
<pitti> Saviq: I can run the test manually with --shell, let it fail, and give you ssh to that instance
<pitti> Saviq: which package/trigger?
<Saviq> pitti, that would be great, sec
<Saviq> pitti, the unity8 one in https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-064/excuses.html
<pitti> Saviq: ah, so that might be hardware/mir specific?
<Saviq> pitti, no
<Saviq> pitti, it's all under xvfb
<Saviq> pitti, but let's hold on, we might've just thought of a solution
 * pitti has some difficulty finding the actual failure in the log
<Saviq> pitti, grep for fail!
<pitti> ah, thanks
<smoser> pitti, if you want to review https://code.launchpad.net/~smoser/cloud-init/trunk.lp1543025/+merge/287682
<smoser> it seems to work for me.
<infinity> "The copy was due to an old bug in Ubuntu" <-- revisionist history by Lennart? :P
<infinity> (it wasn't a bug, it was intentional)
<dobey> is there something wrong with module-init-tools in xenial (or trusty)? i keep having do-release-upgrade -d failing with a complaint that module-init-tools can't be authenticated
<infinity> dobey: It doesn't exist.
<infinity> Oh, it does exist still, but it's NBS and needs removing.
<infinity> Once nothing depends on it anymore.
<dobey> oh
<xnox> smoser, infinity: huh?! symlink from /etc -> usr. That clearly is a good idea(tm).
<smoser> pitti told me to do it.
<xnox> ok
<smoser> if thats not right i can change it.
<xnox> pitti, do we have tzdata shipping in /lib with compat symlinks from /usr/share -> /lib ?
<smoser> that is what timedatectl does. and also dpkg-reconfigure tzdata
<smoser> so cloud-init is not any worse than anything else.  which is always what i strive for :)
<sarnold> :)
<pitti> right, so this makes the localtime handling consistent
<pitti> xnox: no, tzdata ships stuff in /usr
<pitti> smoser: thanks
<xnox> smoser, fair enough.
<pitti> and more importantly, we don't overwrite tzdata's files in /usr :)
<pitti> (which was what this bug was about originally)
<pitti> ah, already merged
<pitti> LGTM, I just suggested clarifying the commit mesage, but no biggie
<pitti> xnox: systems with a separate /usr but no initrd have never really worked well, and we shouldn't claim that we support them
<pitti> "/usr merge!" *cough*
<Skuggen> pitti: I was wondering if you had some input about the use of deb-systemd-helper in maintainer scripts i.e. is it a bad idea?
<pitti> Skuggen: not necessarily a bad idea, as long as you know what you are doing
<Skuggen> I'm working on the mysql 5.7 packaging with rbasak, and we run into an issue when trying to upgrade from old 5.5 installs, since the service is masked and disabled
<pitti> Skuggen: it's generally easier/better/more robust to use dh_installinit or dh_systemd_{enable,start}, though
<pitti> as some operations are not at all trivial
<Skuggen> https://github.com/ltangvald/mysql-5.7/blob/fixes/debian/mysql-server-5.7.postinst#L80
<Skuggen> That's the problem; I don't feel I know what I'm doing. I just saw that the system would run those commands after postinst, and that they fixed the specific problem :)
<pitti> Skuggen: e. g. dh_systemd_enable already creates unmask/was-enabled/enable code (plus the necessary bits in postrm, etc.)
<Skuggen> pitti: But it adds it at the end?
<pitti> Skuggen: it adds it wherever you put #DEBHELPER#
<Skuggen> Right, which is at the end of the postinst script
<Skuggen> (I got it from there when enabling debug output)
<rbasak> pitti, Skuggen: essentially I don't really understand exactly what's going on there, so I'd appreciate pitti's review.
<rbasak> If pitti thinks it looks OK then I'm happy to upload it.
<Pharaoh_Atem> nacc_: I'm baffled by this pcre thing
<nacc_> Pharaoh_Atem: yeah, it's ugly ... i have a good start on debugging it, but am trying to fix php-imagick still
<Pharaoh_Atem> I'm going to go take a look at the fpm bugs for now
<nacc_> Pharaoh_Atem: ok
<Pharaoh_Atem> as this bug makes me want to cry
<Pharaoh_Atem> nacc_: is there a policy for closing long standing bugs that no one has responded to?
<Pharaoh_Atem> most of the bugs here seem to be for really old versions of php5 and ubuntu
<sarnold> bugs in Incomplete state get closed after N days
<sarnold> and community members tend to close the others in other states when they refer to releases that are no longer supported
<nacc_> Pharaoh_Atem: ideally, we'll trawl those and figure out if its still reproducible with supported php5 (in precise/trusty/wily)
<Pharaoh_Atem> sarnold: so I could go ahead and close some of these years-old "Incomplete" bugs?
<sarnold> Pharaoh_Atem: probably :)
<Pharaoh_Atem> what status should I set it to?
<Pharaoh_Atem> Invalid?
<Pharaoh_Atem> I don't see another way to close it
<sarnold> hmm, I think that's fair, maybe wont-fix.. Inever pay too close attention to those floods of mails when they arrive :)
<Pharaoh_Atem> there's no wontfix option, so I'll just use invalid
<rbasak> I'd use Incomplete. Or are they Incomplete already?
<rbasak> Especially if the bug has languished due to no developer input.
<Pharaoh_Atem> incomplete status for four years
<rbasak> Together with a comment explaining that you're sweeping through fpm bugs. Tends to upset people less.
<rbasak> Incomplete status but didn't go to Expired automatically? That's odd.
<Pharaoh_Atem> okay
<Pharaoh_Atem> there's quite a few of those :/
<rbasak> (also instructions on what to do to get attention if they still want it)
<rbasak> I usually subscribe to the bug too, to catch any replies.
<rbasak> Unfortunately some proportion of reporters still get upset by that :-/
<Pharaoh_Atem> there's just no winning
<Pharaoh_Atem> I'm surprised there's no just plain "closed" status
<rbasak> We consider Fix Released, Invalid, Expired and Won't Fix to all be closed.
<rbasak> I think it's nicer this way. You can't close without a reason.
<barry> mterry: ping re: deja-dup
<mterry> barry, heyo
<barry> mterry: hi.  not sure if you still work on this package, but i'm wondering if it makes sense to treat deja-dup-backend-gvfs and gvfs-backends the same way deja is treating dpulicity and pytho-gi?
<mterry> barry, it could, sure.  The code would be a little less generic though, to look for a specific ubuntu-specific package name (debian doesn't even hame them)
<barry> mterry: cool.  let me see if i can figure something out.  i guess d-d-gvfs-backends doesn't do anything except pull in some dependencies when installed (it has effectively no contents)
<mterry> barry, I was trying to be discouraging.  :)  Why would you prefer it that way?
<mterry> barry, it's not a change that could be upstreamed
<barry> mterry: maybe i don't ;)  i'm trying to tackle the last few py2 hold outs, but i guess it all comes down to samba-libs :(
<mterry> barry, is deja-dup still pulling anything in?
<barry> mterry: deja-dup-backend-gvfs and gvfs-backends afaict
<mterry> barry, but those don't have python deps anymore, right?
<barry> mterry: transitively they do though, through samba-libs
<mterry> barry, ah....
<mterry> barry, ok, I see.
<mterry> barry, well whatever is easiest for you there.  I'd be happy to review something that uses the package names instead
<Pharaoh_Atem> rbasak: jeez, some of these FPM issues are from Ubuntu 9.04?!
<barry> mterry: porting samba is a big hairy mess, and upstream isn't too psyched to help afaict.  i've talked to the fedora guy, and even they are not making much progress on it.  my thinking is if i can install on demand the deja deps and system-config-printer-{common,gnome} then i can get py2 off the iso
<mterry> barry, ok, makes sense
<Pharaoh_Atem> barry: yeah, samba has been... thorny
<barry> Pharaoh_Atem: hi.  indeed
<Pharaoh_Atem> I don't know if you guys know about this, but it might come in handy for Py2->Py3 stuff: http://fedora.portingdb.xyz/
<barry> mterry: ok thanks.  will ping if review is needed.
<barry> Pharaoh_Atem: yep, and at some point we'll get a tracker for debian/ubuntu.  just haven't had time to put that up yet
<Pharaoh_Atem> barry: it'd be great if it could be part of the same portingdb
<Pharaoh_Atem> that would make the cross-distro efforts much easier
<barry> Pharaoh_Atem: yep!  that's the plan
<Pharaoh_Atem> barry: have you hooked up with Petr (encukou) on it?
<barry> Pharaoh_Atem: yep, on both the portingdb and samba
<Pharaoh_Atem> awesomeness
 * Pharaoh_Atem likes hearing about stuff like that
<barry> \o/
<Pharaoh_Atem> barry: I'm a member of the Fedora Python SIG, so I like hearing about stuff like this
<barry> Pharaoh_Atem: oh cool.  i lurk on the gmane group.  we pythonistas gotta stick together, right? :)
<Pharaoh_Atem> indeed
<Pharaoh_Atem> I live and breathe on IRC :)
<Pharaoh_Atem> I've personally been shepherding a few small projects over to py3 land
<Pharaoh_Atem> and I've recently pushed updates in Fedora for pika and mgarepo to enable py3 versions
<Pharaoh_Atem> and it looks like Xenial already has pika updated
<Pharaoh_Atem> woohoo
<Pharaoh_Atem> rbasak: it looks like a patch was forgotten for php5 in precise: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1352617
<ubottu> Launchpad bug 1352617 in php5 (Ubuntu) "php5-fpm UNIX sockets in Precise do not listen as www-data:www-data by default, and causes 502s with webservers trying to use socket" [Undecided,New]
<Pharaoh_Atem> rbasak: I think the Launchpad Janitor is broken
<Pharaoh_Atem> rbasak: also, what do I do with these bugs reported by apport, they give me nothing useful for reproducing it :/
<teward> oh hey that's my bug
<teward> Pharaoh_Atem: that bug didn't have enough testers at the time of my filing to confirm the issue
<teward> that, and nobody bothered to look at it after my filing (looks like security changes introduced regressions)
<teward> Pharaoh_Atem: TBH I would rather forward that to the Security team for consideration first - as my comment with the attached patch said
<teward> (it's also why I never subbed sponsors - i wanted a security team review first)
<teward> rbasak: ^ just to keep you in the loop (re: 1352617, which was just poked up at 16:27)
<Pharaoh_Atem> teward: I see
 * Pharaoh_Atem is trying to just triage through the bugs so that rbasak will feel more comfortable about switching php-fpm to main
<teward> right
<teward> Pharaoh_Atem: though, refer to https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1334337 for the 'related' bug
<ubottu> Launchpad bug 1334337 in php5 (Ubuntu Utopic) "Regression: php5-fpm's socket should be accessible by www-data by default" [Undecided,Fix released]
<teward> which was Saucy, Trusty, and Utopic
<teward> it's the same regression, I believe, though I didn't poke the patch any further because Precise went out of my radar
<teward> Pretty certain that one doesn't exist anymore
<teward> in any php*-fpm
<Pharaoh_Atem> yeah, it's not a problem in trusty, vivid, wily, and xenial from my checking
<teward> Pharaoh_Atem: it's not, pretty certain it's an extended case of that regression as documented in 1334337 - esp. given mdeslaur's comments on the irc logs on that bug
<teward> Pharaoh_Atem: it'd be wonderful if I had the ability to approve the Precise nomination on that bug
<teward> because then we can actually mark it as affecting *precise* :P
<Pharaoh_Atem> I have zero powers here
<teward> right
<Pharaoh_Atem> afaik, only rbasak can do anything of value
<teward> :P
<Pharaoh_Atem> all I'm doing is trying to win him over so that I can have php7.0-fpm in main
<teward> yep :)
<teward> Pharaoh_Atem: well, you can confirm with me especially that 1352617 is not going to impact the MIR
<teward> :)
<Pharaoh_Atem> frankly, I don't expect any of these bugs to really apply to php7.0-fpm, because the internals were completely rewritten
<Pharaoh_Atem> the internal codebase for php7.0 is wildly different from php5, so the bugs for php5 don't actually apply to php7
<Pharaoh_Atem> unless they are distro specific config things
<nacc_> slangasek: question about php-imagick for you ... i think debian (and we) will want to undo the change to move to phpunit (it's a divergence from upstream and doesn't really work). But the run-tests.php script that was used before isn't packaged. WOuld it make sense to package it? Or should I do a temporary build in debian/tests/control just to get the script ?
<Pharaoh_Atem> basically all the bugs I see here don't apply to php7.0 in its entirety
<rbasak> Pharaoh_Atem: for main inclusion of fpm, that would only affect Xenial onwards. I only want the bugs resolved for Xenial. If the conclusion is that they don't affect php7.0, then that's resolved for Xenial in my book.
<rbasak> Pharaoh_Atem: but we should sort out the bug statuses accordingly, so that everybody understands what we think of each bug and has the opportunity to tell us otherwise.
<rbasak> I'm not suggesting that we mass close bugs, but actually consider each on their own merits.
<rbasak> If we have reason to believe that a bug probably doesn't affect Xenial, then we can explain that in a comment and mark Incomplete (or Fix Released or Invalid as appropriate).
<barry> mterry: LP: #1551989
<ubottu> Launchpad bug 1551989 in deja-dup (Ubuntu) "Demote deja-dup-backend-gvfs and install on demand" [Undecided,New] https://launchpad.net/bugs/1551989
<mterry> barry, noted.  Will look tomorrow
<barry> mterry: thanks!
<Pharaoh_Atem> rbasak: I have not yet seen a bug that affects php7.0/Xenial
<Pharaoh_Atem> given that it's in a separate package name, wouldn't it be obvious they don't carry over to php7.0?
<Pharaoh_Atem> brb
<Pharaoh_Atem> rebooting
<Pharaoh_Atem> back
<mwhudson> hm, https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda looks a little out of date
<mwhudson> are the next meetings going to be 2016-03-14Z15:00 and 2016-03-28Z19:00 ?
<mwhudson> 2016-03-28 is easter monday but i don't know if that matters
<sarnold> mwhudson: given that five of the seven members have terms expire before the next meeting, it may be moot :) https://launchpad.net/~developer-membership-board/+members
<mwhudson> sarnold: i see https://launchpad.net/~techboard/+members is similarly humourous
<sarnold> mwhudson: hehe
#ubuntu-devel 2016-03-02
<rbasak> Pharaoh_Atem: that it's a different source package name is just a technicality really. We all know the new name is derived from the old name. It would be sensible for bugs to carry over.
<rbasak> Pharaoh_Atem: though as I say, if there's a good reason it's fine to comment on bugs saying that they are presumed fixed in Xenial and marked Fix Released or Incomplete or whatever as appropriate.
<nacc_> Pharaoh_Atem: what a doozy -- learned a bit of twig syntax, wrote a test php & template that is identical to the one that causes the testsuite to segfault ... and no segfault. But if I remove the two utf8 files from the tests, no segfaults. So it is in those files. I'm now worried there is some corrupted state in php itself
<hallyn> pitti: hey...  so you wrote a patch for systemd-shim "Clean up closing logind sessions".
<hallyn> it inserts a cgroup release agent (regardless of whether one was already defined) which, when a cgrou pis emptied, stops a session
<hallyn> this is wreaking havoc on a xenial system if you install upstart-sysv, lxc1, and fix cgroup-lite the way we need to for phone :)
<hallyn> upon login, /etc/pam.d/common-session tells systemd to create cgroups;  then it has libpam-cgfs do the same;  the cgroups created by systemd are cleared, teh release agent called, the session stopped, login session terminated
<hallyn> pitti: would you boject to patching systemd-shim to not insert the release agent if one is already set?
<hallyn> (it's poor manners to do otherwise :)
<hallyn> or can i just get rid of that since in all real installs we expect to be using real systemd
<Son_Goku> hallyn: why not just move to systemd on the phone?
<Son_Goku> just let upstart dieâ¦ for all of our sakes :)
<hallyn> Son_Goku: not in my power
<Son_Goku> :â(
<hallyn> I think it just has to do with some user jobs, i'm sure they'll be switching soon
<Son_Goku> :(
<Son_Goku> can you plea for them to move asap?
<hallyn> nah i'm gonna lobby for openrc.
<hallyn> i kid!
<sarnold> daemontools 4 life!
<hallyn> we have a bsd init job for cgmanager
<hallyn> (for slackware)
<hallyn> sarnold: well at some point you'd like to stop rewriting the lowe rlayers so you can build higher layers on top of them :)
<hallyn> but this point is not that point
<sarnold> hallyn: haha :)
<hallyn> all right, that fixes it.  I'll sling a debdiff over to pitti after find some more kleenex to dry my tears
<hallyn> hm, no, i was wrong.  drat.
<hallyn> meh, bad patch.
<hallyn> pitti: http://paste.ubuntu.com/15264990/
<hallyn> ugh.  minus the debug statements
<hallyn> pitti: maybe http://paste.ubuntu.com/15264999/ instead
<sarnold> hallyn: you may be the only person I know who debugs a string with strlen() :)
<hallyn> pitti: basically that is needed becaues when I push http://paste.ubuntu.com/15265000/ I wil lotherwise cause upstart-based xenial deploys to refuse logins
<hallyn> sarnold: well i wanted to catch the length of a dbus reply for an empty string :)
<sarnold> :)
<hallyn> then again, now my vm has a corrupt fs.  did my patch somehow contribute to that?
<nacc_> Pharaoh_Atem: last thought of the night (it's a good one) -- phpunit --process-isolation makes twig not segfault
<nacc_> Pharaoh_Atem: which i think means we have a php bug
<sarnold> that sounds ungood
<hallyn> huh   Begin: Running /scripts/init-bottom ... Warning: overlayroot: debug is busted
<sarnold> hallyn: -that- sounds like a clear suggestion to EOD :)
<hallyn> i'm open to suggestions, i'll tkae that one
<hallyn> \o
<cpaelzer> good morning
<pitti> hallyn: systemd-shim> sounds good; this code isn't very good, it has never been thoroughly tested with running systemd side by side, just for making logind work under upstart (where nothing else fiddles with cgroups)
<pitti> hallyn: http://paste.ubuntu.com/15264999/ LGTM
<pitti> hallyn: ah, src/cgmanager.{h,c}, I thought that was some piece of standard code being copied around into various projects
<pitti> hallyn: let's test this for a few days, then I'll apply it upstream and upload it to Debian too
<pitti> hallyn: thanks!
<hallyn> pitti: cool, thanks.
<hallyn> pitti: noob question, but it's late and i'm not trusting my judgement - the cgroup-lite needs systemd-shim to be the newer version.  should it conflicts or breaks on the <= old version?
<Skuggen> pitti: Did you have a chance to look at the deb-systemd-helper use we have in the mysql 5.7 postinst, to see if it looks safe?
<hallyn> i think conflicts
<hallyn> no, breaks sounds more accurate per the docs
<pitti> hallyn: it should Breaks: (<< fixed_version)
<hallyn> kewl, pushing htat, and calling it a day - thx
<pitti> Skuggen: the pastebin you showed to me yesterday? that looked reasonable, if you also replicated dh_systemd_*'s postrm and prerm code
<pitti> Skuggen: still wondering if it wouldn't be simpler to just move the #DEBHELPER# tag further up in the postinst and let the code be autogen'ed
<Skuggen> pitti: But the #DEBHELPER# code will also do the 'proper' starting of the service that should happen at the end
<pitti> Skuggen: so you need to things *between* enable and start? OOI, what is that?
<Skuggen> Updating an existing database to mysql-5.7 requires running mysql_upgrade, which (unfortunately) is a client that needs to connect to a running server
<Skuggen> And we added running mysql_upgrade as part of postinst instead of relying on users doing it manually
<pitti> Skuggen: right, but can't that happen before the debhelper stuff?
<pitti> i. e.
<pitti> if [ "$1" = configure ] && have_older_db; then mysql_upgrade; fi
<pitti> #DEBHELPER
<Skuggen> Yes, but I need to start the service to be able to run mysql_upgrade, which is what the systemd_helper commands are for
<Skuggen> Well, I could run mysqld manually and wait in a loop for it to be ready, but we moved away from that because it's also not very robust
<pitti> Skuggen: *confused* I thought you said the service must *not* be running yet for upgrading?
<pitti> so doing #DEBHELPER# first and then call mysql_upgrade?
<pitti> Skuggen: I should probably purge my entire brain state about this and we'll start over :)
<Skuggen> Hehe
<Skuggen> I might be able to move all the upgrade-related stuff after #DEBHELPER#, with some reshuffling
<Skuggen> (there's also some checking/fixing of password access for the maintenance user used to run upgrade, but should be able to refactor it)
<pitti> Skuggen: so I think the question is "do you need to anything *within* the #DEBHELPER# generated code"
<pitti> if yes, then you need to do things manually or apply some seddery; if not, then things are easy, and you just need to strategically place the #DEBHELPER# token
<Skuggen> Hopefully not. I'll give it a try. Thanks for the help :)
<dholbach> good morning
<cpaelzer> pitti: thanks for agreeing that "changing" enviroment features for tests is a bad thing
<cpaelzer> pitti: I didn't realize that my first paragraph could have been so misleading until you repled on the RT ticket - thanks
<cpaelzer> pitti: I tihnk it is now up to all the involved parties to consider if changing from host-cpu to sandbridge would break anything else (due to the fact that it is a global config)
<pitti> cpaelzer: I'm not convinced at all that we use -cpu host right now
<pitti> cpaelzer: I've seen "SandyBridge" on all our clouds, on the semaphoreci.com clouds, etc.
<pitti> it seems it's just a default -cpu SandyBridge in openstack
<pitti> i. e. I think we are currently using that ^
<cpaelzer> pitti: that is how I read kuhlmannt RT post
<cpaelzer> pitti: well I just took "The current configuration in nova is unset for cpu_mode which means it should default to host-model " for granted, but I just saw your post checking it
<cpaelzer> pitti: and I understand that we assume at least one of the systems runs on >sandybridge which means your check confirms that it is not running as "host-cpu"
<pitti> cpaelzer: *nod*, I yet have to see an x86 cloud instance which is something else
<cpaelzer> pitti: I really wonder what that was two weeks ago where sse3 wasn't there - it is a shame that we can't timewarp and do a proc/cpuinfo and such there
<cpaelzer> pitti: waitnig for IS replies to your post now, thanks for testing your scalingstack instances
<cpaelzer> actually - do we already (if not should we?) do an environment report in the adt-* output that we could check that in logs after the fact?
<pitti> cpaelzer: we have testinfo.json which has some info  like the running kernel version, environment variables, etc.
<pitti> we can certainly add stuff to that
<pitti> e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/u/udisks2/20160301_213435@/result.tar
<pitti> that contains testinfo.json
<cpaelzer> pitti: just parsed through it - interesting
<cpaelzer> pitti: there are no links from what I consider a packages CI overview to that result.tar (e.g. http://autopkgtest.ubuntu.com/packages/o/openvswitch-dpdk/xenial/amd64/)
<cpaelzer> pitti: I could fetch my data by just manually constructing the link thou
<cpaelzer> pitti: any reason not to add that link there as well?
<pitti> cpaelzer: I'd rather expand it into the debci log
<pitti> we have three links there already, adding more isn't helping confusion
<cpaelzer> pitti: agreed
<pitti> cpaelzer: indeed it's just replacing log.gz with result.tar in the URL
<cpaelzer> pitti: IMHO the dbci log could take a plain /proc/cpuinfo, on s390x maybe also /proc/sysinfo - that would be great
<cpaelzer> pitti: I also thought about lshw, but that is too heavyweight
<pitti> cpaelzer: perhaps #processors and the model name
<pitti> the full thing is quite big
<cpaelzer> pitti: processor, model and flags of one of them?
<pitti> ok
<pitti> cpaelzer: mind reporting a bug against autopkgtest about that, as a reminder?
<cpaelzer> I'll do
<cpaelzer> thanks
<pitti> great
<cpaelzer> pitti: before I open the bug one more thing to clarify, I don't know who controls the results.tar or artifacts.tar.gz
<cpaelzer> pitti: I guess the answer is no
<pitti> the answer to "who" is "no"?
<cpaelzer> pitti: but would it be possible to add e.g. a full sosreport into those tarballs AFTER failing tests?
<pitti> cpaelzer: adt-run writes testinfo.json
<pitti> cpaelzer: it could go into artifacts.tar.gz (certainly not into results.tar)
<pitti> cpaelzer: but I don't want to do this by default really, as you don't need it for most tests
<pitti> so if your test wants to depend on sosreport and use it, please feel free
<cpaelzer> pitti: ok, so if anybody wants it make it test specific - I'm absolutely ok with that - thanks
<pitti> i. e. most tests aren't that hardware specific, and having sosreport in all of them woudl just be a waste of resources, and also it's another potential point of brittleness
<Skuggen> pitti: Simply moving everything that needed a running server below #DEBHELPER# does the trick. Thanks!
<smb> Hm anybody here got experience with bind9/isc-dhcp packaging. Looks to me like in order to unbreak dhcp one needs to (fake) moving back to a less-featured libbind to build dhcp. There is something in there for udeb, but I am not sure that would be the right thing.
<smb> That's about bug 1551351 for reference
<ubottu> bug 1551351 in isc-dhcp (Ubuntu Xenial) "dhclient does not renew leases" [High,Confirmed] https://launchpad.net/bugs/1551351
<Saviq> pitti, morning, did you see the recent britney results in silos? https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-076/excuses.html https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-076/excuses.html https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-064/excuses.html
<Saviq> pitti, there's all kinds of unsatisfiable depends, both on vivid (how Â¿?) and xenial (proposed migration?)
<Mirv> much of unsatisfaction
<Saviq> they can get no...
<Saviq> satisfactioon
<Mirv> is there a way to see what autosynced from Debian between certain dates (2016-02-17 - end of auto sync period)?
<seb128> Mirv, I don't think we have a list for those, but autosync stopped on the 18 iirc
<Mirv> yeah I know, something magic happened between the morning of 17th and 19th that breaks generation of top-level-domain data
<Mirv> but we're closing in anyway with oSoMoN
<seb128> Mirv, how are those generated?
<Mirv> seb128: http://code.qt.io/cgit/qt/qtbase.git/plain/util/corelib/qurl-generateTLDs/main.cpp called from http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/plain/debian/generateTLDs.sh?h=ubuntu - but it does not fail locally, only on builders
<Mirv> so what I'm next trying is settings C.UTF-8 as the locale in debian/rules, just a wild guess now that it was found that there's something wrong with the generation
<seb128> Mirv, oSoMoN, grep changed on the 17th and created issues for e.g ubiquity
<Mirv> thank you :)
<seb128>   * debian/rules: Build under C.UTF-8 locale. grep 2.23 causes broken debconf
<seb128>     templates to be built under the C locale.
<Mirv> mitya57: I see you committed set -e to qtbase, have you already found the grep error?
<Mirv> if it's that one
<seb128> that's what pitti did to ubiquity ^
<Mirv> seb128: ah, it sounds like my guess is the correct one <- oSoMoN
<Mirv> so, I'll prepare a real silo with C.UTF-8 set and start a build and go to lunch
<pitti> Skuggen: cool! that's so much easier and robust
<seb128> Mirv, https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1547466
<ubottu> Launchpad bug 1547466 in grep (Ubuntu) "grep switches into binary mode while processing a text file" [High,New]
<seb128> sorry that it has bitten you as well, seems like you spent several days trying to figure that out
<pitti> Saviq: ah, I know -- looks like this is from xnox' recent component check
<seb128> we should perhaps have reverted the grep update :-/
<pitti> xnox: ^ I think we need to disable the component checking if PPAs are involved
<xnox> pitti, right, because ppas only have 'main'
<xnox> pitti, but we don't run britney excuses against ppas... or do we?!
<pitti> xnox: we do, silos do that
<xnox> pitti, ok =) i'm so out of date. Do you want me to look into this?
<pitti> xnox: I'll have a look, should be fairly simple
<pitti> xnox: what I'd like you to do is to have a look at the ubuntu excuses, like http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#squid3
<pitti> xnox: I don't see how squid3 depends on squid
<xnox> essentially calls to get_dependency_solvers should change component to MULTIVERSE and then things are ignored, "if PPA:" or some such.
<xnox> or maybe we need a britney.conf feature flag for components missmatches.
<LocutusOfBorg> superm1, please please on the next upload drop fonts-droid on mythtv https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039159.html
<pitti> xnox: I think we should just disable the check if ADT_PPAS is set
<smb> seb128, heh... so it turned out to be a problem for other people, too. :)
<seb128> smb, grep you mean?
<pitti> xnox: change "if allowed_component(component, package[COMPONENT]):" to "if self.options.adt_ppas or allowed_component()" perhaps?
<smb> seb128, yep.
<seb128> smb, yeah, Mirv and oSoMoN just spent several days investigating qt regressions
<oSoMoN> Mirv, and confirmed, running a local build with LANG=C LC_ALL=C generates a broken qurltlds_p.h
<seb128> which turned out to be due to that
<pitti> xnox: oh, nevermind, the squid3 binary in -proposed indeed has Pre-Depends: squid (>= 3.5.12-1ubuntu1)
<pitti> rbasak: ^ please run check-mir on your squid merge
<LocutusOfBorg> superm1, well, nevermind
<smb> seb128, I was fearing it could also cause more obsure problems. Build fails only if grep is used to produce new sources on a build
<oSoMoN> if there wasnât one already, a unit test should be added to grep
<pitti> rbasak: ah, unping
<pitti> xnox: so for squid, apparently squid3 now builds a squid transitional package, so this is a case of component-mismatches
<Mirv> oSoMoN: thanks
<pitti> apparently 'squid' is the new main package, and squid3 is a transitional
<seb128> smb, well, in this case that was not a build failure but some runtime issues due to buggy top-level-domain data generated
 * xnox should have run update the chdist before looking into it, or like have more coffee
<pitti> xnox, rbasak: it's on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt , I promoted squid now
<smb> seb128, yeah -> more obscure problem. :) Guess I was kinda lucky that Xen failed to build then
<seb128> is anyone looking at the grep issue?
<smb> I don'T think so (yet). I think I could not convince Brian it is broken
<Mirv> this is linked to C.UTF-8 not being the default locale which has been a discussion topic for years. it gives grey hairs to many who build Python packages
<xnox> pitti, squid3 package builds squid package in both release & proposed, and in both cases it's in universe.
<pitti> xnox: right, so we caught the component-mismatches in britney
<pitti> xnox: I just wasn't aware of the squid3 -> squid transition
<pitti> so it seems all fine
<xnox> pitti, right yes, i see that now.
<pitti> xnox: http://paste.ubuntu.com/15265997/ should work, right? (no testsuite..)
<seb128> Mirv, yeah, still it's a behaviour change and impacting our things with the current buildds setup
<xnox> pitti, looks good! cowboy that in =)
<Mirv> seb128: yep
<pitti> Saviq: ok, britney fix pushed, so silo excuses should update within the next 2 hours; sorry about that
 * pitti keeps the page  open to check after lunch
<Saviq> pitti, thanks :)
<seb128> Mirv, oSoMoN, smb, seems like it's being discussed upstream on the grep list, http://lists.gnu.org/archive/html/bug-grep/2016-02/msg00036.html
<rbasak> pitti: [squid] that's right, thanks for sorting it.
<smb> seb128, not like that sounds the discussion is going well...
<seb128> yeah...
<seb128> it would feel safer reverting the behaviour change for xenial
<seb128> or we might end up wasting quite some more time chasing weird issues where we should focus on bugfixing for the lts
<oSoMoN> Mirv, so according to the upstream discussion, the correct fix is to invoke grep with -a, not LANG=C LC_ALL=C, is that what youâre doing?
<smb> I tend to agree. Even worse with that example of some backup tool silently failing...
<seb128> who would the right person to do that call? foundations?
<smb> guess foundations but not sure which person... slangasek ?
<Mirv> oSoMoN: I used the LC_ALL (same as ubiquity), it should be fine for now and I'd guess Debian will switch to -a which I'll notice in a future merge
<oSoMoN> ok
<LocutusOfBorg> pitti, can you please have a look at ubuntukylin-meta wrt http://lists.gnu.org/archive/html/bug-grep/2016-02/msg00036.html ?
<dholbach> Laney, I won't have time to look at the tomahawk thing in the next days :-/
<Laney> dholbach: ok, well keep it on the queue then
<pitti> LocutusOfBorg: sorry, what's wrong with ubuntukylin-meta?
<pitti> and FWIW, we really ought to switch to C.UTF-8 by default on buildds and the like
<pitti> tell me one good reason why one would still want 'C' in 2016
<LocutusOfBorg> pitti, https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039159.html :)
<seb128> pitti, yeah, but meanwhile the builders are on C locales and we have people wasting days chasing random side effect of that grep update
<pitti> Saviq: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-076/excuses.html is good again now
<Saviq> pitti, great, thanks
<pitti> LocutusOfBorg: re (sorry, out for lunch); ok, I'll update the seeds now
<pitti> LocutusOfBorg: ugh, it wasn't updated since wily
<pitti> LocutusOfBorg: uploaded
<LocutusOfBorg> thanks!
<tjaalton> I can't run sudo on schroots after updating to xenial, can someone confirm the same?
<pitti> WFM
<tjaalton> ok then :)
<pitti> maybe schroot dir/overlay/mount dir has "nosuid" or so?
<tjaalton> maybe, it's on /run/shm
<pitti> tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
<pitti> yes, that can't work then
<tjaalton> must've been changed
<phatina> hi, I am trying to create several *.deb packages from a single tarball (binary, libraries, header files), but I can't make desired files (listed in ./debian/package.install) to appear in the packages. Every tutorial I found recommends to use "single binary" type of package (bzr dh-make ...)
<phatina> Any tips, what I am doing wrong?
<LocutusOfBorg> zequence, you there? hi
<LocutusOfBorg> ubuntustudio-meta is the last blocker for fonts-android migration
<cjwatson> phatina: put your source package somewhere for people to look at and then it will be easier to work out what you've done wrong
<LocutusOfBorg> zequence, look e.g. lp: #1546847
<ubottu> Launchpad bug 1546847 in ubuntukylin-theme (Ubuntu) "Fonts-droid has been deprecated and removed, use fonts-droid-fallback instead of fonts-droid" [Undecided,New] https://launchpad.net/bugs/1546847
<LocutusOfBorg> and https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039159.html
<pitti> LocutusOfBorg: I can update that as well, while I'm at it
<LocutusOfBorg> pitti, it would be awesome :)
<LocutusOfBorg> just note: the fonts-noto is about 100MB, while droid fallback is 1MB
<mardy_> cjwatson: hi! I have a daily recipe on launchpad, which doesn't work because it needs to include some .so files but they are being removed when building the tarball, because launchpad passes the -I option to dpkg-buildpackage
<mardy_> cjwatson: is there some way to prevent the daily builder to use that option?
<cjwatson> mardy_: No.
<cjwatson> But IIRC there is a way to make that work at the source package level ...
<mardy_> cjwatson: I've found this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735377
<ubottu> Debian bug 735377 in dpkg-dev "dpkg-source: 3.0 (native) silently ignores many binary files by default" [Normal,Open]
<mardy_> cjwatson: but it doesn't seem to work here, it looks like the -I given from the commandline is "stronger"
<cjwatson> mardy_: Which source format?
<mardy_> cjwatson: actually, I've tried both 1.0 and 3.0 (native), and I'm getting the problem with both of them
<cjwatson> mardy_: I think debian/source/options ought to be workable somehow, though possibly only for 3.0.
<cjwatson> mardy_: Beyond that I probably can't help at the moment.
<mterry> barry, your deja-dup patch makes some sense.  But I have a counter-proposal.  Working on it myself
<mterry> barry, (my counter proposal just closes a couple issues with my original python-gi patch)
<cyphermox> good morning!
<mdeslaur> hi cyphermox
<barry> mterry: cool, thanks
<cyphermox> hey mdeslaur
<pitti> LocutusOfBorg: argh -- I can't push to https://code.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.xenial, and they explicitly seed fonts-droid
<pitti> so sorry, I can't do this
<smb> cyphermox, wait until you catch up (about the good) ;)
<pitti> LocutusOfBorg: you need someone from https://launchpad.net/~ubuntustudio-dev/+members
<cyphermox> smb: ah?
<pitti> LocutusOfBorg: perhaps you can do a MP?
<smb> cyphermox, one never know whether a morning really is good. :) Well speaking of, haven't I seen your name i bind9/isc-dhcp changelogs, too
<cyphermox> smb: I hate you! :)
<smb> :)
<LocutusOfBorg> pitti I can bother Ross for this then
<LocutusOfBorg> MP what is?
<smb> cyphermox, well, I think I got a rough idea what needs to be done to fix dhclient but not how to tell the packaging
<LocutusOfBorg> or cjwatson ^^^
<cyphermox> smb: to fix dhclient for what?
<smb> cyphermox, to work again in xenial
<cyphermox> bug #?
<smb> cyphermox, bug 1551351
<ubottu> bug 1551351 in isc-dhcp (Ubuntu Xenial) "dhclient does not renew leases" [High,Confirmed] https://launchpad.net/bugs/1551351
 * cyphermox reads and observes dhclient's behavior locally
<smb> cyphermox, tl;dr is that bind9.10 drops the export library in favour of a combined one which breaks dchlient
<cyphermox> mmkay
<cyphermox> well, I see that here it has renewed..
<cjwatson> LocutusOfBorg: not me
<cyphermox> but I haven't checked if it's because NM did something to it, for instance
<smb> cyphermox, hm... could be ... the installs I looked on where server kind (ifupdown)
<smb> cyphermox, there is that discussion as reference https://lists.isc.org/pipermail/bind-users/2015-February/094640.html
<cyphermox> yeah I'm reading that
<cyphermox> I doubt using bundled sources (assuming there are still any) would help
<cyphermox> well, that's not entirely true
<cyphermox> I have no difficulty believe it would work; it's just not right unless there is no way to fix bind
<cyphermox> .. or to fix isc-dhcp itself
<smoser> cyphermox, i'd appreciate your thoughts on https://bugs.launchpad.net/curtin/+bug/1551937 . i tried to summarize in comment 7.
<ubottu> Launchpad bug 1551937 in curtin "lvm and multipath and xenial not happy together" [High,Confirmed]
<smb> cyphermox, Somehow there seems to be one part of build (currently) done for udeb which drops epoll and threads, but whether that would be an option
<cyphermox> mkay
<ahasenack> hi guys, quick policy question about a package that was in proposed but rejected
<LocutusOfBorg> lets wait for zequence :)
<ahasenack> once I have a new fix, do I need to build upon the proposed one, or can I start fresh from the one that is in the distro?
<cjwatson> ahasenack: As far as the archive is concerned, it doesn't matter.
<smb> cyphermox, The timeline made me wonder. Somehow the change to bind9.10 seemed to have happened last year December. But dhclient breaking seems to match with a recent upload of doko that says stop building against the export lib.
<ahasenack> cjwatson: ok, if I upload something to proposed again, with the same version and release numbers, but different contents (because it's a different fix), it won't be rejected?
<cjwatson> ahasenack: Consider it just like the question of whether if a branch is rejected you should commit on top or prepare a new branch.  (i.e. depends on the circumstances)
<cjwatson> ahasenack: *Personally* I would find it clearer to use a different version, but it's not a policy requirement to do so.
<ahasenack> cjwatson: that's fine, I was wondering about that check that ppas do, if it applies here as well (same version, different content). Looks like proposed really "forgets" the package then?
<cjwatson> ahasenack: It does.
<ahasenack> ok, thx
<cyphermox> smb: ok, seems like maybe the issue is "just" epoll. I can look in bind9 source to see if there's an obvious clue
<cjwatson> ahasenack: At least for the purpose of version checks.  It still exists in the rejected queue, but duplicates are allowed there.
<ahasenack> cjwatson: can the final debian changelog include the proposed one that was rejected? The fix wasn't incorrect, just not enough, so it will still be there in the new upload, plus a new fix
<ahasenack> or should I merge the entries into one?
<cjwatson> ahasenack: Up to you.
<ahasenack> ok
<ahasenack> thx again
<smb> cyphermox, Ok. I guess that would be a cleaner solution if it would work. I was thinking about faking an export style parallel lib... but I agree that is not really desirable if it can be avoided
<cyphermox> smoser: it would be necessary to look also at the bindings file, and the output of multipath -ll from the initramfs
<oSoMoN> Mirv, I confirm that packages in silo 12 fix the regression in webbrowser-appâs unit tests
<smoser> cyphermox, i put thebindings file there.
<smoser> see comment 6
<oSoMoN> Mirv, as far as Iâm concerned, that silo is good to land (when armhf packages are done building of course)
<cyphermox> smoser: well, sure, but I really mean *from the initramfs*, seeing bindings and wwids and the output of multipath -l  from the same environment and install
<cyphermox> smoser: sorry but otherwise it's not clear whether there are changes in curtin between the point you got the serial log and the point you wrote comment 6
<Mirv> oSoMoN: oh you found the silo, thanks! :)
<cyphermox> (but you could tell me; yet comment 5 seems to point to the fact that there may have been)
<mardy_> cjwatson: nope, I studied the dpkg-source code and there just isn't a way to override a -I given from the command line (no matter what the source format is) :-(
<cyphermox> smoser: that said, multipath -l is really the most interesting part of it all, IIRC you *should* see things not have whitespace on xenial.
<smoser> cyphermox, the problem is that one expects spaces in its bindings file
<smoser> and one does not
<smoser> and as curtin i have to know that
<smoser> and in an upgrade from trusty to xenial, the system is goign to be hosed
<cyphermox> err, what?
<oSoMoN> Mirv, yeah, Iâm really anxious to get this resolved, and I suspected you had a silo build going on already, so it wasnât hard to find it :)
<smoser> the wwid for the drives in that system have spaces in them.
<smoser> and in xenial, multipath -r will write /etc/multipath/bindings with multiple consecutive spaces turned into a '_'.
<smoser> in trusty, that file has to have the spaces.
<smoser> if i upgrade from trusty to xenial, i'm going to have the spaces
<smoser> and on reboot, i'm going to fail to find root
<cyphermox> trusty had spaces (if the drive make/model had), xenial does not, and we handle this through the postinst for multipath-tools where appropriate
<smoser> so the postinst is going to edit that file ?
<cyphermox> only your last statement is incorrect; the upgrade should be handled by multipath-tools
<smoser> and anyone writing that file for both is just going to have to "know" this.
<cyphermox> yes
<cyphermox> that's the fun part is writing installers :)
<cyphermox> *in
<smoser> do you have a suggestion on how to know which behavior?
<cyphermox> what do you mean?
<cyphermox> what format for bindings and wwid is completely dependent on the release
<cyphermox> it comes from which version of multipath-tools is in use
<barry> mterry: you rock, thanks
<mterry> barry, how close are we now to a python2 free image?
<cyphermox> smoser: tbh, if you want to make it easy on yourself you may want to run multipath -W to create the wwids file for you, then you could run multipath -l and parse the output to create the bindings file
<smoser> i can't currently do that.
<smoser> as i dont have the modules
<cyphermox> ah, multipath -r writes the bindings
<cyphermox> you could modprobe them if it needs to do multipath stuff?
<barry> mterry: i think the only things left to deal with are system-config-printer-{common,gnome}
<cyphermox> smoser: if you don't start up with understanding multipath though, it will be fun and dangerous to try to add stuff like lvm on top of it
<barry> mterry: those also pull in samba-libs
<barry> mterry: once we take those off, we can unseed `python` and then the rest should just fall off
<Son_Goku> barry: I thought system-config-printer-* was already converted to py3?
<barry> Son_Goku: it is, but they depend on samba-libs which transitively pulls in python2 :(
<Son_Goku> what?!
<Son_Goku> couldnât you make like a samba-libs-nopython thingy?
<barry> Son_Goku: apparently it is not that simple
<Son_Goku> :â(
<Son_Goku> wait, why does system-config-printer need Samba
<Son_Goku> doesnât it use IPP?
<barry> system-config-printer-common -> python3-smbc -> libsmbclient -> samba-libs
<Son_Goku> O.o
<Son_Goku> http://fedora.portingdb.xyz/pkg/system-config-printer/
<Son_Goku> I donât see python3-smbc
<Son_Goku> barry: whereâs python3-smbc coming from?
<barry> Son_Goku:
<barry> % apt-cache show system-config-printer-common | grep -i depends
<barry> Depends: python3-cups (>= 1.9.60), python3-smbc, python3-dbus, python3-cupshelpers
<ogra_> bah, infinity is out today ?
<barry> ogra_: i believe so, yes
<ogra_> sad ..
<smoser> cyphermox, well, maybe. i did result in trusty deploying lvm on top of multipath before knowing of this difference
<smoser> so as for now, i'm quite blissful in my ignorance.
<Son_Goku> barry: Iâm super confused about that
<barry> Son_Goku: any insight is appreciated
<Son_Goku> I know that python-smbc was required at one point
<Son_Goku> but according to the Fedora spec, itâs not required anymore
<barry> Son_Goku: python3-smbc, but i think you're saying that it might be an old dependency that can get dropped?
<Son_Goku> ah, I see now
<Son_Goku> itâs an optional dependency
<Son_Goku> barry: http://pkgs.fedoraproject.org/cgit/rpms/system-config-printer.git/tree/system-config-printer.spec#n57
<Son_Goku> Itâs set as âSuggestsâ now
<Son_Goku> it is not required for the program to function
<Son_Goku> thatâs as of system-config-printer 1.5.7
<Son_Goku> obviously, the Suggests line is a bit of an error, as it needs to be python3-smbc, but I think that should clear up your issue
<barry> Son_Goku: it's worth a try, thanks
<Son_Goku> no problem
<cpaelzer> sorry, but my "usual uploaders" for dpdk seem to be currently all busy/on vacation
<cpaelzer> I prepared an upload in bug 1551601 and would be super happy if somebody could take that a look today for review and (if ok) upload
<ubottu> bug 1551601 in dpdk (Ubuntu) "DPDK init scripts need some hardening against broken specifications in /etc/dpdk/interfaces" [High,Triaged] https://launchpad.net/bugs/1551601
<seb128> barry, Son_Goku, check with tkamppeter
<Son_Goku> barry: looks like you guys are on a snapshot release, so you should be able to successfully downgrade python3-smbc to Suggests
<barry> seb128: yes for sure, before i upload anything
<Son_Goku> Iâm going to have to ping the maintainer of system-config-printer to change that Suggests line
<Son_Goku> because itâs wrong
<ogra_> slangasek, around ?
<barry> ogra_: probably not ;)
<ogra_> bah
<ogra_> why is everyone i could ask about my issue off today :P
<barry> ogra_: it's your lucky day i guess
<ogra_> yeah
<barry> Son_Goku: unfortunately, it looks like there are definitely still imports of smbc in the code
<barry> well 2
<Son_Goku> dammit, where?
<barry> in pysmb.py and troubleshoot/CheckNetworkServerSanity.py
<Son_Goku> thatâs in system-config-printer?
<barry> the latter is protected by a try/except (a dubious bare one, but there nonetheless)
<barry> Son_Goku: i'm looking in the xenial source package
<barry> Son_Goku: yes
<Son_Goku> hmm
<Son_Goku> the pysmb imports are supposed to be runtime optional deps
<Son_Goku> itâs a bug if they are mandatory anywhere
<barry> Son_Goku: what does pysmb.py do?
<barry> (it is installed as part of system-config-printer-common)
<barry> ah, it's imported in newprinter.py, but again wrapped in a bare try/except
<Son_Goku> yep
<Son_Goku> pysmb is the module that actually handles discovery and attachment of printers on a Samba network
<Son_Goku> it should be split out
<barry> it's in probe_printer.py too
<Son_Goku> that package should be Recommends/Suggests, with python3-smbc as a Requires on that package instead of system-config-printer-common
<barry> well, that's indeed one way of handling things: install on demand
<Son_Goku> now I *definitely* need to talk to someone in Fedora about this
<Son_Goku> this is a problem, because weâre not handling this correctly
<barry> i'll relay this to tkamppeter and see if we can come up with something
<Son_Goku> from what I can tell, though, even if it remains in the *-common package
<seb128> barry, Son_Goku, would splitting that out mean that samba discovering would work out of the box?
<Son_Goku> it should be fine, because when pysmb import fails, itâll just keep going
<seb128> +not
<Son_Goku> seb128: if the printers are only available through Samba (which is rare these days), then yes
<barry> seb128: that's what i would think too
<Son_Goku> but most networked printers are available through IPP and JetDirect, and those will work
<seb128> k, I don't know enough about printers to know how common that is
<seb128> would be nice to hear from tkamppeter on the topic
<barry> seb128: i don't know whether it would be acceptable to do what mterry just did for deja-dup, i.e. install on demand.  but then deja was already set up to do that so it was an easy change
<barry> seb128: yes, for sure.  i am going to craft an email to u-d@ about it
<seb128> barry, would we pull that stack in as soon as you open the printer config?
<Son_Goku> the other alternative is to remove system-config-printer entirely, and thatâs a crappy idea
<barry> Son_Goku: or complete the port of samba, but that ain't gonna happen for 16.04 :(
<seb128> barry, because there is no way to know in advance if smb is going to be useful and to know if we should install it
<barry> seb128: yeah, i don't know.
<smb> seb128, I _am_ always useful :-P
<seb128> smb, :-)
<barry> :)
<seb128> sorry for pinging
<barry> smb: can we install you on demand?
<Son_Goku> barry: the FreeIPA guys have been wringing with this issue as well
<barry> i know :(
<smb> barry, there might be a service delay... :)
<barry> :)
<Son_Goku> of course, they also are damn near close to making it so Heimdal isnât required for Samba AD DC, which is awesome
<tkamppeter> seb128, s-c-p should not have any depends/Recommends/Suggests on python-* must be all python3-*, if not something was overlooked. This I could quickly fix.
<barry> tkamppeter: hi!
<barry> tkamppeter: that's not the issue
<tkamppeter> seb128, s-c-p is totally Python3.
<Son_Goku> tkamppeter: I discovered the issue in the Fedora packaging
<Son_Goku> the Ubuntu one is fine
<barry> tkamppeter: the problem is that there is still a transitive Depends on samba-lib and that pulls in python 2
<Son_Goku> well, ish
<seb128> tkamppeter, it's python3-smbc and the python3 part is fine, but it depends on libsmbclient which depends on samba-libs which is the issue
<tkamppeter> seb128, this is a problem the Samba maintainers have to fix.
<barry> tkamppeter: agreed, long term.  but what can we do for 16.04?
<barry> tkamppeter: these are the last two deps keeping py2 on the desktop iso
<Son_Goku> tkamppeter: s-c-p already is capable of running without python3-smbc installed
<Son_Goku> as the samba functionality is an optional runtime dependency
<Son_Goku> the overwhelming majority of networked printers expose via IPP and JetDirect rather than Samba, so it shouldnât be a problem to downgrade python3-smbc to Suggests like Fedora did
<tkamppeter> seb128, as the Samba dependency is probably hard-defined and not be removable for the LTS, I would degrade the python3-smbc to Suggests:.
<seb128> tkamppeter, that was the suggestion, we just wanted to check what you think
<tkamppeter> seb128, who wants to connect to a Windows printer has to pull the full-fledged Python2 from Universe then.
<barry> tkamppeter: still main, but yes
<barry> tkamppeter: so you're happy with a change that just demotes python3-smbc?
<tkamppeter> seb128, I would very very much appreciate if the Samba guys could sort out the problem (hope it does not need a rewrite of Samba), as there should be many users who want to access a printer on Windows.
<seb128> barry, I wonder if that's really a win to drop it from the iso if it means dropping useful features and still have in in main/supported and pulled it in on the first occasion for a non trivial number of users
<tkamppeter> seb128, can you ask the Samba guys (or report a bug) asking them to lift this Python2 dependency, assuring that python3-smbc does not pull Python2?
<barry> seb128: i think it's still useful because it reduces the size and complexity of the iso by not having two full python runtimes
<tkamppeter> seb128, or did you already talk with them and they told it is not possible?
<seb128> tkamppeter, barry seems to say that it's too much work to be done this cycle
<tkamppeter> barry, are you one of the Samba maintainers?
<barry> yes, especially because upstream still hasn't fully embraced py3, so it's not just a smop
<barry> tkamppeter: i am not
<barry> but i have talked to jelmer, petr, and others who are trying to get upstream samba on board
<barry> i guess the more people knocking at their door the better ;)
<tkamppeter> seb128, I cannot do anything else then demoting dependencies. And I cannot introduce new code which makes Samba unneccessary for accessing printers on Windows. Ans so we have only Samba which is still a Python2-based solution.
<tkamppeter> seb128, s-c-p is Py3, but Samba is still Py2, so either no Windows printer/server access or Py2 pull-in.
<seb128> tkamppeter, right
<barry> tkamppeter: right
<tkamppeter> seb128, meaning that I can only demote python3-smbc to Suggests.
<seb128> barry, not my call at the end but I think that loosing the "working out the box" experience is costing more than having some python binaries on the iso
<tkamppeter> seb128, barry, seems that the last Py2-based core part of our OS is Samba.
<barry> seb128: if it's not tkamppeter's call, i'm not sure who's it is.  obviously i want this change, but i cannot gauge how onerous it will be on our users
<barry> tkamppeter: yes for sure it is the biggest blocker right now
<barry> tkamppeter: how can we move forward?
<tkamppeter> barry, is there no way of splitting binary packages to get rid of the Py2 dependency?
<seb128> barry, I don't know,  we don't really have a product manager to define the cost/benefit there
<tkamppeter> barry, if s-c-p calls Samba code to do its Windows printer discovery and access, is then actually Py2 code executed?
<barry> tkamppeter: my understanding is that there isn't.  i actually asked jelmer about this, but he told me (iiuc) that there are calls back into the python runtime from c code, so a split (as i did with libpeas) isn't feasible
<barry> tkamppeter: i don't think so.  i think the problem is that there are too many intertwined dependencies in samba-libs, and *that's* the thing that needs upstream support to unwind.  so anything that ultimately depends on samba-libs will pull in py2
<barry> even if it doesn't need it :(
<Son_Goku> barry: is the samba-libs stuff not split out into a python-samba package?
<Son_Goku> err, the python stuff in samba-libs
<tkamppeter> barry so the program flow is more or less Py3 (scp) -> C (libsmbclient) -> Py2?
<Son_Goku> crap, that isnât possible
<Son_Goku> why are normal C libraries linking to libpython2.7?!
<barry> tkamppeter: no, at runtime it shouldn't cross back into py2
<Son_Goku> tkamppeter: some of the libraries link to it, but s-c-pâs usage does not invoke py2 at all
<kyrofa> Logan, re: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815205#10 . Is that a texinfo bug, then, you think? Or misuse by sbcl?
<ubottu> Debian bug 815205 in src:sbcl "sbcl: FTBFS due to TeX error" [Serious,Open]
<Son_Goku> otherwise it would crash
<Son_Goku> because the py2 interpreter library would be loaded into the same area the py3 one was
<barry> hmm.  i wonder:
<barry> % apt-cache show samba-libs | grep -i Depends
<barry> Depends: libldb1 (<< 2:1.1.25~), libldb1 (>> 2:1.1.24~), libacl1 (>= 2.2.51-8), libattr1 (>= 1:2.4.46-8), libbsd0 (>= 0.5.0), libc6 (>= 2.15), libcap2 (>= 1:2.10), libcups2 (>= 1.6.0), libgnutls30 (>= 3.4.2), libldap-2.4-2 (>= 2.4.7), libpam0g (>= 0.99.7.1), libpopt0 (>= 1.14), libpython2.7 (>= 2.7), libtalloc2 (>= 2.1.0), libtdb1 (>= 1.3.0), libtevent0 (>= 0.9.25), libwbclient0 (= 2:4.3.3+dfsg-1ubuntu3), python-talloc (>= 2.0.6),
<barry> zlib1g (>= 1:1.1.4)
<barry> doko recently uploaded a python3-talloc.  i wonder if we can create a samba-libs-py3 that is exactly the same but deps on python3-talloc and not libpython2.7.  i honestly have no idea what libsmbclient would do with that
<barry> tkamppeter: do you know how i could test the windows printer discovery if i don't have a windows printer on my network?
<smoser> cyphermox, you are right about multipath and lvm and such.
<Son_Goku> barry: unfortunately, same sadness hereâ¦ http://fpaste.org/332250/93393314/
<smoser> going to have to learn more to do that.
<tkamppeter> barry, yes. You simply need to run a Samba server on a Linux machine. Have CUPS queues on your Samba server and share them. Then they are also shared by the Samba server, as Windows printers.
<barry> tkamppeter: i see, thanks.  let me do some more investigation.  i'll ping or file a bug if/when i learn more
<tkamppeter> barry, OK.
<barry> i just want to see if depends'ing samba-libs on python3-talloc is a feasible option
<barry> (well samba-libs-py3 or some such)
<bdmurray> xnox: Could you have a look at bug 1550823?
<ubottu> bug 1550823 in mdadm (Ubuntu Xenial) "checkarray doesn't work with sh = dash" [High,Triaged] https://launchpad.net/bugs/1550823
<cyphermox> smb: I think we should ask doko and lamont about the bind9/dhcp stuff; probably reverting the removal of the -export libs, which presumably also built with --disable-epoll would be good enough to let everything work correctly
<cyphermox> lamont: FWIW; I'm talking about bug 1551351
<xnox> bdmurray, ok
<ubottu> bug 1551351 in isc-dhcp (Ubuntu Xenial) "dhclient does not renew leases" [High,Confirmed] https://launchpad.net/bugs/1551351
<xnox> bdmurray, please subscribe foundations bugs to s390-zfcp
<xnox> bdmurray, for MIR
<lamont> cyphermox: see also debian/experimental for what mgilbert is doing with dhcp
<smb> cyphermox, ok, yeah I was going to ask doko but he does not seem to be around today
<cyphermox> ah?
<lamont> it was his recommendation to drop the export libs, iirc
<cyphermox> nothing appears in exp for isc-dhcp...
<cyphermox> at least, according to tracker.d.o
<cyphermox> lamont: did you see that bug before?
<lamont> 9.10 was originally an upload to experimental (9.10.0rc2 iirc), which then FF finally got me off my butt to upload 9.10 to experimental(for dhcp coord) and xenial (9.10.3.dfsg.P2-{1..4} because I sucked)
<lamont> I have not seen that bgu
<lamont> and, tbf, core-dev work is all non-core hours for me
<cyphermox> seems like the removing export bit might be wrong
<cyphermox> lamont: oh, I'm not asking you to fix it, just you know better than me about this stuff on account of maintaining these packages
<lamont> the goal (which upstream adopted) was to stop shipping 2 copies of the shared libs
<cyphermox> ok
<lamont> old isc-dhcp shipped a copy of the library source in the dhcp source, and we finally illed that off, and bind now ships all of it... the ultimately-correct path is probably going to be one that lets us deliver one shlibset, even if it means a runtime option or such craziness to toggle behavior, rather than compile-time switch
<smb> lamont, There is just some other discussion that sounds like upstream shipped bind9.10 before dhcp could handle all the goodness
<smb> lamont, https://lists.isc.org/pipermail/bind-users/2015-February/094640.html
<lamont> smb: I think so.
<cyphermox> hey, this is over a year old
<smb> cyphermox, oops
<lamont> OTOH, mgilbert (of isc-dhcp maintainerhood for debian) wants to go this route, and I think it'll have issues befroe _their_ freeze, so...
<cyphermox> let's see how fedora deal with it, if it's using export, then I'll revert the change
<lamont> cyphermox: bind9.10 first landed in xenial about tue 23rd Feb.  has never landed in sid
<smb> cyphermox, I somehow missed the date part completely
<lamont> cyphermox: please also get mgilbert's (oftc) input
<cyphermox> smb: well, I'm saying over a year ago because both 4.3.2 (where this started happening according to the ML) and 9.10 where released somewhere in feb 2015
<lamont> actually "gilbert" on oftc iirc
<lamont> cyphermox: gilbert is co-maint on bind9, and part (all??) of the maint team for isc-dhcp, on debian.
<smb> cyphermox, Yeah, and it so much matched what I saw that I did not wonder about its age
<cyphermox> pinged him
<cyphermox> heh
<smb> cyphermox, just found a vm which I have not updated since dhcp broke, which shows it (dhclient to be in a poll_schedule_timeout instead of a futex_wait_(something)). I can leave that as is if we need something to compare to
<cyphermox> the fact that it writes futex_wait_xyz doesn't mean much
<cyphermox> here there's one thread in futex wait, one thread in epoll_wait, etc.
<smb> cyphermox, ok, maybe means only its different. would the fact that for the new case I did a strace -p <pid> -ff and that also showed only one line of doing a futex wait call
<smb> mean anything?
<cyphermox> means you should have different files on disk too, ending in the pid..
<smb> cyphermox, iirc in the new world there would only be one (no other thread)... but give  me a min I am installing a second vm locally to have both worlds in parallel
<cyphermox> why should there just be one thread/
<cyphermox> ?
<smb> problem might be wait time related as other pids seem to show up only when there is activity
<cyphermox> well strace will only write stuff when there is activity
<cyphermox> anyway, I don't know enough of dhcp and bind libraries interactions to know what to do about this
<cyphermox> I pinged gilbert on oftc, we'll see if the bug rings a bell
<smb> cyphermox, ok. and thanks
<cyphermox> fwiw; here dhclient works correctly with NM
<cyphermox> I changed my renew time on the router to 5 minutes and I do see things being renewed every 5 minutes
<smoser> hey
<smoser> i typed:
<smoser>  apport
<smoser> on xenial and see
<smoser> $ apport-collect 1552319
<smoser> You need to run 'sudo apt-get install python-apport' for apport-collect to work.
<smoser> are we hoping to make that go to python3-apport ?
<smoser> as
<smoser> 0 upgraded, 26 newly installed, 0 to remove and 10 not upgraded.
<smoser> Need to get 5,265 kB of archives.
<smoser> After this operation, 26.6 MB of additional disk space will be used.
<cyphermox> smb: of course, on fedora they once built isc-dhcp against bind 9.10; and switched back to 9.9, but not explanation why
<smb> cyphermox, heh... so I got the new vm running now and strace dhclient... lets see
<cyphermox> ok
<smb> cyphermox, right, so dns just removed the dynamic hostname of newvm due to not renew the lease. Meanwhile newvm strace -ff showed no activity whatsoever while old(er)vm did renew its lease which also showed up as strace activity
<smb> cyphermox, is NM also using /sbin/dhclient -1 -v -pf <pidfile> -lf <leasefile> -I -df <ipv6leasefile> <interface> still (that does not seem to have changed though) and the main process is in "futex(0x7fb54906b0a4, FUTEX_WAIT_PRIVATE, 5, NULL" ?
<cyphermox> smb: I don't know why that's happening, let's wait for mgilbert to respond, or doko to be around to look into this
<cyphermox> /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /run/sendsigs.omit.d/network-manager.dhclient-eth1.pid -lf /var/lib/NetworkManager/dhclient-fabd6433-ac16-415b-aade-2298001b6f73-eth1.lease -cf /var/lib/NetworkManager/dhclient-eth1.conf eth1
<smb> cyphermox, ok. Just was wondering whether it might be something obvious... I think I add at least that info to the bug report
<cyphermox> another option may be "just" something broken in dhclient-script, I saw a bug on the BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800914 -- that might not be related at all though
<ubottu> Debian bug 800914 in isc-dhcp-client "isc-dhcp-client: dhclient-script fails with /bin/sh=/bin/dash after latest upgrade" [Important,Fixed]
<smb> I guess a lot is possible
<pitti> smb: py3-apport> yes, but we need a working python3-launchpadlib for that; see bug 1153671 for a list of blockers
<ubottu> bug 1153671 in apport (Ubuntu) "Port to python3-launchpadlib" [Low,Triaged] https://launchpad.net/bugs/1153671
<pitti> err, smoser ^
<pitti> smb: sorry, tab fail
<smb> pitti, happens  :)
<pitti> ogra_: so, what's up with /lib64?
<ogra_> pitti, just trying to get you a proper log
<pitti> l
<ogra_> but the board fails again with broken /dev/urandom ... *sigh*
<smoser> pitti, thanks.
<ogra_> pitti, so adding set -x to /usr/share/initramfs-tools/hook-functions the end of my update-initramfs output looks like http://paste.ubuntu.com/15268324/
<ogra_> pitti, the stuff from line 22 to the end shouldnt even be there
<ogra_> (there is no hook that could trigger it)
<ogra_> the former (and actualy last) hook ends at 21
<ogra_> pitti, the script i use is build-initrd.sh from the initramfs-tools-ubuntu-core srouce package (note this isnt cleaned up yet and still has a lot of phone hacks just commented out yet)
<jderose> cyphermox: so from studying syslog, it seems NetworkManager is bringing up networking correctly, just oem-config-firstboot isn't utilizing it. is it possible oem-config-firstboot just isn't loading the ubi-network.py and ubi-wireless.py plugins?
<ogra_> the current call i use is: fakechroot chroot ./build update-initramfs -c -kcore-1234 -v
<ogra_> (in a specifically set up chroot)
<pitti> ogra_: what's the code that corresponds to http://paste.ubuntu.com/15268324/? obviously not the /usr/share/initramfs-tools/hook-functions on xenial?
<pitti> oh, I mis-looked
<ogra_> it is copy_exec mainly ... from that file
<ogra_> (with set -x set)
<pitti> ogra_: and /usr/share/initramfs-tools/hooks/resize ? (that's not on my system); it's allegedly the  thing that failed?
<ogra_> pitti, no, it isnt ... i can remove that one and it will still fail ... it is shipped in initramfs-tools-ubuntu-core
<ogra_> pitti, the lines after line 22 from the pastebin are always executed ... regardless
<pitti> â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦echo "Calling hook ${cs_x}"
<ogra_> i.e. no matter which hooks are there
<pitti> â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦fi
<pitti> â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦${initdir}/${cs_x} && ec=$? || ec=$?
<pitti> that's apparently from there (the ec=1)
<pitti> I just don't see "Calling hook" in the log
<ogra_> because it isnt a full log ...
<ogra_> i need to reboot the board abd start from scratch (cant run update-initramfs anymore because /dev/urandom on the board went crazy)
<pitti> ogra_: can you add set -x to /usr/share/initramfs-tools/hooks/resize ?
<ogra_> pitti, i can just remove the hook and it will still fail the same
<pitti> I mean, that's the one that fails, so that's the one we need to look at, no?
<ogra_> but yeah, if you feel like :)
<ogra_> no
<ogra_> thats a lie
<ogra_> it isnt the hook
<pitti> well, *that* hook can't fail then, does another one fail after that?
<ogra_> it is just that the code that fsails runs after the last hook
<ogra_> let me reboot the board so i get /dev/urandom back
<ogra_> silly stuff ... lsb_release is called but needs urandom ...
<ogra_> pitti, oh, i actually have such a log ... i added set -x to resize earlier
<ogra_> http://paste.ubuntu.com/15267323/
<pitti> ogra_: /dev/urandom -> /dev/zero ? *grin*
<ogra_> haha
<pitti> ogra_: so taht fails on copying /sbin/resize2fs (parted still worked)
<ogra_> pitti, here is a full run with set -x in hook-funtions ...
<pitti> [ -f /lib64/ld-linux-aarch64.so.1 ]
<pitti> so that fails
<zequence> pitti: fonts-droid should be changed to fonts-android?
<ogra_> pitti, here is a full run after rm'ing the resize script http://paste.ubuntu.com/15268536/
<pitti> zequence: no, fonts-noto AFAIK
<ogra_> pitti, the hooks are a red herring ... it is code that runs *after* the hooks
<ogra_> or at the end of the last hook regardless what that is
<pitti> ogra_: yeah, so that fails on chown
<ogra_> right, totally random
<pitti> ogra_: no, it's fails somewhere in copy_exec
<ogra_> right
<pitti> the hooks also call copy_exec or stuff a lot
<ogra_> but only on the last hook
<pitti> [ -f /lib64/ld-linux-aarch64.so.1 ]
<ogra_> yes
<pitti> ogra_: no, it fails in the middle
<pitti> ogra_: I'd bet this is a fakechroot bug on arm64, needing an update for current glibc
<ogra_> pitti, search for lib64 in either of th logs
<pitti> there's a quadzillion __xstat* calls that need to be implemented
<ogra_> it is only called at the very end once
<pitti> unless the symlink is actually broken
<pitti> (or doesn't exist)
<pitti> [ -e /lib64/ld-linux-aarch64.so.1 ]
<zequence> Right, saw the bug report now. Going to make the changes now
<pitti> that does work
<ogra_> pitti, how does that work, there is no /lib64 dir anywhere
<pitti> ogra_: my recommendation: run the whole thing under strace, and then we compare what stat() says
<ogra_> oh my
<pitti> ogra_: err, what?
<ogra_> that will be gigabytes of logs data
<pitti> ogra_: well, if there's indeed no /lib64, that explains the stat failure indeed
<ogra_> pitti, ubuntu (nor debian) have ever had /lib64
<pitti> by why is the dir missing?
<pitti> wut?
<pitti> ogra_: no, it must be there
<ogra_> no
<pitti> lrwxrwxrwx 1 root root 32 Feb 17 00:01 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.21.so
<ogra_> oh
<ogra_> oh !
<pitti> that's glibc/linker ABI
<ogra_> so why dont we have it on arm64
<ogra_> hah
<cjwatson> yes, the dynamic linker has historically been in /lib64 on that arch even though nothing else is
<cjwatson> but that's totally arch-specific
<cjwatson> no reason to carry it over to arm64
<cjwatson> or not necessarily a reason; I don't have the linker paths for all arches in my head
<pitti> well, the point is, copy_exec() should mkdir it if it isn't there
<ogra_> ubuntu@localhost:~$ uname -m
<ogra_> aarch64
<ogra_> ubuntu@localhost:~$ ls /|grep lib
<ogra_> lib
<ogra_> ubuntu@localhost:~$
<ogra_> cjwatson, well, there is that armhf hackery that adam did in mkinitramfs for the linker ... i wonder if we need something like that for arm64
 * ogra_ just got some food ... back in 10-15min
<pitti> + copy_file library /lib64/ld-linux-aarch64.so.1
<pitti> so it ceratinly *tries* to copy the file, but if that file doesn't even exist, then we need to debug back how it got that name
<ogra_> right
<pitti> /lib64 isn't hardcoded in either i-t or i-t-u-core
<ogra_> no, it gets it from soe ldd or some such
<ogra_> *some
<pitti> â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦nonoptlib=$(echo "${x}" | sed -e 's#/lib/\([^/]*/\)\?\(tls\|i686\|sse2\|neon\|vfp\).*/\(lib.*\)#/lib/\1\3#')
<pitti> that's the first occurrence of /lib64, in ${x}
<pitti> and that's from a line in ldd
<ogra_> yeah
<pitti> ogra_: what's the output of ldd /usr/lib/initramfs-tools/bin/wait-for-root ?
<pitti> ogra_: I think that's the exec it's currently copying when /lib64 appears
<ogra_> root@localhost:/initramfs-tools-ubuntu-core-0.7.20# ldd build/usr/lib/initramfs-tools/bin/wait-for-root
<ogra_> 	linux-vdso.so.1 =>  (0x0000007fa9e20000)
<ogra_> 	libudev.so.1 => /lib/aarch64-linux-gnu/libudev.so.1 (0x0000007fa9de8000)
<ogra_> 	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007fa9c9f000)
<ogra_> 	/lib/ld-linux-aarch64.so.1 (0x0000005570feb000)
<ogra_> 	libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007fa9c73000)
<ogra_> no lib64
<pitti> ldd /lib/x86_64-linux-gnu/libc-2.21.so
<pitti> sorry
<pitti> ldd /lib/aarch64-linux-gnu/libc-2.21.so
<ogra_> root@localhost:/initramfs-tools-ubuntu-core-0.7.20# ldd build/lib/aarch64-linux-gnu/libc.so.6
<ogra_> 	/lib/ld-linux-aarch64.so.1 (0x0000005562908000)
<ogra_> 	linux-vdso.so.1 =>  (0x0000007f8406d000)
<ogra_> root@localhost:/initramfs-tools-ubuntu-core-0.7.20# ldd build/lib/ld-linux-aarch64.so.1
<ogra_> 	statically linked
<pitti> ogra_: can you add some extra echo/output of ldd  into hook-functions:copy_exec()?
<ogra_> what exactly ?
<pitti> somewhere in copying /usr/lib/initramfs-tools/bin/wait-for-root the transitive ldd output stumbles over /lib64
<pitti> for example, here:
<pitti> â¦â¦â¦â¦â¦â¦â¦â¦for x in $(ldd "${src}" 2>/dev/null | sed -e '
<pitti> ...
<ogra_> hmm
<pitti> do that instead:
<pitti> ldd_out=$(ldd ...)
<pitti> echo "--------"
<pitti> echo "ldd output of ${src}:"
<pitti> echo "$ldd_out"
<pitti> for x in $ldd_out
<ogra_> i wonder if it is actually th sed call that turns  /lib/aarch64-linux-gnu/ into /lib64 in the end
<ogra_> by stipping out chars
<ogra_> will add, but i need to quickly finish dinner ... gimme a bit
<pitti> ogra_: right, hence my proposal to show what that actually does, for each binary
<ogra_> yeah
<pitti> ogra_: as it's not entirely obvious to me
<pitti> ogra_: ok, have dinner, I need to make a phone call and pack my basketball stuff
<ogra_> k
<cyphermox> jderose: yes, exactly, will look in a bit
<jderose> cyphermox: awesome, thanks!
<pitti> ogra_: err, you did the ldd "outside" the fakechroot, right? that might not be the same
<ogra_> no no ... all fine ... fakechroot is called at the very top level
<ogra_> hmm, or not
<ogra_> there is some issue with the syntax ...
<ogra_> Adding binary /sbin/parted
<ogra_> + cp -pP /sbin/parted /var/tmp/mkinitramfs_4KkPDA//sbin/parted
<ogra_> + /usr/bin/ldd /sbin/parted
<ogra_> ldd: /sbin/parted: No such file or directory
 * ogra_ scratches head
<ogra_> a line above it copies parted but ldd doesnt find it ...
<ogra_> http://paste.ubuntu.com/15268819/
<ogra_> it seems it doesnt hit that code path at all
<ogra_> pitti, how did you get the idea it is wait-for-root btw ? i dont see it there anywhere
<ogra_> (i see it at the very start of the run)
<ogra_> oooh !!!
<ogra_> ignore my former comment i'm blind :P
<ogra_> it is indeed wait-for-root that has /lib64/ld-linux-aarch64.so.1 in its ldd output
<ogra_> see lines 384, 394 and 400 of the last paste
<ogra_> sooo ...
<ogra_> lets see what happens if i create /lib64 in the chroot and copy the linker there ;)
<davmor2> ogra_: wow that is impressive touch typing ;)
<pitti> ogra_: bazinga!
<ogra_> http://paste.ubuntu.com/15268877/ ...
<ogra_> + echo Building cpio /boot/initrd.img-core-1234.new initramfs
<ogra_> Building cpio /boot/initrd.img-core-1234.new initramfs
<ogra_> \o/
<pitti> ogra_: so the only thing that's missing is an effing mkdir -p?
<ogra_> and a cp
<ogra_> after all it wants to pull /lib64/ld-linux-aarch64.so.1 from /lib64
<ogra_> but i can easily add that to the build script
<pitti> ogra_: oh, you mean nothing copies ld.so into the chroot?
<ogra_> it comes from /lib
<pitti> ogra_: well, if you don't have /lib64 in a real aarch64 xenial system, then it seems something went wrong with linking wait-for-root?
<ogra_> but there is no /lib64 at all
<ogra_> yeah
<ogra_> who owns that ?
<ogra_> ah
<ogra_> initramfs-tools-bin
<pitti> wait-for-root: wait-for-root.o
<pitti> â¦â¦â¦â¦â¦â¦â¦â¦$(CC) $(LDFLAGS) -o $@ $< $(UDEV_LIBS)
<pitti> UDEV_LIBS = $(shell $(PKG_CONFIG) --libs libudev)
<xnox> apw, could you please promote s390-zfcp from universe to main? MIR approved -> https://bugs.launchpad.net/ubuntu/+source/s390-zfcp/+bug/1552218
<ubottu> Launchpad bug 1552218 in s390-zfcp (Ubuntu) "[MIR] s390-zfcp" [Medium,Fix committed]
 * cyphermox -> lunch
<pitti> ogra_: can you check that pkg-config? maybe that brings in the /lib64
<ogra_> you are assuming i have the source here :P
<pitti> ogra_: gcc -g -Wall -O2    -c -o wait-for-root.o wait-for-root.c
<pitti> hm, no, not really
<pitti> (from https://launchpadlibrarian.net/237016603/buildlog_ubuntu-xenial-arm64.initramfs-tools_0.122ubuntu3_BUILDING.txt.gz)
<ogra_> that doesnt look like there is any pkg-config
<pitti> and gcc  -o wait-for-root wait-for-root.o -ludev
<pitti> right
<pitti> ogra_: OOI, does ldd of libudev.so have any /lib64 stuff? or any other libraries in /lib ?
<ogra_> lets see
<pitti> seems odd to not have /lib64 but things linking to it
<pitti> ogra_: so, to sum up, you have a h4ck1sh workaround to at least continue experiments, but we haven't really solved the mystery yet
<ogra_> root@localhost:/initramfs-tools-ubuntu-core-0.7.20# ldd build/lib/aarch64-linux-gnu/libudev.so.1
<ogra_> 	linux-vdso.so.1 =>  (0x0000007f85daf000)
<ogra_> 	libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f85d4c000)
<ogra_> 	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f85c03000)
<ogra_> 	/lib/ld-linux-aarch64.so.1 (0x000000555f57c000)
<pitti> ok, so that's not it
<ogra_> pitti, not more hackish than the rest of the script currently, so i'm fine :)
<pitti> ogra_: touchÃ©
<ogra_> i need to clean up all that mess anyway :)
<ogra_> its all still half touch ... which required a lot more hackery
<ogra_> i guess i can cut it down to ten lines in the end ... or some such :)
<pitti> ogra_: it might be worth a try whether initramfs-tools from -proposed is any different (toolchain change or what not)
<ogra_> but that wait-for-root is definitely broken
<pitti> ogra_: I suppose if you try to start wait-for-root it crashes?
<pitti> instead of getting an "Usage:" help
<ogra_> nope
<ogra_> it waits properly
<ogra_> root@localhost:/initramfs-tools-ubuntu-core-0.7.20# time build/usr/lib/initramfs-tools/bin/wait-for-root /dev/mmcblk0p1 10
<ogra_> real	0m10.040s
<ogra_> ...
<ogra_> seems to work just properly
<ogra_> i guess the linker is clever enough to translate it ?
<ogra_> just not under fakechroot ?
<pitti> ogra_: hm, maybe, that's the bit I'm not familiar with
<pitti> ogra_: strace is your friend :)
<ogra_> yeah
<pitti> you can also see how fakechroot mangles the paths
<ogra_> well, let me apply the workaround and get the package ready so i unblock the others :)
<pitti> ogra_: sorry, need to leave to basketball now
<ogra_> pitti, thanks so much for leading me the right way
<pitti> ogra_: I'll be back around 22:45, and will check IRC again
 * ogra_ hugs pitti 
 * pitti hugs ogra_
<ogra_> i'll be fine now
<ogra_> wait-for-root under fakechrot is fine too
 * ogra_ uploads
<nacc_> Pharaoh_Atem: any experience debugging pcre jit :)
<nacc_> Pharaoh_Atem: I think gdb doesn't really like doing it, as functions tend to disappear
<Pharaoh_Atem> nacc_: remember when I said earlier about this bug making me want to cry?
<nacc_> Pharaoh_Atem: :)
<nacc_> Pharaoh_Atem: well, i've got the breakpoitns and stuff working, i can see the value flip
<nacc_> Pharaoh_Atem: did you see my comment from last night?
<nacc_> we do have a workaround of sorts
<Pharaoh_Atem> I'm extremely tempted to just say fuck it and shut off pcre.jit
<nacc_> Pharaoh_Atem: i'm not sure where the bug is yet, though
<Pharaoh_Atem> that's true
<nacc_> Pharaoh_Atem: because if it is in pcre, we do need to fix it, i'd say :)
<Pharaoh_Atem> damn it
<Pharaoh_Atem> you're right :(
<nicolas17> https://wiki.ubuntu.com/ is down
<nacc_> Pharaoh_Atem: ok, so in the short-term, i'm  happy to push a debdiff to use --process-isolation for twig's tests, but then three other tests fail ... http://paste.ubuntu.com/15269619/
<nacc_> Pharaoh_Atem: any ideas?
<mwhudson> infinity: this time for sure (?) https://launchpad.net/~mwhudson/+archive/ubuntu/go16-trusty/+packages
<slangasek> nacc_: is this run-tests.php script not part of the source for php-imagick?
<nacc_> slangasek: it's generated during the build
<nacc_> slangasek: i've got further iwth phpunit again ... i'm a bit worried it's a racy failure
<nacc_> that is run-tests.php happens to not show it
<nacc_> but phpunit does
<nacc_> as it only hpapens sometimes when i run the tests in question manually
<nacc_> slangasek: so it's not available in the autopkgtest unless we re-run configure (or i could package it up, i guess, but that doesn't seem very clean to me)
<slangasek> nacc_: ok, so one of the options for debian/tests/control is to require a source package build
<slangasek> I don't remember the syntax offhand
<slangasek> but if you have a generated script that comes from the source and is only used for the test suite, that's the right way to do it, not packaging it up
<nacc_> slangasek: ok, that's what i was tempted to do ... but i don't want to just paper over a possible real error
<nacc_> i'm debugging it now
<nacc_> slangasek: for twig, i think we're going to need to do a patch for the short-term, as i've got bugs filed with upstream, but don't know how to debug it much further on my own
<rbasak> Restriction: build-needed
<nacc_> slangasek: will post a ubuntu4 debdiff
<slangasek> nacc_: ok
<rbasak> """
<rbasak>     Please use this considerately, as for large builds it unnecessarily
<rbasak>     builds the entire project when you only need a tiny subset (like the
<rbasak>     tests/ subdirectory). It is often possible to run ``make -C tests``
<rbasak>     instead, or copy the test code to ``$ADTTMP`` and build it there
<rbasak>     with some custom commands.
<rbasak> """
<rbasak> s/Restriction/Restrictions/
<rbasak> HTH
<nacc_> rbasak: ah thanks ...
<nacc_> slangasek: so the other thing is that debian made this chagne ... and it's unclear if it was a good idea in the first place :)
<nacc_> ongoing discussions about that :)
<nacc_> slangasek: so should i be putting in versioned depenendencies on phpunit now? so taht we get the one from proposed that depends o php-xml?
<pitti> ogra_: ah, no further discussion here, any luck?
<pitti> apw: binNEWed the kernel FYI
 * pitti cleans up kernel NBS while he's at it
<apw> pitti: thanks :-)
<ogra_> pitti, all good, the binaries just landed in the archive
<ogra_> (well, still in proposed, but they shoould migrate soon)
<nacc_> rbasak: slangasek: fyi, it's Restrictions: build-needed (note need the s)
<slangasek> nacc_: no, we shouldn't be declaring versioned dependencies on phpunit - though the new version of php-cli should declare a versioned Breaks against the old phpunit
<nacc_> slangasek: ok, i'll update my debdiff for twig then ... and send a new debdiff for php-defaults?
<nacc_> Pharaoh_Atem: am i right in reading the php builds that ZTS is off in debian/ubuntu?
#ubuntu-devel 2016-03-03
<Son_Goku> nacc_: yes, thereâs no ZTS in debian/ubuntu
<Son_Goku> as far as I can tell
<Son_Goku> I havenât been testing with php-zts
<nacc_> Son_Goku: ok, just checking
<nacc_> slangasek: i think i figured out the php-imagick bug, but i don't know how to fix it...it's either a bug in libgomp or in imagemagick when compiled with openmp support. I built a version w/o it and no segfaults... NOte that just setting the environment variable or the policy.xml value isn't sufficient, it seems like imagemagick still uses openmp even then.
<nacc_> kirkland: fyi --^
<nacc_> slangasek: maybe it's not that dire, actually -- i wonder how the tests do w/o imagemagick fully installed (note this means there is still this relatively (?) serious bug in imagemagick, but it is independent of php-imagick, at least). Testing that now
<Pharaoh_Atem> nacc_: so this happened to me when I ran the Twig test with process isolation and jit switched on: http://fpaste.org/332583/76723145/
<Pharaoh_Atem> the problem repeats itself when I turn pcre.jit off, so I assume it doesn't have anything to do with pcre jit
<cpaelzer> good morning
<pitti> Good morning
<pitti> ogra_: yay!
<pitti> ogra_: I saw a component-mismatches email fly by last night about fakechroot wanting to go to main, btw
<dholbach> good morning
<ricotz> xnox, cjwatson, hi, regarding https://blueprints.launchpad.net/ubuntu/+spec/core-1403-hidpi-boottime , you might want to have a look at https://launchpad.net/~ricotz/+archive/ubuntu/staging/+sourcepub/6167873/+listing-archive-extra
<phatina> cjwatson: Hi, can you have a look at this package, please? https://phatina.fedorapeople.org/deb/volume-key/ If you recall from yesterday, I was wondering, how to properly split 1 source package into several *.deb packages...
<phatina> cjwatson: what I get now is: 2 *.deb packages, but there is only /usr/share/doc/* in both of them
<phatina> all: anyone, who can guide how to properly split one tarball into several deb packages, please?
<marlinc> Is there something like dh_make but for non source code package? In this case its simply a package containing a set of shell scripts
<xnox> ricotz, given that 2x highdpi plymouth theme has regressed, i'm interested in proper highdpi plymouth.
<flexiondotorg> Is PowerPC supposed to be able to submit bugs via apport?
<flexiondotorg> https://bugs.launchpad.net/ubuntu-mate/+bug/1547568
<ubottu> Launchpad bug 1547568 in ubuntu-mate "apport-collect 16.04 not working" [Undecided,New]
<pitti> flexiondotorg: in principle yes, but a screenshot of the error would be helpful
<pitti> this is a rather vague description
<ricotz> xnox, would be great if this could still make it in, afaics this upstream solution works here (this snapshot ignores the needed soname bump due api changes, the symbols used by mountall are untouched), rstrode got pinged in that regard too
<Laney> pitti: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1549403 FFe might be up your street to review
<ubottu> Launchpad bug 1549403 in cloud-init (Ubuntu) "[FFe]: improvements and fixes to cloud-init networking" [Undecided,New]
<pitti> Laney: queueing
<Laney> r0x0r!
<pitti> Laney: well, I'd call myself biased as I've lobbied for fixing this for ages; but I'll try to stay objective wrt. risk assessment :)
<Laney> :)
<phatina> all: I have a problem with splitting tarball into several deb packages: in control file, I have 3 packages stated, corresponding *.dirs *.install and the packages contain only /usr/share/doc/* not any binary, library, headers...
<phatina> all: is there anyone, who is willing to have a look at this?
<pitti> Laney: followed up
<Laney> pitti: thanks
 * Laney is occasionally checking the release bugmail
<Laney> pitti: and hi, don't think I said that today
<pitti> Laney: inded, good day!
<pitti> Laney: KDE mass upload> autopkgtest queues just recovered from the perl hit and are still aching under the load of Qt from Ubuntu and silos simultaneously
<pitti> I accidentally killed some silo test request this morning; I'll put them back, but that'll add another 100 or so
<Laney> fun
<pitti> Laney: FYI, I split the queus between ubuntu, ppa, and upstream now; so none can starve the other two
<Laney> indeed K* are already being tested
<pitti> see http://autopkgtest.ubuntu.com/running.shtml
<pitti> Laney: yes, for Qt
<Laney> right
<LocutusOfBorg> ok I might be stupid, but what is now preventing fonts-android from migrating? at least, ubuntustudio-desktop* shouln't be listed as a problem anymore
<LocutusOfBorg> Trying easy from autohinter: fonts-android/1:6.0.1r16-1 renpy/6.99.8+dfsg-2 request-tracker4/4.2.12-5 ubuntukylin-theme/1.5.1
<LocutusOfBorg>     * amd64: ubuntustudio-default-settings, ubuntustudio-desktop, ubuntustudio-desktop-core
<LocutusOfBorg> I can see the default-settings as a problem
<zequence> LocutusOfBorg: Yes, we haven't changed that yet
<zequence> Let me do that right now.
<LocutusOfBorg> yes, thanks
<LocutusOfBorg> but I still see the fixed package in the nasty list
<Laney> Might be because it depends on the default-settings
<zequence> Uploaded. Will check in later to see that it built. But, that package is going to be broken for us for a little while. I'm instructing our next project lead how to make changes to it, so he will finish up the rest.
<zequence> I think that was the last dependency to fonts-droid anyhow
<LocutusOfBorg> thanks Laney zequence
<LocutusOfBorg> I hope to see it migrate
<cjwatson> phatina: hmm, looks OK from a quick scan through the packaging, do you happen to have a build log?
<LocutusOfBorg> where is doko when needded? :)
<LocutusOfBorg> Package: libpurple-dev
<LocutusOfBorg> Section: libdevel
<LocutusOfBorg> Architecture: all
<LocutusOfBorg> damn, multiarch broken
<LocutusOfBorg> the pc file is shipped on lib/x86_64 on every arch
<LocutusOfBorg> going to change all to any and reupload
<Laney> DOKOOOOOOOOOOOOOOOOOOOooooooooooOOOOOOOOoooooOOOOOo
<LocutusOfBorg> I lost 15 minutes trying to understand why pidgin-data was failing
<LocutusOfBorg> and rebuilding on i386 pidgin was fine, because the arch:all was good on that arch :)
<phatina> cjwatson: yes, I have: https://phatina.fedorapeople.org/deb/volume-key_0.3.9-1_amd64.build
<phatina> cjwatson: I can't find dh_install in there
<phatina> cjwatson: that may be the problem, right?
<Mirv> pitti: for some reason the autopkgtest retry request does not finish loading, just hangs in there (after loggin in phase), despite several attempts
<cjwatson> phatina: that's a pointer in the direction of the problem, but you shouldn't need to call dh_install explicitly; for some reason dh is deciding that there are no .install files so it doesn't need to call dh_install
<cjwatson> phatina: can you double-check that those .install files really exist in the environment where the build is running?  it's not something like those files not having been added to a VCS?
<phatina> cjwatson: hmm, those files need to be added to bzr?
<cjwatson> phatina: it looks like you're using bzr builddeb so it would be worth checking that "bzr status" doesn't show those files as unknown
<cjwatson> phatina: if you're using bzr builddeb then you need to add them to bzr, yes
<phatina> cjwatson: yes, they aren't added yet
<cjwatson> there we go
<pitti> Mirv: ah, let me look; we got some SSL restriction settings yesterday, maybe they broke something
<phatina> cjwatson: ok, I'll need to build the *.deb without bzr
<phatina> cjwatson: thanks for the tips
<cjwatson> np
<LocutusOfBorg> zequence, fonts-android migrated, hurray
<LocutusOfBorg> thanks!
<LocutusOfBorg> boinc is not migrating because of: boinc-client-nvidia-cuda/amd64 unsatisfiable Depends: nvidia-modprobe
<LocutusOfBorg> this is false
<LocutusOfBorg> did something broke somewhere? I didn't change anything on that side
<pitti> LocutusOfBorg: boinc is universe, nvidia-modprobe is multiverse
<pitti> i. e. you apparently added that as a new dependency, but universe packages must not depend on multiverse
<LocutusOfBorg> pitti, the problem is that the previous version migrated, with the same set of dependencies
<LocutusOfBorg> well, lunch and investigation :)
<pitti> LocutusOfBorg: yeah, we enabled component checking in britney recently
<pitti> but it would have been a component-mismatch anyway before
<pitti> nvidia-modprobe | 361.28-1         | unstable/contrib         | source, amd64, armhf, i386, ppc64el
<pitti> so it could probably go to universe
<pitti> or boinc needs to go to multiverse
<pitti> not sure, but that smells RC to me in Debian too -- a main package depending on contrib
<Mirv> pitti: I'll try again if you find some fixable issue
<pitti> Mirv: happens for me too, I just don't know what's up yet
<pitti> (looking at it)
<Mirv> ok
<pitti> I can't reproduce it in my juju-local instance
<pitti> Mirv: ok, should work again, but please don't hit the buttons yet, I'm still cleaning up
<LocutusOfBorg> thanks pitti
<Mirv> ok :)
<LocutusOfBorg> pitti, moving Depends to Recommends or Suggests can fix the issue?
<pitti> LocutusOfBorg: suggests is fine, recommends not (as that gets installed by defaultl
<pitti> LocutusOfBorg: or boinc needs to move to contrib in Debian/multiverse in Ubuntu
<pitti> whic is reasonably doable, only boinc-app-seti depends on it
<ginggs> LocutusOfBorg: you shouldn't need to suggest or recommend nvidia-modprobe
<ginggs> LocutusOfBorg: in debian the nvidia driver depends on it, and in ubuntu the required drivers are supposed to be loaded at boot
<pitti> robru: we need to remove all pending.json from landing-{050,012,036}, due to some hiccups; where to ask about that again, and where are the file paths to tell webops to delete?
<LocutusOfBorg> the boinc-nvidia has been created to force installation of graphic drivers
<LocutusOfBorg> so moving to suggests is not probably the right thing to do
<LocutusOfBorg> demoting is maybe the best way
<pitti> Mirv: ok, should be all working again, retry away
<lamont> smb: cyphermox I suspect one of you has more info than me from mgilbert?  looks like he'll be adding back in the -export libs, working on it this weekend
<lamont> not sure how that fits with our timeline
<smb> lamont, I did not hear anything but I found out more background about the problem
<smb> and why it works with network-mangler
<lamont> cool.  it'll be sunday at the earliest (and more likely midweek next week) before I can dig into it myself, so hoping mgilbert finishes it up this weekend
 * lamont is going to toss -5 up sometime today/tomorrow, with apparmor and some other simple stuff
<lamont> tjaalton: ^^ did you want me to drop your autoconf thing from that? (it's in the queue already)
<smb> lamont, ok ... meanwhile if you are interested, I am currently writing more detailed findings into bug 1551351
<ubottu> bug 1551351 in isc-dhcp (Ubuntu Xenial) "dhclient does not renew leases" [High,Confirmed] https://launchpad.net/bugs/1551351
<lamont> and already pushed to the main tree, so nm...
<lamont> yeah, I'll read that when I get closer to it
<tjaalton> lamont: it can wait
<cyphermox> lamont: he didn't respond to me
<lamont> cyphermox: ok.  he poked me late last night, pointed at the launchpad bug, and the 2015 email and said he'd be working on -export readd this weekend
<lamont> cyphermox: so we have a clear path forward
<cyphermox> jes
<smb> cyphermox, as a tl;dr update, your case only works because networkmanager runs dhclient in debug/foreground mode
<cyphermox> oik
<lamont> smb: hahaha
<Mirv> pitti: works, thank you
<GunnarHj> pitti: Hi Martin, did you see my question in #ubuntu-desktop?
<pitti> GunnarHj: I did; sorry, backlogged, fighting infrastructure fires
<GunnarHj> pitti: Ok, my thing is not an emergency. Trying to be patient. :)
<barry> pitti: is autopkgtest.ubuntu.com down?
<teward> barry: shows up for me?
<barry> teward: huh
<mitya57> works for me too
<barry> pitti: it could just be the retry button
<barry> (from excuses)
<barry> e.g. https://autopkgtest.ubuntu.com/request.cgi?release=xenial&arch=amd64&package=deja-dup&trigger=deja-dup%2F34.1-1ubuntu3
<pitti> barry: argh, again
<pitti> barry: I just had it working again
<pitti> barry: so, it took me over an hour to gracefully shut down everything with a million tests waiting, and I lost a few already
<pitti> barry: so let's wait until the Qt madness is over, and I'll look into it tomorrow
<barry> pitti: ack
<pitti> apparently somethign hangs when talking to the AMQP server
<tsdgeos> do you guys also get a 500 on https://wiki.ubuntu.com/ ?
<teward> tsdgeos: randomly, yes, but it returns as "up" for me right now
<ginggs> mdeslaur: you asked about WINE some time ago, there hasn't been any activity from the 'wine team' since a PPA upload in December. What can I do to help move this along? Assuming the team is no more, is removing the Ubuntu packaging and transitioning to the Debian packaging an option?
<mdeslaur> ginggs: the packaging is completely different, so someone would need to look through it all and add whatever is necessary to do the transition
<mdeslaur> ginggs: I think the best thing is to use the packages in the ppa, perhaps by asking whoever uploaded them if it's good enough for xenial
<mdeslaur> actually, probably too late for xenial, but x+1
<ginggs> msdeslaur: i've been playing with a transitional package in my PPA, i mostly does the right thing, but gets confused by the fact that debian's wine package is :all and ubuntu have wine:i386 and wine:amd64.  Otherwise the packages all have different names
<mdeslaur> the ubuntu package definitely has the advantage that multiple versions can co-exist
<mdeslaur> which is probably desirable for wine
<ginggs> mdeslaur: so does debian's
<ginggs> mdeslaur: at least they have a wine and and wine-developement these days
<mdeslaur> oh, I though they only had stable and development
<mdeslaur> right, but ubuntu can have 1.6 and 1.8, etc.
<mdeslaur> anyway, I have no opinion either way, I don't care much about wine
<mdeslaur> I just wanted to try 1.8
<mdeslaur> either continuing the approach in ubuntu/the ppa, or migrating to debian's packaging, there's work to be done either way
<xnox> pitti, what is /dev/disk/by-dname ? first time i see that, can it be used somehow for the root= arg?
<ginggs> mdeslaur: let me start by trying to contact the team and see if they are still interested in maintaining it
<pitti> xnox: I don't know this at all -- perhaps a typo?
<xnox> i see those links in the initramfs.
<pitti> xnox: or maybe a typo of your's, and you mean by-name/?
<xnox> oh, it looks like something funky maas-ish.
<rbasak> cyphermox: bug 1547206 claims a regression in a multipath-tools SRU I think. Please could you take a look?
<pitti> (but even then, by-name/ doesn't exist either for block devices)
<ubottu> bug 1547206 in multipath-tools (Ubuntu) "Boot stalls on mountall "disk drive not ready" question in multipath-tools >= 0.4.9-3ubuntu7.5" [Undecided,Confirmed] https://launchpad.net/bugs/1547206
<pitti> xnox: ah, maybe they  set up their own udev rules then
<cyphermox> rbasak: yeah, I've already been in contact with tore on that
<rbasak> cyphermox: OK thanks. I'm just triaging and didn't see any response in the bug. Can I mark it Triaged?
<cpaelzer> xnox: I know the by-name thing from s390 - when you create names in multipath.conf they will populate that
<xnox> cpaelzer, that's udev.
<xnox> by-dname looks like stuff that curtin creates
<cyphermox> rbasak: yeah
<pabs3> is there a channel for the wiki.ubuntu.com sysadmins? I found a page that crashes with certain user-agent headers but not with no user-agent header and not with other headers
<robru> pitti, talk to #webops, it'll be /tmp/britney_data/landing-XX-{xenial,vivid}/autopkgtest/pending.json
<pabs3> https://wiki.ubuntu.com/MoroccanTeam/En
<cpaelzer> xnox: ah you really menat "d"name - sorry, I didn't scroll up enough, yeah seems to be curtin related to bug 1477756
<ubottu> bug 1477756 in curtin "storage format provide consistent paths (dname)" [Undecided,Fix committed] https://launchpad.net/bugs/1477756
<robru> pitti: list of directories is always here: https://requests.ci-train.ubuntu.com/static/britney/report.txt
<pitti> robru: ah, thanks
<robru> yw
<mterry> mvo_, for uboot-go, you said you changed source name too?  Is it stuck in NEW?  I don't see the source pkg in LP
<mvo_> mterry: let me check what is going on, might be an upload issue
<mterry> mvo_, you also said you fixed the issues with goconfigparser?  I don't see a new upload there eithe
<mvo_> mterry: yeah, incorrect upload, sorry for that, will fix in a sec, same issue on the other one
<mvo_> too
<robru> pitti: I guess we should think about some sort of admin panel for bileto that allows to delete arbitrary files.
<mvo_> mterry: silly me, -sa was missing, uploaded them again now
<mterry> mvo_, ah.  I do that all the time  :)
<mvo_> mterry: :) thanks again
<Odd_Bloke> Hmm, I'm seeing some strange sysctl behaviour on wily.  I have configuration in a file in /etc/sysctl.d (which was there before boot) that only seems to take effect if I restart the systemd-sysctl service.
<cjwatson> pabs3: #canonical-sysadmin
<pabs3> thanks
<tjaalton> how does one get rid of an obsolete autopkgtest?
<tjaalton> fglrx is blocking xorg-server, while it shouldn't (it'll get removed from the archive instead)
<pitti> tjaalton: you mean fglrx-installer will be removed?
<tjaalton> yes
<pitti> and -updates?
<tjaalton> same
<pitti>  fglrx-updates : Depends: xorg-video-abi-11 but it is not installable or
<pitti> ah
<pitti> tjaalton: so can we remove it now, so that it stops being an rdependency?
<pitti> tjaalton: is the reason "the free driver is good enough now" by any chance?
<tjaalton> pitti: yes. the reason is "there won't be updates anymore, and free driver is good enough for most" :)
<pitti> tjaalton: excellent
<pitti> tjaalton: so, say the word, and I'll kill them
<tjaalton> gogogo :)
<pitti> with fire!
<tjaalton> from xenial
<tjaalton> trusty will still have it of course :)
<tjaalton> tseliot: ^
<tseliot> pitti: yes, we can remove it. I sent a pull request to the kernel team to add some improvements to open drivers for the same reason
<tseliot> (in xenial)
<pitti> *ZAP*
 * pitti watches it explode
<tjaalton> pitti: so in this case, the autopkgtest was in..? not in the package itself at least
<pitti> tjaalton: auto-generated one by autodep8 (DKMS testing)
<tjaalton> I have some pet projects I need to add tests for..
<tjaalton> ah ok
<tjaalton> yeah, so removing the pkg was needed
<tseliot> :)
<pitti> tjaalton: that's what generates a debian/tests/control for sets of similar packages, like lib*-perl, ruby modules, or DKMS packagse
<pitti> so that they don't need to be copied around a bazillion times
<tjaalton> right, ok
<pitti> tjaalton: ofono isn't your fault, I'll hint that away from xorg
<tjaalton> yeah I noticed :)
<tjaalton> was about to kick it
<pitti> yeah, I give it another chance with a retry first
<tjaalton> pitti: thanks!
<pitti> tjaalton: this is a good day :)
<pitti> tjaalton: we can kill the nvidia drivers tomorrow, right?
<tseliot> :D
<pitti> speaking of binary junk, what's the current word on broadcom wifi cards? I haven't followed that for quite a while
<pitti> there've been like 4 drivers in the past 10 years
<pitti> bcm43xx with fwcutter, wl, and the two free ones in staging
<tseliot> I'm not sure
<tjaalton> pitti: yep, a good day indeed :)
<rharper> how would I make a request to have a PPA be allowed to build packages on s390x ?
<cjwatson> rharper: https://answers.launchpad.net/launchpad, and I'm afraid at the moment this is only allowed for PPAs that can be devirtualised (i.e. must only be uploadable to by Canonical employees)
<cjwatson> due to lack of sandboxing
<rharper> cjwatson: ok, thanks for the information;
<xnox> rharper, is this for juju? you should have a canonical-only devirt ppa imho.
<xnox> cjwatson, ^
<nacc> xnox: i believe it's for docker
<xnox> nacc, ah. right.
<xnox> nacc, rharper: maas -> openstack -> scalingstack -> lp is the dependency chain to get that enabled.
<Son_Goku> nacc: so any luck with pcre+php7?
<nacc> Son_Goku: twig now runs/passes the test -- I put in a manual phpunit isolation on the failing test
<nacc> Son_Goku: i've been getting some help from upstream
<nacc> Son_Goku: I do think something is off with the pcre jit code, but not sure what yet
<Son_Goku> I spent a few hours tracing it through gdb, but I got nowhere
<Son_Goku> Iâm setting up a Fedora VM to fiddle with it a bit more, since Remi said it doesnât fail there, and I want to see it pass with pcre.jit=1 myself
<nacc> Son_Goku: yeah, i have it to the point where I'm getting sort of weird results (https://bugs.exim.org/show_bug.cgi?id=1803)
<ubottu> bugs.exim.org bug 1803 in Code "segfault in pcre jit when running twig test suite (PHP7)" [Bug,New]
<nacc> Son_Goku: if you could do that, that'd be great
<Son_Goku> nacc: I couldnât reproduce your error states in my CentOS 7 PHP7 environment
<Son_Goku> I got *different* error data
<nacc> heh
<nacc> Son_Goku: but the same error location?
<Son_Goku> yes
<Son_Goku> itâs the most bizarre thing ever
<Son_Goku> nacc: at this point, Iâm wondering how people expect PHP to ever be consistent about anything?!
<nacc> Son_Goku: what values do you get?
<nacc> Son_Goku: sorry, didn't see if you responded -- what values do you see in centos?
<Son_Goku> nacc: ah one moment
<nacc> Son_Goku: also, keep in mind, compiler differences, etc., might lead to slight differences
<Son_Goku> yeah, I think thatâs the primary effect here
<Son_Goku> nacc: http://fpaste.org/333171/57030506/
<nacc> Son_Goku: ah, aggressive optimization :)
<nacc> Son_Goku: hrm, yeah, so it fails *earlier* with centos7, i think?
<nacc> at pcre_exec time?
<Son_Goku> nacc: yes
<Son_Goku> it looks like it
<nacc> which is perhaps the same issue -- just not noticed at the same time. I think the JIT code is failing to move the offsets on every call
<nacc> but i need to reproduce that
<Son_Goku> this is with php 7.0.4 and pcre 8.32-15.el7 (so 8.32 with a bunch of backported issues)
<Son_Goku> err, backported fixes
<Son_Goku> nacc: yeah, I suspect thatâs the case
<nacc> Son_Goku: any luck setting up a fc vm?
<Son_Goku> nacc: working on it now
<nacc> Son_Goku: cool, keep me posted please
<Son_Goku> most def
<Son_Goku> just finished the install of fc23
<Son_Goku> so rebooting it into new environment to install php7
<oSoMoN> Mirv, FYI: https://bugs.launchpad.net/ubuntu/+source/qtsystems-opensource-src/+bug/1552860
<ubottu> Launchpad bug 1552860 in qtsystems-opensource-src (Ubuntu) "[MIR] qtsystems-opensource-src" [Undecided,New]
<Son_Goku> thank god for oVirt, or Iâd never get anything done
<nacc> Son_Goku: thanks!
<Son_Goku> my pleasure
<Son_Goku> nacc: wellâ¦ it happens in Fedora
<Son_Goku> http://fpaste.org/333217/45703374/
<Son_Goku> annoyingly enough, Remi didnât upload the debuginfo package for php70, so I need to poke him with a stick for those
<Son_Goku> but it did fail differently here, too
<Son_Goku> well, differently ish
<nacc> Son_Goku: that's good!
<nacc> Son_Goku: in that i did backport those patches
<nacc> and it didn't help me
<nacc> and i was worried something else was up
<nacc> but having it not fixed anywhere is good
<nacc> looking at hte trace, ti'll be the same symptoms, last_match will have moved past where the offsets imply and we'll get a negative length calculation, if i had to guess
<Son_Goku> yeah
<Son_Goku> the patch backport was still good to do
<nacc> yep
<Son_Goku> because it minimized the number of conditions
<nacc> ruled some stuff out
<Son_Goku> and besides, pcre is crap, and needs to be fixed
<nacc> :)
<nacc> Son_Goku: since you are the ones that's reproduced it, can you update the pcre bug?
<Son_Goku> now I just want to know wtf Remi is doing that makes it work on his computer
<Son_Goku> nacc: sure
<Son_Goku> on exim?
<nacc> Son_Goku: yeah that'd be good to know for sure
<nacc> yep
<Son_Goku> or on php.net?
<nacc> https://bugs.exim.org/show_bug.cgi?id=1803
<ubottu> bugs.exim.org bug 1803 in Code "segfault in pcre jit when running twig test suite (PHP7)" [Bug,New]
<nacc> i am thinking more and more, that it's a bug in pcre ... just need to figure out if i cna write a testcase for it. I told you the other day i wrote the twig testcase as it's own (what split_utf8.test does) and it doesn't fail ... so it's a stateful issue. Which is why process-isolation helps
<nacc> but i'm not sure what state pcre could be holding that would go corrupt
<nacc> as it's supposed to be using the offsets passed in to decide where to look in the string, etc
<nacc> hrm, after upgrading to xenial, my previousl working adt-run, which uses my already built .deb says:
<nacc> blame: arg:/home/nacc/ubuntu/build/php-imagick_3.4.0~rc6-1ubuntu3_amd64.deb deb:php-imagick php-imagick_3.4.0~rc6-1ubuntu3.dsc
<nacc> badpkg: got 9 lines of results from extract where 4 expected
<nacc> adt-run [11:44:54]: ERROR: erroneous package: got 9 lines of results from extract where 4 expected
<chiluk> xnox do you have a chance to look at a preseed and debug syslog with me?
<Son_Goku> nacc: done: https://bugs.exim.org/show_bug.cgi?id=1803
<ubottu> bugs.exim.org bug 1803 in Code "segfault in pcre jit when running twig test suite (PHP7)" [Bug,New]
<nacc> Son_Goku: thanks!
<Son_Goku> Iâve attached the log output as attachments, to make things simpler
<nacc> Son_Goku: makes sense
<Son_Goku> the best part is that since these are three different distros, itâs not likely to be considered distro-specific
<nacc> right, it seems like it should be something that is fixable by upstream now :)
<nacc> but we'll see
<mahmoh> hi, I'm seeing a hang with upstart, I tried --verbose on the kernel command line with 14.04 to get additional info but that's not working, any ideas?
<nacc> pitti: hrm, after upgrading to xenial, my previousl working adt-run, which uses my already built .deb says:
<nacc> pitti: blame: arg:/home/nacc/ubuntu/build/php-imagick_3.4.0~rc6-1ubuntu3_amd64.deb deb:php-imagick php-imagick_3.4.0~rc6-1ubuntu3.dsc
<nacc> pitti: adt-run [11:44:54]: ERROR: erroneous package: got 9 lines of results from extract where 4 expected
<nacc> pitti: and the results in particular are: http://pastebin.ubuntu.com/15276066/
<nacc> pitti: i think it's because fo the dpkg-source output, but not positive?
<nacc> pitti: adding >/dev/null 2>&1 to the invocation of dpkg-source fixed it, but i think that's clearly not expected. Did perhaps dpkg-source change it's output in xenial? actually that doesn't make sesne, looking at the exec line, it seems like fd3 gets redirected to stdout and then stdout gets redirected to stderr; so somehow dpkg-source's output is showing up on fd3? will debug it some more
<Saviq> xnox, hey, is it normal that trying to install libboost-dev in a cross-armhf chroots tries to remove gcc and all?
<Saviq> or actually, doko, you seem to have dabbled in "g++ dependencies" in there https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/boost-defaults/wily/revision/15
<superm1> pitti:  new hardware is supported by brcmfmac, older hardware is supported by wl
<nacc> slangasek: woo! i think i found another imagemagick backport that is why php-imagick segfaults its tests ... build and testing now
<Pharaoh_Atem> hmm
#ubuntu-devel 2016-03-04
<Pharaoh_Atem> nacc: well, I ruled out the upcoming pcre-8.38-7.fc23 update pending as a potential solution
<Pharaoh_Atem> I just checked it, and I still get the same backtrace
<nacc> Pharaoh_Atem: thanks for doing that
<nacc> Pharaoh_Atem: yeah, I think it's a *new* bug, but i'm not sure; I believe i at one point in a sbuild env, built upstream pcre directly from source and it also segfaulted
<Pharaoh_Atem> nacc: I figured that this is a new bug
<Pharaoh_Atem> but with how hairy libpcre is, you never know
<nacc> so if i've got a fix, knowing we're past FF, for an actual bug (already filed), do i subscribe sponsors or release at this point? as i can't upload myself?
<nacc> rbasak: can you update usd with logwatch 7.4.2 from debian/unstable? I'll merge and post the debdiff to get that sync'd
<nacc> slangasek: php-imagick fixes (final ones) posted
<nacc> that shoudl free up php7.0 and php-defaults
<nacc> slangasek: i'll look at symfony and php-proxy-manager next, after i file a few non-php bugs :)
<infinity> nacc: Bugfixes don't break Feature Freeze, the key word there is "feature".
<nacc> infinity: yep, understood, just wasn't sure who to subscribe to the bug, exactly
<nacc> infinity: from what you said, it sounds like i should still subscribe sponsors?
<infinity> nacc: Same workflow as pre-FF, unless it needs an exception (which it doesn't sound like it does).
<nacc> infinity: ok, thanks!
<infinity> nacc: (ie: If you had upload rights, you should just be firing bugfixes at the archive without asking, without upload rights, find a sponsor, only bug the release team if you're breaking the freeze)
<nacc> infinity: right, makes sense to me!
<nacc> infinity: thanks again
<smoser> hey.
<smoser> so cloud-inti writes a bunch of systmed .service files.
<smoser> in /lib/systemd/system/
<smoser> and i've moved those to /root/store (random directory, pretty sure systemd isn't looking there)
<smoser> then rebooted
<smoser> systemd-analyze dump
<smoser> ^ that still knows about these jobs.
<smoser> how ?
<smoser> what do i have to do? i've told it 'systemctl daemon-reload'
<smoser> which i wouldnt have thought mattered across a reboot
<sarnold> smoser: try systemctl list-unit-files ?
<smoser> that doesnt show them.
<smoser> ah
<smoser> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/cloud-config.service
<smoser> hm.. well then.
<smoser> thank you deb-systemd-helper-enabled for being so... helpful
<smoser> thanks sarnold
<Pharaoh_Atem> smoser: black magic is fun :(
<smoser> and now, my friend 'Hash sum mismatch' has come to visit while i'im trying to sbuild.
<smoser> thanks to you too
<smoser> anyone have an idea on how i'd convince dh_systemd_enable to disable the jobs it previously enabled .
<smoser> upgrade i no longer want them there.
<smoser> well, filed bug.
<smoser> https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1552999
<ubottu> Launchpad bug 1552999 in init-system-helpers (Ubuntu) "dh_systemd_enable not able to disable on upgrade" [Undecided,New]
<smoser> if anyone wants to add some help. please feel free.
<Mirv> pitti: the s390x karchive seem stuck forever at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src
<infinity> Mirv: Retried.
<Unit193> infinity: Oh say, think those crazy archive admins would merge irssi? :P
<infinity> Unit193: Not really the responsibility of archive admins to do merges.
<Unit193> No, but they'd approve or reject after FF.
<Unit193> FF not being Firefox.
<infinity> Unit193: That would be the release team.  And I'd probably allow it, if I had more info.
<infinity> Unit193: Like, what's changed, do all the rdeps work with it, etc.
<cpaelzer> good morning
<Mirv> infinity: thank you
<pitti> Good morning
<Mirv> good morning
<Unit193> New upstream release, always great to get the latest (when it's had quite a few bug fixes even more so) before something's to be supported for a few years. ;)
<Unit193> https://sigma.unit193.net/source/irssi_0.8.18-1ubuntu1.dsc looks like it, I believe.
<infinity> Mirv: Looks like that did the trick, you're migrating.
<pitti> superm1: thanks, so we still use wl; it appears that the brcmfmac firmware is reasonably free even? (it's in linux-firwmare)
<pitti> nacc: right, apparently dpkg-source spits out some unexpected jitter on stdout; I'll see if I can reproduce this
<pitti> Mirv: ah, some remaining fallout from yesterday's infra problems; next britney run will catch u
<pitti> p
<pitti> nacc: or just sign your .dsc to avoid the error :)
<pitti> nacc: but indeed this should be filtered out
<Mirv> yes it did indeed migrate just minutes after infi_nity's restart
<pitti> nacc: also, which runner is that? lxc? qemu?
<pitti> nacc: can you please file a bug with the full log and invocation? I can't reproduce this even with an unsigned package, this must be something more subtle
<pitti> nacc: ah, LXC runner? indeed I get something there, apparently still a regression with lxc-attach stream handling (~rc1 still works)
<superm1> pitti: yes, it works pretty well overall too
<pitti> robru, Mirv: FYI, we can now easily mass-retry failed or stuck "in progress" tests in silos; retry-autopkgtest-regressions  --silo 050 --state RUNNING
<pitti> so no need to fiddle around with request.cgi URLs if it happens for more than three or so packages
<pitti> or no need to remove pending.json
<robru> pitti: how is "silo" determined? is that just a reference to the PPA name?
<pitti> robru: it determines the landing-XXX bit in https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-036/excuses.yaml
<robru> pitti: is it hardcoded to key off "landing-" specifically? I'm currently working on a total rewrite of how the train handles PPAs (creating them dynamically rather than allocatinng from a pool), and the new way is to have them simply numbered. can your script cope with this change?
<pitti> robru: not right now, but it can be adjusted trivially
<pitti> robru: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/revision/1002
<robru> pitti: ok, look for that in a month or two ;-)
<pitti> robru: this was a quick hack to salvage landing 036 and 050 which fell victim to yesterday's infra work
<pitti> and writing this 10-line patch was way faster (and more satisfying) than cobbling together the right commands manually :)
<robru> pitti: no worries, just be aware that "landing-%s" will eventually need to be just "%s"
<pitti> robru: yep, and then we'll just update it in the script
<pitti> robru: probably it'll become --ci-train then, and you are expected to specify the full name
<robru> cool
<pitti> robru: I suppose we could alredy do this right now
<pitti> robru: as long as the bit in the URL and the actual PPA name match
<robru> pitti: well if you do it now then everybody will have to type landing- all the time
<robru> pitti: yeah that's the plan
<pitti> robru: well, we expect this to get run less than once a month, and I don't want many people to actually run it :)
<robru> pitti: heh, then I guess it doesn't matter
<pitti> ./retry-autopkgtest-regressions  --ci-train landing-050 --state RUNNING
<robru> pitti: looks good
<pitti> robru: ^ ok, it's like that now; that shoudl be compatible with the future
<robru> perfet
<robru> perfect
<pitti> http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/revision/1002
<robru> pitti: did you just --overwrite a publicly-pushed commit? naughty!
<pitti> *shrug*, it was there for like 10 seconds
<tjaalton> my kvm hosts have lost network for some reason, but only those that use dhcp
<tjaalton> err guests
<tjaalton> dunno if kicking the bridge around might break them, or if it's just the router dchp acting funny
<tjaalton> looks like the bridge doesn't work at all..
<Mirv> pitti: I just noticed there is indeed such a script in my ubuntu-archive-tools folder :)
<pitti> Mirv: right, you can run it, and it'll dutifully spit out the run-autopkgtest commands; but you can't run *those*
<pitti> (as they need to be run on snakefruit)
<Mirv> ah
<pitti> r-a-r just downloads excuses.yaml and generates commands on stdout, it's harmless
<rbasak> nacc: logwatch> done, I think.
<pitti> nacc: workaround to unblock you: adt-run -l /dev/null; I filed this a bug 1553097
<ubottu> bug 1553097 in lxc (Ubuntu) "latest LXC breaks autopkgtest's LXC runner" [Undecided,New] https://launchpad.net/bugs/1553097
<pitti> nacc: ok, got it, iz lxc bug; so use that workaround, or the lxd runner, or downgrade lxc
<LocutusOfBorg> is xorg 1.18 in 16.04 rootless?
<pitti> tseliot: ah, ubuntu-drivers-common tests fail now because they test fglrx; I'll change them to something else, like wl or nvidia
<pitti> tseliot: however, there's also a lot of fglrx code i gpu-manager which should be dropped; can you please do that, as you are much more familiar with that?
<LocutusOfBorg> tjaalton, ^^^
<seb128> pitti, tseliot, is there anything replacing fglrx? or opensource drivers better now and doing everything the ati ones were doing?
<tjaalton> LocutusOfBorg: rootless?
 * seb128 just curious
<tjaalton> LocutusOfBorg: it's supported, needs *dm support (lightdm doesn't have it)
<pitti> seb128: I was asked to remove fglrx yesterday, as it doesn't get updates any more and doesn't work with the new X.org ABI; and allegedly the FOSS drivers are now good enough
<tjaalton> yes
<seb128> good enough or as good?
<tjaalton> define "as good"
<tjaalton> foss stack is much better in some areas
<LocutusOfBorg> so tjaalton this change has no effect on ubuntu? https://packages.qa.debian.org/x/xorg-server/news/20150821T010032Z.html
<seb128> dunno, start a good recent games and get as many fps
<tjaalton> there will be a GL blob for that
<pitti> power management is an important point too
<LocutusOfBorg> I mean the xorg-legacy package
<tjaalton> yeah tseliot is backporting a lot for amdgpu kernel driver, including power management.. will be in 4.4.0-11 or such
<seb128> k, so there still are going to be binary parts shipped by amd?
<tjaalton> at some point
<tjaalton> LocutusOfBorg: no, nvidia does pull it in though, so once lightdm does support rootless, nvidia would still work
<tjaalton> or gdm
<tjaalton> seb128: amdgpu performance is quite close to fglrx though
<seb128> cool
<tjaalton> and mesa 11.2 has a FFE
<seb128> tjaalton, I guess we should have something in the 16.04 notes
<tjaalton> so I guess we'll be in a good position with 16.04, just have to be a bit aggressive..
<seb128> and maybe an email on ubuntu-devel
<tjaalton> yeah
<seb128> because usersa re going to wonder where is their fglrx drivers
<seb128> even if they don't need it, if we don't explain why it's missing it's going to create confusion
<tjaalton> sure
<tjaalton> the transition is still blocked by two MIR's
<tjaalton> new deps on s390x & arm
<tjaalton> (drivers)
<tjaalton> hmm or was it the virtualbox tests, xorg meta package is probably separate
<smb> tjaalton, dunno, I'd be somewhat surprised to find s390x blocking something graphical...
<ogra_> pitti, fyi bug 1553110
<ubottu> bug 1553110 in fakechroot (Ubuntu) "weird output of ldd on arm64" [Undecided,New] https://launchpad.net/bugs/1553110
<ogra_> infinity, ^^^ you might be interested
<tjaalton> smb: it's the addition of xserver-xorg-input-void to x-x-input-all on s390x
<pitti> ogra_: wow
<smb> tjaalton, ah ok. yeah "void" describes the graphical experience there...
<pitti> tseliot: autopkgtest fix pushed, but I don't upload yet as the cleanup should be done too
<tjaalton> another option is to just drop it, but arm probably still wants -freedreno in main
<pitti> tsdgeos: xserver-xorg-input-mouse
<pitti> erk
<pitti> tsdgeos: sorry, wrong ping
<pitti> tjaalton: xserver-xorg-input-mouse
<tjaalton> can be removed
<pitti> tjaalton: ... wants to go to universe, can you confirm?
<pitti> replaced by -evdev I suppose
<tjaalton> like others on https://bugs.launchpad.net/ubuntu/+source/fglrx-installer-updates/+bug/1541369
<ubottu> Launchpad bug 1541369 in xserver-xorg-video-s3 (Ubuntu) "remove stale xorg drivers from the archive" [Wishlist,New]
<pitti> tjaalton: ah, thanks; will do now
<pitti> tjaalton: will they be removed in debian too, or is that ubuntu specific somehow?
<tjaalton> vmmouse used to depend on -mouse, but that dep was actually removed upstream six years ago
<tjaalton> gone from debian already
<tjaalton> not mouse, since it had the dependency not too long ago
<tjaalton> yeah we've used -evdev for years, and next up will be -libinput
<pitti> -keyboard is also still in debian
<tjaalton> hmm
<tjaalton> I'll check
<tjaalton> because they have kfreebsd
<tjaalton> actually mouse for the same reason
<tjaalton> but we don't have !linux
<pitti> ah
<pitti> *zap*
<tseliot> pitti: define clean-up please?
<pitti> tseliot: git grep fglrx
<tseliot> seb128: do we have a draft of the release notes? If so, I can write a few lines about it
<pitti> tseliot, tjaalton: actually, what happens on upgrades of systems that have fglrx currently installed? does ubuntu-drivers set an xorg.conf which forces the driver, or does it just configure it and retains auto-detection?
<tjaalton> good point
<pitti> gpu-manager does quite a bit on such systems (I have no idea what exactly, though)
<seb128> tseliot, I don't know, I would expect that be a section on the wiki that is updated during the cycle ... let me find it
<tseliot> pitti: when users upgrade to the new X, fglrx will be removed, gpu-manager will detect that, and remove the xorg.conf
<tjaalton> oh
<pitti> ah, good
<pitti> tseliot: so I suppose some gpu-manager code for fglrx will still be necessary, just not all of it (the setup part)
<LocutusOfBorg> thanks tjaalton
<tseliot> pitti: yes, I'd rather not remove that code yet, as it would make backports to previous Ubuntu releases harder than they need to be
<pitti> tseliot: ah, ok; then I guess I should keep the fglrx support in UbuntuDrivers/detect.py as well for the time being
<pitti> tseliot: good, then I'll upload this to fix the tests
<pitti> tseliot: unless you still have something?
<tseliot> pitti: yes, please, let's keep the code there for now. I have nothing to upload ATM
<pitti> apw: OOI, what happened to the seeding of the linux-meta packages?
<tseliot> pitti: BTW, if you could approve my nvidia packages in Xenial NEW, that would be very welcome ;)
<seb128> tseliot, I don't find a wikipage :-/
<seb128> Laney, do you know if there is already a wikipage somewhere for release notes?
<seb128> I though we had one through the cycle
<seb128> adding infos during alpha/beta/etc
<seb128> but I can't find it
<apw> pitti, i thought we were making that use a * thing, and i actually thought you'd already done it:)
<Laney> seb128: not one that I know of - probably one will be created for Beta 2 though
<seb128> tseliot, ^ I guess need to wait a bit then
<seb128> Laney, thanks
<pitti> apw: no, I understood it like you were going to double-check and update the seeds, but they are still on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt; misunderstanding?
<Laney> seb128: IIRC the ubuntu-release-notes project is for this
<Laney> or someone could start the page I suppose
<tseliot> seb128: ok, I'll be waiting for that then
<Laney> XenialXerus/ReleaseNotes
<seb128> tseliot, or create the page
<pitti> tseliot: no nvidia stuff in https://launchpad.net/ubuntu/xenial/+queue?queue_state=0
<Laney> tseliot: I would create it now so that nobody forgets
<pitti> tseliot: nevermind, saw it now, scrolled off
<tseliot> Laney, seb128: err... https://wiki.ubuntu.com/XenialXerus/ReleaseNotes
<seb128> tseliot, yeah, I think that Laney was just hitting the url and suggesting creating it
<tseliot> no need for me to create it then :)
<seb128> ?
<seb128> it doesn't exist yet
<pitti> cit does
<pitti> just still for wily
<Laney> tseliot: I just made it
<Laney> you can go fill in your section now
<tseliot> Laney: yep, thanks
<oSoMoN> Mirv, Iâm looking into bug #1342031 (for webbrowser-app), and IÂ have a doc package named qtdeclarative5-ubuntu-web-plugin-doc, should that one be renamed too, and if so do I add a transitional dummy package?
<ubottu> bug 1342031 in unity-action-api (Ubuntu) "Rename QML modules to follow qml-module-foo naming" [Medium,Triaged] https://launchpad.net/bugs/1342031
<tseliot> pitti: thanks a lot!
<oSoMoN> Mirv, note that qtdeclarative5-ubuntu-web-plugin-doc doesnât have any rdepends, it looks safe to not make a transitional dummy package for it
<Mirv> oSoMoN: yes to both
<oSoMoN> Mirv, even considering the above?
<Mirv> oSoMoN: still, for people who have it currently installed to get the new one
<oSoMoN> ok, got it
<Mirv> oSoMoN: and thanks for the MIR, looks good!
<oSoMoN> Mirv, what section does the -doc dummy package belong to? doc, or oldlibs?
<Mirv> oSoMoN: that's an excellent question, I think I've seen that used, maybe because there is no other "old*" section. anyone on the channel with better knowledge please enlighten.
<oSoMoN> Mirv, according to https://wiki.debian.org/Renaming_a_Package, setting the section to oldlibs allows tools like deborphan to suggest removal of the package once there aren't any more reverse-dependencies installed
<Mirv> oSoMoN: right, the only thing I haven't seen explicitly said is "please use oldlibs section for all transitional packages", but I indeed have thought that is the case
<Mirv> oSoMoN: thanks for starting that btw, we can get rid of more old names and transitional packages in 2 months then
<Mirv> since there is upgrade path for 14.04 LTS -> 16.04 LTS upgraders
<oSoMoN> Mirv, yeah, it had been on my backlog for a long time, IÂ thought itâd be good to get it done in time for 16.04
<tseliot> seb128, Laney: ok, I've added a few lines about fglrx in the release notes
<seb128> tseliot, looks good, thanks!
<jamespage> barry, hey - just tripped over an interesting niggle - pip includes a vendored pkg_resources (v19.4)  which behaves a little differently to the pkg-resources in packages (20.1.1)
<jamespage> barry, https://github.com/openstack/ceilometer/blob/master/ceilometer/tests/unit/meter/test_notifications.py#L274 works ok with 19.4, but not with 20.1.1 (always uses the full, not relative paths...)
<jamespage> anyway I patched into ceilometer...
<jamespage> I guess that would need to happen in pip itself otherwise xenial will have different pip to the rest of the world....
<oSoMoN> Mirv, https://code.launchpad.net/~osomon/webbrowser-app/qml-module-naming/+merge/288080
<barry> jamespage: pip isn't supposed to contain any vendored packages.  we strip out the _vendor directory
<jamespage> barry, hmm where is that coming from then
 * jamespage looks some more
<jamespage> barry, oh its quite possible that when tox creates the venvs, it installs pip from pypi which brings that in
 * jamespage checks...
<barry> jamespage: also, just syncpackaged new version of pip to xenial.  shouldn't change this bit of it, but just fyi
<barry> jamespage: oh yeah, it'll do that if you don't tell tox otherwise!
<jamespage> barry, my god this is confusing.,..
<jamespage> barry, I think that's what it is
<barry> jamespage: you can set sitepackages=True and install the debs.  also, i think there are ways to tell tox never to download from pypi.  check the docs (something like setting the indexserver to the discard port on localhost)
<barry> (that'll likely error out if you don't have a distro package installed)
<jamespage> barry, indeed
<xnox> barry, you are assuming i understood the structure i was dereferencing..... i tried combos until it worked ;-)
 * xnox <3 TDD
<barry> xnox: tried and true method :)
<Saviq> xnox, any idea about 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
<xnox> Saviq, yes, doko broke things =)
<oSoMoN> Mirv, https://code.launchpad.net/~osomon/webbrowser-app/qml-module-naming/+merge/288080 updated
<Saviq> xnox, half a year ago and noone noticed? ;)
<xnox> Saviq, i was not working on ubuntu half a year ago....
<Saviq> xnox, but you were working on it since! ;D
<Saviq> canfix? ;)
<barry> pitti: ree bug 814115 - thanks! it would really help for debugging failures
<ubottu> bug 814115 in OpenQuake (deprecated) "Celery worker fails to send result message" [Critical,Fix released] https://launchpad.net/bugs/814115
<barry> debian bug 814115
<ubottu> Debian bug 814115 in autopkgtest "autopkgtest: $ADTTMP does not survive until --shell-fail/-s" [Normal,Open] http://bugs.debian.org/814115
<pitti> barry: yep, looking into it now
<barry> \o/
<pitti> stgraber: what's the word on indicator-datetime pulling in obsolete deps?
<pitti> barry: ok, got it :)
<barry> pitti: awesome!
<stgraber> pitti: no response from the merge proposal, I think I'll just upload it and they'll deal with merging things later
<smoser> hey.
<nacc> rbasak: thanks! wil merge today
<nacc> pitti: thanks!
<smoser> i have a stupid question.
<smoser> file in debian/ gets installed by dh_install. debian/open-iscsi.install
<smoser> what is the right way to ensure its installed executable ?
<rbasak> Make sure it is executable to start off with?
<smoser> is that right ?
<rbasak> You can chmod it in d/rules if needed.
<rbasak> (usually only if upstream have it wrong)
<smoser> well its debian/
<smoser> so , its ours
<rbasak> Ah. Is it a "3.0 (quilt)" source package?
<smoser> no. its a file in debian/
<smoser> debian/iscsi-network-interface.rules => /lib/udev/rules.d/70-iscsi-network-interface.rules
<rbasak> What does debian/source/format say?
<smoser> quilt 3.0. but its dh_install from ^
<rbasak> Then you can mark it executable in the source package.
<rbasak> And it should end up executable on the installed system.
<smoser> yeah. that just felt brittle
<nacc> smoser: does it not automatically? i'm reading the debian manual about it ... it probably doesn't hurt to mark it executable in the source
<nacc> https://www.debian.org/doc/manuals/maint-guide/dother.en.html#install
<smoser> it does not do it automatically.
<nacc> ok
<xnox> smoser, debian.rules files should not be executable.
<xnox> smoser, sorry, .rules files under debian.
<cjwatson> If you're concerned about things not working otherwise then it's fine to override_dh_install
<smoser> xnox, its not that style of rules.
<nacc> it's a udev rule, right?
<smoser> yeah. its a udev rule
<nacc> namespace collision :)
<xnox> smoser, i think then you want to e.g.
<xnox> override_dh_installudev:
<nacc> smoser: it seems "better" to override dh_install, but i'm not sure
<xnox>     dh_installudev
<xnox>      chmod +x debian/$pkg/lib/udev/rules.d/*.rules # or some such
<nacc> smoser: rather than assuing te permissions in the tarball are maintained, etc
<rbasak> I prefer to keep the permission in one place and think the source package chmod is fine. That keeps d/rules smaller, which I prefer.
<nacc> heh
<xnox> nacc, i think dh_installudev will strip the permissions anyway, and/or dh_fixperms thing.
<rbasak> But no harm in doing it explicitly in the rules file.
<xnox> smoser, if dh_fixperms "reverts" the chmod+x you'll need to override that too, with e.g. dh_fixperms -X
<nacc> xnox: yeah, that's what I guess I meant ... not sure what the other commands do to the file during install
<rbasak> If dh_fixperms reverts it, then maybe worth looking into why you need it that way?
<nacc> also fair :)
<rbasak> BTW, while we're asking this sort of question...
<xnox> smoser, usually people place "binaries" into /lib/udev and just rules in the rules.d directory....
<nacc> I didn't think udev.rules needed to be exec
<xnox> smoser, but i know that you are not a "usual" person.
<smoser> bah
<smoser> sorry
<smoser> fail
<nacc> none of them are exec on my system, at least
<smoser> debian/net-interface-handler           /lib/open-iscsi
<smoser> that one is the file
<nacc> ah
<rbasak> I'd like to use dh_install --fail-missing to manage a complex package (mysql). But then how do I maintain a list of excludes? With -X, or is there a better way for a larger list?
<rbasak> And, why is dh_install --fail-missing complaining about manpages installed using dh_installman and specified in a .manpages file, and is it right to have to exclude those specifically or is there something else that should be going on?
<cjwatson> dh_install doesn't have a built-in way to maintain more excludes, but you could always generate the options using shell command substitution.
<rbasak> cjwatson: that's a good idea. I just wanted to check that there wasn't some better way I was missing. Thanks!
<nacc> rbasak: is that dh_install complaining or dh_installman
<smoser> rbasak, so  http://paste.ubuntu.com/15281670/ look ok ?
<smoser> i also chmod 755 on the file, but that does not show up in debdiff (which is kind of why i find it brittle)
<rbasak> nacc: dh_install complaining using --fail-missing about manpages installed by dh_installman (not sure what order but the dh sequencer order)
<rbasak> smoser: IMHO, it's debdiffs that are brittle!
<rbasak> git manages it fine.
<smoser> well, yes.
<rbasak> $(CURDIR)/ is a little redundant but I guess that pattern comes from Debian and you didn't want to deviate? Assuming that works, it looks fine.
<smoser> yeah, the ones above use CURDIR
<rbasak> s/needs to be/is/ if you like.
<rbasak> And if you want me to be really pedantic, you're adding an unnecessary blank line in line 24 :-P
<smoser> cyphermox, http://paste.ubuntu.com/15281670/
<smoser> indeed i am.
<nacc> rbasak: hrm, that seems odd ... does that mean you're specifying the manpage to be installed then? (I don't know what the dh_install line looks like)
<smoser>  i will dlean that.
<rbasak> nacc: https://git.launchpad.net/~racb/ubuntu/+source/mysql-5.7/tree/debian/mysql-server-5.7.manpages?h=5.7v3_pre2 is what dh_installman picks up
<rbasak> nacc: but then dh_install --fail-missing (if we switch to that in d/rules) complains about all those manpages again.
<rbasak> (I'm told)
<nacc> rbasak: hrm, interesting -- that doesn't seem like it should be on my reading ofthe manapges, but you certainly know more than I do :)
<rbasak> nacc: I only know as much as the manpages :)
<rbasak> Thanks for looking. I could file a bug at some point I guess.
<nacc> rbasak: :) it seems like it might be an ordering thing, but it's hard to say, and given you do have a workaroudn presuming it's an issue
<rbasak> nacc: yeah we can just use dh_install --fail-missing -X ...
<mitya57> cjwatson, rbasak: I think modern debhelper versions can read list of excluded files from debian/not-installed
<mitya57> â¥ 9.20151004 according to the changelog
<mitya57> (never tried that myself)
<rbasak> mitya57: ah, neat! Thanks. Any idea where that is documented? Google doesn't find anything.
<mitya57> It's documented in dh_install(1) here
<rbasak> Thanks again!
<nacc> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436240
<ubottu> Debian bug 436240 in debhelper "debhelper: exclude file for dh_install --list-missing" [Wishlist,Fixed]
<mitya57> Yw!
<rbasak> http://manpages.ubuntu.com/manpages/xenial/en/man1/dh_install.1.html has it
<rbasak> Skuggen: ^^
<xnox> in moinmoin how do i type CamelCase word without it generating a link to CamelCase page?
<nacc> rbasak: and seems to be referring to exactly your issue in one of the comments :)
<Skuggen> Ah, nice
<mitya57> xnox, try an exclamation sign, i.e. !CamelCase
<xnox> mitya57, thanks!
<mitya57> that was from https://moinmo.in/HelpOnLinking#Preventing_Automatically_Generated_Links
<cjwatson> mitya57: So it does!  Not sure how I missed that.
<mterry> seb128, hello!  Is a11y-profile-manager a package the desktop team is OK with owning / subscribing to?  (in the context of MIR bug 1552507)
<ubottu> bug 1552507 in a11y-profile-manager (Ubuntu) "[MIR/FFE] Promoting a11y-profile-manager to main." [Undecided,Incomplete] https://launchpad.net/bugs/1552507
<infinity> ogra_: Commented.
<ogra_> infinity, i'm batteling other issues too here ...
<ogra_> OOOH !
<ogra_> lol
<ogra_> infinity, my other issue is that despite linbudev being in that ldd output, i dont end up with it inside the initrd
<infinity> ogra_: Curious.  Is that also unique to running under fakechroot?
<ogra_> definitely, since normal built initrds used to work
 * infinity nods.
<ogra_> other hooks all get their libs just fine too
<infinity> ogra_: Of course, you say that copy_exec fail because of the ld.so issue.  It's possibly it's aborting before getting to libudev.
<infinity> s/fail/fails/
<ogra_> well, my outer build script now has a mkdir /lib64 and i copy the linker there
<infinity> Oh.  Gross. ;)
<ogra_> so mkinitramfs moves on without error
<infinity> Right.  Hrm.
<ogra_> yeah ... i have worse hacks in the making currently though :P
<infinity> If you didn't, it wouldn't be you.
<ogra_> (all stuff i hope to drop once fakechroot works again :)
<infinity> The best part about that ldd wrapper is that it fails to do the one useful thing that a wrapper SHOULD do in that situation (filter out libfakechroot!)
<ogra_> yeah, totally
<ogra_> root@localhost:/# grep touch initramfs-tools-ubuntu-core-0.7.28/build-initrd.sh  .... touch $ROOT/usr/lib/$DEB_HOST_MULTIARCH/fakechroot/libfakechroot.so
<ogra_> touch $ROOT/usr/lib/$DEB_HOST_MULTIARCH/libfakeroot/libfakeroot-sysv.so
<ogra_> works but makes a lot of noise about "library to short" in the build logs ...
<ogra_> hmm, so now i have an initrd with libudev ... but my hack to add it actually spilled errors ... that doesnt really help :P
 * ogra_ starts over without the hack ... perhaps i'm hllucinating now ... it shouldnt be there 
<ogra_> building again ... perhaps that libudev thing was a red herring
 * zyga hugs ogra_ and initrd hacking
<zyga> how come other OSes don't have initrds :P
<ogra_> they are not as cool
<ogra_> zyga, usually i dont need to hack actually ... if the tools work :)
<ogra_> wow, so with my linker hack libudev actually ends up where it should ... now thats weird
<ogra_> argh !
<ogra_> initramfs-tools-ubuntu-core_0.7.29_source.changes
<ogra_> err
<ogra_> /usr/share/initramfs-tools/hooks/zz-fix-arm64-linker ignored: not executable
<ogra_> ogra@styx:~/ArbeitsflÃ¤che$ abootimg-unpack-initrd initrd.img-core-0.7.30
<ogra_> 10730 BlÃ¶cke
<ogra_> ogra@styx:~/ArbeitsflÃ¤che$ ls ramdisk/lib/aarch64-linux-gnu/|grep udev
<ogra_> ogra@styx:~/ArbeitsflÃ¤che$
<ogra_> WTF !
<ogra_> why does it work if i run the build script in a chroot but not on the buildd
<ogra_> i clearly have libudev in my local build
<nacc> rbasak: sent a merge requst for logwatch to get us up to 7.4.2-1
#ubuntu-devel 2016-03-05
<justin_time> Hi, I have a approved FFe for my package (LP: #1487729) but unfortunatly the person, who reviewed my package is busy and I have no luck to find a new sponsor. By asking on #ubuntu-motu or writing a email to ubuntu-devel-diskussion, I didn't recive any feedback. I really do not know what I should do next and I'm running out of time. I would be really hapy if someone could help me or give me a tip what I should do next.
<ubottu> Launchpad bug 1487729 in tomahawk (Ubuntu) "[FFe] Tomahawk 0.8.4 or newer [needs upgrade]" [Medium,In progress] https://launchpad.net/bugs/1487729
<mdeslaur> justin_time: I'll take a look on monday if nobody looked at it until then
<justin_time> mdeslaur: That would be really great! Thanks!
<mdeslaur> justin_time: np
<LocutusOfBorg> infinity, hi, what about wings3d?
 * LocutusOfBorg is wondering about a plain sync
<LocutusOfBorg> hi folks, quick question: I don't know how does apport collect data based on the application that crashed
<LocutusOfBorg> bug virtualbox 5.0.16 added a tool (VboxBugReport) that automatically collects the logs and creates a tarball
<LocutusOfBorg> can we patch apport or whatever to launch the command in a trivial way?
#ubuntu-devel 2016-03-06
<cjwatson> juliank: any objection to me cherry-picking my lzma compression fix into xenial's apt?  I'd like to get the trusty SRU moving as quickly as possible so that we can get Launchpad instances upgraded so that we can flip xz on for dists/xenial/ in time for release
<juliank> cjwatson: I'll upload 1.2.5 bugfix release soon which I want to get synced
<juliank> sson = few minutes
<cjwatson> juliank: ah, cool, thanks.  I can organise a trusty SRU of that patch then
<juliank> cjwatson: There's another bug that needs fixing for trusty.
<cjwatson> oh?
<juliank> bug #1445436
<ubottu> bug 1445436 in apt (Ubuntu) "Segmentation faults in libapt-pkg.so.4.12.0" [Undecided,Confirmed] https://launchpad.net/bugs/1445436
<juliank> We might have found another bug today
<juliank> cjwatson: ok, the other we found today does not exist in trusty, but fixing the segfault above seems to be a good idea
<juliank> the patch is tiny
<cjwatson> ah, another remapping bug, whee
<cjwatson> juliank: well, if you're on top of an upload, cool, since I'm wiped out from flying back from Uruguay, otherwise let me know what git commits I should grab :)
<juliank> cjwatson: What you need for the SRU is (1) your fix (2) http://anonscm.debian.org/cgit/apt/apt.git/commit?id=4ea471ecb013d188d03a5c3efb9b21e58ef56065
<juliank> 1.2.5 is released now and can be synced in a few hours hopefully
 * juliank wants to thank travis for providing free CI
<cjwatson> ah, quite an old CP there, ok
<cjwatson> juliank: uploaded; thanks for the advice
#ubuntu-devel 2017-02-27
<sarnold> Unit193: heh, yeah, non-stale mirrors is great reason :)
<Unit193> Or rather, when they're outdated it's more noticable.
<hloeung> rbasak: would you be kind enough to sponsor the patch in https://bugs.launchpad.net/ubuntu/+source/check-mk/+bug/1372284 ?
<ubottu> Launchpad bug 1372284 in check-mk (Ubuntu) "nagios3 + livestatus: SIGSEGV everyday at midnight" [Medium,In progress]
<hloeung> rbasak: I've tested in two separate instances of nagios we IS have (Both Xenial and Trusty)
<hloeung> rbasak: oh make that three, two Xenial and one Trusty
<doko> apw, ogasawara: linux autopkg test failures are triggered by binutils and gcc-6. please could you have a look if these are real?
<apw> doko, yep
<javier4> Hi all. I'm trying to cross-compile a package for ubuntu touch after I applied some edits to the source and modified the debian overlay according to them. I setup the schroot following the first part of this page https://wiki.ubuntu.com/Touch/CrossCompile
<javier4> This is what I get
<javier4> http://pastebin.com/dbHxbM7c
 * javier4 The warning should be unharmful, because I pass the -d flag. I can't see any error.
<javier4> just noticed that this is the only content of my /var/lib/schroot
<javier4> https://www.irccloud.com/pastebin/trLCYdXh/
 * javier4 doesn't it lack something?
<apw> javier4, isn't that saying you don't have a chroot you requested ?
<javier4> apw, I just noticed some minutes ago that the porcedure I used to setup my schroot is not persistent. I issued again the mk-sbuild command and now it seems the chroot has been created. See if it works now...
<apw> doko, the linux/amd64 failure reported on gcc-6 is a known HOST induced test suite failure and can be ignored.  the failures on binutils differ and warrent a retry (already clicked)
<musician_pro> <musician_pro> Hi everyone
<musician_pro> <musician_pro> There is a terrible bug in Mozilla FireFox working on Lubuntu 32-bi
<musician_pro> <musician_pro> When I click in a hyperlink contente an email (like mailto:name@domain.excetera) mozilla oper a tab with the name of email in the searchboard FOREVER
<musician_pro> <musician_pro> if you try to close Mozilla he reopen and open tab that you can close because open every second!
<musician_pro> <musician_pro> 4 or 5 for second!
<musician_pro> <musician_pro> I'm using on Lubuntu (maybe 14.04 32bit)
<musician_pro> <musician_pro> maybe because I haven't an email account associated with the email client program of the software
<musician_pro> <musician_pro> but when I associate the problem present another time
<musician_pro> <musician_pro> I'm so sorry for my bad english xD
<fossfreedom_> musician_pro: suggest file a bug report with the above to the relevant team - in a lxterminal: ubuntu-bug firefox
<tjaalton> doko: mesa still wants llvm 4.0 in main, but others are not ready for it atm. could both be in main for now? clamav for instance could be "fixed" by disabling llvm support again
<juliank> Do we want one shared SRU bug for both apt 1.2.20 and 1.3.5 (where 1.2.20 is a subset of 1.3.5 changes), or one for each?
<juliank> Let's do two, it gets confusing otherwise
<javier4> To crosscompile my package I need dbus header inside my system, so I installed libdbus-1-dev into my chroot
<javier4> (vivid-amd64-armhf)root@UbuBox:/# find /usr -name *dbus.h
<javier4> /usr/include/dbus-1.0/dbus/dbus.h
<javier4> my build still fail, and if I look for the file from outside of the chroot, I can't find it
<javier4> root@UbuBox:/var/lib/schroot/chroots/vivid-amd64-armhf# find . -name *dbus.h
<javier4> root@UbuBox:/var/lib/schroot/chroots/vivid-amd64-armhf#
 * javier4 Is my setup volatile? The changes I made once chrooted get forgotten when I leave the chroot?
<javier4> ok. Just learnt about chroot namepspaces.
<apw> doko, that binutils ADT failure looks real for armhf at least
<doko> apw: strange. there are no armhf related changes compared to the last version ...
<doko> apw: honestly I have difficulties to understand an error message like "error: not found"
<apw> doko, i know ... it is tricky to know where the heck that is even coming from
<apw> doko, but it has not gone away on a re-test and that is a basic kernel compile which is failing, on source which is built in the -proposed pocket with the previous tool-chain
<apw> doko, so in the first instance i am looking at binutils/gcc there
<nacc> mdeslaur: fyi, re: LP: #1668017, i just put 7.0.16 in a PPA for them to test
<ubottu> Launchpad bug 1668017 in php7.0 (Ubuntu) "Large mysql requests broken after security update, null character inserted close to 16MB boundary" [Undecided,New] https://launchpad.net/bugs/1668017
<mdeslaur> ugh
<nacc> mdeslaur: yeah :/
<sbeattie> nacc: vaguely related, any idea why the adt tests for mariadb-10.0 would be running for mariadb-10.1? It seems to be why mariadb10.1 hasn't left -proposed: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mariadb-10.1
<sarnold> nice find
<nacc> sbeattie: mariadb-common
<nacc> sbeattie: iiuc, if mariadb-10.1 were to go in, it would be preferred by mariadb-common, which might break assumptions of 10.0 installations?
<nacc> sbeattie: looking at the autopkgtest failures, that's why it triggered, if i had to guess
<nacc> sbeattie: it's the only package from -proposed being installed, at least :)
<sbeattie> ah okay. but is there any reason to keep mariadb-10.0 in zesty?
<nacc> sbeattie: there are a handful of reverse-dependencies that may need to be verified?
<nacc> sbeattie: and it's after FF :)
<nacc> sbeattie: not sure if 10.1 is no features or not
<sarnold> if it were uploaded before ff it probably could be waved through
<nacc> taht's true
<nacc> sorry, still context switching :)
<sarnold> normally packages being held up by autopkgtests or mirs count on when they were uploaded..
<nacc> sarnold: ack, you're right
<sbeattie> nacc: me either. I'm just trying to figure out how to resolve the zesty portions of bug 1657594
<ubottu> bug 1657594 in mariadb-10.1 (Ubuntu Zesty) "USN-3174-1: partially applies to MariaDB too" [Medium,New] https://launchpad.net/bugs/1657594
<sarnold> (which is good, I'd have a lot more angry co-workers if their mirs had to be done before ff :)
<nacc> why did they use a new source pacakge for waht is presumably a stable update?
<sbeattie> as our zesty package is now a rev behind the x/y packages; the issues have been addressed in mariadb-10.1, which has synced from debian but is sitting in -proposed,
<nacc> i guess that's normal
<nacc> but also does imply there are some changes
<sbeattie> nacc: I've no idea, the constant renaming of sources like that makes it so fun to track.
 * sarnold glares at gcc
<nacc> sbeattie: yeah, ok, so it hink the reverse-dependencies are still satisfied
<nacc> sbeattie: as the 10.1 package produces the same binary packages (afaict)
<nacc> sbeattie: as well as some additional ones
<nacc> sbeattie: so i think we need to transition 10.0 to 10.1 if you want it through, which I believe will end up needing an AA to delete src:10.0; possibly after ignoring the autopkgtest regressions for 10.1 on 10.0
<nacc> infinity: --^ is that right?
<nacc> I don't think we want to delete src:mariadb-10.0 before we migrate its replacement in, though
<infinity> nacc: If the new source produces all the same binaries, yeah, we'll want to remove the orphaned old source once things migrate.
<infinity> nacc: What is the old source's name?
<nacc> infinity: mariadb-10.0 (and new is mariadb-10.1)
<infinity> Check.
<nacc> infinity: the issue is, i think, mariadb-10.1 is triggering mariadb-10.0 to run its autopkgtest with mariadb-10.1 from proposed
<infinity> That's not really an issue.
<nacc> infinity: which installs mariadb-10.1 for the dependencies of the tests from mariadb-10.0 via the shared genericc pacakges (mariadb-server, etc) and the tests fail
<infinity> That's perhaps more of an issue. :P
<infinity> But we can likely ignore that.
<infinity> So, it doesn't produce *all* the same binary packages.
<infinity> Since some are exact-versioned.
<nacc> infinity: ah you're right, so mariadb-{client,server}-10.1 vs. 10.0, etc
<infinity> Who thought this was a good idea?
<infinity> Oh well.
<nacc> infinity: yeah it seems like a bit of a mess :)
<infinity> nacc: The tests should probably make sure they're testing the right package.  So, depend on the exact version, not the meta.
<infinity> (No point fixing for 10.0 of course, but 10.1 could do better so the next one doesn't also break it)
<nacc> infinity: ack, i'll pull that down now
<nacc> infinity: in my checking so far, nthing in z/z-p depends on the versioned packages, they all go via the meta packages, so I don't think anything will break, once src:mariadb-10.1 is in z-release by removing src:mariadb-10.0 (and already installed users should get the new version of the meta package and the new versioned satisfier)
<Laney> nacc: It looks to me like it's via mariadb-test - the 'upstream' test - that the breakage happens, because this one is unversioned
<Laney> https://tracker.debian.org/news/748959
<nacc> Laney: good find
<infinity> Not that attempting to test the old mariadb is wrong (in fact, it's quite right here, when we rev the underlying libs, but claim ABI compat), but it's rather wrong to ask for a test of the old binary and get a test of the new binary with the old tests. :P
<nacc> Laney: yeah i think what you said is right
<nacc> Laney: mariadb-test should be versioned for exaclty this reason, afaict
<nacc> Laney: it can be dropped from the name, but I don't thnk it makes snse to take the 'latest' mariadb-test, you want the one from the same as this source package, right?
<infinity> It stands to reason that you want your tests to match what you're testing, indeed.
<Laney> nacc: I'd think that you're wanting to test the 'current' mariadb (the one from the triggered package), with the new libs from the triggering package (that's what infinity just said), so ya.
<Laney> You got it, and now I can leave for the evening happy. :P
<Laney> o/
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<nacc> infinity: so does it makes sense to get mariadb-10.1 migrated (by fixing mariadb-10.0 as well), even though we'd end up deleting mariadb-10.0?
<nacc> mdeslaur: fyi, looks to be aregression uptream, fixed (will be) in 7.0.17; i'm uploading to my PPA to test, and will push to -updates everywhere and you can copy up to -security
<valorie> hi folks, I joined to find out if there are reports about freezing since the recent kernel update in Zesty. I'm experiencing this twice a day or so, and I've not been able to rule out applications or even Plasma (running Kubuntu)
<valorie> but I hear that cyphermox is investigating a kernel bug
<cyphermox> heh, not really investigating it as throwing guesses at what it might be
<sarnold> valorie: I've heard rumours the kernel in -proposed may help
<cyphermox> I have issues mostly with firefox freezing for no particular reason, and unity not showing me my virt-manager menus
<valorie> I've been trying to quit FF whenever possible
<valorie> however, after a freeze, even if I was not running FF, up it pops
<cyphermox> ok
<valorie> does it have a daemon that auto-starts it?
<valorie> it is not in my very short list of auto-starting applications or scripts
<cyphermox> nothing should be starting a browser.
<cyphermox> unless you go click a link in something else
<valorie> evil, evil FF
<valorie> no, I use Chrome every day
<valorie> but one site only works in FF
<valorie> bleah
<valorie> otherwise I would kill it with fire
<cyphermox> if firefox was not running and it got started, I would go look at the process tree to see what its parent is
<valorie> unfortunately, I don't know how to do that, but I'll try to learn
<valorie> this is really awful
<valorie> so it does not seem to be kernel-related?
<valorie> sarnold: you have heard reports as well?
<valorie> do you have a BR#?
<sarnold> sorry valorie, no bug numbers :/
<valorie> ok, I'll hang out here and keep my ears open
<valorie> better it show up now than in the RC
<nacc> can you express d/t/control dependencies on specific versions using d/control substitutions? I'm assuming not and that you have to do some sort of build-time munging?
<nacc> slangasek: --^ ?
<nacc> slangasek: except build-time is 'too late' as i think autopkgtest just extracts the source and looks in d/t/control?
<slangasek> nacc: debian/tests/control is read from within the source package, so no, you can't
<slangasek> yes, that
<nacc> slangasek: so for mariadb-10.0 and mariadb-10.1, where I want to update the d/t/control 'upstream' test dependency from 'mariadb-test' to 'mariadb-test (= {same binary version as this upload}); do I hve any options?
<slangasek> nacc: I would expect a test dep on '@' to enforce this already
<nacc> slangasek: ok, i was wondering if i could do that -- but is @ versioned?
<slangasek> if it's a binary from /this/ source package, that should already dtrt
<nacc> slangasek: as it's a meta-binary produced by both source pacakges that's the issue
<slangasek> nacc: it should certainly be enforced on the autopkgtest infra
<nacc> slangasek: ok -- i think that will be fine, but is 'more' of a dependency than is actually needed. But that's ok (it will just slow the test down by adding more deps).
<nacc> slangasek: and as far as I can tell, there's no way to tell @ to only provide one binary from /this/ source package, right?
<slangasek> correct
<slangasek> otoh, even if you did just spell out the package name, instead of using '@', autopkgtest should still enforce it with its pins
<nacc> slangasek: ok, thanks
<nacc> the problem is that in -proposed there's a newer mariadb-test
<nacc> and it pulls in the 0.10.1 dependencies
<nacc> which breaks 0.10.0's tests :/
<slangasek> example?
<nacc> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/m/mariadb-10.0/20170128_080150_f9895@/log.gz
<nacc> the 'upstream' test section
<slangasek> nacc: so that's the run of the test that's triggered by the upload of mariadb-10.1 itself
<nacc> it uses mariadb-test from z-p, even thoug it's testing a source package that also generates mariadb-test from z
<nacc> and the script in the z version only is compatible with mariadb in z
<slangasek> right
<slangasek> so it's actually a bad test
<nacc> slangasek: yes, it feels bad :)
<slangasek> you can't have two source packages in a release both producing a binary of the same name
<slangasek> the mariadb-10.0 source package will now fail to upload
<slangasek> unless you make a sourceful change
<nacc> slangasek: our goal is to delete mariadb-10.0
<slangasek> ok, in that case
<nacc> slangasek: and transition to mariadb-10.1
<slangasek> why worry about whether the test is failing? :)
<nacc> slangasek: because mariadb-10.1 won't transition
<nacc> slangasek: and as infinity pointed out earlier, it's ok for now, we understand this, but 10.1 has the same problem and will block 10.2
<nacc> slangasek: it feels like it should be solveable
<slangasek> nacc: but it shouldn't be "let's do a bunch of extra work to make a test wrongly triggered by mariadb-10.1 to pass", it should be "hey release team, ignore this meaningless result"
<slangasek> you're still in the situation that the test is being triggered by a package that shouldn't trigger it
<slangasek> it's triggered *only* because you're taking over the name of the binary package
<nacc> slangasek: i believe it triggers because they both produce the meta packages (all of them, -test, -server, -client)
<slangasek> so you could either a) version the name of the binary package, so this no longer happens; or b) ask the release team to override
<nacc> slangasek: ok, a) was specifically dropped in Debian, thanks to Laney's research
<nacc> https://tracker.debian.org/news/748959
<nacc> i'm not entirely sure i agree with the logic given the situation, but i'm not the expert
<nacc> slangasek: and then, i guess in this particular case, can you override the 10.0 tests triggered by 10.1 so we can migrate it? :)
<slangasek> nacc: well, that is the change that triggers this breakage, so I wonder why Laney thought it was appropriate?
<nacc> slangasek: i can file a bug if you'd rather, of course
<nacc> slangasek: i'm going to contact the debian maintainer(s) as they are seeing the same thing, afaict, e.g. https://ci.debian.net/data/packages/unstable/amd64/m/mariadb-10.0/20170227_005237.autopkgtest.log.gz
<nacc> slangasek: and it feels like they should revert the change in their package
<nacc> *packagin
<slangasek> nacc: I think Debian should revert this misguided change, and I've overridden the failure now for zesty
<nacc> slangasek: agreed
<nacc> slangasek: and thanks!
<nacc> sbeattie: --^
<sbeattie> slangasek: thanks
<nacc> slangasek: e-mail sent, thanks for helping walk me through it
#ubuntu-devel 2017-02-28
<cpaelzer> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: feature freeze, DIF | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: cpaelzer
<Laney> slangasek: nacc: Not sure what you're talking about?
<Laney> I pointed out the historical change that gives rise to this failure --- what's up?
<javier4>  I setup a chroot to crosscompile a package in armhf for Ubuntu-Touch. Inside the cage I ran apt-get build-dep wpa to satisfy the deps needed by my package, but the system installed them all in amd64 instead than armhf. Why?
<javier4> ok. As usual: look for a solution for 24 hours, give up and decide to ask on irc, find the solution after 10 minutes...
<Unit193> qemu-debootstrap?  pbuilder works with it.
<cpaelzer> javier4: was that just like "--build=amd64 --host=armhf" args?
<mdeslaur> nacc: re: php, thanks
<javier4> cpaelzer: no, it was just needed to pass -aarmhf to apt-get build-dep. But, even now that dependencies are correctk satisfied I keep getting the same error
<javier4> sbuild -A -d vivid-amd64-armhf --host armhf wpa_2.3-1+deb8u4.dsc
<javier4> https://www.irccloud.com/pastebin/DEMPiUvh/
<javier4> root@UbuBox:/home/Ubuntu/javier#  find /var/lib/schroot/chroots/vivid-amd64-armhf -name *libpcsclite.pc
<javier4> /var/lib/schroot/chroots/vivid-amd64-armhf/usr/lib/arm-linux-gnueabihf/pkgconfig/libpcsclite.pc
<cpaelzer> javier4: testing ...
<cpaelzer> javier4: I had no vivid around, so I just tried to cross build latest zesty the way I sometimes do - I see similar issues but with Package libnl-3.0
<javier4> Do you think there's a better channel where I can ask for this kind of help?
<cpaelzer> javier4: you are at the tight spot
<cpaelzer> uh
<cpaelzer> right I wanted to say
<cpaelzer> javier4: maybe summarize how you setup your sbuild and the command you use, put it to a pastebin and link it here
<cpaelzer> javier4: with the question being less specific like "failing to cross build wpa .deb for arm64"
<cpaelzer> javier4: also compiling for vivid might always raise questions, so you might explain why right away
<cpaelzer> javier4: also the version you are building is from debian, are you trying to backport that to vivid?
 * javier4 It's a bit more complex: I'm trying to port Ubuntu-Touch to another device. This device is Mediatek based, and in its Android source tree there's a mtk-customized version of wpa based on the 2.3 one. I'm tryng to build mtk-wpa source for Vivid (actual ub-touch stable), that instead use 2.1, upgraded to 2.4 through Stable Phone Overlay PPA. That's why I had
 * javier4 to use the debian one as a base.
<cpaelzer> javier4: I see, sorry that I'm not the cross build master you need :-/
<javier4> cpaelzer: you've already been helpful. Thanks for your time. :)
 * javier4 I realized that the problem must be about pkg-config dealing with multi-arch. Strange that's not configured to this by default.
<cpaelzer> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: feature freeze, DIF | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<nacc> Laney: nm, I probably mis-spoke in referring to your contribution to the discussion; it's resolved now (I think)
<nacc> mdeslaur: np, I got confirmation from the user overnight, will upload today
<Laney> nacc: Ok, I was worried I was being accused of giving bad advice. :)
<nacc> Laney: not at all, and I apologize if that's how I ended up characterizing it :)
<nacc> rbasak: have maybe a few minutes (here) after the meeting?
<bdmurray> cpaelzer: This report might be helpful if you run out of things to sponsor https://launchpad.net/~ubuntu-server/+patches
<bdmurray> cpaelzer: those are any bugs w/ a patch attachment while the sponsoring report is bugs w/ ubuntu-sponsors subscribed
<nacc> bdmurray: handy! thanks!
<cpaelzer> bdmurray: thanks, can be really useful
<bdmurray> no problem, that report isn't well advertised
<tsimonq2> cpaelzer: <3 thanks for doing patch pilot, I appreciate some sort of sign that it's still going! :)
<cpaelzer> thanks tsimonq2
<tsimonq2> :)
<tsimonq2> TheMuso, bdmurray: Patch pilot too? :) :) :)
<rbasak> nacc: a bit later if that's OK?
<nacc> rbasak: ack, just ping
<mdeslaur> slangasek, stgraber, kees, infinity: TB in 15 min
<slangasek> mdeslaur: ack
<smoser> nacc, around ?
<smoser> so if i do :
<smoser>  usd import -v --directory=nova-lxd --lp-user=smoser  nova-lxd
<smoser> that will import it, and push it up tthere.
<smoser> but will it then get magically synced ?
<nacc> smoser: pong
<nacc> smoser: that will still push to usd-import-team
<nacc> smoser: presuming that's what you want
<nacc> smoser: by magic sync what do you mean? the regular imports?
<nacc> smoser: no, that needs an update to the usd-cron-packages.txt file and then I need to restart the importer
<smoser> "that needs an update to the usd-cron-packages.txt"
<smoser> thats what i was asking.
<smoser> would it not make sense to just update anythign that is already present ?
<nacc> smoser: not sure i follow?
<nacc> smoser: the importer doesn't care about the git repositories on lp
<nacc> smoser: it is looking at publishing records
<nacc> smoser: it looks at what has been published since the last run and compares to that list of packages
<smoser> right.
<smoser> but it has some list of "i care about these packages"
<nacc> smoser: yes, that you provided :)
<smoser> but wouldnt it be simpler if at this point it cared about the list of  packages for which a import had been previously done.
<nacc> we haven't imported the list yet
<nacc> smoser: so no
<smoser> ok. i think it'd still be simpler. at least then the list is maintained in one specific place.
<nacc> smoser: and querying lp  for the list of repositories would be more code changes
<nacc> smoser: and would miss any new source pacakges
<smoser> well, which are missed now also
<nacc> right, so it's not better :)
<smoser> well, i think its still better.
<nacc> smoser: you're welcome to work on it
<smoser> :)
<nacc> smoser: right now, beyond fixing imports that are broken, i am not working on it
<smoser> theres probably a api to list
<smoser> right
<smoser> so if i want a package added, i propose a  merge to usd-cron-packages ?
<nacc> smoser: yeah, i think so
<nacc> smoser: also, you ahve push rights, i'm pretty sure
<nacc> smoser: so feel free to just update it :)
<smoser> well, yes.
<nacc> smoser: and then ping me and I'll restart the importer
<nacc> smoser: but that, on its own, doesn't import it, of course (it's useful to do what you did above first, so it's 'caught up', i think)
<bdmurray> tinoco: Do you recall if bug 1556653 is fixed in Yakkety or Zesty?
<ubottu> bug 1556653 in ktp-text-ui (Ubuntu) "ktp-text-ui crashed with SIGSEGV in ~SharedPtr()" [Medium,In progress] https://launchpad.net/bugs/1556653
<tinoco> bdmurray: nope :\
<smoser> nacc, i pushed
<smoser> nova-lxd to the list, and then started an import here
<nacc> smoser: thanks -- let me switch on the vpn so i can kick the importer
<bdmurray> tinoco: I looked and figured it out
<tinoco> bdmurray: tks
<nacc> smoser: restarted
<nacc> smoser: i agree it's not ideal, but we're also going to be changing the trees a bit again...
<smoser> oh
<nacc> smoser: i mean, that's why i haven't yet imported the list
<nacc> smoser: it won't really affect end-users, but it affects the 'project' in terms of reproducible impotws
<nacc> *imports
<nacc> stgraber: if `newnet` is used to run a process, are ports in use shared betweeen the namespaces?
<stgraber> nacc: I don't know newnet, but assuming it does the same as "unshare -n", then you won't have any network interfaces in there except for lo and that lo is specific to that namespace so you can bind the same ports as outside of it (and won't be able to connect to it from the outside)
<nacc> jbicha: --^ that's why plproxy is failing. they are passing -p 5432, which is the postgres default port (and so postgres is already running on it), but using `newnet` and the newnet process is complaining about the port being in use
<nacc> stgraber: ok, thanks
<nacc> jbicha: it's a bug in /usr/share/perl5/PgCommon.pm
<nacc> jbicha: it assumes that if a conf file is defined for a postgres installation with a port in it, that it's reserved that port
<nacc> jbicha: which ignores network namespaces altogether
<nacc> jbicha: well, it might be that pg_createcluster is only looking at the ocnfiguration -- so less a bug and more a mismatch
<nacc> simplest fix is to not pass -p
<jbicha> nacc: would you like to work on that? it sounds like you understand that a lot better than I would
<nacc> jbicha: yep i'm sending an e-mail to debian, i think they should just drop their changes, it's the easiest
<nacc> while it seems 'cool' to use newnet, i have no reason to think it's necessary for these tests :)
<jbicha> the rebuild worked for postgresql-filedump's autopkgtest
<nacc> jbicha: cool, thanks
<javier4> Should I do something to make pkg-config search for libs in multi-arch directories?
<Unit193> So /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf is due to integration with nplan right?  If one doesn't have nplan, "unexpectedly" NM seems broken.  Is there a reason this isn't actually in nplan itself, since the config is useless or even detrimental without nplan installed?
<nacc> jbicha: i wonder if the multicorn regression is due to our older sqlalchemy, am going to test locally
<memeka> gnome-shell (zesty) crashes (so gdm3 and gnome3 won't start) in libmozjs38 ToBooleanSlow() - same crash as reported here: https://bugzilla.mozilla.org/show_bug.cgi?id=1334314
<ubottu> Mozilla bug 1334314 in JavaScript Engine "Crash [@ js::ToBooleanSlow] or Assertion failure: v.isObject(), at js/src/jsbool.cpp:175" [Critical,Resolved: fixed]
<memeka> on armhf
<jbicha> ok
<jbicha> nacc: actually, -multicorn has been failing on Debian and Ubuntu since 2015
<jbicha> see https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/view/head:/pitti#L164
<jbicha> https://ci.debian.net/packages/p/postgresql-multicorn/unstable/amd64/
<nacc> jbicha: ah so taht just needs an update to 1.3.3-1?
<jbicha> yes if we ignore those 2 packages, I think pg 9.6 will migrate
<nacc> well, plproxy doesn't need to be ignored
<nacc> it works now
<nacc> but we should ignore multicorn
<nacc> slangasek: --^ can you help here?
<nacc> jbicha: but also note that multicorn is not holding pg-9.6
<nacc> its the multicorn update itself that's help
<nacc> *held
<nacc> jgrimm: --^ i note that int he above hint, python-boto is also marked as a bad test
<jgrimm> nacc, ahhhhh
<nacc> jgrimm: not sure fully on the context, but specifically it was for the prior version, it seems?
<jgrimm> nacc, possibly.. i don't think anything's new with respect to tests there
<nacc> jgrimm: right, i think that it failed with 2.40.0-1ubuntu1 as well, but it was allowed by the hints
<slangasek> nacc: I see postgresql-multicorn already listed as 'ignored failure'?
<jgrimm> nacc, indeed it did, i didn't know about that file
<nacc> slangasek: yes, for  postgresql-9.6 itself, but not for it's own update
<jgrimm> so along those lines may just need updated again??
<nacc> slangasek: trying to get stuff ready to go through once pg-9.6 itself does (hopefully soon)
<slangasek> nacc: oh. why do we care about ignoring it for its own update, as opposed to making whoever uploaded the new version fix the test failure in that new version?
<nacc> slangasek: it's not a new failure :/
<slangasek> oh, because it's a sync grr
<nacc> yeah
<slangasek> nacc: yeah, but I'm generally in favor of making such packages stuck in -proposed the problem of the uploader... doesn't work when it's a sync :)
<slangasek> nacc: leeloo dallas multicorn - hint added
<nacc> slangasek: ah got you, agreed in principle
<Unit193> Paha.
<nacc> slangasek: and thanks!
<sarnold> multicorn!
<nacc> barry: do we care about pycxx in excuses? it would appear to be also failing in debian and has been since the update to 7.0.1?
<jbicha> nacc: plproxy's autopkgtest failed on armhf, is that arch unusual for autopkgtest?
<nacc> jbicha: always :)
<nacc> jbicha: let me look
<nacc> jbicha: might be a testbed failure, let me retry it
#ubuntu-devel 2017-03-01
<nacc> bdmurray: re: LP: #1667150 and LP: #1666687, do you want me to add delta that drops those to suggests?
<ubottu> Launchpad bug 1667150 in twitter-bootstrap3 (Ubuntu) "[MIR] twitter-bootstrap3" [Undecided,Incomplete] https://launchpad.net/bugs/1667150
<ubottu> Launchpad bug 1666687 in jxrlib (Ubuntu) "[MIR] jxrlib" [Undecided,Incomplete] https://launchpad.net/bugs/1666687
<bdmurray> nacc: I don't really have an opinion / haven't looked into much.
<nacc> bdmurray: ok
<nacc> jbicha: hrm, seems like newpid to install failed on armhf; i wonder if it's because of lxd?
<nacc> jbicha: yep, it also fails locally on lxd
<nacc> slangasek: is it possible to require virtualization of a test runner? otherwise, i think this testcase can't pass on armhf (postgresql-plproxy uses newpid)
<slangasek> nacc: I think that's spelled machine-isolation
<nacc> slangasek: err, right!
<slangasek> nacc: which will cause this test to be skipped for armhf since those are not currently available as runners
<nacc> stgraber: --^ were you aware of this issue? newpid (pkg) doesn't install under LXD
<nacc> slangasek: ack, will update the restriction
<slangasek> nacc: but if you think it's a lxd bug, maybe we should override the failure instead?
<nacc> slangasek: i'm not sure if it is or not -- i'll see what stgraber says before uploading
<nacc> slangasek: thanks!
<stgraber> nacc: it's attempting to set fs capabilities, that's not supported inside user namespaces by the kernel
<stgraber> nacc: most other packages fallback to setuid when that happens (ping for example)
<stgraber> we also have a kernel fix for this but it's not been merged mainline yet
<stgraber> hallyn wrote the patch and has been trying to get it merged upstream for a while now
<nacc> stgraber: ok, what would you recommend we do on armhf? it feels like a packaging issue in newpid really?
<nacc> but if we are going to rely on newpid and newpid is known to not install in userns, then it seems like machine-isolation is an ok solution for now
<stgraber> nacc: why do you rely on newpid in the first place?
<nacc> stgraber: this test uses the `newnew` utility
<nacc> stgraber: i err, newnet
<stgraber> how about just changing the test to use unshare instead which comes from util-linux
<nacc> stgraber: i can do that, let me see ... s/netnew/unshare -n/ ?
<stgraber> I have no idea why someone even wrote newpid/newnet when util-linux provides a tool which does all of that and has done for years...
<stgraber> nacc: yup
<nacc> stgraber: thanks, testing
<nacc> stgraber: thanks seems to work!
<nacc> jbicha: --^ so that will need to build and then run through
<nacc> is this a case of just retry on armhf? " unable to install updated status of 'python-minimal': No space left on device"
<nacc> yep, it was, succeeded on retry
<hallyn> newnet?
<memeka> can anyone help with this: https://paste.ubuntu.com/24088463/ ?
<Unit193> mvo: Did you ever see LP 643623?
<ubottu> Launchpad bug 643623 in ubuntu-keyring (Ubuntu) "Should ubuntu-keyring include the debug archive key?" [Undecided,Confirmed] https://launchpad.net/bugs/643623
<mvo> Unit193: I have not seen this bug, no. I think its a valid request
<Unit193> mvo: Great, I think with Debian moving more towards dbgsym packages, would be great if apt-setup created that, commented out, in sources.list by defaul too.  I plan to file that bug after this gets closed.
<sarnold> Unit193: have you seen clear linux's debug symbol server thing? "all the symbols" sitting there waiting for FUSE to read them.. I fear find and rsnapshot etc but it sure would be convenient..
<Unit193> sarnold: No, I have no idea what that is.
<Unit193> s/that is/their setup/
<sarnold> hrm, a bit short https://clearlinux.org/features/all-debug-information-all-time
<Unit193> Not sure I like a fuse mount to a remote server on all the time, but that's certainly pretty cool.
<sarnold> yeah it feelsl ike something you'd really want to turn o nwhen you want it
<sarnold> maybe with a -t3600 or something so you don't forget to turn it off again :)
<Unit193> Wonder how that affects df calls.
<sarnold> hopefully the right thing, the fuse filesystem apparently can hook that http://libfuse.github.io/doxygen/fuse__lowlevel_8h.html#aa1d95ec3ca674253baac3639ea10f0ff
<Unit193> I have df (with --local, which fuse ignores) in my bashrc, slowdowns are fun.
<cpaelzer> Odd_Bloke: smoser: no expectign that the latter is awake, could you take a look at bug 1668876
<ubottu> bug 1668876 in simplestreams (Ubuntu) "Yakkety daily image (1st March) sync broken" [Undecided,New] https://launchpad.net/bugs/1668876
<cpaelzer> TL;DR assumption daily yakkety images of this night don't match metadata (size/checksums)
<cpaelzer> I tried from a lab and from home and both match, but if anyone else could try the wget/sha256 or the sync command I listed in the bug - just to see if there are any proxy/caching things different around the world
<javier4> I got this error trying to cross-compile wpa for armhf on a x86_64 host.
<javier4> "/usr/include/qt4/QtCore/qatomic_armv5.h:131: Error: no such instruction: `swpb %al,%bpl,[%rbx]'"
<javier4> Reading online it seems to be due to an incorrect setup of qmake. In particular it seems to not find the arm toolchain.
<javier4> I'm totally ignorant in QT developing. The only file that I think could be a config for qmake is the wpa_gui.pro that qmake should use to generate its makefile.
<javier4> https://www.irccloud.com/pastebin/ni0ymJpB/
<javier4> Should I modify it someway?
<rbasak> jbicha: around? About bug 1571816. Did 1:1.6.2-0ubuntu14.2 actually achieve anything then? If not, I'm not sure we should be releasing it.
<ubottu> bug 1571816 in wine-development (Ubuntu Yakkety) "Gnome Software catalog entry missing for Wine" [Medium,Fix committed] https://launchpad.net/bugs/1571816
<jbicha> rbasak: before the update, wine1.6 does not show in gnome-software at all, after the update it shows as "Configure Wine" which while odd is still an improvement
<jbicha> see also my last comment on bug 1639507
<ubottu> bug 1639507 in unity-control-center (Ubuntu Yakkety) "unity-control-center in installed software is listed with wrong icon and title" [Medium,Fix committed] https://launchpad.net/bugs/1639507
<rbasak> jbicha: I'm dubious about that as a justification, because users still have to download tons of updates, and I think I'd prefer to know and confirm the full fix. But separately from that, I'm questioning "Set X-AppStream-Ignore=true" specifically between 1:1.6.2-0ubuntu14.1 and 1:1.6.2-0ubuntu14.2, which AFAICT didn't do anything?
<jbicha> all the other parts of 1571816 work correctly (wine-development on xenial and yakkety and wine/yakkety)
<rbasak> jbicha: so to be clear, 1) I appreciate that it works incrementally after the update, though I'm not sure that's enough so that's one question; and 2) is the update actually minimal, because of the effectively no-op X-AppStream-Ignore change?
<jbicha> right, 14.2 had no effect :( it might be needed if we fix gnome-software but I don't know
<rbasak> jbicha: I appreciate you driving this. Though IMHO, the bug isn't severe enough to warrant landing a half fix.
<rbasak> I appreciate it's subjective though. Other ~ubuntu-sru may disagree and I'm fine with that.
<jbicha> the x-appstream-ignore change is probably correct though, it was flagged as an issue on http://appstream.ubuntu.com/xenial-proposed/universe/issues/wine1.6.html
<jbicha> that page doesn't exist now because it was fixed in -proposed but this still does
<jbicha> http://appstream.ubuntu.com/xenial/universe/issues/wine1.6.html
<rbasak> jbicha: sure, but probably correct isn't enough for an SRU.
<rbasak> jbicha: I'd prefer to see definitely verified correct with a real user impact confirmed resolved.
<rbasak> jbicha: but, I think the Yakkety bits do work, right?
<jbicha> yes, the other 3 packages work fine; it's just wine1.6/xenial that's half fixed
<jbicha> I think the 2 biggest packages left that people complain about not showing in Software are steam (non-i386) and wine
 * rbasak is still sorting out his understanding of which pieces do what
<jbicha> until yakkety, Ubuntu had wine1.6 which was fairly separate from Debian's wine packaging
<jbicha> Debian has wine and wine-development which are the same except wine-development is a newer ("less stable") version
<jbicha> Debian's packaging doesn't have any .desktops so it's not affected by the "gnome-software picking a random .desktop instead" bug
<rbasak> jbicha: is "Fix Committed" correct for wine1.6's development task? Or should that be Invalid?
<rbasak> Hmm. wine1.6 is still in Zesty?
<jbicha> wine1.6 is just a transitional package in 16.10+
<rbasak> OK, so Invalid?
<jbicha> if you want; I just had it set to the same status as xenial
<rbasak> jbicha: OK thanks. wine1.6 for Xenial hasn't aged enough anyway. The others look fine to accept. Personally I'd hold wine1.6 in xenial-proposed until it's properly resolved, and drop the X-AppStream-Ignore change unless it is demonstrably required.
<rbasak> (demonstrably required whether for this bug or some other SRU-worthy issue)
<jbicha> ok
<smoser> cpaelzer, commented in your bug.
 * cpaelzer reading
<cpaelzer> thanks smoser
<cpaelzer> I was kind of waiting you to point me to a user error, thanks for reassigning where it belongs to
 * cpaelzer is not sure if broken images are really better than me haning up on a user error
<smoser> cpaelzer, diamond is still up
<cpaelzer> smoser: sure I didn't kill it
<cpaelzer> a bunch of broken guests around
<cpaelzer> smoser: but I'd want to wait with a reinstall until the power Devs had a chance to inquire
<smoser> what did you want to do about firware there ?
<cpaelzer> smoser: keeping as-is in regard to my issue, we can go to 860 if you need that for other reasons
<cpaelzer> smoser: I'm pretty convinced it is not a FW issue, but if you want I can up that to 860
<cpaelzer> smoser: just the re-deploy of the OS is what I'd postpone atm
<smoser> cpaelzer, ok
<rbasak> jbicha: regarding https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1662749/comments/4 and https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1662750/comments/4, it'd be useful to state the actual package version strings tested. We've had a severe SRU regression in the past because of confusion due to the lack of that being stated.
<ubottu> Launchpad bug 1662749 in gnome-software (Ubuntu Yakkety) "GNOME Software has entry in Startup Applications" [Low,Fix committed]
<ubottu> Launchpad bug 1662750 in gnome-software (Ubuntu Yakkety) "Remove 3rd party / non-free license warnings and just show license as Unknown" [Medium,Fix committed]
<rbasak> Note though that I'm not releasing it yet due to https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1621971/comments/16.
<ubottu> Launchpad bug 1621971 in gnome-software (Ubuntu) "Add handler for snap: URLs" [Wishlist,Triaged]
<jbicha> rbasak: good catch, it was fixed in gnome-software 3.23.90 but zesty is still at 3.22.5 so we need to backport that patch
<barry> nacc: afaict, pycxx doesn't have any reverse-depends
<tsimonq2> slangasek: :O is patch pilot no longer a thing? Nobody is on the calendar...
<nacc> barry: ack, was just wondering as it's been stuck for a while
<nacc> tsimonq2: i have it on my calendar periodically, at least
<nacc> hallyn: yeah, i guess it's an alternative wrapper just for network namespaces?
<nacc> jbicha: do you have a track of what all still requires src:postgresql-9.5 in 17.04?
<jbicha> nacc: uh, maybe nothing?
<nacc> jbicha: ack, i just updated the bug
<nacc> slangasek: would you mind taking a peek at my last comment in LP: #1666566 when you have a moment?
<ubottu> Launchpad bug 1666566 in postgresql-9.5 (Ubuntu) "Transition from src:postgresql-9.5 to src:postgresql-9.6" [Undecided,New] https://launchpad.net/bugs/1666566
<slangasek> nacc: ugly that repmgr declares that its dep is satisfied by a package that it no longer builds from its own source; but binaries removed now
<nacc> slangasek: agreed, and thank you!
<slangasek> nacc: and 9.5 removed
<nacc> slangasek: great, thanks! I'll have pings about mariadb shortly too, i think :)
<jtaylor> barry: re python regression, have you tested turning the computed gotos on and off in xenial, so far I know python2 in xenial has that python3 backport
<jtaylor> though that should improve performance in theory, but you never know
<barry> jtaylor: thanks. caribou has done most of the actual testing ^^.  i'll make sure he knows about that
<nacc> jgrimm: figured out the issue with ocfs2-tools; it depends on dlm-controld which ubuntu renamed to dlm
<nacc> jgrimm: fixing
<jgrimm> ahh. cool
<nacc> jgrimm: should make a note somwhere theat uploaders ofdlm will need to fix ocfs2-tools
<jgrimm> suggestion on where?
<nacc> powersj: --^ fyi
<powersj> given I packaged dlm this time around, is there a reason to keep the rename?
<nacc> powersj: the changelog only mentions history
<powersj> yeah...
<jgrimm> i'm trying to remember the history.. was it that debian renamed and we wanted to keep our legacy historic name? or just thought it was cleaner? may have to dig for the reason to answer your question
<nacc> jamespage: --^ do you know the history?
<nacc> jgrimm: yes, it seems something historical -- that we relied on 'dlm' being the binary package name (it's only source in debian)
<nacc> jgrimm: feels like something we should transition in 18.04 so we can sync
<jgrimm> nacc, sounds reasonable indeed
<nacc> jgrimm: well, we can transition in z+1 and then drop it after 18.04, that is
<jgrimm> please add to the whiteboard
<nacc> ack
<jgrimm> thanks
<nacc> yeah, lvm2 carries a delta for this same issue
<nacc> so we'd be able to drop a few pieces of delta and sync two packages
<jgrimm> cool, yeah seems like busywork that we should drop
<jgrimm> nacc, i'd straight out open a bug to track all the packages as well
<nacc> jgrimm: LP: #1669133 and bp updated
<ubottu> Launchpad bug 1669133 in ocfs2-tools (Ubuntu) "Drop unnecessary rename of dlm -> dlm-controld (binary package)" [Undecided,New] https://launchpad.net/bugs/1669133
<jgrimm> nacc, thanks sir!!
<nacc> jgrimm: upload ofcs2-tools as well, should go through
<jgrimm> ack. thanks
<nacc> slangasek: so i think mariadb-10.0 may not be showing up in NBS because of the powerpc binaries leftover? last comment in LP: #1669073
<ubottu> Launchpad bug 1669073 in mariadb-10.1 (Ubuntu) "Transition from src:mariadb-10.0 to src:mariadb-10.1" [Undecided,New] https://launchpad.net/bugs/1669073
<slangasek> nacc: it's not NBS because the source is still in zesty.  Do you want mariadb-10.0 removed?
<slangasek> NBS == not built from source; but there's a source there which builds it
<nacc> slangasek: err, yes, sorry!
<nacc> slangasek: yes, my eventual goal is removal of src:mariadb-10.0
<slangasek> nacc: right - do you want me to delete it now? :)
<slangasek> it'll take the binaries with it when it goes
<nacc> slangasek: yes please
<nacc> slangasek: i would update that bug with a task for mariadb-10.0 but i'm getting LP timeouts
<slangasek> nacc: removal done, and I'll take care of the lp bug update when timeouts relax
<nacc> slangasek: thanks
<nacc> slangasek: on a different note, i'm not sure what to do about liblog4ada's regressions in z-p. afaict, it's not passed on ppc64el/s390x since september (and unfortunately the passing logs seem to be gone). But it feels like it's not strictly true that it's a regression in any of the packages affected.
<nacc> sbeattie: fyi only mariadb-10.1 is now in z
<sbeattie> nacc: thank you!
<nacc> sbeattie: np
<nacc> slangasek: last one :) LP: #1667834
<ubottu> Launchpad bug 1667834 in php7.1 (Ubuntu) "[FFe] Please remove php7.1 from zesty" [Undecided,New] https://launchpad.net/bugs/1667834
<slangasek> nacc: it shouldn't be in main anyway, so no security committment, right?
<slangasek> regardless, demoted to zesty-proposed
<slangasek> oh
<nacc> slangasek: right, we just don't want to ship two
<nacc> slangasek: it's in universe
<slangasek> but I shouldn't go and close the bug that I just marked as block-proposed
<nacc> slangasek: ah i see, so what happens is php7.1 still gets synced, but stays in proposed becuase of the tag? fancy!
<slangasek> nacc: yep
<nacc> slangasek: TIL and thanks!
#ubuntu-devel 2017-03-02
<nacc> sbeattie: do you want to update the tasks in LP: #1657594 accordingly? i think the zesty mariadb-10.0 task can  either be removed or marked invalid and i'm not sure if 10.1 needs the CVE fix?
<ubottu> Launchpad bug 1657594 in mariadb-10.1 (Ubuntu Zesty) "USN-3174-1: partially applies to MariaDB too" [Medium,New] https://launchpad.net/bugs/1657594
<sbeattie> nacc: I've updated them now, thanks.
<nacc> sbeattie: np, thanks!
<otto> Can somebody trigger a rebuild of https://launchpad.net/ubuntu/+source/mariadb-10.1/10.1.21-5/+build/11934111 ? It OOMed and a rebuild might fix it
<ginggs> otto: triggered
<otto> ginggs: thanks!
<caribou> I need some counseling on the unattended-upgrade-shutdown systemd unit
<caribou> right now, it is ordered as Before=shutdown.target reboot.target halt.target network.target local-fs.target
<caribou> if /var is a separate FS, local-fs.target will complete before  unattended-upgrade-shutdown start
<caribou> and the script expect /var/run to be there, so it blocks & timeout waiting
<caribou> I'm trying to figure out how to sequence it so it can complete before /var gets unmounted
<bluss> there is no bug tracker for libappindicator?
<bluss> I can't find it
<fossfreedom_> bluss: https://bugs.launchpad.net/ubuntu/+source/libappindicator
<tjaalton> doko: llvm-4 ping. could it be moved to main now
<tjaalton> to unblock mesa
<doko> tjaalton: what are the remaining dependencies on 3.9 in main?
<tjaalton> libclc is updated, not sure about the others
<tjaalton> there aren't many
<sinzui> Juju testing is seeing a dbus problem on zesty. Is someone about to comment on bug 1665160
<ubottu> bug 1665160 in juju "MachineSuite.TestMachineWorkers timed out waiting for workers zesty because dbus is in interactive mode" [High,Incomplete] https://launchpad.net/bugs/1665160
<jbicha> fossfreedom_: I confirm that I can launch apps on budgie with downgraded mutter 3.23.90-0ubuntu2
<jbicha> could you file bugs with mutter and budgie-desktop upstream?
<fossfreedom_> jbicha: thanks for the confirmation.  I'm trying to get a relevant valgrind log - will attach bug reports with it.  cheers
<jbicha> we can revert mutter if we need to, but it would be nicer if we could just revert a commit or two if we can isolate what's wrong
<jbicha> tseliot: Ubuntu GNOME has suffered from bug 1559576 for the past year
<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
<jbicha> if I understand the most recent comments correctly, it can be fixed by making sure the nvidia-* packages depend on xserver-xorg-legacy
<jbicha> by the way, GDM3 uses Wayland by default (even though Ubuntu's gnome-shell still uses X by default)
<sil2100> slangasek: hey! I think I need a TB member to +1 the SRU release of thunar: https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1512120
<ubottu> Launchpad bug 1512120 in thunar (Ubuntu Yakkety) "[SRU] thunar crashes on file renaming" [Undecided,In progress]
<sil2100> slangasek: could you take a look? The procedures on the wiki page mention that in case of microreleases without all bugs mentioned in the changelog and no good test coverage, this is required
<slangasek> sil2100: the last TB ruling is that the SRU team have total discretion of how to manage SRUs; are you asking because you think it shouldn't go in as-is?
<slangasek> sil2100: oh, you're asking because the wiki page is out of date
<sil2100> slangasek: no, I'm asking because I follow the SRU wiki page ;p
<slangasek> :)
<sil2100> Ok, in that case thanks for the info!
<sil2100> The changes look sane, all bugfixes and seriously not much more critical can happen than what's already present
<slangasek> sil2100: if this is a deviation from the SRU policy, and it's going to be a recurring theme, we should get a wiki page documenting the exception
<rbasak> Yeah I think that should be ~ubuntu-sru policy for anything expected to be recurring.
<rbasak> Then we can be consistent to uploaders.
<rbasak> And we should document the test plan, what is and isn't acceptable, etc. Effectively TB exceptions but done by ~ubuntu-sru.
<tseliot> jbicha: I'll look into that again. The legacy drivers already pull in that package, so I could make sure that the non legacy one does the same.
<jbicha> tseliot: great, could you look into SRUing that too?
<tseliot> jbicha: yes, it should be doable
<tdaitx> robru, regarding britney email: on the very first run, will it sent the package list for each uploader in a single email or will it send 1 email for each package to each uploader?
<robru> tdaitx: it sends one email for each individual stuck package it finds.
<robru> slangasek: gaughen: tdaitx: ok I made some revisions if you want to re-review the draft
<tdaitx> robru, I saw it, it is much better now
<robru> thanks
<juliank> Eww, anyone has a test case for bug 1657567
<ubottu> bug 1657567 in apt (Ubuntu Yakkety) ""Content-Range: */<file size>" on non-416 responses considered invalid" [Low,In progress] https://launchpad.net/bugs/1657567
<juliank> It seems to me that sourceforge has fixed their end, so we need some other server that responds with a Content-Range field on a redirect
<tdaitx> robru, made another suggestion as for some reason I don't really like seeing the "newly-stuck" phrase relate to the "large volume" phrase. I think they are somewhat independent
<robru> tdaitx: thanks, accepted
<juliank> I have a test case now
<juliank> But I hijacked my entire domain for it...
<juliank> I should add a subdomain for that
<juliank> random-stuff.jak-linux.org
<juliank> For those wondering, the test case is `/usr/lib/apt/apt-helper download-file -o debug::acquire::http=1 http://www.jak-software.de/lp1657567 ubuntu.iso` now
<jbicha> doko: could you look into bug 1669132 ?
<ubottu> bug 1669132 in openjdk-8 (Ubuntu) "openjdk should stop recommending gconf and other deprecated gnome2 stuff" [High,Triaged] https://launchpad.net/bugs/1669132
<nacc> doko: ping/
<doko> jbicha: I'll have a look tomorrow
<doko> jbicha: for which releases did you check that?
<jbicha> doko: zesty, I was using reverse-depends -c main src:gconf
<doko> jbicha: could you check that for xenial and yakkety as well? bonus points for trusty ...
<jbicha> doko: you just want me to check what's using gconf?
<doko> jbicha: we are using the same package for older releases. just want to make sure that we can still backport it, so if gconf is recent enough, then we can apply the change there too
<nacc> doko: just looking for any guidance on that liblog4ada regression
<jbicha> doko: oh, I believe smcv already did that analysis for precise and up at https://bugs.debian.org/850268
<ubottu> Debian bug 850268 in src:openjdk-8 "Please stop using deprecated GNOME libraries (libgnome-2-0, libgnomevfs2-0, libgconf2-4)" [Normal,Open]
<doko> nacc: I need to follow up with the Debian guys ... they had a procedure to follow
<doko> jbicha: ok, looking at these tomorrow
<nacc> doko: thanks, i am happy to help, just not sure on the order to get everything updated :)
<tdaitx> robru, I'm good with the britney2 email changes now, both the announcement and stuck message read well and seem fine =)
<doko> tjaalton: done. can you do the llvm-defaults update?
<tjaalton> doko: yup, thanks
<doko> nacc: it should be according to the build-dependencies
<doko> so when in doubt, start from the libs directly using libgnat
<nacc> doko: ok, i will try that, thank you
<robru> tdaitx: thanks!
<nicman23> hello i uploaded a new package to launchpad and i have not gotten any mail indicating rejection or acceptance since 5 hours ago. what gives?
<nacc> nicman23: to a PPA?
<nicman23> yes
<nacc> nicman23: which PPA?
<nicman23> https://launchpad.net/~n-fit-8
<nacc> nicman23: did dput report success?
<nicman23> yes
<nicman23> i could try again
<nacc> nicman23: you could; and if it really was uploaded, it will get rejected
<nicman23> deleted the ppa.upload file and uploading now
<nicman23> it reports "Successfully uploaded packages."
<sarnold> this says "published 4 hours ago" on wlc-git-... https://launchpad.net/~n-fit-8/+archive/ubuntu/sway-git/+packages
<nicman23> yeah that is the other package that is needed
<sarnold> aha
<nicman23> would it matter if the section was wrong or it would just reject it?
<nicman23> also does size matter?
<cjwatson> There are a couple of bugs where certain syntax-level errors in the .changes file can cause a silent rejection.
<cjwatson> 2017-03-02 19:45:14 INFO    Failed to parse changes file '/srv/launchpad.net/ppa-queue/incoming/upload-ftp-20170302-194329-027611/~n-fit-8/sway-git/sway-git_0.12-rc1-18-gd4aa604-2_source.changes': Unable to find mandatory field 'Date' in
<cjwatson> the changes file.
<cjwatson> Did you write the .changes file by hand or something?
<nicman23> no but i did just run debuild and got 2 errors .......... brb (the software itself works)
<cjwatson> I'm not sure how you could end up without a Date field by using the standard tools.
<cjwatson> Can you pastebin the .changes file?
<nicman23> probably was the errors in debuild. i though i had pushed some changes and worked in another computer .... Should work now
<nicman23> man PKGBUILDs are so easier :/
<cjwatson> I should finish that LP branch I had lying around to make those rejections not be silent, which would help.
<nicman23> btw should i bump the version number?
<pitti> Laney: did you change something wrt. kernel pinning? I'm now regularly seeing https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-pitti-systemd-semaphore/xenial/i386/s/systemd-upstream/20170302_173333_a1919@/log.gz
<pitti> Laney: the linux-headers-generic there is from xenial-release
<cjwatson> nicman23: That's not required in this case, since the upload was rejected.
<nicman23> thanks new to launchpad and all :)
<cjwatson> nicman23: You can't reuse a version once it's been accepted, so bumping the version is a good habit to be in.
<nicman23> cjwatson: in what format should date in changelog be? my locale is greek ..
<nicman23> also still nothing
<cjwatson> nicman23: Can you please pastebin the .changes file?
<nicman23> yes
<nacc> nicman23: how are you generating your .changes file? you shouldn't need to know the format really, afaict, using standard tooling
<pitti> Laney: although, no change in autopkgtest-cloud, time-wise this rather coincides with https://launchpad.net/ubuntu/+source/linux/4.4.0-64.85
<cjwatson> nicman23: You should use dch to maintain debian/changelog, at least when adding new blocks to the top of it.
<nicman23> i wrote a script
<cjwatson> If your script doesn't use dch, and you have to ask what the format is, then your script is probably wrong :-)
<nacc> nicman23: what does your script do?
<nacc> nicman23: it seems likely to be what cjwatson said -- i would suggest using the existing tools rather than writing your own :)
<nicman23> merge upstream (has no debian folder), rebase, write changelog and debuild -S
<nicman23> naac: but that is no fun :P
<nacc> nicman23: how does it write the changelog?
<nicman23> give me 1
<mwhudson> oh great there is some big circular dependency mess of golang packages in zesty-proposed :(
<nicman23> it is not complete but here : (keep in mind i am hobbyist) https://github.com/nicman23/sway/blob/debian/upstream.sh
<cjwatson> That is almost certainly wrong.
<cjwatson> should be date -R
<nacc> nicman23: yeah, use dch ...
<cjwatson> dch -D xenial -v "$version" -m "Bumped to commit $commit"
<cjwatson> or similar
<nacc> bdmurray: re: puppet in yakkety-proposed (regression in autopkgtests). It's not an actual regression from this upload, in that it was broken before. Do you want me to fix the tests in a follow-on upload? Not sure it qualifies for SRU, but I have the fix we used for zesty for the same.
<nacc> bdmurray: or any advice on that
<nicman23> sigh man dch here i go :/
<cjwatson> (You may need to set DEBFULLNAME and DEBEMAIL in your environment.)
<nicman23> cjwatson: if you care there is the bitbucket http://pastebin.com/ksgu5Cap
<cjwatson> Your script may be buggy in another way, by the way: $date seems to be unset when you do git commit -am "fast on date $date"
<nicman23> it does not rebase anything atm, master is not updated
<nicman23> thanks though :)
<cjwatson> I gather that's after you fixed the date in debian/changelog.
<nicman23> yes
<cjwatson> Since it seems to have the correct date format, and a date that's during this conversation
<bdmurray> nacc: remember them for the next SRU is my advice
<nacc> bdmurray: ack
<nicman23> btw is there anyway to set the package to also be compiled for releases that are not ie xenial, but xenial and later?
<nacc> nicman23: normally you upload it multiple times -- maybe copy packages in your ppa can do it, though
<nicman23> yeah i though so
<jbicha> nicman23: best practice would be to use different version numbers for different series (xenial, yakkety) since different series may be built against different libraries
<sarnold> some handy guidelines are at https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<nicman23> thanks all :) , it got accepted and is building
<Laney> hey pitti
<Laney> presumably something to do with the kernel rollback?
<Laney> pitti: being DoSed by m1.large tests atm, so I can't boot an image to check that it has the bad kernel installed, and I won't be able to rebuild the xenial one
<Laney> ah wait, there will be a manifest on cloud-images.u.c
<Laney> yeah that looks bad
<Laney> smoser: ^- any chance you (or someone, sorry I forgot who to ping) could kick some new xenial daily cloud images out of schedule? they have a kernel which has been removed from updates, causing uninstallability for some autopkgtests
<Laney> if not, not a huge deal as the next dailies should be good, but would be nice to get good ones now
<javier4> Is there a way to make "sbuild" ignore .dsc checksums? In practice something like this?
<javier4> --debbuildopt=--source-option=--nocheck
<valorie> cyphermox: after the new updates to zesty last night, laptop didn't freeze overnight! btw the previous day I had purged firefox, but still had freezes
<valorie> so fingers crossed and knock on wood -- fixed for me. Fixed for you?
<fory> hi guys, got a strange problem, i can connect via SSH during the initial of the boot then it seems i get a message like this "NETDEV WATCHDOG: eth0 (tulip): transmit queue 0 timed out" and i cant access the server anymore... the server cant even ping its own gateway... can someone assist?
<pitti> Laney: ah, that explains it, thansk!
<sarnold> fory: does your NIC driver allow you to disable the watchdog timer? (perhaps via ethtool) did it work on older kernels?
<fory> seems like disabling irqbalance solved it!
<sarnold> o_O
<fory> found it somewhere online
<fory> this has happened to me in about 2-3 random VM's
<sarnold> please do file a bug against linux; I know the bot will dissuade you at every turn, but "disable irqbalance" doesn't feel like a real solution :)
<fory> sure will do, but atm in a clock-rush to deliver this VM :(
<fory> murphy's law atm
<sarnold> yikes, I'm glad you found the irqbalance workaround then :)
<fory> you bet
<fory> i'd be jobless if i didnt i guess
<cyphermox> valorie: not at all, but part of it is imputable to having too little memory. It's still slow, but less since I switched from unity to gnome-shell to try that out.
#ubuntu-devel 2017-03-03
<valorie> cyphermox: I spoke too soon -- returned home from shopping to find it frozen again
<valorie> :(
<valorie> valorie-GT60-2PC': Running inside KDE Plasma 5.9.2 on Ubuntu 17.04 (Zesty Zapus) powered by Linux 4.10.0-9-generic, CPU: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz at 1899/3800 MHz, RAM: 2620/24027 MB
<valorie> plenty of memory here, and plasma runs flawlessly until the freeze
<valorie> fooey
<Unit193> sil2100: G'morning!  How's the thunar SRU looking?
<sil2100> Unit193: morning! All good, will publish it in a few minutes!
<sil2100> Just need to wake up
<Unit193> \o/
<Unit193> Hah, get some good coffee.  We were just trying to make sure it gets in well before our Trusty EOL.
<Laney> pitti: want to try resubmitting a systemd request?
<Laney> I just built some bodged up adt images
<pitti> Laney: â¥
<pitti> Laney: https://github.com/systemd/systemd/pull/5528 is running from 20 mins ago, that might just have missed it
<pitti> Laney: I'll retry that one if/after it fails
<Laney> depends if it hit lcy01/amd64 :P
<pitti> https://github.com/systemd/systemd/pull/5529 is from 6 mins ago, that should have caught it
<Laney> ok, nice
<pitti> Laney: I'll retry https://github.com/systemd/systemd/pull/5510 now, that already failed (yesterday-ish)
<Laney> pitti: 5528 seems to be building
<Laney> so that's past where it would have broken already
<pitti> nice!
<Laney> IIUC
<pitti> yeah, it would have failed early, during setup-commands
<Laney> i386/lgw01 amd64 came a bit later
<Laney> -y --allow-downgrades FTW
<pitti> Laney: so we published a kernel update, the daily cloud images grabbed it, then we pulled the kernel update?
<Laney> right
<pitti> "nice" timing
<Laney> then you couldn't install linux-* because of the = depends
<pitti> thanks for debugging that
<Laney> np, I knew it had happened so it didn't take me long to connect once I saw a failing log
<pitti> Laney: https://github.com/systemd/systemd/pull/5528 i386 failed; I think that's the one that missed your update by a few minutes, retrying
<Laney> nod
<xnox> smoser, xe-daemon.service has weird stanzas w.r.t. cloud-init units and it ends up a dependency loop.
<xnox> Before=network.target cloud-init.service cloud-init-local.service seems wrong to me
<xnox> i would have thought it should be After=cloud-config.target Wants=cloud-config.target instead
<smoser> xnox, did you get sorted on that ?
<xnox> somewhat
<xnox> smoser, i think xe-daemon encodes correctly everything it needs without cloud-init as well.
<xnox> but i will test that out
<smoser> xnox, it quite possibly does.
<smoser> josvaz, was just not interested in pushing an sru at that point.
<javier4> Sorry If I ask the same question again: is there a way to make sbuild ignore checksum of sources inside a .dsc?
<tjaalton> LocutusOfBorg: hi, what's up with virtualbox autopkgtests failing?
<LocutusOfBorg> looking
<LocutusOfBorg> apw, please merge virtualbox kernel drivers? ^^
<LocutusOfBorg> tjaalton, seems that the kernel module is already provided in the driver itself, so installing the dkms package is useless
<LocutusOfBorg> usually kernel people were behind virtualbox version, so the dkms packages was overriding the kernel one
<LocutusOfBorg> right now this isn't the case
<tjaalton> ok
<tjaalton> the dkms failure was seen on erlier tests too that passed iirc
<apw> tjaalton, that is one of those where i need to fix the tests to understand that the kernel also has versions of the driver
<apw> if the error is "already installed" it should be ignorable
<tjaalton> ah ok
<nacc> rbasak: around?
<rbasak> nacc: o/
<nacc> rbasak: wondered if you had some time to talk about the -devel pointers?
<rbasak> Sure!
<nacc> rbasak: HO ok?
<rbasak> Yeah. Two minutes please.
<nacc> rbasak: of course
<forehelp> hi all, how can i have two machines that are updating from the same repo (an internal repo), new ones show 14.04.5 and old ones show 14.04.3 ? kernel is the same... what package is making this change ?
<nacc> forehelp: wrong channel?
<forehelp> nacc: yes sorry i asked on the right one
<powersj> infinity: slangasek: similar to the server amd64,i386 ISOs, can we get our automated tests blocking the release of those for ppc64el as well?
<bulletxt|2> hi, can someone be kind enough to see if ubuntu kernel 3.16.x series has the intel i219-lm network driver?  Thanks a lot
<bulletxt|2> or, how can I see if the intel e1000 loaded driver has such support?
<sarnold> bulletxt|2: if I'm reading this correctly, that kernel hasn't had any updates since july https://launchpad.net/ubuntu/+source/linux-lts-utopic
<bulletxt|2> ok but
<bulletxt|2> does it have support for the driver? sarnold
<bulletxt|2> how can I discover this info?
<bulletxt|2> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16.40/
<sarnold> ah here we go, here's the git tree http://kernel.ubuntu.com/git/ubuntu-archive/ubuntu-utopic.git/
<sarnold> they apparently move the no-longer-supported ones to ubuntu-archive
<sarnold> oh hrm that .. looks too old.
<bulletxt|2> sarnold: I just need to know if the driver is included in the 3.16 series
<bulletxt|2> how can I discover this?
<wxl> bulletxt|2: looks like, using the most recent 3.16 tag and searching the tree, there's e1000e http://kernel.ubuntu.com/git/ubuntu-archive/ubuntu-utopic.git/tree/drivers/net/ethernet/intel?h=Ubuntu-3.16.0-44.59
<wxl> looks like support has existed in that driver since 2012 https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=2fbe4526e5aafc9ffa5d85fa4749a7c5b22af6b2
<bulletxt|2> wxl: no
<bulletxt|2> its not i217
<bulletxt|2> its i219
<bulletxt|2> which came out in 2015
<wxl> i quote "e1000e: initial support for i217"
<bulletxt|2> in my case the card is i219-lm
<wxl> ah
<bulletxt|2> can you check when that has been added in the official linux kernel? I guess its 4.0 series
<sbeattie> Looking at http://cateee.net/lkddb/web-lkddb/E1000E.html seems to indicate the first upstream kernel to support it (device: 156f) is the 4.1 kernel
#ubuntu-devel 2017-03-04
<bulletxt|2> thanks sbeattie
<sarnold> sbeattie: wow that's cool
<wxl> wow i did NOT know about lkddb sbeattie thanks!
<bulletxt|2> any way to understand if ubuntu ever backported it to the  3.13, or 3.16 series?  even 3.19 would be fine
<sarnold> way easier than hunting through git trees :)
<sbeattie> rando googling for the win (TIL also)
<wxl> bulletxt|2: why not ask if you can get the kernel that includes the support you're looking for?
<bulletxt|2> im on 12.04 and for the moment I cant upgrade
<wxl> 12.04 is still supported
<bulletxt|2> I cant install 4 series can I ?
<sarnold> it'd be best to test on a staging machine before production but I'd expect it to work
<bulletxt|2> I tried installing 4.4 but it complains it cant find kmod package
<wxl> bulletxt|2: linux-generic-lts-xenial will get you 4.4
<bulletxt|2> reallyÃ©
<bulletxt|2> ?
<bulletxt|2> let me check
<wxl> yuup
<wxl> were you otherwise trying to compile 4.4 yourself?
<sarnold> that's probably only available on 14.04 LTS
<wxl> oh derp
<wxl> sorry
<wxl> i take it back
<bulletxt|2> yea
<wxl> precise not trusty :(
<bulletxt|2> yea :(
<sarnold> but it might still be the easiest way to get there
<wxl> you can get 3.13 with linux-generic-lts-trusty but that's not 4.1
<bulletxt|2> yea, so the question is, does latest 3.13 have backportd that driver? :)
<sbeattie> it does not (just checked)
<bulletxt|2> :(
<bulletxt|2> sbeattie: what about 3.16 or 3.19 ?
<wxl> you could request an SRU (yeah, i doubt it)
<wxl> or you could just upgrade the version
<sbeattie> looks like the 3.19 kernel(vivid/linux-lts-vivid) has it backported; *however* that kernel is not officially supported by the kernel team anymore.
<bulletxt|2> 3.19? really? that because I can install this on 12.04  http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19.8-vivid/
<bulletxt|2> when was that backported?
<bulletxt|2> because this actually is newer, http://kernel.ubuntu.com/~kernel-ppa/mainline/linux-3.19.y.z-review/current/
<bulletxt|2> not sure what's the differenfe thoughÃ¹
<sbeattie> mainline == upstream's 3.19 kernel != the ubuntu kernel team's kernel
<bulletxt|2> mm
<wxl> i mean if you don't care about it being supported there's quite a few ways you could probably go
<bulletxt|2> for example?
<wxl> compile it yourself, maybe search for ppas, etc.
<bulletxt|2> wxl: intel seems to offer source   https://downloadcenter.intel.com/product/82185/Intel-Ethernet-Connection-I219-LM
<bulletxt|2> but I cant even compile that doing "make"
<bulletxt|2> not sure what im doing wrong
<wxl> heh
<wxl> well if i click on linux for OS, it gives me stuff for freebsd :)
<bulletxt|2> it says OS linux... not sure what intel is doing on that page..
<wxl> https://downloadcenter.intel.com/download/17509/Intel-Network-Adapter-Gigabit-Base-Driver-for-FreeBSD-?product=82185
<sbeattie> (For the record, this was the commit in the vivid 3.19 kernel that added support for it https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/vivid/commit/drivers/net/ethernet/intel/e1000e/hw.h?id=bb198e17affadccf6273253b295dbf100e367b56 )
<bulletxt|2> thanks
<sbeattie> (sorry, wrong url, https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/vivid/commit/?id=bb198e17affadccf6273253b295dbf100e367b56 )
<bulletxt|2> who knows if the ubuntu kernel ppa team put that too
<sbeattie> it's not going to be in the 3.19 mainline kernel
<bulletxt|2> yea
<sbeattie> also, 12.04 has about 1 more month of maintenance left to it.
<bulletxt|2> yea :S
<wxl> there's the "connections cd" which is supposedly os independent, but they only list red hat for supported linux systems
<bulletxt|2> I could try that
<sbeattie> moving to 14.04 and the linux-lts-xenial kernel would get you to a kernel/OS combination that will be maintained for 2 more years.
<sbeattie> that will support your hardware.
<wxl> oh sorry, that's for FCoE
<wxl> given that it's a "CD" that suggests an ISO
<wxl> which would make sense for something "OS independent"
<bulletxt|2> wxl: so its not ok for me?
<bulletxt|2> oh well
<bulletxt|2> Ill just try
<bulletxt|2> thanks for the moment to everyone!
<bulletxt|2> have a nice day
<smoser> bdmurray, my cloud-init bug referenced a security bug
<smoser> err.. cloud-init upload
<smoser> not a private one, a security one. it isn't particularly necessary to be security, but i would have expected that is allowed.
<slangasek> smoser, bdmurray: I spoke with jgrimm about this; we do expect that by the time a bugfix is pushed to a public queue, the bug is also public, and the process doesn't really allow for verification of bugs that the scripts can't see
<smoser> slangasek, tahts fine. i can just make it public
<slangasek> smoser: I understand this bug may or may not be made public, but we expect there to be /a/ public bug for tracking this issue
<smoser> thats fine. i didn't realize that.
<smoser> bug is set public now
<smoser> .
<slangasek> ok
<smoser> rharper, found an issue so i'm not going to re-upload at the moment :-(
<slangasek> well, I was going to rescue it from the rejected queue anyway
<slangasek> but if there's a known issue, I won't do that ;)
<smoser> slangasek, if you're looking for work, and want to start your reviewing of it, that is perfectly fine
<smoser> i dont expect anything other than this one issue to change.
<slangasek> smoser: is it fine to accept the current version, or should I wait for the upload?
<slangasek> (I started reviewing much earlier)
<smoser> don't accept it.
<slangasek> ok
<slangasek> smoser: this version also includes the ds-identify sleep, which AIUI is to be dropped?
<smoser> it doesnt hurt much.
<smoser> ie, having that support doesnt cause any real issues. it just wont be used
<smoser> slangasek, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/318975
<smoser> that is the one change that i think we will need.
<slangasek> smoser: since it's all part of ds-identify which is new in this upload, I'll trust that is the case
<smoser> and on that note, /me goes afk.
<jgrimm> thanks smoser, hope you are feeling better
<tsimonq2> infinity, slangasek: So patch pilot is no longer a thing, or did the calendar move?
<slangasek> tsimonq2: I'm not aware of any calendar moving; which one were you looking at?
<tsimonq2> slangasek: https://calendar.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok%40group.calendar.google.com&ctz=America/Chicago
<slangasek> tsimonq2: we probably do have less than perfect coverage on it, however, since the person who managed it is no longer at Canonical
<tsimonq2> slangasek: I miss Daniel :(
<slangasek> so it's possible no roster was set beyond Feb
<tsimonq2> (yes I know who you're talking about :P)
<tsimonq2> slangasek: Ok, well I found it very useful to have a person in here who I can ping and ask questions to.
<tsimonq2> slangasek: I understand the attendance wasn't good, but the couple of people who did end up doing it were really helpful. ;)
<slangasek> tsimonq2: people are not immune to pinging just because their name isn't in the channel topic ;)
<slangasek> (but if you ping me now, I'm going to be unhelpful, as I have a one-year-old to go put to bed in the next few minutes)
<tsimonq2> slangasek: Sure they aren't, but it's saying, "I am setting aside some time to look at patches and go through the sponsorship queue" - I guess that's more inviting than pinging someone who might be working on something else.
<tsimonq2> slangasek: <3
<tsimonq2> slangasek: I guess I wanted to ping you and Adam because I was hoping someone could send an email or take the time to fill in for Daniel on managing the Patch Pilot roster (not saying you or Adam should do it, bringing up the usefulness of it).
 * tsimonq2 's thoughts are a bit jumbled at the moment, I need some sleep
<tsimonq2> But otherwise I just wanted to send a ping :)
<tsimonq2> slangasek: Have a good night :)\
<bulletxt|2> wxl:         sbeattie:       at the end, what I am attempting now is to compile vanilla 4.4 kernel on ubuntu 12.04 :)
<bulletxt|2> following this simple guide http://veithen.github.io/2013/12/19/ubuntu-vanilla-kernel.html
<javier4> I'm trying to cross-compile a modified version of the wpa package from amd64 to armhf through sbuild. Every time I make a change to the orig tar or the debian overlay I have to reset the sieze and checksums inside the .dsc file. I need something like this --debbuildopt=--source-option=--nocheck that obviously doesn't work. Anyone?
<cjwatson> javier4: in nearly 20 years of Debian-based development I've never had to do this; I am confident you are doing something fundamentally wrong
<cjwatson> javier4: you should normally just rebuild the source package using the usual tools, e.g. debuild -S
<cjwatson> javier4: do not try to work around .dsc checksum verification; you are on the wrong path
<javier4> cjwatson: I have a .dsc, an .orig archive and a debian overlay archive. If I made a change inside one of the two, how can I build without changing the checksums? I normally use
<javier4> sbuild -A -d vivid-amd64-armhf --host armhf wpa_2.3-1+deb8u4.dsc
<cjwatson> javier4: you should not be editing any of those by hand; you edit the unpacked tree and then use debuild -S to construct a new source package
<cjwatson> javier4: all of the files you listed are output files, and editing them directly is a mistake
<javier4> should I pass to sbuild the unpacked source tree instead of the .dsc as argument?
<cjwatson> you can do that if you like, but you don't have to.  rebuilding the .dsc etc. using debuild -S will work fine (that's what I normally do)
<cjwatson> but whatever you do, do *not* hack about with the .debian.tar.* (or .diff.gz) directly, that's a mistake
<javier4> cjwatson: debuild will work even for croos-compile?
<cjwatson> the .orig.tar.* should come unmodified from upstream and any time it changes then its version number (and hence file name) should also change; the .debian.tar.* and the .dsc are *outputs* of the process of building the source package and are not to be edited manually
<cjwatson> javier4: debuild -S means "build a source package", and it is irrelevant whether you're later going to be cross-compiling that source package
<cjwatson> debuild without -S would be a binary package build, and is not what I am suggesting
<javier4> cjwatson: If I understood: 1) create the debian source tree (orig+overlay unpacked) 2)apply my changes to the tree 3) recreate a new overlay and a new .dsc with debuild -S 4) use these two new files together with the original .orig file to build my package
<javier4> right?
<cjwatson> javier4: roughly, yes
<cjwatson> javier4: use dpkg-source -x foo.dsc to unpack the source tree
<javier4> cjwatson: yes I already did it that way. Thanks a lot. :-)
<javier4> Another question: I don't wanna lose the edits I already made inside the archives. Could I dpkg-source -x my custom-archives, then substitute the my-custom-.orig with the original one, to make debuild -S put all my editings inside the new overlay that it will create?
<cjwatson> you are getting yourself into a dreadful tangle
<cjwatson> why were you editing the orig in the first place?
<cjwatson> so yes, you probably can do something along those lines, but it sounds like you should take backup copies of everything before going any further
<javier4> It's complicated: I have a mediatek-customized wpa source in an android tree. I'm trying to port UbuntuTouch, but it seems that the vanilla wpa doesn't work. Then I'm trying to build the customized version and install it inside the rootfs of Ubuntu Touch.
<cjwatson> depending on the source format, you may find that debuild -S makes you transform your changes into patches
<cjwatson> but cross that bridge if you come to it
<javier4> @cjwatson unfortunately my try failed. It seems that debuild -S tries to apply the patches on the orig.tar.gz (that I substituted with the original one) instead of using the already extracted&patched tree.
<udevbot> Error: "cjwatson" is not a valid command.
<javier4> cjwatson unfortunately my try failed. It seems that debuild -S tries to apply the patches on the orig.tar.gz (that I substituted with the original one) instead of using the already extracted&patched tree.
<cjwatson> javier4: Yes, that's how it works.  It's trying to build a source package based on the given orig and the given source tree.
<cjwatson> javier4: I'm afraid I can't help you further right now, though.  I suggest doing some reading - there are lots of manual pages and such describing how the source format works.
<tsimonq2> javier4: Did you get it working?
<javier4> tsimonq2: Hi Simon. Still learning some man-pages. Perhaps the --no-pre-clean flag dor dpkg-buildpackage could help?
<tsimonq2> I'm unsure. What are you attempting at this point?
<javier4> Build a deb-source directly from a debian tree instead than from an .orig archive.
<tsimonq2> javier4: Like cjwatson said, you should probably use a clean orig tarball and just use debian/patches for any needed modifications.
<tsimonq2> javier4: My favorite guide on this: https://raphaelhertzog.com/2012/08/08/how-to-use-quilt-to-manage-patches-in-debian-packages/
<tsimonq2> javier4: I'd save whatever changes you had and just use uscan to get a new tarball
<tsimonq2> javier4: Then like I said, use debian/patches and try it
<tsimonq2> javier4: You can also just cd into the source dir and build it directly from there with sbuild -d CHROOTNAME
<javier4> too much work. I'm doing this just as a try that I'm not sure will fix my ubuntu touch problem. I'm already losing too much time, and I'm losing sight of my original objective: ports ub-touch.
<tsimonq2> Ok
<tsimonq2> javier4: Then it won't build properly
<tsimonq2> But I guess that's your choice...
<javier4> tsimonq2: I just gave a wuick look at your page: I should give a quilt add for every modified file? No possibilities of making just a diff from origin to mediatek-wpa and make a single commit?
<tsimonq2> javier4: Well you can just quilt add everything then apply the diff and you're good
<tsimonq2> javier4: So yeah you can do it all in one patch if you want
#ubuntu-devel 2018-02-26
<jbicha> fossfreedom_: shouldn't visualspace be a separate package?
<sunweaver> jbicha: I need some help...
<sunweaver> jbicha: do you see instantly why https://launchpad.net/ubuntu/+source/nx-libs is not yet in the release pocket?
<sunweaver> or is it a matter of time (it has been in proposed for 16h only)...
<Unit193> sunweaver: Last I looked earlier today, depends on glibc which is having a transition.
<Unit193> sunweaver: https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#nx-libs
<sunweaver> Unit193: so this means, it will be stuck in proposed until the transition is settle?
<Unit193> sunweaver: I wouldn't think that'd take *too* long.
<pitti> infinity: I'm afraid I don't have it any more; but robru wrote a better version in bileto: https://git.launchpad.net/bileto/tree/britney/fetch-indexes
<tsimonq2> pitti: Could you update the wiki page?
<pitti> tsimonq2: well, it's not a drop-in replacement, the script needs to be adjusted a bit to not run in bileto
<alkisg> Hi, https://packages.ubuntu.com/bionic/all/openshot-qt/filelist ships a weird file called "/v8QpiHa9tC/xb59dA3xKQ"
<alkisg> I'd normally just file a bug report about it, but it's strange that debian testing has the exact same version and that file isn't there, so I'm wondering if it's a problem with the builders?
<tsimonq2> pitti: Sure; I were to take on the task of doing that, where could I put it?
<pitti> tsimonq2: maybe into the britney2 git tree itself? my original version was just a slow PoC, so I didn't want to add that
<tsimonq2> pitti: Oh, right. I wonder if I could integrate that right into Britney...
<tsimonq2> pitti: Thanks.
<tsimonq2> alkisg: That's weird. Maybe cjwatson has an idea?
<alkisg> Also, I'm not seeing anything weird in debian/rules, I don't know what generates that file
<tsimonq2> Right, there's nothing in the build logs.
<tsimonq2> https://launchpadlibrarian.net/355931364/buildlog_ubuntu-bionic-amd64.openshot-qt_2.4.1-2_BUILDING.txt.gz
<tsimonq2> alkisg: Looks like LocutusOfBorgg fixed it with a no-change rebuild.
<alkisg> tsimonq2: cool, we'll never find out what the problem was but it's fine now :D
<tsimonq2> :D
<schout-it> don't know if this is the place to ask, but is there an official way to make a feature request for landscape (a warning when you plan an action in the past)
<LocutusOfBorg> tsimonq2, alkisg false
<LocutusOfBorg> drwx------ root/root         0 2018-02-26 07:34 ./VmLhlRqaww/
<LocutusOfBorg> -rw------- root/root         0 2018-02-26 07:34 ./VmLhlRqaww/VzXuI70yCQ
<LocutusOfBorg> just looked at the wrong directory
<alkisg> Ah
<alkisg> LocutusOfBorg: do you think the difference with debian is the build dir, e.g. /tmp vs / ?
<LocutusOfBorg> who knows? :/
<LocutusOfBorg> in pbuilder doesn't happen
<tsimonq2> schout-it: Maybe contact Canonical Sales; afair Landscape is proprietary.
<tsimonq2> LocutusOfBorg: ack :(
<LocutusOfBorg> I want to find a tool to blame
<blahdeblah> schout-it: https://bugs.launchpad.net/landscape
<cjwatson> tsimonq2: Not a clue.  Very peculiar.
<cjwatson> LocutusOfBorg: Have you tried a local sbuild?
<infinity> drwx------ root/root         0 2018-02-05 13:41 ./XYPnyMzRcv/
<infinity> -rw------- root/root         0 2018-02-05 13:41 ./XYPnyMzRcv/WAbPjD6CDt
<infinity> (from a local sbuild build)
<seb128> cjwatson, hey, the translations import I was waiting on have been done during the w.e, so it's all good now, thanks again for being responsive to my questions and checking the status!
<infinity> LocutusOfBorg: Confirmed that a local sbuild build in bionic reproduces it, and same sbuild but building in sid does not.  Most obvious place to go hunting would be pkgbinarymangler, which is Ubuntu-specific (and maybe not in your pbuilder chroots?)
<cjwatson> seb128: ah good, I'd intended to check on that this morning so thanks
<seb128> np!
<santa_> stgraber: hi, you might want to have a look at this patch:https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1669578/comments/54, if you think it's correct I could try to send it upstream. btw thank you very much for your work on LXD and your nice blogs posts about it, it's an execellent tech for the stuff I'm working on
<ubottu> Launchpad bug 1669578 in multitail (Ubuntu) "Get ttyname() to work properly in containers" [Undecided,New]
<LocutusOfBorg> infinity, I confirm the same, I didn't get your message, but yeah, it is some ppkgbinaryfoo
<LocutusOfBorg> I even did a find debian after dh_install and such files are not there http://debomatic-amd64.debian.net/distribution#bionic/openshot-qt/2.4.1-2build1/buildlog
<LocutusOfBorg> infinity, I can repro in pbuilder now
<coreycb> hello, can an archive admin review percona-xtradb-cluster-5.7 in the bionic NEW queue?
<Woodpecker> Hey Qt Developer here; looking to update my skills, and need a project to contribute to. What has Ubuntu got brewing?
<tsimonq2> Woodpecker: Depends on where you're looking :)
<Woodpecker> well one thing I liked about ubuntu (Although Im sad they had to drop unity, as that was all qt), was the developers were willing to serve as references on my resume.
<tsimonq2> coreycb: You might get more (relevant) eyes in #ubuntu-release ;)
<tsimonq2> Woodpecker: UBPorts is still alive and well, fwiw
<coreycb> tsimonq2: good point, thanks
<Woodpecker> Im thinking it might be useful to learn a bit of C as well.
<Woodpecker> tsimonq2: yeah I have ubuntu phone still installed on my phone. Although I was more interested in yunit. Seems a bit dead, and crossing that river that is Mir to Wayland... it sounds steep.
<tsimonq2> Woodpecker: afaict Mir is working fine as a Wayland compositor...
<Woodpecker> tsimonq2: excuse my language, but I am still pissed at how the bloody linux community treated ubuntu and canonical for deciding to use Mir.
<Woodpecker> It worked remarkably well.
<tsimonq2> Woodpecker: And yet development continues on ;)
<Woodpecker> tsimonq2: for mir? you are kidding me?
<tsimonq2> Nope, not kidding.
<Woodpecker> o_O from canonical?
<tsimonq2> It's going to be (if it isn't already) a Wayland compositor.
<tsimonq2> Yes.
<Woodpecker> How does the wayland project feel about this?
<tsimonq2> Â¯\_(ã)_/Â¯
<Woodpecker> tsimonq2: is it the same as what weston is to wayland?
<Woodpecker> or is a reference compositor different?
<tsimonq2> Not sure.
<tsimonq2> I don't do much with Wayland myself.
<Woodpecker> Hm; maybe that changes things for Yunit...
<tsimonq2> Yunit? Probably not. Unity 8? Surely.
<Woodpecker> Unity 8 is what Yunit forked so ???
<Woodpecker> mmmmm maybe I have to go bug the ubports people https://www.phoronix.com/scan.php?page=news_item&px=Unity-8-On-Ubuntu-18.04 -- it sounds like they are handling unity 8 development
<GunnarHj> Hi mvo, any thoughts on https://github.com/snapcore/snapd/pull/4723#issuecomment-368475140 ?
<mvo> GunnarHj: aha, its green! nice job
<mvo> GunnarHj: let me quickly check the question
<mvo> GunnarHj: let me followup on GH
<GunnarHj> mvo: Ok.
<mvo> GunnarHj: replied, thanks again for pushing this i18n fix forward
<GunnarHj> mvo: Replied to your reply. I don't know if there is some other safe way to check if it really works but to get it in and build in Ubuntu. The "|| true" shouldn't really need to be there.
<mvo> GunnarHj: cool
<mvo> GunnarHj: thank you
<mvo> GunnarHj: if you don't mind I can play with the PR, we build on ubuntu (14.04, 16.04) as part of the CI so if it builds without the build-dep I think we are fine. I can check the build, sometimes we had failures for unrelated reasons which might be confusing (e.g. issues with downloads from external sources)
<smoser> I'm mostly just curious.  is there information available on when a package enters the archive?
<GunnarHj> mvo: It ought to build without the build-dep, but then it would generate warnings about not understanding the file type and fail to extract the strings from the .policy files. Maybe I should add a local polkit.its file before you start "playing".
<cjwatson> smoser: publishing history in LP?
<smoser> as in teh first time that an appropriately configured 'apt-get install foo' would have that package/version available to it.
<cjwatson> oh well that relies on mirroring timing and such and is in general more or less unknowable
<smoser> mirrors can't be knowable, i'll accept that.
<cjwatson> best you can do is what publishing history says plus a bit
<smoser> but archive.ubuntu.com
<cjwatson> archive.ubuntu.com is a mirror
<smoser> fair.
<smoser> so what is there in publishing history ? what time does that represent?
<cjwatson> publishing history tells you when LP processed the publication as part of a publisher run; that's before it runs apt-ftparchive and triggers mirrors
<cjwatson> timing information for the latter is only available in private log files
<cjwatson> the next index file update after the published time given in publishing history is guaranteed to include the publication
<smoser> ballpark time difference between those two things?
<smoser> small minutes? hours? just curious.
<mvo> GunnarHj: interessting, so polkit has some sort of plugin for gettext? do you know what file it is?
<persia> smoser: Old information (~2010) was between 2 minutes and 12 hours, depending on the mirror.  Might be longer for private mirrors.
<cjwatson> smoser: depends heavily on the number of publications being processed; typically ranges from small minutes to maybe most of an hour
<cjwatson> for the master archive
<cjwatson> as persia says mirrors other than archive.u.c could be much longer
<smoser> thanks.  yeah, persia your-private-mirror could lag by days, so i'm not too concerned about that.  for this excercise i was most interested in when a cloud image would find it.
<Laney> I usually ask rmadison for things that are going to hit ftpmaster
<GunnarHj> mvo: The file is /usr/share/gettext/its/polkit.its. Or did I misunderstand your question?
<mvo> GunnarHj: thanks, that was exactly what I was looking for! so my suggestion is to add this build-dep to the other files in packaging/ for rpm etc but only if you know how to do this, otherwise we just ask the packagers for suse/fedora etc for help
<persia> smoser: Long ago, there used to be a constraint that if master wasn't updated in about 50 minutes, things would break.  That may have been fixed, but I would expect it to be usually less (just because fixing a race condition is rarely an excuse to make things slower).
<GunnarHj> mvo: We'd need help from the other packagers, I suppose. But if we drop the build-dep, and instead put polkit.its in the source (the file is tiny), then we could do it without asking for help.
<GunnarHj> mvo: I'd be happy to modify the PR in accordance with that.
<smoser> Laney: where does rmadison get its data ? does it come from data downloaded from an archive?
<Laney> smoser: I think basically it works because the machine it runs on gets a copy of dists/ from ftpmaster
<cjwatson> correct
<cjwatson> basically just rsync dists and then madison-lite
<cjwatson> the machine it runs on has a cron job that tries to update itself every minute and then spawn off a load of other jobs if anything changed (though it will only update if those jobs aren't running, to avoid chaos)
<mvo> GunnarHj: sounds good, lets put it in there if its tiny
<cjwatson> ideally rmadison would run off a separate webservice so that it isn't tied to that kind of detail
<smoser> thanks everyone.
<smoser> xnox: bug 1751797 . is that known to you ?
<ubottu> bug 1751797 in systemd (Ubuntu) "dns resolution only works for domains in 'search'." [Undecided,New] https://launchpad.net/bugs/1751797
<smoser> i dont think i'd be the only one seeing that.
<xnox> smoser, the title is too scary to open at the moment =)
 * smoser changes subject to 'free candy or beer'
<GunnarHj> mvo: Ok. It will take a while, because I want to test it locally first. ;)
<mvo> GunnarHj: sure, no worries!
<tsimonq2> rbasak: qt5 app> Are you sure you looked at the whole page? ;)  There's also syncs
 * tsimonq2 has to get K9 Mail set up
<rbasak> tsimonq2: I'm mostly interested in what you have had sponsored into Ubuntu that's relevant to your packageset request. I'd like to see a list of just those.
<rbasak> tsimonq2: don't mind the other stuff being there, but I don't know how to find the bit that I do want right now.
<rbasak> tsimonq2: and you probably know the list :)
<tsimonq2> rbasak: sure
<rbasak> tsimonq2: note that I'm not sure I'll be able to make all of the meeting today - hence the email.
<tsimonq2> rbasak: sure; any other questions?
<rbasak> tsimonq2: I haven't looked in detail yet, sorry.
<tsimonq2> rbasak: OK, no rush, but there's always a chance there won't be quorum :)
<tsimonq2> Speaking of quorum...  BenC bdmurray cyphermox micahg sorry for poking but it would be great to get quorum if possible ;)
<oSoMoN> nacc, hey, I updated the debdiff attached to bug #1749920
<ubottu> bug 1749920 in libepubgen (Ubuntu) "[MIR] libepubgen" [Undecided,New] https://launchpad.net/bugs/1749920
<nacc> oSoMoN: yep, reviewing it now
<oSoMoN> excellent, thanks!
<nacc> oSoMoN: thank you!
<bdmurray> tsimonq2: I believe there is an outstanding question about your application which should be answered before we worry about quorum.
<tsimonq2> Sure.
<tsimonq2> If only the wiki would load...
<tsimonq2> rbasak, bdmurray: Editing the wiki with a 3G connection on a phone is impossible; I can't even log in... the ubuntu1 uploads in those tables are the ones that should be referred to, and if I could edit the wiki I could.
<tsimonq2> Surely it isn't a blocker, right?
<tsimonq2> Actually, it seems acheronuk edited the wiki for me \o/
<tsimonq2> So it should be good
<acheronuk> I hate editing wiki tables, so I hope no uploads went missing!
<tsimonq2> Hah it should be fine
<rbasak> tsimonq2: I'm afraid it's a blocker for me because it's one of the primary ways I assess applications. I can't speak for the others, and of course if I won't be here to vote it won't matter.
<rbasak> ("it" being my opinion)
<tsimonq2> rbasak: Is it better now?
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, jbicha, micahg, rbasak, sil2100: DMB ping.
<rbasak> tsimonq2: it doesn't look any different?
<tsimonq2> rbasak: There is now a third table towards the bottom
<tsimonq2> It's hiding but it's there :)
<nicebu> just for logs: https://pastebin.com/nmdRUY6h   -   dax aka rww aka ro aka pweh aka rw aka dax_ doxed  Robert William Wall robert@rww.name robertlikesturtles@gmail.com freenode operator ubuntu
<nicebu> just for logs: https://pastebin.com/nmdRUY6h   -   dax aka rww aka ro aka pweh aka rw aka dax_ doxed  Robert William Wall robert@rww.name robertlikesturtles@gmail.com freenode operator ubuntu
<nicebu> dox reason: being an asshole to freenode users
<tsimonq2> ugh
<tsimonq2> anyways
<tsimonq2> bdmurray: I updated my wiki with the diffs asked for, but I feel like I need to generally be a bit more verbose; I'll follow up on the list ewhen it's better
#ubuntu-devel 2018-02-27
* opal changed the topic of #ubuntu-devel to:   .-.
* opal changed the topic of #ubuntu-devel to:  (. .)__,')
* opal changed the topic of #ubuntu-devel to:  / V      )
* opal changed the topic of #ubuntu-devel to:  \  (   \/        Lovelypenisbird
* opal changed the topic of #ubuntu-devel to:   `._`._ \        ===============
* opal changed the topic of #ubuntu-devel to: 8===<<==`'==D
* Unit193 changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of trusty-artful | #ubuntu-app-devel for app development on Ubuntu
<tsimonq2> tjaalton: When you get the chance, could you please do a review of this? https://salsa.debian.org/xorg-team/debian/xorg/merge_requests/2  I'd like it to land for 18.04, and imho it qualifies as a bugfix.
<tjaalton> tsimonq2: you need to rebase with current git, which added the changes from latest upload..
<tsimonq2> tjaalton: Sure.
<tsimonq2> tjaalton: Done.
<alkisg> flexiondotorg: the file /usr/share/mate/desktop-directories/mate-network.directory is not localized in 32bit builds. Everything else is properly localized, including that same file in 64bit builds. Would that be a MATE issue, or an issue with the builders langpack mangling?
<alkisg> I.e. the Applications > Internet menu is not localized to "ÎÎ¹Î±Î´Î¯ÎºÏÏÎ¿" specifically on 32bit builds...
<flexiondotorg> alkisg: I'd have to have a poke around and see where that translation comes from.
 * alkisg checks the mate-menus source code...
<alkisg> Everything seems fine, trying to build locally to see if the result is fine too (which would mean the problem is in the builders...)
<alkisg> Everyone, flexiondotorg: I rebuilt mate-menus locally, and /usr/share/mate/desktop-directories/mate-network.directory is indeed properly localized. So I believe the problem is in the builders.
<alkisg> The two related build logs are:
<alkisg> 32bit: https://launchpadlibrarian.net/356151086/buildlog_ubuntu-bionic-i386.mate-menus_1.20.0-0ubuntu1_BUILDING.txt.gz
<alkisg> 64bit: https://launchpadlibrarian.net/356151076/buildlog_ubuntu-bionic-amd64.mate-menus_1.20.0-0ubuntu1_BUILDING.txt.gz
<alkisg> Both say "Merging translations into mate-network.directory."... it might be a race condition somewhere in the builders tools... could someone issue a rebuild, to test?
<flexiondotorg> Thanks for the feedback alkisg.
<alkisg> np, thanks for all the hard work
<rbasak> tsimonq2: thank you for the update. That's very helpful.
<LocutusOfBorg> infinity, the problem for openshot is pkgbinarymangler, specifically dh_builddeb. I can say, doing a mv dh_builddeb.pkgbinarymangler to dh_builddeb makes the problem disappear /cc tsimonq2 alkisg
<LocutusOfBorg> I'm doing some perl debug, but I don't speak perl :p and it is a 20 lines of stuff, should be somewhat easy to trace it down
<alkisg> LocutusOfBorg: thanks; I found another unrelated issue with the builders, i.e. localization of some failing failing randomly, see above, I don't know if you're the correct person for this or if I should file a bug, and where, in soyuz...?
<alkisg> *of some files
<cjwatson> alkisg: if parallelisation is causing random failures, that's a bug in the package
<alkisg> cjwatson: in the mate-menus package itself, or in some of the packages that take care of localization like intltool etc?
<cjwatson> if you file a bug against anything Launchpadish then I shall reassign it :)
<cjwatson> alkisg: probably in mate-menus itself, but I haven't looked deeply
<cjwatson> it could serialise the relevant bits of its build to avoid invoking the tools in question in parallel
<alkisg> cjwatson: thank you, at least that means that whatever issue won't be widespread
<alkisg> flexiondotorg: please see above ^, I'll file a bug report in mate-menus as well
<cjwatson> alkisg: you can probably reproduce it locally with sbuild -j4 or similar
<alkisg> Gotcha, I'll try it
<cjwatson> (maybe with a few attempts, since it's no doubt racy)
<alkisg> flexiondotorg: https://bugs.launchpad.net/ubuntu/+source/mate-menu/+bug/1752063
<ubottu> Launchpad bug 1752063 in mate-menu (Ubuntu) "Random localization issues probably due to build parallelization" [Undecided,New]
<alkisg> Meh, that should be mate-menus, not mate-menu, I thought I changed that :/
<LocutusOfBorg> infinity, cjwatson, can you please give me a quick perl hint? seb128 ?
<LocutusOfBorg> https://paste.ubuntu.com/p/55qsWdj2tf/
<alkisg> Fixed
<LocutusOfBorg> the problem of the spurious /foo installed inside the rootfs comes from this line
<LocutusOfBorg> my $dir = tempdir( CLEANUP => 1 );
<LocutusOfBorg> this creates a /temp directory that goes into the final package...
<LocutusOfBorg> maybe the dh_builddeb is called *before* deleting it?
<cjwatson> LocutusOfBorg: what's the full source package name - openshot-qt?
<alkisg> cjwatson: yes, e.g. https://packages.ubuntu.com/bionic/all/openshot-qt/filelist => /v8QpiHa9tC/xb59dA3xKQ
<cjwatson> LocutusOfBorg: (I have some theories but I want to check a bit before confusing other people with them)
<LocutusOfBorg> cjwatson, yes, for the first answer
<LocutusOfBorg> race condition seems not, because it is fully reproducible, every-single-time
<LocutusOfBorg> i added an rmdir but I don't know if this is the best thing to do :p
<cjwatson> almost certainly not
<LocutusOfBorg> yes, it isn't working
<cjwatson> give me a minute to download this thing :)
<LocutusOfBorg> sure, I don't want to steal too much of your time ;)
<LocutusOfBorg> BTW NO_PKG_MANGLE=1 makes no difference, just to avoid some time
<cjwatson> so the problem is that openshot-qt/debian/rules exports TMPDIR, which means that File::Temp creates the temporary directory/file inside debian/openshot-qt/, while ordinarily it'd be in /tmp or similar
<LocutusOfBorg> LOL
<cjwatson> give me a moment to work out a reasonable workaround
<LocutusOfBorg> damn, I even read the rules file, but I couldn't find it :/
<cjwatson> is pkgbinarymangler in git these days?
 * cjwatson fails to find it
<cjwatson> LocutusOfBorg: OK, anyway, I think https://paste.ubuntu.com/p/YXq2mKkwfF/ is probably the right fix
<cjwatson> LocutusOfBorg: maybe with a comment to explain that this is in order to ignore any setting of TMPDIR in the environment
<LocutusOfBorg> can I upload then? I'll give you credits in the changelog, of course :)
<cjwatson> LocutusOfBorg: be my guest, assuming it works - I haven't tested this at all
 * LocutusOfBorg is already testing
<cjwatson> beyond checking that File::Spec->tmpdir's value isn't conditional on $TMPDIR
<cjwatson> interesting subtle bug though
<alkisg> I think I've seen 5-6 files in / in the past as well, but I haven't bothered reporting them at that time... so it might have affected more packages in the past
<cjwatson> could be from the same thing, could be something else; I've seen ad-hoc bugs with that symptom
<cjwatson> wouldn't be a bad idea to scan Contents though
<Laney> https://perldoc.perl.org/File/Spec.html says it looks at TMPDIR
<cjwatson> $ TMPDIR=/ perl -MFile::Spec -le 'print File::Spec->tmpdir'
<cjwatson> /tmp
<cjwatson> odd
<LocutusOfBorg> it is not fixing...
<Laney> needs to be writable I think
<cjwatson> oh yes
<cjwatson> bah
<cjwatson> probably best to just hardcode DIR => '/tmp' then
<LocutusOfBorg> my $dir = tempdir( DIR => '/tmp', CLEANUP => 1 );
<cjwatson> yep
<cjwatson> with a comment of course
 * LocutusOfBorg checks
<LocutusOfBorg> # avoid using default TMPDIR because it might be used already by debian/rules
<LocutusOfBorg> # package file, and point to a wrong location
<LocutusOfBorg> this is what I wrote
<LocutusOfBorg> do we run lintian over the archive? such files are spot by this tag https://lintian.debian.org/tags/file-in-unusual-dir.html
<LocutusOfBorg> https://codesearch.debian.net/search?q=TMPDIR+path%3Adebian%2Frules%24
<LocutusOfBorg> lots
<cjwatson> I not systematically AFAIK
<cjwatson> s/^I //
<LocutusOfBorg> tsimonq2, alkisg we should be finally good in two hours :)
<tjaalton> LocutusOfBorg: do you maintain virtualbox?
<s1aden> slangasek: https://github.com/psifidotos/Latte-Dock/issues/884  what's your preferred solution?
<s1aden> slangasek: the font is being runtime loaded, and doesn't appear to be being derived-from
<sladen> slangasek: ie.  is it the linking.  Or is it OPL is non-free and needs to go in multiverse?
<sladen> slangasek: (in which case can go in a separate package, and the app can fallback to $any cursive looking font, or serif
<tsimonq2> sladen: I'm the uploader for that; he rejected it last night on those grounds.
<sladen> tsimonq2: well, lets try and find out the hard facts from slangasek, then everyone is in a better situation to have a discussion and see what the solutions might be
<tsimonq2> sladen: Works for me.
<tsimonq2> rbasak: Nice, I'm glad the update was useful
<tsimonq2> LocutusOfBorg: \o/
<xnox> tsimonq2, what does the reject email say?
<tsimonq2> xnox: "Source embeds and uses at runtime a GPL-incompatible (OPL-licensed) font; needs an upstream license exception statement or a patch to not special-case the font"
<xnox> ah, i see the issue on github now.
<xnox> tsimonq2, tah.
<tsimonq2> There's also https://marc.info/?l=kde-devel&m=151973598814829&w=2
<xnox> tsimonq2, yeah, he is wrong.
<tsimonq2> xnox: Steve or Jon?
<xnox> tsimonq2, riddell
<tsimonq2> xnox: OK; how so?
<xnox> tsimonq2, GPL does not discriminate against binary blobs that are loaded by the program, and thus linked into it at runtime. same as dlopening() libssl, needs a GPL openssl linking exception.
<tsimonq2> xnox: ah ok
<xnox> tsimonq2, the request here is not to drop the usage of the font, but to provide linking exception, to state that it is not the intention of Latte-Dock to upconvert the OPL font into a GPL thing and force the font to be released under GPL. Thus, we, Latte Dock are gpl, but gpl should not apply to the font we load.
<tsimonq2> xnox: OK, I'm not an expert here but that sounds sane :)
<sladen> xnox: can you help me understand this 'linking to a font' bit
<sladen> xnox: (ideally with a comparison to what eg. Inkscape does)
<alkisg> (02:08:20 Î¼Î¼) LocutusOfBorg: tsimonq2, alkisg we should be finally good in two hours :) ==> yey! much appreciated! :)
<LocutusOfBorg> tjaalton, yep
<tjaalton> LocutusOfBorg: the dkms doesn't build with 4.15
<tjaalton> or at least seems not
<xnox> sladen, inkscape / evince load all/any system fonts, for display of a document / editor; and they do so optionally, if a particular document needs it or a user chooses a particular content.
<xnox> sladen, that dock, appears to require and load a specific font, and dynamically create and render, the UI components of the application using a specific free-but-license-incompatible font.
<sladen> xnox: how can the code be changed so that situation (1) is absolutely clear?
<xnox> sladen, e.g. all .svg / .png shipped in an app, must be free and license compatible, with the app that uses said icons. That's why e.g. we had to remove skype logo icons from many packages from the archive in th epast. so it is not without the presedence.
<xnox> sladen, use a free font; use a default system/toolkit font; without specifying one.
<xnox> sladen, add a license exception.
<xnox> sladen, make it such that, a particular font, is neither preferred nor required.
<sladen> xnox: well, lets try and find a clear example/solution that doesn't require adding a licence-exception, otherwise we're going to have an enormous amount of archive work to remove/fix other applications, eh?
<sladen> xnox: so, focusing on the exact problem
<xnox> sladen, you are extrapolating. most apps do not do what this app does.
<sladen> xnox: right, so focusing on this exact problem
<xnox> sladen, it's like github.com loading a custom proprietary webfont, to load all the icons as text. Such that all the UI of github.com is completely unusable, if one blocks loading their proprietary webfont =/
<sladen> xnox: how do we make this application do what "most apps do" ?
<xnox> sladen, sorry, i'm not going to code that app, as i'm busy with other things. I gave you specific guidance "use a free font; use a default system/toolkit font; without specifying one." is that not sufficient for you?
<sladen> xnox: not convinced that is the case here... sounds like "extrapolating"
<xnox> sladen, most apps do not reference, nor ship, nor embedd license incompatible fonts.
<sladen> xnox: this is not sufficient information.  hence asking for me
<xnox> as part of the combined work.
<xnox> nor via dependencies.
<sladen> xnox: and trying to understand what *exactly* is trigging the issue (ie. what is the issue, precisely)
<sladen> xnox: my understanding is that the rejection came from slangasek.  So it would be interesting to learn what information you have, and whether it is the same understanding as slangasek (who made the rejection), or another opinion (which may/may not be the same)
<xnox> sladen, license incompatibility of the combined work which is consists of two things licensed under a free license.
<sladen> xnox: yes, and we work very very hard together on licencing and what is compatible (which is also different in Debian and Ubuntu)
<xnox> sladen, i have no information, but i simply, independently came to the same conclusion.
<sladen> xnox: right
<sladen> tsimonq2: sounds like we need to wait for slangasek
<xnox> sladen, look, the package claims to be GPL, yet it ships ./shell/package/contents/fonts/tangerine.ttf which is not gpl, and uses that to render itself in
<xnox> ./app/packageplugins/shell/dockpackage.cpp:    package->addFileDefinition("tangerineFont", QStringLiteral("fonts/tangerine.ttf"), i18n("Tangerine Font"));
<xnox> ./app/dockcorona.cpp:    QFontDatabase::addApplicationFont(kPackage().filePath("tangerineFont"));
<sladen> xnox: yes.
<xnox> sladen, but Latte-Dock are not copyright holders, and cannot relicense tangerine.ttf from OFL -> GPL.
<sladen> xnox: can't see anything here that is proposing to relicense a font from *OPL* to GPL
<tsimonq2> sladen: No problem
<xnox> sladen, instead they should sate, in the License file "everything is covered by gpl, but we allow linking OFL fonts and our GPL code, does not affect nor change license of the loaded tangerine.ttf"
<xnox> s/sate/state/
<sladen> xnox: (Open Font License != Open Public Licence)
<xnox> sladen, this is the same bullshit, as including embeded copy of openssl, dropp-in SSL license text, and shipping the whole tarball as GPL.
<xnox> sladen, the bit that matter is that GPL is more restrictive than OFL, and that one is not allowed to relicense OFL as GPL.
<xnox> sladen, and pretending life is wonderful because openssl license is included in the tarball.
<sladen> xnox: still can't see any proposal to relicence anything from either Open Font License (OFL), nor Open Public License (OPL) to GPL
<xnox> sladen, please read the text of GPL.
<sladen> xnox: I suspect many of us have, many times.  Is there a particular font which is specifically relevant here, and which does not apply to all other applications dynamically loading non-code assets
<sladen> s/particular font/particular part/
<xnox> sladen, in ./Latte-Dock/COPYING stating that these terms apply to everything in this tarball, and things that are linked.... of which the included .ttf font is one of the things.
<xnox> sladen, .ttf font in this case, is no different from a glade ui xml file.
<sladen> xnox: so debian/copyright needs adjusting/clarifying?
<xnox> sladen, no, because the upstream states that "You may modify your copy or copies of the Program or any portion
<xnox> of it, thus forming a work based on the Program, and copy and
<xnox> distribute such modifications or work under the terms of Section 1
<xnox> above"
<xnox> sladen, the upstream, need to change their copying text to give a linking exception.
<sladen> xnox: with hard information to go back to upstream, I'm sure this can be clarified
<xnox> sladen, saying that the GPL terms imposed by Latte-Dock on the programm, do not include imposing these terms on the .ttf font.
<xnox> sladen, a debian maintainer, is not docker-latte copyright holder, and thus cannot change the terms of the whole upstream release.
<sladen> xnox: yes.  we know that
<xnox> sladen, debian maintainer, can only create a +dfsg tarball, exclude the font, and patch the software to not load said font.
<sladen> xnox: and normally we collectively communicate and forth any clarifications or problems, once they are understood
<xnox> as it is clear that Latte-Dock is not copyright holder of the ttf font, and is wrongly trying to impersonate the original copyright holder of the font, and incompatibly relicense it.
<sladen> xnox: this this case, the precise issue of an application (any GPL application) causing a non-code asset to be loaded does not appear yet understood
<sladen> xnox: which makes it difficult to go back to upstream (or ask anyone else to go back to upstream) with a request for clarification
<xnox> there are softare, the very permissive licenses, that do allow relicing. ANd e.g. there are forks of such codes embedded in gpl software, with forks becoming gpl-only.
 * sladen can't see any proposals to do any relicensing
<sladen> xnox: the application runs fine with the .ttf deleted/not present => not dependency
<xnox> sladen, no. just because an app loads with broken icons, doesn't mean that the icons shipped in the package can be of an incompatible license.
<xnox> sladen, "can't see any proposals to do any relicensing" -> you do understand the terms of GPL, right? and how GPL poisoning works?
<sladen> xnox: hopefully.  But always interesting to learn more, particularly in respect of the exact, precise, situation under discussion so that it is realistic to make a proposal/recommendation to pass on to others to pass on to upstream
<xnox> sladen, please explain to me how GPL license poisoning works / copyleft?
<sladen> xnox: what precisely would you like to know/
<xnox> sladen, I created a software tarball and release it under gpl v2, which includes a patched Apache v2 subcomponent. Can I do it? and under what terms?
<xnox> Apache v2 is quite a permissive license.
<sladen> xnox: are the copyright holder of all the code, and/or hold a CLA from the copyright holder of all the code?
<xnox> sladen, i am copyright hold of my software tarball, the patch to the apache v2 subcomponenet, but not the original subcomponenet code which i got externally without cla.
<xnox> (software tarball aka everything else)
<cjwatson> As I understand it the point here is that the font is more intimately associated with the program than is usual for fonts: this specific font is used for a *functional* purpose rather than being an interchangeable choice of text rendering, and so the argument is that it must be distributable under the terms of the GPL.
<cjwatson> (I haven't looked into this example in any detail, but the two of you seem to be talking past each other.)
<xnox> ./app/packageplugins/shell/dockpackage.cpp:    package->addFileDefinition("tangerineFont", QStringLiteral("fonts/tangerine.ttf"), i18n("Tangerine Font"));
<xnox> ./app/dockcorona.cpp:    QFontDatabase::addApplicationFont(kPackage().filePath("tangerineFont"));
<cjwatson> (I'm also not sure I necessarily agree, but I think this is what xnox is arguing ...)
<xnox> $ find . -name tangerine.ttf
<xnox> ./shell/package/contents/fonts/tangerine.ttf
<xnox> cjwatson, (yes)
<xnox> or, instead of distributing under the terms of the GPL, an exception granted, which is easier to do.
<cjwatson> Right, relicensing is only one of several ways to cure an unsatisfied requirement to distribute a component of a work under the terms of the GPL.
<sladen> changing the licence (adding an exception) requires going back to the upstream original author with a clear request/proposal for clarification.  Equally with a better understanding of the precise concern, some alternative can likely be suggested/recommend/proposed
<sladen> in this case it would be just to nuke the font from the tarball, as it appears to serve no functional purpose of the licence is clearly being mis-represented
<sladen> s/of the licence/and the licence/
<xnox> sladen, the same terms apply to containment/package/contents/icons/splitter.png as they do for containment/package/contents/ui/ParabolicManager.qml containment/package/contents/images/panel-west.png and icons/org.kde.latte.plasmoid.svg and shell/package/contents/fonts/tangerine.ttf because that is what the header of ./app/packageplugins/shell/dockpackage.cpp requires and ellaborated in ./COPYING
<xnox> sladen, if you understand what license terms containment/package/contents/icons/splitter.png should be compatible with, you can extend what license terms the rest of files must be compatible with.
<LocutusOfBorg> tjaalton, I know... is 4.15 planned for bionic?
<LocutusOfBorg> anyhow, I'll fix in case
<xnox> LocutusOfBorg, as in the kernel? we are already at 4.15....
<LocutusOfBorg> xnox probably some minor update broke it
<LocutusOfBorg> virtualbox-guest, 5.2.6, 4.15.0-10-generic, x86_64: installed (WARNING! Diff between built and installed module!)
<LocutusOfBorg> E: not installed
<LocutusOfBorg> mmmm maybe something different?
<LocutusOfBorg> apw, might be the usual "hey kernel already has the same version, don't install it" issue, in that case ignoring the test would be fine
<tjaalton> LocutusOfBorg: that's why the autopkgtest failed :)
<LocutusOfBorg> so, apw please ignore the results!
<jbicha> cjwatson: wgrant: it looks like LP stopped importing Debian unstable uploads on Sunday, don't know if it's on Debian's end or LP
<cjwatson> jbicha: Well, we did move the importer to another machine because the original one ran out of space, but I thought it had been tested.  Let's see
<tjaalton> LocutusOfBorg: hmm sorry, so it actually did build
<cjwatson> ah, debmirror is sad, let's see what's going on there
<cjwatson> jbicha: Can't quite tell from the current logs, unfortunately.  I've committed a more helpful error message upstream and asked for that to be cowboyed so that I can see what the problem is
<tjaalton> sigh, installed my laptop with luks root and a separate /boot which for some reason is just 200MB.. how impossible is it to resize the luks root?
<tjaalton> found some docs
<rbasak> luks is quite resizeable
<rbasak> The header at the start is agnostic of the partition's size IIRC
<rbasak> So it's the same as resizing a partition without luks
<rbasak> Make the partition bigger, luksOpen it, and ask the filesystem to grow
<tjaalton> I need to shrink, but looks like it's not much different
<rbasak> Yeah it's basically the same in reverse
<rbasak> You just need to know the size of the LUKS overhead to know how much to finally shrink the partition by.
<rbasak> It might be easier (safer) to make the filesystem much smaller, make the partition a little smaller, and then ask the filesystem to resize to the size of the available space again.
<tjaalton> hmm, actually it's probably easier to shrink the windows partition :P
<alkisg> tjaalton: resizing the start of a windows partition is ricky; resizing the end isn't :) From a lot of personal experience.
<tjaalton> yeah, looks like it went well.. don't dare to boot until I have a usb stick handy :P
<slangasek> sladen: my preferred solution is for upstream to explicitly state "yes, we think it's ok to ship this as a binary, even though the GPL doesn't unambiguously allow that".  Yes, this is a "linking" question.  The GPL doesn't care about dynamic vs static linking, and it doesn't care if the bits you're pulling in are C code or something else; if you make your work rely on that object, and you do not
<slangasek> have the same distribution rights on that object that the GPL requires you to have for the work as a whole, the GPL does not give permission to distribute the binaries
<slangasek> sladen: the font would be fine to package separately, if latte-dock didn't then depend on it.  But I'm not sure why we should take this font into Ubuntu as a separate package if the only thing that wants it is latte-dock, and latte-dock isn't allowed by license to depend on it :)
<slangasek> sladen: enormous amount of archive work> what other GPL packages are hard-coding preferences for GPL-incompatible fonts?
<bdmurray> tseliot: what do I need to do to fix my system for bug 1752053?
<ubottu> bug 1752053 in nvidia-graphics-drivers-390 (Ubuntu) "nvidia-390 fails to boot graphical display" [Undecided,Confirmed] https://launchpad.net/bugs/1752053
<tsimonq2> slangasek: Upstream says that they are considering shipping it as a PNG then. Would a screenshot of a font which (going with what you're saying here) doesn't comply with the GPL be fine to then license under the GPL and ship in place of that?
<tsimonq2> ("it" being the logo)
<bdmurray> tseliot: I installed libglvnd0 and xserver-xorg-core from -proposed but I'm still getting an error
<slangasek> tsimonq2: assuming the font license doesn't "taint" the png, and the png itself can then be licensed under the GPL (which seems likely), then the answer is yes
<tsimonq2> slangasek: What do you mean by "assuming the font license doesn't "taint" the png"?
<slangasek> tsimonq2: I haven't reviewed the text of the SIL Open Font License to see if the license claims to attach to derivative works
<tsimonq2> slangasek: OK
<tseliot> bdmurray: can I see your /var/log/Xorg.0.log and your dmesg, please?
<bdmurray> tseliot: sure, it'll be a moment
<slangasek> infinity, kees, mdeslaur, stgraber: TB meeting?
<mdeslaur> slangasek: ack!
<tsimonq2> slangasek, sladen: https://github.com/psifidotos/Latte-Dock/issues/884#issuecomment-369007487
<tsimonq2> There we go
<nacc> ugh, this seems like a step backwards
<nacc> https://paste.ubuntu.com/p/jb76TmdG3V/
<nacc> I assume that's the new c-n-f
<nacc> which is now completely unhelpful to new users
<sarnold> nacc: agreed. that needs wordsmithing.
<nacc> sarnold: it isn't happening for all packages/command,s though
<nacc> sarnold: i wonder if it's snap-sensitive
<nacc> mvo: --^
<nacc> this is quite sad
<nacc> mvo: it just needs refactoring, it looks like and i don't know why you wouldn't give a `snap install` command line like we do for pat
<nacc> *apt
<mvo> nacc: feel free to make suggestions! https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1749777 is the relevant bug
<ubottu> Launchpad bug 1749777 in command-not-found (Ubuntu) "Syntax tweaks for snap-friendly output" [Critical,In progress]
<nacc> mvo: yes i will :)
<mvo> nacc: thank you :) I'm actively working on this right now, hopefully tomorrow the output from the bugreport will be there (except the version numbers those need some server side tweaks first)
<nacc> mvo: i'm putting a comment in :)
<sladen> slangasek: any application that directly refers to any specific font.  any application that refers to any SVG that refers to any specific font.  where(licence(app) != licence(font) != licence(svg))
<slangasek> infinity, stgraber: hmph, edit-acl create prompts for a description, where do I /query/ existing descriptions for comparison?
<stgraber> slangasek: I have them somewhere
<stgraber> slangasek: http://people.canonical.com/~ubuntu-archive/packagesets/bionic/
<sladen> slangasek: ...any included/generated developer documentation (eg. PDF) that references specific images, or PDFs.  that reference specific fonts.  etc
<slangasek> sladen: ok, so I'm perfectly willing to be shown that my reject is inconsistent with existing practice because there is a non-empty set of packages in that situation (and it must be more than just "unequal licenses", the issue is only with strong copyleft licenses, i.e. GPL)
<nacc> sarnold: effective jinx :)
<sarnold> nacc: I can't help myself :) I follow every patch / issue / link ...
<nacc> sarnold: it's good, makes me feel less alone :)
<nacc> slangasek: fyi, i think the removal of s2tc has made steam uninstallable on bionic
<slangasek> nacc: hmm
<slangasek> nacc: do you want to re-upload s2tc to Ubuntu?
<slangasek> or get someone else to :)
<nacc> slangasek: i only pointed it out as being a regression and you removed it :)
<nacc> slangasek: i can re-upload it, if htat's the 'right' solution; i'm not sure how multiverse works in this regard :)
<slangasek> nacc: yes, packages removed from Debian are also removed from Ubuntu "semi-automatically" when there is nothing holding them in; but Ubuntu developers should feel free to revert removals when appropriate
<slangasek> nacc: they simply need to do so in a way that makes it clear that Ubuntu is taking responsibility for the package now, rather than it being a Debian sync
<nacc> slangasek: would update-maintainer be sufficient (and I guess a new version string)?
<slangasek> nacc: yep
<nacc> slangasek: ack, will do it now
<cjwatson> sladen,slangasek: FWIW I think the situation is qualitatively different if a document has some preferences but is happy to fall back to some other more-or-less-interchangeable font, than if an application tries to load a single font and is in a somewhat broken state if it's missing (I had the impression that this case was more like the latter, but I may be mistaken)
<slangasek> cjwatson: yes; in this context, the code looks for a specific font in order to render its logo, with no fallback.  I haven't tested what the code does if the font is absent; maybe it works but has a broken logo, maybe it crashes; but ideally we would deliver what upstream /wants/ the user to experience, so I'm glad to see upstream has given us a license exception statement now in this case
<xevious> nacc: What would the best way to update php-codesniffer be? It just needs uscan & uupdate run. Should I try to get in touch wih the Debian maintainer?
<nacc> xevious: you can file a bug in debian and a bug in ubuntu; i can do the one in ubuntu
<tsimonq2> slangasek: Would this be satisfactory? https://github.com/psifidotos/Latte-Dock/compare/db58a240400e4dbf6c87dac0c7ab04acb881e813...1a6fbcdfe0811436f39fc189b1a0eea707de3c60
#ubuntu-devel 2018-02-28
<slangasek> tsimonq2: that looks fine. Also fine was the upstream statement that they are ok with us distributing the binaries
<cpaelzer> hmm, any known hickup on the test machnies? I see "cati" on http://autopkgtest.ubuntu.com/running as "Running for 0g 16m" since yesterday
<cpaelzer> test time dilation :-)
<cpaelzer> and it affects i386, amd64 and ppc64 - so it isnot just one hung test vm
<cpaelzer> OTOH armhf and s390x worked in ~24 minutes yesterday
<cpaelzer> so it is not generally broken to be a hanging test
<GunnarHj> Hi mvo, can you please revisit https://github.com/snapcore/snapd/pull/4723 ?
<GunnarHj> I made the change we agreed on, but CI complained again. Can't see that the complaints are related to the proposed change.
<GunnarHj> What now?
<Laney> who's maintaining ddebs.u.c atm? Is there some known issue with syncing of some ddebs? I'm looking at https://launchpad.net/ubuntu/+source/clutter-1.0/1.26.2+dfsg-4/+build/14173188 - some of those don't show up at http://ddebs.ubuntu.com/pool/main/c/clutter-1.0/
<Laney> in fact most of the -4 ddebs aren't there
<xnox> Laney, try bdmurray ?
<Laney> cheers
<Laney> I couldn't remember who owns that now
<mvo> GunnarHj: in a meeting right now, but will look as soon as I can
<cpaelzer> the cacti tests on autopkgtests are still dead (pretend to run for 15 minutes, but don#t move since a day)
<cpaelzer> shouldn't there be a hard timeout at some point - if so does one know the timeout value?
<cpaelzer> because atm I can't even restart them (test zombie apocalypse :-P )
<Laney> the running page was fake news, updated now
<cpaelzer> thanks Laney, looking what is there now ...
<cpaelzer> hmm the arches that appeared hanging before are now silently gone
<cpaelzer> e.g. the test does not show up in http://autopkgtest.ubuntu.com/packages/cacti/bionic/amd64
<cpaelzer> neither as failed nor as passed
<Laney> yeah give me a minute
<cpaelzer> ah so this part also needs tim eto regen
<cpaelzer> sure, will check in ~15 again
<Laney> weird, our machine was restarted and that seems to have done something bad to the tests that were in progress at the time :(
<cpaelzer> as long as we find a way out of the "something bad" hole all is fine
<Laney> yeah it's fine
<Laney> just requeue them
<cpaelzer> need to wait until update_excuses relizes that they are gone
<cpaelzer> Laney: or will that not happen and I should construct the requeue links manually?
<Laney> I did it, don't worry
<Laney> well just for net-snmp
<Laney> to figure out which other ones are dangling it'll be easiest to wait for the queue to go down and see what's still in progress then
<acheronuk> is anyone with knowledge of the latest ubiquity changes around?
<acheronuk> https://bugs.launchpad.net/bugs/1752323
<ubottu> Launchpad bug 1752323 in ubiquity (Ubuntu) "Ubiquity crashes at startup on Kubuntu daily iso - 2018/02/28" [Critical,New]
<cpaelzer> Laney: cluster-glue for net-snmp on amd64 and i386 are the same, did you requeue all of net-snmp or just the cacti tests?
<GunnarHj> mvo: Ok, thanks.
<bdmurray> Laney: juliank made some recent changes to the ddeb retriever so is more familiar with the code.
<xevious> Is anyone else seeing this message while booting 18.04? "A start job is running for sys-subsystem-net-devices-multi-user.device (XXs / 1min 30s)"
<xevious> For me, it waits the whole 1min 30s, then continues booting properly (networking works fine).
<Laney> bdmurray: ok, but if there are any logs it might be good to look around that time to see if something shows up there
<bdmurray> Laney: Noted
<sunweaver> nacc: around? Quick request for feedback. I have a quite complex fix for the gosa mcrypt -> openssl transition, but I need more time than just today to upload a fix to unstable.
<nacc> sunweaver: ack
<sunweaver> Would you be willing to manually sync it over to bionic once uploaded (withing the next couple of days, if things go as planned).
<nacc> sunweaver: i'll need to file a FFE for it, but I think that would be fine, given that the 'feature' is re-adding something that's present in prior releases
<nacc> sunweaver: so ack :)
<nacc> sunweaver: thanks for reaching out!
<sunweaver> nacc: nice. I'll see to it with top prio.
<nacc> mdeslaur: around?
<nacc> mdeslaur: i'm noticing (well, others did in #ubuntu/#ubuntu+1) that ubuntu-support-status is reporting some weird packages in 'Unsupported' (on bionic, and a user reported on xenial) -- e.g., apt-file, expect, etc.
<mdeslaur> nacc: apt-file and expect are both unsupported
<nacc> mdeslaur: what does that mean in this context?
<nacc> mdeslaur: oh, no "Supported" field in packages?
<nacc> mdeslaur: ... but why? :)
<mdeslaur> nacc: it means the packages are in universe and nobody supports them
<nacc> mdeslaur: so that's about package subscription?
<nacc> mdeslaur: just trying to understand
<nacc> (so i can answer better in #ubuntu/#ubuntu+1)
<mdeslaur> nacc: you know the difference between main and universe, right?
<nacc> mdeslaur: right
<mdeslaur> main = canonical supports it, universe = community supports it
<nacc> mdeslaur: so you're saying universe does not actually mean that, then
<nacc> :)
<mdeslaur> in universe, some packages have been assigned as being supported by specific community members, for example, packages that flavours have decided to support
<mdeslaur> when a flavour asks for lts status, they sign up to support packages part of their package set
<mdeslaur> and if nobody asks to support a package, it is "unsupported"
<mdeslaur> which means nobody has commited to supporting it
<nacc> ok, so "community supported" is actually more 'active' then just being in universe
<mdeslaur> yes
<nacc> mdeslaur: ok, that explains that, thanks
<mdeslaur> once bionic comes out, some universe packages will have a 3-year supported firld
<nacc> i think the community understood 'community supported' to mean 'is in universe'
<mdeslaur> field
<nacc> so i'll correct that :)
<mdeslaur> unfortunately, nobody has committed to supporting all of universe yet ;)
<alkisg> Wouldn't it be better to list the debian maintainers there?
<mdeslaur> in what way are debian maintainers supporting ubuntu packages?
<alkisg> (assuming there's no ubuntu .diff)
<mdeslaur> they aren't releasing security updates for ubuntu, or fixing bugs
<alkisg> Ubuntu bug => report in launchpad, debian bug => report in debian, upstream bug => report upstream
<alkisg> As as users, shouldn't I get to know that there are those 3 levels of support here?
<alkisg> *there
<alkisg> *as a user...
<TJ-> The misunderstanding is because the word "support" is used in more than context; most users understand it as being able to get help whereas as for packages a better word would be "maintained"
<TJ-> s/more than context/more than ONE context/
<mdeslaur> alkisg: while packages originally come from debian, once ubuntu is released, updates no longer trickle down
<alkisg> mdeslaur: eh, there are several cases where a new debian release gets SRU'ed or microupdated to Ubuntu after release
<alkisg> But the main point is "I have this bug report that I want to file, where would I file it, how to contact the person that wrote that package that I'm using, is anyone maintaining it..." not so much as "how can canonical support me"
<mdeslaur> that would be "always in ubuntu"
<alkisg> So personally I'd really like it if it was clearer for the users that there are those 3 levels of support; I'm seeing even long time users that don't realize that
<mdeslaur> Well, I disagree with the three levels
<mdeslaur> but meh
<xnox> alkisg, canonical customers use the Ubuntu Advantage to file tickets typically. And that has 3 leves of support - Essential, Standard, and Advanced ;-)
<alkisg> xnox: yeah, it's like trying to fit the canonical marketing into .deb fields, it doesn't fit so well there :)
<alkisg> Upstream code, debian packaging, ubuntu diff... 3 teams writing code, and it's best to file bug reports to the team that wrote the exact line that causes each issue... but sure, there are many ways to view it, that's just mho
<xnox> alkisg, there is no way to generalise things, as it very much depends on the bugs and issues at hand. Most of the time, it all boils down to specific bugs/problems/issues encountered. And at times, the fixes may be cherrypicked in one package, multiple package, other packages, and/or fixes and solutions created from scratch.
<xnox> alkisg, no, it is not best to file a report with a specific team, for a shortest time to fix.
<xnox> alkisg, as often times, independant things work correctly by themsevles, yet fail to integrate, with no fault of any of the individual teams.
<xnox> alkisg, ubuntu bugs, should go to ubuntu first. always.
<mdeslaur> if you want it fixed in ubuntu, it needs to be filed in ubuntu
<alkisg> Let's take a package in universe for example. Noone maintains it in ubuntu. Why would we want a bug report in launchpad for that, instead of redirecting users to debian or upstream?
<xnox> then go through Ubuntu bug triange, then find the fix, and dig deeper.
<xnox> alkisg, because ubuntu systems, are different enough, to warrant different behaviour, of the same source code.
<alkisg> I've seen thousands of bug reports in launchpad like that, that just then make users not want to file bugs anymore
<mdeslaur> alkisg: what good is redirecting a user to debian if the package in ubuntu doesn't match the package in debian?
<xnox> alkisg, we have differt ISA levels on all architectures, vs debian.
<xnox> alkisg, different kernel, toolchain, libc, qt, gtk, etc.
<alkisg> mdeslaur: agreed. But what if it's in universe, with no ubuntu .diff, and noone maintains it in ubuntu, etc etc?
<alkisg> Wouldn't it be better for the users to at least know that they may get support either in debian, if they reproduce it there, or upstream in many cases?
<xnox> alkisg, we do maintain universe, we do fix FTBFS bugs, we do upload srus for universe. Note, everything in main, at one point was in universe!
<alkisg> Now many users don't know that
<mdeslaur> alkisg: nobody in debian is going to maintain the package in ubuntu either...if you have 1.2.7-1 in ubuntu and debian is at 1.3.6, good luck getting something useful out of filing a bug with debian
<xnox> alkisg, it's like Mint users filing bugs in launchpad, instead of Mint -> most of the time i really cannot help them at all.
<mdeslaur> this is exactly what "supported" means...someone has committed to making sure the bug gets looked at and fixed
<xnox> alkisg, i think you are mistaken on the level of good will of people. And a valid bug, is a valid bug.
<xnox> most bugs, are valid across many versions of upstream software.
<xnox> it's very "lucky" to hit a bug, which has already been fixed elsewhere.
<alkisg> Anyways I think we said our points of view; not sure what I could add (or you could add) to change each other's minds... we all have enough experience with bugs to have made our own minds up
<alkisg> In the past, I used to start filing bug reports in ubuntu first, that was very disappointing in many cases
<alkisg> Currently, I follow that 3-levels-of-support method, and it's much more effective for me
<nacc> xnox: i think the contentious point (to me) is "< xnox> alkisg, we do maintain universe"
<nacc> xnox: except there is some percentage of universe that is 'unsupported' (which would imply unmaintained to me)
<mdeslaur> we don't maintain universe, we will sponsor and help anyone who wants to fix something in universe
<mdeslaur> that's not the same
<xnox> nacc, the amount of work i put into package maintainance in debian, and in ubuntu, and in universe, is a bit insulting to say unmaintained.
<nacc> mdeslaur: perhaps there should be help text in ubuntu-suppor-tstatus :)
<mdeslaur> nacc: file a bug! ;)
<nacc> xnox: i agree, i'm going by what i would read if i saw the u-s-s output
<nacc> mdeslaur: ack :)
<xnox> nacc, alkisg - mdeslaur's perspective is from an Ubuntu Security point of view, and there is no guarantee that CVE fixes are shipped for packages in universe.
<nacc> mdeslaur: i think if the terms were well-defined, it would not be an issue, so that's probably teh right approach
<mdeslaur> nacc: file it in debian first, let's see how that goes ;)
<nacc> lol
<xnox> but from the point of universe, as during development, it is maintained a lot. by us, where us, are people in the Ubuntu Foundations team
<nacc> mdeslaur: i'm really not trying to blame you. i was suprising to see how many packages on my system were 'unsupported'
<nacc> when they are 'maintained' as xnox said
<xnox> autopkgtests fixes, ftbfs fixes, abi/library transitons, etc.
<nacc> 'unsupported' in such a tool, to me, reads like 'where the  hell did this package come from'
<mdeslaur> nacc: "supported by nobody" perhaps? ;)
<mdeslaur> I'm not sure what a good term is
<xnox> nacc, what is 'unsupported'? all packages in ubuntu are supported, but they have different timeframes.
<mdeslaur> for something that nobody has committed to support
<nacc> xnox: exactly
<alkisg> Not supported by Ubuntu
<nacc> xnox: it's the ubuntu-support-status output, though :)
<mdeslaur> xnox: "supported for 0 days"
<mdeslaur> xnox: let me know which universe packages you support so I can send you the CVEs
<xnox> nacc, i'm not sure what you expect from that tool. that tool, tries to list things that get HWE, security, and regular SRUs only, in stable releases.
<xnox> for the purpose of commercial support.
<nacc> xnox: it doesn't say that anywhere
<mdeslaur> http://people.canonical.com/~ubuntu-security/cve/universe.html
<nacc> xnox: and it doesn't say canonical-support-status
<nacc> which perhaps it should
<xnox> nacc, it does say which bits is canonical supported, and which are community supported.
<xnox> nacc, because official flavours, have community support: some sign up for 3y, some for 5y.
<nacc> xnox: i mean it does not say "I try to list things that get HWE, security and regular SRUs for the pruposes of commercial support"
<xnox> nacc, e.g. kubuntu is 5y community supported package.
<nacc> which would be a canonical thing (I assume)
<nacc> xnox: i understand all that :)
<xnox> nacc, please read the output of ubuntu-support-status
<xnox> nacc, it does state canonical, community, nobody designated. very clearly. with timeframes.
<nacc> https://paste.ubuntu.com/p/WwSdscnwfd/
<nacc> xnox: yes, i'm not arguing with that
<nacc> xnox: it does not define what 'unsupported' is
 * xnox even has packages that are "that can not/no-longer be downloaded"
<xnox> nacc, but for _all_ of these, bugs go to launchpad. and _all_ of these is still ubuntu.
<mdeslaur> it means "nobody has committed to support"
<nacc> mdeslaur: right, i know that now :)
<mdeslaur> is there a better synonym?
<xnox> not that no support will be provided
<nacc> xnox: i don't see how any user would know that
<xnox> because opportunistically, there is support provided.
 * xnox spots mistakes in ubuntu-support-status in bionic
<mdeslaur> xnox: good, go fix the seeds ;)
<nacc> xnox: right, i think your distinction can be expressed by the tool
<nacc> xnox: my hope is that users can run this on their system and we can quickly see what they have installed from 3rd party
<nacc> xnox: right now, the unsupported part makes that harder (afaict)
<xnox> nacc, please open a bug, on launchpad, against update-manager package ;-)
<mdeslaur> If someone has a better term than "unsupported" that clearly informs users to not expect support, I'm all ears
<xnox> nacc, the distinction of source of instalation, would be nice. cause e.g. google-chrome package installed form dl.google.com repository is clearly supported .... (by Google)
<alkisg> It would indeed be a lot clearer if the components were "main, 3years-community-sup, 5years-community-sup, universe" :D
<xnox> nacc, and universe from ubuntu; is different from a random PPA
<nacc> xnox: right
<mdeslaur> please don't pretend universe is supported in any way
<nacc> lol
<nacc> xnox: mdeslaur: i feel like you're saying different things re: universe
<nacc> which is why i think the tool needs to be explicit about what it means :)
<mdeslaur> sorry, I mean the part of universe nobody has commited to supporting
<mdeslaur> ie: not community
<xnox> nacc, alkisg - and what you imply is not "support" either.
<xnox> or ask for.
<nacc> xnox: what did I imply?
<xnox> nacc, it seems like you are saying "it appears as if I installed too many packages, not from ubuntu repositories" which has nothing to do with weather there is a team that committed to provide timely critical SRUs & security patches. It seems to me that for you support is "there is a place to file bugs, which are looked at by people, and fixed eventually, via ongoing upgrades" -> which i call maintainance.
<nacc> xnox: if the tool is *only* about security updates
<nacc> thenit should be named something else
 * mdeslaur considers deleting the tool completely
<nacc> mdeslaur: +1 :)
<xnox> nacc, break your concerns down into smallest concern possible, phrase it as simple as possible, and open a bug report.
<TJ-> There's a relatively simple change to the tool which could clarify things enormounsly. When using --show-unsupprted and lumping all Ubuntu and 3rd party packages in one list, separate those out with different headers so instead of "Unsupported:" there is "Unsupported (Ubuntu universe/multiverse):" and "Unsupported (Third party installs):"
<nacc> xnox: yep
<xnox> mdeslaur, people still look at Supported: field in the package archive.
<mdeslaur> xnox: too bad it's wrong for every release except bionic
<mdeslaur> xnox: the whole point of the ubuntu-support-status sru was to stop relying on it for stable releases
<xnox> mdeslaur, we fixed up xenial-updates!
<mdeslaur> well :P
<mdeslaur> let's just make sure it's going to be accurate in bionic
<mdeslaur> TJ-, nacc: I think separating out third party installs is a good idea
<xnox> TJ-, grouping by Apt-Sources is hard, due to lack of description, and one can be using a random self-hosted ubuntu mirror. I guess we could group by the overriden maitnainer.
<nacc> mdeslaur: LP: #1752380, feel free to reword
<ubottu> Launchpad bug 1752380 in update-manager (Ubuntu) "ubuntu-support-status: emit source of packages" [Undecided,New] https://launchpad.net/bugs/1752380
<TJ-> xnox: for Ubuntu packages can't we rely on the apt /lists/ files ?
<xnox> however, grouping the output by Apt-Sources will be a massive step up.
<xnox> TJ-, ubuntu-support-status goes via api, so it pulls things as seen by e.g. $ apt show ubuntu-dev-tools
<xnox> that has:
<xnox> APT-Manual-Installed: yes
<xnox> APT-Sources: http://gb.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
<xnox> but
<mdeslaur> I doubt we'll have enough information to be able to do it with apt, but it would definitely be nice
<xnox> TJ-, deb http://gaosu.rave.org/ubuntu/  is also ubuntu.....
<TJ-> can we via API get the same info that "apt list --installed" provides?
<nacc> TJ-: LP: #1752379, if you want to help me flesh that out
<ubottu> Launchpad bug 1752379 in update-manager (Ubuntu) "ubuntu-support-status could more clearly define unsupported" [Undecided,New] https://launchpad.net/bugs/1752379
<mdeslaur> xnox: what about the Origin tag, do people put Ubuntu in their third-party repos?
 * xnox doesn't know about origin of Origin
<TJ-> nacc: xnox I'll do some hacking on the source see what is possible
<xnox> at least google-chrome-stable does not have Origin, but does have Apt-Sources
<xnox> maybe we can group things by origin.
<mdeslaur> "Maintained by nobody for 5 y"
 * xnox giggles
<nacc> mdeslaur: xnox: you bring up a good point, support vs. maintain
<nacc> i think as ubuntu developers, etc. the difference is clear, but for regular users it might not be
<TJ-> I'm getting sick of LP! Someone tell me where/how to fetch the latest code for update-manager!
<nacc> TJ-: `pull-lp-source update-manager`
<mdeslaur> I'm not sure I know the difference between support and maintain myself
<cjwatson> or for the latest upstream, 'bzr branch lp:update-manager'
<xnox> things that are not maintained, are removed from the archive, and then upon upgrades it is listed as "packages no longer available, would you like to remove them?"
<TJ-> To me "maintain' infers bugs may be fixed whereas "support" means someone might help me use/configure the package
<xnox> for example, upstart is supported in xenial; but no longer maintained, and has been removed from ubuntu.
<nacc> TJ-: --^ but i think that contradicts your definition
<nacc> because id on't think anyone will a user configure/use upstart on xenial :)
<nacc> it's there :)
<mdeslaur> so we should never use "support" then
<nacc> mdeslaur: i wonder if that's really the underlying issue :)
<xnox> TJ-, maintain -> bugs will be fixed in the devel series, and if suitable might be eligible for SRU/Security/Backport (support), the "support" to use/configure is typically called "end-user support", rather than the L3 support which what the "supported" status implies.
<nacc> xnox: so u-s-s is only relevant to canonical customers?
<nacc> (trying to narrow down what L3 support is)
<TJ-> nacc: cjwatson: thanks :) so which of the 3 methods is the 'canonical' (not Canonical!) one to use between pull-lp-source, bzr branch lp:update-manager and git clone https://git.launchpad.net/~usd-import-team/ubuntu/+source/update-manager ??
<cjwatson> I reckon that never trying to reduce any of these complex concepts to a single misunderstandable word would be a good idea
<xnox> TJ-, e.g. canonical provides very little end-user support. Yes the toolchain is in main, but we provide very little direct end user support, as to why ubuntu gcc doesn't compile sombodies code.....
<TJ-> nacc: I know, rename the tool to canonical-support-status :D
<mdeslaur> TJ-: but we want to know which packages are community-supported too
<xnox> TJ-, but that's still confusing, if you are after "support" to use/configure a thing =)
<cjwatson> TJ-: pull-lp-source gets you the most recent version in the Ubuntu archive; bzr branch lp:update-manager gets you what's under development upstream.  Neither of those is more canonical than the other, since it depends what you're trying to do
<TJ-> mdeslaur: :P that's a little 'c' not a big 'C'
<mdeslaur> lol
<mdeslaur> this conversation wasn't confusing enough ;)
<cjwatson> TJ-: the git clone is an under-development method to fill the same slot as pull-lp-source in a more convenient/powerful/etc. way
<nacc> TJ-: and the git repo will eventually (hopefully) supplant the `pull-lp-source` option
 * TJ- whistles innocently
<TJ-> cjwatson: aha, because I do prefer git... so I'm safe to use that (in this case) ?
<nacc> TJ-: i'd make sure it's up to date (I'd need to check)
<nacc> it *should* be, but we're under some flux right now
<cjwatson> TJ-: like I say it depends what you're doing.  If you intend to contribute code somewhere, you should always start from the intended target of your contributions
<TJ-> nacc: It's OK I'll compare the two trees after using both methods
<xnox> TJ-, i believe usd-import-team is "pull-lp-source done with git" and should match latest in-archive version; but it's not a suitable base for e.g. merge proposal into the devel series.
<cjwatson> TJ-: (and IMO it's generally best to contribute code as far upstream as possible, all other things being equal)
<TJ-> cjwatson: right, which is why I was trying to figure out which one to use... generally I prefer working on the development master branch and then backport/cherry-pick
<cjwatson> TJ-: with that extra piece of information, I'd recommend bzr branch lp:update-manager
 * xnox shakes fist "native" package format should not have ever existed
<TJ-> xnox: right ... as if figuring out the meaning of 'support' wasn't painful enough, now I have to figure out 'canonical method' :D
<TJ-> cjwatson: thanks
<TJ-> cjwatson: I can use the git-bzr thing to do that too, so I'm happy
<xnox> TJ-, thinking about it, there is a lot more end-user support on how to use/configure things; including majority of things in universe. As there are a tonne of guides and blogs and forums on the interent telling people how to use this or that on ubuntu.
<nacc> xnox: right, but 'random forum post' would never be considered Ubuntu support
<TJ-> In the context of IRC then in #ubuntu for example 'support' means any package in the archives
<mdeslaur> perhaps the tool should say what support means... "Security updates and important bug fixes" or something
<TJ-> mdeslaur: indeed, I think it writing footnotes would be great idea
<nacc> mdeslaur: yeah that's what i initially was writing in LP #1752379
<ubottu> Launchpad bug 1752379 in update-manager (Ubuntu) "ubuntu-support-status could more clearly define unsupported" [Undecided,New] https://launchpad.net/bugs/1752379
<nacc> mdeslaur: i can file a third bug if that's appropriate
<nacc> or can just amend that one to request defining all the relatively subjective terms
<mdeslaur> I think adding to that one is fine
<nacc> mdeslaur: bug amended
<TJ-> to save duplication, if no one objects, I'll work through these?
<mdeslaur> no objection from me
<nacc> TJ-: +1
<mdeslaur> as long as the resulting output allows someone to know which packages they shouldn't count on having security updates for, I'm ok
<TJ-> I may be back with questions especially regarding the API if I get lost
<nacc> mdeslaur: ack
<nacc> xnox: totally separate question, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846219 is why fusionforge is stuck in b-p. It was filed over a year ago and no response; does that imply fusionforge is abandoned in Debian?
<ubottu> Debian bug 846219 in src:fusionforge "Missing runtime dependencies (former libarc-php, libgraphite-php and php-http)" [Grave,Open]
<TJ-> mdeslaur: I'd like to see something like "Security updates for X years"
<nacc> xnox: i woudl ask in the bug, but not sure if the debian maintainer would find it offensive to be asked "did you abandon this?"
<xnox> nacc, if you at all follow recent news about alioth shutdown, and move to gitlab instance salsa..... you would know that yes, fusionforge has been abandoned for years now =)
<xnox> alioth (fusionforge) is dead; long live salsa (gitlab)
<xnox> https://salsa.debian.org/public
<nacc> xnox: fusionforge is still in debian and ubuntu
<nacc> xnox: should we delete it?
<xnox> nacc, probably, yeah.
<nacc> xnox: ok
<nacc> xnox: because it sounds like it's both unsupported and unmaintained :)
<xnox> nacc, it needs to be unshipped
<Odd_Bloke> Canonically unsupported and unmaintained?
 * Odd_Bloke runs.
<nacc> xnox: ack
<nacc> Odd_Bloke: :)
<seb128> jbicha, doh, the clutter autopkg test now fail on
<seb128> Unpacking fonts-ubuntu-console (0.83-1) ...
<seb128> dpkg: error processing archive /var/cache/apt/archives/fonts-ubuntu-console_0.83-1_all.deb (--unpack):
<seb128>  trying to overwrite '/usr/share/consolefonts/UbuntuMono-B-8x16.psf', which is also in package fonts-ubuntu-font-family-console 1:0.83-0ubuntu2
<seb128> jbicha, that transition is not meant to clear before ff it seems :/
<jbicha> seb128: sorry, fix was just uploaded to bionic-proposed (missing breaks/replaces)
<seb128> jbicha, ok, I guess we need to retry things when it's published then
<seb128> jbicha, thx
<sladen> ta
<slangasek> seb128: all autopkgtests are busted right now, I'll be batch-retrying
<seb128> slangasek, thanks
<bdmurray> jbicha: is bug 1751546 something you could take a look at?
<ubottu> bug 1751546 in tasksel (Ubuntu) "the net installer doesn't install gnome-vanilla" [High,Confirmed] https://launchpad.net/bugs/1751546
<jbicha> bdmurray: not this week, but feel free to remind me later
<bdmurray> jbicha: would assigning it to you be a good reminder or ...?
<jbicha> no, I haven't really used the LP assignment feature
#ubuntu-devel 2018-03-01
<nacc> slangasek: xnox: what would be the right way for me to esnure i have the most recnet ubuntu and debian keyrings in git-ubuntu (for gpg verifying the archive files current and historical)?
<nacc> dpb1: --^ fyi reimport on hold until i resolve that
<nacc> slangasek: xnox: to be clear, in a snap, so 'run bionic' isn't an answer (yet)
<rbalint> mvo: imo -updates should be enabled in u-u for Ubuntu as well
<rbalint> mvo: otherwise updates from -security may fail to install or may be stuck due to missing dependencies
<rbalint> mvo: filed the PR, it may even fix Travis check
<rbalint> mvo: u-u changes are in limbo, i'm trying to fix travis checks
<rbalint> mvo: you can wait with the review till i update changelog again
<mvo> rbalint: hm, I remember this, iirc we allow dependencies now even from non whitelisted sources, no?
<mvo> rbalint: for exactly this reason
 * mvo needs to step out for a little bit
<rbalint> mvo: you seem to be right, the config file is a bit misleading
<mvo> rbalint: yeah, interessting error in travis, maybe apt.apt_pkg.config.set("Debug::pkgProblemResolver","1") will help
<mvo> rbalint: also "debug::pkgDepcache::marker","1" - not sure if we automatically add this with --debug
<mvo> rbalint: maybe we should :)
<rbalint> mvo: python3 (python-apt) is also crashing in https://travis-ci.org/mvo5/unattended-upgrades/builds/347636065
<rbalint> juliank: ^
<rbalint> (python-apt is just a suspect)
<rbalint> mvo: for today i planned only tagging 1.0 and happily uploading it to Debian & Ubuntu, but that escalated quickly :-)
<mvo> rbalint: heh, yeah, the joy of software development :/
<slangasek> nacc: not sure I understand the question; the ubuntu-keyring package is authoritative
<slangasek> nacc: so you probably need to be pulling it into your snap?
<rbalint> mvo: ok, now i finalized u-u's changelog, too
<mvo> rbalint: cool, did you figure out the travis error?
<rbalint> i found several ones :-\
<rbalint> mvo: it is hopeless to gate the PRs with an upgrade test running on crashing python/dependencies + with 3rd-party packages
<rbalint> u-u correctly fails on apt resolver error in the best case
<rbalint> the python-apt crash is already tracked: LP: #1737441
<ubottu> Launchpad bug 1737441 in python-apt (Ubuntu Bionic) "/usr/bin/unattended-upgrade:11:__GI___libc_free:operator:__gnu_cxx::new_allocator:std::allocator_traits:std::__cxx11::basic_string" [Undecided,Confirmed] https://launchpad.net/bugs/1737441
<mvo> rbalint: agreed if the test case includes 3rd part packages, I though it was a vanilla ubuntu
<rbalint> mvo: one more little change, please check the PR and it it is good i'm prepping the release
<mvo> rbalint: sure, let me look.
<mvo> rbalint: looks great now, is it ready to be merged? if so I am happy to press the button
<rbalint> ready! :-)
 * mvo hugs rbalint 
<rbalint> mvo: hugs mvo :-)
 * rbalint hugs mvo :-)
<tkamppeter> Hi, I need sponsoring for an upload of brlaser before the FF today. It is the new version 4: https://bugs.launchpad.net/ubuntu/+source/brlaser/+bug/1752579
<ubottu> Launchpad bug 1752579 in brlaser (Ubuntu) "Needs sponsoring: Upload brlaser 4" [High,New]
<ahasenack> sil2100: hi there,
<ahasenack> sil2100: about #1717040, xenial doesn't have the updated zstd package yet
<ahasenack> sil2100: just wondering if you missed it, or if you really just wanted to work on the artful update?
<ahasenack> bug #1717040
<ubottu> bug 1717040 in libzstd (Ubuntu Xenial) "Please backport libzstd 1.3.1+dfsg-1 (universe) from artful" [Undecided,Fix committed] https://launchpad.net/bugs/1717040
<ahasenack> thanks ubottu
<sil2100> ahasenack: hey! I didn't want to publish it as we're still in .4 freeze, and from what I know it's seeded in the ubuntustudio flavour
<ahasenack> ah
<ahasenack> sil2100: so what do we do now, wait for .4 to be out, then publish it? Is there a trigger so we don't forget?
<sil2100> ahasenack: well, it's marked as ready so the SRU members see it as ready, and once we're done with .4 it'll just get published like any other marked SRU
<ahasenack> ah, ok. The std comment that was added hinted that it would not be looked at anymore
<ahasenack> but that might be about the artful task then
<sil2100> Yes :)
<ahasenack> ok, thanks
<nacc> slangasek: you can't pull from not the version you're building on without lots of hacks
<nacc> slangasek: and the xenial debian-archive-keyring package (apparnetly) does not have latest Debian keyrings
<nacc> I'm checking now
<nacc> slangasek: yeah, that's the problem, i think
<nacc> (possibly true for the ubuntu keyring too, but perhaps it hasn't changed enough to be noticed)
<nacc> slangasek: i can rephrase my question if that will make it clearer :)
<xnox> nacc, what are you verifying? and how did you get those files?
<nacc> xnox: https://git.launchpad.net/usd-importer/commit/?id=48249b21607fdfbb80af9d53e8d0b1375d8778c1 -- basically, we are using the archive to determine what files are in which components in releases so that we can phase correctly.
<nacc> xnox: those files need to be verified using the archive keys
<xnox> nacc, specifically which files / and signatures.
<xnox> nacc, sorry =) i don't want to read source code....
<xnox> nacc, are you trying to verify signatures of .dsc? cause we do not ship keyrings to verify that.
<nacc> xnox: Release files
<nacc> xnox: no
<nacc> xnox: we implicitly trust LP to give us good data
<xnox> nacc, so ubuntu-keyring should have all the keys in /usr/share/keyrings/ubuntu-archive-keyring.gpg and /usr/share/keyrings/ubuntu-archive-removed-keys.gpg
<xnox> for all the releases / archives.
<nacc> xnox: even on xenial?
<xnox> nacc, yes.
<nacc> xnox: ok, i can leave that as-is; what about the debian keys?
<xnox> nacc, debian-keyring too... but they rotate keys too often. I guess we could SRU debian-keyring to update keys there.
<nacc> xnox: yeah, i'm seeing it fail right now for something in debian (i can figure out which in a moment)
<nacc> xnox: so ... while the SRU will take ~ 7 days; what should I do in the meanwhile? I can't generally wait on that delay (we get gpg failures)
<xnox> nacc, you can download and install newer debian-keyring on the machine you need at.....
<nacc> xnox: from ... ?
<xnox> nacc, or you can be a normal person, and use chroots to get the right keyrings.
<nacc> xnox: you want me to use chroots in a snap?
<xnox> nacc, if you don't know how to install debian-keyring package from a different release?
<nacc> xnox: snaps don't make it easy
<xnox> nacc, it's in the archive....
<nacc> xnox: so i'd need to manually download a fixed URL
<xnox> nacc, this is #ubuntu-devel; i guess you need #snapcraft?! </troll>
<nacc> xnox: :)
<nacc> xnox: the typical answer for snaps is 'build it yourself'
<nacc> i don't know that i can for a native package
<xnox> O_o
<nacc> well, i mean i can, i meant i'm not sure i should
<xnox> nacc, it's just a file.... you can grab them from commit in your git repo.... no?!
<nacc> xnox: and even so, i'm not sure where the 'source' is ... i found debian-keyring on salsa; is ubuntu-keyring on LP?
<nacc> xnox: a file i have to keep up to date all the time?
<xnox> nacc, you should use $ pull-lp-source debian-keyring
<xnox> nacc, you said you can't wait for sru
<xnox> nacc, please contact somebody else, there is nothing that requires foundations involvement here.
<nacc> xnox: i am just asking for suggestions
<nacc> xnox: if you don't want to help, please don't.
<slangasek> nacc: so perhaps this should be an SRU of the keyring package?
<ddstreet> nacc is pull-lp-source failing, or code in usd-importer?
<nacc> slangasek: i think that would solve it this time; but i am not sure it solves it long-term
<nacc> ddstreet: context?
<ddstreet> nacc i don't have context for your discussion ^
<nacc> ddstreet: oh it's about git-ubuntu trying to verify archive files with gpg
<ddstreet> ok so it's not using pull- then
<ddstreet> directly trying to verify sig
<nacc> ddstreet: right, this is for the Release file itself
<nacc> ddstreet: not for source packages
<ddstreet> ah ok cool
<slangasek> nacc: surely it's an issue for the keyring packages in a stable release to not have up-to-date info about the archives
<nacc> slangasek: oh yes, i agree
<slangasek> nacc: and ISTM that your concern is derivative of this
<nacc> slangasek: i guess i meant we probably need to do that at all times
<nacc> slangasek: so it's both do it now, and commit to doing it in the future :)
<slangasek> yeah
<ddstreet> nacc how far back are you importing from? stopping at precise or going farther than that?
<nacc> ddstreet: as far back as LP goes
<nacc> ddstreet: inclusive of debian
<ddstreet> sweet, that'll be a big old git repo for each pkg :)
<nacc> ddstreet: yeah :)
<nacc> slangasek: i can file a bug
<nacc> meanwhile have to go figure out this regression in snapcraft :
<nacc> slangasek: LP: #1752656 i'll fix the tasks in a bit
<ubottu> Launchpad bug 1752656 in ubuntu-keyring (Ubuntu) "Please SRU archive keyrings to older releases" [Undecided,New] https://launchpad.net/bugs/1752656
<ddstreet> nacc i noticed some older packages used keys that were no longer in newer releases, but were in older releases...is that what you're addressing in ^
<nacc> ddstreet: which key do you mean? the uploader's? or the archive key?
<ddstreet> uploader's
<nacc> ddstreet: the old keys are in the 'old' keyrings, usually
<ddstreet> sorry, nm - you're talking about the archive key
<nacc> ddstreet: we don't store uploader's keys in any of the keyrings afaict
<nacc> ddstreet: yeah
<ddstreet> yep sorry :)
<ddstreet> different keys, nm me :)
<nacc> np, it's easy to mix them up
<nacc> ddstreet: did you try using ubuntu-archive-removed-keys.gpg ?
<nacc> ddstreet: RE: LP: #1700846
<ubottu> Launchpad bug 1700846 in ubuntu-dev-tools (Ubuntu) "src:texinfo fails to import (importer) or download (pull-debian-source) with ASCII decoding issue" [Undecided,In progress] https://launchpad.net/bugs/1700846
<ddstreet> nacc i haven't, no
<nacc> ddstreet: that probably would fix it for you
<nacc> ddstreet: that's what git-ubuntu is ahving to do, use both old and new keyrings, since we don't which will work
<ddstreet> cool i'll try it, but as pull-*-source can be used by anyone it still probably needs to default to continue if there's no pub key...i can update the warning msg tho
<nacc> ddstreet: ack
<ddstreet> would be great if my ubuntu-dev-tools changes could get merged one of these days...been waiting for quite a long time now, i think people are getting tired of me bugging them to review it
<ddstreet> anyway
<ddstreet> nacc sorry for another q about git-ubuntu; any plan for it to handle source/changes of snaps?  for example, 'git ubuntu clone git-ubuntu' does not work :(
<ddstreet> in fact i'm not entirely sure how snap sources/changes are tracked/available...
<nacc> ddstreet: not possible, afaik
<ddstreet> pull-snap-source maybe...
<nacc> ddstreet: and no :)
<ddstreet> :)
<nacc> ddstreet: i believe this is something the snap team is working on (reproducible snaps, getting source for snaps)
<nacc> but i have no intention of importing them
<ddstreet> ack
<nacc> usually, they are already in an external git repository
<nacc> so the benefit is lower, i'd think
<ddstreet> yeah, and IIUC not all snaps even make source public
<nacc> nor should they, depending, i guess
<nacc> ddstreet: we are only concerned with 'the archive' in git-ubuntu
<nacc> ddstreet: technically, snaps are not ubuntu specific :)
<ddstreet> true, right
<ddstreet> good point :)
<nacc> ddstreet: feels like it should be a snapcraft or snap subcommand (I guess)
<xevious> Is there an archive of previous Bionic packages? It seems like a change in mysql-server-5.7's postinst script broke my image building script.
<nacc> xevious: you can download them from the archive
<nacc> err from LP
<nacc> https://launchpad.net/ubuntu/+source/mysql-5.7/5.7.21-1ubuntu1/+build/14311288
<nacc> https://launchpad.net/ubuntu/+source/mysql-5.7/5.7.20-1ubuntu1/+build/13855476
<bdmurray> xevious: Its not asking for a password for the mysql user anymore
<bdmurray> bug 1752215
<ubottu> bug 1752215 in mysql-5.7 (Ubuntu) "Server - LAMP installation no longer asks for a mysql password" [Undecided,New] https://launchpad.net/bugs/1752215
<xevious> The error I'm getting is "Error: Unable to shut down server with process id 2796"
<bdmurray> Okay, maybe its not that issue then. ;-)
<nacc> powersj: --^ you may want to subscribe to that
<nacc> rbasak: as well
<powersj> nacc: thx
<wxl> does anyone have any idea where the upstream code of debian-installer is? i can't find it on salsa.debian.org
<sladen> wxl: https://wiki.debian.org/DebianInstaller/Git  suggests it is still at  https://anonscm.debian.org/cgit/d-i/
<wxl> thanks sladen. the project in launchpad was pointing to anonscm but a different location, and it was failing, so i figrued it SHOULD have been on salsa, but i guess everything hasn't been moved over.
<nacc> xevious: i got to those links via the publishing history of mysql-5.7 fwiw
<xevious> nacc: Yeah, thanks for pointing that out. I'm trimming my image creation process down to the bare minimum steps to reproduce the issue I'm seeing.
<nacc> xevious: np
<xevious> bdmurray: I created a bug about the issue I'm seeing: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1752705
<ubottu> Launchpad bug 1752705 in mysql-5.7 (Ubuntu) "installation of mysql-server fails because postinst fails to shut down server" [Undecided,New]
<xevious> bdmurray: Does anything look wrong in those steps to reproduce?
<nacc> xevious: have you tried running the postinst manually (possibly with -x ) ?
<xevious> That'll be my first step after I get back from meeting with my dad for coffee/tea.
<nacc> xevious: ack
<xevious> I'll be back in a half hour or 45.
<sunweaver> nacc: gosa has been uploaded to Debian unstable today. gosa 2.7.4+reloaded3-2 is your friend.
<sunweaver> Can you make sure it lands in Ubuntu bionic?
<nacc> sunweaver: yep
<sunweaver> nacc: thx!!!
<nacc> sunweaver: thank you!
<sunweaver> welcome!
<sunweaver> was a pressing issue on the Debian side, too.
<nacc> sunweaver: yep
<nacc> sunweaver: LP: #1752713 I'll sync once Launchpad can see it
<ubottu> Launchpad bug 1752713 in gosa (Ubuntu) "Please sync gosa 2.7.4+reloaded3-2 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/1752713
<xevious> Clearly, I meant a half hour *plus* 45.
<roadmr> microsoft minutes, I guess
<flooood> hey folks! i tried to modify hid.ko (hid-core.c), i therefore inserted some printk's and replaced the module
<flooood> but the messages never appear on dmesg
<flooood> dbus[607]: [system] Rejected send message, 2 matched rules; type="error", sender=":1.1" (uid=0 pid=613 comm="/lib/systemd/systemd-logind ") interface="(unset)" member="(unset)" error name="org.freedesktop.DBus.Error.UnknownMethod" ...
<nacc> flooood: i think you want #ubuntu
<flooood> is what i get
<nacc> flooood: although not really ontopic there either :)
<flooood> are you sure? i think ubuntu-devel fits best, isn't it? since i try to debug some strange behaviour in ubuntu
<xevious> nacc: I logged into the container after the failed install, added `set -x` to mysql-server-5.7.postinst, and ran `dpkg --configure -a` and it ran the configure script successfully. I'm testing dropping a postinst with `set -x` in it and setting its immutable bit before installing the package.
<xevious> I'm not sure how dpkg will react to that.
<nacc> flooood: this is for development *of* ubuntu
<xevious> Well, as I suspected, dpkg didn't like being unable to unpack the package.
<nacc> xevious: :)
<nacc> xevious: is it possible the postinst always works when run twice?
<nacc> (as opposed to being related to set +x ) ?
<xevious> That's what I expect. I'll confirm now.
<flooood> hm, i would expect that debugging *of* ubuntu *is* development of ubuntu, but okay...
<nacc> flooood: you're debugging some module you modified, right?
<flooood> nope, i modified it TO debug it
<flooood> my modification is "insert printk's"
<nacc> flooood: i don't see how dbus is relevant to printk
<nacc> flooood: those go into the kernel log buffer
<flooood> me too, but that's the only message i get in the moment when i would expect the kernel message - anyhow, have to reboot. c ya
<nacc> flooood: also, how did you 'replace themodule'
<nacc> flooood: i'm really fairly sure this is the wrong channel, in any case
<flooood> okay, spooky... i deleted hid.ko from /lib/modules/..., rebooted and it  _still_ gets loaded, according to modules.builtin, it is _not_ builtin
<flooood> according to modinfo "there is no such ..."
<nacc> flooood: still wrong channel, it's in the initrd almost certainly
<nacc> flooood: you need to rebuild the initrd if you want different modules
<flooood> nacc: where is the right channel then, #ubuntu-debug? ;D
<flooood> thanks!
<nacc> flooood: afaict, you are doing normal kernel stuff, so a kernel channel
#ubuntu-devel 2018-03-02
<xevious> nacc: It only completes if I start an nspawn container and then run `dpkg --configure -a` at the bash prompt launched in the container.
<xevious> nacc: If I directly run dpkg in the container (not manually from a shell inside the container), it doesn't complete.
<xevious> I'll continue investigating it tomorrow.
<nacc> xevious: strange
<jbicha> bdmurray: could you push your changes to lp:software-properties ?
<bdmurray> jbicha: yep, doing so
<jbicha> slangasek: I'm updating software-properties-gtk & update-manager's dependency from libgtk2-perl to libggtk3-perl for debconf. Why is it only a recommends?
<jbicha> slangasek: based on the test case from LP: #1679784, I'm going to bump it to Depends unless you objectâ¦
<ubottu> Launchpad bug 1679784 in software-properties (Ubuntu Yakkety) "Changing from Xorg video driver to NVIDIA driver using Software & Updates does not display debconf prompt" [Critical,Fix released] https://launchpad.net/bugs/1679784
<jbicha> apt gets in this neat inconsistent state while waiting for a debconf answer it will never get
<jbicha> oh I guess it's only stuck until I close the app but stillâ¦
<jbicha> slangasek: also please remove ubuntu-font-family-sources from bionic (replaced by fonts-ubuntu)
<slangasek> jbicha: I don't recall a reason why libgtk2-perl is a Recommends instead of a Depends.  It's possible it's because that's what the package relationship had been previously.  But how does updating to libgtk3-perl work?  Is there now a gtk3-based debconf frontend?
<jbicha> slangasek: https://launchpad.net/ubuntu/+source/debconf/1.5.66
<jbicha> https://salsa.debian.org/pkg-debconf/debconf/commit/0250616b
<slangasek> well, huzzah!
<nacc> sigh, i'm pretty close to asking for a full on revert of the snapcraft SRU
<Unit193> bdmurray: Hi.  Regarding LP #1693032...This reeeally doesn't do jack for us on Xubuntu, nor any other flavor than gnome.  Last year in May you talked with wxl and I about solutions for this in Xubuntu and Lubuntu, I had remarked about xfce4-session-logout (and I don't remember what Lubuntu had)  whatever happened to less hardcoding to GNOME? :/
<ubottu> Launchpad bug 1693032 in software-properties (Ubuntu) "missing dependency on gnome-session-bin" [Medium,Fix released] https://launchpad.net/bugs/1693032
<flocculant> slangasek xnox - seb128 said you've be the best people to mention this too - grub looking horrendous - bug 1748028 has a hardware video of what I see and also a vm - seeing this reported elsewhere by others too
<ubottu> bug 1748028 in grub2 (Ubuntu) "Flashing text at bottom of grub menu" [Undecided,Confirmed] https://launchpad.net/bugs/1748028
<slangasek> flocculant: that looks like a duplicate of the other bug report that has just been tagged regression-update
<flocculant> slangasek: aah - cool, I'll mark my old one as a dupe then
<flocculant> didn't think about tagging it regression-update
<rbasak> powersj, nacc: bug 1752215: the test needs updating (intentional in MySQL). Do we have a place to assign the bug?
<ubottu> bug 1752215 in mysql-5.7 (Ubuntu) "Server - LAMP installation no longer asks for a mysql password" [High,Confirmed] https://launchpad.net/bugs/1752215
<seb128> slangasek, btw we didn't "nack" net-cpp or url-dispatcher removels, just indicators ones (which are still using by the unity session which is now community maintained)
<slangasek> seb128: well, they're dependencies of the indicators; how can we unpick this?
<seb128> slangasek, somebody needs to make the indicators not use them I guess? those depends are not useful under xorg/unity7
<seb128> I guess "needs work"
<seb128> unsure how much that is though, but probably not something we can invest much into atm
<slangasek> right, so who is that somebody :)  if nobody does the work, the libs and their reverse-depends need to be removed
<seb128> there is a new group of people who picked up unity
<seb128> I guess talk to them
<seb128> and tell them you are going to delete their work now if they don't fix your problem :p
<Unit193> sforshee: Thanks for the patch on nvidia 304, I'll use it myself at least. :)
<Unit193> I don't suppose there's a hard push to get everything with openssl 1.1 for Bionic?
<seb128> slangasek, I'm going to have a look today to see if it's easy to drop the depends, if it's not I guess it's up to the unity team
<slangasek> Unit193: as much as possible; we know there will be a couple of packages still in main using openssl 1.0
<Unit193> openssh, right.
<slangasek> seb128: ok, thanks.  what's the best way to flag that to the unity team?  other than just filing bug tasks
<seb128> slangasek, anyway, desktop team own that problem and isn't objecting to remove indicators if you think that's the right way to go
<Unit193> slangasek: Package in universe, it's pretty simple but wasn't sure if anyone would be interested.   https://salsa.debian.org/takaki/gvpe/merge_requests/1
<seb128> slangasek, they use https://community.ubuntu.com/c/desktop/ubuntu-unity-dev I think, otherwise jbicha knows who to ping in their team
<seb128> slangasek, sorry, "desktop team *doesn't* own that problem"
<slangasek> seb128: well, it definitely needs to be fixed or removed soon for 18.04 because of the entanglement with curl
<seb128> k, well as far as I'm concerned you can remove indicators&unity, I just think it would be a shame and a bad step community wise
<seb128> anyway
<seb128> slangasek, let me have a look today to the indicators and ping the unity people and I let you know where we stand
<slangasek> seb128: sounds good, thanks
<seb128> np!
<TJ-> I'm hacking on update-manager (ubuntu-support-status). Is there a recommended way, possibly pythonic, to get the currently running package architecture, even where possibly it's a 32-bit install on a 64-bit kernel, e.g. without shelling out to do 'dpkg --print-architecture'  ?
<cjwatson> TJ-: I'd ask python-apt for it: import apt_pkg; apt_pkg.init(); apt_pkg.config['APT::Architecture']
<cjwatson> TJ-: (ubuntu-support-status already imports apt, which does the apt_pkg.init() bit implicitly, so you don't need that bit)
<TJ-> cjwatson: Yes, thanks, I hadn't spotted that. Makes the job much easier
<sladen> frozen planet.  frozen bionic
* sladen 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 trusty-artful | #ubuntu-app-devel for app development on Ubuntu
<Unit193> sarnold: Hello, looks like Irssi hasn't been patched for the latest CVEs, is this on your tracker?  Would you be interested in reviewing and sponsoring the bugfix instead?
<xnox> slangasek, demote them to -proposed, rather than remove? add block-proposed, let curl migrate, keep them uninstallable in -proposed?
<xnox> Unit193, well, we are down to just 95 packages using openssl1.0, and I hope at least 4 more will get fixed up, so 91. Getting the number lower would be awesome.
<xnox> smoser, rharper - check this out, resolvconf compat interface for systemd resolved => https://github.com/systemd/systemd/pull/8296/files
<Unit193> Last 3 patches above S-V bump in that merge would fix 1. openssl compatibilty. 2. Ftbfs.
<Unit193> (Trying to get it in Debian.)
<smoser> coccinellication.  thats a word ?
<smoser> xnox: what "use resolvconf state in the initramfs and hope that it will be transfered into the root filesystem" ?
<smoser> i'm not aware of anything.
<xnox> smoser, there are some, maybe it's not popular anymore.
<smoser> in fact bug 1714308 pretty well guarantees they didn't do it well
<ubottu> bug 1714308 in initramfs-tools (Ubuntu Zesty) "dns does not work in initramfs after configure_networking" [Medium,Confirmed] https://launchpad.net/bugs/1714308
<xnox> smoser, huh? "they"? above is a pull request, which is yet to be merged upstream to provide a compatible /sbin/resolvconf -u
<smoser> right
<smoser> you said in that pull request that some things "use resolvconf state in the initramfs and hope that it will be transferred into the root filesystem"
<smoser> and i dont know of anythings that do that.
<smoser> nor do i think they would work
<xnox> why not?
<smoser> well maybe the "transfer" part might work
<smoser> but dns didn't work in the initramfs until bionic
<xnox> resolvconf parses input on the stdin, and then sanitises it, and dumps it to /run/resolvconf/interface/$IFACE as if.
<smoser> so configuring resolvconf was clearly not on anyone's high priority
<xnox> hehehe
<xnox> smoser, but it does work in trusty/xenial? maybe nobody uses itermediate releases
<smoser> no
<smoser> to my knowledge we've never had working initramfs dns
<smoser> not in "stock"
<smoser> maybe trusty
<alexarnaud> Hello all
<alexarnaud> Can I forward a bugupstream on Launchdpad ?
<alexarnaud> https://bugs.launchpad.net/ubuntu-mate/+bug/1618723 is the result of https://github.com/mate-desktop/marco/issues/118#issuecomment-355697924
<ubottu> Launchpad bug 1618723 in ubuntu-mate "Unable to connect to wifi with Orca" [Undecided,New]
<alexarnaud> I would like to help on bugs related to accessibility.
<alexarnaud> This bug has been fixed upstream, what is the process to mark it as resolved ? https://bugs.launchpad.net/ubuntu-mate/+bug/1618642
<ubottu> Launchpad bug 1618642 in ubuntu-mate "Desktop launchers invisible to Orca" [Undecided,New]
<alkisg> alexarnaud: this is mostly a channel for ubuntu developers, while for users questions it's #ubuntu-mate and #ubuntu...
<alexarnaud> alkisg: It's not usage question, it's question about the bugtracker, is there a QA channel maybe?
<alkisg> alexarnaud: try the channels I linked, I think you'll have better chances to get a responce
<alkisg> bug management is part of user support offered there
<alkisg> In general, you don't need to file each upstream bug to launchpad as well,
<alkisg> and you'd only mark it as "fix released" once the release lands in the development version of ubuntu
<alexarnaud> alkisg: It's already the case since 17.04 or 17.10.
<alkisg> Nice, then you can just close it
<alexarnaud> alkisg: thanks for your help
<alkisg> You're welcome
<xevious> This mysql-server issue is especially weird.
<xevious> I'm running a few more tests before posting an update to the ticket.
<sunweaver> hi!
<sunweaver> I would like to test ubuntu-desktop in a nested Xserver.
<sunweaver> my setup...
<sunweaver> a bionic-amd64 chroot with ubuntu-desktop meta package installed.
<sunweaver> a nested Xserver launched with "nxagent -ac :1"
<sunweaver> in the chroot, I do: export DISPLAY=:1
<sunweaver> GNOME_SHELL_SESSION_MODE=ubuntu STARTUP="gnome-session --session=ubuntu" dbus-run-session /etc/X11/Xsession
<sunweaver> with that, I get complaints, that the system-wide DBus instance is not running.
<sunweaver> with other desktop envs, esp. on Debian, I can test a desktop from a chroot with that setup.
<sunweaver> Any hint, how this can be done in Ubuntu?
<rbasak> xevious: I commented on the bug. I'm not sure this is a bug in mysql-5.7 packaging though. What's the postinst doing wrong that breaks nspawn?
<xevious> rbasak: It behaves differently depending on how you run it.
<xevious> If you do the installation as a parameter of `systemd-nspawn` it'll fail.
<xevious> If you log into the contain and run the installation from the bash prompt, it'll succeed.
<xevious> Here's the REALLY weird thing I discovered a little while ago..
<xevious> If you do the `apt install` as a parameter of `systemd-nspawn`, but add `dpkg --configure -a` after the `apt` command, it succeeds.
<rbasak> xevious: given what nspawn does, it seems more likely to either be by-design behaviour from nspawn, or a bug in nspawn, no?
<xevious> This worked fine on mysql-server-5.7 5.7.20-1ubuntu1, though.
<xevious> It only broke with the new mysql-server package.
<xevious> rbasak: I'm about to post some more steps to reproduce. If you could try them out, I'd appreciate it.
<xevious> The weird thing about adding `dpkg --configure -a` is that the `apt install` doesn't fail any more: it succeeds and `dpkg --configure -a` doesn't have to do anything.
<xevious> Without that, it fails.
<xevious> I've only tried adding `dpkg --configure -a`. Since it doesn't appear to actually be doing anything, I'm trying an arbitrary command (`ls`) to see what that does.
<rbasak> xevious: as I (just) described in the bug, we've changed how the postinst starts the server internally for upgrade purposes.
<rbasak> xevious: so I can understand that this might break some use case that's less tolerant of how the postinst does that.
<rbasak> xevious: this doesn't necessarily make it a bug in mysql-server-5.7.postinst though, even if it is a regression in behaviour.
<xevious> Please try the steps in the comment I just posted.
<rbasak> xevious: why? Can you not try it yourself in a VM to verify the steps?
<xevious> I have numerous times
<xevious> I just posted a comment
<xevious> New steps
<rbasak> Can you find steps to reproduce that don't rely on nspawn?
<rbasak> If it reproduces for you in a fresh VM with nspawn, I honestly don't see what I can add by confirming it.
 * rbasak will be back later
<xevious> rbasak: I think I found a solution. Testing further...
<lool> xnox: hey! is there some email explaining the way the deputy systemd is supposed to work on 14.04?
<lool> xnox: I have a 14.04 system (with snapd, which pulled deputy systemd) but the certbot cron thinks systemd is init and disables itself; however the systemd timer for certbot doesn't work with a weird error
<lool> I'm trying to understand if certbot systemd timer is supposed to work or if I should change the cron to detect system-systemd-active-but-not-pid-1
<xnox> lool, i am happy to SRU "change the cron to detect system-systemd-active-but-not-pid-1" into trusty.
<xnox> lool, please open a bug and subscribe me?
<lool> xnox: if you mean change certbot, it's a PPA package â might also affect the released one if any
<xnox> lool, basically, on trusty, one should assume pid1 is upstart; by hard-coding it; unless one is inside the snap, then assume pid1 is systemd.
<lool> I'm happy to contact Ondrej@Debian to change the cron
<xnox> lool, yeah, so if building/running on trusty, assume upstart-only, unfortunately.
 * xnox checks calendar, *sigh* trusty is not dead yet
<lool> xnox: Ok; he's backporting the package with just a rebuild and no source changes ATM
<lool> I'll try to suggest something smart to do
<lool> perhaps check which init /proc/1 actually is
<rbasak> lool, xnox: https://lists.ubuntu.com/archives/ubuntu-devel/2017-December/040100.html
<rbasak> It'd be worth making a list of these I think.
<rbasak> Basically it's fallout from the SRU regression.
<lool> ah right, remember that thread now
 * rbasak disappears again
<lool> rbasak: thanks!
<lool> deputy systemd is a bit of an evil mode   :-/
<lool> the jobs are all listed as failed etc
<lool> anyway, will go back to Ondrej to update certbot packaging
<xnox> lool, i recommending opening with "some trusty systems suffer from split personality disorder w.r.t. init system in charge, when snapd is also installed"
<lool> Yep, exactly
<xevious> rbasak: I found a solution (mentioned in the comment I just put on the ticket). Should I close it as "Invalid" or do you want to close it as "Won't fix"?
<xevious> I figure "Invalid" applies.
<xevious> It was effectively a support request, after I explored the issue further: I just needed to add an option to systemd-nspawn.
<xevious> System UIDs and GIDs are carefully managed by a Debian or Ubuntu team, right?
<xevious> E.G. the mysql UID and GID shouldn't have changed between mysql-server-5.7 5.7.20-1ubuntu1 and mysql-server-5.7 5.7.21-1ubuntu1, right?
<xevious> Looks like the new mysql-sever-5.7 package decremented them by 1: https://paste.ubuntu.com/p/WC8WrnwwfC/
<alkisg> aren't those randomly selected on postinst?
<mdeslaur> they're randomly assigned, yes
<mdeslaur> xevious: there's no expectation that it wouldn't change in two different installs
<xevious> I see. It's just 0-99 that are statically assigned.
<tsimonq2> rbasak, bdmurray: For the sake of not letting the process stall, how is my Qt 5 Uploaders app?
<rbasak> tsimonq2: I've not looked again yet, sorry. A bunch of Canonical people are sprinting next week, so it may not conclude until after that.
<tsimonq2> rbasak: ack, but it would be good to get responses from non-Canonical people then :)
<cjwatson> xevious: 0-99 and 60000-64999 (see https://www.debian.org/doc/debian-policy/#uid-and-gid-classes)
<xevious> cjwatson: Thanks! I also reviewed the Ubuntu Policy page about UIDs/GIDs. I'm surprised this hasn't gotten me sooner.
<cjwatson> I'm the base-passwd maintainer, so I kind of have to know this ;-)
<xevious> I'm adapting my imaging process to create the mysql user/group prior to installing it to ensure that it's always got the same UID/GID.
<cjwatson> (>15 years now; I should probably look for a co-maintainer at some point)
<xevious> Currently, mysql is refusing to start because all of the files in /var/lib/mysql are owned by epmd.
<cjwatson> Right, if you're dropping in files created on another system then you often need to make sure IDs are synced up.
<TJ-> Is the ubuntu-bugcontrol team no longer dealing with applications? I send a re-join message Nov 9th which I've had no reply to and checking the public archive don't see it, and don't see anything posted there since 22nd Jan. I've just re-sent my application and confirmed on my email server it was delivered (in case of an original delivery failure)
<andersk> Can someone request a rebuild of openafs?  It will work now that a flex regression has been fixed.  (LP #1752388)
<ubottu> Launchpad bug 1752388 in openafs (Ubuntu) "Retry bionic build of openafs 1.8.0~pre5-1" [Undecided,New] https://launchpad.net/bugs/1752388
<nacc> slangasek: trying to package a new lib and seeing the installed files end up in debian/tmp/usr/lib instead of debian/tmp/usr/lib/x86_64-linux-gnu -- what am i missing?
<nacc> (it's using pkg-config)
<slangasek> nacc: debhelper compat level?
#ubuntu-devel 2018-03-03
<slangasek> pkg-config itself doesn't dictate filesystem placement.  is it autoconf? cmake?
<nacc> slangasek: it's at 9, which i think should be fine?
<nacc> slangasek: simple (relatively) Makefile, no autoconf afaict
<nacc> i wonder if ineed to tell it libdir or something (rather than just prefix)
<nacc> slangasek: i can dig into it, np
<slangasek> no autoconf> yeah that'll be why
<slangasek> debhelper doesn't do automatic things with pure make because variable names aren't portable
<themill> BTW are you sure you want xchat in bionic?
<nacc> themill: already discussed
<nacc> slangasek: ack
<themill> ok
<Unit193> xnox: Sorry to ping.  Looks like you were indeed interested in that upload.  Now regarding src:dnsval that was removed in Debian in 2016, so bet it can go too.
#ubuntu-devel 2018-03-04
<slangasek> LocutusOfBorg: ok, autopkgtests passed on an --all-proposed retry, whee
<LocutusOfBorg> yes slangasek :) I'm planning to no-change rebuild again stuff now
<LocutusOfBorg> I don't want to be ever blamed because of a miscompilation due to a missing rebuild
<LocutusOfBorg> hopefully they will be sorted out in a matter of two hours, queues are empty, and autopkgtests too
<kuri0> How can I rebuild Ubuntu from source ?
<kuri0> such as for a new arch (ILP32)
<ikonia> you'd need to take the source packages and rebuild them against either a running toolchain on the arch you want or build a cross compiler/toolchain
<ikonia> it's not really the scope of this channel
<kuri0> ikonia, yeah but is there a better way than manually building everything
<kuri0> what do the ubuntu devs use ?
<ikonia> automated build jobs
<TJ-> kuri0: are you working with the Linaro or Debian toolchain?
<TJ-> kuri0: Linario have some useful information at https://wiki.linaro.org/Platform/arm64-ilp32
<ikonia> based on the fact that he's asking the same question in other channels about other distros I don't get the impression this is a serious situation
<kuri0> ikonia, i asked in #debian since ubuntu is based on debian and it might have a similar build process
<kuri0> TJ-, that link only says how to build the kernel
<kuri0> i could easily build a buildroot image though
<kuri0> which can be useful for testing
<TJ-> kuri0: at the end itÅ got links to prebuilt rootfs etc
<kuri0> TJ-, yeah but i want ubuntu
<kuri0> i could use that for testing thanks
<TJ-> You could use that as the base for then building Ubuntu packages
<kuri0> TJ-, so build apt and dpkg from source and then install stuff ?
<kuri0> i think that might be better done with buildroot
<kuri0> also i could create a custom debian repo with the packages built for ilp32
<kuri0> but i haven't found a way to automate building the packages
<kuri0> ill have to manually build them
<kuri0> ill write my own script to build the packages
<kuri0> because none seem to exist
<nacc> sunweaver: it synced but gosa-dev depends on php7.0-cli?
<nacc> sunweaver: hardcoded :/
<rindolf> Hi all! How can I help w the release of https://wiki.ubuntu.com/BionicBeaver ?
<ikonia> how do you think you can help ?
<sladen> rindolf: if you have a spare machine, doing some install testing would probably be a useful contribution
<rindolf> ikonia: by testing the prereleases
<rindolf> sladen: i have some VMs
<ikonia> ok, so download it and test it
<sladen> rindolf: if there isn't a spare machine, installing applications, and clicking around (probably things like the system settings) it check things work
<sladen> rindolf: main thing when finding a bug is to work out how to reproduce it reliably
<sladen> rindolf: which can often take quite a bit of guessing around
<rindolf> sladen: thanks
<sladen> rindolf: thank _you_  !!
<rindolf> sladen: you're welcome
<rindolf> sladen: installing 18.04 in a vbox vm now
<rindolf> it took a while for the installer screen to come up
<sunweaver> nacc: oh well...
<sunweaver> I can do another unstable upload.
<sunweaver> I'll do that anyway, as we don't want that in Debian, either.
<sunweaver> nacc: gosa-2.7.4+reloaded3-3 has just been dput to Debian unstable.
<sunweaver> with the php7.0-cli -> php-cli fix for gosa-dev.
<rindolf> sladen: the ubuntu 18.04 systen seems to work fine - i installed some stuff
<rindolf> sladen: no major complaints
<TJ-> With debhelper is there a way to run only the auto_configure target (including override_dh_auto_configure) ?
<nacc> sunweaver: thanks, i'll sync that shortly (i uploaded the same fi xto ubuntu)
#ubuntu-devel 2019-02-25
<LocutusOfBorg> infinity, since you asked me about the testsuite on marc-perl* sadness, I want to give you what I found
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/libmarc-charset-perl/1.35-2build1
<LocutusOfBorg> for some reasons, gdbm transition, broke the 32bit testsuite, and a no-change rebuild of marc-charset works, even if I don't really know why
<LocutusOfBorg> I'm not sure how worth investigating this is...
<LocutusOfBorg> ./usr-old/lib/libmarc-charset-perl/Table is just a different file in lots of places
<LocutusOfBorg> not even sure why britney let it migrate, probably some timing issue
<LocutusOfBorg> anyway, rebuilding should be ok now
<LocutusOfBorg> diffing a 5.4MB binary file is not that easy
 * LocutusOfBorg opens an RC bug in Debian
<LocutusOfBorg>  https://bugs.debian.org/923238
<ubottu> Debian bug 923238 in libmarc-charset-perl "libmarc-charset-perl: needs a rebuild on 32bit architectures?" [Serious,Open]
<slashd> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<bgmccollum> greetings...there seems to be a problem with the xenial netboot mini.iso. there is a segfault during detest disks, as libc6-udev failed for unknown reasons. this has been observed consistently in two different environments. my understanding is that the mini.iso may beed to be rebuilt to accommodate an updated libc6-udeb that is being fetched...
<CarlFK> bgmccollum: note: im not a dev - just a user.  do you have the URL to the mini iso handy?
<bgmccollum> CarlFK -- http://us.archive.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64/current/images/netboot/mini.iso
<bgmccollum> Just found this -- https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1816846
<ubottu> Launchpad bug 1816846 in glibc (Ubuntu) "segfault in libc-2.23.so netinstall installation pxe" [Undecided,Confirmed]
<CarlFK> bgmccollum: you have a pxe server right?
<bgmccollum> yes
<CarlFK> do you boot this file:  http://us.archive.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/linux
<bgmccollum> well, packer driven preseed, not PXE
<bgmccollum> sorry...i just boot the ISO
<bgmccollum> then packer edits the boot args and specifies a preseed
<bgmccollum> but if you just boot the ISO and step through the installer, it segfaults
<CarlFK> actually.. looking at that bug report:             ...             3 hours ago
<CarlFK> It seems it is being actively worked on, and is some dependency or publishing problems that will be worked out in at most a day or two
<CarlFK> what's packer ?
<bgmccollum> skimming the bug report
<bgmccollum> http://packer.io
<CarlFK> I skimmed too, then jumped to the bottom
<bgmccollum> i have a series of jenkins pipelines to build base images for use in openstack environments
<bgmccollum> the first pipeline uses back to do a base OS install
<bgmccollum> *user packer*
<CarlFK> from a quick skim, sounds like what I built: https://salsa.debian.org/carlfk-guest/ansible/blob/usb-reorg1/usbinst/mk_usb_installer.sh
<CarlFK> which uses hd-image instead of netboot: http://us.archive.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64/current/images/  hd-image or netboot
<bgmccollum> whats the difference between the two?
<CarlFK> https://salsa.debian.org/carlfk-guest/ansible/blob/usb-reorg1/docs/usb.rst#step-by-step-details
<CarlFK> hd-media fs can be mounted read/write
<bgmccollum> hence the name...hd-media...makes sense
<CarlFK> well, it had an iso9660? fs once.  and the fs isn't big enough to put the files it needs to work.
<CarlFK> which is being debated in my own bug report :p
<CarlFK> im going to run it for xenial and see what happenes
<tsimonq2> cyphermox, rbasak, et. al: earlier DMB meeting> bug 1817621 filed. I'm not sure what an edit-acl command would be, as I can't seem to find a case where permissions are set for an existing packageset and an existing team; teams like ~kubuntu-dev seem to have had their ACLs set prior to the usage of the ubuntu-community project for bugs.
<ubottu> bug 1817621 in ubuntu-community "[TB/DMB] Grant ~lubuntu-dev upload permissions to the lubuntu packageset" [Undecided,New] https://launchpad.net/bugs/1817621
<tsimonq2> The closest I can get is an edit-acl command done per-series, which I don't know is right for seed-based packageset upload permissions. I don't recall seeing edit-acl commands anywhere in the new release process.
<tsimonq2> My current theory after looking over docs is that when seed creation is done for a new release and packagesets are created from those, it's a copy-over process with ACLs. I also believe I'm going down a rabbit hole. :P
<bgmccollum> CarlFK i switched to using the mini.iso published to xenial-updates, and that seems to have done the trick.
<CarlFK> oh right.. -updates.. my favorite thing to rant about :p
<mwhudson> i don't at all understand why anna is trying to update libc
<bgmccollum> when "current" isn't current, cause you're in xenial, not xenial-updates :P
<CarlFK> yeah
<CarlFK> http://cdimage.ubuntu.com/releases/16.04.5/release/  Where is x86 or amd64 ?
<CarlFK> or where is ubuntu-16.04.4-server-amd64.iso
<CarlFK> http://old-releases.ubuntu.com/releases/16.04.4/ says "16.04.1" >:
<cyphermox> tsimonq2: the person who will make the changes should be able to figure it out :)
<tsimonq2> cyphermox: I guess so :)
<infinity> CarlFK: releases.ubuntu.com
<rbasak> tsimonq2: I believe you're right.
<rbasak> tsimonq2: but doesn't the ownership/adminship of ~lubuntu-dev need sorting first?
<rbasak> Sorry I didn't make the DMB meeting earlier. I was driving (a long way), and failed to send apologies in advance :-/
<CarlFK> infinity: I'm trying to find a pattern for -server.iso - like ubuntu-16.04.5-server-amd64.iso    and ubuntu-18.04.2-server-arm64.iso
<CarlFK>    http://releases.ubuntu.com/16.04.5 has it, but  http://releases.ubuntu.com/18.10/  has ubuntu-18.10-live-server-amd64.iso
<CarlFK> not -live is under http://cdimage.ubuntu.com/releases/18.04.2/release/
<tsimonq2> rbasak: The RT is filed, I'm waiting on a Launchpad admin.
#ubuntu-devel 2019-02-26
<RAOF> Aaargh. How do I convince Launchpad that my gpg key is not expired? keyserver.ubuntu.com sees my keys with an expiry of 2019-06-07!
<jamesh> RAOF: try pushing your key to keyserver.ubuntu.com?
<jamesh> oh.  It already has the up to date version
<RAOF> Yup! It's been up there for a number of weeks.
<jamesh> RAOF: are you able to remove and re-add the key?
<jamesh> I'm just wondering if it stops checking the key once it believes it is expired
<RAOF> jamesh: not on launchpad. I can deactivate, and then fall to reactivate because launchpad considers the key expired, though ð¤¦ââï¸
<RAOF> There's apparently an ongoing failure with key server replication.
<jamesh> My memory was that the gpg code in LP would always start by importing the key, so it shouldn't be a stale version of the key in a ~/.gnupg directory on the app server
<RAOF> popey https://bugs.launchpad.net/snapcraft/+bug/1817553 is the `nodejs` plugin failing to handle the simplified case of a single binary; if you can mangle the package.json you can work around it by turning it into the equivalent dictionary.
<ubottu> Launchpad bug 1817553 in Snapcraft "The plugin is not prepared to handle bin entries of type <class 'str'>" [Undecided,New]
<lesshaste> is it technically possible to boot off a USB stick (say) from a running linux install? This would be to save having to reboot through a BIOS you can't reconfigure for example
<SwedeMike> lesshaste: https://linux.die.net/man/8/kexec ?
<lesshaste> SwedeMike, that looks exactly it.. thank you
<lesshaste> SwedeMike, well it solves the problem of changing kernel.. Now I have to work out how to actually go through the whole boot process
<tomreyn> after a chromium-browser crash whoopsie states it cannot report it because "BFD: warning: /tmp/apport_core[..] is truncated" - the core file was indeed truncated. should ubuntu raise those limits in general if some RAM heavy apps are becoming more and more common?
<doko> oSoMoN: when do you plan the next lo upload for bionic?
<teward> anyone know why debuild and such can't verify my new PGP key that I'm using for things, even though I have the private key and such in my keyring...? o.O
<ahasenack> hi, any idea why the backuppc dep8 tests didn't run for trusty? http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html#backuppc
<seb128> teward, did you use -k<...> or change the default?
<ahasenack> this is an update that added them
<ahasenack> it worked in the xenial case (http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#backuppc)
<LocutusOfBorg> teward, ~/.devscripts ?
<teward> seb128: shouldn't it inherit DEBSIGN_KEYID from devscripts?
<teward> 'cause the key i'm signing with and it's prompting for my passcode for *is* the key i've stated in that in devscripts
<seb128> what error do you get?
<LocutusOfBorg> somewhere I exported also DEB_SIGN_KEYID
<teward> seb128: ahhh I see, it's when i dput and it tries to sig-verify it fails
<teward> but debuild works without issue and DOES sign with the key
<teward> *needs more coffee*
<teward> still interesting that dput won't verify the signature with the key that's in my keyring :|
<teward> or does it use a different keyring?
<teward> ahhh i see what happened
<teward> seb128: looks like when gpg created my new private and public key pair I'm using, it didn't set the local trust to 'ultimate'.  WHoopsies?
<teward> (verification errors have since ceased)
<oSoMoN> doko, can do today, shall I use bug #1814133 in the changelog ?
<ubottu> bug 1814133 in writer2latex (Ubuntu) "update to openjdk 11 in 18.04 LTS" [Undecided,New] https://launchpad.net/bugs/1814133
<doko> oSoMoN: sure
<doko> oSoMoN: I already prepared writer2latex
<oSoMoN> ok, I'll prepare an upload soon
<doko> oSoMoN: please let me know where I can find it. Need to build it against the security pocket
<CarlFK> what are the chances of 50MB being added to http://cdimage.ubuntu.com/ubuntu-server/daily/pending/disco-server-amd64.isoÂ Â 752M
<sladen> 50MB(?)(!)
<CarlFK> which will then bump into bug 1807047
<ubottu> bug 1807047 in debian-installer (Ubuntu) "sync hd-media FLOPPY_SIZE with debian" [Undecided,New] https://launchpad.net/bugs/1807047
<CarlFK> \wondering about translation strings or whatever isn't there now but was there for http://cdimage.ubuntu.com/ubuntu/releases/18.04/release/ubuntu-18.04.2-server-amd64.iso 883M
<bdmurray> jbicha: Why were these patches dropped in gnome-desktop3 for cosmic?
<oSoMoN> doko, https://people.canonical.com/~osomon/libreoffice-6.0.7/
<jbicha> bdmurray: because they were included in the new release
<bdmurray> jbicha: Got it, I can read now.
<doko> oSoMoN: ta, could you upload to ppa:openjdk-11-transition/apps
<oSoMoN> doing
<oSoMoN> dâoh, my uploads were rejected because they target the security pocketâ¦
<vorlon> xnox: do your comments on LP: #1815691 mean you believe the bug is invalid?
<ubottu> Launchpad bug 1815691 in ubiquity (Ubuntu Disco) "disk not detected on an Intel NUC7i5BNHXF" [Undecided,New] https://launchpad.net/bugs/1815691
<bdmurray> vorlon: There's no way for an ordinary user to see that kernel message so I think it should be surfaced better.
<vorlon> bdmurray: did making the firmware config change solve the problem for you?
<bdmurray> vorlon: I haven't tested that but guess I probably could w/o losing anything.
<vorlon> kees, stgraber, mdeslaur, infinity: TB meeting ping
<vorlon> bdmurray: if you now have timeouts in apport for gdb hangs, is there anything further to do on https://bugs.launchpad.net/apport/+bug/1760207 ?
<ubottu> Launchpad bug 1760207 in Apport "gdb sandbox can cause issues with gdb and glibc" [Medium,New]
<bdmurray> vorlon: No, I think I missed flipping it to Fix Released when updating the retracers.
<bdmurray> vorlon: although it'd still be best if apport were to install the libc6 version from the crash report as the gdb dep if the gdb dep is unversioned.
 * vorlon nods
<bdmurray> vorlon: I'll make that a separate bug though
<vorlon> ok
#ubuntu-devel 2019-02-27
<juliank> seems I messed up the livecd-rootfs change yesterday - no packages are marked as automatically installed by the minimize-manual script. Just uploaded a fix :)
<juliank> it was so obvious, ugh
<juliank> had to do s/continue/pass/
<juliank> infinity: turns out we can't really test the change either, as nothing seems to pull in ubiquity from a metapackage in disco, so its dependencies never get marked in the first place.
<doko> oSoMoN: I uploaded your packages, plus fonts-liberation2 for the security pocket (no-change upload)
<oSoMoN> doko, IÂ saw that, thanks! there was a suspicious amd64 build failure in the PPA (all other arches built fine), IÂ retried the build
<doko> oSoMoN: odk/CustomTarget_javadoc.mk:33: recipe for target '/<<PKGBUILDDIR>>/workdir/CustomTarget/odk/docs/java/ref/javadoc_log.txt' failed
<oSoMoN> doko, yes, that's the same error as last night, looking into it now
<doko> javadoc: error - The code being documented uses modules but the packages defined in http://java.sun.com/j2se/1.5/docs/api/ are in the unnamed module.
<doko> oSoMoN: looks like the missing javadoc backport that we already had for disco
<oSoMoN> doko, so https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/ff9d43e60d872a54a0982b3572e6f2085c09ddf5 should fix it, I'll add that patch and re-upload to the PPA
<doko> ta
<ahasenack> what's the trick again to use a variable like $ARCH in debian/<pkg>.install files?
<ahasenack> it was another debhelper iirc
<ahasenack> or should I just use * instead of the arch name?
<ahasenack> usr/lib/*/libpytalloc-util.cpython-37m-x86-64-linux-gnu.so.*
<ahasenack> dh-exec?
 * ahasenack looks for it
<ahasenack> #!/usr/bin/dh-exec
<ahasenack> usr/lib/*/pmdk_debug/libpmem.so.1* usr/lib/${DEB_HOST_MULTIARCH}/pmdk_dbg/
<ahasenack> dh-exec
<ahasenack> k
<infinity> juliank: ubiquity isn't pulled in via metapackage in *any* release.  If you're operating under the assumption that that's the cause of the bug, your assumption's wrong. :)
<juliank> infinity: well, there was some suggests or something from somewhere in a cycle or something
<juliank> I don't remember the analysis
<juliank> s/suggests/recommends/
<infinity> juliank: Not ubiquity itself.  It's the top level of that chain.
<juliank> infinity: The chain was xubuntu-desktop -> indicator-messages -> ubiquity-frontend-gtk (via provides inidicator-renderer) -> ubiquity -> cryptsetup & lvm
<juliank> some of those are recommends, some are depends
<juliank> oh, maybe I should ook at the xubuntu build log
<juliank> yeah, that one is visiting ubiquity, but that does not happen in ubuntu itself
<infinity> juliank: Ahh, kay.  The metapackage isn't what installed it, but it happened to provide something for somehting in the meta's chain.  Check.
<juliank> yup
<ahasenack> doko: ok, now I hit the problem you brought up in samba-technical@
<ahasenack> doko: do you have a link to the fedora packaging which has the patches?
<doko> https://src.fedoraproject.org/rpms/samba/blob/master/f/samba.spec
<doko> ahasenack: https://src.fedoraproject.org/  but as I wrote, they don't have the patches. the one rh guy pointed to the old patch
<ahasenack> yeah, just cloned, no patches
<ahasenack> doko: without those patches, do we have a way out of this?
<ahasenack> something like a symbol file per arch, if that is even enough to fix it?
<doko> dh-exec?
<doko> yes, per arch should work as well
<ahasenack> no, the symbols having the architecture
<ahasenack> or did you mean a dh-exec trick for the symbols file?
<doko> (arch=amd64)<symbol>
<doko> no, dh-exec doesn't work with symbols files
<ahasenack> doko: so I would include symbols for all arches in the symbols file, but prefix them with (arch=<arch>)? or what is the trick?
<ahasenack> do we have something like this already in the archive somewhere?
<doko> libffi.so.7 libffi7 #MINVER#
<doko>  (symver)LIBFFI_BASE_7.0 3.3~20180313
<doko>  (symver)LIBFFI_CLOSURE_7.0 3.3~20180313
<doko>  (symver|arch=!hppa !ia64 !m68k !riscv64 !sh4)LIBFFI_GO_CLOSURE_7.0 3.3~20180313
<doko>  (symver|arch=!hppa !ia64 !m68k !mips !mipsel !mips64el !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !sh4)LIBFFI_COMPLEX_7.0 3.3~20180313
<doko>  (symver)LIBFFI_BASE_7.1 3.3~20180313
<ahasenack> doko: I wonder if the #include trick could help. From the manpage:
<ahasenack>             (arch=amd64 ia64 alpha)#include "package.symbols.64bit"
<ahasenack> although
<ahasenack> looks like it's just one
<ahasenack> hm
<doko> yes, would just use six lines for that one symbol
<ahasenack> what about the first line of the symbols file, which is the library name? It has $arch in its name
<doko> argh
<ahasenack> specifically
<ahasenack> libpytalloc-util.cpython-37m-x86-64-linux-gnu.so.2 python3-talloc #MINVER#
<ahasenack>  PYTALLOC_UTIL.CPYTHON_37M_X86_64_LINUX_GNU_2.1.16@PYTALLOC_UTIL.CPYTHON_37M_X86_64_LINUX_GNU_2.1.16 2.1.16
<doko> so, just six separate symbols files
<ahasenack> do we need some sort of foo.symbols.in file and render that?
<doko> like the current libffi is doing that
<doko> have to run now ...
<ahasenack> ok, thanks, I'll look at libffi
<ahasenack> cya
<ahasenack> doko: 23 symbols files, that ought to be fun :)
<ahasenack> doko: got it done for talloc, using per-arch symbols files, and an #include directive to keep it less repetitive, seems fine
<ahasenack> thanks for the tip
<ahasenack> like https://git.launchpad.net/~ahasenack/ubuntu/+source/talloc/tree/debian/python3-talloc.symbols.amd64?h=disco-talloc-2.1.16
<doko> ahasenack: yeah, but upstream is insane, and doesn't listen ...
<ahasenack> the guy from fedora seems aboard
<ahasenack> not upstream, but if two (three) big distros push for it, we might get it
<seb128> vorlon, oh, you also mentioned curl on the desktop iso yesterday, it looks like it's due to gettext which Recommends curl | wget, if we prefer wget we should have it listed first
<vorlon> seb128: well, wget should have been pulled in already earlier due to it being in standard; so it might be we should do some seed surgery rather than adding a delta on gettext
<seb128> vorlon, right, unsure what's the best way there
#ubuntu-devel 2019-02-28
<doko> RAOF: libmiral-dev/amd64 unsatisfiable Depends: libmirclient-dev (= 2.4.0.1.1.1-0ubuntu2)  did you test-install that? ;p
<doko> coreycb, jamespage: swift & Python3 ping
<RAOF> doko: argh! Did I upload that version? ð
<RAOF> Tomorrow, tomorrow.
<RAOF> Maybe launchpad will notice my gog key isn't expired tomorrow...
<RAOF> That's what you get for trying to fix lintian errors in... interesting packaging.
<seb128> RAOF, hey, do you need some sponsoring?
<RAOF> seb128: thanks, but I'll just generate a temporary key until I resolve whatever's going wrong.
<seb128> k
<RAOF> Hopefully I'll be less jetlagged tomorrow (!)
<doko> RAOF: uploaded
<RAOF> doko: um, *what's* uploaded? The (hopefully) obvious fix?
<doko> RAOF: http://launchpadlibrarian.net/413134775/mir_1.1.1-0ubuntu2_1.1.1-0ubuntu3.diff.gz
<RAOF> doko: ta
<doko> oSoMoN: LO autopkg tests are not happy in disco with new openjdk 11.0.3 :-/
<oSoMoN> doko, it would be interesting to see the results when run against 1:6.2.1~rc1-0ubuntu3 (in disco-proposed atm, blocked by the glibc migration)
<juliank> ugh, flashes of email notifications. testing current xubuntu daily now to see if the livecd-rootfs fixes worked and we don't break encrypted installs anymore :)
<juliank> and it does not boot
<juliank> but lvm2 and cryptsetup are manual and autoremove returns nothing, so we're all good
<juliank> My code is bad, though
<doko> oSoMoN: persists
<LocutusOfBorg> coreycb, do you think this: https://salsa.debian.org/python-team/modules/python-jmespath/commit/414bcc4154c73716e437e6bb9ae1d5487a3fdeac and this: https://launchpadlibrarian.net/357052308/python-jmespath_0.9.3-1_0.9.3-1ubuntu1.diff.gz can be considered equivalent?
<coreycb> doko: sorry i didn't ignore you earlier i just thought you were going to have a question after that
<coreycb> LocutusOfBorg: yes that's the same
<LocutusOfBorg> can I sync?
<coreycb> LocutusOfBorg: yes please, assuming the latter is the only diff
<coreycb> thank you
<doko> coreycb: I assume you are at the sprint. is swift for Python3 on your agenda?
<LocutusOfBorg> coreycb, the diff looks like python3.7 compatibility fixes https://salsa.debian.org/python-team/modules/python-jmespath/commit/e08c8d51f8d39448b62c4e5293481489d6c5a090
<coreycb> doko: i believe we're in a holding pattern on that until the May sprint. we discussed with xnox recently and our understanding is that python 2.7 won't move to universe until 19.10
<coreycb> if upstream doesn't do anything we will likely handle it ourselves next cycle
<doko> ok, good to know
<superm1> Hi, I just wanted to make sure bug 1814997 is on someone on the security team's radar.  it's going to block gnome-software, fwupd and fwupd-signed migration in disco
<ubottu> bug 1814997 in libxmlb (Ubuntu) "[MIR] libxmlb" [Undecided,Triaged] https://launchpad.net/bugs/1814997
<superm1> robert_ancell: ^
<robert_ancell> yep
<chiluk> thanks for sru approval bdmurray++ I'll validate it this weekend.
#ubuntu-devel 2019-03-01
<jbicha> juliank: what about pushing your packagekit patch to Debian? If not, could you at least merge packagekit for a crash fix?
<juliank> jbicha: merged
<juliank> But yes, should send patch upstream
<seb128> juliank, thx
<acheronuk> O_o packagekit FTBFS
<juliank> acheronuk: seems build deps cannot be resolved
<juliank> gotta wait a bit I guess
<juliank>  sbuild-build-depends-packagekit-dummy : Depends: docbook-utils but it is not going to be installed
<juliank> I'll be trying something new and keep status logs for march in https://wiki.ubuntu.com/JulianAndresKlode/Status/1903, so you can get a sneak peak of what there will be from me in #ubuntu-meeting on the foundations meeting
<seb128> juliank, did you want to maybe SRU https://github.com/hughsie/PackageKit/pull/306 ?
<seb128> that segfault would be nice to see fixed in the lts
<juliank> seb128: oh I guess that's the 3 bugs I was looking at this morning
<seb128> right
<seb128> which is the fix you just merged :p
<juliank> seb128: I'd like to see this fixed, but I'm unsure how to test it
<seb128> juliank, my usual testcase for those are "check that e.u.c get no reports of the issue for that version & make sure things keep working" which is often good enough for the SRU team
<seb128> especially in case like tis where the the fix is an obvious one liner
<juliank> seb128: ack
<seb128> juliank, thx
<LocutusOfBorg> klebers, LP: 1818049 do you need help, sponsors?
<ubottu> Launchpad bug 1818049 in virtualbox-hwe (Ubuntu Xenial) "virtualbox dkms modules fail to build with linux 4.4.0-143.169 [error: too many arguments to function âget_user_pagesâ]" [Undecided,New] https://launchpad.net/bugs/1818049
<seb128> vorlon, hey, I'm not sure how often foundations look at rls-dd-incoming bugs so I'm mentioned that here in case it's more appropriate, bug #1818285 is blocking desktop isos to be moved from pending to current (we forced one this week though because the current was quite outdated)
<ubottu> bug 1818285 in partman-base (Ubuntu) "[disco desktop] preseeded installation fails with parted_server: No data in infifo. parted_server: Line 2387. CRITICAL ERROR!!! EXITING." [Undecided,New] https://launchpad.net/bugs/1818285
<vorlon> seb128: ack, I imagine bdmurray might have triaged it at some point soon, but let's do so directly now, thanks
<seb128> vorlon, thx
<vorlon> seb128: LP: #1814341> ouch, so fwupd included handling of a device from a 3rd-party vendor that lied and used Microsoft USB IDs? D:
<ubottu> Launchpad bug 1814341 in fwupd (Ubuntu) "Xbox 360 controller doesn't work in Ubuntu 18.10 anymore" [High,Fix released] https://launchpad.net/bugs/1814341
<vorlon> seb128: btw you'll also need an upload of fwupd-signed to go with this, I don't currently see one in the queue
<seb128> vorlon, looks like so. Ah, thanks for pointing that out, I'm not familiar with fwupd ... is there anything special to do for -signed?
<vorlon> seb128: the -signed packages are roughly no-change rebuilds, but you may have to manually twiddle versioned build-deps in debian/control and such
<seb128> k, I see, taking http://launchpadlibrarian.net/387738423/fwupd-signed_1.1_1.2.diff.gz as an exampke
<seb128> vorlon, I do that now
<seb128> vorlon, uploaded
#ubuntu-devel 2020-02-24
<mwhudson> uhh
<mwhudson> is ssh-import-id just broken on focal?
<mwhudson> mwhudson@anduril:~$ ssh-import-id lp:mwhudson
<mwhudson> 2020-02-24 13:36:25,093 ERROR module 'platform' has no attribute 'dist'
<mwhudson> looks like a python 3.8 thing
<cjwatson> Easy fix is to port it to the distro module
<cjwatson> (Not in the standard library, but it's more or less a drop-in replacement)
<cjwatson> https://pypi.org/project/distro/
<mwhudson> ah https://bugs.launchpad.net/ubuntu/+source/ssh-import-id/+bug/1864107
<ubottu> Launchpad bug 1864107 in ssh-import-id (Ubuntu) "ssh-import-id broken on Focal" [High,In progress]
<mwhudson> and https://code.launchpad.net/~waveform/ssh-import-id/+git/ssh-import-id/+merge/379351
<mwhudson> now where was i in this mountain of yaks
<cpaelzer> vorlon: doko: I see you have restarted tests related to the new procps upload that is breaking postgresl-common autopkgtests - is there an analysis/bug for that already?
<cpaelzer> vorlon: was bug 1864424 intentional to bring in mouse=a for 20.04?
<ubottu> bug 1864424 in vim (Ubuntu) "new vim version in 20.04 sets mouse=a by default" [Undecided,New] https://launchpad.net/bugs/1864424
<ackk> hi, is it expected for focal not to have the nice boot screen & password prompt for encrypted volumes yet?
<mwhudson> ackk: works for me
<mwhudson> ackk: or to more directly ask, no i don't think that is expected
<ackk> mwhudson, did you upgade or run a fresh install?
<mwhudson> ackk: upgrade
<ackk> ok, mine was a fresh install. it also seems it takes a looong time until the password prompt, and then until gdm login
<ackk> also, after install, I didn't have any snap installed nor I could install them
<ackk> snap reports that the system is not yet seeded
<mwhudson> ah now that sounds like a reported bug
<ackk> mwhudson, FWIW even during the boot of the installer I didn't get the nice spash screen
<ackk> I only had a purple text screen with an off-centered "Ubuntu 20.04" text
<ackk> mwhudson, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1864230 maybe?
<ubottu> Launchpad bug 1864230 in snapd (Ubuntu) "error: too early for operation, device not yet seeded or device model not acknowledged" [Undecided,New]
<mwhudson> ackk: yeah
<mwhudson> ackk: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1864252 might be the fix?
<ubottu> Launchpad bug 1864252 in livecd-rootfs (Ubuntu) "preseeded snap installs fail in images" [Undecided,Confirmed]
<ackk> mwhudson, ah, nice
<mwhudson> ackk: cat /var/log/installer/media-info?
<ackk> mwhudson, Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200220)
<mwhudson> ackk: so before that livecd-rootfs fix landed
<ackk> mwhudson, do I need to reinstall?
<mwhudson> ackk: hm, don't know
<mwhudson> ackk: you can probably fix it by messing around in /var/lib/snapd and rebooting
<mwhudson> ackk: but reinstalling is probably easier...
<mwhudson> ackk: you could ask #snappy about the seeding issues
<ackk> mwhudson, thanks
<mwhudson> ackk: seems Laney has found some problems with the fix, but things are in progress at least
<Laney> :'(
<doko> cpaelzer: no analysis done yet
<doko> oSoMoN: marcustomlinson: could you have a look at the lo arm64 autopkg test failure?
<marcustomlinson> doko: If I donât get to it Iâll let hellsworth know
<cpaelzer> doko: vorlon: ok I have started in https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1864423
<ubottu> Launchpad bug 1864423 in procps (Ubuntu) "Failed test 'default log is not used' with new procps 3.3.16-1" [Undecided,New]
<doko> cjwatson: openssh gained some new dependencies on universe packages. do we need to promote those, or should we build without those?
<cjwatson> doko: we should really MIR and promote libfido2 - the new version of openssh uses it for U2F (universal second-factor token) support, which is the headline feature in openssh 8.2 and I want it in focal
<cjwatson> doko: (ref. https://www.openssh.com/txt/release-8.2 under "Changes since OpenSSH 8.1")
<cjwatson> I think we'll also need to add libfido2 to the i386 whitelist
<doko> cjwatson: that includes libcbor and mathjax
<doko> filing a MIR
<cjwatson> Thanks
<cjwatson> doko: Wait, why mathjax?
<doko> cjwatson: libcbor-doc depends on it. so we should blacklist that one
<cjwatson> doko: Might be simplest
<ahasenack> Skuggen: hi, mysql8 question
<ahasenack> Skuggen: password() was removed/deprecated, right
<ahasenack> Skuggen: I'm looking at a patch where someone changed password("%s") to
<ahasenack> CONCAT('*',UPPER(SHA1(UNHEX(SHA1('%s')))))
<ahasenack> is that the right thing to do?
<ahasenack> rbasak: if you have seen that before^
<rbasak> I've not seen that before
<rbasak> Looks like someone is constructing their own KDF
<rbasak> (badly)
<ahasenack> we might be better off going with a new upstream release for this one
<ahasenack> ahead of debian
<ahasenack> the new release works with mysql8 (allegedly)
<ahasenack> and doesn't do this with the password
<ahasenack> hm, the new version pulled in a lot of crypto/hash functions
<ahasenack> is doing the hash client side and then comparing
<Skuggen> Yeah, that looks kind of horrible :)
<ahasenack> Skuggen: suggestions? :)
<Skuggen> Which package is this?
<ahasenack> zoneminder
<ahasenack> that change came from an attached patch, to the bug
<ahasenack> Skuggen: this bug: https://bugs.launchpad.net/ubuntu/+source/zoneminder/+bug/1859295working
<ubottu> Launchpad bug 1859295 in zoneminder (Ubuntu) "zoneminder 1.32.3-2build1 does not work with MySQL 8" [Undecided,New]
<ahasenack> the other changes are basically quoting new reserved keywords in mysql8
<ahasenack> like Groups, Function
<ahasenack> and match what upstream did
<Skuggen> Right
<Skuggen> I don't really understand what it's doing, but is that meant to work with mysql_native_password, or caching_sha2_password?
<ahasenack> I'm not sure either, it looks like it has its own user db, and is doing a simple string comparison to authenticate someone
<ahasenack> or find someone in the db
<ahasenack> the new upstream code does just this query in the beginning:
<ahasenack>       "SELECT `Id`, `Username`, `Password`, `Enabled`, `Stream`+0, `Events`+0, `Control`+0, `Monitors`+0, `System`+0, `MonitorIds`"
<ahasenack>       " FROM `Users` WHERE `Username` = '%s' AND `Enabled` = 1", safer_username);
<ahasenack> (it dropped Password = )
<Skuggen> There's some functionality for setting password there, which should probably just be replaced with the standard user management
<ahasenack> but does this new thing later:
<ahasenack>   if ( verifyPassword(username, password, user->getPassword()) ) {
<ahasenack> and that verifyPassword() function does the hashing now
<ahasenack> manipulating SHA_CTX and whatnot via openssl
<ahasenack> with checks like
<ahasenack>   if ( db_password_hash[0] == '*' ) {
<ahasenack>     // MYSQL PASSWORD
<ahasenack> ....
<ahasenack> funny that they *moved* to SHA1
<Skuggen> Where is the code for creating users?
<Skuggen> Maybe they set them to use mysql_native_password
<ahasenack> don't know yet, https://github.com/ZoneMinder/zoneminder/tree/master/src is what I'm looking at, but that's the new upstream version
<Skuggen> Yeah, I'm looking there too
<ahasenack> current code in focal (well, my branch on top of focal) is https://code.launchpad.net/~ahasenack/ubuntu/+source/zoneminder/+git/zoneminder/+ref/focal-zoneminder-mysql8
<Skuggen> But it doesn't really seem like upstream's code is less hacky about this than that patch :)
<Skuggen> It's just that it doesn't seem to me it should work if the users are set to caching_sha2
<ahasenack> https://github.com/ZoneMinder/zoneminder/tree/1.32.3/src is what is in focal
<ahasenack> based on tag and version number, that is
<Skuggen> Oh, wait!
<Skuggen> I've misunderstood completely. These aren't mysql users :P
<ahasenack> no
<ahasenack> its their own, and they just happened to use mysql's password() function for convenience is my guess
<Skuggen> Yeah
<Skuggen> It's just that the password() function was a sha1 function
<Skuggen> So it's "fine".
<ahasenack> so they do a query for where user=foo, pass=bar, and if that query fails, say that authentication failed
<rbasak> If it was, then perhaps it's no loss to reimplement as the replacement that ahasenack originally suggested?
<rbasak> Even if that is bad, that is what they were doing before
<Skuggen> Yeah
<ahasenack> ok
<rbasak> Meanwhile, clickhouse is taking forever to build :-(
<ahasenack> rbasak: yeah, last good build was recorded at 1h in LP
<ahasenack> rbasak: did you look at that removal bug? Just in case this is a waste of time (trying to get it to build)
<Skuggen> One possible concern for ZM is the way the hashing is done, though; Is it correct, i.e. as secure as it was before?
<rbasak> ahasenack: it looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950983 is the same issue and proposes a trivial patch, so I'm trying that
<ubottu> Debian bug 950983 in src:clickhouse "clickhouse FTBFS in bullseye/sid" [Serious,Open]
<rbasak> Reproducing the failure first though
<rbasak> (locally)
<rbasak> Skuggen: if it's wrong, hashes will mismatch and nobody will be able to log in
<rbasak> (until individual passwords are reset)
<rbasak> Who wrote that replacement?
<ahasenack> rbasak: https://bugs.launchpad.net/ubuntu/+source/zoneminder/+bug/1859295/comments/1 the person who opened the bug
<ubottu> Launchpad bug 1859295 in zoneminder (Ubuntu) "zoneminder 1.32.3-2build1 does not work with MySQL 8" [Undecided,New]
<ahasenack> https://launchpad.net/~joe-yasi
<Skuggen> Maybe ask if he's tested with an upgrade scenario?
<ahasenack> I think I'll upload the ftbfs fix first
<ahasenack> I thought tackling this runtime bug would be quicker (as I was just seeing those quoting changes), but then I stumbled on this
<Skuggen> Hehe
<vorlon> cpaelzer: mouse=a> no; there was a change upstream of us that I thought I saw had made the mouse=a behavior conditional on OS, but apparently I misread. I'll restore the patch
<cpaelzer> thanks vorlon
<cpaelzer> in that case I'm glad I filed the bug and asked about it
<vorlon> ah maybe I was led astray by "can be reverse-applied" :P
<vorlon> but reverse-applying a deletion, well..
<vorlon> cpaelzer: ah new procps is breaking it because the new Debian version is setting fs.protected_regular=2 (debian/protect-links.conf)
<vorlon> cpaelzer: so this is related to https://lists.ubuntu.com/archives/ubuntu-devel/2020-February/040904.html etc
<cpaelzer> vorlon: is that what you get out of the debug into I put into the postgresql-common bug?
<vorlon> yes
<cpaelzer> oh I have read that thread, but not mapped the two into one
<vorlon> systemd was setting fs.protected_regular=1, and that caused some problems
<vorlon> procps is setting f.sprotected_regular=2, which causes more problems
<vorlon> kees: ^^ hey there's your =2
<vorlon> so, changing postgresql-common is for the good to make it more portable; but we may want to revert this procps change
<cpaelzer> ack
<rbasak> xnox: o/ are you working on the new clickhouse FTBFS?
<rcj> Could I get a sponsor to upload livecd-rootfs for the MPs in bug #1864252 ?
<ubottu> bug 1864252 in livecd-rootfs (Ubuntu) "preseeded snap installs fail in images" [Undecided,Confirmed] https://launchpad.net/bugs/1864252
<rcj> Eoan builds are blocked on this bug
<rbasak> PSA: the DMB election has closed and the results are available directly from CIVS. I am clearing up a minor administrative matter before I send the announcement, so it may not be today.
<rbasak> teward: FYI ^
<teward> thanks rbasak
<rbasak> We do have a DMB meeting scheduled today
<rbasak> I'm not sure who is in the DMB currently!
<Laney> only 31% turnout? :(
<Laney> but well done to the (eventual) new members :>
<teward> yeah i noticed that too :P
<teward> rbasak: i just took a look at the agenda it doesn't look like there's any pressing matters that need attention today from the DMB just the regular holdovers.
<teward> so given that it might just be prudent to skip the meeting today
<ahasenack> xnox: hi, your clickhouse upload is failing to build on arm64 and s390x, and I see you included a fix for https://bugs.launchpad.net/ubuntu/+source/clickhouse/+bug/1863026
<ubottu> Launchpad bug 1863026 in zoneminder (Ubuntu) "Remove my_bool typedef workaround" [Undecided,In progress]
<rbasak> teward: that might be a good idea.
<teward> rbasak: there is something that needs attention on the 9th but that's not today's meeting so :P
<ahasenack> xnox: I marked the clickhouse task in that bug I linked as "fix committed"
<ricotz> ahasenack, hi, I assume this needs a i386 exception https://launchpad.net/ubuntu/+source/bind9-libs/1:9.11.16+dfsg-3~build1
<ahasenack> ricotz: indeed, since bind9 had it
<xnox> rbasak:  ahasenack: in theory, yes, in practice i'm not sure what the test regressions on arm64/s390x are yet. I did fix the failure to build, it *just* now fails to pass compile time test
<ahasenack> rbasak: Skuggen: https://pastebin.ubuntu.com/p/b2yw9hv28p/
<ahasenack> rbasak: Skuggen: output is always the same (this is mysql 5.7)
<ahasenack> I checked 5.7's source, and that's exactly what PASSWORD() did back then
<ahasenack> double sha1(), display as hex
<ahasenack> no salt, nothing else
<rbasak> Looks good!
<Skuggen> Yup
<bryce> xnox, although php7.4 is still in proposed due to icu, I'd like to go ahead and kick off the php 7.4 transition today by uploading the new php-defaults, if that won't cause any troubles for you with the icu transition?
<xnox> bryce:  well arm64 instances fail to boot at the moment, thus icu is stuck behind libreoffice
<bryce> xnox, yeah it sounds like you may need some time for getting icu sorted.  I want to get php at least started before FF, but only if it won't impact your work negatively.  I don't think it will but wanted to doublecheck with you first.
<xnox> bryce:  ah.... you are not on #ubuntu-release
<xnox> bryce:  vorlon might try to make icu transition regardless libreoffice.
<bryce> xnox, ok so you'd advise to hold off for now?
<xnox> bryce:  "<vorlon>	and no we shouldn't be uploading any packages currently tangled in icu for the php transition until icu is done"
<xnox> bryce:  please don't upload php-defaults just yet
<bryce> xnox, alright, thanks
<xnox> bryce:  also join #ubuntu-release for transitions coordination
<xnox> with the release team
<vorlon> no
<vorlon> php-defaults is not dependent on icu
<vorlon> and he can upload that just fine
<vorlon> (as I said on Friday)
<vorlon> but things currently in -proposed which depend on icu should not be reuploaded for new php until after icu migrates
<bryce> I think only php7.4 itself is dependent on icu (it's the only package I've noticed this so far, anyway).  I wasn't needing to alter php7.4 though, and it's fine if the remaining php bits stay in proposed as a result, until icu is migrated.
<vorlon> bryce: ^^
<vorlon> right
<vorlon> so, since bryce has already coordinated with the release team on this... :)
<bryce> vorlon, xnox, thanks.
<xnox> ah, ok, now i understand what you mean
<mwhudson> good morning
<sarnold> welcome back mwhudson :)
<bdmurray> Does anybody know if there is a bug report about my T450s keyboard light keeps turning on?
<CarlFK> Feb 24 23:05:25 main-menu[367]: (process:3286): dpkg-divert: warning: diverting file '/sbin/start-stop-daemon' from an Essential package with rename is dangerous, use --no-rename  http://paste.ubuntu.com/p/GYF4sbXDkJ/
<CarlFK> pxe + preseed.cfg di/key/value file from bionic.
#ubuntu-devel 2020-02-25
<seb128> vorlon, hey, I probably already asked that, but is there a manual process for adding source to build on i386? gedit picked up some new depends, amtk & tepl ... will those be pulled on the whitelist automagically by depends chain or is there any manual work involved?
<seb128> vorlon, other i386 question, libsoup2.4 fails to build now due apache/php i386 installability problem, is that a known issue?
<seb128> vorlon, oh and mozjs68 is about to replace mozjs60 for GNOME so we also need to get it built on i386, again unsure if I should do some manual work or if that's going to automatically happen due to depends?
<Laney> seb128: Just saw your i386 comments. For bootstrapping you need to add them to the code of update-i386-whitelist in lp:ubuntu-archive-tools, re-run that to update the packageset, get the build record re-created (copy the package over itself), and then once the leaf package has picked up the dependencies on i386 germinate should keep it in the seed after that, so it can be dropped from that script.
<seb128> Laney, thx
<seb128> Laney, vorlon, is that process documented somewhere?
<seb128> I'm probably not the only one who is going to hit that kind of question
<Laney> dunno
<Laney> is there a place for archive admin docs?
<seb128> Laney, https://wiki.ubuntu.com/ArchiveAdministration
<Laney> looks like a good place
<seb128> vorlon, could you write a i386/whitelist on there ^?
<seb128> +section
<rbasak> !dmb-ping is tsimonq2, rafaeldtinoco, slashd, teward, sil2100, ddstreet, rbasak: DMB ping
<JackFrost> !no dmb-ping is <reply> ddstreet, rafaeldtinoco, rbasak, sil2100, slashd, teward, tsimonq2: DMB ping
<ubottu> I'll remember that JackFrost
<Laney> sounds threatening
<rbasak> JackFrost: thanks. Was my command correct? It's from our checklist.
<JackFrost> rbasak: It's close enough, you have to be an editor in order to edit factoids too though.
<rbasak> Thanks - yeah I had a private message back saying it was being moderated
<Sharcho> FYI: On the Ubuntu 20.04 docker image, command-not-found is not working: /usr/lib/cnf-update-db , KeyError: 'suite'
<cpaelzer> if a package needs root for the build time tests triggered by dh_auto_test what would be the best way to provide it that?
<cjwatson> Fake it somehow or move them to autopkgtest
<cjwatson> You can't have root in dh_auto_test
<cjwatson> (real root that is)
<cjwatson> Maybe fakeroot would do though?
<cpaelzer> I need to check if I can fake it, it seems most parts work already ~140 of 160 tests
<cpaelzer> what fails right now is that it wants to read /boot/vmlinuz-...
<cpaelzer> which is "-rw------- 1 root root"
<cjwatson> In that case your choices are to install some kind of mock version (if appropriate/possible), to disable those particular tests, or to run the test suite in autopkgtest instead
<cjwatson> Or some combination
<cpaelzer> yeah, I guess I skip them and move to autopkgtest
<cpaelzer> cjwatson: might I ask - is that different in Debian? as there the test works
<cjwatson> No
<cjwatson> Something else must be different
<cjwatson> Probably /boot/vmlinuz-* is readable in Debian's kernel packages
<cpaelzer> checking ...
<cjwatson> I vaguely remember that's something Kees got changed in Ubuntu because it impeded automatic operation of some rootkits (even though the actual contents of the kernel image are of course public knowledge)
<cpaelzer> yep - -rw-r--r--
<cpaelzer> ok, now things fit together and on that I can at least add my changes "knowing why"
<cpaelzer> thanks cjwatson
<vorlon> seb128: I wasn't aware of the libsoup2.4/apache issue, no
<vorlon> seb128: re: docs, sure but I'm not sure when I'll get to it
<seb128> vorlon, hey, k, I will try to poke at it
<k_alam> Hi, can anyone here restart building of netboot image for focal ? It is not there in cdimage...
<k_alam> http://cdimage.ubuntu.com/netboot/focal returns error
<seb128> vorlon, do you know how close we are from icu migrating? we started some other transitions (poppler/gnome-desktop) which have some common package, we didn't rebuild those yet since I think it's better to wait for icu to migrate first before risking complicating things
<vorlon> seb128: it is better to wait, thanks.  I don't know exactly how close it is, I would've hoped it to migrate today during Europe's day.  xnox are you working on this today?
<vorlon> seb128: I am going to be working on it today and I think the only remaining blockers are all test failures that need to be worked through
<seb128> vorlon, k, anything desktopish/we could help with?
<vorlon> seb128: find packages in update_excuses that are listed as depending on icu and not candidates due to autopkgtest failures, and help resolve those
<vorlon> looks like rdkit/s390x still needs resolved, I'll do that now
<seb128> vorlon, ack
<rbasak> vorlon: previously some TB members have had the developer-membership-board@ admin password.
<rbasak> vorlon: what do you think I should ask IS to do? Reset it and give it to you?
<vorlon> rbasak: I was going to say you should have them update the list membership
<vorlon> I dunno, stgraber might have the password
<vorlon> but the list management stuff is pretty lame overall in terms of credentials sharing, so I'd rather just make it IS's problem ;)
<Laney> Previously the TB and the DMB both had the password
<Laney> I guess it's good practice to rotate it when either group's membership changes ...
<stgraber> I may still have it in my listadmin config
<rbasak> I have the moderator password
<rbasak> But I can't admin from there AFAICT.
<ahasenack> hi, which package should I use for a bug report about notifications?
<ahasenack> just "mutter", and let them reassign as needed?
<Laney> I have *a* password too
<Laney> gnome-shell
<ahasenack> thanks
<Laney> ideally report upstream too :-)
<stgraber> Found a password
<rbasak> It works
<rbasak> I might as well just make the changes
<rbasak> And then someone can tell me who should have it later, and I can do that.
<xnox> vorlon:  rdkit needs rebuild hit
<vorlon> xnox: it did.  it's been done
<xnox> vorlon:  i was waiting for pandas removal to be published
<xnox> vorlon:  from my point of view icu is done; if you want me to fix anything else let me know.
<xnox> vorlon:  i was working on completing ocaml
<vorlon> xnox: it's not done until it's in the release pocket
<xnox> vorlon:  it's a valid candidate.... or are you expecting me to fix all of nodejs & R too?
<vorlon> xnox: you said you were managing the *transition*.  It's not done until all the reverse-dependencies can go through together
<vorlon> xnox: r-base has two autopkgtest failures blocking it, I don't see that anyone has checked yet if those are present in the release pocket (I've done this now)
<xnox> vorlon:  i didn't start icu. Somebody accepted icu NEW without coordination. I only stepped in to clean up fallouts when it was half way through.
<xnox> vorlon:  when i saw icu in NEW i asked AA to reject it, to avoid it entagling with everything. And instead AA accepted it.
<xnox> hence we are here now.
<mwhudson> oh huh go 1.14 release
<JackFrost> And already in Debian.
#ubuntu-devel 2020-02-26
<cpaelzer> rafaeldtinoco: FYI for kronosnet (which somewhat belongs to corosync) and is failing on i386 => https://code.launchpad.net/~paelzer/britney/hints-ubuntu-focal-kronosnet-i386/+merge/379877
<cpaelzer> the commit message hopefully explains all the details
<cpaelzer> so far I've seen you and vorlon retrying this test since the i386 switch
<cpaelzer> at http://autopkgtest.ubuntu.com/packages/k/kronosnet/focal/i386 and since then it was part of the whitelist (but versioned to the former version)
<cpaelzer> thanks LocutusOfBorg for the massive set of test triggers around llvm-8 - that will unblock a bunch of stuff
<LocutusOfBorg> cpaelzer, I hope it will make something migrate :D
<LocutusOfBorg> e.g. having ocaml candidate was my primary goal
<rbalint> hi, i'd like to perform a mini transition to kodi 18 later today
<rbalint> all of the kodi-reverse deps need sourceful uploads and the main ones are built in ppa:ci-train-ppa-service/3204 , and i'm in the process of updating all addons on Salsa
<rbalint> the reason of going ahead of Debian is libkodiplatform so bump being in NEW
<rafaeldtinoco> cpaelzer: thanks! reviewing your merge
<ahasenack> doko: hi, do you know about this glibc issue?
<ahasenack> I just got this ping:
<ahasenack> """
<ahasenack> can we get this fixed in Ubuntu releases? https://sourceware.org/bugzilla/show_bug.cgi?id=23844#c14
<ahasenack> It causes BIND 9.16 to deadlock under load.
<ahasenack> """
<ubottu> sourceware.org bug 23844 in nptl "pthread_rwlock_trywrlock results in hang" [Normal,Resolved: fixed]
<ahasenack> comment #23 in that bug also says it's being seen in 18.04 in openvswitch
<doko> ahasenack: no. infinity ^^^
<tjaalton> ahasenack: btw, bind-dyndb-ldap upstream said it'll take a couple of weeks to get it ported to bind 9.16
<ahasenack> cool, then we might be able to keep it
<tjaalton> and get freeipa back
<ahasenack> that needs pkcs11, no?
<tjaalton> what does?
<tjaalton> you mean opendnssec?
<tjaalton> or if you mean the native-pkcs11 patch in the current bind, aiui that can go
<ahasenack> tjaalton: I meant that native pkcs11 hack, yeah
<tjaalton> I guess it works with openssl just the same
<ahasenack> sounds like a better way forward even if it doesn't work on the first try
<LocutusOfBorg> ricotz, you sure wrt meson upload? Explicit depends on rustc and valac, so autopkgtests can pick it up this should be useless
<rafaeldtinoco> kanashiro: https://bugs.launchpad.net/ubuntu/+source/ruby-defaults/1:2.5.2ubuntu1/+build/18596304
<ubottu> Launchpad bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress]
<LocutusOfBorg> considering that the new code has this: " @skipIfNoExecutable('rustc')"
<kanashiro> rafaeldtinoco, any issue with the sync?
<rafaeldtinoco> kanashiro: nope, it was me
<rafaeldtinoco> i had an issue with my container
<rafaeldtinoco> let me sync it
<rafaeldtinoco> kanashiro: syncpackage: Source ruby-defaults -> focal/Proposed: current version 1:2.5.2ubuntu1, new version 1:2.5.7.1
<kanashiro> rafaeldtinoco, we want the version 1:2.7~0 from experimental which drops Ruby 2.5 support
<rafaeldtinoco> yep, I think it has to go to unstable
<rafaeldtinoco> for the sync
<rafaeldtinoco> ahasenack: ^
<ahasenack> hm?
<rafaeldtinoco> can we "sync" from experimental ?
<rafaeldtinoco> put a pkg on "sync" with experimental ?
<ahasenack> in terms of tooling? yes
<kanashiro> rafaeldtinoco, can't you use "-d experimental"?
<rafaeldtinoco> kanashiro: yep, i wasnt sure if it would be ok
<kanashiro> ah ok
<rafaeldtinoco> alright. done.
<kanashiro> because we don't have enough time to wait for Debian
<rafaeldtinoco> yep
<rafaeldtinoco> let me check my email
<rafaeldtinoco> if its good ill close the bug
<seb128> LocutusOfBorg, the changes are not new from this upload, also the depends are there so an upload to those packages trigger the autopkgtests which they wouldn't do otherwise, not to handle the missing compiler
<rafaeldtinoco> kanashiro: alright. done
<rafaeldtinoco> =) have fun
<kanashiro> rafaeldtinoco, I am not quite sure how to proceed but I have a list of packages that needs to be rebuilt against ruby2.7, should I ask on #ubuntu-release for binNMUs or a core dev like you should help me on that?
<tkamppeter> LocutusOfBorg, it seems that sane-backends is hanging on the gscan2pdf autopkgtest for arm64, and gscan2pdf fails generally on arm64. gscan2pdf is a Universe package where no one here at Ubuntu cares, simply auto-synced. Can we do an exception in the autopkg tests here?
<rafaeldtinoco> I'm able to help. Let's get it published first and then we can start doing build only uploads
<ahasenack> tkamppeter: I have a bug for gscan2pdf getting stuck on arm64
<ahasenack> tkamppeter: upstream tried to help, but this wasn't reproduceable outside of canonistack instances
<kanashiro> rafaeldtinoco, great, thanks for helping me on this :)
<rafaeldtinoco> anytime!
 * rafaeldtinoco goes for lunch now before meeting ;)
<ahasenack> tkamppeter: https://bugs.launchpad.net/ubuntu/+source/gscan2pdf/+bug/1860592 you might want to badtest it using this bug as the reason
<ubottu> Launchpad bug 1860592 in gscan2pdf (Ubuntu) "Test t/06190 hangs on arm64" [Undecided,New]
<tkamppeter> ahasenack, thanks, how do I "badtest" this?
<LocutusOfBorg> seb128, context?
<seb128> LocutusOfBorg, <LocutusOfBorg> ricotz, you sure wrt meson upload? Explicit depends on rustc and valac, so autopkgtests can pick it up this should be useless
<LocutusOfBorg> tkamppeter, you have to ask release chanel...
<LocutusOfBorg> seb128, yes, but better convince debian to also add them...
<LocutusOfBorg> in any case, removing is not making the situation worse, because now the code handles that case
<seb128> LocutusOfBorg, that's a different statement than 'this should be useless'
<LocutusOfBorg> yes, true :D
<seb128> LocutusOfBorg, it does make a different as I just wrote
<seb128> LocutusOfBorg, without that the meson tests wouldn't trigger on a vala uplaod
<LocutusOfBorg> I mean, this is now an useless delta, because it might trigger test failures that debian isn't experiencing, and we should convince them that they are real issues
<seb128> but yes, ideally Debian would take those changes
<LocutusOfBorg> opening RC bugs in Debian is trivial now that they have a ci
<seb128> LocutusOfBorg, it's not useless delta, it prevents us from regressions
<LocutusOfBorg> but we have to convince them to extend testsuites
<seb128> it makes meson be tested on vala updates
<seb128> which wouldn't otherwise
<LocutusOfBorg> will anybody open a bug against meson in debian with a patch? :)
<seb128> but agreed, better to thave that in Debian
<seb128> LocutusOfBorg, I said to Rico that we should forward the change when he added it yes
<seb128> LocutusOfBorg, but feel free to it if you have free cycles since he didn't seem to have done it (yet)
<rbasak> How long has vim defaulted to restoring the cursor to its previous position on a re-edit of a file?
<rbasak> It keeps throwing me editing debian/changelog :-/
 * rbasak isn't sure if he likes this or not
<rbasak> Also on git commit messages
<tkamppeter> ahasenack, LocutusOfBorg, did you already badtest something? On #ubuntu-release they say one needs to do a merge request on hints-ubuntu, and there seems to be no documentation about how this works.
<rbasak> So what's the convention in our team for package merge MPs currently wrt. test builds, PPAs, and dep8?
<rbasak> I never used to do anything but a local test build on amd64 only, but I think you've upped the bar nowadays?
<rbasak> (in our team -> server team)
<tkamppeter> ahasenak, seems that you have added "force-badtest gscan2pdf/2.6.3-1/arm64" could you update it or better expand it to all/arbitrary versions?
<tkamppeter> ahasenack, it even contains a reference to your bug report. I found it via "blame" in the ubuntu-release file.
<rbasak> ahasenack: oh look. You've done the PASSWORD -> SHA1 thing before! https://merges.ubuntu.com/p/pam-mysql/pam-mysql_0.8.0-1ubuntu3.patch
<seb128> vorlon, libvisual autopkgtest fail on i386 because it depends on g++ ... IIRC you said to use build-essential instead? is it tehnically wrong to use g++ (I'm just trying to figure out what to write if I forward that request to Debian)
<ahasenack> tkamppeter: it's the release tem who accepts or not merges against that branch
<ahasenack> tkamppeter: what you should do next I think is propose a bump in the version of that hint
<ahasenack> tkamppeter: this was the merge proposal I had for that, and that was merged: https://code.launchpad.net/~ahasenack/britney/gscan2pdf-badtest/+merge/377955
<ahasenack> you can use it as a template
<ahasenack> just add the new ubuntu version next in that line
<ahasenack> rbasak: heh, good times
<LocutusOfBorg> tkamppeter, thanks for doing it!
<LocutusOfBorg> seb128, I'll do it
<seb128> LocutusOfBorg, thanks!
<tkamppeter> ahasenack, how do I clone the original bzr branch to my LP account so that I get a "Propose for merge" entry?
<ahasenack> tkamppeter:      bzr branch lp:~ubuntu-release/britney/hints-ubuntu
<tkamppeter> ahasenack, this way I could download and edit it. But how do I "bzr push" it into my LP account?
<ahasenack> you have to branch it, then hack on it, and then bzr push lp:~<yourlp>/britney/<name-of-your-branch>
<tkamppeter> Why "britney"?
<ahasenack> it's the name of the project
<tkamppeter> ahasenack, now it works, thanks.
<LocutusOfBorg> seb128, I sent the email, but you seem to have a failure on testsuite
<ahasenack> tkamppeter: cool
<LocutusOfBorg> exhaustive           FAIL non-zero exit status 1
<LocutusOfBorg> crossbuild           FAIL non-zero exit status 1
<LocutusOfBorg> that exhaustive is failing ubuntu-only and not debian...
<LocutusOfBorg> probably that valac /rustc addition?
<seb128> LocutusOfBorg, that wouldn't make any sense, those are pulled in in Debian as well by @build-depends@, it's not that the autopkgtest service doesn't know to use @build-depends@ to trigger other tests
<seb128> LocutusOfBorg, also where was 0.53.2 tested in Debian? it's not on https://ci.debian.net/packages/m/meson/unstable/amd64/ yet?
<seb128> LocutusOfBorg, it's the same failure than https://ci.debian.net/data/autopkgtest/unstable/amd64/m/meson/4340268/log.gz though
<seb128> so maybe .2 didn't resolve the problem as Jussi though it would
<tkamppeter> ahasenack, LocutusOfBorg: Here is my merge request: https://code.launchpad.net/~till-kamppeter/britney/hints-ubuntu/+merge/379910 I hope it is correct.
<ahasenack> tkamppeter: make it against britney/hints-ubuntu
<ahasenack> not just britney
<ahasenack> it's confusing, I also make that mistake a few times
<ahasenack> tkamppeter: I mean the proposal, your branch is fine
<ahasenack> click "resubmit" on the top right, and append "/hints-ubuntu" to the target
<ahasenack> in the end, "merge into" in the mp page, should look like "lp:~ubuntu-release/britney/hints-ubuntu"
<ahasenack> and then your diff will show up correctly
<kanashiro> rafaeldtinoco, re ruby 2.7 transition: we need to start with the packages in level 1 here: https://people.canonical.com/~ubuntu-archive/transitions/html/html/ruby2.7-add.html
<rafaeldtinoco> wh0t ?1
<rafaeldtinoco> lol
<tkamppeter> Have done it. Now it reads: lp:~ubuntu-release/britney/hints-ubuntu
<tkamppeter> ahasenack, why does this not work in the first place. Or why do we not switch to GitHub or GitLab?
<ahasenack> tkamppeter: I'm not the one to answer these questions, sorry :)
<ahasenack> I'm just a client, just like you :)
<ahasenack> tkamppeter: is it still https://code.launchpad.net/~till-kamppeter/britney/hints-ubuntu/+merge/379910 ?
<ahasenack> ah, wait
<LocutusOfBorg> seb128, https://ci.debian.net/data/autopkgtest/testing/amd64/m/meson/4381867/log.gz
<ahasenack> I see the superseeded bit
<ahasenack> tkamppeter: yeah, diff looks correct now
<LocutusOfBorg> https://code.launchpad.net/~till-kamppeter/britney/hints-ubuntu/+merge/379911
<LocutusOfBorg> this one is nice
<seb128> LocutusOfBorg, that one is red though?
<LocutusOfBorg> yes, but exhaustive           PASS
<LocutusOfBorg> you can see the run here https://tracker.debian.org/pkg/meson
<seb128> LocutusOfBorg, and not, the other fail is the other patch tumbleweed added in https://launchpad.net/ubuntu/+source/meson/0.53.0-1ubuntu2
<LocutusOfBorg> or here https://ci.debian.net/packages/m/meson/unstable/amd64/
<seb128> LocutusOfBorg, see https://github.com/mesonbuild/meson/pull/6656
<seb128> it trigger the same issue in upstream CI
<seb128> tumbleweed, ^
<LocutusOfBorg> seb128, so shouldn't we just revert the patch? :)
<seb128> LocutusOfBorg, you could but then it would fail on python missing
<seb128> which Debian doesn't have as an issue atm
<tumbleweed> that patch did the right thing on Ubuntu, but wasn't appropriate for Debian at the time
<LocutusOfBorg> sure
<tumbleweed> from my PoV, a quick hack, rather than trying to do something generic
<LocutusOfBorg> why not move to python3?
<seb128> tumbleweed, the tests and upstream CI fail with 'meson.build:20:2: ERROR: Assert failed: Didn't load python from config file'
<seb128> tumbleweed, so seems it's buggy
<seb128> in ubuntu
<LocutusOfBorg> maybe xenial or whatever upstream has didn't have python2?
<LocutusOfBorg> I mean, the symlink
<tumbleweed> seb128: It got it to build on debian, where ubuntu1 didn't
<tumbleweed> s/debian/ubuntu/
<seb128> tumbleweed, it built but autopkgtests are failing due to it
<seb128> so it didn't help much
<tumbleweed> it must have passed, because it migrated
<seb128> tumbleweed, anyway, I'm not interested to argue, was just pointing out that meson is still blocked because that patch created a regression
<LocutusOfBorg> mmm
<LocutusOfBorg> python2 not installed?
<LocutusOfBorg> it is not listed in debian/tests/control lol
<seb128> LocutusOfBorg, /usr/bin/python got removed from focal
<tumbleweed> right, so I should have updated debian/tests/control too
<LocutusOfBorg> seb128, I'm not saying that
<LocutusOfBorg> seb128, python2 is not getting installed
<seb128> LocutusOfBorg, if python2 is needed it's easy to add to the control
<LocutusOfBorg> in debian it is
<tumbleweed> Debian hasn't removed /usr/bin/python, yet
<seb128> still we need to fix the other issue (which is also in Debian)
<LocutusOfBorg> mmm it is not listed but it gets installed due to something else
<LocutusOfBorg>         self._simple_test('python2', 'python2')
<LocutusOfBorg> that would fix it
<LocutusOfBorg> seb128, can you please update the pull request?
<LocutusOfBorg> so we get easy testing
<seb128> LocutusOfBorg, sure, will do that in a bit
<LocutusOfBorg> <3
<vorlon> seb128: build-essential gets handled specially by the patches to autopkgtest; so it's not "technically wrong", just incompatible with the current implementation for cross
<seb128> vorlon, what's the right thing to state in a Debian bug report? 'please use build-essential instead of g++, should work the same for you and it fixes cross build in Ubuntu'?
<vorlon> seb128: that's what I would say yes
<seb128> vorlon, thanks
<vorlon> seb128: if you want to steal some of my boilerplate language, you could use e.g. Debian bug #950303
<ubottu> Debian bug 950303 in libgpg-error "libgpg-error: Please make autopkgtests cross-test-friendly" [Minor,Fixed] http://bugs.debian.org/950303
<seb128> vorlon, thanks
<seb128> LocutusOfBorg, https://github.com/mesonbuild/meson/pull/6656 still not happy, so I don't find the issue in the log
<seb128> LocutusOfBorg, ah, I see it now
<seb128> 'meson.build:1:0: ERROR: Value "python2" for combo option is not one of the choices. Possible choices are: "find_program", "config_dep", "python3", "python".'
<ricotz> seb128, for my defence, I wrote jpakkane about it in #mesonbuild
<LocutusOfBorg> seb128, its self._simple_test('python', 'python2')
<LocutusOfBorg> probably
<LocutusOfBorg> seb128, it is good, you probably need this vi "./test cases/unit/47 native file binary/meson_options.txt"
<LocutusOfBorg> and then change python to python2
<LocutusOfBorg> can you please try?
<tumbleweed> On Python 2.7 doko: FYI: https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1864766 (there's a link at the bottom to a pypa discussion about this)
<ubottu> Launchpad bug 1864766 in python-pip (Ubuntu Xenial) "[SRU] pip in xenial is installing packages incompatible with Python 2.7 (and those are becoming common)" [Medium,In progress]
<gbit86> Does anyone know if it is possible to configure xkb to cancel the Shift key if BOTH shift keys are held down?
<ahasenack> infinity: hi, do you remember why this cross-compile patch wasn't forwarded to debian at the time? It has an explicit "Forwarded: not needed". Was it because it's from upstream, and it was thought it would be in a new upstream release by now?
<ahasenack> infinity: https://pastebin.ubuntu.com/p/vctTmQFSKn/
<infinity> ahasenack: Exactly that, yes.  It was yeeeears ago, I kinda figured upstream would have released something including that by now.
<LocutusOfBorg> seb128, https://github.com/mesonbuild/meson/pull/6703
<LocutusOfBorg> this might be the solution
<vorlon> seb128: libsoup2.4 fixed btw, new php had needed adding to the whitelist which is done now
<seb128> LocutusOfBorg, good, one less thing for me to refresh
<seb128> vorlon, ah ok, that was still on my todo but I'm struggling a bit due to ff coming ... thanks for the status update and for fixing!
<seb128> vorlon, I need also to read again L_aney's hints from yesterday about how the whitelist and refreshes are being handled
<seb128> vorlon, while you are around, what's the word with icu? I'm still holding to upload some of the GNOME stuff but ff is tomorrow and I would prefer to no have to end up having to do ffe parperwork ... :)
<vorlon> seb128: I intend to finish it today before I EOD; how much I have to break in anger to accomplish that is another question
<vorlon> (I just had to roll back an upload of a ruby package which depends on icu, which would've entangled icu + ruby-defaults)
<vorlon> seb128: is the stuff you're holding back currently in -proposed?
 * sarnold hands vorlon a larger hammer
<seb128> we don't have a a 'force in hammer' for those cases?
<vorlon> we do have one
<vorlon> but it's also a moving target because the force hammer only works if the versions of the packages in -proposed /stay the same/ between the time i write the hint and the time britney runs
<seb128> vorlon, yes, like I want to upload webkit2gtk 2.27, but https://launchpad.net/ubuntu/+source/webkit2gtk/2.26.4-1ubuntu1 is on the 'rebuilt with the new icu' list
<vorlon> ack
<vorlon> yeah please hold off just a little longer
<seb128> also poppler and gnome-desktop transitions are started
<vorlon> I think 1-2 britney runs and we should be there
<seb128> but they can't be completed without rebuilding libreoffice and other things
<seb128> k, hopefully things migrate by the time I start my day tomorrow :)
<vorlon> if they haven't, then I am having a very bad day
<seb128> let's hope you don't then :)
<LocutusOfBorg> dpkg: error processing archive /tmp/apt-dpkg-install-wNmXFW/264-libx11-dev_2%3a1.6.9-1_s390x.deb (--unpack):
<LocutusOfBorg>  trying to overwrite '/usr/include/X11/extensions/XKBgeom.h', which is also in package x11proto-dev 2018.4-4
<seb128> LocutusOfBorg, https://packages.qa.debian.org/libx/libx11/news/20200226T170800Z.html
<seb128> which didn't autosync yet (might be worth doing a manual sync to avoid waiting?)
<LocutusOfBorg> I did it :D
<LocutusOfBorg> tjaalton, ^^ I'm trying to fix therion
<seb128> thx
<LocutusOfBorg> also xorgproto syncd
 * LocutusOfBorg goes to sleep
<seb128> calling it a day on that note since the syncs/uploads I just did failed due to that bug
<seb128> same here
<LocutusOfBorg> g night
<seb128> 'night!
#ubuntu-devel 2020-02-27
<RAOF> ???
<RAOF> What is happening here? mir-1.7.0-0ubuntu2 has a libmiral3.symbols file which includes `(c++)mir::Foo::~Foo()`. objdump -T on libmiral.so.3 from that package asserts that it does *not* contain `mir::Foo:~Foo()`.
<RAOF> And then the build of mir-1.7.1-0ubuntu1 with no changes to `Foo` fails because `mir::Foo::~Foo()` doesn't exist in the object?
<wxl> did we add some thing to check the iso on boot?
<wxl> if so, where?
<RAOF> I don't see how all three of these things can happen?!
<wxl> also does anyone know if this new iso manifest-diff check applies to flavors? or can we make it be? is there code for this somewhere?
<wxl> er huh i should probably ask this on release blah
<seb128> vorlon, hey! so icu still didn't go as expected? :-(
<vorlon> seb128: I think it's going to go in the current run
<seb128> fingers crossed!
<vorlon> should've gone in a previous run but there was a znc sync and it took me a while to realize that was entangled with python3.8
<seb128> hum, is there a problem with the arm64 autopkgtest infra/capacity?
<seb128> backlog doesn't seem to go down but we didn't upload that much in recent days?
<seb128> vorlon, I had packages just migrating but not those blocked on icu, I guess it means it failed again? :(
<didrocks> it go down, but not fast. My yesterdayâs upload only ran this morning on arm64
<seb128> Laney, juliank, vorlon, do we have a page that list the number of active builders for autopkgtest? something like https://launchpad.net/builders/
<Laney> nope
<seb128> :(
<Laney> you can count the builds on the running page
<seb128> the arm64 backlog doesn't seem to go down
<seb128> let me do that
<juliank> seb128: patches welcome!
<juliank> :D
<seb128> :)
<Laney> ubuntu@juju-prod-ues-proposed-migration-machine-11:~$ journalctl --since=08:00 ADT_ARCH=arm64 | grep -c 'Acknowledging request'
<Laney> 114
<Laney> it is going
<LocutusOfBorg> rafaeldtinoco, ruby-psych and jruby have a chicken and egg serious problem, and now they are uninstallable both...
<rafaeldtinoco> LocutusOfBorg: hum, that was part of the ruby transition uploads, I'm almost home will take a look shortly
<LocutusOfBorg> thanks
<rafaeldtinoco> kanashiro: fyi ^
<rafaeldtinoco> looks like for this build loop I'll have to drop ruby-psych from build-depends of jruby, and after building ruby-psych do another build of jruby supporting it
<rafaeldtinoco> and open a bug in debian to check what they can come up with as ruby-psych has been alternating between suggest and dependency since 2017
<rafaeldtinoco> kanashiro: ^
<seb128> icu migrated \o/
<seb128> vorlon, well done :-)
<kanashiro> rafaeldtinoco, let me know if your plan work as you planned
<rafaeldtinoco> kanashiro: yep, will give it a try locally now
<rafaeldtinoco> kanashiro: your transitions page look much better today
<rafaeldtinoco> just a few packages missing from the 1st wave
<kanashiro> rafaeldtinoco, yes, and I am checking it and some of the packages in red already built fine, it might be a matter of waiting to update it
<rbasak> ahasenack: pam_mysql is a sync I believe. Could you please review before I sync it?
<rbasak> (pam-mysql)
<rbasak> libdbi-drivers is in main. So why doesn't https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.focal/rdepends/libdbi-drivers/ exist?
<seb128> vorlon, your tepl upload to pick i386 is depwaiting on amtk to be also added
<Laney> wish I could update that i386 seed myself
<rbasak> Ah - apparently we unseeded libdbi-drivers this cycle
<ahasenack> how can I get access to focal on armhf to troubleshoot http://autopkgtest.ubuntu.com/packages/c/cacti/focal/armhf ?
<ahasenack> should I use a bileto ticket and do "interactive" debugging with it, one print() per upload?
<Laney> ahasenack: get an arm64 VM and use lxd to launch armhf inside that
<ddstreet> juliank hi, i'm assuming you probably won't have time to review this MR until after focal? https://code.launchpad.net/~ubuntu-support-team/software-properties/+git/software-properties/+merge/379928
<ddstreet> i can split it up or adjust or whatever, but need to know what you'd like to see done, otherwise i'll just keep developing and it will grow larger :)
<juliank> ddstreet: that's hard
<ddstreet> you mean it's hard to review at all?
<juliank> i don't know
<ddstreet> oh
<ddstreet> well i'll be at the sprint next week if you want to talk
<juliank> I think I reviewed in the wrong order
<juliank> I was looking at the commit that removes PPA stuff before the commit that rewrites it
<juliank> ddstreet: Do you know if anything is using the library that could break by this change?
<cjwatson> ddstreet: https://code.launchpad.net/~ddstreet/launchpadlib/nosudo/+merge/379694 is on my queue but I'd find it helpful if you didn't add extra review requests please :)
<ddstreet> cjwatson ack, i wasn't sure if you were on the list
<juliank> ddstreet: I don't want it to get even larger :D
 * cjwatson deletes that request - I'm already in ~lazr-developers
<juliank> but I also don't really have time or nerve to review this yet
<ddstreet> juliank i dont think anything is using the changed code, but i'll check all the reverse-depends
<juliank> worst case, I guess we can sit down for 30 mins next week and go over the commits
<ddstreet> sounds good, thnx
<ahasenack> Laney: thanks, that worked!
 * Laney does a celebratory moonwalk
<vorlon> seb128: thanks for the hint re: amtk, sorted that now also
<seb128> vorlon, thanks for sorting it out, days are a bit crazy with ff this week but I will take time to learn to do that myself next time I get one
<seb128> vorlon, what issue was your libxml2 recent patch fixing? There is no bug reference in the changelog/patch and Debian has applied what look like a subset of your change in https://packages.qa.debian.org/libx/libxml2/news/20200227T184953Z.html and I would like to check if that's enough to fix the issue you were having
<seb128> vorlon, in which case we could sync back, which would be nice because Debian also backported some extra CVE fixes
<vorlon> seb128: I actually opened a PR upstream for my change, and upstream pointed out it was fixed differently on trunk.  so a newer upstream is probably fine
<vorlon> the issue was a testsuite failure in libxml-libxslt-perl on armhf
<vorlon> because it was constructing trees of nodes that were unexpected by libxml2
<seb128> vorlon, ok, Debian took the fix from upstream so I guess it should be fine to sync, thanks
<seb128> vorlon, right, https://salsa.debian.org/xml-sgml-team/libxml2/-/commit/f91d1425 sounds like a variant for the same fix
<seb128> thanks for confirming!
<vorlon> and I spoke w/ mapreri this morning on #debian-devel
<vorlon> so yeah we should be good
<vorlon> if it gets hung up again on the autopkgtest, we'll know soon enough
<seb128> right
#ubuntu-devel 2020-02-28
<eoli3n> Hi
<eoli3n> i have a strange behaviour, i use ldap auth and logins are mail adresses (i know that it is not great, not my decision)
<eoli3n> when i try to log with for exemple username.lastnamelastnamelastname@domain.fr on tty
<eoli3n> it doesn't ask for password
<eoli3n> i can't find the rule
<eoli3n> if you remove the dot
<eoli3n> usernamelastnamelastnamelastname@domain.fr, it asks for password
<seb128> RikMills, hey! we have a poppler transition started, any chance you could look at what calligra and kitinerary (and maybe scribus?) need to build with it? (simple rebuild failed)
<RikMills> seb128: already looking :)
<eoli3n> any idea what's limit that ?
<seb128> RikMills, great, thanks!
<RikMills> np
<eoli3n> just try to enter that exact username on tty "username.lastnamelastnamelastname@domain.fr"
<eoli3n> and you will see that something resets
<andrewsh[m]> hi
<andrewsh[m]> dear Ubuntu developers, why is the kernel image in Ubuntu readable by root only?
<andrewsh[m]> and what would be the best way to package a tool run by a non-root that needs to read the kernel image?
<andrewsh[m]> I mean, package for Debian but in an Ubuntu-compatible way
<juliank> andrewsh[m]: security?
<juliank> andrewsh[m]: My understanding is that you can extract the kernel memory layout from the image and use that for attacks
<juliank> andrewsh[m]: hence you need to write a helper and use policykit to limit access to admins
<andrewsh[m]> has anyone done anything like this in the past?
<andrewsh[m]> anything I can look at as an example?
<juliank> probably not
<juliank> arighi: so I went crazy and picked the -17 kernel from the PPA and will stress test i915 on there now
<cjwatson> https://wiki.ubuntu.com/Security/Features/Historical#kptr-restrict
<juliank> because -16 did not help at all, probably due to the off-by-one
<cjwatson> andrewsh[m]: ^- at some point I remember having a better reference for that, but there's that at least
<juliank> 3 mins into test, stuff is stable
<juliank> I'm having one window run Netflix in Chrome and one window run glxgears
<juliank> still leaves me enough space for more windows :)
<juliank> 1280x1440 is plenty...
<juliank> cjwatson: has it been considered to make merge proposals for git redirect to the git branch when you use git, so you can just git fetch the merge proposal url?
<andrewsh[m]> I'm asking for a friend^W fakemachine+debos
<cjwatson> juliank: We've considered various things like that and will hopefully make some improvements next cycle
<andrewsh[m]> it needs a kernel to create a virtual machine to run debootstrap and other things in
<cjwatson> (We'd hoped to this cycle, but ran out of time a bit)
<juliank> ack
<juliank> kernel -17 is stable so far, 30 mins in
<tjaalton> juliank: good to hear
<doko> mitya57: what's your plan with sphinx 2.x? split out a source package to still build sphinx 1.x for Python2 in focal?
<seb128> xnox, hey, how easy for you is it to kick a refresh to the auto-transitions list? would be nice to have gnome-desktop3 and poppler on there
<arighi> juliank, thanks! I'm also testing -17 on my test laptop, so far so good
<mwhudson> smoser: are you going to upload ssh-import-id ?
<smoser> mwhudson: i can do that.
<smoser> it felt like i should do a full new release.
<smoser> since the version in pypi is not functional with 3.8
<mwhudson> smoser: i'm being parochial and only caring about focal but that makes sense
<smoser> mwhudson: yeha. i'll do that all now.
<mwhudson> smoser: thanks!
<smoser> uploadign to focal is easy/known/automated
<smoser> but the "new release" stuff is more a pita
<rbasak> kanashiro: may I have some help merging ruby-dataobjects-mysql please? I don't see where the upstream VCS for that is - both the Homepage d/control field and the upstream https://rubygems.org/gems/data_objects (I think?) point to https://github.com/datamapper/do which appears dead.
<rbasak> So not sure how it would sit with feature freeze.
<rbasak> This can wait until after the ruby transition I think.
<kanashiro> rbasak, I think it is better to do it after the ruby transition, but yes, upstream seems inactive
<kanashiro> rbasak, is this delta something that we can push to Debian? is it work with the current version of mysql in Debian?
<seb128> doko, hey, inkscape hits a gcc ICE on ppc64el https://launchpad.net/ubuntu/+source/inkscape/0.92.4-5ubuntu3 is that something you could a look at? we need to rebuild inkscape for the poppler (and gnome-desktop3) transitions
<rbasak> kanashiro: yes it's fairly small - just fixes to work against latest MySQL
<rbasak> It's not yet appropriate for Debian since Debian doesn't have MySQL 8 yet - that's a separate yet-to-be-completed effort
<rbasak> (for Debian to maintain a separate patch just for that)
<rbasak> But appropriate for upstream - all that work is still outstanding
<kanashiro> rbasak, so let's keep the delta then
<kanashiro> and I can do the merge when the time comes
<rbasak> Thanks!
<doko> seb128: looking, but maybe not today anymore
<seb128> doko, no hurry, those transitions need a libreoffice upload, that's not going to build/go through in a day
<seb128> doko, I tried to build with O2 in a ppa but my debian/rules foo failed
<smoser> mwhudson: why can't anything ever be easy.
<smoser> https://bugs.launchpad.net/ssh-import-id/+bug/1865171
<ubottu> Launchpad bug 1865171 in ssh-import-id "local variable 'distro' referenced before assignment" [Critical,Confirmed]
<mwhudson> smoser: computers were a mistake
<seb128> doko, in fact buildign with O2 worked, I will do that for now
<smoser> mwhudson: agreed.
<smoser> hey. i just uploaded.
<smoser> http://paste.ubuntu.com/p/wBbnXsS5ng/
<smoser> but i dont see it anywhere in queue
<smoser> bah. how do i tell it to do the full upload. if orget.
<smoser> ok. fixed. -sa
<mwhudson> smoser: thanks
<mitya57> doko: For focal it's the best to stick to sphinx 1.8.5.
<mitya57> Every major sphinx release breaks many packages, here we have three major releases (2.0, 2.1, 2.2) and I didn't have time to test rebuild reverse dependencies yet.
<mitya57> For Debian the number of packages using Python 2 sphinx is decreasing, and having a separate source package for it causes some problems, so I don't want to do that.
<mitya57> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944913#49 â and some of these are already fixed.
<ubottu> Debian bug 944913 in python3-sphinx "python3-sphinx: Please update to Sphinx 2.2.1" [Wishlist,Fixed]
<doko> mitya57: yep, asking because numpy 1.8 requires it, and I'd like to update that one ..
<mitya57> Maybe disabling docs is the easiest you can do.
<CarlFK> amurray: kinda ot, if someone can tell me where to open an issue: https://launchpad.net/dhcp  "Home Page" http://www.isc.org/index.pl?/sw/dhcp/  404  -  https://www.isc.org/dhcp/ is good.
<sarnold> CarlFK: probably the email address on https://launchpad.net/~registry which appears to own https://launchpad.net/dhcp
#ubuntu-devel 2020-02-29
<cjwatson> CarlFK: updated, thanks
<CarlFK> cjwatson: yay.  and hi!
<cjwatson> o/
#ubuntu-devel 2020-03-01
<doko> mitya57: there are some build-deps on python-numpy-doc :-(  networkx pycuda dask dask.distributed pandas pyepr pyopencl python-hdf5storage scikit-learn statsmodels
<mitya57> doko: Do you know why exactly it needs newer Sphinx? Maybe you can revert some changes that added this dependency, or maybe I can backport some missing features to 1.8?
<mitya57> Maybe reverting dedc4178fc334329 and 5d5ce4ccb89f0b30 will be enough.
<doko> I'll have a look later
<mitya57> Both these commits are from https://github.com/numpy/numpy/pull/14356.
<Logan> is it kosher to sync over a package  that has been traditionally uploaded by CI Train or PS Jenkins bot? In this specific example I'm looking at properties-cpp, which is now packaged in Debian and uses the newer UBports source (and doesn't FTBFS)
<vorlon> Logan: yes; packages that were previously uploaded through the CI Train are de facto unmaintained, and most of them have been removed from Ubuntu since they were part of an EOL product and in many cases ftbfs.  So if there's a newer version in Debian that fixes bugs, don't let the upload history from 2014 stop you
<Logan> awesome, thanks!
<Ark74> Hello guys!
<Ark74> I'm trying to backport libreoffice 6.4 to bionic, but even when all dependencies seems to be satisfied
<Ark74> I keep getting errors like this; https://paste.ubuntu.com/p/VsysHvcv8n/
<Ark74> that's only a the lines that have the error, the whole build log is around 45 mb long
<nickgaw> Hi, I have bzr installed and was just trying to checkout the latest version of the ubuntu installer what command do I run for this after I have the debian-installer also checked out?
