#ubuntu-devel 2004-11-29
<infinity> I'd rather see a "patch to make Replaces work the way it intuitively should" before anything dealing with :"teaching people what Conflicts means". :)
<infinity> (ie: if I install B, then A, and B replaces A, the file overlaps should select the file from B, not A)
<seb128> if B replaces A and you install B first and the A you get a file conflict
<Keybuk> I think what infinity is trying to describe is the fact that dpkg doesn't back-depend
<Keybuk> A depends B > 2.0
<Keybuk> install A and B 2.0
<Keybuk> install B 1.0
<Keybuk> works
<seb128> hum ? no, doesn't work
<Keybuk> sure it does
<Keybuk> try it :p
<lamont_r> seb128: mind you, it _shouldn't_...
<seb128> I mean with apt it doesn't work :)
<seb128> I've not tried with dpkg, but I believe you :p
<Keybuk> dunno about APT, that's mdz's toy
<Keybuk> but dpkg will let you do that
<Keybuk> because it only considers the dependencies of the packages you've given it to process
<infinity> Keybuk : No, I'm talking actual replaces.
<Keybuk> it doesn't go through the system and check that previously-installed packages' dependencies aren't broken
<Keybuk> infinity: it's the same bug
<Keybuk> when you install A, it doesn't go through the system to see if anything Replaces it.
<infinity> Ahh, yeah.
<infinity> Same bug probably, then. :)
<shaya> Keybuk: so you're saying dpkg needs apt's dependency handeling logic
<Keybuk> shaya: no idea whether apt's works or not
<infinity> I first noticed it when I used to run Woody systems with the "dselect" package installed from an old sid snapshot.
<infinity> If you reinstalled dpkg.deb, it would overwrite /usr/bin/dselect, despite 'dselect' replacing 'dpkg'.
<Keybuk> yup
<infinity> (Which was irritating, because the newer dselect sucked a lot less)
<seb128> BTW time to sleep
<seb128> 'night everybody
<Keybuk> nite dude
<shaya> sleep?
* shaya tries to figure out where seb128 is
<Keybuk> France.
<shaya> 5 hours ahead?
<shaya> or 6?
<Keybuk> 1 hour ahead
<Mithrandir> UTC+1, so it's 00:10 here now.
<sjoerd> it's 0:11 over here (and in france too)
<shaya> Keybuk: I'm an imperialistic washington, DC native, so hence 6 hours ahead (as DC is the center of the world, or so they brainw, I mean taught us as kids)
<Keybuk> with such geography, it's amazing the Merkins get *anywhere*
<Mithrandir> shaya: giving relative time references based on anything else than UTC gives people headaches. :)
<shaya> Mithrandir: but they taught us that EST was the real universal time :)
<Keybuk> the Earth is a *spheroid* ... the centre is roughly the same distance from everywhere in a downward direction
<Mithrandir> Keybuk: give or take a few clicks, yes. :)
<Keybuk> you can only be "the centre of the world" if you're in a notably crackful, but rather fun, blockbuster of a few years ago
<shaya> Keybuk: do you put it pass GWB to try and get there just to say it?
<shaya> hmm, just noticed, those initials are also used for the George Washington Bridge
<shaya> maybe that's where he was conceived :)
<Keybuk> "My fellow Umbrella-stands.  I have decidified to embark on a great and dangerous journey to the centrofold of the Earth."
* lamont_r wanders off for a bit
<gicmo> 'evening
<jdub> yo gicmo 
<jdub> sladen: around?
* gicmo is closely reading https://www.ubuntulinux.org/wiki/USplash 
<jdub> gicmo: when sladen is around, we should ask him where it's at :)
<Keybuk> jdub: he's awake
* jdub sends an ICBK in sladen's direction
<jdub> you can't put parameters in /etc/modules, can you?
<Keybuk> no
<jdub> that's a bummer
<Keybuk> actually, I like
<Keybuk> I lie too
<Keybuk> you can
<jdub> oh!
<jdub> ide-cd dma=1
<jdub> :)
<Keybuk> echo "options ide-cd dma=1" > /etc/modprobe.d/ide-cd
<Keybuk> would be more "robust", as it'd also ensure that option happened if hotplug or jdub loads it
<jdub> ahr
<sladen> gicmo: evening
<gicmo> sladen, it's almost 2pm here so morning would be better ;)
<gicmo> sladen, I definitly wanna help out with the graphical boot stuff (I just switched over from fedora and I really miss it) :)
<sladen> gicmo: your welcome to help and join in (we'd like your ideas too)
<Keybuk> jdub: I wish there were a way of having separate volumes
<Keybuk> so rather than all this "PCM" nonsense, you just set the volume for gaim, the volume for rhythmbox
<gicmo> btw .. I took me 3 hours to get acpi up and running here .. :(
<Keybuk> then you can have loud music, without BRING!(*"($*!"&*$!&$*(!"$_$ every time you get a message <g>
<sladen> gicmo: there was some code written at the last conference, which I promised I'd package up for the #debsplash guys
<gicmo> sladen, ahh some code is always a good starting point ;)
<gicmo> Ok, blog updated .. 
<gicmo> checking mail and then to bed .. damn its 2.30 am already ..
<gicmo> 'nigh
<lamont3> daniels/fabbione around?
* lamont3 grumbles, kicks xserver-xorg, sends the nice user to the other room to get the mdetect-loving monitor
<lamont3> bbiab
<shaya> interesthing thing I've noticed.  If you do set a root password, many things that ask you for a root password don't take it, but want your user password (ala sudo)
<shaya> i know why you do sudo, but it seems once a root password is set all those things are buggy, as they do ask for the root password
<shaya> for example, run aptitude as a regular user, it asks for the "root" password
<jdub> that's unrelated to whether you have a root password set or not
<jdub> we just didn't bother fixing it to use sudo
<tseng> lo jdub 
<jdub> morning tseng 
<shaya> jdub: confused?
<shaya> aptitude does use sudo
<shaya> but it asks for root password
<shaya> so root password doesnt work
<shaya> need to use user password
<jdub> sounds like it wasn't a fully fixed bug, then
<shaya> so it's something I should file?
<shaya> there was a bug filed and closed
<shaya> reopened it
<hornbeck> jdub: you around?
<jdub> yeah
<hornbeck> the Ubuntu in a Nutshell
<hornbeck> what are you looking for in it
<jdub> ah
<jdub> long discussion
<jdub> i'll mail ubuntu-doc or you or something
<hornbeck> ok, have you seen our book outline?
<jdub> bits, haven't investigated a lot
<jdub> seems different to the nutshell goals
<hornbeck> right, if you could mail me what you are looking for 
<hornbeck> hornbeck at freeshell dot org
<hornbeck> thanks
<fabbione> morning guys
<pitti> Hi fabbione!
<sladen> hornbeck: 'what is sudo', 'why did they rename kernel-sources', 'I heard mp3 ain't legal, where do I get my warez?'
<sjoerd> morning
<sjoerd> pitti: could you check the new device-removable.sh script to see if i haven't done anything stupid
<pitti> Hi sjoerd 
<pitti> yes, I can
<pitti> From a quick glance it seems that you do something similar as pmount
<pitti> sjoerd: do you have the file at hand somewhere?
<sjoerd> no svn checkout ?
<pitti> sjoerd: svn checkout lasts so long...
<pitti> sjoerd: okay, I'll check it out
<sjoerd> :)
<sjoerd> alioth is somewhat overloaded it seems....
<pitti> sjoerd: debian/patches looks nice again :-)
<pitti> sjoerd: and I suppose with your merges the Ubuntu version shouldn't look much worse
<sjoerd> you mean in gvm ? there were no changes in hal's debian/patches
<pitti> no, I actually meant hal
<pitti> Ubuntu's debian/patches in hal is pretty crowded now
<sjoerd> ah right
<pitti> I looked at the script, but it is too complex for me to be able to say yes or no after two minutes :-)
<sjoerd> you have somewhat more time 
<pitti> I will scrutinize it more thoroughly after I fixed samba
<sjoerd> k
<sjoerd> just want to be sure that stupid things are out of it before i sent it to md
<sjoerd> my shell programming skills suck
<pitti> btw, do you publish the orig.tar.gz tarballs somewhere?
<pitti> for PostgreSQL I just put them into the top repository directory
<sjoerd> pitti: why did you put ubuntu-storage-policy.fdi in /etc instead patching the one in /usr/share 
<sjoerd> without tarball.mk it's just the upstream tarball
<pitti> sjoerd: because I want the users actually be able to customize it
<pitti> sjoerd: changes in /usr/share are lost on next upgrade
<sjoerd> ok, but the can always put something like this in /etc 
<pitti> sjoerd: and I think it is nicer to give users something to change, instead of urging them to write a conffile from scratch
<sjoerd> so it's more an example 
<sjoerd> k, good point
<pitti> sjoerd: hmm, I don't insist on my solution
<pitti> sjoerd: if you want to adopt the change for Debian as well, I don't need the etc file any more
<pitti> sjoerd: if you want to keep 2GB, fine for m
<pitti> me
<sjoerd> i was gonna put an example in /etc anyway, to show how people can indicate that gvm shouldn't automount certain drives
<pitti> sjoerd: but at least you need the patch to set correct values for the flags
<sjoerd> yeah
<sjoerd> didn't check the differences yet (except for the 1gb and 2gb difference)
* sjoerd couldn't care less if it's 1 or 2 gb
<pitti> sjoerd: the key difference is that the original fdi only sets sync to true if < 2 GB
<pitti> sjoerd: but that is pmount's default anyway; you need to set sync to false explicitly
<pitti> sjoerd: same for noatime
<sjoerd> ah
<sjoerd> i can patch the system fdi for the rigth flags.. and also put this commented out in a preferences.fdi
<sjoerd> just to show how to easily do it
<sjoerd> i was planning to do that for the automount hint anyway
<pitti> sjoerd: this would be nice
<pitti> sjoerd: then I could revert the Ubuntu patch
<sjoerd> yeah and we can still change the default easily, as it's in /usr/share
<sjoerd> oh cool.. kay send a patch to let udev handle all the hotplug stuff
<pitti> sjoerd: i. e. the unmounting?
<sjoerd> uhm no, what /sbin/hotplug now does.. but then done by udev
<sjoerd> which gives you better serialisation among other things
<pitti> sjoerd: oh, everything? Including module loading, file parsing etc.
<pitti> sjoerd: hmm, this essentially means to merge the udev and hotplug sources, I suppose
<pitti> sjoerd: but it certainly looks nicer to have one less item in the chain
<sjoerd> udev did already the same thing for the most part
<pitti> sjoerd: udev did not load modules AFAIK
<pitti> however, sounds nice
<pitti> I hope that all the upstream and Debian maintainers agree on this
<sjoerd> should fix some races here and there
<sjoerd> dunno, it makes more sense that way.. so i think it's hard for the debian people not to agree
<pitti> from the technical perspective they surely agree, but the hotplug maintainer will lose his baby... :-)
<pitti> Hi daniels 
<daniels> pitti: morning
<pitti> Hey, I just became "uncle"! :-))
<pitti> My sister got a little daughter 
* pitti jumps for joy
<sjoerd> congratulations 
<lulu> pitti:that's awesome :o)
<pitti> lulu: Yeah! Unfortunately my sister lives 700 km away, so it will take a while until I actually see her
<lulu> pitti: have to live with digital pics via email :o(
<fabbione> daniels: 3614 <-
<Kamion> morning folks
<fabbione> hey Kamion
<pitti> Hi Kamion 
<pitti> mvo__: growing tails? :-))
<mvo__> tsss :)
<daniels> fabbione: got it, thanks
<fabbione> daniels: what about uploading xorg? ;)
<fabbione> my sparc already hates you :P
<daniels> heh
<daniels> so just put it in not-for-us for the time being
<daniels> but yeah, I'll do xorg this morning
<fabbione> nah that's ok.. it needs to build xfree86 first
<fabbione> i forgot to tell sbuild to not die for inactivity
<fabbione> and it killed the build right in the middle of it
<daniels> heh!  whoops
<daniels> fabbione: i'm going to go with a full (security + your crack) upload
<fabbione> daniels: ok
<fabbione> if mdz will say something i will take that responsability
<daniels> simply because I've been busy enough with triage, other distro stuff, taking tuesday off, etc, that I haven't had time to properly finish all of my stuff
<daniels> cool
<fabbione> but you will take the responsability for the broken crap
<Kamion> 10:17 < fabbione> if mdz will say something i will take that responsability
<Kamion> say something about what?
<fabbione> Kamion: mixing a security upload to hoary, together with other bug fixes
<daniels> (enter Kamion!)
<Kamion> for hoary I shouldn't think there'd be a problem with that
<daniels> Kamion: uploading 6.8.1-1ubuntu3 with libxpm fix + other random stuff
<daniels> ok, cool
<fabbione> Kamion: exactly my idea
<daniels> ounds ill
<Kamion> ?
<fabbione> also because i don't see any point in pushing foo 1.0-2 with the security and 10 minutes later -3 with all the other crack
<Kamion> quite so
<daniels> Kamion: 'sounds ill' -> 'delightful!  my people shall make it so'
<pitti> Hi seb128!
<Kamion> daniels: thanks for the British translation ;-)
<seb128> hey
<daniels> Kamion: i'm here to help, dude
<daniels> Kamion: but after hearing some British music, I'm unsure about my translations
<rburton> haha
<daniels> 'dude am I ever pissed off' -> 'GUNS DON'T KILL PEOPLE, WAPPERS DO' might be more appropriate, it seems :P
<Kamion> (sed's fixed now, right?)
<Kamion> wappers?
* azeem never understood that word in the song
<daniels> Kamion: goldie lookin chain
<daniels> Kamion: keybuk's not subjected you to that?
<Kamion> nope
<rburton> oh he doesn't have it does he?
<daniels> Kamion: the origin of WOO WOO SUMMON THE POLICE
<daniels> Kamion: sort of welsh/northern rap
<azeem> summon?
<Kamion> daniels: terrifying
<daniels> azeem: when you summon someone, you get them
<daniels> Kamion: but hillariously funny :)
<azeem> ok, but KRS-1 had that as 'sound of da police', no?
<rburton> daniels: have you heard "guns don't kill people, wabbits do" by elma fudd
<daniels> rburton: no, but I've heard Kinnison mumbling it :)
<daniels> azeem: dunno, don't listen to much krs stuff
<daniels> but anyway, we're *desperately* offtopic here
<rburton> bah
* rburton decides he needs more Herbalizer
<Kamion> dpkg: error processing /var/cache/apt/archives/base-files_3.1.0ubuntu1_amd64.deb (--unpack):
<Kamion>  trying to overwrite `/usr/X11R6/lib64', which is also in package xorg-driver-synaptics
<daniels> Kamion: /usr/X11R6/lib64?!?
<Kamion> daniels: can you just install stuff in /usr/X11R6/lib/ please?
<Kamion> daniels: base-files installs a symlink, you install a directory ...
* daniels *stares* at xorg-driver-synaptics.
<Kamion> probably didn't break until base-files got upgraded
<daniels> Kamion: unintentional, I assure you
<Kamion> np
<Kamion> just broke my upgrade, that's all :)
* daniels summons the poli-ice.
<azeem> woo! woo!
<_rene_> pitti: ping
<pitti> _rene_: pong
<pitti> _rene_: Hi, how are you?
<_rene_> pitti: you may be interested in contribution to the current discussion of debian-openoffice wrt tasksel / OOo's l10n pkgs
<_rene_> pitti: the depends _is_ needed. I outlined why
<_rene_> pitti: maybe we could do it a conflicts to the older version
<_rene_> pitti: fine, thanks
<_rene_> s/do/make/
<pitti> _rene_: I did this conflicts to older/newer versions in the mozilla locale packages, works fine
<_rene_> args, the reassigning failed
<_rene_> so it's not on -openoffice yet ;-)
<pitti> _rene_: is this possible in the template?
<_rene_> er, blah
<_rene_> I need coffe
<_rene_> it is on -openoffice
<pitti> Enjoy it :-)
<_rene_> pitti: we could do in control.lang.in, yes
<pitti> _rene_: this would be nice
<pitti> _rene_: conflicting to older and newer versions should basically do the same as a Depends to a particular version
<pitti> _rene_: are there any other difficulties apart from mixed versions?
<_rene_> not that I know of
<_rene_> one of the  majjor problems is when you want -y
<_rene_> wou *need* 1.1.3 oo.o and oo.o-bin
<_rene_> erm
<_rene_> 1.1.2
<_rene_> since only there the definitiions needed are added
<_rene_> but otherwise I see no problems except them not being removed when wanting to remove openoffice.org ;-)
<rburton> ooh, http://www.klika.si/ziga/bootchart/bootchart-rhgbfix.png is sweet
<pitti> _rene_: if you remove the language pack as well, it will be removed
<pitti> _rene_: this is exactly what we want
<_rene_> yes, but I currently am thinking only about tasksel and sarge ;-)
<daniels> Kamion: new xorg-driver-synaptics in my upload queue in chinstrap
<_rene_> as I said I am no ubuntu dev, but as you would profit from that Conflicts: sttuff too I tell you ;-)
* _rene_ doesnt like that important debian people get lesser time for releasing sarge while working on ubuntu...
<daniels> _rene_: it's just the same as work
<daniels> _rene_: when my job hacking on X fired up, I had no time for Debian
<daniels> _rene_: if you need to work long hours in a supermarket, or at a bakery, you don't always have time for Debian
<daniels> _rene_: seriously, people are only noticing more because it's another free software project
<_rene_> ah, and why don't we still have all testing-security stuff complete? when elmo now has time to do Debian stuff? (elmo: nothing personal)
<pitti> _rene_: In fact I'm now able to put more work to Debian as before
<azeem> _rene_: this is off-topic here, really
<_rene_> daniels started it, I just tought
<elmo> _rene_: don't be ridiculous, of course it's pesonal.  you're pretending  like I'm the only person in the world who can fix testing-security which blatently isn't true.
<_rene_> elmo: no. just that you and ryan can do that
<_rene_> elmo: as far as I know
<elmo> _rene_: bzzt
<elmo> and Ryan (and two of the three others) don't work for Canonical\
<daniels> elmo: have I got half an hour on concordia?
<_rene_> anyway, this really wasn't meant personal
<seb128> elmo: python-gtk2 sync please
<_rene_> this was just an example where an important person looks like he doesn't have time to do this
<smurfix> _rene_: it's still off-topic.
<elmo> _rene_: dude, if you make it personal, it doesn't matter how many times you say "it's not personal"
<_rene_> yes
<_rene_> smurfix: but since daniels and elmo responded...
<elmo> if you want to make it not personal, stop talking about me when it's not actually all on me
<_rene_> elmo: 't insult you personally
<elmo> seb128: done
<seb128> thanks :)
<_rene_> elmo: Itf it wold be personally I would have somethking like "James Troup doesn't do ...."
<smurfix> _rene_: doesn't change the fact that it isn't. Now please take it elsewhere.
<fabbione> elmo: please sync apache 1.3.33-2 from sid
<_rene_> I would call it misunderstanding
<elmo> daniels: dude, don't even ask - it's a port box, as long as it's work related, do what you want
<elmo> if I need the machine exclusively, you wouldn't even be able to login ;-)
<daniels> elmo: heh :) ok, cheers
<_rene_> smurfix: I am in here to coordinate OOo stuff.
<_rene_> smurfix: when daniels and elmo respond I think I should be able to re-respond
<elmo> fabbione: you don't have to ask me to sync stuff without 'ubuntu' in the version in hoary - it'll sync as soon as it reaches a mirror
<_rene_> anyway, this now seems to have settled down
<fabbione> elmo: oh ok..
<mvo__> elmo: how often (~changes/day) does the Packages file change currently in warty/hoary? 
<_rene_> hi mvo__ 
<elmo> mvo: hard to tell at the moment - due to ia64 uploading packages 24/7
<mvo__> hi _rene_ 
<elmo> mvo: but in theory, up to every 30 mins
<mvo__> elmo: arggggss, that's a lot. how often in debian? how often (roughtly) in warty?
<elmo> mvo: debian is once a day
<elmo> warty, I dunno, it's no 48, but it's a lot, I'd WAG at 20+
<elmo> err, not warty, hoary
<elmo> warty is like, never, except for the odd warty-security update and the incredibly rare warty-updates update
<mvo__> all right, thanks. I'm still toying with the Packages.gz diff idea
<elmo> mvo__: you could just ignore our insane update speed for that - we probably won't be able to sustain it forever
<fabbione> elmo: why not?
<mvo__> :) it would be cool for ubuntu/stable and debian then
<elmo> fabbione: more arches, bigger archives, more distributions, etc.
<elmo> and it encourages mirrors/users to sync more often, which hurts the master etc.
<fabbione> elmo: how far are we from the limit?
<fabbione> (of the 30 minutes)
<elmo> fabbione: quite away at the moment - don't worry, it's not changing in the next month or anything
<elmo> I'm just saying, it's not something I think we should guarantee we'll do indefinitely
<fabbione> elmo: i understand.. 
<fabbione> also switching from 30 minutes to 2 hours would be more than sane imho
<Kamion> daniels: thanks
<fabbione> seb128: you around?
<seb128> yes
<seb128> why ?
<fabbione> seb128: just one simple question.. is the default gdm config always shipped by the package or is it generated?
<seb128> what do you mean by "generated" ? like debconf questions to create it ?
<seb128> no, that's shipped by the package
<Kamion> generated => maintainer script presumably
<fabbione> ok
<fabbione> thanks
<seb128> np
<Kamion> fabbione: 2 hours> the current interval is absolutely fantastic when you're trying to get something fixed in a hurry, as I often have to do
<seb128> you would like to make some changes ?
<fabbione> Kamion: i fully agree with the current interval, but if we will reach the limit we will need to go one step higher.. to let say one hour....
<fabbione> but i think we can easily live with 2 hours + manual elmo's black magic if the s**t hit the fan
<azeem> btw, you guys do source-only uploads, right?
<fabbione> azeem: yes
<azeem> all the time?
<fabbione> yes
<azeem> thanks
<fabbione> azeem: still this doesn't exclude that you need to check your package before uploading
<fabbione> and bla bla bla...
<fabbione> seb128: no thanks.. there is no need to modify anything
<fabbione> seb128: i would be more glad if you will tell me in advance when there will be changes (if any)
<azeem> fabbione: heh, sure
<azeem> it should apply cleanly, at least ;)
<seb128> fabbione: ok
<fabbione> azeem: lol
<pitti> carlos: Hi!
<carlos> pitti: morning!
<pitti> carlos: morning is good - it's lunchtime
<carlos> pitti: I just wake up :-P
<carlos> so, it's morning here
<carlos> ;-)
<seb128> hey carlos 
<carlos> seb128: dude, you should confirm your flight to matar or I will be alone in the hotel :-)
<seb128> oups, sorry, I've forgotten the jabber window on a desktop the other day
<seb128> and noticed some hours after that
<seb128> I've confirmed it, just not updated the wiki
<carlos> ;-)
<robtaylor> carlos: hey :)
<carlos> robtaylor: hey!
<robtaylor> carlos: i'll be coming to mataro :) paid for my my work :)
<carlos> robtaylor: cool!
<carlos> robtaylor: which days?
<robtaylor> carlos: 9th till the 13th i think
* robtaylor checks
<robtaylor> carlos: yep, land in barcelona 16:35 on thursday, and leave 22:70 on monday
<robtaylor> s/22:70/2155
<robtaylor> i thought that looked wrong =)
<robtaylor> carlos: so hows the accessd going. did you give some thought to the black box idea?
<carlos> robtaylor: I was talking with gst's maintainer
<carlos> and he agree on the idea
<robtaylor> carlos: gst?
<carlos> gnome system tools
<robtaylor> ah :)
<carlos> but I was not able to finish the prototype this weekend
<robtaylor> cool. i bought a new laptop yesterday so i could start working on stuff again, but the hd was b0rked :(
<carlos> :-(
<robtaylor> yeah, luckily i got it from a shop so i'll get them to replace it.. i just hope it is the hd and not the controller :(
<robtaylor> carlos: didi you get much done on the prototype?
<carlos> robtaylor: nothing about dbus yet, I was playing with pygtk and did the login dialog, nothing more
<robtaylor> carlos: hmm, the login dialog is another executable, remember ;)
<carlos> I know, but part of the system
<carlos> :-)
<seb128> carlos: dude, gst=gstreamer :)
<carlos> I was working on the dialog <-> daemon communication
<carlos> seb128: nor really :-)
<carlos> seb128: both have the same letters
<robtaylor> carlos: should just be done over stdout/stdin
<carlos> robtaylor: that was my first attempt but I was getting mad with that because it didn't worked until I close the pipe
<carlos> so I moved to unix sockets
<robtaylor> carlos: definitly should just be inherited pipes..
<robtaylor> for max security
<carlos> robtaylor: as I said, I did it
<carlos> but It didn't worked
<carlos> I need a two ways channel
<carlos> and I was using two pipes
<carlos> but it always got blocked
<robtaylor> carlos: why do you need 2 way channel?
<robtaylor> just get the cleinet to send login:<bla> passwd: <bla> when its finished
<carlos> robtaylor: the server needs to tell the helper daemon if it's right or not
<robtaylor> carlos: hmm, ok, well i'll take a look at the code when i have a moment - it *should* be possible to do it with pipes
<carlos> robtaylor: if you get it working with pipes, It's perfect
<gicmo> 'morning
<herzi> can somebody please verify this: there's no character-pick applet un gnome-applets 2.9.1-0ubuntu1
<gicmo> herzi, seems like I dont have one here ..
<herzi> k
<herzi> looks like a missing build dependency
<elmo> gar.  nice way to quasi-DOS a machine, fill it's /tmp with so much crap it takes eons to boot
<daniels> elmo: yeah
<elmo> damn.  I don't even get to shout at anyone - the directories seem to be owned by me :(
<daniels> elmo: well, if you're really upset at yourself, you could slice yourself up
<daniels> the datacentre equivalent of seppuku
<fabbione> seb128: do you think you can create somekind of patch to disable the XKeepcrashing from gdm as a argument switch?
<seb128> fabbione: yeah, that should be easy to do
<daniels> why does X fail to start on the 441?
<fabbione> or as a config oprion like NoXKeepCrashing
<fabbione> daniels: no that's not the case
<fabbione> seb128: the config option would be the best solution
<fabbione> seb128: either to accept the fact that there is no XKeepCrashing
<seb128> ok
<seb128> hum, I've to go for lunch
<fabbione> seb128: or a special option that disables it
<fabbione> so do i :-)
<fabbione> i don't need it right away...
<fabbione> so don't worry :)
<seb128> there is no hurry I guess, I'll think about it during lunch :)
<seb128> later
<fabbione> bon apetit
<herzi> jdub, ping
<elmo> oh. my.  god.  could linux-source-2.6.8.1 take _any_ longer to build? :/
<daniels> elmo: could be worse, it could be OOo
<elmo> I'm pretty sure it's worse than oo.o
<daniels> seriously?
<daniels> that's impressive
<elmo> oh, no, it's about the half the  time,but still
<elmo> linux-source-2.6.8.1:   01:55:16 (5 entries, sigma 01:08:07)
<fabbione> daniels: ok after lunch :-)
<elmo> openoffice.org:         03:59:50 (1 entry, sigma 00:00:00)
<Mithrandir> OOo isn't that bad, gcc is worse, iirc.
<elmo> anyway, lunch..
<daniels> fabbione: thanks
<fabbione> daniels: no problem
<Mithrandir> elmo: a sigma of one hour is bloody much, though.
<fabbione>       db_set xserver-xfree86/config/device/driver nvidia
<fabbione>       db_set xserver-xorg/config/device/driver nvidia
<fabbione> this won't work
<fabbione> you need to setup a var for the server you are using
<fabbione> and change that to xserver-${SERVER}
<fabbione> debconf will kill the script if there is no template
<daniels> ah ok, will do
<fabbione> daniels: it's the same reason why we set +e in the data migration loop
<daniels> fabbione: try that
<fabbione> daniels: i would also do in a slightly different way.
<daniels> how so
<fabbione> you assume that either one or the other server is installed
<fabbione> but you you might have one in a non purge state
<fabbione> you assume that either one or the other server is installed and the other purged (sorry)
<daniels> mmm, fair point
<daniels> that's why I put the test for xorg first though
<daniels> if xorg.conf is there and they're running XFree86, they've downgraded
<daniels> in which case -- both pieces
<fabbione> daniels: remember that xserver doesn't purge the config if it has been customized
<fabbione> so don't rely only on the fact that the config is there
<fabbione> i think you can check using /var/lib/xfree86/{server}.roaster or md5sum
<daniels> bah
<daniels> it's a pretty good guess
<daniels> if they've purged a server, nvidia-glx-config isn't going to do them much good anyway :P
<Kamion> yay, Manoj merged the kernel-package stem patch
* Kamion goes mergy mergy
<daniels> Kamion: that sounds awfully like 'bouncey bouncey'
<daniels> (emphasis on 'awful')
<Kamion> daniels: xorg-driver-synaptics failed to build
<daniels> Kamion: ?!?
<daniels> let me hit the logs up
<Kamion> dh_installdocs
<Kamion> cp: cannot stat `changelog': No such file or directory
<daniels> interesting.
<daniels> yeah
<daniels> how incredibly bizzare
<asw> sabdfl ping 
<Kamion> elmo: please resync xemacs21 to Debian
<fabbione> doh
<fabbione> did something happended to our theme?
<fabbione> all of a sudden gdm decided to gimme back the original one with the big yellow flower
<pitti> Can someone please proofread https://chinstrap.warthogs.hbd.com/~pitti/usn-samba.txt ? TIA
<Kamion> "writing access" => "write access"
<smurfix> pitti: Whom do I ask for access? elmo?
<Kamion> otherwise looks ok to me
<pitti> Kamion: fixed, thanks for review
<pitti> Kamion: I'll publish the thing now
<pitti> Kamion: I think it is okay to give smurfix the chinstrap web password, what do you think?
<pitti> Kamion: he's now an approved developer
<Kamion> pitti: ask elmo, please, I don't know the policy
<pitti> smurfix: please ask elmo
<Kamion> seb128: #3833> should we just sync to the Debian version then?
<smurfix> I noticed ;-)
<pitti> smurfix: /me likes to play parrot :-)
<seb128> Kamion: no, we have a bunch of extra changes
<seb128> Kamion: I don't get the point to spend 1 hour to merge the changes in the debian package for nothing ... I'm missing something ot that's ok ?
<Kamion> seb128: at least merging the changelog would be good so that we can tell that without looking at the bug, then
<Kamion> there are benefits to being able to determine this sort of thing automatically
<Kamion> statistics over the whole distribution, etc.
<seb128> statistics ?
<Kamion> how many packages are completely merged with Debian
<seb128> Keybuk said it's not needed yesterday
<Kamion> I shall have to talk with Keybuk when he arrives, then
<seb128> Kamion: in we want to merge the package it'll take ... say 1 hour, there is 5-6 patch to add to the debian package ... to get nothing out of the fact to be based on the debian package
<seb128> that's wasting 1 hour imho
<Kamion> why does it take so long if everything in the Ubuntu package is in the Debian one?
<Kamion> sorry, other way round I mean
<Kamion> IMO if you don't want to do it you should leave the bug open, but *shrug*
<Kamion> remember that this sort of thing is going to provide vital clues to Malone in the future
<Kamion> it is not a no-op
<seb128> but there is no point to let it open, we don't need anything from the debian package
<Kamion> you need the changelog so that Malone can have a clue how the versions interrelate
<seb128> why does it take time ? Because apt-get source the debian package, start adding ubuntu patches, review the diff to extra stuff not added in debian/patches but directly changed, build, test ...
<seb128> easy to spend 20min (1hour is perhaps too much yes)
<Kamion> I realise that it's essentially just bookkeeping, but this sort of bookkeeping is going to keep us sane in the future
<Kamion> if you don't want to merge the packaging but just the changelogs, that's fine by me
<seb128> hum
<Mithrandir> daniels: moo?
<seb128> what's useful in the changelog ?
<Kamion> although maybe not, it isn't really a descendant
<Kamion> you have obviously never attempted to implement a version-tracking BTS. I have. :-)
<Mithrandir> dpkg: error processing /var/cache/apt/archives/base-files_3.1.0ubuntu1_amd64.deb (--unpack):
<Mithrandir>  trying to overwrite `/usr/X11R6/lib64', which is also in package xorg-driver-synaptics
<Kamion> Mithrandir: told daniels about it earlier, he's fixing
<Mithrandir> ok, goodie
<Kamion> seb128: probably best not to merge the changelog without merging the packaging, actually ...
<seb128> Kamion: still time to merge when that will be useful ...
<Kamion> seb128: the useful bit in the changelog is that it's the only possible reliable way to tell that one version of a package is based on any given other version
<seb128> Kamion: we could spare a bunch of useless merges before this time and use that time for useful work :)
<seb128> Kamion: the ubuntu package is not based on the debian version, it was here before ...
<Kamion> true
<Kamion> well, like I say, I simply disagree with closing the bug, that's all, I'm not telling you to do it now
<Kamion> there are plenty of bugs in bugzilla that it's not worth fixing yet
<seb128> I know, I'm closing it because we don't need to merge it imho
<seb128> but let me know if I'm wrong
<seb128> as said, I've already talked about this with Scott yesterday
<seb128> we should have a clear line about what we want to do :)
<Kamion> fundamentally I guess it depends whether you want to diverge GNOME forever from Debian or not
<seb128> I've no problem with merging for bookkeeping if that's useful, I just thought it was not needed
<seb128> Kamion: I include debian changes when they happen in fact, not need to be based on a debian version to do this
<Kamion> for example, if Debian applies some fix to a patch that's also in the Ubuntu package, it will be easier to tell that automatically if the packaging is similar
<seb128> and Debian's GNOME will always be late, so I don't know when we can merge
<Kamion> I realise that you can handle it now, but we need to not be relying on the heroism of individuals :-)
<seb128> true
<Kamion> the same goes for me and debian-installer, to some extent ...
<Kamion> anyway, I'll talk to Scott
<seb128> the main difference with GNOME is that we have 2.9 and debian 2.8
<seb128> taking 2.8 packages to redo 2.9 ...
<Kamion> oh, sure, but that doesn't mean that there won't be say a security patch that applies to both, and we could derive benefit from being able to detect that more automatically
<seb128> GNOME packages only have patches in debian/patches
<seb128> that should not be hard to detect automatically
<Kamion> (actually it's harder than any other type of package right now, isn't it? I didn't think Scott's merge-o-matic knew how to handle it at all
<Kamion> )
<Kamion> and no, with respect, I disagree, debian/patches/ is not a panacea
<seb128> what's the problem with debian/patches ?
<seb128> one example: take the debian packages for gdm and figure what changes are in it with the .diff.gz, good luck ...
<Kamion> can Scott's merge-o-matic deal with new patches being applied in Debian that are named differently to an Ubuntu patch but that contain the same changeset?
<Kamion> let's not have the monolithic vs. debian/patches argument again, I'm not trying to argue that
<seb128> good question, I don't know
<Kamion> I understand that it cannot
<Kamion> which may not affect you with GNOME, but which affects everyone else
<seb128> let's wait for Scott and talk with him about all this
<Kamion> ok
<Kamion> if the merge-o-matic knew how to handle your type of packaging, it could probably just spit out a source package that you could upload rather than you having to merge by hand, anyway
<Kamion> that's what most of the other distro team people are dealing with right now.
<seb128> yeah
<azeem> it could compare md5sums first perhaps, but that does not catch whitespace/indentation issues of course
<daniels> Mithrandir: moo!
<Mithrandir> daniels: kamion had already prodded you, he said -- xorg-synaptics-driver is b0rken on amd64.
<daniels> Mithrandir: yeah, just finished lunch
<daniels> uploading in a sec
<Mithrandir> goodie
<daniels> there, have a new xorg while I'm at it
<fabbione>     debian/patches/000_stolen_from_patches.diff (taken from
* fabbione hits daniels
<fabbione> i mean.. we have like: stolen_from_HEAD.diff
* fabbione sighs
<infinity> Maybe he has a dog named "patches" who wrote the patch?
<fabbione> infinity: that would be mostlikely named: stolen_from_DOG.diff
<infinity> Never attribute to malice that which you can attribute in a contrived, roundabout way, to pets.
<daniels> fabbione: it's not committed to HEAD, so putting it in stolen_from_HEAD is misleading
<daniels> fabbione: it was taken from www.x.org/pub/X11R6.8.1/patches, as I said in the header, so that seemed the most sensible thing to put
<fabbione> yeah eayh :-))
<fabbione> btw.. when do you expect to have cvs back online?
<daniels> dunno
<daniels> still got ldap to finish tonight after i finish work
<infinity> Did you find a CVS backup you're satisfied?
<infinity> s/\?$/with\?/
<daniels> yeah, I've got one I'm satisfied with -- from the 15th of October
<daniels> sigh
<fabbione> daniels: tell that's the one WITHOUT xprint :-)
<daniels> heh
<daniels> if only
<fabbione> daniels: this is a really really really ood opportunity
<fabbione> good even
<daniels> well, I think the current best plan is to say 'right, here's your CVS on the 15th of October, here's your CVS on the 15th of November; do what you like with these two snapshots'
<daniels> i have snapshots of a few projects' CVS roots from the 5th also
<fabbione> seb128: is it normal that gdm lost his ubuntu theme?
<seb128> not
<seb128> when ?
<elmo> OH MY GOD IT'S STILL BUILDING
<daniels> elmo: ... impressive
<daniels> elmo: where are you building it?
<fabbione> i am not sure.. it was a while i didn't upgrade the machine
<elmo> you know, I think that 2hour +figure is with a hot ccache
<seb128> fabbione: you have changed the gdm.conf file ?
<elmo> I could have hand-edited the binary in this amount of time
<elmo> daniels: adare
<daniels> elmo: good god
<fabbione> seb128: yes but i didn't touch the Theme part
<daniels> elmo: oh, that's with thirty-one flavours of sven crack, no?
<seb128> perhaps you broke the structure somewhat
<elmo> daniels: no, only 3 flavours, that's less than i386
<fabbione> seb128: hmmm
<daniels> elmo: oh
<fabbione> seb128: is there any automatic check i can use?
<seb128> fabbione: not afaik
<azeem> did you consider splitting up the web archives for, say, ubuntu-users to several pages?
<daniels> elmo: are we going to get the customary triumphant salute when it finishes? :)
<daniels> elmo: (wappers, not shaft)
<fabbione> seb128: yeah. it looks like something related to the config
<elmo> Kamion: done
<elmo> daniels: meh
<fabbione> seb128: it was a permission problem
<seb128> ok
<Kamion> elmo: ta
<Kamion> elmo: (you meant xemacs21, right?)
<Kamion> speaking of Sven, I have a Pegasos here
<lamont_r> morning
<elmo> Kamion: right
<elmo> sed's fixed now right?
<Kamion> so I'm told, I haven't managed to actually test it myself though quite yet
* ..[topic/#ubuntu-devel:elmo] : Ubuntu development -- general discussion and support on #ubuntu | Hoary is here: http://lists.ubuntu.com/archives/ubuntu-announce/2004-October/000005.html | Want to help? see https://www.ubuntulinux.org/wiki/HoaryGoals | archive.ubuntu.com going down briefly for reboot
<Kamion> there's a bizarre comment in #3771 suggesting that the current powerpc version is broken, which I want to test myself first
<lamont_r> daniels/fabbione?
<daniels> lamont_r: sup
<lamont_r> s3 video chipset with ancient monitor + xorg or xf86 -> nfg
<lamont_r> you want a log and config?
<daniels> yes please
<daniels> through BZ if you will
<lamont_r> ok. gimme a bit
<fabbione> lamont_r: did you notice python_gtk2 failed to build?
<fabbione> because of a md5sum mismatch
<lamont_r> fabbione: working through noticing lots of such things....
<fabbione> ok
* ..[topic/#ubuntu-devel:elmo] : Ubuntu development -- general discussion and support on #ubuntu | Hoary is here: http://lists.ubuntu.com/archives/ubuntu-announce/2004-October/000005.html | Want to help? see https://www.ubuntulinux.org/wiki/HoaryGoals
<Mithrandir> fabbione: what's the state of ubuntu@sparc?
<daniels> elmo: topicdiff?
<fabbione> Mithrandir: building phase0. almost everything as expected.
<smurfix> daniels: -archivr reboot
<smurfix> archive
<Mithrandir> fabbione: ok, anything I can help you with?
<fabbione> Mithrandir: Total 248 package(s)
<fabbione> left to build
<fabbione> Mithrandir: not yet i think
<fabbione> Mithrandir: until you don't want to setup a buildd :-)
<Mithrandir> ok, when is it ready for me to bootstrap off?
<Mithrandir> I have a few sparcs I want to get flying.
<elmo> bah, sucks, if you install lilo and switch to grub, you don't get the nice menu.lst
<fabbione> Mithrandir: we will need to work on the installer sometimes after i pass phase1
<Mithrandir> I have a small pile, as I said.  Two 333MHz boxes, can get two 270MHz ones as well
<daniels> ah, right
<fabbione> Mithrandir: right now i am building ubuntu on top of sid
<Kamion> _rene_: can you point me to where I can get the patch for #281643, or is RSN going to be in the next day or so?
<Kamion> _rene_: I want working Ubuntu CDs :-)
<fabbione> Mithrandir: finished this phase i need to manually sort out the dep-wait (like gnome2.8 and xorg)
<fabbione> Mithrandir: completed that phase, we need to rebuild all ubuntu on top of ubuntu
<Mithrandir> ok.
<Mithrandir> tell me when I can do something useful.
<fabbione> Mithrandir: right now only extra buildd's would help
<Mithrandir> if I set up Debian on the boxes, can you take it from there or do you want help running them as well?
<fabbione> Mithrandir: if you are up for them, we can make the setup sunday
<_rene_> Kamion: http://cvs.debian.org/oo-deb/debian/rules.diff?r1=1.241&r2=1.242&cvsroot=debian-openoffice
<fabbione> Mithrandir: i can take it from there, yes
<fabbione> Mithrandir: i will need some sudo access and stuff like that
<_rene_> Kamion: it will go in once I catch joeyh and change one thing more in the packages or not
<Mithrandir> obviously, and I will need to kill you if you do $stupid_stuff on the network.
<Mithrandir> fabbione: I'll see if I can get them netinstalled later today.
<fabbione> Mithrandir: other than scp'ing packages in/out.. no
<fabbione> ah.. and a configured MTA
<fabbione> i need to get mail back from the buildd
<fabbione> but no need for me to send them
<fabbione> to it
<Mithrandir> fabbione: it's an academic network; copying shit is just fine.  We won't notice until you start going >> 10MBit/sec.
<fabbione> ahah no way i can manage that from here
<Kamion> _rene_: hm, we have a forked version anyway, I might just apply that
<lamont_r> fabbione: X11/Xauth.h not found. - what is nas missing?
<daniels> lamont_r: libxau-dev
<daniels> lamont_r: what exactly are you building??
<lamont_r> daniels: looking at the build logs (in this case, nas)
<fabbione> lamont_r: from yesterday daniles is your X guy :P
<daniels> lamont_r: craaaaaaack.
<lamont_r> daniels is my X-bitch.  got it.
<lamont_r> Build-Depends: xlibs-static-dev, libsm-dev, libice-dev, libx11-dev, libxt-dev, libxaw7-dev, xutils, bison, flex, file, po-debconf
<lamont_r> oh, look. xlibs-static-dev.
<daniels> sub out xlibs-static-dev
<daniels> anything reverse-depending on xlibs-static will be broken, pretty much
<daniels> (xlibs-static -> xlibs-static-{dev,pic})
<lamont_r> so file bugs and assign them to you.  got it.
<lamont_r> :-)
<daniels> yeah, pretty much
<daniels> but you get to fix this one :)
<lamont_r> are they debian bugs, or just us
<lamont_r> daniels: np
<lamont_r> xlibs-static == xlibs-static-{dev,pic}, eh?
<lamont_r> yes?
<daniels> right
<daniels> they're just us
<lamont_r> daniels: 3860, btw.  if I get a fix today then I can help the poor user when I next visit his house before I head home saturday....
<Mithrandir> amu: *prod*?
<daniels> lamont_r: lspci output?
<Mitario> hey all
<daniels> lamont_r: it could well be one of the few cards which are unsupported in xfree86 4.x and above s3
<daniels> lamont_r: (try vesa)
<lamont_r> daniels: not near the machine right now.
<lamont_r> was s3 though for sure...
<lamont_r> how does one "try vesa", just to be clueless and off-topic?
<daniels> just change Driver "s3" to Driver "vesa"
<daniels> and you might want to nuke the BusID while you're at it
<lamont_r> doh
<Kamion> lamont_r: are the amd64 buildds particularly clogged right now?
* lamont_r looks
<lamont_r> shouldn't be
<ironwolf> lamont_r: is xlibs mis-behaving in hoary today?
<lamont_r> ironwolf: nah - it's an xf86->xorg change thing
<daniels> what'd I miss?
<ironwolf> lamont_r: (gvim:6415): Gdk-WARNING **: locale not supported by Xlib what's that? and how do I fix?
<lamont_r> daniels: he's referring to your answer earlier, I xpect...
<lamont_r> ah
<lamont_r> ironwolf: that's a locale thing
<daniels> ironwolf: if I knew how to fix it, my head would hurt a lot less
<ironwolf> daniels: does that mean there isn't currently a fix? or that it's complicated?
<daniels> ironwolf: both
<Kamion> lamont_r: wondering why they're lagging on xorg-driver-synaptics is all; tell me to sod off if I'm just being too impatient
<lamont_r> oh, those are ftbfs
<lamont_r> dh_installdocs
<lamont_r> cp: cannot stat `changelog': No such file or directory
<lamont_r> dh_installdocs: command returned error code 256
<enrico> Hello.  Someone knows the IRC nick of Jane Silber (if she has one?)
<Mithrandir> enrico: silbs
<enrico> Mithrandir: thanks!
<lamont_r> Kamion: on all 3 architectures
<Kamion> lamont_r: that's the last version back
<lamont_r> oh.  well then sod off. ;-)
<Kamion> mmkay :)
* lamont_r goes and looks more
<lamont_r> sigh... sed is not my friend
<lamont_r> grumble
<lamont_r> Kamion: fixed
<Kamion> lamont_r: heh, thanks
<lamont_r> Kamion: fwiw, I hadn't really fixed the config on yellow when I started the buildd back up - it's all better now.  (sigh(
<lamont_r> fabbione: thanks for pointing me to the real current status of sasl2 and friends (rebootstrapping those on ia64)
<lamont_r> fabbione: where does wartylog wind up (for this channel)?
<daniels> fabbione: http://people.ubuntu.com/~fabbione/irclogs/
<gicmo> sladen, did you get the mail?
<Kamion> #3861 is freaky
<daniels> Kamion: crack
<daniels> hm, this 8-bit version of Freestyler is pure crack
<daniels> daniels@catsby:~/canonical/xfree86/foo/libx11-6-dbg/usr/X11R6/lib/debug% export LD_LIBRARY_PATH=en_US.UTF-8
<daniels> more caffeine this way
<daniels> gnarcrackgnar
<infinity> daniels : S'ok.  Early today, I mindlessly typed "apt-get install ll" when a shell alias wasn't defined.
<daniels> heh
<sladen> gicmo: yup, I did.  I'll answer it at some point too ;-)
<sladen> who runs mailman around here?
<Kamion> that would be jdub I think
* sladen fetchs the ICBM from yesterday and looks around for jdub
<Mithrandir> sladen: what's wrong with mailman now?
<daniels> i wish I had've looked at that jelly bean instead of eating it straight away -- it was really nice, and I don't know which colour it was
<sladen> Mithrandir: nothing.  After a new list
<daniels> Keybuk: 'morning
<Keybuk> daniels: *cough* yeah
<Kamion> oh, baby jesus WEPT, I have to build the openoffice.org source again because it has CVS directories in the source package and my default debuild configuration kills those
<infinity> And you want to ship them, why?
<daniels> Kamion: oops
<Kamion> minimising diff against Debian
<Kamion> makes merges sane later
<infinity> So, file a bug against the Debian packages to remove the CVS dirs. :)
<haggai> infinity: they are there on purpose
<infinity> (and arch dirs too... Those really irritate me)
<Kamion> arch directories in source packages seem to contain a lot more guff
<haggai> I meant the CVS dirs
<haggai> I'm not sure what you mean by arch dirs
<Kamion> {arch}, .arch-ids
<Kamion> i.e. tla
* #ubuntu-devel  [freenode-info]  why register and identify?  your IRC nick is how people know you.  http://freenode.net/faq.shtml#nicksetup
(Mitario/#ubuntu-devel) hi mvo_ 
<mvo_> hi Mitario 
(daniels/#ubuntu-devel) LKJE
(Kamion/#ubuntu-devel) _rene_: isn't 'grep -v -en' wrong? grep will interpret the -en as an option
(Kamion/#ubuntu-devel) $ (echo openoffice.org-l10n-en; echo openoffice.org-l10n-fr) | grep -v -en
(Kamion/#ubuntu-devel) $
(Mithrandir/#ubuntu-devel) it will, yes.
(Kamion/#ubuntu-devel) _rene_: you need 'grep -v -- -en'
(Mithrandir/#ubuntu-devel) it will grep for n, just, afaik
(Kamion/#ubuntu-devel) it'll use -n as an option; standard getopt behaviour ...
(Kamion/#ubuntu-devel) or maybe not?
(Kamion/#ubuntu-devel) oh, no, you're quite right
(Mithrandir/#ubuntu-devel) nope, it'll use n as the pattern, since what follows -e is the regex
(Mithrandir/#ubuntu-devel) quite confusing, though
* Kamion is thankful he didn't upload
(rcaskey/#ubuntu-devel) btw, anyone played with OOo's new database tool yet?
(rcaskey/#ubuntu-devel) It's definately a start
(Kamion/#ubuntu-devel) Can anyone post a translation of #3863 to the bug?
(Kamion/#ubuntu-devel) it's Spanish, I think
(trukulo/#ubuntu-devel) going
(Kamion/#ubuntu-devel) thanks
(Mithrandir/#ubuntu-devel) I think he's complaining that his pen drive isn't automagically mounted and that he's told the list which told him to bug report it.
(trukulo/#ubuntu-devel) Dear developers. I've got a Abit AN7 uGuru Motherboard with Nvidia mcp-t chip, and usbpen doesn't mount automatically.
(trukulo/#ubuntu-devel) he said he can mount it by hand, but not automatically
(Kamion/#ubuntu-devel) to the bug :-)
(trukulo/#ubuntu-devel) :) sorry
(Mithrandir/#ubuntu-devel) I'm surprised my translation was that accurate -- I don't know spanish or any latin languages at all :)
(trukulo/#ubuntu-devel) very accurate Mithrandir 
(Mithrandir/#ubuntu-devel) "Escribi en la lista de ubuntu en espaol y me dijeron que me notificara este bug" is roughly "I posted to the spanish ubuntu list and was asked to bugfile this"?
(_rene_/#ubuntu-devel) Mithrandir: oh, it will?
(_rene_/#ubuntu-devel) Mithrandir: hmpf
(_rene_/#ubuntu-devel) Kamion: thanks
(Mithrandir/#ubuntu-devel) _rene_: : tfheen@shonap ~ > grep -en /etc/passwd | wc -l
(Mithrandir/#ubuntu-devel) 30
(Mithrandir/#ubuntu-devel) : tfheen@shonap ~ > grep -- -en /etc/passwd | wc -l
(Mithrandir/#ubuntu-devel) 0
(trukulo/#ubuntu-devel) doing mi bugzilla account
(_rene_/#ubuntu-devel) hmm
(trukulo/#ubuntu-devel) need password to post bug translation
(daniels/#ubuntu-devel) ka-BAM.
(daniels/#ubuntu-devel) narrowed down the locale issue
(trukulo/#ubuntu-devel) daniels, so tuesday 14 ?
(_rene_/#ubuntu-devel) obvious
* _rene_ womnders why he didn't think about that
(daniels/#ubuntu-devel) WOO WOO SUMMON THE PO-LICE
(trukulo/#ubuntu-devel) Kamion, bug translated
(Kamion/#ubuntu-devel) trukulo: thanks
(_rene_/#ubuntu-devel) Kamion: thanks, fixed
(trukulo/#ubuntu-devel) you're wellcome
(trukulo/#ubuntu-devel) see you soon kamion :) IRL
(daniels/#ubuntu-devel) trukulo: sounds good to me, but you'll probably want to check with others
(trukulo/#ubuntu-devel) daniels, confirmed with jane
(trukulo/#ubuntu-devel) tuesday 14 at 7pm
(trukulo/#ubuntu-devel) we only need confirmation of jdub
(daniels/#ubuntu-devel) awesome!  i'll be there
(trukulo/#ubuntu-devel) and he said to me he wants to
(trukulo/#ubuntu-devel) :)
(trukulo/#ubuntu-devel) want to know you all (except fabbione, lol)
(daniels/#ubuntu-devel) heh
(lamont_r/#ubuntu-devel) Kamion: d-i unhappy on ppc
(Kamion/#ubuntu-devel) lamont_r: howso?
(lamont_r/#ubuntu-devel) udev-udeb depends hotplug but it is not installable
(Kamion/#ubuntu-devel) debian-installer build you mean?
(lamont_r/#ubuntu-devel) yes
(lamont_r/#ubuntu-devel) sorry for the lack of clarity
(Kamion/#ubuntu-devel) what's the i386 failure about, anyway?
(daniels/#ubuntu-devel) Kamion: so, dude.
(daniels/#ubuntu-devel) daniels@catsby:~% export LANG=en_AU.UTF-8
(daniels/#ubuntu-devel) daniels@catsby:~% export LC_ALL=$LANG
(daniels/#ubuntu-devel) daniels@catsby:~% gedit
(daniels/#ubuntu-devel) [type some stuff] 
(daniels/#ubuntu-devel) daniels@catsby:~%
(Mithrandir/#ubuntu-devel) daniels: you know how useless it is to set LANG and LC_ALL?  LC_ALL overrides.
(lamont_r/#ubuntu-devel) Kamion: looks like a burp in the bubble we call reality
(lamont_r/#ubuntu-devel) retrying
(daniels/#ubuntu-devel) Mithrandir: well, I'm just being very sure
(Kamion/#ubuntu-devel) lamont_r: hmm, ok, so I suck, fixing
(daniels/#ubuntu-devel) Mithrandir: the point was the lack of OMG XLIB H8S UR LOCALE
(Mithrandir/#ubuntu-devel) daniels: to be even more sure, export the variable twice. :P
(Kamion/#ubuntu-devel) daniels: bonus
(Kamion/#ubuntu-devel) lamont_r: (it'll be a udev upload)
(daniels/#ubuntu-devel) that bug was an utter bastard to track down
(lamont_r/#ubuntu-devel) Kamion: anything I should d-w on?
(lamont_r/#ubuntu-devel) or will you just tell me to kick it in an hour or 2?
(Kamion/#ubuntu-devel) lamont_r: udev-udeb 0.042-1ubuntu3 (if you can d-w on udebs)
(Kamion/#ubuntu-devel) otherwise udev 0.042-1ubuntu3
(lamont_r/#ubuntu-devel) >=?
(Kamion/#ubuntu-devel) sure
(lamont_r/#ubuntu-devel) the retry on i386 was a mirror of ppc
(lamont_r/#ubuntu-devel) the retry on i386 was a mirror of ppc
(lamont_r/#ubuntu-devel) xfree86:                02:24:12 (3 entries, sigma 00:16:01)
(lamont_r/#ubuntu-devel) grumble
(Kamion/#ubuntu-devel) seb128: is nautilus-media meant to be in universe?
(Kamion/#ubuntu-devel) daniels: hm, you mean it was an issue just with the en_US.UTF-8 definition?
(daniels/#ubuntu-devel) Kamion: afaict, and probably others as well
(daniels/#ubuntu-devel) Kamion: but it only manifests in this particular combination
(daniels/#ubuntu-devel) Kamion: so I tried regressing libraries and stuff first, and ended up tearing hair out
(Kamion/#ubuntu-devel) thought somebody'd reported it with en_AU.UTF-8 too
(daniels/#ubuntu-devel) same definition
(daniels/#ubuntu-devel) (i'm running in en_AU.UTF-8 now)
<seb128> Kamion: yes
<seb128> Kamion: it's not really useful and doesn't work very well
(Kamion/#ubuntu-devel) hm, ok
(Kamion/#ubuntu-devel) does that mean you don't want to handle its merge bug? :)
<seb128> oh no, just assign it to me
<seb128> I've probably zapped it
* ..[topic/#ubuntu-devel:elmo] : Ubuntu development -- general discussion and support on #ubuntu | Hoary is here: http://lists.ubuntu.com/archives/ubuntu-announce/2004-October/000005.html | Want to help? see https://www.ubuntulinux.org/wiki/HoaryGoals | website downtime due to server reboots
(Kamion/#ubuntu-devel) seb128: ok
(elmo/#ubuntu-devel) can someone try logging into the website please?
(elmo/#ubuntu-devel) the ubuntulinux.org one I mean
(jdz_/#ubuntu-devel) elmo: It works, I'm logged in.
(elmo/#ubuntu-devel) jdz_: have you logged in just now though ?
(elmo/#ubuntu-devel) I need someone without an existing cookie to try logging, if possible
(Kamion/#ubuntu-devel) elmo: works for me, logged in just now
(elmo/#ubuntu-devel) Kamion: excellent thanks
(jdz_/#ubuntu-devel) elmo: Just now.  First time on this computer
(elmo/#ubuntu-devel) jdz_: thanks
(elmo/#ubuntu-devel) ok, now for the actual web server
<Kyaneos> hi
(lamont_r/#ubuntu-devel) mdz ain't around, is he...
* ..[topic/#ubuntu-devel:elmo] : Ubuntu development -- general discussion and support on #ubuntu | Hoary is here: http://lists.ubuntu.com/archives/ubuntu-announce/2004-October/000005.html | Want to help? see https://www.ubuntulinux.org/wiki/HoaryGoals
(Kamion/#ubuntu-devel) lamont_r: nope
(amu/#ubuntu-devel) a usbcdrom is handled as sda or scd? 
* lamont_r prepares to upload apt_0.5.30ubuntu1
(lamont_r/#ubuntu-devel) :-)
<seb128> fabbione: here ?
(lamont_r/#ubuntu-devel) apt uploaded
<seb128> somebody did a xfree warty-security upload ?
(elmo/#ubuntu-devel) daniels did, I think
<seb128> an user is complaining on #ubuntu-fr that he can only use 640x480 now
<seb128> and he was using 1024x768 before the security update
(lamont_r/#ubuntu-devel) so how do I force reportbugs to send the mail to a specific address, I wonder.
<fabbione> seb128: X belongs to daniels now :-)
<seb128> ok
<seb128> BTW do you have an idea on what could cause this ?
<seb128> I would like to reply something to the guy
<fabbione> seb128: probably an inconsistency in the debconf information
<fabbione> seb128: just tell him to use dpkg-reconfigure
<seb128> ok
<daniels> what'd I miss?
<seb128> daniels: 
<seb128> <seb128> an user is complaining on #ubuntu-fr that he can only use 640x480 now
<seb128> <seb128> and he was using 1024x768 before the security update
<daniels> ehm
<daniels> that's complete crack.  nothing changed but libXpm.
<seb128> ok
<seb128> thanks :)
<daniels> no worries
(lamont_r/#ubuntu-devel) @ERROR: max connections (25) reached - try again later
(lamont_r/#ubuntu-devel) r
(lamont_r/#ubuntu-devel) sigh...
(lamont_r/#ubuntu-devel) should archive.ubuntu.com be happier?
<fabbione> Mithrandir: are you still around?
<fabbione> daniels: we need to prepare a few slides for the talk...
<fabbione> daniels: and decide what to talk about
(amu/#ubuntu-devel) fabbione: 20:13 <Mithrandir> I'm off for some food and beer
<fabbione> amu: thanks :-)
(amu/#ubuntu-devel) fabbione: he told me also ... , drop me a /msg .... 
<fabbione> nah
<fabbione> it's nothing urgent
<fabbione> lamont_r: and this update is going to take forever
<fabbione> xorg and xfree86 the same day
(lamont_r/#ubuntu-devel) fabbione: shame on you. :-)
<fabbione> no no
<fabbione> I AM NOT X MAINTAINER ANY
<fabbione> MORE
(lamont_r/#ubuntu-devel) hehe
<fabbione> ops
<fabbione> sorry
(lamont_r/#ubuntu-devel) really?  well shame on daniels then. :-)
<fabbione> i _didn't_ want to use the C4P5 L0CK
<seb128> fabbione: what do you do know so ? :)
<fabbione> seb128: keeping an eye on daniels :P
<seb128> ah ah
<fabbione> if he fucks up i am going to hunt him down like an eagle on a rat
(jdub/#ubuntu-devel) fabbione: you're not going to be doing X maintenance for debian or ubuntu?
<fabbione> ubuntu
(jdub/#ubuntu-devel) whatcha going to be doing?
<fabbione> jdub: other stuff
(jdub/#ubuntu-devel) heh
(jdub/#ubuntu-devel) no kidding!
<daniels> fabbione: yeah
<daniels> fabbione: not now though
<daniels> fabbione: if i'm not working and i'm behind a computer, it's fd.o
<fabbione> daniels: j/k kid :P
<fabbione> daniels: for the presentation it's enough we think about something during Mataro
<fabbione> no need to do it *right now*
<daniels> yeah
(elmo/#ubuntu-devel) pitti: ?
(lifeless/#ubuntu-devel) daniels: so how is the recovery coming?
<FTTP> hi
<FTTP> fabio! :)
<fabbione> yes?
<FTTP> i sent u a bug report earlier 
<mxpxpod> daniels: any progress on the xorg utf-8 thing?
<FTTP> dunno if its a bug or not 
<FTTP> fabbione:  is there a workaround for monitors that dont provide appropriate DDC?
<fabbione> no
<fabbione> FTTP = Adam?
<FTTP> yep
<FTTP> i left some comment
<FTTP> s
<fabbione> i am reading them now
<FTTP> ok
<FTTP> i only put reopen cause i had some additional comments
<FTTP> not sure if it was worthy of reopen
<fabbione> "am I correct in assuming that Windows 
<fabbione> cant correctly detect this information either? "
<fabbione> yes
<daniels> mxpxpod: fixed
<FTTP> i figured that
<daniels> lifeless: yeah, not too bad thanks
<fabbione> if it detects higher rates than what the monitor can really handle it's a bug
<mxpxpod> daniels: nice
<daniels> lifeless: just making LDAP my bitch
<pitti> elmo: back, phone
<mxpxpod> daniels: when's it going to be uploaded?
<fabbione> FTTP: also.. there are monitors that claims to be DDC compliant and they are not
<fabbione> FTTP: it won't be the first time
<daniels> mxpxpod: probably two days
<FTTP> fabbione:  right..... i understand.....
<fabbione> FTTP: nv or nvidia makes no difference. The driver comes from the same people
<fabbione> FTTP: other than 3d features
<mxpxpod> daniels: also, what's up with fonts on xorg... example: http://www.reigndropsfall.net/screenshots/coaster-main.png compared to http://www.reigndropsfall.net/screenshots/coaster-main-new.png
<fabbione> it's exactly the same crap
<FTTP> fabbione:   ok, on the refresh rate issue
<fabbione> FTTP: please wait for the next X release. We have a bunch of updates for the nv driver
(lifeless/#ubuntu-devel) daniels: cool
<FTTP> fabbione:  Yep :)
<fabbione> iirc it includes also something DDC related
<daniels> mxpxpod: they look nice on -new and crap on -main?
<fabbione> FTTP: i am talking about X.org 1ubuntu4 at least
<mxpxpod> daniels: they look strange on -new
<fabbione> not the one that come out today
<FTTP> fabbione:  can the xfree you use tho handle the higher refresh rates where its just an X config problem?
<mxpxpod> daniels: I guess I'm just used to the way they look in -main
<fabbione> FTTP: as last thing, please add your config file and /var/log/Xorg.0.og to the bug
<daniels> mxpxpod: to me, that's a 100% improvement :)
<mxpxpod> daniels: really?
<daniels> yah
<fabbione> FTTP: that's a very hairy thing.
<FTTP> fabbione:  Hairy? 
<spotter> anyone here suffering from frequent crashes in evolution in hoary?
<mxpxpod> daniels: to me, it looks like the letters are running into each other
<fabbione> FTTP: the protocol works more or less in this way:
<daniels> mxpxpod: mmm
<FTTP> fabbione:  See my monitor can do higher refresh rates in windows ......
<fabbione> FTTP: driver attempts to detect rates.
<mxpxpod> daniels: especially when e and a are together
<FTTP> im wondering if its just the xfree config file causing the lower rates to be used
(ironwolf/#ubuntu-devel) spotter: yes *must be daniels fault*
<fabbione> FTTP: than it grabs the info from the config file
<fabbione> FTTP: let me finish please :-)
* spotter wonders what ironwolf has against daniels 
<fabbione> FTTP: now the black magic happen
* ironwolf loves daniels... he's the xorg God. :)
<fabbione> FTTP: where there are 4 combinations
<fabbione> a) ddc return - data in config file -> driver uses the safest data from the two set of info
<fabbione> so for ex.
<mxpxpod> daniels: btw, you've done a good job on xorg for ubuntu
<daniels> thanks
<fabbione> ddc returns a VertSync 49-120
<daniels> fabbione needs credit for xorg too tho
<fabbione> config has 50-80
<fabbione> hem
<fabbione> config has 40-80
<fabbione> the safe value is 49-80
<mxpxpod> fabbione: good job
<fabbione> mxpxpod: thanks :-)
<fabbione> FTTP: are you following me?
<mxpxpod> I didn't think any debian based distro would have it for years
<mxpxpod> :)
<FTTP> yep
<fabbione> b) ddc return - no config info
<fabbione> the driver has to trust the ddc info
<fabbione> c) no ddc return - config info
<fabbione> the driver trust what you say
<fabbione> d) no ddc - no config
<fabbione> the driver goes bana
<fabbione> banana
<fabbione> so basically the combination is not simple
<fabbione> in your case you might have to try to disable the values in the config
<FTTP> gotcha
<fabbione> but this is something we canNOT do by default
<fabbione> we can't allow people to hit case d)
<FTTP> fabbione:  it did an excellent job in making it work
<fabbione> that's because we chose a safe and reliable path
<fabbione> for "details"
<fabbione> that's up to the user
<fabbione> we can't push over what we know
(lamont_r/#ubuntu-devel) daniels: if you need me to punch ironwolf, just say so. :-)
<fabbione> simply because i can't efford to start replacing monitors all over the glob
<fabbione> globe
<jdz_> fabbione, very good to know, thanks!
(lamont_r/#ubuntu-devel) oh wait, common guest-rules prevent that.
* ironwolf loves fabbione too.... just less. ;)
<fabbione> ironwolf: ?!?!
<FTTP> right....... would be nice tho if those could be selected in an easier manner 
(ironwolf/#ubuntu-devel) fabbione: was in response to something someone said.
<fabbione> FTTP: we are going to re-discuss the autodetection implementation in Mataro during DecConf
<FTTP> ok thanks :)
<FTTP> fabbione:  Seems like you already know about this stuff 
<fabbione> FTTP: it's kinda like because i have been maintaing X for almost a year?
<fabbione> FTTP: if you want some fun try this:
<FTTP> fabbione:  no no i mean the bug i reported which is not a bug :)
<fabbione> exit from X
<FTTP> yeah your work is excellent
(infinity/#ubuntu-devel) fabbione : That IS fun!
<fabbione> mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup
<fabbione> and restart X
<FTTP> im not in linux right now but ill try that 
<fabbione> you will test the new Xorg autodetecion policy engine
<fabbione> no need to reconfigure anything
<fabbione> just run it :)
<FTTP> sounds kewl
* jdz_ runs off to try it
<fabbione> FTTP: we don't know how good it is yet
<FTTP> fabbione did u put the files u wanted me to send over in the bug report ?
<FTTP> easier for me to remember that way
<fabbione> FTTP: i can't put YOUR files in the bug report :-)
<FTTP> no i mean the names
<fabbione> just your config and your Xorg.0.log
<fabbione> no i didn't
<fabbione>  /etc/X11/xorg.conf and /var/log/Xorg.0.log
<FTTP> well ill just save that to notepad, no biggie
<FTTP> im in windows now
<FTTP> oh u mean for the new xorg detection mechanism?
<FTTP> should i send both over? 
<fabbione> no.. only the normal one please
<fabbione> play and experiment AFTER
<FTTP> ok
<FTTP> fabbione wait xorg.conf is the config file?
<fabbione> yes
<FTTP> for the current ?
<FTTP> ok
<FTTP> confused me there
<fabbione>  jdz_ runs off to try it
<fabbione> i killed a user
<fabbione> if he is not back in the next 2 minutes, there will be a new bug report for daniels
<FTTP> quick question for any takers:  i need to redo my grub boot partition cause i had problems with windows 
<FTTP> whats the easiest way for me to reinstall grub without being able to get into my system?
<FTTP> kinda sounds stupid i know 
<FTTP> <grin>
<fabbione> FTTP: this is more for #ubuntu :P
<FTTP> yeah i tried what they said 
<FTTP> couldnt get it to work 
<FTTP> oh well ill ask there again, thanx
<FTTP> maybe i did it wrong
<FTTP> its coming across nicely tho
<FTTP> cant wait for hoary :)
<fabbione> good night everybody
(sivang/#ubuntu-devel) night fabbione
<FTTP> night fabbione
<FTTP> thanks 
(lamont_r/#ubuntu-devel) Kamion: ??
(lamont_r/#ubuntu-devel) +ackages.gz  Sub-process bzip2 returned an error code (100)
* lamont_r giggles
(lamont_r/#ubuntu-devel) grumble
(lamont_r/#ubuntu-devel) 26-7=19.  4 hours probably too long
(lamont_r/#ubuntu-devel) grumble
(ironwolf/#ubuntu-devel) night fabbione
(lamont_r/#ubuntu-devel) seb128: you around?
<seb128> yes
(lamont_r/#ubuntu-devel) why does python-gtk2_2.4.1.orig.tar.gz have a bogus md5sum?
(lamont_r/#ubuntu-devel) grumble.
* lamont_r will fix
(lamont_r/#ubuntu-devel) just had the need to bitch, and all that.
<mvo_> lamont_r: where did you got the "Packages.gz Sub-progcess bzip2" error?
<seb128> the md5 is bogus ? or that was you ? :)
<seb128> I got this one too
<seb128> on a fresh install while doing an apt-get update
(lamont_r/#ubuntu-devel) mvo_: that was the latest round of debian-installer build failures.
<seb128> bzip2 was not installed
(lamont_r/#ubuntu-devel) fixed by upgrading apt to the current version
(lamont_r/#ubuntu-devel) right.
(lamont_r/#ubuntu-devel) 0.5.30ubuntu1 Depends: bzip2 
<mvo_> ah, great
* lamont_r is unsure why python-gtk2 is bad-md5sum...
<seb128> should not, I've not changed the orig.tar.gz in hoary
<seb128> jdub: around ?
(lamont_r/#ubuntu-devel) mvo_: and bug filed with debian
<mvo_> lamont_r: about the bzip2? 
<mvo_> it's not yet in debian apt IIRC
(lamont_r/#ubuntu-devel) yes
<mvo_> I wrote it yesterday I think
(lamont_r/#ubuntu-devel) Why install postfix at all ? Procmail would do the same job.
* lamont_r snickers
<mvo_> or the day before maybe
<mvo_> isn't that cool? we file bugs before they even can happen ;)
(lamont_r/#ubuntu-devel) mvo_: I figured it was mdz's package, with a debian-native version number, so _must_ be in debian, right?
(lamont_r/#ubuntu-devel) except that the bug is in .30, and debian has .27... oops.
<mvo_> yeah
<mvo_> he will merge the stuff pretty soon I guess
<mvo_> IIRC there is nothing ubuntu specific in the diffs
(lamont_r/#ubuntu-devel) well, he has to get back from vacation first. :-)
(lamont_r/#ubuntu-devel) or whatever he's doing that he's away from the computer...
<mvo_> heh :) he'll be back on monday I think?
(lamont_r/#ubuntu-devel) yeah
(jdub/#ubuntu-devel) seb128: here
<seb128> jdub: could you comment on #3871 :)
<seb128> +?
<seb128> I don't remember exactly the details of what we have decided about this
<pitti> Kamion: still here?
(jdub/#ubuntu-devel) seb128: definitely no template files by default
(jdub/#ubuntu-devel) seb128: as discussed on list
(jdub/#ubuntu-devel) seb128: actually seeding the directories... undecided. :)
<pitti> daniels: here?
<daniels> sup
<daniels> ah, yeah
<daniels> wanted to talk to you about the CAN stuff
<daniels> it appears CAN 0914(?) is relevant to our xfree86 update (sigh; I explicitly asked if there was a new one, and was told no)
<seb128> jdub: ok, so no decision about if/where ~/Templates should be created ...
<seb128> jdub: thanks
#ubuntu-devel 2004-11-30
<pitti> OUT NOW: new warty kernels
<seb128> jdub: what's the rationnal to not provide any Templates ? I've read the discussion about this, the idea has been finally dropped but not sure of why
<pitti> advisory novel sent out, kthxbye and good night everybody!
<seb128> 'night pitti 
<pitti> Night seb128!
<daniels> night pitti
<mvo_> night pitti 
(jdub/#ubuntu-devel) seb128: that's the user's space. if we add templates, admins add templates, packages add templates, and everyone adds templates... it'll be as useless as the Windows "New" menu
<seb128> right ..
<calc> so the user has to make their own templates?
<calc> or copy them into a special dir from somewhere else?
* jdub fears pitti's latest security release
<daniels> jdub: THE ONLY THING WE FEAR IS FEAR ITSELF
<daniels> jdub: (AND DAVID HASSELHOLF RAPPING)
<Keybuk> pingu++
<daniels> glc++
(Kamion/#ubuntu-devel) lamont_r: apt depending on bzip2 sounds bogus, since that makes bzip2 effectively Essential: yes; can't it just fall back quietly to gzip if bzip2 isn't installed?
<mvo_> Kamion: I can do this tomorrow
(Kamion/#ubuntu-devel) mvo_: thanks
(lamont_r/#ubuntu-devel) Kamion: very true...
(lamont_r/#ubuntu-devel) Kamion: was after something to unbreak the archive, as in 'fix it right now to not be dead anymore'...
(jdub/#ubuntu-devel) $ cat /proc/cpufreq
(jdub/#ubuntu-devel)           minimum CPU frequency  -  maximum CPU frequency  -  policy
(jdub/#ubuntu-devel) CPU  0       600000 kHz ( 42 %)  -    1000000 kHz ( 71 %)  -  userspace
(jdub/#ubuntu-devel) 
(jdub/#ubuntu-devel) eh, bong
<daniels> jdub: 600MHz -> 1GHz?
(jdub/#ubuntu-devel) mmm, should be 1.4 (100%)
(mjg59/#ubuntu-devel) jdub: Doesn't that just mean that userspace has set the maximum frequency to 1GHz?
(jdub/#ubuntu-devel) what's set it?
(mjg59/#ubuntu-devel) Dunno
(mjg59/#ubuntu-devel) The proc interface is deprecated, anyway
(mjg59/#ubuntu-devel) Fiddle with stuff in /sys
(jdub/#ubuntu-devel) $ cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
(jdub/#ubuntu-devel) 1400000
<shaya> is sed safe again?
(jdub/#ubuntu-devel) yes
<moyogo> ahhh, my nautilus and gnome-panel are dead
<lamont_p> moo
<lamont_p> palm ui sucks for irc
<lamont_p> l8R
<mxpxpod> daniels: ping
<daniels> pong
<mxpxpod> daniels: ok, I have another font issue... tiles look like hash marks with bitstream vera sans
<daniels> i have no idea, sorry
<daniels> fonts hurt my head
<mxpxpod> daniels: ok, didn't know if you knew
<mxpxpod> daniels: what do you have your dpi set to?
<daniels> 75, probably
<lamont_p> sigh.  ma
<lamont_p> x chan count of _2_
<fabbione> morning
* lamont_r ponders news readers... should he put emacs21 or lynx in the alternatives list?
<pitti> Morning everybody!
* pitti watches the snow falling
(jdub/#ubuntu-devel) pitti: mm, sounds nice :) morning
(jdub/#ubuntu-devel) it's very, very hot here
<pitti> jdub: we have -1C here
<pitti> jdub: for me it's odd to imagine to celebrate Xmas in short pants :-)
(jk/#ubuntu-devel) 22:40 @     Xiph| maar op de HCC stond er een meisje
(jk/#ubuntu-devel) 22:40 @     Xiph| en die was _zo_ _mooi_
(jk/#ubuntu-devel) oops
<tuo2> pitti: it's 22c here atm.
<pitti> wow
<fabbione> pitti: just for lazyness, is the CAN for the kernel fixed in hoary?
<pitti> fabbione: according to Herbert yes
<fabbione> ok
<fabbione> cool
<fabbione> Total 197 package(s)
<fabbione> uhhh
<fabbione> (left to build on phase0)
<fabbione> hmmm
<fabbione> i think we overlooked something...
<fabbione> xfree86 in warty ubuntu25.1
<fabbione> in hoary 25
<fabbione> we should probably do the last xfree86 upload with server only
<fabbione> and the security fix
<fabbione> even if it is not involved
<fabbione> that would alligm the packages properly
<fabbione> otherwise the source is still contaminated
<seb128> morning
<fabbione> morning seb :-)
(lamont_r/#ubuntu-devel) fabbione: daniels up yet?
<fabbione> lamont_r: no idea... he is uk
(lamont_r/#ubuntu-devel) seb128: gnome-applets wasn't happy yesterday, btw
(lamont_r/#ubuntu-devel) fabbione: ah, ok
(lamont_r/#ubuntu-devel) http://people.ubuntu.com/~lamont/daniels/ has ia64 MANIFEST for xorg
(lamont_r/#ubuntu-devel) and I'm going to sleep now.
<fabbione> lamont_r: cool thanks
<fabbione> did you add .ia64 .ia64.new ?
<fabbione> because we need both
(lamont_r/#ubuntu-devel) fabbione: debian/*ia64*
<fabbione> cool
(lamont_r/#ubuntu-devel) and msg'ed to him as well. :-)
* lamont_r sleeps
<fabbione> night :-)
* jdub cheers pitti on hal list
<pitti> thx
<pitti> jdub: I don't really understand why David insists on the "root, root everywhere" paradigma
* jdub doesn't either - his email sounded really odd
<pitti> seb128: Hi! Thanks for demozillafying swfdec! Was it reasonably easy?
<seb128> np, yes it was pretty easy
<trukulo> hi ppl
<seb128> morning
<trukulo> morning too :)
<pitti> mvo_: Egon! I always knew!!! Now it's public
* pitti chuckles
<mvo_> morning pitti 
<pitti> mvo_: Morning! :-) BTW, you should correct the subject of your activity reports if you send them after midnight :-)
<mvo_> I should stop working before midnight :)
<pitti> mvo_: I have told this to myself for weeks now, but I eventually gave up
<mvo_> it's a hard time for security people. too many things to fix :/
(jdub/#ubuntu-devel) pitti: vicious kernel update, btw.
<pitti> mvo_: actually it calmed down a little. Three weeks ago I did nothing else, though
<pitti> jdub: why, did something break?
(jdub/#ubuntu-devel) pitti: no, just the number of fixes
(jdub/#ubuntu-devel) surprising and scary
<pitti> jdub: oh, yes. It was half a novel of an advisory :-)
(jdub/#ubuntu-devel) started reading the advisory... "ow, that's bad"... "oh, there's more"... "oh, more..."
<pitti> jdub: but given the amount of time, monkeys and typewriters that you actually need to exploit this ELF bug, delaying the update to accumulate some patches did not really hurt
(jdub/#ubuntu-devel) heh
<pitti> jdub: the smbfs thingy was more serious, though
<fabbione> hey daniels 
<pitti> Hi daniels 
<fabbione> daniels: we need to do a xfree86 upload into hoary
<daniels> fabbione: mmm
<fabbione> hoary: ubuntu25 <- no sec fix
<daniels> we can just retarget .1 to hoary
<fabbione> warty: ubuntu25.1 + security fix
<fabbione> no we can't
<fabbione> let me finish
<fabbione> the source is contaminated
<fabbione> so
<fabbione> my idea is to upload a .26 that will build only the servers
<fabbione> that's all we need at the end
<fabbione> and after that move them into universe
<daniels> what do you mean, source is contaminated?
<fabbione> daniels: if you do apt-get source xfree86 in hoary
<trukulo> fabbione, do you know where can i find nxfree packages for debian? want to make a test about that on conferences
<fabbione> you don't get the security update
<fabbione> trukulo: no sorry
<trukulo> and you daniels ?
<trukulo> now that kalyxo and fdo are down...
<fabbione> daniels: the changes should be pretty simple.. so i can take care of it
<daniels> trukulo: dunno, i only knew it was hosted on kalyxo
<fabbione> daniels: there is no need for you to work on it
<trukulo> thx anyway
<daniels> fabbione: right -- so why not just do a ubuntu26 with no changes other than 25->25.1?
(jdub/#ubuntu-devel) trukulo: Mithrandir might know, when he's around
<fabbione> daniels: because a simple .26 will bring all the libs with it
<trukulo> thanks jdub, i'll ask him
<fabbione> daniels: and katie will reject the upload
<daniels> ok
<fabbione> daniels: because there are newer versions from x.org
<fabbione> to be more precise katie will reject the binaries from the buildd
<daniels> right
<fabbione> not the source
<daniels> personally I think we could well kill off xfree86 in hoary altogether, but -- your call
<fabbione> daniels: i think we should keep it around still for a little bit
<fabbione> specially when a massive amount of people will start switching to hoary
<fabbione> but for sure we will kill it before release
<fabbione> i would say to keep it around until the beginning of Febrary
<fabbione> February even
<daniels> ok
<pitti> elmo: can you please sync pmount 0.4.2-1 from Debian? 
<fabbione> just that people can still switch back and forward if needed
<daniels> is there really a call for doing that, thought?
<daniels> s/thought/though/
<daniels> given how much of '4.3.0' was really from xorg
<fabbione> daniels: well our x.org isn't that spreaded around yet
<daniels> right
<daniels> but if we create an xserver-xfree86 package that just deps xserver-xorg ...
<fabbione> so if the new server doesn't work for somebody and the fix can take long time
<fabbione> they can still revert and use the old one
<daniels> i think that kind of regression would be staggeringly rare, though
<fabbione> i agree, but it is still a possibility
<daniels> i mean, given nv was from xorg wholesale, and massive chunks of ati were also
<pitti> fabbione: do the irc logs have a new URL? The old one just gives 404
<tuo2> daniels: how's the recovery going?
<fabbione> pitti: yes.
<daniels> alright, your call -- I just think we should take the opportunity to trim down our hoary support obligations
<daniels> tuo2: very, very good
<fabbione> daniels: moving it to universe = no support
<fabbione> daniels: just a goodie for people to revert if required
<tuo2> daniels: nice one. Normally a compromise recovery is a PITA.
<pitti> fabbione: hmm, wrong question. Can you please tell me the new URL? :-)
<daniels> fabbione: i suppose
<fabbione> pitti: there is a temporary URL, but i forgot to tell elmo to add the alias
<fabbione> pitti: people.u.c/~fabbione/
<pitti> fabbione: ah, thanks
<fabbione> no problem
<daniels> tuo2: yes, but the amount of stuff we got done last night (i got ldap authentication and userdir-ldap working, plus dns, mail and the lists processing, plus got a couple of archives up; infinity and cworth got moin and virtual hosting working properly; keithp got pserver working)
<daniels> tuo2: plus the fact we're doing it really well, unlike the previous pile of shit
<daniels> anyway, off-topic
(Mithrandir/#ubuntu-devel) Kamion: I don't see why removing any entries from /etc/hosts should change anything, as the application gets the IPv6 address to connect to from DNS.
<fabbione> hey Mithrandir 
<trukulo> Mithrandir, do you know where i can get freenx that were on kalyxo?
<trukulo> and morning
<fabbione> trukulo: why not trying googling?
(Mithrandir/#ubuntu-devel) hi fabbione, trukulo
<fabbione> Mithrandir: i found something you can start to play with :-)
<trukulo> fabbione, i did
<fabbione> Mithrandir: linux-kernel-*_sparc.deb ;)
<trukulo> but fdo and kalyxo are down
(Mithrandir/#ubuntu-devel) fabbione: rock.
<fabbione> Mithrandir: that needs quite a lot of love..
<Matt|> *laughs*
(Mithrandir/#ubuntu-devel) trukulo: it's freedesktop.org; daniels is working on it and it should be back withing a few days.
<fabbione> Mithrandir: and clearly we will need the *-di-* kernel too
<trukulo> ok, thx anyway, but i already know that
<trukulo> try to continue searching
(Mithrandir/#ubuntu-devel) trukulo: I'd just wait a few days
<trukulo> yes, but i want them to make a demo for conference, and want to try them well before
<trukulo> ok, forget me and keep on working :)
<seb128> Kamion: not sure than "nautilus" is better than "UNKNOW" if the bug is not a nautilus one ... do we have a "general" component or something like that ?
(Kamion/#ubuntu-devel) seb128: afraid not
<seb128> Kamion: if that's "nautilus" it'll stay on my list and nobody is going to handle it
(Kamion/#ubuntu-devel) where would be better?
(Kamion/#ubuntu-devel) I was assuming that it must be some part of GNOME
(Kamion/#ubuntu-devel) it's certainly not the job of anything beneath that
<seb128> or skel :)
<fabbione> daniels: does the patch from x.org/patches include the previous CAN fixes or it has to be applied on top?
(Kamion/#ubuntu-devel) yeuch, if I could veto that I would
(Kamion/#ubuntu-devel) even so, it would be GNOME's responsibility to add it to skel if such a solution were being considered
<seb128> we already had this discussion
(Kamion/#ubuntu-devel) it is not the responsibility of the base system, definitely
<seb128> right
(Kamion/#ubuntu-devel) so ... is there a suitable base GNOME package?
<seb128> the problem with the assignement to nautilus is that it's in y list of bug and I'm not going to take a decision on this
(Kamion/#ubuntu-devel) if not I guess assigned to you but component UNKNOWN would be workable
<seb128> I'll reassign to mdz or jdub
(Kamion/#ubuntu-devel) bleh, ok
<seb128> the problem is:
<seb128> 1- I'm not sure we need to create it by default
(jdub/#ubuntu-devel) Kamion: you're okay with other packages adding stuff to skel?
<seb128> 2- which part should create it (the installation or an app)
(Kamion/#ubuntu-devel) seb128: oh, sorry, I didn't realise that you had already reassigned it to UNKNOWN
<seb128> np
(Kamion/#ubuntu-devel) seb128: I wish bugzilla showed me that in the web history of the bug
<seb128> we should have a component "general distro issue"
(Kamion/#ubuntu-devel) jdub: /etc/skel is *there* for other packages to add stuff to; but since you ask I'm not OK with non-dotfiles being created there
<seb128> jdub: doable ?
(jdub/#ubuntu-devel) Kamion: i didn't think your earlier explanation was convincing enough for me to see why it was dangerous. it sounded more like "obviously it is bad". could you write some more about why it's a bad idea in that bug?
(Kamion/#ubuntu-devel) jdub: it means that users who never use the desktop get this directory they never care about, and it suggests that some part of GNOME has a bug because it's relying on /etc/skel and adduser to create a directory it should be taking care of itself.
(jdub/#ubuntu-devel) this isn't a gnome policy thouhg, it's a distro policy
(Kamion/#ubuntu-devel) jdub: also, some people use useradd, which doesn't create that directory (it was even in some documentation on our wiki for a while)
<seb128> GNOME doesn't rely on it, it just use it if available
(Mithrandir/#ubuntu-devel) it also means only locally created users will get the directory
(Kamion/#ubuntu-devel) Mithrandir: indeed, was just going to get on to that
(Kamion/#ubuntu-devel) NIS/NFS systems are a reality
(Kamion/#ubuntu-devel) jdub: distros can patch GNOME :)
(Mithrandir/#ubuntu-devel) as well as systems being upgraded from what we have now.
(Kamion/#ubuntu-devel) jdub: by "GNOME bug" I mean "bug in GNOME as configured for us"
<daniels> fabbione: 6.8.1 includes the fixes for 0687 and 0688 already, so it needs to be applied on top of the existing package
<fabbione> daniels: i was more wondering about xfree86 :-)
<daniels> fabbione: er yeah, just badly phrased, sorry
<daniels> fabbione: so you'll need to apply it on top of the 0687/0688 fixes you already have
<fabbione> did you apply that patch on top 000_stolen_from_x.org.diff ?
<fabbione> ok
<fabbione> thanks
<daniels> except!
<daniels> it looks like that code changed in x.org (hurrah!)
(elmo/#ubuntu-devel) pitti: done
<daniels> so you need to dig the original xpm-sec7.patch (or .diff) from your mailbox, and use that instead
<daniels> because that applies cleanly against xfree86 with the 0687/0688 patch
<fabbione> daniels: ah ok
<fabbione> i was rediffin the other one
<daniels> walking that route is pain; just grab mathieu's xpm-sec7 and apply it on top of what you have already
<fabbione> cool
<fabbione> thanks
<daniels> no worries
<fabbione> i got the same rejects
<fabbione> never mind
<fabbione> they are trivial to fix
<fabbione> most of them just white spaces
(Kamion/#ubuntu-devel) jdub: comments added to bug
(Kamion/#ubuntu-devel) seb128: (I have a "New Ubuntu bugs" query; I've been trying to go through it each morning and assign as many of the debzilla@ubuntu.com / UNKNOWN bugs somewhere, since they tend to get lost otherwise ...)
<daniels> fabbione: remove #099d
(jdub/#ubuntu-devel) Kamion: thanks!
<daniels> fabbione: #099d is the single thing that's breaking UTF-8 support
(azeem/#ubuntu-devel) jdub: did you have time to try those multisync packages?
(jdub/#ubuntu-devel) azeem: yeah, i was telling you about them as i was using them :)
(azeem/#ubuntu-devel) ah, so they work for you?
<pitti> elmo: thanks
(jdub/#ubuntu-devel) yes
(jdub/#ubuntu-devel) but multisync makes me cry :|
(azeem/#ubuntu-devel) yeah, yeah
<fabbione> daniels: ah
(azeem/#ubuntu-devel) there was an initial opensync release last week I believe
<seb128> Kamion: right. We should have a "general purpose" component 
(Kamion/#ubuntu-devel) seb128: would be fine by me
<seb128> jdub: "general purpose" component doable ? :)
<seb128> or whatever is the name
<seb128> a component for general distro issues
<daniels> fabbione: how were the manpages actually corrupted?
(Kamion/#ubuntu-devel) jdub: (workflow: UNKNOWN = nobody has dealt with this yet; general = somebody has looked at this, but diagnosis suggests it requires widespread changes)
<fabbione> daniels: there were __something__ not being parsed properly
(jdub/#ubuntu-devel) Kamion: yeah
<daniels> fabbione: blah
(Kamion/#ubuntu-devel) hm, we have a lot of open merge bugs on universe
<daniels> fabbione: right now I'll take the manpage hit for UTF-8 in Hoary
<daniels> fabbione: i'll open up the Debian bug and we can work on it
(jdub/#ubuntu-devel) seb128: what was the directory creatino bug # ?
(Kamion/#ubuntu-devel) daniels: <perks up> man page bugs?
<fabbione> daniels: the problem is only in xorg
<fabbione> daniels: due to that crackified patch
<daniels> Kamion: http://bugs.debian.org/259996
<daniels> Kamion: the patch for that is what's smacking UTF-8 locales to hell in Hoary
<seb128> jdub: 3871
<daniels> Kamion: since you're our cheap imit^W^Wnew shiny mdz, d'you know if there's any way to import Debian bugs into our BZZ?
<daniels> s/BZZ/BZ/
(Kamion/#ubuntu-devel) daniels: I know (in the abstract) how mdz did it, but I don't have access ...
<daniels> ahr
(Kamion/#ubuntu-devel) elmo: who's got access to debzilla on macquarie? AFAIK it runs under mdz's userid or something similarly crackful
<daniels> yeah, it involves SSHing to macquarie (which I can't do), as mdz (which I can't do), and then running a script :)
(elmo/#ubuntu-devel) Kamion: yes, it is :(
(elmo/#ubuntu-devel) if you know what commands to run, I can do that
(Kamion/#ubuntu-devel) elmo: I don't, I'm afraid; might be able to find out
(jdub/#ubuntu-devel) seb128: thanks
<seb128> np
(Kamion/#ubuntu-devel) daniels: what was wrong with the original man page text? the hyphens?
(Kamion/#ubuntu-devel) daniels: or something else?
<daniels> Kamion: the bug report's too incoherent for me to decipher
<daniels> Kamion: i plan to revert the patch and see ofr myself
<daniels> Kamion: but it looks like there's raw '\n' in the stream?
<mvo_> is there a opionion about putting libgnome2-perl into main? it's needed by debconf if you want a non-text frontend.
(Kamion/#ubuntu-devel) elmo: I *believe* it's 'debzilla-sync <bug numbers>', but I don't know if there's any weird environment crap required
(Kamion/#ubuntu-devel) elmo: mdz's .bash_history might be greppable for that? :)
(Kamion/#ubuntu-devel) mvo_: it sounded reasonable to me when it was last suggested
(Kamion/#ubuntu-devel) jdub: was libgnome2-perl left out deliberately, or as an oversight?
(jdub/#ubuntu-devel) left out of main?
(Kamion/#ubuntu-devel) I guess it pulls in a bunch of perl stuff, let's see
(Kamion/#ubuntu-devel) yeah
<mvo_> it's only 4 perl modules that a not yet in main (according to a shallow dependency view)
<mvo_> libglib-perl, libgnome2-canvas-perl, libgnome2-vfs-perl, libgtk2-perl
<daniels> Kamion: heh
(Kamion/#ubuntu-devel) daniels: \n> oh, I see, can't say I can decipher the bug report either
<daniels> Kamion: well, let's find out, shall we? :)
(Kamion/#ubuntu-devel) daniels: perhaps it's that the trailing backslash is missing? comparing to current xterm(1) ...
(Kamion/#ubuntu-devel) daniels: (the UTF-8 hyphen thing is due to using - rather than \-, BTW)
<daniels> Kamion: er, current xterm(1) is broken as hell anyway
(Kamion/#ubuntu-devel) current in Debian ...
<daniels> Kamion: 'The default bindings in the VT102 window are:' -- everything below here is absolute arse
<daniels> Kamion: well, Ubuntu
(jdub/#ubuntu-devel) Kamion: nothing depended on it, wasn't of great interest, etc. :)
(Kamion/#ubuntu-devel) it looks OK to me on Debian, there's some overflowing lines but apart from that it's fine
<daniels> wtf?
(Kamion/#ubuntu-devel) jdub: ah, we missed the suggests from debconf then
<daniels> Kamion: yeah, it's broken as hell on Ubuntu, UTF-8 or not
* Kamion chroots to look
(jdub/#ubuntu-devel) Kamion: (i don't buy into supporting the bindings if we don't have anything or anyone (customers, user demand) that uses them)
(Kamion/#ubuntu-devel) bleh! yes
(Kamion/#ubuntu-devel) jdub: synaptic wants to pop up the GNOME frontend to debconf by default
(Kamion/#ubuntu-devel) jdub: so will we, eventually :)
(Kamion/#ubuntu-devel) (graphical d-i => graphical base-config)
(jdub/#ubuntu-devel) yeah
* jdub growls at generated gui hate
(jdub/#ubuntu-devel) sucks the salt out of baby jesus' eye sockets
(Kamion/#ubuntu-devel) daniels: oh, I see, newlines being eaten
(Kamion/#ubuntu-devel) jdub: depends on the direction you're coming at it from; you could argue that a generated gui is better than no gui
(jdub/#ubuntu-devel) i wouldn't
<daniels> jdub: heh!
(Kamion/#ubuntu-devel) at least for consistency of presentation if you have other gui pieces
(jdub/#ubuntu-devel) no gui means no stupid questions :-)
<daniels> jdub: body shots off baby jesus?
(Kamion/#ubuntu-devel) jdub: you'd rather have some gui bits and then flip back to text mode?
(jdub/#ubuntu-devel) daniels: don't tell sabdfl 
(jdub/#ubuntu-devel) Kamion: no stupid questions! :)
(Kamion/#ubuntu-devel) jdub, meet reality ;-)
(Kamion/#ubuntu-devel) jdub: gui != questions, consider progress bar for installing packages
(jdub/#ubuntu-devel) ...
(jdub/#ubuntu-devel) no stupid questions!
(Kamion/#ubuntu-devel) (not that we have one of those in debconf yet, but we will)
<daniels> Kamion: we tried introducing them once before, but they just sort of sat across the room and scowled at each other, then jeff told his friend to tell reality he was a tool
(jdub/#ubuntu-devel) it's bloody hard making a generated gui work nicely
(jdub/#ubuntu-devel) so hard, i don't think it's worth bothering
(jdub/#ubuntu-devel) you end up with ncurses + 3d buttons
(Kamion/#ubuntu-devel) it's perfectly fine for simple dialogs
<daniels> jdub: THREE DEE
(jdub/#ubuntu-devel) Kamion: dude, you could use zenity for all the d-i gui stuff :)
(Kamion/#ubuntu-devel) jdub: yabbut that's all you need for a package-installation progress bar
(Kamion/#ubuntu-devel) zenity? *looks*
(Kamion/#ubuntu-devel) heh
(jdub/#ubuntu-devel) it's pretty rad
<mvo_> jdub: so you rather would like to remove the "configure" menu option in synaptic? 
(Kamion/#ubuntu-devel) well, debconf supports Xdialog, so theoretically
(jdub/#ubuntu-devel) mvo_: settings menu?
(Kamion/#ubuntu-devel) not sure it wouldn't be a major negative surprise to people running debconf in an xterm though
<mvo_> there is a option to configure debconf packages in synaptic. it depends on libgnome2-perl though. 
(jdub/#ubuntu-devel) oh right
<seb128> elmo: gnome-keyring sync please
(jdub/#ubuntu-devel) yeah, that's what Kamion was talking about
(elmo/#ubuntu-devel) seb128: done
(Kamion/#ubuntu-devel) also, if we're doing graphical base-config, I rather suspect it won't have a terminal at all, which will make it difficult to revert to text mode ;)
<mvo_> I just wonder if we shouldn't remove the option from synaptic if we don't want libgnome2-perl in main anyway
(Kamion/#ubuntu-devel) mvo_: looks like I want it in main and jdub disagrees
<mvo_> it has my vote for main too :)
<daniels> hold on ... we branched off -6
(Kamion/#ubuntu-devel) anyone want to do an equivalent of /usr/share/pixmaps/debian-logo.png for Ubuntu, for the debconf GNOME frontend?
(jdub/#ubuntu-devel) Kamion: oh, i don't disagree, just saying what we did for warty
<daniels> Kamion: could you please set a UTF-8 locale in sid (4.3.0.dfsg.1-7) and tell me if it's arse?
(Kamion/#ubuntu-devel) daniels: I run UTF-8 pretty much everywhere
<daniels> Kamion: quickest way to tell is to start gedit on the console and see if it bitches really loudly
(jdub/#ubuntu-devel) Kamion: yeah
(jdub/#ubuntu-devel) Kamion: file me a bug :)
(Kamion/#ubuntu-devel) mkay :)
(Kamion/#ubuntu-devel) hey, how come I can't reassign bugs to the Live CD product?
<seb128> elmo: thanks
(Kamion/#ubuntu-devel) jdub: ah, ok; mind if I add it to supported now then?
(jdub/#ubuntu-devel) ok
(Kamion/#ubuntu-devel) mvo_: done, not installed by default though
<mvo_> Kamion: thanks!
(Kamion/#ubuntu-devel) elmo: please sync bittornado (universe)
(Kamion/#ubuntu-devel) elmo: please sync bayonne (universe); capi20 support added upstream so the warty change is obsolete now
(Kamion/#ubuntu-devel) elmo: please sync aqsis (universe); libtiff4 transition done in Debian
(Kamion/#ubuntu-devel) elmo: please sync albatross (universe)
* Kamion wonders if elmo would prefer the flood by e-mail
<lupus_> xmms is broken in woody after recent security updates
(Kamion/#ubuntu-devel) woody?
<fabbione> elmo: can you compare ubuntu python-gtk2_2.4.1-1 orig with the debian one? apparently there are some md5sum mismatches.
<fabbione> elmo: http://people.no-name-yet.com/~lamont/buildLogs/p/python-gtk2/2.4.1-1/
<fabbione> apparently the 2 are different
<fabbione> andour is wrong
<fabbione> and our
(Kamion/#ubuntu-devel) elmo: please sync camlimages, cinepaint, ctypes, djvulibre, dx, ecasound (universe); misc build-dep stuff all fixed in Debian
<fabbione> Kamion: is there any showstopper on hoary d-i ?
<fabbione> or can we start testing it?
(Kamion/#ubuntu-devel) fabbione: array cd 1 works fine; you can try it in hoary dailies but it's in major flux right now so expect breakage :)
(Kamion/#ubuntu-devel) fabbione: (though feel free to report breakage)
<fabbione> Kamion: sure..
(Kamion/#ubuntu-devel) fabbione: I'm just in the middle of switching to udev/hotplug
(Kamion/#ubuntu-devel) mvo_: apt upload> yay, thanks
<fabbione> Kamion: cool
<mvo_> Kamion: yeah, I broke it afterall :P
<lupus_> I mean
<lupus_> warty
<lupus_> sorry
(Kamion/#ubuntu-devel) lupus_: please file a bug with details
<seb128> grrr
<seb128> the proftpd upgrade has broken my ftp
(elmo/#ubuntu-devel) fabbione: dude, anyone can do that - if it's different, it's because a different one was originally upload to ubuntu.
(elmo/#ubuntu-devel) Kamion: all done
<fabbione> elmo: dude.. i did check my side and the 2 differs, but after a sync from sid there are problems.
(elmo/#ubuntu-devel) fabbione: why are you talking to me about it?  it's not my problem
<fabbione> elmo: so since i don't have any way to fix it in the archive.. i was a) asking to confirm b) perhaps you can fix it, since you know what happened
(elmo/#ubuntu-devel) if we upload a different orig.tar.gz to ubuntu.   we lose.
<fabbione> elmo: because i don't have the history of automatic sync?
(elmo/#ubuntu-devel) you don't need it
(elmo/#ubuntu-devel) and I can't fix it anymore than you can - as with any "orig.tar.gz filename clash", the upstream version needs changed
(Kamion/#ubuntu-devel) elmo: thanks
<fabbione> elmo: can't we just replace the orig.tar.gz?
(elmo/#ubuntu-devel) no
(elmo/#ubuntu-devel) for exactly the same reason Debian won't do that
<fabbione> ok
<seb128> which package ?
<fabbione> seb128: python-gtk2
<seb128> hum
<seb128> we don't need to sync, but the .orig should be the same
<fabbione> it's not
<seb128> ok, just ignore it so
(elmo/#ubuntu-devel) seb128: dude, we can't :)
<fabbione> seb128: it FTBFS :-)
<seb128> bah
(elmo/#ubuntu-devel) seb128: we have Debian's .dsc which refers to Debian's .orig.tar.gz, but we have Ubuntu's .orig.tar.gz
<seb128> right
<seb128> just redo a 2.4.1b tarball so :p
<fabbione> Kamion: the netboot kernel and initrd.gz have changed location in the archive and they have been lost from the CD, do you want a bug for it?
(Kamion/#ubuntu-devel) fabbione: sure, debian-cd component
<fabbione> ok
<fabbione> Kamion: 3887
<herzi> jdub: ping
(Kamion/#ubuntu-devel) elmo: more universe stuff for you to sync: gem, gnome-gpg, grass, gtkhtml, gtkpbbuttons, hp2xx, hylafax, kdebase, kdegraphics, kdemultimedia, kdenetwork
<fabbione> OPS
(Kamion/#ubuntu-devel) I've a horrible feeling that KDE is going to require fixes to build against X.org, but no way am I spending significant work time on that ...
<herzi> :)
<fabbione> Kamion: sorry... i think i opened the same bug twice
(jdub/#ubuntu-devel) herzi: pong
(jdub/#ubuntu-devel) Kamion: we'll have help :)
<herzi> jdub: can you plz update my hackerhead on planet? http://www.advogato.org/person/herzi/
(elmo/#ubuntu-devel) Kamion: syncing
(Kamion/#ubuntu-devel) fabbione: np, duped
<fabbione> Kamion: yeah.. middle air collision :)
(jdub/#ubuntu-devel) herzi: your eyes are closed and the contrast/colour is terrible :)
(elmo/#ubuntu-devel) mvo_: err, dude, I thought mdz explicitly wanted bz2 tried first?
(Kamion/#ubuntu-devel) fabbione: um ... that was a deliberate change, can you just unpack netboot/netboot.tar.gz now?
(elmo/#ubuntu-devel) that's certainly how he explained it to me, in any event
(Kamion/#ubuntu-devel) fabbione: it's got all the stuff in it, I didn't see any reason to waste CD space by duplicating it
(elmo/#ubuntu-devel) oh, I have to file all those fun Xserve d-i/kernel bugs - blah
<herzi> jdub: isn't that good for a hackergotchie? :)
(jdub/#ubuntu-devel) herzi: we have QA standards, dude ;)
<mvo_> elmo: he put my patch in, I fix the piece and take the blame
<herzi> so if you update the hackergotchie we'll see whether the qa team is just you :)
<herzi> .oO(why do people cann themselves a "team"?)
<herzi> call
<fabbione> Kamion: well... before it was one step less.. i had the symlinks poiting from the tftp area to the images...
(jdub/#ubuntu-devel) herzi: i recommend posting a photo for the gimpers to hackergotchi-ise :)
<fabbione> now i need to unpack and so on...
<fabbione> (yeah.. it's lazyness)
<mvo_> elmo: (the bzip2 patch was put in 0.5.30 by mdz)
* herzi blogs about lanet and QA now...
<mvo_> elmo: fear my pdiff patch ;)
(Kamion/#ubuntu-devel) fabbione: yeah, I know, but the netboot.tar.gz is convenient for people who don't have an existing setup
(Kamion/#ubuntu-devel) fabbione: although I guess I could unpack the whole lot onto the CD, and leave out netboot.tar.gz maybe?
<fabbione> Kamion: i suggest to leave the netboot.tar.gz 
<fabbione> it takes less space
<fabbione> Kamion: perhaps you can leave just the kernel and initrd out?
(Kamion/#ubuntu-devel) those are the bulk of the space, dude :)
(Kamion/#ubuntu-devel) I might as well unpack the lot
(Kamion/#ubuntu-devel) the rest is ~30KB
<fabbione> ok
<fabbione> let's unpack it
<fabbione> so people can just mount the cd
<fabbione> and point the tftp to it
<fabbione> and BANG! it works
<fabbione> not even the need of untarring
(Kamion/#ubuntu-devel) and actually the netboot.tar.gz seems to be negligibly smaller at best
<fabbione> Kamion: 3905 is going to give you a lot of headacke
(Kamion/#ubuntu-devel) fabbione: hah. I hate udev sometimes
<fabbione> Kamion: it's not only udev
(Kamion/#ubuntu-devel) fabbione: why is that bug on debian-cd?! :)
<fabbione> it's also hotplug
(Kamion/#ubuntu-devel) yeah
<fabbione> they are the apocalipse of race conditions
<fabbione> so we have a netinstall component?
(Kamion/#ubuntu-devel) fabbione: I need to redesign ddetect for hotplug anyway, and that may fix it
(Kamion/#ubuntu-devel) uh, no, dude, you don't file installer bugs against the CD :-)
(Kamion/#ubuntu-devel) reassigned to partman
(Kamion/#ubuntu-devel) debian-installer's the catch-all if you don't know the udeb involved
<fabbione> but it's not a partman fault
(Kamion/#ubuntu-devel) it'll do for now
<fabbione> ok
(Kamion/#ubuntu-devel) maybe it's ddetect, we'll see
<fabbione> eheh ok
* Kamion flips it to ddetect
<fabbione> argh.. my eyes!
<fabbione> :)
<fabbione> ah cool!
<fabbione> it's installing warty :-)
(Kamion/#ubuntu-devel) what, hoary netboot?
(Kamion/#ubuntu-devel) oops
<fabbione> Kamion: http://www.fabbione.net/IMG_0632.JPG
<fabbione> this is phase 2 with framebuffer
<fabbione> other than the stripes on the monitor
<fabbione> that are caused by a almost broken video card
<fabbione> the "3D" effect seems broken...
<fabbione> Kamion: yeah.. from netboot :P
(Kamion/#ubuntu-devel) fabbione: where did it say it was installing warty?
<fabbione> hmmm
<fabbione> some apt lines
(Kamion/#ubuntu-devel) before reboot?
(Kamion/#ubuntu-devel) I thought I'd fixed all of that :(
<fabbione> no phase2
(Kamion/#ubuntu-devel) ./apt-setup.templates:7:Choices: warty, hoary
<fabbione> it's baseconfig
(Kamion/#ubuntu-devel) ./apt-setup.templates:8:Default: warty
(Kamion/#ubuntu-devel) hm, oops
<fabbione> we should kill that template
* Kamion fixes
<fabbione> one installer x release
<fabbione> :)
(Kamion/#ubuntu-devel) nah
(Kamion/#ubuntu-devel) it's useful for people who need a fix from the newer installer for their hardware, but don't want to install the development release
(Kamion/#ubuntu-devel) at least in principle, as for whether we'll actually be able to support that we'll see
(Kamion/#ubuntu-devel) fabbione: fixed, thanks
<fabbione> Kamion: no problem dude!
<fabbione> i love to test d-i..
<fabbione> specially with this setup :)
<fabbione> it's like: f12 -> enter -> enter
<fabbione> Kamion: did you check the pic?
<pitti> fabbione: "every chicken can install Debian. Just keep pecking on Enter" .-)
<fabbione> pitti: hahaha
<pitti> fabbione: whoops, my smiley lost an eye
<fabbione> no bigge
(Kamion/#ubuntu-devel) fabbione: do you mean the lack of outline around the dialog?
<fabbione> Kamion: yup
(Kamion/#ubuntu-devel) fabbione: I think that's something to do with dialog in UTF-8
(Kamion/#ubuntu-devel) seems to have forgotten how to do line-drawing characters
(Kamion/#ubuntu-devel) fabbione: is the console otherwise properly configured for UTF-8?
<fabbione> is it a known problem in debian too?
<fabbione> Kamion: that's from reboot entering phase2
(Kamion/#ubuntu-devel) Debian don't default to UTF-8 so I wouldn't imagine many people have noticed
(Kamion/#ubuntu-devel) most use of debconf is probably in xterms etc.
<fabbione> i didn't touch anything at all
(Kamion/#ubuntu-devel) yeah, I know
(Kamion/#ubuntu-devel) is Italian working otherwise though? (assuming you're using Italian)
<fabbione> brrrr
<fabbione> i installed in en_DK
<fabbione> let me check
<fabbione> en_DK.UTF8
<fabbione> strange... after a reboot i lost the framebuffer
(Kamion/#ubuntu-devel) if you reboot in the middle of base-config, some stuff may not have been saved yet; probably a bug all the same
<fabbione> it failed to install desktop.. so that might be
<fabbione> nothing important..
* Mithrandir wonders if there is a boot server on the network here.
<fabbione> yay.. it's snowing!
(Mithrandir/#ubuntu-devel) it's blizzardy here. :)
(HcE/#ubuntu-devel) a bit too blizzardy ;)
(Mithrandir/#ubuntu-devel) HcE: wimp. :)
<__daniel> it's snowing over here too *jump happily around fabbione*
(HcE/#ubuntu-devel) think we got about 50 cm in Trondheim/Norway now
<cenerentola> its sunny here...
<fabbione> nah here are the first cm
<__daniel> HcE: my dog will be happy about one cm of snow ;-)
(Mithrandir/#ubuntu-devel) it's scary how easy starting d-i is; apt-get install atftp rarpd; edit /etc/ethers; wget -O /tftpboot/$hostid http://ftp.no.debian.org/debian/dists/testing/main/installer-sparc/current/images/sparc64/netboot/boot.img ; then boot net on the sparc.
(HcE/#ubuntu-devel) "easy"
* HcE takes a note of that line
<fabbione> Mithrandir: oh yeah
<daniels> to kick off network booting, that really is very easy
(Mithrandir/#ubuntu-devel) still no norwegian keyboard layout, though. :/
<fabbione> Mithrandir: too bad that the OBP knows only about rarp/tftp protocol
<fabbione> otherwise via dhcp is nice too
<fabbione> dhcp/tftp
* fabbione flushes 22K spam mails
(HcE/#ubuntu-devel) I flushed 100Mb of spam here the other day =)
(HcE/#ubuntu-devel) but I'm like to keep thing, so it went through bzip
<fabbione> if you like spam i can forward you mine :)
(HcE/#ubuntu-devel) :P
(HcE/#ubuntu-devel) I have plenty
(Mithrandir/#ubuntu-devel) fabbione: only 9GB disk so far.. I guess I'll throw a bigger disk into it as well.
<fabbione> Mithrandir: that's plenty
<fabbione> i use less than that for the buildd dir
(HcE/#ubuntu-devel) since 14. nov I have received 226 new spams
(Mithrandir/#ubuntu-devel) fabbione: it's the whole system, though.. and I like to have some extra space in there.
(Mithrandir/#ubuntu-devel) but it'll do for now.
(Mithrandir/#ubuntu-devel) hmm, how many disks can one stuff into a U5?
<fabbione> Mithrandir: yeah.. 
<fabbione> hmmm... 2 i think
<fabbione> it's a "desktop" one, isn't it?
<fabbione> with ide disks...
(Mithrandir/#ubuntu-devel) yeah :/
<fabbione> if so up to 4 ide devices
<fabbione> but you need to find the space where to mount them
(Mithrandir/#ubuntu-devel) yeah, I was more worried about that.
<fabbione> iirc you can easily add one below the cdrom
<fabbione> or below the floppy
(Mithrandir/#ubuntu-devel) hmm, I guess I could remove the cdrom as well
(sjoerd/#ubuntu-devel) you can get 4 in there if you really want to
<fabbione> remember that u5 can't read disks bigger than 120G
(Mithrandir/#ubuntu-devel) fabbione: can't read or can't boot off?
<fabbione> can't see/read
(Mithrandir/#ubuntu-devel) that sucks.
<fabbione> it recongnize weird values
<fabbione> yeah
(Mithrandir/#ubuntu-devel) I'm considering getting one to use as my backup box.
<fabbione> probably with an updated OBP
<fabbione> also take into account that it doesn't support cable-select
<fabbione> and it doesn't like all brands of hd
(sjoerd/#ubuntu-devel) fabbione: doesn't the ide controller need lba48 stuff for > 120G
<fabbione> but that's common to all sparc's
(Mithrandir/#ubuntu-devel) yeah
<fabbione> sjoerd: i think so yeah..
(Mithrandir/#ubuntu-devel) it's only a 128MB system so far, but I'll see if I can find some more to stuff into it.
(Mithrandir/#ubuntu-devel) what kind of ram does it use?
<fabbione> but the U5 is way older than LBA48
(sjoerd/#ubuntu-devel) my current desktop is an U5
<fabbione> mine was a U60
<fabbione> until either the mobo or the cpu went banana
(sjoerd/#ubuntu-devel) that's a shame
<fabbione> oh it's really funny
(sjoerd/#ubuntu-devel) i'm using my U5, because my intell machine died
<fabbione> you can turn it on.. once in a while
<fabbione> and it works perfectly
<fabbione> as soon as it warms up
<fabbione> you can't reboot it anymore
(Mithrandir/#ubuntu-devel) then don't reboot it?
<fabbione> or turn it off, without turning it on again for days...
(sjoerd/#ubuntu-devel) put it in the fridge :)
<fabbione> Mithrandir: ehhh
<fabbione> sjoerd: my gf didn't like the solution :)
<fabbione> replacing the mobo and cpu is a bit expensive
<fabbione> because i don't know if it's either one or the other
(Mithrandir/#ubuntu-devel) what kind of ram does the U5 use?
<fabbione> mobo is approx 100USD, but the cpu is aih.. way higher than that
(sjoerd/#ubuntu-devel) is it the same cpu as in a U5 or another one
<fabbione> if you include transport and taxes + everything else
<fabbione> the mobo jumps to 200USD
<fabbione> sjoerd: another one
<fabbione> the u5 has a "flat" cpu
<fabbione> mounted horizontaly
<fabbione> the u60 is vertical
<fabbione> 2 different busses
(sjoerd/#ubuntu-devel) ah too bad. i've got several spare U5 cpu's lying around
<fabbione> ehe no problem
<fabbione> it can cost me less to buy another U60
(sjoerd/#ubuntu-devel) probably
<fabbione> it definetely does
(sjoerd/#ubuntu-devel) got my U5 for free
<daniels> i have a free u5
<fabbione> U60 366Mhz 512Mb 18GB for 425USD
<fabbione> that's almost the same i have now
<fabbione> i could buy another one and merge them
(sjoerd/#ubuntu-devel) sun is extremely expensive.. looked for a replacement sparcstation 4 mobo once, because mine was struck by lightning
<fabbione> sjoerd: www.anysystem.com
<fabbione> the original mobo for the u60 is over 900USD from sun
<fabbione> and i can pay 100 for the same...
<fabbione> with one year warranty
(sjoerd/#ubuntu-devel) yeah, got another sparcstation somewhere for a lot less and merged them
* fabbione wants to look very cool and handles http://people.debian.org/~fabbione/e10k/debian_on_e10k.txt to sjoerd 
(sjoerd/#ubuntu-devel) ah nice
(Mithrandir/#ubuntu-devel) yay, boheci boots.
(Mithrandir/#ubuntu-devel) hmm
<ChrisH> e10k? Wow. I wonder if they have an e10k in laptop form-factor. :)
(Mithrandir/#ubuntu-devel) but she claims to not being able to read the partition table due to I/O errors.
(Mithrandir/#ubuntu-devel) that's kinda bad.
(sjoerd/#ubuntu-devel) ChrisH: no, but you can get a sparc in a laptop if you really want to
<fabbione> sjoerd: yeah i remember about that :-)
(sjoerd/#ubuntu-devel) fabbione: we almost got our uni into giving us a old small enterprise machine they stopped using
<fabbione> ChrisH: you will need a mini portable nuclear power plant
(sjoerd/#ubuntu-devel) but in the end they decided to keep it for testing :(
<ChrisH> sjoerd: Nah. I'd be happy already if my Toshiba would support power-management.
(Mithrandir/#ubuntu-devel) seems it's not too happy about being rebooted.
<fabbione> sjoerd: i had to buy one for the company i was working for at that time :-)
<ChrisH> fabbione: Yeah, the elec bill should be "interesting".
(sjoerd/#ubuntu-devel) http://www.tadpolecomputer.com/html/products/mobile/sparcle/
<ChrisH> sjoerd: 1 GHz Ultrasparc should be nice. But $3k for a laptop?
(sjoerd/#ubuntu-devel) fabbione: nice.. did they actually run debian on it in production or just for toying around ?
<fabbione> i don't think Sparc IIIi processor is supported by linux yet
<fabbione> sjoerd: no.. they had to run slowlaris
<fabbione> sjoerd: but i had my fun with that board for a while
<fabbione> nobody noticed a missing 4 CPUs and 4 GB of RAM
(sjoerd/#ubuntu-devel) haha
<fabbione> also because of the hotplug functionalities in slowlaris
<fabbione> i could just remove CPU / RAM from one virtual machine to another
<fabbione> and "top" on e10k is patched to report some virtual values
<fabbione> so basically you don't really know what hardware you have available at that moment
(sjoerd/#ubuntu-devel) hehe
<fabbione> and shifting one board from one execution domain to another is simple :-)
(sjoerd/#ubuntu-devel) pitti: i'm done with g-v-m patching and testing.. if you have any remarks left lemme know, otherwise i'll upload to experimental rsn :)
(sjoerd/#ubuntu-devel) fabbione: thats nice
<pitti> sjoerd: I already read the logs, nice work
(sjoerd/#ubuntu-devel) cool thanks
<pitti> go, sjoerd, go!
<pitti> sjoerd: then I can throw the stuf into Hoary as well
(sjoerd/#ubuntu-devel) pitti: for hal i'm waiting on md 
<pitti> sjoerd: ah, right
* sjoerd build the final package
(sjoerd/#ubuntu-devel) pitti: could do a binary only build for gvm on i386 for debian
<pitti> sjoerd: ahem, what for?
<pitti> sjoerd: for testing?
(sjoerd/#ubuntu-devel) pitti: for experimental, so people can test it 
* sjoerd doesn't have an i386 machine to build on currently
<pitti> sjoerd: ah, you mean you would usually upload sparc
<pitti> sjoerd: I can do that if you want
<pitti> sjoerd: as soon as the package hits the mirrors, I can upload it
<pitti> sjoerd: I never did this though; just upload a changes with the i386 deb and the same version?
(sjoerd/#ubuntu-devel) pitti: pull the package out of incoming and do dpkg-buildpackage -B -mpitti@debian.org 
(sjoerd/#ubuntu-devel) and upload the result
<pitti> sjoerd: this part is clear
<pitti> sjoerd: okay, if that works, I'm fine with that
<fabbione> sjoerd: btw.. 197 packages to go for the first set of ubuntu sparc packages
<fabbione> pitti: -b -B
(sjoerd/#ubuntu-devel) fabbione: nice.. although i don't have ubuntu on any of my machines
<fabbione> you don't want to regenerate the diff.gz
<fabbione> sjoerd: well.. there is always a first time :-)
<pitti> fabbione: right
<pitti> fabbione: I ususally use debuild -b
(Kamion/#ubuntu-devel) -B for porting to avoid the _all.{deb,udeb}, usually
<pitti> ah, nice hint; not a g-v-m problem (just one binary deb), but for general
<daniels> Kamion: {,u}deb
(Kamion/#ubuntu-devel) picky :)
(sjoerd/#ubuntu-devel) fabbione: for now i'm just working on the debian side of things, so having debian makes more sense :)
<zul> fabbione, do you need any help with the sparc debs
<fabbione> sjoerd: argh! the dark side!
<fabbione> sjoerd: P
<fabbione> add another :P
<fabbione> zul: it depends what you can offer
<zul> fabbione, i got a sparc32 and sparc64 i just need to put debian on it this weekend
(sjoerd/#ubuntu-devel) speaking about the darkside.. I sent one mail to the sparclinux list that i've found ``the'' problem with alsa on my sparc and various gentoo lusers start mailing me for patches
<fabbione> sjoerd: ehehe
<fabbione> i had several problems with alsa on sparc
<fabbione> specially due to the emu10k
<zul> heh..there are *some* gentoo lusers :)
(sjoerd/#ubuntu-devel) fabbione: my sparcstation is currently unused, but i don't think it's a good target for ubuntu :)
(sjoerd/#ubuntu-devel) fabbione: as in hanging the complete machine ? :)
<fabbione> sjoerd: no.. as it can't be compiled
<fabbione> or atleast.. that was like a year ago
<fabbione> if not more
(sjoerd/#ubuntu-devel) oh
(sjoerd/#ubuntu-devel) currently an unpatched kernel will just hang your machine if your run alsamixer 
<fabbione> dunno.. really... the only sparc i have left is a netra t1 105
<fabbione> no gfx, no audio
<fabbione> no keybaord
<fabbione> no mouse
(sjoerd/#ubuntu-devel) and alsaplayer doesn't work because of inconsistencies in the userspace and kernelspace structs
(sjoerd/#ubuntu-devel) but the last should be fix in 2.6.10-rc2
(sjoerd/#ubuntu-devel) pitti: gvm just hit incoming
<pitti> sjoerd: nice, thanks
* pitti will grab and build it
(sjoerd/#ubuntu-devel) thanks
(sjoerd/#ubuntu-devel) for unstable i maybe need to add a debconf note.. otherwise gvm will just stop working, because people didn't put themselves in the plugdev group
<pitti> sjoerd: ah right
<pitti> sjoerd: we were lucky to have put this right into our first distro
(sjoerd/#ubuntu-devel) we will hopefully get it right to in the first distro shipping it :)
(sjoerd/#ubuntu-devel) a slow release has it advantages :P
<pitti> sjoerd: do you want to add the note to pmount or gvm?
(sjoerd/#ubuntu-devel) pitti: gvm 
(sjoerd/#ubuntu-devel) it also is nice for people installing it for the first time though
(sjoerd/#ubuntu-devel) in debian the first user isn't in plugdev automagically
<pitti> sjoerd: well, this could be changed
(sjoerd/#ubuntu-devel) don't think it makes sense for debian to do that
<pitti> sjoerd: OTOH, the last time I installed a debian system, the first user was not even in audio and video :-)
<pitti> sjoerd: I guess that's the drawback of an "Universal OS" :-)
(sjoerd/#ubuntu-devel) yeah
<pitti> sjoerd: but it's actually not too bad if the admin puts the users into the needed groups explicitly
(sjoerd/#ubuntu-devel) nope, i just want too mention it clearly
<pitti> sjoerd: "Also turn autorun off and turn autobrowse on by default" -> nice, this makes another Ubuntu patch disappear :-)
(sjoerd/#ubuntu-devel) otherwise i'll get a load of bugs
(sjoerd/#ubuntu-devel) pitti: i know, i went through your patches
(sjoerd/#ubuntu-devel) and dvd on by default, that was off strangely enough
(azeem/#ubuntu-devel) AFAIK the initial user gets added to various groups in Debian, so adding plugdev wouldn't hurt I guess
(sjoerd/#ubuntu-devel) azeem: not that i know
* sjoerd checks
(sjoerd/#ubuntu-devel) hrm your right, that's new
(sjoerd/#ubuntu-devel) azeem: do you know what package does that ?
<pitti> sjoerd: should be passwd in base-config
(azeem/#ubuntu-devel) it was a hack in base-config, perhaps the passwd package does it properly now
(sjoerd/#ubuntu-devel) ./lib/menu/passwd:              adduser "$RET" video >/dev/null 2>&1 || true
(sjoerd/#ubuntu-devel) from base-config..
(Kamion/#ubuntu-devel) yeah, still is
(sjoerd/#ubuntu-devel) pitti: you could file a bug for the plugdev group there
(sjoerd/#ubuntu-devel) but i guess that won't make it into sarge anyway..
<pitti> sjoerd: I cannot build this in a sid environment
(sjoerd/#ubuntu-devel) pitti: hrm why not
<pitti> sjoerd: libgnomeui-dev has unsatisfiable depends
<pitti> sjoerd: I try to build in an up-to-date sid pbuilder chroot
<pitti>   libgnomeui-dev: Depends: libgnomeui-0 (= 2.8.0-2) but it is not going to be installed
<pitti>                   Depends: libgnomecanvas2-dev (>= 2.6.0) but it is not going to be installed
<pitti>                   Depends: libbonoboui2-dev (>= 2.5.4) but it is not going to be installed
(sjoerd/#ubuntu-devel) pitti: oh that's a problem with the G2.8 transition
<pitti> sjoerd: so shall I add the experimental pacakge source?
(sjoerd/#ubuntu-devel) libgnomecanvas2-dev is in incoming for i386
(sjoerd/#ubuntu-devel) pitti: that should work too, newer version of the depends are in sid rsn anyway
<pitti> sjoerd: okay, I build against experimental for now
<pitti> sjoerd: I uploaded the i386 deb and a binary-only changes file. Let's see whether it works :-)
(sjoerd/#ubuntu-devel) pitti: thanks
<pitti> sjoerd: it's nice to have a server with 100MBit connection for these purposes :-)
(sjoerd/#ubuntu-devel) good connections are always nice
<pitti> oh, just got a phone call. Gotta go, will return later. CU
(sjoerd/#ubuntu-devel) pitti: later
(Kamion/#ubuntu-devel) doko: why was http://people.ubuntu.com/~scott/ongoing-merge/libnet-ph-perl/libnet-ph-perl_ubuntu.debdiff necessary? the dependency was versioned due to a perl policy requirement, to deal with the perl 5.6 transition; is there a reason we need to keep this divergence?
(Kamion/#ubuntu-devel) elmo: more universe syncs for you: libapache-mod-python, libcgi, libforms1, offlineimap, opencv, paul, pgadmin3, pike7.6, primaxscan, pstoedit
(elmo/#ubuntu-devel) Kamion: done
(Kamion/#ubuntu-devel) ok, that was scary fast
<fabbione> Kamion: i think that's the "elmo autoanswer feature"
<fabbione> ;)
(Kamion/#ubuntu-devel) I think there's only about 20 more low-hanging fruit, after that the masters of the universe can take care of it
<daniels> fabbione: we replaced elmo with a very high-performance bot
<daniels> the scary thing is that you could actually easily automate the syncs
<fabbione> let see if it works:
<fabbione> elmo: sync..
<fabbione> :P
<daniels> scripts can't do esp :P
<daniels> but you look for sync, and you just tokenise the rest of the string, and if it matches a package in the archive, sync it
<daniels> excluding 'from debian', 'from sid', etc
<daniels> and you could probably have a heuristic involving : and stuff as well
<fabbione> ehhehe
<fabbione> daniels: is elmo there at sabdfl?
<daniels> fabbione: nope, not any more
<daniels> back to the north
<daniels> (sorry, norf)
<fabbione> ok
(robtaylor/#ubuntu-devel) hey.. anyone know hoe pmount decides which options to use for which media?
(Kamion/#ubuntu-devel) yep, kde needs x.org build-dep love
<daniels> Kamion: YAY!!!!
<daniels> Kamion: which module?
<fabbione> daniels: i think we should considering fixing it in a different way
(Kamion/#ubuntu-devel) kdebase
(Kamion/#ubuntu-devel) kde* build-deps on xlibs-static-pic
<daniels> Kamion: do you want me to sort it?
(Kamion/#ubuntu-devel) you know the rest :)
(Kamion/#ubuntu-devel) *shrug* I'm not bothered, it's universe
<daniels> Kamion: by kde*, you don't really mean ... all of kde ... do you
<fabbione> like xlibs-static-dev Depemnds: <allsplittedmodules>
(Kamion/#ubuntu-devel) wouldn't spend too much work time on it
<daniels> fabbione: i like the idea of forcing them to update b-ds
<daniels> fabbione: because, realistically, no-one now b-ds on anything other than xlibs-dev
<daniels> which is crap
<fabbione> i agree
<gicmo> hi everybody ;)
(Kamion/#ubuntu-devel) daniels: well, the four that I asked elmo to sync earlier anyway; kdebase, kdegraphics, kdemultimedia, kdenetwork
<daniels> Kamion: ok
<daniels> i might sort base and network and leave the rest for later
(elmo/#ubuntu-devel) hmm, one of the ia64 buildds has taken nearly 3k packages as 'building'
(elmo/#ubuntu-devel) "woops"
(lamont_r/#ubuntu-devel) elmo: it's bogosity from not having X
<daniels> elmo: what does it think it is, concordia?
(Kamion/#ubuntu-devel) shame, I was kinda hoping we could be synced to Debian for KDE for at least a while
(lamont_r/#ubuntu-devel) was waiting for it to quiesce before doing a mass giveback
<daniels> Kamion: the b-d change should be enough for merge-o-matic to work its love
(elmo/#ubuntu-devel) daniels: only in it's dreams
(elmo/#ubuntu-devel) lamont: ah
(Kamion/#ubuntu-devel) daniels: sadly not often judging from the syncs I've been reviewing :(
(Kamion/#ubuntu-devel) daniels: too often the b-ds are in like a different order or something and hi_mom gives up in despair
(Kamion/#ubuntu-devel) anyway, I have to go and pick my car up from being repaired, back in an hour or so
<fabbione> we could ask Keybuk to write a special tool for checking build-deps
(Kamion/#ubuntu-devel) that might be good
<fabbione> sorting them would avoid a lot of conflicts
(Kamion/#ubuntu-devel) oh, and it's usually next to the standards-version line so any update of that will cause fuzz ...
<Keybuk> yeah, was tempted to write a depends-field parser to sort those out
<daniels> Kamion: ahr, bugger
<daniels> Keybuk: great work with mom though
<Keybuk> sourcerer.deb can already parse much of the control file, and do a three-way diff ... is just those fields that are trickier
<daniels> Keybuk: it's really really good
(Kamion/#ubuntu-devel) oh, yeah, not dissing it, it's doing a fine job
<fabbione> Keybuk: perhaps you can parse them one by one
(Kamion/#ubuntu-devel) today's syncs were trivial to review
<fabbione> Keybuk: just ideas.. it's not complaining
<daniels> Kamion: not saying that it was :) just remembered that I wanted to compliment Keybuk the other day, but he was selfishly not here
(Kamion/#ubuntu-devel) he does that
(Kamion/#ubuntu-devel) doesn't want to know what we're saying behind his back ;)
<daniels> elmo: that ia64 buildd doesn't want to share
<Keybuk> I suspect I'm going to need a depends-field parser for hct anyway at some point, so it'll probably just turn up <g.
<daniels> elmo: so you'll have to shaft it
* Keybuk clears his bug folder ... Colin "SYNC FROM DEBIAN" Watson has been busy :p
(elmo/#ubuntu-devel) lol
<seb128> elmo: sync for easytag (1.99.1-1) from experimental please
(lamont_r/#ubuntu-devel) daniels: that buildd was your fault, you know.
(elmo/#ubuntu-devel) easytag's in universe atm?
(lamont_r/#ubuntu-devel) (xorg/xf86 causing quick failures that the autodepwaiter couldn't parse...)
<seb128> elmo: yes
<daniels> lamont_r: why did xorg fail quickly?
<daniels> lamont_r: build rman, build xorg, watch it fail, throw me debian/MANIFEST.ia64.new
<fabbione> daniels: he did already
(elmo/#ubuntu-devel) seb128: hmm - I thought we were only doing experimental syncs for release goals.. but *shrug* it's your package :)
<fabbione> check your irc backlog
(elmo/#ubuntu-devel) seb128: done
<daniels> fabbione: i don't have anything in my backlog
<seb128> elmo: ok, thanks :) (we have the choice between an old gtk+1 app and a new gtk+2 supporting utf-8 fine so .. :)
<fabbione> daniels: it's on people/~lamont/daniels/
<fabbione> daniels: *ia64*
<daniels> lamont_r: ah, ill
<daniels> lamont_r: thanks dude
(lamont_r/#ubuntu-devel) daniels: actually, it was xf86 _and_ xorg not being there that was fatal to all those builds..
(lamont_r/#ubuntu-devel) xf86 finally built
<daniels> heh
<gicmo> sladen, ping ? :)
<enrico> hello.  Can someone help me with the wiki?
<enrico> I modified my entry in the ConferenceAttendees, then viewed the page a bit later and I saw a single block of text with the Moin markup.  I did Edit and I saw that the page formatting was set to HTML.  I reset it to Moin but it's now messy.  And I can't understand how to roll it back
* fabbione starts the first round of manual hits on the buildd
<enrico> Ah, ok, someone did something after I last edited it
<fabbione> ciao enrico 
<enrico> fabbione: ciao!
<fabbione> madduck: you can't be god
<Mitario> hello everyone
(Kamion/#ubuntu-devel) elmo: more syncs, please: pytables python-biggles python-gnome python-rrd python-utmp qgis quantlib-python
(Kamion/#ubuntu-devel)  quiteinsanegimpplugin radiuscontext rdiff-backup rezound scite scribus sdl-imag
(Kamion/#ubuntu-devel) e1.2
(Kamion/#ubuntu-devel) oops, sorry for crappy line wrap
(elmo/#ubuntu-devel) Kamion: done
* Kamion gives Keybuk more mail
(lamont_r/#ubuntu-devel) Kamion: you're on a roll dude
<daniels> lamont_r: (just like butter)
(lamont_r/#ubuntu-devel) elmo: you probably don't want to know that there are 5 more unknown/'s, do you?
(lamont_r/#ubuntu-devel) (ia64/build-db)
(elmo/#ubuntu-devel) oh, I just need to cron elisha
(elmo/#ubuntu-devel) hmm, except she only finds 2.  meh.
<Keybuk> is that a new euphemism?
<Keybuk> daniels will probably claim that "cronning" means something in Australian
(lamont_r/#ubuntu-devel) Keybuk: almost certainly to do with 18 yearolds and sex
<mxpxpod> does the ubuntu kernel have any extra patches to it?
(elmo/#ubuntu-devel) lamont: I see ejabberd, u++(fixed) and elilo-installer - what's the other 2?
(lamont_r/#ubuntu-devel) partitioner efi-reader
<daniels> Keybuk: yes, scheduling a task to be done at a particular time via an automated system
<daniels> lamont_r: you sick bastard
<Keybuk> daniels: well, you go into firts of giggles whenever we talk about routeing, so we can never be too sure
(elmo/#ubuntu-devel) lamont: k, will look at that at some point then
<daniels> well, try to talk about more mundane topics, such as network infrastructure
(lamont_r/#ubuntu-devel) elmo: np
<Keybuk> daniels: we all know you hacked fd.o yourself just so you can claim you've been rooted *once* this year :p
(Kamion/#ubuntu-devel) elmo: last lot for today: serpento sip-qt3 sqlrelay ted tla-load-dirs vrweb waili wallp wdm wxwindows2.4 xdiskusage xemacs21-packages xpaint xt ygraph
(elmo/#ubuntu-devel) done
* lamont_r goes to to help move
(Kamion/#ubuntu-devel) -rw-rw-r--    1 cjwatson cdimage  635965440 Nov 19 14:45 hoary-install-powerpc.iso
(Kamion/#ubuntu-devel) hm, we're getting close to capacity here
(Kamion/#ubuntu-devel) about 40MB to go ... taking mozilla-browser off the CD is looking pretty appealing :)
<Keybuk> is hoary that much bigger than warty?
<daniels> powerpc is that much bigger than i386
<mxpxpod> I'd like to take a 2.6.9 vanilla kernel, patch it with benh's sleep patch for ibook g4... do I need to create an initrd image? or will make-kpkg do that for me?
(Kamion/#ubuntu-devel) -rw-rw-r--    2 cjwatson cdimage  621025280 Oct 20 00:43 warty-install-powerpc.iso
(Kamion/#ubuntu-devel) not *that* much worse, admittedly
<daniels> Kamion: kdebase is FTBFS for me right now in other ways I can't be arsed fixing
(Kamion/#ubuntu-devel) fair enough
<daniels> Kamion: (code issues, so not worth the time on universe0
<daniels> s/.$/)/
(mjg59/#ubuntu-devel) Kamion: Around?
(Kamion/#ubuntu-devel) mjg59: yes
(mjg59/#ubuntu-devel) Kamion: I'm meeting various debian-uk people this evening - if there are some straglers, would you object to them wishing you a happy birthday later on?
(Kamion/#ubuntu-devel) mjg59: not at all
(mjg59/#ubuntu-devel) Kamion: Excellent
<pitti> Hi sjoerd
(sjoerd/#ubuntu-devel) pitti: hi :)
<pitti> sjoerd: can you please clean up 20_specify_mountprogram.patch a bit?
<pitti> sjoerd: it still contains this autofoo cache
(sjoerd/#ubuntu-devel) ugh
<pitti> sjoerd: which makes the patch 270 KB big
(sjoerd/#ubuntu-devel) i knew i forgot something :)
<pitti> sjoerd: I just went through the ubuntu g-v-m patches
<pitti> sjoerd: In fact I do not need any of it any more :-)
(sjoerd/#ubuntu-devel) cool
<pitti> sjoerd: did my binary upload work?
(sjoerd/#ubuntu-devel) yeah
(sjoerd/#ubuntu-devel) pitti: new 20_specify_mountprogram.patch in svn
(sjoerd/#ubuntu-devel) dbs-edit-patch does indeed work very nice :)
<pitti> sjoerd: if there was something similar for simple-patchsys, then it would be even nicer 
<pitti> sjoerd: but I agree, it helps a lot
<_rene_> pitti: 
<_rene_>   * debian/control.lang.in:
<_rene_>     - stop depending on openoffice.org at -l10n-*. Just recommend it.
<_rene_>       Conflict against the older versions to get the desired effect
<_rene_>       instead. This enables re-inclusion of them in tasksel and
<_rene_>       allows per-language metapackages (closes: #281645) [RE] 
<pitti> _rene_: looks nice
(sjoerd/#ubuntu-devel) pitti: even better if it worked together nicely with svn-buildpackage
<_rene_> umm, s/enables/allows/, but this would be the change ;-)
<pitti> _rene_: the only difference to my version is that it is not automatically uninstalled if you remove both OO.o and the lanugage pack
<_rene_> it isn't here either
<pitti> _rene_: but for the sake of compatibility this is fine
<_rene_> oh, wait
<_rene_> how do you mean that?
<pitti> _rene_: will this be uploaded soon?
* _rene_ is shlightly confused but maybe only because his caffeine level is low
<pitti> _rene_: if o-l10n-de depends on ooo | language-support-de
<pitti> _rene_: then synaptic/apt will automatically remove it if both packages are removed
<_rene_> ah, yeah
<_rene_> we don't do that :-)
<pitti> _rene_: so users can choose not to want de any more and this would uninstall all mozilla and OO.o stuff
<pitti> _rene_: it's not that important
<pitti> _rene_: but shouldn't you conflict to older _and_ newer versions?
<_rene_> since it's a completely new metapackage / sarge/ blah / yada ;)
<pitti> _rene_: or will that work?
<pitti> _rene_: at least mozilla fails badly with an older language pack and a newer broser
<pitti> browser, even
<_rene_> if the strings don't change it will work
<_rene_> if they change.. Hmm
<pitti> _rene_: if it is possible that it breaks, I'd rather conflict to older and newer versions
<pitti> _rene_: differently from Mozilla, the language packs for OO.o should always be available in matching versions
<pitti> _rene_: so I don't see a problem
<_rene_> yeah, but theer are some people who try to upgrade via apt-get *install*
<_rene_> which sometimes has nice effects
<pitti> _rene_: well, then they will be lectured that they need to update the l10n package, too
<pitti> _rene_: but it might safe you some odd bug reports :)
<_rene_> yeah, and we have to deal with the bugreports :/
(Mithrandir/#ubuntu-devel) fabbione: what do you want installed on the buildd?
(haggai/#ubuntu-devel) pitti: you can't do versioned provides I'm afraid
<pitti> haggai: we don't need them?
(haggai/#ubuntu-devel) pitti: so you'd have to list every possible language in the conflicts
<_rene_> erm, this is the other way round
(haggai/#ubuntu-devel) oh, right
<pitti> haggai: why, every l10n package just needs to conflict to unmatching versiosn of the main package
<_rene_> -l10n-* conflicting against oo.o versions
<pitti> haggai: yes, conflict in one direction is enough
(haggai/#ubuntu-devel) hmm, could work
<pitti> haggai: it does :)
<_rene_> ok, so I'll do a Conflicts: openoffice.org (<< 1.1.1+1.1.2), openoffice.org (>> 1.1.2+1.1.3)
(haggai/#ubuntu-devel) ok
(haggai/#ubuntu-devel) hmmm, I think the reason we didn't do that was because you sometimes get point releases without string updates
(haggai/#ubuntu-devel) but I guess dropping that won't hurt many people
<pitti> _rene_: hmm, shouldn't it be >= 1.1.2+1.1.3?
<pitti> _rene_: or will all 1.1.2 translations work also with 1.1.3?
<_rene_> uh?
<pitti> _rene_: you used >>
<_rene_> 1.1.2+1.1.3 is lesser than 1.1.2+1.1.3-1
<_rene_> 1.1.2+1.1.3 would be the upstream version
<pitti> _rene_: right, that's why I ask
<_rene_> and you conflict against anything after 1.1.2
<pitti> _rene_: you should conflict to 1.1.3 too
<_rene_> which 1.1.2+1.1.3 is
<_rene_> 1.1.3 is bigger than 1.1.2+1.1.3
<pitti> _rene_: no, 1.1.3 would still be allowed since you use >> (Stricter greater)
<_rene_> we don't allow anything bigger than 1.1.2+1.1.3
<pitti> _rene_: ah, I thought you package a version which really is called 1.1.2+1.1.3
<_rene_> and 1.1.3 _is_ bigger
<pitti> _rene_: okay, my fault, sorry
* pitti fetches brown paperbag
<_rene_> the current version is 1.1.2dfsg1-3
<_rene_> so no problem :)
<_rene_> no problem. I sometimes have to think about it again too if I edit that ;-)
<Kyaneos> hi
* mvo_ goes and plays some hockey now
<mirak> hi
<mxpxpod> does anyone here use ubuntu on an ibook g4?
* amu on a pb-g4
<mxpxpod> amu: alubook?
(amu/#ubuntu-devel) n, the latest with 1,5Ghz and 15" 
<mxpxpod> hmm
(sjoerd/#ubuntu-devel) mxpxpod: pitti has an ibook g4 iirc
<mxpxpod> I'd like to compile my own kernel (2.6.9 + benh's new patch for sleep) but I'm not sure how to do the initrd stuff that ubuntu uses
<gicmo> benh's sleep patch?
<mxpxpod> gicmo: http://lists.debian.org/debian-powerpc/2004/11/msg00367.html
<mxpxpod> whoops
(amu/#ubuntu-devel) formorer packaged it, see p.d.o/~formorer 
<mxpxpod> http://lists.debian.org/debian-powerpc/2004/11/msg00356.html
<gicmo> ahh only for g4s .. 
<mxpxpod> amu: p.d.o?
<mxpxpod> amu: heh, people... not planet
<gicmo> hehe
(amu/#ubuntu-devel) people 
<mxpxpod> amu: ah, that's not the new patch
<mirak> hi
<mirak> anyone have knowledge with apt-build ?
<mirak> isn't it supposed to resolve and compile the deps ?
(amu/#ubuntu-devel) aehm well sleep works .... sometime ;) 
(sjoerd/#ubuntu-devel) the old patch works great on my albook
<mirak> because for me it blocks on the -dev packages and don't get them
<mxpxpod> amu: the new patch fixes some issues, supposedly
<mxpxpod> sjoerd: you compiled your own kernel?
<gicmo> I wonder when/if the inotify patch will go into the ubuntu kernel
(sjoerd/#ubuntu-devel) mxpxpod: yeah, i always do
(amu/#ubuntu-devel) make-kpkg kernel-image --initrd should work 
<mxpxpod> really...
* mxpxpod writes that down
<mxpxpod> wasn't sure how to do the initrd
(amu/#ubuntu-devel) yep
<mxpxpod> sjoerd: do you just compile everything as a module?
(sjoerd/#ubuntu-devel) mxpxpod: no
(amu/#ubuntu-devel) everything as a module ? you submit your patch rerun make oldconfig and build the package  
<mxpxpod> sjoerd: so you have a config for your specific machine
(sjoerd/#ubuntu-devel) mxpxpod: yes
<mxpxpod> ah, that makes sense
<mxpxpod> sjoerd: what fs do you use for your linux partitions?
(sjoerd/#ubuntu-devel) ext3
<mxpxpod> do you compile that in?
(sjoerd/#ubuntu-devel) i need to, i don't use an initrd
<mxpxpod> ahhh, ok
(tseng/#ubuntu-devel) boo
(tseng/#ubuntu-devel) any built cvs lately?
(tseng/#ubuntu-devel) er, sorry that was for #muine
* tseng hits mxpxpod for tricking me
<jdz_> Has there been any work done with Ubuntu and LTSP?
<mxpxpod> :D
<Gaaruto> hello
<Mitario> lo everyone
<cenerentola> ciao
(jdub/#ubuntu-devel) elmo: around?
(elmo/#ubuntu-devel) jdub: yeah
(jdub/#ubuntu-devel) elmo: did you get my mail about ubuntu-calendar* and hoary?
(jdub/#ubuntu-devel) i repinged it again recently
<seb128> jdub: do we want gst-ffmpeg somewhere ? I've taaz's (the gst maintainer in debian) source package, I can upload it in hoary if we have a place for it ...
(jdub/#ubuntu-devel) seb128: is it in debian?
<seb128> no
<seb128> ffmpeg is staying in NEW for like 3 months
(jdub/#ubuntu-devel) i think we should be very cautious about adding it anywhere
<seb128> ftpmasters have no love for it :p
<seb128> why ?
(jdub/#ubuntu-devel) at least we have plausible deniability for stuff we sync from debian into universe ;)
<seb128> we have ffmpeg in xine in universe ... what's worst in gst ?
(jdub/#ubuntu-devel) seb128: because it will kick our arses :)
<seb128> and we have mplayer in multiverse
<seb128> which have it too
(jdub/#ubuntu-devel) seb128: sure, but those are both quite dangerous
(jdub/#ubuntu-devel) libxine we have some plausible deniability about
<seb128> the question is "why 2 packages with ffmpeg and not 3"
(jdub/#ubuntu-devel) mplayer was a conscious decision, unfortunately
<seb128> I would understand 0
<seb128> or 3
(jdub/#ubuntu-devel) seb128: because libxine is straight from debian ("oh really? we didn't know that")
<seb128> ok
(jdub/#ubuntu-devel) mplayer was a conscious decision, unfortunately
(jdub/#ubuntu-devel) but bringing gst-ffmpeg in is another conscious decision
<seb128> I'll use the alioth pkg-gnome pool for debian, the package will work on ubuntu too
(elmo/#ubuntu-devel) jdub: answered
(elmo/#ubuntu-devel) sorry
(jdub/#ubuntu-devel) thanks
(jdub/#ubuntu-devel) elmo: so 'warty-updates hoary' in the changelog header?
(jdub/#ubuntu-devel) elmo: also, what do we do about november calendar updates that are already in warty?
<wasabi> How does one request support for a package in universe? I'd like to see it in main. I can make a case for it.
(elmo/#ubuntu-devel) jdub: I thought i migrated it already
(elmo/#ubuntu-devel) jdub: and yes
(elmo/#ubuntu-devel) apparently not, go me
(jdub/#ubuntu-devel) ok thanks :)
<wasabi> lib{nss,pam}-{ldap,krb5}
(jdub/#ubuntu-devel) wasabi: mail ubuntu-devel
(jdub/#ubuntu-devel) wasabi: instant support from me
(elmo/#ubuntu-devel) okay, they'll go out into hoary in the next mirror pulse
<wasabi> looks like libpam-krb5 is utterly useless, just like in debian
<wasabi> doesn't even create a ticket cache
* wasabi sigh.
(jdub/#ubuntu-devel) elmo: awesome, thanks
* wasabi subscribes to list
(jdub/#ubuntu-devel) wasabi: please point out any integration fixes we need
<wasabi> Is that okay? I point out "it doesn't work" to the debian maintainer at one point, but wasn't going to say anything else since I had no time to fix it myself.
(jdub/#ubuntu-devel) worth pointing out as you propose them
<jdz_> Does anyone know if there has there been any work done with Ubuntu and LTSP? (http://ltsp.org/)
(jdub/#ubuntu-devel) a guy called punkass on #ubuntu mentioned he was looking into it
<jdz_> Thanks, I'll keep an eye out for him
<jdz_> The only relevent infomation in the Ubuntu website is in MarksHoaryGoals: Must Have: LTSP in the box
<jdz_> I haven't been able to find any discussion beyond that though.
<wasabi> You guys realize how bad of a name Hoary is right?
<wasabi> I just had to yell across my office: "Hey Paul, are you using Hoary?"
<wasabi> And of course all the women in the office turn and scowl.
<wasabi> man nscd is so messe dup
<wasabi> does libc in ubuntu not work with nscd?
<wasabi> It's not even attempting to probe for the socket
<wasabi> oh there it is.
#ubuntu-devel 2004-12-01
(lamont_r/#ubuntu-devel) network move.  back on in a bit.
<nasdaq4088> is there anyone here who has written visual basic applications?
(sladen/#ubuntu-devel) nasdaq4088: have you tried #basic ?
<nasdaq4088> your one fucking funny guy
(sladen/#ubuntu-devel) the correct gramma would be "you're"
(sladen/#ubuntu-devel) r
<lamont_p> moo
<ogra> elmo: are you around ?
<Keybuk> A thought for all those doing merges ... http://www.lag.net/random/leisure-c.jpg
<lamont_r> Keybuk: aint that the truth.
<lamont_r> in a few minutes, I'll be heading home.  Which is to say, offline for a day or 2...
<lamont_r> time to get ready to leave.
<lamont_r> right.  off to home.  later
<mirak> hi 
<mirak> I have all kde menu entries in dupes
<mirak> how can I fix that ?
<mirak> a full kde reinstall ?
<mirak> even in the kde control center
<mirak> every menu is in double
<Riddell> mirak: it may be because ubuntu has KDE libs 3.3 but KDE base 3.2
<mirak> ah ?
<mirak> ah sorry wrong channel
<mirak> I though I was in ~kde
<mirak> #kde
<mirak> I use ubuntu indeed, so thanks :)
<mirak> Riddell: is there some command that rebuild the menu from de .desktop files ?
<Riddell> mirak: kbuildsycocoa
<mirak> thanks
<mirak> Riddell: where is the orininal database so I could erase it ?
<mirak> original
(amu/#ubuntu-devel) mirak: link /usr/share/config /etc/kde3 
<mirak> ok
(amu/#ubuntu-devel) it will solve the problem with your double menus
<mirak> in fact the problem was a .back folder in /usr/share/applications
<mirak> I don't remember if it's me who crated it
<mirak> maybe yes
(amu/#ubuntu-devel) aaahh those "menus" ;) i thought to the window-menu's *g* 
(amu/#ubuntu-devel) btw. someone build libs&base against xorg ?
<wasabi> Has anybody considered using binary diffs for apt upgrades?
(Kamion/#ubuntu-devel) wasabi: there have been a number of discussions about it but it's a very hard problem; people don't generally upgrade from one version to the next in sequence, and they may not have the old packages around
<wasabi> Well, I'd say in Warty they most likely do.
<wasabi> But yeah, I see your point.
<wasabi> I'm wondering how much of a benefit it would have, for instance for openoffice.
<wasabi> Which is a 40mb .deb
<Keybuk> given the openoffice build process, it'd probably be a 40mb xdelta as well :-/
<wasabi> how so?
<Keybuk> everything slightly changes
<Keybuk> ELF isn't great for deltaing at the best of times
<wasabi> Well, the binaries aren't the biggest parts either
<Keybuk> no, I was just thinking, there's a huge amount of data in that .deb as well
<wasabi> Grr.
<wasabi> xdelta doesn't do dir trees?
<Keybuk> wasabi: tar, tar, xdelta
<wasabi> hmm. yeah.
<wasabi> So, somebody is working on deb as .tar.gz support, I heard.
<wasabi> THat'd solve that.
<Keybuk> "deb as .tar.gz" ?
<wasabi> Instead of whatever format they are in now.
<Keybuk> a deb is a .tar.gz
<wasabi> eh? what'd I read then
<Keybuk> somebody who'd found the crackpile, by the sounds of it :p
<wasabi> ahh, support for bzip2
<wasabi>  Support for bzip2-compressed .debs
<wasabi> 
<wasabi> ScottJamesRemnant
<wasabi> 
<wasabi> Code in dpkg mainline 
<wasabi> Oops. sorry.
<Keybuk> that would be me :)
<wasabi> Didn't expect the lines.
<wasabi> oh. ;)
(Mithrandir/#ubuntu-devel) wasabi: Keybuk is Scott James Remnant. :)
<wasabi> looky there.
<Keybuk> could be worse, trey got as far as arguing quite heavily with me about the deb format before someone pointed out that I'm the dpkg maintainer :o)
(Mithrandir/#ubuntu-devel) Keybuk: it's fun, isn't it? :)
<Keybuk> not sure whether bzip2 would help openoffice or not
<Keybuk> bzip2 generally performs better on plain text than gzip
<Keybuk> but usually no better on binary, at a lot higher memory and CPU cost
<wasabi> So, what is a .deb?
<Keybuk> an ar file containing a text file and two tar files
<Keybuk> first tar file is all the meta-data, second are the contents
<wasabi> Hmm. Makes it hard to diff.
<Keybuk> -rw-r--r--    1 scott    scott         40M 2004-11-20 16:51 data.tar.bz2
<Keybuk> -rw-r--r--    1 scott    scott         42M 2004-11-20 16:52 data.tar.gz
<Keybuk> heh
<wasabi> And the contents tar file is gzipped?
<Keybuk> both are gzipped
<Keybuk> no real saving in bzipping openoffice
<wasabi> I'm trying to find the savings by diffing it
<Keybuk> well, if you take openoffice.org-bin_1.1.2-2ubuntu6 -> openoffice.org-bin_1.1.2dfsg1-2ubuntu2 as a release upgrade ...
<Keybuk> -rw-rw-r--    1 scott    scott         29M 2004-11-20 16:56 test.xdelta
<Keybuk> so it's not even half the size
<wasabi> diffing the data.tar.gz I assume?
<Keybuk> uncompressed data.tar
<wasabi> I did xserver-xorg, because I happened to have two versions of it, ubuntu1 and 2
<wasabi> Orignial's about 5.3 MB, diff is 348k
<Keybuk> I wouldn't generally expect a huge difference if it were just an ubuntu patch change
<Keybuk> those are usually changes to things like the admin scripts
<wasabi> Yeah.
<Keybuk> but in a release -> release situation, you're almost looking at one or more upstream version changes
<Keybuk> and then the benefit vanishes
<wasabi> Even if it's a new version, similarities like images and stuff would make a big diff imo
<wasabi> Well, there is always an option of only doing a diff if it matters.
<Keybuk> there's more benefit for splitting those into a separate source package
<wasabi> For a dialup user, 5MB to 380k is a major diff
<Keybuk> sure, but dialup users probably won't be following the development cycle anyway
<wasabi> Sure.
<Keybuk> and if they are, they won't be following fast enough to get every releas
<wasabi> haha
<Keybuk> so it becomes impossible to have a set of deltas that they'll hit
<wasabi> I'd be curious to actually stick a diff generator in katie or some such on a real archive and see what actually happens.
<Keybuk> what do you diff from/to ?
<wasabi> last version to current version.
<Keybuk> it's very rare that anybody will get every single version
<Keybuk> they're more likely to skip one or more
<wasabi> So they have 3 patches.
<wasabi> if size of 3 patches < size of orignal package, delete patches.
<wasabi> err, >
<Keybuk> this also still assumes they have the original .deb on the drive, of course
<wasabi> Yes, it does.
<Keybuk> which isn't unreasonable, as APT does tend to keep them around until they're out-dated
<wasabi> I see a little check in apt: if current version on drive, search for patch from current version.
<wasabi> repeat until there are no more patches.
<wasabi> beyond that it's up to the archive scripts to determine if a patch is appropiate or not, and if not, it doesn't make one.
<Keybuk> if you've got some time, it'd certainly be interesting to see it implemented
<Keybuk> I don't know whether the cost of generating the deltas would be huge or not
<wasabi> Here's a good example.
<wasabi> Evolution 2.0 to evo 2.1 in hoary
<wasabi> patch is 3.8M
<wasabi> i dont know if that's worth it. =/
<wasabi> it is < 1/2
<Keybuk> how big is the evolution binary?
<wasabi> 9.2M
<Keybuk> there's also a worry about doubling the amount of mirror space the archive takes
<wasabi> yeah.
<Keybuk> if we're talking about Debian, which would benefit hugely from patching
<wasabi> Well, im talking only about Ubuntu at this point. ;)
<Keybuk> basically taking a 120GB archive and turning it into a 240GB archive :p
<wasabi> Laying out the file names in the archive would be interesting too
<wasabi> Not sure how to go about that.
<Keybuk> how do you mean?
<wasabi>  /pool/b/blah/blah_oldversion.diff?
<wasabi> Or add it to the Package file somehow?
<Keybuk> pool/$component/$s/$source/$source_$version_$arch.debdelta
<Keybuk> you'd need a version index for each package, to make sure you could *get* all of the deltas
<wasabi> there's nothing saying what version that patch patches too.
<wasabi> Which doesn't matter.
<wasabi> But, it is a bit annoying
<Keybuk> otherwise you could miss an important one, because a mirror ran out of disk, or hadn't sync'd it yet
<Keybuk> sorry, that second $source should be $binary obviously, duh :p
<wasabi> Hmm. Apt takes the file in the archive. Takes the version on it.
<wasabi> Say it's 1.0.0
<wasabi> Finds 1.0.0_i386.debdelta
<wasabi> which always upgrades to the "next" version.
<wasabi> Don't know what the next version is.
<wasabi> Perhaps .debdelta itself becomes an ar, with a control file.
<Keybuk> I'd do it the other way around, the version indicates the version you get -- because that's what you expect from FTP sites that supply patches
<wasabi> Yeah, but then you'd need to do version calcs to find the next version from the current.
<wasabi> Or you'd need to ls the directory.
<Keybuk> can't ls an http directory
<wasabi> exactly.
<daniels> .listing :P
<Keybuk> you could do a GNU-style
<Keybuk> File: libtool-1.5.8-1.5.10.diff.gz  	89 KB  	19/09/04  	14:00:00
<Keybuk> File: libtool-1.5.8-1.5.10.diff.gz.sig 	1 KB 	19/09/04 	14:00:00
<Keybuk> File: libtool-1.5.8-1.5.10.xdelta 	24 KB 	19/09/04 	13:59:00
<Keybuk> File: libtool-1.5.8-1.5.10.xdelta.sig 	1 KB 	19/09/04 	13:59:00
<Keybuk> File: libtool-1.5.8.tar.gz 	2620 KB 	07/08/04 	13:57:00
<Keybuk> File: libtool-1.5.8.tar.gz.sig 	1 KB 	07/08/04 	13:57:00
<wasabi> There is nothing recording the progression from version 1.0.0 to 1.0.1 to 1.1.0
<Keybuk> File: 
<wasabi> old-new?
<Keybuk> $binary_$old_$new_$arch.debdelta
<wasabi> So which file do you grab?
<wasabi> You don't know waht the new is.
<Keybuk> though you'd still need to unpack the debdelta to make sure it wasn't lying about it's filenames (neither dpkg nor apt trust them, currently)
<Keybuk> so again, you're back to putting the information in the Packages file
<Keybuk> then the Packages churn bites
<wasabi> User currently has lintool_1.5.8
<wasabi> lib
<wasabi> It is upgrading to 1.5.10 ultimatly
<wasabi> there is also a 1.5.9 patch
<Keybuk> in fact, you'd need the Packages file information *anyway* to make sure you were getting a delta that applies to your branch
<Keybuk> otherwise you could accidentally pick up a delta specific to testing or experimental
<wasabi> yeah.
<wasabi> doesn't solve my dilema though
<Keybuk> so it now takes you
<Keybuk> a) three times as long to download the Packages file
<Keybuk> b) maybe half the time to download the packages themselves
<Keybuk> c) a small eon to apply all the deltas to put together the new .deb and install it
<wasabi> 3 times as long?
<wasabi> Maybe...
<wasabi> won't argue with c.
<Keybuk> wasabi: assuming 3-4 deltas per binary, with md5sum, size, previous and next version info -- roughly triples the size of the Packages file
<wasabi> =)
<wasabi> Hmm. I wouldn't say triple!
<wasabi> Just 2 additional lines to each Package: stanze
<wasabi> ?
<Keybuk> Deltas:
<Keybuk>   md5sum size previous next filename
<Keybuk>   md5sum size previous next filename
<Keybuk>   md5sum size previous next filename
<Keybuk> etc.
<Keybuk> assuming you keep the similar format to the Files: line
<wasabi> Delta-Next: md5sum size filename?
<wasabi> Actually...
<wasabi> You're format is more righter. ;)
<wasabi> Deltas:\  md5sum size fromversion filename
<Keybuk> you can only have one entry per binary, and one occurance of each field
<wasabi> I might say that instead.
<wasabi> And apt grabs the target version and finds a path to it's current version through the fromversions.
<Keybuk> yeah, you could work out if it were possible at Packages time, and download the appropriate things then
<wasabi> That opens up some interseting optimization ideas that nobdoyw ould probably use.
<wasabi> Have multiple patches to get you from various versions to the current.
<wasabi> Progressive or not.
<wasabi> Or not. You could have one delta from warty to hoary
<wasabi> and another between h oary versions, for large packages only.
<Keybuk> indeed, it allows for big-jump upgrade deltas if they're smaller
<Keybuk> it'd be interesting to find out where it becomes cheaper to just download the new deb than to patch up the old one
<wasabi> I've never popped open the apt source code.
<wasabi> It C?
<Keybuk> C++
<gicmo_> I think C++
<gicmo_> ahh damn I am slow
<wasabi> Oh, so it
<wasabi> s probably all OO
* wasabi guessing he'll find a acquireVersionOrSomething function.
<Keybuk> it's a harder problem than the "is it faster to download uncompressed than compressed and decompress it" because you've actually got to decompress the original deb, then download and decompress each delta, then apply them
<Keybuk> I guess you should recompress it again, so you can use it next time without throwing it away
<wasabi> Yeah.
<wasabi> You would just be acquiring the cache/apt/archives files differently.
<wasabi> And the same methodology to clear that folder would be in effect.
<wasabi> Whatever it is.
<Keybuk> I'd finger-in-the-air that there's a cut off point around half the download time of the original deb
<wasabi> I'd say if you're on dialup, any time saved is a blessing.
<daniels> i'd agree with wasabi
<wasabi> But, it would just have to be balanced based on archive size
<Keybuk> sure, but you don't want to shoot the people who can pull 100Mbps from the archive :p
<Keybuk> instead of a 2s download, they get 2m of patching
<wasabi> Oh sure.
<wasabi> THere would be options.
<wasabi> I don't know how those options would be determined automatically.
<wasabi> but there would be options. ;)
<Keybuk> remember how long it took to download the Packages file, and its size to determine archive speed -- then use the delta sizes and deb sizes in the Packages file to calculate whether there's a benefit in getting the deltas instead
<wasabi> Yeah. THe sizes are listed. Take all the possible paths, find the shortest one by size.
<wasabi> where direct upgrades are a possible path
<wasabi> I wonder what the average patching time is
<Keybuk> APT's C++ is pretty readable
<Keybuk> it's more of a "struct and some functions that use it" kind of OO
<wasabi> Oh actually.
<wasabi> Oh.
<wasabi> My evolution measurement was way off.
<Keybuk> rather than a Java/Smalltalk nut's crack
<wasabi> It's 28M to 3M
<wasabi> That's massive.
<wasabi> Ahh. I see. 28M is the data.tar, 9MB is the data.tar.gz.
<wasabi> the patch is 3.8M, so it isn't that good.
<wasabi> Are the entries in the data.tar sorted?
<Keybuk> executables are a bitch to delta, because the compiler will insist on moving damned functions around in memory :p
<Keybuk> wasabi: not generally
<wasabi> That might help massively
<Keybuk> I think xdelta copes with that though
<Keybuk> it's designed to diff tar files, after all
<Keybuk>   if (!(c1= m_fork())) {
<Keybuk>     m_dup2(p1[0] ,0); close(p1[0] ); close(p1[1] );
<Keybuk>     m_dup2(p2[1] ,1); close(p2[0] ); close(p2[1] );
<Keybuk>     if (chdir(directory)) ohshite(_("failed to chdir to `%.255s'"),directory);
<Keybuk>     execlp(TAR,"tar","-cf", "-", "-T", "-", "--null", "--no-recursion", (char*)0);
<Keybuk>     ohshite(_("failed to exec tar -cf"));
<Keybuk>   }
<daniels> heh, ohsite()
<daniels> er, ohshite()
<Keybuk>     execlp(FIND,"find",".","-path","./" BUILDCONTROLDIR,"-prune","-o","-print0",
<Keybuk> and that to give the file list
<Keybuk> so there's no sorting, other than it moves symlinks to the end for shits and giggles
<Keybuk> daniels: ohshit() is an exception, ohshite() is an exception which errno is useful for :p
<daniels> heh :)
<wasabi> This could also be made efficient... threaded.
<eruin> I like your style ;)
<wasabi> Say you have 4 patches to reach a new version.
<Keybuk> heh, that's iwj-C, not mine!
<wasabi> IT could be applying the first while it downloads the 2nd
<Keybuk> daniels: ya know, I've never noticed before, but that's doing a longjmp inside a child process
<Keybuk> so it's the child that bungees into error handling, instead of the parent
<Keybuk> CRACK!
(Mithrandir/#ubuntu-devel) Keybuk: it's dpkg, what do you expect?
<Keybuk> and I'm only noticing, because I've hit the same bug in Python -- where you end up handling the exception in the child which carries on its merry way while the parent is waiting for it to finish
<daniels> Keybuk: heh!  that's part of dpkg, is it?
<daniels> http://www.freedesktop.org/~pasc/maillist.html
<daniels> erk, ww
<Keybuk> this explains at least three open bugs on dpkg :p
(pasc/#ubuntu-devel) but since daniel posted it here... if someone have some comments on how the indices look on that page, I'd be interested to know ;-)
(pasc/#ubuntu-devel) to know what people think that is. I still haven't modified the actual message views, but that will come later
<wasabi> Noooooooooooooo
<wasabi> I just typed up all the stuff we talked about in the wiki
<wasabi> hit submit, and it didn't work. =( and Epiphany lost it
<Keybuk> d'oh
<wasabi> and then the wiki went *beep beep beep* and my page was gone. +9
<eruin> why oh why does openoffice.org supply a so-called "installer" archive that just contains rpms
<Kyaneos> hi
<wasabi> Keybuk, https://www.ubuntulinux.org/wiki/APTPackageDeltas   I have no experience hacking in dpkg or apt, so im looking around now. Maybe i'll come up with something.
<Keybuk> wasabi: has some major vanishing-off-the-right-hand-side issues
<wasabi> plain text.
<wasabi> i dont' know any of the listed wiki languages.
<Keybuk> some newlines at 70-column would be great :p
<wasabi> I'd just assume figure out MoinMoin or something.
<Keybuk> there's no scrollbar, it just cuts
<wasabi> i have scrollbar
<Keybuk> hmm, I just have a vertical one
<wasabi> scroll down?
<Keybuk> oh
<wasabi> hehe.
<Keybuk> there's a scroll page in the *page*
<Keybuk> gee, that's useful
<wasabi> yeah.
<Keybuk> so I scroll down, scroll right, then scroll up to find I've scrolled to far
<Keybuk> I swear
<Keybuk> if I ever meet the designer of this new wiki, there will be words
<Keybuk> and then there will be death
<wasabi> it's pretty slow too.
<Keybuk> it's a total chocolate teapot
<Keybuk> it might fit with everything else in the chocolate store
<Keybuk> but you can't make tea in it.
<wasabi> haha
<ogra> Keybuk: who is responsible for the old wiki still being online ?
<Keybuk> ogra: no idea, someone who I shall be friends with, I suspect.  is it?
<ogra> there is no pointer to the new one.....
<daniels> i swear, twiki is better than zwiki
* Keybuk sobs for moin
<Keybuk> I like moin
<Keybuk> you can *gasp* use it
<Keybuk> so, I can either make my font size too small to read
<daniels> Keybuk: font size> in bugzilla?
<Keybuk> or I can select and drag right slowly until it scrolls how far I want
<daniels> oh, right
<Keybuk> wasabi: hmm, your text seems to only allow for single deltas
<Keybuk> "from this source version to the new version"
<wasabi> yeah.
<wasabi> you can have multiple lines listed.
<Keybuk> so there's no way to download three or four consecutive deltas and put them together ?
<wasabi> Just didn't make a note of it
<wasabi> Oh, sure, you just have to trace through all the Packages entries
<Keybuk> our archive churn is really too fast to expect people to only be taking one version jump
<wasabi> okay, I can get 1.0.1 to 1.0.2
<Keybuk> there's only one Packages entry for a given Package
<wasabi> how how can I get 1.0.1 from 1.0.0
<wasabi> oh?
<wasabi> is there?
<Keybuk> because there's only one version of that Package in the archive
<wasabi> I thought there were multiple with different versions
<Keybuk> :-o no!  what would be the point?  APT would just pick the latest one
<wasabi> Well... ;)
<wasabi> Just FYI!
<Keybuk> there can be different versions in different Packages files
<wasabi> Hmm./
<wasabi> That's unfortunate. THe way I imagined it would be pretty slick
<Keybuk> but you certainly can't have more than one in the same file ... it breaks an assumption
<Keybuk> you'd need to keep the .debs around as well
<Keybuk> and then your archive gets biiig and faaat
<wasabi> yeah, old .deb's are kept around.
<wasabi> To an extent.
<Keybuk> and people who mirror you say "fuck dial-up"
<wasabi> I have two versions of xorg for instance.
<wasabi> Well. Then I just add two versions into the Delta's section
<wasabi> no biggy, just not as cool as I thought it was. ;)
<Keybuk> and then you work out it's cheaper to send dial-up users free CDs than expect them to download an update
<Keybuk> because the hardware and bandwidth upgrade to support all that extra weight costs more than shipping half a million CDs
* sivang joins Keybuk sobbing on moin.
<wasabi> Probably makes the code easier anyways.
<Keybuk> wasabi: also don't use ".debdiff", there's already a tool called that
<Keybuk> .debpatch or .debdelta is fine though
<wasabi> oh. That was your example. ;)
<Keybuk> no, I used .debdelta :p
<wasabi> damn. foiled again.
<Keybuk> mention the patches are against the uncompressed control.tar.gz and data.tar{,.gz,.bz2,.Z,*}
<wasabi> Oh here's another question.
<wasabi> the data.tar.gz, is there a standard compression level?
<Keybuk> -z9 by default
<wasabi> Can that be altered by the packager?
<Keybuk> if they like
<wasabi> If so, it makes generating exact copies hard.
<Keybuk> deb-deb -z3
<wasabi> Since the repackaging has to know what it should be.
<wasabi> Or the checksums don't match
<Keybuk> yeah, you're going to need some "DON'T LOOK AT THAT CHECKSUM" fiddling anyway :p
<wasabi> Hmm. Was hoping there was some way around that. ;)
<Keybuk> well, gzip is theoretically deterministic
<Keybuk> so if you put the .deb back together it should match the md5sum of the deb you would've downloaded anyway
<wasabi> Except `ar' stores dates.
<Keybuk> but, as you say, you'd need to take into account the -z and -Z flags used when putting together the .deb
<wasabi> or does it. i dunno.
<Keybuk> yeah it does
<wasabi> well the entire thing falls apart then.
<wasabi> unless i ignore checksums, which I really dont want to do
<wasabi> Eh, actually. If the checksums of the .debdeltas are stored in the Packages file, it's not a security issue.
<Keybuk> hmm, why not?
<wasabi> Well, my concern was that if a bad .deb is generated from this process, then you'd have to skip checksums... and by skipping checksums there would be a way for a evil archive to sneak something in.
<wasabi> But if the Packages file hsa the sums of hte .debdeltas, then there's no way to sneak anything in.
<Keybuk> yeah ther eis
<wasabi> ?
<Keybuk> you craft a Packages and set of xdeltas to attack a known version of a .deb
<Keybuk> but the checksum would still match, I guess *shrug*
<wasabi> Packages.gpg?
<Keybuk> I'm not sure whether APT re-checks the checksums of things in its cache before installing or not
<wasabi> Somebody (maybe you!) is working on signing apt I think.
<Keybuk> that was Progeny
<wasabi> s/apt/Packages/
<Keybuk> mdz maintains Debian's APT, and has a branch that includes that stuff
<wasabi> Well, it's no more a vuln than it is currently.
<wasabi> https://www.ubuntulinux.org/wiki/APTAuthentication
<Keybuk> you could compromise someone's machine, replacing something in /var/cache/apt/archives with something malicious
<wasabi> You could do that now.
<wasabi> If you've done that, you mine as well just hack the machine while you were in it.
<Keybuk> I don't think you can with Secure-APT
<Keybuk> it verifies the Packages file and the Packages when it installs them
<Keybuk> not just when it downloads them
<Keybuk> (I think)
<wasabi> I think the secure apt idea is just to verify downloads.
<wasabi> I think it's just a matter of signing Packages.gz
<Keybuk> largely, yeah
<wasabi> /var/cache/apt is root owned. If somebody is in that, they have owned the system already.
<wasabi> I think ignoring checksums of assembled .deb's is pretty decent.
<wasabi> No longer worried about it
<wasabi> So I guess some of this has to be in Dpkg, and some of it in Apt.
<wasabi> Dpkg needs all the proper stuff to take a .deb and a .debdelta and produce a new .deb
<wasabi> ANd apt needs to handle the resolution of all that and pass it to dpkg.
<RubenV> Hi, i'm trying to build a .deb
<RubenV> however, when issuing dpkg-buildpackage -rfakeroot
<RubenV> i get a permission denied error
<RubenV>  fakeroot debian/rules clean
<RubenV> /usr/bin/fakeroot: line 150: debian/rules: Permission denied
<daniels> chmod +x debian/rules
<daniels> either that, or use debuild
<RubenV> oh, forgot
<RubenV> :/
<RubenV> let's see if this get's me further
<Keybuk> wasabi: I'd just make it a companion tool, rather than changing dpkg
<Keybuk> dpkg-delta and dpkg-patch for example
<Keybuk> anyway, I'm going to go and satisfy my mass-entertainment needs by watching Simon Cowell be hilariously mean to people
<wasabi> enjoy.
<RubenV> doesn't dpkg-buildpackage call autoconf automatically?
<Keybuk> RubenV: no.
<wasabi> no.
<RubenV> (never done this before)
<robtaylor_> mjg59: alive?#
<Keybuk> not unless the package's debian/rules calls autoconf
<Keybuk> which is a silly thing to do anyway
<wasabi> dpkg-buildpackage does nothing except try to reach the proper targets in debian/rules.
<Keybuk> if you ever need to run autoconf on source you downloaded (rather than got from CVS) you need to hurt someone
<RubenV> it's a cvs checkout
<RubenV> autoconf gives me horrible errors though
<Keybuk> autoreconf -i
<RubenV> something is horribly wrong with this source tree :)
<wasabi> hmm. this leaves off the possibility of using patches to rename packages. ;)
<wasabi> So I wrote a script to generate a .debdelta from two .debs
<wasabi> Even small packages are getting significant savings.
<RubenV> wasabi: i was thinking about the same thing a couple of days ago
<RubenV> while I was slurping OO.o over a slow line
<wasabi> https://www.ubuntulinux.org/wiki/APTPackageDeltas
<wasabi> think about it there.
<RubenV> there should be a way to delta pkgs :)
<wasabi> yeah. working on that.
<RubenV> great idea
<RubenV> Also a Packages.bz2 delta could be usefull
<RubenV> one/day or so
<wasabi> that would be hard to keep track of
<wasabi> since Packages does not have any sort of version indicator.
<RubenV> true
(haggai/#ubuntu-devel) eruin: were you looking for binaries of openoffice 1.9.x ?
(smurfix/#ubuntu-devel) wasabi: you could use the md5sum of the Packages file as the "version number".
<phlax> hi there - trying to use ldap auth - when I add ldap to nssswitch i can no longer get rootly powers - anyone got any ideas?
<mxpxpod> chrisa: ping
<ggi> Is the association of every sort of text file with OpenOffice.org intentional?
<Keybuk> wasabi: you can't technically rename a package anyway, so that's not exactly a problem :p
<wasabi> yeah.
<wasabi> I've got two scripts writte
<wasabi> dpkg-gendelta, and dpkg-delta
<wasabi> one creates a delta given two packages, the other takes an original package and a .debdelta and produces the new package.
<wasabi> Both work.
<wasabi> just bash scripts though. :0
<Keybuk> heh, all the best things are :p
<wasabi> SO in theory it works.
<wasabi> THe dpkg part at least. ;)
<wasabi> And it produces a valid .deb that installs. Yay.
<wasabi> epiphany goes from 2.8MB to 774k.
<wasabi> that's a pretty big savings.
<wasabi> woh.
<wasabi> mozilla-firefox goes from 9.0M to 216k
<wasabi> just this one little -4 ubuntu change
<sivang> wasabi : have you used python to do this?
<wasabi> bash
<sivang> wasabi : ah nice, could you send me the scripts?
<wasabi> dcc?
<sivang> wasabi : darn, my firewall probably blocking this..strange, I added the IRC helper module to netfilter..
<wasabi> actually i probably can't sand that.
<wasabi> heh forgot where i was
<sivang> wasabi : mail would be also fine :)
<wasabi> addy?
<sivang> wasabi : sivanSpamfreeaTworkaround.org 
<wasabi> sent.
<sivang> wasabi : thanks. so you basically compute the difference and download only the remaining parts?
<wasabi> oh no.
<wasabi> these are just two examples.
<mxpxpod> is there a guide out there on how to make a ubuntu kernel image?
<wasabi> of how feasibly it would be to do.
<wasabi> feasible.
<wasabi> it is not in any way shape or form functional.
<wasabi> heck I just did it in 20 minutes.
<sivang> wasabi : k, thanks anyways.
<mxpxpod> because I'd like to make a 2.6.9 image with benh's sleep patch applied, plus the wlan-ng patches from ubuntu
<wasabi> This has me thinking weither a new extension should be used or not... maybe these "patches" could just be ".debs" that require the previous version to be installed.
<wasabi> s/installed/available/
<wasabi> heck, or just installed. And just distribute changed files.
* wasabi ponder.
<eruin> haggai, ooh, yes
<eruin> haggai, sorry for the slow reply on ooo 1.9 debs ;)
<wasabi> Keybuk, new thought process. What if these "patches" were .deb files. Exactly like normal .deb files. The difference being that the data.tar.gz only contains changed files, and they contain a control field that says they are an update to another package.
<wasabi> No delta's required.
<wasabi> Internal dpkg mods...
<wasabi> to extract the new files in / and then run the scripts on control.tar.gz
<Keybuk> SUN-like you mean?
<wasabi> ?
<Keybuk> SUN patches are distributed as package files that just contain the replacement files
<wasabi> I'm spelunking in dpkg code now figuring out how to do that. It really sounds easy.
<Keybuk> or, in some cases, just the deltas with a class to apply them rather than copy over the top
<Keybuk> two problems
<wasabi> deletions.
<Keybuk> yup
<wasabi> (file in control listing them)
<Keybuk> basically it'd be a package that only had changed files, with a magic control field to tell dpkg not to delete anything not in the new package
<wasabi> what's hte other one?
<Keybuk> moves
<wasabi> I'll have to think thorugh how hte info files will be altered.
<wasabi> moves are fine.
<wasabi> doesn't matter. just gets redownloaded.
<Keybuk> you can pretty much just stick an 'if (! a_patch_package)' round a large block of process_archive
<wasabi> yeah.
<wasabi> That's what im thinking.
<wasabi> THere will have to be a few mods into the management of the db.
<wasabi> In order to alter the info file, by adding the new additions to it
<Keybuk> it does that anyway
<Keybuk> if you look at process_archive, it adds the new files first
<Keybuk> and then goes through the list to see whether it needs to delete anything
<wasabi> Ahh.
<wasabi> How does it tell if it needs to delete anything? If it doesn't exist in the archive?
<Keybuk> yeah :)  just sets a flag on the file list entry as it unpacks the file
<wasabi> We only want it deleting stuff that exists in a composite of hte old and new archives.
<Keybuk> then iterates the file list to see if there are any entries without flags
<wasabi> does not exist that is
<wasabi> Will have a different naming convention on the .deb though.
<wasabi> old_new
<wasabi> or, maybe something else
<Keybuk> processarc.c  line 586-662 (roughly)
<wasabi> Okay, so that can stay as it is, but the list it operates on can be altered
<Keybuk> the list it operates on is just the old file list
<Keybuk> you just need some way of copying stuff from the old file list to the new one before that
<wasabi> Hmm. So what the unlink?
<Keybuk> you'd need to cope with an empty data.tar.gz too
<Keybuk> sometimes uploads are just control-file changes
<wasabi> well, that should handle itself.
<Keybuk> would be nice if you could build one of those without trying too :p
<Keybuk> wasabi: ever tried to make an empty tar.gz ? :p
<mxpxpod> is there a kernel team for ubuntu?
<wasabi> it would simply be like an upgrade that installed nothing.
<wasabi> Oh. Heh.
<wasabi> Suspose you can't do that?
<Keybuk> descent scott% tar czf foo.tar.gz
<Keybuk> tar: Cowardly refusing to create an empty archive
<wasabi> Could have something like a first ignored file in it all the time
<wasabi> .DEBIAN or something.
<Keybuk> just stick ./ in it
<wasabi> ahh you can do that?
<wasabi> heh.
<wasabi> That's silly in a way.
<Keybuk> descent scott% tar --no-recursion -czf foo.tar.gz ./
<Keybuk> descent scott% tar tzf foo.tar.gz
<Keybuk> ./
<wasabi> how big is it?
<Keybuk> 111 bytes
<wasabi> workable, silly, but workable.
<wasabi> So this seems pretty easy actually.
<wasabi> Just a few ifs really.
<wasabi> All the hard stuff is really up to apt.
<Keybuk> yeah, it's some neuro-surgery on dpkg to make it understand that it doesn't need to remove the old files
<Keybuk> you'd need the patch-deb filenames to be pretty obvious, to make sure people don't download them by accident unless they want them
<sivang> wasabi : wow, you're gonna make it not delete the old file, and just add them the binary delta?
<wasabi> no real need for delta at all
<wasabi> that I see anyways.
<wasabi> Interesting.
<wasabi> If you have a 1.0.0 to 1.0.5 .deb patch.
<sivang> wasabi : ah, just pull out the changed dependencies?
<wasabi> You can upgrade 1.0.1 to 1.0.5 using the same file.
<wasabi> So, the archive scripts can really optimize good upgrade paths.
<Keybuk> wasabi: only if the same files were changed in each version between that
<wasabi> Keybuk, a 1.0.0 to 1.0.5 patch would contain all the mods between 1.0.0 and 1.0.5
<Keybuk> oh, sorry
<Keybuk> yeah, that'd work
<wasabi> If 1.0.0 to 1.0.5 cover 20 versions, but ends up being like one file changed 20 times, it'd be one very small patch.
<wasabi> the archive scripts could do some optimization on that.
<Keybuk> this wouldn't work too well for mostly-binary packages though
<Keybuk> the resulting debs would be the same as the non-patch debs
<wasabi> THe deltas don't work well for those either though.
<Keybuk> true
<wasabi> And in that case, the archive scripts can just not make them.
<wasabi> If there is no savings.
<Keybuk> it's a pity that every upload is a rebuild
<Keybuk> which means every upload there is a slight change to every binary :-/
<wasabi> Well, that can, and probably should, be solved in other ways.
<wasabi> Why would gcc turn the same thing into a different thing two times?
<Keybuk> because it's non-deterministic
<wasabi> i fail to see how a compiler can be non-deterministic unless it has a random number generator in it. :0
<mxpxpod> mjg59: ping
<Keybuk> memory offsets and whatnot
<wasabi> or encodes times into it
<wasabi> wasabi@kyoto:~ $ gcc test.c
<wasabi> wasabi@kyoto:~ $ md5sum a.out
<wasabi> 7e7fb7d522a047d438aa60b4a4918553  a.out
<wasabi> wasabi@kyoto:~ $ rm a.out
<wasabi> wasabi@kyoto:~ $ gcc test.c
<wasabi> wasabi@kyoto:~ $ md5sum a.out
<wasabi> 7e7fb7d522a047d438aa60b4a4918553  a.out
<wasabi> ???
<Keybuk> do it on a different machine ?
<wasabi> true.
<Keybuk> descent scott% md5sum main-only
<Keybuk> 11d9ad98f23a24f04f3365e280b3aa63  main-only
<Keybuk> syndicate scott% md5sum main-only
<Keybuk> 79e1a52f4e49295c11bcd29680b4661b  main-only
<wasabi> ahh well.
<Keybuk> and that's the simplest example there is :p
<wasabi> not a super big deal. I supose down the road some optimization can be made there, to do some sorta more complicated diff on binaries to see if they really are different.
<wasabi> but that's probably not a good idea.
<wasabi> would screw md5sum's in the packages all to hell
<Keybuk> heh, you wanna write it? ;)
<Keybuk> but then I guess binaries are rarely the *major* component of any package
<wasabi> I'm gonna try to understand this dpkg code and see what I can do.
<wasabi> Hmm.
<wasabi> control/md5sums in the new package lists every file.
<wasabi> and it would in the upgrade package too
<wasabi> Yeah, it's just a few k.
<wasabi> Another optimization would be to include file deltas in the new data.tar.gz... instead of including /usr/share/blah/whatever.svg, it would include /usr/share/blah/whatever.svg.patch, and make a not in one of hte control files that this is a patch to that file.
<wasabi> That can also be done later without any trouble.
<Keybuk> control/md5sums isn't mandatory
<Keybuk> dpkg itself doesn't have one, for example
<wasabi> Well, if a openoffice upgrade is distributed with 1 file moded, all billion files would be listed.
<Keybuk> yah
<wasabi> which I think is okay
<wasabi> gzipped it's nothing.
<Keybuk> tricky, because dpkg doesn't touch md5sums at all
<wasabi> yeah, but it has to be present. I dont think any diffs or antyhing are going to be done on control.tar.gz
<Keybuk> doesn't have to be present
<Keybuk> it's not part of the deb format
<wasabi> i know, im just sayin. ;)
<mxpxpod> how do you guys make your kernels?
<Keybuk> changelogs are the killer
<Keybuk> mxpxpod: kernel-package
<mxpxpod> Keybuk: do you use vanilla kernels?
<Keybuk> mxpxpod: yes.
<mxpxpod> Keybuk: what if I want a patch that ubuntu applies... like the wlan stuff
(tseng/#ubuntu-devel) apt-get linux-source
(tseng/#ubuntu-devel) -2.6.8.1
(tseng/#ubuntu-devel) gives you the patched tree
<mxpxpod> tseng: right... I'd like to compile a 2.6.9 tree
<Keybuk> mxpxpod: linux-patch-debian-2.6.8.1
#ubuntu-devel 2004-12-02
<mxpxpod> Keybuk: and it's in a patch that has a bunch of stuff in it
<wasabi> heh. changelogs.
<wasabi> You use kernel-package?
<wasabi> doesn't it generate kernel-image packages, and not linux-image?
<wasabi> ANd not all those cool symlink stuff.
<wasabi> Or was that fixed? :)
(tseng/#ubuntu-devel) the only difference between kernel-image and linux-image is the name afaik
(tseng/#ubuntu-devel) i hope someone can enlighten us otherwise
<wasabi> well linux-source packages are a bit different.
<wasabi> They use a symlink farm of some sort in /usr/src
(tseng/#ubuntu-devel) no kidding, thats why its called -source
<wasabi> make-kpkg never build those for me with kernel_source.
(tseng/#ubuntu-devel) never built the linux-source?
<wasabi> the symlink farms.
<mxpxpod> is there a reason ubuntu hasn't upgraded to 2.6.9?
<wasabi> it just makes flat dirs in /usr/src
<FTTP> hi
<FTTP> any hoary isos working yet?
<FTTP> tried a developmental snapshot which had issues
<Keybuk> what kind of issues?
<eruin> the 2.6.9 I tried had some crazy issues with kswapd
<FTTP> keybuk:  Installer screen came out all messed up
<FTTP> it was not usable
<FTTP> its only a dev so....
<FTTP> keybuk:  Was work done to the newest daily snapshot?
<FTTP> or are there any releases which i can try for hoary which are more stable than the others?
<Keybuk> not that I'm aware of ... I've not heard that bug
<Keybuk> is it in Bugzilla (opened or closed?)
<FTTP> keybuk:  I didnt report it
<FTTP> should I try the newest snapshot and report it?
<Keybuk> sure
<FTTP> if it occurs again
<FTTP> ok
<FTTP> keybuk you a developer for ubuntu?
<Keybuk> ish
<Keybuk> :p
<FTTP> ish?
(Mithrandir/#ubuntu-devel) Keybuk: pft, you're well an ubuntu dev. :)
<Keybuk> I work for Canonical, but most of my time isn't working on Ubuntu itself at the moment
<FTTP> ahh
<FTTP> what are you responsible for? 
(Mithrandir/#ubuntu-devel) Keybuk: you're still an ubuntu developer, though
<Keybuk> FTTP: "Special Projects", heh
<FTTP> such as?
<FTTP> or they cant be disclosed so they are SPECIAL :)
<wasabi> assassinating high level redhet executives.
<FTTP> hehe
<Keybuk> Mithrandir: I didn't even have my key in the keyring until last week!
<Keybuk> FTTP: heh, it's a joke ... Special Projects is the mythical dept. people get transferred to before they're made redundant
(Mithrandir/#ubuntu-devel) Keybuk: you didn't?  that actually surprises me :)
<Keybuk> Mithrandir: nah, almost the only stuff I've uploaded have been that big match of first-run merges
<daniels> Mithrandir: would *you* want him uploading to Ubuntu?
<daniels> Mithrandir: mdz just has good taste ;)
(Mithrandir/#ubuntu-devel) daniels: sure, I need my daily dose of crack.
<sivang> Keybuk : have you spotted my BOF proposal for a python workshop? What do you think? :)
(Mithrandir/#ubuntu-devel) Keybuk: I haven't uploaded much either, though.
<Keybuk> sivang: I thought "cool" :)
<daniels> Mithrandir: craaaaaack
<Keybuk> daniels: heh, the trouble with filling mdz's shoes on Tuesday was THEY'RE TOO SMALL! :p
<daniels> heh :)
<sivang> Keybuk : Feel free to add your comments there, maybe a list of requested reading before it, I want to come prepared :)
<FTTP> any 24 hour a day coders over at canocal?
<FTTP> :P
<FTTP> heh
<daniels> FTTP: no, but I've hardly left my laptop in the last 5 days :P
<Keybuk> sivang: "Dive into Python" :)
<FTTP> daniels:  u know the link for the hoary isos?
<FTTP> the snapshots
<sivang> Keybuk : ah, then I'm already set :)
<FTTP> cant seem to find the link 
<daniels> FTTP: http://archive.ubuntu.com/cdimage/, I'd imagine
<FTTP> ahhh
<FTTP> thanks
<daniels> Keybuk: speaking of Python -- http://gabe.freedesktop.org/~daniels/old-to-new-ldap.py
<FTTP> ill bookmark that :P
<daniels> Keybuk: check that baby out :)
<daniels> Keybuk: the two password crypting functions are stolen from userdir-ldap, the rest is mine
<Keybuk> daniels: what does that *do* ?
<Keybuk> FTTP: we have coders in every timezone
<Keybuk> and I've certainly done the odd 24+ when I've not noticed the sun come up again
<daniels> Keybuk: takes an ldif of our old ldap database, generates an ldif of the new-format setup
<daniels> Keybuk: lies
<daniels> Keybuk: there's no-one in +1300 (NZ)
<Keybuk> daniels: pedant :p  you knew what I meant :p
<daniels> or +0950, or +1050, or +1000
<Keybuk> daniels: aww, so it doesn't convert woody-era ldap to sarge-era ldap? :(
<daniels> Keybuk: but yeah, the code is pretty horrible
<stratus> -0300 ?
<daniels> Keybuk: nope, just different formats of database
<FTTP> keybuk:  Shouldnt you be coding now ? :)
<FTTP> heh
<daniels> stratus: wtf is that?
<FTTP> oh wait your in special projects
<FTTP> i fergot
<Keybuk> daniels: *cry* ... my ldap server is broke because of that
<daniels> Keybuk: i.e. one from some horrid abortion called usradm to userdir-ldap
<FTTP> :P
<Keybuk> keeps bitching about records not being structural
<daniels> Keybuk: should happen ... oh, wack
<daniels> Keybuk: how many records?
<stratus> daniels, BRT of course.
<daniels> stratus: oh, right
<daniels> stratus: is that in line with us est, or is it an hour ahead?
<daniels> stratus: because we have someone in est
<Keybuk> daniels: not a huge number
<Keybuk> but I can't figure out what it's talking about
<wasabi> oye.
<Keybuk> and how I'm supposed to solve it
<stratus> daniels, i guess not, checking...
<daniels> Keybuk: meh, just do it by hand
<wasabi> dpkg is ugly
<daniels> Keybuk: probably to do with your objectClasses
<Keybuk> I added a silly structural record type to them all
<Keybuk> then it bitched about having two structural types in some of the fields
<Keybuk> and I declared that I couldn't win
<stratus> daniels, no EST is -0500
<daniels> stratus: ah.  in any case, actually, we do have people there.
<FTTP> keybuy: Array1 is more stable right?
<FTTP> err keybuk
<stratus> daniels, np but not at -0300 !
<FTTP> i tried the daily last time
<daniels> Keybuk: you can never win with LDAP
<daniels> Keybuk: just lose less horrendously badly
<daniels> stratus: yes we do :)
<daniels> stratus: i just realised we have some people in brazil
<Keybuk> FTTP: *shrug* Array has Colin's hand-built touch
<Keybuk> so theoretically it's more ... testable
<FTTP> yep
<FTTP> :P
<Keybuk> daniels: tell me about it
<seb128> hum, the archive is not updated ?
<stratus> daniels, oh yes the guys at async?
<Keybuk> from what I could tell, posixGroup is structural -- but then posixAccount *isn't*
<seb128> the new gnumeric has built for hours and is still not available
<wasabi> Keybuk, you know much about parsedb and pkginfo struct?
<daniels> stratus: aye
<Keybuk> but organization is structural ... so what if something's both an Organisation and a POSIX Group?!
<stratus> daniels, i see
<Keybuk> wasabi: yeah, it's just a linked list of the state file
<wasabi> Posix group is messed up
<wasabi> nss_ldap also reads groupOfUniqueNames
<daniels> Keybuk: yeah, don't use posixAccount
<wasabi> I believe.
<Keybuk> well, I changed posixGroup anyway to have "gid" instead of "cn"
<daniels> Keybuk: i use top/inetOrgPerson/shadowAccount/debianAccount/debianDeveloper
<Keybuk> so maybe I just need to change that to be auxiliary
<wasabi> posixGroup is a pretty dumb class.
<Keybuk> daniels: top isn't structural :-o
<daniels> Keybuk: but iirc the old stuff was top/posixAccount/shadowAccount
<daniels> Keybuk: in that case, none of our records are, but sarge/warty's ldap still loves me \o/
<Keybuk> slapadd: dn="dc=netsplit,dc=com" (line=7): (65) no structural object class provided
<Keybuk> objectClass: top
<Keybuk> ^ yet
<daniels> dn: dc=freedesktop,dc=org
<daniels> objectClass: top
<daniels> objectClass: dcObject
<daniels> objectClass: organization
<daniels> o: freedesktop.org
<daniels> dc: freedesktop
<Keybuk> organization is structural
<Keybuk> I hate ldap
* Keybuk about -> <- this far away from dumping it and going back to passwd
<mojo> Good morning all fellows
(kylem/#ubuntu-devel) ldap >>>>>>> nis.
<FTTP> will ubuntu have enuff capital to compete with the likes of novell + redhat?
<mojo> I no longer can sync with CVS from gnome.org/gnome-icons
<FTTP> developers are top notch i know
<FTTP> :)
<FTTP> but i worry about capital 
<mojo> does anyone know something wrong with the CVS server?
<Keybuk> FTTP: we have a similar amount of capital in the bank as RedHat, as I understand it
<FTTP> keybuk:  Novell has 500mil +
<FTTP> it won a microsoft lawsuit <grin>
<Keybuk> yeah, but Novell is a much larger business than Ximian
<wasabi> yeah but redhat is making money.
<daniels> kylem: represent
<wasabi> =)
<daniels> anyway, this is all horrifically offtopic (novell, ldap, stuff)
<FTTP> anyways
(kylem/#ubuntu-devel) daniels, and take it from me, i administrate both. :(
<FTTP> burning dev cd
<FTTP> keybuk:  We will see :)
<FTTP> keybuk:  When hoary comes out we will know more 
<Keybuk> FTTP: true, but then RedHat have to go begging for more money, we just have to excite the boss
<Keybuk> actually, the "plan" is to be starting to make money in 18 months time
<FTTP> shuttleworth is easy? :)
<Keybuk> so more perky-era
<FTTP> hehe
<FTTP> keybuk:  From what?  just support?
<FTTP> keybuk:  I hope your right :) seen too many distros come out and go poof
<FTTP> ubuntu has so much potential
<FTTP> anyways back to dev chat
<FTTP> ---------pretend im not here
<FTTP> :P
<wasabi> So, who "makes decisions"?
* Keybuk gives up and goes back to /etc/passwd
<Keybuk> wasabi: it's complicated
<Keybuk> the developers make decisions
<Keybuk> but if they can't reach consensus, they can ask either the technical board or the community council to make a decision for them
<Keybuk> and if they can't reach consensus, we ask Mark
<wasabi> Otherwise it's just like Debian, people do what they think they should do whenever?
<Keybuk> kinda, the tech board and sabdfl both set direction for people to head in
<wasabi> Hmm.
<wasabi> Dpkg is confusing me to no end.
<Keybuk> it's good at that
(sabdfl/#ubuntu-devel) it's usually the pointy end that gets the most confused by dpkg though
<wasabi> I found parsedb(), which reads hte control file... but I have no idea what it's doing with the values.
<stratus> discarding them? :)
<Keybuk> puts them in the package info list
<wasabi> struct pkginfo?
<jdz_> Are there any plans for LTSP work in Ubuntu?
<Keybuk> the package list is global, so it doesn't get passed in or out, just added to in general
<Keybuk> oh, would it help to know findpackage always returns?
<Keybuk> so if you try and find a package that doesn't exist, you get an empty record to fill in?
<wasabi> heh.
<wasabi> Right now im just trying to figure out how to expose my new control fields to the code.
<Keybuk> thus pig=findpackage(newpig.name); actually makes a record
<wasabi> And I don't understand the relation of the pkginfo struct to the deb and to the currently installed packages
<Keybuk> add it to the fieldinfos
<wasabi> if a package is currently installed, the pkginfo struct you receive makes note of it
<wasabi> fieldinfos
<wasabi> where?
<Keybuk> top of parse.c
<wasabi> oh. that.
<wasabi> ;)
<wasabi> f_whatever = type, w_whatever = ???, other col = ???
<Keybuk> name, read function, write function, offset in structure
<Keybuk> (or some other integer you want to pass to them)
<FTTP> anyone know about module hid in hoary?
<sivang> FTTP : it has one? doesn't it?
<FTTP> lol
<FTTP> i tried the developmental daily snapshot
<FTTP> it says fatal error module hid not found
<FTTP> so nope it doesnt 
<wasabi> Keybuk, in pkginfo,   struct pkginfoperfile installed;  struct pkginfoperfile available;   Is available the instance of hte package attempting to be installed, and installation the one that is already installed (or null)?
<Keybuk> installed is the one in the status file
<Keybuk> available is the one "on the FTP site"
<wasabi> cool.
<Keybuk> (ie. in the available file)
<Keybuk> neither are the one on disk
<wasabi> eh?
<wasabi> oh you mean in the archive?
<Keybuk> yeah
<wasabi> Yeah, the archive is just for apt.
<Keybuk> remember, APT is a "relatively" new invention
<wasabi> but if I do dpkg -i /blah/blah.deb, available refers to that one
<Keybuk> no.
<Keybuk> the available file is populated by "dselect update"
<Keybuk> and mucked around with by dselect
<wasabi> Well im totally confused then
<wasabi> What is the one "being installed right now"?
<Keybuk> neither
<wasabi> well im totally confused then.
<wasabi> parsedb(cidir, pdb_recordavailable|pdb_rejectstatus|pdb_ignorefiles|pdb_weakclassification,          &pkg,NULL,NULL);
<wasabi> does that not read the control file from the .deb being installed?
<Keybuk> there's a "pkginqueue" struct
<wasabi> not that I can see.
<FTTP> hid = Human interface device right?
<FTTP> so thats the mouse, keyboard
<wasabi> correct.
<Keybuk> yeah, that call passes &pkg to parsedb (donep) so parsedb returns the pig
<wasabi> pig stands for?
<FTTP> wasabi can one submit code changes?
<wasabi> FTTP, to?
<FTTP> i mean suggestions
<Keybuk> pig
<Keybuk> piggy wiggy
<Keybuk> go oink, have tails
<wasabi> ...
<FTTP> wasabi to fix bugs like hid not found :P
<Keybuk> iwj likes calling packages pigs
<wasabi> FTTP, I'd imagine so.
<Keybuk> we don't ask why
<wasabi> FTTP, bugzilla.
<FTTP> wasabi ok
<wasabi> okaaay.
<FTTP> :)
<wasabi> well hell. I dont get it.
<Keybuk> K
<wasabi> parsedb returns a pkginfo. This pkginfo has an installed and available struct. They are not representative of what is being installed.
<wasabi> pkginqueue (which I cannot find)
<wasabi> is.
<Keybuk> ah, sorry
<Keybuk> I see your confusion there
<Keybuk> yeah, that parsedb call is told to fill the available pkginfoperfile struct
<Keybuk>   newpifp= (flags & pdb_recordavailable) ? &newpig.available : &newpig.installed
<Keybuk> inside process_archive, pkg->available is the one you're processing, pkg->installed is the one you're replacing (if any)
<Keybuk> I thought you were in another function (the one that calls process_archive)
<wasabi> Keybuk, if the field isn't found in the control file, w/f_whatever are not called, right?
<Keybuk> right
<ironwolf> daniels?
<daniels> sup
<ironwolf> daniels: when changing s3 to vesa and removing BUSID line, system boots to 640x480 unchangeable resolution. at ~256 color
<ironwolf> it's ugly.. what next?
<daniels> ugh
<daniels> have you got a HorizSync and VertRefresh set of lines in there?  if so, delete them and try that
<ironwolf> nope, lines aren't there.
<ironwolf> did you ever get lspci -vvv output?
<daniels> can't remember, sorry
<daniels> just plain lspci should be sufficient (you can paste it here if you like -- just the display line)
<sivang> daniels : btw, are we anyway close with Xorg to be able to exploit capable displays for 100hz Vert refreshes?
<daniels> sivang: um should work anyway if you just remove the HS/VR lines
<daniels> and that's going away soon anyway
<daniels> anyway, I have to go crash now
<sivang> daniels : I remember fabbione told me that I Need to add a specific rate line..
<sivang> daniels : ok I will give it a try :)
<sivang> night!
<daniels> night
<ironwolf> daniels: 0000:01:01.0 VGA compatible controller: S3 Inc. Trio 64 3D (rev 01)
<ironwolf> night daniels.
<mxpxpod> daniels: when did you say that fix for the UTF-8 stuff was going in?
<spotter> Is there a difference b/w a release w/ a -(num)ubuntu(num) version over a plain -(num) version
<fabbione> morning guys
<shaya> fabbione: maybe you can answer this Q for me
<shaya> <spotter> Is there a difference b/w a release w/ a -(num)ubuntu(num) version over a plain -(num) version
<fabbione> shaya: i don't grok the question...
<fabbione> is that for a package?
<fabbione> or for the distro?
<shaya> fabbione: package
<shaya> for example, I'll upgade from a -2ubunutu1 versione package to a -3 version
<shaya> then to a -3ubuntu1
<fabbione> shaya: the one with *ubuntu* are packages that contains modification
<fabbione> done by us
<fabbione> the others are plain imported from Debian
<shaya> so in the above example, first they imported from Debian, then they redid the modifications?
<fabbione> yes
<shaya> is that a "safe" upgrade?
<fabbione> shaya: it should
<shaya> i guess its only an issue w/ hoary
<shaya> [UPGRADE]  zip 2.30-6ubuntu1 -> 2.30-8
<shaya> for instance
<fabbione> if you are running hoary it might be not
<fabbione> hoary is unstable
<fabbione> and can break
<shaya> yes yes
<shaya> I ran unstable for 4 years on my work laptop
<shaya> just need to get used to how hoary works
<shaya> hence the Qs
<fabbione> it's the same concept
<shaya> personally, I think hoary would be a great name for unstable (though I guess warty would be too)
<wasabi> I'm pretty happy not having a real unstable.
<mojo> ehem
<mojo> can someone tell me how to enable the MPEG4 codec of RealPlayer 10 without recompiling?
<fabbione> mojo: -> #ubuntu
<fabbione> this is offtopic here
<fabbione> dpkg: dependency problems prevent configuration of locales:
<fabbione>  locales depends on glibc-2.3.2.ds1-13ubuntu2; however:
<fabbione>   Package glibc-2.3.2.ds1-13ubuntu2 is not installed.
<fabbione> since when glibc-2.3.2.ds1 is a package on its own?
<daniels> it's not
<daniels> but ... huh
<daniels> that first - needs to be a =
<fabbione> ahh
<fabbione> never mind
<fabbione> i figured
<fabbione> it was a leftover of a symlink in my archive
<sivang> Morning all
<fabbione> daniels: http://people.ubuntulinux.org/~fabbione/xresprobe.diff
<fabbione> daniels: do you have any objection to this change?
<fabbione> tested and it works
<daniels> fabbione: please do the same for ia64
<fabbione> daniels: was it tested on ia64?
<fabbione> ifeq ($(ARCH),sparc)
<fabbione> DDC_OBJS += stub.o
<fabbione> endif
<fabbione> ifeq ($(ARCH),ia64)
<fabbione> DDC_OBJS += stub.o
<fabbione> endif
<fabbione> ok?
<daniels> looks good to me
<sivang> daniels : btw, my cousin using your thinkpad-x40-package , got really AMAZED by it, I almost lost him to FC3, but then he broke up and cried for not having his WiFi support and came back :) hehe
<fabbione> i can't test ia64 yet
<fabbione> sparc works
(Mithrandir/#ubuntu-devel) fabbione: that "yet" sounds dangerous.. getting one? :)
<daniels> sivang: heh!
<fabbione> Mithrandir: no way i am gonna buy ia64 :-)
(Mithrandir/#ubuntu-devel) fabbione: I was more thinking of sabdfl throwing one in your direction to get xorg rocking on one.
<fabbione> Mithrandir: i think daniels will get access to the porting box
<fabbione> + we already have the MANIFEST files
<fabbione> and xorg builds fine there
<fabbione> xresprobe is up
<fabbione> i hate when katie is soooo silent
<sivang> fabbione : who is katie?
<infinity> katie's elmo's girlfriend.
<fabbione> sivang: katie is one of elmo's gf
<sivang> fabbione : one? how many does he have? :)
<fabbione> several..
<infinity> A dozen or so.
<infinity> At least.
<fabbione> i think she is not around at all
<daniels> infinity: at least two or three dozen
<fabbione> daniels: could you see the message going trouh?
<fabbione> trough?
<daniels> not yet, but I haven't been able to convince @c.c to love me yet
<infinity> http://cvs.debian.org/dak/docs/README.names?rev=1.26&cvsroot=dak
<infinity> Has he added more ladies for Ubuntu's use?
<fabbione> infinity: i think so :-)
<sivang> daniels : funny, he has all this hardware support, and complains about not having gaim 1.0.3 in warty, How rude! :)
<daniels> heh
<fabbione> i don't think they are running at all
<fabbione> elmo: one of your gf is ill
<fabbione> elmo: time to call the doctor
<Mitario> hello everyone
<Matt|> hi all. Sorry to butt in but I have a hoary question, and it's not gonna be answered in #ubuntu. I have a laptop. Since updating hoary yesterday I have lost the ability to plug in a mouse with xorg, and I can only use my touchpad. Anyone know the solution? haven't changed the configuration since updating.
<RubenV> since the convert thing basically just copies the XF86 config, it should work
<RubenV> i'm not an X whiz though
<Matt|> no this was not the convert
<Matt|> it was an xorg update
<Matt|> was working fine with the last xorg packages before i updated
<Matt|> RubenV, thanks for replying btw
<RubenV> look in the changelogs of something concerning your mouse changed
<RubenV> maybe that'll give a hint
<Matt|> i'll try :/
<RubenV> Matt|: gotta do something to contribute
<Matt|> me?
<RubenV> giving some irc help is the best i can do at the moment for the open source community
<Matt|> oh i c
<Matt|> :)
<RubenV> magnificent C skills coming up though ;)
<Matt|> *grins*
<Matt|> i have no such skills
<Matt|> i am soon to be a lawyer ;p
<RubenV> nice
<Matt|> i was thinking that it would be amazing to work as a lawyer for an open source company
<RubenV> defend the gpl
<Matt|> yeah
<Matt|> any idea where I would find the changelogs?
<RubenV> synaptic has a way to do so
<RubenV> it's in the menu somewhere
<Matt|> oh ok
<Matt|> RubenV, nope can't see anything
<Matt|> there is a mouse thing, but a different protocol
<RubenV> hmmm
<RubenV> your X config is still intact?
<RubenV> it's a laptop so i guess it's an usb mouse, does it get detected when you plug it in?
<Matt|> no it is ps2
<Matt|> xconfig seems ok
<Matt|> when i plug it in, the light on the touchpad goes out, as it usually does when I plug a mouse in, but then it comes back on again.
<Matt|> i've tried with 2 mice
<Matt|> i guess i need to try a live disk to make sure it isn't a hardware error :(
<RubenV> normally, afaik PS2 is not plug'nplay
<RubenV> but i could be wrong
<RubenV> hardware ain't really my thing
<Matt|> RubenV, mine has always worked fine like that. but I've rebooted too and it still doesn't work
<Matt|> Be RiGhT bAcK i'll try and boot knoppix or something
<Matt|> RubenV, it doesn't work in knoppix either. Guess there must be something wrong with the mouse port :((((
<RubenV> Matt|: can't judge about that, i'm no hardware specialist
(Mithrandir/#ubuntu-devel) you can't hotplug ps2 mice, no.  ps2 keyboards you usually can, but some people claim to have fried their hardware doing that.
<Matt|> hi Mithrandir 
(Mithrandir/#ubuntu-devel) hi Matt| 
<eruin> hehe, latest synaptic wants to run as root ;)
<Matt|> that is normal no?
<eruin> ie it asks for the root password, not the users password
<Matt|> fine here
<eruin> the password dialog says "Please enter root's password"
<Matt|> if you're running it from the menu it should be gksudo /usr/bin/synaptic
<eruin> oh yeah, forgot to check that. the menu item got moved from the computer menu to the applications menu (system) and now spells gksu instead of gksudo
<Matt|> eruin, you must have moved it ;)
<Matt|> it's still in Computer here
<eruin> nope, I just did a dist-upgrade thru synaptic and it moved all by itself
<Matt|> dunno why that could be
<eruin> what version you got installer?
<eruin> *d
<Matt|> hang on
<Matt|> 0.55+cvs20041116-1
<eruin> <- 0.55+cvs20041119-1
<eruin> yeah.
<Matt|> oh
<Matt|> lemme see
<Matt|> i guess they just take the packages from debian or something and forgot to change it
<eruin> yeah, probably
<Matt|> are you putting in a bug?
<eruin> yeah, I thought I'd ask here first though... since it seems like just a slight goofup
<Matt|> mm
<RubenV> mjg59: u there?
<seb128> elmo: libgnomeprintui sync please
<IRCMonkey_> hi
<IRCMonkey_> is there a rescue mode on the CD ?
<IRCMonkey_> Why not ?
<IRCMonkey_> I have installed ubuntu on a slave disk without lilo and grub
<IRCMonkey_> I success to boot with a debian rescue disk
<IRCMonkey_> is it possible to add a mode rescue on the CD ?
<seb128> elmo: sync for "libgnomeprintui gtksourceview glade-2 gail gtkhtml3.2" please :)
* lamont arrives home, wanders off to spend time with the family
(elmo/#ubuntu-devel) seb128: done
<seb128> thanks
(bob2/#ubuntu-devel) mjg59: not putting up source packages for your uberkernels make bayb jeebus cry
<Matt|> hey daniels you do get around huh ;p
<daniels_> bob2: why don't you just install the binary packages?
<bob2_> daniels_: foad, i386-boy
<Matt|> hey daniels you do get around huh ;p
<Matt|> come to visit our fine country?
<daniels_> Matt|: yeah, been here for a week
<Matt|> ah k
<Matt|> how do ya like it?
<Matt|> bob2, you too huh?
<daniels> yeah, not too bad
<Matt|> *laughs*
<Matt|> convincing ;)
(bob2/#ubuntu-devel) heh
(bob2/#ubuntu-devel) I'm amazed the eye doesn't fall over
<Matt|> LOL
<daniels> Matt|: tired
<Matt|> bob2, the sign of a true geek :)
<Matt|> bob2, you've already calculated the engineering of the eye
<Matt|> anyway have a nice time
<sivang> do we have any known issues with usb cdroms, something about having /dev/sr0 instead of /dev/scd0 ?
(bob2/#ubuntu-devel) hah, the fact it stands shows I don't know jack about engineering
<Matt|> go and see the lloyds building it's cool
<Matt|> if you want a tourist tip
(bob2/#ubuntu-devel) where's that?
<Matt|> hang on
<Matt|> http://www.greatbuildings.com/buildings/Lloyds_Building.html
<Matt|> it's like someone turned it inside out
<Matt|> http://www.mykreeve.net/london/the_city/lloyds_building/
<Matt|> (if you have time for touristing) :)
(bob2/#ubuntu-devel) hah, not much, sadly
<Matt|> :(
<Matt|> watcha doing here?
(bob2/#ubuntu-devel) some team stuff before the spain meeting
<Matt|> bonding huh
<Matt|> :)
(bob2/#ubuntu-devel) hah, and drinking
<Matt|> well england is good for that :(
<Matt|> have fun guys
<spotter> anyone upgrade pmount today and screwed up their dvd mounting?
(mjg59/#ubuntu-devel) bob2: Heh. Good point.
<lupus_> still no package for transset available?
<Kyaneos> hi
<zul> cool...i created my first deb
(tseng/#ubuntu-devel) that reminds me
(tseng/#ubuntu-devel) if i would like to see X package added to ubuntu
(tseng/#ubuntu-devel) do i need to have it sponsored in debian?
<Keybuk> tseng: that's one way, certainly
<Keybuk> we're still working out how direct-to-universe will work
(tseng/#ubuntu-devel) hm-k
* tseng hits the new-maint guide again
<Keybuk> certainly you should follow debian-policy and the maint-guide *anyway*
(tseng/#ubuntu-devel) yes :)
<Keybuk> the only difference between a correct Ubuntu package, and a correct Debian package is where you send it
(tseng/#ubuntu-devel) was looking for the proceedure to getting a package sponsored
<Keybuk> find a sponsor
(tseng/#ubuntu-devel) my packages are correct
<Keybuk> I think there's a website for that these days
(tseng/#ubuntu-devel) im looking @ mentors.d.o
(tseng/#ubuntu-devel) oh, jdub added tomboy already
(tseng/#ubuntu-devel) jdub: ping
(bob2/#ubuntu-devel) mjg59: http://gate.crashing.org/~benh/albook-ibookg4-sleep-3.diff, if you want to pimp up the source package with ppc-sleep love
<Keybuk> bob2: good flight?
(bob2/#ubuntu-devel) loooong
(bob2/#ubuntu-devel) when are you coming down?
<Keybuk> tomorrow morning
(bob2/#ubuntu-devel) ah
<Keybuk> should be at Mark's for 9ish or so
(bob2/#ubuntu-devel) ah, have to get up early then ;-)
<Keybuk> yeah, leave here about 6
(elmo/#ubuntu-devel) anyone got an upload to do by any chance?
#ubuntu-devel 2004-12-03
(mjg59/#ubuntu-devel) bob2: Rock
<btfan> hi
<btfan> is it possible that windows network printing colud be improved?
<btfan> basically, is it possible for ubuntu to scan the subnet, find the smb hosts and search for printers and put them in the 'detected' printers dialog?
<eruin> for future reference
<eruin> https://bugzilla.ubuntu.com/show_bug.cgi?id=3979
<eruin> have I got priority, severity, etc right on that one?
<hornbeck> did evolution break for anyone else today?
<eruin> haven't seen any evolution updates in a couple of days
<robertj> mine just started working
<eruin> mine has the occasional crash when frantically selecting text in mails
<robertj> still crashing
<robertj> but its more working than before
<robertj> when I just got a toolbar with a send/receive ubtton ;)
<eruin> :)
<calc> jdub: heh
<wasabi> kalc.
<wasabi> kalk i mean
<eruin> a bit shy, calc?
<calc> eruin: jdub seems to be swamped by users telling him what he better do ;)
<eruin> yeah, I've been following it ;)
* calc runs gnome ~2.8 now ;)
<eruin> ~
<wasabi> yeah so i have no idea what to do with pam_krb5
<wasabi> since im not installing fedora to find out what they use
<eruin> can't wait for gimp2.2
<jdub> wasabi: check their src.rpms
<wasabi> incoming u-d post.
* robertj ducks
<calc> wonder what kind of hell its going to be once the menus merge and all three are changed (debian/gnome/kde) to a unified one ;)
<calc> people are already whining that one simple package moved in a menu
<wasabi> I could care less about KDE's menu at this point.
<wasabi> =)
<robertj> calc: break them from the habit. Move them randomly
<calc> wasabi: once gnome 2.9/2.10 is out the gnome/kde menu is one and the same
<wasabi> I like the Computer menu concept extremely well.
<calc> its the fdo menu
<Keybuk> calc: this is where it's great to have your own distro and be allowed to exercise sanity ;)
<wasabi> THe clear seperate between applications and system configuration
<robertj> wasabi: I like it but I'm not a fan of having places on the computer menu
<wasabi> I just want to be able to launch apps from it easily, without having to make panel launchers like I do.
<Keybuk> robertj: the "plan" is to have a Places menu in hoary, which is shared with the Gtk file manager and nautilus
<wasabi> I dislike having tons of panel launchers
<wasabi> hard to organize and maintain
<drbyte> asterisk is in universe, i presume ?
<calc> Keybuk: heh
<robertj> Keybuk: What is Gtk file manager?
(tseng/#ubuntu-devel) drbyte: yes
<jdub> robertj: the filechooser
<robertj> oh, ok
<Keybuk> uh, GtkFileChooser
<Keybuk> brain isn't quite in gear
<robertj> just checking
* calc wonders why so many people hate dselect, its great :)
<eruin> it's cli!
<eruin> eek
<wasabi> so when's ubuntu going to package 2.6.9?
<eruin> I didn't part with lots of cash for my mouse just to use a cli
<Keybuk> wasabi: of?
<Keybuk> kernel?
<wasabi> yeah.
<drbyte> tseng: thanks. we're gonna try build a voip system now
<jdub> i haven't opened my ubuntu-users folder for days :|
<eruin> wasabi, hopefully along with nvidia 6629
(tseng/#ubuntu-devel) hey jdub, tiny mistake in tomboy control
(tseng/#ubuntu-devel) im missing a closing parens on depends, it got uploaded to hoary like that
<jdub> d'oh
<wasabi> ain't lintian suppose to catch that stuff? *hides*
(tseng/#ubuntu-devel) jdub: i fixed it and then updated to 0.2.2, i can send source somewhere or file a bug, whatever is most convenient for you
<robertj> also, does anyone ever wonder if the Computer menu should have an icon similar to the Applications menu?
<wasabi> I like apple's way of doing it actually.
<robertj> or is that just my hangup ;)
<wasabi> The icon is the menu.
<wasabi> ANd it's the System Menu.
<wasabi> With all the Important System Stuff.
<jdub> robertj: it'd be kinda confusing (the applications menu icon is a bit confusing in itself)
<jdub> tseng: send me a url :)
<robertj> jdub: yeah, it's a catch 22. Because if you do then you say "well then, why is the application icon a foot"
(tseng/#ubuntu-devel) the icon on the app menu is just a throwback to the old foot
<robertj> it seems empty without the foot though
<wasabi> I'd do what apple does
<wasabi> First menu, ubuntu icon. System config stuff. Stuff that's in COmputer now.
<wasabi> (some stuff from computer)
<wasabi> like log out, etc.
<robertj> Users have a real tough time finding log out under the apple menu
<wasabi> It says to the user "this is the menu that lets you edit Ubuntu the system"
<wasabi> Well, then name it System or something too
<Keybuk> the annoying thing about that is it breaks Fitt's Law
<robertj> to me it says "This is a foot. We put everything that is hard to categorize in here."
<wasabi> I am not aware of Fitts law
<eruin> apple's apple isn't something I love
<robertj> wasabi: it's the only rule anyone knows about UI design
<Keybuk> wasabi: "The most used things should be the easiest things to click."  basically
<jdub> Keybuk: pfft.
<robertj> although one fact that the UI needs to face is that people don't often launch applications
<wasabi> Sucky rule.
<Keybuk> it's very easy to throw your mouse into the top-left of the screen and click what ever's there
<robertj> it comproises maybe 1/10,000th of the average computer usage
<wasabi> The most used things should be arranged where they are expected.
<wasabi> So somebody can find them
<wasabi> Not just On The Top
<Keybuk> robertj: sure, but they launch more applications than they take screenshots
<Keybuk> unless they're jdub, of course :p
<robertj> Keybuk: yeah, agreed on that one
<Keybuk> who I think has tipped the balance the other way
<robertj> having the Places menu in the Upper Left would seem better
<robertj> your more often going somewhere than opening an appliation
<wasabi> I like hte idea of classify items as "things you do to the computer", "things you do within your desktop environment".
<wasabi> but that's JUST ME
<Keybuk> robertj: hmm, I can't comment -- I have a sneaky suspicion you're right
<wasabi> I like the idea of a Places menu.
<jdub> robertj: there's a thread on d-d-l about possible menu changes upstream
<jdub> which includes:
<jdub> Applications  Places  System
<jdub> and
<jdub> [foot]   Applications  Places
<wasabi> System Applications Places
<wasabi> Where System can be a icon. ;)
<eruin> Places Applications System'd seem better
<jdub> that's what [foot]  i
<jdub> s
(tseng/#ubuntu-devel) jdub: try http://www.smarterits.com/~brandon/ubuntu/
<robertj> The big thing is users expect their programs to be in the corner from the Start Menu or Apple Menu
<wasabi> I'd think labeling it Applications eleviates that.
<robertj> so that inch difference makes a ..err difference
<robertj> I still feel like it skirts the real problem of not having good scratch space
<jdub> tseng: building now
<robertj> that might could be fixed by gnome-panel enhancements
<wasabi> okay, if you guys use make-kpkg.... what builds linux-restricted?
<jdub> tseng: successful build, successful install...
(tseng/#ubuntu-devel) :)
<jdub> successful microtesting ;)
(tseng/#ubuntu-devel) it even takes notes with style
<robertj> I mean sure, we tell ourselves that we work methodically, every file is needed to be able to reproduce our work. In actuality we download stuff, delete 90% of it a minute later, paste things into a wordprocessor because we want our sticky notes spell-checked and uber-formatted, etc
<robertj> am I boring yall ;)
(tseng/#ubuntu-devel) robertj: its ironic you say these things
<jdub> tseng: has anyone sponsored you to get it into debian?
<robertj> tseng: why?
(tseng/#ubuntu-devel) jdub: no, i was just looking at mentors.d,o today
<jdub> STICKY WIKI
(tseng/#ubuntu-devel) robertj: because we are working on uploading a tomboy fix
(tseng/#ubuntu-devel) with.. spellchecking!
(tseng/#ubuntu-devel) the mythical scratchpad you long for
<robertj> It's just hte principle of the thing though
<robertj> like you have a document that you say "I want to use this for a while until I file it or delete it"
(tseng/#ubuntu-devel) http://beatniksoftware.com/tomboy/
<robertj> sometimes its a spreadsheet, or a csv, or some code, or whatever
(tseng/#ubuntu-devel) and:
<jdub> tseng: want me to upload?
(tseng/#ubuntu-devel) http://www.gnome.org/projects/beagle/
(tseng/#ubuntu-devel) jdub: that would be rad
<robertj> the problem with beagle is it's not got that spatial feel
<eruin> funny I thought I saw tomboy in synaptic the other day
(tseng/#ubuntu-devel) robertj: the current beagle ui is a poc really
(tseng/#ubuntu-devel) eruin: its in ubuntu
(tseng/#ubuntu-devel) thanks to mr. dub
<robertj> tseng: it's not just that though
<jdub> robertj: search folders in nautilus -> spatial.
<robertj> jdub: the closest I've gotten is binding a special key to show/hide desktop
<jdub> robertj: you can't apply spatiality to everything.
<robertj> if there was a way to make it show on press down and hide on release that would be closer
<jdub> and it doesn't make sense to do so
<robertj> then you could drag something off the desktop into yoru document
<robertj> I'm not a real spatial fan
<eruin> tseng, I can't find it anywhere ;o
<robertj> but this seems like one of the really good uses
(tseng/#ubuntu-devel) eruin: its in hoary
<eruin> <- hoary ;)
(tseng/#ubuntu-devel) well, the source is at least
<eruin> ah
<robertj> it's just lots of little things that kind of make it a pain
<robertj> like you can't show/hide desktop while dragging
(tseng/#ubuntu-devel) remind me why id want to do that?
<robertj> tseng: you have 3 jpegs on your desktop you want to attach to an evolution document
<robertj> err "Email message"
(tseng/#ubuntu-devel) ok?
<robertj> so you press the show desktop key, select them, start the drag, press the key again to put windows back in their position, and drop the documents on the message to attach
<wasabi> you want to be able to alt-tab while dragging, or drag to an app on the panel widow list
(tseng/#ubuntu-devel) or id move evo to its own desktop
<wasabi> or point to a window for 2 seconds and have it move above
(tseng/#ubuntu-devel) which wasnt full of other crap
<robertj> I don't have another desktop, I'm happy with one
(tseng/#ubuntu-devel) maybe if you are really impassioned about this you could write up how youd prefer it to work and make an open proposal to the gnome mailing list
(tseng/#ubuntu-devel) w/o using phrases like "its a pain" and other things with negative conotation
<robertj> yeah
(tseng/#ubuntu-devel) "it would be great if we had this" vs "it sucks that you cant do this"
(tseng/#ubuntu-devel) you get a better response.
<jdub> tseng: :-)
<robertj> also, does anyone know if dragging to the panel for launcher creation is on the list for 2.10?
<robertj> it works if your dragging an executable app, but it assumes any file is an executable instead of rooting for the handler
(tseng/#ubuntu-devel) so, you want to add .mp3s to your panel?
(tseng/#ubuntu-devel) or how do you mean
<robertj> well yeah
(tseng/#ubuntu-devel) i can drag .desktop files to it all day long
<robertj> or more practically my 5 spreadsheets that I use all the time
(tseng/#ubuntu-devel) isnt that why we have recent files?
<jdub> ah, smeg.
<jdub> tseng: will have to upload again -> s/unstable/hoary/ :-)
(tseng/#ubuntu-devel) Computer - Recent Messages
<robertj> tseng: but I just want those spreadsheets, not all the other stuff
(tseng/#ubuntu-devel) recent documents rather
(tseng/#ubuntu-devel) you want a lot of things :)
(tseng/#ubuntu-devel) you can also easily make a folder with your spreadsheets, and add it to you favorites in gtkfilechooser
<robertj> is there a GtkFileChooser applet?
<jdub> filechooser bookmarks will be in the places menu
<robertj> that will help
(tseng/#ubuntu-devel) :)
<robertj> being able to drag to and from that menu would be very intuitive though
<robertj> although it's not really what menus are used for
(tseng/#ubuntu-devel) to me its counterintuitive
<jdub> elmo: ping
(tseng/#ubuntu-devel) the panel is for launching applications
(tseng/#ubuntu-devel) not for launching files
<robertj> tseng: that's not true
<jdub> robertj: probably best to take this discussion to gnome's usability list.
(tseng/#ubuntu-devel) launching an applications w/ a file uses the drag n drop paradigm
<robertj> there are a bajillion things that can and do live on various people's panel
(tseng/#ubuntu-devel) well thats true
<robertj> yeah, it probably needs to get moved
(tseng/#ubuntu-devel) but not "intuitive"
<robertj> wanna go to #gnome-usability?
(tseng/#ubuntu-devel) why not.
<robertj> (come one come all)
<jdub> tseng: tomboy's on its way.
(tseng/#ubuntu-devel) yay
<Keybuk> \o/
<sivang> hey keybuk what's the ascii art about ?
<Keybuk> it's a yay for tomboy
<sivang> Keybuk : got accepted into universe, right?
(tseng/#ubuntu-devel) indeed.
(tseng/#ubuntu-devel) see hoary-changes
<sivang> tseng : was this your debian package? :)
(tseng/#ubuntu-devel) ya
<sivang> tseng : (i've been using it since I found out your repo)
(tseng/#ubuntu-devel) ya its nice
(tseng/#ubuntu-devel) i found a few other things id like to do
<sivang> tseng : It's very cool :), did it pass the regular, sid ---> hoary universe cycle?
(tseng/#ubuntu-devel) no :P
<sivang> tseng : cooler, uploaded straight into universe?
(tseng/#ubuntu-devel) ya
<fabbione> morning guys
<fabbione> lamont: ping?
<fabbione> what is wrong with jackass?
<fabbione> jdub: do you happen to know where the UploadQueue is gone?
<drbyte> no asterix in universe!
<eruin> can anyone point me to a package building guide?
<jdub> eruin: debian new maintainer's guide
<jdub> fabbione: the directory?
<eruin> cheers
* jdub uploads nautilus with a bunch of old mush removed
<fabbione> yeah
<fabbione> it's not there anymore
<jdub> just worked for me
<fabbione> bah it works without
<fabbione> probably elmo chrooted even more
<fabbione> and the Contents files aren't updated properly :(
<Keybuk> right, time to go play with the arch people
* Keybuk heads for London
<fabbione> this is so cooool!
<fabbione> i have a couple of fox'es in my garden
<Lathiat> a fox or stray dog came and killed all 10 of my chickens last week :(
<Lathiat> dug under the fence into the pen
<fabbione> i don't have chickens in my garden
<fabbione> but they keeps rats and stuff like that away
<Lathiat> ah
<pitti> Morning
<fabbione> hey pitti
<pitti> fabbione: Hi! I saw my small niece yesterday (3 days old now). Babies are sooo sweet :)
(sjoerd/#ubuntu-devel) pitti: if you start saying that, your getting old :)
(sjoerd/#ubuntu-devel) morning
<pitti> sjoerd: Morning. Really? Damn...
<fabbione> pitti: oh yeah :-)
<fabbione> sjoerd: ehehhehe
(sjoerd/#ubuntu-devel) gotta go
(sjoerd/#ubuntu-devel) later
<fabbione> holy.. it's snowing like hell today
<fabbione> and i need to go and renew my passport
<doko> morning all!
<fabbione> hey doko
<pitti> Hi doko, mvo_!
<jdub> lifeless: around?
(bob2/#ubuntu-devel) jdub: he's with mark and martin
<jdub> thanks
<jdub> (doesn't matter now)
<fabbione> bob2: can you ask Mark to show up on irc when he has 2 minutes of time?
(bob2/#ubuntu-devel) fabbione: will do
<fabbione> thanks
<lifeless> jdub: yo
<jdub> 'sok
<jdub> just had to get the keyring
<jdub> but
<jdub> out of interest
<jdub> when baz fails due to lack of gpg love
<jdub> how can you tell which key it doesn't have? :)
<sid77> hi
<fabbione> jdub: ximian-connector needs some love
<fabbione> E: Package evolution has no installation candidate
<fabbione> does evo* provides evolution somehow?
<fabbione> ops
<fabbione> never mind
* fabbione goes and sit in a corner
<jdub> :-)
<lifeless> jdub: yah
* fabbione fixes another FTBFS
<fabbione> daniels: hey kid
<Lathiat> hehe
(bob2/#ubuntu-devel) he's not a kid
(bob2/#ubuntu-devel) he beat up a family of clowns this morning
<daniels> fabbione: sup
<fabbione> daniels: getting ready to upload xfree86 ubuntu26
<daniels> fabbione: changes?
<fabbione> i was waiting for you to review the changes
<daniels> fabbione: just the restructure of the packaging?
<daniels> 'k
<fabbione> daniels: just a sec
<daniels> sure
<fabbione> xfree86 (4.3.0.dfsg.1-6ubuntu26) hoary; urgency=low
<fabbione>   Changes by Fabio M. Di Nitto:
<fabbione>   * Sync debian/rules install-server target with install and make
<fabbione>     binary-server work again.
<fabbione>   * Start shipping only xserver-xfree86 and xserver-xfree86-dbg as a temporary
<fabbione>     stage, while waiting for full removal.
<fabbione>     This will give the opportunity for users to be able to revert to an "old"
<fabbione>     and well known server if the xserver-xorg package does not work for them.
<fabbione> + the security stuff
<fabbione> it basically builds only xserver-xfree86{,-dbg}
<daniels> ok
<fabbione> goody
<fabbione> i am gonna do a test
<fabbione> and upload
<fabbione> this will also solve the problem of having warty > hoary
<fabbione> pitti: what about uploading libc6 to hoary?
<fabbione> pitti: with the security fix and a -3 version?
<fabbione> ;)
<pitti> fabbione: ?
<fabbione> it gave a big headacke
<pitti> fabbione: I thought I uploaded the fix there long ago
<pitti> fabbione: or did Debian eventually fix it too?
<pitti> fabbione: then it could be synced
<fabbione> pitti: warty has -2.2
<fabbione> hoary 2
<daniels> fabbione: how will it solve the warty->hoary problem???
<fabbione> daniels: hoary has 2 problems atm
<fabbione> daniels: one is the version
<fabbione> the other one is the cache for the Contents file
<daniels> the ubuntu-desktop problem is the biggest, and that's solveable by an xserver-xfree86 metapackage that deps on -xorg
<fabbione> the latter is more important
<daniels> what?
<fabbione> daniels: check XKBstr.h
<fabbione> using Contents-i386.gz
<daniels> it's listed as being in xlibs-static-dev?
<fabbione> the file is still registered as part of xlibs-static-dev
<fabbione> because the package is probably still cached from xfree86
<daniels> yeah, which is solveable by killing that from xfree86
<fabbione> this upload should "kill" the cache
<mvo_> Kamion: synaptic as it needs some ubuntu-patches before it can be synced
<fabbione> daniels: exactly
<pitti> fabbione: the Debian version also fixes a problem on amd64, so I would rather base hoary on this
<fabbione> pitti: make sense
<pitti> fabbione: I don't understand this, a new glibc was uploaded on Oct 5 without fixing the security problem
<seb128> morning
<pitti> fabbione: I sent the patch to the bug, it would have been trivial...
<pitti> Hi seb128 
<seb128> hey pitti 
<pitti> fabbione: I will sync manually
<fabbione> pitti: nothing important.. it was just to allign stuff around
<fabbione> hey seb128 
<fabbione> seb128: i did a bunch of uploads of gnome stuff this morning
<seb128> hi fabbione 
<fabbione> seb128: to fix FTBFS
<pitti> fabbione: however, it is on my todo list for some weeks now, so I won't forget about it :)
<seb128> fabbione: yeah, I've seen that, thanks
<fabbione> pitti: cool!
<fabbione> seb128: thanks the sparcbuildd that is catching them
<fabbione> i am sure there are more
<fabbione> but we will see them in the next phase
<seb128> probably yes
<fabbione> well i will rather fix them or bug you :P
(Kamion/#ubuntu-devel) mvo_: you can stop things from being synced by uploading an Ubuntu version
<mvo_> Kamion: ah, I think that was the problem. thanks for pointing this out
<daniels> fabbione: you are on crack
<daniels> -xfree86 (4.3.0.dfsg.1-6ubuntu26) warty-security; urgency=low
<daniels> +xfree86 (4.3.0.dfsg.1-6ubuntu26) hoary; urgency=low
<daniels> w-s got 25.1, not 26
(Kamion/#ubuntu-devel) mvo_: you can either (a) upload something now to keep it out, (b) upload the merged version before the Debian version makes it out of incoming, (c) don't worry about it and upload the merge afterwards, since hoary users should be able to cope, (d) ask elmo if there are more available options
<fabbione> daniels: you are on crack
<fabbione> daniels: read carefully
(Kamion/#ubuntu-devel) fabbione: cache> Contents-* only gets updated once a week or so, I believe
<fabbione> daniels: warty has 25.1
<daniels> ...
<fabbione> daniels: hoary will have 26
<daniels> yes, warty-security specifically
<daniels> yes
<daniels> note the -
<fabbione> so what?
<daniels> -6ubuntu26) warty-security
<daniels> where did you get that from?
<fabbione> from the previous svn commit
<fabbione> i just forgot to change the target
<fabbione> it was never uploaded
<daniels> heh
<fabbione> Kamion: afaik Contents is updated each time apt-ftparchive run
<fabbione> Kamion: at least it does it here
<fabbione> and in any case
<fabbione> xorg has been uploaded a while go
<fabbione> s/go/ago
(Kamion/#ubuntu-devel) fabbione: no, search for Contents in the apt-ftparchive man page
(Kamion/#ubuntu-devel) you're right that it seems to be older than I'd expect for some reason, though
(Kamion/#ubuntu-devel) but I think you're describing the problem wrongly :)
<fabbione> Kamion: ok.. there are flags to tune it
<daniels> iirc the dak 'daily' pulse regenerates contents
<fabbione> i didn't know about it
<fabbione> Kamion: but the point is that files are listed in the wrong package after a looong while :-)
<daniels> (of course, our 'days' are half an hour ... everything moves faster in ubuntu)
<fabbione> Kamion: and of course i agree with you.. a few hours back i had to formulate my theory :-)
(Kamion/#ubuntu-devel) (ContentsAge is 10 days by default)
<fabbione> Kamion: not here..
<fabbione> and i did never change the default
(Kamion/#ubuntu-devel) if it's cheap for apt-ftparchive to regenerate the files it will do so, I believe
<fabbione> apt-ftparchives keeps updating them each time
<fabbione> possibly
(Kamion/#ubuntu-devel) it basically tries not to do too much work
<fabbione> here i only have main
<mvo_> Kamion: the last comment on #2651 looks like it might be debian-installer releated?
<fabbione> Kamion: but even if i take the oldest xorg that hitted the archive.. it's like 14 days old
<fabbione> so i guess elmo has done some black magic
<fabbione> ;)
(Kamion/#ubuntu-devel) mvo_: yeah, languagechooser is responsible for that $LANGUAGE setting
(Kamion/#ubuntu-devel) mvo_: seems like intentional behaviour - AFAIK those languages are close enough that showing messages in the wrong one of them is better than showing no translation at all
<mvo_> Kamion: so I will explain that and tag "notabug"
(Kamion/#ubuntu-devel) mvo_: I'm guessing it's falling back on a message-by-message basis when it can't find translations; complete the translations and it should go away
<mvo_> right, I think I found a new .no translator, let's see how fast he is :)
<daniels> bob2: i've already fixed your xkb problem, without even needing to debug it on your laptop.  how cool am I?
<Lathiat> heh
<daniels> fabbione: it's USN time again
<fabbione> daniels: i hate you
<daniels> i hate me too
<fabbione> seb128: libpanel-applet2-dev -> libgnome-desktop-dev transition.. shouldn't the latter provide the former?
<fabbione> or do you plan to change build-deps on all of them?
<seb128> which transition ?
<seb128> there is a transition ? upstream ?
<fabbione> watch this:
<fabbione> Building Dependency Tree...
<fabbione> Package libpanel-applet2-dev is not available, but is referred to by another package.
<fabbione> This may mean that the package is missing, has been obsoleted, or
<fabbione> is only available from another source
<fabbione> However the following packages replace it:
<fabbione>   libpanel-applet2-doc libgnome-desktop-dev
<infinity> Are you sure that "Replaces" isn't just a file overwrite?
<seb128> ii  libpanel-applet2-dev     2.9.1-0ubuntu2           Library for GNOME 2 Panel applets - Development files
<seb128> Package: gnome-panel
<seb128> Binary: libpanel-applet2-dev, libpanel-applet2-doc, gnome-panel-data, libpanel-applet2-0, gnome-panel, libpanel-applet2-dbg
<seb128> dunno how you get this
<fabbione> HMMMMM
<fabbione> i think wanna-build is on pure crack!
<seb128> but this part has not changed for ages
<Mitario> hi everyone
<fabbione> seb128: thanks
<seb128> np
(bob2/#ubuntu-devel) daniels: you are my hero
<daniels> bob2: i am my hero too
<daniels> bob2: want to buy me some red bull?
<daniels> bob2: edit /etc/X11/xkb/symbols/macintosh/us
<daniels> bob2: after ~line 147, where it has the include statements, add 'include "srvr_ctrl(xfree86)"' after the existing two
<daniels> bob2: then you should be able to do set xkbmap -symbols us
<daniels> er
<daniels> setxkbmap -symbols us
<daniels> and hopefully it's not cached
<gicmo_> sladen, ping?
(bob2/#ubuntu-devel) daniels: if your fridge isn't full anymore, ok
<daniels> bob2: there's still a fair bit of dr pepper and some iced tea, but i've drunk all the red bull already
<daniels> 'Ctrl-c will is appear to be Ctrl-Thaisaraae in case of th 
<daniels> keymap.'
<daniels> control-what?
(bob2/#ubuntu-devel) you know, the Thaisaraae key
<fabbione> daniels, Kamion: new d-i use of framebuffer breaks Xorg autodetection
<fabbione> daniels: the scripts enables the use of fb automatically when they find it
<fabbione> but than it fails to find the device
<fabbione> Kamion: btw.. hoary installed perfectly
<fabbione> (netinstall)
<fabbione> or netboot
<fabbione> or net<whatever_fits_better>
<daniels> fabbione: huh?
<daniels> more details dude
<fabbione> daniels: UseFBDev "true"
<fabbione> and than it cannot find the /dev/fb* associated
<fabbione> the first is generated by maint scripts
<fabbione> the second is the error in the logs
<daniels> +authenticated = authctxt->valid ? 1 : 0;
<daniels> fabbione: grunt
<daniels> fabbione: otoh, usefbdev false should be safe in *most* cases in xorg with benh's new patch
<fabbione> daniels: there is not only ppc that uses fb
<fabbione> Kamion: the framebuffer is not loaded after the second reboot
<daniels> fabbione: which other platforms do we have that require fb for detection?
<fabbione> Kamion: d-i -> reboot -> install -> reboot (no framebuffer)
<daniels> iirc the only case where we really needed fb to do the setup right was r128 panels on powerpc
<daniels> and that case should be fixed now
<fabbione> daniels: i am pretty sure sparc does
<daniels> UGH
<daniels> it was so nice, only caring about three platforms that people actually used :)
<fabbione> daniels: well.. if we can keep some level of portability 
<fabbione> if you want to kill it you can do it for platform
<fabbione> the code is relatively flexible
<fabbione> there is no need to do it for world
<fabbione> daniels: there is a simpler option
<fabbione> daniels: like making the "UseFBDev" a real option and not a fatal
(Kamion/#ubuntu-devel) fabbione: if the framebuffer must be loaded after the reboot you have to do it somewhere other than d-i
(Kamion/#ubuntu-devel) fabbione: base-config only has any effect on the first reboot, which wouldn't be good enough
<pitti> Hi lulu
<lulu> pitti: hiya :o)
(bob2/#ubuntu-devel) baaaaaaaaz.
<fabbione> Kamion: yes, i understand that. but is it FB required for base-config?
<fabbione> Kamion: otherwise i think something should take care of making the behaviour consistent across reboots
<Keybuk> seb128: is SMTP with TLS known-broken in evolution/hoary ?
<seb128> yes
<seb128> Keybuk: https://bugzilla.ubuntu.com/show_bug.cgi?id=3310
<seb128> Keybuk: all sort of problems with secure connections
<Keybuk> seb128: uh, what was that URL?  X-Chat helpfully crashed while I was un-thomming firefox so I could load it :p
(bob2/#ubuntu-devel) hurry up, mr buildd
(bob2/#ubuntu-devel) I want tomboy on ppc!
<Keybuk> heh
<Keybuk> is it not built yet?
<Keybuk> it got uploaded some 6 hours ago
(bob2/#ubuntu-devel) yeah, I know
<Keybuk> it's not built on i386 either
<Keybuk> I suspect a FTBFS
(bob2/#ubuntu-devel) fucking doorstop architectures!
<fabbione> i think there is something wrong with the buildd
<fabbione> amd64 isn't building either
<fabbione> and the logs are on the web
<fabbione> yeah.. it failed on i386 and ppc
<seb128> Keybuk: https://bugzilla.ubuntu.com/show_bug.cgi?id=3310
(bob2/#ubuntu-devel) ouch
<fabbione> configure: error: XML::Parser perl module is required for intltool
<fabbione> missing build-dep probably
<fabbione> same as update-manager
<fabbione> i think one build-dep killed a dependency
<fabbione> and this is just a chain
<cenerentola> hello ppl do you know where i can find exact dates and times of the conference
<fabbione> cenerentola: on the wiki
<cenerentola> well.. nice.. i came from there
<cenerentola> do you know the exact "page"?
<fabbione> no
(bob2/#ubuntu-devel) it has the exact dates on it
(bob2/#ubuntu-devel) that's how we all planned to be there (-ish)
<fabbione> http://www.ubuntulinux.org/wiki/Conference/
<cenerentola> no... one day i visited a page, that explained exactly at what time it started in the morning and ended in the afternoon..
<cenerentola> fabbione: im came from there
<fabbione> they might have moved stuff around
(Kamion/#ubuntu-devel) fabbione: shouldn't be, generally
<cenerentola> kamion: well.. effectiveness is: i can't find it
(Kamion/#ubuntu-devel) cenerentola: huh?
(Kamion/#ubuntu-devel) cenerentola: my comment was nothing to do with your conversation
<cenerentola> ahh... sorry
<cenerentola> i own you a beer
(bob2/#ubuntu-devel) are you sure such a page exists?
<fabbione> ok daniels...
<fabbione> Xorg is out of way
<fabbione> we are back to xfree86
<fabbione> xfree86 4.3.0.dfsg.1-6ubuntu26 
<fabbione> with the epoch bump people will see it as normal upgrade
<Mitario> back
<fabbione> new version of tomboy uploaded
<Astharot> /query pitti
<Astharot> oops
* sid77 ciao
<pitti> Astharot: this might not have been what you want :)
<Astharot> ciao sid ^^
<Astharot> pitti: yes, probably :)
<pitti> lulu: I will handle this issue with HolgerDaut@aol.com
<bitserf> hi, i'm not sure due to differing hardware configurations, but has anything changed between hal 0.4.1-1ubuntu1 and 0.4.1-1ubuntu6 that would cause CD-ROM devices to not have volume children? 
<bitserf> i have a work machine with 0.4.1-1ubuntu1 that still shows the volume children (children of the IDE drive device), and 0.4.1-1ubuntu6 at home doesn't. 
(bob2/#ubuntu-devel) bitserf: anything obvious in the changelog?
<lulu> pitti: ok - many thanks -  would you mind sending me the translation anyway please.
<pitti> lulu: uh, if you want
<pitti> lulu: he complains about the lack of accessibility in Gnopernicus on a Gnoppix Live CD
<pitti> lulu: it's just wrongly addressed to us
<lulu> pitti:...offline
<fabbione> elmo: after xfree86 in hoary (ubuntu26) will build, you can safely move it to universe
<bitserf> bob2: i'm not entirely qualified to answer that, just starting to understand how various bits of hal work. nothing immediately obvious to me though.
(bob2/#ubuntu-devel) bitserf: /usr/share/doc/hal/changelog.Debian.gz
<bitserf> bob2: read it :P
(elmo/#ubuntu-devel) fabbione: ok
<fabbione> elmo: thanks
<fabbione> elmo: btw.. this morning we were checking Contents file. how often are they updated on out archive?
<fabbione> s/out/our
(elmo/#ubuntu-devel) not very often
<fabbione> less than once every 10 days?
(elmo/#ubuntu-devel) updating the Contents file is VERY expensive so I can't posssibly update it as part of cron.daily
(elmo/#ubuntu-devel) the second problem is apt-ftparchive doesn't do any locking, so I can't cron it less often easily
<fabbione> elmo: yup.. i noticed it is expensive.. 
<fabbione> i was just wondering.. because i still see old xfree86 files in the wrong xorg packages :-)
* fabbione goes to renew the passport
(bob2/#ubuntu-devel) jdub: gnome-gpg in supported someday?
(elmo/#ubuntu-devel) where's a good place to put upload instructions on the wiki? do we have an equivalent to www.d.o/devel/ yet ?
<daniels> 'el puo doble'
(Mithrandir/#ubuntu-devel) linking to it from UbuntuProcedures would make sense?
(elmo/#ubuntu-devel) *boggle* the searching on zwiki OWNS
<daniels> elmo: what, when it's not searching plone.org?
(elmo/#ubuntu-devel) btw, next person to upload, please try it via direct FTP
<pitti> elmo: what does that mean, is there now a public FTP upload queue?
(elmo/#ubuntu-devel) yes
<daniels> elmo: ftp to chinstrap?
(elmo/#ubuntu-devel) no, jackass
(elmo/#ubuntu-devel) and don't do an upload for the sake of it - I know what your impulse control is like :P
<daniels> i have an xorg upload later today, but i'm doing dhclient in a bit
(bob2/#ubuntu-devel) hah
<daniels> elmo: ok, I just bought directftpuploadstojackass.org for two years, what now?
(bob2/#ubuntu-devel) ok, someone suspend daniels' domain-buying rights
<daniels> it was a joke
<daniels> clearly you need more caffeine
(bob2/#ubuntu-devel) I've been drinking this diet shit all day
<daniels> bob2: exactly
<daniels> ranlib: libxf86_os.a: No space left on device
<daniels> make[7] : *** [libxf86_os.a]  Error 1
<daniels> make[7] : Leaving directory `/home/daniels/canonical/xorg/arch/source/xorg-6.8.1/build-tree/xc-xserver-xorg-dbg/programs/Xserver/hw/xfree86/os-support'
<daniels> BABY JESUS!!
(bob2/#ubuntu-devel) hahaha
<sivang> this is one deep path
<smurfix> I wonder whether keeping Contents in a database and incrementally updating with new packages would make sense. Just do a daily table dump
(elmo/#ubuntu-devel) if apt-ftparchive had a --contents-only mode, that'd be a good start
(elmo/#ubuntu-devel) then, if it could update the contents file out-of-bound (i.e. not as .Contents-$arch.new but in /tmp or something), that would totally fix it, AFAIC
<Keybuk> seb128: so, uh, I can't seem to be able to send e-mail with TLS at "never"
(Kamion/#ubuntu-devel) elmo: usb-discover upload coming up shortly
(Kamion/#ubuntu-devel) ... done
<seb128> Keybuk: have you restarted evolution ?
<Keybuk> seb128: it's crashed at least once since I changed the setting, does that count? :)
<gicmo> hehe
<gicmo> evolution mail sending is broken here
<seb128> it works fine here with secure connection to "never"
<seb128> and the workaround works for all the bug reporters for the moment
<seb128> BTW the problems seems to be fixed upstream so we are waiting for a new release :)
<Keybuk> you're allowed to patch it, you know :p
(lamont/#ubuntu-devel) mvo around?
(lamont/#ubuntu-devel) off to take the kids to school
<mvo_> lamont: yes
(Kamion/#ubuntu-devel) elmo: seemed to work
(elmo/#ubuntu-devel) Kamion: cool
(bob2/#ubuntu-devel) aw, I coulda done a test upload of X.org for you
<daniels> bob2: you're not in the keyring, foo'
(bob2/#ubuntu-devel) hrm, I was
<seb128> Keybuk: I know, but starting to include CVS changes for each bug in a devel branch is insane
<pitti> daniels: I just replied to #2327, but did not CC you...
(elmo/#ubuntu-devel) can someone, esp. someone not already familiar with ubuntu uploads, check out Uploads on the wiki and see if it makes sense?
<daniels> pitti: cheers
<pitti> daniels: not easy, eh?
<daniels> pitti: gnaaarrrrrrrrrrrr
<pitti> daniels: I produced a similar noise when I found out all details and options about this issue
(azeem/#ubuntu-devel) elmo: you could clarify on that 'and/or' part for .changes perhaps
<pitti> daniels: so far my best solution is to walk to the Apple factory equipped with a chainsaw
<fabbione> re
<pitti> daniels: and force the people to provide real AltGr keys on the iBooks...
(bob2/#ubuntu-devel) yeah, the "notification" point is a little confusing
<fabbione> elmo: so basically now, ftp on jackass is open?
(elmo/#ubuntu-devel) yes, it's running a custom (python) ftpd
<fabbione> ahh that's why UploadQueue disappeared all of a sudden
(elmo/#ubuntu-devel) fabbione: it's a totally fake fs, you can upload into /UploadQueue still if you want, it all ends up in the same place when you logoff
<fabbione> uh yeah.. well i did try ls and cd and it was all empty
<fabbione> but that's ok
<fabbione> until it works.. who cares? ;)
(elmo/#ubuntu-devel) yeah, it works enough for existing dupload/dput configs not to break, which is what I cared about
(elmo/#ubuntu-devel) (i.e. all our buildds ;)
<fabbione> ehehe
<daniels> pitti: heh
<fabbione> elmo: xfree86 ubuntu26 is in the archive.. you can move it to universe (source included) anytime you prefer
<fabbione> not too bad.. only 14 FTBFS on sparc at the end of phase0
<smurfix> elmo: "use one of the pre-registered email addresses" -- registered where and when? Otherwise it makes sense.
<fabbione> of which most of them are common to debian and ubuntu
<fabbione> lamont: ping
(elmo/#ubuntu-devel) can anyone think of a better name than 'ftp-master' or 'archive-master'?  I need something both as an alias for jackass and an email adresss, but neither are terribly appealing
<fabbione> god@ ?
<fabbione> ;)
(elmo/#ubuntu-devel) meh
* elmo strikes fabbione down with a bolt of lightning
<zul> zeus@
(bob2/#ubuntu-devel) Iletyouuploadpackages@
(bob2/#ubuntu-devel) cf Isignyourpaychecks
(Mithrandir/#ubuntu-devel) archive is taken, else it'd be a good name.
<fabbione> iamjamestroupyourftpandarchivemaster@
(Mithrandir/#ubuntu-devel) elmo: upload ?
(Mithrandir/#ubuntu-devel) upload.ubuntu.com, upload@ubuntu.com
<fabbione> let-me-in
(bob2/#ubuntu-devel) ooh, that's good
(Mithrandir/#ubuntu-devel) trapdoor, as in something packages pass through.
(bob2/#ubuntu-devel) katie?
(Mithrandir/#ubuntu-devel) or incoming, but that's used already.
<shaya> does martin pitt hang out here?
<pitti> shaya: that's me
<daniels> letmeatthecrackpipe.u.c
<fabbione> elmo: what about picking up a name from one of your gf?
<pitti> shaya: ah, you are the guy with the funny dvd?
<daniels> fabbione: may I suggest konnie?
<shaya> yes
<fabbione> daniels: i don't care.. they are elmo's gf
<shaya> how many shaya's use ubunut :)
<pitti> shaya: does it work with other DVDs/CDs?
<shaya> yes
<shaya> just updated bugzilla
<shaya> it's the X bit
<pitti> shaya: I tested this with some DVDs too, worked fine
<shaya> does it make sense that dvd's that are user mounted in iso9660 or udf should have the x bit forced for their dirs?
<shaya> i.e. doesn't make sense that a dir wouldn't be accessible
<pitti> shaya: right
<pitti> shaya: the mount manpage does not give any option for this, however
<shaya> pitti: but that would be a kernel bug?
<shaya> right, I checked
<pitti> shaya: you could try umask=000
<pitti> shaya: it is not officially suppored for UDF, but maybe it works
<shaya> that's global though
<pitti> shaya: right
<shaya> I was thinking more of something that just affects dirs
<shaya> dont want every file changed
<shaya> pitti: though setting uid and gid to the the user might also work
<pitti> shaya: well, there is little that you can do about broken permissions...
<shaya> that would seem to be the more sane thing
<pitti> shaya: I doubt it
<pitti> shaya: because uid= and gid= only alter files that are owned by root
<pitti> shaya: however, the files are owned by a nonexisting UID
<pitti> shaya: you can try, however
<shaya> oh
<pitti> shaya: uid=1000,gid=1000 or so
<shaya> all my DVDs are owned by the same nonexisting one
<pitti> shaya: this option change in fstab would be global, too, but it makes sense for most CD-ROMs
<shaya> i.e. Gattaca (Region 1)
<shaya> dr-xr-xr-x  3 4294967295 4294967295   88 1998-05-12 15:38 cdrom0
<shaya> as long as single user system :)
<pitti> shaya: where the hell is this broken uid coming from?
<shaya> I have no idea
<pitti> shaya: did you burn these DVDs yourself?
<shaya> no
<shaya> this is commercial Gattaca Region 1 DVD
<shaya> have about 40-50 other commercial ones I can test
<shaya> but cant do it now
<pitti> shaya: sorry, I'm lost with this; I do not want to patch mount/the kernel to ignore permissions on CD-ROMs
<shaya> k
<pitti> shaya: can you try with uid/gid?
<pitti> shaya: in any case, there is not much I can do as a general solution; there are many people who do want the permissions on mounted devices to be respected
<pitti> shaya: (me, for example :) )
<fabbione> pitti: are you on ppc?
<pitti> fabbione: not currently, but I can boot it if you want
<shaya> pitti: I'm trying to wonder what perms mean for udf/iso9660?
<fabbione> pitti: can you try to build redland-bindings and tell me if it fails because it can't find -lmysqlclient?
<pitti> shaya: well, they mean exactly the same as for any other file system
<fabbione> pitti: i think something has been changed since the upload and now it FTBFS
<pitti> fabbione: sure. Is this ppc-specific?
<fabbione> pitti: i think it is for all arch, but i would like to be sure
(bob2/#ubuntu-devel) I can run it now if you're busy, pitti 
<pitti> fabbione: okay, my iBook is booting. 
<fabbione> pitti: be sure not to have libmysqlclients{,10}-dev installed
<pitti> bob2: oh, if you want to...
<pitti> fabbione: sure
<fabbione> pitti: and that build-dep are satisfied
<pitti> fabbione: usually I wipe everything away that I don't need
(bob2/#ubuntu-devel) pitti: heh, wouldn't want you to get bored ;-)
<pitti> fabbione: and being the PostgreSQL maintainer I certainly don't need mysql :-))
<fabbione> pitti: ehehe well.. i didn't think to have mysql stuff installed.. but i did
<pitti> bob2: I'm at it
<pitti> fabbione: oh, do you mean the Hoary version? My iBook is warty currently
(bob2/#ubuntu-devel) pitti: btw, sleep now works!
<pitti> bob2: yay, with BehH's kernel?
<fabbione> pitti: yes. i need hoary
<fabbione> that package is not even in warty
(bob2/#ubuntu-devel) pitti: yup
(bob2/#ubuntu-devel) fabbione: I'm doing it on hoary now
<fabbione> bob2: arch?
(bob2/#ubuntu-devel) fabbione: ppc
<fabbione> bob2: cool thanks
(bob2/#ubuntu-devel) pitti: I sent a followup to 1940 about it
<pitti> bob2: are there readymade kernel images somewhere?
<pitti> bob2: that would be nice
<pitti> bob2: I don't know how to deal with this bug anyway
(bob2/#ubuntu-devel) pitti: no :/.  and it's only against 2.6.9
(bob2/#ubuntu-devel) pitti: do you know when 2.6.9 will hit hoary?
(bob2/#ubuntu-devel) fabbione: /usr/bin/ld: cannot find -lmysqlclient
<pitti> bob2: no, sorry
<pitti> bob2: damn, you were faster
(bob2/#ubuntu-devel) fabbione: do you want a log?
<pitti> bob2: I just managed to download the source package
(bob2/#ubuntu-devel) pitti: heh, mark's dsl rocks
<fabbione> bob2: no thanks.. it's the same failure all over
(elmo/#ubuntu-devel) oh good god
(bob2/#ubuntu-devel) fabbione: ok
(elmo/#ubuntu-devel) oo.o runs gimp in a virtual X session as part of the build process
<pitti> bob2: when you are at it, can you please reassign the bug to Herbert and ask him to include the patch?
(bob2/#ubuntu-devel) hahahaha
(bob2/#ubuntu-devel) pitti: sure
<fabbione> elmo: you are the license expert.. against which of the 2 libmysqlclients library should we link?
<pitti> bob2: thanks! One neglected bug less.. :)
<daniels> lamont: i think i would need access to an ia64 machine to get x building on that
(elmo/#ubuntu-devel) fabbione: err.. depends - what are you linking it to?
<pitti> shaya: any success?
<fabbione> daniels: you have the MANIFEST files... isn't that enough?
<fabbione> elmo: redland-bindings
(bob2/#ubuntu-devel) pitti: just about all the people who followed up seemed very confused about whether it was supposed to work or not
<shaya> pitti: cant try it
<shaya> right now at least, need to run off to school
<pitti> shaya: have fun
<fabbione> 1. The GNU Lesser General Public License (LGPL) Version 2.1
<pitti> shaya: btw, do you object to closing the bug?
<fabbione> elmo: it's LGPL
<daniels> fabbione: grep MANIFEST.ia64.in for Xorg
(elmo/#ubuntu-devel) fabbione: either should be fine then
<fabbione> elmo: so i guess i need to link with libmysqlclient10
<daniels> oh, hold on
<daniels> fabbione: those files are from xfree86, aren't they?
<fabbione> daniels: wake up :-)
<daniels> oh crap
<fabbione> elmo: do you remember if there is any policy against which one to link? iirc there was a lot of discussion that they can't be mixed....
<daniels> that *sucks* dude
<fabbione> daniels: you kinda need to update the MANIFEST
<fabbione> daniels: we did it for i386, amd64, ppc, sparc
<daniels> 'kinda' :P
<fabbione> daniels: i told you already.. that's why you got the new MANIFEST from lamont
(elmo/#ubuntu-devel) fabbione: the problem is the newer one is/was GPL incompatible.  AFAIK upstream were trying to fix this, but kept fucking up.  I'm not sure if it ever got 100% resolved.  OTOH, LGPL is a free'n'easy license and you can happily link it with even the GPL-incompatible libmysql license
<fabbione> elmo: ok. cool!
<shaya> pitti: well, it's a broken DVD, unsure what the correct course is, if you want to close it I wont object
<pitti> shaya: the problem is that we cannot fix this generally<
<lucas_> hi
<fabbione> ok.. let see if jackass works from remote :-)
<shaya> pitti: it would seem perhaps udf should be smart and say "if all the directories in the root are not traversable, this is a broken DVD and we should handle it as such"
<pitti> shaya: maybe we should rather correct broken uids to root
<pitti> shaya: and the kernel should support uid/gid
<pitti> shaya: I leave the bug open for now and comment it
<shaya> pitti: the problem isn't just uid
<shaya> for example Gattaca has messed up UID but still works perfectly, as it's dirs are r-x
<pitti> shaya: I know, it's permissions
<pitti> shaya: can you please play around with umask/dmask/uid/gid
<pitti> shaya: and report back to the bug if you found something?
<shaya> ok
<shaya> time to run
(lamont/#ubuntu-devel) moo
(azeem/#ubuntu-devel) oh, is ubuntu-devel gated bi-directionally to ubuntuforums.org?
(bob2/#ubuntu-devel) I hope not
(bob2/#ubuntu-devel) use gmane
(azeem/#ubuntu-devel) eh, *I* wont' use it
<daniels> there's a bidirectional gate to the forums, yes
(azeem/#ubuntu-devel) ah
(azeem/#ubuntu-devel) I was just about to send away a mail, better cancel that then
(azeem/#ubuntu-devel) poptone's messages are quite readable in the forum but totally unreadable via the list
<daniels> fabbione: 
<daniels> if [ "$(echo "$DISPLAY_MODES" | grep 1280x800)" ] ; then
<daniels>   printf "\tModeline\t\"1280x800@60\" 83.91 1280 1312 1624 1656 800 816 824 841\n" >&4
<daniels> fi
<daniels> fabbione: (dexconf) surely that should be in #989?
<mxpxpod> is there any chance of 2.6.9 going into hoary any time soon?
(bob2/#ubuntu-devel) I hope so
<mxpxpod> who would I email about that?
(bob2/#ubuntu-devel) about asking for it?
<mxpxpod> that, or about certain patches to the ubuntu kernel (like the wlan-ng patch)
<mxpxpod> because I'd like to start using 2.6.9+benh's ibook g4 sleep patch on a regular basis, but w/o the wlan-ng patches, I can't use wireless
(bob2/#ubuntu-devel) hah, me too
(bob2/#ubuntu-devel) I just sent an email to herbert about that an hour ago
<mxpxpod> bob2: ah, cool... keep me posted
(bob2/#ubuntu-devel) why do you need a wlan-ng patch?
(bob2/#ubuntu-devel) or do you mean the modules?
<mxpxpod> bob2: I mean the modules... they aren't in the vanilla kernel
(bob2/#ubuntu-devel) yeah
<mxpxpod> bob2: make sense?
(bob2/#ubuntu-devel) well, yeah
(bob2/#ubuntu-devel) but it's pretty easy to build the modules from linux-wlan.org, manually
<mxpxpod> bob2: yeah, I know... but it's easier to have them in the kernel :P
<pitti> lamont: here?
(bob2/#ubuntu-devel) mxpxpod: heh, true, that's the exact reason I'm not using the patch yet
(bob2/#ubuntu-devel) I tried forward-porting the ubuntu kernel source to 2.6.9, but the build failed, and I was too tired to try fix it
(lamont/#ubuntu-devel) pitti: yo
<mxpxpod> bob2: I tested -2 of the patch and it seemed to work alright... I had to enable AGPMode "4" and EnablePageFlipping "true", but that was it
<pitti> lamont: I uploaded an fcron security update a while ago; i386 and ppc are ready for ages, but amd64 build did not arrive yet
(bob2/#ubuntu-devel) mxpxpod: with x.org?
<mxpxpod> bob2: yeah
<pitti> lamont: is this stuck somewhere or FTBFS?
(bob2/#ubuntu-devel) mxpxpod: ah, ok...
<mxpxpod> bob2: and sometimes the panel would crash after a wakeup... not sure about that
(bob2/#ubuntu-devel) daniels: are those options sane to enable on ibook's all the time?
<mxpxpod> bob2: maybe -4 will fix that
(bob2/#ubuntu-devel) mxpxpod: -4 fixed a bug like that, yeah
* lamont looks
(bob2/#ubuntu-devel) mxpxpod: have you tried pmdisk/swsusp from 2.6.9 on your machine?
<mxpxpod> bob2: I had them enabled on xfree86... they seemed fine
<mxpxpod> bob2: yeah, I did, but they don't work with dri enable
<mxpxpod> d
(bob2/#ubuntu-devel) mxpxpod: even with x.org?
<mxpxpod> bob2: didn't test with xorg
(bob2/#ubuntu-devel) (iirc it should work with dri on x.org now)
(bob2/#ubuntu-devel) ah
* mxpxpod is still waiting for the utf-8 fix for xorg to make it to ppc
(bob2/#ubuntu-devel) hrm, what's that?
<daniels> bob2: which options?
(bob2/#ubuntu-devel) daniels: AGPMode "4" and EnablePageFlipping "true"
<daniels> no
<mxpxpod> bob2: when I launch an X/GNOME app from the command line, I get a warning about my utf-8 locale
<mxpxpod> daniels: why?
(bob2/#ubuntu-devel) mxpxpod: ah
<daniels> mxpxpod: a) dude, not everyone has agp, b) not everyone has 4x agp, c) page flipping breaks on many i386 chipsets iirc
<daniels> your problem will likely be fixed with benh's radeon megapatch which I'm waiting on the final version of
<mxpxpod> daniels: this is on an ibook g4 where we have 4x agp
<mxpxpod> daniels: awesome
(bob2/#ubuntu-devel) ah
<mxpxpod> daniels: you're doing an awesome job on xorg
<daniels> cheers
<daniels> yeah, unfortunately we can't reliably pick amiagp4xornot
<mxpxpod> daniels: oh, I figured out my font problem... I turned off the autohinter which made smaller fonts look really strange
(bob2/#ubuntu-devel) you should setup a website
(bob2/#ubuntu-devel) so people can vote if it's 4xagpornot
(lamont/#ubuntu-devel) pitti: grumble.  fixed.
<pitti> lamont: thanks a lot!
<pitti> lamont: my fault or the buildd's?
(lamont/#ubuntu-devel) not yours
<daniels> mxpxpod: ah, rad
<mxpxpod> daniels: is there a way to turn off the autohinter for smaller fonts?
<pitti> lamont: hmm, it's still not on jackass
<mxpxpod> daniels: like, 11 pt. fonts and smaller?
<daniels> mxpxpod: i'm not sure, sorry -- fonts simultaneously scare me and hurt my head
(lamont/#ubuntu-devel) pitti: give it another 5 minutes, eh?
<mxpxpod> daniels: haha, ok
<pitti> lamont: okay, thanks :)
<mxpxpod> daniels: if I figure it out, I'll let you know
(elmo/#ubuntu-devel) that's lamont-polite-speak for 'elmo fucked up the MTA config' ;)
<lupus_> this bug can be closed: https://bugzilla.ubuntu.com/show_bug.cgi?id=303 since it will be in hoary if I'm not mistaking
(lamont/#ubuntu-devel) elmo: and I didn't notice for long enough that we actually bounced a bunch of logs... :-(
<mxpxpod> daniels: I'm also experiencing a flash of black when I click logout on the gnome-panel
(lamont/#ubuntu-devel) pitti: still arguing with a couple things...  I'll tell you when it's there
<daniels> mxpxpod: wack
<mxpxpod> daniels: huh?
(lamont/#ubuntu-devel) pitti: uploaded, :35 should see the accepted queue
<daniels> mxpxpod: weird
(elmo/#ubuntu-devel) whee, nice stress test of poppy, thanks lamont :)
(lamont/#ubuntu-devel) elmo: glad to help. :-)
(lamont/#ubuntu-devel) poppy is the new upload processor?
<mxpxpod> daniels: ah, ok
(Kamion/#ubuntu-devel) lupus_: done, thanks
(elmo/#ubuntu-devel) lamont: right
* lamont bows
(elmo/#ubuntu-devel) okay, please recheck: http://www.ubuntulinux.org/wiki/Uploads
(elmo/#ubuntu-devel) ?
(lamont/#ubuntu-devel) looks sane to me - I assume the .cf entries are correct...
(lamont/#ubuntu-devel) and buildd's need not change their dupload.cf, correct?
(elmo/#ubuntu-devel) lamont: yep
(elmo/#ubuntu-devel) I made sure of that :)
(lamont/#ubuntu-devel) the rest looks comprehensive
(Mithrandir/#ubuntu-devel) elmo: possibly note in big letters that only Ubuntu devs may upload?
* lamont wanders off for about 30 minutes
(bob2/#ubuntu-devel) oh mozilla, please use 100% of my cpu
<mozilla> bob2: if you had a nice fast X40 as opposed to your slow iBook, I'd be far more forgiving
(kylem/#ubuntu-devel) haha.
(bob2/#ubuntu-devel) I hate you milkman dan.
(bob2/#ubuntu-devel) (iels)
(tseng/#ubuntu-devel) that might be cheaper than gas
(tseng/#ubuntu-devel) from NC
(tseng/#ubuntu-devel) er, damn window again
(elmo/#ubuntu-devel) bob2: just call him, Daniel Bellamy
(elmo/#ubuntu-devel) he likes that name
<lupus_> does hoary support chinese input methodes??
<daniels> elmo: watch it
<daniels> elmo: mr 'i have so much impulse control i'll shove my finger into a ring that's already been shown to be too small for most fingers'
* Mithrandir chalks down another happy ubuntu user, though live-cd for now.
<ironwolf> daniels: 0000:01:01.0 VGA compatible controller: S3 Inc. Trio 64 3D (rev 01)
<ironwolf> daniels around?
<daniels> ironwolf: yo dude
<daniels> ironwolf: ah, thanks very much
<daniels> ironwolf: that really should be supported ...
<ironwolf> daniels: let me know how I help this fine, fine user/new convert.
<daniels> ironwolf: 'sec
<daniels> ironwolf: what's the output of lspci -n?
<ironwolf> daniels: gotta wait for user to wake up.
<daniels> ironwolf: heh, sure :)
<smurfix> daniels: any known reports of a radeon 9600 just turning off its digital output when X starts up? (also happens with the kernel radeonfb driver) may be a hardware problem, but ENOWAYTOTEST
<daniels> ironwolf: AH!
<daniels> ironwolf: change 's3' to 's3v'
<daniels> smurfix: yep, there sure is, will be fixed in the next xorg upload
<smurfix> daniels: good to hear. Ditto the kernel driver, I assume.
<daniels> smurfix: probably not with radeonfb
<smurfix> hmm. Does having radeonfb loaded make sense for X, these days?
<daniels> not really for X, but it's kind of nice if you want to use the console ;)
<daniels> benh wrote radeonfb and he does all the detection code for the X driver, so they play very well together
<daniels> i'm waiting on a patch from him (should come tomorrow, Australian time) to fix like every detection issue with the radeon driver ever
<smurfix> daniels: I can use vesafb for that. Fortunately, otherwise I'd have no X at all right now.
<daniels> ... why no X at all?
<smurfix> daniels: because I can use either vesafb or the radeon driver... and since the latter doesn'twork at the moment, I'm reasonably happy with the former, even though that means I can't watch DVDs. Does wonders for my productivity, though, or at least it would if I could use both hands.
<daniels> 'either vesafb or the radeon driver'
<daniels> do you mean radeonfb?  or the vesa driver in X?
<smurfix> daniels: sorry for being unclear -- I meant "vesafb+framebuffer". Didn't try X's vesa support, as I don't see the point of doing that.
(sjoerd/#ubuntu-devel) daniels: wtf is Fo'shizzle
(bob2/#ubuntu-devel) haha
<daniels> sjoerd: 'certainly'
(sjoerd/#ubuntu-devel) thanks :)
<ironwolf> daniels: s3v X didn't start.
<daniels> ironwolf: bugger.  what was the error?
<ironwolf> daniels: no screens found
<ironwolf> daniels: where should I send the Xorg.0.log?
<daniels> ironwolf: to daniel@fooishbar.org, please
<ironwolf> daniels: sent.
(mdz/#ubuntu-devel) good morning, Ubuntuans
(lamont/#ubuntu-devel) morning mdz
(Kamion/#ubuntu-devel) hey mdz
(Kamion/#ubuntu-devel) hm, typing while wearing a gi is fiddly
(mdz/#ubuntu-devel) trying to remember how to use this "keyboard" thing
(Kamion/#ubuntu-devel) the sleeves keep getting in the way of the keyboard
(elmo/#ubuntu-devel) mdz: back already?
(mdz/#ubuntu-devel) on schedule
(mdz/#ubuntu-devel) heard from thom recently?  he's supposedly in town
<wasabi> Is NFSv4 going to be included in Ubuntu at any point?
<mvo_> hi mdz
(Kamion/#ubuntu-devel) wasabi: is it slated for inclusion in the upstream kernel?
(mdz/#ubuntu-devel) wasabi: it already is
<wasabi> It's in 2.6.
(Kamion/#ubuntu-devel) aha, even better
(mdz/#ubuntu-devel) CONFIG_NFSD_V4=y
<wasabi> mdz: it seems to require user mode utilities
<wasabi> which are not present
(mdz/#ubuntu-devel) I see
(mdz/#ubuntu-devel) new tools, or just a new mount?
<wasabi> I'm not sure.
(mdz/#ubuntu-devel) s/mount/version of &/
<wasabi> jhaltom@station-1 jhaltom $ sudo mount /export/bin/
<wasabi> NFSv4 not supported!
<wasabi> NFSv4 not supported!
<wasabi> Tht's all I can tell you. ;)
<wasabi> But it's in both kernels at both ends.
(mdz/#ubuntu-devel) wasabi: if you find out what's required, drop a note to ubuntu-devel
(Kamion/#ubuntu-devel) http://www.citi.umich.edu/projects/nfsv4/patches-2.5/patch-util-linux-2.11t-A
(Kamion/#ubuntu-devel) that may be an older version
(Kamion/#ubuntu-devel) the optimal solution is to have the requisite patches merged into util-linux upstream so that everyone gets them, though
<wasabi> yeah of course
<wasabi> I'd really like to start using the GSSAPI support.
(Kamion/#ubuntu-devel) RH seem to have an NFSv4 patch to util-linux, or so Google suggests
<wasabi> buh latest hoary upgrade just friend my gnome-panel xinerama detection. it's now spanning all 3 monitors.
<wasabi> s/friend/fried/
(mdz/#ubuntu-devel) Kamion: does util-linux still have an upstream?
(Kamion/#ubuntu-devel) mdz: he's looking for an adopter I believe
* lamont is 75% looking for a co-maintainer as well...
(lamont/#ubuntu-devel) it's an annoying, griefsome package.
<smurfix> looks like a chunk of work for somebody who needs some more stuff on their plate to feel happy
(lamont/#ubuntu-devel) then again, part of that has been due to the size of the diff... being (part of) upstream might make that less painful
(lamont/#ubuntu-devel) or rather, painful in different ways...
<smurfix> I passed that point some time ago :-/
* lamont tackles zsh
<wasabi> Anybody know much about nscd? Trying to get it to cache the entire passwd table.
(elmo/#ubuntu-devel) Kamion: are the -pic packages still used?
<wasabi> grrr.
(lamont/#ubuntu-devel) Kamion: you around?
(lamont/#ubuntu-devel) GAH! gthktml3 has a md5mismatch on orig.tar.gz as well???
(mdz/#ubuntu-devel) wasabi: what I know about nscd is that it is buggy, which is why we don't use it
<wasabi>  I have to
<wasabi> LDAP based users.
(mdz/#ubuntu-devel) lamont: mismatch between what and what?
(mdz/#ubuntu-devel) lamont: are you back at home now?
(lamont/#ubuntu-devel) mdz: most of those are because we uploaded a diff orig.tar.gz to warty than debian got.
(lamont/#ubuntu-devel) yes, home
(elmo/#ubuntu-devel) I should probably just make the sync break when that happens
(lamont/#ubuntu-devel) elmo: pretty please?
(lamont/#ubuntu-devel) mdz: and this is how you wind up with xx_2.8.0ubuntu-1ubuntu1
(lamont/#ubuntu-devel) doko??
(mdz/#ubuntu-devel) lamont, seb128: how did we end up with a different .orig?
(mdz/#ubuntu-devel) I thought gnome released official .tar.gzs
<seb128_> for which package ?
<seb128_> elmo: gconf-editor sync please 
(lamont/#ubuntu-devel) seb128: devel/gal2.2_2.2.3ubuntu1-1ubuntu1: Installed [optional:uncompiled] 
(lamont/#ubuntu-devel) that's the only one I've fixed todate
<seb128_> perhaps Kitame did some changes ...
(lamont/#ubuntu-devel) gtkhtml3 has an md5sum mismatch
<seb128_> I don't know how Kitame works
(lamont/#ubuntu-devel) as does python-gtk2
(elmo/#ubuntu-devel) seb128: done
<seb128_> elmo: thanks
<seb128_> lamont: I don't understand for python-gtk2. 2 tar of the same dirs made a differents moment have the same md5 ?
(elmo/#ubuntu-devel) seb128: gziped files have a timestamp
(elmo/#ubuntu-devel) IIRC
<doko> lamont: here
<seb128> that's probably it, I don't know why but some debian packages have source package name different of the upstream one, the tarball is remade
<seb128> elmo: libbonoboui sync too please :)
(lamont/#ubuntu-devel) doko: need an upload of gcc-3.4 that turns off the ada tests for ia64 (or otherwise works..)
<doko> lamont: could you check out the one from unstable, if that works for you?
(lamont/#ubuntu-devel) doko: if you want to tell me what to change, I can verify that it works before uploading...
(lamont/#ubuntu-devel) sure
(mdz/#ubuntu-devel) mvo_: are your apt changes in arch where I can merge them easily?
(lamont/#ubuntu-devel) elmo: once gcc-3.4 is in, and my debootstrap upload is done, you can debootstrap hoary
<mvo_> mdz: not yet, sorry for that. I can do this tomorrow morning
<mvo_> mdz: I assume you didn't had a chance to look over the packages.gz (pdiff) patch  I send to the debian-deity list?
<mvo_> yet
<doko> lamont: are you going to apply the libunwind patches in binutils/glibc and gcc-3.[34]  ?
(lamont/#ubuntu-devel) doko?
<doko> lamont: http://lists.debian.org/debian-ia64/2004/10/msg00029.html
(lamont/#ubuntu-devel) which is to say that we want debzilla to sync 278835-278837
(lamont/#ubuntu-devel) any reason _not_ to bring my laptop to current-hoary?
<wasabi> nfs-common should be included by default.
<wasabi> It isn't apparently.
(mdz/#ubuntu-devel) mvo_: that mailbox is very low on the priority list, and I have much mail to read :-)
<ironwolf> lamont: good luck. no reason I can see. :)
(mdz/#ubuntu-devel) mvo_: please send me a patch or a changeset reference so that I can get the bzip2 fixes into mainline
(lamont/#ubuntu-devel) ironwolf: heh
* lamont grabs some lunch
<ironwolf> With liveCD can ping router/gateway, with installed system, can't ping router/gateway.  Where do I look to make this work?
<qopi> hello peeps
<qopi> i've got a really wierd bug
* qopi thinks it has something to do with X
<qopi> since an X appears in the middle of my screen every time i start up
(sladen/#ubuntu-devel) qopi: hardware cursor.  Add the X option   SWcursor on
(sladen/#ubuntu-devel) the very simple way around this bug would be to set the default cursor to be 100% transparent
<qopi> sladen: how/wherer would I do that?
(sladen/#ubuntu-devel) qopi: /etc/XF86Config.conf
<narcisiss> fast question, does it exist a way to install the livecd to the hd?
<Matt|> hello all
<Matt|> massive problem has been caused by the last hoary updates. Any one else have it?
<ironwolf> narcisiss: no :(
<ironwolf> matt|: which problem?
(elmo/#ubuntu-devel) Kamion: what's the solution to parted's brain damage on powerpc?  use something else?
<qopi> ironwolf: i've got another wierd bug too: my computer makes strange sounds as it starts up
<Matt|> ironwolf, not sure the cause. I cannot open the attach file dialogue on evolution or gaim, and I cannot open the change desktop background dialogue. In all cases they all crash
<ironwolf> Matt|: weird... I'm not seeing it.
<Matt|> i'm thinking that perhaps I can't open any dialogues
<ironwolf> qopi: that's probably intentionally :) darn african drums
<narcisiss> rotl
<narcisiss> rotfl =)
<Matt|> ok the OOo open file dialogue works.
<Matt|> i get this error when trying to do these things in the terminal
<Matt|> (gaim:4973): Gdk-WARNING **: locale not supported by Xlib
<Matt|> (gaim:4973): Gdk-WARNING **: cannot set locale modifiers
<Matt|> i'll try and reconfigure
* lamont remembers a movie date with his daughter, runs out the door
<Matt|> have fun
* ironwolf waves to lamont.
(sladen/#ubuntu-devel) narcisiss: IIRC the warty LiveCD is based on Mophix which is based on Knoppix.  the Knoppix way is .../.../hd-install or somesuch
<Matt|> ironwolf, any ideas about that error?
<qopi> ironwolf: i see. guess my soundcard isn't properly installed or my speakers are fuxored
(sladen/#ubuntu-devel) narcisiss: it would be better to use the Proper Ubuntu installer which has lots of autodetection foo
<ironwolf> Matt|: no clue sorry.
<Matt|> damn
<Matt|> shall i file it?
<ironwolf> yup :(
<Matt|> K
<Matt|> np those X11 guys are great at replying to bugs :)
<narcisiss> sladen: the problem is this one: with the livecd i can use the net, with the installed version i cannot
<ironwolf> Matt|: daniels is great.. I agree.
<qopi> narcisiss: knx-hdinstall or knx-installer
* qopi just read that in #mepis
<Matt|> ironwolf, they are both great :)
<ironwolf> Matt|: both? Fabbione doesn't do X anymore I thought. correct me if I'm wrong.
<Matt|>   	 fabbione@canonical.com   	
<Matt|> xlibs
<Matt|> is that a good package to file it under?
<Matt|> i really have no clue
<narcisiss> brb
<ironwolf> no clue matt
<Matt|> ironwolf, thanks for ya help anyhow
<mxpxpod> how can I get the cramfs patch for vanilla kernels?
<Matt|> google?
(Kamion/#ubuntu-devel) elmo: -pic> you mean debian-installer's build-deps?
(Kamion/#ubuntu-devel) elmo: Sven's got some idea for how to fix it I think, we'll probably get it in hoary
(elmo/#ubuntu-devel) ok
(Kamion/#ubuntu-devel) elmo: if you want something now you could fart about with mac-fdisk and pray
(elmo/#ubuntu-devel) and nm, about the parted question
(elmo/#ubuntu-devel) Kamion: just using mdadm to create the array seems happy enough
(elmo/#ubuntu-devel) I dunno if it'll auto-start though
(Kamion/#ubuntu-devel) elmo: the -pic packages are something to do with extreme mklibs weird shit; I had great fun with that while trying to build gtk d-i
(Kamion/#ubuntu-devel) elmo: what partition type are you using?
(elmo/#ubuntu-devel) 4        954.660  78533.437              untitled              
(elmo/#ubuntu-devel) kamion: err, how do you mean?
(Kamion/#ubuntu-devel) uh
(Kamion/#ubuntu-devel) what's printing that?
(elmo/#ubuntu-devel) parted
(Kamion/#ubuntu-devel) oh, parted's annoying for that, try mac-fdisk
(Kamion/#ubuntu-devel) second column
(elmo/#ubuntu-devel) what crack is pmac-fdisk btw?  it REALLY doesn't like the Xserve
(Kamion/#ubuntu-devel) mac partition types are textual (!)
(elmo/#ubuntu-devel) /dev/sda4         Apple_UNIX_SVR2 untitled           158881336 @ 1955144   ( 75.8G)  Linux native
(Kamion/#ubuntu-devel) don't use pmac-fdisk, it's for IBM powerpc systems
(Kamion/#ubuntu-devel) the names are fucked up but that's the gist of it
(elmo/#ubuntu-devel) meh, the short description REALLY needs to say that
(elmo/#ubuntu-devel) in fact _any_ part of the description
(Kamion/#ubuntu-devel) bleh, I thought djpig and I had fixed that between us
(Kamion/#ubuntu-devel) evidently not
(Kamion/#ubuntu-devel) "the PC partition format" is about as clear as it gets
(Kamion/#ubuntu-devel) ok, so Apple_UNIX_SVR2 is just the same as every other Unix partition on a mac disklabel, fair enough
(Kamion/#ubuntu-devel) lamont: ?
<Matt|> he's gone to the movies
(elmo/#ubuntu-devel) Kamion: is the sungem causing an oops a discover+hotplug bug and/or a kernel one?
(Kamion/#ubuntu-devel) elmo: it must be a kernel bug; could be discover/hotplug in addition but seems less likely
(elmo/#ubuntu-devel) well I more mean discover/hotplug for trying to load it when it's not needed
<Mitario> lo everyone
<narcisiss> after i type "ifconfig eth0 up" i receive this message from the kernel:
<narcisiss> Message from syslogd@localhost at Mon Nov 22 23:23:40 2004 ...
<narcisiss> localhost kernel: Disabling IRQ #233
<narcisiss> where 233 is the irq of the eth card
<narcisiss> so i cannot use the net
<narcisiss> how can i change that irq?
(elmo/#ubuntu-devel) openoffice.org gcc-3.3 mozilla-firefox gnumeric xfree86 tla
(elmo/#ubuntu-devel) anyone got any suggestions for additions to the above to en-mass populate a chroot with a useful set of build-depends ?
<_rene_> kde* gnome*?
<_rene_> ;)
#ubuntu-devel 2004-12-04
<doko> elmo: tetex-bin
<htaccess> if there is anyone from cannonical here, has ubuntu been invited to join the Linux Core Consortium?
(Mithrandir/#ubuntu-devel) I'm from canonical, but I don't know.
<carlos> htaccess: that looks like UnitedLinux second try
<carlos> but changing Caldera with Progeny and Suse with Mandrake
<lupus_> will openoffice 2.0 be ready before hoary I wonder
<carlos> don't think they will want to invite Ubuntu or any other distribution, a new distribution could "steal" their customers (personal opinion)
<Matt|> is it possible to get bashcompletion working with things like "apt-get install" or "killall" and suchlike on ubuntu? or is it something to do with the way you compile the packages?
<carlos> Matt|: look at /etc/bash_completion.d
<Matt|> thanks
<Matt|> it is very long
<Matt|> oh no sorry it is empty
<carlos> :-?
<Matt|> /etc/bash_completion is very long
<carlos> look at the .d
<Matt|> nothing in d
<carlos> carlos@frodo ~ $ ls -l /etc/bash_completion.d/
<carlos> total 32
<carlos> -rw-r--r--  1 root root 5437 2004-06-20 11:23 dpatch_edit_patch
<carlos> -rw-r--r--  1 root root 2340 2004-02-19 01:16 make_kpkg
<carlos> -rw-r--r--  1 root root  946 2004-07-23 11:05 pon
<carlos> -rw-r--r--  1 root root 5702 2004-11-02 17:29 quilt
<carlos> -rw-r--r--  1 root root 8105 2004-09-30 14:16 subversion
<Matt|> howdya do that?
<carlos> I just have those file there
<Matt|> perhaps this is better in #ubuntu
* carlos is in hoary
<Matt|> me too
<carlos> Matt|: yes, better #ubuntu
<seb128> you just need to uncomment it in ~/.bashrc IIRC
<carlos> seb128: it depends on the command
<carlos> not all commands have that feature
<seb128> he was speaking about apt-get install
<seb128> I guess the include is commented
<Matt|> could it be this:
<Matt|> # enable programmable completion features (you don't need to enable
<Matt|> # this, if it's already enabled in /etc/bash.bashrc).
<Matt|> #if [ -f /etc/bash_completion ] ; then
<Matt|> #    . /etc/bash_completion
<Matt|> #fi
<carlos> Matt|: yes
<seb128> that's it
(elmo/#ubuntu-devel) warty-release-install-i286.iso
(elmo/#ubuntu-devel) heh - ^-- from releases.ubuntu.com apache log... someone's a little hopeful :)
(sladen/#ubuntu-devel) wonder if bochs would compile to 16-bit
(sladen/#ubuntu-devel) run your l33t 64-bit and 32-bit programs on your well-crappy processor
(mdz/#ubuntu-devel) elmo: still about?
(elmo/#ubuntu-devel) mdz: yes
<jdub> elmo: did you get the openoffice source package names from chris halls?
(elmo/#ubuntu-devel) jdub: uh?
(elmo/#ubuntu-devel) last mail I have WRT openoffice is the discussion about syncing/merging it
(elmo/#ubuntu-devel) nothing from Chris recently
<jdub> ok
<jdub> let's pick and choose ourselves then
<jdub> we need to pull in openoffice from experimental
<jdub> openoffice.org, openoffice.org-debian-files
(elmo/#ubuntu-devel) I thought the conclusion was they were modified and needed merged?
<jdub> can they go through mom?
(elmo/#ubuntu-devel) I dunno, I think mom only looks at unstable by default - we'd have to ask keybuk to special case them
<doko> jdub: I already did the merging, please wait until Rene did merge the latest 1.1.2 diffs to the 1.1.3 branch,
<jdub> doko: ahr cool, can you track that please?
<doko> jdub: will do.
<jdub> thanks
* jdub wobbles with OOo 1.1.3 excitement ;-)
* robertj fiddles with Update-Manager
<jdub> which rocks harder, dput or dupload?
* pasc uses ncftp
(chrisa/#ubuntu-devel) infinity got me to use dput and I haven't switched
(chrisa/#ubuntu-devel) Though I seem to have a config for each in ~, now I'm confused
<jdub> pasc: ncftp? are you french or something?
(pasc/#ubuntu-devel) heh
* chrisa uses ncftp
(elmo/#ubuntu-devel) I use lftp :-P
(chrisa/#ubuntu-devel) People keep telling me to use lftp instead of ncftp
<jdub> lftp is the healthy choice
(chrisa/#ubuntu-devel) Actually, s/People/infinity/. He just doesn't like my software selection in general
(mdz/#ubuntu-devel) jdub: dput
(mdz/#ubuntu-devel) chrisa: lftp does everything I ever liked about ncftp and more
(mdz/#ubuntu-devel) and it's free
* lamont returns
(lamont/#ubuntu-devel) spongebob squarepants is, um, interesting.
(lamont/#ubuntu-devel) and Kamion is almost certainly asleep, yes?
<jdub> yo mdz 
<jdub> mdz: good break?
(lamont/#ubuntu-devel) doko: Running /build/buildd/gcc-3.4-3.4.3/src/libjava/testsuite/libjava.lang/lang.exp ...
(lamont/#ubuntu-devel) FAIL: StringBuffer_overflow -O3 execution - bytecode->native test
(lamont/#ubuntu-devel) just byutw
(lamont/#ubuntu-devel) btw
(mdz/#ubuntu-devel) jdub: fabulous
* lamont curses at zsh's read test
(lamont/#ubuntu-devel) doko: sid gcc-3.4 builds on hoary/ia64
(mdz/#ubuntu-devel) jdub: here?
<jdub> yeah
(mdz/#ubuntu-devel) jdub: I need you to fix the permissions on the seed archive
(mdz/#ubuntu-devel) jdub: patch-24/++revision-lock
(mdz/#ubuntu-devel) I think needs to be group-writable
(mdz/#ubuntu-devel) I'm getting
(mdz/#ubuntu-devel) arch_commit: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))
<jdub> hrm
<jdub> change all files to group writable and world readable?
<jdub> well, i've done that
(mdz/#ubuntu-devel) gah
(mdz/#ubuntu-devel) jdub: then you committed a new revision, and I have the same problem
(mdz/#ubuntu-devel) jdub: is your umask broken?
(mdz/#ubuntu-devel) jdub: in the other archives, ++revision-lock shows up group-writable by default
<jdub> umask == 0022
<spotter> anyone else having issues w/ gnomevfs updates?
<spotter> can't mount smb shares anymore via gnome (still works fine w/ smbmount)
(mdz/#ubuntu-devel) jdub: should be 002
(mdz/#ubuntu-devel) jdub: can you fix patch-25 so that I can commit my pending changes?
<jdub> can't i just check in again?
<jdub> heh
<jdub> try now
<jdub> (you can commit nothing)
<jdub> ooh, crashing nautilus
<jdub> Program received signal SIGSEGV, Segmentation fault.
<jdub> [Switching to Thread -1226321792 (LWP 13937)] 
<jdub> 0xb76cc5ff in _gnome_vfs_drive_from_corba () from /usr/lib/libgnomevfs-2.so.0
<jdub> 
<spotter> gnomevfs is screwed up in more ways than one
(lamont/#ubuntu-devel) cd ../../../Src/Modules && autoconf pcre.configure.ac >pcre.configure
* lamont kicks zsh
(mdz/#ubuntu-devel) jdub: arch_commit: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))
(lamont/#ubuntu-devel) AM_MAINTAINER_MODE won't do much if the Makefile explicitly invokes autoconf, will it?
(mdz/#ubuntu-devel) mdz@chinstrap:/home/warthogs/archives/ubuntu-devel@lists.ubuntu.com/seeds/seeds--hoary/seeds--hoary--0 $ ls -l patch-26/++revision-lock/
(mdz/#ubuntu-devel) total 4
(mdz/#ubuntu-devel) drwxr-sr-x    2 jdub     warthogs     4096 Nov 23 02:53 +contents
<jdub> ^ to fix the above gnomevfs upgrade issue, just kill gnome-vfs-daemon after upgrading
(mdz/#ubuntu-devel) lamont: AM_MAINTAINER_MODE will suppress the autoconf-invoking rules which are placed in Makefile.in by automake
<jdub> mdz: ... how am i going to fix that? :|
(mdz/#ubuntu-devel) jdub: chmod -R g+w /home/warthogs/archives/ubuntu-devel@lists.ubuntu.com/seeds/seeds--hoary/seeds--hoary--0/patch-26/++revision-lock/
* jdub thought this is what we all laughed at svn about.
(lamont/#ubuntu-devel) mdz: ah, ok
<jdub> ber, okay
<jdub> that's cheating :)
(mdz/#ubuntu-devel) and then fix your umask
(lamont/#ubuntu-devel) mount -t msdos -o loop=/dev/loop5 bootdiagnostic.b /tmp/liloboot
(lamont/#ubuntu-devel) mount: only root can do that
(lamont/#ubuntu-devel) lilo unhappy. :-(
<jdub> mdz: my umask is 0002 on chinstrap
(lamont/#ubuntu-devel) lilo is main?
(lamont/#ubuntu-devel) how strange...
(mdz/#ubuntu-devel) jdub: please chmod g+w /home/warthogs/archives/ubuntu-devel@lists.ubuntu.com/seeds/seeds--hoary/seeds--hoary--0/patch-{25,26}
(mdz/#ubuntu-devel) ahh, finally
(mdz/#ubuntu-devel) * committed ubuntu-devel@lists.ubuntu.com/seeds--hoary--0--patch-27
<jdub> so mcuh bong
<jdub> let's get lifeless to fix that
(mdz/#ubuntu-devel) welcome to arch-land
(lamont/#ubuntu-devel) Mithrandir: around?
* lamont doubts it...
<jdub> elmo: can you do a sync of samba 3.0.8-2 from unstable?
<jdub> elmo: requires a merge
<jdub> (need it to fix a gnome-vfs issue)
* spotter waits patiently for the fix
<spotter> :)
(lamont/#ubuntu-devel) jdub: if it requires a merge.....
(lamont/#ubuntu-devel) why not just upload?
(whiprush/#ubuntu-devel) hey jdub, I'm a month or two late, but I'm close to a draft for a review for this weekend if you still want to review my work.
(whiprush/#ubuntu-devel) I'm shooting for a monday morning post US thanksgiving review on ars if things go well.
<jdub> cool
<jdub> fire away
<jdub> lamont: thought our merge infrastructure did smarty-pants things
(whiprush/#ubuntu-devel) sorry so late, moved an apartment or two, changed a job, and inbetween laptops. But we've got some good feedback over the past few months. Should turn out well methinks.
<jdub> lamont: i could upload, but it should merge cleanly
<jdub> whiprush: fun times :-)
<jdub> whiprush: don't mind a bit of momentum press :-)
(lamont/#ubuntu-devel) jdub: either the ongoing-merge/samba files are correct (and someone just needs to sign/upload), or there is merge work to do...
<jdub> yay for uploading with dput
(lamont/#ubuntu-devel) yes
(lamont/#ubuntu-devel) although I had it scripted the other way..
(lamont/#ubuntu-devel) script just got a lot shorter
(lamont/#ubuntu-devel) jdub: or more to the point, what would you like me to do with samba?
(lamont/#ubuntu-devel) :-)
<jdub> we need 3.0.8-2 from sid
(lamont/#ubuntu-devel) or rather, 3.0.8-2ubuntu1?
<jdub> yeah ;)
(lamont/#ubuntu-devel) ok.  I'll do that shortly
<jdub> that will let gnome-vfs2 go through
<shaya> jdub: this is my problem? with smb gnome-vfs?
<jdub> thanks
<jdub> shaya: dunno, there are two problems
<jdub> 1. smb won't work at all
<jdub> 2. everything using gnome-vfs will crash until you killall gnome-vfs-daemon
<shaya> jdub: later doesn't seem to be my issue, as I just booted up my laptop
<jdub> yeah
(lamont/#ubuntu-devel) jdub: verifying that it at least builds before I upload.
(lamont/#ubuntu-devel) jdub: uploaded.
(lamont/#ubuntu-devel) hrm.
(lamont/#ubuntu-devel) yeah. uploaded
<jdub> rocking, thanks :)
(mdz/#ubuntu-devel) lamont: the output of MOM includes the appropriate dpkg-genchanges flag needed to get a useful .changes file
(lamont/#ubuntu-devel) mdz: kewl
* netjoined: irc.freenode.net -> tolkien.freenode.net
(lamont/#ubuntu-devel) fabbione: you really here?
<jdub> mdz, lamont: is ia64 for hoary supported, or just being built for the time being?
(lamont/#ubuntu-devel) jdub: I think it's a relatively committed feature-goal
(lamont/#ubuntu-devel) but it still lacks a few simple things like kernel packages and d-i.. :-)
<shaya> who runs ia64 in real life as a desktop?
<jdub> shaya: ubuntu isn't desktop-only.
(lamont/#ubuntu-devel) shaya: the gang that is committed to making ia64 work for hoary, of course.
(lamont/#ubuntu-devel) I think tomorrow is 'fix postfix' day.
(lamont/#ubuntu-devel) there are a few hoary bugs to kill
* aj reads planet debian and thinks "mako - rhymes with whacko" :)
(tseng/#ubuntu-devel) no, it rhymes with wako
(tseng/#ubuntu-devel) which is worse?
(tseng/#ubuntu-devel) its waco, my bad.
(lamont/#ubuntu-devel) aj: you talking about the baby comment?
(aj/#ubuntu-devel) lamont: that's more the straw that broke the camel's sanity
(lamont/#ubuntu-devel) aj: heh
(lamont/#ubuntu-devel) aj: mako's cool
(aj/#ubuntu-devel) cool, but craaaazy
(lamont/#ubuntu-devel) aj: you know, I'm not sure _he'd_ refute that... :-)
(aj/#ubuntu-devel) i bet he'd focus on the cool part if he did
<fabbione> morning guys
<fabbione> lamont: hey man
<fabbione> lamont: i finished phase0 here :-)
<fabbione> and i can bootstrap a chroot without any problem
<mako> aj: actually.. i think getting to vent that stuff on a blog stabalizes me a little :)
(lamont/#ubuntu-devel) fabbione: trying to discern from previous conversations... xlibs-dev* is evil now?
(lamont/#ubuntu-devel) evening mako
<fabbione> lamont: what do you mean?
<fabbione> hey mako
<mako> fabbione, lamont hey there :)
<fabbione> (i am still at the first cup of coffee)
(lamont/#ubuntu-devel) fabbione: packages should not build-dep xlibs-dev or xlibs-static-dev or ..., yes?
<mako> fabbione: i'm about to crash :)
<fabbione> lamont: they shouldn't build-dep on xlibs-dev
* lamont is close to crash time as well
<fabbione> lamont: but they can on xlibs-static-dev
<mako> aj:  there was a funny comment on my blog that was like "dude, i don't get it at all. are you a philosophy major or just nuts"
(lamont/#ubuntu-devel) fabbione: ok.
<fabbione> lamont: and talking about it, we need to test a full rebuild of main
<fabbione> lamont: because our buildd didn't catch some FTBFS
(lamont/#ubuntu-devel) fabbione: sigh
<mako> "actually. i am an award winning philosopher and this is seriously deep shit"
<fabbione> lamont: and it might be a good idea to do it in parallel
<fabbione> lamont: with a faster machine than my sparc
(lamont/#ubuntu-devel) fabbione: yeah - we have a few ftbfs right now
<fabbione> lamont: (that's how i got some of them yesterday)
<fabbione> lamont: i have 12 of them that are general
(lamont/#ubuntu-devel) heimdal and nas are the 2 in the current logs
<fabbione> emacs enigmail libgd2-perl libgd2-noxpm-perl screen wvstreams and zsh
<fabbione> these are common with debian i think
<fabbione> the other few are strictly sparc related
(lamont/#ubuntu-devel) ah, you're claiming libgd-gd2-noxpm-perl and libgd-gd2-perl?? cool
<fabbione> remember i am checking only main
<fabbione> lamont: they are just broken from debian too
(lamont/#ubuntu-devel) would just about need to be amd64 doing the build, I fear.
(lamont/#ubuntu-devel) fabbione: ah, ok
<fabbione> lamont: no, i am not claiming any of these
<fabbione> what i mean is that this pkgs fails in ubuntu as they fail in debiqan
<fabbione> debian
(lamont/#ubuntu-devel) I mean "claiming that they are X fallout", not claiming them to fix.
(lamont/#ubuntu-devel) ah, ok
<fabbione> no no.. all the X fallout that i could spot have been fixed
<fabbione> but it would be wise to test a rebuild of main
<fabbione> to be sure i didn't miss any
<fabbione> and amd64 is the best arch to do so
(lamont/#ubuntu-devel) fabbione: heimdal and nas remain
<fabbione> are they in main?
(lamont/#ubuntu-devel) yes
<fabbione> ok.
<fabbione> i will fix them
(lamont/#ubuntu-devel) both can't find X11/Xauth.h
<fabbione> ok that's easy
<fabbione> i will take care of them
<fabbione> just go and crash in the bed :-)
(lamont/#ubuntu-devel) fabbione: thanks
* lamont decides to imitate a pumpkin
<fabbione> lamont: welcome :-)
<mako> yum
<fabbione> lamont: heimdal and nas fixed
<shaya> isn't macco the place that does collision repair?
<shaya> or is that aamco?
* shaya always gets confused
<jdub> lamont: is there any work going on to replace cyrus-sasl? (or, at least in postfix?)
<jdub> lamont: hrm, we should find out what postfix patches apple have done
<shaya> jdub: are the gnomevfs stuff I'm downloading now, good?
<jdub> probably
<jdub> samba's probably upgrading too
<shaya> yes
<jdub> if you're getting both, you'll be fine
<Lathiat> Anyone know how to get gdb to ignore a SIGTRAP? it SIGTRAPs on __linuxthreads_create_event() and when i step it kills the program
<shaya> yay
<shaya> it works
<pitti> Morning, folks!
<fabbione> damn
* fabbione prepares another nas upload
<fabbione> hey pitti
<doko> morning all!
<fabbione> morning doko
(bob2/#ubuntu-devel) 'morning
(Mithrandir/#ubuntu-devel) lamont: pong
<fabbione> Mithrandir: he went to sleep a while ago
(Mithrandir/#ubuntu-devel) oh well, he'll be up at some point.
<fabbione> Mithrandir: did you have any time to look at the kernel?
(Mithrandir/#ubuntu-devel) not yet.  Project turn-in deadline friday.
<fabbione> no problem :-)
<fabbione> just curious
<fabbione> i am starting phase1 today
<fabbione> we are in a pretty good shape
<fabbione> only 11 FTBFS
<fabbione> 2 kernel related
<fabbione> 1 d-i
<fabbione> and the others are shared with Debian/Ubuntu
(mdz/#ubuntu-devel) pitti: awake?
<pitti> mdz: oh yes
<pitti> mdz: welcome back! Had a fine holiday?
<fabbione> hey mdz!
(mdz/#ubuntu-devel) good morning
* mdz needs to sleep soon
<fabbione> mdz: good night :-)
* fabbione runs another hoary install
<fabbione> hey guys
<mvo_> hi fabbione 
<pitti> Hi mvo_ 
<mvo_> hi pitti 
<daniels> ironwolf: DUDE
<daniels> ironwolf: please try changing DefaultDepth 24, to DefaultDepth 16
<ironwolf> daniels: DefaultDepth ?
<ironwolf> daniels: dude!
<daniels> ironwolf: in /etc/X11/XF86Config-4
<daniels> ironwolf: dude?
<ironwolf> daniels: don't you mean xorg.conf?
<daniels> ironwolf: oh, using xorg -- yeah
<ironwolf> daniels: DefaultDepth and Driver to s3? s3v? ???
<daniels> ironwolf: DefaultDepth 16, Driver s3v
<ironwolf> daniels: I'll let you know tomorrow once he wakes up. :)
<daniels> rad
<ironwolf> daniels: dude...
<daniels> ironwolf: sweet?
<daniels> bob2: about as well as your x40
<fabbione> ciao enrico 
<enrico> fabbione: ciao!
<seb128> morning
<fabbione> hey seb128 
<fabbione> seb128: when do you think you can do that patch to gdm for me?
<lupus_> daniels, how come libxdamage isn't installed by default?
<daniels> lupus_: because nothing uses it?
<lupus_> libxdamage1 that is
<daniels> having a library that does nothing around is pretty pointless
<lupus_> ic :)
<seb128> fabbione: can you remember what the patch should do ? 
<fabbione> seb128: sure. Accept an option in the configfile to disable XKeepCrashing
<fabbione> seb128: both the script and the internal handler for it
<seb128> ok, noted on my loooooong todolist
<fabbione> ok :-)
<fabbione> seb128: if you think it can take too long, i can give it a shot
<fabbione> but i had rather prefer someone that knows gnome all the way trough to do it
<seb128> should not be really long, I'll give a try soon
<fabbione> great!
<seb128> jdub: I'm not sure than bumping the requirement on libsmbclient was needed (we have decided to not bump it on the debian side)
<daniels> rburton: dude!
<rburton> yo daniels 
<amu> hmm who is our kernel god ? 
(Kamion/#ubuntu-devel) Herbert Xu
<seb128> hey rburton 
<rburton> hi seb128 
<seb128> & amu & Kamion & daniels 
<lupus_> damn composite is slow with nvidia drivers
<lupus_> does it only work with DRI?
<rburton> lupus_: turned on render acceleration?
<lupus_> got nvidia-drivers installed
<rburton> and did you turn on render acceleration?
<daniels> Kamion: 'morning
<daniels> seb128: hey dude
<lupus_> if that isn't the default then no
<daniels> lupus_: you need Option "RenderAccel" with the nVidia drivers, I think
<daniels> (yay nVidia!)
<rburton> (beta feature, may break, etc)
<rburton> (works for me)
<rburton> daniels: ship Xephyr in ubuntu and i'd love you
<daniels> rburton: that's otaylor's crack, yah?
<rburton> nah
<rburton> it's mallum's crack
<lupus_> Option "RenderAccel" "1"
<lupus_> like that?
<rburton> lupus_: i think so, but check the nvidia readme, it documents all the options
<daniels> oh right, fb-as-root-window
<daniels> s/fb/another-window/
<lupus_> brb :)
<rburton> daniels: xnest re-implemented in kdrive. it's rocking.
<daniels> rburton: dunno, we'd need to fake out the presence of pkg-config'ed xlibs
<daniels> consider it on my todo, below otaylor's crack
<rburton> wow, that unlikely :)
<daniels> heh
<daniels> It turns out that this is a Hard Problem. (Because Xlib i18n is screwed
<daniels> up in ways that I can't describe in a family bugzilla report).
* daniels cheers otaylor on.
<fabbione> can we kindly move support issues to #ubuntu ?
<fabbione> that is probably more appropriate than here
<daniels> fabbione: i presume you mean nvidia?
<fabbione> clearly
<daniels> fabbione: btw, I've been submitting stuff upstream
<fabbione> yeah.. i read some irc logs :-)
<daniels> all the XKB stuff has gone upstream, all our ATI patches, a lot of the other-arch stuff
<daniels> all in all, if they incorporate the stuff I submitted plus linuxwacom.sf.net, our 6.8.2 patchset should be 20,000 lines
<daniels> down from 50,000 in 6.8.1, and >300,000 in 4.3.0 :)
<daniels> (that's with linuxwacom.sf.net disappearing, 6.8.x branch disappearing, the patch from patches/ disappearing, and all the patches I submitted disappearing)
<fabbione> ehhehe
<fabbione> not too bad
<herzi> seb128: there are still build dependencies missing, so i reopened the bug, let me just add all the info i collect until the package got build so i can attach a patch
<seb128> herzi: ok, sorry, I've closed it after getting the "g++ is missing"
<fabbione> herzi: did you install build-essential?
<fabbione> herzi: and then apt-get build-dep gdm ?
<seb128> herzi:   /usr/bin/sudo /usr/bin/apt-get --purge $CHROOT_OPTIONS -q -y install libpam0g-dev libgnomeui-dev librsvg2-dev libglade2-dev libwrap0-dev debhelper gettext intltool scrollkeeper libselinux1-dev libattr1-dev libxt-dev libxau-dev libxkbfile-dev
<seb128> oups
<seb128> herzi:  libxau-dev libxkbfile-dev are already in the build-deps
<herzi> seb128: not in the one that I got with apt-get source gdm
<seb128> warty or hoary ?
<seb128> which version did you get ?
<herzi> which is the 2.6.0.3-1ubuntu20
<herzi> hoary
<seb128> 2.6.0.4-1ubuntu3 is the current version
<seb128> your deb-src source is not an hoary one
<herzi> oh, i sourced warty
<herzi> sry
<seb128> warty has xfree86 not xorg
<seb128> so the build-dep are adapted to xfree86
<herzi> yeah, i though i has replaced every "warty" by "hoary" but obviosly i did that on the notebook, not on the desktop, so i left the commented one...
<seb128> ok
<herzi> so i can go back to #4037
<pitti> Hi sivang 
<sivang> pitti : Hi, what's up?
<pitti> sivang: currently PostgreSQL again
<sivang> pitti : ah, debian lovin' ..;-)
<pitti> sivang: well, it's Ubuntu supported, too
<pitti> sivang: and it got a major bug
<zul> whats wrong with postgresql?
<pitti> zul: http://bugs.debian.org/282502
<pitti> zul: I already fixed some other (easy) bugs
<pitti> zul: but I cannot reproduce this one
<pitti> zul: I currently prepare a debug version for joeyh to test
<zul> ah...
<herzi> seb128: can you take a quick look at #4037?
<seb128> herzi: I've already read it, it's on my list, but I've done anything to turn this build off, dunno for the moment
<seb128> herzi: due to a missing build-dep ?
<herzi> yep
<herzi> libxdmcp-dev
<herzi> so it was autodetecting whether to enable xdmcp or not
<seb128> herzi: thanks, I'll upload a fixed package in a few min
<herzi> you might want to add --with-xdmcp to debian/rules
<herzi> so it will fail definitely without
<seb128> ok
<seb128> herzi: fixed package uploaded, it should be available soon (time to get it built/in the archive)
<seb128> thanks
<herzi> np
* daniels kicks seb128.
<daniels> seb128: ping on #1506
<seb128> daniels: dude, I've 300 bugs on my list 
<daniels> this one's been in your court for like a month :)
<seb128> daniels: I don't know anything about xkb, I've no opinion on this
<daniels> would you be happy to try the patch and see if we break anything?
<daniels> it's not doing anyone much good bitrotting
<seb128> I'm happy to include the patch if you want yes
<seb128> is "right tab" different of "alt gr" ?
<daniels> yes
<daniels> us-layout keyboards don't have an altgr, they just have two alt keys
<seb128> I don't have a "right tab"
<seb128> hard to test
<daniels> i can test it for you if you like
<seb128> yes please
<daniels> er, 'right alt', not 'right tab'
<daniels> but my right alt is bound to compose anyway ;)
<seb128> oups, yes
* Keybuk binds his right control to compose
<seb128> my window's key is bound to compose :)
<Keybuk> seb128: I use that for Metacity things
<Keybuk> I couldn't work out whether I ever use the right-shift key, but for safety I decided to leave it
<Keybuk> I really never use the right-control; so it was safe to rebind :p
<seb128> I don't use right-control neither :)
<rburton> from the state of my keyboard, i can say i've never actually pressed right control
<seb128> hum, why nautilus-cd-burner is not updated in the archive ? Who is supposed to sign the builds ? :)
<daniels> i've pressed space a lot
<daniels> just ask Keybuk
<seb128> lamont: ?
<rburton> daniels: i see i press space with my right thumb
<daniels> rburton: yeah, me too
<daniels> in the same spot
<rburton> this is kinda fun
<rburton> i press 8 more than the other numbers for some reason. and Z and Q are the only letters without wear
* rburton stops this now
<daniels> heh
<pitti> seb128: according to the gnome-vfs2 changelog you now use the hal patch, right?
<pitti> seb128: did you notice _any_ difference? I didn't
<rburton> pitti: you should be able to tell in the nautilus "computer" window
<pitti> rburton: how?
<pitti> rburton: the icons are all the same
<pitti> rburton: and the behaviour of the mounted drive applets did not change
<rburton> hm, maybe that patch didn't get in
<rburton> is it really linking to hal ;)
(sjoerd/#ubuntu-devel) the changing of the icons depends on the way you compile hal support
<pitti> rburton: it definitively is in the source package
<seb128> pitti: me neither
<seb128> jamesh: ping ?
<pitti> seb128: I hoped it would resolve the "umount entire drive instead of partitions" issue
<pitti> seb128: and other bugs
<seb128> pitti: have you read #3666 ?
<pitti> seb128: indeed, that's the bug I was aiming at
<pitti> seb128: IIRC jamesh said something about resolving this with the hal patch
<seb128> Trying patch debian/patches/06_hal.patch at level 0...success.
<seb128> in the build log
<pitti> seb128: I saw that the patch is in, but I do not notice it
<seb128> pitti: arg
<pitti> seb128: "notice" == behaviour did not change
<seb128> pitti: --with-hal missing in the configure options
<pitti> seb128: ah
<seb128> I'm rebuilding it
<pitti> seb128: I'm currnently debugging another g-vfs issue, but it could be solved with the hal patch
<pitti> seb128: thanks
<seb128> np
(elmo/#ubuntu-devel) seb128: is libzvt not used anymore?
(elmo/#ubuntu-devel) fabbione: going to demote: xdmx, xfree86-common, xserver-xfree86, xserver-xfree86-dbg ... ok?
<herzi> elmo: it's supposed to be deprecated by vte
<fabbione> elmo: no
<fabbione> elmo: only xserver-xfree86 and xserver-xfree86-dbg
<seb128> elmo: why ?
(elmo/#ubuntu-devel) fabbione: please add the other two to the appropriate seed then
<herzi> seb128: i might have one more for gnomevfs, but i'm compiling to check now
(elmo/#ubuntu-devel) seb128: because nothing seems to depend on it anymore, so my scripts want to demote it to universe
<seb128> herzi: what kind of change ?
<fabbione> elmo: i already filed a bug on daniels :-))))
<fabbione> elmo: he is our Xorg bitch^Wguy now ;)
<daniels> yeah, I've got the universe stuff on my things to do list
<seb128> elmo: oh, it should be fine in universe. I'll check to be sure and let you know
(elmo/#ubuntu-devel) seb128: thanks
(elmo/#ubuntu-devel) fabbione/daniels: ok
<fabbione> elmo, daniels: nothing will never ever depend on Xdmx
<fabbione> elmo: it's a server :-)
<fabbione> daniels: i don't mind Xdmx in universe, up to you
<herzi> seb128: a missing module
<seb128> herzi: smb ?
<herzi> tar
(elmo/#ubuntu-devel) is libgnome-perl really meant to be in supported?
<herzi> guess it's only missing in some file list
<seb128> herzi: ok, it has been removed on purpose
<fabbione> elmo: for xfree86 you can demote also the source to universe
<fabbione> elmo: the last upload was done to generate only the 2 servers and "kill" the other packages
<herzi> seb128: can you tell me which purpose?
<seb128> gnome-vfs2 (2.6.1.1-2) experimental; urgency=low
<seb128>   * debian/rules:
<seb128>     + Remove support for cdda, extfs, nntp, tar and vfs-pipe methods,
<seb128>       all broken. Accidentally fixes crash when trying tar:// URIs
<seb128>       (closes: #157322).
* herzi would love to be able to use file:///foo.tar.bz2#bzip2#tar.
<seb128> herzi: have you already used it, does it work fine ?
<herzi> will check it
<seb128> it used to not work fine
<seb128> and nobody has fixed it afaik
<herzi> obviously we need a better infrastructure to split uri-modules (sftp, http, etc.) from chain-modules (tar, bzip2, gzip, etc.)
<herzi> so noone can try tar:///
<herzi> will write to gnome-vfs list
<seb128> ok
<seb128> perhaps gnome-vfs2 should be splitted
<seb128> (ueah, it already used to be splitted)
(elmo/#ubuntu-devel) do we care about the gnome frontend to debconf?
(Kamion/#ubuntu-devel) elmo: yeah, synaptic invokes it
(Kamion/#ubuntu-devel) (I believe)
<mvo_> yes
(elmo/#ubuntu-devel) meh, ok
<pitti> seb128: I recompiled gvfs with --with-hal, but still don't notice any difference :-(
<daniels> elmo: my 'meh' filter just exploded
* fabbione imagines elmo with a big vacuumclenear on top of archive.u.c
<herzi> seb128: i've got something to tell you in private (no need to flood the chan)
<herzi> is that okay?
<seb128> pitti: it doesn't build here
<seb128> herzi: sure
<pitti> seb128: oops, did fine for me. Odd...
<seb128> gnome-vfs-hal-mounts.c:42:28: libhal-storage.h: No such file or directory
<seb128> gnome-vfs-hal-mounts.c:53: error: parse error before "HalStoragePolicy"
<pitti> ah
<pitti> seb128: there's probably a missing build-dep
<pitti> seb128: libhal-storage-dev
<seb128> yep
<seb128> the configure is broken so :p
<pitti> seb128: the hal patch probably doesn't patch configure.ac :)
<seb128> in fact it does, but since we don't run the auto* ...
<pitti> ah
<seb128> grumpf
<seb128> /home/seb128/boulot/paquets/vfs/gnome-vfs2-2.8.3/libgnomevfs/gnome-vfs-hal-mounts.c:292: undefined reference to `hal_storage_policy_new'
<seb128> oups
<seb128> libgnomevfs/gnome-vfs-hal-mounts.c:293: undefined reference to `hal_storage_policy_set_icon_mapping'
<seb128> pitti: you have just added the --enable-hal ?
<pitti> seb128: oh, I did --with-hal
<seb128> ok, so you don't have it
<pitti> seb128: thanks, I try again
<pitti> seb128: gosh, this requires another full recompile...
<seb128> let me know if you get it building correctly
<seb128> I'll get something to eat, I'm starving
<pitti> seb128: please do that
<pitti> seb128: I try to build it in the meantime
<lupus_> networkmanager seems to be working noz
<lupus_> after last hal upgrade
<pitti> lupus_: sounds good :)
<pitti> sjoerd: still here?
(thom/#ubuntu-devel) i hate transatlantic flights
(sjoerd/#ubuntu-devel) pitti: yeah
<pitti> sjoerd: pmount itself works fine if the mount point is already present
<pitti> sjoerd: so I assume you mean pmount-hal?
(sjoerd/#ubuntu-devel) if that's what does the choosing stuff
<pitti> yes
(sjoerd/#ubuntu-devel) pitti: didn't know where exactly you implemented it :)
<pitti> sjoerd: hmm, now I have to implement the mount point checking again in shell...
(sjoerd/#ubuntu-devel) why did you implement it in pmount-hal and not in pmount itself ?
(sjoerd/#ubuntu-devel) it does make sense for pmount too or ?
<pitti> sjoerd: because pmount itself does not _choose_ a mountpoint
<pitti> sjoerd: you either give it a label or not
<pitti> sjoerd: pmount will accept valid mount points and reject invalid ones
(sjoerd/#ubuntu-devel) ah
<pitti> sjoerd: choosing the mount point name is done by looking at the HAL properties
(sjoerd/#ubuntu-devel) i thought you changed that, that the label was ``just'' a suggestion
<pitti> sjoerd: it is
<pitti> sjoerd: but only if pmount falls back to mount
(sjoerd/#ubuntu-devel) ah
<pitti> sjoerd: it is still used if pmount does not fall back 
(sjoerd/#ubuntu-devel) why not also regard it as a suggestion when not falling back ?
<pitti> sjoerd: because then you would end up mounting it as /media/sda1 again
<pitti> I regard guessing new mount points in pmount proper bad
(sjoerd/#ubuntu-devel) not necessarily
<pitti> pmount should be predictable
(sjoerd/#ubuntu-devel) you, but with the falling back to fstab it's already not predictable
(sjoerd/#ubuntu-devel) s/you/yeah/
(sjoerd/#ubuntu-devel) if you want to implement the mounpoint checking in pmount-hal too, that's just fine with me :)
(sjoerd/#ubuntu-devel) just seems cleaner and easier to do it in pmount itself
<pitti> sjoerd: you mean the mount point enumeration?
<pitti> sjoerd: hmm, I'm not sure about that
(sjoerd/#ubuntu-devel) yes
(sjoerd/#ubuntu-devel) when not doing the suggested one, at least take the suggestion into account seems nice
(sjoerd/#ubuntu-devel) pmount already isn't predictable anymore, because you fall back to mount sometimes.. so
(sjoerd/#ubuntu-devel) pitti: just think about it and tell why it's a bad idea sometime later :)
* sjoerd goes on reading school stuff
<pitti> sjoerd: the mount point behaviour was predictable until I changed it to be ignored for mount fallback
<pitti> sjoerd: remember who wanted that feature? :)
* sjoerd whistles 
<pitti> sjoerd: btw, what was this good for in the first place?
(sjoerd/#ubuntu-devel) you agreed to it btw :)
<pitti> sjoerd: of course I did
<pitti> sjoerd: but my mind is a sieve
(sjoerd/#ubuntu-devel) because if that feature isn't there, pmount-hal or g-v-m must search the device in fstab
(sjoerd/#ubuntu-devel) and if it's in there not pass a label to pmount
<pitti> ah
* pitti remembers
(sjoerd/#ubuntu-devel) my suggestion was to just change the label to a ``suggestion'', which fits in this model
(sjoerd/#ubuntu-devel) for some reason i always remember the stupid details ;)
<pitti> nice to have somebody who does
<herzi> seb128: thanks for the gdm fix, no I can happily log into my server :)
<seb128> you're welcome ;-)
<seb128> pitti: ok, runnin the autogen.sh fixes the issue
<pitti> seb128: the problem is that LIBGNOMEVFSDAEMON_LIBS does not include -lhal-storage
<pitti> seb128: oh, does it?
<seb128> yes
<pitti> seb128: I just tried autoreconf, which fails
<pitti> nice
<fabbione> this is interesting
<fabbione> daniels: you around?
<daniels> sup
<fabbione> daniels: i binded an xserver kbd and mouse to /dev/null
<fabbione> the DPMS turned off the screen
<daniels> yeah
<fabbione> all of a sudden it woke up again
<daniels> er yeah, that's probably the bug I've fixed
<fabbione> like if /dev/null was pushing data
<fabbione> but not the real server with real kbd and mouse
(thom/#ubuntu-devel) daniels: have you fixed the dpms randomly blanking thing yet?
(thom/#ubuntu-devel) and if not, why not?
<fabbione> hey thom
<fabbione> aren't you supposed to be in holidays?
(thom/#ubuntu-devel) hello
(thom/#ubuntu-devel) got back an hour ago
(Mithrandir/#ubuntu-devel) hi thom
<fabbione> thom: did you have fun?
<pitti> Welcome back, thom
(thom/#ubuntu-devel) fabbione: lots, thanks
(bob2/#ubuntu-devel) yo thom
(thom/#ubuntu-devel) and i didn't lose all my money in vegas, either
<daniels> thom!
<fabbione> thom: ehehhe
<daniels> thom: already fixed
<fabbione> thom: isn't time to fix thunderbird?
<seb128> pitti: ok, much better :)
(thom/#ubuntu-devel) fabbione: eh?
<fabbione> thom: you are back for an entire hour and still no uploads :-)
<pitti> seb128: does it actually make a difference now?
(thom/#ubuntu-devel) fabbione: it's a mozilla product, it's broken inherently
<fabbione> thom: thunderbird keeps crashing on me
<seb128> pitti: with the patch I've the drive capacity and better names
<fabbione> thom: ehehhe
(thom/#ubuntu-devel) fabbione: dude, i have 4500 messages in my inbox
<seb128> pitti: in computer:///
* Mithrandir whacks fabbione gently
<fabbione> thom: only?
(thom/#ubuntu-devel) fabbione: my INBOX. my mail is filtered
<pitti> seb128: any difference in the drive applet?
<fabbione> thom: dude.. take your time as usual :P
<pitti> seb128: can you eject entire devices now?
<fabbione> thom: just teasing you...
<seb128> pitti: I've not add time to test yet, I'll upload the package first
<seb128> s/add/had/
<pitti> seb128: fine, give it to us! :
* thom sticks his tongue out at fabi
(thom/#ubuntu-devel) o
<pitti> seb128: s/:/:)/
<pitti> Hi sabdfl, how are you
(thom/#ubuntu-devel) so what excitement have i missed? (if any ;P )
* fabbione grabs thom's tongue with the fingers and start pulling thom around :P
(bob2/#ubuntu-devel) thom: you missed scott cooking up a storm
<sabdfl> pitti: well thanks!
(bob2/#ubuntu-devel) that's been the most exciting thing all week
<daniels> thom: you missed a transfer of X maintainership
<fabbione> hey sabdfl 
<sabdfl> fabbione! 
<pitti> thom: and you might have missed X.org :)
<daniels> thom: and the discovery of a hotel that serves muffins for breakfast
(thom/#ubuntu-devel) pitti: no, i've got xorg
(thom/#ubuntu-devel) :-)
(bob2/#ubuntu-devel) man
(thom/#ubuntu-devel) daniels: did you firebomb it?
(bob2/#ubuntu-devel) that was the most awesome discovery ever
(thom/#ubuntu-devel) that is the only correct response for people claiming muffins are a breakfast product
<zul> gday
(bob2/#ubuntu-devel) they also serve cold ham as a breakfast product
<daniels> thom: i've already removed the HorizSync/VertRefresh stuff, fixed DPMS, pushed ~25,000 lines of patches upstream, grabbed many other fixes (including the patch for every Radeon problem, ever), and yeah
(bob2/#ubuntu-devel) that's far wronger
<pitti> thom: what's wrong with muffins for breakfast?
<daniels> thom: oh, I thought you meant X, not the K+K :)
<fabbione> daniels: removed what?
<daniels> fabbione: HorizSync/VertRefresh
(bob2/#ubuntu-devel) pitti: english people don't like breakfast foods that aren't fried and/or made of intestines
<fabbione> daniels: dude.. you are on pure crack
<daniels> fabbione: crack is shiny
(Mithrandir/#ubuntu-devel) daniels: so my radeon will now make coffee and run emacs?
<fabbione> daniels: it's not going to work
<daniels> fabbione: it so will -- just watch
<pitti> bob2: gar, English food... nevermind
<daniels> Mithrandir: no, I said it *fixed* problems, not created them
<fabbione> daniels: i will watch
<daniels> fabbione: (the problems we were having were from iBooks IIRC, and I have the patch to fix that from benh)
<daniels> if it's wrong, I will go back grovelling to you
<fabbione> but i also remember very well why we readded it
<Keybuk> bob2: the cold ham is for the europeans who bitch if they get served blood and burnt bits steeped in lard
<daniels> and the muffins are for people who resemble Simpsons characters
<Keybuk> which, as all Englishmen know, is what you need to start off your day
<fabbione> daniels: no they were a but more general.. anyway.. your call
<daniels> the croissants are a sweet deal though
<daniels> fabbione: we'll find out
(bob2/#ubuntu-devel) Keybuk: can't imagine why they complain about that!
* thom tickles Keybuk 
<fabbione> daniels: M   debian/patches/080_pci_isolate_device_feature.diff
<fabbione> is that just a rediff?
<daniels> yah
<daniels> it's -3 offset IIRC
<Keybuk> thom: good trip?
<fabbione>   * debian/patches/020_r128_remove_interrupt_handler.diff:
<fabbione> there is no 020.. it's 025
(thom/#ubuntu-devel) Keybuk: aye, danke
<daniels> pinhead: agh, thought I fixed that
<lifeless> mjg59: ping
<pinhead> grrrr
<pinhead> got kicked out by the server
<fabbione> daniels: please keep one blank line between changelog entries
<daniels> bah
<fabbione> that thing is unreadable
<daniels> i'm playing with changelog style to see how it works out
(Kamion/#ubuntu-devel) that's weird; udev seems to be looking for a device symlink corresponding to sysfs' /class/net/eth0, while it's blatantly obvious that there won't be one because it's a *network interface*
<Keybuk> Kamion: hmm?
<Keybuk> it should just check for a /sys/.../dev file and make that device
(Kamion/#ubuntu-devel) for a network interface? what device node would that be?
(Kamion/#ubuntu-devel) (it's wait_for_sysfs, anyway)
(Kamion/#ubuntu-devel) seems harmless though, I'm just watching all the logs in a paranoid way 'cos I'm sure there are things I've got wrong
<robtaylor> sabdfl: mdz: is there any particular reason that seb128 cant package 2.10 in the alioth svn repository? 
<seb128> robtaylor: I've not said I can't package 2.10 in the SVN, I'm free to do whatever I want in my non-working time
<sabdfl> robtaylor: yes, because it's work i'm funding for ubuntu, and needs to go out there first
<robtaylor> but surely packaing gnome for ubuntu and packaging gnoem for debian is 98% the same task??!
<robtaylor> sabdfl: but its open source. by upsxtreaming early you save money later by noot having to propagate patches
<robtaylor> later
<sabdfl> upstreaming?
<sabdfl> gnome is upstream
<robtaylor> sabdfl: upstream of ubuntu is debian
<rburton> robtaylor: i don't know about you, but the first thing i did when i upgraded my packages in debian was to take all of seb's patches
<robtaylor> rburton: qwell exatcly
<robtaylor> why have a silly extra step?
<rburton> as a lot of those patches were totally useless in debian when they were created
<sabdfl> robtaylor: there's always an extra mental cost to doing something in two places, which is why i ask our guys to do the work in ubuntu and publish all the patches immediately
<sabdfl> upstream can take them, but i'm not going to do the work on both sides
<robtaylor> sabdfl: i'm not suggesting do it in 23 places
<robtaylor> sabdfl: thats what happend right noe
<robtaylor> sabdfl: i'm saying make it happen in *one* place
<sabdfl> sure. join seb ;-)
<robtaylor> sabdfl: that waht i'm asking to do
<sabdfl> robtaylor: we're bring up a revision control system, would that make it easier for you to collaborate with seb?
<robtaylor> sabdfl: as seb128 does all this work in a separate tree to the rest of us, who are also doing the same task...,.
<robtaylor> sabdfl: ideally the gnome-team and ubuntu shoudl be working in the same repo. we're doing the same task
<sabdfl> i'm happy for you guys to work with seb, in our revision control system
<sabdfl> the system we are building should make it easy for that collaboration to work well
<robtaylor> this is what i'm pushing for here...
<robtaylor> i sdo sasy that alreasy  t
(Kamion/#ubuntu-devel) (I thought part of the point was that it didn't have to be *our* revision control system ... :-) )
<azeem> robtaylor: you should push for that (using Canonical's vcs) at the other side, i.e. Debian
<robtaylor> if it works better..
<robtaylor> the isxsue i see *right now* is taht seb128 is pacaking 2.9 on his own
<robtaylor> when there are other people also intested in debian 2.9 pacakges
<robtaylor> (which of course would be pretty damm similar to ubuntu 2.9 packages)
<seb128> they can use them
<azeem> robtaylor: every guy doing work for Debian should be interested in releasing Sarge, really
<robtaylor> sabdfl: thats not the point... 
(Kamion/#ubuntu-devel) robtaylor: s/sabdfl/seb128/?
<robtaylor> Kamion: oops, yes ;)
<robtaylor> its the lack of full FOSS process usage that's irritating me ....
<sabdfl> robtaylor: there's no lack of foss process usage
<sabdfl> we're publishing all patches immediately
<sabdfl> even linking to them from the debian bts
<robtaylor> sabdfl: but there's already a repo for the gnome packaing
<robtaylor> you dont need to publish patches
<sabdfl> the ubuntu packages need ubuntu branding, ubuntu docs, ubuntu icon preferences etc
<sabdfl> since we're funding the work, i'd like the focus to be on getting it done that way
<sabdfl> i'm very happy that the work also benefits debian
<sabdfl> our panel is different, we make different choices about defaults and preferences and desktops
<robtaylor> sabdfl: i'm not comaplaing about debain not benifiting from you... i'm complaining about you not benifiting from debain
<sabdfl> then pitch in and help seb ;-)
<azeem> sabdfl: this is a technical problem one could solve by e.g. changing the patching systems to only apply *ubuntu* patches on ubuntu, and vice-versa
<azeem> that was supposed to be wildcards, not bold text, btw
<sabdfl> i think we are close to a first internal release of a revision control system that will let us do this
<robtaylor> sabdfl: i agree that a good vcs is important to doing this well
<robtaylor> i gues what i wean to see is gnometeam and seb working together in systems both can see all the code..
<sabdfl> robtaylor: we are working on a system like that, but it will still be a while before it's ready
<sabdfl> till then, the best way i can think of is to ask the team to publish their patches and ntoe them in the debian bts
<robtaylor> sabdfl: hmm, i think in gernealy that sounds wrong, but for this case that was wrong as there was alreasy existing team and source control
<robtaylor> oops
<robtaylor> i mean in general that sounds right =)
(Kamion/#ubuntu-devel) it works better for packages where we aren't leaping so far ahead of Debian unstable
(Kamion/#ubuntu-devel) so where the patches are actually patches rather than "here, replace this enormous thing with this other enormous thing"
<sabdfl> robtaylor: i'm hoping a team will form around seb to help him
<Keybuk> robtaylor: so would the Debian GNOME team happily give commit access to any Ubuntu developer who might apply patches to our GNOME packages?
<robtaylor> sabdfl: but there alreasy is a team!
<robtaylor> Keybuk: yep
<robtaylor> as far as i know
<Keybuk> robtaylor: so if some guy in #ubuntu-devel asks, you'd give him an account today?
<Keybuk> because I doubt that very much
* daniels notes that there is still much work to be done for GNOME for sarge, and it's not 2.9.
<Keybuk> it's just a co-incidence that seb happens to be on "both teams"
<azeem> Keybuk: there are a couple of people in the Debian GNOME team which are not DDs
<azeem> it's part of the Alioth success story
<robtaylor> Keybuk: (they gave me an account just becasue i said 'hey can i package gtk+2.4?' )
(Kamion/#ubuntu-devel) lamont: re debootstrapability of ia64, can we make sure that germinate does the right thing for it first and then debootstrap can be updated automatically?
<Keybuk> robtaylor: what about (e.g.) people packaging 2.9 for Fedora ?
<robtaylor> Keybuk: well, somethings it might well make sense to collaborate on. but realistsically the systems are so different theres unlikely to be much common work
<robtaylor> Keybuk: for gnome-print stuff i try to stay current with colin walters work
<Keybuk> the idea of Ubuntu stamping on (and relying on) another distribution's monolithic repository unnerves me
<robtaylor> Kamion: it isnt monolithic - thats what branches are for =)
<robtaylor> s/Kamion/Keybuk
* robtaylor spanks his tab key 
<Keybuk> robtaylor: Subversion makes it *harder* than just applying patches you can get from HTTP
<robtaylor> Keybuk: true, and i agree arch is better for managing these kind of processes
<azeem> Keybuk: HTTP doesn't make it particularly easy to find the patches in the first place, though
<robtaylor> but you need to weigh that up against splitting an existing community
<Keybuk> why is it splitting it?
<sabdfl> robtaylor: we're trying to create a framework where separate communities can collaborate effectively
<sabdfl> saying "do it all in my codebase" doesn't recognise that different groups *want* to do somethings differently
<sabdfl> what we need is to make sure that work can easily move around
<robtaylor> better would have been for ubuntu to be a branch in svn for warty and hoary, and then seb to have bursuaded us all that moving to the new vcs was a good idea, and mopving the repo as a whole
<sabdfl> i'm trying to get this right for much more than debian-ubuntu, where it's relatively easy
<sabdfl> we have to get it right for gentoo-ubuntu and fedora-ubuntu too
<sabdfl> and that's... challenging ;-)
<robtaylor> sabdfl: i'm in full agreement with your sentiments =)
<sabdfl> so i can appreciate where you're coming from
<sabdfl> and i appreciate your concern that we're not getting the benefit of the debian team's work
<sabdfl> i think seb is doing an amazing job, and i really hope others step up to help him do it even better
<sabdfl> but i'm going to ask him to keep at it the way we are currently structured
<sabdfl> now... i need to write some more code
* robtaylor wanders off muttering about ineffiecient behaviours
<robtaylor> =)
<Keybuk> robtaylor: there's a scary line with it all though -- "work in our repository" is only semantically different from "work in our archive"
<Keybuk> you could just as easily argue Ubuntu should upload all of its packages into Debian's archive, NMUing where appropriate
<Keybuk> and, imo, that would be a very very bad thing
<robtaylor> Keybuk: the difference is, its very hard to branch an archive
<Keybuk> robtaylor: it's very hard to properly branch a CVS or Subversion repository
<azeem> Keybuk: we're talking about a strict subset of Debian where most people are pro-Ubuntu anyway
<Keybuk> azeem: that's not actually the issue with it
<robtaylor> Keybuk: not really
<Keybuk> the most you can do with svn is have side-by-side copies
<Keybuk> and I don't see the benefit from doing that
<Keybuk> it doesn't provide any useful history between the two (a copy breaks history in svn)
<Keybuk> it doesn't provide any help merging changes between the two (you diff and apply)
<robtaylor> Keybuk: i agree svn isnt good enough. and arch is a much better vcs architecture (moduleo ui, etc) =)
<Keybuk> so it'd be an entirely political move, only
<robtaylor> Keybuk: hmm, so would what i'm suggesteing be blessed if gnome-team used an arch repo?
<Keybuk> at least then you have the advantage that the repositories can be merged relatively easily, can be stored on separate machines and only related via history, etc.
<robtaylor> Keybuk: this came up becasue kov was aslking if he should package gtk2.5.x for experimental
<Keybuk> I still think you'd then simply have the problem that seb is paid full time to package gnome, so can't wait a week for someone else who we're not paying to do to the work *shrug*
<robtaylor> Keybuk: yeah, no probs with that. why is taht a problem?
<robtaylor> i'm paid to work on openembedded, if other people dont do the work, i do it, no big deal
<Keybuk> so random question, why haven't Debian taken the Ubuntu 2.9 packages?  rather than packaging them separately themselves?
<robtaylor> Keybuk: becasue seb desnt want to do that, as far as i can tell
<mojo> hi all fellow developers
<mojo> can u guys give me some help on RealPlayer compiling?
<mojo> RealPlayer requires oggvorbisssdk
<mojo> what packages do I need to install?
<rburton> robtaylor: surely you mean "seb is busy with 2.8 in sarge so isn't putting 2.9 into experimental, but the patches are available so it could be done by someone else"
<robtaylor> Keybuk: basically i want to be able to 1) see what work seb is doing on libgnomeprint/ui and 2) easily pul that into the 'debian' repo
* sid77 ciao
<Keybuk> robtaylor: apt-get source libgnomeprint, apt-get source libgnomeprintui, etc.
<Keybuk> I don't think Subversion makes this *any* easier for you
<robtaylor> Keybuk: i want to see cheking logs
<robtaylor> Keybuk: being able to see the work does!
<Keybuk> I don't think seb even works in a revision control system at the moment
<robtaylor> Keybuk: exactly! 
<Keybuk> we are working on it for the entire hoary team
<rburton> seb128: you don't even have a local svn! :)
<robtaylor> Keybuk: at elast witha  branch i can keepup to date with what hes going, and if i'm in agreement, i can jyust copy accorss. if i'm not, then we can talk about it
<robtaylor> at the meoment, i just have NO IDEA what work is ebing done
<seb128> rburton: nop :p
<seb128> robtaylor: apt-get source package and read the changelog
<robtaylor> seb128: ok
<seb128> if a patch is good for debian I ping you guys about it or open a bug in the BTS
<robtaylor> thats a right royal pain in the ass
<robtaylor> seb128: i'm sure most of wht you do is good for debian
<robtaylor> its looks like the same job to me
<robtaylor> modulo a couple of backdrops =)
<seb128> so what's the problem ?
<robtaylor> because we're doing the same job separately ..
<robtaylor> and this is FOSS . thatt isnt supposed to heppen
(Kamion/#ubuntu-devel) Keybuk: copies don't break history in svn?
<seb128> robtaylor: we are not, 2.9/2.5 is not packaged in debian for the moment
<seb128> robtaylor: when it'll be you just have to pick my changes and keep what you want
<Keybuk> Kamion: diff across one
<Keybuk> svn commit file
<Keybuk> svn copy file new-file
<Keybuk> svn commit new-file
<Keybuk> than diff from the file before the first commit to after the second commit
(Kamion/#ubuntu-devel) Keybuk: AIUI that's a client-side problem, not a server-side problem, and it's fixed in 1.1
(Kamion/#ubuntu-devel) the history of the copy is stored in the repository
<Keybuk> it's broken in 1.0.9 at least
* Keybuk just checked it was still broken
<robtaylor> suffice to say. as far as i can see it costs noone anything dfor seb to workin svn rather than on his local harddisk
(Kamion/#ubuntu-devel) 1.1 > 1.0.9
<robtaylor> and you gain and i gain
(Kamion/#ubuntu-devel) it required an API change to fix it, I believe, and was therefore strictly a 1.1 thing
<Keybuk> robtaylor: it costs noone anything for you to look at what's seb's done by getting the packages either
<robtaylor> Keybuk: its one way
(Kamion/#ubuntu-devel) Keybuk: see http://subversion.tigris.org/svn_1.1_releasenotes.html under "Client follows renames"
<Keybuk> Kamion: that's a different bug!
<Keybuk> rename != copy
<Keybuk> that was just the client being thick and not resolving the right url for the history
<Keybuk> but a copy is a delete and an add
<Keybuk> so it sees the diff as the removal of the entire file, and adding an entire new one
(Kamion/#ubuntu-devel) Keybuk: dude, read the URL
(Kamion/#ubuntu-devel) it says "copies" under the headline
(Kamion/#ubuntu-devel) "Subversion makes a lot of noise about the way branches (copies) of files and directories maintain historical connections to their source, but [...] "
<sabdfl> we're working hard on gnu arch (see bazaar.canonical.com) which i hope will let us make collaboration very easy
<robtaylor> Keybuk: seb loses any inut i have on his work
<robtaylor> s/inut/input
<robtaylor> sabdfl: i know. but its a way off
<Keybuk> is good that they've fixed it
<Keybuk> robtaylor: no he doesn't, not if he checks your repository
<robtaylor> right now theres a good enough solution, and its not being used
<Keybuk> Kamion: will have to test when 1.1 gets packaged -- will be good if they've fixed that
<Keybuk> it's the single thing that drove me away from svn
<robtaylor> Keybuk: there no way i can easliy keep up to date with his work and keep an eye on it and make sure its sane
(Kamion/#ubuntu-devel) I'm not sure offhand whether getting that feature requires a new server as well; I suppose I could try fairly easily at some point
<robtaylor> Keybuk: apt-getting and diffing sourcetrees every day isn't my idea of fun
<Keybuk> robtaylor: I disagree your solution is good enough
<robtaylor> Keybuk: well its better than your *current* solition
<Keybuk> robtaylor: we're working on our solution for it though
<robtaylor> Keybuk: i know
<robtaylor> i just want soemthing i can use for 2.10
<robtaylor> and it really doenst seem much to ask
<robtaylor> sigh. ah well . ist apt-get and diff for me
<robtaylor> must go do some work
(lamont/#ubuntu-devel) moo
(lamont/#ubuntu-devel) Kamion: was wondering what/where hoary template was used...
(Mithrandir/#ubuntu-devel) lamont: pong
(lamont/#ubuntu-devel) morning Mithrandir
<eruin> someone filed a bug on nautilus crashing on startup already?
(Mithrandir/#ubuntu-devel) hi lamont
(Mithrandir/#ubuntu-devel) definitively not morning any more, as it's almost pitch dark outside, though
(Kamion/#ubuntu-devel) lamont: required-base.py
(Kamion/#ubuntu-devel) lamont: hoary.* are glued together to make hoary
(lamont/#ubuntu-devel) Kamion: although hoary.buildd is separate, yes>
(Kamion/#ubuntu-devel) lamont: I generate hoary.base automatically from germinate output
(lamont/#ubuntu-devel) ?
(Kamion/#ubuntu-devel) lamont: yep
* lamont spews a little
(lamont/#ubuntu-devel) +        "ia64")
(lamont/#ubuntu-devel) +            base="$base libreadline4 libreadline5"
(lamont/#ubuntu-devel) +            required="$(subst_package "libc6" "libc6.1" "$required")"
(lamont/#ubuntu-devel) +           base="$(subst_package "libc6-dev" "libc6.1-dev" "$base")"
(lamont/#ubuntu-devel) +           base="$(without_package "ltrace" "$base")"
(lamont/#ubuntu-devel) +            LIBC6="libc6.1"
(lamont/#ubuntu-devel) +            ;;
(lamont/#ubuntu-devel) that's the current (working) version.
(lamont/#ubuntu-devel) -    ln -s mawk $TARGET/usr/bin/awk
(lamont/#ubuntu-devel) +    ln -sf mawk $TARGET/usr/bin/awk
<seb128> robtaylor: we already managed 2.8 fine, no reason to worry for 2.10
(lamont/#ubuntu-devel) and that change should have been added a million years ago
(Kamion/#ubuntu-devel) lamont: that subst_package should not be necessary
<pitti> sjoerd: pmount 0.4.3 released upstream and to Debian
<pitti> sjoerd: btw, did you get the commit mails?
(Kamion/#ubuntu-devel) lamont: what I'd prefer is for hoary.base and hoary.overrides to list the correct packages for ia64, and then required-base.py will work it out for itself
<robtaylor> seb128: ok
(lamont/#ubuntu-devel) Kamion: ok
(Kamion/#ubuntu-devel) are all the base packages for ia64 uploaded?
* Kamion experiments
(lamont/#ubuntu-devel) Kamion: all bug gcc-3.4 :(
(Kamion/#ubuntu-devel) presumably that rather takes out everything else :)
(lamont/#ubuntu-devel) or raher, libgcc1
(lamont/#ubuntu-devel) well, people.ubuntu.com/~lamont/ia64/stage2/libgcc1_3.4.2-2ubuntu1_ia64.deb is available for testing purposes
(Kamion/#ubuntu-devel) one minor issue is that doing this the normal way will result in libc6 being unpacked/configured last rather than somewhere in the middle
(Kamion/#ubuntu-devel) so may have to do some frobbing there
<robtaylor> seb128: next week i'll finally be able to work on stuff again, and i know for gnome-print there's some big changes planned
(Kamion/#ubuntu-devel) basically I was trying to get away from the manually-maintained-debootstrap-script thing because it was too error-prone with germinate output changing every couple of days
(sjoerd/#ubuntu-devel) pitti: ah you went for magic in pmount-hal :)
<pitti> sjoerd: yes, sorry, but I really like it more that way
(sjoerd/#ubuntu-devel) pitti: works for me, so no problem
<pitti> sjoerd: I want to do such stuff entirely as non-root
<pitti> sjoerd: and it's a bit easier in sh :)
<pitti> sjoerd: works fine for me, too
<seb128> robtaylor: have you planned to include redhat changes, hal stuff, etc ? :)
(sjoerd/#ubuntu-devel) pitti: hrm if /media/blabla is a symlink to dir ? what happens then 
<pitti> sjoerd: -d will be true for symlinks to dirs
(Kamion/#ubuntu-devel) lamont: can we seed your bootloader and stuff?
(lamont/#ubuntu-devel) probably should, eh?
(sjoerd/#ubuntu-devel) pitti: but that dir won't turn up in the mount list 
(lamont/#ubuntu-devel) Kamion: efibootmgr
<pitti> sjoerd: oh, right, mount resolves symlinks
<robtaylor> seb128: definitly :) i'll need to chat to kenshi muto as cups will need the dbus patch adding
<seb128> ok, rock :)
<pitti> sjoerd: well, if you manage to screw up /media that far...
(sjoerd/#ubuntu-devel) true 
<pitti> sjoerd: pmount will fail to mount it
<pitti> sjoerd: I can add symlink resolution in the next version, however
(Kamion/#ubuntu-devel) lamont: that's all?
<pitti> sjoerd: this should be necessary only for grepping the mount output AFAICS
(Kamion/#ubuntu-devel) lamont: (debootstrap shouldn't install that, of course)
(sjoerd/#ubuntu-devel) pitti: yeah
(Kamion/#ubuntu-devel) lamont: is elilo similar/different/obsolete or what? d-i only installs elilo, it doesn't know about efibootmgr
<pitti> sjoerd: although... resolving symlinks before doing any check on them might be safer and even easier
(lamont/#ubuntu-devel) ah, then elilo is probably needed...
(Kamion/#ubuntu-devel) well, d-i could be changed, I'm just wondering
(lamont/#ubuntu-devel) efibootmgr is for mucking with efi
* lamont shrugs - dunno.  probably best to do what di does.  That is, d-i+2.6kernel.
(Kamion/#ubuntu-devel) neither are in main at the moment AFAICS
(lamont/#ubuntu-devel) both in universe.
(sjoerd/#ubuntu-devel) pitti: haven't seen commit mails yet
<pitti> sjoerd: not even the ones from some days ago=
<pitti> sjoerd: ?, even
(sjoerd/#ubuntu-devel) no, never had any afaik
(Kamion/#ubuntu-devel) lamont: I've made the installer seed changes for ia64 since I think that's OK to do, but mdz/jdub will need to ack base changes
(Kamion/#ubuntu-devel) lamont: (given you efi-reader, elilo-installer, libc6.1-udeb)
(lamont/#ubuntu-devel) cool
<Mitario> heyhey
<mvo_> hi Mitario 
<mvo_> update-manager 0.32 was uploaded today :)
<pitti> guys, do we have CC today?
(bob2/#ubuntu-devel) hrm, anyone understand the kernel build system?
(bob2/#ubuntu-devel) I want to stop it applying some patches
(bob2/#ubuntu-devel) er, ubuntu kernel package build system
<pitti> seb128: just installed new gvfs; now it really does make a difference :) thanks
<seb128> np :)
<seb128> is that better ?
<pitti> seb128: however, complete drive unmounting (#3666?) still doesn't work
<seb128> :(
<pitti> seb128: but the new names and capacity is nice
<seb128> yeah
<pitti> also, mount point symlinks are still an issue
<pitti> seb128: but I already debugged it (#1217), and I can fix it on my own
<pitti> seb128: I jsut hoped that hal would fix this for free :)
<pitti> No CC meeting today?
(bob2/#ubuntu-devel) pitti: is it possible to have g-v-m set certain mount options?
<pitti> bob2: what do you mean in particular?
<pitti> bob2: right now you can influence async and noatime
<pitti> bob2: in fact the newest versions do this automatically
<gicmo> 'evening
(bob2/#ubuntu-devel) pitti: they're the ones I'm thinking of
<pitti> bob2: right now the devices get "sync,noatime" for < 1GB and "async,atime" for > 1GB
<herzi> what does it take to build a package and get it uploaded into universe?
<pitti> bob2: you can customize that in /etc/hal/fdi/ubuntu-storage-policy.fdi
<pitti> herzi: build it, put it to a place where it can be downloaded and tested
<pitti> herzi: then ask here
(bob2/#ubuntu-devel) pitti: oh cool, thanks
<pitti> bob2: however, g-v-m itself does not yet allow to modify this
<pitti> bob2: it's currently HAL and pmount-hal
<pitti> bob2: the intention is to have save memory sticks and fast USB hard drives
<pitti> bob2: s/save/safe/
<seb128> hey gicmo 
<seb128> gicmo: here now ? :)
(bob2/#ubuntu-devel) pitti: cool, that's just what I wanted
<herzi> hi gicmo:)
<seb128> Keybuk: here ?
<gicmo> seb128, hehe yeah!
<gicmo> seb128, I installed ubuntu about a week ago .. I wanna help out with the graphical boot stuff .. but sladen is never around :(
<gicmo> herzi, jo! :)
<carlos> gicmo: hey!, nice to see you here
<Keybuk> seb128: nope :p
<Keybuk> seb128: shoot.
<gicmo> Hi carlos! .. good to see you too .. how are you?
<seb128> Keybuk: is there a meeting today ?
<seb128> <smurfix> Is anybody going to open this meeting / are we waiting for people / ???
<seb128> on #ubuntu-meeting
<pitti> seb128: I just pinged sabdfl
<carlos> gicmo: fine, thanks. Enjoying your webdavs code :-)
<Keybuk> seb128: Community Counctil I assume
<gicmo> heh :)
<Keybuk> Tech Board was last week
<seb128> ok
<seb128> dunno if you organise all the meetings :)
<Keybuk> lol, no
<Keybuk> I can probably hit Mark with a bread roll from here
<gicmo> I am trying to buy a keyboard with .en layout.. wow thats kinda difficult if you are in .de
<Keybuk> though I warn you, my aim is terrible
<seb128> ah ah
<smurfix> you seem to have hit ;-)
<daniels> Keybuk: see, if you managed to iht me, now that's an achievement
<daniels> gicmo: yeah, qwertz is interesting
<gicmo> daniels, yeah but really sucks if you do lots of coding/unix-sysadmin .. so I wanna have a .en layouy
<gicmo> layout
<Keybuk> gicmo: I'm sure my keyboard was made in .de
<herzi> gicmo: i have only one querz left, but i have one query that you can get in berlin on 21c3
<herzi> qwerty
(Kamion/#ubuntu-devel) "No common CD-ROM drive was detected"
<gicmo> herzi, sweet ... but I think I can find some on ebay
(Kamion/#ubuntu-devel) meh, I must have broken something fairly core :(
<pitti> mdz: Good morning!
(mdz/#ubuntu-devel) pitti: morning
<gicmo> I wanna have beagle packages .. 
* gicmo runs
(Kamion/#ubuntu-devel) -rwxr-xr-x    1 root     root            0 Nov 23 15:50 /bin/hw-detect
(Kamion/#ubuntu-devel) ah, that would do it
(Mithrandir/#ubuntu-devel) ew
(mdz/#ubuntu-devel) we ought to send out a reminder the day before, for CC meetings as well as TB
(Mithrandir/#ubuntu-devel) mdz: it would be _really_ nice to have an ical feed somewhere people could subscribe.
<herzi> gicmo: build some
<gicmo> herzi, heh .. I suck at debian package stuff .. and of course you would need the inotify kernel patches .. 
<azeem> does beagle use inotify directly, or via gamin?
<gicmo> azeem, good question ... maybe directly ...
(mdz/#ubuntu-devel) mvo_: ping?
<mvo_> mdz: pong
(mdz/#ubuntu-devel) mvo_: do you have your apt changes in arch now?
<mvo_> mdz: yes
<mvo_> at chinstrap 
<mvo_> apt--mvo--0
<mvo_> unfortunately the apt-0.6 sync is not yet finished, apparently some problems with cvs.debian.org
<elmo> mvo_: meh, not cvs.d.o's fault
<mvo_> elmo: sorry, didn't wanted to imply that it was the fault of cvs.d.o :)
<mvo_> elmo: you make funny noises today BTW ;)
<pitti> seb128: after logging out of gnome, there are still three user processes running (esd, gam_server, dbus-daemon-1)
<pitti> seb128: this gives funny messages when logging in again and generally doesn't look right
<pitti> seb128: which package is the best to file bugs about this against?
<seb128> esd -> esound
<pitti> seb128: I shall file bugs against the packages themselves?
<seb128> there is an option for that in /etc/esound/esd.conf
<pitti> seb128: not against the packages that start these processes?
<pitti> ah
<seb128> dunno for the 2 others
<seb128> yes, probably against the packages
(lamont/#ubuntu-devel) Kamion: so next steps for debootstrap?
* lamont blames low blood sugar.  bbiam
(Kamion/#ubuntu-devel) lamont: get gcc-3.4 uploaded, I think ...
(mdz/#ubuntu-devel) mvo_: your tree seems to have both Suggests and Depends: bzip2
<mvo_> mdz: apt suggests bzip2, apt-utils depends on bzip2. the later may be from lamonts upload
(Kamion/#ubuntu-devel) lamont: just for a moment assuming that Herbert won't be doing hoary kernels soon, how complicated are the required patches for ia64?
(mdz/#ubuntu-devel) mvo_: hmm...why would apt-utils depend on bzip2?
(mdz/#ubuntu-devel) lamont: ?
(lamont/#ubuntu-devel) Kamion: no kernel diff, just configs
(lamont/#ubuntu-devel) mdz: yes
(Kamion/#ubuntu-devel) mdz: oh yes; can we add the ia64 bootloader to base? either elilo or efibootmgr, not 100% sure which yet
(lamont/#ubuntu-devel) mdz: no good reason - was applying a large cluebat to get the archive usable again.
<elmo> lamont: err, yeah there is a kernel diff?
(lamont/#ubuntu-devel) not according to dannf...
<elmo> which dannf are you talking to?  he told me to apply the ia64 patch when building kernels for our boxes
(Kamion/#ubuntu-devel) -rw-r--r-- dannf/dannf  111522 2004-06-29 21:07:28 kernel-patch-2.6.7-ia64-2.6.7/linux-2.6.7-ia64-040629.diff
(Kamion/#ubuntu-devel) there are several others too, dunno how many were merged in 2.6.8
(lamont/#ubuntu-devel) for 2.6 there is no kernel-patch-ia64
(lamont/#ubuntu-devel) 2.4 is a diff story, unknown here.
(lamont/#ubuntu-devel) that's as of when I asked yesterday
<elmo> dude, there's no kernel-patch-ia64 in _Debian_ because it's managed as part of the generic Debian kernel patch now
(mdz/#ubuntu-devel) mvo_: ok, merged, mirror updating
<elmo> but there's definitely still an ia64 patch to 2.6.<n>
(lamont/#ubuntu-devel) ah.  and ours are based off of upstream, or debians?
<seb128> pitti: I'm a patch for gnome-session/esd
(lamont/#ubuntu-devel) ours==ubuntu
(Kamion/#ubuntu-devel) Debian's, but I don't think we're totally up to date
<seb128> pitti: oups, s/'m'/'ve/
<pitti> seb128: you are a patch? Interesting :)
<seb128> yes
<seb128> I AM THE PATCH
<seb128> FEAR
<seb128> :p
* Kamion ponders the approach of just uploading ddetect and seeing what breaks
<daniels> 'be the patch'
<kylem> hah.
<gicmo> seb128, no no .. go away .. please .. dont patch me ..noooooooo
<seb128> :p
(Kamion/#ubuntu-devel) there are three ia64 patches in our linux-source right now
(lamont/#ubuntu-devel) Kamion: and the build fails on ia64 after the build completes (ia64 not in arch list).  Which of course, doesn't mean it would actually _work_...
(lamont/#ubuntu-devel) that was what led me to ask folks yesterday
(Kamion/#ubuntu-devel) well, let's compare
<mvo_> mdz: thanks
(mdz/#ubuntu-devel) mvo_: did you hear anything from lifeless about v0_6?
<lifeless> its done, just finishing a prod update for you to see it
(Kamion/#ubuntu-devel) OK, so we seem to be missing five patches that include the string "ia64"
(lamont/#ubuntu-devel) Kamion: so there is definitely some kernel work to be done before we're really happy there.
(Kamion/#ubuntu-devel) they're all self-contained though
(lamont/#ubuntu-devel) that sounds good
(Kamion/#ubuntu-devel) the dropping of kernel-patch-2.6.8-ia64 happened with the first Debian kernel-image-2.6.8-ia64 build, and Herbert merged everything up until after that date from Debian
(Kamion/#ubuntu-devel) elmo: which patch did dannf tell you to apply?
<elmo> the one in ports/ia64/ on kernel.org
<elmo> that may already be in debians and ours tho
(lamont/#ubuntu-devel) Setting up fontconfig (2.2.3-2ubuntu1) ...
(lamont/#ubuntu-devel) /usr/sbin/laptop-detect: line 14: dmidecode: command not found
(lamont/#ubuntu-devel) that's got to be something I can blame on daniels.... ;-)
(Kamion/#ubuntu-devel) elmo: oh, you were going from upstream source weren't you?
(Kamion/#ubuntu-devel) lamont: thom, wasn't it?
<elmo> Kamion: yeah - I tried with ours and got patch conflicts and ran away screaming
<elmo> oh, actually, I Fixed the patch conflicts, but it still FTBFS
<elmo> we had a patched ACPI and the ia64 part hadn't been updated to match, IIRC
(Kamion/#ubuntu-devel) there's certainly some of that we haven't got; Debian doesn't either though
<daniels> lamont: notmeblamethom
(lamont/#ubuntu-devel) daniels: heh
(lamont/#ubuntu-devel) daniels: but you're _FUN_ to blame.... :-)
<daniels> :P
(Kamion/#ubuntu-devel) elmo: after ignoring the big wodge of deleted files there's only one diff hunk that touches ACPI ...
<elmo> Kamion: in which?
(Kamion/#ubuntu-devel) linux-2.6.8-ia64-040901.diff.gz
<elmo> yeah, but I mean we (i.e. ubuntu's kernel patch) update ACPI but didn't take the corresponding update for ia64
(Kamion/#ubuntu-devel) oh, I see
<elmo> is my very dubious understanding of it - it was 10pm by this point and I was trying to get out of the DC
(Kamion/#ubuntu-devel) not that I can figure out where the hell Herbert got that version of the patch from in the first place
(Kamion/#ubuntu-devel) I wonder if he just pulled it straight from BK
<daniels> elmo: so, what doesn't suck in the land of gigabit switches?
<daniels> elmo: looking at up to 10 connections
(Kamion/#ubuntu-devel) lamont: was dannf very definite that the patch on kernel.org wasn't needed?
(lamont/#ubuntu-devel) Kamion: really fuzzy on the whole conversation...
* lamont looks
<fabbione> hey lamont 
<fabbione> lamont: i started phase1 :-)
(lamont/#ubuntu-devel) Nov 21 10:51:59 <dannf> lamont: there's no kernel-patch package, if that's what you're asking
(lamont/#ubuntu-devel) Nov 21 10:52:47 <dannf> lamont: there's plenty of changes vs. kernel.org though; mostly backports
(lamont/#ubuntu-devel) Nov 21 10:53:11 <dannf> 2.6.9 builds, but i haven't done an upload yet - waiting for someone to generate a new kernel-source
(lamont/#ubuntu-devel) Nov 21 10:53:36 <dannf> i'm not antsy enough to put one together myself, but i've added all the patches i've found necessary to get it to build
(lamont/#ubuntu-devel) N
(lamont/#ubuntu-devel) ov 21 10:55:02 <dannf> and there's 2.6.9 configs in the repo as well
(lamont/#ubuntu-devel) fabbione: kewl
<fabbione> lamont: just one question.. if i manage to build phase1 without any cheating (since i did all of them in phase0), phase2 can be considered "gold", right?
(lamont/#ubuntu-devel) fabbione: well,there's a naming thing going on here...
<fabbione> lamont: i did try to allign my naming with your :-)
(lamont/#ubuntu-devel) I created chroot-stage0 by debootstrapping sid. the debs built there went into the stage1 repository, which was pointed at by chroot-stage1...
<fabbione> phase0 build on top of sid
(Kamion/#ubuntu-devel) lamont: hm, bit vague
(lamont/#ubuntu-devel) but to answer your real question
<fabbione> phase1 bootstrap a chroot with phase0 pkgs and rebuild
(lamont/#ubuntu-devel) if you build using only .debs that you previously built (albeit in some random - aka sid - chroot), then we consider it to be bootstrapped.
(lamont/#ubuntu-devel) then comes d-i and kernel work
(lamont/#ubuntu-devel) as well as the seed changes
(lamont/#ubuntu-devel) all of which then feed into debootstrap changes, and presto.
(lamont/#ubuntu-devel) (right Kamion)
(lamont/#ubuntu-devel) Kamion: and yes, dannf was a bit vague...
<fabbione> yup.. i did a local hack to debootstrap to be able to create a clean chroot from phase0 pkgs
(Kamion/#ubuntu-devel) lamont: ayup
<fabbione> local hack = just add the sparc arch and add the 2/3 pkgs required by sparc only
(Kamion/#ubuntu-devel) somebody remind me tomorrow to do architecture-specific tagging in germinate
<fabbione> lamont: but the chroot is clean, there are no sid packages in it
<fabbione> and it is building ubuntu on top of ubuntu
(lamont/#ubuntu-devel) fabbione: on the naming thing, I was calling sid 'phase0 packages', and that produced things that were for stage1, while you're calling the output 'phase 0 packages' - not a big deal, as long as we both keep our stories straight. :)
(lamont/#ubuntu-devel) fabbione: right
<fabbione> lamont: ok, let me try with your naming scheme :-)
(lamont/#ubuntu-devel) once you build ubuntu on top of ubuntu, then you're done building packages, and ready to start fixing bugs.
<fabbione> (if you don't mind)
(lamont/#ubuntu-devel) fabbione: sure.  although I understood it in your terms too...
<fabbione> so basically building on top of sid is stage0 and creates packages that have to be used for stage1
<fabbione> or so called stage1 packages
<fabbione> did i get you right?
(lamont/#ubuntu-devel) fabbione: I declared the sid packages to be stage 0, and began by building stage1 (ubuntu built on sid), then used the stage1 packages (output from chroot-stage1 builds) to debootstrap and build ubuntu on ubuntu (stage2)
(lamont/#ubuntu-devel) if no cheating is involved, then you're done.
<fabbione> ahh ok
<fabbione> than i am at stage2
<fabbione> because i am building ubuntu on top of ubuntu
(lamont/#ubuntu-devel) if you cheat in getting everything into stage2, then you must iterate until you didn't cheat to build everything.
(lamont/#ubuntu-devel) right
<fabbione> well i did cheat building some packages for stage1
<fabbione> but mainly because of build-deps
(Kamion/#ubuntu-devel) elmo: would adding passive => 1 to the dupload.conf stanza in Uploads be a good idea? it might work for a few more people
(lamont/#ubuntu-devel) hence the current state of ia64: I cheated in building gcc-3.4, so I can't upload that to the archive.  (Killed the hung ada tests, you see...)
<fabbione> lamont: i didn't have to change the packages
<fabbione> lamont: only make the build-dep available from the phase1 archive to the chroot
<fabbione> like gnome 2.9 build-dep on libfoo 2.9
(lamont/#ubuntu-devel) fabbione: that's not cheating.
(lamont/#ubuntu-devel) that's optimizing the iteration. :-)
<fabbione> ah ok
<fabbione> well even better
<fabbione> i considered that cheating
<fabbione> becuase right now i am down to 12 FTBFS
<fabbione> 3 are d-i/kenrel related
<fabbione> and the others are the same in Debian and Ubuntu
(Kamion/#ubuntu-devel) debian-installer, the kernel itself, what else?
(lamont/#ubuntu-devel) cheating includes source changes, manual intervention in the build process, manually installing things that don't belong in the chroot, etc.
<fabbione> Kamion: linux-meta and ubuntu-meta
<fabbione> Kamion: the latter builds but incorrectly
(Kamion/#ubuntu-devel) ah yes
<fabbione> lamont: no.. i did nothing like that
<fabbione> lamont: instead i have been properly fixing the packages and upload them (see the FTBFS fixes from yesterday ;))
<fabbione> lamont: there was probably one thing that made me think....
<fabbione> when i started stage2, sbuild and apt were complaining about postdrop group
<fabbione> i had to install postfix on the buildd to fix that problem
<fabbione> it was mumbling something about group override (dpkg iirc)
* Kamion contemplates dropping discover from the d-i initrds
(Kamion/#ubuntu-devel) it might actually stand a chance of working without it now
<fabbione> Kamion: if you don't mind of the next day i will distrub you to get some sparc stuff in.
<fabbione> s/day/days
(Kamion/#ubuntu-devel) fabbione: sure, what kind of stuff?
(Kamion/#ubuntu-devel) fabbione: (and are sparc uploads cleared with mdz/jdub?)
<fabbione> Kamion: the seeds and the debootstrap stuff?
<fabbione> Kamion: we are not going to upload to the main archive. We discussed this last TechBoard Meeting
(Kamion/#ubuntu-devel) ok, but for debootstrap I want an archive I can download Packages files from that has a complete sparc base system
<pitti> @ALL: can anybody do a review of a mysql security update?
<fabbione> Kamion: ok, that can wait than..
<fabbione> thanks a log guys
<fabbione> i need to go
<fabbione> cya around tomorrow :-)
(Kamion/#ubuntu-devel) and preferably an assurance that it will remain reasonably up to date to avoid complications
(Kamion/#ubuntu-devel) seeds, certainly
(Kamion/#ubuntu-devel) cheerio
<fabbione> Kamion: we discussed that too at the meeting
<pitti> fabbione: bye!
* fabbione &
(lamont/#ubuntu-devel) seb128: ??
<seb128> what .
<seb128> ?
* lamont points at the msg window
<seb128> oh ok
<seb128> no, libgnomevfs2-dev missing this
(mdz/#ubuntu-devel) lifeless: the v0_6 tree looks good, thanks
(lamont/#ubuntu-devel) seb128: whatever. :-)
<seb128> thanks
(lamont/#ubuntu-devel) if I should dep-wait totem on something, that'd be a new verison of libgnomevfs2-dev?
<seb128> right
<seb128> 2.8.3-0ubuntu8
(lamont/#ubuntu-devel) seb128: done
(lamont/#ubuntu-devel) seb128: btw, about python-gtk2...
<seb128> lamont: hum, in fact nautilus-cd-burner bug
(lamont/#ubuntu-devel) we should be using the debian source tree for that (and gtkhtml3.2), yes?
<seb128> /usr/lib/libnautilus-burn.la point on libhal
<seb128> lamont: we should yes
(lamont/#ubuntu-devel) ok.  I'll upload the debian versions then.
<seb128> lamont: source name != upstream name, so we tar xzf && mv && tar czf 
<seb128> if there is a timestamp somewhere perhaps the md5 is !=
(lamont/#ubuntu-devel) that'd do it
(lamont/#ubuntu-devel) maybe an upload of our bits to experimental is in order... :-)
(lamont/#ubuntu-devel) that way the orig.tar.gz would be there...
<seb128> he he
(lamont/#ubuntu-devel) but that's mean..
(lamont/#ubuntu-devel) seb128: mind you, ISTR dpkg-source handled sourcename != upstreamname
<seb128> lamont: yeah, but changing the sourcename would mean to go through NEW, right ?
* lamont doesn't know.
<seb128> lamont: I've not renamed these packages but when I've started to work on them they were in this state
<seb128> and waiting 2-3 weeks to get a package out of NEW is a annoying, so I've not renamed them, perhaps I should :)
<seb128> elmo: gnome-gv sync please
<elmo> seb128: done
<seb128> thanks
(lamont/#ubuntu-devel) seb128: the trick is to ask nicely. :-)
<seb128> lamont: right, and to not abuse :)
<ironwolf> daniels ?
<daniels> ironwolf: yo
<ironwolf> daniels: s3v module does not exist.
<daniels> argh!  sorry, 's3virge'
* ironwolf whaps daniels...do you mean s3verge ?
<daniels> s3virge
* lamont adds gnome-gv to the list of &%*))&% packages
<daniels> i know that because that chipset has ruined my ability to type 'verge'
<daniels> (it's called s3v_driver.c in the sources, which is what I was looking at, hence the confusion -- sorry again)
(lamont/#ubuntu-devel) elmo: I thought you were gonna make the sync fail on md5 mismatch introduction...
<ironwolf> daniels: as long as it gets working for hoary, my friend may not kill me.
<daniels> ironwolf: should work, yes
(lamont/#ubuntu-devel) daniels: was bug?
<daniels> lamont: hmm?
<ironwolf> lamont: is bug. :(
(lamont/#ubuntu-devel) daniels: s3virge
<daniels> lamont: what, using s3 instead of s3virge?
<daniels> just an uncaught case in discover1-data
<daniels> combined with POSSIBLY a DefaultDepth problem
<daniels> because S3 cards suck
(lamont/#ubuntu-devel) dunno - whatever had adam's system not autoconfiguring X.
(lamont/#ubuntu-devel) ah, ok
<ironwolf> S3 cards are fun... but I like radeon better. :)
<daniels> ati cards are way better
<ironwolf> unfortunately, not everybody runs ati or nvidia cards. :)
(Kamion/#ubuntu-devel) Keybuk: merge-o-matic seems to get confused sometimes about the order in which debian/changelog hunks should be merged
(Kamion/#ubuntu-devel) Keybuk: see e.g. http://people.ubuntu.com/~scott/ongoing-merge/debian-installer/debian-installer_merged.debdiff
(Kamion/#ubuntu-devel) 20041115ubuntu1 was put before 20041118
<daniels> Kamion: 15 < 18?
(Kamion/#ubuntu-devel) sorry, before => earlier in the file
(Kamion/#ubuntu-devel) chronologically after
<Keybuk> Kamion: yeah, not sure why that is yet
<Keybuk> I think it's when it applies the Ubuntu patch to Debian
<Keybuk> the logic doesn't quite works
<lifeless> mdz: mvo|away your request is fulfilled
(lamont/#ubuntu-devel) seb128/elmo: I'll fix gnome-gv as well
(mdz/#ubuntu-devel) lifeless: thanks
(mdz/#ubuntu-devel) lifeless: mvo|away seemed to have some trouble with the merge, though
(mdz/#ubuntu-devel) <mvo_>   CHECKSUM FILE(S) DISAGREE WITH
(mdz/#ubuntu-devel) <mvo_>   DIRECTORY LISTING ABOUT WHAT
(mdz/#ubuntu-devel) <mvo_>   FILES SHOULD BE PRESENT IN
(mdz/#ubuntu-devel) <mvo_>   REVISION DIR OF ARCHIVE
(mdz/#ubuntu-devel) <mvo_> argggg
<seb128> lamont: md5 not matching again ?
<lifeless> well, its only just ready to go.. so ...
<lifeless> and it works just fine for me ...
<ironwolf> daniels: s3virge + Depth=16 seems to work, you want we should try Depth 24?
<ironwolf> daniels: adam sends his thanks, and says you rock!
<ironwolf> daniels:  So this will autodetect in hoary yes?
<daniels> ironwolf: trying depth 24 would be cool also
<daniels> rad
<lifeless> might be that hes missing the gpg key in the web server root dir
(lamont/#ubuntu-devel) seb128: yep
<seb128> doh, *again*
(lamont/#ubuntu-devel) python-gtk2 and gtkhtml3.2 uploaded
(lamont/#ubuntu-devel) seb128: is easy to fix, annoying to need to....
<seb128> yes
(lamont/#ubuntu-devel) seb128: and the real issue is that gnome-gv_2.8.0.orig.tar.gz exists in warty, so we can't change that one.
(Kamion/#ubuntu-devel) maybe we can start putting a big list of our repacked-from-upstream .orig.tar.gz filenames somewhere and asking the Debian GNOME guys to take them from us if they package that version
(Kamion/#ubuntu-devel) or version them 2.8.0~1.orig.tar.gz or something (dunno if that works)
(Kamion/#ubuntu-devel) or indeed 2.8.0ubuntu1.orig.tar.gz ...
(lamont/#ubuntu-devel) daniels: you around?
(lamont/#ubuntu-devel) Kamion: yeah - been uploading 2.8.0ubuntu1 versions
(lamont/#ubuntu-devel) issue there is that if we do that first, then the debian package will forever be younger.
(lamont/#ubuntu-devel) seb128: gnome-gv uploaded
(Kamion/#ubuntu-devel) that's OK for GNOME though
(lamont/#ubuntu-devel) true
* lamont wonders how much pain this will cause keybuk and hct...
(lamont/#ubuntu-devel) ECHAN
<ironwolf> daniels: Depth 24 worked.
* lamont heads to town for a bit
<jdub> seb128: pong
(mdz/#ubuntu-devel) lifeless: is that permissions issue fixed, where things come in with (e.g.) mode 446?
<lemsx1> i just found out about this nifty project: http://biddell.co.uk/gnomebaker.php
<lemsx1> GnomeBaker
<lemsx1> it has similar goals as mrburns
<shaya> is upgrade-notifier supposed to be usable?
<mvo|away> shaya: I think so
<seb128> jdub: I've pinged ? I don't remember why :)
<jdub> seb128: the gnomevfs depends change
<jdub> seb128: it wasn't appropriate?
<seb128> probably
<seb128> was not needed
<jdub> but without the new libsmbclient, the smb module wasn't built
<seb128> the consensus on the debian side was to wait to get the new version on the autobuilders and to not bump the depends for nothing
<jdub> oh right
<jdub> but really, the depends *is* needed to make gnomevfs work :)
<seb128> nop, we just need to avoid a bugged samba package
<seb128> but whatever, both ways are fine
<seb128> jdub: do you know if somebody is working on OO.o 1.1.3 ? We have planned to update to 1.1.3 for hoary, right ?
<jdub>    * Remove discover from the initrds and rely entirely on hotplug. Let's see
<jdub>      how much this breaks ...
<jdub> ^ woo
<jdub> seb128: yeah, doko is tracking the merge and sync
<seb128> ok
<shaya> mvo: it doesn't work well for me
<mvo_> shaya: what does not work ?
<shaya> 1) it doesn't seem to do the apt-get update (if I do it manually it works)
<shaya> 2) it leaks gdksudo's all over the place
<shaya> gksudo that is
(Kamion/#ubuntu-devel) jdub: the answer's probably "lots", judging from my preliminary testing
<shaya> though it pops up a notification correctly
(Kamion/#ubuntu-devel) jdub: I need a tame hotplug guru :)
(Kamion/#ubuntu-devel) seb128: Chris Halls just applied and was approved for Ubuntu maintainership, too
<mvo_> 1) is deliberately, it will install a config option in /etc/apt.conf.d to trigger a apt cron.daily job to do the "apt-get update"
<mvo_> 2) what does "leaks gksudo" mean?
<shaya> spotter@dent:~ $ ps auxw |grep gksudo |wc -l
<shaya> 3
<jdub> Kamion: fun :-)
<mvo_> shaya: I don't have any. can you reproduce the leak?
<shaya> mvo_, is this what you are talking about? APT::Periodic::Update-Package-Lists "1";
<shaya> so shouldn't it do it?
<mvo_> yes
<mvo_> it will trigger a cron.daily script 
<shaya> apt?
<shaya> hmm
<shaya> perhaps thats why
<shaya> ubuntu updates more than daily
<shaya> hence I usually do it manually before it notifies me
<shaya> :)
<mvo_> shaya: :)
<mvo_> if you manage to reproduce the leaks with gksudo I would be really happy
<mvo_> the upgrade-notifier is pretty young
<lifeless> mdz: permissions are fixed, yes.
<daniels> ironwolf: awesome!  thanks dude :)
<jdub> lifeless: will this be a problem in future?
<ironwolf> daniels: so it'll be automagic in hoary right? :)
<daniels> ironwolf: sure will
<ironwolf> daniels: EXCELLENT!
<jdub> ooh, nautilus is dead again
<jdub> oh, there it goes
<ironwolf> daniels: now, this battery monitor thing.  Do I need APCI or can I use APM? *currently says 0% all the time. :(*
<daniels> ironwolf: how old is the laptop?
<jdub> no external storage icons though
<ironwolf> P4 2.2Ghz *different machine* couple years maybe...
(bob2/#ubuntu-devel) come on baby use nautilus-spire
<ironwolf> daniels: 2001?
<daniels> ironwolf: you might need to boot with acpi=force
<daniels> ironwolf: alternately, you might need to use APM, yah (acpi=off)
<ironwolf> daniels: where do I set acpi=force? *grub is new to me*
<lifeless> jdub: will what
<daniels> ironwolf: in /boot/grub.conf, and run update-grub
<daniels> ironwolf: there'll be a line like '# kopt="foo"'
<daniels> ironwolf: change it to '# kopt="foo acpi=force"'
<daniels> ironwolf: note that you retain the initial #
<daniels> ironwolf: then run update-grub
<jdub> lifeless: permissions and stuf
<pitti> night, guys
<shaya> any plans to include beagle in ubuntu?
* Kamion gives up on work for the night and goes off to kill the Wizard of Yendor
<daniels> Kamion: summon the police, woo woo woo?
<lifeless> jdub: yeah, all good won't happen again
<ironwolf> daniels: woohoo! thanks.  It works *well 99%, not 100%*
<Matt|> hes gone
<ironwolf> thanks Matt|
<Matt|> np
<Matt|> <-- daniels has quit ("hometime, yo!")
#ubuntu-devel 2004-12-05
<seb128> elmo: nautilus-cd-burner sync please
<herzi> seb128: i work on a gaim-devel now
<seb128> have you contacted the debian maintainers ?
<herzi> not yet
<herzi> i want to have a patch ready that works on my box
<herzi> then i will contact them
<seb128> you should have started by this
<seb128> I think they have perhaps the change ready
<seb128> they were waiting for the debian freeze for this change apparently
<seb128> oups
<sabdfl> night all
<Matt|> nite
<seb128> 'night
<sivang> night sabdfl
(lamont/#ubuntu-devel) elmo?
* lamont bbiab - meeting for a while
<zul> hey
(Kamion/#ubuntu-devel) lamont: can you try kicking off another set of builds of debian-installer 20041118ubuntu2? I fixed the hw-detect bug that broke it just after uploading it
<elmo> Kamion: done
<elmo> night all
<fabbione> morning guys
<mdz> morning
<fabbione> hey mdz
(lamont/#ubuntu-devel) Kamion: will do
<fabbione> Kamion: are you still around?
(lamont/#ubuntu-devel) ENOKEYBUK
<fabbione> heheh
<fabbione> mdz: 3745... not yet :P
* lamont is reminded of just how much he ^&*&*^) HATES perl
<fabbione> ehehe
(lamont/#ubuntu-devel) no daniels either.  hrm.
<fabbione> lamont: something about X?
(lamont/#ubuntu-devel) just gonna pester him about xorg upload with ia64 support.. :)
<fabbione> lamont: it's pending upload
<fabbione> i will kick him today
(lamont/#ubuntu-devel) There are 37 (or so) main packages remaining to be built, most of which are either d-w xorg, or blocked by gcc-3.4
<fabbione> lamont: yeah.. i know..
<fabbione> i will talk to him to do an upload today
<fabbione> or max tomorrow
(lamont/#ubuntu-devel) np - I was just quoting my activity report.. :)
<fabbione> ahah
<mdz> good night, all
<fabbione> night mdz!
<doko> morning all.
<doko> lamont: please let's sort out the libunwind problems for ia64 first, before doing the gcc upload
(lamont/#ubuntu-devel) doko: it won't build until something happens...
(lamont/#ubuntu-devel) cc'ed you on the mail to t-bone telling him what he could work on.
* lamont is trying really hard to not be working on ia64, esp during work hours - other stuff is ahead of it on my tasklist
(lamont/#ubuntu-devel) that is, I'm trying to let t-bone do all the real work.
<doko> lamont: ok
* lamont decides to go to sleep - more merges and bugfixes looming in the morning.
(lamont/#ubuntu-devel) night all
<fabbione> night lamont
<pitti> Morning
<jdub> Keybuk, mdz: http://lwn.net/Articles/111859/
<Keybuk> jdub: cute ... though udevd looks more "interesting"
<Keybuk> as it actually deals with the various races hotplug can introduce
<Keybuk> (remove beating add, for example)
<jdub> yeah, where can i find out more about it?
<Keybuk> lkml, lwn, etc.
<jdub> hrm
<jdub> must of missed it in lwn
<Keybuk> is part of the udev package these days
<Keybuk> it's even in hoary
<Keybuk> syndicate scott% whatis udevd
<Keybuk> udevd (8)            - udev event serializer daemon and udev event sender
<Keybuk> you basically use udevsend instead of hotplug, and udevd does the work in the right order
<jdub> cool
<smurfix> http://linux-hotplug.sourceforge.net/; kernel.org/pub/linux/utils/kernel/hotplug/
* jdub reads man page, is pleased
<jdub> maybe hotplug-ng is gregkh's attempt to fix the hotplug problems though
<Keybuk> jdub: reading his code, it isn't even trying
<Keybuk> he's basically just written run-parts
<jdub> hrm, udevd is not mentioned even as far back as october 28th
<Keybuk> I don't what the ideal final solution is yet
<Keybuk> udevd seems to be the fore-runner, with hotplug-ng C scripts replacing the existing shell hotplug agents
<Keybuk> (you still need all the stuff to do module and firmware loading)
<fabbione> hey Keybuk 
<fabbione> is daniels around there?
<Keybuk> fabbione: he was still in bed
<jdub> Keybuk: so /sbin/hotplug calls udevsend?
<fabbione> Keybuk: ok
<Keybuk> jdub: no, you set the kernel to call udevsend instead of /sbin/hotplug
<Keybuk> udevsend informs udevd of the new event
<Keybuk> and udevd makes sure /sys is populated, creates the device node and runs the /etc/hotplug* scripts for it
<jdub> hrm, positive review of mepis from ladislav in lwn
<jdub> Keybuk: ahh
<Keybuk> udevd also makes sure the events actually happen in the right order
<pitti> Keybuk: btw, /sys/ is automatically populated by the kernel; you mean populating /dev/?
<pitti> Hi sivang!
<Keybuk> pitti: no, udevd *makes sure* /sys is populated
<Keybuk> when the kernel fires the hotplug event, it usually hasn't actually got around to populating /sys yet
<pitti> Keybuk: ah, you mean it waits for the sysfs entries?
<Keybuk> so the hotplug event runs, and has to sit and sleep until the right /sys path shows up
<pitti> Keybuk: this is a nice feature; so far we have too many races because of still missing /sys entries
<Keybuk> indeed
* jdub wonders if simplymepis have permission to ship all the plugin and media foo
<Keybuk> there's also the "add event takes longer than the remove event" issue
<Keybuk> where you plug a device and unplug it quickly
<Keybuk> and the add event is still finishing after the remove event has been fired and finished
<jdub> Keybuk: could udevd use inotify on /sys? :)
<Keybuk> jdub: dunno whether inotify works on /sys -- possibl
* sid77 ciao
<mojo> hi all devel
<mojo> I found prob of RealPlayer that make it not run on Hoary
<mojo> if remove the swfformat.so and swfformat.so in plugins folder
<mojo> and that will fix it
<mojo> just move the swfformat.so and swfformat.so in plugins folder in RealPlayer folder
(bob2/#ubuntu-devel) you should add that to the wiki
<mojo> it's still a bug
<mojo> I'm wondering y swf has prob with Debian
<mojo> ..
(bob2/#ubuntu-devel) you mean helixplayer, right?
<fabbione> hey daniels 
<mojo> no
<mojo> RealPLayer
<fabbione> daniels: when do you plan to upload the next X?
<mojo> is there any relation of swfrender and swfformat in Debian and Ubuntu?
<fabbione> daniels: since you have planned some major changes it is a good idea to start now
<mojo> sorri
<mojo> I say remove not move
<mojo> just remove 2 files
<fabbione> daniels: early breakage will give you more time to fix stuff around
<fabbione> daniels: and ia64 buildds are waiting for you :-)
(bob2/#ubuntu-devel) mojo: where can one get the source for realplayer?
<mojo> http://forms.helixcommunity.org/helix/builds/
<mojo> get the latest src
(bob2/#ubuntu-devel) erm. that's helixplayer.
<mojo> and can u please check the swf plugins
<mojo> there's RealPlayer there
(bob2/#ubuntu-devel) ok.  I'm at work atm, sorry, might have a look later.
(bob2/#ubuntu-devel) someone has ITP'd it for debian, tho, you might want to talk to them
<mojo> it's just acutally Helix Player that is on respo
<mojo> I can't find any RealPLayer there
<daniels> fabbione: today
<daniels> lamont: ping
<mojo> if u know any Debianized package of RealPlayer, please give me the URL
(bob2/#ubuntu-devel) mojo: google: "helixplayer itp"
<mojo> ok
<mojo> what is itp?
(bob2/#ubuntu-devel) intent to package
<mojo> k
<pitti> Hi silbs, hi mvo_!
<mvo_> hi pitti 
<mvo_> hi silbs 
<seb128> morning
<mojo> bob2: it
<mojo> seems to me that's a bug of RealPlayer
<mojo> bob2: and helix-player itp doesn't get involve in Realplayer so they won't give me a hand
<jdub> Our plan is to produce a usable version of beagle that can be shipped
<jdub> as part of SUSE 9.3.  This almost exactly corresponds to the timeline
<jdub> for GNOME 2.10.  We call this goal "Milestone One," and the tasks
<jdub> required to reach that goal are labeled as such in
<jdub> bugzilla.gnome.org.
<jdub> 
<jdub> Keybuk: ^
(bob2/#ubuntu-devel) yeah, robert love went and assigned a bunch of novell people tasks
(bob2/#ubuntu-devel) including "make it not crash all the bloody time"
<Keybuk> jdub: cool, so you think we can sneak that into hoary too? 
<jdub> Keybuk: perhaps we should seriously consider it :)
<jdub> not a lot of dependencies we don't have
<jdub> kernel will be sorted
<jdub> i'm sure we can inspire a new d-bus release
<Keybuk> jdub: yeah, I think it sounds like a goal to me
<jdub> no gsf cil stuff
<jdub> hrm, no evolution sharp
<jdub> weird
<Keybuk> no evo# where?
<jdub> hoary
<Keybuk> ah, is it in Debian?
<Keybuk> that's going to be a tomboy dep too, isn't it?
<jdub> doubt it
<seb128> jdub: is there any plan to upload polypaudio in Debian one day ?
<jdub> seb128: was planning to upload 0.7, but there are problems with it.
<seb128> ok
<jdub> seb128: so working those out with lennart, then it'll go straight into debian and hoary.
<jdub> seb128: want to sponsor it? :)
<seb128> what kind of problem ?
<jdub> b0rked autofoo
* jdub is not fully sold on it for hoary either, yet
<seb128> jdub: for the sponsoring if you want, but I thought it was better to find a non-canonical people ?
<jdub> seb128: i think that's *very* important for becoming a DD, but less important for sponsoring.
<jdub> seb128: i wanted to do it, but it can be harder. :)
<seb128> ok
<azeem> jdub: I can still sponsor polypaudio for you if you want, btw
<fabbione> seb128: thanks for fixing gdm, is that enough for the other gnome-suite as well?
<fabbione> seb128: i have the problem with panels too
<seb128> no panel problem is a libwnck bug, I'm fixing it for Debian right now it should be fixed in hoary as soon as libwnck is synced after that
<fabbione> cool thanks!
<seb128> s/no panel/no, the panel/
<seb128> np
<fabbione> seb128: did i ever tell you that you rock?
<fabbione> ;)
<seb128> thanks :)
<seb128> (you rock too ;)
* fabbione gets red in his face
<fabbione> :P
<seb128> :)
<seb128> hey rburton 
<rburton> hi seb128 
<fabbione> if you think that compiling X is slow.. build the kernel
<jdub> $ gpg --list-keys jdub
<jdub> gpg: WARNING: using insecure memory!
<jdub> ^ should that happen with our gpg?
<fabbione> nope
<azeem> it happens if gnupg is not suid, I think
<jdub> but we have user mlock
<fabbione> azeem: iirc out gpg is patched for that
<azeem> nicey
<jdub> hrm, maybe mjg59's kernel doesn't do that
<fabbione> s/out/our
<azeem> but gnupg drops the priviledges as soon as it got hold of secure memory anyway
<fabbione> and there we go... my laptop has been ubuntified too
<jdub> i love reading people getting angry about "all this attention on a new distribution, that ubuntu thing"
* jdub goes for dinner
<sivang> jdub : well, eat their (red) hats out :) 
<sivang> ;-)
<fabbione> daniels: did you upload all the xorg goodies in the archive? like composite manager?
<daniels> fabbione: NEW
<pitti> Hey, I just got my Warty CD shipment
<pitti> They really look nice
(bob2/#ubuntu-devel) woo
<fabbione> i still didn't.. but hounestly.. i can't wait :P
* sivang is still awaiting his..
<sivang> shipment cds
<pitti> they came too late for the Linux fair here
<pitti> but still there are enough linux freaks in our University :-)
* pitti fondly drapes a cd for each platform on his computer desk
<seb128> elmo: libwnck sync please
<daniels> Kamion: ping
<elmo> seb128: done
(thom/#ubuntu-devel) morning
<fabbione> morning elmo, thom
<fabbione> elmo: do you have any objections to start looking at sparc.u.c ?
<fabbione> elmo: i have started building the "golden debs"
<fabbione> and theoretically i can also upload them
(Mithrandir/#ubuntu-devel) fabbione: crack!  I want my craaaaack.
<fabbione> Mithrandir: soon :-)
<fabbione> Mithrandir: it will take another week or so to finish
<fabbione> + still missing the kernel stuff
* jdub will run it on his 220R :)
<fabbione> and in order to get everything in the proper place we will need to do a bit more stuff after that
<fabiand> hey, someone experienced problems with vconfig and/or the 8021q module?
<fabbione> jdub: after you get main, start building universe you lazy guy :P
<seb128> elmo: thanks
<seb128> hey thom 
<daniels> fabbione: how well set up is linux-restricted-modules to deal with multiple nvidia versions?
<fabbione> daniels: no idea.. i did only the first packaging.. 
<daniels> fabbione: i386/amd64 are 6629, while ia64 is 5336
<daniels> ok
<fabbione> daniels: but i guess pretty well
<fabbione> daniels: 6629 is buggy
<fabbione> you need to patch it
<fabbione> or wait for the next release (better
<fabbione> )
<daniels> how's it buggy?
<lupus_> I know ubuntu does not support sun jvm but a lot of users are using it
<lupus_> http://news.com.com/Java+flaw+could+lead+to+Windows%2C+Linux+attacks/2100-1002_3-5464872.html?tag=nefd.top
(Mithrandir/#ubuntu-devel) daniels: l-r-m handles it ok-ish.
<fabbione> daniels: something about agp
<lupus_> A flaw in Sun Microsystems' plug-in for running Java on a variety of browsers and operating systems could allow a virus to spread through Microsoft Windows and Linux PCs.
* fabbione doesn't use java
<lupus_> should ubuntu warn it's users for this or not?
* RubenV votes yes!
(Kamion/#ubuntu-devel) daniels: pong
<daniels> Kamion: can you please chat to sideshow for a sec about powerpc stuff?
<daniels> fabbione: hooray for nvidia :P
<daniels> Kamion: he's having severe troubles booting his iBook -- both 2.6.8.1 (ours) and his self-compiled 2.6.9 refuse to find his root device?
<daniels> s/.$//
<fabbione> daniels: did i ever claim that they are cool?
<daniels> fabbione: you seem to like them
<fabbione> Kamion: nice work with that ddetect thingy :-)
<fabbione> daniels: gimme multihead without and i will get rid of them NOW
<daniels> fabbione: ati :)
<fabbione> daniels: than gimme the money to change gfx
(Kamion/#ubuntu-devel) daniels: filesystem?
<fabbione> Kamion: this morning i discussed with mdz about creating udebs from linux-source and he convinced me to take the goal for hoary :-)
(Kamion/#ubuntu-devel) daniels: sounds like an initrd problem anyway; I don't know the answer to his problem offhand, but I'd boot with init=/bin/sh and step through it by hand
(Kamion/#ubuntu-devel) fabbione: cool
<fabbione> Kamion: he also told me that you already have some ideas on how to do it
<fabbione> Kamion: should we take a look to it later today?
<fabbione> (i am still building the ccache for the kernel source..)
<fabbione> and i would like to get some lunch before
(Kamion/#ubuntu-devel) ideas> I do?
(Kamion/#ubuntu-devel) it's mostly a linux-source-* build system job, and I don't know it well at all
<daniels> Kamion: ext3, presumably
<fabbione> Kamion: well ok.. but the i think mdz was talking about a way to simply the management of the module lists for the udebs (or something like that)
<daniels> Kamion: the kernel won't find the root FS (i.e. i have no root and i must scream)
<fabbione> s/simply/simplify
<daniels> Kamion: while specifying root=, initrd= by hand also
<fabbione> Err http://people.ubuntulinux.org ./ xcompmgr 1.1.1+cvs.20041109-0ubuntu1
<fabbione>   404 Not Found
<fabbione> daniels: mind to fix you Packages file?
<daniels> fabbione: fix your head :P
<daniels> fabbione: deb http://people.ubuntu.com/~daniels/ xcompmgr/
<fabbione> bah
<daniels> fabbione: alternately, they just got ACCEPTED about half an hour ago ...
<daniels> fabbione: i have fdclock/ also, and a broken transset/
<fabbione> daniels: ok...
<daniels> but working versions of all of the above should be in hoary
(Kamion/#ubuntu-devel) daniels: boot from CD and poke around to see if the initrd's sane?
(Kamion/#ubuntu-devel) fabbione: we have to keep with approximately the layout of linux-kernel-di-*, otherwise merging becomes totally impossible
<fabbione> Kamion: sure, make sense
(Kamion/#ubuntu-devel) fabbione: we should resist attempts to "simplify" it; besides which kernel-wedge is really clever and does a lot of things we want, like converting kernel module dependencies into package dependencies
<fabbione> Kamion: yes.. i was checking kernel-wedge..
(Kamion/#ubuntu-devel) let me dig up Herbert's e-mail from when we last discussed
(Kamion/#ubuntu-devel) this
<fabbione> Kamion: the "hardest" thing to do is to integrate 
<fabbione> #!/usr/bin/make -f
<fabbione> include /usr/share/kernel-wedge/generic-rules
<fabbione> debian/rules (END) 
<fabbione> this ^
<fabbione> into debian/rules for the kernel
<fabbione> Kamion: sure.. please fwd them to me
<fabbione> i really need to cook some lunch
<fabbione> later
(Kamion/#ubuntu-devel) fabbione: there's apparently some complication with depmod
(Kamion/#ubuntu-devel) fabbione: remember that you need a modules.dep for this to work
<fabbione> Kamion: yup.. i read that in one of the notes
(Kamion/#ubuntu-devel) elmo,lamont: build logs on yellow are still in super-noisy mode due to the locale the buildd is using not being configured in the chroot
<elmo> fixed
<elmo> (it was king last time)
<elmo> I either have an old amd64 install cd, or this is broken in warty final
(Kamion/#ubuntu-devel) it's the chroot
(Kamion/#ubuntu-devel) just running debootstrap won't generate locales
(Kamion/#ubuntu-devel) so LANG=<anything but C> will cause this, and we do generally set LANG!=C
<elmo> you sure it's not /etc/environment in the base ?
<elmo> 'cos that's all I did on king.. ;)
<elmo> what I mean is, both king and yellow had an /etc/environmment after a freash warty install
<elmo> (an empty one)
(Kamion/#ubuntu-devel) you've got an old install CD
(Kamion/#ubuntu-devel) I fixed that in base-config 2.44ubuntu25 on 9 October, before final
(Kamion/#ubuntu-devel) however, it should be mostly harmless
(Kamion/#ubuntu-devel) elmo: you need to *generate* the locale as well as just setting it; all /etc/environment does is the latter
(Kamion/#ubuntu-devel) 'dpkg-reconfigure locales' generates them; prebaseconfig does the equivalent of that in d-i
<elmo> no, I just want to wipe it out
<elmo> so we're using C
<elmo> we don't have locales installed on most of our machines
(Kamion/#ubuntu-devel) ah; the installer won't do that for you
(Kamion/#ubuntu-devel) changing it in /etc/environment should certainly do for just wiping out the locale, yeah
(Kamion/#ubuntu-devel) ok, sorry if I was teaching granny to suck eggs, no idea how much you ignore locales in general :-)
<daniels> Kamion: do you have a working dhcpd/tftpboot setup for ibooks?
<elmo> uh - hasn't he got a CD?
<daniels> matter of fact, he has, actually
<elmo> I was going to say, if he doesn't, there's a bazillion lieing around the flat
(Kamion/#ubuntu-devel) daniels: yeah, somewhere
(thom/#ubuntu-devel) down to 2500 unread messages *sigh*
(Kamion/#ubuntu-devel) daniels: booting from CD probably way less hassle though
<daniels> Kamion: jane/lulu had a couple of powerpc cds, as it turned out
<daniels> thom: how many of them were 'where's firefox 1.0'?
<daniels> elmo: 'bazillion', 'two', close enough
(Kamion/#ubuntu-devel) pitti: so, do you make it general consensus that we should at least drop mozilla-browser from the CD?
<pitti> Kamion: yes
<jdub> Kamion: *kill!*
<pitti> Kamion: but there still seem to be too many users/usages for it
<pitti> Kamion: so I would at least leave it in main
(Kamion/#ubuntu-devel) so move to supported?
<pitti> Kamion: the remaining question is what to do with the locale packages?
<pitti> Kamion: currently they are in universe
(bob2/#ubuntu-devel) Kamion: thanks for your help dude
<pitti> Kamion: if we propagate them to main, our future language packs should include them
(bob2/#ubuntu-devel) not actually sure what fucked up, but rerunning ybin worked
<pitti> Kamion: which is kind of a waste
(Kamion/#ubuntu-devel) pitti: dunno; I'm not wearing the mdz hat any more ;)
<daniels> Kamion: that's a pretty big hat
(Kamion/#ubuntu-devel) bob2: ah, ok, cool
* daniels has flashbacks to _Weekend at Bernie's_.
<pitti> Kamion: we have this problem regardless of whether moz is in shipped or supported
<pitti> Kamion: so I don't think it's a problem to move it to supported
(Kamion/#ubuntu-devel) indeed ...
(Kamion/#ubuntu-devel) jdub: from your comment above can I assume you approve? :)
<jdub> hell yeah
<fabbione> Kamion: i will test the new cd tomorrow :-)
<fabbione> Kamion: no problem about it ;)
<fabbione> Kamion: do you mind to check if the current kernel-di-i386 builds properly?
<fabbione> I am getting an error here and i would like to know if it is just local
<fabbione> or something more than that
(Kamion/#ubuntu-devel) fabbione: sure, let me just make a hoary-i386 chroot
<fabbione> Kamion: thanks
(Kamion/#ubuntu-devel) fabbione: what's the error?
<fabbione> debian/ppp-modules-2.6.8.1-3-386-di lib/modules/2.6.8.1-3-386/kernel/lib/crc-ccitt.ko
<fabbione> debian/nic-shared-modules-2.6.8.1-3-386-di lib/modules/2.6.8.1-3-386/kernel/lib/crc-ccitt.ko
<fabbione> some modules are in more than one package
<fabbione> command exited with status 255
<fabbione> make: *** [binary-arch]  Error 2
<fabbione> Kamion: i think the integration is much easier than we think
<fabbione> Kamion: kernel-wedge is well designed
(Kamion/#ubuntu-devel) fabbione: that usually means that crc-ccitt needs to be added to a common package, but I thought I fixed that particular one ages ago; I'll have a look
<fabbione> Kamion: probably a left over from the recent merges?
<fabbione> anyway.. i "just" need a working kernel-di-i386 that i can use to verify my changes
(Kamion/#ubuntu-devel) fabbione: shouldn't think so, it built last time
(Kamion/#ubuntu-devel) fabbione: I'm looking, ok :)
<fabbione> sure
<fabbione> no rush
(Kamion/#ubuntu-devel) fabbione: what version are you using? the changelog says I fixed this in 0.64ubuntu6
<fabbione> -0.67ubuntu3
(Kamion/#ubuntu-devel) and of the kernel?
(Kamion/#ubuntu-devel) fabbione: and of kernel-wedge?
<fabbione> -17
<fabbione> Version: 1.25ubuntu2
<fabbione> in the same order as requested :-)
<queuetue> Hi.  I'm a reasonably good python developer interested in ubuntu - is there a list of low-hanging fruit that needs to be worked on so I could get my toes wet and learn about the ubuntu development process?
(Kamion/#ubuntu-devel) fabbione: that's weird; I can see why it happens, but it didn't happen for me nor for the buildd; investigating ...
<fabbione> Kamion: just tell me if there is anything i can test here
<fabbione> Kamion: only one note: i am not building in a chroot and i have other kernels installed
<fabbione> (if that's relevant)
<sabdfl> queuetue: do you want to become a maintainer, or a contributor on docs and translations?
(Kamion/#ubuntu-devel) queuetue: I'm not sure we have particularly good lists of low-hanging fruit at the moment, unfortunately, other than trawling bugzilla
(Kamion/#ubuntu-devel) queuetue: is there something in particular you're interested in?
<queuetue> Kamion, I'm not picky, but I happen to have a lot of interest in getting jack and professional audio recording/editing easy to use on a linux workstation atm...
<queuetue> sabdfl, I could do the first two, if someone could walk me through the process - translation, probably not - I'm English only. :)
<sabdfl> queuetue: are you a maintainer in any other distro, or upstream on any open source projects?
<jdub> seb128: dude
<jdub> seb128: duuuuude
<jdub> seb128: nautilus 2.9.1 :-)
<queuetue> sabdfl, No, I've contributed over the years to mozilla, python, and the kernel (via kernel-janitors) but nothing large or serious.
<seb128> jdub: I know, I've packaged the CVS this morning and checked with alex that all was ok :)
(Mithrandir/#ubuntu-devel) queuetue: you could always look at the bounty list.
<jdub> seb128: that's going to make hoary fun :)
<sabdfl> what's rocking in the new nautilus?
<jdub> sabdfl: boNObo -> gone :-)
<sabdfl> queuetue: ok, to become a maintainer you basiaclly need
<sabdfl> to demonstrate your ability to package upstream code
<sabdfl> pick a piece of software you have a real interest in improving the package of, or which has not yet been pacakged for ubuntu
<sabdfl> learn about the packaging system, and produce a package
<sabdfl> get feedback from the existing maintainers
<seb128> jdub: not totally :)
<seb128> but yeah, no view anymore, less crappy code :)
<jdub> seb128: it's so close :-)
<sabdfl> queuetue: then, when it's good enough, it goes in and you get to upload packages to universe
<sabdfl> after a while you may also get to upload to main
<elmo> ?! how has a random console based app I alien'ed ended up linked to libarts...
<lifeless> hardlinked ?
<lifeless> or soft?
<pitti> Mithrandir: FYI, I just modified sysklogd to run syslogd as normal user "syslog" instead of root
<pitti> Mithrandir: do you see any problem with this?
<pitti> Mithrandir: it opens the log files as root and then drops to user "syslog"
(bob2/#ubuntu-devel) lifeless: unix filesystems have these things that are kinda like "short cuts" on windows
* lifeless pfffft
<elmo> lifeless: no, as in, 'when you run ldd, it shows the binary is linked to the libarts library'
<azeem> elmo: perhaps it was part of some KDE project, and the build process involved linking against libarts for all binaries without further thinking?
<elmo> aiee, OO.o has some sort of word-completion on-by-default?   how satanic
(Mithrandir/#ubuntu-devel) pitti: who owns /var/log/syslog?
(thom/#ubuntu-devel) OOo is satanic
<elmo> azeem: it's a RAID monitor/configuration program :P
<pitti> Mithrandir: root
(bob2/#ubuntu-devel) 
(bob2/#ubuntu-devel) haha
(Mithrandir/#ubuntu-devel) pitti: note that sysklogd rotates its own logs.
<pitti> Mithrandir: that's the default and I don't want to chage it
(Mithrandir/#ubuntu-devel) thom: no shit.
<azeem> elmo: with a qt-frontend? ;)
<pitti> Mithrandir: oh, since when?
(Mithrandir/#ubuntu-devel) pitti: since forever.?
<pitti> Mithrandir: I always had to add a stanza to /etc/logrotate.conf
<elmo> and CLIPPY!!
<elmo> RUN AWAY
<lifeless> elmo: garh
(Mithrandir/#ubuntu-devel) : tfheen@vawad ~ > grep messages /etc/logrotate.d/*
(Mithrandir/#ubuntu-devel) : tfheen@vawad ~ >
* thom giggles
(Mithrandir/#ubuntu-devel) pitti: and I have rotated messages in /var/log
<pitti> Mithrandir: my logs were never rotated on my box
<pitti> Mithrandir: in logrotate.conf?
(Mithrandir/#ubuntu-devel) pitti: I don't have _anything_ touching files such as /var/log/syslog and /var/log/messages in /etc on my unstable nor my warty box.
<pitti> Mithrandir: /etc/cron.daily/sysklogd 
<pitti> Mithrandir: that's doing it
(Mithrandir/#ubuntu-devel) pitti: ah, true.
<pitti> Mithrandir: it calls "/etc/init.d/sysklogd reload-or-restart "
<pitti> Mithrandir: I modified sysklogd's init script to really restart the daemon
<pitti> Mithrandir: so this works
<pitti> Mithrandir: I already checked that before
* fabbione commits suicide
(Mithrandir/#ubuntu-devel) pitti: I thought it did it itself, but that ought to work, yes.
(Mithrandir/#ubuntu-devel) fabbione: oh, why?
(bob2/#ubuntu-devel) fabbione: can I have your 4 monitors?
<pitti> Mithrandir: I was more concerned about the fact that I write root files as normal suer
<fabbione> daniels: i swear... .. it installed by itself..
<pitti> Mithrandir: I don't see a problem with it right now, but I wanted to have a second opinion
(Mithrandir/#ubuntu-devel) pitti: it drops priviledges after it has opened the files?
<fabbione> daniels: AHHH XPRT ON MY DESKTOP
<pitti> Mithrandir: yes, before it does not work :-)
<fabbione> bob2: forget it
<fabbione> ;)
<pitti> Mithrandir: unless I change the postinst to do some chown magic, but I don't want that
(Mithrandir/#ubuntu-devel) pitti: hmm.
(bob2/#ubuntu-devel) hah
(Mithrandir/#ubuntu-devel) pitti: have you talked with Joey about it?  I don't see any big problem with it per se, at least.
<pitti> Mithrandir: theoretically the syslogd user should be as hard to break as the root user
<pitti> Mithrandir: not yet
<pitti> Mithrandir: I will send him a patch, but Iwanted to have something working 
(Mithrandir/#ubuntu-devel) pitti: I think it's a good idea
<pitti> Mithrandir: btw, if we are at it
<pitti> Mithrandir: I also tried to run klogd as nonroot
(Mithrandir/#ubuntu-devel) pitti: but it won't be able to reopen the files when they are rotated, so you have to restart it.
<pitti> Mithrandir: yes, that's why I modified the init script
<pitti> Mithrandir: I also documented that in the manpage
(Mithrandir/#ubuntu-devel) ok
<pitti> Mithrandir: I tried to drop privs in klogd, too
<daniels> fabbione: it's better than discovering someone INSTALLED XPRINT ON YOUR SERVER
(Mithrandir/#ubuntu-devel) but it blew up?
<pitti> Mithrandir: it opens /proc/kmsg as root and then drops to user
<pitti> Mithrandir: but then I get a permission denied if it reads from the file descriptor
(Mithrandir/#ubuntu-devel) pitti: sounds like a bug
<pitti> Mithrandir: this works with normal files, but obviously not with files in /proc
<pitti> Mithrandir: I thought that, too
<pitti> Mithrandir: but it's hard to circumvent
(Mithrandir/#ubuntu-devel) pitti: fix the kernel? :)
<pitti> Mithrandir: doesn't work for Debian, where half of the users run their own kernels
(Mithrandir/#ubuntu-devel) get the fix upstream, then.
<pitti> Mithrandir: and I don't want to have it break on custom kernels, too
<pitti> Mithrandir: still it will take a while until everybody has the fix
(Mithrandir/#ubuntu-devel) pitti: true enough
<elmo> seriously, does anyone know how to disable OO.o's auto-word-complete insanity?  it's driving me Krazy
<azeem> elmo: please use #ubuntu for general support questions :p
* pitti sings "Another root bites the dust"
<daniels> elmo: hm, I got duplicate ACCEPTED notifications for xcompmgr
<pitti> Mithrandir: thanks!
<elmo> To: Daniel Stone <daniel.stone@canonical.com>,
<elmo>         Daniel Stone <daniels@debian.org>
<seb128> this is annoying, why do we get 2 mails ?
<azeem> wrong use of dpkg-genchanges I guess
<seb128> I don't care to get a mail on my debian email for an hoary upload
(Kamion/#ubuntu-devel) Maintainer: != Changed-By:
(Kamion/#ubuntu-devel) if the Maintainer: field is legal it'll get a mail
(Kamion/#ubuntu-devel) legal i.e. known to Ubuntu's katie
<seb128> ok, so the right way is to use my @debian.org for the uploads ? :)
(Kamion/#ubuntu-devel) either that or don't ever use your @debian.org address for hoary uploads at all and get it taken out of katie's allowed list
<daniels> elmo: nevermind me
(Kamion/#ubuntu-devel) which is what most of us do
<elmo> seb128: I can take your debian.org address out of the whitelist if you want
<daniels> Kamion: hm, I was advised to set Maintainer: daniels@d.o and C-B: d.s@c.c
<daniels> elmo: if you could take daniels@d.o out, that would be phat
(Kamion/#ubuntu-devel) daniels: I meant wrt the allowed list really
<daniels> Kamion: oh, right
(Kamion/#ubuntu-devel) fabbione: ok, something very evil is going on in kernel-wedge here, may take me a while to untangle it
<azeem> daniels: set Maintainer to daniels@d.o in .changes, or in debian/control?
<seb128> elmo: hum, no I prefer to keep it in fact, but thanks. I'll do a mail filter for these rather :)
<daniels> azeem: control
<fabbione> Kamion: ah.. ok.. do you have a simple workaround i can use in the meanwhile?
* fabbione disables composite
<azeem> daniels: it was the Maintainer in .changes which triggered the double mail I guess, you can override that
<daniels> azeem: yeah, but ugh
(Kamion/#ubuntu-devel) fabbione: no, I don't understand it yet, sorry
<azeem> daniels: dpkg-buildpackage reads $DEBEMAIL, so you could set that to @canonical.com perhaps
<fabbione> Kamion: ok no problem.
(Kamion/#ubuntu-devel) fabbione: I've come up with a way to reproduce your problem, and it seems to be a bug in kernel-wedge that I couldn't reproduce it; although I completely don't understand why it fails for you with the current kernel-wedge code
<fabbione> Kamion: do you want access to my box?
<fabbione> Kamion: it's just my devel workstation, if you want to play just tell me
(Kamion/#ubuntu-devel) nah, it's ok, I'll be able to fix the bug without that
<fabbione> ok
(Kamion/#ubuntu-devel) fabbione: oooohhh!
(Kamion/#ubuntu-devel) fabbione: it's locale-dependent; try LC_COLLATE=C
<fabbione> Kamion: AH
<fabbione> Kamion: BINGO!
(Kamion/#ubuntu-devel) [cjwatson@cairhien /tmp] $ sort test
(Kamion/#ubuntu-devel) -b
(Kamion/#ubuntu-devel) a
(Kamion/#ubuntu-devel) c
(Kamion/#ubuntu-devel) [cjwatson@cairhien /tmp] $ LC_ALL=it_IT.UTF-8 sort test
(Kamion/#ubuntu-devel) a
(Kamion/#ubuntu-devel) -b
(Kamion/#ubuntu-devel) c
<fabbione> <- en_DK.UTF8
(Kamion/#ubuntu-devel) that's basically the root cause why you see the problem and I don't; the problem still exists though
<fabbione> ;)
<fabbione> yeah i agree
<fabbione> i can live with C for testing.
<zul> hey
(Kamion/#ubuntu-devel) fabbione: kernel-wedge 1.25ubuntu3 uploading, fixes both the reason I didn't see this and the dependency bug itself
<fabbione> Kamion: ROCKING!
<fabbione> Kamion: i was thinking that for the first merge i will create a dri struct like this to keep merging simple
<fabbione> Kamion: linux-source-<ver>/debian/d-i/arch/
(Kamion/#ubuntu-devel) dri?
<fabbione> s/dri/dir
(Kamion/#ubuntu-devel) ah
<fabbione> and create symlinks to the proper files according to the arch
(Kamion/#ubuntu-devel) if you could basically just copy each linux-kernel-di-* package except for the debian/ directory in there, that would be ideal
<fabbione> Kamion: you can't :(
(Kamion/#ubuntu-devel) why not?
<fabbione> there is the package-list that is clashing :(
<fabbione> otherwise i need to move it somewhere else
<fabbione> or rename it like: package-list.<arch>
(Kamion/#ubuntu-devel) not if you have per-arch directories
(Kamion/#ubuntu-devel) package-list does have per-arch support, but the merging would get complicated
<fabbione> exactly
(Kamion/#ubuntu-devel) I thought you were suggesting just having i386/package-list, i386/kernel-versions, i386/modules/, etc., for each arch
<fabbione> my point was to copy linux-kernel-di-/* in that debian/di/<arch> di
<fabbione> dir
(Kamion/#ubuntu-devel) right
<fabbione> ywah
(Kamion/#ubuntu-devel) if you build it after the linux-image-* packages have been constructed, it should be easy
(Kamion/#ubuntu-devel) set SOURCEDIR to the linux-image-* temporary tree
<fabbione> yup
<fabbione> exactly what i was thinking about
(Kamion/#ubuntu-devel) but depmod has to be run, and that's what Herbert was talking about
(Kamion/#ubuntu-devel) kernel-wedge needs the modules.dep file
<fabbione> yes i read the mails
<fabbione> that's easy
(Kamion/#ubuntu-devel) in fact I notice that there's already a modules.dep file in the linux-image package
<fabbione> correct
<fabbione> but it is simple...
<fabbione> you just call depmod with an arg or 2
<fabbione> i did it before.. i just have to RTFM again to remember how to do it
(Kamion/#ubuntu-devel) um
(Kamion/#ubuntu-devel) the modules.dep file is already in the package, therefore it must be generated as part of the package build process
<fabbione> it's like directory and kernel version
(Kamion/#ubuntu-devel) unless I'm mistaken you shouldn't have to do anything
<fabbione> uh could be yes
<fabbione> s/could/should
<fabbione> so is it ok for you if i use a debian/di subdir?
<fabbione> i don't want to clutter the toplevel since debian lives in the kernel tree already
(Kamion/#ubuntu-devel) yeah, fine by me, make it d-i rather than di I think, or maybe "udebs"
<fabbione> sure
<fabbione> d-i sounds good to me
<fabbione> ok i am off for today
<fabbione> cya later guys
(Kamion/#ubuntu-devel) cool
(Kamion/#ubuntu-devel) heh, I'm just off for lunch
(Kamion/#ubuntu-devel) bye
<daniels> seeya fabbione
<pitti> smurfix: I'm currently discussing the cscope patch with Astharot 
<pitti> smurfix: I have some other objections
<pitti> smurfix: wait for his 3rd patch :-)
<elmo> pitti: btw, <hint type=v. subtle>ntpd still runs as root</> ;)
<pitti> elmo: oh, nice idea
<pitti> elmo: I'll put that onto my todo list
(Mithrandir/#ubuntu-devel) elmo: uhm, is that possible to change?
* pitti fetches the "slash root" axe
<pitti> Mithrandir: why it shouldn't?
(Mithrandir/#ubuntu-devel) pitti: it needs to be able to call adjtimex(2)
<pitti> Mithrandir:        CAP_SYS_TIME
<pitti> Mithrandir: should work
(Mithrandir/#ubuntu-devel)        EPERM  buf.mode is non-zero and the user is not super-user.
<pitti> "Allow   modification  of  system  clock(3,n)  (settimeofday(2),  adj-
<pitti>               timex(2)); allow modification of real-time (hardware) clock"
(Mithrandir/#ubuntu-devel) not according to the man page for adjtimex.
<pitti> capabilities(7)
(Mithrandir/#ubuntu-devel) but it might
<pitti> Mithrandir: yes, all manpages only talk about root, not capabilities
<pitti> Mithrandir: but that's an error of the manpages
(Mithrandir/#ubuntu-devel) file bugs!
(Mithrandir/#ubuntu-devel) :)
<pitti> Mithrandir: I'm currently trying to depriv klogd
<pitti> Mithrandir: I play around with various capabilities
<elmo> Mithrandir: RH has a patch for it - I believe it's even in current Debian source, it just doesn't run as a non-root user for some reason
<pitti> even nicer
(Mithrandir/#ubuntu-devel) pitti: ok :)
<pitti> Mithrandir: next one is X.org :-))
<daniels> elmo: are our kernels NX?
<pitti> Mithrandir: no, not seriously
<daniels> pitti: HA HA HA
<elmo> daniels: no idea
<pitti> my ps aux also shows gpm, but that's not supported
<daniels> elmo: 'kay
(Mithrandir/#ubuntu-devel) pitti: you. are. on. crack. :)
<daniels> does anyone know if our kernels are NX?
<pitti> Mithrandir: with the root slash axe in my hands, I am :-)
<daniels> Mithrandir: there's no WRITE_RANDOM_SHIT_INTO_DEV_MEM capability, sadly
(Mithrandir/#ubuntu-devel) daniels: NX as in nonexecutable?
(Mithrandir/#ubuntu-devel) daniels: it's so wrong that X servers do that.
<elmo> if it still needs ingo's patch, then it won't be in 
<elmo> I'm not sure if mainline does, esp. in 2.6.8.1 era
(Kamion/#ubuntu-devel) Mithrandir: not as bad as the READ_RANDOM_SHIT_FROM_DEV_MEM that they used to do in order to get "randomness"
<daniels> Mithrandir: non-executable
<daniels> Mithrandir: yeah, writing to the video card is for suckahs :P
(Mithrandir/#ubuntu-devel) Kamion: if they happen to hit the area covered by /dev/random, it shouldn't be too bad. :P
<smurfix> pitti: the last version goes into an endless loop if TMPDIR is too long, not to mention that the buffer isn't null terminated.
<pitti> smurfix: argh, you are right
<pitti> Astharot: I'd recommend checking strlen(tempname)
<Astharot> okay
<pitti> Astharot: before strcpy'ing 
<pitti> Mithrandir: argh
<pitti> Mithrandir: reading /proc/kmsg requires CAP_SYS_ADMIN
<pitti> Mithrandir: WTF invented this???
(Mithrandir/#ubuntu-devel) er, that's just Wrong.
(Mithrandir/#ubuntu-devel) CAP_SYS_ADMIN is ~root, isn't it?
<pitti> Mithrandir: nearly as good as root, yes
<pitti> Mithrandir: you can boot, mount, change hostnames, and so on
(Mithrandir/#ubuntu-devel) yeah
(Mithrandir/#ubuntu-devel) reading from kmsg does empty the buffer, though
<pitti> Mithrandir: I tried with less crucial caps, but it doesn't work
<pitti> Mithrandir: it should be something like CAP_DAC_READ_SEARCH
<pitti> Mithrandir: oh sorry, SYS_ADMIN does not allow to boot
<pitti> Mithrandir: but mounting devices is bad enough
<pitti> Mithrandir: I'm not sure whether this is worth the effort then
(Mithrandir/#ubuntu-devel) sounds like an oversight in the kernel
<pitti> Mithrandir: actually there should be an extra capabilitiy for reading kernel messages
<pitti> Mithrandir: it doesn't really fit in any existing one
(Mithrandir/#ubuntu-devel) probably why it was added to SYS_ADMIN, then
<pitti> Mithrandir: it's still slightly better than root
<pitti> Mithrandir: but I think you can get root privileges with mount, too
<pitti> Mithrandir: one could loopback mount a new /etc and thus overwrite shadow or so
(Kamion/#ubuntu-devel) far easier than that
(Kamion/#ubuntu-devel) make a filesystem with a setuid copy of /bin/sh on it, loopback-mount that
<pitti> Kamion: yes, right
<pitti> so I suppose I just leave it as root then
(Mithrandir/#ubuntu-devel) pitti: it'll stop script kiddies, but nobody who knows their unix.
<pitti> not worth the fuss
(bob2/#ubuntu-devel) speaking of which, are we getting a pimp new ppc glibc in hoary?
<elmo> bob2: no
(Kamion/#ubuntu-devel) there's a new glibc in experimental isn't there?
(Kamion/#ubuntu-devel) at least, gotom has been talking about doing that
(Kamion/#ubuntu-devel) hm, not uploaded yet
<azeem> the glibc guys are good at talking :)
<daniels> w
(Kamion/#ubuntu-devel) azeem: that's not really fair to them
<azeem> heh, just joking
(Kamion/#ubuntu-devel) ok :)
<azeem> oh, jbailey is not around, so the pun was not recieved anyway
<[Clint] > they're just on a different timescale than some people
(Kamion/#ubuntu-devel) [Clint] : it's not their fault, it's the release team being evil
(Kamion/#ubuntu-devel) we told them in no uncertain terms to stop pulling from CVS ages ago
(Kamion/#ubuntu-devel) (for sarge)
<[Clint] > they're still on a different timescale
<azeem> yeah, but they could upload to experimental, no?
(Kamion/#ubuntu-devel) azeem: gets difficult as soon as shlibdeps change
<[Clint] > there are other people on that timescale too
(bob2/#ubuntu-devel) but do they want to maintain 3 branches of glibc?
(Kamion/#ubuntu-devel) azeem: anyone installing packages from experimental would have to install experimental glibc too, and before you know it we'd end up effectively trying to support it
<azeem> bob2: woody isn't really a branch
(bob2/#ubuntu-devel) hm, s'pose so
<azeem> Kamion: the trick is to tell sbuild/whatever to only pull from experimental if the Build-Depends explicitely require a version from there I guess
<pitti> smurfix: Astharot just sent another patch
<pitti> smurfix: since I proposed much of this code, would you mind taking a look at it?
<azeem> in any case, did you guys ask the glibc maintainers whether they would perhaps start working on glibc now, get it into hoary first and then into sid once sarge is done?
(lamont/#ubuntu-devel) daniels: this channel's proabbly better...
(lamont/#ubuntu-devel) and yes, I can get you the build tree after
(lamont/#ubuntu-devel) do you want it even for success?
<daniels> lamont: i'm expecting failure, tbh
(Kamion/#ubuntu-devel) azeem: well, they already have started working on it; there's stuff in svn and I see a lot of stuff in my #debian-glibc scrollback
<azeem> ah, cool
<azeem> then bribe them to work faster :)
(tseng/#ubuntu-devel) ergh
(lamont/#ubuntu-devel) daniels: given my email this morning, I understand fully. :-)
(tseng/#ubuntu-devel) does anyone know where to find the debian cramfs-initrd patch broken out?
(bob2/#ubuntu-devel) I'm pretty sure it's upstream in 2.6
(tseng/#ubuntu-devel) ah, thatll do
<daniels> lamont: heh :)
(lamont/#ubuntu-devel) daniels: btw, I see that you already fixed the other 2, so I won't mention them. :-)
* daniels coughs.
(lamont/#ubuntu-devel) anyway, lob me a pointer to source, and I'll throw it against the wall and see if it sticks
<daniels> lamont: just building it now for you
(lamont/#ubuntu-devel) cool
* azeem doesn't understand why Canonical hasn't snatched jbailey yet anyway - He knows the toolchain very well, is cdbs upstream and according to his blog seems to be looking for a new job
<daniels> thom: if the screenshot is no use, please reassign to xserver-xfree86+d.s@c.c and ask for lspci output and /var/log/XFree86.0.log
(thom/#ubuntu-devel) righto
(lamont/#ubuntu-devel) daniels: eta?  just trying to figure out when I should bounce back in front of my computer from the grand install fest in the house...
<smurfix> pitti: I'd dr
<smurfix> oops
* lamont bbiab
<pitti> smurfix: i'd only change the permission to 0600
<pitti> smurfix: otherwise it looks good now
<daniels> thom: (by 'no use', I mean, shows no corruption -> it's a rendering bug)
<smurfix> pitti: OK. I'd use strcpy now, since the length has been tested -- not much point in filling the whole buffer with zeroes, but that's just my preference.
<daniels> lamont: on the way now
(thom/#ubuntu-devel) daniels: you're getting this bug, don't worry ;-)
<daniels> thom: did I say 'my shout tonight'?  whoops ...
<smurfix> pitti: assuming he has actually tested the patch, unlike his first one :-) looks OK otherwise.
<jdub> lifeless: ping
(Kamion/#ubuntu-devel) ok, ifrename stuff is definitely not working properly in hoary
* Kamion cranks up the hotplug debugging
(Kamion/#ubuntu-devel) Warning: Interface name is `eth0' at line 2, can't be mapped reliably.
(Kamion/#ubuntu-devel) Error: cannot change name of eth1 to eth0: File exists
<smurfix> Kamion: well, if eth0 exists, that sortof makes sense...
(Kamion/#ubuntu-devel) smurfix: the real question's why eth0 hasn't already been renamed to something else
(Kamion/#ubuntu-devel) which I think is because it didn't get detected by the installer for some reason, or netcfg just couldn't be arsed to write out the iftab line, or something
(Kamion/#ubuntu-devel) I'd also like to know why events sometimes seem to get lost between hotplug and udev :(
(bob2/#ubuntu-devel) is hal meant to be tcp-reliable?
<daniels> bob2: ... ?
<daniels> bob2: <hal> ah rad, a new bit of hardware! <hal> dbus: yo <dbus> hal: sup <hal> dbus: new mouse, yo <dbus> ALRIGHT SUCKERS, THERE'S A NEW MOUSE <hal> dbus: kthxbye
(bob2/#ubuntu-devel) you should write a book
<daniels> about what?  the fd.o platform?
(bob2/#ubuntu-devel) hah
(bob2/#ubuntu-devel) speaking of which...
(Mithrandir/#ubuntu-devel) daniels: I think we should have an IRC client interface to DBUS.
(Mithrandir/#ubuntu-devel) DBUS-over-IRC.
<daniels> wouldn't be terribly difficult
(Mithrandir/#ubuntu-devel) with aussie dialect?
<ironwolf> daniels: it worked, thanks.
<daniels> 'yo' and 'sup' are not aussie dialect :P
<daniels> ironwolf: rockin :)
<daniels> ironwolf: we'll fix it for hoary, thanks for the debugging help
(thom/#ubuntu-devel) writing unit tests considered boring
* rburton slaps thom with an XP book
<rburton> thom: unit tests are good for your karma, or do you want to come back as a winxp administrator?
(Mithrandir/#ubuntu-devel) thom: you just failed your unit test.
(thom/#ubuntu-devel) just because they're "cool" doesn't make writing tests for correct md5 generation fun :P
<daniels> rburton: shouldn't you have someone pick up the book, hand it to someone who does the backswing, and then another independent person to take care of the foreswing, with unit-tested interfaces between each?
(thom/#ubuntu-devel) Mithrandir: as long as that's not the same as SteveA failing his, that's fine
<rburton> daniels: yes
(Mithrandir/#ubuntu-devel) thom: do I want you to elaborate?
<rburton> daniels: with a mock thom object to confirm that the force of the slap was sufficient
(Kamion/#ubuntu-devel) thom: in the SHOWER
<daniels> rburton: remind me to bring a very heavy book next week ;)
(lamont/#ubuntu-devel) daniels: where?
<daniels> rburton: why a mock one?
<rburton> daniels: just for checking. then replace with real thom in the real world
(thom/#ubuntu-devel) Mithrandir: almost certainly not
<ironwolf> daniels: Where do I suggest changing maxtaptime to 130 as default in xorg.conf for synaptic pads?  bugzilla? or just bonk you? :)
(thom/#ubuntu-devel) no bonking on channel, please
* lamont must run to fix something for his wife... daniels - if you tell me where to fetch from, I'll start that before I leave...
<daniels> lamont: p.u.c/~daniels/xorg
<daniels> lamont: but!! remove debian/patches/000_stolen_from_fedora.diff from the source package
<daniels> lamont: rm != baz rm
<daniels> ironwolf: hmm.  any negative side-effects this could have?
<RubenV> for those interested
<daniels> ironwolf: i assume this is for people who can't/don't complete a tap within 100ms(?)
<RubenV> i've just build cvs packages for beep-media-player
<RubenV> http://files.lambda1.be/linux/
<ironwolf> daniels: well, it works now, didn't really work well before.  It made it so that faster/*normal for me* taps actually were acknowledged.
<ironwolf> daniels: so no, no bad effects.
<daniels> ironwolf: sorry?  i would presume it meant taps could last long
<daniels> ironwolf: e.g. if you tapped for 120ms, it would work now, but not before
(lamont/#ubuntu-devel) daniels: and you want the build dir even for success, yes?
(lamont/#ubuntu-devel) build running.
<ironwolf> daniels: appears to be opposite. *no clue why*
* lamont back in about 90-120 minutes or so.
<daniels> ironwolf: bong
<ironwolf> daniels: bong?
<daniels> ironwolf: 'that's weird'
<ironwolf> daniels: tell me about it... :)
<ironwolf> daniels: that's why I asked.
<eruin> smells like hash
<lifeless> jdub: pong
<lifeless> jdub: shiny gnome syncs
* daniels coughs.
<azeem> " A quiet revolution is taking place on the home desktop market and it's called MEPIS Linux."
<azeem> dudes, you're out of the game
(bob2/#ubuntu-devel) yeah, dunno why we wasted so much time
(bob2/#ubuntu-devel) or why LWN is running press releases
(Kamion/#ubuntu-devel) gnnnnnnnnn
(Kamion/#ubuntu-devel) why does init=/bin/sh give me a blank screen, eh?
(Kamion/#ubuntu-devel) ah, vga=771 seems to be causing issues; yet without it I get a screen too big for my display :(
(Kamion/#ubuntu-devel) I hate Via and all its spawn
<eruin> http://www.mepis.org/node/view/1735
<eruin> take a look at that menu
<eruin> reminds me of some crude mix of win95alpha and a modern linux desktop
<mdz> thom: welcome back
(bob2/#ubuntu-devel) ubuntu's menu just can't compete with that
<eruin> no
<mdz> morning, folks
<robtaylor> eruin: oh my god
<eruin> hehe yeah
* robtaylor marvels
<eruin> pretty horrible innit
<mvo__> good morning mdz 
<chrisa> They made KDE look worse
<robtaylor> that takes some skill ;)
<eruin> yeah, hehe
<daniels> bashing MEPIS considered offtopic
(thom/#ubuntu-devel) mdz: thanks :-)
<daniels> mdz: 'morning boss
(thom/#ubuntu-devel) mdz: i tried to reply to your text, but it seems it got et
<mdz> thom: oh, you received that? interesting
<mdz> thom: I tried to call as well, but it went straight to voicemail
(thom/#ubuntu-devel) yeah, i got your voice mail when i landed
<mdz> but you got the text stateside?
(thom/#ubuntu-devel) yup
(thom/#ubuntu-devel) on the train
<mdz> mvo__: your underscores are growing :-)
<mdz> mvo__: is there a good way for upgrade-notifier to take advantage of APT::Periodic::Download-Upgradeable-Packages ?
<mvo_> :)
(thom/#ubuntu-devel) two hours of fun on the public "transport" system
<mvo_> mdz: sure! I'll add a option for this to the coming preferences for it
<pitti> Hi mdz!
<mdz> mvo_: I guess it will need to prompt for the root password to modify the config
<mdz> thom: which one?
<mvo_> mdz: yes, that's going to be needed
(thom/#ubuntu-devel) mdz: hollywood/western -> LAX
<mdz> thom: oh god
(thom/#ubuntu-devel) yeah
<mdz> I did that once
<mdz> red -> blue -> green or whatever
(thom/#ubuntu-devel) "oh god" covers that pretty well
(thom/#ubuntu-devel) yeha
<mdz> I live near the universal city station
(thom/#ubuntu-devel) and then a free bus
(thom/#ubuntu-devel) oh, right
(thom/#ubuntu-devel) i was trying to work out where studio city was :-)
<mdz> just about 2 hours as I recall
<mdz> and a 20-minute wait at one of the transfers
<mdz> LA transit does have the benefits of the "honor system", though
(thom/#ubuntu-devel) nod
(thom/#ubuntu-devel) and then the fun of the Trillions Standing Around at LAX
(bob2/#ubuntu-devel) 1718 is pretty close to beer o'clock in london
<daniels> honor system?
(bob2/#ubuntu-devel) aiui
<daniels> thom: not to mention the numerous GWB portraits
<mdz> daniels: you just walk on
<mdz> and they randomly ask to see tickets
(thom/#ubuntu-devel) yeah, i didn't get asked in 4 days
(thom/#ubuntu-devel) the bus to santa monica was interesting, too
<daniels> mdz: ah, rad
<daniels> mdz: if you get enough inspectors, it works better than barriers or whatever
(Kamion/#ubuntu-devel) oops, incredibly stupid hw-detect mistake by me ...
(Kamion/#ubuntu-devel) set variable $HOTPLUG_TYPE, test $hotplug_type
<daniels> mmm, i've done that a few times
(thom/#ubuntu-devel) bob2: where is best for you guys?
<mdz> daniels: where are you, anyway?  London?
(bob2/#ubuntu-devel) everyone who's anyone is in london
(thom/#ubuntu-devel) yeah, they're lowering house prices
(Kamion/#ubuntu-devel) the best people are a few dozen miles north
(bob2/#ubuntu-devel) thom: erm, dunno
(bob2/#ubuntu-devel) thom: earl's court high street is right near the hotel tho :)
<daniels> mdz: yah, been here for a week
<daniels> thom: we're at south ken now, we'll be at earl's court later
<daniels> thom: so logically anywhere near those two points, or between, is phat
<daniels> and dope
(thom/#ubuntu-devel) and k-rad?
(thom/#ubuntu-devel) shall i -> sarf ken, then?
<daniels> thom: how long will it take?
(thom/#ubuntu-devel) some time
(thom/#ubuntu-devel) uh, some random time
(thom/#ubuntu-devel) less than an hour
<daniels> thom: if my memory serves me correctly, and it's ~30min, fo'shizzle
<daniels> post-6pm sounds reasonable
(thom/#ubuntu-devel) yeah, that's about right
<rburton> thom: you'll need one of these if you are going down to da hood with daniels -- http://www.theregister.co.uk/2004/11/24/iboom.jpg
<eruin> lul
<eruin> that pod looks so out of place
(thom/#ubuntu-devel) *g*
<daniels> rburton: oh dear
<daniels> ghetto lyf
(Kamion/#ubuntu-devel) hmm, I think I may need to create a pciutils-udeb
(Kamion/#ubuntu-devel) I can't present the names of network interfaces otherwise
<smurfix> Rich , using 
(thom/#ubuntu-devel) right
* thom -> south ken now
(bob2/#ubuntu-devel) rock
<daniels> thom: dope, seeya in a bit
<nmf> dir
<mdz> oh yay, de-rootified syslogd
<daniels> mdz: yeah, pitti went off about half an hour ago, he mumbled something about starting on derootifying X
<azeem> executive review of MEPIS: 12(!) modified packages (mostly alsa, the kernel [without source] , cloop) three new binary-only packages (control/system center, installer) and a themes package
<daniels> kernel modified sans source?
* daniels raises an eyebrow.
<azeem> well
<azeem> there are a couple of patches in /usr/src
<azeem> the dorks in #mepis told me I should get the source at kernel.org
<azeem> but couldn't even tell me it's modified from vanilla or debian
<azeem> of course, they don't ship any of the source for their packages (except glibc, incidently), they refer to ftp.debian.org
<daniels> smooth move
<azeem> 19:14 < darkstego> I am guessing azeem doesn't have access to the private dowload
<azeem> anyway, no match, they just seem to be good at bribing "authors"
(Kamion/#ubuntu-devel) ooh, anything I can GPL clause 4 them for?
<azeem> roblimo wrote a book about MEPIS, but couldn't tell me off-hand their APT-source line ("eh? what for? I'm using a GUI client...")
<azeem> it's 2004.mepis.org/mepis, if you want to have a look
<azeem> (of course, they might have all the source package somewhere else and I did not find it yet, but I doubt that)
(lamont/#ubuntu-devel) daniels: you around still?
(lamont/#ubuntu-devel) seb128: you around?
(lamont/#ubuntu-devel) Preconfiguring packages ...
(lamont/#ubuntu-devel) Can't exec "lspci": No such file or directory at /tmp/libglide3.config.429423 line 74, <STDIN> line 2.
<daniels> lamont: represent
<mxpxpod> seb128: ping
(lamont/#ubuntu-devel) represent?
(lamont/#ubuntu-devel) oh
<elmo> lamont: daniels is stuck in his time warp again - he thinks he's a wapper from the 80's
<elmo> clearly, David Bellamy wasn't insulting enough - I think we'll have to step it up a notch and start calling him Vanilla or VI
<elmo> \o/ [yay for 200 miles of physical distance :)] 
(lamont/#ubuntu-devel) lol
<daniels> elmo: it's been done -- someone did that like two years ago.  mr time warp. :P
<mjg59> They can't just refer to ftp.debian.org
* spotter plays w/ fdclock package
<mjg59> That would only work if we distributed under 3b, which we don't
<eruin> hmm
<eruin> permissions on /dev/nv* are too restrictive all of a sudden
<eruin> any recent updates that might cause that?
<seb128> lamont: yes ?
<seb128> mxpxpod: pong
(lamont/#ubuntu-devel) seb128: was griping about glide
<seb128> I've nothing to do with glide afaik
(lamont/#ubuntu-devel) ah, ok.  It starts with 'g' you see... :-)
<seb128> yep, but this one is not mine :)
<mxpxpod> seb128: have you looked into making a gaim-dev package?
<seb128> mxpxpod: herz1 is working on that, #3959
<mxpxpod> seb128: awesome, thanks
<seb128> np
* lamont goes to install a computer or 3
<herz1> mxpxpod: i think we can close the bug at the weekend
<herz1> .oO(today is criawips hacking day for me)
<mxpxpod> herz1: that's awesome!
<herz1> yes, i want to build a gaim-encryption package
* herz1 files a bug for that
<mxpxpod> herz1: hopefully, that will lead to gaim plugin packages
<mxpxpod> herz1: and a gaim-evolution-plugin package
<herz1> yep
<mxpxpod> herz1: there should probably be a standard naming scheme for gaim plugins
<mxpxpod> herz1: like gaim-plugin-foo
<herz1> yes
<herz1> sounds good
<mxpxpod> cool
<herz1> apt-cache should be happy if we have upstreams package names in the long descrption
<mxpxpod> yeah
<herz1> mxpxpod: 4079
<seb128> feel free to package/maintain it guys
<seb128> herz1: the bug is about getting the package done by somebody or you're saying you'll maintain it ?
<herz1> i can create and maintain it
<seb128> herz1: cool :)
<mdz> Changed-By: Brandon Hale <brandon@localhost.localdomain>
<mdz> tseng: might want to change that :-)
<Keybuk> mdz: Yeah, people who upload with someone else's name in Changed-By are odd :p
<mdz> Keybuk: which of the photo->{html,thumbnails} generators do you use?
<mdz> tseng: if I confused nicks, ignore me
<Keybuk> mdz: NIH
<mdz> gah
<mdz> there are about 50 in Debian, surely one of them is decent
<mdz> I just want something less scary than gallery
<Keybuk> dunno, they all seem to pre-suppose MySQL, PostgreSQL, PHP, etc.
<Keybuk> mine's just a shell script that does some imagemagick and writes out a static html page
<mdz> I've written similar stuff too many times and want someone else to maintain it :-P
<azeem> cthumb is what Keybuk described, except it is written in perl
<Keybuk> heh, at some point I'll probably investigate pyblosxom gallery plugins; that seems to be a good way forward
<azeem> otherwise, gthumb does a good job for publishing albums if you only need to do this once in a while, IMHO
* Keybuk wonders whether f-spot has a publish facility
<azeem> it's at least being worked on, jimmac blogged about that IIRC
<mdz> I'm trying curator, purely because it's python
<mdz> aw, seems to be unmaintained
<mdz> both upstream AND in Debian
<mdz> bins, cthumb, curator, igal, imageindex and album are the ones I see
<mdz> and galrey
<elmo> the more featureful ones seem to have chequered pasts security wise :(
<Keybuk> "Root me, root me, root me with your HTML-embedded scripting language!"
<mdz> elmo: yeah, I just want something simple and non-interactive
<mdz> which I think most of those are
* lamont_ kicks ac97 sound
<mdz> curator produces reasonably nice output
<lamont_> 0000:00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS]  Sound Controller (rev a0)
<lamont_> should that work?
<zul> it should
<zul> i have one
<mdz> lamont_: yeah, it's pretty common
<elmo> I think last time I used igal because it was simple and produced nice multi-size options
<lamont_> mdz: speaker icon in the panel has a red slash through it...
<mdz> lamont_: I know you can dig deeper than that :-)
<lamont_> yeah - digging dammit
<zul> hint...intel8x0
<lamont_> zul: is loaded
<lamont_> SiS SI7012 [alsa mixer] 
<lamont_> sigh.  once you unmute things, you still have to turn up the volume control on the speaker to > 0. :-(
* lamont_ grumbles and wanders awaty
(tseng/#ubuntu-devel) mdz: you caught me
(lamont/#ubuntu-devel) bonnie is now installing warty on her own computer, which has a second hard drive for doing hoary test installs.
(lamont/#ubuntu-devel) that reminds me... gonna need a switch over there now...
* jdub sucks down the new nautilus -> woo
<RubenV> anything special 'bout it?
(tseng/#ubuntu-devel) it seems pretty fast.
(tseng/#ubuntu-devel) like, on hard drugs fast.
<RubenV> if only my mirror wouldn't be broken
<jdub> RubenV, tseng: no more bonobo! (mostly)
<RubenV> ok
<RubenV> let's fix my sources list
<RubenV> gotta have that :)
<sivang> jdub : already in hoary?
<jdub> sivang: yes, seb128 is the master :)
<sivang> jdub : yes he is :)
* sivang auptgrading
<jdub> lamont: aren't we shifting to gcc-3.4 for hoary?
<zul> latewr
<sivang> jdub : does it use any new file search/index system? really fast..
<eruin> new nautilus you say? /me aptgetupdates
(lamont/#ubuntu-devel) jdub: uh, sure... that's a gcc-defaults change, I expect...
(lamont/#ubuntu-devel) atm, we haven't yet.
<eruin> any particular spot I can place flags like mcpu, etc?
<eruin> sorry, wrong channel indeed
<__daniel> anyone else having problems logging into the wiki?
<__daniel> i always get "... connection terminated unexpectedly ..." error messages :-/
<jdub> lamont: hrm, we should probably do that sooner rather than later
(lamont/#ubuntu-devel) jdub: yeah.
(lamont/#ubuntu-devel) that's a doko thing.
* jdub just got his boxes of CDs :-)
<doko> jdub, lamont: we didn't decide on a gcc shift for hoary. with the C++ API change that would mean a lot of diversion in changing package names to reflect the new ABI and integration of somewhat 400 not yet applied patches to sucessfully build with 3.4. Not sure, if we really want to do that.
<Mithrandir> doko: do you think we could have a talk about multiarch in Mataro?
<Mithrandir> doko: like talking together, not holding a speech
<Mithrandir> I want to move forward
<mvo_> hi __daniel 
<__daniel> hai mvo_
<doko> Mithrandir: who was the guy working on multiarch?
<Mithrandir> doko: darksatanic hacked a bit on the dpkg part of it.. apart from that, me. :)
<doko> Mithrandir: yes, I know ;) yes, should be worth half a day or a day.
<elmo> if the gnome desktop background change thing breaks - what's the most likely thing to kick/look at ?
<seb128> elmo: define the breakage
<pitti> Hi guys
<seb128> you change it in the UI and there is no change at screen ?
* pitti is back from concert
<seb128> evening pitti 
<elmo> seb128: right
<jdub> seb128: just uploaded vino + libxdamage-dev
<jdub> seb128: just about to upload howl and gnome-vfs
<seb128> elmo: that's #909, gconf's bug
<seb128> elmo: killall -HUP metacity should do the trick as a workaround
<elmo> pitti: please switch to uploading directly to jackass
<jdub> seb128: unfortunately, the howl change is going to be scary :-)
<seb128> jdub: what's new in gnome-vfs ?
<seb128> oh, howl/gnomevfs
<jdub> (howl dependency)
<seb128> yeah
<seb128> jdub: go go go, we need some scary changes, hoary is getting boring :p
<jdub> this is really scary though
<jdub> because we link so... liberally
<jdub> (libtool's fault?"
<jdub> everything that links to gnomevfs (which means EVERYTHING) will stop working when howl upgrades :-)
<jdub>         libhowl-0.9.6.so.1 => not found
<jdub> ^ FEAR
<seb128> DOH
<seb128> and while I'm thinking about that
* jdub hates liberal linking :)
<seb128> if somebody know an app linking on the old libnautilus2.so let me know
<seb128> since this lib has been dropped :p
<seb128> (abiword was broken due to that)
<elmo> seb128: doesn't seem to have worked :(
<seb128> elmo: killall nautilus if you don't use it atm :)
* Mithrandir hates the new libpng
<jdub> seb128: so how should we deal with this mass b0rk?
<elmo> seb128: that worked, thanks!
<jdub> seb128: lots of package uploads sounds like teh suck to me.
<seb128> elmo: np
<seb128> jdub: thinking about it, that really sucks
<pitti> elmo: I tried, but ftp does not work very well for me
<seb128> jdub: move the issue to #gnome-debian :)
<jdub> ok
<pitti> elmo: but I can route it over my server and upload from there
<jdub> seb128: our problem :-)
<seb128> apparently :)
<seb128> ok, so
<seb128> $ apt-cache rdepends libhowl0 | wc -l
<seb128> 55
<seb128> DOH
<jdub> :-)
<seb128> jdub: so, what's the libhowl lib name now ?
<seb128> libhowl.so.0.... ?
<jdub> yeah
<jdub> 0.0.0 :-)
<seb128> I you did name the package correctly we wouldn't have this problem now :p
* seb128 kicks jdub 
<jdub> heh
<jdub> it was .1 before! and totally broken! :)
<seb128> yeah, crappy stuff should not go in the archive in the first place :p
<jdub> heh
<jdub> we hadn't identified the arse yet, unfortunately :|
<seb128> BTW, the only right solution is the massive rebuild
<jdub> FUN
<seb128> but
<seb128> is it binary compatible with the previous one ?
<jdub> elmo: 
<jdub> PGP/GnuPG signature check failed on vino_2.8.1-0ubuntu2_source.changes
<jdub> gpg: Signature made Wed Nov 24 17:27:31 2004 EST using DSA key ID 565B38F9
<jdub> gpg: Can't check signature: public key not found
<jdub> (Exit status 2)
<jdub> vino_2.8.1-0ubuntu2_source.changes has bad PGP/GnuPG signature!
<jdub> Removing vino_2.8.1-0ubuntu2_source.changes, but keeping its associated files
<jdub> for now.
<jdub> 
<jdub> seb128: i think so - i can check
<seb128> jdub: in which case include a dummy libhowl-0.9.6.so.1 
<seb128> time to rebuild
<seb128> but we need to be sure to not build/link against the dummy :p
<seb128> yeah, that's ugly ... but could avoid apps breakage
<jdub> btw, is your totem crashing on startup atm?
<seb128> gst or xine ?
<jdub> xine
<__daniel> jdub: are you talking about the hoary ones?
<seb128> jdub: it crashes with empty playlists
<seb128> jdub: workaround, start it with an file in argument and keep it in the list :)
<jdub> heh
<jdub> thanks :)
<seb128> np
<jdub> elmo: ping?
<jdub> seb128: that's a reasonable workaround -> perhaps we should wait until after 2.9.2 comes out next week to reduce the rebuild load?
<enrico> Hello.  It appears that we can't log into the wiki: is someone aware of it?
<seb128> jdub: oh, I've a less-ugly solution :p
<seb128> jdub: but longer to get
<enrico> Like... the docteam people are a bit stuck without being able to log into the wiki...
<seb128> jdub: upload a gnomevfs without howl, keep it the time to get the howl depends down and put the new back
<jdub> enrico: please ping elmo
<seb128> ie: 2.9.2 will not depends on howl
<jdub> seb128: bah, that's no fun!
#ubuntu-devel 2005-12-05
<mdke> np
<siretart> mjg59: re: acpi-support on r50e: read the bug report, sounds great. will test tomorrow!
<siretart> gn8 for today!
<jdon1> alright, what's the magical command for finding the source package to a given binary package from the CLI?
<jdon1> trying to figure out what'd need rebuilding for a hypothetical Firefox 1.5 backport :)
<lifeless> apt-cache show binary-pacakge
<jdub> apt-cache show <binary-package-name> | grep ^Source
<jdon1> ok, that make sense
<jdon1> apt-cache rdepends firefox | awk -F\  '{print $1}'  | grep -v "^|" | sort | uniq | grep -ve "desktop" | grep -v "Reverse" | xargs apt-cache show | grep "^Source" | awk -F\: '{print $2}' | awk '{print $1}' | sort | uniq
<jdon1> aaaaahhhh
<jdon1> but it works
<jdon1> :)
<jefferyb> I was wondering if anyone can help... I need to run a script everytime a user logs in onto the desktop, and I was wodering where to put the script so it could run when ever someone logs in...
<jdon1> jefferyb: wrong channel... #ubuntu
<jefferyb> thanks
<majyk> is the backports archive down? Synaptic complains that it cannot stat some files when I add the backports archives to my /etc/apt/sources.list
<jdon1> majyk: what exactly _did_ you add to sources.list?
<jdon1>  |bookmarkbridge
<jdon1>     firefox
<jdon1>   mozilla-thunderbird
<jdon1> how to take out spaces and |'s?
<majyk> deb http://archive.ubuntu.com/ubuntu breezy-backports main restricted universe multiverse
<jdon1> majyk: did you reload synaptic?
<jdon1> majyk: I meant the list (i.e. sudo apt-get update)
<majyk> yes multiple times
<jdon1> majyk: exact error example from Synaptic
<majyk> sorry it's on another computer and it's a bunch of garbage about how synaptic can't stat files pertaining to the backports archive
<majyk> ok the apt-get update worked
<majyk> but the directions on the backport page don't tell you to do an apt-get update
<majyk> maybe that's an understood task
<jdon1> majyk: sorry, it's more of an understood thing
<majyk> haha, yeah
<jdon1> majyk: doesn't the error box in synaptic suggest trying to reload the list?
<jdon1> majyk: if not, that should be addressed for usability :)
<jdon1> it's a very common problem, actually
<jdon1> don't feel bad :)
<majyk> why do I feel stupid while using Ubuntu when I've been using Gentoo for so long
<majyk> each distro has it's own set of shit to remember
<majyk> us.
<majyk> oops
<majyk> browsing us.archive.ubuntu.com mirror with a firefox lists a Ruby 1.8.3 package in main but Synaptic does not list this
<majyk> must not be a breezy package right?
<azeem> majyk: sounds plausible
<majyk> thanks guys
<mhz> jdub: ping
<jdub> mhz: pong
<mhz> jdub: ping
<jdub> mhz: pong again
<mhz> hehehe
<mhz> sorry
<mhz> I thought you were somewhere else, i was
<mhz> jdub: so, will that ML be possible
<jdub> mhz: yeah, gotta catch up with ogra abougt it tho
<mhz> okis
<mhz> jdub: are you in charge of registering IRC channels, as well?
<jdub> nup
<jdub> see the list of ops for #ubuntu
<ogra> jdub, i bet you are in this list :
<ogra> :P
<mhz> ok, and when do you think I can have a y/n answer from you about the ML?
<jdub> i probably am, but i don't register new channels now ;)
<jdub> mhz: unfortunately not tonight (even though ogra is here) because i have to go in a minute
<jdub> ogra: will catch up with you tomorrow or something
<ogra> me too... its about 3am :)
<mhz> jdub: ok, i get it
<mhz> jdub: ogra thx for taking care of this
<toresbe> hello guys :)
<toresbe> Are there plans for a Firefox 1.5 backport to Breezy?
<mhz> no idea, here
<wasabi_> So udev has self destructed on me in some fashion. At boot, the system appears to lock up on Creating initla device nodes.
<infinity> Lucky you.
<wasabi_> Upon some creative working around the problem, I've found it's reading from /dev/.tmp-13-64.
<wasabi_> and blocking
<infinity> Which kernel and which udev?
<wasabi_> latest from dapper.
<wasabi_> Any idea what 13, 64 is?
<wasabi_> So I can fix it heh
<infinity> Are you using a 2.6.15 kernel, or 2.6.12 still?
<wasabi_> eh, good question, checking.
<wasabi_> 2.6.12-10
<wasabi_> didn't see .15
<infinity> And udev 0.060-1ubuntu15?
<wasabi_> Yes.
<wasabi_> My first guess is this is some broken device in my system.
<wasabi_> I just don't know which one.
<wasabi_> and udev should timeout...
<infinity> Kay.  That combination should work fine (does for everyone else), so you're lucky with a capital "L", but there's not a whole lot of point in debugging it, since kernel 2.6.15 and udev 076 should become the defaults within a day.
<wasabi_> Makes sense.
<wasabi_> Still would like to know what device this is. There a easy refernece for min/maj numbers?
<infinity> If it still breaks for you in fun ways after the Update From Hell later, bug Keybuk. :)
<lamont> ogra: missed one spot - sorry.  and then I've had connectivity issues for the last couple days...
<lamont> edubuntu livefs builds running now
<jbailey> mjg59: No script should use takeover, it's for humans only.
<mjg59> jbailey: That's what I thought
<jbailey> mjg59: KErnels before -5 don't use update-initramfs, so that looks like the expected response.
<mjg59> Ok
<wasabi_> Weird
<mjg59> So what should usplash do in that case?
<jbailey> It'll go away as linux-meta is updated.
<wasabi_> 13, is somehow related to input.
<mjg59> Bearing in mind that it may be installed before the new kernel
<jbailey> Probably silently ignore it and do nothing.
<jbailey> The new kernel getting installed will cause the initramfs to be updated.
<wasabi_> jbailey: any clues why udevstart would lock up? 
<wasabi_> =)
<jbailey> wasabi: A bus scan on a fault driver, usually.
<wasabi_> specifically looks like it is blocking reading /dev.tmp-13-64
<wasabi_> Looks like the specific process is '/sbin/vol_id --export /dev/.tmp-13-64
<wasabi_> no man page. =(
<jbailey> wasabi_: udevstart will probably dissapear from dapper in a week or so, so.. =)
<jbailey> mjg59: I need to go pass out soon.  Is there anything else you need on that?
<lamont> ogra: and edubuntu-{desktop,live} are not installable
<jbailey> mjg59: And failing that, Adam's now handling initramfs-tools, so he's likely to be awake sometime soonish.
<infinity> Riddell : Around?
<mjg59> jbailey: Nope, that's cool
<wasabi_> Wonder if I can just kill udev for the time being
<wasabi_> or make it ignore that major/minor
<jbailey> mjg59: Lovely. =)
<wasabi_> So that new pre-dapper stuff available now? :)
<calc> how do you put a computer into suspend mode normally so that it uses the /etc/acpi scripts, besides using the gnome suspend logout option?
<calc> i'm trying to debug why its not working right on my system
<calc> vbetool seems to at least partially work, but something is keeping the system from coming back from suspend
<mjg59> calc: Just call /etc/acpi/sleep.sh
<mjg59> It does a small amount of stuff, calls prepare.sh, sleeps and then calls resume.sh
<calc> ok
<mjg59> calc: What hardware is this? Still amd64?
<calc> yea amd64
<calc> i ran /etc/acpi/sleep.sh and it did nothing apparently
<mjg59> calc: Edit /etc/default/acpi-support and uncomment the second line
<calc> oh oops :)
<calc> sleep in gnome doesn't seem to use that
<calc> note i may disappear if it doesn't come back, i'll log back in
<wasabi_> Where'd isapnptools get to?
<mjg59> wasabi_: Should be mostly superseded by /sys/bus/pnp nowadays
<ccheney> back
<ccheney> it didn't come back
<ccheney> the power light lit back up solid instead of blinking but it didn't seem to come back at all
<wasabi_> mjg59: hmm. nead to relearn ISA in linux I guess
<ccheney> the screen didn't come back and magic sysrq didn't work either
<mjg59> ccheney: Which kernel?
<ccheney> 2.6.12-10-amd64-k8 2.6.12-10.24
<mjg59> Ok
<mjg59> My amd64 only started working with 2.6.15
<ccheney> i could try 2.6.15 i have it installed but the ipw2200 driver doesn't work
<mjg59> Oh. Hm.
<mjg59> Yeah, give the 2.6.15 one a whirl
<ccheney> oh bbia 5min
<ccheney> back
<ccheney> does the same thing, too bad laptops don't have serial anymore :(
<ccheney> is there a way to get output from it in some other way?
<ccheney> as far as to whether it came back at all?
<ccheney> i disabled the video post option since it didn't seem to work at the command line, but the vbe save state does work at least without going into s3 first, tested it out on command line earlier
<mjg59> calc: So with 2.6.15 and running that script, it suspends and then hangs on resume?
<calc> yea
<mjg59> What model is this?
<calc> afaict it hangs so that sysrq doesn't work
<mjg59> No caps lock light?
<calc> hmm yea i have one of those i forgot to check that
<mjg59> Last thing to try is disabling all the video options in /etc/default/acpi-support and try sleeping from a text console
<calc> http://people.debian.org/~ccheney/arima-w720-k8.html
<calc> actually i think the model is w730-k8, its emachines m6809/gateway 74xx
<calc> oh yea i was sleeping from text console but had the video vbe stuff still enabled but not the video post
<mjg59> Ok - disable the video vbe stuff
<calc> ok
<mjg59> /Sometimes/ it can cause hangs
<calc> so without any video stuff i should test the capslock key?
<calc> because the video will be dead, right?
<mjg59> Yeah
<calc> ok will try that out brb
<calc> back
<calc> i think it comes back but without video or keyboard
<calc> the hard drive light blinks a few times after i hit a key to bring the system back
<mjg59> It's probably dying in the kernel
<mjg59> Does it have docking station support?
<calc> no
<mjg59> Right
<mjg59> In that case, you're probably screwed for now
<calc> ok
<calc> i'll probably try causing disk io in the resume.sh later with some sleep stmts to see if i can make it blink to me ;)
<calc> thanks for the help
<mjg59> Heh
<mjg59> Also, search acpi-devel for beep
<mjg59> There's some code for trying to make the system speaker go beep
<calc> ah ok
<calc> hmm i found a list of acpi_sleep options that are supposed to do interesting things to buggy hw
<calc> eg s3_bios ?
<calc> interesting the acpi-devel list states my laptop should work, but perhaps it is only for 32bit mode
<calc> just says vbestate is needed
<mjg59> The kernel options only do stuff that vbetool can already do
<mjg59> (rather more safely)
<calc> ok
<infinity> a) QT takes forever to build
<infinity> b) I'm impatient
<infinity> Pick one.
<Amaranth> a?
<infinity> Could be a bit of both.  I'm undecided.
<calc> got some more ideas to try, bbl
<dholbach> good morning
<pitti> Good morning
<pitti> hehe, nice usplash artwork :)
<pitti> (althouhg I hope that it won't be the final one)
<dholbach> i think it rocks
<dholbach> that's a reason to upgrade to dapper imho
* dholbach will blog about it ;)
<infinity> The final one will be EVER BETTAR.
<infinity> s/EVER/EVEN/
<dholbach> :)
<zyga> morning
* ajmitch_ needs to see usplash artwork
<ajmitch_> oh very smooth
<dholbach> yeah, it rocks
<pitti> Hi zyga 
<siretart> morning
<sivang> morning all
<pitti> Hi siretart 
<pitti> Hey sivang 
<noary> i
<noary> i have problem remaster ubuntu install cd .
<noary> i add package font . but i seem error apt step fail.
<noary> Please answer me.
<noary> if  do you know.
<dholbach> hey seb128 
<seb128> hi dholbach
<zakame> hi seb128 :)
<FireRabbit> howdy
<noary> what is chanel develop?
<hunger> noary: This is not a support channel. Please ask on #ubuntu.
<dholbach> noary: didn't you write this already on the mailing list?
<noary> what is mailing list?
<dholbach> oh sorry, i thought you did, nevermind then
<zyga> noary: try #ubuntu
<zyga> morning mvo
<dholbach> hey mvo!
<mvo> hey zyga, dholbach 
<pitti> Hi mvo, a lovely good morning!
<mvo> pitti: hello! nice outcome of the discussion yesterday, I'm going to do it like this in update-notifier as well
<pitti> mvo: well, it's an easy and imperfect solution, but I can live with it
<mvo> pitti: I like the fact that it's easy. and all the options we had had one or the other problem
<zyga> what are you guys talking about? :)
<Riddell> infinity: hi
<pitti> Hey seb128_
<mvo> Kamion: was my upload of language-selector for breezy-updates rejected?
<seb128> pitti: hey ;)
<infinity> Riddell : I was going to ask you why libqt3-mt-dev.links had been dropped from QT 3.3.5, but it was blocking me, so I just uploaded.
<Riddell> infinity: saw that, thanks for fixing, I'll investigate what happened when I get time
<fabbione> seb128, dholbach: can you please remove type-handling B-D from gnome-applets?
<fabbione> type-handling -> universe
* dholbach pipes innocently
<fabbione> otherwise is FTBFS
* dholbach will take care of it
<fabbione> thanks guys
<seb128> I blame dholbach
* seb128 knows about type-handling :)
<dholbach> haha :)
<fabbione> i blame gtk and gnome team
<fabbione> :)
<mvo> isn't there the saying "you win as a team, you lose as a team" ;)
<ajmitch_> mvo: sure, that's why he blamed the gnome team :)
<ajmitch_> better them than the distro team :)
<fabbione> ajmitch: ++
<fabbione> ;)
<mvo> haha
<ajmitch_> jordi!
<seb128> I blame jordi
<dholbach> haha
<dholbach> ajmitch_, fabbione: it's the DESKTOP! TEAM! *raising awareness*
<ajmitch_> oh sorry
* ajmitch_ should know better :)
<sivang> dholbach: ?
<dholbach> fabbione: done, thanks for the heads-up
<fabbione> dholbach: no problem.. it was my sparc buildd yelling at you ;)
* pitti does the Dapper dance
<pitti> yay, my new language packs *finally* work
<ajmitch_> yay
<doko_> pitti: ping
<pitti> Hi doko_ 
<jordi> wtf!
<siretart> elmo: please sync londonlaw from unstable, overriding ubuntu changes. thanks
<\sh> moins
* fabbione eyes evily the desktop team
<fabbione> so...
<fabbione> why do i get an Edubuntu gdm theme installing a clean dapper?
<sivang> edubuntu takes over?
<fabbione> jordi: do i need to blame you this time? ;)
<\sh> fabbione: edubuntu world domination .. the plan was setteled during a drinking bof at ubz...can't you remember...you agreed ,-)
<fabbione> ehm.. i always remember even when i am drunk :/
<Kamion> mvo: Rejected: no signature found in language-selector_0.0+baz20050824_source.changes.
<Kamion> you should've got mail ...
<siretart> elmo: please sync i810switch from unstable, all ubuntu changes have been merged
<marilize> rob1: hi, what is your email address?
<hunger> Seen the (prelimanary) results of the desktop linux survey: http://www.desktoplinux.com/news/NS5481370522.html
<\sh> fabbione: hehe :) just teasing :)
<hunger> 53% ubuntu;-)
<mvo> Kamion: what about version language-selector_0.1.1?
<mvo> Kamion: from 22.11?
<siretart> Kamion: I'm not excatly sure how to proceed, but I noticed that lbdb (in main) now build depends on libvformat1-dev, which is in universe and thus ftbfs.
<Kamion> mvo: oh, right, sorry, guess I should've checked the date
<Kamion> mvo: language-selector |      0.1.1 | breezy-updates | source, all
<Kamion> siretart: "anastacia" is the tool that gives us automatic reports of such problems
<pitti> siretart: I looked at libvformat, it needs to drop c2man before I approve it
<\sh> elmo: please accept sync requests from zakama and bmonty, they're motus since yesterday thx :)
<Kamion> promotions/demotions are done every so often by elmo or mdz or me, sometimes based on inclusion reports (as pitti alludes to)
<siretart> ah, ok, you already know about that.
<mvo> Kamion: I'll ask mdz later
<mvo> thanks
<siretart> I noticed that it tries to get build since a couple of days
<Kamion> mvo: what do you need to ask him about? it's already in the archive ...
<mvo> Kamion: oh, sorry. it dosn't show up on packages.u.c
<zakame> elmo: hi! please sync kexi, hardware-monitor, ion2, ipkungfu, lessdisks, luxman, and matrem from debian, ok to override ubuntu changes.   Thanks! :)
<\sh> dholbach: ping...https://launchpad.net/distros/ubuntu/+source/xterm/+bug/4724
<sivang> mm, is still utf-8 not working on dapper? 
<viviersf> doko_, is that bug with openoffice and big documents fixed yet ?
<sivang> in terminals, that is
<dholbach> \sh: pong?
<lifeless> there seem to be two synaptic touchpad packages now...
<lifeless> which one is 'latest' ?
<sladen> sivang: utf-8 should work fine.  Do you have enough fonts for hebrew?
<\sh> dholbach: it's more daniels issue
<dholbach> \sh: i thought you were the maintainer now
<dholbach> \sh: you did all the uploads
<\sh> dholbach: yes...but it's not an xterm issue
<dholbach> then reassign it, thanks
<\sh> dholbach: yepp
<sivang> sladen: ah, it does work on the terminal, but now on irssi etc. possibly something wrong with irssi ?
<sladen> sivang /SET term_type UTF-8
<sladen> sivang: and you need to teach screen aswell
<crimsun> ^A:utf8 on on
<sladen> (maybe these should just default by now)
<\sh> hmm...I need xvbf-run which is missing in action
<mjr> screen should understand an utf-8 locale setting just fine. Not sure about irssi, I thought it did tho. term_type may be needed.
<sivang> I can see now hebrew letters and type, but acutally inputting them is all broken. That is, I get 1 out of 10 letters typed shown etc
<mjr> hmm, oh yeah, actually, irssi has a problem with full width characters; are hebrew ones like that?
<\sh> dholbach: grmpf...forget it :) 
<\sh> dholbach: damn changes
<sivang> mjr: what do you mean full width?
<mjr> sivang, double the width of normal ascii chars
<sladen> sivang: 'double-width'
<sivang> sladen: I think so
<sladen> sivang: Hebrew , hmm.  For me those are 6 and 5 'squares' wide
<sladen> and that worked just fine through gnome-terminal->ssh->screen->irssi
<mjr> yeah, normal half-width it seems
<sivang> sladen: I got QY
<lifeless> yah, I got them too
<mjr> 'course, irssi doesn't do rtl at all :)
<lifeless> uxterm->ssh->screen->irssi too
<lifeless>  
<sivang> mjr: it doesn't (so I usual type backwards) but it used to display every char correctly on breezy
<lifeless> round trips fine too ;)
<mjr> sivang, ok
<mjr> some regression then :I
<sivang> sladen: how do you know if a non latin char is half/double width ?
<mjr> sivang, wcwidth() :] 
<sladen>  , , interesting, it gave me a double width entry cursor after pasting those, but the display got out of sync and require a ctrl-L to fix it
<mjr> sladen, yeah, that's the way irssi "handles" it
<sladen> and even that didn't match what came back again (two commas)
<mjr> (the cursor is just a terminal thing, irssi doesn't know about that)
<mjr> ...now, if irssi just used readline :)
<sivang> sladen:  W\uffff\\uffff^ <-- this is what I got
<pitti> 'Wuff', nice :) sounds like a dogg
<sivang> hehe
<pitti> s/g$//
* mdke hussles elmo some more for the docteam svn account for bhuvan
<sladen> sivang: I think something along the line assumes you've got 8bit mapping and is trying to convert the highbit into a W and then finding out that it can't convert the rest.
<janimo> will hotplug, grepmap and pcmcia-cs be kept in dapper?
<Kamion> janimo: hotplug won't, grepmap will, pcmcia-cs probably won't but does need to stay there for now while we figure some other stuff out
<siretart> wow fun. ld segfaulting on ia64
<janimo> what is the reason for grepmap staying?
<Kamion> janimo: it's going to be adjusted a bit and used for some cases where the kernel doesn't expose useful MODALIAS
<janimo> thanks
<Keybuk> grepmap?
<Kamion> yes
<janimo> yes
<Keybuk> yeah, if you look at http://people.ubuntu.com/~scott/software/grepmap/ there's a new 1.1.0 release of it
<Keybuk> it supports a "grepmap --udev" option that reads the environment rather than the command-line
<janimo> and the kernel can't do it or just won't export that in dapper timeframe?
<Keybuk> so we can do: SUBSYSTEM=="input", PROGRAM="/sbin/grepmap --udev", RUN+="/sbin/modprobe $result"
<Keybuk> well, the kernel hasn't yet done modalias for the input subsystem ... I guess it's a "tricky" one and might come later
<Keybuk> but I don't know for certain that it ever will
<janimo> hmm I thought 2.6.15 was supposed to take the input subsys to the same level as the rest
<Keybuk> there's also the use case: SUBSYSTEM=="usb_device", PROGRAM="/sbin/grepmap --udev --file=/etc/udev/libsane.usermap", GROUP="plugdev"
<pitti> Keybuk: I don't think we'll need it for sane
<Keybuk> pitti: no?
<pitti> but it's good to have it as a backup
<pitti> Mithrandir merged the package yesterday, and IIRC the udev rules are generated in debian/rules
<Keybuk> janimo: 15 certainly updates it to driver-core
<Keybuk> but not modalias yet
<Mithrandir> I haven't uploaded it yet, iirc
<pitti> no, we both need the new udev (hint, hint)
<Keybuk> I guess infinity hasn't uploaded lrm or -meta for 15 yet then?
<pitti> yay long dependency chains :)
<Keybuk> I gave him signed ready-to-upload binaries on Monday, in case he was ready yesterday while I was away
<Keybuk> s/binaries/sources/, s/empty cup/coffee/
<Kamion> Keybuk: no, he's doing final lrm testing
<janimo> ogra, ping
<ogra> janimo, pong
<janimo> does hwdb-client use gnome stuff besides gtk?
<ogra> yup
<janimo> I'm thinking if it could be used with xfce
<ogra> but i planned to change that ...
<janimo> that would be nice
<ogra> it uses the gnome_sound_play function for the sound test
<janimo> aha
<janimo> maybe just an aplay or something would do?
<ogra> might also be other stuff in there, havent visited the code for some time
<ogra> i'll try to fix that for dapper
<ogra> fabbione, eh ? 
<janimo> ok, thanks
<ogra> fabbione, if you dont have edubuntu-artwork installed that cant be ....
<janimo> ogra, oh btw that focus bug with the next button in hwdb-client is it  a gtk bug?
<ogra> yup
<janimo> needing to click outside of the button
<ogra> it only happens on some desktops ...
<janimo> is it _that_ hard to fix? I'd have thought that's elementary GUI widget foo :)
<ogra> i have no idea why ... (happens on 2 of 5 systems i have here)
<janimo> feature I mean
<janimo> mine too
<janimo> do you know if there's a gtk bug filed?
<ogra> yes, it is that hard to fix, since its not reliable reproducable
<janimo> k, thanks
<janimo> does it happen witrh gnome on your systems?
<ogra> i'm not really sure its a gtk bug, it might be a input bug, a X bug or even something else ...
<ogra> yes
<ogra> i have gnome on all systems here
<janimo> well good thing it's not a gtk bug then
<ogra> i dont know ...
<ogra> it might or might not be one ...
<janimo> ok
<ogra> or it might be caused by combinations of gtk and the input or gtk and the graphics driver ...
<janimo> if hwdb-client is not among your top prios I may take a look at it too sometime
<ogra> i'd have solved it already if it would be that easy
<janimo> maybe there should be a hwdb-client-client app, which asks you whether the next button works, and reports back with X.org info :)
<ogra> i promised zyga that i'd put up a bzr archive of it during the week, pleas use that one ... i'll ping if its there
<janimo> great
<viviersf> soz for the OT
<viviersf> but does any1 have mary janes at hbd no here plz
<fabbione> ogra: seriously.. i just did a standard dapper install
<siretart> elmo: please sync helix-player from unstable, ok to override ubuntu changes. thanks
<sivang_away> fabbione: flight 1?
<dholbach> hi carlos 
<dholbach> hi carstenh :)
<carlos> dholbach, hi
<dholbach> carlos: how are you?
<carlos> dholbach, fine, thanks
<carlos> and you? 
<dholbach> cool :)
<carlos> dholbach, I don't see your question about launchpad's email at #launchpad.... :-P
<dholbach> me too, just a bit tired :)
<dholbach> argharghargharghargh :)
<fabbione> sivang_away: no. today netinstall
<pitti> Hi Yagisan 
<sivang_away> fabbione: k
<Yagisan> G'day pitti !
* mdke nudges dholbach about uploading ubuntu-docs, yelp is now working
<dholbach> mdke: right
<carstenh> hi daniel, hi pitti :)
<Yagisan> how have you been pitti ? I've been busy - My son was born on the 18th, so I have chronic lack of sleep.
<pitti> Hi carstenh 
<pitti> Yagisan: contratulations to your son!
<pitti> Yagisan: I'm still busy with fixing Ubuntu ;)
<mdke> is it intentional that the web browser button on the top panel opens firefox, rather than the defaul browser as set in preferences->preferred applications?
<mdke> defaul/default
<Yagisan> pitti: thanks, he was huge. 3.6kg
<mdke> congrats Yagisan :)
<pitti> wow :)
<pitti> Yagisan: so the poor Windows machines out there are a little safer for now? :)
<pitti> Yagisan: when you spend time with your son instead of cracking Win machines
<Yagisan> pitti: sadly, they are safer, for now. But I now have two apprentices in training :)
* sivang_away .oO( pitti and Yagisan craking windows machines?...)
<Yagisan> sivang_away: My day job
<sivang_away> oh, lol
<\sh> Yagisan: congrats to your new duties :) 
<Yagisan> thanks \sh :)
<\sh> Yagisan: where are the photos :) and where is the cigar for all ubuntu devs? ;)
<jordi> Yagisan: ditto, congrats for that!
<jordi> \sh: Ubuntu is officially a smoke free area!
<Yagisan> \sh I haven't scanned the photos yet. I don't smoke, so sorry - no cigar
<\sh> jordi: hmmm...you should come to germany...last time when the baby of my colleague was born he just spread a bunch of nice cuban cigars for everybody :) it's somehow a tradition
<pitti> jbailey: the new langpacks and the langpack-locales are ready for upload
<pitti> jbailey: I guess I should wait for the new belocs-enhanced glibc?
<fabbione> seb128, dholbach: glibmm2.4 is FTBFS
<\sh> infinity / lamont: can you have a look on debtags-edit 1.1.2...it was given back to amd64/i386/ppc but only ppc had been build
<jbailey> pitti: Yes, I'm slightly lagged there, but I'll work on that this morning.
<dholbach> fabbione: looking
<jbailey> infinity: Around?
<fabbione> hey jbailey 
<fabbione> jbailey: theoretically from today you can install directly on LVM (ppc)
<pitti> jbailey: oh, good morning :) I didn't expect you to be awake already
<fabbione> it's the worst code ever, but it works just fine :)
<pitti> oh, it's well past noon - time for lunch :)
<jbailey> fabbione: Yay!
<dholbach> fabbione: argargarg
<jbailey> pitti: My core hours start about 20 minutes ago.  I don't hop on IRC first thing, I usually do upgrades and make a pass through email first. =)
<fabbione> dholbach: i still blame the desktop team :P
<dholbach> excellent :)
<jbailey> dholbach: You know you're successful when people start blaming you rather than ignoring you? =)
<dholbach> jbailey: that's what i thought too - that's more publicity (and thrilling opportunities for involvement) in the *bling* DESKTOP! TEAM! *bling*
* Kamion wonders if ubuntu-devel-announce@ is the right place for "new mailing list" announcements - maybe they'd be better batched up
<dholbach> fabbione: fix uploaded - merci
* Keybuk hugs dholbach, rather than blaming him
<jordi> jdub: ping
<dholbach> Kamion: hmm, the mails contained specific information on both of the teams - that's why i split them up
* dholbach hugs Keybuk back :)
<dholbach> Kamion: but if you decide to reject the mail, i accept your decision
<tepsipakki> just tried daily netinstall, but it still won't install dapper? (preseeded "d-i mirror/suite string dapper")
<tepsipakki> instead it installs breezy
<mdke> the new desktop menu organisation makes no distinction in the System->Admin submenu between programs (eg network-admin) which require admin privileges, and those which don't (e.g. system monitor). I preferred the old distinction with system tools in the applications menu :(
<tepsipakki> hold on, I think I made a mistake..
<tepsipakki> I was on crack.. somehow the netboot still loaded breezy. dapper works fine ;) I noticed that hotplug discovers interfaces in the "correct" order (wired before wireless)
<tepsipakki> which is nice
<HiddenWolf> is it design or a bug in ubuntu.com that the planet button only shows up when you're on the wiki?
<mdke> HiddenWolf, bit of both I think
<mdke> actually, more design
<siretart> could anyone please NEW libxml++2.6? I need it for c2a transition of another library package
<seb128> dholbach: for you :)
<dholbach> seb128: he uploaded it already
<seb128> oh, k
<pitti> Kamion: I did the changes to the locales package and langpacks, i. e. locales are now shipped in langpacks, and the 'locales' package uses /var/lib/supported.d; is there anything I need to do to unbreak the installer?
<siretart> elmo: please sync xmltv from unstable, overriding ubuntu changes
<seb128> mdke: feel free to join #ubuntu-desktop for discuss issue like your epiphany feature about focus on new tab :)
<lamont> ogra: livefs build is now scheduled (missed one spot), but it doesn't build atm
<mdke> seb128, ah cool thanks
<jbailey> Kamion: When you're counting your merge stats, how do I mark one as not-mergable from Debian?
<jbailey> Kamion: lkh doesn't share a source between the two.
<Kamion> jbailey: I just did a bugzilla search, nothing special
<Kamion> jbailey: is it possible to make the version number higher?
<Kamion> jbailey: failing that you'll have to talk to Keybuk
<Keybuk> mark the bug RESOLVED INVALID
<Kamion> pitti: I'll have a look at it later; the installer will break today anyway
<Keybuk> then ask elmo to blacklist it from the sync process
<jbailey> Kamion, Keybuk: Thanks.
<ptlo> neuralis 'lo
<pitti> lamont-away: any idea why cyrus21-imapd does not build on hppa? it's the only package/arch that still keeps ucd-snmp in main
<jbailey> Riddell: Thanks for grabbing the cdbs merge.  I'll close 19134 for you.
<Mithrandir> pitti: uhm, what do I put in "source code review" for bootchart?
<pitti> Mithrandir: main inclusion report?
<Mithrandir> yes
<Mithrandir> sorry for not giving you context.
<pitti> Mithrandir: oh, don't worry too much about it; the MainInclusionReportTemplate just covers all cases
<Mithrandir> so just remove that?
<pitti> Mithrandir: for new libs etc. it makes much sense, e. g. I discovered some buffer overflows in libgpod
<siretart> elmo: please sync xpdf from unstable, overriding ubuntu changes
<pitti> Mithrandir: since bootchart is not really security critical, feel free to remove it
<Mithrandir> pitti: thanks.
<pitti> Mithrandir: I usually look at unprotected mallocs, array out-of-bounds, sprintf()s, and the like - the usual suspects
<pitti> Mithrandir: but it's only important for libs/apps that deal with user dat
<pitti> a
<Mithrandir> pitti: yeah, though, bootchart is a java app which renders data, and a set of shell scripts, so no many buffer overflows.
<pitti> hehe
<ogra> meh, where is udev ... all other intresting parts are uploaded ... :/
<fabbione> ogra: where are the patches?
<ogra> fabbione, i thought Keybuk was ready already
<ogra> fabbione, what was the thing with edubuntu GDM theme ? 
<fabbione> ogra: he probably is and he is going to upload as soon as you will go to sleep ;)
<fabbione> ogra: dunno.. installed dapper and got that one
<ogra> pfft ....
<fabbione> no kidding
<infinity> udev is ready, It'll get uploaded when we're pretty sure the world is ready to change to the new kernel.
<fabbione> i didn't investigate it yes
<ogra> so around the time you stand up ? 
<infinity> (ie: once LRM has built, etc)
<ogra> yay
<tashiro> Does anyone know when will libgnomevfs 2.13.2 will enter drapper?
<HiddenWolf> tashiro: dapper!
<tashiro> Or dapper the drunken duck
<doko> viviersf: which bug?
<WaterSevenUb> jbailey, let me know if you need clarification on this http://bugzilla.ubuntu.com/show_bug.cgi?id=18050
* jbailey looks
<jbailey> dholbach: There?
<dholbach> jbailey: yes
<jbailey> dholbach: 18050 is ubuntu-docs breakage with languages.  Would you mind taking a look at it?
<dholbach> yes, can you CC me on it?
<dholbach> because i was just about to go for a dogwalk :)
<jbailey> dholbach: I was hoping to put you in the assigned field. =)
<dholbach> go ahead
<jbailey> Enjoy your walk, we can chat when you're back. =)
<seb128> I'm sure than dholbach has a dog only to get a pretext for all those walks he does in the day :)
* seb128 runs
<jbailey> seb128: Sure.  It's like I thought of taking up spoking at UBZ so I could get out of the basement.
<jbailey> smoking, rather.
<dholbach> seb128: i'm happy to get out more often because of the dog :)
<sivang_away> well, it's good enough to do that. I bet it can help you be more productive
* jbailey wonders if LP will make assigning bugs suck less, since it actually knows all of the email addresses.
* sivang_away --> food
<jbailey> dholbach: Done, thanks.
<WaterSevenUb> jbailey, thx.
<jbailey> WaterSevenUb: =)
<Kamion> jbailey: you don't have to know the e-mail addresses in bugzilla either; just a substring will do
<Kamion> if it's ambiguous it'll prompt you
<Kamion> (substring of name <email> that is)
<jbailey> Kamion: Ah, neat.  Thanks.
<jbailey> So failing everything I can type "ubuntu.com" and get a list to choose from. =)
<Seveas> jbailey, evil :)
<jbailey> JaneW: Have you been spreading rumours about me again?
<JaneW> jbailey: perhaps...
<siretart> elmo: please sync ire, xine-ui, superkaramba and zorp, all from from unstable, overringing ubuntu changes. thanks
<sivang_away> JaneW: did you get my PM ?
<\sh> siretart: stop superkaramba
<\sh> siretart: please discuss with riddell if he is ok with it...
* ogra goes looking for his earplugs before the overringing starts
<ogra> Kamion, any idea how the new pcmciautils cope with ndiswrapper based cards ? 
<zyga> is the dapper backup solution anywhere off the ground?
<siretart> zyga: you mean sbackup?
<ogra> infinity, ping
<ogra> infinity, no ndiswrapper in l-r-m for amd64 ? :/
<ogra> oh, infinity unping ... its supposed to be in linux-image iirc ...
<zyga> siretart: probably, I mean the gui for  some existing backup tool
<ogra> BenC, ^^^ ?
<BenC> ndiswrapper is in the kernel
<ogra> hmm, ndiswrapper utils isnt installable here ...
<ogra> depends on ndiswrapper-modules-1.5 ...
<BenC> sounds like something else needs to be updated for kernel version
<siretart> l-r-m didn't update madwifi?
<ogra> yup
<BenC> can you track it down and see where it is?
<jdub> ooh, l-r-m for 2.6.15
<ogra> looks like Keybuk did the last upload, i'll ask him
* jdub is very tempted to upgrade
<jdub> stupid quebecistani laptop requires it :-|
<Keybuk> ogra: I only made editorial changes
<ogra> jdub, i think you should wait for udev too :)
<Kamion> ogra: not offhand
<ogra> oki
<ogra> Kamion, thanks will test as soon as i can ... 
<jdub> oh man
<jdub> someone added a first startup druid to rhythmbox
<ogra> EEEK
<Robot101> thats been there ages
<Treenaks> you've just not started it for the first time in ages ;)
* ogra didnt notice it either
<ogra> (for ages)
<jdub> yeah
<jdub> stupid new laptop fascism
<jdub> meanwhile, that druid is a criminal offense
<ogra> heh
<Amaranth> muine does it too
<HiddenWolf> it's a rather accepted practise for music players.
<jdub> it's one step short of amarok's "mysql or sqlite?" question
<Robot101> the UI has enough other gash in it, the druid is the least of the problems
<jdub> breakfast time though :)
<Robot101> like the right click menu in the list of playlists. can you make a playlist? no. you can add music to your library. how useful.
<HiddenWolf> jdub, you're kidding on the mysql question, I hope...
<jdub> HiddenWolf: nup
<HiddenWolf> jdub: *shocked*
<Robot101> HiddenWolf: amarok lets you choose like "gstreamer, MAS, NAS, ALSA, OSS, ALSA, esound..." :P
<HiddenWolf> Robot101: shudder!
<Robot101> it's a feature!
<ogra> a "mysql or sqlite?" question ? whats that ?
<Kamion> I have to say I'm not sure our "esound! no, polypaudio! no, esound! no, ALSA!" flip-flopping on defaults is much less confusing sometimes :P
<HiddenWolf> ogra: should I store your music this way, or that.
<ogra> eeek
<HiddenWolf> Kamion, even windows can't make the sound sub-system easy, Don't sweat it.
<ogra> Kamion, but the gui tool should just jump on the running bit here :)
<HiddenWolf> Kamion, took more work to get my audigy to play under winxp than ubuntu, I swear. :)
<ogra> BenC, re ensidwrapper, the prob is the provides line in linux-image-2.6.15-5-amd64-k8, it refers to ndiswrapper-modules-1.1, ndiswrapper-modules-1.5 is recent
<dholbach> did anybody report that cpu freq scaling is broken on 2.6.15-5-amd64-k8 already?
<mvo> BenC: did you got my message about the "failed to download firmware" for the 76c503 driver in 2.6.15-5?
<BenC> ogra: ah, so I need to fix it, ok
<BenC> mvo: new udev fixes that
<BenC> mvo: firmware location changed
<dholbach> BenC: any idea about the cpu freq stuff, or was that, what udev changes related to?
<BenC> dholbach: what cpu freq stuff?
<dholbach> BenC: cpu frequency scaling doesnt work with 2.6.15-5-amd64-k8 any more
<mjg59> dholbach: Works fine here
<dholbach> hrm
<mjg59> Though this is amd64-generic
* dholbach will try that one
<mjg59> model name      : AMD Turion(tm) 64 Mobile ML-28
<mjg59> cpu MHz         : 798.051
<BenC> if it works on -generic, let me know so I can compare config's
<BenC> they should be matching though
<dholbach> will do
<xhaker> modprobe -Q option got deprecated?
<xhaker> modprobe: unrecognized option `--help' :)
<Keybuk> xhaker: it was an Ubuntu patch, and we stopped using it
<xhaker> then just upload a new powernowd package it relies on it
<xhaker> i mean.. if it's in the plans
<xhaker> don't wanna sound demanding
<Keybuk> it doesn't seem to on my machine?
<xhaker> just noticed hotplug needs the same love :P
<ogra> Keybuk, 
<ogra> if [ "x$VERBOSE" = "xno" ] ; then
<ogra>         MODPROBE_OPTIONS="$MODPROBE_OPTIONS -Q"
<ogra>         export MODPROBE_OPTIONS
<ogra> fi
<xhaker> yeh
<xhaker> remove that
<xhaker> :P
<Keybuk> oh eww
<ogra> from powernowd init
<Keybuk> I missed that
<Keybuk> I shall put the patch back then :)
* ogra uncomments before rebooting to -5
<ogra> xhaker, good catch, thanks :)
<xhaker> in hotplug too :P maybe hotplug is not that important since you're going to replace all by udev
<Keybuk> yeah, I should probably make udev use it
<ogra> xhaker, hotplug might not survive the week :)
<xhaker> yeh.. i know :P
<ogra> depending on bugs :)
<xhaker> i'll just "patch" it myself
<xhaker> scott is working on udev right?
<ogra> its done afaik .... just waiting on the pieces it depends on
<xhaker> Keybuk, you're going to put -Q back? or edit the packages that depend on that option?
<xhaker> ogra, 
<xhaker> btw..
<xhaker> but this i think you already know
* ogra is all ears 
<xhaker> in firmware.agent of the hotplug package the should be added a new location for the firmware /lib/firmware/$(uname -r)
<Keybuk> xhaker: put -Q back
<ogra> i'm luckily not in charge of this :)
<xhaker> of course, again... the new udev  will have it and i don't think you'll upload any hotplug package before :P
<xhaker> hehe
<Keybuk> yeah, there's no plans to update hotplug
<xhaker> i had to figure it out without my wireless how to make it load the firmwares, grr
<xhaker> :P
<Keybuk> copy them into /lib/firmware
<xhaker> i've already said i fixed hotplug.. it now searches in /lib/firmware/$(uname -r) too
<xhaker> correction: i fixed that bit
<xhaker> lol
<WebWiz> what the heck is going on in #ubuntu
<xhaker> lamers
<WebWiz> heh, ubuntu is getting too popular now when we get people like that in there :)
<dholbach> BenC: false alarm, after the change to the powernowd init script it was happy
<xhaker> dholbach, you thought it was the kernel?
* dholbach hugs the Kernel Team
<dholbach> xhaker: yeah, it was the only change i remembered
<sivang> hmm, Deer Park doesn't offer me to use evince to open a pdf, but gpdf which crashes. nice
<BenC> dholbach: cool
* ogra grumbles about wrongly reported main bugs in launchpad ....
<ogra> how do i make them duplicates of bugzills bugs grr
* dholbach grumbles about wrongly reported main bugs in launchpad, bugzilla, upstream bug trackers, ...
* mdke grumbles about mailman delivery errors
<dholbach> ogra: just add a "remove watch"
<dholbach> ogra: just add a "remote watch"
<ogra> dholbach, just add a "remote watch" ?
<ogra> dholbach, just add a "remote watch" ?
<ogra> will do :)
<dholbach> ogra: i typed it wrong in the first attempt
<ogra> but the first would be my preferred option :P
<ogra> it wont get fixed anyway :)
<sivang> ogra: hehe, what bugs are those?
<dholbach> hrm, now sounds doesnt work no more
<ogra> the fun of development releases
<ogra> sivang, search for beard and xscreensaver in bugzilla
<dholbach> snd-via82xx was just not loaded
<dholbach> hrm
<slomo> BenC: want some bugreports for 2.6.15 on ppc? evdev and genrtc should be loaded by default... other than that linux-headers is missing asm/highmem.h (which is included by linux/highmem.h)... some modules ftbfs because of that outside the kernel tree... everything else is perfect :)
* HiddenWolf blinks
<HiddenWolf> linux + kernel + perfect in one sentence
* HiddenWolf blinks again
<ogra> slomo, module loading is done by hotplug/udev ...
<slomo> ogra: even for fundamental stuff like rtc? the only rtc related things in /etc/udev are symlinking and permission setting imho
<ogra> slomo, udev for *everything* in the future as i understand it
<BenC> slomo: so evdev and genrtc should be built-in?
<BenC> slomo: highmem.h I  have a fix for in -6.8
<Kamion> BenC: I was almost going to throw bricks in your direction for modularising ext2 on me, but I've decided to just convert d-i to initramfs instead
<slomo> BenC: at least genrtc must be in, otherwise hwclock fails... for evdev... it was in or at least loaded by default in the past... it is needed for pbbuttonsd
<BenC> I know that something loads rtc on ppc64
<BenC> Kamion: had to because of mbcache module ended up being needed in more than one udeb
<Kamion> BenC: (that's usually solved by something like the fs-common-modules hack on powerpc)
<Kamion> though I'm kind of surprised that *modularising* something fixed that - it's normally the other way round
<Kamion> hmm, interesting, grub builds -m64 on amd64 now
<BenC> mbcache is a funny thing
<BenC> it's not an option that can be configured during config, it's set based on ext3/ext2 and some of it's attribute options
<xhaker> BenC, i need you to see something.. maybe you'll incorporate this patch in your new kernels :P
<xhaker> http://five.pairlist.net/pipermail/linux-laptop/2005-June/001543.html
<xhaker> read where it says Patch to Kernel for SuSe 9.3
<xhaker> only the point 1)
<Mithrandir> doko: why have you changed ia32-libs to not put the .so for libdb-4.2 in ia32-libs-dev ?
<xhaker> i can access my battery info.. and the other stuff.. but in the logs.. there is a message about a missing EC and ibm_acpi refuses to load then..
<BenC> xhaker: that patch is so old, I doubt it will even apply
<mjg59> xhaker: ibm_acpi should refuse to load
<BenC> xhaker: have you even tried dapper kernel?
<mjg59> xhaker: That's really not the right approach, in any case
<xhaker> i'm using 2.6.15-5 now
<mjg59> xhaker: What hardware is it?
<ogra> jdub, is there a way we can de-uglify the dapper clearlooks theme ? it looks horrible on 16bit displays with all theye ugly gradients
<xhaker> i was hopping this would fix a bug i have always
<xhaker> speedstep_centrino doesn't load.. says the device is busy.. and acpi_cpufreq is loaded instead
<xhaker> and i have a centrino dothan
<mjg59> xhaker: Again, what hardware is this?
<xhaker> acer laptop
<mjg59> xhaker: So why would you expect ibm_acpi to load?
<xhaker> sorry.. i thought it would apply to all "ibm" pc's
<mvo> jdub: you started that "make language-selecotr" more usefull spec, could you please (briefly) add some of your ideas? it's a bit bare-bone right now :)
<mjg59> No, it applies to IBM laptop
<mjg59> s
<xhaker> and that ec not found error kinda tricked me
<mjg59> If you have working battery status, you don't need any acpi patches
<mjg59> Are you sure you get "Device is busy"?
<Kamion> configure: error: GRUB requires a working absolute objcopy; upgrade your binutils
<Kamion> d'oh
<Kamion> ah, works fine if I drop back to -m32
<mjg59> Kamion: Hmm. How does grub work if built as a 64-bit application?
<xhaker> mjg59, ill get back tu you the right line
<Kamion> mjg59: I have no idea
<mjg59> Presumably it still has to build 16-bit code along the way
<Kinnison> k
<Kinnison> urgh, w/w, sorry
<Kamion> mjg59: did it ever? stage1 is assembly ...
<Kamion> (and has .code16)
<xhaker> mjg59, FATAL: Error inserting speedstep_centrino (/lib/modules/2.6.15-5-686/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko): Device or resource busy
<Kamion> and the stage2 bootstrap to protected mode is assembly too
<mjg59> Kamion: Ah, that would probably do it
<xhaker> powernowd init script trigger this
<mjg59> xhaker: If acpi-cpufreq is loaded already, then you'll get that error
<Kamion> still, I'll just drop it back to 32-bit for now, I can't be bothered dealing with binutils madness
<xhaker> the thing is.. it never loads speedstep centrino
<xhaker> i filed a bug for this in hoary already
<xhaker> the answer was some fixes to the check-something.sh script
<xhaker> and i tested that script and it return speedstep  centrino
<xhaker> i guess my bios is ****ed up
<ogra> whose isnt ? 
<ogra> :)
<xhaker> :)
<doko> Mithrandir: I didn't add it at all, the runtime library was just needed for OOo2
<rob^^^> ps: reading over the Edubuntu meeting logs, did anyone ponder the possibility of JaneW's disconnect being DHCP related?
<rob^^^> perhaps so an upstream provider could force all clients to renew to avoid old and broken dhcp clients?
<Mithrandir> doko: +mv debian/ia32-libs-dev/$(ROOT)/usr/lib$(SUFFIX)/libdb-*.so debian/ia32-libs/$(ROOT)/usr/lib$(SUFFIX)/
<Mithrandir> doko: from http://people.ubuntu.com/~scott/ongoing-merge/ia32-libs/ia32-libs_ubuntu.patch
<Mithrandir> doko: I wondered why
<doko> Mithrandir: libdb-*.so is the soname
<Mithrandir> doko: yes, but that still doesn't answer the question "why".
<doko> Mithrandir: why? because I do not want to install the -dev package to dlopen a library
<ogra> seb128, if i iconify windows, the black frame without content stays about a second on my desktop, is this intended behavior ? 
<ogra> feels a bit sluggish
<seb128> not, seems to be xorg bug
<ogra> ah, ok
<jdon1> quick question, what's the difference between dsa/rsa keys in SSH?
<ogra> also the animation in metacity seems to be gone ...
<Diziet> jdon1: Shouldn't you be asking in a support channel ?
<segfault> boo
<jdon1> Diziet: couldn't get a good answer; thought I'd get a better answer here
<Diziet> jdon1: I see.
<ogra> but that changes the intention of the channel, or the support character of the question :)
<Kamion> #ubuntu-devel isn't an escalated support channel
<jdon1> sorry; I just thought you guys would use SSH keys quite regularly....
<jdon1> that's the only reason I asked here
<Kamion> I'm afraid we have to be reasonably hard-arsed about this otherwise the channel's usefulness is degraded
<Kamion> I'm happy to help you in /query
<ogra> err s/changes/doesnt change/
<lamont>  20186 is a blocker for livecds.  kthxbye
<ogra> err, thats trivial ? 
<fabbione> lamont: also for dapper install :)
<lamont> ogra: assuming that the external api as used didn't change with the soname change...
<fabbione> lamont: it should be just a rebuild
<lamont> fabbione: well, not necessarily server installs... :-)
<lamont> build-depends: libsnmp5-d4ev
<lamont> --> nope
<fabbione> lamont: net-snmp had a ABI breakage of somekind that had no soname change
<fabbione> libsnp9-dev is an artifact afaik
<lamont> fabbione: in any case, it'll need a new upload
<fabbione> yup
* lamont uploads rss-glx instead
<lamont> well, once my testbuild finishes, that is.
<ogra> ogra@honk:~/seeds/edubuntu/dapper $ bzr push
<ogra> Using saved location: sftp://chinstrap.ubuntu.com/home/warthogs/archives/seeds.ubuntu.com/edubuntu/seeds/dapper
<ogra> bzr: ERROR: No WorkingTree exists for {'base': 'sftp://chinstrap.ubuntu.com/home/warthogs/archives/seeds.ubuntu.com/edubuntu/seeds/dapper'}(base).
* ogra cries 
<ogra> why do only i have probs ... and why is it a different error everytime ...
<ogra> *sigh*
<Kamion> asking on #bzr for help has a better chance of finding people who know what they're talking about than asking here ...
* ogra joins #bzr
<ogra> err...
<ogra> seems it worked anyway ....
<Keybuk> ... mdz made me do it
<ogra> made you do what ? 
<janimo> elmo, please sync/override xfce4-toys, thank you
<elmo> xfce4-toys |    4.2.3-1 | dapper/universe | source, amd64, i386, ia64, powerpc
<janimo> hmm
<janimo> elmothanks, sorry for the noise then
<Kamion> ogra: do you have an edubuntu-meta upload pending, or can I do one?
<ogra> Kamion, just running update :)
<ogra> give it 1 min ..
<Kamion> ogra: if you're already doing one, please wait
<ogra> ok
<Kamion> (i.e. rm -rf, unpack old version, and run update again when I've done this commit)
<ogra> ok
<pvanhoof> that's cool guys.. Hoary to Dapper upgrade without a glitch
<pvanhoof> thanks for making this a perfect upgrade procedure
<Treenaks> pvanhoof: Dapper hoor, nu al dapper ;)
<pvanhoof> and as a developer, I'm more used to having upgrade troubles. I think this must be one of the first times I successfully upgraded without any human intervention
<pvanhoof> including vmware etc etc
<Kamion> pvanhoof: is about to change ;-)
<pvanhoof> Treenaks, jep, als als het zo goed blijft lopen volgen er nog systemen :)
<pvanhoof> Kamion, are you guys going to fuck it up just like you guys fucked up breezy? :-) again? :)
<pvanhoof> put it in the topic will yha. That way I can decide when I apt-get upgrade ;-)
<Kamion> pvanhoof: it's already gone to ubuntu-devel-announce@
<elmo> Mithrandir: ?
* ogra twiddles thumbs watching the buildlogs for udev
<Kamion> big kernel/udev upgrade's about to land
<pvanhoof> it's okay if my desktop is unstable and bleeding edge etc etc .. but I do need some basic stuff working. Like X :)
<Kamion> how about booting? ;-)
<ogra> hehe
<pvanhoof> lol. booting is often important :)
<pvanhoof> it's a laptop and I can't always make sure it has forever power 
<pvanhoof> :D
<Keybuk> bah
<Keybuk> if I can boot a machine by hand, anyone can
<pvanhoof> Kamion, well, I know enough about kernels to get a custom/old one up and running :)
<Kamion> ogra: ok, go for it
<pvanhoof> and I'm going into holiday for three weeks after this week. It's just that, after those three weeks (1st of january) I'm likely going to do a C/C++ project for a customer. I'd like to have a proper environment by then :)
<Kamion> was removing hotplug from all the seeds
<ogra> Kamion, running
<Kamion> as usual, we recommend the stable release if you must have something that works
<pvanhoof> does somebody know whether or not support for Xen is planned (short term planning)?
<Kamion> comments of the form "your development release broke my production system" will meet with relatively little sympathy :-), although we will of course be interested in fixing the bugs
<ogra> pvanhoof, not for dapper
<Keybuk> elmo: talking of which, please remove hotplug from the archive, then burn it
<pvanhoof> ogra, the release after dapper?
<elmo> ** multiseat has an unsatisfied dependency on i386: hotplug
<elmo> ** udev has an unsatisfied dependency on i386: hotplug (>= 0.0.20040329-16)
<elmo> ** ubuntu-minimal has an unsatisfied dependency on i386: hotplug
<Kamion> I just typoed it "hogplut" here
<ogra> oh, multiseat
<Kamion> elmo: udev and ubuntu-minimal are being fixed, but I don't think anyone's on multiseat yet
<pvanhoof> doom3 also works, so I guess flgrx and stuff like that also got upgrade properly
<pvanhoof> sounds to good to be true
<pvanhoof> anyway, thanks for all that
<elmo> lamont/infinity: around?
<elmo> lamont/infinity: trustedqsl (sic, qsl not sql) is an inf looper
<elmo> it's taken out half of the debian arches and probably ours too, judging by the lack of binaries in the archive
<Kamion> pvanhoof: the kernel hasn't been upgraded since breezy yet ... until just now
<Kamion> hence working lrm
<pvanhoof> Kamion, ah ic ;). So no dist upgrade for a few days now
<Kamion> indeed
<pvanhoof> :P
<pvanhoof> okay
<pvanhoof> else I can nolonger play doom3
<ogra> ndiswrapper wil break until the next linux-image upload ...
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 1 released | Dapper getting new kernels, very unstable; don't bother trying to install it
<mjg59> Kamion: Which ones are we getting now?
<Kamion> mjg59: 2.6.15-5
<mjg59> Ok
<Kamion> as opposed to 2.6.12
<mdz> mjg59: (as default)
<mjg59> Suspend will be broken until -6
<ogra> yay for breakage
<\sh> mjg59: tell me now that sk98lin will also break?
<mjg59> \sh: Oh, possibly
* ogra loves this part of the development cycle ...
<mjg59> Or it might work better than before
<mjg59> Who knows? :)
<mjg59> But seriously, 2.6.15 is looking good
<ogra> yup, already ...
<\sh> mjg59: is the sky2 driver at least working now, or is it just a bitch as the last time...(only working for a few sec)?
<mdz> except for both still having the bug which breaks sound on my desktop, and breaking the workaround for it (irqpoll), it seems mostly OK
<ogra> but lets see how it breaks hand in hand with Keybuks udev :)
<mdz> oh, and completely breaking suspend on my laptop
<mdz> mjg59: is there anything I can do to form a useful bug report about that btw/
<mdz> ?
<mjg59> \sh: It should be better than it was
<mjg59> mdz: No, we figured it out
<mjg59> It's because we're shipping SMP kernels now
<mdz> oh, super
<mjg59> Which don't support suspend unless HOTPLUG_CPU is enabled
<mdz> so in other words, it isn't just me
<\sh> mjg59: ok...will test then
<mdz> but all suspend everywhere
<mjg59> mdz: Except on amd64, yeah
<mjg59> Oh, and APM
* Kamion contemplates stealing some of chmj's merges
<Kamion> on the other hand it's evening ...
<Keybuk> Kamion: hmm, I wonder who should do multiseat?
<Kamion> Keybuk: I'll have a look at it now
<ogra> does it need more than a dependency change ?
<Kamion> like I say, I'll have a look at it now
<Kamion> hmmmmmmm, ships a hotplug agent
<Kamion> and is, how you say, non-trivial
<Kamion> let's defer it and give it to daniels when he gets back
<Keybuk> rofl
<Keybuk> "you weren't around to say no" ?
<ogra> heh
<Keybuk> shouldn't be a problem
<Keybuk> (it being uninstallable for a while, that is)
<Kamion> elmo: please sync libtextwrap, ok to override
<elmo> Kamion: done
<siretart> elmo: please sync rockdodger and scgi from unstable, ok to override ubuntu changes
<Keybuk> hmm, I might go grab some food and lean some new chords while brave people try and boot
<elmo> siretart: done
<siretart> elmo: and thanks a lot for the merges processed, but for the last merges, I got the ACCEPTED mail, but I didn't see them yet on dapper-changes@. is there something going wrong?
<siretart> I'm just a bit confused, because in the past, I didn't see that
<elmo> siretart: I've got them on dapper-changes@ and the web archive shows them too?
<siretart> elmo: I dont see e.g. the 'helix-player' sync
<Kamion> siretart: should #19205 be closed?
<elmo> siretart: it was in NEW
<elmo> until minutes ago
<siretart> ah, okay. this explains
<siretart> Kamion: yes, I'm closing it now
<Kamion> thanks
<elmo> actually, no it doesn't
<mdke> elmo, cancel that email request for whitelisting me, the upload seems to have gone through ok
<ogra> Keybuk, :( udev failed 
<ogra> whats libsepol1-dev ?
<Keybuk> "failed" ?
<Keybuk> selinux policy library
<Keybuk> oh, yeah
<ogra> http://tiber.tauware.de/cgi-bin/buildlogs.cgi?show=http://people.ubuntu.com/~lamont/buildLogs/u/udev/076-0ubuntu1/udev_076-0ubuntu1_20051130-1947-powerpc-failed.gz#anchor
<Keybuk> Kamion: that'll need promoting
<ogra> all arches
<Kamion> it also needs a main inclusion report
<Kamion> being new source for main
<Kamion> and, er, security review. I bet that'll be fun
<Keybuk> meanwhile nothing will boot <g>
<Kamion> mdz: ?
<lamont> elmo: want me to just stop the building of trustedqsl?
<mdz> Kamion: yes?
<xhaker> omg, i updated initramfs and udev failed :(
<Kamion> mdz: libsepol; can we hurry it through main inclusion somehow? pitti is not here to do a review
<mdz> I see
<Kamion> xhaker: see the topic
<Keybuk> xhaker: see, you didn't read the topic, did you? :p
<elmo> lamont: I suggest killing it on any buildds it's building on and  n-f-u-ing it
<elmo> on all arches till it's confirmed fixed, yeah
<mdz> Kamion: let's both give it a once-over
<elmo> lamont: <offtopic> I fixed caballero and sarti already</>
<xhaker> i just now noticed the email saying initramfs will change stuff for udev
<Kamion> I think we only need libsepol1 and libsepol1-dev, not the tools
<xhaker> dapper-changes
<lamont> elmo: will do
<mdz> Keybuk: or can we do without it in udev?
<Kamion> xhaker: stuff is breaking at the moment, as the backlog of this channel should make clear
<Kamion> please do not clutter #ubuntu-devel with "omg, stuff broke" reports while we are trying to sort things out :)
<Keybuk> mdz: I can drop all selinux support, yeah
<Keybuk> might upset ajmitch
<Keybuk> and the other kids
<ogra> lol
<Keybuk> but it's a quick and easy change
<Kamion> does libselinux not provide much of that? that's in main
<Keybuk> apparently not
<Keybuk> it links to them both
<mdz> Keybuk: drop all selinux support?  but udev didn't depend on this before
<Keybuk> mdz: well, I'd have to manually go in, learn enough about selinux to cut out the deps on libsepol1 and leave those on libselinux1 without altering the functionality
<Kamion> it links to them both, but doesn't appear to actually include <sepol/*>
<Keybuk> it's probably easier to just drop the USE_SELINUX=true <g>
<Kamion> so what's it doing with it? :P
<Keybuk> really?  that's kinda cunning
<Kamion> hm, hang on, I'm looking at 074
<Keybuk> doesn't in 076 either
<Kamion> <cjwatson@cairhien ~/src/ubuntu/udev/udev-076>$ wcgrep sepol
<Kamion> ./Makefile:182: LIB_OBJS += -lselinux -lsepol
<Kamion> ./debian/control:6:Build-Depends: debhelper (>= 4.1), libselinux1-dev, libsepol1-dev
<Kamion> <cjwatson@cairhien ~/src/ubuntu/udev/udev-076>$
* Kamion goes symbol-hunting
<mdz> it builds fine without sepol
<Keybuk> it compiles and links without it
<mdz> it has a -lsepol but builds fine if it is removed
<Kamion> only text symbols that libsepol1 defines are sepol_*
<xhaker> hah.. nvm initramfs didn't get installed ;)
* Keybuk wonders whether there's a "git blame"
<Keybuk> hmm
<Keybuk> close enough
<mdz> I have an upload ready to go which removes it
<Keybuk> it's under "fix selinux compilation, taken from RedHat CVS"
<mdz> might be required for a newer selinux or something
<Keybuk> it's entirely possible that it's a new dep of libselinux in RH CVS tree
<Kamion> joy
<Keybuk> mdz: beat you :p
<Kamion> in that case surely libselinux should link to it itself
<mdz> Keybuk: uploaded already?
<mdz> Kamion: perhaps RH link udev statically or something
<Keybuk> mdz: uploading currently
<Keybuk> xhaker: yeah, I did put a dep in there <g>
<Keybuk> Kamion: yeah, it's probably in an unreleased libselinux we don't have yet
<lamont> is there a way to add comments in debian/control?
<mdz> X-comment: ?
<lamont> ok
<Keybuk> dpkg actually supports #
<Kamion> dpkg-dev >= 1.10.11 lets you just use #
<mdz> scary
<Keybuk> "doogie woz 'ere"
<Kamion> horribly non-rfc822, but hey
<mdz> fine for dpkg but not the dozens of other tools which parse that format
* lamont opts to put the comment in debian/changelog instead
<mdz> seb128,dholbach: http://people.ubuntu.com/~lamont/buildLogs/libg/libgnomeuimm2.6/2.12.0-0ubuntu2/
<ajmitch_2> Keybuk: it would upset me, I'd cry, but I understand if you want to drop selinux stuff :)
<seb128> dholbach: *mm ... for you :)
<dholbach> seb128: ok
<seb128> thanks
<Keybuk> ajmitch: s'ok, looks like it's just a RH weirdness that we can drop
<ajmitch> right
<ajmitch> probably something I have to review in the next week or two
<ajmitch> if I want any chance of landing stuff before feature freeze :)
* lamont tries to remember how to get apt to just print the url's it would download
<LaserJock> lamont: --print-uris ?
<sivang> mdz: maybe someone else but you can review the under consideration goals ? I don't want to start with mine and then realize it's not a target - I'd  rather help on other possibly more important goals if allowed.
<lamont> yep
<lamont> LaserJock: thansk
<wasabi> There an X command for changing the mouse speed?
<Keybuk> xset
<wasabi> thx
<wasabi> wooh. fixed it right up.
<wasabi> mouse preferences thing seems to be totally ineffectual now for some reason
<Keybuk> udev built
<Keybuk> ...and zis is ze time on sprockets venn ve dance!
<psusi> can someone give me a pointer to where I can read about what udev is?  I remember the days when you just used mknod to create device nodes for devices you expected to use...
<psusi> I remember hearing something about some sort of devfs to dynamically create devnodes for devices as they existed, but didn't really pay attention
<psusi> and now it seems they have gone away from that again?
<Keybuk> http://www.google.com/search?q=udev
<wasabi> devfs was a pretty bad implementation.
<wasabi> not to mention it made stupid names. ;)
<psusi> what was so wrong with it?
<psusi> heh
<wasabi> Just didn't belong in the kernel.
<wasabi> others know better than me.
<psusi> who better knows what devices actually exist in the kernel than the kernel?
<Keybuk> the kernel exposes that information to user-land via /sys
<wasabi> the kernel knows, but shouldn't be responsible.
<psusi> it allways seemed silly to manually make devnodes for device numbers that may or may not actually exist in the kernel
<Keybuk> it's not up to the kernel to create filesystem nodes like /dev/*
<ogra> Keybuk, where did you see it build ? its not in the buildlogs yet
<Keybuk> ogra: in the build logs
<psusi> hrm....
<Keybuk> http://tiber.tauware.de/cgi-bin/buildlogs.cgi?show=http://people.ubuntu.com/~lamont/buildLogs/u/udev/076-0ubuntu3/udev_076-0ubuntu3_20051130-2046-i386-successful.gz
<wasabi> psusi: udev runs in user space. It monitors kernel device events and applies a policy to determine how to create the nodes.
<wasabi> It's pretty simple, conceptually.
<Keybuk> increasingly simple in implementation too
<wasabi> Yeah.
<wasabi> hotplug is gone now or something?
<Keybuk> hotplug is gone
* psusi wonders when they will finally get the hard disk partition detection code out of the kernel
* ogra wonders why its not in the summary http://tiber.tauware.de/cgi-bin/buildlogs.cgi
<wasabi> psusi: likely as soon as Linux becomes a microkernel.
<wasabi> (ie don't count on it)
<psusi> I think sooner than that... seems to be what they are pushing for with the kernel device mapper
<wasabi> evms does partition detection in userspace already.
<psusi> move the partition detection code out to user space, and just tell the kernel where they are when it finds them
<wasabi> Yeah. I'm not sure what the focus is on that. It's d-m is neat.
<wasabi> But I question it's important for detecting DOS partitions.
<wasabi> importance.
<psusi> right now I have a hardware fakeraid... dual booting ubuntu and winxp on it... raid0 between two 10,000 rpm 36 gig raptors
<psusi> it's nifty how a user mode utility detects the drives, figures out the raid config, and sets up the dm devices to access the raid and the partitions on it
<wasabi> I agree.
<psusi> unfortunately, things like gparted don't grok dm
<Keybuk> dm is evil
<psusi> dm rules ;)
<psusi> let me see you resize and move around partitions on your hard disk, and create a new one to play with all while running the system from one of the existing partitions without dm ;)
<psusi> I did that the other day... heh
<psusi> without dm you'd either have to do it from a livecd, or at best, reboot after changing the partition table so the kernel could re-read it
<sivang> psusi: how does ext3 supports real time resize , does it also require reboots?
<sivang> (I've heared it does)
<rob^^^> heya to the fridge folks, there is a typo in the link to the CC notes
<Keybuk> evil!
<Keybuk> evil!
<Keybuk> (moody evil)
<psusi> sivang: no, I don't think ext3 supports on the fly resize... I didn't resize the partition I was booted from obviously... but I shrank some others and created a new one in the free space all without a reboot
<rob^^^> it has an extra space on the end onf the href causing bad things
<psusi> sivang: you can't do that with conventional partitions because the kernel will not re-read the updated partition table while one of the partitions is still in use
<psusi> which is why fdisk will tell you to reboot
<mdz> sivang: honestly, what difference does it make to you if I select it as a target?
<lifeless> mdz: hi
<lifeless> mdz: you pung before ?
<mdz> sivang: either you will do it, or you will not.  if it is interesting to you and you feel confident that you can complete it, do it
<mdz> lifeless: yeah, I passed the token to SteveA though
<lifeless> mdz: ok
<mdz> lifeless: he said he would follow up with you
<lifeless> Keybuk: re formats and support : http://bazaar.canonical.com/SuperMirrorFormats?action=show
* ogra does the guineapig reboot !
<ogra> Keybuk, looks like grepmap doesnt get installed in the initramfs ...
<lucas> is there some sort of whitelisting which would prevent my mail for new@bugs.launchpad.net from reaching its target ?
<Nafallo> Keybuk: ping :-)
<mjg59> Keybuk: Hm. What was that about not moving /dev from the initramfs to / ?
<Nafallo> and what happened to /dev/hd*?
<Nafallo> ALERT! /dev/hda2 does not exist. Dropping to a shell!
<ogra> Nafallol already upgraded ?
<ogra> lol
<Nafallo> now what? :-)
<ogra> me too :)
<HiddenWolf> http://www.desktoplinux.com/files/article019/osdl-dtl-survey-12.jpg
<ogra> have you booted without splash to see all errors ? 
<Nafallo> yes, and to get the shell 
<ogra> does it complain about missing grepmap too for you ? 
<Nafallo> damn mindreader!
<Nafallo> yes :-)
<ogra> heh
<\sh> please welcome a new channel..."#ubuntu-motu-school"
<ogra> that seems to be the issue ...
<Nafallo> ogra: so what now? :-) reboot to livecd and chroot or wait for Keybuk to come back? ;-)
<Nafallo> hi pitti :-)
<ogra> Nafallo, the latter i think 
* ogra was clever enough to have a breezy partition handy on his system :)
<Nafallo> baah :-P
<Nafallo> I'm using silverfairy for the moment ;-)
<ogra> i wouldnt make such experiments without fallback, its my main machine 
<HiddenWolf> Nafallo, silverfairy?
<pitti> Hi Nafallo
<Nafallo> my girlfriend shuttle (http://www.magicalforest.se/silverfairy/)
<Nafallo> s/nd/nds/
<sivang> \sh: why another channel? :)
<HiddenWolf> Nafallo, ah. That sounded suspicious for a minute. :)
<Nafallo> hehe
<Nafallo> Keybuk: please include mknod in initramfs until it's stable, thanx :-P
<sivang> Nafallo: you forgot kthxbye
<sivang> Nafallo: and end it with "love, $YOUR_NAME" :)
<Nafallo> sivang: naah, I actually want help from him, so naah. I postponed it rather ;-).
* Nafallo takes another ginger bread
<Kamion> uh, mknod isn't in the initramfs?
<Kamion> it's in the busybox initramfs config
<Nafallo> Kamion: not here on amd64 anyway...
<ogra> grepmap isnt ... thats way worse
<Kamion> well you should be able to do busybox mknod anyway
<Kamion> grepmap shouldn't be needed for most events any more anyway
<ogra> modprobe ide-disk is enoug
<ogra> worked for me ...
<hunger> I see that I am not the only one who can no longer boot;-)
<ogra> Kamion, udev complains very loud about missing grepmap
<Nafallo> ogra: right. thanx :-)
<ogra> just before it breaks completely because of missing /dev/hdX
<hunger> ogra: I had about 20k udevsend failures when rebooting.
<hunger> ogra: ... and missing /dev/sdX as well.
<HiddenWolf> hunger, count them to make sure. ;)
<hunger> HiddenWolf: It started with PID 10k and ended in the 30k range.
<dholbach> the old kernel works (2.6.12-9)
<ogra> dholbach, not if the initramfs doesnt boot ;)
<ogra> err ... indeed ... i'm silly, sorry
* hunger is confident that somebody will sort all this out till he upgrades again tomorrow:-)
<Nafallo> hmm
<ogra> Nafallo, can you select the old kernel ? 
<ogra> it will indeed also use the old initramfs ...
<mvo> ogra: so it's a bad time do dist-upgrade right now :) ?
<Nafallo> modprobe ide-disk, mount -rtext3 /dev/hda2 /root, ln -s /root/sbin/grepmap /sbin/grepmap, udevplug :-)
<ogra> i wouldnt advise anyone to do it before Keybuk is back, mvo ;)
<Nafallo> mvo: dist-upgrade is ok, just do not try to boot it afterwards ;-)
<Mithrandir> elmo: yes?
* ogra grumbles about all the accessibility bugs that land in his personal bug folder in evo .... silly evo filters
<\sh> ogra: #ubuntu-desktop-school? "lesson 1: How to setup good evo rules?"
<ogra> heh
<jdub> ogra: can you raise a bug with the clearlooks guys about it on 16 bit displays? they probably have no idea. :-)
<HrdwrBoB> lesson 2: how to remove all the filters and end up using procmail anyway
<ogra> \sh, i didnt think about having bugs that are not assigned to me ... but the bugzilla rule in my filters overrules the a11y mailing list rule apparently ...
<HiddenWolf> lesson 3: file another set of bugs on Evo
<ogra> jdub, will do :)
<Tm_T> hullo
<\sh> ogra: that's why I'm using sieve..it does what I want...not the other way around :)
<Tm_T> any news about dapper & nvidia drivers?
<HiddenWolf> Tm_T: #ubuntu
<HiddenWolf> Tm_T: no, no progress, dapper is quite broken at the moment.
<Tm_T> ok, then I wait
<Tm_T> and yes it is, some day I get most of things working fine, today less :p
<Nafallo> quite broken is and underestimation ;-)
<ogra> lol, yes
<Nafallo> I MIGHT have booted it soon :-P
<Tm_T> thank you for the info, back to kubuntu wonderland ;) ->
<ogra> Tm_T, jst see /topic :)
<ogra> *just
<Tm_T> ogra: heh, I'm not asking support if that's what you mean
<mdke> jdub, got 2 minutes for a quick technical question?
<ogra> Tm_T, nope, i rather meant the last part of /topic
<ogra> this time at least :)
<Tm_T> :p
<Tm_T> humm, have to recheck it ;)
<mdz> lifeless: how was your talk with Diziet about automated testing?
<Tm_T> ogra: ah yes, keep hitting me, haven't learnt yet ;-P
<jdub> mdke: ok
<mdke> jdub, #ubuntu-doc
<Nafallo> oh, are the kernels unstable?
<dholbach> good night everybody
<ogra> night dholbach 
<Tm_T> ogra: thank you sir, I'll test last well worked kernel ;) ->
<ogra> Tm_T, yup... wait some days before upgrading 
<mdke> jdub, or in here if you like
<jdub> mdke: what's the query?
<mdke> jdub, we've just uploaded our first offering for dapper. In it, we've included two of the guides in both xml and html form, and I made a omf entry for each, to see how they would each work in yelp. They both appear to work fine (if you've got dapper you can check it out, or even install on breezy from http://mdke.org/images/ubuntu-docs.png). Do you foresee any (technical) problems in including the html in yelp in this way? I'm thinking mainly of trans
<mdke> :)
<jdub> well, it's shippable, but not useful
<jdub> having both formats just ends up being confusing
<mdke> jdub, yeah, i don't foresee having both
<jdub> so why did you bother? :)
<mdke> jdub, they are both there now so that we can compare them and see if there are any technical problems
<jdub> the technical problem remains the same -> yelp won't automagically show the translated html, there is no standard way of doing so
<mdke> jdub, i thought that problem was only for items opened from the menu.
<mdke> jdub, if there is a translated omf file, why won't yelp show it?
<mdke> e.g. in /usr/share/omf/desktopguide-html/ you would have desktopguide-C.omf, desktopguide-fr.omf etc
<mdke> i mean, desktopguide-html-C.omf etc, sorry
<Tm_T> how many of you are experiencing many segfaults in dapper lately?
<jdub> mdke: i don't believe that helps - we'll see. even so, i don't think there is a significant advantage to shipping html - we should just make a nicely branded stylesheet for yelp, thus improving *all* the documentation.
<mdke> jdub, we could, yeah
<mdke> that would be more difficult that customising our css
<mdke> plus, yelp doing xml->html is MUCH MUCH slower than doing it in the build
<mdke> you'll see the speed difference if you try the dapper package
<Nafallo> Tm_T: can't find the harddrive at boot atm :-)
<Tm_T> haha
<mdke> doesn't segfault here
<Tm_T> I lost some apps since yesterday
<Nafallo> "lost some apps"?
<jdub> what the crap is up with that patrick mcfarland dude
<jdub> oh
<Tm_T> but, small flaws for better caause, making dapper the best release ever! ;)
<jdub> i recognise the nick
<jdub> what a tool
<mdke> lol
<Tm_T> Nafallo: well, when I try to run them, segfault immediately, recompiling doesn't help :p
<Nafallo> Tm_T: sounds like fun.
<mdke> jdub, ok as you say, we'll see. I think the speed difference is the killer for me though.
<mdke> jdub, anyhow, we're chuffed at having uploaded so early, so that should bode well
<mdke> :)
<Tm_T> Nafallo: indeed, this silence is killing me when amaroK isn't working ;)
<elmo> Mithrandir: what's up with mailman's insane /var/lib/mailman must be empty check in the preinst?
#ubuntu-devel 2005-12-06
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 1 released | Dapper getting new kernels, very unstable; don't bother trying to install it.  NO, REALLY, DON'T.
<jdub> mdke: yeah, that's awesome
<jdub> Keybuk: awwww!
<mjg59> Keybuk: Ping?
<Nafallo> lol
<Keybuk> mjg59: 'sup?
<mjg59> Keybuk: The stuff about not moving /dev from initramfs to / - what does that actually mean?
<mjg59> (re initramfs-tools changelog)
<mjg59> usplash depends on the fifo in /dev being the same in the initramfs and the real rootfs
<Keybuk> mjg59: read the udev changelog too
<Keybuk> or Kamion's reply
<Keybuk> basically that mount-move thing is in scripts/bottom/udev now which is supplied by udev itself
<Mithrandir> elmo: /var/lib/mailman/spool, since it doesn't upgrade quefiles.
<Mithrandir> queuefiles, even
<Keybuk> likewise the actual population of it is in scripts/premount/udev
<elmo> Mithrandir: dude this is going from one debian revision to another
<elmo> Mithrandir: why on earth is the check trigger-ing?
<mjg59> Keybuk: Ok, so it's just moved to udev? Cool.
<Mithrandir> elmo: because it's paranoid.
<Keybuk> mjg59: yeah, will make keeping it up to date muuuch easier
<Mithrandir> elmo: I agree that might be a bit over the top, though.
<elmo> Mithrandir: ITYM fcuking retarded
<Keybuk> I imagine the evms and lvm and crap will also move to those packages
<Keybuk> it also means load_modules() is just "cat conf/modules | xargs modprobe" type affair
<elmo> Mithrandir: do you mind if I file a bug?
<Keybuk> all the udevstart/etc. gubbins is done by udev now
<Mithrandir> elmo: please do.
<LaserJock> where can I find the Flight 1 cd?
* Kamion disables tomorrow morning's CD builds; no point
<Kamion> LaserJock: see the ubuntu-devel-announce mailing list archives on http://lists.ubuntu.com/
<SEJeff> LaserJock, http://cdimage.ubuntu.com/releases/dapper/flight-1/
<wasabi> http://isthis4real.com/orbit.xml   open in firefox 1.5
<LaserJock> SEJeff: cdimage, I knew it was something like that. I just couldn't remember. Thanks
<SEJeff> np
<jdub> Keybuk: so the new kernels with the new meta packages are not yet recommended?
<Tm_T> I would say "yu"
<Keybuk> depends
<Keybuk> let me put it this way
<Keybuk> do you like being able to boot?
<jdub> tend to prefer it
<ogra> Keybuk, !
<Keybuk> then not just yet
<ogra> i cant boot :/
<ogra> anything i can collect for you ? 
<Nafallo> ogra: module-init-tools FTBFS'd :-P
<Tm_T> muaaah, can't find any gui music player app that really plays anything :(
<ogra> argl 
<ogra> why did i miss this ...
<SEJeff> Just out of curiousity, any rough ETA?
<ogra> SEJeff, nope
<ogra> Keybuk, udev also complains very loud about missing grepmap....
<ogra> in initramfs that is
<Keybuk> yeah, I just haven't muted that yet
<Keybuk> you can ignore it unless your hard drive is on the input subsystem
<Keybuk> or you're running on an s/390
<jdub> but mum! my ps/2 disk won't wokr!
<ogra> hehe
<ogra> it just looked scary ...
<jdub> allo xkahn 
<xkahn> hey jdub!
<jdub> fancy seeing you in a place like this ;)
<Keybuk> ogra: can you boot your system? :p
<xkahn> Heh.  Yeah.  A little unfamiliar.
<\sh> ah...I just missed jdub in my "ubuntus motu school" announcement...
<jdub> Keybuk: packages to be removed... hotplug... wheee :-)
<Keybuk> jdub: \o/
<xkahn> So I wrote a patch which adds pam_xauth support to pam_modules.
<Keybuk> jdub: I like the fact you ignored the "NO, REALLY, DON'T (upgrade)" :p
<xkahn> It doesn't enable it...  Just makes it possible.
<jdub> Keybuk: i just looked at the dist-upgrade -u --purge output :)
<xkahn> Although I believe it should be enabled by default, I pick my battles.
<ogra> Keybuk, nope
<xkahn> How do I go about getting it in the package?
<ogra> it doesnt load ide-generic in initramfs
<jdub> xkahn: you could file a bug on the package, and perhaps raise it on ubuntu-devel if you think it's something that should 'just work'
<xkahn> Okay.  So file a bug with the patch enabling it...
<xkahn> And then start a flame war ont eh mailing lists.  
<xkahn> Got it.  ;)
<jdub> :)
<Keybuk> ogra: yeah, yeah, I know the bug now :p
<Tm_T> interesting, looks like I don't have modules for my soundcard anymore
<xkahn> Well, I'll have to do it later tonight.
<xkahn> I've got a book reading to attend.
<jdub> infinity: wigga-wigga-wha--? UP/SMP unified kernels?
<jdub> xkahn: ciao, nice to see you around these parts
<Seveas> jdub, fresh fridge material: http://www.tecspy.com/blogs/loveslugradio/2005/11/30#051131-episode3
<Seveas> make sure you have nothing in your mouth before clicking :)
<jdub> bah
<jdub> can't click atm
<Seveas> no gui nearby?
<jdub> would have to go back to the table
<Seveas> it's worth it :)
<jdub> severe lack of synaptics driver for X ;-)
<ogra> hmmm
<Seveas> hehe
<ogra> what do i do with apps that have compile options like --with-hotplug-scripts-dir=  nowadays ?
<\sh> dum dum de dum dum *ubuntu*
<Seveas> I actually spilled some coke when reading that
<SEJeff> Seveas: Awesome
<Keybuk> ogra: fix them
<mdke> heh
<mjg59> jdub: modprobe mousedev
<Seveas> lol@keybuk :)
<jdub> mjg59: nup
<mjg59> (if you're on 2.6.15)
<jdub> mjg59: on 2.6.14 with upgraded X *sans* all xserver-xorg packages
<ogra> Keybuk, hmm, how ? if they expect scripts we dont support anymore ... are there replacements for all scripts ? 
<mjg59> jdub: Oh, fun
<infinity> jdub : Yes, on i386, the "non-smp" kernels are actually SMP kernels thsat dynamically turn all the SMP locks into no-ops on boot if a UP system is detected.
<jdub> mjg59: because all the drivers moved around, and didn't have l-r-m yet (this lappy needs ati and atheros drivers)
<jdub> infinity: elite!
<infinity> jdub : I think the word you wanted was "scary".
<jdub> that's the australian spelling
<Seveas> lol
<jdub> Seveas: that's fucking brilliant
<Seveas> jdub, I KNOW :)
<\sh> well...to substitute "scary" with the name of an old "Sinclair ZX Spectrum Game" named "Elite"...I knew the German language missed something....
<Seveas> btw: http://www.ubuntulinux.nl/quotes?minid=39
<ogra> \sh, elite !! i spend a year or so with it :)
<\sh> ogra: only one year?
<\sh> there is even a java emulator applet of a zx spectrum running "elite"
<\sh> that is scary^Welite!
<Keybuk> ogra: no, there are no replacements in the traditional sense
<ogra> thats what i thought 
<\sh> as I said...I missed jdub in my announcement: topic for jdub: "The Secrets of Australian English, or how to make people happy, even if everything just breaking apart..." (Should be Topic No. 1 in our MOTU School)
<ogra> i'll find out if the new kino really need them
<ogra> *needs
<\sh> wow...0:30 UTC...time to sleep because todays morning I have to send some CVs to some companies
<sistpoty> gn8 \sh
<ogra> \sh, "have to" ??
<\sh> ogra: well...yes..we had yesterday a meeting with colin Buechner...
<ogra> and ? 
<ogra> are you on the list for te next mass firing ? 
<\sh> ogra: first question: "Who are you, how long are you working for this company?"
<\sh> (implied the rhethorical non asked question: how expensive will it be, to get rid of you"
<ogra> yes, ish gmbh ...
<HrdwrBoB> "20 years"
<HrdwrBoB> "and I've never taken leave, ever"
<\sh> ogra: jepp..."not long enough in this company, not married, no kid (well...not officially)"...i'm easy
<Nafallo> \sh: you should have told them you where the father of 14 children or something :-)
<\sh> HrdwrBoB: this guy wasn't even thinking about money 20 years ago...he is a kid of the real existing communism...
<\sh> HrdwrBoB: he just converted 1989 to capitalism because of the bananas
<jdub> Seveas: see fridge :)
<magnon> howdy jeff
* ogra_ grumbles in direction of german telekom
* magnon raises a whisky to ogra
<ogra_> magnon, i would so love to ... but no whisky around :/
* \sh will drop the connection now...to dream about a good way to get the money of his life insurance, without being murdered....
<elmo> /var/lib/dpkg/info/udev.postinst: line 144: /usr/share/update-notifier/notify-reboot-required: No such file or directory
<elmo> dpkg: error processing udev (--configure): subprocess post-installation script returned error exit status 1
<elmo> Keybuk: known?
<Keybuk> yes
<elmo> k
<Keybuk> you brave, brave, brave man
<Keybuk> so, err, don't reboot
<elmo> it's a chroot
<Keybuk> ahh
* infinity doesn't have udev in his chroots.
<tseng> speaking of dont reboot
<tseng> my new kernel doesnt see /dev/hda1 :/
<infinity> Which kinda solves that problem. :)
<elmo> it's a porting chroot, what do I care
<Keybuk> tseng: see topic (the bit about don't reboot)
<Keybuk> and the bit about not installing it 
<infinity> tseng : You didn't need it anyway.  (Or, if I nuderstand correctly, wait for the new module-init-tools to build, upgrade, update-initramfs -u, reboot)
<tseng> yeah how about that.
<tseng> good thing i have 3 pcs in this room
<Keybuk> WHEN PATCH SYSTEMS ATTACK
<ogra_> slomo, still awake ? 
<ogra_> ah, he said good night in -motu already :/
* Nafallo has updated packages for amd64 in his "main-stuff"-repo :-)
<ogra_> Treenaks, here ? 
<ogra_> is anyone here a kino user ? i'm looking for testers ...
<ogra_> oh, it crashed ... ... ...
<Tm_T> this was sort of frustrating
<Tm_T> to get even some sound out, I needed to load modules manually (and guessing what I need)
<Tm_T> :p
<lifeless> mdz: it was good
<lifeless> mdz: I'm doing up a strawman smipler interface for the test runner, so that things like lintian/existing package tests can all report in, and the new metadata based virtualisation runner etc reports via that
<lifeless> mdz: thats based on the subunit protocol
<Keybuk> right
<Keybuk> everyone's machines boot again
<Keybuk> so I'm going to bed :p
<Keybuk> so I'm bouncy enough to deal with the 100 other problems everyone will have found by morning <g>
<SEJeff> Keybuk: Do I need to manually run update-initramfs -u, or did the package do that for me?
<Keybuk> you'll need to for module-init-tools
<Keybuk> it doesn't put itself into initramfs, it gets press-ganged in, so it didn't seem right to update it there
<sistpoty> elmo: please sync libcoyotl from unstable, ubuntu override ok. thx.
<Keybuk> udev updates it (and there's a -4 on the way in that fixes cosmetic problems)
<SEJeff> I guess having modules loaded at boot is kind of important
<SEJeff> Thanks
<ajmitch> Keybuk: yeah, people were complaining on the forums about not booting - you'd think they'd learn that dapper will break :)
<Keybuk> my laptop boots :)
<Keybuk> but then it had a version of module-init-tools from before the patch system from hell reverted the patch from the source package and gave me something *else* to upload
<Nafallo> Keybuk: *grin* :-)
<sistpoty> elmo: if you haven't synced libcoyotl yet, please don't do it yet... I test-built the wrong version :(... sorry for the inconveniece
* Nafallo goes to bed
<elmo> sistpoty: sst
<elmo> sistpoty: too late it's already done
<sistpoty> elmo: ok, thx... then I'll at least check the harm (if any) that I've done :/
<elmo> oh, except I managed to misparse your nick as slomo.  so he gets the blame on dapper-changes ;-)
<elmo> slomo: sorry about that
<sistpoty> elmo: phew... I did build the right version, so nothing bad there... sorry, was a little confused. maybe I should go to bed now ;)
<SKK|xhaker> sabdfl in ubuntuforums is really Mark ?
<tseng> who else would it be?
<seth_k|lappy> an IMPOSTER
<seth_k|lappy> treason! :P
<SKK|xhaker> i mean
<SKK|xhaker> by the sound of this post doesn't seem it is Mark :S http://ubuntuforums.org/showpost.php?p=517266&postcount=1
<mdz> infinity: it looks like l-r-m changed its default rc.d sequence number, but didn't migrate the existing links?
<SKK|xhaker> so... is that really Mark? i mean, gtkwifi is coded by myself now and he seems to want to know about it
<infinity> mdz : The link migration should have worked, unless I dropped that change by accident in the final upload...
<mdz> SKK|xhaker: the posts from that account generally sound like him
<mdz> infinity: my link is still at S15, and I didn't see anything in the maintainer scripts
<infinity> Which it looks like I did...
<infinity> Go me.
<infinity> Oh, feh.  I probably forgot to remove lrm-common.postinst from the clean target. :)
<mdz> in fact I don't see update-rc.d being called at all
<infinity> The code WAS there. :)
<mdz> hehe
<infinity> Thanks for the catch.
<infinity> I'l fix it when we do the ABI bump later today.
<infinity> (Which should be in an hour or two)
<infinity> Oh, *cough*
<infinity>         rm -f debian/linux-restricted-modules-*.postinst
<infinity> La la la.
<infinity> Oddly enough, * matches "common".
* infinity changes SHELL=/bin/sh to SHELL=/bin/dwimsh
<jvw> infinity: don't forget to put /bin/dwimsh in Debian too, or you'll have yet another Debian vs Ubuntu flame ;-)
<ogra> cool, booting really feels faster ...
<jdon1> is Diziet or some other Firefox guy around right now?
<ogra> jdon1, 3am around here ... unlikely
<jdon1> oh, hehe
<jdon1> I'll bugzilla it then
<jdon1> an upstream/trunk bugfix to 1.5 that would be valuable
<ogra> it actually might be 2am for him... but still :)
<ogra> slomo, is this really you ? or just a reconnect ? 
<tseng> if he isnt asleep by now he should be
<ajmitch> hi tseng 
<ogra> i'm just poking at kino 0.8.0 ....
<ajmitch> ogra: not asleep yet?
<ogra> nope
<tseng> hi ajmitch 
<ogra> just building a new power-manager :)
<jdon1> geez why are people so friggin impatient about Firefox 1.5?
<jdon1> what part of "big system change that has a large ripple effect" do they not comprehend?
<ajmitch> because it's new & shiny
<jdon1> :)
<jdon1> well, then again, Breezy 1.0.7  was a bummer....
<tseng> 1.0.7 doesnt break a dozen major apps
<jdon1> no it doesn't, but it does render remarkably slowly compared to other Firefoxes
<jdon1> something about the 25K lines of patches  applied by Ubuntu :)
<jdon1> either way, the current Dapper FF 1.5 sources are still too unstable for backporting
<mdz> infinity: did you find out if there was anything to those rumours about php in breezy?
<ogra> wow, where did the other 10k come from ? 
<jdon1> geez, so I missed by 10K or so... when has that ever harmed anyone ;)
<jdon1> hmm, so it breaks Flash in everything but Firefox itself... just wonderful
<LaserJock> that's starting to sound like a Windows tactic *grin*
<jdon1> ooh, never mind, Java breaks
<jdon1> that figures
<jdon1> blackdown Java is broken by FF 1.5...
<jdon1> would recompiling it fix the problem, or is it something more serious than that?
<wasabi> Not that unstable. ;)
<wasabi> initrd is broken though
<wasabi> Looks like md and lvm and evms are all not playing nice again.
<Amaranth> ha, nice nick
<backports-r-us> lol
<backports-r-us> sabdfl called me that in a meeting, and it's stuck on as an alternate :)
<infinity> mdz : Both php4 and php5 in breezy work fantastically for me (and many others), so I think I'm going to have to mail that user directly and ask him to explain in more detail what exactly is going on.
<tseng> infinity: i use php5 in breezy very heavily
<tseng> no problems
<tseng> 10,000 lines of code later
<infinity> mdz : Of course, the problems seen "in the sefver forums" could be due to the fact that people are referring each other to broken howto docs. :/
<mdz> infinity: thanks, let me know what they say
<ajmitch> what was the php rumour? the only issues I've heard are missing php5 modules
* ajmitch got to curse & swear at php-imap again today
<infinity> mdz : I'll have to spend some time perusing the forums, but the biggest issues look like "the blind leading the blind" which is leading to more confusion.  I'll try to clear some of it up in a bit.
<infinity> ajmitch : php-imap is pure evil.  And I should know.
<infinity> ajmitch  : jbailey promised  acouple of years ago to rewrite it using mailutils instead of libc-cleint.  Remind him. :)
<backports-r-us> infinity: blind leading blind?
<ajmitch> yes, if I remind him about it, he'll just tell me to do it
<ajmitch> and I'm sorely tempted these days
<akurashy> lol weird nick
<infinity> backports-r-us : People leading each other around in circles to diagnose prpoblems that aren't there, while giving advice on how to install things that could work, during the right moon phase, but probably won't.
<backports-r-us> infinity: :-/, I roughly know what you're talking about...
<infinity> mdz / backports-r-us : Anyhow, I'll try to dig a bit, summarise, propose some changes for the ubuntuguide people, etc.
<backports-r-us> infinity: yeah, there's some changes I wanna propose to the guide too, like say GET RID  OF MIRROMAX ALREADY
<backports-r-us> apparently the guy running the guide is in some kind of medical trouble
<infinity> backports-r-us : It's the other side of the double-edged sword that is a large anf friendly community.  Everyone thiks they're an expert, and everyone wants to help.  Even when some shouldn't. :/
<ajmitch> and there he is now, hi jbailey :)
<infinity> backports-r-us : Easy enough to rememdy once the bad advice has been spotted.
<backports-r-us> infinity: in any community that encourages the "everyone help each other" attitude, that's bound to happen
<jbailey> ajmitch: yoyosup?
<infinity> backports-r-us : Yup, and in general, I like the community aspect.  Except when I don't. :)
<backports-r-us> infinity: we try hard to minimize the probability of bad information damaging others... When it doesn't happen, it need to be brought to our attention. Thanks for doing so
<ajmitch> jbailey: just cursing php-imap & how it should be rewritten
<jbailey> Ah, right. =)
<backports-r-us> In the future, please contact a forum admin with any of these kinds of gripes... we need to know about it 
<jbailey> ajmitch: I'm not sure whether "rewrite php4-imap" is above or below "finish the Hurd" on my task list, honestly.
<ajmitch> jbailey: I think more people would love you if you rewrote php-imap
<ajmitch> finishing the hurd would probably finish you
<jbailey> ajmitch: I hack glibc for a hobby and for work.  What makes you think I need love?
<ajmitch> you're right
<ajmitch> besides, you've got angie :)
<jbailey> True ;)
<wasabi> Cool.
<wasabi> Linux kyoto 2.6.15-5-k7 #1 SMP Tue Nov 29 08:27:28 UTC 2005 i686 GNU/Linux
<ogra> mdz, :/ no luck with the new kernel/udev/module-init-tools on ltsp clients ... cant load the netcard driver it seems
<ogra> infinity, is there anything new about nfsroot booting in initramfs ? 
<xhaker> ogra any luck with that initramfs in edubuntu?
<ogra> nope
<xhaker> i seem to have that /dev/hda not found too
<ogra> that what i was just saying above
<ogra> thats already fixed 
<xhaker> what fixed it?
<ogra> update your system
<xhaker> i can't
<xhaker> it doesn't boot :P
<ogra> module-init-tools
<ogra> use a livecd
<ajmitch> it's part of the dapper experience
<ajmitch> knowing how to recover a screwed up system :)
<xhaker> chroot into the insstalled system?
<Amaranth> my solution: a vmware player image
<ajmitch> yes
<ogra> chroot to the disk and update ... run dpkg-reconfigure for the linux-image package you use to recreate the initramfs ...
<Amaranth> it never boots, it reloads from a snapshot :D
<xhaker> :P
<ajmitch> Amaranth: some of us are daring & run dapper on real hardware
<Amaranth> ajmitch: I could think of a few good words to replace "daring" there. ;)
<xhaker> the funny thing is module-init-tools were updated today when i found out -Q patch was missing.. and now i got ****ed by it
<xhaker> lol
<ajmitch> Amaranth: 'developers', perhaps?
<Amaranth> ajmitch: Yeah, that must be it. :D
<xhaker> hehe
<xhaker> well
<xhaker> of i go :P
<desrt> well
<desrt> erp.
<ogra> yay, linux source 6.8 :)
<Amaranth> ogra: In the future, does the source have a stable module ABI?
<Amaranth> err, not source
<Amaranth> kernel
<ogra> Amaranth, i'm not the kernel guy... ask #ubuntu-kernel
<Amaranth> ogra: Joke Terminated.
<ogra> sorry its 4:40am and i just broke my ltsp setup ... 
<SEJeff> Amaranth: you sound like the Japanese OSDL. Next you're going to ask for the kernel be relicensed so that proprietary drivers are actually "ok"
<ogra> not really in the mood for joking ...
<Amaranth> SEJeff: I don't care about proprietary drivers, it'd just be nice to find a driver and install it instead of having to get kernel source and build it.
<mdz> ogra: did you try to track down the problem with thin clients and the new boot stuff?
<ogra> mdz, i just broke it ... 
<ogra> mdz, i get a kernel panic directly after the kernel is uncompressed with "cant open /tmp/net-eth0.conf"
<mdz> ogra: what's before that?
<ogra> looks like the module loading doesnt work right in initramfs ...
<ogra> i'll ask Keybuk tomorrow
<ogra> SOICGIFINDEX: No such device
<ogra> and ipconfig: no devices to configure
<OgMaciel> smurf: excuse me, can I pvt you for a minute?
<ogra> OgMaciel, i doubt he's awake, 5am here
<OgMaciel> ogra: ohh...  thanks... and where is "here" for you guys?
<ogra> germany
<OgMaciel> ohh
<OgMaciel> ogra: I'll try again much later...  'nite
<TreeStump> hi
<TreeStump> i think theres a problem with the Ubuntu 5.1 installer
<TreeStump> ?
<Amaranth> TreeStump: #ubuntu would be a better place to ask, I think.
<cshields> jdub: ping (you back from your trip yet?)
<TreeStump> ok sorry
<TreeStump> they recommended me here
<Amaranth> TreeStump: If you've identified the problem and are sure it's not due to a bad burn file a bug in bugzilla, please.
<cshields> jdub: I take that as a negative.  will ping you later, thx
<TreeStump> its just that i dont think its a bug just i dont think i have the option to use hardware RAID but only software or nothing, which stops me from installing
<infinity> TreeStump : It's not up to the installer to setup hardware RAID, it would be up to your RAID controller.  (ie: You'd set it up before you installed an OS)
<ogra> mdz, going through initramfs manually and loading 8139too instead of the ide drivers makes it work ... there is something missing in the premount part of initramfs
<TreeStump> ive already setup the hardware RAID but the installer will not recognize it
<infinity> TreeStump : What sort of hardware RAID?... 
<infinity> TreeStump : If I had to guess, I'd say you're using some intel/via/promise "pseudo-RAID" that isn't actually hardware RAID at all, but requires software support to work.
<infinity> TreeStump : In which case, we have packages (dmraid) that can help make that go, but we don't (yet) support that in the installer.
<TreeStump> ok so i have to wait for my promise RAID to be supported in the installer?
<SEJeff> TreeStump: Promise doesn't make the best RAID controllers. 3Ware RAID controllers probably have the best Linux support
<SEJeff> TreeStump: And they have great OSS userspace tools to manage their controllers
<ivoks> 3ware is ok
<ivoks> but dont get latest controler
<ivoks> it will be supported in dapper, but it isn't in breezy
<SEJeff> TreeStump: I'm not trying to say Promise sucks, but I've heard mostly bad reports about Promise and Linux / BSD in general
<ivoks> SEJeff: ?
<TreeStump> ok so what if i change to Silicon image?
<ivoks> i can tell you only best about 3ware
<SEJeff> TreeStump: I'm just speaking from personal experience and what my collegues tell me. I've never used Silicon Image
<wasabi> I'm disappointed in my 3ware hw.
<wasabi> It's slow on Linux.
<TreeStump> because my board has that on it too
<ivoks> are we talking about IDE, SATA or SCSI controllers? :)
<mdz> ogra: tell Keybuk what you find
<ogra> mdz, see 20331 ;)
<desrt> anyone with sata running 2.6.15 yet?
<crimsun> I am.
<desrt> hum.
<ogra> mdz, in other news the xorg autodetection didnt work either ... but thats something for tomorrow, 6am, bed time :)
<ajmitch> night :)
<ogra> night all :)
<desrt> crimsun; did you have to manually tweak your initramfs modules config?
<crimsun> desrt: nope
<desrt> odd.
<desrt> well.  brb, i hope.
<Diablo-D3> heh
<Diablo-D3> udev replaces and conflicts hotplug now? why?
<Amaranth> because udev replaces hotplug?
<Diablo-D3> it used to co-exist
<Amaranth> yeah, but hotplug isn't needed anymore
<Diablo-D3> ahh
<sivang-zzz> morning
* netjoined: irc.freenode.net -> brown.freenode.net
<Treenaks> ogra: at 1:50 in the morning? nah ;)
<dholbach> good morning
* desrt ties a long string around dholbach's wrist and ties the other end around pitti's wrist
* desrt goes off to bed before anyone can ask why
<pitti> hmm?
* dholbach hugs desrt 
<pitti> Hi desrt 
<desrt> n8 :)
* pitti pulls the string and hugs dholbach 
<dholbach> woohoo
<pitti> sleep well, desrt
<dholbach> good night desrt 
<dholbach> lamont, infinity: could somebody of you please give back libgnomeuimm2.6?
<jdub> BenC: ping
<fabbione> jdub: ubuntu-server mailing list now please. kthxbye
<jdub> fabbione: right! right now :-)
<jdub> sorry, did a bunch last night, skipped out on that one because i was being lame :)
<jdub> oh
<jdub> ah
<jdub> hrm
<jdub> elmo, Znarl: ping
<dholbach> hey jdub 
<dholbach> hey slomo_ 
<slomo_> hi dholbach :)
<pitti> Mithrandir: I uploaded the new libgphoto2, which means that you can upload the new libsane
<Mithrandir> pitti: thanks.
<dholbach> elmo: please sync libfwbuilder from sid, ok to override
<pitti> Mithrandir: nice to see the dependency chain resolving :)
<pitti> Mithrandir: nice, then /etc/hotplug/usb will be empty
<Mithrandir> woo
<jdub> eh, so are the new kernels built that will boot? :)
<dholbach> sure :)
<fabbione> jdub: of course they do
<dholbach> without hotplug :)
<fabbione> they boot
<fabbione> the problems are later on on initramfs/udev/etc..
<fabbione> up to your setup to decide if you are "lucky today"
<jdub> this quebecistani computer is *never* lucky :)
<sivang> jdub: still in .ca ?:)
<jdub> yes
<jdub> no
<jdub> of course not
<hunger> Can I do something to help with fixing the linux-meta problem? My box does no longer find the rootfs (/dev/sdaX).
<hunger> s/linux-meta/initramfstools or whatever/
<pitti> elmo/Kamion: can you please NEW the langpack-locales package?
<janimo> pitti, are you the only approver of mainInclusion?
<crimsun> hunger: make sure you're running module-init-tools_3.2.1-0ubuntu3 and udev_076-0ubuntu4
<pitti> janimo: in principle not
<pitti> janimo: but in practice; anything urgent?
<janimo> pitti, I don;t know who to ping about xfce main inclusion
<pitti> janimo: oh, that would certainly be me, is it urgent?
<janimo> since I have no feedback at all so far
<janimo> pitti, well not urgent, but would be nice to get all xubuntu stuff into main soon
<janimo> so I can  start building CDs
<pitti> janimo: can you upload to main?
<janimo> it's easier if there are no universe bits
<janimo> pitti, no I proposed myself for main-up
<pitti> hm, ok
<janimo> but these should at least in principle be approved and then promoted when possible
<JaneW> sivang: not sure if I got your PM... can you send a again or mail me please?
<sivang> JaneW: I'll email you.
<mdke_> woohoo the mailing lists are a lot faster now
<JaneW> sivang: great thanks
<hunger> Wow... this is the first time that I need Windows to fix my linux
<sivang> hunger: why not use a livecd?
<Diablo-D3> hunger: that sounds wrong
<hunger> Diablo-D3: Windows can mount my usb stick with the updated debs I need to make my box boot again.
<jdub> elmo, Znarl: ping
<hunger> Diablo-D3: The old kernel does no longer do much due to hotplug having been removed.
<HrdwrBoB> er
<dholbach> hunger: 2.6.12-9 still worked for me
<HrdwrBoB> because you can't load the modules manually?
<HrdwrBoB> or revert?
<dholbach> hunger: i had to load usb-storage and mount the stick manually
<crimsun> (hunger: you should still have it in /var/cache/apt/archives/  if you haven't cleared it)
<hunger> dholbach: That might have worked as well:-)
<dholbach> :)
<hunger> dholbach: Well, now I know that windows still boots... just in case I need to update my BIOS or something.
<dholbach> i keep my fingers crossed
* hunger hates his deb-addiction.
<hunger> I could have such a stable system if I woudn't need to upgrade as soon as I see some new deb popping up!
<ajmitch> evening :)
<ajmitch> hunger: the addiction can be managed?
<hunger> Do I still need to manually create a initramfs after upgrading udev and module-init-tools?
<hunger> "udevd-event[x] : run_program: exec of program "/usr/lib/hal/hal.hotplug" failed.
<hunger> That's after upgrading udev and m-i-t with the 2.6.15 kernel.
<hunger> I guess that is due to /usr not being mounted yet.
<pitti> hunger: initramfs should be created automagically now
<hunger> pitti: The datestamp on it was *very* old, so I recreated it manually.
<hunger> pitti: Just top make sure.
<pitti> hm, dunno, I thought udev, uspash, etc. use update-initramfs now
* seb128 kicks ogra
<infinity> usplash does.  Not sure if udev does yet, though it should.
<seb128> what about speaking with the maintainer about bugs before mailing the list to "revert change of the new version"
* infinity would really like to know why his system has suddenly decided to start loading radeonfb.
<hunger> Could that udevd-event thing stop after failing some action for a couple of times?
<infinity> If that's a new udev "feature", it can die.
<Diablo-D3> ih
<Diablo-D3> uh
<Diablo-D3> well heres one
<Diablo-D3> now that hotplug is gone, insertion of media doesnt bring up a file browser
<pitti> infinity, hunger: udev's postinst calls update-initramfs
<hunger> 2.6.15 still does not boot here:-(
<infinity> pitti : So it does, and it even seems to work.
<hunger> Yeap... hal has its stuff in /usr/lib/hal... That is not available at early bootup here.
<jsgotangco> hey guys
* Diablo-D3 tries to remember how to manually mount media
<hunger> Could someone please move the hal-stuff into /lib, please?
<pitti> hunger: yes, will do
<Diablo-D3> mount -t vfast /dev/my-flash-reader /media/sdb1 doesnt seem to work
<pitti> hunger: I did not notice that failure...
<infinity> Diablo-D3 : You meant 'vfat', right?
<Diablo-D3> yeah
<Diablo-D3> damn typos
<hunger> pitti: I guess moving /usr/lib/hal/* to /lib/hal should be enough.
<pitti> hunger: oh, wait, no - why should we move the complete hal to /lib?
<pitti> hunger: the hotplug program does not make sense without hald running
<Diablo-D3> does anyone know if automatic opening of file manager windows will work with the new pure udev solution?
<pitti> hunger: where did you see that message?
<hunger> pitti: Maybe moving /usr/lib/hal/hal.hotplug is enough already.
<pitti> hunger: it couldn't do anything since hald is not running
<hunger> pitti: During bootup... Dunno where.
<pitti> hunger: well, this seems to be rather cosmetic then
<hunger> pitti: I get thousands of messages about it being missing.
<Diablo-D3> so 2.6.15 is verified not worky?
<hunger> pitti: Bootup stops with those messages scrolling by.
<pitti> hmm, odd
<infinity> Diablo-D3 : Works for me, just not perfectly yet. :)
<pitti> grep hal.hotplug /var/log* delivers nothing
<Diablo-D3> infinity: ahh
<Diablo-D3> damnit
<pitti> hunger: I'd rather modify the udev rule to check whether the script is available before calling it
<infinity> pitti : One assumes because your /usr is on /
<Diablo-D3> I'd normally not even care about a file manager window popping up...
<hunger> pitti: I'll check...
<pitti> infinity: righto
<Diablo-D3> but why isnt mount working >_<
* Diablo-D3 wonders if something in dapper broke when he wasnt looking
<Diablo-D3> I mean more than the usual breakage
<hunger> pitti: Can I add the check in the RUN part of that rule?
<Diablo-D3> btw
<Diablo-D3> does anyone have an opinion on the new human look?
<jdub> Diablo-D3: dude. read the mailing list.
<pitti> hunger: rather call a PROGRAM (like test -x) and check the result
<pitti> Keeeeeeybuk
<seb128_> hey hey jdub
<Diablo-D3> jdub: the ml kinda sucks.
<jdub> Diablo-D3: your post was entirely inappropriate and wrong
<jdub> morning seb128_ 
<seb128_> I hate those mails
<pitti> why does my /etc/udev contain all my devices now and /dev is empty? And where have my /etc/udev/ conffiles gone?
<seb128_> people flaming on list when you do a little change on new version
<Diablo-D3> jdub: oh screw you. the new look sucks, and if this is what final is going to look like, Im going to quit recommending ubuntu
<jdub> Diablo-D3: read my reply, and chill out.
<seb128_> Diablo-D3: don't use dapper if you want something stable which doesn't change
<dholbach> Diablo-D3: that's not the language we want here
<infinity> pitti : You're special, my system has conffiles in /etc/udev, and devices in /dev...
<seb128_> Diablo-D3: welcome to a moving distro, work is done, bugs are fixed, not a way to behave
<Diablo-D3> seb128_: dapper will be stable someday.
<Diablo-D3> which is what Im afraid of.
<pitti> infinity: let's swap
<seb128_> Diablo-D3: still your post has a totally inapropriate ton
<infinity> pitti : I'll keep my own special breakage for now, thanks.
<dholbach> Diablo-D3: it's a development release and if you don't intend to participate, stop complaining
<Diablo-D3> I think the look should be put back the way it was.
<jdub> and based on a complete misunderstanding of the status of the software
<jsgotangco> hey jdub
<seb128_> Diablo-D3: I think you should not agress people like that
<Diablo-D3> jdub: what misunderstanding?
<jdub> jsgotangco: yO! you in korea?
<jdub> Diablo-D3: again, read my replies
<jsgotangco> jdub: Yo! I'm flying tonight!
<dholbach> what's wrong with writing a bug report "i think this looks wrong since the new version?"
<jdub> jsgotangco: cool, good luck and have fun :-)
<jsgotangco> jdub: dude they got me into business class
<jdub> rad!
<Diablo-D3> jdub: the theme changed, it needs to be put back, no matter if this is dapper or not.
<jdub> how long is the flight?
<jsgotangco> 4 hours
<Diablo-D3> like or not, people depend on how it looks.
<jdub> Diablo-D3: that is a totally incorrect analysis of the situation
<jsgotangco> i leave 11pm (+8) arrive around 5am (+9)
<seb128_> Diablo-D3: what about "fixing" it rather than returning to the stone age?
<dholbach> Diablo-D3: and threats like "i stop recommending ubuntu" are completely  inappropriate - they don't change anything
<Diablo-D3> otherwise we get retarded windows users saying, "ZOMG UGLY! I WONT USE THIS!"
<pitti> can somebody please /msg me the contents of /etc/udev? I need to reinstall the packages which ship rules
<ajmitch> jsgotangco: lucky sod! I was in economy all the way to montreal :)
<Diablo-D3> seb128_: fix what? it was perfect the way it was.
<dholbach> Diablo-D3: man we have other bugs which need fixing too, and we have time left
<seb128_> Diablo-D3: cairo is much better than gdk
<Diablo-D3> and apparently its ubuntu policy never to roll packages back
<jdub> Diablo-D3: again, READ MY REPLIES so you can be informed about the situation
<dholbach> Diablo-D3: that's hilarious
<Diablo-D3> (assuming the ML is correct)
<Diablo-D3> seb128_: well, I guess. I'm not a fan of either.
<jdub> (it's pointless to further discuss it further here, because it has been sufficiently answered on the list)
<jsgotangco> go Cairo
* dholbach hugs jsgotangco 
<pitti> infinity: do you have anything in /etc/udev/permissions.d?
<pitti> infinity: udev does not create this directory apparently
<infinity> dpkg: /etc/udev/permissions.d* not found.
<pitti> ok, so it's maybe just a leftover
<infinity> -rw-r--r-- 1 root root 2797 2005-03-29 22:57 /etc/udev/permissions.d/udev.permissions
<infinity> Curious.
<infinity> hand-made config file, I guess.
<infinity> Not sure if it's a leftover or required.
<infinity> (hand-made = postinst-made, I never touched it)
<pitti> infinity: there is /etc/udev/rules.d/40-permissions.rules
<pitti> so let's just see whether that's enough
* ajmitch has a /etc/udev/permissions.d/udev.permissions from 2004
<ajmitch> from when this was sid
<pitti> since /etc/init.d/udev restart seems to be borked, let's just reboot...
<jsgotangco> see you guys later gotta start packing up
<ajmitch> see you, have a great trip
* pitti discovers the init.d section that was responsible for the breakage
* pitti eagerly awaits Keybuk coming online... :)
<infinity> pitti : Upload, upload, upload, dude.
<pitti> infinity: well, I'd like to discuss a proper solution with him first ;)
<infinity> Crazy talk. :)
<hunger_> pitti: My system boot sagain.
<hunger_> pitti: I commented out everything starting with /usr...
<hunger_> pitti: Added a modprobe here and there (into my crydtodisks)
<hunger_> pitti: Now the system hangs when startin KDE (kdm works fine).
<dholbach> fabbione, BenC: do you want to have kernel bugs assigned to ubuntu-kernel-team in malone?
<fabbione> dholbach: bugzilla -> linux
<dholbach> fabbione: i'm talking about malone bugs
<fabbione> there should be no malone bugs for the kernel :)
<lucas> hi
<dholbach> fabbione: man... there should be no kernel bugs at all :)
<dholbach> fabbione: look how many bugs the desktop team has on malone ('gnome' team)
<dholbach> i think we're all in a state of 'transition' :)
<fabbione> dholbach: that too.. but people shouldn't be using malone for main stuff
<fabbione> dholbach: reassign them to the team
<dholbach> and i don't want to push users around if we're going to switch to malone in n+x days
<dholbach> will do so
<seb128> dholbach: yeah, we get almost the same amonth on bug on malone now
<\sh> anyone who wants to do some lectures for ubuntu-motu-school? 
<fabbione> pitti: i can see your lang pack upload script works :P
<fabbione> pitti: you just sinked my local mirror :)
<pitti> fabbione: yes, nicely :)
<pitti> fabbione: however, I need the new locales NEWed until folks can actually enjoy the new locale stuff
<hunger_> pitti: My box boots again with two tine wrappers around hal-unmount.sh and hal.hotplug (just doing an exit 0 if the files are not there/executable)
<fabbione> pitti: yeah
<pitti> hunger_: ok, I'll add a test -x to the udev rule
<hunger_> pitti: Minor glitches are still there, but at least I do get back into the system properly.
<pitti> \sh: the new centericq in Debian fixes a security hole, and the Ubuntu changes don't look important
<pitti> \sh: may we just stomp over them and sync?
<zakame> pitti: I did the merge for centericq, and yes, a sync is best imho
<\sh> pitti: please do :)
<pitti> elmo: please sync centericq
<pitti> thanks
<\sh> pitti: (u forgot "ok to override") :)
<pitti> \sh: that's pretty meaningless at the moment
<pitti> \sh: since packages without changes are autosynced
<pitti> so every sync request will be for overriding Ubuntu changes
<zakame> hmm, on second thought, the change to remove *.[a|o]  files on clean to enable successful rebuild seems important... I should ping the debian bts then :)
<pitti> zakame: oh, you can also merge if you want
<pitti> go SCO - they just fixed a 9 months old vuln in an utterly security-irrelevant package (ipsec-tools)
<zakame> gaah
<zakame> pitti: will do that then :0
<zakame> :)
<pitti> zakame: oh, thanks
<hunger_> pitti: After the upgrade I have about 40%user activitity in top on an idle system.
<pitti> hunger_: from which process?
<hunger_> pitti: I can't see any... top lists one or two processes with ~2% CPU.
<raphink> I upgraded my dapper and now it doesn't recognize my sound card anymore :S
<raphink> I wonder what this can be
<pitti> the new udev probably
<raphink> probably
<pitti> the kernel probably doesn't provide a modeline for it
<pitti> s/modeline/modalias/
<pitti> raphink: same for pcspkr, btw
<raphink> pcspkr ?
<zakame> pc speaker
<raphink> ah ok
<zakame> bbl
<ajmitch> fabbione: could we get your bot to log #ubuntu-motu-school please? :)
<fabbione> ajmitch: no i can't.. i am at the max channel allowed from this net from one user
<ajmitch> ah right
<ajmitch> I understand that, I have 2 connectoins with irssi
<\sh> fabbione: irssi script or perl/python ircbot?
<fabbione> \sh: bitchx
<pitti> crimsun: thanks a lot for the fuse patch, it look sfine
<pitti> crimsun: can you upload this yourself, or shall I do it?
<sistpoty> elmo: please sync libghemical from unstable, ubuntu override ok
<crimsun> pitti: do I have upload privs to *-security? I didn't think I did.
<pitti> crimsun: if you can upload to universe, you have
<pitti> crimsun: it will go in my queue anyway, not straight to the archive
<pitti> crimsun: I'll release the packages when all arches have built
<crimsun> ok, so I upload both?
<pitti> yes
<pitti> thanks
<crimsun> all right, will do. Thanks.
<sistpoty> crimsun: what do you want to upload to security?
<pitti> fuse
<sistpoty> ah... 
<sistpoty> pitti: I've recently uploaded libflashplugin-nonfree to multiverse, which installs a newer flash version (old has security issues)... but I'm not 100% happy with the quick fix... any advice?
<pitti> sistpoty: what was the problem?
<sistpoty> pitti: mom.
<Tm_T> hmm, how your mom can be problem with flash...
<pitti> *laugh*
<sistpoty> pitti: the package is an installer only, but it tried to install the old version: CVE-2005-2628
<pitti> sistpoty: ah, right, so by merely upgrading the package you won't upgrade the lib itself?
<sistpoty> pitti: I guess you do, but I'll recheck this
<pitti> sistpoty: hm, it does not have an integrated notification mechanism? or upgrade mechanism?
<pitti> Hi ajmitches
<ajmitch> hm
<sistpoty> pitti: iirc installing is done in postinst
* sistpoty looks
<infinity> Err, wait... We have both an installer package, and a real package for flash?
<infinity> That's... Retarded.
<infinity> (real package being "flashplayer-mozilla")
<pitti> infinity: 'debian is about choice' :)
<infinity> This is Ubuntu's fault, I think.
<infinity> As in, Debian ships the installer package, Marillat ships the "real" package, we choose to ship both.
<pitti> ah, I see
<crimsun> yes, we probably should kill flashplayer-mozilla from multiverse.
<retrix_> whats the ubuntu method of packaging programs that have i18n? i.e. where should the .po/.mo files get put?
<infinity> crimsun : Except that it works...
<infinity> (It's what I have installed)
<crimsun> infinity: granted.
<pitti> retrix_: don't change anything, the buildds will pick up the po files and shove them to the langpack builder automatically
<infinity> Assuming we can legally distribute it, we should be using a packaged version, not an installer.
<crimsun> we can't
<infinity> Then why are we?
<pitti> oh, so why we do?
<crimsun> "Macromedia's EULA forbids repackaging and/or redistribution of their software so please do not mirror this repository."
<crimsun> http://macromedia.mplug.org/site_uh.html
<retrix_> pitti: where do they pick them up from?
<pitti> errm, and we have it on archive.u.c?
<pitti> <jdub mode>WE WILL ALL GO TO JAIL</jdub>
<crimsun> pitti: yes, that's why the installer (flashplugin-nonfree) is preferable
<pitti> retrix_: well, from anywhere in the source package
<pitti> retrix_: and the mo's should be in the standard location (/usr/share/locale/lang/LC_MESSAGES/
<retrix_> pitti: ok thanks
<pitti> Kamion: is there any reason why w3c-libwww is in main? nothing uses it, it's just seeded
<pitti> Kamion: (I just have a pretty complicated security update for it, that's why I was looking for it)
<sistpoty> pitti: flashplugin-nonfree will dl a new version on upgrade
<pitti> sistpoty: oh, so all is good?
<sistpoty> pitti: not all... unfortunately I broke the update mechanism, so always a new version is downloaded 
<pitti> ooh :)
<pitti> well, it's not that bad, is it?
<sistpoty> pitti: minor side-effect, I'd call it: it supplies an update-flashplugin script, which now always fetches the new version
<sistpoty> pitti: the new version is already in dapper, should this go to breezy-security then?
<pitti> sistpoty: if you follow the steps in SecurityUpdateProcedures, yes
<pitti> if you want to
<sistpoty> pitti: ok, will read that... thx for your help
<Kamion> all_ubuntu_dapper_i386:libwww-ssl-dev                          | w3c-libwww                        | Supported seed                                 | Richard Atterer <atterer@debian.org>                                                  |          614464 |            2612
<Kamion> pitti: ^---
<pitti> Kamion: right, that's what I mean
<pitti> Kamion: but there are no rdepends to it
<Kamion> oh, I read what you said as "not seeded" rather than "just seeded"
<pitti> it's one of the 'we randomly seeded libraries' cases
<Kamion> pitti: feel free to un-rescue libwww-ssl-dev from extra
<pitti> well, not randomly
<pitti> ok, thanks
<Kamion> I've dropped libwww-dev to universe now
<pitti> and -ssl-dev?
<pitti> I'll unseed it now
<Kamion> pitti: not dropped because still seeded
<pitti> Kamion: also, may I bother you with NEWing langpack-locales?
<Kamion> pitti: I'd rather it waited for elmo today; I have a lot to do and am short on time
<pitti> ok, thanks
<seb128_> is there a known laptop issue atm? like "something is wrong, since the lastest dapper update my box is damn slow and hangs all the time ....its shuts the disk done all the time, are .. I am on AC,"?
<hunger_> seb128: Sleep does no longer work here.
<janimo> Kamion, it is still not clear to me what the non-ubuntu-meta packages relation is to standard/minimal seeds
<janimo> I copied from kubuntu/edubuntu but this makes messages like Removed hotplug from minimal-i386
<janimo> in the changelog
<janimo> and mdz told me I should drop minimal/standard from xubuntu, but I am not sure what dropping means in this context
<Kamion> don't worry about it
<Kamion> as long as you do not generate xubuntu-minimal and xubuntu-standard binary packages, the changelog messages are harmless noise
<janimo> so whould I just let minimal standard files and changelogs generated
<janimo> ok, thanks
<Kamion> yes, leave it be
<mvo> Kamion: is http://www.ubuntulinux.org/newsitems/release510 the canonical place for the breezy release notes? 
<Kamion> ubuntulinux.org is never the canonical place for anything - ubuntu.com :-)
<Kamion> I'm honestly not sure, though. I think so ...
<mvo> do we have it somewhere as text too?
<mvo> I want to display relesae notes in the upgrade tool :)
<mvo> (obviously in the ML archive)
<Kamion> mvo: no idea, sorry :(
<Znarl> We're moving to ubuntu.com from ubuntulinux.org but both should be equal.
<Kamion> doko: do you need help with your merges?
<Kamion> Riddell: do you need help with your merges?
<doko> Kamion: these are the outstanding python merges, I did want to have an initial python-central version first, so I do not have to touch these twice
<doko> Kamion: or do these merges do have absolute priority?
<pitti> crimsun: fuse updates released, thanks
<crimsun> pitti: thanks :)
<Kamion> doko: we discussed in the last Thursday meeting that we would try to get as many merges done as possible by the next meeting, indeed as close to zero outstanding as possible; you did not raise this then
<Kamion> doko: in fact, you put "Next week: ... start python merges/syncs" in your update
<Kamion> yes, they have priority, it's important for us to see what bugs we're pulling in from upstream as early as possible
<Kamion> mdz said "Remaining merges should be completed next week." on ubuntu-devel last Friday
<Kamion> if you need someone to help get them sorted today, go ahead and nominate someone, or else shout and I'll try to find somebody who's not looking busy enough :-)
<doko> Kamion: yes, "start them", anyway, I can do it, I don't see not much sense, if there's no new upstream version
<Kamion> as we discussed in the dapper release process meeting at UBZ (you were there), distinguishing between upstream versions and Debian releases is often not particularly useful
<Kamion> merges are something we all have to do and have to live with
<Kamion> regardless of whether we think they're irrelevant in particular cases, we need to get them done so that it's possible for people like mdz and me to see where we're at across the whole distro
* Nafallo gets 10KB/s from archive.ubuntu.com
<Nafallo> anyone else seeing slow speeds today?
<Mithrandir> Hentet 1119kB p 2s (404kB/s)
<Mithrandir> that
<Mithrandir> that's from se.archive, though
<Mithrandir> so not very useful
<Nafallo> :-P
* Nafallo could only wish that se.a.u.c would use push in the future ;-)
<Mithrandir> pitti: care to review https://wiki.ubuntu.com/MainInclusionBootchart, pretty please?
<Keybuk> Mithrandir: good maintenance in Debian is probably irrelevant for bootchart
<Keybuk> given I packaged it entirely independantly
<Mithrandir> Keybuk: better now?
<Keybuk> yup
<maswan> Nafallo: how often would you like us to update, given that each update takes 20-60 minutes to run (sample size: the last 7 updates)
<Mithrandir> maswan: every 60 minutes? :-P
<Nafallo> maswan: every half hour :-)
<Nafallo> that's how often I apt-get update from archive.ubuntu.com :-)
<Mithrandir> Nafallo: you seem slightly obsessed that way.
<maswan> hmm.. it seems that the time taken is very time dependant, it is the ~06 updates that takes the longest time. I wonder if that collides with another cron job, perhaps I should shuffle the hours a bit
<Nafallo> hihi, I like to try the fresh packages ;-)
<Nafallo> still 6 hours between the updates?
<crimsun> Keybuk: ping, do you have a couple minutes to explain the udev New World Order to me for a usb sound device that requires its own firmware uploader and firmware?
<Nafallo> (except for the ~20 run)
<Keybuk> not currently
<Keybuk> please file a bug, giving details about your sound device, the firmware uploader (what package it's in) and where the firmware is
<crimsun> Keybuk: ok, thanks. It depends on non-free firmware that uses a GPLed firmware loader. I'll see if I can musk it out.
<pitti> Hi jbailey 
<Keybuk> crimsun: is that why your loading devices takes ages?  I have that problem ... my soundcard modprobe takes 15s of spinning for firmware it doesn't especially need
<ogra> Keybuk, udevplug -Bpci -Iclass=0x0200* doesnt work :/
<jbailey> pitti: g'm Martin.
<ogra> assuming you meant i had to add it in the udev script
<Keybuk> ogra: "doesn't work" is not a useful statement
<Keybuk> it must work to some degree, so let's discuss what it does and doesn't do instead
<ogra> Keybuk, it doesnt behave different at all
<Kamion> http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
<Keybuk> join us in #ubuntu-boot
<Kamion> surely all our developers have read that or similar at some point
<jbailey> Kamion: Right.  One should at least use technical terms like "No Worky!"
<jbailey> ;)
<doko> elmo: pleas sync pycurl, overwriting Ubuntu changes
<jdub> what's karl tilbury's email address? karl@canonical.com?
<jbailey> jdub: rt@admin.canonical.com. ;)
<jdub> no, need him direct
<slomo_> BenC: seems like therm_adt746x isn't compiled on ppc... but it's needed at least for ibook/powerbook for the temperature sensor which enables the cooler at some point
<BenC> slomo: ok, can you email me that info, please?
<slomo_> BenC: sure
<BenC> thanks
<ogra> Kamion, would it be very bad if i wait some days with xscreensaver merge (which splits the package in a very intrusive way, see 3044), i'd rather not do such a change before flight2
<Kamion> ogra: is that intrinsically tied to the merge? (why?)
<ogra> its not, but my merged package already has the change ... indeed i could raise the version loally and just do a sync first ..
<ogra> *locally
<ogra> if you prefer this ...
<ogra> i just want to be 1287% sure that the split works fine before i upload and dont want to break fligth2 with it
<ogra> (there are other changes too to make the hacks work with gnome-screensaver)
<doko> elmo: pleas sync python-crypto, overwriting Ubuntu changes
<Kamion> ogra: yes, please separate the merge from that stuff
<ogra> pitti, thanks for the moodle hint :)
<ogra> elmo, please sync xscreensaver from unstable and drop the ubuntu changes :)
<ogra> Kamion, thanks ..
<jdong_> is the equivalent of amd64_agp supported by NvAGP?
<jdong_> ftp://download.nvidia.com/XFree86/Linux-x86/1.0-7676/README.txt, I wasn't sure about the chipset name
<ogra> ask nvidia ? 
<ogra> its an option of the binary driver...
<jdong_> ok
<jdong_> and how do I debug resume-from-hibernate?
<jdong_> right now, it resumes but suddenly reboots after reading the pagefile
<jdong_> the same happen on both my systems
<ogra> hmm, elmo acually no, i'll do the merge myself, forget xscreensaver 
<jdong_> the onlything in common is amd64_agp + nvidia GPU
<ogra> jdong_, you cant, thats why nvidia binary drivers are not supported for STR
<ogra> they might or might not work ... up to nvidia
<jdong_> ogra: I'm quite sure the driver itself suspends, but AGPGART doesn't
<jdong_> http://www.opensuse.org/NVidia_Suspend_HOWTO reports success by using NvAGP / no AGPGART
<ogra> until recently it had no sane suspend option, but mjg59 might prove me wrong
<jdong_> ogra: I think they added it in the late 6xxx series
<ogra> jdong_, lease ask mjg59 i only know they never worked for me (up to the recent 7XXX) , not even in hibernate, while the nv driver works fine here
<jdong_> ogra: hmm, is there a way to have startx switch between 2 xorg.confs?
<jdong_> jdong_: I need GLX very rarely
<ogra> you can have a xorg.conf in your homedir ...
<ogra> rename it to xorg.conf.bak if you want to us the system xorg.conf
<jdong_> ok, so startx will automagically use ~/xorg.conf if present?
<ogra> yup
<jdong_> oh, and also startx -- -conf /path/to/xorg.conf
<jdong_> apparently Google says so
<sladen> orga: not sure, but you can have multiple layouts in one xorg.conf and start them with  X -layout "Multihead"  or something
<jdong_> not currently at a Linux box, but will test when I get home
<ogra> no need for the -conf option
<ogra> it just picks it up ... here at least
<jdong_> ogra: right, but if I wanna store it system-wide
<ogra> sladen, oh, thats news to me
<jdong_> ogra: probably I'll have a "startx-3d" command for starting a new session with nvidia binaries
<sladen> ogra: so I have  Single, Dualhead, Multihead and Xinerama  and those refer to "Screen", which refer to "Device" which refer to "Driver"
* ogra reads dholbach's gnome 2.12.2 thread and wonders how many meanings of "won't" are there in english ...
<dholbach> :)
<sladen> ogra: https://wiki.ubuntu.com/LaptopTestingTeam/ThinkpadR52/Multihead  for a documented file of what all the configs mean
<ogra> sladen, done with "ServerLayout" and identified by Identifier i guess ?
* Tm_T installed newest kernels
<ogra> sladen, ah, yes, thats what i thought
<sladen> ogra: I think so.  Probably.  Yes.  (Yes, that example uses multiple ServerLayouts but only one driver; copy and paste will get you more)
<\sh> hmmm...when is daniels coming back?
<Kamion> next week
<\sh> Kamion: thx...I really need this little xvfb-run script 
<zakame> wb pitti :)
<doko> elmo: pleas sync python-sqlite, overwriting Ubuntu changes
<Robot101> btw you all want dbus 0.60 in dapper, it fixes the python bindings and merges some of your patches :)
<pitti> it's not yet too late to upgrade to it :)
<Robot101> it doesn't really break much, only the meaning of some flags
<ogra> pitti, apparently they want to rename it to 1.0 shortly after 0.6 is out as well ...
<ogra> we should probably go with 1.0 for 3 year support if it doesnt come to late ;)
<azeem> J5's blog post sounded like they'd change the API a bit more before 1.0
<pitti> ogra: I agree
<ogra> oh, i thought they didnt want ... thats something else then ...
<pitti> Robot101: 1.0 is supposed to have a stable ABI, right?
<ogra> an api change in january might be bad ...
<Robot101> J5 is being very optimistic
<azeem> "If there are problems with the system we are still open to changes but if all goes well this will be the 1.0 API."
<Robot101> calling it 1.0 might commit to an API but it's still buggy :-/
<Robot101> I'd quite like to fix crapness before 1.0 is released
<azeem> OTOH, he contradicts himself in the previous paragraph
<Robot101> but J5 wants to rush 1.0 to commit to the API, no matter how crap it is
<Robot101> the pending ABI break is varying the maximum allowable signature length I think
<Kamion> merp, somebody put user-setup-udeb in main when I wasn't ready yet
<Kamion> ELMO
<Robot101> I'm not even sure everyone can build 0.60 because of fuckups in the configure.ac with the qt bindings
<Robot101> you can't build it with libxml support, it needs expat, and yet the python bindings have just added a hidden dependency on the libxml2 python bindings
<Robot101> total nose bleed.
<Kamion> except no, it's in universe. huh? how did my installer manage to pick it up then?
<Kamion> I think net-retriever and I need to have a long talk
<mjg59> Kamion: Can d-i be beaten into installing to a block device rather than a partition?
<Kamion> like I said before, depends on how much you feel like hacking partman
<mjg59> Kamion: So partman is responsible for providing a formatted device to the rest of the installer?
<mjg59> partman really seems to want a partition table. I, uhm, don't...
<Kamion> you need something to prepare /target. In the current installer, that's partman
<Kamion> I thought I explained this a day or two ago?
<Kamion> partman knows about different disk label types; perhaps it can be convinced to know about one that isn't partitioned
<Kamion> I think parted's internal 'loop' disklabel is unpartitioned
<mjg59> We discussed whether or not partman would consider non-physical block devices, but not whether it was responsible for providing the fs
<Kamion> ok - it is
<mjg59> If I write another module that provides the fs, can partman just be skipped?
<Kamion> because it's that UI that handles mountpoints
<Kamion> theoretically yes, although the packaging issues are complex
<Kamion> you'd have to make very sure that partman didn't appear in your image, and it would all be, uh, interesting for netboot
<mjg59> Well, it'll need to be a custom d-i build anyway
<mjg59> Because it'll also need something to set up the loopback device
<mjg59> So I might as well just set that up as a single udeb
<Kamion> ok
<mjg59> So that might be the easiest way of doing it, I guess - I can have the partman-replacement set up the device, format and mount it
<Kamion> sure, that seems reasonable ...
<Kamion> you may have to Provides various things that partman-* provide
<Kamion> mounted-partitions and suchlike
<mjg59> So the "only" problem then is to have something added to the initramfs that'll be used on boot
<mjg59> The initramfs is generated on kernel install in d-i, right?
<mjg59> So I just need to make sure that an extra package providing the script fragment is installed by then
<Kamion> mjg59: yes, preseed base-installer/kernel/linux/extra-packages
<Kamion> mjg59: yes, preseed base-installer/kernel/linux/extra-packages-2.6
<Kamion> (sorry)
<mjg59> Heh
<Kamion> it's 'usplash' by default
<mjg59> Rocking
<mjg59> This is all starting to sound worryingly plausible
<Kamion> infinity: current gfxboot patch says:
<Kamion> +  If you encouter problems with the graphics code, hold down SHIFT while
<Kamion> +  syslinux starts. This will put it into 'failsafe' mode that lets you
<Kamion> +  interactively skip critical parts (like monitor detection).
<Kamion> infinity: is that good enough for us, do you think?
<pitti> hunger: ok, the hal I just upload should fix your problem
<pitti> hunger: it does not use hal.hotplug at all any more :)
<crimsun> rawr
<crimsun> got hotplugging with firmware uploading working with the udev New World Order
<pitti> BenC: here?
<BenC> yeah
<pitti> BenC: I completed the belocs-locales spec this morning
<pitti> BenC: but it is still assigned to you
<pitti> BenC: can you please update the status?
<BenC> pitti: sure, thanks!
<pitti> well, langpack-locales is still in NEW
<pitti> but otherwise it's all good
<BenC> kick ass, belocs-locales is the first one to be marked "Implemented" in our specstable :)
<rob^^^> I heard some rumbeling about improving LDAP config and such for dapper, does anyone know the appropriate WikiWord of interest?
* pitti ^5s BenC 
<Nafallo> rob^^^: NetworkAuthentication if memory provides...
<BenC> Keybuk: ping
<Nafallo> [15:05 UTC]  <Keybuk> right, while the buildds are building new udev and m-u-t, I'm gonna grab lunch
<BenC> thanks
<rob^^^> Nafallo: thanks
<rob^^^> I run an OS X OpenDirectory server and it's been a very mixed bag
<rob^^^> unfortunately its the closed source bits that make the world go round :(
<pitti> elmo: can you please NEW langpack-locales to make langpacks installable again?
<pitti> elmo: (only the source package is new, the locales package is now build from it instead of glibc)
<elmo> pitti: uh
<pitti> elmo: bad?
<elmo> pitti: no, just, uh interesting
<elmo> I assume someone's going to fix glibc to not also build locales?
<pitti> elmo: jbailey did already
<elmo> so he did, sorry
<pitti> elmo: updating locales through glibc was a pain, so we split it out
<pitti> elmo: thanks; this means this spec is fully implemented now :)
<xkahn> ugh.  ubuntu-devel is member only posting?
* xkahn sighs
<Nafallo> every lists is, no?
<ogra> xkahn, all are
<pitti> every ubuntu lists
<xkahn> Kinda annoying for such a high traffic list.
* xkahn subscribes but turns off delivery.
<seb128> dholbach: around?
<Keybuk> BenC: back
<BenC> Keybuk: is udev-roadmap implemented/done?
<Keybuk> yes, I think so
<Keybuk> mostly anyway
<BenC> ok
<Keybuk> I've still to fix a few bugs
<dholbach>  seb128 yes
<seb128> dholbach: you who work on bug policy, what do we do about those using backport?
<dholbach> seb128: hrm.... as soon as people tell us, that they use backports and we can't dup the bug (sounds strange), cc the backport guys
<dholbach> does that make sense?
<seb128> dholbach: "cc the backports guys" ... do they have a list or something? what do we cc?
<dholbach> ubuntu-backports@lists.ubuntu.com?
<seb128> yeah, looks ok
<seb128> k, thanks
<seb128> (about freetype transition)  the Debian cairo maintainer has dropped a feature to not use a freetype 2.1.10 function ... we have no interest to do this, right?
<dholbach> i'm not sure how that would help
<sivang> how can I chagne a status of a bug from unconfirmed to NEW ?
<sivang> ogra: you are the one giving bug-edit privs right? :)
<seb128> sivang: what about picking the line with "NEW" on it?
<Keybuk> sivang: you should only confirm a bug if you're not the reporter
<Keybuk> confirming your own bugs somewhat defeats the object
<sivang> Keybuk: I am not the reporter
<sivang> Keybuk: I just verified something that was sure to be working in dapper, and is not
<sivang> seb128: pardon?
<sivang> Keybuk: http://bugzilla.ubuntu.com/show_bug.cgi?id=17941
<BenC> if there are two packages that provide "foo-bar", and both also conflict "foo-bar" does that have the affect of making only one of them installable at a time?
<Keybuk> no
<seb128> sivang: you ask how to change a bug to NEW, just pick the line with this label ...
<Keybuk> you need all three of Provide/Conflict/Replace
<sivang> seb128: I want to change a bug from UNCONFIRMED, to NEW , is this the same for this as well?
<BenC> postfix doesn't do that for mail-transport-agent
<BenC> it just provides/conflicts it
<BenC> replaces doesn't make sense to me for that
<BenC> that's more for when a package "goes away"
<seb128> sivang: I think I don't get the question
<Keybuk> Conflict+Replace is the magic "remove and install this one" combination
<sivang> seb128: never mind, I don't own the bug so I can't change it. thanks anywya
<Keybuk> Conflict is just a hard conflict
* sivang --> dinner
<seb128> sivang: if you know what do you ask? 
<BenC> provides/conflicts/replaces does not uninstall though, it overwrites in place
<seb128> Keybuk: you should make a faq/page about that
<Keybuk> seb128: *shrug* it's called POLICY :p
<seb128> lol
<Keybuk> BenC: right, and then disappears the old package
<seb128> Keybuk: yeah, but stuff like using Conflicts when packages don't Conflicts is bad :)
<BenC> that's not what I want though
<Keybuk> you want interchangable virtual packages?
<BenC> postfix/qmail/exim use provides/conflicts for mail-transport-agent, and that seems to be what I want
<Keybuk> exim uses all three
<Keybuk> debian-policy  7.5.2
* sivang was just reading in the policy where it's allowed to use versioned conflicts for the same package
<Keybuk>      In this situation, the package declared as being replaced can be a
<Keybuk>      virtual package, so for example, all mail transport agents (MTAs)
<Keybuk>      would have the following fields in their control files:
<Keybuk>           Provides: mail-transport-agent
<Keybuk>           Conflicts: mail-transport-agent
<Keybuk>           Replaces: mail-transport-agent
<Keybuk>      ensuring that only one MTA can be installed at any one time.
<sivang> anyway, now dinner for real. laterz
<BenC> interesting
<BenC> anyway, I can retroactively add the replaces or conflicts to the old package
<Keybuk> basically the fields go like this (you maintained dpkg once, you should know this :p):
<Keybuk> Replaces - allow overwriting of files without error
<Keybuk> Conflicts - require removal (because files will be overwritten)
<BenC> linux-doc-2.6.12 provides linux-doc-2.6, and I want to have linux-doc-2.6.15 conflict with linux-doc-2.6, so that it uninstalls anything else that provides linux-doc-2.6
<Keybuk> when dpkg hits a Conflict, it stops and throws its toys out of the pram
<Keybuk> but if dpkg hits a Conflict+Replaces, it automatically removes the package
<Keybuk> so
<Keybuk> Provides/Conflicts virtual would mean dpkg would refuse to install your selected package until the existing one was removed
<BenC> yeah, I get how it works, but the c/p/r combination, from what I remembered, was meant for something else other than mail-transport-agent type things, unless virtual packages are a special case
<Keybuk> Provides/Conflicts/Replaces lets dpkg interchange them freely
<Keybuk> virtual-packages are special-cased
<BenC> will apt do the right thing for me with linux-doc-2.6.15 though?
<Keybuk> yes
<BenC> then that's all I need
<BenC> thanks
<Keybuk> assuming linux-doc-2.6 is a virtual package, not a meta-package
<BenC> linux-doc-2.6.12 Provides linux-doc-2.6
<Keybuk> right
<Keybuk> then 2.6.15 should provide/conflict/replace it
<BenC> ok
<Keybuk> so it can automatically replace any existing package
<Keybuk> that also means you can only have one installed at a time
<trevilor> hi guys
<hunger> And I get "BUG: soft lockup detected on CPU#0!" on the console. Any ideas what I can do to narrow down this bug?
<hunger> The box freezes at that point.
* hunger is on the dapper 2.6.15 kernel
<BenC> hunger: is there a full oops after that BUG line?
<hunger> BenC: Nope, nothing.
<BenC> hunger: also, which 2.6.15 dapper kernel, there were quite a few :)
<hunger> BenC: I installed it yesterday night. IIRC it is -5-686.
<Tm_T> huh
<Tm_T> that reminds me: linux-restricted-modules-common doesn't install properly
<BenC> try -6-686
<Tm_T> but I think you already know this :)
<BenC> I fixed a couple of soft lockups there
<hunger> BenC: I will upgrade when I get back into my hotel.
<BenC> Tm_T: elaborate, please?
<hunger> BenC: No net here (at least not for my laptop).
<jdub> BenC: known probs with -5-686 versions?
<jdub> i'm upgrading now, because this laptop is spewing crap anywya ;)
<Tm_T> BenC: oh, sure, just you wait a second
* BenC laughs at the topic
<Keybuk> BenC: soft lockup known?
<Tm_T> BenC: pkg (subprocess): unable to execute post-installation script: Exec format error
<Tm_T> +d
<Diablo-D3> well that was interesting
<xhaker> BenC, what Tm_T is trying to say is that the postinst file puff
<Diablo-D3> 2.6.15-dapper says /dev/sda1 doesnt exist
<Tm_T> /usr/lib/python2.3/site-packages/OpenGL/GL/PGI/vertex_hints.py:28: FutureWarning: hex/oct constants > sys.maxint will return positive values in Python 2.4 and up
<Diablo-D3> anyone else have this bug yet?
<Keybuk> Diablo-D3: dpkg-query -W udev
<Tm_T> and so on
<hunger> Diablo-D3: Upgrade mdoule-init-tools and udev. That fixed that issue for me.
<Diablo-D3> udev    076-0ubuntu4
<Keybuk> Diablo-D3: update to 0ubuntu56
<Keybuk> uh s/6$//
<Diablo-D3> its not in dapper yet, is it?
<jdub> heh, no ! in postinst ;)
<jdub> easy fix tho
<Keybuk> rookery scott% madison-lite udev
<Keybuk>       udev | 076-0ubuntu5 |   dapper/main | source, amd64, i386, powerpc
<Keybuk> Diablo-D3: "yes"
<Tm_T> xhaker: thanks, I'm bit dizzy atm so can't expres myself cleanly allthetime
<Diablo-D3> rm.
<Diablo-D3> Hrm.
<Keybuk> BenC: soft lockup not present in -6, so I guess it was known :p
<ogra> Diablo-D3, the /dev/{h,s}dX not found bug was yesterday ...
<Diablo-D3> ogra: woot.
<xhaker> jdub, LOL.. missed that one.. i was checking the code for something
<Diablo-D3> once again Im not the first to find a bug =(
<ogra> youre lagging a day with your breakage
<Diablo-D3> well, I dont reboot often, ogra =P
<Keybuk> sweet
<xhaker> ogra, btw, chrooting to update the module-init-tools package was sweet :P
<Diablo-D3> btw, in something totally unrealted, I want a tivo
<Diablo-D3> just so I can choose what commericals I want to see.
<ogra> xhaker, :)
<Keybuk> http://people.ubuntu.com/~scott/bootcharts/dapper-20051201-1.png
<Keybuk> ^ 0:52
<Keybuk> improving
<Diablo-D3> Keybuk: how isthat measured?
<Keybuk> Diablo-D3: with the bootchart package
<ogra> 0:52 here too ... on my lappie with 4200rpm disk :)
<Diablo-D3> also, btw, why are we starting hp daemons?
<xhaker> Keybuk, i managed to make it 37 seconds.. but i disabled hplip and whatnot
<Keybuk> xhaker: *shrug* those start after gdm
<xhaker> Keybuk, i disabled some more stuff
<xhaker> now i'm at the default again
<jc-denton> how stable is dapper compared to debian unstable?
<Diablo-D3> how many people use hp printers?
<Amaranth> read the topic
<jc-denton> NO REALL DON'T
<jc-denton> humm
<Diablo-D3> lol.
<jc-denton> so i'll install it
<Diablo-D3> jc-denton: imho, less
<Diablo-D3> but thats a good thing
<HiddenWolf> Diablo-D3, considering their price, a lot of people.
<hunger> jc-denton: It broke my system...
<Diablo-D3> HiddenWolf: feh
<Diablo-D3> I want hp daemon to be optional
<Diablo-D3> just so I can shave like 5 seconds off my boot time or something
<Keybuk> Diablo-D3: it is ... uninstall it
<Diablo-D3> er, since when?
<Keybuk> since we use packages
<hunger> Diablo-D3: I agree. Everybody I know uses a dedicated print server anyway;-)
<Diablo-D3> then why did some VIP (very important package) install it?
<Keybuk> dpkg --purge libc6 if you want
<Keybuk> that's optional too
<jc-denton> hunger: oh..
<HiddenWolf> there is an option in hplibs config to prevent it from booting, right?
<Keybuk> you can replace or remove any part of your system as you see fit
<hunger> jc-denton: So upgrade with care;-)
<xhaker> Keybuk, not if you want to keep ubuntu-desktop
<xhaker> S:
<Diablo-D3> kubuntu-desktop also depends on hp shit
<Keybuk> that's only a problem if you want a supported ubuntu system
<Keybuk> and a supported ubuntu system includes support for HP all-in-one printers
<jc-denton> heh i think i would need a box only for testing to use dapper
<slomo_> fabbione: hi... you told Nafallo to enable xvmc support in mplayer... but mplayer currently supports only a nvidia library it seems, which wasn't found and thus xvmc support wasn't enabled
<Keybuk> eventually we may do clever things like only start the HP stuff if the hardware is detected
<Keybuk> but not for dapper
<hunger> BBL.
<xhaker> Keybuk, what if it only starts if the printer gets added to the printer list?
<Tm_T> xhaker: gnomes printer list?
<xhaker> cups, gnome.. whatever
<xhaker> of course someone has to make the daemon start upon the printer add :P
<Tm_T> I'm not sure if that's good or even usable way to do it ;)
<wasabi_> Cups should start it as part of it's own auto configuration routine when it receives hardware events from HAL. ;)
<xhaker> wasabi_is leet :P
<Tm_T> humm
<Tm_T> maybe
<torkel> pitti: ping
<\sh> elmo: please sync gnotime from unstable, ok to override
<\sh> bah
<\sh> elmo: forget it
<Tm_T> jdub: ping
<\sh> wrong line ...wrong request :(
<dholbach> elmo: please sync libfwbuilder from sid, ok to override
<jdub> Tm_T: pong
<Tm_T> jdub: so you know what's wrong with that restricted modules package? any way I can fix/help to fix it?
<jdub> nup
<jdub> talk to BenC and infinity 
<Tm_T> aye sir
<Tm_T> anything so I get nvidia drivers working ;)
<\sh> jdub: what do I have to do to put something on The Fridge?
<jdub> \sh: mail the editors - fridge-devel@lists.ubuntu.com
<\sh> jdub: merci :)
<jdub> gotta go, battery running out
<crevette> hello
<torkel> Tm_T: edit var/lib/dpkg/info/linux-restricted-modules-common.postinst and change #/bin/sh to #!/bin/sh
<Tm_T> torkel: ah, I will try, thanks :)
<\sh> elmo: please sync hasciicam , hdf5 from unstable, ok to override (and now this is right :))
<crevette> Since 2 days my sound modules are not loaded automaticaaly (I use dapper), is it a known issue ?
<Tm_T> torkel: thank you sir :)
<torkel> Tm_T: np
<Tm_T> hmm, maybe I feel adventurous and even test if it really works ;)
<Tm_T> I mean new kernel etc
<Tm_T> yes, testing ->
<BenC> crevette: 2.6.15 kernel? latest udev?
<raphink> hmm
<raphink> I can't seem to install hotplug
<raphink> it says it requires to uninstall all my kernels and kernel-modules
<BenC> that's because it should be there anymore
<crevette> BenC> I tried 2.6.15 but I had the same with 2.6.12
<BenC> shouldn't
<raphink> which is a bit ... unuself
<crevette> so I assume its a known pb
<crevette> :)
<raphink> BenC: ?
<raphink> but then
<HiddenWolf> crevette, not a known problem, design decision.
<BenC> raphink: hotplug is obsolete
<raphink> all my USB stuff are not recognized anymore
<BenC> upgrade udev
<raphink> except the mouse
<raphink> BenC: well ok
<raphink> then how come my printer doesn't work anymore?
<raphink> nor my USB key?
<BenC> and use 2.6.15, and if all else fails, file a bug report
<raphink> they don't mount
<raphink> they are shown in usbview
<crevette> HiddenWolf>hum ok
<BenC> are you using 2.6.15 and latest udev?
<raphink> but can't be used
<raphink> ok
<raphink> I'll try that
<raphink> earlier today I used 2.6.15 and it wouldn't start
<raphink> it would freeze at PCMCIA staring during boot
<raphink> so I booted with 2.6.12
<BenC> make sure it's 2.6.15-6.8
<raphink> I'll reboot with 2.6.15 
<raphink> BenC: 
<raphink> I'm up-to-date on dapper
<raphink> ;)
<BenC> crevette: you also need newer udev
<BenC> raphink: up-to-date since 12 hours ago?
<raphink> just upgraded a few minutes ago BenC 
<raphink> I upgraded 4 times today
<raphink> ;)
<BenC> ok, please make sure it's latest 2.6.12-6.8, just so I can rest easy, just need to "ls -l /boot"
<crevette> BenC> tx
<BenC> 2.6.15-6.8 I mean
<raphink> ii  linux-image-2.6.15-5-k7     2.6.15-5.7                  Linux kernel image for version 2.6.15 on AMD K7 SMP/UP
<raphink> that's the one I have
<BenC> wrong one
<raphink> oh ok
<raphink> well it's default one in dapper
<raphink> 2.6.15-6 doesn't replace it yet
<raphink> but I'll put it
<BenC> apt-get install linux-image-2.6.16-6-k7
<BenC> damnit, .15 :)
<raphink> hehe 
<raphink> ;)
<raphink> Rception de: 1 http://archive.ubuntu.com dapper/main linux-image-2.6.15-6-k7 2.6.15-6.8 [21,7MB] 
<raphink> that's fine, right?
<raphink> ;)
<raphink> does it change many things from 2.6.12 ?
<BenC> yes, but you shouldn't really notice
<BenC> mostly under-the-hood stuff
<raphink> ok
<raphink> I'll try it
<BenC> linux-meta was updated so that -6 gets pulled in, so you would get that kernel soon anyway
<raphink> :)
<raphink> bubbye :)
<HiddenWolf> keyword being "shouldn't"
<xhaker> does anyone know why intel soundcards doesn't work now? just wanna know if it's udev, kernel or alsa, would be "sad" if it was neither
<xhaker> seems to be alsa.. since i can OSS
<xhaker> :P
<xhaker> i don't really know nothing
<Keybuk> what sound card driver?
<raphink> xhaker: did you upgrade and switch to kernel 2.6.15-6 ?
<raphink> xhaker: did you upgrade and switch to kernel 2.6.15-6 ?
<raphink> I had the same pb, with an ASUS MB
<raphink> I upgraded to kernel 2.6.15-6 and it works now
<raphink> VIA 8235
<raphink> I still have USB pbs though
<raphink> which is pretty bad since I need to print something :(
<xhaker> i'm running that kernel now
<xhaker> no change
<raphink> Keybuk: my printer is not listed in the printer list in kcontrol anymore
<xhaker> alsa-utils refuses to start
<raphink> and in usbview its reference is in red
<Keybuk> xhaker: known bug
<raphink> it's already configured but won't print :(
<raphink> (it worked fine yesterday)
<Keybuk> raphink: interesting.  what kind of printer, what model, make, etc?
<xhaker> Keybuk, any bug number?
<raphink> what kernel xhaker ?
<raphink> what version?
<raphink> Keybuk: PSC 1510
<Keybuk> xhaker: not yet
<raphink> Keybuk: my USB key won't work anymore either
<xhaker> 2.6.15-6
<Keybuk> raphink: is it a USB printer? Parallel port? etc.?
<raphink> since this morning's upgrade
<raphink> (so I'd say 10 hours ago)
<raphink> hmm the USB key seems to work again now
<raphink> Keybuk: http://kubuntu.pastebin.com/445208
<Keybuk> ok, unplug the printer
<Keybuk> run udevmonitor -e
<Keybuk> then plug it back in again
<xhaker> Keybuk, can you please tell me the why of his bug with the soundcard? 
<xhaker> this* :)
<raphink> Keybuk: http://kubuntu.pastebin.com/445211
<Keybuk> xhaker: I haven't done anything with converting sound cards to the new world order yet
<xhaker> you mean /dev...
<Keybuk> huh?
<Keybuk> raphink: do you have a /dev/lp0 ?
<raphink> Keybuk: how do you like that ? ;)
<raphink> how do I know that Keybuk ? :s
<Keybuk> "ls" is favourite
<Keybuk> also do you have /dev/bus/usb/001/005 ?
<raphink> hehe
<raphink> yes I do
<Keybuk> for both?
<raphink> yes
<Keybuk> I suspect your configured printer is for /dev/usb/lp0 ?
<raphink> both
<raphink> wait a min
<raphink> I'll tell you that
<Keybuk> and does symlinking /dev/usb/lp0 to /dev/lp0 make your configured printer work?
<raphink> well 
<raphink> in kcontrol my printer is set to : usb://6543?serial=MY58GDC10M0498
<raphink> lol
<raphink> not sure that helps
<Keybuk> freaky
<Keybuk> does making the symlink make it work?
<raphink> that's the peripheral
<raphink> hmm I'll try
<raphink> ln -s /dev/lp0 /dev/usb/lp0 
<raphink> right?
<Keybuk> right, you may need to mkdir
<raphink> mhm
<raphink> let's try
<raphink> well done Keybuk ;)
<raphink> what is it linked to iyo?
<Keybuk> ok
<Keybuk> needs a BUS=="usb", KERNEL=="lp[0-9] *", NAME="usb/%k" rule putting back
<raphink> something missing in a package ?
<spotter> anyone having lockup issues w/ the new .15 kernel?
<Keybuk> spotter: which "new" kernel?
<spotter> 686 .15-5.7
<Keybuk> yes, everybody, updgrade to .15-6.8
<raphink> use 6.8
<raphink> it works great :)
<spotter> got repeated crashes when I clicked and dragged w/ mouse
<spotter> what was hte problem?
<spotter> btw, lrm-common don't work well with .12 :)
<Keybuk> nothing will work with .12
<spotter> had to manually get my madwifi working :)
<spotter> well, I managed to get bitchx up and running to get here :)
<spotter> Keybuk: where can I download 6.8?
<spotter> just apt-get updated, don't see it
<raphink> spotter: just apt-get update
<raphink> and it's on the repos
<spotter> I did
<spotter> not on the one I seem to check
<raphink> and you didn't find it?
<spotter> archive.ubuntu.com
<spotter> nope
<spotter> not there
<raphink> well yes
<spotter> ah I see it
<raphink> it is
<raphink> in main on archive.ubuntu.com
<spotter> why hasn't the meta package been updated
<raphink> I have it
<spotter> it's -6
<spotter> not -5
<raphink> hehe ;)
<raphink> ;)
<raphink> yep
<raphink> -6.8
<spotter> someone should update the meta package :)
<spotter> lots of people might be forced upgraded to -5 and reboot
<raphink> well -6-[i363|i686|k7] 
<spotter> oh
<raphink> yes someone ;)
<spotter> so not on all platforms, so no meta package yet?
<raphink> yes it's on all platforms
<raphink> no smp yet, but that was also the case for .15-6
<raphink> btw, I'm wondering : why wasn't .14 used ? and isn't .15 a dev version?
<spotter> raphink:
<raphink> (or did the kernel release policy change lately?)
<spotter> raphink: I figured this is to track .15 to make a .16 release
<spotter> ala gnome 2.13
<Keybuk> we're releasing with 2.6.15
<raphink> hmm ok
<raphink> Keybuk: in april, releasing dapper as stable with .15 ?
<Keybuk> kernel release policy is soooo off-topic here, the topic pixies will eat you if you try and discuss it <g>
<Keybuk> yes
<raphink> hzhz
<raphink> haha
<raphink> ok
<raphink> well just that it sounds funny to release a stable distro with a .15 kernel
<Keybuk> why?
<raphink> hmm
<raphink> oh no, it's just the second number of the kernel version that counts for devel
<spotter> Keybuk: cause it's not considered stable by kernel devs?
<raphink> not the third
<raphink> so 2.6.x are stable
<raphink> and 2.7.x are dev 
<raphink> right?
<spotter> raphink: no
<spotter> they changed that
<raphink> hmm 
<spotter> now doing alternate releases
<Keybuk> no.
<spotter> merging and stabelization
<Keybuk> spotter: wrong.
<raphink> spotter: I'm lost with kernel versions lol
<spotter> Keybuk: I was under the impression that 2.6.x where x is odd are now for merging, and where x is even are no merging done, just bug fixes
<Keybuk> spotter: nope
<spotter> ok
<spotter> guess I was wrong
<spotter> not the first time
<spotter> anyone having problems configure lrm-common w/ a "Exec format error"
<raphink> heh, most of us are wrong before being right ;)
<Keybuk> spotter: everyone.
<spotter> :(
<spotter> I looked at the script
<spotter> it looks sane
<Keybuk> except for the missing ! on the first line
<raphink> ok I'm out :)
<spotter> ah
<spotter> I'm blind
<raphink> thank you so much Keybuk, you saved my life on this printer stuff ;)
<spotter> and now to reboot into -6
<mdz> Keybuk: potpal:[/tmp]  diff -u -I '\.static' -I '\.udev' old-dev.txt new-dev.txt
<mdz> potpal:[/tmp] 
<mdz> that's promising
<mdz> it's also completely unbelievable
<mdz> ah, that's more like it
<Keybuk> mdz: what are you trying to do? :p
<mdz> Keybuk: compare the device nodes I got under breezy with the ones I have now
<Keybuk> ahh
<mdz>  1 file changed, 326 insertions(+), 327 deletions(-)
<Keybuk> ?!
<Keybuk> did you not exclude .udevdb / .udev ?
<mdz> I did
<Tm_T> oh great
<mdz> Keybuk: here's one I don't particularly like:
<mdz> drwxrwxrwt 15 root root 14100 2005-12-01 09:50 /dev
<Tm_T> somehow my eth0 isn't pulled up at boot
<Keybuk> hmm
<Keybuk> wonder why that happens
<mdz> missing mode= on the tmpfs mount?
<Keybuk> there wasn't a mode= on the tmpfs mount in breezy
<Keybuk> mount -t ramfs none /dev
<Keybuk> ^ from breezy initramfs
<mdz> maybe init.d/udev fixed it up?
<Keybuk> possibly, just looking now
<mdz> or perhaps ramfs defaults to 755
<mdz> while tmpfs defaults to 1777
<mdz> Keybuk: anyway, I mailed you the full diff from my laptop
<Keybuk> mdz: yup, you got it
<mdz>  /dev/dvd* are missing
<Riddell> Kamion: my merges were delayed because of libstdc++ transition, getting KDE gettext support in and getting KDE 3.5 in, and now I'm at OSDL
<mdz>  /dev/evms now has correct permissions
<mdz> Keybuk: ignore the /dev/fb diff; the old one is from a server install
<Riddell> Kamion: I don't think I need any help but obviously I'm not going to complain if someone does it for me :)
<mdz>  /dev/kmem is missing
<doko> infinity. lamont: please fix the buildd's or please tell me, why the test in the bash build is wrong.
<mdz> a few other bits here and theer
<mdz> there
<doko> Riddell: you can remove the hppa workaround building with 3.4, when gcc-4.0_4.0.2-4ubuntu4 is in the archive for hppa
<Riddell> doko: excellent
<shaya> well, -6-6.8 don't work for me
<shaya> hangs too
<shaya> and .12 and udev wont work together, meaning no gnome right now
<shaya> hopefully hoary's udev will install
<Keybuk> shaya: udev requires 2.6.15
<shaya> yes
<shaya> hence "hoary's udev"
<shaya> as 2.6.15-6 aint working for me
<shaya> hanging in X means cant debug it
<shaya> t42p has no serial cosnole
<shaya> hmm, htere is no udev in hoary?
<shaya> weird
<mdz> Keybuk: this is fairly strange:
<mdz> +dev/disk/by-path/pcmcia--ide-0:0 root root 777 ../../hda
<mdz> shaya: there certainly is
<shaya> right, but I dont see it in aptitude
<xhaker> shaya, maybe what you want is breezy?
<shaya> oh right
<shaya> I'm an idiot
<mdz> regardless, there are udevs in warty, hoary and breezy as well as dapper
<shaya> aptitude dont show it
<shaya> I know there was
<shaya> wondering why aptitude refuses to show it
<mdz> then you haven't configured it to show you the packages from those releases
<shaya> I am
<shaya> aptitude -t breezy even
<mdz> that doesn't cause it to download package lists for breezy
<xhaker> we should setup some bot to remind all of us.. sleep deprivation causes bad things 
<xhaker> /var/lib/dpkg/info/language-pack-en-base.postinst: line 4: /usr/share/locales/install-language-pack: Permission denied
<shaya> mdz: an update should
<shaya> but it didn't
<shaya> needed to apt-get updat
<shaya> for some reason aptitude update refused to update those lists
<torkel> xhaker: filed as #20351
<mdz> you probably didn't have them in sources.list
<xhaker> thanks torkel 
<shaya> mdz: I did, ran apt-get update right after quiting aptitude
<shaya> after apt-cache show showed that it hadn't updated those lists
<mdz> you probably didn't have them in sources.list [the last time you ran an update] 
<shaya> I agree that's what it would seem, but I'm pretty sure I did
<torkel> xhaker: just change the permission of /usr/share/locales/{install-language-pack,remove-language-pack} and reinstall the lang-packages
<xhaker> yeh toresbe 
<xhaker> torke
<Keybuk> mdz: strange how?  it's a pcmcia ide controller?
<mdz> Keybuk: no, it isn't
<mdz> it's a PCI IDE controller
<Keybuk> heh
<Keybuk> mdz: SATA controller?
<mdz> Keybuk: nope
<mdz> 0000:00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01)
<mdz> Keybuk: this is on my T42
<Keybuk> weird
<Keybuk> what does readlink /sys/block/hda/device say?
<xhaker> ../../devices/pci0000:00/0000:00:1f.1/ide0/0.0 for mine.. i got the same controller
<mdz> pitti: these postgresql debconf messages cause FURY
<mdz> Keybuk: ../../devices/ide0/0.0
<pitti> mdz: yes, sorry, I had no time to do Debian stuff yesterday and today :/
<pitti> mdz: but there is an easy fix, just remove the old packages :)
<mdz> pitti: you know about "/usr/share/locales/install-language-pack: Permission denied" already ,right?
<Keybuk> mdz: hmm, top-level ide controller ... could mean your IDE controller module wasn't loaded properly
<mdz> pitti: launchpad only works with 8.0
<pitti> mdz: uh, no, I don't
<fabbione> slomo: i doubt but i will look at it
<mdz> pitti: there will be other people in the same position, who must stay with 8.0 for one reason or another, and we should not harass them
<pitti> mdz: yes, I'll fix the note eventually
<mdz> Keybuk: for what value of 'properly'?
<mdz> Keybuk: it was sufficient to mount the root filesystem at least
<slomo_> fabbione: is xvmc support really important for you atm? i'm currently repackaging mplayer as marillat's package was unmaintainable...
<fabbione> slomo: well it's nice to have.
<Keybuk> what does readlink /sys/devices/ide0/0.0/driver say?
<mdz> ../../../bus/ide/drivers/ide-disk
<Keybuk> is there a /sys/devices/ide0/driver ?
<slomo_> fabbione: sure :) i'll take a closer look tomorrow
<Keybuk> and lsmod | grep ide_core ... is there a "real" driver tagged on there other than ide_generic
<hunger> l-r-m-common has a broken postinst (missing ! in #!/bin/sh).
<hunger> The 2.6.15-6-686 kernel does not boot. The initramfs does not find /dev/sd*
<Keybuk> hunger: update udev and module-init-tools
<hunger> Keybuk: I did!
<hunger> Keybuk: -5-686 boots
<crimsun> Keybuk: the latest udev breaks it again for me
<Keybuk> udev or kernel?
<crimsun> udev.
<Keybuk> which breaks and which works?
<fabbione> DEVELOPER MEETING -> now
<crimsun> Keybuk: 076-0ubuntu4 works, neither 3 nor 5 do
<hunger> Keybuk: I am at whatever is in the archives right now. That does NOT work.
* ogra silently opens the door between -meeting and -devel and looks for mdz
<Keybuk> it works for me
<Keybuk> so clearly it does work
<Keybuk> and there's something different about your machine
<Keybuk> your root filesystem is /dev/sda1 and it doesn't exist?
<crimsun> must be. /dev/sda3 can't be found with either 3 or 5, which is probably the same issue hunger is running into.
<hunger> Keybuk: Yeap. /dev/sda1 is on the disk.
<Keybuk> "is on the disk" ?
<hunger> Keybuk: It is not found in /dev
<Keybuk> righ
<pitti> mdz: locales package fixed
<Keybuk> boot with break=premount on the kernel command line
<Keybuk> . conf/initramfs.conf
<Keybuk> . scripts/functions
<Keybuk> . scripts/$BOOT
<Keybuk> scripts/init-premount/acpid
<Keybuk> udevd --daemon
<Keybuk> uh, UDEV_LOG=info udev --daemon
<dholbach> Kamion: so what is the car like? :)
* Keybuk sits down and starts singing about gold
<ogra> Keybuk, gold ?
<Keybuk> ogra: waiting for either crimsun or hunger to declare they've reached the initramfs prompt
<ogra> ah :)
<pitti> seb128: I'll try this fi_FI.UTF-8 bug tomorrow; with a bit of luck, the belocs locales even fix it :)
<slomo_> fabbione: seems like i got it working... i'll try if it only builds or if it actually works ;)
<fabbione> ok
<Keybuk> *shrug* guess the lack of a root filesystem can't be _that_ important to them then <g>
<crimsun> Keybuk: I'll reboot to test as soon as I'm finished with office hours
<crimsun> (13 mins)
<seb128> pitti: thanks
<torkel> pitti: if you have fixed locales I'll close #20351 (If I am allowed to close bugs I have submitted)
<pitti> torkel: I fixed the permissions of {install,remove}-language-pack
<pitti> torkel: I didn't look at bugs yet
<pitti> torkel: right, it's that
<torkel> pitti: yeah, I filed a bug about it while you was away :-)
<pitti> torkel: I'll close it in a minute with the changelog
<torkel> pitti: ok
<pitti> closed
<pitti> thanks
<elmo> dholbach: umm
<elmo>  Homepage: ftp://ftp.gnome.org/pub/gnome/sources/gnome-web-photo
<dholbach> elmo: i can change it
<elmo> dholbach: do you really think that's worthwhile info for the extended description?
<dholbach> elmo: maybe not, you're right
<elmo> meric
<elmo> merci too.  damn it, can't have my language trolling spoiled by typoes
<dholbach> :)
<Keybuk> lol @ splash screen
<elmo> sigh
<sistpoty> elmo: read in backlog my sync-request for libghemical (ubuntu override ok)?
<lamont__> doko: debootstrap doesn't build /dev/fd
<doko> lamont__: please fix it
<ajmitch> elmo: please sync module-assistant, changes can be dropped
<Kamion> debootstrap defers to frontends for most devices these days
<lamont__> ls -l /dev/null
<lamont__> c---------  1 root root 1, 3 May  9  2005 /dev/null
<lamont__> now that's amusing
<crimsun> Keybuk: there's no scripts/init-premount/acpid
<Keybuk> crimsun: sorry, it's called thermal now
<Keybuk> crimsun: can you come on #ubuntu-boot so we don't flood the channel
<torkel> BenC: ping
<BenC> torkel: pong
<torkel> BenC: Got a sec or to for a kernel related question?
<pitti> ogra: but the coded isn't in gstramer0.8-mad
<pitti> ogra: it's in libmad0, which is in main since warty
<BenC> torkel: shoot, but give me a minute or two to answer
<torkel> BenC: I'm trying to fix the openafs kernel module to build against 2.6.15-6.8
<Riddell> dholbach: see my comment to kamion at 19:27UTC about helping with merges :)
<ogra> pitti, oh, i thought it was included there 
<torkel> BenC: You have applied a patch (from Joel Becker) that changes WRITEPAGE_ACTIVATE to AOP_WRITEPAGE_ACTIVATE and also changes it from a define to an enum.
<pitti> ogra: no, it's just a gstreamer wrapper around libmad
<torkel> BenC: What would be the best (correct) way to test if the kernel has WRITEPAGE_ACTIVATE or AOP_WRITEPAGE_ACTIVATE
<ogra> ah
<torkel> BenC: The patch is not in upstream kernel, so I guess it is wrong to check with #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,15)
<pitti> ogra: that's the silly thing about it - we could have mp3 support in the last three releases
<BenC> torkel: #ifndef WRITEPAGE_ACTIVATE
<ogra> heh, just not officially
<torkel> BenC: ok. Thanks
<BenC> if it's not defined, then use AOP_WRITEPAGE_ACTIVATE
<Kamion> pitti: JAIL
<pitti> Kamion: not us Europeans, but jdub :)
<torkel> BenC: I was not just sure if that was good enough
<BenC> torkel: should be
<torkel> hopefully it will be enough for openafs upstream too...
<BenC> torkel: can you email me info about the patch that changed that? (just the commit sha1, or the subject line the commit description)
<BenC> bcollins@ubuntu.com
<torkel> mail sent. Looks likes it comes from the OCFS2 tree
<elmo> Kamion: have you tried tailor btw?
<Kamion> elmo: no, not yet
<elmo> Kamion: it may no longer be relevant, but it's quite cool, when it works ;)
<Kamion> apparently native bzr support for svn branches is coming RSN
<elmo> *snort* bzr in dapper doesn't even have working annotate
<lifeless> ?
<lifeless> what version is in dapper
<pitti> elmo: WFM?
<elmo> ii  bzr                    0.6.2-0ubuntu1    
<elmo> gives me http://people.ubuntu.com/~james/tmp/bzr.log
<pitti> oh, sorry, I use jbailey's daily crask
<elmo> lifeless: ^--
<elmo> I reported it on #bzr a couple of days ago
<lifeless> elmo: bugs really should go in malone
<lifeless> but that said...
<lifeless> annotate in head works, 0.7 should fix it, and thats not too far off now
<elmo> lifeless: duh, I didn't drive by it, I asked if it was known, and mbp said no and he was looking at it
<elmo> would have quite happily reported it if told to or if no one had said anything
<lifeless> elmo: wasn't accusing you of drive-sorry if it sounded like I was
* lifeless gets breakfast and caffiene
<lifeless> before pissing people of :)
<cshields> elmo: hey..  who runs the forums site?  I was talking to sabdfl while he was in portland tuesday and mentioned the OSL would like to help out, he said forums was in a bit of need
<Diablo-D3> hrm.
<Diablo-D3> I must be on crack
<Diablo-D3> I cant find the new version of udev
<Diablo-D3> ........
<Diablo-D3> oh fuck.
* Diablo-D3 installed it already.
<dholbach> good night ubunteros
<Diablo-D3> night dholbach 
<pitti> night daniel!
<elmo> cshields: that'd be Ryan Troy
<cshields> elmo: he on irc at all?
<\sh> ok listen people...I
<cshields> (btw, did we ever get spohr back on to the out-of-band net?)
<Diablo-D3> woot
<Diablo-D3> 2.6.15 boots for me
<\sh> 'm desperate and I need really fast a new job...(!= canonical, sabdfl already has my cv)
<elmo> cshields: not much, I don't believe - the three main people are him, john dong and kassetra.  john at least is usually on IRC a lot as 'jdong'
<\sh> read the planet and you know all about it...thx
<cshields> elmo: k, thx
<Diablo-D3> oh grea
<Diablo-D3> I spoke too soon
<Diablo-D3> it stops at "Starting PCMCIA services"
<Diablo-D3> and this box doesnt have pcmcia slots either
<Diablo-D3> er, hey guys, which key exits usplash so I can see the console?
<Kamion> have you upgraded pcmcia-cs and installed pcmciautils?
<xhaker> ctrl + alt + F*
<Kamion> because pcmcia-cs should be a no-op now, and I have trouble imagining pcmciautils hanging
<\sh> Diablo-D3: #ubuntu 
<Diablo-D3> uh
<Diablo-D3> Im wondering if my box locked up\
<Diablo-D3> I cant change terminals
<pitti> good night everybody
<ajmitch> certainly possible, try toggling caps lock :)
<ajmitch> night pitti 
<Diablo-D3> night pitti
<Diablo-D3> damn
<ajmitch> hi mvo :)
<Diablo-D3> ajmitch: heheh, I need to turn the watchdog back on
<mvo> hello ajmitch
<Diablo-D3> yup locked up
<Diablo-D3> is the logs on the console logged anywherere
<andrea> hi there, does ubuntu support dual xeon?
<neuralis> andrea: that's a question for #ubuntu. this is the ubuntu development channel.
<andrea> neuralis: would you please ask someone in #ubuntu to answer?
<neuralis> andrea: in short, yes, i wouldn't expect you'd have any problems with it.
<andrea> neuralis: thanks. so difficult.
<fabbione> hey neuralis 
<neuralis> andrea: it's not difficult, but if everyone starts coming into this channel with their quick question, it will become completely useless for development discussion.
<neuralis> fabbione: hey!
<dsas> has anyone saw mez recently?
<fabbione> nope
<dholbach> elmo: i tried to upload the changes to gnome-web-photo, but it was rejected - should i just upload it without .orig.tar.gz?
<dholbach> elmo: i'll ask tomorrow.. i'm off now
<dholbach> *wave*
<ogra> mumble mumble .... 
* ogra hates power outages
<janimo> Kamion, was the gtk d-i deferred after dapper too?
<Kamion> janimo: yes
<Kamion> we're not working on that ourselves; upstream are working on it and we'll pull stuff in as/when it matures
<Nafallo> ogra: word!
<Nafallo> ogra: if you find an easy way to build an UPS for 15V, ping me :-)
<dsas> fabbione: ok, thanks for letting me know.
<ogra> i *have* a 3.5KV UPS here ...
<ogra> but my router isnt connected to it ... and the rest of the house isnt either
<Keybuk> Nafallo: isn't that just called a "laptop battery" ?
<Nafallo> Keybuk: doesn't work for my adsl2+ modem and soon AP though ;-)
<Nafallo> ogra: who cares about the rest of the house as long as the laptop have internet? ;-)
<Diablo-D3> <Kamion> because pcmcia-cs should be a no-op now, and I have trouble imagining pcmciautils hanging
<Diablo-D3> well lets see if I have it installed
<Diablo-D3> yes, its the newest version.
<ogra> Nafallo, 15V ? put a car battery parallel
<Diablo-D3> hey Kamion 
<Diablo-D3> pcmcia-cs doesnt look like a forwarding metapackage thingy
* Diablo-D3 removes usplash and tries again, hopefully getting a log this time
<Nafallo> ogra: hm, good point.
<ogra> seems our stove is broken :(
<Diablo-D3> so lets see
<Diablo-D3> boot, boot, the magical function, the more you something the more you something that rhymes with boot.
<Diablo-D3> okay
<Diablo-D3> here we go
<Diablo-D3> Intel ISA PCIC probe: not found
<Diablo-D3> BUG: soft lockup detected on CPU#0!
<Diablo-D3> locked up in modprobe, while executing _spin_lock_irqsave
<Diablo-D3> so, what do I do now?
<dilinger> hrm
<dilinger> mjg59: is usplash in breezy smp safe?
<dilinger> i'm seeing amd64-k8-smp hang on my dual opteron machine, while amd64-k8 chugs happily along
<Diablo-D3> dilinger: where is it locking up?
<dilinger> right at the start; it display the ubuntu logo, the little progress bar, and then the machine hangs
<dilinger> no progress text, and no progress in the bar
* dilinger tries booting w/out the splash kernel arg
<Diablo-D3> apt-get remove usplash and boot with amd64-k8-smp
<Diablo-D3> to see if its actually usplash
<dilinger> wow
<dilinger> that is the most awesome kernel oops i've ever seen
<Diablo-D3> what?
<dilinger> i killed the quiet and splash args
<dilinger> and booted, and it spewed backtraces for a good 60 seconds
<Diablo-D3> rotfl
<Diablo-D3> good going dilinger 
<Diablo-D3> btw, is sound broke for everyone else?
<xhaker> it is
<Diablo-D3> just making sure
<otavio> Hi folks, I just want to notify that I received a REJECT mail from your upload queue ;-)
<Diablo-D3> is anyone else having problems with pcmcia hitting the fan?
<Diablo-D3> I mean, the bug makes no sense
<Diablo-D3> I have no pcmcia hardware
<otavio> From: Launchpad Admins <launchpad@lists.canonical.com>                                                                                        
<sistpoty> otavio: which package?
<otavio> Subject: abntex_0.8.2-1_source.changes REJECTED                                                                                               
<otavio> To: Launchpad Admins <launchpad@lists.canonical.com>,                                                                                         
<otavio>         Ubuntu Archive Auto-Sync <katie@rockhopper.ubuntu.com>,                                                                               
<otavio>         Otavio Salvador <otavio@debian.org>                                                                                                   
<otavio> sistpoty: this is the header of mail
<elmo> otavio: sorry, that was a mistake
<otavio> elmo: no problem
<LaserJock> Diablo-D3: I am having the pcmcia problem too
<elmo> otavio: we've disabled the MTA and are working to ensure it shouldn't happen again
<otavio> elmo: don't worry about, i was just interested to warn about the issue
<elmo> otavio: thanks for letting us know
<otavio> elmo: you're welcome
<otavio> i'm interested to know if trac package is included in ubuntu. If  yes, I'm uploading 0.9.1 to sid and it has a serious security bug fixed
<otavio> the issue don't affect 0.8.x versions
<elmo>       trac | 0.9-1ubuntu1 | dapper/universe | source, all
<otavio> elmo: so, grab 0.9.1 from incoming in some minutes
<otavio> elmo: are you interested in a patch for 0.9?
<elmo> otavio: once 0.9.1 hits sid, the MOTUs will get notification and our changes will either be merged or we'll just pull 0.9.1 in directly
<elmo> otavio: don't worry, thanks, we'll merge your 0.9.1 one way or another
<otavio> elmo: ok
<ajmitch> otavio: it'll be a quick merge, the only ubuntu change is changing python2.3 to 2.4
<otavio> ajmitch: good to know
<otavio> ajmitch: i hope we move to python 2.4 in debian asap
<Diablo-D3> lol
<Diablo-D3> even though its locked up
<Diablo-D3> I get event debugging lines
* Diablo-D3 removes pcmcia shit
* Diablo-D3 reboots yet again
<Diablo-D3> grr
<Diablo-D3> how can it start pcmcia services if there is no pcmcia stuff installed
<HiddenWolf> I guess it has to start it to figure out that there's no pmcia. 
<HiddenWolf> Either that, or it's braindead.
<Diablo-D3> braindead
<Diablo-D3> has to be
<ajmitch> elmo: please sync fluidsynth, dropping ubuntu changes
<SEJeff> So how bad will dapper break if I reboot right now?
<Diablo-D3> SEJeff: probably quite bad
<SEJeff> I just noticed that linux-restricted-modules postinst fails. I don't think I'll be rebooting anytime soon
<Diablo-D3> SEJeff: make sure you keep your old working kernel installed
<ogra> SEJeff, if you care that everything is up to date (udev, initramfs-tools and module-init-tools) it will be fine
<Diablo-D3> ogra: nope, it wont
<ogra> Diablo-D3, yes it will 
<Diablo-D3> ogra: many people are having issues with pcmcia shit hanging the kernel
<Diablo-D3> even if they dont even own pcmcia hardware
<SEJeff> This is on a desktop
<ogra> Diablo-D3, please stop this
<Diablo-D3> stop what?
<SEJeff> But kernel module debs failing postinst says that I shouldn't reboot
<Diablo-D3> SEJeff: unless you require nonfree drivers, the lack of that wont hurt much
<Diablo-D3> ogra: um, you do realize I'm not kidding around, right?
<SEJeff> Diablo-D3: I am running the ATI drivers, but that shouldn't matter
<fabbione> good night guys
<Diablo-D3> SEJeff: yeah, you just wont get X then =P
<SEJeff> Diablo-D3: Try this thing called tact
<SEJeff> no x isn't a big deal
<Diablo-D3> ogra: pcmcia starting up, even through lack of pcmcia hardware, locks the kernel up
<ogra> SEJeff, make sure module-init-tools 3.2.1-0ubuntu3, udev 076-0ubuntu3, initramfs-tools 0.40ubuntu1 are installed and you will be fine
<SEJeff> I'm just going from latest update && dist-upgrade
<Diablo-D3> ogra: so far I've gotten it on one of my machines, and 2 others have reported it in here as far as I've seen
<ogra> Diablo-D3, please stop spreading FUD here
<Diablo-D3> ogra: please take your own advice.
<Diablo-D3> ogra: just because /you/ arent experiencing it, doesnt mean others arent as well.
<ogra> Diablo-D3, i have 8 machines here that boot fine and 3 laptops
<Diablo-D3> ogra: thats good for you.
<SEJeff> Diablo-D3: He is saying you don't need to argue. Chill out man
<ogra> Diablo-D3, others are fine too
<Diablo-D3> SEJeff: no, hes saying I'm lying about tbe bug
<SEJeff> Diablo-D3: Well post a link for us to look at
<minghua> to be fair to Diablo-D3, I used to have the same lockup-on-boot problem when pcmcia starts with 2.6.15-4 kernel, I've not tried the recent kernels though
<LaserJock> ogra: I have the same problem as Diablo-D3 (the pcmcia one anyway) but ogra is right Diablo-D3, you need to chill a little bit
<Diablo-D3> why am I automatically the enemy here?
<Diablo-D3> someone asked if booting the newest dapper kernel was a bad idea, and I said yes it was.
<LaserJock> because you get hot too fast and you are rude
<SEJeff> Diablo-D3: Because you are acting childish and arguing over something that isn't a big deal like it is
<SEJeff> Diablo-D3: And your complete lack of this thing we like to call tact
<Diablo-D3> I really do get a kick out of you guys.
<Diablo-D3> Instead of helping to fix the bug, you argue about it's existance first.
<Diablo-D3> Thats pretty backwards imo
<LaserJock> anyway, I only get the lock up with the 2.6.15 kernel which, as the topic says, is probably not wise to rely on right now
<LaserJock> Diablo-D3: you don't help either by being so rude all the time. It just annoys the people trying to help
<minghua> Diablo-D3: complaining on this channel doesn't help fixing the bug either
<ogra> LaserJock, are you already on 2.6.15-5 ?
<crimsun> there are a number of issues at play here; the kernel and udev are just the highest profile ones
<Diablo-D3> minghua: I agree, I'd wish people would just shut up if they aren't willing to help.
<LaserJock> ogra: not at the moment. I'm in breezy cause of all the kernel probs in dapper
<SEJeff> trulux: ping
<ogra>  the -5 kernel should be a relatively safe one already
<LaserJock> ogra: well it hard locks when starting the pcmcia stuff
<ogra> sure thats -5 ? 
<SEJeff> Let me see if I understand this correctly... hotplug is going away in favor of the new sysfs + udev integration?
<ogra> yup
<LaserJock> ogra: vmlinuz-2.6.15-5-k7
<ogra> udev is moving into initramfs
<SEJeff> thats alot more flexible
<SEJeff> I see why there are problems, thats a very invasive change
<ogra> s/moving/moved
<ogra> LaserJock, do you still have old pcmcia stuff in place ? 
<LaserJock> ogra: I don't have anything pcmcia
<ogra> LaserJock, look at your initscripts
<LaserJock> ogra: it is in init.d
<ogra> which one ? 
<ogra> pcmcia or pcmciaurils ? 
<LaserJock> both
<LaserJock> pcmciautils right ;-)
<Diablo-D3> LaserJock: try a dpkg --purge pcmcia-cs
<crimsun> SEJeff: currently there's a race condition with the root device not actually being ready when initramfs want to gogogo
<thierry_> if I have Icon=/usr/share/pixmaps/zapping/gnome-television.png , I can't put it without the absolute path right?
<ogra> pcmciautils should be ok ...
<ogra> pcmcia shouldnt be there its useless
<SEJeff> crimsun: And I'm guessing it's not quite as easy to fix as sleep 2
<LaserJock> ogra: so should I do as Diablo-D3 suggests?
<Diablo-D3> btw, I think pcmcia-cs should be replaced with a dummy package that just requires pcmciautils
<crimsun> SEJeff: no. keybuk and I just spent two hours on it
<ogra> you either might try it or wait 8-9h until Keybuk returns
<Diablo-D3> just to get rid of the damn init script
<Diablo-D3> Im going to try rebooting yet again, which everything pcmcia confirmed to be gone
<crimsun> in the end, though, Dapper has hellafast boots.
<Diablo-D3> crimsun: oh yeah
<Diablo-D3> crimsun: z00m
<LaserJock> alright, I will try it and brb
<Diablo-D3> I've seen embedded devices boot slower.
<SEJeff> crimsun: What makes it so much faster, kernel, or init scripts?
<ogra> LaserJock, also make sure new udev etc are in the initramfs ...
<crimsun> SEJeff: udev, kernel, initramfs
<Diablo-D3> crimsun: do we have parellel initing yet?
<SEJeff> no
<ogra> sudo dpkg-reconfigure linux-image-2.6.15-5
<SEJeff> Diablo-D3: That is going to be based off of the LSB spec I believe similar to how fedora has it. You would see it in the init scripts if it was
<crimsun> parallel init is kinda pointless with what keybuk and jbailey have done with udev and initramfs
<ogra> thats the next step ...
<Diablo-D3> crimsun: Im still trying to figure out what they did
<SEJeff> How is something that can shave time off of the boot pointless?
<Diablo-D3> btw, whats the name of the package that measures boot time again?
<SEJeff> My breezy box boots to a gnome desktop in 35 seconds with initng. Even though initng is a bit hackish atm
<SEJeff> Diablo-D3: bootchart
* Diablo-D3 installs it
<crimsun> SEJeff: it's not pointless in the long run, but it's pointless right now because udev hasn't even begun to settle down, and udev has already shaved tens of seconds off boot times
<Diablo-D3> too bad its written in java =/
<Diablo-D3> btw, using gdm over kdm should increase boot time even more, right?
<SEJeff> crimsun: I understand.
* Diablo-D3 is on a boot time kick atm
<Diablo-D3> so all I do is add bootchart to the kernel line, right?
<SEJeff> http://www.bootchart.org/docs.html
<Diablo-D3> ahh okay
<ogra> you just install it... it does everything for you
<Diablo-D3> ogra: I dont have to add init=/sbin/bootchartd to my grub line?
<ogra> it puts the png into /var/log/bootchart
<ogra> nope
<Diablo-D3> okay!
<ogra> it installs in the initramfs ...
* Diablo-D3 reboots, mainly to see if pcmcia works
#ubuntu-devel 2005-12-07
<Diablo-D3> okay
<ogra> got your bootchart ? 
<Diablo-D3> 2.6.15-5 boots with pcmcia-cs and pcmciautils --purged
<Diablo-D3> took 45 seconds to boot.
<Diablo-D3> but this is with apache2 and mysql included
<mjg59> dilinger: Uhm. As far as I know...
<SEJeff> Diablo-D3: Could you post your bootchart?
<Diablo-D3> uh sure
<Diablo-D3> actually
<Diablo-D3> I wanna do another one
* Diablo-D3 disabled a few things he isnt using
<SEJeff> Diablo-D3: awesome, thanks
<dilinger> mjg59: ok, turns out to be some framebuffer or other display thing, i think
<Diablo-D3> Ill do it after I get back from dinner
<SEJeff> ok
<ogra> LaserJock, so ? 
<LaserJock> ok, back
<LaserJock> I had to get rid of pcmciautils also
<ogra> but you are on 2.6.15-5 now ? 
<LaserJock> yep
<ogra> yay
<LaserJock> but I had to get rid of ubuntu-desktop and ubuntu-minimal. oh well
<LaserJock> but sound and nvidia now work so that is cool too
<LaserJock> so I don't know what is the problem with pcmcia and the 2.6.15 kernel but since I don't have any pcmcia I'm doing better than 2.6.12 right now
<mdz> fabbione: why do you want to assign server-candy to a team rather than to yourself?
<mdz> fabbione: it makes the summary displays in launchpad less useful
<neuralis> ptlo: hey
<ptlo> heya neuralis :)
<ptlo> whassup
<hawke_> Before I file a bug for lsb-release, has its behaviour changed intentionally recently?
<neuralis> ptlo: finally working on the community server testing spec, will try to get it in line with mdz's wishes
<ptlo> neuralis: that's nice, hope you won't have to do many changes to the initial drafts 
<neuralis> ptlo: the initial drafts essentially don't at all deal with what mdz had in mind ;)
<ptlo> then good luck with the rewrite :)
<Diablo-D3> ahh
<Diablo-D3> food is a wondeful thing
* Diablo-D3 had an ansi standard pizza.
<Diablo-D3> LaserJock: there really isnt a difference
<Diablo-D3> LaserJock: pcmcia kernel modules and the userland stuff are two halves of the same thing
<Diablo-D3> LaserJock: ie, one breaks, it all breaks =P
* Diablo-D3 reboots for great justice
<Diablo-D3> LOL!
<Diablo-D3> great usplash!
<Diablo-D3> okay
<Diablo-D3> 45 seconds
* Diablo-D3 launches all zig
<neuralis> ptlo: for dapper+1, someone should write a M^7 spec. multiple mdzs mingling merrily 'mong mere mortals.
<neuralis> ptlo: this would solve all of our BOF issues.
<Diablo-D3> http://shadowconflict.com/dapper-20051201-2.png
<Diablo-D3> SEJeff: there.
<ptlo> neuralis: hahahahah :))
<ptlo> good job on the bacronym :)
<Diablo-D3> neuralis: lol
<mpt> neuralis, we used to plot doing that in the Mozilla Project too
<mpt> Cloning Dave Hyatt and Blake Ross
<Diablo-D3> is dave hyatt related to the one that works for apple?
<tseng> he is the one
<Diablo-D3> ahh, I've met him on irc
<Diablo-D3> hes cool
<tseng> he is a firefox hater now iirc
<Diablo-D3> and he likes my blog <3
<mpt> He's the god of Web browsers
<mpt> He worked on Netscape 4
<mpt> and started Firefox
<mpt> and started Camino
<mpt> and now works on Safari
<Diablo-D3> I moved the image
<mpt> oh yeah, and worked on the Mozilla suite
<mpt> and invented XUL
<mpt> and XBL
<Diablo-D3> http://shadowconflict.com/blog/dapper-20051201-2.png
<Diablo-D3> fear my awesome fast machine!
<neuralis> tseng: interesting, he had his fingers in creating it. what happened?
<Diablo-D3> neuralis: he realized khtml rocks.
<LaserJock> Diablo-D3: sorry, I was away, what did you mean about the pcmcia stuff?
<tseng> neuralis: he decided KHTML is a good idea
<tseng> (pass the pipe)
<Diablo-D3> LaserJock: you said you didnt know which was causing the problem
<Diablo-D3> LaserJock: and I said it really didnt matter
<Diablo-D3> something needs a smackdown! woopah!
<LaserJock> Diablo-D3: hmm, ok, I just noticed that removing just pcmcia didn't work. I had to remove pcmcia-utils also
<Diablo-D3> LaserJock: yeah
<Diablo-D3> I had to dpkg --purge pcmcia-cs pcmciautils to make it work
<Diablo-D3> other than the sound being broke, everything seems to be working
<LaserJock> really, sound works for me now too
<Diablo-D3> er, it does?
* Diablo-D3 checks
<neuralis> tseng: weird. drugs are bad.
<Diablo-D3> oh
<Diablo-D3> bah
<tseng> I agree
<Diablo-D3> sound works
* Diablo-D3 listens to music!
<jsgotangco> yo jdub i'm at the conference now
<Diablo-D3> conference?
<ajmitch> jsgotangco: great, how is it?
<ajmitch> when is your talk?
<jsgotangco> Diablo-D3, linux desktop conference in seoul
<jsgotangco> ajmitch, in an hour
<ajmitch> nervous yet? :)
<Diablo-D3> jsgotangco: ahh, cool
<jsgotangco> ajmitch, not really
<jsgotangco> i had to talk to the translator today
<jsgotangco> poor jdub he really missed a lot
<jsgotangco> the wireless is shitty though
<ajmitch> as bad as UDU?
<jsgotangco> pretty much
<ajmitch> ouch
<jsgotangco> its terribly cold though
<jsgotangco> great im going to present in a windows laptop for a linux desktop conference
<ajmitch> you don't have a cd on hand?
<Amaranth> it seems like backports is quickly expanding from "apps that lots of users want" to "any and all packages that build on breezy"
<desrt> something is extremely messed up with gpg right now
<desrt> sebastien's key is seriously messed up
<desrt> all of his normal signatures have expired and he has a tonne of new signatures from himself and from some other person who shares a similar key id (seb=A2D7D292 them=A2D70910) and whose key corrupted my gpg keyring as a result of downloading it
<Amaranth> rHLfuwf is a bot.
<Amaranth> "ircdig.com spider"
<desrt> http://keyserver.ubuntu.com:11371/pks/lookup?search=seb128&op=vindex
<desrt> i wonder if his key got 0wned?
<SEJeff> Diablo-D3: Thanks, I was out for a bit
<SEJeff> Diablo-D3: Are you hosting that domain on dialup? It's super slow ;-P
<tseng> desrt: yeah whats with the dozens of selfsigs
<desrt> tseng; i just refreshed his key (last refresh was maybe a week ago) and it was like "22 new sigs"
<desrt> tseng; +notice that all of his legit sigs have expired
<desrt> sig 3     X  44779E18 2004-04-10  Fabio M. Di Nitto <fabbione@debian.org>
<desrt> sig 3     X  91CFA34D 2004-08-16  James Henstridge <james@jamesh.id.au>
<desrt> etc
<desrt> ok.  not all of them, but many of them.
<desrt> something bad is happening
<desrt> ubuntu's keyserver, pgp.net keyservers and my gpg are all in agreement about this much :)
<jamesh> desrt: I'll look at fixing up the code of conduct validation code today, so you don't need to remove your tinfoil hat
<desrt> jamesh; thanks :D
<desrt> jamesh; any reason why your signature on sebastien's key has expired?
<desrt> (along with a bunch of other people)
<jamesh> desrt: no idea
* desrt is becoming extremely concerned
<jamesh> desrt: maybe his key was marked to expire then?
<desrt> jamesh; no.  only some of the signatures have expired
<desrt> and it's the sigs themselves... not the key
<jamesh> desrt: when you sign a key with an expiry date, it asks you if you want the signature to expire when the key expires
<jamesh> desrt: but I've got no idea.
<desrt> jamesh; i'm going to try and find out.  this is rather disturbing since my gpg is supposed to independently verify that the signature you've made on his key is valid and it seems to not be doing so
<jamesh> desrt: maybe the key has been modified, so the signatures are invalid
* desrt scratches head
<desrt> but then the fingerprint wouldn't be the same, one would think
<desrt> and therefore all signatures would break
<desrt> type this:
<desrt> gpg --recv-key CA57AD7C
<desrt> tell me what happens
<SEJeff> desrt, gpg: key CA57AD7C: public key "PGP Global Directory Verification Key" imported
<SEJeff> desrt, worked fine
<desrt> no errors about invalid packet sizes?
<SEJeff> desrt, buffer shorter than subpacket. I got that 9 times
<desrt> that's what i mean
<desrt> this key has signed behdad's key with 22 expired signatures
<desrt> that are dated 2005-01 through 2005-08 but all appeared just now
<desrt> seems to be related to sebastien's problems
<tseng> maybe a bad sign script just corrupted his key
<tseng> doesnt make sense it would sign *itself* repeatedly though
<desrt> even if both behdad and seb128's keys were 0wned, the keyservers shouldn't accept key uploads that cause my gpg to spew error messages when i use them
<Amaranth> maybe a bad server replicated bad info throughout the system
<desrt> Arrogance; even if that was the case, my gpg should independently verify the validity of the information and now show it to me if it's not true
<desrt> so unless fabio, james, etc all had their keys stolen.....
<desrt> ie: it shouldn't accept that seb's key is signed by someone just because the keyserver says so... it should actually verify the signature for itself
<jamesh> desrt: are you using --list-sig or --check-sig?
<desrt> list-sig
<desrt> i didn't know of the difference, thanks.
<jamesh> desrt: list-sig does not verify signatures
<jamesh> it should show my signature on seb's key as valid (but expired)
<jamesh> I don't know why it has expired
<desrt> k.  here's a neat question
<desrt> when the signature is stored on a signed key, what is stored with it to match it to the signing key
<desrt> the 32bit ID, the full fingerprint?
<jamesh> fingerprint
<desrt> can i get that in the check/list-sig output?
<jamesh> or maybe just the 64 bit key id
<jamesh> use --with-colons
<desrt> ok
<desrt> now i'm very suspicious indeed :)
<desrt> sig:?::17:431A3CEDA2D70910:2004-11-21:::::13x:
<desrt> sig:!::17:431A3CEDA2D7D292:2004-11-21::::Sebastien Bacher <seb128@debian.org>:13x:
<desrt> exactly the same 64bit key id except for the last 2 bytes
<desrt> but, of course... since the signature doesn't contain the public key of the signing party there is no way to look at a signature and say "this is legit"
<desrt> (without also having the key that claimed to create the signature)
<desrt> which means that you are able to attach bogus signatures to people's keys with arbitrary key IDs, trivially
<desrt> so the mysterious 431A3CEDA2D70910 signatures are probably a case of this......  which would also explain why no such key exists on the servers
<SEJeff> desrt: Well what do you do to remove the evil sigs?
<sistpoty> elmo: pleasy sync mpqc from unstable, ubuntu override ok
<sistpoty> elmo: please also sync ipe from unstable, ubuntu override ok, thx
<desrt> SEJeff; i've been thinking about this
<desrt> SEJeff; there seems to be no mechanism to instruct the keyserver "please remove this shit from my key"
<desrt> SEJeff; which is a significant problem.... think about a spammer... they could sign everyone's key and attract huge amounts of attention to themselves
<SEJeff> desrt: So all of the defaced keys have to be removed and regenerated?
<SEJeff> desrt: That will be a headache
<desrt> SEJeff; there is also no method for removing keys
<SEJeff> desrt: You would likely have to contact the keyserver staff. It's possible I'm sure
<desrt> SEJeff; there is no one keyserver.  they constantly sync with each other
<desrt> SEJeff; if you removed it from one it would just pick it up from the others again on the next sync
<tseng> thats why you dont loose your revoke key, kids
<desrt> :)
<desrt> even revoked keys stay on the servers
<tseng> but revoked.
<desrt> once ever have the revoked/expired keys been batch-removed
<Diablo-D3> <SEJeff> Diablo-D3: Thanks, I was out for a bit
<Diablo-D3> <SEJeff> Diablo-D3: Are you hosting that domain on dialup? It's super slow ;-P
<Diablo-D3> SEJeff: nope, its on sf.net
<SEJeff> Diablo-D3: might as well be dialup :)
<Diablo-D3> yeah, I was having problems earlier
<Diablo-D3> afaik its only one server out of many actually doing it
<Diablo-D3> its unusual, thats for sure
<SEJeff> Diablo-D3: I'm just kidding. But that server is being slammed ridiculously hard
<Diablo-D3> no kidding
<Diablo-D3> have you ever seen the sf.net hardware?
<Diablo-D3> even the project webservers are beefy
<Diablo-D3> and they have a ginormous ammount of bandwidth
<SEJeff> Diablo-D3: Does that bootchart go to gdm only, or to the desktop?
<Diablo-D3> SEJeff: um, ?
<Diablo-D3> I have a choice?
<SEJeff> Diablo-D3: I am asking
<Diablo-D3> it only goes to gdm
<Diablo-D3> SEJeff: your question doesnt make sense, I didnt know I could measure desktop component loading too
<SEJeff> Diablo-D3: And what kind of hardware?
<Diablo-D3> sempron 2600+, ungodly fast sata drive, 2 gigs of ram.
<SEJeff> Diablo-D3: I have never used bootchart. I was curious if that measured up to gdm and stopped, or not.
<SEJeff> Diablo-D3: Oh, that bootup sucks then
<Diablo-D3> oh, afaik it only measures up to and including gdm
<Diablo-D3> well, I think its apache and mysql screwing things over
<Diablo-D3> maybe ssh too
<Diablo-D3> I've actually considered using dropbear instead of openssh
<Diablo-D3> openssh is a fatass
<SEJeff> Diablo-D3: I can get 32 seconds to nautilus and a desktop with init-ng on my breezy box
<SEJeff> dropbear is faster?
<Diablo-D3> dropbear is a tiny little ssh server
<SEJeff> Just because it's embedded I would think it is slower
<tseng> its smaller memory footprint
<Diablo-D3> its ungodly small
<Diablo-D3> its something you'd, say, put on a wrt54g router
<Diablo-D3> (which I do)
<SEJeff> I have dropbear on my Linksys with OpenWRT
<tseng> it didnt implement scp until recently for example
<SEJeff> Yes
<Diablo-D3> SEJeff: hah!
<Diablo-D3> openwrt > *
<Diablo-D3> tseng: yeah, and it sucked
<SEJeff> small memory footprint != fast
<Diablo-D3> tseng: I kept trying to sshfs my router, and I didnt understand why it didnt work until I realized it doesnt implement scp
<tseng> i am pretty heavy on the scp/rsync
<Diablo-D3> oh, and fuse > *
<Diablo-D3> and dropbear's scp implementation still doesntsupport sshfs
<Diablo-D3> or rather, it doesnt support the things sshfs uses
<SEJeff> tseng: I love scp. and sftp also
<SEJeff> mget *
<Diablo-D3> anyhow
<Diablo-D3> SEJeff: I dunno if thats slow or not
<Diablo-D3> 45 seconds imo is fast
<SEJeff> Diablo-D3: Did you read my above post?
<Diablo-D3> which one?
<SEJeff> SEJeff Diablo-D3: I can get 32 seconds to nautilus and a desktop with init-ng on my breezy box
<Diablo-D3> oh that
<Diablo-D3> yeah I read that
<SEJeff> Thats the box I have my parents using
<Diablo-D3> but I still dont think 45 seconds is slow
<Diablo-D3> I'm loading apache2, mysql, openssh, distcc, and default installs dont
<SEJeff> I was thinking it would be ~30 seconds or so
<SEJeff> True
<SEJeff> In a week or so (when I reboot dapper) I will put it back to a default state and make a bootchart
<Diablo-D3> I've been considering bootcharting a ubuntu livecd
<Diablo-D3> but that might not work as planned
<Diablo-D3> well, actually, it might
<Diablo-D3> I can still load the whole image into ram, right?
<Diablo-D3> I just need to make a livecd that has bootchart.
<SEJeff> Diablo-D3: Yep
<SEJeff> And make an option in the bootloader
<SEJeff> Like bootchart
<Diablo-D3> hehe
<Diablo-D3> Im surprised no one hasnt already done that
<SEJeff> Diablo-D3: Seriously. That would be great to test out different systems
<Diablo-D3> well, Im making no promises...
<SEJeff> But you would have to modify bootchart
<tseng> a livecd is significantly different enough to be pretty irrelevant
<Diablo-D3> but if it doesnt seem like too much of a pita, I'll consideri yt
<SEJeff> As I don't think /boot is in a tmpfs
<Diablo-D3> *it
<Diablo-D3> tseng: oh =/
<tseng> the IO is an entirely different story
<Diablo-D3> nm then
<tseng> it would be good to profile the livecd on different hardware
<tseng> but not with the goal of optimizing iowait times on the desktop
<SEJeff> And have a little wizard to email the bootchart back to ubuntu.org
<Diablo-D3> tseng: hrm
<tseng> oh
<SEJeff> And maybe some hardware data
<tseng> ogra: add bootchart support to your hwdb :P
<SEJeff> Exactly
<Diablo-D3> I wanna make a feature request for this on launchpad
<SEJeff> That would be a great idea actually
<Diablo-D3> just to make sure this idea isnt lost
* Diablo-D3 wonders what livecd is under
<Diablo-D3> argh
<Diablo-D3> I hate launchpad sometimes
<Diablo-D3> SEJeff, tseng: help me find ubuntu livecd on launchpad
<Diablo-D3> actually, maybe I'll just put it on my blog
<SEJeff> I'm not finding a live-cd component
<Diablo-D3> yeah neither am I
<SEJeff> Just the install scripts
<SEJeff> the casper stuff too
<Diablo-D3> I'll put it on my blog
<Diablo-D3> and I'll post the url to the ubuntu-devel ml
<SEJeff> Will you put a link in here also?
<Diablo-D3> yeah of course
<Diablo-D3> give me a second to write this up
<SEJeff> ok
<Diablo-D3> whats the url for the hwdb?
<tseng> http://hwdb.ubuntu.com/ creatively enough
<Diablo-D3> hah
<Diablo-D3> lol
<Diablo-D3> in random googling, I've found this
<Diablo-D3> SEJeff and tseng have both played professional football. (rotfl)
<SEJeff> http://video.google.com/videoplay?docid=-1021256519470427962&q=wep
* tseng misses the joke
<SEJeff> Use kismet instead of kismac though :)
<Diablo-D3> kismet is pretty fun
<SEJeff> Diablo-D3: http://www.digitalprognosis.com (hasn't been updated in a year and 1/2) and google for "jeff.schroeder2@us.army.mil"
<Diablo-D3> I was using kismet on my laptop, and kismet drone on my wrt54g
<SEJeff> You can find all kinds of my posts on LUG mailinglists
<SEJeff> Yes
<Diablo-D3> and you know what I found?
<Diablo-D3> I'm the only ap in listening distance =(
<Diablo-D3> wow
<Diablo-D3> cracking wep is that easy?
<tseng> in ideal circumstance
<tseng> s
<Diablo-D3> jesus!
<Diablo-D3> that makes wep totally useless
<Diablo-D3> thank god I use wpa2
<SEJeff> Diablo-D3: With my little sharp laptop, a copy of WHAX, and a few minutes driving around. I will always get net access
<SEJeff> Whax also has the exploit code database from packetstorm AND metasploit framework
<Diablo-D3> I'm waiting for openwrt to support multiple wifi vlans, btw
<Diablo-D3> so I can simutaniously use wpa2 and no encryption
<Diablo-D3> so I can use wpa2 for my clients, and open my ap for everyone else
<mojo> which pcmcia that kernel 2.6.15 use? Is that pcmcia-cs or pcmciautils?
<mojo> i am trying to solve some kernel panic here
<Diablo-D3> mojo: pcmciautils, but watch out, it may lock the kernel up
<Diablo-D3> I had to --purge both to bootwith 2.6.15
<mojo> Diablo-D3: you're rite, it DID lock up my PC
<Diablo-D3> yeah, you're the fourth person in here so far to experience it
<Diablo-D3> what I dont get is.... I dont even own pcmcia hardware.
<Diablo-D3> atleast, not on my workstation
<mojo> Diablo-D3: yup, I tried to purge both to boot with the kernel, locking up still happens, maybe I go the other way around, turn off the pcmcia service then
<Diablo-D3> SEJeff: http://shadowconflict.blogspot.com/2005/12/bootchart-on-ubuntu-livecds.html
<mojo> Diablo-D3: i am owning only Desktop,however the kernel still boot up with pcmcia service
<Diablo-D3> mojo: it doesnt if you purge both pcmcia-cs and pcmciautils afail
<Diablo-D3> *afaik
<Diablo-D3> tseng, url --^
<mojo> Diablo-D3: 2.6.15-6 solve this lock up, i only encountered this with 2.6.16-5
<Diablo-D3> hrm, let me check what Im using
<mojo> uname -r
<Diablo-D3> 2.6.15-5.7
<Diablo-D3> yeah, mojo ;)
<mojo> 5.7 hrm
<mojo> what an odd number ;)
<mojo> then I think i am rite
<Diablo-D3> its easier to apt-cache show linux-image-2.6.15-5-foo
<mojo> the bug is fixed during 5 and 6
<mojo> thx anyway, bak to hacking
<mojo> btw, the url u pasted has very nice layout, looks like Eclipse layout
<Diablo-D3> wtf, bwm on openwrt has to be wrong
<Diablo-D3>        Total          287.1000      291.391         579.391
<Diablo-D3> thats KB/sec
<Diablo-D3> I can only download at 90k/sec
<Diablo-D3> and thats download, upload, and total, in that order.
<Diablo-D3> oh I get it
<Diablo-D3> ubuntu dapper magically made my connection faster *g*
<sistpoty> elmo: please sync libccrtp from unstable, ubuntu override ok
<Diablo-D3> new initramfs-tools
<Diablo-D3> mojo: that could have been what did it
<mojo> for whom who love a bit art on desktop, we are developers but not nerds rite? http://orion.thos.me.uk/~joneslee85/Tango-0.5.1.tar.bz2   <--- GNOME Tango Theme (latest)
<Diablo-D3> Im not sure I want to look.
<Diablo-D3> screenshot plzkthx
<mojo> hold on sec
<mojo> http://opax.swin.edu.au/~4089294/Tango.png
<Diablo-D3> my eyes!
<Diablo-D3> actually.
<Diablo-D3> except for the background
<Diablo-D3> thats not so bad
<xkahn> mojo: it looks like the icon theme is really coming together.
<jbailey> Tell me those colours are picked for high contrast on a black and white screen or something.
<xkahn> mojo: I still don't like the small folders.
<mojo> aw
<Diablo-D3> hrm
<Diablo-D3> I dunno
<mojo> i am not artists who designed it
<mojo> i am just a mere developer
<Diablo-D3> I like kde's crystal
<mojo> who package it
<xkahn> mojo: I've talked with the artists.
<xkahn> :)
<xkahn> I was outside the first design meeting.
<Diablo-D3> why dont we use crystal?
<mojo> oh well, it's up to us to decide whether to move on to this theme rather than Humility
<mojo> you guys can check this exciting post
<mojo> http://www.ubuntuforums.org/showthread.php?t=88477
<xkahn> But I really like the overall style.
<Diablo-D3> better yet
<Diablo-D3> why doesnt someone make a Free icon set that is universal
<Diablo-D3> that works with everything
<xkahn> Diablo-D3: that's what tango is.
<Diablo-D3> xkahn: can I use it with kde?
<xkahn> Diablo-D3: yes.
<mojo> for now, i am going to bed, damm freaking tired hacking all day long
<Diablo-D3> my prayers have been answered
<Diablo-D3> now all I want is matching plastiky/openlooky gtk and qt themes
<xkahn> Diablo-D3: http://tango-project.org/Tango_Desktop_Project
<SEJeff> The clearlooks in dapper is nice
<SEJeff> I really like it
<Diablo-D3> SEJeff: ...
<xkahn> Diablo-D3: it's based on the Firefox icon style.
<Diablo-D3> xkahn: eh, I guess its okay
<xkahn> Diablo-D3: and the artist who did that is helping.
<Diablo-D3> I wanna see finished product before I pass judgement
* xkahn shrugs
<Diablo-D3> because I cant say they're ugly icons
<xkahn> I'm not involved anymore.
<SEJeff> Diablo-D3: Sorry for being the odd bird. I personally know the guy who worked on the original Human theme (Nathan Mcallum) and told him it sucked
<Diablo-D3> SEJeff: well, you suck then
<Diablo-D3> actually, I cant say human is that good either
<Diablo-D3> I prefer the default openlooks theme
<SEJeff> Diablo-D3: I use bluecurve icons on Ubuntu with clearlooks gtk and metacity
<xkahn> And even then I was only NEAR them when work started.
<xkahn> And mostly complained about it.
<xkahn> :)
<Diablo-D3> I use the qt-gtk theme
<Diablo-D3> so I get plastik in gtk =P
<SEJeff> to each his own
<Diablo-D3> slow as fuck but hey
* Amaranth hangs out with the clearlooks author, so he is biased toward clearlooks
<xkahn> and historically buggy.
<Amaranth> but clearlooks cairo (real stuff, not human) looks awesome
<SEJeff> Amaranth: Yes, thats what I was talking about. The scrollbars are just "pretty"
<Amaranth> and afaik there isn't a single prerendered image in it
<Amaranth> http://www.stellingwerff.com/progress_ltr.gif is the part i like
<Amaranth> someone wrote a patch to do it, but i dunno if it's in gnome cvs or dapper yet
<SEJeff> Amaranth: Why don't they make a brown version and call it "human 2"
<mojo> yuk, can't sleep, bak to IRC
<SEJeff> ANd you can toggle progress bar animation in your .gtkrc I believe
<Diablo-D3> mojo: lol
<mojo> SEJeff: feel free to hack it to brown, it's pretty easy
<Amaranth> SEJeff: eventually, you'll be able to
<SEJeff> I'm just curious why it isn't the default
<SEJeff> Usability wise, I think clearlooks gives the best user feedback
<mojo> SEJeff: it's not the default b/c it reminds me of the color of chocolate, I dun want to get overweighted since I sit next to my PC 24/7
<mojo> ;)
<Diablo-D3> lol
<Diablo-D3> it reminds me of chocolate, and since I'm allergic to chocolate, I'm going to switch to suse!
<Diablo-D3> no, gentoo! yeah! I'm the world's next ricer! yar!
<mojo> lol
<SEJeff> Well I like blue over brown... but since Mark is determined that Brown will be Warty --> Dapper, it will be brown
<Diablo-D3> Im going to go recompile my entire OS just so I can get 1% improvement, but 50% more instability for free!
<mojo> i am working on fixes rotation order in gnome-panel, it's pain in the ass, y GNOME developers has a such bad design for GNOME Panel, if they did better, we can have a transparent, right rotated ordered panel like KDE
<Amaranth> ack, jdong just pointed out a problem with backports
<Amaranth> vlc in breezy-backports works but the version in dapper has changed and won't build anymore
<Amaranth> so what happens if there is a security issue with the vlc in backports?
<Diablo-D3> Amaranth: ouch
<SEJeff> mojo: I talked to davyd madely about the transparency issue and he isn't really sure why it does that
<Diablo-D3> Amaranth: you'd think a new one would be backported
<Diablo-D3> and bleh linux-restricted-modules-common is still whacked
<Amaranth> Diablo-D3: can't be, dapper version doesn't build against breezy anymore
<Diablo-D3> Amaranth: er.
<Diablo-D3> Amaranth: ... oh my.
<mojo> SEJeff: and the transparency issue is very pain staking, I've been hacking on it for 2 weeks, still doesn't get it work properly, b/c GDK and Cairo based theme behave pretty differently, >,<
<SEJeff> mojo: yes, see my bug on that: http://bugzilla.ubuntu.com/show_bug.cgi?id=20022
<mojo> SEJeff: nasty bug heh? I am also thinking giving patch to Main Menu bar, making it transparent aswell, but I haven't imagined how do you set Properties for it, right click on Menu Bar? Or make it follow the Settings applied to the panel it's placed on
<SEJeff> mojo: Inherit the panel settings. Anything else would be very anti-HIG
<FireRabbit> are the images used on the official ubuntu cds avaliable somewhere?
<mojo> SEJeff: that's the hard bit, making it inherits the parent panel, anyway I am trying to working that out
<mojo> FireRabbit: ask ubuntu-art
<mojo> FireRabbit: ask at #ubuntu-art
<FireRabbit> uhhh...okay..
<mojo> FireRabbit: sorri, it's #ubuntu-artwork
<FireRabbit> oh
<SEJeff> mojo: It really bugs me that the panel won't respect transparency properly
<FireRabbit> i was going to say..
<SEJeff> mojo: good luck fixing that one.
<mojo> SEJeff: it's the design that count, bad design is annyoying
<SEJeff> And that is why superheros like federico, behad, and mattias have to optimize gnome
<SEJeff> It is slow
<mojo> SEJeff: that's bad, GNOME should aim for quality 1st, or else GNOME will lag behind KDE
<mojo> SEJeff: can you also post up to Bugzilla for me this bug:
<mojo> SEJeff: when u set your panel vertically, the Window List doesn't rotate along
<SEJeff> mojo: I will open a bug. BUt it will be a few minutes
<mojo> SEJeff: thx in adv
<mojo> SEJeff: btw, can you send me the BlueCurve theme package that you used in the screenshot? I am so lazy to install Fedora just to get that theme
<SEJeff> mojo: How about this
<SEJeff> mojo: I wrote a script to download it from the fedora site, alien it to deb, install it, and use gconftool-2 to set it as default
<infinity> Diablo-D3 : Oops.  lrm-common fix uploaded.
<SEJeff> mojo: I haven't had time to finish the script 100%, but you can cherrypick that part if you are interested
<mojo> SEJeff: it'd be nice
<mojo> SEJeff: okay, I will help u revise the script
<SEJeff> mojo: www.digitalprognosis.com/opensource/setup.sh
<SEJeff> mojo: I've honestly just been to busy to finish it. I'm sure that will give you an idea of what to do though
<SEJeff> And if anyone else wants to comment about it feel free
<SEJeff> mojo: make SURE to not run the sed commands on your init scripts
<mojo> SEJeff: cool, i got it, playing around with it now
<SEJeff> mojo: It's a mess ATM, but I haven't seen a script as complete yet
<SEJeff> So I wrote one
<SEJeff> mojo: I'm going to fix some things in that script right now and re-ul a new copy in a few minutes
<mojo> SEJeff: url?
<mojo> SEJeff: I go out get pizza
<SEJeff> mojo, Same as before. I'll update it in a bit
<aedes> are most ubuntu packages modified from the debian ones?
<Amaranth> the desktop ones, yeah
<aedes> I'm wondering about cupsaddsmb, specifically
<Amaranth> !info cupsaddsmb
<aedes> !info cupsaddsmb
<infinity> That would work a lot better if this wasn't #ubuntu-devel.
<aedes> Amaranth, if that's for a bot in here, I'm not getting anything
<aedes> infinity, where would it work better?
<Amaranth> err, i forgot, that's only in #ubuntu :P
<infinity> (Which is where this conversation should be)
<aedes> infinity, I'm unclear as to exactly what is considered development
<infinity> aedes : Working on development is development.  Asking how development works isn't.
<infinity> If you're asking for curiosity's sake, ask in #ubuntu, if you're asking cause you want to get involved, #ubuntu-motu
<ptlo> if you're asking if you should install dapper, don't :)
<infinity> (And no, I'm not just picking on you, I just happened to glance at my screen at the wrong/right time)
<aedes> actually, I was ultimately looking for the modified sources, to debug a problem I'm having
<infinity> The sources are in the archive, next to the binaries.
<aedes> I can probably get that frrom the devel resources, I suppose
<aedes> ok, thanks
<infinity> "apt-get source foo"
<infinity> Definitely not a -devel question.
<Diablo-D3> <mojo> SEJeff: I go out get pizza
<Diablo-D3> mojo: get an ansi standard pizza!
<calc> anyone use dual head dvi?
<calc> i'm trying to find a good dual head dvi agp card that isn't too expensive
<infinity> What resolution on each head?
<calc> 1920x1200
<infinity> Ouch.  Then you need dual DVI-D.
<calc> so within single link specs if the card fully supports it (ie nvidia 5xxx doesn't aiui)
<infinity> Which is going to be  abit pricier.
<infinity> a bit, too.
<calc> 1920x1200 is at the limit of single link
<Diablo-D3> which islame
<calc> some older nvidia cards only do 135MHz which isn't enough for 1920x1200 the spec itself is 165MHz which is fine for 1920x1200
<infinity> Are you positive on that?... I usually see the limit qutoed at 1280x1024
<calc> i'm also trying to find a card that is fanless which seems to be harder
<calc> infinity: yea
<calc> most cards say either 1280x1024, 1600x1200, or 1920x1200
<Diablo-D3> yeah, you can do 1600x1200 on a single link fine
<infinity> Well, fiif you find a card maching those specs that isn't DVI-D, let me know.  I'm curious.
<calc> the only lcd that needs dual link aiui is apple 30"
<Diablo-D3> calc: heh
<calc> though some of the 9MP displays might use multiple dual link ports
<Diablo-D3> theres more than one >1920x1200 lcd now
<Diablo-D3> but Im betting it uses the same panel apple's gigantor
<calc> infinity: DVI-D confusingly enough doesn't mean dual link ;)
<Diablo-D3> dvi-d == digital
<calc> DVI-D is DVI Digital (only)
<Diablo-D3> ie, what dvi is supposted to be
<calc> as opposed to DVI-I which is what i use on my 21" crt
<calc> DVI-I ports do digital and analog
<calc> my 21" crt being analog of course
<Diablo-D3> lol
<infinity> Err, then "DVI-dual", then. :)
<Diablo-D3> infinity: "dual link"
<calc> Diablo-D3: there are other 30" high res displays now?
<Diablo-D3> I think dvi is retarded for dong that, btw
<Diablo-D3> calc: yeah
* infinity notes that he has exactly 0 digital displays, not counting the laptop.
<calc> Diablo-D3: there have been better than apple lcds for a long time but not the same res as them until recently i guess
<Diablo-D3> calc: I forget who, though, someone pointed it on on irc somewhere a few days back
<Diablo-D3> I think it was a samsung
<calc> several companies have had 3840x2400 displays for years
<Diablo-D3> those 3840x2400 displays suck
<Diablo-D3> they tile lcd panels to do it
<Diablo-D3> and you get that horrible seam because of it
<calc> oh?
<calc> thats odd
<Diablo-D3> you dont notice it when you're across the room though ;)
<calc> so they get tiny high res panels to do it
<calc> ?
<Diablo-D3> basically
<calc> iirc most of the 3840x2400 lcds were ~ 21"
<Diablo-D3> not theones I saw
<Diablo-D3> they were like 40+ inches
<calc> hmm maybe the 21" ones i saw were real single pane lcds
<Diablo-D3> maybe
<calc> iirc viewsonic and ibm made them among other companies
<calc> the biggest samsung has on their site is 32" and is low res
<calc> 1280x768, basically just a hdtv
<HrdwrBoB> best is 24"
<HrdwrBoB> 24" 1920x1200
<HrdwrBoB> samsung panel
<Diablo-D3> no
<Diablo-D3> best is apple's 30"
<calc> HrdwrBoB: yea, Diablo-D3 thought samsung was a company that had a competing lcd to apples 30"
<Diablo-D3> I think it was samsung, calc 
<calc> i have two 23" 1920x1200 on order
<HrdwrBoB> erm, apples LCDs are samsung
<Diablo-D3> HrdwrBoB: nope.
<HrdwrBoB> IIRC
<calc> Diablo-D3: perhaps its not available yet and was at a tradeshow
<Diablo-D3> apple buys panels from quite a few companies
<Diablo-D3> calc: maybe, I wasnt quite with it that day =/
<calc> whoever actually produces them for apple doesn't seem to be selling them for themselves  yet
<dholbach> good morning ubunteros
<Diablo-D3> its funny
<Diablo-D3> apple gets first crack at buying panels
<Diablo-D3> from any company
<calc> wow apple lcd is down to ~ $2350 USD
<Diablo-D3> everyone else gets the panels apple rejected
<infinity> That's because Apple will pay more wholesale than they could get retail for the same panel.
<Diablo-D3> yup.
<infinity> Because Apple can resell it with a big "it has an Apple logo on it, suckers!" pricetag.
<Diablo-D3> infinity: well, yeah
<Diablo-D3> but samsung makes the best panels in the world
<Diablo-D3> there are samsung models I'll buy before apple ones.
<calc> put a better backlight in and take all the features off the monitor and put apple logo on it, instant profit
<calc> the ones i got are HP L2335
<calc> has dvi/vga/component video/svideo/pip/etc
<Diablo-D3> yeah, all I need is dvi
<calc> i can hook up a cable box to it and watch tv on one and work on the other :)
<Diablo-D3> who'd want to? =/
<calc> s/tv/pron/ maybe? ;)
<Diablo-D3> all my pron is dvd rips.
<calc> i have a tv card in my box that afaict still doesn't work under linux :\
<calc> it'll teach me not to buy hardware without finished support
<calc> :\
<Diablo-D3> roffle
<Diablo-D3> I gave up on cable tv
<Diablo-D3> I mean, right now I'm downloading about 35098325083 hours of anime
<Diablo-D3> 58 hours.
<HrdwrBoB> the amount of anime you watch is inversely proportional to how capable you are of integrating into society
<calc> HrdwrBoB: is that a bad thing?
<Diablo-D3> HrdwrBoB: I watch very little anime.
<calc> most of society sucks
<Diablo-D3> calc has a point
<HrdwrBoB> calc: I'm just making sure people are aware
<calc> heh
<calc> HrdwrBoB: does that rule hold up if the anime in question is hentai?
<Diablo-D3> I'd actually like to live in some of these alternate tokyos
<HrdwrBoB> calc: hentai is double
<calc> hmm looks like my tv card might work if i add a card entry for it to the drive
<calc> driver
<calc> HrdwrBoB: heh
<Diablo-D3> who here has seen read or die tv?
<HrdwrBoB> I'd also like to point out that japan has one of the highest rates of depression and suicide, despite having the most disposable income
<HrdwrBoB> .. but this is INCREDIBLY offtopic
<fabbione> morning
<HrdwrBoB> so we should all STFU right now. please.
<Diablo-D3> http://www.newegg.com/Product/Product.asp?Item=N82E16824001211
<Diablo-D3> yum
<fabbione> who is a bit familiar with printers?
<dholbach> fabbione: pitti?
<fabbione> hmm i think i figured :)
<fabbione> mdz: ping?
<fabbione> hey pitti
<fabbione> dholbach: you talk about the evil :)
<pitti> Good morning
<dholbach> haha :)
<Diablo-D3> fabbione: I am a little.
<fabbione> pitti: i have a foomatic-* question for you :)
<Diablo-D3> erk, foomatic scary
<pitti> fabbione: uh, ENOCLUE, but what's it?
<fabbione> pitti: #17218 and #17693 they are basically asking to include the only 2 foomatic external drivers in the archive (universe) into main
<fabbione> pitti: printing stuff
<pitti> yes, THAT much I know :)
<Diablo-D3> lol
<fabbione> pitti: what do you suggest? add a Depends: in foomatic-db or just seed them?
<fabbione> pitti: well never be sure :P
<fabbione> in both cases i guess they will need a main inclusion report
<pitti> fabbione: I'd rather seed them, then folks can at least unintstall them
<pitti> fabbione: yes, but PPD files are a no-brainer
<fabbione> pitti: yeah they are not even that big.. 1MB or so
<Diablo-D3> zomg 1 meg?!
<fabbione> (both of them)
<pitti> fabbione: uh, that's pretty big for a PPD file...
<pitti> but having them in main at least can't hurt
<fabbione> there is more in foo2
<Diablo-D3> no kidding
<Diablo-D3> thank god I dont want zipubuntu.
<doko> good morning
<mdz> fabbione: yes?
<fabbione> pitti: the foo2.. has quite a bunch of PPD
<fabbione> mdz: thanks. i was going to ask the same question as pitti
<fabbione> mdz: my printing knowledge is like UBZ..
<fabbione> below zero
<Diablo-D3> lol
<pitti> fabbione: we should also switch to gutenprint, btw
<fabbione> pitti: -ENOIDEAWHATYOUARETALKINGABOUT
<Diablo-D3> -EWTF
<fabbione> pitti: i am dead serious.. i don't understand printing at all :)
<pitti> fabbione: it's the successor to gimpprint
<fabbione> pitti: ok.. does that effect these 2 pkgs?
<pitti> just more drivers, etc.
<pitti> fabbione: if these 2 packages are just PPDs, then not; if there are binaries, maybe, but I don't know that much either
<pitti> at least I have to look at the packages first 
<fabbione> only one has a bunch of binaries
* fabbione goes and discovers the new world of seeds
<zakame> er is libatlas-cpp-0.5 dropped? eris b-ds on it...
<mdz> where is initramfs-tools mainline these days?
<mdz> (bzr)
<mdz> infinity: ^^
<infinity> mdz : I don't have a bzr branch (or new mainline) as yet, so the "old" mainline of Jeff's is still authoritative (though out of date)... If Scott's been doing his changes in a bzr branch, his stuff should be pushed and made the new maqinline for me to merge back into.
<infinity> mdz : So, short answer right now, without input from Scott, is that the archive is authoritative.
<mdz> the archive is definitely out of date and I don't see any branches in ~scott
<infinity> I meant "the archive", as in "archive.ubuntu.com"
<mdz> oh, that
<infinity> I'll branch Jeff's archive, merge Scott's stuff, and publish to chinstrap shortlyish.
<fabbione> pitti: ok.. i got the seed changes.. now.. main inclusion reports
<mdz> infinity: I'm going to upload a trivial change nowish
<infinity> Worksish for meish.
<infinity> Now that we're mostly caught up on merges, would this be a good time for me to book off a day or two for nothing but hunting FTBFS bugs and filing reports?
<fabbione> pitti: https://wiki.ubuntu.com/UbuntuMainInclusionQueue is this page still the canonical queue?
<stephans> who do I talk to regarding active directory and exchange oss replacements for ubuntu
<pitti> fabbione: yes, it is
<fabbione> pitti: if so ocfs2-tools: MainInclusionReportOcfs2Tools [defered]  it's in main already
<pitti> fabbione: I also created a page template for them which should make it easier to create a report
<fabbione> pitti: you rock :)
<pitti> fabbione: oh, then sb forgot to move it to accepted
<slomo> pitti: ah, while we're at main inclusions... did you already take a look at xsp? would be nice to get it into main asap... and do you think we can get avahi into main for dapper? :)
<pitti> slomo: I wanted to catch up a little with the reports today
<pitti> meh avahi - that's going to be a hell of a review
<mdz> stephans: ubuntu-devel@lists.ubuntu.com
<slomo> pitti: fine :) when you have some question on both feel free to ask me
<mdz> stephans: assuming you want to tell us about existing software, rather than suggesting that we write it
<fabbione> ARGH
<fabbione> mozilla crashing while you are editing a maininclusion report? .. priceless
<pitti> fabbione: too bad we never wrote a report for firefox itself
<stephans> mdz: well... ahem... i am not a developer... but I am willing to test.... who should write this?
<Lathiat> pitti: heh
<stephans> mdz: i mean.. I have several smaller clients that I am trying to evangelize linux to
<dholbach> pitti: what would have ended up with? dillo?
<stephans> their requirements are 1: something like exchange and active directory...
<stephans> but ... he... fedore directory would fit the bill 
<stephans> Fedora.. sorry
<stephans> but that would require using Fedore
<mdz> stephans: we can't write all of the free software that anyone would like; what we do is integrate software which is available as open source into a distribution
<mdz> stephans: if fedora has a directory server which meets our licensing guidelines, then I'd be interested in hearing about it
<stephans> can you integrate Fedora Directory Server?
<stephans> it is GPL
<dholbach> stephans: you could add it to http://wiki.ubuntu.com/UniverseCandidates
<stephans> by redHat
<stephans> ok  i will
<stephans> one more question...
<stephans> is ubuntu comitted to delivering on the server side as well as on the desktop?
<infinity> It was just released under a useable license, afaik.
<stephans> I know that ubuntu et al. is mainly known for desktop
<stephans> infinity: what was?
<dholbach> stephans: dapper will be supported for 5 years on the server (!)
<dholbach> :)
<infinity> RHDS (rebraded as FDS)
<stephans> great!
<stephans> should i try to alien it?
<infinity> I doubt that would go well..
<stephans> and try to run it?
<stephans> ok
<infinity> But you can always try.
<stephans> hey, infinity, are you going to try?
<stephans> to port FDS that is?
<stephans> Do you think that it would be a lot of work?
<infinity> It will be a chunk of work.
<infinity> You realise that RHDS/FDS isn't an Active Directory replacement, but rather something that works kinda like it, but not quite, right?
<infinity> ie: If you want Win2K/WinXP Active Directory clients on your network, you still need an AD machine that your RHDS/FDS system syncs with.
<fabbione> pitti: i did queue the 2 reports for review. Of course i left the security stuff to you
<pitti> yes, that's fine, thanks
<fabbione> otherwise they look no-brainer
<stephans> infinity, but you can use it to authenticate linux boxes via ldap. 
<stephans> fedora has this utility that can set up you machine to authenticate to ldap hsiod active directory etc.
<mdz> that is not the same thing as having a directory server.  that's a directory client, in fact.
<stephans> mdz, yes... the client needs a server to authenticat to though, and I would rather not use windows 2003 to authenticate my linux machines
<stephans> enter FDS!
<stephans> now if that could run on ubuntu, adn ubuntu had a tool to set up the authentication with ... wooo hooo!
<stephans> now window and no redhat
<mdz> the client side, configuring network authentication, is planned for Ubuntu 6.04
<stephans> windows sorry!
<stephans> that is dapper?
<mdz> correct
<stephans> ok
<stephans> great... now we have the possibility to authenticate ubuntu desktops to an ubuntu server in a modern way!
<stephans> I will go hunting for a groupware server that can talk evolution... 
<pitti> ogra: hrm, gobby in main??? this piece of cr^Wwork needing software?
<pitti> Mithrandir: ping
<pitti> Mithrandir: why is the bootchart udeb empty?
<pitti> Burgwork: ping?
<pitti> Burgwork: oh, nevermind
* desrt plays around with sebastien's key a bit more
<desrt> all of the expired signatures are not exported... i suppose this probably makes sense... but i can also no longer download them, either
<pitti> Hi desrt 
<desrt> hello martin
<desrt> something very bad is happening with pgp today and i am trying to figure out what it is :)
<Mithrandir> pitti: it shouldn't be.
<pitti> -rw-rw-r--  1 archvsync archvsync   1794 Nov 30 16:15 bootchart-udeb_0.9-0ubuntu4_all.udeb
<Mithrandir> pitti: 1798 here, but that's approximately correct, yes.
<pitti> Mithrandir: well, there's just a startup script and a casper/post.d
<Mithrandir> pitti: that's correct.
<pitti> Mithrandir: where's the actual binary?
<Mithrandir> pitti: binary? :-)
<pitti> Mithrandir: oh, does it depend on the bootchart.deb?
<Mithrandir> pitti: if you want to render something, yes.
<Mithrandir> it just does data gathering.
<pitti> ah, ok
<Mithrandir> so even though it looks tiny, it's ok.
<pitti> great :)
<pitti> Mithrandir: it's approved now, but it needs to be germinated
<Mithrandir> pitti: ok, thanks.  I
<Mithrandir> 'll ask Kamion when he's around
<pitti> Mithrandir: oh, you can seed it yourself
<pitti> bootchart should probably be seeded, not sure about the udeb
<Mithrandir> I need to check out how big a hit on the live cd it'll be, and it should possibly be in the installer seed?
<Mithrandir> the first for bootchart itself, the latter for -udeb.
<pitti> fabbione: I merge the seeds now, so that your printer packages go to {k,edu,server}buntu as well
<fabbione> pitti: ah right.. cool thanks
<fabbione> reboot timew
<fabbione> bbl
<fabbione> (hopefully
<pitti> wb fabbione 
<pitti> fabbione: hmmmm
<pitti> fabbione: foo2zjs contains some firmware crap
<fabbione> wow
<fabbione> impressive
<fabbione> everything did work at the first shot!
<pitti> fabbione: are you sure that we can redistribute it in main?
<fabbione> pitti: well it's in Debian main and it has been for a few months.. 
<pitti> hm, ok
<fabbione> given -legal paranoid i assume yes
<pitti> these binary blobs (*.crd) make the package big...
<fabbione> yes i know
<fabbione> it's still around 900K
<fabbione> that's not too big
<pitti> fabbione: min2xxw surprises me, there are not even PPD files in it; I wonder about the magic it does to register in the print system :)
<fabbione> pitti: uh?
<fabbione> right..
<fabbione> probably the ppd are already part of foomatic
<fabbione> but it needs the binaries to work
<pitti> yes, probably
<pitti> Moin mvo
<mvo> hi pitti 
<jdub> whiprush: ping?
<\sh> anyone working on a package for fedora directory server?
<slomo_> \sh: afaik no... someone already asked 2 hours ago if there's a ubuntu package he could use
<doko> mvo: can you reproduce the aptitude/libsigc++ stuff that mdz reported?
<slomo_> elmo: please sync haskell-devscripts from debian/unstable... ubuntu changes can be dropped
<mvo> doko: no, but I have the latest apt/aptitude/etc already here. can you reproduce it?
<ondrej> hi all, what does it take to promote package from universe to main?
<doko> mvo: no
<ondrej> I work for ccTLD and it would help a lot to have nsd (alternative authoritative DNS server) in main for Dapper Drake
<fabbione> ondrej: there are several steps that needs to be done
<fabbione> you need to start searching for a consensum first to see that you are not the only user for it
<fabbione> after that you prepare a MainInclusion report on the wiki
<fabbione> (assuming there is a consensum)
<fabbione> and queue it
<fabbione> if all the steps proceed properly it will eventually enter main
<ondrej> fabbione: thanks, UbuntuMainInclusionQueue in wiki was exactly what I needed to see :-)
<fabbione> ondrej: yes, but you need a consensum first
<fabbione> from ubuntu-devel mailing list
<ondrej> fabbione: yep, I understand, it's written on that wiki page as well...
<ondrej> btw, I am also debian maintainer of that package :-)
<fabbione> ondrej: yes :)
<fabbione> but for example
<fabbione> including another DNS solution in main clashes with another spec to remove pkgs that provide duplication
<fabbione> that's why it's important to seek consensum :)
* Mithrandir waves to ondrej
* ondrej waves back
<ondrej> ok, that could be a problem, since bind9 and nsd will clash and nsd doesn't provide caching dns server...  I'll write email to u-d will rationale and will see
<ondrej> mithrandir: btw, did you sign my key already or still not?
<Mithrandir> ondrej: I've forgotten to.
<Mithrandir> sorry
<ondrej> no prob
<Mithrandir> hi daniel
<dholbach_> me? :)
<Mithrandir> yeah
<Mithrandir> good morning, and such
<dholbach_> i was here like 4h ago :)
<dholbach_> morning tollef :)
<Mithrandir> not your IRC client.
<Mithrandir> :-P
<dholbach_> ME! :)
<Mithrandir> or, I just saw you when you rejoined
<dholbach_> yeah... the connection dropped! YAY! :)
<Mithrandir> heh
* dholbach_ hugs Mithrandir 
<dholbach_> how are you?
<Mithrandir> trying to find a silly segfault in kbd-chooser, but otherwise good
<dholbach_> hm :/
<dholbach_> i'll get back to bug triage! fun! :)
<Mithrandir> I hate works-by-accident code.
<Kamion> Mithrandir: let's put it in the casper seed, not the installer seed
<Kamion> Diablo-D3: Mithrandir has been doing that live CD bootchart stuff over the last few days already
<Kamion> Diablo-D3: if you haven't already, could you please install the 2.6.15-6 kernel, reinstall pcmciautils, and confirm/deny that the lockup is gone?
<ogra> pitti, whats wrong with gobby in main ? 
<Kamion> Diablo-D3: if it isn't gone, please *report a bug* rather than using several hundred lines of my #ubuntu-devel scrollback on it, kthxbye :-)
<Mithrandir> Kamion: sure, either works.
<ogra> i warned you beforehand that we decided to have it in edubuntu :)
<pitti> ogra: oh, gobby itself :) it's hideously broken...
<Kamion> Diablo-D3: because pcmciautils is going to stay in minimal - the packaging/upgrade issues are too difficult to deal with otherwise - so we need to make sure any lockups such as this are fixed
<ogra> pitti, nah ... 
<ogra> pitti, there would be bugreports about that ;)
<pitti> ogra: did you never saw gobbies divert from each other without notice and without chance of merging?
<pitti> or the crappy editor?
<ogra> pitti, nope
<ajmitch> pitti: gobby is a wonderful app ;)
<pitti> ogra: then you didn't actually use it :) (just joking)
<ogra> it worked fine for me, except the times where someone ran zeroconf in the network
<ogra> ;)
<ajmitch> it just needs a few 'features' smoothed over
<ogra> 0.3.0 will have this ...
<ogra> and since debian isnt fast enough in the transition, we'll get it first ... (according to pkern ;) )
<ogra> he'll prepare source packages for us
<Kamion> Mithrandir: hmm, I guess we'd have to put it in both for now actually
<Kamion> since the initrd's common
<Mithrandir> Kamion: it's a whopping 5k hit to the unpacked ram size.
<slomo_> elmo: please sync cln and haskell-devscripts from debian/unstable, ubuntu changes can be dropped... thanks :)
<tepsipakki> kamion: is the installer broken until 20051026ubuntu3 hits the archive?
<tepsipakki> I'm having all sorts of weird errors now ;)
<tepsipakki> using latest daily
<Kamion> tepsipakki: see topic
<Kamion> we mean it
<tepsipakki> oh
<Kamion> 20051026ubuntu3 may be broken too, I cannot guarantee anything much at the moment
<Kamion> for the next day or three, it's going to be more efficient for me to encounter the issues myself than to walk other people through how to fix them :)
<ogra> hmm, i removed kino from the edubuntu seeds and metapackages, why does it still show up in my cdimage report.html ?
<tepsipakki> that's ok, I'll try again after my vacation
<ogra> oh
<ogra> Kamion, cdbuilds stopped ? 
<Kamion> ogra: yes
<ogra> hmm, intentional i guess ..
<Kamion> deliberately
<Kamion> it should be obvious why if you stop to think about it :)
<ogra> yup 
<Kamion> (it's not going to work *anyway*, why bother building them ...)
<ogra> wasnt just fast enough .... my fingers were faster ;)
<Kamion> #ubuntu-devel benefits from thought *before* typing. :-)
<ogra> heh
<netdur> in case you don't know... this is very cool to point http://video.google.com/videoplay?docid=-6104490811311898236&q=
<netdur> is there any plan for enterprise edition of ubuntu?
<hunger> netdur: People are working on a server edition.
<hunger> netdur: #ubuntu-server is the channel of that subproject.
<netdur> I don't have problem with server... I installed ldap and sambe services on ubuntu server, it's joy and easy to do
<\sh> uh...apache 2.2.0 released
<HiddenWolf> so what would you consider enterprise material?
<netdur> the problem about to set ubuntu as client to active directory, exchange... and set up policy
<HiddenWolf> netdur, write some specs. :)
<doko> chmj: do you currently on libxt-java?
<doko> chmj: do you currently work on libxt-java?
<netdur> HiddenWolf, so no one working on that!!! I will write some specs and help myself... just about time ;)
<pitti> janimo: ping
<janimo> pitti, hey
<janimo> thanks for dbh :)
<chmj> doko: no, its uploaded 
<janimo> you can skip exo if you worry it's not from debian
<janimo> it will be shortly
<chmj> doko: its ftbfs, I'll fix it a abit later, do you need it ?
<doko> chmj: ok I fixed it. btw, the libservlet2.4-java b-d was not merged
<chmj> doko: its in universe for some reason 
<pitti> janimo: I try to catch up with the list now
<pitti> janimo: your reports are fine, but a bit concise
<pitti> janimo: I recently created a template for that stuff: MainInclusionReportTemplate
<pitti> janimo: if you do more reports, can you please use it?
<doko> chmj: please could you request a promotion to main?
<chmj> doko: sure 
* chmj afk 
<janimo> pitti, sure I saw the template I'll use that from now
<pitti> thank you
<janimo> so should I move reports as they are done in the main page?
<janimo> right now they're unde xfcemaininclusion
<pitti> janimo: why there are so many changes to upstream files (*.html and the like) in the diff.gz?
<janimo> hmm which package?
<pitti> janimo: yes, please move all reports directly to the main page
<fabbione> pitti: how do we look for min12xxw and foo2?
<pitti> fabbione: I approved it, and it's seeded, so it's looking good
<fabbione> pitti: ok thanks.. i guess we need Kamion to move them around, right?
<pitti> fabbione: however, to actually close the bugs, we pro'lly need them in desktop, not only in supported
<pitti> fabbione: elmo or Kamion, yes
<fabbione> they are in desktop
<fabbione> i did seed them in desktop
<pitti> oh, ok
<ogra> dholbach, thanks for the atomix update :)
<fabbione> if you didn't change it, they are there :)
<dholbach> de rien
<janimo> pitti, which package has the html changes in diff.gz?
<pitti> janimo: exo
<janimo> ah, skip exo for now then, it came not from sid
<janimo> debian has an older version, when it catches up
<janimo> we'll sync that and that will be cleaner
<pitti> hmkay
<pitti> janimo: shall I move it to the 'needs work' queue then? (for now)
<mvo> is anyone else seeing "dlopen: /usr/lib/xorg/modules/libGLcore.so: undefined symbol: __glXLastContext
<mvo> " in his Xorg.0.log with the latest xorg packages? it looks like it kills dri for me
<fabbione> mvo: what driver are you using?
<mvo> fabbione: ati
<janimo> pitti, fine
<fabbione> mvo: no, not here. but be aware the ati driver is shaky.. there are some bugs that needs to be addressed in the modular tree
<mvo> fabbione: hm, I wonder if it is a more general problem, I can't find this symbol outside of xserver-xorg-core (but I haven't greped through all drivers)
<fabbione> mvo: actually
<fabbione> there is no libGLcore...
<fabbione> or at least not on my system
<fabbione> meh ok
<fabbione> mvo: check /usr/lib/libGLcore.do
<fabbione> .so even
<fabbione> if the lib is there
<fabbione> we are either missing a symlink
<fabbione> or it's placed in the wrong position
<mvo> no, I don't have it there
<janimo> hmm can wiki pages be deleted/renamed?
<mvo> I set a symlink and will restart X with it, thanks
<pitti> janimo: yes, see 'further actions' menu
<pitti> janimo: 'more actions', even
<janimo> thanks
<mvo> fabbione: no, nothing changed
<fabbione> mvo: weird.. hold on
<fabbione> i am in the middle of a distupgrade... and can't isntall strings and stuff like that
<fabbione> grep __glXLastContext libGLcore.so 
<fabbione> Binary file libGLcore.so matches
<fabbione> this is on ppc
<mvo> sure, I'll poke around a bit more on my own and keep you updated (I'm on amd64)
<fabbione> ok
<janimo> pitti, I think that works only in tha launchpad wiki, not the ubuntu one, as I cannot see 'more actions' here
<pitti> janimo: it's there, I moved pages in the past
<mvo> fabbione: $ grep __glXLastContext /usr/lib/libGLcore.so
<mvo> Binary file /usr/lib/libGLcore.so matches
<mvo> interessting ...
<pitti> mvo: btw, I greatly miss aptitude for over a week now :(
<mvo> pitti: you do? why?
<pitti> mvo: it's uninstallable because of libsigc++-2.0-0c2a
<janimo> pitti, oh I see it now,was in edit mode.sorry for the nois
<fabbione> mvo: yes. it matches here too
<mvo> pitti: oh, so you get thesame error as mdz
<fabbione> grep __glXLastContext libGLcore.so.xlibmesa 
<fabbione> Binary file libGLcore.so.xlibmesa matches
<fabbione> amd64
<pitti> mvo: I mainly use it for the automatic dependency removal
<mvo> pitti: ok, let's debug it
<Kamion> hmm ... oh yeah, x86 assembler won't build very well on powerpc
<doko> pitti: do you have a hint, why it's uninstallable?
<pitti> doko: yes, gtkmm and workrave need to be rebuilt for the new C++ transition
<dholbach> gtkmm2.4 is done
<dholbach> gtkmm is *OLD*
<dholbach> and workrave doesnt use it
<dholbach> but i can rebuild workrave, if you want
<doko> dholbach: the merge report is still open
<dholbach> doko: the merge is senseless, but yes, i'll do it
<dholbach> doko: thanks for reminding me
<pitti> dholbach: hm, there seems to be a problem with gtkmm2.4
<pitti> dholbach: it apparently uses libsigc++-2.0-0c2
<pitti> dholbach: and aptitude wants libsigc++-2.0-0c2a
<dholbach> errrr
<pitti> dholbach: so a mere rebuild should help
<dholbach> it uses libsigc++-2.0-0ca (>=2.0.2)
<dholbach> at my place
<seb128__> dholbach: maybe you have a local build and the archive version
<dholbach> just one version here... hmm
<dholbach> do you all have libgtkmm-2.4-1c2a of version 2.8.1-0ubuntu3?
<dholbach> or am i the only one? :)
<seb128__> same version here
<dholbach> and i built gnomemm and gnomeuimm against it
<dholbach> so i have no idea what the problem is
<dholbach> but i'll poke at the merge and workrave
<pitti> dholbach: right, I have both the c2 and c2a versions of gtkmm
<pitti> dholbach: so it seems that just workrave still depends on the c2 ones
<dholbach> ah ok
* dholbach will take care of it
<pitti> dholbach: same for inkscape
<pitti> dholbach: thank you
<dholbach> pitti: ajmitch did inkscape
<seb128> I've planned an inkscape upload for other change anyway so there will be a new upload
<dholbach> you mean another one? ;)
<seb128> ?
<dholbach> it was already transitioned... nevermind me :)
<seb128> I don't upload it for the transition ;)
<dholbach> seb128: yeah - somebody else should do that crazy c++ stuff, right? ;)
<seb128> there is no cpp stuff to do, you said that's already done ;)
<seb128> anyway, time for lunch
<seb128> bbl
<dholbach> seb128: bon apptit
<ogra> WTH
<ogra> error opening security policy file /usr/lib/xserver/SecurityPolicy
<ogra> whats that ?? 
<Treenaks> a trojan!
<ogra> Treenaks, :p
<ogra> ah, it moved from /etc/X11/xserver/SecurityPolicy :)
<sebest_> Ubuntu 4 Servers, anyone?
<sebest_> this project could make a very good web interface for ubuntu servers: http://ebox-platform.com
<Mithrandir> doko: it seems the newer libjaxp1.2-java breaks xml-crimson builds..
<Mithrandir> doko: want to take a look?
<doko> Mithrandir: later
<Tm_T> sebest_: hmm, looks interesting
<sebest_> Tm_T, yes i also think so, and the developper documentation is good to write new module
<fabbione> sebest_: you can join and look at the topic on #ubuntu-serve
<fabbione> +r
<fabbione> #ubuntu-server
<sebest_> Fabbione, ok
<dholbach> and package ebox :)
<fabbione> that too :)
<Tm_T> sebest_: no pressure, just package it ;)
<Kamion> Mithrandir: I've added bootchart-udeb to the installer and casper seeds
<Mithrandir> Kamion: thanks
<sebest_> hi dholbach :)
<sebest_> it's already packaged for debian
<dholbach> oh cool
<sebest_> http://ebox-platform.com/download
<dholbach> but it should be in the distro
<dholbach> :)
<sebest_> it was developped on debian, so it won't be too hard to get it working on ubuntu i guess
<sebest_> dholbach, yes it should ;) what is needed?
<zakame> hi :D
<dholbach> sebest_: somebody should talk to the maintainers of those packages and ask, if they were willing to notify us of new package and some of us sponsor the uploads (if they don't want to become motus temselves)
<seb128> elmo: please sync gnome-python 2.12.2-2 from Debian incoming
<sebest_> dholbach, i can contact the author, should i cc to some list?
<ogra_> dholbach: they have a livecd .... guessing this is based on ubuntu they might already have ubuntu ready packages
<Mithrandir> hmm, it seems like jakarta-log4j1.2 can build fine without xml-crimson, and apart from the build-dependency, libcrimson-java-doc is seeded as supported.  Can we just chuck that out of main?
<dholbach> ogra_: afaik koke works on this too
<dholbach> ogra_: it's a matter of gettint that stuff in
<ogra_> ah, yeah, i thik he blogged it a while ago
<dholbach> yeah
<koke> I think it's tested on ubuntu too
<koke> I'm not part of the eBox team but they are in the same room :)
* ogra_ grumbles about totally broken xorg ....
<dholbach> ah koke :)
<dholbach> ogra: you're grumbling too much
<ogra> dholbach, i see to many bugs currently ....
<dholbach> grumbling doesn't help
<ogra> xorg doesnt work at all on thin clients... and it seems xauth is totally broken
<koke> sebest_: now the team is here :)
<isaac> lol
<ogra> koke, upload to revu !
<koke> I think I'm not in the revu keyring yet
<sebest_> koke, hi ;)
<sebest_> no need for the mail so :)
<ogra> koke, afaik you get in automatically with your first upload ... but i might be wrong, siretart will know ...
<ogra> s/upload/signed upload/
<koke> mmm, anyway I don't have my key here
<koke> btw, ebox may break current installations, it's meant to be installed in a dedicated server
<ogra> yes, i read that 
<koke> s/installations/configurations/
<Yagisan> ogra: siretart had to manually add me, so koke may need to ping siretart to be added
<koke> and it needs patching some packages like posfix and gconf
<ogra> do you have a debconf warning in the package about that ? so the user knows ? 
<Kamion> argh not more debconf notes
<ogra> Kamion, so it should just silently break the users system ? 
<isaac> ogra: it shouldn't be installed in any user system
<Kamion> no, it shouldn't break the user's system at all :P debconf notes aren't an excuse for bugs
<isaac> except a dedicated one
<Kamion> in that case it should require special action to enable, not just installing the package
<Kamion> ogra: also, this is what /usr/share/doc/ebox is for
<ogra> ah, yes, better ...
<Mithrandir> chmj: I'm doing a jakarta-log4j upload now to fix the FTBFS.
* ogra reboots to get 2.6.15-6 love
<raphink> :)
* ogra dances wildly around Kamion (looking a bit silly)
<ogra> Kamion, my orinoco card works !!!!
<Kamion> good stuff
<ogra> yeah :)
<koke> I think I'll upload eBox to revu this weekend
<freeflying> raphink:  how about your new kernel
<Kamion> ogra: you want to close the bug? (I'm assuming you didn't start cardmgr this time :-))
<ogra> yup
<ogra> only pccardd is running
<ogra> will close it
<Kamion> (pccardd is a kernel thread)
<ogra> yup..
<ogra> but its the only output of "ps ax|grep card" ;)
<Kamion> right, you get one pccardd per socket I believe
<ogra> yup
<ogra> closed ...
<Kamion> hmm, gfxboot seems to do precisely nothing
<ogra> with the patches included already ?
<Kamion> yes, obviously
<Kamion> tracing indicates that it gets to the start of get_gfx_file and then falls out without hitting any more tracers; I'll have to add some more tracing I guess
<jordi> Kamion: is the date format mm/dd/yyyy something from the US, or is it common in Britain as well?
<Kamion> jordi: that's the US abortion of a date format
<Kamion> jordi: UK uses dd/mm/yyyy
<jordi> I think it's only a US brainfart, but just checking
<jordi> ah, thanks. :)
<mvo> elmo: please sync libmpeg3 from debian (override ok)
<zyga> hey mvo
<mvo> hey zyga 
<zyga> does anyone have contact with tango-project.org upstream?
<ogra> zyga, dholbach i think
<sladen> oooh, debtags causes  glibc: free() invalid pointer... funky
<enrico> sladen: gah, I have no time to debug it now :(
<enrico> sladen: but please keep me posted on it, I might have more time in a few days
<aigarius> could someone please approve my email to ubuntu-devel regarding "HomeUserBackup Feature Specification" ?
<janimo> aigarius, aren't you subscribed?
<aigarius> janimo, no, I never have been :)
<janimo> try gmane/nntp if you don't want to subscribe then
<janimo> admins, approving non-subscriber mails just doesn't scale :)
<aigarius> aren't messages coming in via news gateway moderated too?
<janimo> yes, but you confirm once to gmane and you're done
<janimo> and you don't get you rinbox filled either
<mvo> elmo: please sync mpeg2dec from debian (override ok)
<aigarius> janimo: well there is the same option in mailman - just tick a box while approving the first message and all further messages from this email will be approved automatically
<janimo> yes, but that is doen by an operator, while gamne does it automated
<sivang> aigarius: why don't you subscribe then?
<aigarius> sivang, because I am not really an Ubuntu developer?
<Mithrandir> doko: would you mind if we removed libcrimson-java-doc from supported and kicked xml-crimson out of main?
<sivang> aigarius: well, not all of the people are sub'd there are ubuntu developers per se, you could sub there if you are interested in any of the discussions there. Anyway, I'm the HomeUserBackup asignee - what feedback do you bring ? :)
<jbailey> pitti: There?
* janimo guesses sbackup knowledge
<pitti> jbailey: yes, good morning
<sivang> janimo: ?
<sivang> pitti: Hey Martin
<jbailey> pitti: At some point I think we might have selinux questions for you.  
<janimo> aigars is author of sbackup
<jbailey> doko: ^^ ?
<pitti> jbailey: uh, oh, toss them to ajmitch :)
<sivang> janimo: oh :-D , I had no idea
<pitti> jbailey: I used grsecurity, but never SELinux, since it was a PITA to setup in the past
<doko> Mithrandir: looks ok, no rdepends.
* sivang wonders if selinux integration is getting closer.
* sladen wonders if it is selinux that is currently stopping X loading (the other being that xorg-server-driver-* weren't installed by default)
<sladen> s/driver/input/
<aigarius> I just subscribed, waited a minute and resent my email, but still got the same "your email is held for moderation" reply
* netjoined: irc.freenode.net -> brown.freenode.net
<sivang> aigarius: were you planning to add external device backup to sbackup ?
<sivang> aigarius: (e.g, CDRW/CDR/USB..)
<aigarius> sivang, jep. it actually is very simple given the sbackup architecture
<aigarius> sivang, I even had the glade files for the gui in my original spec :)
<sivang> aigarius: wow cool, then it seems there is not much point in trying to implement my spec - there is only one thing I am currently thinking of in order to merge our two specs
<aigarius> sivang: please take a look at http://sbackup.sourceforge.net . I am trying to make a braindump of my ideas about backup there. you could help with you ideas.
<sivang> aigarius: if you could take the "Simple Mode" ideas from my spec , and incorporate them into a "simple mode" available in sbackup , and running by default. that would rock
<sivang> aigarius: the simple mode operation will do all what I specified in my spec as a default, e.g. backup ONLY home directories, be default exclude all media content, and use the CDRW/CDR/USB as I described there. it seems it wouldn't require too much additional work, as you say you have most of the infra. in plac.e
<aigarius> my email finally got trhough to the list, please read it
<sivang> aigarius: I will sure do. thank you
<dholbach> elmo: do you what happened to my corrected version of gnome-web-photo?
* mpt wonders why mozilla-thunderbird-inspector is in main, when the far more useful firefox-dom-inspector is in universe
<Kamion> dholbach: it's in NEW
<mvo> doko: does https://launchpad.net/products/gnubash/+bug/5120 look ok to you?
<dholbach> Kamion: elmo asked me to do a tiny change to it, i did it and reuploaded (with new version number and .orig.tar.gz) but it was rejected, since the .orig.tar.gz was already there
<Kamion> was the second .orig.tar.gz different?
<dholbach> i shouldn't think so
<dholbach> oh well, if it's in NEW, i'll just wait
<Kamion> dholbach: just reupload without -sa
<dholbach> ok
<dholbach> merci Kamion 
<Kamion> dholbach: 0.1.1-0ubuntu1 is in NEW; if elmo asked you to make a change to it I doubt it'll get out of NEW until that change is made
<dholbach> understood, thanks Kamion 
<elmo> no, it was a trivial change, it can get out of NEW as is, I just haven't had a chance to do that yet
<dholbach> elmo: take your time... i just thought i had done something wrong
<Kamion> surprised you didn't get the reject message though - you were using an @ubuntu.com address so it should've been whitelisted
<Mithrandir> Kamion: can I just unseed libcrimson-java-doc or is there somewhere I should raise discussion about it?
<dholbach> Kamion: i got the reject message, that's why i asked
<Kamion> Mithrandir: if nothing uses the main binary, it's fine to unseed under the general banner of reducing-duplication
<Mithrandir> Kamion: ook.
<elmo> Kamion: I didn't reject it
<elmo> oh that reject, neer mind me
<Kamion> elmo: -0ubuntu2 was rejected
<doko> mvo: 127 -> EX_NOTFOUND, but looks ok otherwise
<zyga> doko: hi
<zyga> doko: that's exactly why 127 was choosen
<zyga> doko: so the handler can ask for default action fallback
<zyga> (which is: print the message)
<sivang> aigarius: still didn't see it, I'll give it some minutes to arrive
<aigarius> sivang, I see it in the archive
<sivang> aigarius: ok, it arrived now.
<pitti> Diziet: ping
<Diziet> Hi.
<pitti> Hi Ian
<pitti> Diziet: a dpkg question
<Diziet> Sure.
<pitti> Diziet: if package A ships a conffile, and package B Conflicts/Replaces/Provides: A, and ships the same conffile
<pitti> Diziet: how is it possible to get a file conflict on upgrading A to B?
<pitti> Diziet: I'm asking because of https://bugzilla.ubuntu.com/show_bug.cgi?id=20265
<Diziet> That sounds wrong to me.
<pitti> Diziet: the bug or the dependencies?
<Diziet> The bug.
<pitti> Diziet: libcupsys2 c/r/p libcupsys2-gnutls << 1.1.23-11
<Diziet> That is, if B -c/r/p-> A then A should be removed first.  Now obviously A's conffiles may remain but they ought to be taken over by B.
<pitti> and breezy has -10ubuntuN
<pitti> so the conffile shouldn't stay in A's file list?
<Diziet> This may be related to the `dpkg conffiles bug' which Keybuk said he'd been working on.
<Diziet> Yes, the conffile should stay in A's file list until B is unpacked, and then B should end up owning it.
<pitti> if I merely remove A, then the conffile certainly stays in its list?
<pitti> ah, ok
<Diziet> Quite so.
<pitti> Diziet: but it doesn't ATM?
<Diziet> Um, well, evidently either we don't understand the situation correctly or there is a bug in dpkg.
<sivang> Diziet: hey Ian, it seems that sbackup's author ( aigarius ) is going to acutally implement most of what we discussed over HUB spec, and some more. My feeling is that the spec should stay informational if only to give him more ideas to be merged, and doesn't stand on it's own as implementation worthwhile. What is your opinion?
<Diziet> I say `should' because I want to describe what it ought to do without reference to the actual behaviour :-).
<pitti> Diziet: I don't really want to rm the conffile in -gnutls10's preinst
<Diziet> pitti: No, no, don't do that, definitely.
<pitti> no, I don't want to stomp over the admin's customizations
<Diziet> sivang: Oh, excellent.  sbackup does not a fair amount of work, I think.
<pitti> Diziet: ok, thank you; I'll CC Scott on the bug
<Diziet> Do.  He said he's got some kind of ADSL problem so do email him.  If you could CC me (iwj@ubuntu.com) that would be good.
<sivang> Diziet: you mean, does not (need) a fair a mount of work ? :)
<Diziet> Err, I mean it _needs_ a fair amount of work.  Sorry.
<Diziet> Provide him with the bugzilla url you just gave me and obviously my offer to help.
<Diziet> But I don't think I should start messing with the conffile handling which he said he's fixing.
<sivang> Diziet: I will sure do, np :)
<mvo> Diziet: did you got my python mozembed problem report? do you have any idea about it? or should I poke around it a bit again?
<Diziet> sivang: Err, that instruction with `Provide him with the bugzilla url' was to pitti.
<pitti> I read it :)
<sivang> Diziet: oh, hehe np at all.
<Diziet> sivang: But you can pass on my name to aigarius of course :-).
<Diziet> mvo: I have no idea about it.  If you have effort to diagnose it then that would save me the work, otherwise I may or may not get round to it in today's upload.
<aigarius> Diziet, me here :)
<Diziet> aigarius: Ah, hello :-).  Did you read the HomeUserBackup wiki page we had ?
<Diziet> aigarius: Also, you may have seen my bug reports against sbackup in the Debian BTS.
<aigarius> Diziet, I have seen the bug reports and will try to make the stuff you mention there, but that wiki page ... I am not sure that there is much usable stuff there
<aigarius> Diziet, it assumes that we want to bother the user each and every time that we think a backup should be done, after some time that will gt annoying
<Diziet> aigarius: Yes, I think we do want to bother the user.  That is, we bother them once to ask for permission to bother them in future.
<aigarius> Diziet, also there is no room for user growth. I think that advanced backup features should be available from the same location as the simple way and as similar as possible
<Diziet> aigarius: I think this is needed, really.  You'll have seen all the desperate messages from people who've lost their PhD thesis or their draft novel.
<janimo> Diziet, you mentioned yesterday firefox and gnome MIME handling
<janimo> does that mean ff will grow gnome lib deps?
<Diziet> janimo: Yes.
<janimo> :(
<Diziet> janimo: Our ff already has gnome lib deps I think.
<janimo> the one in breezy did not at least
<sivang> Diziet: see also, http://lists.ubuntu.com/archives/ubuntu-devel/2005-December/013518.html
<janimo> and neither does current ff 1.5
<Diziet> janimo: Is that a bad thing ?
<SEJeff_work> \sh: ping
<janimo> only suggests ff-gnome-support
<janimo> Diziet, well it was/is the default browser in xubuntu
<janimo> which tries avoiding gnome libs everywhere
<Diziet> sivang: No, I hadn't read that yet.  Will do now.
<janimo> one gnome lib tends to bring in the rest
<janimo> what is exactly used gnome-vfs for mime functions?
<seb128> yep
<janimo> that's all or deeper gnome-vfs integration is planned?
<seb128> which doesn't bring all the UI stuff
<janimo> if only local files are looked at, isn;t there some other mime lib? xdgmime or something else?
<Diziet> janimo: Just to find the right application to open some content with.
<janimo> current firefox scheme is messy?incomplete?
<Diziet> Current firefox mime handling is totally insane.
<SEJeff_work> totally broken
<Diziet> aigarius: Hmm.  I read your posting, but I think we have a different view about these things.  I think backups to the same disk have very limited value.
<janimo> does anyone actually use xdgmime (the lib not the spec?)
<pitti> does anybody have a breezy box at hand?
<janimo> it's a shame bringing in so many deps for just mime matching
<seb128> janimo: gnomevfs
<Diziet> If dpkg-shlibdeps did the right thing, my package with the uriloader fix just uses libglib2 and libgtk2 (and many other libs not starting libg.)
<SEJeff_work> janimo: Could you do something like OO.o native widget framework and "use it if it's available"?
<seb128> Diziet: you don't use libgnomevfs2-0 for mime stuff?
<aigarius> Diziet, they recover deleted and corrupted files, they are easy to implement, they are completely automated. and power users can use the same backup scheme to backup to a mounted USB drive, another HDD or even a remote server mounted via NFS of FUSE or whatever else that Linux supports.
<sivang> aigarius: what about non power users?
<siretart> elmo: please sync qjackctl from unstable, dropping ubuntu changes
<Diziet> Hard-disk to hard-disk backups can be done easily by the user with nautilus anyway.
<Diziet> I think the problem is that you're not addressing the real difficulty with un-backed-up home user systems.
<sivang> Diziet: true, a matter of drag-n-drop
<Diziet> This is particularly true of laptops.
<SEJeff_work> aigarius: I tried sbackup and coudn't get used to it. rsync is a needed feature
<aigarius> sivang, they will have automatical daily backups of all important files. you can forget to make a backup by drag and drop. cron will not.
<Diziet> seb128: The firefox-gnome-support package appears to depend on libgnomevfs2-0.
<dholbach> elmo: can you please sync libfwbuilder from sid (ok to override)
<Diziet> seb128: I think the best thing to do would be for me to upload a ff with this patch included and you can tell me whether you hate it.
<seb128> Diziet: so this part of the code is probably shipped by this package which makes janimo happy
<janimo> seb128, bonobo,gamin,gconf,orbit,libsmb are all vfs deps
<aigarius> AND by trivial drag and drop or nautilus CD writer users can archive a selfcontained backup snapshot to any media
<seb128> janimo: yeah, what I said, no UI
<Diziet> seb128: If so, then yes, but I'm suspicious because I read the patch and it didn't seem to be in the gnome support part.
<sivang> aigarius: yes, btw - what about offering to someone to use other backend engine for backups? many people seem to want a frontend solution to use rsync, as is very robust and already proven to work.
<uenyioha> question for the not so faint hearted
<janimo> seb128, why UI is the largets part of gnome libs?
<Diziet> What I would like is for a naive user to be prompted by the system to make backups and for the system to make it as convenient as possible.
<ogra> BenC, around ?
<BenC> yeah
<janimo> if the patch would be just in gnome-support that would be great
<seb128> janimo: why? because
<uenyioha> is there a flag for ld that specifically tells it to create an x86 library on an amd64 system
<BenC> ogra: pong
<Diziet> We need to think about the problem not as `how can we add buzzword-tickybox "backup" to our system' but rather `how can we improve many of our users lives by saving them from data loss'.
<ogra> i have a prob with ndiswrapper on amd64, i get a lot of ndiswrapper: Unknown symbol x86_64_  output if i try to load the module
<janimo> seb128, I meant why, is UI the largets?
<sivang> Diziet, aigarius : may we continue this discussion over the mailing list? I have to run now, but I think this discussion is important and interesting.
<ogra> BenC, ^^
<Diziet> sivang: Right.  I'll see if I can reply later today.
<ogra> BenC, is the module not compiled with amd64 support ? 
<janimo> wrong wording
<BenC> ogra: hmm, we had that before in breezy, and it was the build process, but I was sure I got things right in dapper (I fixed breezy)
<Diziet> Err, -2s/users/&'/
<aigarius> Diziet, that can be accomplished by doing 3 things with SBackup: ask a question to switch from "no backup" to "recommended backups" on first startup, implement backup to CD, make a montly prompt to the user to write the latest daily backup snapshot to CD or other secure location
<BenC> ogra: I'll  get it fixed for -7.9
<jbailey> -7.9?
<aigarius> Diziet, sivang: sure, lets continue in the mailing list
<ogra> BenC, this card never worked, so i dont reallycare, but apparently it shall work in suse sinc ndiswrapper 1.4 so i thought i'd try again...
<Diziet> aigarius: I think you really want to look at that HomeUserBackup wiki page for answers to questions about prompt order.  We thought quite carefully about these things.
<Kamion> uenyioha: -m elf_i386
<jbailey> Are you not resetting the number after the decimal place when you increment ABIs?
<Kamion> uenyioha: obviously the objects will have to have been built 32-bit as well
<uenyioha> Kamion: yeah...the funny thing is they are
<infinity> jbailey : No, the point is to say "7th ABI, 9th upload)
<infinity> s/)/"/
<uenyioha> Kamion: i was expecting ld to automagically know what to do with them
<sivang> Diziet, aigarius : cool thanks.
<seb128> janimo: probably, gconf/gamin/gnomevfs are quite small
<Kamion> uenyioha: ld defaults to elf_x86_64 emulation on amd64, afaik
<jbailey> infinity: Ah, okay. =)
<sivang> Diziet: I basically just want to see that we are not dupping any work or reinventing someone else's wheel, before embarking on the implementaion furiously.
<Kamion> uenyioha: might be nice, but I don't think it does
<janimo> seb128, g-vfs uses a copy of xdgmime right?
<janimo> I see also gtk has xdgmime code in it but it doesnot look like it's used
<seb128> janimo: correct, as do gtk
<Diziet> seb128,janimo: I think there are two sensible answers to this question: 1. wait for my package, which will be uploaded today.  If you don't like it, say so and then we can talk with actual information.   2. I email you the diff that I've applied and you tell me whether you hate it by reading it.
<uenyioha> Kamion: yeah that worked like a charm
<uenyioha> Kamion: Thanks!
<Diziet> I don't think this discussion of abstract possibilities is really going anywhere, is it ?
<sivang> anyway /me --> out now.
<Diziet> sivang: TTFN
<janimo> seb128, is the gtk xdgmime exported to apps?It doesnot look like it is
<seb128> Diziet: I'll just wait for your upload and play with it, thanks :)
<janimo> and if it is maybe it would be a better match for just mime handling than gnome-vfs
<seb128> janimo: gtk doesn't do mime stuff, gnomevfs does
* Diziet goes back to working on the package.
<janimo> what does gtk use xdgmime for
<janimo> if not mime stuff?
<seb128> janimo: probably GTK stuff but no external API to be used by other apps
<janimo> Diziet, go ahead with 1
<seb128> janimo: like the png loader, etc
<janimo> I'll see what I'll do later
<Kamion> uenyioha: you're welcome
<janimo> is xdgmime considered unworty currently of being actually released and packages as a libary?
<janimo> I've seen other uses of it are the same 'copy in the tree' types
<seb128> janimo: <mclasen> seb128: the xdgmime api is not really that great, and in fact has changed repeatedly
<mdke> elmo, docteam commit access for bhuvan pleeeeeaase :)
<Diziet> Can I rely on the URL  http://www.ubuntulinux.org/support/releasenotes604  coming into existence when Dapper releases ?
<infinity> s/ubuntulinux.org/ubuntu.com/
<infinity> We're moving away from the former.
<infinity> Or trying.
<janimo> seb128, ok I see. So what's the point of it then?Just a testcase for shared-mime-info?
<janimo> btw, I looked at memory consumtion of some gnome libs and they're about 3 Mb together.
<janimo> those non UI
<Diziet> infinity: Thanks, noted.
<seb128> janimo: no, it's used by gtk/gnomevfs, but they don't want to depend on a moving API
<seb128> janimo: by shipping a copy they are sure they don't break due to some external API changes they have not followed
<janimo> aha
<seb128> janimo: <mclasen> seb128: we have hesitated for years to put it in glib, because of the "what to do on win32" issue
<mdke> Diziet, i think you probably can count on it yes, but it is worth firing an email off to henrik to make sure he's aware of it
<janimo> fscking win32
<whiprush> jdub: pong
<Diziet> mdke: Ta.  I've done so.
<xhaker> seb128: care to make a libsexy package for universe?
<seb128> xhaker: I can do that, right
<pitti_> re
<xhaker> seb128: looks like debian doesn't have it.. oh and xchat-gnome can spellcheck if compiled with it
<seb128> xhaker: I'm not sure than people want spellchecking their IRC :)
<xhaker> seb128: it's the same feature Gaim has
<xhaker> seb128: it only highlights possible mistakes
<Amaranth> so, uh, does the new g_slice_* stuff in glib means apps will stop holding on to large chunks of unused memory?
<mdke> people don't take enough care of their grammar on IRC these days
<xhaker> not sure if it uses aspell tho.. but i should
<xhaker> it*
<seb128> xhaker: I think that people doesn't try to make 0 mistake when using IRC, but maybe that's just me :)
* mdke points at xhaker's misspelling of the word "tho"
<seb128> mdke: no only the grammar
<mdke> disgusting
<seb128> s/no/not/
<xhaker> mdke: lol
* mdke underlines lol
<Kamion> mdke: (shouldn't that be "take ... care about", anyway?)
<Kamion> (as opposed to ensuring that your grammar is properly fed)
<mdke> yeah
<xhaker> mdke: spellcheck happens on the editbox only i think :P
<seb128> xhaker: anyway, I'll package the lib, which was the topic
<seb128> or get dholbach to package it :)
<xhaker> thanks
<seb128> np
* dilinger looks at the invitation in the topic.. ooh, new kernels!
<ogra> invitation *g*
<xhaker> wasabi_ the wise
<janimo> pitti, how will packages which are not germinated getting in main afer approved?
<janimo> the xfce ones are not in any CD build
<pitti> janimo: they either need to be seeded, or be a dependency of other packages
<pitti> janimo: i. e. you would seed the core components, and this would draw in the libraries
<janimo> pitti, yes but the seeds xfce is in are not build by Kamion/Riddell
<janimo> so I am afraid they won't get in anastacia
<pitti> hmm
<pitti> this almost cries for a new set of seeds
<janimo> they may eventually, but not yet
<pitti> alternatively we would just seed xubuntu-desktop in supported
<janimo> I am keepeng them outside ~cjwatson/seeds
<janimo> ah that's a good idea
<Kamion> janimo: that will be sorted out eventually
<Kamion> once there's a reasonable set of xfce stuff approved, it can trivially be added to anastacia's output
<janimo> nice, thanks
<Kamion> putting xubuntu-desktop in the Ubuntu supported seed isn't something I want to do
<janimo> right
<janimo> I was wondering isn's supported common to ubuntu/kubuntu just like minimal
<janimo> ?
<janimo> and only desktop/ship different?
<dholbach> seb128: package it?
<janimo> dholbach, he meant libsexy
<dholbach> what uses it already?
<Kamion> janimo: no
<dholbach> janimo: what uses it already?
<Kamion> janimo: minimal and standard are common for technical reasons (can't do per-derivative priorities)
<dholbach> janimo: or just to hack with it?
<janimo> so isn't 'supported' seed == supported by canonical
<wasabi_> So what's this libsexy control that makes IP entry possible?
<Kamion> janimo: it used to be
<janimo> dholbach,dunno, but that's what he was talking about 
<janimo> with xhacker I think
<dholbach> janimo: thanks
<Kamion> janimo: current definition is that everything in main is supported
<slomo> pitti: regarding XSP... it's possible to package this script in a different sourcepackage or include it somewhere else but we would differ greatly from debian. what are your concerns moving the sourcepackage and mono-xsp-base (which in fact is only the debhelper script) to main and leaving everything else in universe?
<janimo> later
<pitti> slomo: as soon as the source is in main, it is supported
<pitti> slomo: including the universe debs it builds
<pitti> slomo: we can slack a little with updates, but everybody can grab the source from main and build stuff
<pitti> slomo: and I wouldn't like to keep up with fixing the xsp server for 5 years just for the debhelper script
<slomo> pitti: oh, i thought we would only support the binary packages in main :/ ok, i think it's the best then to move the script to mono-utils or in a separate source package
<pitti> slomo: does that sound totally stupid for you?
<slomo> pitti: me neither... xsp itself isn't ready for supporting in any way yet
<pitti> slomo: does xsp-base depend on any package in main that would be suitable to ship the script?
<pitti> slomo: a separate source apckage just for a single debhelper script seems pretty heavy for me
<slomo> pitti: well, the best would be mono for the time beeing... it was there in the past
<pitti> slomo: maybe Debian can be convinced to do the same...
<pitti> if not, is the delta very big?
<pef> hello
<Nafallo> what's the policy with transitional packages from warty to hoary? keep them until warty isn't supported anymore?
<slomo> pitti: not too big... only some new files... i'll talk to debian later and if they want to keep it that way prepare to ship it with mono for dapper. or we could just stop shipping the monodoc-http package for dapper, tseng and me don't think it's very useful anyway... i'll think about it
<Nafallo> ooh. it's already gone in dapper, never mind then :-).
<pitti> slomo: I'd love you if we just shipped the standalone browser and put doc-http to universe :)
<tseng> pitti: the source needs xsp as a build dep
<tseng> because of the stupid script
<tseng> whether the binary goes to universe or not (which i advocate already)
<slomo> pitti: the standalone browser is in universe atm btw ;) it's the mono-utils package. but i think we should get it into main for dapper
<tseng> it would probably be pretty easy to put dh_installxsp into the monodoc source
<slomo> tseng: or we could just do what dh_installxsp does by hand... should be even easier... the results are no black magic
<tseng> yes
<slomo> tseng: but i think we should write a main inclusion report for mono-tools soon... (which will pull nunit into main too)
<slomo> tseng: currently monodoc is pretty useless without the standalone browser
<tseng> sigh, nunit
<tseng> just wait until something depends on a feature in the novell forked version
<xhaker> dholbach: libsexy -> xchat-gnome "can" use it for stuff like spellcheck and url highlighting
<BenC> can anyone see a reason for enabling USB network devices for our server class kernel?
<eruin> does anyone know when mvo is usually around?
<BenC> IMO, I can't think of anything we need USB for servers other than HID/kbd/mouse and mass-storage
<dholbach> xhaker: nice
<pitti> BenC: hmm, when you want to allow using USB drives on a server (*shudder*), why forbid USB network cards?
<tseng> BenC: i could easily imagine someone wanting to build a "server" out of some beat up old beige box and hanging on a usb wifi thingy
<xhaker> dholbach: that's what i thought :P
<tseng> for connectivity only or to act as a hacker-type's AP
<pitti> BenC: as tseng says; my kitchen server needs USB wireless, too :)
<BenC> this isn't "I call it a server because it runs apache", this is "8-way NUMA" system type servers
<dholbach> xhaker: i saw it in blogs, just wasnt sure what you and seb were talking about
<BenC> high-end
<pitti> BenC: these things are usually driven with an USB mouse? (serious question)
<BenC> pitti: PC's, I suspect yes...it's not like an ultrasparc where serial console is the prefered method of accessing it :)
<BenC> probably doesn't need a mouse, but USB keyboard for sure
<Kamion> the mouse is generally not the first thing you spec about such a box - you might well just plug in whatever's lying around the server room
<Kamion> (on the rare occasions that you'd need it)
<BenC> yeah, I'm including HID stack just because being able to connect a keyboard is desirable
<BenC> so does USB drives sound crazy? Maybe they connect USB dvd burners for backups (who knows), just mass storage seemed like a decent requirement
<BenC> but USB networking seemed kind of like using a go cart wheel on a race car
<xhaker> BenC: better off asking those things to some datacenters
<xhaker> some kind of survey
<pitti> BenC: hm, you probably don't worry about the memory requirements; do you think they make the system potentially unstable?
<tseng> xhaker: im sitting in a data center
<xhaker> tseng: good. help him out :P lol
<BenC> pitti: I just want to trim down our requirements for that kernel
<pitti> ah
<BenC> if I say "USB network devices are ok", then we open ourselves up to requests for whacked out external drivers
<pitti> right, they shouldn't be on such a box
<BenC> and supporting high-end servers is going to be hard enough without adding a $30 Walmart USB wireless device to the list :)
<torkel> BenC: or usb floppies, or... but usb network nah...
<pitti> torkel: right, in the end the guys want automounting USB devices :)
<BenC> main thing is for the server kernel, we want to support configurations that come from the vendors
<BenC> and not a whole lot else
<BenC> but common add-ons need to be supported if they make sense
<tseng> watch out for the bong when you get to Dell raid controllers
<doko> how do I add a custom field to a control file. dpkg-gencontrol seens to strip the additional field name, even if it starts with X-, which should be allowed: dpkg-gencontrol: warning: unknown information field `C1 X-Foo-Bar' in input data in package's section of control info file
<torkel> pitti: we want to netboot everything, including bios upgrades :-)
<siretart> BenC: is prism2_cs known to be broken?
<BenC> tried hostap_cs instead?
<pitti> OMG, somebody wrote a main inclusion report for fam
<BenC> hostap has some overlap with a few external drivers that we had in breezy, and I need to figure out where that overlap is
<torkel> pitti: and everything should be remotely controlled. We never ever want to go down to the machine room, it's too hot and noisy in there :-)
<siretart> BenC: hm. both seem to be loaded
<pitti> torkel: my own server is 800 km away from me, so my kernel has nothing but the bare minimum either
<siretart> and I cannot rmmod prism2_cs, because it is in use (wtf?)
<BenC> tseng: second phase is to get vendors to allow us to distribute their raid tools and such
<tseng> oh!
<Kamion> doko: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s5.7 describes how to make it work
<siretart> BenC: is that prism2_cs breakage known or shall I file a bugzilla?
<BenC> siretart: file a bug please
<BenC> siretart: try blacklisting prism2_cs so hostap_cs can take over
<BenC> rmmod both, and then modprobe hostap_cs
<siretart> hm
* siretart looks up how to blacklist with new udev
<doko> Kamion: thanks
<eruin> Conflicts: hotplug (<< 0.0.20040105-1)
<eruin>  <- hotplug no longer necessary for 2.6.15?
<Kamion> eruin: indeed
<eruin> exciting ;)
<Kamion> hmm, debian-installer 20051026ubuntu3 still won't work, oh well
<Kamion> next daily build of it will hopefully wrk
<Kamion> work
<jbailey> Kamion: Has ther ebeen any installer fallout so far from the locales transition?
<Kamion> jbailey: haven't rebuilt localechooser yet ...
<jbailey> Ah, okay.
<Kamion> at the moment I'm wading through the fallout from the kernel/udev transition, and won't be able to see the locales transition until I'm on the other side, really
<jbailey> 'kay.  As long as you're not feeling abandoned and unloved by Martin and me. =)
<mkrufky> hey.... what package do i need in order to install sox?
<mkrufky> sorry if the question  is OT
<mkrufky> but apt-get says sox is referenced by another package, and apt-cache finds nothing
<\sh> re
<Diziet> mvo: I'm just picking up investigating that ff python crash now.  I'll see how far I get.
<doko> Diziet: which architecture?
<sabdfl> hi all
<sabdfl> how's dapper right now?
<sabdfl> i have a few minutes, and wondered if it was worth updating
<sabdfl> has the new kernel stuff landed, and is it roughly working?
<sabdfl> mdz: ping ^^
<JanC> it's roughly working for some people AFAIK  :)
<mdz> sabdfl: see topic
<dholbach> it is roughly working, the really bad trouble is over :)
<sabdfl> ah, bugrit, why not
<sabdfl> it's a long drive to ft collins
<mdz> sabdfl: if you're already on 2.6.15 and you know that that works well, you can try it
<dholbach> JanC: i'm one of the lucky guys then :)
<mdz> sabdfl: it's a long drive without Internet ;-)
<minghua> kernel is not bad, yesterday I booted into 2.6.15 the first time
<sabdfl> mdz: no internet till monday, likely
<Diziet> doko: i386.  Why ?
<doko> Diziet: need to fix an amd64 issue, but thats amd64 only
<sabdfl> mdz: hmm... why is linux-image-2.6.15-5-686 not available?
<mdz> sabdfl: because it's been superseded by -6
<sabdfl> i just did an update
<JanC> BenC: I would say that people who need USB networking for their server can as well use a "normal" kernel on their "server" (which would likely be a home server/router with usb wireless or something like that)?
<mdz> mizar:[/var/log/cups]  apt-cache show linux-image-2.6.15-6-686 |head -1
<mdz> Package: linux-image-2.6.15-6-686
<BenC> JanC: that's my thinking too
<Diziet> doko: `an amd64 issue' ?
<BenC> sabdfl: it's not as bad as people make it sound, I have latest dapper + 2.6.15 on 6 machines here, and they aren't smoking that bad, and I've only lost one harddrive :)
<Diziet> If you need me to fix it now would be a good time.  I'm currently test-building my latest edits.
<mdz> sabdfl: you aren't in ft. collins yet?
<sabdfl> mdz: no. headed there shortly
<mdz> BenC: I had a strange issue with a firewire hard drive last night
<mdz> it showed up as 4 separate direct-access storage devices, all of which were inaccessible (no medium found)
<BenC> mdz: that is pretty odd
<mdz> I was told it worked fine on a Mac running 9.3
<Simira> hmm... how bad is it when London is rainy? Like, wearing army boots, or just solid shoes? The forecast says showers for all the four days we are staying there... anyone?
<BenC> mdz: I pulled in the ieee1394.git that -mm uses, but without that it's pretty broken for a lot of people anyway
<mdz> Simira: reasonable shoes and an umbrella
<mdz> BenC: this was on a breezy system
<BenC> mdz: Oh, understandable then :)
<mdz> I had success with a firewire dvd-rom at some point in the distant past, like hoary
<mdz> on the same machine
<mdz> (desktop G4)
<BenC> yeah, it's just a few types of sbp2 devices
<BenC> my G4 firewire is working fine with 2.6.15, never tried it with 2.6.12 though
<BenC> 250gig LaCie drive
<Simira> mdz : ok, thanks. "Showers" means a lot more in Norwegian...
<xhaker> sabdfl: something you wanted to know about gtkwifi in ubuntu forums?
<sabdfl> xhaker: yes, can't remember the specifics. url?
<xhaker> you wanted to know if it is a complement to network-manager
<xhaker> let me introduce, i'm project admin/coder of gtkwifi, the url http://ubuntuforums.org/showthread.php?t=94536
* Nafallo looks for mvo *
<xhaker> sabdfl: gtkwifi is the easiest solution for free/wep wireless connections, it's a gnome applet, so it means it only works inside gnome (not a daemon)
<sabdfl> xhaker: ok, looks good. is there a good gtkwifi package on ubuntu?
<sabdfl> would you work with seb128 on that?
<sabdfl> i have to run for a car
<xhaker> sabdfl: i would like to.. i already package it in .deb
<xhaker> but maybe some stuff might not be fine
<sabdfl> ok., seb128 will help you get it perfect
<dholbach> xhaker: then you should put it up for review
<dholbach> or the seb128 way :)
<dholbach> xhaker: do you have the source package somewhere, so i can have a look at it?
<xhaker> dholbach: i already have revu rights, been lazy to learn dput tho
<mdz> Mithrandir: I've reassigned simplified-livecd to you, per discussion yesterday
<xhaker> dholbach: in a minute
<dholbach> xhaker: then upload it there - that's the easiest way
<xhaker> dholbach: an url to the .deb http://easynews.dl.sourceforge.net/sourceforge/gtkwifi/gtkwifi-1.09.deb
<dholbach> the deb doesnt help :/
<dholbach> you need the source package
<xhaker> dholbach: tell me if it's ok
<dholbach> xhaker: let's take it to #ubuntu-motu
<xhaker> k
<mdke> Simira, it's cold too
<Simira> mdke : the forecast says 5 to 9 celsius. considered the -9 to 0 celsius in Norway at the moment, I find that comfortable.
<mdke> sure, just don't pack for the beach and you'll be ok
<Simira> mdke : I'm NORWEGIAN. :p
<mdke> yeah, same hemisphere and so on
<Simira> well, I was mostly melting when _someone_ in Montreal told us to dress "warm and sensible"....
<spacey> i thought is was pretty cold :P
<zyga> is there any way to get current line and filename in python
<zyga> something similar to __LINE__ and __FILE__ from gcc?
<Kinnison> zyga: I think __name__ is similar to __FILE__
<Kinnison> but I could be wrong
<zyga> __name__ can be "__main__" so I guess not
<Kinnison> sys._getframe() could give you the info you want
<Kinnison> but it'd be slow
<zyga> checking
<Kinnison> And apparently there's something called inspect.stack
<Kinnison> Sorry I can't be of more use
<zyga> Kinnison: you ave of great use :-) thank you
<Kinnison> zyga: you're welcome
<greenpenguin13> if i just avoid the kernel upgrades for a while will that be ok?
<jbailey> greenpenguin13: Avoid udev upgrades while you're at it.
<greenpenguin13> ta
<jbailey> And probably initramfs-tools and usplash.
<jbailey> In practice, it's working fine for me. =)
<greenpenguin13> it worked except for restricded-modules
<greenpenguin13> but thats fixed
<jbailey> See?  Nothing to phear.
<jbailey> In fact, it's better if you get bugs in to people and run it if you can do so, given that these are essentially the bits that will go into dapper.
<jbailey> So helping them stabilize sooner is good.
<jbailey> It's amazing the number of really obvious bugs that get found near the end of a release just because people didn't try it early.
<greenpenguin13> yeah
<dholbach> good night ubuntueros
<seb128> xhaker: pong
<seb128> dholbach: 'night
<xhaker> seb128: dholback gave me some lights on how to build a real deb package for gtkwifi.. sabdfl was asking for you to help earlier
<seb128> xhaker: I can work with you to get that packaged/uploaded
<seb128> feel free to ask anything
<xhaker> i'm currently trying to write the rules file :) my orig.tar.gz is has some wierd directory structure
<botein> Is somebody here how nows how preeseding works for critical notes?
<slomo> infinity, lamont: please give-back libqalculate on everything except ppc... and qalculate-{kde,gtk} when it built ;)
<Simira> how do I print a page in b/w, without using colours?
<mvo> infinity: can you please have a look at the language-selector build? for some reason it isn't build yet
<hunger> BenC: The -6-686 kernel seems to work properly for me. Thanks for the update!
<BenC> hunger: good deal
<hunger> BenC: Still some minor glitches with udev, but nothing serious.
* hunger goes of trying to get his cdrom up again.
<BenC> my cdrom started working again when I upgraded to latest udev
<BenC> FYI
<hunger> BenC: Mine counts as SCSI (sata), the newest udev is installed but does not help.
<BenC> does it show in dmesg, and can you mount it manually?
<sivang> do I get all the udev / kernel and initramfs upgrads when apt-get upgrading ?
<sivang> (I'm doing that now)
<BenC> apt-get dist-upgrade
<hunger> BenC: I have no device nodes.
<BenC> hunger: dmesg mention it at all?
<sivang> BenC: k, I still have other kernels booting in case it all goes wrong
<hunger> BenC: Dmesg does only show iptables stuff.
<BenC> hunger: what about /var/log/kern.log?
<BenC> thing is, if the kernel doesn't show it, then it's my problem, if it does, then it's udev, so I want to be sure which it is :)
<hunger> BenC: No, it is not listed.
<\sh> ogra: pingeling
<hunger> BenC: There is something about ide0 and 1 having its ports used.
<BenC> hunger: is your cdrom on the same sata as your harddrive?
<hunger> BenC: Dunno... I think not.
<BenC> but this does work in breezy?
<hunger> BenC: This is a laptop... never opened it to check:-)
<hunger> BenC: Oh yes, works fine in breezy.
<BenC> heh, likely it is all connected to the same thing
<hunger> BenC: I think it is not... but I don't know how to make sure.
* sivang of resintalling from cd and then doing dist-upgrades to see what more bugs can be found in that transition
<hunger> BenC: This HW stuff is changing too much, I am only bothering with it when I must.
<BenC> hunger: ok, can you boot to "single", get the output of the following commands: lspci -vv; lspci -vvn; dmesg; 
<BenC> and lsmod
<BenC> and either open a bug report, or email them to kernel-team@lists.ubuntu.com (or both)
<hunger> BenC: The lspci output should be on the wike (thinkpad t43p laptop report).
<hunger> BenC: Without the -vv stuff:-)
<BenC> is there already a bug report on this in regards to dapper?
<BenC> 2.6.15 that is
<hunger> BenC: I'll be right back (gathering data).
<BenC> ok, thanks
<hunger> BenC: Where do you want the bugreport? malone or bugzilla?
<BenC> hell, might as well put it in malone
<hunger> BenC: I mailed the stuff to the list you gave me.
<hunger> BenC: I'll try to submit it to malone as well, but usually I am too stupid to make that do what I want.
<BenC> hunger: thanks again
<BenC> anyone know of a cheap 4-port serial board or USB device?
<BenC> I need a way to attach serial consoles to 4 boxes so I don't have to keep swapping one serial cable around
<BenC> well, one computer acting as a serial console that I remotely use via minicom
<fabbione> BenC: usb to serials are cheap.. 
<fabbione> you could just buy 4 of them and hub them together
<fabbione> it's probably cheaper than to find a 4xrs232
<BenC> true, didn't think about that possibility
<BenC> 4xrs232 PCI cards are probably legacy and hard to find
<fabbione> exactly
<fabbione> i saw usb to serials around
<fabbione> but i don't know how much they cost
<fabbione> they are supported by linux tho
<BenC> wonder if walmart has any :)
<hunger> Oh, just noticed that the udev init script uses find which is not available when the script is run (/usr is not mounted).
<BenC> ah, you have a special case :)
<fabbione> BenC: they probably do :)
<fabbione> hunger: DOH!
<fabbione> actually
<fabbione> hunger: it still works tho
<BenC> they have DB9-to-USB...wonder if they have DB25-to-USB for the hppa and sparc64
<fabbione> i have separate /usr here.. i think
<hunger> fabbione: find is only used to copy devices.
<fabbione> hmm no
<fabbione> BenC: i doubt.. i only saw DB9 on USB
<fabbione> but DB25 -> Db9 are still common around
<BenC> the DB9-to-DB25 are probably more expensive than the USB adapter :)
<hunger> fabbione: It still does copy the files, so no harm done, but why use the find at all if it is not necessary?
<fabbione> BenC: eheh true
<fabbione> hunger:  i don't know that code at all
<hunger> fabbione: Oh, forget that... I am too tired to think right now.
<hunger> Good night!
<fabbione> night
<fabbione> i am off too actually :)
<\sh> hmmm...
<\sh> what is the bzr equivalent to cvs export ?
<\sh> bzr export doesn't work
* trevilor bounces on trulux 
<trevilor> trulux, how is the hardening project going? :o)
<\sh> elmo: why is paramiko not found by pbuilder? http://people.ubuntu.com/~lamont/buildLogs/p/paramiko/1.5.1-0ubuntu1/
<elmo> sh: err, that's not pbuilder, and I'm not lamont or infinity
<\sh> elmo: na.....apt-cache show tells me something else as well..I habe jbaileys bzr snapshot archive and universe enabled...and apt-cache tells me that 1.5-0ubuntu0 is greater then 1.5.1-0ubuntu1...which is IMHO not correct...
<\sh> elmo: that's why I asked you :) because it's already build and available :)
<\sh> (my pbuilder doesn't use jbaileys archive)
<\sh> .oO(and I'm mixing german and english..it means I need some sleep)
<xhaker> 30min powernap
<xhaker> :P
<\sh> xhaker: no..real sleep until 4 utc...:)
<xhaker> anyone know where siretart went?
#ubuntu-devel 2005-12-08
<\sh> or I will mix tomorrow german, english, russian and scottish
<xhaker> \sh, do you have any type of admin access to revu ?
<\sh> xhaker: sure
<xhaker> you know russian?
<spacey> i'm more surpised about scottisch actually :)
<\sh> xhaker: no :) but my colleague is russian :) and his english accent is quite dangerous for non native english speakers :)
<\sh> xhaker: and the other guy is a scottsman :)
<xhaker> \sh, i'm asking you if you have "admin" rights, because of my package.. gtkwifi.. i waited but it doesn't get rejected.. :S and i know the checksums are bad
<\sh> xhaker: looking...
<xhaker> can you somewhat clean in incoming the gtkwifi stuff?
<\sh> xhaker: now try
<\sh> xhaker: source uploads only pls
<\sh> xhaker: debuild -S -sa will do what you want :)
<xhaker> done my friend :P
<xhaker> uploaded
<\sh> xhaker: can u create a non native package pls?
<\sh> with a real orig.tar.gz?
<xhaker> i'm the app developer.. the orig.tar.gz would be the dir usr
<xhaker> or if you really want it that way
<xhaker> tell me how to do it :)
<tseng> make a tarball with just the code
<tseng> and start with that
<azeem> xhaker: unless it is Ubuntu-specific, it is still customizable to have a non-native package
<azeem> s/customizable/customary/
<xhaker> i'm confused
<\sh> xhaker: the easiest thing is to remove debian/ dir from the upstream source, create a new tarball...and dh_make it
<\sh> don't add the debian dir in your source tree
<azeem> if you do not do funky things, you can just mv foo-1.2.3.tar.gz foo_1.2.3.orig.tar.gz
<azeem> where both don't include the debian/ dir
<\sh> upstream sources should never have a debian/ dir
<azeem> ... in a perfect world :)
<\sh> azeem: ... which we don't have 
<\sh> another topic for "ubuntus motu school": "Why upstream sources shouldn't carry debian/ dirs around?" 
<tseng> sh++
<\sh> well...we can carry on with this e.g. "why should upstream developer never write .spec files for rpm source packages"
<tseng> we dont care about that
<tseng> you might.. but its irrelevant to motu school :)
<\sh> tseng: for sure..but the topic is quite "distro independent" 
<xhaker> \sh, no native package uploaded
<\sh> xhaker: cool
<xhaker> ups
<xhaker> this last change broke it
<xhaker> :S
<xhaker> got to fix it
<lllmanulll> Hey there, I'm trying to hack gnome-session, but I'm not sure how I can test hat I'm doing, since I can run only one gnome-session program at once, anybody already found a cunning way ?
<lllmanulll> I'm working on the logout dialog, actually
<minghua> lllmanulll: Xnest?
<lllmanulll> Ah, right :) I just hoped there was something simpler :)
<lllmanulll> Thanks anyway !
<backports-r-us> so is Dapper going to have GCC 4.0 or 4.1?
<backports-r-us> I see 4.1 going to Universe
<Nafallo> 4.0
<backports-r-us> k
<backports-r-us> and has GCC Java speed improved at all?
<backports-r-us> for some reason it's amazingly unresponsive under Breezy
* backports-r-us notices reproducible OOo2 crash :)
<floam> are there any strange issues going on with dependencies? I decided to reinstall dapper, except with the flight 1 install, ended up with edubuntu stuff installed along with some KDE packages that normally don't exist.
<Diablo-D3> floam: kubuntu is a little screwy atm
<Diablo-D3> due to the c++ abi updates
<floam> I'm not on Kubuntu.
<Diablo-D3> s/kubuntu/kde
<floam> It was the regular ubuntu stuff, I wasn't expecting any KDE stuff
<floam> ah
<Diablo-D3> er, oh.
<floam> still, I don't think it should have been installed
<Diablo-D3> if you havent installed kde, then I dont know why you're getting kde apps
<floam> like, I had even amarok an high-level applications
<Diablo-D3> at any rate, installing dapper might not be that good of an idea atm
<floam> yeah, I gather.
<floam> s/an/and/g
<floam> there are wierd other issues going on, so I might need to reinstall breezy and dist-upgrade again
<floam> this isn't my primary machine, so it isn't too huge of a deal. (though even if it were, that would probably not obviate my desire to test it)
<mojo> I just found on Garret's blog that there is a patch for Firefox 1.5 adopt the gtk-icon themes
<mojo> http://cvs.fedora.redhat.com/viewcvs/devel/firefox/firefox-RC1-stock-icons-fe.patch?rev=1.1&view=auto
<mojo> we might consider to patch that up with our Firefox package
<mojo> or should we wait for Mozilla accept that patch?
<Amaranth> I'd say apply it now, wait for upstream later.
<Amaranth> I have a feeling they want to keep sgarrity's theme across all OSes.
<levander> Anybody remember a project that I think was supposed to be done for breezy that was merging the livecd and the install cd so that they were a single cd?
<levander> I'm just trying to remember the name of it so that I can look on the web site and see if they've reported any progress on it.
<Amaranth> ubuntu express
<Amaranth> it's now an official dapper goal, iirc
<Amaranth> so that instead of shipping a live and install cd they can ship an ubuntu and kubuntu cd
<levander> Amaranth: that project is gonna rock is they complete it, i'm sitting here waiting for a stupid livecd to download now so i can copy partitions over, i'm gonna go look up ubuntu express while i'm waiting
<levander> thanks
<sistpoty> elmo: please sync quantlib from unstable, ubuntu override ok. Thx.
<fabbione> morning
<TheMuso> c
<TheMuso> sorry...
<mdke> jdub, the ubuntu-doc-commits list hasn't been working for 24 hours or so, any ideas?
<hunger> Is there anything like the netinst CDs for debian in ubuntu?
<fabbione> yes there is
<fabbione> http://archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/current/images/netboot/
<fabbione> hunger: ^^^
<fabbione> there are also for other arches
<lifeless> hmm
<lifeless> how buggy is hotplug/udev meant to be ? my CF drive has stopped working
<HiddenWolf> lifeless, hotplug was removed a few days ago in favor of udev. it still has issues.
<lifeless> yah
<lifeless> put another way - is this a new one or old one ?
<lifeless> and how do I debug ?
<HiddenWolf> udev is new, but not yet debugged. ask #ubuntu-boot
<ProN00b> can anyone tell me how i can config oom-killer ?
<seb128> slomo_: why do you splitted banshee only for ipod? is there a lot of Depends to get ipod working with it?
<fabbione> hmm
<doko> elmo, Kamion, mdz: please process the locales packages in NEW. getting testsuite failures in various packages due to missing locales ...
<thierry_> seb128 : is there anyway I could push someone to review my patch for bug 5288, because I'd like to do more .desktop files for all the program that have none... but I don't want to waste my time doing wrong things
<thierry_> seb128 : I've packaged the whole thing with the changed and it works great... but just have a more advandced point of view....
<seb128> thierry_: the patch is probably wrong
<thierry_> seb128 : why?
<seb128> thierry_: you should install the desktop file from the install target/before running dh_desktop
<thierry_> seb128 : k, going to change that, anything else?
<seb128> out of this, this kind of bug should really sent upstream/to debian, we don't want to create hundred of package to maintained because we had desktop files
<seb128> you are shooting yourself to the foot by doing this change for Ubuntu only
<thierry_> seb128 : ok, but the space-orbit package is not in the upstream list of ubuntu package (iin malone)
<seb128> thierry_: doesn't prevent to send a patch upstream or to the Debian BTS
<thierry_> seb128 : and how do I send bug to debian? (not familiar at all with debian bug system)
<thierry_> seb128 : how do I send it upstream then?
<seb128> http://www.debian.org/Bugs/Reporting
<seb128> to send a bug to Debian
<seb128> for upstream, figure who upstream is (debian/copyright is an easy way for this) and send them the patch
<seb128> you can as well send it to Debian and let the Debian maintainer forward it if there is no upstream bug tracker
<seb128> usually the maintainer communicate with upstream
<thierry_> seb128 : ok I've sent the fixed patch to the bug
<thierry_> seb128 : and how can I find the debian version of the package??
<thierry_> to report the bug...
<siretart> thierry_: look at the changelog
<siretart> thierry_: it is the last version which is uploaded to 'unstable'
<thierry_> k
<thierry_> thanks
<thierry_> sirestart : have you any idea of what I should change in a changelog of a ubuntu package patch (like for bug 5288) to make patch totally suitable for debian?
<thierry_> siretart
<jsgotangco> hey all
<thierry_> seb128 : even if it's only a packaging patch, do I really need to send it to upstream? I mean, the original upstream source doesn't have any debian directory right?
<slomo_> seb128: because it can be easily split off and with the next release there will be at least njb support which i plan to ship in a separate package too... iriver support is planned also
<seb128> thierry_: the desktop file should be sent upstream
<seb128> thierry_: no reason why upstream can't ship a desktop file
<seb128> slomo_: "easily split" is not a reason to create zillions of binary packages when not required
<seb128> slomo_: what does the ipod stuff trigs?
<seb128> s/trigs/pulls/?
<slomo_> seb128: each of this packages (i.e. ipod, njb, iriver) pulls in 2 libraries... i don't see why someone who doesn't have an (for example) creative nomad need to install libnjb and njb-sharp
<seb128> slomo_: because if every source package ships 15 binary package for every single possible option we are going to have a 10M apt index soon
<tseng> hi seb, slomo
<seb128> hey tseng
<slomo_> seb128: ok... so you would suggest to add support for everything in the banshee package?
<seb128> if ipod support force to install like 150ko of libs I would not split but just force people to install that
<seb128> who care about some ko
<seb128> the number of binary packages has a cost too
<seb128> it's confusing, the index has to list everything, etc
<slomo_> ok, i'll do that with my next upload then... i.e. when i get an updated browser patch
<seb128> but still, it could make sense
<thierry_> seb128 : the patch has been sent upstream and to debian
<seb128> if the ipod stuff force you to install 10M of libs by example
<seb128> that's why I was asking what Depends does it force
<seb128> thierry_: cool, thanks
<slomo_> seb128: the dependencies for each of the packages would be fairly small... i didn't thought about it because i've seen many packages who split of small stuff with small dependencies
<seb128> like?
<seb128> anyway that's my opinion on the topic, other may disagree
<slomo_> muine for example... trayicon plugin splitted off
<tseng> i disagreed with that
<tseng> but look where that got me :)
<seb128> slomo_: doesn't mean they made the right decision :)
<seb128> slomo_: can you active or not the trayicon from muine?
<seb128> that's a good reason to split
<slomo_> no idea, tseng?
<seb128> like we are going to split totem / totem-firefox
<tseng> thats the reason
<tseng> you cant disable plugins
<seb128> because the browser part is crappy and people may want to uninstall it
<tseng> it loads anything in the plugins dir
<seb128> slomo_: but for ipod it doesn't hurt non-ipod users, it just force some ko of Depends
<ProN00b> i wonder, why are you using totem as a default player ?
<seb128> because that's the GNOME player
<seb128> because it's nice
<tseng> feel free to install many others :)
<ProN00b> tseng, you say that if it was easy
<seb128> slomo_: BTW any reason to not hang on #ubuntu-desktop? :)
<tseng> ProN00b: it is.
<seb128> ProN00b: clicking on a package from synaptic is not hard
<ProN00b> as soon as i get a new video format i got to change the open with thingy to my player
<ProN00b> otherwise everything is opened with totem
<seb128> right, it's the default player
<slomo_> seb128: oh, yes ;) i was at my ibook the last days and forget to add it to autojoin at my other machine
<tseng> is -desktop alive now?
<ProN00b> and there is no gui way to choose another default player, and the way to change open with from console is hidden so good i can't find it
<seb128> tseng: the IRC chan is quite active, mostly dholbach/mvo/zyga/mdke speaking during the week though :)
<seb128> ie: not a lot of new people coming
<seb128> ProN00b: right click on a file, properties, open with to change the default for your user
<seb128> ProN00b: edit /etc/gnome/defaults.list and s/totem/<your_player>/ to change for the box
<ProN00b> big thanks for the second info
<ProN00b> but you should consider making a gui app to do that
* zyga feels recognized
<seb128> hey zyga :)
<seb128> zyga: you deserve it with all the work you do ;)
<zyga> nah, I'm just loud ;] 
<seb128> ProN00b: right, an UI would be nice, as always contributions are welcome :)
<ProN00b> if i already changed the defaults, where are the changes ?
<zyga> seb128: how hermetic is gtk+ upstream?
<seb128> "hermetic"?
<tseng> zyga: they dont bite
<zyga> :-)
<tseng> seb128: reclusive and weird
<zyga> how easy it to come in and contribute/disturb something ;)
<seb128> they are nice on IRC and responsive
* zyga likes gtk
<seb128> depending of how you act and what kind of distrubance
<zyga> I'd like to improve memory performance proably
<zyga> I don't like all the string creation/copying that happens in programs all the time (I'm not talking about the libs right now)
<seb128> if you don't speak about the lib you don't care about gtk upstream :)
<seb128> every app has its upstream
<zyga> maybe things meld a little too much in my mind
<zyga> gnome+gtk+gnome+apps
<thierry_> seb128 : when I add a ubuntu bug to debian, do I need to link the ubuntu bug with "link to other bugtracker"?
<tseng> yes
<jsgotangco> hey tseng
<tseng> hi jerome
<seb128> thierry_: better to do it so we can follow what Debian does about the bug
<jsgotangco> tseng: i send my regards to you from seoul: http://www.flickr.com/photos/jsgotangco/69674600/
<jsgotangco> heh
<tseng> silly asians
<tseng> http://www.flickr.com/photos/jsgotangco/69668393/in/photostream/
<jsgotangco> yeah
<jsgotangco> heh
<jsgotangco> :P
<jsgotangco> that mozilla guy was really cool
<thierry_> seb128 : the upstream maintainer of space-orbit package (steve1@genesis.nred.ma.us) , has no valid e-mail and his website (in the copyright file) doesn't exist...
<jsgotangco> tseng: http://www.flickr.com/photos/jsgotangco/69677766/
<seb128> thierry_: don't bother, as said the Debian maintainer can forward and probably knows how to forward patches if there is an active upstream working on the software
<tseng> jsgotangco: game store?
<seb128> thierry_: other way the patch can just be shipped by Debian so we continue to sync from them and don't have extra work
<jsgotangco> tseng: its a convenience store
<jsgotangco> (pretty popular)
<thierry_> seb128 : do you say that the best way to save work would be to make the changes for debian and them wait to sync with them?
<thierry_> then wait*
<seb128> exactly
<seb128> Debian or upstream
<seb128> better to fix that upstream, so everybody get it for free
<seb128> ie: for stuff like GNOME apps put a bug on bugzilla.gnome.org
<thierry_> seb128 : yeah but does .desktop file bug should be added on bugzilla.gnome.org ?
<seb128> for stuff using bugzilla.gnome.org
<seb128> which is not the case for space-orbit
<seb128> but for gnome-system-tools by example yep
<Seveas> Kamion, are you around perhaps?
<mojo> i am just wondering
<mojo> really wondering if the Tab Reorder thing like this http://macromates.com/images/inline/tabs.gif is GTK's lib code or Gedit or propreitary code?
<thierry_> seb128 : so all the bugs I opened about absolute icon path thing about gnome products should also be reported in bugzilla.gnome.org and then link malone to it? 
<seb128> thierry_: correct
<seb128> mojo: you gif is not GTK
<trevilor> hi guys
<mojo> seb128: i know, i am thinking if that feature is not availalbe in GTK SDK yet, then I will suggest 1 or write 1 my own
<mojo> seb128: my screenshot is from TextMate of MacOSX, if GTK Tab can do the same, it'd be nice
<seb128> mojo: what? transparency?
<mojo> seb128: no, tab moving
<mojo> seb128: not transparency
<mojo> seb128: you can reorder the tab, isn't that nice?
<seb128> you can do the same with GTK
<mojo> seb128: check website http://macromates.com/
<seb128> try with epiphany-browser
<mojo> seb128: really?
<mojo> seb128: let me see epihpany
<mojo> seb128: cool, my mistake, it's not in Gedit yet, i will suggest this with gedit team
<azeem> you cannot with gnome-terminal
<azeem> would be nice if that was a general feature
<mojo> azeem: some ppl hate gnome-terminal with tab-close and tab-reorder
<azeem> mojo: hate?
<mojo> ofcoz, it'd be nice if it's general code
<HiddenWolf> I'd rather see gnome-terminal trimmed down. rather than bloated more. :)
<azeem> HiddenWolf: let's assume this would be general GTK code
<mojo> azeem: yes, hate, for example : let see... dobey from Novell, Tango project, very good coder
<HiddenWolf> mojo, he wouldn't have to use it. :)
<azeem> mojo: so he hates tab-reorder for gnome-terminal but not epiphany?
<mojo> HiddenWolf: i know, I told him, if he doesn't like it, feel free to use alternative, but that guy is also main coder of gnome-terminal
<azeem> mojo: or is that the reason why hacks on that gtkhtml browser? (that's him, no?)
<mojo> azeem: thats him!! the guy with gtkhtml patch for icon
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=73240
<azeem> seb128: thanks
<seb128> np
<mdke> anyone know why the ubuntu-doc-commits mailing list isn't working?
<mdke> afaics, the breezy-changes list is down too (or maybe just the archive?)
<mdke> Znarl, elmo ? ^^
<mdke> assuming you guys work weekends :)
* mdke tries to remove restricted and multiverse but finds that he can't without removing linux-386 and openoffice :(
<mdke> that's a shame
<mdke> oh no my bad
<squirrelpimp> hi developers...
<zyga> hi
<squirrelpimp> can i annoy you with an obvious bug?
<zyga> squirrelpimp: bugzilla/malone is the one to bug
<squirrelpimp> i knew one would say that...
<squirrelpimp> it's related to libpam-ssh and gdm and hotplug. any hearings about those during the last time...
<zyga> sorry I'm more -desktop kind of person
<LaserJock> squirrelpimp: is that on Breezy?
<squirrelpimp> yo...
<squirrelpimp> it is...
<squirrelpimp> LaserJock: i added libpam-ssh support to pam.d/gdm to get my key loaded at login and not hotplugging of usb-disks stopped working..
<squirrelpimp> also the default system language changed...
<HiddenWolf> squirrelpimp, file bugs
<LaserJock> well, I don't I can't really help you. I was just going to say that in Dapper hotplug has been removed. I would really check bugzilla.ubuntu.com or launchpad.net/malone/ 
<squirrelpimp> are those the same? I only know bugzilla...
<LaserJock> squirrelpimp: they are not the same
<squirrelpimp> then why two??
<LaserJock> bugzilla will be replaced by malone eventually but for now you probably want to try both
<squirrelpimp> pam is so bad... i think the developer had sasl in mind when doing it...
<squirrelpimp> after logging in a /etc/init.d/hotplug restart solves it...
<squirrelpimp> but that's a bug anyways...
<squirrelpimp> i'll file one.....
<nico8481> hello
<desrt> good morning
<nico8481> morning? where do you live? :) 8:30PM here (BE)
<desrt> 2:30PM here.  i am not overly concerned.
<ajmitch> morning
<nico8481> i'd like to buy a laptop and install ubuntu on it, any idea which ones are the best supported (hp? apple?)
<neuralis> nico8481: that's a question for #ubuntu, but see https://wiki.ubuntu.com/LaptopTestingTeam
<nico8481> ah... saw this channel on the "ubuntu laptop team" webpage but well... on my way to #ubuntu then...
<ploum> Hi
<ploum> I thinking about writing a spec proposal about window's buttons in metacity
<ploum> http://bugzilla.ubuntu.com/show_bug.cgi?id=13305
<ploum> Can anyone write a spec ?
<HiddenWolf> ploum, best take that upstream.
<ploum> HiddenWolf, why upstream ? It's just about the theme 
<ploum> ( HiddenWolf : nog jij ;-) )
<HiddenWolf> ploum, hm, you can make a spec anyway, but chances are greater if you raise the issue upstream. There has been some focus on accesibility on the gnome-devel list.
<ploum> HiddenWolf, I will talk about it upstream
<ploum> HiddenWolf, by the way, how can I make a spec ?
<HiddenWolf> ploum, write a wiki page using the spectemplate, then register it on the specs component of launchpad, and lobby to have it reviewed and approved.
<ploum> ah !
<ploum> thx :-)
<HiddenWolf> just take a look at the others to see what's required.
<ploum> I just discovered the SpecSpec page :-)
<Kamion> remember that the main reason the core development team writes up specifications is in order to coordinate resourcing of those of us who're paid to work on Ubuntu
<Kamion> you're not obliged to have a spec in order to get something done, although the process of writing one up may certainly help you to gather your thoughts
<tseng> jdub: http://primates.ximian.com/~jimmac/product-design/desktop/desktop-applets-search.png < Holmes mock up reveals pantsless jdub, news at 11
<HiddenWolf> tseng, that is one sweet theme
<tseng> its a mockup
<HiddenWolf> sweet none the less.
<HiddenWolf> Altho I'd kill anyone who dared touching my top menu. :)
<tseng> most of the stuff in that directory is a mix of "notifications done right" "osx goodies" and "gnome3 ideas"
<HiddenWolf> *chuckle*
<HiddenWolf> Well, start coding already. ;)
<ploum> I wrote this first draft :
<ploum> https://wiki.ubuntu.com/MetacityDefaultTheme
<ploum> Kamion, can you tell me if it can be a spec. If not , I will simply delete this page
<Tm_T> "Two very different buttons are just next the other : maximise, wich only has a minor impact on your work and" ...and ?
<Tm_T> ;)
<ploum> oops ;-)
<Tm_T> but seems good to me
<Kamion> ploum: it can be, it does not have to be
<Kamion> that's all
<ploum> Kamion, ok. It's just it will maybe help to discuss it as a spec.
<ploum> The bug in bugzilla has no support at all
<ploum> I even tried to talk about it on the desktop list
<ploum> nobody seems to bother
<ploum> (and as I often work with people with disabilities or with old people, I find it important enough)
<ploum> (at least to discuss)
<ploum> but now, how can I register it as a spec on Launchpad ?
<Kamion> I'd recommend leaving it just on the wiki for the moment
<Kamion> the launchpad spec tracker is still not entirely suitable for wiki-mode additions except during conferences, imho
<ploum> Kamion, ok, no problem
<ploum> thanks for your help
<ploum> (and sorry for being a bit "intrusive")
<ploum> Have a nice day everyone
* ploum is going to sleep
<Aegir> Hmm. My applications menu is absolutly forked.
<Aegir> Giving me a chance to learn to love the deskbar applet, however :D
<HiddenWolf> Kamion, any idea when we'll be rid of bugzilla?
<Kamion> HiddenWolf: no
<Kamion> ("soon" is the official answer I suspect)
<HiddenWolf> Kamion, any idea then what's the holdup?
<Kamion> I don't; I've had almost no involvement with that project, sorry
<HiddenWolf> ok, cool.
#ubuntu-devel 2005-12-09
<Nafallo> mdke: ping
<Nafallo> Seveas: ping
<Nafallo> jdub: ping
<Seveas> Nafallo, ICMP ECHO REPLY
<Diablo-D3> lol
<Nafallo> hi! do you have a license for the dutch forumtheme ubuntu-se want's to use? :-)
<Seveas> Nafallo, hehe, it's a rip-off of ubuntu.com combined with a standard punbb theme
<Seveas> I can tar it up for you if you want, but it's not too pretty 
<Diablo-D3> lol
<Diablo-D3> go Seveas 
<Seveas> (You also should disable all other themes, since they sometimes don't integrate well)
<Nafallo> infact, I think ozamosi already stolen it ;-)
<Seveas> (and the poll crud is a recent addition that is Uber crap css-wise)
<Diablo-D3> Hrm.
<Seveas> Nafallo, :)
<Seveas> URL?
* Diablo-D3 is trying not to buy a mac atm
<Nafallo> http://ubuntu-se.org/forum IIRC. right ozamosi? :-)
* HiddenWolf takes all Diablo-D3's money, and buys a mac for himself
<Diablo-D3> not thatI have the money, mind you, but the whole osx experience is.... is....alluring
<ozamosi> Nafallo: jupp
<Seveas> Nafallo, looks like it, just without the right bar :)
<Diablo-D3> a computer... that works perfectly.... out of the box
<Diablo-D3> no tweaking, no having to isntall linux
<ozamosi> Seveas: I removed it, since I didn't have anything to write in it
<Nafallo> hehe, so the work has no license then? :-P
<Diablo-D3> so, guys
<Diablo-D3> when can I start buying boxen with ubuntu preinstalled?
<Seveas> Nafallo, the license for the bits I created is "Do whatever you want and don't blame me when it breaks" :)
<unkn0wn2u> why in the hell does linux in all its beauty still persistantly try dns servers in order in /etc/resolve ? if the server on the top is down it takes extra time to try the next one 
<Diablo-D3> unkn0wn2u: well
<Diablo-D3> this is sorta why I like dnsmasq
<Diablo-D3> atleast then I can cache results easily
<Diablo-D3> but yeah, I agree, it should be randomly
<Nafallo> Seveas: that's what I thought ;-)
* Nafallo totally blames ozamosi :-P
* Diablo-D3 even runs dnsmasq on his openwrt <3
<unkn0wn2u> Diablo-D3, I don't think random   I think whatever one is the fastest 
<Diablo-D3> unkn0wn2u: but you cant know which one is fastest
<unkn0wn2u> Diablo-D3, do a ping and the lowest time
<Diablo-D3> unkn0wn2u: except that wastes time
<Diablo-D3> unkn0wn2u: the time it takes to get a ping done, I could have the dns request completed
<unkn0wn2u> not if you only do it once when a dns server dies on you
<Diablo-D3> I think it should be random
<unkn0wn2u> Diablo-D3, what if 2 of 3 are down
<Nafallo> Seveas: what do you think about the ubuntu.com parts? jdub as the person to talk to and they love if we use it under whatever copyright? :-P
<Seveas> Nafallo, back when I started with the dutch site, I talked to a canonical person, don't remember who, but I got permission to use it
<Seveas> at least unofficially
<Diablo-D3> unkn0wn2u: okay, lets say it randomly hits one, and that one is down...
<Nafallo> hmm, oki. should be hno73's work I think?
<Diablo-D3> unkn0wn2u: then it randomly hits one of the other two.... and that one is down...
<Diablo-D3> unkn0wn2u: then it just randomly hits the last one. ;)
<Seveas> Nafallo, please keep me posted on this :)
<Nafallo> Seveas: I will :-)
<Seveas> ta
<Diablo-D3> unkn0wn2u: however, theres a problem
<Diablo-D3> unkn0wn2u: apps dont keep hitting dns servers
<Diablo-D3> when dns times out, they just go on, instead of hitting the other servers
<Diablo-D3> which imo is a bug in itself
<unkn0wn2u> Diablo-D3, if it was random it could hit the first one twice the second one then the first one again then the final one , if it was random
<Diablo-D3> unkn0wn2u: theres an implication that dead servers get removed
<unkn0wn2u> thats good
<unkn0wn2u> that is all i want
<Diablo-D3> of course, as I said, apps dont hit the rest of the servers
<Diablo-D3> I wish someone would hack glibc's resolver to hit other servers until it resolves
<Diablo-D3> I mean, the way dns works is kinda retarded
<unkn0wn2u> yep
<Diablo-D3> a) we allow multiple ips per a record, but apps dont randomly choose what ip to use
<Diablo-D3> b) we allow multiple dns servers to resolve from, but apps dont automatically fall back
<Diablo-D3> atleast, if they do fall back, I've never seen useful behavior come out of that
<unkn0wn2u> all i know is that my isp's primary dns server crashes all the time and sometimes so does its secondary so I have to edit /etc/resolve.conf to speed things up when one goes down
<Diablo-D3> unkn0wn2u: so apps are hitting the 2nd dns server eventually?
<unkn0wn2u> yes
<Diablo-D3> ignore what I said in b then
<unkn0wn2u> just takes a couple of seconds
<Diablo-D3> they do fall back
<Diablo-D3> but yeah, if this was atleast randomly chosen, it'd a) make load balancing implicit in the design, b) a bit saner
<unkn0wn2u> try it for yourself put two fake dns entries into resolv.conf and it takes much more time to get to where you want to go
<unkn0wn2u> Diablo-D3, I agree with that
* Diablo-D3 adds that to his list of mistakes that shouldnt be repeated
<Diablo-D3> I should add a regular running feature on my blog
<Diablo-D3> "Diablo's List Of Bad Ideas" or something
<mdke> Nafallo, pong
<Nafallo> mdke: hi! do your moinmoin wikitheme has a license? :-)
<mdke> Nafallo, go ahead and help yourself. except the "ubuntu-it" header of course :D
<Nafallo> thanx :-)
<Nafallo> public domain or copyleft then :-)
<TheMuso> Hi all. I have recently reported a bug, which I now have a fix for. However, the fix involved editing the configure.in of the package the bug was reported against. The package build doesn't generate the configure script every time it gets built, so what should my patch contain, as well as adding build deps, etc?
<djk_> doko_: hi, why does the OOo package not include DicOOo and why does it not use the standard OOo buttons?
<infinity> TheMuso : If you don't want to completely mess with the package to regenrate configure (which I wouldn't bother with), your patch should include the patch to configure.in, a patch to configure, and a hunk in debian/rules that touches each configure-related file in the right order to make sure they don't get re-genrated on build.
<minghua> TheMuso: I'm not an expert on this, but I've seen the general way to deal with this is to re-auto* the package, and provide a patch to configure as well
<minghua> infinity: is there any doc on how to get the timestamps right?
<infinity> TheMuso : Read /usr/share/doc/autotools-dev/README.Debian.gz for info on timestamps.
<minghua> infinity: ah ok, I've read that file, but I must have missed the timestamp part
<infinity> TheMuso : (adjust as appropriate, if the package has more auto* stuff than is mentioned in the timestam pskew example)
<infinity> minghua : "The problem with time-stamp skews and Debian source packages:"
<TheMuso> infinity: Thank you.
<Diablo-D3> hum
<Diablo-D3> does anyone have problems with 0.5.5.1-1ubuntu2 starting?
<Nafallo> Diablo-D3: we are currently developing 6.04. what's 0.5.5.1?
<Diablo-D3> er
<Diablo-D3> somewhere in there the word "hal" dissapeared
<Nafallo> :-)
<Nafallo> I don't think so, but I haven't checked it either :-)
* Nafallo thinks he should have noticed :-P
<Diablo-D3> it stops hal, it stops udev, it starts udev, and it just stops at trying to start hal
<TheMuso> infinity: What approach should I take if the package uses cdbs?
<infinity> TheMuso : Cry.
<minghua> infinity: thanks, and reading.  I use dpatch though, and I've not seen such time-stamp skew yet, I wonder if you know dpatch is immuned?
<infinity> TheMuso : Some double-colon target (like "clean::" maybe?) would likely be the right place to put it with cdbs.
<infinity> minghua : Nothing is immune, but you could be patching in such a way as to make yourself immune by accident. :)
<Diablo-D3> lol
<Diablo-D3> it catches itself
<infinity> minghua : ie: if you always patch .in before configure, etc.
<Diablo-D3>  * Starting Hardware abstraction layer:                                         
<Diablo-D3> a minute later
<TheMuso> infinity: Thanks again. Will see how I go.
<Diablo-D3> run-parts: /etc/dbus-1/event.d/20hal exited with return code 2
<Diablo-D3> invoke-rc.d: initscript dbus, action "force-reload" failed.
<Diablo-D3>  * Starting Hardware abstraction layer:
* minghua has been patching Makefiles.am and Makefiles.in without adding protection measures for quite some time
<minghua> infinity: :-(  I'll read that doc carefully again, and fix my packages
<infinity> minghua : Do you ever get failures on slower arches (m68k, arm, mipsel) that you can't really explain? :)
<infinity> minghua : They are far more likely to smack into timestamp skew issues (though I see it in the Ubuntu DC buildds too)
<minghua> infinity: no, not yet, even though I put both patches of Makefile.am and Makefile.in in one .dpatch file
<infinity> minghua : Could be pure luck with the order of the patch file. :)
<infinity> minghua : Err, wait.  You're not patching configure directly, though?
<infinity> minghua : If you're re-running autogen.sh (or whatever) in your build, then you're immune by definition.
<minghua> infinity: no, not configure.  Just Makefile.* stuff
<minghua> infinity: but no, not re-bootstrapping either
<Diablo-D3> hrm
<infinity> minghua : Oh, okay.  Check.
<Diablo-D3> I wish realtime-lsm came with the kernel by default
<infinity> minghua : Then yeah, .am should be patched/touched before .in, unless you're in AM_MAINTAINER_MODE, then it won't even try to re-generate.
<minghua> infinity: as you said, maybe just pure luck.  better not depend on luck too much, I suppose :-)
<Diablo-D3> anyone wanna comment on that?
<mdke> mjg59, awesome usplash
<mjg59> mdke: Haha
<mdke> you own design?
<mdke> r
<mdke> mm kernel works too
<mdke> rocking
<wasabi> Slashdot: (#14175758)
<wasabi> I'm deeply suspicious of a so-called "educational" distribution put together by people who can't seem to spell "calendar" correctly [edubuntu.org] .
<wasabi> Somebody might want to fix that. ;)
<tseng> you know in the netiquite rfc it has an item about not posting soley to make fun of someones spelling mistake
* Diablo-D3 boots 2.6.15-6
<tseng> it was a pretty key item
<wasabi> I'm just pasting a /. posting that happened, despite it's sarcasm, point out a legitimate spelling mistake.
<Diablo-D3> I still get a kick out of the ubuntu dapper ksplash
<wasabi> I should have paraphrased I suspose.
<Diablo-D3> er usplash
<Diablo-D3> 2.6.15-6 seems to boot fine, btw
<theCore> guys, what do you recommend for installing packages ? aptitude or apt-get ?
<wasabi> Try both, you decide.
<theCore> wasabi: it for the PackagingGuide
<theCore> i want to know what we should recommend to the readers
<infinity> From the name, I'd assume "PackagingGuide" is aimed at people who are building software?
<LaserJock> infinity: correct
<infinity> If so, you should assume they know how to install software. :)
<infinity> "Install build-essential" is fine, you don't need "apt-get install build-essential"
<minghua> good point :-)
<infinity> They can use apt, aptitude, dselect, synaptic, or download the debs by hand if they want.
<LaserJock> but it is more than buil-essential that we are recommending
<infinity> LaserJock : Doesn't matter.  The point is that you should recommend packages to install, not HOW to install them.
<mdke> +1
<infinity> If your target audience is so far down the learning curve that they don't know how to install software, they're not ready to be building it yet, and should be reading an entirely differnt set of docs.
<theCore> infinity: good point
<LaserJock> infinity: true I just wanted to have a one liner because we list lots of packages but you don't necessary have to install all of them because of deps, etc.
<mdke> yeah they can start reading something else
<wasabi> I probably wouldn't recommend a packager to install anything except build-essential, though. Seems to me the best package results from packagers tracing down the dependencies for the piece of software when they're needed.
<minghua> LaserJock: what about "install foo, bar, baz and their dependencies"?
<LaserJock> but maybe the solution is to do as infinity suggests and just take that out 
<LaserJock> minghua: right 
<LaserJock> wasabi: well, we are going to use examples so we need to at least put the programs that are going to be used in the examples
<theCore> LaserJock, maybe but having the whole command near is convenient
<infinity> And yeah, recommending that people install much more than build-essential and devsctips is just asking for trouble down the road with missing build-deps.
<minghua> LaserJock: then you should use apt-get build-deps
<infinity> devscripts, too.
<wasabi> Btw, I think it's awesome that you're writing this.
<LaserJock> right, here is the list as of now : build-essential dh-make automake pbuilder gnupg lintian dchroot debian-policy debian-reference
<wasabi> When I was learning packaging, there wasn't any good resource other than the debian dev/policy and existing packages. ;)
<infinity> theCore / LaserJock : If this is including walktrhgoh examples, I guess this is meant as a replacement for Debian New Maintainer's Guide?
<LaserJock> infinity: sort of
<LaserJock> infinity: maybe a little easier
* infinity found the NM Guide pretty easy...
<LaserJock> infinity: put not everybody does I guess
<LaserJock> s/put/but/
<minghua> If you are remaking/improving NM guide, would you please de-emphasis the dh_make approach and add more details about hand-crafting the debian/rules?
<minghua> dh_make really generates bad debian/rules except for the most basic package
<infinity> I'm of two minds about that.
<LaserJock> minghua: yeah, I hope to get a lot out of #ubuntu-motu-school
<infinity> dh_make is a good place to start to see what is available to you, via debhelper, etc.
<infinity> If you're doing complex packaging, one assumes you've already done some basic packaging and know what tricks you can dna can't pull.
<infinity> And that's certainly out of the scope of a beginner's guide to packaging.
<minghua> infinity: very ture
<minghua> s/ture/true/
<LaserJock> well I wanted to have different packaging scenarios that would illustrate when it is appropriate to use things like dh_make and cdbs etc.
<infinity> (I wouldn't expect a beginner to come up with the crazy debian/rules2 in gcc, for instance)
<minghua> infinity: I had always been hoping there would be an "Advanced Maintainers' Guide" :-)
<infinity> I suppose someone could write one, but Make is pretty flexible if you mangle it just right, so an "Advanced Maintainer's Guide" could be a single line saying "do whatever you have to do to make it work, HTH, HAND"
<minghua> the reality is that most currently (interesting) non-packaged software are more than "basic"
<LaserJock> minghua: well this could include more advanced topics eventually
<theCore> LaserJock: that would make a great guide
<infinity> Yeah, but if you run through and example of ground-up packaging of "Hello World", then go look at the source for complex packages, you can make the logical leaps from "simple" to "complex" yourself.  Probably.
<minghua> Is this PackagingGuide online somewhere right now?
<LaserJock> doc.ubuntu.com
<theCore> yes, http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html
<minghua> thanks, both of you
<minghua> Hmm, where should I report typos for this packaging guide?  #ubuntu-doc?
<LaserJock> minghua: 
<LaserJock> yeah
<crimsun> elmo: please sync omniorb4 from Sid (overriding Ubuntu changes), thanks
<pepsi> is the replacement of hotplug by the new udev package intentional? im hesitant to allow hotplug to be removed
<minghua> pepsi: http://lists.ubuntu.com/archives/ubuntu-devel-announce/2005-December/000028.html
<pepsi> i see
<pepsi> i should probably subscribe to that, eh?
<minghua> pepsi: and you should subscribe to that list if you uses dapper
<minghua> exactly :-)
<pepsi> yay.. that was exactly what i was looking for.. now i dont have to get yelled at for asking about dapper in #ubuntu ;)
<minghua> oh?  people yell at you for asking questions about dapper on #ubuntu?
<minghua> that's unfortunate
<pepsi> well
<pepsi> usually something like "DONT USE DAPPER" or somesuch ;)
<minghua> well, that's more or less true, though
<pepsi> and i understand that having people asking for help with an unfinished release only adds to the overwhelming number of questions asked
<pepsi> but its silly to just tell people already using it to not use it ;)
<minghua> pepsi: yes.  if you don't intend to help testing, I think you should wait until the preview release
<pepsi> perhaps if the mailing lists were pointed out.. i just assumed they were more about "hey billl... theres a bug in x-package.. could you chceck it out?"
<pepsi> i spent a few hours figuring out why gnome-app-install kept crashing :P
<pepsi> tis firefox's fault
<pepsi> but i tracked it to the exact function
<pepsi> but then i never filed a bug report :D
<poningru> I had a question, why do we not use the driver binaries that the manufacturer gives us permission to distribute? in restricted ofcourse
<infinity> poningru : For example?... We do use some (nvidia and ati come to mind)
<infinity> poningru : s/use/ship/, we don't install them by default (because we can't really support them)
<poningru> right
<poningru> for example the wireless drivers
<infinity> Like the atheros drivers we ship?
<poningru> there was some rumors that couple of chipset devs would allow drivers to be shipped
<poningru> but arent those open?
<infinity> Not precisely, no.
<poningru> oh
<infinity> The ath_hal portion of them is very not open, and that's why its in restricted.
<poningru> hmm ic
<infinity> Are there actually drivers we COULD distribute that we a) don't have a working alternative for and b) aren't distributing?
<infinity> And if you're going to suggest distributing the Win32 drivers for use with ndiswrapper, no, we don't have a license to do that, rumours notwithstanding.
<poningru> ah gotcha
<infinity> "Manufacturers would look the other way and pretend not to notice" isn't the same as "we can legally distribute them".
<poningru> so if we were to 'lobby' the manufacturer to allow redistribution...
<poningru> we == customers
<infinity> If customers managed to lobby manufacturers to allow (in writing) redistribution of certain drivers known to work with ndiswrapper, there'd be no difference between us distributing that and us distributing closed firmware and ath_hal, IMO.
<infinity> That doesn't mean we WOULD, but there's be a better chance of talking us into it.
<poningru> but there is something that I found in the (b) category btw
<poningru> http://rt2x00.serialmonkey.com/wiki/index.php/Downloads
<poningru> http://www.sourceforge.net/projects/rt2400
<poningru> err
<poningru> http://prdownloads.sourceforge.net/rt2400/rt2500-1.1.0-b3.tar.gz?download
<infinity> We have the rt2x00 drivers in our default kernel builds.
<poningru> oh we do?
<poningru> hmm guess I better take this to the user support channel then
<poningru> cause mine isnt working
<infinity> $ modinfo rt2400
<poningru> and lots of people's arent working
<dilinger> noooooooooo
<dilinger> dilinger@sticky:~$ gtetrinet
<dilinger> *** glibc detected *** double free or corruption (fasttop): 0x080de710 ***
* dilinger cries
<poningru> https://wiki.ubuntu.com/Rt2500WirelessCardsHowTo
<Lathiat> haha dilinger 
* poningru tries that command
<poningru> oh hmm ok it does exist
<infinity> poningru : The very top of that wiki page notes that Breezy supports rt2x00 out of the box.
<poningru> ok thanks this was mistake on my part
<poningru> sorry about that
<poningru> wasting your time and all
<infinity> poningru : If "lsmod | grep rt2" doesn't show it having a driver loaded for your card, your problem is in udev (in dapper) or hotplug (in breezy)
<poningru> no the driver is loaded its just not connecting
<infinity> poningru : If the right driver IS loaded, but you have no interface, or the interface doesn't work, file a bug on the kernel.
<poningru> its most likely something I did wrong
<poningru> but I will file a bug if its something wrong with the interface
<poningru> once again thanks dude
<pepsi> what is bazaar?
<poningru> https://launchpad.net/products/bazaar
<pepsi> ok
<poningru> basically cvs but with more upstream/downstream controls and more friendliness in general
<poningru> well I guess the second portion is debatable for some people
<pepsi> but its a version control thang
<pepsi> its what ubuntu uses i guess
<Diablo-D3> magnet:?xt=urn:btih:DES4INMGPQINDVOUGOQPQP4QWZXJXDCW
<Diablo-D3> oops wrong window
<Diablo-D3> thats a music torrent if anyone cares, btw
<zakame> hello
<zakame> is daniels around?
<infinity> Nope.
<zakame> waah... I'd just like to ask if gccmakedep's really gone in dapper
<zakame> as MAS seems to need it (from xutils) to build
<infinity> Why does it need it?... Can you replicate the behaviour with "gcc -M"/
<infinity> ?
<zakame> I just did that, but I wasn't sure if that's the way to go, so I was asking :)
<zakame> I asked earlier at -motu, siretart was unsure too
<zakame> with DEPEND="gcc -M" MAS built ok :)
<zakame> thanks :)
<jsgotangco> hey guys
<zyga> morning
<djk_> doko: hi, why does the OOo package not include DicOOo and why does it not use the standard OOo buttons?
<\sh> elmo: please sync pgadmin3 from unstable, dropping ubuntu changes
<\sh> elmo: thx
<mjg59> jdub: I'd already got in touch with them
<zyga> \sh: hi do you have ro accecss to archive.ubuntu.com?
<\sh> zyga: via web? yes
<zyga> \sh: fast?
<\sh> zyga: yes
<zyga> \sh: is there any way you could mount it for unix tools to work?
<zyga> \sh: I need to run three scripts on all the debs
<\sh> zyga: hmmm? ro access i have via http..i don't have any direct access...this is elmo who has the power to do everything 
<zyga> ah, ok
<zyga> elmo: :)
<poningru> can someone update this page please?
<poningru> why not link it to the new faq?
<poningru> http://www.ubuntulinux.org/support/documentation/faq/faqfolder_view
<pkern> zyga: Isn't it possible with fuse anyhow?
<pkern> zyga: But perhaps this requires WebDAV for the listing, don't know.
<\sh> pkern: hi..any news about gobby 0.3.x?
<pkern> \sh: We've got a weird encoding bug to fix before we could release Gobby 0.3.0... Sadly enough. |:
<pkern> \sh: That's the only thing left, but it doesn't happen with Linux<->Linux but with other combinations.
<pkern> \sh: I can't build debs earlier because 0.3.0rc3 > 0.3.0 if you ask dpkg ;)
<pkern> \sh: Lame excuse, I know that it would be possible anyway. ;)
<\sh> pkern: no problem :) ogra is just waiting for it for edubuntu :)
<pkern> \sh: Deadline? ;)
<siretart> yesterday *fg*
<\sh> pkern: 19th jan
<pkern> \sh: Easy enough. :P
<\sh> well..I have to say, yesterday at the essener linuxtage a lot of people were interested in edubuntu. the workshop was quite fillled up with people...and during ogras talk many people were listening...so there is a market for edubuntu :)
<pkern> \sh: Guess what I am running on the desktop. ;)
<pkern> \sh: Edubuntu rocks and the artwork is cool, too. :P
<\sh> pkern: gerntoo? ,-)
<pkern> \sh: Edubuntu (: I am so tired of Gentoo... Forget to update for a month and you're screwed.
<\sh> pkern: hehe..I know what you mean...
<\sh> but I heard just now, that suddenly 100 ubuntu cds reached the gentoo booth in essen :)
<pkern> As long the 100 ubuntu cds don't reach the Debian booth... *fg*
<pkern> I'm still distributing all those Ubuntu Breezy copies besides me among our teachers.
<pkern> It's just that the German translation on the Live CD isn't that great. At least the buttons in the panel remain untranslated.
<\sh> pkern: hmm...I just bought a debian shirt...it's x-mas time :)
<pkern> \sh: I bought one in Karlsruhe some months ago. :P
<pkern> \sh: But well, I am associated anyway. ;)
<\sh> pkern: *g* ] 
<pkern> If Ubuntu (as in Linux) wouldn't screw my laptop's harddisk drive I would use it more... But like this I stick to enhance the DarwinPorts in OpenDarwin a bit... *cough*
<\sh> hmmm...bugzille no.?
<\sh> :)
<pkern> \sh: It doesn't really matter where I would file it...
<pkern> \sh: Paul van Tilburg's blog is down at the moment. ):
<pkern> \sh: So I can't link you to the problem
<pkern> \sh: Last time I filed a bugzilla bug I never saw a solution... And I wasn't able to finger it out, too. (xfs as root)
<\sh> pkern: next time then :)
<djk_> when's the best time to talk to doko?
<\sh> djk_: when he is at work? so between monday and friday :)
<\sh> or email him :)
<pkern> Anyone using RSS reading in Thunderbird? ;)
<\sh> i don't use thunderbird at all
<pkern> I just try to convert myself to it... But the RSS reader seems stupid.
<pkern> Time for a RSS to mail interface
<\sh> pkern: there is one
<djk_> \sh: well, yes, i meant in here ;)
<\sh> pkern: http://www.aaronsw.com/2002/rss2email/
<pkern> Surely it was packaged by Joey... ha
<pkern> Thanks (:
<sivang> pkern: this is surely somethign related to some specific combination of hardware
<pkern> sivang: Well, it parks the HD heads several times per minute.
<sivang> pkern: ah,. well I was use experiencing data loss, I am not sure if it was due to parking heads
<pkern> sivang: The harddisk gets too many of those and then refuses to read sectors.
<pkern> sivang: I had two replaces already.
<zyga> pkern: I could just rsync but that's 50GB away :)
<pkern> zyga: Isn't there a development machine with a mirror of it available?
<pkern> Like merkel in Debian ;)
<zyga> pkern: not for me 
<pkern> k
* stockholm looks for sabdfl
<ogra> hey stockholm 
<stockholm> ogra: hi!
<stockholm> ogra: how are things?
<stockholm> ogra: are you aware of the schoolserver meeting in nrnberg?
<ogra> fine :)
<ogra> when ? 
<stockholm> dec 17
<ogra> hmm, nope, wasnt aware ...
<ogra> but i met your colleagues yesterday at linuxtag in essen
<stockholm> i am not sure how one gets invited.
<stockholm> who was that?
<stockholm> the skolelinux gang?
<ogra> they invited me to your test center in guetersloh
<stockholm> i never saw them in action
<ogra> oh, lots of people hving a booth there ...
<stockholm> that is their standard move. they invite everyone (c:
<ogra> hehe
<\sh> in guetersloh?
<ogra> i'll visit if i have time ...
<stockholm> cool.
<stockholm> there is a meeting in januar, too
<stockholm> near aachen
<stockholm> when is mark online normaly?
<\sh> next to the evil place of the bertelsmann cd printing company? ,)
<ogra> i'm very busy until end of feb ... but aachen mightbe possible (only 80km)
<stockholm> i want to know how hard it is (and rewarding) to live in southafrica (c:
<stockholm> \sh: i dont know about that. what was the deal with that?
<pkern> \sh: CTCP LOCATION
<Kamion> stockholm: UK working hours would be a better bet than Sunday :-) However he's been travelling a fair bit, so if I were you I'd try e-mail
<stockholm> ogra: why are you so busy?
<ogra> stockholm, finishing the next edubuntu before feture freeze ;)
<\sh> stockholm: well..I worked in guetersloh...for mr. mohn junior :) next to sonopress :)
<ogra> *feature
<stockholm> Kamion: do you think he would have time to answer *those* kind of questions in email? (c:
<\sh> pkern: hehe :)
<Kamion> stockholm: no idea
<pkern> \sh: That's not a valid response ;)
<stockholm> ogra: ah, i understand.
<\sh> pkern: kerpen :) rhein-erft, NRW :)
<pkern> \sh: NRW! kk (:
<stockholm> ogra: then you might be too busy for the nrnberg meeting, too.
<pkern> \sh: So you're having snow up there? ;)
<ogra> likely ...
<ogra> hey pkern 
<\sh> pkern: next to michael schumachers cart racing 
<ogra> nice to see you here :)
<pkern> Hey ogra (:
<stockholm> arg, i am needed downstairs
<\sh> pkern: well...to be honest, i didn't have a look out of my window for today..but I don't think so
<stockholm> see you around.
<Kamion>  Source and binary demotions to universe
<Kamion>  ---------------------------------------
<Kamion>  o readline4: libreadline4
<Kamion> SCORE
<ogra> heh
<pkern> ogra: I heard Jan 19th as a deadline...
<ogra> thats upstream version freeze
<pkern> ogra: Fine.
<\sh> ogra: latest date for including gobby :)
<ogra> getting all new features into ltsp is my main work currently ...
<ogra> so feature freeze is more important to me :)
<\sh> ogra: grr...I wanted to push pkern a bit :)
<pkern> ogra: When is feature freeze? (:
<ogra> end of feb ...
<pkern> Fine.
<Kamion> http://wiki.ubuntu.com/DapperReleaseSchedule
<pkern> ogra: And please keep up the good work. I even use Edubuntu as my favourite desktop distribution (=
<ogra> YAY !!!!
<ogra> thast cool to hear :)
<pkern> ogra: And it's not only the artwork... ;)
<ogra> heh, thanks ...
<ogra> there is a lot of controversal discussion about the artwork ...
<pkern> Hehe.
<ogra> if all goes fine we'll get gobby in the default install next release ;) (but i bet you read your blog comments)
<\sh> pkern: to answer your question..no snow but a lot of rain...rifood
<zyga> hi guys
<zyga> any python module for easy handling of short binary messages?
<pkern> ogra: Sure I did.
<\sh> and please never type a sentence when the pizza cab is coming
<pkern> ogra: It's just one weird bug left before we could release 0.3.0.
<zyga> things with methods like push/pop_bigendian/littleendian_8/16/32
<ogra> pkern, great, i guess you'll solve it before jan 19th ;)
<pkern> ogra: A big showstopper concerning encodings and special characters. ):
<pkern> ogra: Yep.
<pkern> ogra: Well, there are the winter holidays in between!
<ogra> heh, yes
<pkern> ogra: Perhaps we get Gobby 0.4.0 with TLS encryption done by that date... *cough&
<ogra> 0.3.0 would suffice for me, but 0.4.0 would be cooler indeed ...
<pkern> Because the GNOME people complained about that when they discussed the inclusion into GNOME. They won't do it, though. Rather by obby plugins into other applications than by including Gobby itself.
<\sh> pkern: only because of a missing tls feature?
<pkern> \sh: Nope.
<pkern> \sh: Because two editors are bad, etc.
<pkern> \sh: gedit and gobby... doesn't look like "integration"
<\sh> pkern: hmm..but I don't see any collaborative editing functions in gedit
<pkern> TLS is a low-level problem anyway (net6), so possible plugins would also receive it.
<pkern> \sh: Yes. We looked at it when we started Gobby, but the plugin architecture didn't seem advanced enough for the task. It was easier to reinvent the wheel. |:
<pkern> \sh: I'm still not glad about the problem, that we need to implement every single editor feature which is not covered by GtkSourceView.
<ogra> how about a libGtkEdit ?
<\sh> pkern: well...kde...this is...kde...really a ...kde... problem ... kde 
<pkern> ogra: Probably more features should be added to GtkSourceView instead ;)
<pkern> \sh: Did you say anything about...kde...? ;)
<ogra> or that :)
<\sh> pkern: I? never...where ...kde...did you see...kde...kde?
<\sh> hehe
<pkern> \sh" Heh
<\sh> pkern: serious...I would be cool to see gobby even as kobby
<\sh> s/I/It/
<ogra> \sh, port it ;)
<\sh> ogra: I would...but I need some "gnome main uploads" you remember?
<pkern> We first considered Qt because it's portable to OSX, but there was no free Windows port at that time and the lead developer didn't like the naming conventions. (: (And apart of that it lacked a serious editor widget.)
<ogra> yup :=)
<pkern> A question: Should one register products or projects in Launchpad?
<ogra> products 
<\sh> pkern: what is wrong with kates ?
<pkern> \sh: There's MateEdit, a collab editor?
<\sh> pkern: or qscintilla?
<\sh> pkern: yes..but not compatible to gobby...
<\sh> I think
<pkern> I registered net6, obby and gobby as products, but that was wrong I think. At one time in Launchpad (I can't really remember) I was asked to specify a project instead.
<ogra> hmm
<pkern> As those projects are really developed outside of Ubuntu. 
<ogra> #launchpad could tell i gess
<pkern> \sh: I did try qscintilla... It was a mess.
<pkern> k
<pkern> \sh: It needs to emit correct signals for insertion and deletions... and it was... quite... unusable.
<\sh> pkern: hmm...but what about improving QTextEdit then
<pkern> \sh: Others are invited to do that. That's why obby is a library (=
<\sh> pkern: pythonbindings to obby?
<pkern> Python would be reasonably easy, other languages not because there aren't yet any C bindings.
* Kamion turns CD image builds back on
<Kamion> s'pose I should do a few seed merges too
<Vebzku> Hi
<Vebzku> Can someone help?
<Kamion> Vebzku: it's normally more effective to ask the question first - people have different kinds of expertise
<Vebzku> ^^ok
<Vebzku> umm..weit a sec. i'm bad english
<Vebzku> umm...when i try do internet accres whit DHCP its do some error
<Vebzku> and when i'm in ubuntu. i can be 15min and then X cursor come and my Screen go black.
<Kamion> ok, sorry, this isn't a support channel (even if #ubuntu couldn't answer - but if you haven't tried there, try #ubuntu first)
<Vebzku> ok
<Vebzku> sory
<Kamion> failing that, try ubuntu-users@lists.ubuntu.com, or, if you prefer, the forums or a launchpad.net support request
<ogra> hey sabdfl 
<ogra> sabdfl, had a edubuntu workshop and talk yesterday, lots of interest :) http://photos.shermann.blogweb.de/main.php/d/3448-2/P1000213.JPG , http://photos.shermann.blogweb.de/main.php/d/3451-2/P1000214.JPG ...
<sabdfl> hiya
<sabdfl> nice, ogra!
<sabdfl> am snowboarding with mdz in colorado
<ogra> cool, enjy the wather :) visiting lamont ?
<ogra> *enjo
<ogra> grr
<ogra> enjoy indeed
<sabdfl> ogra: sort of :-)
<slomo> BenC: the bcm43xx driver is now "usable"... you can scan, assign channel/essid and transfer data ;)
<zyga> guys, how do I do unsigned math in python?
<zyga> I need to minick 32bit C code
<zyga> s/minick/mimick/
<siretart> elmo: please sync ldaptor from unstable, overriding ubuntu changes
<firefly2442> anyone know if there will be an update for the gam_server 100% CPU issue?
<kbrooks> Hey
* kbrooks pokes everyone
<kbrooks> i have a big compliant trhat should be addressed immediately
<kbrooks> zsnes: (Emulator of the Super Nintendo Entertainment System (TM)), section multiverse/otherosfs, is optional. Version: 1.400-1ubuntu1 (breezy), Packaged size: 504 kB, Installed size: 3212 kB
<kbrooks> This should be moved to universe and also updated
<kbrooks> to 1.4.2
<kbrooks> zsnes is licensed under the GNU GPL
<kbrooks> i checked
<ajmitch> and.. why should this be done immediately?
<mantiena> doko, hi are you near the computer ? I have few question about OpenOffice.org plans in Ubuntu
#ubuntu-devel 2005-12-10
<Kamion> kbrooks: it's in multiverse because you generally can't actually use it without non-free ROMs, i.e. the same reason that it's in Debian contrib. See zsnes/debian/README.Debian.
<kbrooks> Kamion, but its licensed under the GNU GPL
<Kamion> yes, but main+universe is supposed to be closed under dependency; that is, if you can't use software there to any significant degree without requiring non-free software, it doesn't go in main/universe.
<Kamion> Debian's contrib and non-free sections map to restricted/multiverse unless we explicitly override that due to differing licensing policies, and this isn't one of the areas where our licensing policy differs from Debian's. Sorry.
<Kamion> See http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib, relevantly "free packages which require contrib, non-free packages or packages which are not in our archive at all for compilation or execution"
<elmo> Kamion: got a sec?  I'm trying to figure out why breezy is uninstallable (sic); aptitude -o debug::pkgproblemresolver=true isn't being helpful - is there another magic switch for aptitude?
<Kamion> that's the only one I know of ... let me see if I can zen it out
<elmo> Kamion: the base cause is that libesd-alsa0 is now in ubuntu-desktop; it always should have been, but wasn't due to bugs in the dak setup
<Kamion> huh, so there were bugs other than the cron.sync Task screwup? (which shouldn't have affected ubuntu-desktop)
<elmo> Kamion: this particular bug was that I assumed apt-ftparchive would automatically concatenate multiple Task entries in the extra file - it doesn't tho
<Kamion> oh, ok
<elmo> Kamion: so stuff was never getting into multiple tasks, in breezy pre-my-changes, libesd-alsa0 was only in edubuntu-desktop
<elmo> now it's in edubuntu-desktop _and_ ubuntu-desktop
<Kamion> ugh, amazing netboot worked at all
<elmo> Kamion: for ref ~jackass/katie/backup/pre-fixes/ might be useful
<elmo> [err jackass:~katie/ obviously, but you knew that] 
<elmo> Kamion: yes :(
<elmo> I don't think netboot did work in !server mode for much of anything
<elmo> or I'm amazed if it did
<Kamion> unless aptitude's just blatantly ignoring |-ed deps ...
<Kamion> hmm, libasound2 isn't in ubuntu-desktop, wonder why
<Kamion> oh, it's in minimal, ok
<elmo> err, in breezy?
<Kamion> yeah
<elmo> oh, indirectly
<\sh> grr..good morning...
<Kamion> elmo: try -o Aptitude::CmdLine::Resolver-Debug=true
<Kamion> aptitude has its own problem resolver, I think
<elmo> hmm, no dice
<elmo> using pkgproblemresolver does give me more info, justnot enough and not the usual apt spew
<Kamion> ok, can I reproduce this with a debootstrap?
<elmo> Kamion: yes, I did it in a --variant=buildd chroot
<elmo> and then 'aptitude install "~tubuntu-standard|~tubuntu-desktop"'
<elmo> (after installing aptitude)
<kbrooks> When are the "beta" (e.g. flight) cds released? when the distro is stable
<kbrooks> ?
<Kamion> kbrooks: that plus when I have time to do it
<kbrooks> Kamion, huh?
<Kamion> (BTW, we're going to be calling the previously-so-called "Preview" release "Beta" from now on)
<Kamion> ("alpha" is a better description of the Flight CD releases)
<kbrooks> Kamion, ok, s/alpha/beta/
<kbrooks> why are the cd releases named flight?
<Kamion> kbrooks: Flight CD releases require manual QA and usually fixups from someone, and that someone is usually me
<kbrooks> er, beta alpha
<Kamion> kbrooks: collective noun for both dragons and ducks (i.e. Drake)
<bmonty> elmo: please sync lmodern from debian unstable, overriding ubuntu changes is OK
<kbrooks> what is "tubuntu"
<kbrooks> ?
<Kamion> nothing
<Kamion> ~t is part of an aptitude pattern
<kbrooks> ah 
<Kamion> elmo: ah, that aptitude option is new in dapper's aptitude, arse
<kbrooks> arse?
<kbrooks> :)
<Kamion> kbrooks: ok, explaining everything I say to somebody else is getting kind of old now :)
<Kamion> elmo: (BTW you want --without-recommends to match the installer, not that it makes any difference)
<elmo> Kamion: ah, ok
<Kamion> elmo: hmm, even more bizarrely, it seems to be quite happy for me to install the ubuntu-desktop task from the UI
<elmo> ugh
<elmo> oh, ok, so if I do:
<Kamion> differences between what installing ubuntu-desktop wants to install and the list in Task: ubuntu-desktop:
<Kamion> +apmd
<elmo>  apt-get install $(apt-cache dumpavail | grep-dctrl -FTask -sPackage ubuntu-desktop | cut -d: -f 2)
<Kamion> +laptop-mode
<Kamion> +libqthreads-12
<Kamion> -mysql-common-4.1
<Kamion> +mysql-common
<Kamion> not clear to me that any of that is relevant
<Kamion> (dude, grep-dctrl -n)
<daniels_mobile> mdz: don't happen to know if LAX has any wireless?
<\sh> daniels_mobile: whereever .nu is...but give us back xvfb-run :)
<daniels_mobile> Stuck here for another 7 hours but no frigging networks I can see.
<Kamion> elmo: hmm, I guess the mysql-common thing isn't helping
<elmo> daniels_mobile: http://www.jiwire.com/browse-hotspot-airport-united-states-us-california-ca-los-angeles-17239.htm
<Kamion> elmo: ugh, look at the dependencies of libmysqlclient12 and libmysqlclient14
<Kamion> I bet those are confusing matters something rotten
<daniels_mobile> elmo: thanks. Any executive summary? Can't get big pages on my phone. In the Bradley international terminal, pre-security.
<elmo> daniels_mobile: it claims there is one, but doesn't given any useful info, it looks like a bit of a lame site tho
<daniels_mobile> Okay, thanks. I'll do some more wandering.
<elmo> it's meant to be a "Boingo" network, and the map is useless
<elmo> christ, these deps are a mess
<Kamion> elmo: we explicitly seeded mysql-common in the breezy server seed to avoid a similar problem
<Kamion> elmo: I'm wondering if LALALAYOUDIDN'THEARTHIS demoting mysql-common-4.1 to breezy/universe LALALA would help
<elmo> I'm wondering if we shouldn't just put the old Packages files back
<Kamion> I think it would, actually
<elmo> and declare that gina/soyuz/lp doesn't get to generate the indices files for a released suite
<Kamion> the old indices files *were* fucked in other ways though ...
<elmo> well at least netboot for ubuntu worked with the old ones :P
<elmo> but yeah, I guess
<elmo> ugh
<Kamion> how about tomorrow I set up a fake archive with my proposed change and see if it works?
<elmo> this still doesn't explain libesd0 tho?
<Kamion> I suspect aptitude may be running into the mysql thing and giving up
<elmo> ah
<Kamion> once stuff is broken apt* can be a lot less willing to fix other things
<Kamion> worth noting that the released CD images include libesd-alsa0 and mysql-common, but not libesd0 or mysql-common-4.1
<Kamion> which at least gives us a guide to what we're supposed to be installing
<elmo> well, except kubuntu must have libesd0, but yeah
<Kamion> right, yeah, sorry, just referring to Ubuntu here
<Kamion> I note that Task: kubuntu-desktop in the new Packages files manages to include both mysql-common and mysql-common-4.1
<elmo> *sob*
<elmo> tho, if we demote mysql-common-4.1, that should stop that?
<Kamion> should do ...
<Kamion> I'd probably want to rerun germinate against faked-up Packages files and check out the differences
<Kamion> explicit seeding would help kubuntu but I don't see how it could help ubuntu/edubuntu
<Kamion> (of mysql-common)
<Kamion> the other option I can think of is an updated ubuntu-desktop binary, but that's possibly even more horrible than a demotion
<Kamion> since it would have to go in breezy, not breezy-updates, and VOMIT
<elmo> breezy-updates is on by default tho, right?
<elmo> or is it still too late?
<Kamion> hm, you're right
<Kamion> ok, that's theoretically an option
<Kamion> hmm, removing mysql-common-4.1 from my local apt-cached Packages file doesn't fix the libesd0 thing
<elmo> can you remove stuff from the Packages file in apt?
<Kamion> oh, smeg, smeg, smeg
<elmo> what about thebinary cache?
<Kamion> you know, having our main distribution be a substring of our derivative distributions really wasn't a good idea
<elmo> oh, you're kidding?
<Kamion> (a) in your grep above, "ubuntu-desktop" matches "kubuntu-desktop" and "edubuntu-desktop"
<Kamion> (b) in the aptitude pattern encoded into the breezy installer, the same applies
<Kamion> headdesk
<elmo> ARGH
<elmo> yeah, confirmed
<Kamion> (yes, it seems you can go in and edit the cached Packages file; I edited Release too for good measure, although it didn't seem to care that I hadn't changed Release.gpg - apparently it only validates that on update)
<elmo> aptitude install "~t^ubuntu-desktop" works
<Kamion> but that won't install the right thing, unless you arrange for "ubuntu-desktop" always to come first in the Task lines
<elmo> oh, is that how the ~t thing works?  eww
<elmo> 3 packages upgraded, 910 newly installed, 0 to remove and 0 not upgraded.
<Kamion> although it'll probably be relatively close because the ubuntu-desktop binary is only in Task: ubuntu-desktop
<elmo> doesn't look too far out?
<Kamion> so that'll pull in the rest
<elmo> ah
<Kamion> oh, god, I have no clue how to solve this at 12:30 in the morning
<elmo> don't worry about it, it's been broken for a while, there's no rush
<Kamion> yes, reverting to the old Packages files seems like the only sane thing to do right now
<elmo> (since Nov 23rd, to be exact)
<daniels> christ, what a uselessly broken hotspot
<Kamion> and maybe, if we have to, providing shadow Packages files somewhere unofficial where people can point Kubuntu or Edubuntu netboot installs
<daniels> it's down in the checkin area, where the food and powerpoints aren't, and it's munted for seven minutes out of every ten
<kbrooks> Is ubuntu *itself* licensed?
<Kamion> although they'd have to be signed with the archive key which is, er, kinda awkward
<daniels> \sh: you do know I've been on holiday all last week, right?
<elmo> remind me why we don't just do apt-get install ubuntu-desktop for netboots?
<kbrooks> Is ubuntu *itself* licensed?
<elmo> kbrooks: your question is meaningless and repeating it, doesn't help
<\sh> daniels: i'm just teasing you...don't take me too serious
<kbrooks> elmo, meaningful question ... ok
<Kamion> elmo: semi-historical reasons originally, partly that I found the metapackage broke more during development, and nowadays installing the metapackage doesn't clue aptitude in to the fact that it should consider all the dependencies of ubuntu-desktop individually manually installed
<kbrooks> why is ubuntu apparently "open source" if ubuntu itself is not placed under a license?
<Kamion> please don't troll #ubuntu-devel, thanks
<elmo> Kamion: ugh, right, ok
<kbrooks> I'm not trolling.
<mjg59> kbrooks: You have permission to distribute modified or unmodified versions of everything in Ubuntu
<mjg59> The CD packaging specifies that you have permission to distribute the CD, too
<kbrooks> OK
<Kamion> I suggest you consult a lawyer if you have specific concerns; most people here do not have legal training and are merely trying to do the best they can
<daniels> or just ask debian-legal, they rock
<kbrooks> heh, i'll look in there
<kbrooks> ty
<Kamion> (although between us we have fairly extensive experience with free software licences)
<Kamion> (i.e. enough not to generally wildly cock it up, we hope)
<Kamion> elmo: actually, you were right, apparently aptitude's ~t pattern matches task names individually
<Kamion> so '~t^ubuntu-desktop$' should be a viable workaround
<Kamion> but unfortunately there's no way to retrofit that into breezy without a base-config upload to breezy, and breezy-updates *wouldn't* cut it in that case
<Kamion> I'll fix my local dapper trees now though
<seth_k> kbrooks, zsnes updated to 1.420
<kbrooks> seth_k, ok
<seth_k> kbrooks, just hit archive so you should be able to apt-get it now
<elmo> Kamion: ugh
<Kamion> elmo: I'm off to bed, will look more in the morning
<elmo> Kamion: ok, thanks a lot for looking at it
<Toma-> is there any talk of including initng with dapper?
<Amaranth> nothing major like that for dapper
<Amaranth> but initng is a hack
<Amaranth> i believe the ideal solution is porting sun's stuff
<SEJeff> Amaranth: What did sun do?
<Amaranth> i can't remember but it has real dependency handling and such
<SEJeff> http://lists.debian.org/debian-lsb/2005/08/msg00013.html
<Amaranth> what would be cool is to say "start GDM" and have the init system handle all the dependencies to make that happen
<SEJeff> The new lsb has an example for paralell init script execution. That would be the easiest likely
<SEJeff> Yes you're very right
<Toma-> that would be nice
<SEJeff> apt-start gdm would be cool
<Amaranth> http://en.wikipedia.org/wiki/Service_Management_Facility
<Amaranth> that's what solaris has
<infinity> I don't really dig anything that tears out init scripts and starts from sratch.  Perhaps because I like being able to do a slow transition.
<infinity> And I'm not sure I see the point, except to be hip and cool.
<Toma-> everyone that tries linux says it starts so slow. alot of people like to turn their PC's off alot for some crazy reason
<infinity> If we can achieve similar results through a dependency-based sysv-init behave-alike, it's less confusion for people upgrading and wondering WTF happened.
<Toma-> yeh
<wasabi> I really don't fancy having so many scripts sitting around in /etc. No technical reason though. I like Macs launchd or whatever. Just a simple description about what program to run, how to run it, and what to do if it doesn't run.
<uenyioha> hey guys
<uenyioha> anyone know assembly...?
<uenyioha> im trying to increment the value of a register by 8
<uenyioha> i was thinking thinking this was the proper memmonic with gas
<daniels> o/~ this is how I represent over this here beat
<uenyioha> mov 8(%ebp), %ecx
<uenyioha> i think i'm a little off....since it appears to be "dereferencing" the register instead
<desrt> uenyioha; what register?  ecx?
<uenyioha> desrt: i think i found what i needed
<desrt> addl $8, %ecx   ?
<desrt>  mov 8(%ebp), %ecx  is    mov ecx, [ebp+8] 
<uenyioha> desrt: yeah...brain fuzz is a bitch
<uenyioha> desrt: yeah....thanks a lot!
<elmo> what's the usual solution to autoconf insisting on libxt-dev's header files to test for X?  just build-depend on it?
<infinity> Least resistance is to build-dep on libxt-dev, "correct" solution is to re-autocrapify with a shiny new autoconf that gets it right.
<elmo> how new?
<elmo> like, newer than breezy?  because breezy still seems to reference Intrisic.h when you use AC_PATH_XTRA
<elmo> ugh, holy crap
<elmo> it appears the "solution" is a debian-specific patch that makes optional arguments to AC_PATH_XTRA so you can tell it to look for something other than libXt
<infinity> Yeah, uhm.  Note I had "correct" in quotation marks above.
<infinity> I don't think the upstream autotools guys have given a single thought to modular X yet.
<infinity> Or, if they have, they're not letting us know what they've come up with.
<infinity> I assume in the end, the old X-related macros will just become deprecated, and we'll get new ones for each library and wire protocol, or something.
<elmo> well given debian is the de facto upstream for this package, I don't think adding debian specific stuff to configure.in is likely to win me any friends
<elmo> oh well, bogus build-depends it is
<elmo>   * Remove some ancient debian-specific patches
<elmo>     - install no longer calls strip with special options
<elmo> grr
<fabbione> morning
<infinity> coreutils has been making everyone happy lately, for different reasons.
<fabbione> elmo: hey dude
<fabbione> elmo: did rt got my mails?
<fabbione> elmo: i had no ack back from it
<elmo> fabbione: when/where did you send them?
<fabbione> after i did wake you up on saturday
<fabbione> :/
<elmo> fabbione: I'll look later today, when I'm working
<fabbione> oh ok
<fabbione> sure
<fabbione> i tought you were just shifting hours
<pitti> Good morning
<fabbione> morning pitti
<pitti> Hi fabbione 
<zakame> hello pitti :)
<pitti> daniels: here?
<HiddenWolf> Mogge
* HiddenWolf shakes head
<doko> good morning
<pitti> Hi doko
<doko> seb128: dude, more libcairo fun. change the package name, if you remove symbols :-(
<doko> hi pitti
<doko> pitti: what are the names of the new locale packages?
<pitti> doko: 'locales', just as before
<pitti> doko: the source package is 'langpack-locales'
<doko> hmm, and all locales are pregenerated?
<doko> pitti: ^^^
<pitti> doko: no, they aren't
<pitti> doko: the langpacks itself ship the locales
<pppoe_dude> q: is ubuntu sorta like debian unstable or is it better?
<pitti> doko: and they generate the language-relevant loclaes on installation
<pitti> pppoe_dude: #ubuntu, pleas
<pitti> e
<pppoe_dude> k bye :)
<doko> pitti: look, at debian/locale-gen in the gcc-* sources, that currently is broken by the new locales package, and I certainly don't want to build-depend on 15 language packs
<mvo> pitti: I just got a dpkg override problem error from langpack-zh-<something> on upgrade, known issue?
<pitti> mvo: no, it's not; what is the conflict?
<pitti> doko: uh, gcc needs to generate locales?
<infinity> For the testsuite.
<infinity> A few pckages generate locales during build.
<infinity> (In the build directory, of course)
<pitti> I had assumed that test suites would ship their own example locales, hmm
<doko> pitti: every package which needs locales for the testsuite needs them
<doko> pitti: but you didn't mention it in the spec ;-P
<pitti> doko: no, I didn't even think about the possibility of that
<doko> please fix it. kthxbye
<pitti> 'every' can't be that many, though
<pitti> ok, so should there be a locales-all package maybe? 
<pitti> doko: 'fix'? what's your suggestion?
<doko> which depends on every langpack package?
<pitti> either gcc could just copy the locale definitions, or we create an -all package
<doko> how would this package look like?
<pitti> doko: no, b-d on all langpacks would be a bit silly
<pitti> doko: it could ship the locales in /usr/share/locales-all/, or whereever
<doko> so the -all package would contain a copy, which is only used as a b-d?
<pitti> doko: would be an option, yes. no idea whether it makes sense
<pitti> if it's only gcc, then just copying the locales there would make more sense
<pitti> then the test suite would be self-containing
<doko> well, at least better than build-depending on language packs
<mvo> pitti: hm, sorry. I can't reproduce it anymore. it was language-pack-gnome-zh and/or language-pack-gnome-zh-base during a upgrade
<doko> pitti: I know locales are tested in gcc, bash, python (and maybe binutils as well).
<pitti> mvo: well, -zh and -zh-base replace each other, so that can't be it
<pitti> mvo: maybe a gnome package coflicted to a non-gnome one?
<doko> the thing is, that we'll break things without knowing about it ...
<pitti> doko: ok, since there seem to be more packages, then having an -all package would seem like a clean solution?
<pitti> doko: I would build it from langpack-o-matic
<pitti> since eventually we'll pull locales from rosetta
<pitti> doko: can you tell the test suites where the definitions are? (path)
<doko> pitti: please make it compatible with the previous implementation of localedef, so that script have not to be changed
<pitti> doko: localedef did not change at all
<pitti> doko: well, it got some belocs enhancements, but localedef only has a default path which wasn't changed
<pitti> doko: ok, we can make the langpacks Replace: locales-all
<pitti> but that requires another langpacks upload
<doko> pitti: sent you the script
<fabbione> dpkg-shlibdeps: warning: could not find any packages for /usr/lib/libncurses.so.5 (libncurses.so.5)
<fabbione> dpkg-shlibdeps: warning: unable to find dependency information for shared library libncurses (soname 5, path /usr/lib/libncurses.so.5, dependency field Depends)
<fabbione> hey guys
<fabbione> any idea why i could get that error?
<pitti> doko: script?
<fabbione> libncurses5 is installed
<fabbione> also -dev
<doko> pitti: a script, which many packages use to generate the locales which they need for testing
<pitti> doko: hm, the script already looks into `pwd`/locales
<pitti> doko: so the locales just need to be there without changing the sript
<doko> pitti ... the dir is empty ...
<pitti> doko: right, but it means that a quickfix is just to copy the locales there; 12 locales or so are tiny
<pitti> Hi seb128 
<seb128> hey pitti
<doko> pitti: that's the wrong fix. touching N packages instead of one.
<pitti> doko: it's a 'quickfix'
<pitti> doko: building and uploading 300 new language packs is not a 5-minute fix
<doko> some would call it crap ;-P
<pitti> doko: I would call it 'self-contained test suite' :)
<doko> pitti: wrong, I'm not supposed to test against my own data, but against the system's data. I don't include the libraries I use, as well.
<dholbach> good morning
<doko> seb128: dude, more libcairo fun. change the package name, if you remove symbols :-(
<seb128> doko: I don't remove symbols
<seb128> doko: Debian do, I've dropped the patch for Ubuntu
<seb128> hi dholbach
<dholbach> hey seb128 :)
<doko> seb128: then maybe the shlibs dependency needs to be tighened? see siretart's posting on u-d
<pitti> doko: well, if you truly want to test against what the system has, then b-dep'ing on the langpacks wouldn't even be completely wrong
<seb128> doko: it lacks any detail to be useful
<seb128> doko: imho this has nothing to do with cairo, that's the freetype ABI breakage itself
<doko> pitti: it's not wrong to use the same mechanism to create these locales on build time.
<seb128> freetype dropped symbols
<sivang> morning all
<pitti> doko: no, it's not, I didn't say that
<doko> seb128: ok
<doko> pitti: so did we agree that we will have a locales-all package?
<pitti> doko: as I said, if you want I can create a locales-all package, but I'd prefer to ship the locale definitons in a different path
<doko> pitti: it's ok for me as long as localedef finds this data
<pitti> doko: you probably need to adapt the path in the script
<pitti> i. e. change LOCDATA
<pitti> erm, LOCPATH
<doko> pitti: please no. this way we have to change every package.
<pitti> doko: changing 3 packages seems easier than 300, no?
<doko> pitti: a) you _know_ these 300 packages b) it's mechanical c) there are more than 3, and they are unknown
<pitti> doko: ok, I'll talk with jbailey about changing localedef, it could look into an alternative path
<doko> pitti: ok, I'll file a bug report to keep track of it
<pitti> doko: that would be nice, yes
<mvo> Riddell: in what package is the kdesu binary?
<infinity> kdebase...
<infinity> (kdebase-bin for the binary package, I think)
<mvo> thanks
<siretart> seb128: /usr/lib/libcairo.so.2: undefined
<siretart> symbol: FT_GlyphSlot_Embolden
<seb128> siretart: freetype symbol
<seb128> freetype ABI change
<seb128> cf bug I pointed
<siretart> seb128: I really don't want to attack you, I just want to really understand whats about this soname magic and how to "bump soname"
<seb128> siretart: who said you attack anybody?
<seb128> siretart: if the ABI change it a non-compatible way you have to change the soname
<dholbach> normally upstream does that :)
<seb128> but upstream don't always do this actually
<seb128> lu vuntz_
<dholbach> lintian should check the list of exported symbols on a library upgrade :)
<siretart> in this case: shouldn't debian do the soname bump?
<siretart> and how can we do this in the most compatible way?
<seb128> siretart: changing the soname over upstream is making you binary incompatible with the rest of the world
<dholbach> siretart: the bug report and d-d@ has a discussion on this topic
<seb128> ie: if upstream has .so.0 and ubuntu .so.1
<seb128> let's say skype is built with .so.0
<seb128> it'll not run on Ubuntu
<seb128> out of this look on libfreetype6 rdepends
<seb128> not an easy case
<siretart> seb128: how about running dh_makeshlibs in libfreetype with '-V'?
<seb128> that's bad
<seb128> you should bump the shlibs only when the ABI/API change
<seb128> not on every new version
<seb128> because you force transitions when not required
<siretart> I see
<seb128> and transitionning hundreds of packages is not a piece of cake
<siretart> the thing is, it IS required in this case
<seb128> so you don't want to do it every single new version for nothing
<seb128> right
<seb128> soname should have been changed since symbols have been dropped
<seb128> which breaks binary compatibily
<seb128> the issue is that Debian screwed
<siretart> so you suggest that freetype upstream and debian should fix this and we cannot do much about it, right?
<seb128> and dholbach asked for a sync of the new version, so we are quite stucked too now
<seb128> we don't want to do it differently from Debian
<thoron> Hi! 
<seb128> imho we should just bump the shlibs and move on
* dholbach mutters something about reducing delta... no idea that would happen... truly sorry...
<seb128> dholbach: no need to be sorry, that happens to everybody :)
<seb128> thoron: morning
<thoron> Could I get somewhere the whole source of Ubuntu build system?
<dholbach> that's quite a lot :)
<HrdwrBoB> thoron: if you so desired
<thoron> Not the packages, only the system that makes the binaries. So that I make my own Linux distribution. ;-)
<sivang> isn't it like the debian build system?  
<HrdwrBoB> sivang: extremely complicated and takes many many hours to build?
<thoron> Anything goes, is there some tarball available?
<siretart> seb128: ok. what do we do about this freetype problem? wait for debian or bumb soname on our own?
<HrdwrBoB> thoron: there is no giant source tarball
<HrdwrBoB> thoron: you will have to grab each packages source individually
<thoron> HrdwrBoB: No, I am not looking for source packages, I looking for build and release system.
<seb128> siretart: my opinion is what I just said, bump the shlibs for now ... you may want to ask to Kamion/mdz
<thoron> The tools that Ubuntu or XYZ disto makes it work for source packages to bootable installation ISO images.
<thoron> Surely that is not something that is made by hand.
<infinity> thoron : svn ls http://svn.cyberhqz.com/svn/wanna-build/
<infinity> thoron : That's (more or less) what we use for building binaries from sources.
<infinity> thoron : We use the debian-cd package for making CD images.
<thoron> Now we are getting somewhere. ;) Thanks.
<sivang> thoron: well, I guess that are many automated parts in it, however I wouldn't count on the assumption it would all go into a nice formatted ISO without some intervention :)
<infinity> thoron : Both are heavily modified by us, but that's what's publically available.
<thoron> well, I have lot to learn.
<thoron> And I don't want to invent wheel again.
<thoron> infinity: so why isn't everything public?
<infinity> thoron : "Because it's not" is probably the best answer you'll get.  Most of our modifications are very specific to Ubuntu, so there's no point in pushing patches back out to the world at large.
<thoron> Linux from scratch is interesting project too.
<thoron> There is automation process going on but it's not ready yet.
<thoron> And Red Hat will not release their build system if I have understood correctly.
<thoron> Anyway, thanks for this part. I'll try to figure out how it works.
<Tliug> hi guys
<Tliug> I've added a LILO boot screen for Ubuntu ...
<Tliug> http://guilt.bafsoft.net/stuff.php 
<Tliug> please check it out and let me know your opinion
<Tliug> :)
<Tliug> Anyone here? 
<pitti> Mithrandir: ping
<pitti> ogra: argh, what happened to xscreensaver? it looks like the Debian version again
<seb128> pitti: read the changelog?
<seb128> pitti: it's moved to universe with Ubuntu hacks dropped
<pitti> seb128: ah, ok, sorry
<pitti> so g-s-s comes along?
<seb128> yep
<seb128> pitti: no need to be sorry, just pointing that's explained by the changelog :)
<janimo> elmo, if it's you who can delete packages from the archive, please remove xffm4-icons, it is causing unnecessary user confusion and it is superseded (conflicts, replaces) by new xffm4. thank you
<pitti> yay, that's the dapper way of printing - put a pdf on an USB stick and boot a breezy live CD *grumpf*
<pitti> Keybuk: oh, you are here now? :) maybe we can try to chase down the printing breakage?
<Keybuk> yeah, they attacked my line all day Friday and *still* haven't fixed it
<Keybuk> grr
<pitti> Keybuk: oh, you are still on modem?
<pitti> Keybuk: I can feel your pain, I have to work though ISDN pretty ofen
<pitti> often, even
<Keybuk> no, on ADSL, but it barely works at night time
<Keybuk> pitti: "printing breakage"?
<Keybuk> do you mean that cups sulks and doesn't recognise USB printers?
<pitti> Keybuk: oh, I found out a bit now
<pitti> Keybuk: usb printers are now called /dev/lp0, not /dev/usblp0 any more
<ogra> pitti, remove the old xscreensaver cruft, gnome-screensaver is the future ;) (will write the main inclusion reports today for you)
<pitti> Keybuk: probably cupsys doesn't recognize that
<pitti> Keybuk: oh, and linux-wlan-ng breaks as well - the prism2_usb module is not loaded automatically :(
<pitti> bah, even cp -a lp0 usblp0 doesn't help - cupsys refuses to see the printer
<fabbione> pitti: you probably want a symlink on /dev
<pitti> fabbione: doesn't help
<Keybuk> pitti: yeah, that one I know, I fixed it already locally
<Keybuk> it's /dev/usb/lp0 ... extra /
<pitti> ah
<Keybuk> dunno why prism2_usb is not loaded ... easiest way to debug is to run "udevmonitor -e", then plug your adapter in
<pitti> ok, I'll do that later
<Keybuk> you'll get a [UEVENT]  and [UDEV]  block for it (often multiple)
<pitti> hm, still no fun with /dev/usb/lp0
<hunger> Keybuk: You noticed bluetooth breaking?
<hunger> Keybuk: bluetooth module is there, so udev seems to do its magic, so this is probably nothing for you to worry about.
* pitti RTFC
<Keybuk> hunger: not yet
<Keybuk> again, use udevmonitor to capture the device being inserted ... and mail me the output
<pitti> Keybuk: cupsys checks for /dev/usblp0, /dev/usb/lp0, /dev/usb/usblp0; should not be a problem to teach it /dev/lp0; but for that it has to work with usblp0 first
<hunger> Keybuk: The device is builtin... And I the key combo used to deactivate/activate does no longer work.
<Keybuk> hunger: built-in, or mini-PCI?  on my laptop the wifi killswitch also kills the bluetooth.
<Keybuk> pitti: nah, will fix the udev rules instead
<pitti> Keybuk: k, but still a cp -a of the device should certainly work?
<hunger> Keybuk: No idea how it is integrated.
<pitti> since the kernel is only interested in the major/minor?
<hunger> Keybuk: The wifi killswitch used to kill BT as well on mine. Unfortunately that no longer works since the kernel/udev upgrade.
<Keybuk> pitti: yes, but cups may not be inotifying the /dev directory <g>  if it only looks when hal tells it about a new device ...
<Keybuk> hunger: what wireless card is it?
<hunger> Keybuk: BT is allways on now... but does not react to my mouse.
<pitti> Keybuk: no, cupsys doesn't use hal - it just opens every usblp device it can find and issues some ioctls on it
<hunger> Keybuk: Uses madwifi drivers... lspci lists it as Atheros AR5212.
<pitti> Keybuk: (in list_devices)
<Keybuk> hunger: is your wifi card working?  is it up?
<Keybuk> pitti: when does it call that?
<pitti> Keybuk: might very well be that the usblp driver was broken in a more recent kernel
<pitti> Keybuk: whenever you ask for the device list
<hunger> Keybuk: It is down at the moment.
<pitti> Keybuk: but manually forcing usb:/dev/lp0 as a device doesn't work any more either
<hunger> Keybuk: Wifi does work.
<Keybuk> could be
<pitti> Keybuk: I'll gdb this and dig a bit further
<Keybuk> I think there's also a race if you have a real /dev/lp0
<Keybuk> the kernel uses "lp0" to refer to both a real printer, and a usb printer
<pitti> right, that's probably why the USB device detector doesn't check for /dev/lpX
<Keybuk> and depending which one gets detected first, wins the name
<Keybuk> yeah
<pitti> Keybuk: oh, btw, with "yeah, that one I know, I fixed it already locally -- it's /dev/usb/lp0 ... extra /'
<pitti> Keybuk: did you mean that it should be /dev/usblp0 right now?
<Keybuk> what do you think it should be?
<pitti> Keybuk: no, I mean, my current /dev/lp0 is probably my parallel port
<pitti> Keybuk: so priting somethign to it is doomed to fail
<Keybuk> right
<pitti> so there is no device for my printer
<Keybuk> yes
<Keybuk> here's a good way to fix it
<Keybuk> echo 'BUS=="usb", KERNEL=="lp[0-9] *", NAME="usb/%k"' > /etc/udev/rules.d/50-printer.rules
<Keybuk> usbplug -Busb
<pitti> ok, I have the udevmointor output for the printer
<Keybuk> that should create /dev/usb/lp0 for you
* pitti does not have an usbplug program
<Keybuk> sorry, udevplug
<pitti> Keybuk: yay, that worked
<Keybuk> should it be /dev/usblp0 or /dev/usb/lp0 ?
<Keybuk> which one does the cupsys source seem to "prefer" ?
<pitti> Keybuk: /dev/usblp0
<pitti> Keybuk: but it doesn't really care
<pitti> Keybuk: but the flat name seems more consistent nowadays
<Keybuk> right
<Keybuk> flat it is then
<pitti> Keybuk: what I don't understand is: there already is a rule 'SUBSYSTEM=="usb", KERNEL="lp[0-9] *",     GROUP="lp"'
<pitti> Keybuk: is SUBSYSTEM wrong?
<pitti> it's obviously evaluated since the permissions are correct
<pitti> so both rules match
<pitti> but with only this rule I should have gotten a /dev/lp1
<pitti> oh, wait, no
<pitti> it seems that the kernel enumerates usb lp devices separately
<Keybuk> exactlyu
<Keybuk> kernel names them *both* lp0
<Keybuk> and udev doesn't compensate by re-enumeration
<pitti> that explains the race
<pitti> Keybuk: shall I open a bug report with that rule? or is your todo list enough for that?
<Keybuk> pitti: it's already done
<Keybuk> pending, if you like
<Keybuk> doing an update to 077 today, then will release it
<pitti> ok, great; then a bug report doesn't make sense
<pitti> Keybuk: l-wlan-ng is a kernel fault, btw
<fabbione> pitti: how's that?
<pitti> fabbione: well, not a bug in the kernel itself, just the prism2_usb driver needs updates for the new kernel
<fabbione> ok..
<pitti> fabbione: dmesg says 'driver is using old /proc/net/wireless support, please fix driver'
<fabbione> ehehe
<pitti> module is loaded, wlan0 appears in iwconfig, but with 'no wireless support'
<fabbione> fix the driver ;)
<pitti> and what do I do in the afternoon?
<eruin> is "dlopen: /usr/lib/xorg/modules/libGLcore.so: undefined symbol: __glXLastContext" (Failed to load libGLcore.so) a candidate for a bug report? I saw a f-d mail about it ( https://www.redhat.com/archives/fedora-devel-list/2005-November/msg00558.html ) where someone had the issue with using the nv driver on the same xorg version as is in dapper, which leads me to believe it's not an issue with the fglrx I'm trying to use, but with xorg
<eruin> if this stinks end-user-support, feel free to ignore ;)
<mvo> eruin: do you use the "ati" driver?
<eruin> currently trying to use fglrx
<eruin> mvo, was that a rhetorical question? ;)
<mvo> eruin: oh, no. it's just had the ati driver has the same problem, but apparently i810, nv work fine
<eruin> mvo, hmm, according to the f-d list thread, nv has the same issue
<eruin> though that might ofcourse not apply to dapper
<pitti> Hi jbailey 
<djk_> doko: hi, why does the OOo package not include DicOOo and why does it not use the standard OOo buttons?
<jbailey> g'm Martin (et al)
<dholbach> djk_: do you have openoffice2-gnome installed?
<djk_> dholbach: i use kubuntu and the 1.9.129 package
<dholbach> i see, was just a quick guess
<doko> djk_: remove openoffice.org2-kde
<djk_> doko: it's not the buttons i actually care about, i just wonder why DicOOo wasn't included.
<doko> license problems
<djk_> doko: oh, i didn't know that file had a different license than the rest of OOo.
<doko> it's worse. the licenses differ from dictionary to dictionary (language to language)
<djk_> ah okay, that explains this of course. could one add a notice to the ubuntu releases regarding that?
<doko> chmj: please build libxml-commons-resolver1.1-java without libxerces-java, which is not in main
<chmj> doko: got it 
<doko> chmj: ok
<Keybuk> pitti: typo in auto-generated libgphoto2 rules ... you have "Goto=" not "GOTO=" :p
<pitti> Keybuk: oh, thanks; I'll file a Debian bug and fix that in our packages
<pitti> jbailey: how difficult would it be to add another locales defintions path to localedef?
<jbailey> pitti: What do you mean?
<pitti> jbailey: we need a locales-all package since some packages need the locales in their test suites at build time (gcc, etc.)
<pitti> jbailey: right now, localedef looks in /usr/share/i18n/locales
<jsgotangco> hi
<pitti> jbailey: can we have it additionally look into /usr/share/locales-all? (or sth. similar)
<pitti> jbailey: to avoid a file conflict of locales-all with the langpacks
<jbailey> Yes, that can be done, I think.
<jbailey> Do you need glibc to look at those as well, though?
<jbailey> I think you do.
<pitti> jbailey: hm, I don't
<pitti> jbailey: the only issue is the path of the definition sources
<pitti> not the binary generated ones
<pitti> jbailey: we only need to unbreak the test suites
<jbailey> Ah, I see.
<jbailey> So it's for an overall dump that can be just installed and generated as needed?
<pitti> jbailey: right, it should just become a build dep of python, gcc, bash (and possibly a few others)
<pitti> jbailey: pretty hackish, but I don't see another good solution; doko doesn't want gcc et al to b-dep on 10 langpacks
<pitti> (understandably...)
<jbailey> Lazy sod.
* jbailey hides
<jbailey> =)
<pitti> jbailey: so this -all package can just be generated from langpack-o-matic, which has the locale data
<pitti> jbailey: alternatively, we change the structure again to just use this -all package in the langpacks and not ship the locales in the langpacks itself
<pitti> jbailey: it doesn't sound too bad either
<pitti> (and then -all is superfluous, it should just be locales)
<doko> jbailey: get you coffee^Wtea first, so you become bearable ;-)
<doko> pitti: yes, the proposal sounds good
<pitti> well, having locales spread in langpacks is still a nice idea IMHO
<pitti> e. g. the -all approach would force us to update locales-all whenever we update a locake in a langpack
<pitti> so we can't do that after a release
<jbailey> Having them spread throughout, I think, make for a more scalable installation as we penetrate to more communities.
<pitti> (that's why b-deps on the langpacks are the only true way to get the locales that are actually used in the system)
<jbailey> pitti: Is locales-all just intended for build-dep'ing?  Like for testsuites and whatnot?
<jbailey> So there'd be no reason to update it after a reelase.
<pitti> jbailey: right now, yes
<jbailey> (And not much reason to update it ever, really...)
<pitti> jbailey: if we don't update it, then it becomes senseless
<pitti> then we can as well copy the locales into the sources itself
<jbailey> Things that depend on localisations for their testsuites are (to some degree) broken, since there's no promises that the data won't change.  The glibc testsuite made a bunch of assumptions that the belocs locales had changed.
<jbailey> Right.  That's part of what I'm wondering.
<jbailey> Should the testsuites themselves just cache a version that they know to meet their needs that won't change?
<doko> pitti, jbailey: why not ship the data in /usr/share/i18n/locales in the locales package?
<pitti> jbailey: according to doko, the testsuites want the actually used locales in the system, which makes sense to me
<pitti> doko: file conflict with langpacks
<doko> pitti: that's solvable
<jbailey> pitti: How does it make sense?  There's no promise about collation ordering, currencies, symbol names, etc.
<jbailey> These things do slowly change.
<pitti> jbailey: right, comparing string output doesn't make sense, but I don't know what the locale tests actually do. doko?
<jbailey> I had to fix the glibc testsuite to work with the belocs data because its internal collation testing relied on ordering that had changed with belocs.
<doko> pitti: is the data in /usr/share/i18n/locales managed by rosetta? if not, then there's no reason not to keep it in the locales package
<jbailey> pitti: I'd assume everything.  Python / gcj would want to test date, ordering, currency, etc.
<pitti> doko: it will be eventually
<pitti> doko: that was part of the idea
<jbailey> doko: The idea is that as new languages get added to the system, that rosetta can handle all of it.
<jbailey> doko: So that you come along and decide to, say, get one of the North American native languages into Ubuntu.  Translators should be able to generally do all that work in rosetta and not bother the poor coders about it. =)
<doko> well, why not have the same schema as we have with the language packs: have two locations, and if rosetta has an update, use that one
<pitti> that's what the alternative path in localedef is about
<pitti> doko: but still the question remains what gcc etc. actually test about a particular locale?
<doko> pitti: yes, but packages can continue to b-d on locales, and don't have to be changed
<jbailey> doko: That's what we'll do , assuming that it's the right thing.
<jbailey> I'm not convinced that it's safe for a package to test based on  properties of a system locale.
<doko> pitti: have a look, there are just 60000 test cases ;-)
<jbailey> Because you're caching the results of that system locale in the testsuite.
<jbailey> With no promise that the system locale is static.
<Kamion> jbailey: I can see how you'd want to test against the current system locales, though
<\sh> jbailey: Sure...I would like to see you doing some lectures on cdbs for the ubuntu motu school :) lets talk about date and time later
<Kamion> as opposed to some artificial set of locales that don't actually correspond to what will be used
<doko> jbailey: well, that's no change to the current approach. We do work with the system locale, so we should test with it as well
<infinity> jbailey : By that argument, we shouldn't have testsuites, unless we're going to re-run them every time anything on the system changes.
<jbailey> Kamion: It depends on what you're testing.
<Kamion> glibc's a special case because it's shipping tools that manage the locales, but most other testsuites will want to test that they work *with* the system locales
<pitti> Kamion: it depends on what you actually test for
<jbailey> Most of the time I don't think they're actually interested in testing that "In german, collation comes out in this order".  That's a nonsensical test.
<jbailey> What I suspect that they want is that a series of colation option DTRT.
<jbailey> And that this is conveninently tested by looking at German, Chinese, and Khosa. =)
<jbailey> \sh: Lovely. =)
<pitti_> hrmpf network
<pitti_> <pitti> Kamion: an artificial locale is the right thing for checking correct collation, time formatting, etc., whereas the system locale is good for checking for - well - hmm, whether the time is formatted at all?
<\sh> jbailey: Well, I have to thank you for raising this idea...I wanted to ask you anyways :)
<doko> \sh: ask jbailey to talk about the finished cdbs2 implementation ;-P
<jbailey> \sh: Now's not the best time, I'm split between two things already at once.
<\sh> jbailey: well...the plan is to have at least every two weeks one lecture (from january on)
<\sh> jbailey: I'm preparing some timetable now...and collecting the topics and the speakers :)
<pitti> I thought cdbs2 would never see the light of the day, in favor of -3?
<\sh> doko: well...I heard, you wanted to do a nice lecture about "ABI Transitions...how to find the right packages to transition!" topic...
* netjoined: irc.freenode.net -> brown.freenode.net
<doko> \sh: you're the expert ;-)
<jbailey> infinity: Isn't the proposal at some point to separate the builds from the testsuites so that a test run can be done later?
<\sh> doko: but you prepare this stuff...and I would like you to explain why it has to be done and how it's working...would be nice if you could do this in the near future...(february sometimes)
<jbailey> infinity: I thought I heard someone suggesting that at UBZ.
<jbailey> infinity: But mostly, I think it depends on what you're testing for.  I'd be curious in which cases programs are testing things which are actually best served by the actual results from the system locales.
<infinity> jbailey : I don't recall anyone suggesting build/test separation, but I approve of the general idea.
<jbailey> infinity: I'll try and come up with the who said it.
<jbailey> infinity: It wouldn't be the first time I've dreamed of a coworker saying something and then implemented it as if it were fact.  *sigh*
<jbailey> (Or gone to them and asked them if they were insane)
* infinity laughs.
<fabbione> doko: should i bother to try the new oo2 on sparc?
<jbailey> fabbione: You were complaining yesterday that the buildd was idle ;)
<fabbione> jbailey: i did a give back :)
<doko> fabbione: it should not fail, but wait until the i386 build succeeds
<fabbione> jbailey: and each doko upload means ~ 24 hours of work for my buildd
<fabbione> doko: will do thanks dude
<Keybuk> pitti: what's with the ENV{UDEVD_EVENT} and ENV{SEQNUM} checks in /etc/udev/rules.d/85-hal.rules ?
<Keybuk> oh, and there's a typo in there too
<Keybuk> I think that file should be just:
<Keybuk> RUN+="socket:/org/freedesktop/hal/udev_event"
<Keybuk> SUBSYSTEM=="block", ACTION=="remove", RUN+="/lib/udev/hal-unmount.sh"
<Kamion> jbailey: build/test separation is part of AutomatedTesting, yes
<Keybuk> (note ACTION== not ACTION=, and move the helper to /lib/udev if you like)
<jbailey> Kamion: Oh good. =)
<pitti> Keybuk: dunno, these SEQNUM and UDEVD_EVENT checks were there for ages, I didn't change them
<Keybuk> pitti: they're a bit irrelevant now :p
<pitti> Keybuk: ok, I'll clean it up
<pitti> Keybuk: ok, fixed in my local package; I'll upload it when I fixed some more stuff
<pitti> Hi BenC 
<BenC> hey pitti
<seb128> doko: thanks for pinging me for the menus change before uploading openoffice.org2
<Kamion> pitti: hmm, I just found my sysfsutils patch was slightly wrong
<Kamion> pitti: could you please arrange for the udeb to remove the libsysfs.so.1 symlink and move libsysfs.so.1.0.3 to libsysfs.so.1?
<pitti> Kamion: I can change it in Debian quickly (oh, we can sync, btw)
<pitti> Kamion: sure, that's not a problem
<doko> seb128: that won't be the only upload this week
<Kamion> I'll just check that that really works, but d-i library reduction fails otherwise and I think that's why
<pitti> Kamion: ah, there should be no library symlinks in udebs in general?
<Kamion> it seems to break when there are library symlinks in /lib
<Kamion> hmm, I may have an alternative solution though, one sec
<seb128> doko: I'll do the patch now, please ship it with next one :)
<Kamion> library symlinks are kinda pointless in udebs though :)
<pitti> right
<Kamion> pitti: ok, my workaround didn't work, but moving the library does work, so yes, please do that thanks :)
<\sh> STRIKE
<\sh> I just ordered a nice amd64
<pitti> Kamion: ok, I'll upload it to Debian and then we sync from incoming in half an hour?
<Kamion> works for me
<ogra> \sh, WOW !!!
<ogra> \sh, congrats 
<\sh> ogra: including everything 450,-  (shipping, etc.) but no monitor...
<\sh> which means I need to install ubuntu via serial...
<\sh> I hope this is possible
<raphink> Ubuntu lacks a netinstall
<jbailey> \sh: Works on sparc. =)
<raphink> or I yet have to find it
<raphink> if it exists
<Kamion> raphink: http://archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/current/images/netboot/
<\sh> raphink: no..netinstall works :)
<Kamion> next time start out with a question rather than a statement :-P
<raphink> oh good
<ogra> heh
<raphink> hehe
<raphink> I missed it several times
<raphink> it's not easy to find
<Kamion> yeah, it should be documented better. it's referenced in the installation manual shipped on the CDs
<raphink> hehe sorry Kamion ;)
<zakame> Kamion: ooh netinstall! :D
<ogra> a wikipage would suffice i guess ;)
<raphink> zakame: you ignored there was one, too ? ;)
<raphink> ogra : agreed
<Kamion> ogra: no, not really, it needs to be linked from www.u.c/download/ and cdimage, probably
<zakame> raphink: well I remembered Debian has it, so Ubuntu should have it too :)
<raphink> zakame: that's what I thought at first, but lately I searched for it and couldn't find one, only threads about creating one
<Kamion> ogra: I can tell that a wiki page doesn't suffice because there's already more than one
<raphink> so i'm happy there's one :)
<ogra> Kamion, yes, but for a start it would be nice to find the url by searching for netinstall
<raphink> that's very useful
<\sh> jbailey: on sparc I know that it works :) but do we have enabled serial output in our syslinux and kernel?
<Kamion> (Installation/Netboot, Installation/LocalNet, etc.)
<\sh> ogra: search for netinstall on the wiki
<ogra> oh, yes
<Kamion> ogra: netinstall means something else in a Debian context; netboot is usually close enough for most people, but it isn't the same
<ogra> i searched for title ... 
<ogra> a conten search throws ot several pages
<ogra> *content
<Kamion> so I do not advertise the netboot images as netinstall (i.e. CD images containing the full installer and base system but requiring you to download the rest from the network)
<\sh> Kamion: do you actually know if we enabled serial output in syslinux and the kernel?
<ogra> damned i need a serial mouse ...
<Kamion> \sh: not for certain, no, although I'd be surprised if it were disabled
<raphink> there's https://wiki.ubuntu.com/Installation/Netboot?action=show&redirect=NetbootInstall
<Kamion> Debian has it on and I certainly haven't turned it off in syslinux
<\sh> Kamion: ok...I'll check it out on friday..when the computer is delivered :)
<raphink> Kamion: yes I meant netinstall as a small (10 MB) CD that contains the installer and installs everything from network
<zakame> er, I'm not sure if this is the right place, but I'm toying with the idea of a graphical first time guide, similar to what xp has (its in flash)...
<ogra> \sh, do you have access to serial mice anywhere ? apparently the serial mouse patches to ltsp dont work and i cant even test it
<sivang> \sh: bought a new machine ? :)
<Kamion> raphink: "yes <contradiction>" ;-)
<raphink> hehe ;)
<raphink> well gtg
<raphink> later
<Kamion> raphink: the netboot images I pointed you to contain the core of the installer and enough to get more
<\sh> ogra: sorry no...I only have access to a ps/2 mouse
<zakame> bye raphink :)
<\sh> sivang: finally
<Kamion> and the image is less than 10MB, yes
<sivang> \sh: I also want to get an amd64 machine, soon
* ogra is still looking for a cheap ppc to do install tests ... 
<ogra> i can only test liveCDs ... :/
<\sh> ogra: pegasos
<ogra> hmm, whats still making acpi-support and powermanagement-interface uninstallable ? 
<ogra> \sh, nah ... i want something commonly used 
<ogra> who uses *pegasos* 
<\sh> mac mini then :)
<ogra> yes, but they are still expensive ... only for install tests ... i think i'll look for a cheapo used iMac or something ...
<seb128> doko: there is just the debian/template.desktop.in to not ship (debian/rules to change for that), do you need a patch or could you make the few changes for that?
<doko> seb128: that file isn't used
<sivang> ogra: ebay should probably have enough offerings
<ogra> i guess so
<seb128> doko: ?
<seb128> $ grep "desktop.in" rules
<seb128>         sed 's/@VER@/$(VER)/g' debian/template.desktop.in \
<seb128>         sed 's/@VER@/$(VER)/g' debian/template.desktop.in \
<seb128> doko: that seems to be the menu entry we want to drop to me
<seb128> (I've 1.9.129 source package)
<doko> ahh, ok, for the "From Template ..." one
<seb128> doko: yep
<seb128> doko: so, do you want a patch or you just do the changes for that for the next upload?
<doko> seb128: please send me a patch, you can use the file from 1.9.129. it's unchanged
<ogra> hmm, 165 doesnt seem to much for an unsed iMac
<ogra> *used
<Amaranth> yeah, but new ones are faster than advertised, have more video ram than advertised, and have a faster HD
<ogra> but what for ? i only need it for install tests i'll never work with it ...
<ogra> or for ltsp client tests
<pitti> Kamion: sysfsutils_1.3.0-5_i386.changes  is on incoming.d.o
<pitti> Kamion: current Ubuntu changes can be overwritten, if you want to sync yourself
<zakame> er, what's policy for java packages in ubuntu?  I'm trying to merge lucene, and I'm reconciling the b-d-i's...
<Kamion> elmo: please sync sysfsutils from incoming, ok to overwrite; needed for d-i to build
<Kamion> pitti: thanks
<elmo> partman (68/74ubuntu2+1): in main - skipping.
<elmo> Kamion: ok to remove or not?
<Diziet> Hmm.  So I want to make a new project/package/thing for AutomatedTesting (got to the top of my list, yay).
<Kamion> elmo: not - partman.udeb's been replaced by partman.deb
<Diziet> What should I do about revision control ?  (a) cp -a   (b) CVS   (c) baz   (d) bzr  (e) hct  ?
<mdke_> elmo, <insert daily ping about docteam commit access here>
<jbailey> Diziet: I don't think (e) is far enough along yet to generally use the way you'll want, and is primarily targetted to packages.
<Diziet> This won't be a complicated project.  Is bzr ready enough ?  How's its integration with the .dsc toolchains ?
<Diziet> jbailey: Right.  This will be a package.
<jbailey> Diziet: I use bzr for all my personal projects now.
<jbailey> I haven't gotten around to writing bzr-buildpackage, although I keep meaning to.
<jbailey> More interesting things keep coming up for spare time hacking like that.
<Diziet> Right :-).  I'm not sure I want to get into that kind of yak-shaving either.  Presumably if you haven't done it yet it's not that essential.
<mvo> I use bzr as well for all new stuff and it works very well for me
<Diziet> I haven't used bzr at all.
<jbailey> Diziet: Are you likely to be the main developer for this stuff?
<Diziet> Yes, at least for now.
<jbailey> Diziet: Here's all you need to know to start with:
<Diziet> But I should learn bzr anyway so maybe this is a good place to start.
<jbailey> Diziet: Put everything in a directory where you want it and are ready for the initial commit.  Then do: bzr init; bzr add .; bzr commit -m "Initial Commit"
<jbailey> Diziet: Literally: Setup the repo, add all the files from the current directory down, actually do the commit.
<Diziet> I'm very `commit early, commit often' whereever possible.  bzr's cheap branches seem likely to be good for that.
<jbailey> Diziet: It requires no server.  It puts everything in a .bzr directory off the root of the tree.
<Diziet> jb: And when you dpkg-buildpackage you end up shipping a copy of the repo too ?
<jbailey> Diziet: I do a -I.bzr in my debuild.
<Diziet> jbailey: Right.
<mvo> Diziet: I have a arch-build in my debian/rules with  "tar cf - `bzr inventory` | (cd debian/arch-build/$(PKG)-$(DEBVER);tar xf -)
<mvo> "
<Diziet> Oh, debuild has been rewritten by someone-not-Christoph-Lameter.  Maybe I'll try it out some time :-).
<Diziet> mvo: :-).
<Diziet> Err, WDYM `arch' ?  Is this `bazaar is a brand so it doesn't mean anything, and bazaar is supposedly the successor to arch, so arch must be a brand too, so arch==bzr' ? :-)
<jbailey> Diziet: I've done a ssh people.ubuntu.com mkdir -p public_html/bzrtree then after that "bzr push people.ubuntu.com:public_html/bzrtree/PACKAGE"
<jbailey> Diziet: And then anyone else can branch from you trivially.  And then it's also someone else job to put it onto a tape backup. =)
<Diziet> Is there a bzr reference manual ?  I like reference manuals much more than recipes and howtos.
<Diziet> I have my own tape backup here :-P.
<jbailey> I do too.  It's in a box somewhere.
<jbailey> I don't know if I can still buy tapes for it. =)
<Diziet> Right under the 4 obsolete CRTs and the Sun4c, right.
<jbailey> Hey it's not that bad.
<jbailey> It's a Mips 5000. =)
<jbailey> Diziet: But basically after that, all you need is the occasional bzr add and frequent bzr commits, and end of day bzr push's.
<jbailey> It caches the location of the last push, so just "bzr push" is enough after that.
<Diziet> Like I say, I want a reference manual.
<Diziet> Cool.
<jbailey> There might even be one.  I
* Diziet finds a URL in the FM.
<jbailey> 'll go looking when I decide to figure out how merges and cherrypicking works. =)
<Kamion> jbailey: do you happen to know if there's any way to tell whether you're in an initrd or an initramfs?
<Kamion> from the perspective of a random shell script running in either
<Diziet> Hmm.  I can have   http://www.bazaar-ng.org/obsolete-docs/cmdref.html   which looks nice but out of date, or a wiki (doom).
<Kamion> or 'bzr help commands'
<jbailey> Kamion: Am I allowed to assume that the initramfs was created by initramfs-tools, or are you looking from the first point when you start up?
<Diziet> That's not quite a reference manual :-).
<Kamion> (although I realise you need an initial "how does it all go together" first
<Kamion> jbailey: neither, because this is in the live CD
<\sh> going home
<Kamion> I can put a cue-file in if I *have* to, but I'd rather not
<mdke_> elmo, thanks!
<jbailey> Kamion: My best guess is that you might be able to check filesystem type.
<jbailey> Kamion: initrd might be a read-only cramfs.
<jbailey> initramfs is a RW cramfs.
<jbailey> err.
<jbailey> RW ramfs
<jbailey> but that's a guess.
<Kamion> in an initrd it's 'tmpfs on / type tmpfs (rw)'
<Kamion> well, in *this* initrd
<Kamion> jbailey: also, do you know if anyone's already porting klibc's run-init to busybox?
<jbailey> Kamion: Oh hm.  you're using ext2 images aren't,you?
<Kamion> that said I suppose run-init's trivial if you don't bother to remove the initramfs contents and if you assume that the new root filesystem has mount and chroot
<Kamion> jbailey: varies by arch
<Kamion> from 2.6.15 installer images onwards, at least in Ubuntu, it will be initramfs for everything; before that, it was ext2 on some and cramfs on others, depending on size restrictions and on what our beloved kernel team decided to provide ;)
<Kamion> (gzipped ext2 was rather more size-efficient than cramfs last time I checked, but wasn't available everywhere)
<Diziet> Urgh, James B consistently writes `independantly'.
<lucas> I have a problem with a desktop system which hangs during shutdown/reboot. On which package should I report the bug on bugzilla ?
<mdke> lucas, do the best you can. If you have no idea, try UNKNOWN, and it will get reassigned appropriately.
<mdke> Diziet, is that on the wiki? maybe we can correct it
<ogra> lucas, look for it in bugzilla, i'm sure there are bugs already ...
<lucas> well, I was hoping to skip one step by asking here :)
<Diziet> mdke: No, it's on his blog.
<mdke> ah :(
<elmo> doko!
<elmo> WTH is this oo.o -experimental crap?!
<doko> elmo: native amd64 packages, as discussed on the last meeting
<elmo> which meeting?
<ogra> elmo, the weekly meeting
<ogra> dapper dev
<doko> yep
<doko> elmo: these will go away before dapper is released
<ogra> its only for the flight 2 CD for now ...
<doko> ogra: no way!
<ogra> doko, ?? 
<ogra> did you say you build them to make flight 2 possible ? or did i get that wrong ?
<doko> yes, you're wrong, we'll use the ia32 binaries
<ogra> ah, k
<ogra> so ignore me then :)
<elmo> dear lazychannel, where are the logs for this meeting? kthx
<doko> OOo build with -j3 was not a good idea ...
<elmo> ok, so I found the last meeting can't see any refernce to this, seriously, someone pls give me a useful keyword to search on, I've tried the obvious ones (oo.o, amd64, experimental)
<doko> Mithrandir doko: are you doing the ooo-amd64 stuff as well?  It's a fairly easy change, I'd imagine?
<Riddell> _mvo_: kdebase-bin I think
<doko> elmo: ^^^
<_mvo_> Riddell: thanks
<pitti> mvo: move it :)
<elmo> doko: pfft
<LaserJock> Amaranth: ping?
<thierry_> seb128_ : does the .desktop file get translated by default or we need to set something special for it? (like a happy maintainer that adds translation directly in the .desktop file?)
<doko> elmo: as the OOo build failed, I need another upload. so what does the "pfft" mean? ;-)
<seb128_> thierry_: that's why one the reason why desktop files should go upstream
<thierry_> seb128_ : ok but when upstream, do they go in the translations files?
<elmo> doko: there's no actual discussion in that meeting or justification
<elmo> doko: do these packages work?
<elmo> doko: if not, why build them?  if they do, why not just ship them as the default?
<elmo> doko: are we going to ship with these in dapper?
<elmo> etc.
<seb128_> thierry_: the strings are listed by the pot file if that's the question
<thierry_> k thanks
<thierry_> seb128 : well in fact I wanted to know if they are listed automatically, or someone needs to add them?
<doko> elmo: not shipping in dapper, testing, the build, they work until they crash. ok, I'll let Mithrand1r sort this out, it's not my task anyway. 
<seb128> thierry_: you need to make a desktop.in and to list in with po/POTFILES*
<thierry_> seb128 : and how do I do that?
<thierry_> seb128 : what's the difference between a .desktop and a .desktop.in
<seb128> thierry_: the first has the translation and is generated from the second
<seb128> thierry_: look on whatever source package, the .desktop.in has _Name=, _Description=. The .desktop is made from this one using the po translations for those
<thierry_> seb128 : ok but if I sent a .desktop addition to upstream, will they create the .desktop.in or is my job to do so?
<seb128> thierry_: better to do it, but they will probably do it other way
<thierry_> seb128 : ok cool, but how do I do it? where do I put this file? in debian directory?
<seb128> look on other package sources
<seb128> usually data/
<seb128> you need to list the Makefile.am
<seb128> s/list/change/
<LaserJock> elmo: can I request a sync of ghemical? I have verified that the Debian unstable source builds in a dapper pbuilder and the previous Ubuntu changes are no longer neccessary.
<thierry_> seb128 : and is "cp src/pixmaps/sine.xpm debian/geg/usr/share/pixmaps" a good way to copy the icon in /usr/share/pixmaps ?
<seb128> for a package that's a way, for upstream no
<thierry_> seb128 : why not for upstream??
<ogra> because upstream doesnt use the debian dir and might want to integrate with his .po files
<thierry_> ogra : k but what do I do if I want to sent my patch upstream?
<elmo> LaserJock: are you a motu?
<seb128> thierry_: learn?
<ogra> ask upstream how he wants it first ? 
* mvo is away to play hockey, bbl
<ogra> he/shce might telly you what to do 
<seb128> thierry_: you need to change the Makefile.am to get the file shipped
<ogra> elmo, not yet
<LaserJock> elmo: no, not yet, but the Debian maintainer is azeem. He can verify
<thierry_> seb128 : mmm any wiki or guide for that?
<azeem> I am not a motu, either
<elmo> LaserJock: get a motu to verify and I'll sync.  what's your preferred email?
<LaserJock> elmo: mantha@chem.unr.edu
<seb128> thierry_: nop, just look at some package as example
<elmo> LaserJock: ok, whitelisted you - lemme know when you've got a MOTU to sign off
<LaserJock> elmo: ok, thanks
<Amaranth> LaserJock: pong
<LaserJock> Amaranth: I have a menu question
<Amaranth> I'm psychic. ;)
<LaserJock> Amaranth: Is it ok to put Categories=Application;Science; in a .desktop?
<LaserJock> lol
<LaserJock> I mean there isn't a Science menu but there really should be one, I think
<Amaranth> I don't see why not.
<Amaranth> It's a valid category according to the spec.
<Amaranth> But GNOME's applications.menu doesn't have any sorting for it.
<LaserJock> Amaranth: right so what will happen to it?
<Amaranth> It'll go into Other.
<LaserJock> Amaranth: that stinks
<LaserJock> so is that a Gnome problem?
<Amaranth> Define "problem".
<Amaranth> I'm sure it'll get flagged NOTABUG.
<\sh> god bless daniels...he gave me back xvfb-run :)
<LaserJock> well, it should go in Science not other
<\sh> daniels: thx
<Amaranth> LaserJock: Science doesn't exist in the GNOME menu and they'll say it's too specialist to include.
<Amaranth> I believe someone already tried to get it.
<\sh> daniels: but you broke it :( or gtk is broken
<Amaranth> blame gtk
<Amaranth> :)
<\sh> ** ERROR **: Failed to init GTK+
<\sh> aborting...
<LaserJock> Amaranth: that's irritating, so there isn't anything we can do about it>
<\sh> /usr/bin/xvfb-run: line 153:  5102 Trace/breakpoint trap   DISPLAY=:$SERVERNUM XAUTHORITY=$AUTHFILE "$@" 2>&1
<thierry_> LaserJock : I just installed a rebuilt package with a new .desktop file with the science menu as category, and I get nothing in the menu, not even others
<\sh> /usr/bin/xvfb-run: line 158: kill: (5100) - No such process
<Amaranth> LaserJock: You can put it in more than one menu.
<Amaranth> thierry_: Then your .desktop file isn't valid.
<Amaranth> thierry_: If my dapper vmware image worked I'd tell you the command to run to check it.
<thierry_> Amaranth : thierry@modemcable050:~/dev/geg-1.0.2/debian$ desktop-file-validate geg.desktop
<thierry_> thierry@modemcable050:~/dev/geg-1.0.2/debian$
<LaserJock> Amaranth: what do you mean but "put it in more than one menu", like a different category?
<LaserJock> s/but/by/
<Amaranth> LaserJock: Yeah, you can do Categories=Applications;Science;Education; or something.
<LaserJock> Amaranth: yeah, well I guess that will have to do. I was trying to avoid putting non educational things in Education.
<Amaranth> science apps are always educational :)
<Amaranth> they teach you about your level of patience :D
<thierry_> Amaranth LaserJock : maybe we could retry sending a bug to gnome since it doesn't make very professional putting science stuff in education menu, wich doesn't even have an icon!
<LaserJock> Amaranth: but seriously, many of them are real research tools. oh well
<thierry_> it's ugly looking and not very well triaged...
<Amaranth> http://bugzilla.gnome.org/show_bug.cgi?id=140900
<Amaranth> LaserJock, thierry_: Poke that bug, see if someone responds.
<\sh> grmpf
<LaserJock> yeah, ok thanks for your help Amaranth. I don't want to keep you any longer from your other important work ;-)
<Amaranth> hehe, these little breaks are fun though
<thierry_> Amaranth : just added a comment about how much it was sooooo important that this get fixed :)
<fabbione> dear ftpmaster, I really appreciate the sync you have to NEW daily d-i and me running rsync. please shift to normal working hours. kthxbye
<elmo> fabbione: -EITAGLISH
<fabbione> elmo: ehhe 
<elmo> fabbione: seriously, I don't parse?
<elmo> speaking of daily d-i
<elmo> lamont/infinity/kamion: only ia64 is being built ATM
<fabbione> elmo: each time you NEW daily d-i, i start rsync and find this nice 300MB of stuff to download :/
<Kamion> elmo: sysfsutils upload fixed it, I byhanded amd64 and i386 earlier, when the powerpc buildd gets off its arse and builds sysfsutils it should work too
<elmo> Kamion: ah, ok
<Kamion> s/upload/sync/
<fabbione> shifting 12 hours would let me sync while i am sleeping ;)
<Kamion> ah, sysfsutils_powerpc in accepted, woo
<Kamion> fabbione: was me doing the byhands, and I'm sorry but I needed to do it fairly urgently
<fabbione> Kamion: i will survive :)
<Kamion> because I can't do any CD testing at all until that blockage is shifted
<fabbione> i love you guys too much to be upset
* fabbione sends a big hug to elmo and Kamion
<Kamion> (oh, just on a semantic note, daily d-i doesn't get newed, it gets byhanded ...)
<fabbione> right
<Kamion> just be glad you aren't mirroring cdimage right now
<\sh> Topic No. 8 : "The Ubuntu Vocabulary" -> Host: Kamion
<fabbione> Kamion: i do
<Kamion> \sh: no :)
<fabbione> Kamion: but only once a day in the morning
<\sh> Kamion: hehehe
<Kamion> fabbione: whoa, insane person
<Kamion> what, really cdimage, not releases?
<Kamion> oh, iirc you only mirror {daily,daily-live,dvd}/current/ or something, that's not so bad
<fabbione> yeah
<fabbione> only daily
<\sh> elmo: please sync ghemical from unstable, ok to override, thx
<fabbione> Kamion: what's up with cdimage?
<fabbione> did you decide to re-release warty/hoary and breey in one go?
<Kamion> fabbione: no, just doing a fair few builds today that's all
<fabbione> eeheh
<fabbione> Kamion: do you think we can schedule to start building -server cd's after flight-2 ?
<fabbione> speaking of which.. i need to setup the mailing list
<Kamion> fabbione: cdimage is already trying to build them
<fabbione> Kamion: ah nice.. reports at the usual url?
<Kamion> today's build apparently succeeded in fact
<Kamion> yeah
<fabbione> server rocks!
<Kamion> and previous builds have succeeded (from before I turned cdimage off for five days during the kernel madness)
<fabbione> ok
<fabbione> the 2 problems are known and soon to be addressed
<fabbione> as soon as Ben will upload 7.9 i will have to book 20 minutes of your time
<fabbione> because we should get the first cut of server kernels
<Kamion> meh, that's probably a bit more than 20 minutes
<Kamion> hope you don't want them in d-i
<fabbione> Kamion: that's what i wanted to talk with you about.. best approach to it
<Kamion> 'cos that would be PAIN and SUFFERING
<fabbione> i love pain and suffering :)
<Kamion> I prefer inflicting pain and suffering on people who overcomplicate the installer build system ;)
<trevilor> hi guys
<fabbione> Kamion: we can avoid to do that.. really.. ideally we can install with 386 and install by default the 686-server kernel
<fabbione> Kamion: optional a 686-superhighendclassservernoyoucantrunthisathomebecauseyoucanteffordthehw
<fabbione> but well
<fabbione> you tell me when
<\sh> ogra: please remind me, if fabbione and kamion are visiting cologne, that I have to go somewhere else...too much SM here
<ogra> lol
<\sh> love pain and suffering vs. inflict pain and suffering...that's too much stiefelknecht
<Kamion> fabbione: right, that sort of thing is only P&S in base-installer, which is not so bad
<fabbione> ogra: you should probably show HellRaiser to \sh
<Kamion> (it's already a bit of a mess)
<fabbione> Kamion: ok :)
<ogra> fabbione, i bet he knows it ... (actually i never asked him)
<\sh> fabbione: the movie?
<\sh> part 1/2/3?
<fabbione> \sh: movies
<ogra> \sh, ever seen/read hellraiser ?#
<fabbione> from 1 to 6 ?
<ogra> \sh, all
<\sh> i missed 4/5/6
<\sh> the guy with the nails in his head, right? actually I don't like b-movies ,)
<ogra> \sh, its not a movie, its philosophy :)
<tseng> massochism?
<fabbione> tseng: no
<fabbione> not really
<\sh> ogra: hmmm....torrent url? ,-)
<\sh> oh no...no space left on home....deleting sources now
<fabbione> \sh: time to get a bigger hd
<\sh> fabbione: the new machine will be delivered thursday or friday...
<ogra> \sh, aldi sells 250 GIG USB HDs for 140 
<\sh> ogra: I just bought a stupid sempron64
<tseng> \sh: ugh
<backports-r-us> I need some quick GNOME C help... would this be a good place to ask? (please?)
<backports-r-us> It's related to a Universe package :)
<rob^^^> ogra: that's wayy too mcuh
<\sh> tseng: no ugh...the only thing I could buy for my money :)
<tseng> you can get a "free" sun ultra20 :P
<backports-r-us> what's the GNOME function for getting the filename of the wallpaper?
<ogra> rob^^^, really ? 
<rob^^^> ogra: indeed. in the US you can regularly get them for about $80 after rebates
<ogra> with case and all ? 
<\sh> rob^^^: and when you import them .. you have to pay customs like hell...
<rob^^^> ogra: or external?
<rob^^^> err oh
<ogra> yes, uUSB HD
<rob^^^> hrmmm didn't notice hte uSB in there but you can get those for $30 here
<ogra> -u
<ogra> so i'm at 110 + wire ...
<ogra> might come up to 120 ...
<\sh> rob^^^: calculating the customs plus the hw prices ... the result will be the same price like here..or even more expensive
<ogra> and i pay 20 for not having to assemble it ;)
<rob^^^> man, how do yall make ends meet over there
<rob^^^> I'd definately buy a lot less than half the amount of computer junk if it cost twice as much
<rob^^^> ogra: is that 160 tax inclusive?
<ogra> 140 all inclusive
<rob^^^> oh 140
<rob^^^> yeah that's ok I guess
* rob^^^ readjusts his contacts
<\sh> ogra: btw...did you buy this mac now?
<ogra> \sh, still waiting for an answer, i mailed them
<ogra> but i will, they have plenty others for the same price ...
<rob^^^> We just got an Aldi here, I still haven't been
<ogra> and i can pick it up in pulheim
<\sh> ogra: did you hit the "buy now" button?
<rob^^^> what Mac are you buying?
<ogra> i have no ebay account ... and wont create one ...
<ogra> http://cgi.ebay.de/Apple-iMac-G3-blue-PowerPC-B_W0QQitemZ8728930419QQcategoryZ4603QQrdZ1QQcmdZViewItem
<\sh> ogra: I have one...
<rob^^^> those are quite slow these days
<ogra> its enough... i need one for install CD and live CD testing ... i dont develop on it
<rob^^^> ogra: it will definately be faster than PEARPC ;)
<ogra> its cheap ... 
<rob^^^> not having firewire ports is kinda a downer though for real use
<ogra> thats all i need ... and i can use it as thin client for ppc tests too 
<rob^^^> what's a MINI run over there?
<rob^^^> having a 128 meg machine for thin-client could be an asset I suppose
<ogra> between 4and 500
<rob^^^> ogra: probably the only PPC mac that will ever pass through your fingers eh?
<ogra> nope, my GF has a grey G4 and i had a iMac flowerpower before i gave away ...
<ogra> but my GF does her work on hers, i cant play with install CDs on it 
<rob^^^> oh
<Amaranth> ppc is dead
<ogra> thast why i have to care for it for ltsp ... 
<rob^^^> ogra: is it sawtooth or silverdoor?
<xhaker> users ppc computers are not
<ogra> they will get cheap ...
<ogra> rob^^^, no idea, its grey :)
<rob^^^> the silverdoors have silver reflective doors
<rob^^^> they go all the way up to like dual 1.25 I believe
<\sh> ogra: http://cgi.ebay.de/apple-Mac-Mini-1-25-Ghz-512-40-COMBO_W0QQitemZ8731815198QQcategoryZ99526QQrdZ1QQcmdZViewItem
<ogra> \sh, yes, will be around 700~1000 in the end ...
<ogra> i'd bet
<\sh> ogra: i'll have it on my viewlist
<Hieronymus> My webcam crashes Gnomemeeting, and takes the system with it. What info should I put in a bugreport
<ogra> Hieronymus, http://wiki.ubuntu.com/HelpingWithBugs
<Hieronymus> ogra: well, I know how to file bugs.. but the webcam crashes my system...
<mdke_> Hieronymus, saying that would be a good start.
<ogra> Hieronymus, https://wiki.ubuntu.com/HelpingWithBugs?action=fullsearch&context=180&value=debug&titlesearch=Titel
<ogra> Hieronymus, sorry i had the impression these pages were linked from the HelpingWithBugs page
<stockholm> ogra: ping
<ogra> stockholm, pong :)
<stockholm> ogra: what about dec 17?
<stockholm> ogra: could you come to nrnberg? travel could be payed, i think
<ogra> hmm...
<stockholm> ogra: not by me but by the organizers.
<ogra> lol, i guessed so
<stockholm> ogra: are you familiar with arktur etc?
<ogra> nope 
<stockholm> and the dramas involved? 
<stockholm> i am not deeply initiated either.
<ogra> ah, i remember the guy from essen
<ogra> he's somewhat strange ... 
<stockholm> but i think it could be a good start to cooperation on this front. not just arktur, but others, too
<ogra> and i heard him tell people that edubuntu wasnt for them, they should use his distro
<stockholm> ah, right.
<ogra> as well as skole wasnt for them
<stockholm> and he really is compentent. (c:
<ogra> heh
<stockholm> they came to our mailinglist for some time and tried to diss us (c:
<ogra> i'm not sure if i really want to donate my sparetime to him
<stockholm> is he an old ugly guy? then it is Helmut Hullen and he wont be there.
<ogra> note that my company wont pay for it so it will be in my private time ...
<ogra> yes...
<stockholm> yes, he wont come.
<stockholm> he does not have many friends, for some reason.
<ogra> understandable
* stockholm giggles
<ogra> how is the skole relationship to Arktur ?
<ogra> except him dissing you
<azeem> ugh, Helmut Hullen
<ogra> lol
<ogra> he seems to be well known in the german community *g*
<stockholm> they dont like us because kurt garmlich (know him?) make a great job in marketing and debian-edu is better known then arktur in germany, despite arktur being really old
<stockholm> ogra: there are three forks in arktur, helmut hullen does one of them. the oldest and most broken one
<ogra> i heard his name, but i dont know him
<stockholm> the other two forks will attend.
<ogra> is it woody based ? 
<stockholm> no, it is a mixture of redhat, suse and slackware
<stockholm> i dont know how it works in detail
<ogra> ouch
<ogra> sounds greatly upgradeable and stable :P
<stockholm> yes, very ouch. no security support. and you have to recompile everything or it wont fit in
<ogra> edugentoo ? 
<stockholm> it is a nightmare. 
<ogra> sounds like
<stockholm> but ct supports it
<stockholm> or distributes it
<mdz> mjg59: have you talked with anyone about getting radeontool and smartdimmer into main?
<ogra> give me some days to think about, i'm not sure if i can make some free time ...
<stockholm> ok
<mdz> mjg59: they're tiny; if they're sanely packaged and don't introduce any security concerns it should be straightforward
<ogra> stockholm, why do they do that ? 
<ogra> stockholm, do they get money for promoting it ? 
<stockholm> ogra: historic reasons, i guess.
<ogra> i'd expect more from ct
<michele> I have this problem (solved) where I always get an error when unmountin the ipod shuffle because hal wants to eject it
<stockholm> it used to be the first think like this
<stockholm> ogra: it has quite an install base in germany. 5000 schools or so
<ogra> phew
<michele> I fixed it by setting storage.requires_eject to false in 10-storage-policy.fdi
<michele> it's related to https://bugzilla.ubuntulinux.org/show_bug.cgi?id=2134
<ogra> that'd be worth going ... but i also have ot make mdz happy and finish my work ;)
<michele> I don't know if I should reopen that bug, report something else, or...
<ogra> and i regulary do the stuff thats left from the week on saturdays
<stockholm> ogra: in my oppinion mdz should make time for that. it is directly work related
<stockholm> mdz: ?
<mjg59> mdz: Uhm. I was under the impression that the process was automatic.
<ogra> stockholm, it isnt, my focus is ltsp development and i have deadlines
<stockholm> hrm.
<dholbach> have a nice evening
<ogra> edubuntu wont see much further improvements this release
<ogra> except community contributed stuff but thats just starting slowly 
<mjg59> mdz: The packaging looks sane
<stockholm> i dont know how you work. i think it is import enough for me to travel for a few days.
<stockholm> so obviously i would expect mdz to think similarly
<ogra> stockholm, mdz is and thinks like a CTO, not like a merketing guy ;) (which is important)
<mdz> mjg59: it has never been automatic; http://wiki.ubuntu.com/UbuntuMainInclusionQueue
<stockholm> i dont go there for marketing reasons at all. it is a developer meeting. 
<ogra> hmm
<mjg59> mdz: Ah, right
<stockholm> they explicitly DIDnt want kurt garmlich there, eventhough he is intimatly familiar with the german scene.
<stockholm> because he is not a developer but marketing person 
<ogra> stockholm, as i said, give me some time to think about it ... its before christmas and time is short
<stockholm> sure.
<stockholm> ogra: what was your email? i just got an info mail about the meeting
<ogra> ogra@ubuntu.com
<stockholm> *surprise*
<stockholm> (c:
<ogra> heh
<jelkner> is this an ok place to ask a question about what appears to be a network bug?
<lifeless> jelkner: if you are not asking for *help* with it, but rather how to *help us fix it* - sure ;)
<lifeless> thats the difference between support and development ;)
<jelkner> lifeless: yes, but i somewhere in the middle
<jelkner> i need to ask for help first, to be sure i have a bug to report
<jelkner> (i'm pretty sure i do)
<jelkner> and then i need to figure out which package to file it on
<jelkner> problem: networking does not work after a breezy install on a toshiba satellite m45-s269
<jelkner> the devices (both ethernet and wireless) appear to be recognized, but no connections are possible from either one
<mdz> jelkner: seems a bit fishy that they both fail to work in the same way; I'd look for an external problem first
<jelkner> such as?
<jelkner> i have several other machines on the same network
<jelkner> including a laptop using wireless
<jelkner> the other machines can connect without problem
<jelkner> the toshiba can not
<stockholm> jelkner: some security thing perhaps?
<jelkner> i feel confident it is a problem with the toshiba
<jelkner> nope, *all* security has been turned off
<jelkner> i brought another laptop which i know works to test
<stockholm> jelkner: does it work with other software?
<jelkner> don't know, i guess i could try knoppix
<jelkner> let me do that
<ProN00b> i need to make a 280gig file as fast as i can, the space doesn't need to be allocated and its contents do not matter, any idea ?
<Kamion> ProN00b: dd if=/dev/null of=bigfile count=$((1024*1024*1024)) skip=280
<Kamion> er
<Kamion> ProN00b: dd if=/dev/null of=bigfile bs=1 seek=$((280*1024*1024*1024)) count=0
<Kamion> ignore the first, didn't mean to paste that
<Kamion> (#ubuntu in future though ...)
<feugan3333> Hi all. What is the easiest way to learn how to create kernel modules. On a stock build kernel or on default ubuntu kernel?
<ProN00b> Kamion, count=0 really true ?
<Kamion> ProN00b: yes
<Kamion> I mean, count=1 if you prefer, but count=0 worked for me
<lifeless> so is xpdf meant to be installable with ubuntu-desktop ?
<elmo> you're meant to use evince now
<lifeless> oh. Whats that ?
<elmo> shiny new PDF/PS reader
<lifeless> I've been holding up updates for a week now trying to keep pdf
<lifeless> xpdf I mean
<elmo> but xpdf should install with ubuntu-desktop, FWIW
<lifeless> because all hte other readers I've seen blow donkeys
<elmo> does here anyway - assuming you mean breezy
<elmo> evince is much better than xpdf
<elmo> IMO
<azeem> lifeless: try evince, it is love
<azeem> GNOME love
<ogra> elmo++
<mdke> evince is quite nice
<lifeless> okk, it is installed
<lifeless> I shall give it a whirl
<lifeless> but yes, xpdf seems to depend on pre c++ transition or something funky
<mdke> the text tends to disappear if you click on it
<mdke> otherwise its peachy
<lifeless> it and devhelp
<lifeless> they both try to go away when ever I 'mark all upgrades'
<lifeless> mvo: is there a 'why is this being removed' button in synaptic ?
<mvo> lifeless: no, but you can set "Debug::pkgProblemResolver=true" and see what it outputs. it's not very friendly though 
<lifeless> garh
<lifeless> would such a button make sense ?
<mvo> lifeless: it's something that libapt dosn't provide now. smart will be better in the future
<mvo> lifeless: under Settings/Set internal option
<mvo> set variable to "Debug::pkgProblemResolver" and value to "true"
<mvo> it will give some (more or less) usefull output to clog then
<mvo> if you put it into a pastebin I'll have a look
<Kamion> mdz: it would be nice if the head entry of debian/changelog in your casper/main branch had some informative contents - it doesn't describe unionfs at all
<Kamion> mdz: are you planning to release that to dapper? I know we're replacing a lot of it, but it would be nice to know which one I'm supposed to branch off for trivial changes
<Kamion> (which one> main or breezy that is)
<ogra> Kamion, always main 
<ogra> i asked the same about ltsp ;)
<Kamion> well, casper probably needs an upload soon to get the live CD working again for Flight CD 2, and I don't want to suck in the unionfs code if it's insufficiently tested yet
<ogra> well, yur decision, i was told breezy is done and the branch is there for historical reasons but unmaintained, might be different with casper
<Kamion> it's mdz's decision, that's why I'm asking him :)
<ogra> indeed :)
<Kamion> mdz: speaking of, please merge http://people.ubuntu.com/~cjwatson/bzr/casper/fixes, just a small tweak
* mvo goes to bed
<lamont__> infinity/elmo: anyone look at daily-di yet?
<elmo> lamont: see kamion's response
<elmo> lamont: (i.e. he has)
<lamont__> good
<\sh> grmpf
<mdz> Kamion: hmm, yes, I forgot to update changelog when merging Tollef's branch. done now
<Kamion> ta
<Kamion> heh, current live CD fails at nic-restricted-modules - d'oh
<mdz> Kamion: /fixes merged also, pushing now
#ubuntu-devel 2005-12-11
<\sh> elmo: please sync konserve from unstable, dropping ubuntu changes,thx
<Kamion> mdz: hmm, 'bzr log' shows repeated changesets again from the previous merge - maybe 'bzr fix'?
<mdz> Kamion: bzr fix crashes
<Kamion> whee
<mdz> ogra: update-rc.d remove is inappropriate for ThinClientFasterStartup because the links will be restored on upgrade
<ogra> so i have to remove the packages completely then, ok
<ogra> its a bit harder but will work too ...
<ogra> i was planning to make a positive list and remove everything thats not in the list ...
<mdz> ogra: no, you need to remove the startup links
<ogra> you mean a plain rm ? 
<mdz> yes
<ogra> oki
<mdz> ogra: does X autoconfiguration seriously take 30 seconds on any hardware you have available?
<mdz> it is about 5 seconds here
<ogra> yes
<ogra> on your laptop ? 
<mdz> yes
<mdz> which is a 1.5GHz pentium M
<sorush20> guys how do I get this package to be added to the graphics packaged in the development pachage lists? 
<ogra> yes, on my amd64 3000+ its very fast
<sorush20> http://www.path.unimelb.edu.au/~dersch/
<mdz> on a 100mbit switched network
<ogra> but thats exceptional for thin clients
<mdz> sorush20: https://wiki.ubuntu.com/UniverseCandidates
<ogra> i dont think thats network dependent at all
<mdz> well, loading the X server and all its modules over the network takes some time
<mdz> plus perl, etc.
<ogra> its the probing that takes the time ... all appr should be in mem at this point
<ogra> s/appr/apps/
<mdz> unless it's a laptop LCD, the X server won't even be loaded at that point
<ogra> wait a sec
<mdz> it just scans the PCI bus with discover and uses debconf
<ogra> i'll upload the recent bootchart from today
<mdz> oh, that would be good
<ogra> http://people.ubuntu.com/~ogra/edubuntu/dapper-20051205-1.png
<ogra> grumbel ... my system is darn slow without DMA ...
<ogra> compared with http://people.ubuntu.com/~ogra/edubuntu/breezy-20051113-1.png its a lot faster ...
<ogra> but still not the 45sec i want ...
<ogra> according to Keybuk we robably can achievethe 15 sec with his future fixes
<mdz> ogra: the ltsp guys have no problem with using esd -public?
<ogra> nope
<ogra> they do it as well
<mdz> if I were a student in a class which used that, I would play sounds through other students' thin clients to get them in trouble ;-)
<ogra> i also was at linuxtage essen this weekend and talkeda lot to the skole people, they do it too
<mdz> the alternative would be to send the esd auth cookie in an environment variable
<mdz> which would require an esdlib patch
<ogra> there is no other way to make esd listen on the net :/
<ogra> yes
<mdz> esd can use its usual authentication over the network
<tseng> mdz: you would be the kid that MiM his ssh X tunnel and made bad pictures come up in a browser on his screen
<ogra> most teachers tell me they will disable it anyway, because it will be distracting
<mdz> but if everyone else is doing this, we can try it as a first cut
<ogra> and encourages kids to download mp3s
<mdz> tseng: except that the real me foiled that attack by stashing the server's ssh host key ahead of time
<ogra> heh
<mdz> ogra: it will be disabled by default
<ogra> oh, i wanted enable it by default ... and make disabling optional
<mdz> we should disable it by default; if I'm not mistaken, that's what ltsp does as well
<ogra> btw, seems the X_MOUSEDEV patches dont work at all for serial mice... i had several people that tried it ... will get a serial mouse myself as soon as i can find one ...
<mdz> ogra: it looks like those debconf-communicate calls take a long time; we should collapse them into a single invocation
<mdz> I think the MOUSEDEV stuff came from pere or vagrantc
<ogra> as well as the colordepth patches from pere cant work with our xorg
<ogra> i talked to daniels about it
<ogra> as long as seen is set in debconf, it won be touched at all ... but he wanted to make a ENV var available
<ogra> it would break the autodetection if we'd change the dbeconf behavior if i undrstood him right
<ogra> but 16bit by default is essential
<ogra> else we'll eat all mem ...
<Keybuk> ogra: still haven't tracked down what causes that no-DMA issue; it affects you too?
<ogra> i'm astonished the mouse stuff doesnt work ... a shame i cat test myself
<ogra> Keybuk, yes, but the driver is loaded fine
<mdz> ogra: thin client memory usage approved
<ogra> ut since my lappie already has a 4200rpm drive its really a pain :)
<ogra> YAY
<Keybuk> ogra: yeah, that's the same thing mdz sees
<Keybuk> ogra: are you around tomorrow AM (UTC) for some hot debugging action?
<ogra> sure :)
<mdz> ogra: in ThinClientAudioSupport, you removed my comment about esddsp but didn't address it
<mdz> Keybuk: I can trace first-hand what happens; I just don't understand why it didn't happen before
<mdz> Keybuk: have you checked with BenC if something changed in kernel-land
<Keybuk> he didn't seem to think anything did, kay had no idea either
<mdz> Keybuk: is it expected that ide-disk isn't loaded when piix loads?
<Keybuk> do you concur that we're loading the right modules, but the module isn't claiming the disk and ide-generic is instead?
<ogra> mdz, because the ssh_remote_commad hac worked so well... i'll look at esddsp again
<Keybuk> tbh, I'm not sure ... I think mine does the same thing, and only loads ide-disk once ide-generic is loaded _except_ that for some reason, the right driver claims the disk
<mdz> ogra: you are basically reimplementing esddsp on the command line
<ogra> but i have to set ESPEAKER= anyway 
<ogra> so we wont get around this hack
<mdz> ogra: esddsp is a lot better than setting LD_PRELOAD on the command line
<ogra> yes, thats true, but i have still to add ENV vars ... so we'll have to make changes in two places instead of one ...
<mdz> ogra: give it a try, update the spec for that, and it is ready for approval
<mdz> ogra: no, it's still in one place
<ogra> oki
<ogra> i'll update it before the next dev meeting ...
<BenC> are we talking about cdroms?
<ogra> BenC, nope
<ogra> harddisks
<BenC> ok
<mdz> just remove the LD_PRELOAD stuff, remove ESDDSP_MIXER, and use esddsp -m
<ogra> Keybuk, -generic isnt loaded here 
<ogra> oki
<mdz> ogra: it'll look like this:
<Keybuk> ogra: ide-generic being loaded is hard-coded into the script <g>  if it's not loaded, you've been playing silly buggers :D
<mdz> ogra: ['env', ..., 'esddsp', '-m', session_manager, ...] 
<ogra> ah, k
<ogra> that doesnt require ESPEAKER ??
<mdz> ESPEAKER is still required
<ogra> that what i thought
<mdz> well
<mdz> or you could use esddsp --server
<mdz> that is probably clearer
<ogra> yup
<mdz> ogra: also, why mess with amixer?
<mdz> the alsa init script does a better job
<ogra> its full volume here if i dont do anything ...
<ogra> thats *very* loud
<mdz> it should have exactly the same volume as if you booted the live CD or installed ubuntu
<ogra> and thats what ltsp.org does as well btw
<mdz> which is 80%
<mdz> on most cards
<ogra> hmm, then i'll have to inspect this
<mdz> but the script has logic to set an appropriate level, and you should use it
<ogra> yes, might also be 80% but y next neighbor hears it (150m away) if my window is open in the office
<ogra> at least on the ltsp client i have here its to loud ...
<Keybuk> mdz, ogra: when you do "udevplug -Bpci -Iclass=0x01*" at break=premount ... can you recall which modules are loaded?
<ogra> ide-disk and the via driver iirc
<mdz> Keybuk: I did that test on friday
<Keybuk> mdz: can you recall the output?
<mdz> I believe I got only piix and deps
<ogra> via82cxxx
<mdz> no ide-disk
<mdz> will try again now
<Keybuk> ide-core, piix and "generic" ?
<ogra> oh, and -generic 
<Keybuk> easiest way to tell is to do UDEV_LOG=info udevd --daemon
<mdz> actually, will try again after upgrading the laptop
<Keybuk> then read the output
<Keybuk> heh
<ogra> oh, intresting 
<[g2] > Anyone from the installer team around ?  I'm wondering about an embedded installer (XScale target)
<ogra> i suddenly can switch on DMS
<ogra> DMA
<jbailey> [g2] : We don't have any embedded targets atm.
<ogra> i didnt try since todays upgrade
<jbailey> [g2] : So, no arm binaries in Ubuntu at this point.
<ogra> Keybuk, so it works again at least, its just not on by default
<[g2] > jbailey that's ok, I've got an XScale target and they 13.5K debian packages are ported to it
<[g2] > s/debian/Debian
<Keybuk> ogra: I still suspect you've not got the right association to your driver
<jbailey> [g2] : Right.  But we don't inherit the binaries from Debian, only source packages.
<jbailey> [g2] : So there's no Ubuntu arm binaries that you can use.
<[g2] > jbailey right, two of my buddies build all the packages form source
<jbailey> [g2] : https://wiki.ubuntu.com//%c2%b5buntu has some info on where it's heading, but we're not there yet.
<[g2] > jbailey I know. I'm ahead of you
<Diablo-D3> hrm
<[g2] > I talked with Jeff W. after the trilug meeting about it
<Diablo-D3> kernel is built with gcc4 now, right?
<ogra> Keybuk, lsmod looks like it looked in breezy ... i just habe the prob that DMA is off
<ogra> *have
<Diablo-D3> ooh
<Diablo-D3> and new X
<Diablo-D3> <3
<Keybuk> ogra: right
<Keybuk> ogra: could you do # readlink /sys/bus/ide/devices/0.0 for me
<ogra> ../../../devices/pci0000:00/0000:00:11.1/ide0/0.0
<ogra> all for you :)
<Keybuk> ok
<Keybuk> also
<Keybuk> readlink /sys/devices/pci0000:00/0000:00:11.1/driver
<mdz> Keybuk,jbailey: any reason not to add lsmod to initramfs for debugging?
<\sh> ok...I'll give up...
<mdz> it must be laughably small
<Keybuk> mdz: cat /proc/modules is the same thing ... though I have no problem with lsmod being there
<mdz> Keybuk: it is close but it is a lot more typing
<mdz> and I don't have a keymap in initramfs
<Keybuk> Colin is currently my hero for adding readline support :p
* ogra got used to cat /proc/modules after cursing two days about missing lsmod :)
<Keybuk> ogra: what was the output of the second readlink?
<ogra> ../../../bus/pci/drivers/PCI_IDE
<ogra> sorry
<Keybuk> thanks ... # ls /sys/bus/pci/drivers
<ogra> agpgart-amd64  ohci1394         r8169     VIA 82xx Audio  vt596_smbus
<ogra> ehci_hcd       parport_pc       serial    VIA 82xx Modem  yenta_cardbus
<ogra> nvidia         pcieport-driver  shpchp    VIA_IDE
<ogra> nvidiafb       PCI_IDE          uhci_hcd  via-ircc
<Keybuk> what model laptop is yours?
<ogra> acer aspire 1520
<ogra> amd64, nvidia card and 512MB
<Keybuk> mdz: yours is an IBM T42?
<mdz> Keybuk: yep
<mdz> ok, from break=premount
<mdz> I did UDEV_LOG=info udevd --daemon
<mdz> and udevplug -Bpci -Iclass=0x01*
<mdz> I get one modprobe and a bunch of has_drivers
<jbailey> mdz: No real objection.
<Keybuk> ok
<mdz> and when the dust settles, I have piix, ide_core and 'generic' loaded
<Keybuk> that modprobe is for pci:bllaaaaah
<mdz> correct
<Keybuk> then if you modprobe ide-generic, you get a whole frat-party of events?
<mdz> yes, I did that before
<mdz> do you want me to try it now or check something else first?
<Keybuk> could you do that now, so I can get the readlink outputs on yours
<Keybuk> (I'm composing an e-mail to the IDE list first)
<mdz> ok, gobs of events
<mdz> more than console scrollback worth
<Keybuk> right
<Keybuk> readlink /sys/bus/ide/devices/0.0
<mdz> ../../../devices/pci0000:00/0000:00:1f.1/ide0/0.0
<Keybuk> readlink /sys/devices/pci0000:00/0000:00:1f.1/driver
<mdz> ../../../bus/pci/drivers/PIIX_IDE
<Keybuk> oh, now that's interesting
<mdz> well, I'm not testing exactly the same code as before
<mdz> perhaps I should continue the boot and see if DMA is still b0rked
<Keybuk> what code has changed?
<Keybuk> sure ... just press ^D to continue the boot
<Keybuk> (COLIN IS A HERO)
<mdz> Keybuk: that one was me, actually ;-)
<Keybuk> oh, was that you?
<Keybuk> then you are also a HERO
<mdz> interesting, I got a DEVPATH missing message from udevd
<[g2] > jbailey thx for the URL
<mdz> just after ext3 loaded it looked like
<Keybuk> that's kinda interesting
<mdz> anyway, since friday I've got new initramfs and new kernel I think
<jbailey> [g2] : Glad to help.  I'm just running out.  I'd love to chat more about it another time, since I'm interested in the buntu project.
<mdz> hah!
<mdz> Keybuk: using_dma = 1
<jbailey> [g2] : I'm jbailey@ubuntu.com if you want to chat more.
<mdz> lemme do a default boot
<Keybuk> could've been a kernel bug then ...
<[g2] > jbailey cheers
<Keybuk> if this is another one of those annoying races though, I'm going to get grumpy
<tseng> [g2] : !
<[g2] > hey!
<tseng> [g2] : i was just looking for you the other day
<mdz> Keybuk: using_dma = 1
<Keybuk> mdz: could you keep a close eye on that every time you reboot?
<Keybuk> at least for the next few times, anyway
<Keybuk> BenC: were there any piix driver changes recently?
<BenC> not that I know of, but I can check
<BenC> ata or ide?
<Keybuk> ide
<mdz> Keybuk: my boot time is back down to pre-bootchart pre-new-udev-world-order levels
<mdz> Keybuk: http://people.ubuntu.com/~mdz/bootchart/dapper-20051205-1.png
<mdke> is there any particular place that those of us who can't usefully debug our bootcharts should be uploading them? perhaps wiki pages?
<BenC> Keybuk: piix.c hasn't been touched except to allow it to be modular
<Keybuk> mdz: that's better ... you'll benefit a lot from moving ifup back into hotplug events by the looks of it
<BenC> maybe the modular changes are broken, did it ever work in 2.6.15?
<mdz> Keybuk,BenC: I'll boot .15-5 again for kicks
<tseng> elmo: please sync libapache-mod-musicindex. dropping changes
<mdz> Keybuk: is readahead still fucked?
<BenC> that modular change was in -1.1, so it's always been there
<ogra> mdz, woah, over a minute ? 
<ogra> my lappie is ~50 sec even with a slow HD
<Keybuk> mdz: I have a tool to generate new lists now, going to play follow-the-lady with rcS tomorrow and wednesday and upload new readahead with that
<Keybuk> http://www.ussg.iu.edu/hypermail/linux/kernel/0512.0/0669.html
<Keybuk> ^ mmmm
<ogra> the intro text is worrying
<Keybuk> heh
<Keybuk> why?
<Keybuk> SATA != IDE
<mdke> Keybuk, any idea on my question above (at 00:04)?
<ogra> yeah, but testing IDE with a cf reader due to lack of HW makes me worry about the ide implementation
<mjg59> Keybuk: That's nice and easy
<Keybuk> mdke: there is no particular place, upload them anywhere you like and attach them to reports of bugs or mail them to the users list, etc.
<mjg59> ogra: The patch is trivially obvious(tm)
<BenC> the change to piix.c is so minimal it couldn't affect operation
<mdke> Keybuk, okay, the users list?
<BenC> it has like a couple of lines for module exit, and that's it
<Keybuk> BenC: I've heard that before <g>
<Keybuk> mjg59: the subsystem maintainer is having a sulk though
<mjg59> Keybuk: Bart?
<Keybuk> yeah
<mjg59> Oh, Broadcom wireless stuff is now usable with a bit of fiddling
<mjg59> So we'll certainly be shipping with support
<segfault> hotplug dropped from dapper?
<Keybuk> segfault: keep up <g>
<Keybuk> mjg59: bitched about the missing ide-scsi and ide-optical stuff
<desrt> segfault; hopefully.
<segfault> whats replacing it?
<desrt> udev
<desrt> and the kernel netlink socket
<Keybuk> which is probably a good census of people who use them, because neither the Debian, Ubuntu or SuSE ide helpers load those modules <g>
<mjg59> Keybuk: Well, tough
<Keybuk> segfault: udev has entirely replaced it
<mjg59> Heh
<Keybuk> all of the hotplug scripts have been replaced by the command
<Keybuk> "modprobe $MODALIAS"
<desrt> no more kernel shelling out to /sbin/hotplug
<Keybuk> welcome to the revolution, baby
<segfault> heh
<ogra> hehe
<Keybuk> <fx: voodoo child intro>
<desrt> does that make modules.conf the right place to blacklist these days?
<Keybuk> desrt: yes.
<desrt> excellent!
<segfault> any sound handling changes in dapper?
<Keybuk> segfault: not yet, they're on my tofix list :p
<segfault> i have no sound here, although the snd-intel8x0 is loaded
<segfault> its quite weird
<Keybuk> yeah, you'll probably find the OSS driver has STOLEN YOUR SOUND
<ogra> evil
<segfault> heh, exactly
<mjg59> Wow. I hadn't realised just how easy writing a libata-based PATA driver is
<Keybuk> mjg59: you now need to cackle manically
<Keybuk> as if writing a libata-based PATA driver was the key to world domination
<mjg59> You provide a setup function, a table of function pointers and some functions that set the timing
<mjg59> Utter win
<ploum> lol :-)
<ploum> Just look at the changelog of libcairo2
<ploum> "* debian/patches/02-no-ft-glyphslot-embolden.patch:
<ploum>      - not required."
<ploum> not required...  Thus now every gnome application fail with : "symbol lookup error: /usr/lib/libcairo.so.2: undefined symbol: FT_GlyphSlot_Embolden"
<ogra> not here
<Keybuk> ploum: "required" and "used" are different words
<ploum> ogra : you don't have this on a dapper install ?
<ogra> nope
<ogra> all fine here
<ploum> so maybe it's me...
* ploum try to think what it can be
<ploum> found
<ploum> sorry, it was (as always) my fault ;-)
<ogra> :)
<ploum> (libfreetype6 not upgraded)
<ogra> yup thete is a lot fuss about the freetype stuff currently ...
<ploum> I will suggest to seb128 that the package libcairo2 must depend of libfreetype6 >= 2.1.10
<ploum> Do you think it worths a bug ?
<ploum> (or things are moving so quickly that it doesn't matter?)
<ploum> I don't know anything about freetype. Exciting new stuffs ?
<ploum> good night
<Diablo-D3> hrm
<Keybuk> ogra: around?
<ogra> yup
<ogra> sure :)
<Keybuk> the laptop with the via chip, can you debug some stuff with that while you IRC from another machine?
<ogra> hmm...
<ogra> i have to save some stuff
<mjg59> Keybuk: I've got a VIA laptop here, if you have a general via problem that needs debugging
<Keybuk> mjg59: is it running dapper?  the problem is that the IDE chipset doesn't probe for or register the devices
<mjg59> Keybuk: Ah. No, it's on Breezy.
<Keybuk> don't suppose you know a way of getting dmesg output without /bin/dmesg ?
<ogra> give my evo 2min (it needs it to close)
<mjg59> Keybuk: cat /proc/kmsg
<Keybuk> ahh, of course
<mjg59> Oh, except that doesn't seem to give the current contents of the buffer
* ogra_ twiddles thumbs
<ogra_> Keybuk: ok
<ogra_> reboot with break=premount ?
<Keybuk> yup, please
<Keybuk> then run scripts/init-premount/thermal to stop your laptop burning up
<ogra_> heh ... will do
<ogra_> done
<Keybuk> right
<Keybuk> udevd --daemon
<Keybuk> udevplug -Bpci -Iclass=0x01*
<Keybuk> (wait about 10-15s)
<ogra_> ok
<ogra_> hmm the fan is still running
<Keybuk> that's ok
<Keybuk> think that should be enough of a wait
<Keybuk> now modprobe ide-generic
<Keybuk> and wait another 10-15s
<ogra_> done ...
<Keybuk> ok, then hit ^D ... and once booted, send me your /var/log/dmesg
<ogra_> ouch ...
<ogra_> udevd socket: illegal seek
<ogra_> and some other failures
<Keybuk> yeah, that's ok
<Keybuk> also mail me output of lspci -vvv
<elmo> Kamion: around?
<ogra_> Keybuk, on its way
<Keybuk> thanks
<ogra_> whee ...
<ogra_> using_dma = 1
<ogra_> hmm .... what changed ?
<mdz> Keybuk: when do you expect to have a new udev upload ready?  sounds like you have a bunch of fixes queued up
<ogra> hmm, 4:41 ... not a nice bootchart :p
<Keybuk> mdz: tomorrow AM
<ajmitch> heh
<ajmitch> that sounds a little slow
<ogra> it has the human factor ;)
<ogra> (which indeed doesnt show up in the chart)
<Keybuk> don't you have a long ogra bar in the gaps?
* ogra checks
<Keybuk> ... bed time for you, dude
<ogra> heh, yes 
<ogra> dog time before :)
<Diablo-D3> has anyone booted with 2.6.15.2-2?
<ogra> why should we, thats old cruft
<ogra> 6.8 is recent
<Diablo-D3> ogra?
<ogra> wahhh ... oo.o looks worse than yesterday in my cdimage report :/
<ogra> Diablo-D3, 2.6.15-6.8
<Diablo-D3> argh, thats out now?
<Diablo-D3> when did that happen?
<ogra> thats sone days (1-2) old
<Diablo-D3> wtf!?
<ogra> *some
<Diablo-D3> wait, does restricted modules have a seperate version number?
<ogra> its from Thu,  1 Dec 2005
<ogra> linux-restricted-modules-2.6.15 2.6.15.2-2
<Diablo-D3> yup it does -_-
<Diablo-D3> hrm
<Diablo-D3> I wonder when dapper will get xorg 6.9-rcx 
<Diablo-D3> or this mystical godlike 7.0 everyone is talking about
<minghua> huh? aren't we using 7.0-rc now?
<tseng> we are
<Diablo-D3> the one thats supposed to cure cancer and bring peace to the middle east
<Diablo-D3> diablo@infinity:~ $ apt-cache show xserver-xorg | grep Version
<Diablo-D3> Version: 6.8.2-77
<crimsun> that's a dummy package.
<Diablo-D3> ... hrm.
<crimsun> Look instead at xserver-xorg-core
<Diablo-D3> Version: 1:0.99.3-0ubuntu6
<Diablo-D3> so thats not quite helpful either
<crimsun> X Window System Version 6.99.99.902 (7.0.0 RC 2)
<crimsun> just head the log
<Diablo-D3> ... lol I guess I could do that
<Diablo-D3> I gotta go figure out why control-+/- doesnt work anymore
<bmonty> elmo: please sync stardict from unstable, ok to drop ubuntu changes, thanks
<ryanpg> so I'm told the two lists to join if testing dapper are ubuntu-devel and dapper-changes yes? and are there others?
<ajmitch> ubuntu-devel-announce
<ryanpg> k
<Diablo-D3> The Matrix-XP, funny as hell: http://www.uni-duesseldorf.de/~ricke/matrix_xp/mxp_engl_l.zip
<stub> Launchpad will be going down in 30 minutes time, which will also put the Ubuntu wikis into read only more. Estimated down time is 30 minutes.
<desrt> stub; good luck.
<Diablo-D3> now only if ubuntu bugzilla died too
<LaserJock> stub: so the wiki.ubuntu.com will be read only for 30 min.?
<stub> LaserJock: With luck, yes
<LaserJock> stub: ok, I guess I will wrap up my editing ;-)
<ajmitch_> morning sabdfl 
<sabdfl> hia ajmitch_
<sabdfl> erk
<SEJeff> ogra: ping
<sabdfl> EST not yet working for me
<SEJeff> May I ask why my bug was closed on xscreensaver being reverted to the old dialog? It seriously takes away from the polish that I always brag on ubuntu for
<LaserJock> SEJeff: yeah, I know what you mean. I was like "ewww" when I saw that the Ubuntu dialog was gone
<Amaranth> I can't wait to get DSL again.
<sabdfl> SEJeff, LaserJock, i expect it's just a merge from debian that needs to be cleaned up. we are testing gnome-screensaver too
<Amaranth> This dialup connection is going down more than <insert insult>
<SEJeff> I wouldn't be angry if the bug wasn't immediately closed with a "this isn't a bug" http://bugzilla.ubuntu.com/show_bug.cgi?id=20522
<ispiked> desrt: ping
<desrt> hello.
<desrt> you're the guy who filed the battstat bug.
<ispiked> desrt: I am. :)
<desrt> i just wrote a patch against HAL to fix it
<desrt> wanna test?
<ispiked> desrt: tried to PM you, but freenode is blocking those from non-reg. users.
<desrt> ispiked; freenode is evil.
<ispiked> derekS: hrm... possibly. I was just going to ask why it doesn't read form "charging state: ".
<ispiked> like as a last resort or something.
<ispiked> damn.
<ispiked> sorry derekS.
<desrt> because it incorrectly assumes that the values it is provided with will be sane/correct :)
<desrt> (which is incorrect in your case and many others)
<desrt> the correct place for all of these work-arounds is in hal, though
* ispiked thinks it should check the charging status first, then use the rate to determine the %.
<ispiked> I thought I was using HAL, according to the troubleshooting part.
<desrt> it's not so easy... the inside of battstat is a bit archaic
<desrt> it was made to support apm/acpi backends directly
<desrt> as such it doesn't have an idea of batteries 'charging' or 'discharging'
<ispiked> alright.
<Diablo-D3> desrt: eww
<desrt> all it has is 'charging' and a zero or non-zero rate for discharge
<fabbione> morning all
<desrt> fabbione; word.
<ispiked> desrt: fwiw, I haven't tried the cvs version of batstat to see if the bug exists there.
<desrt> ispiked; very little has changed
<desrt> ispiked; school has been kicking my ass lately... very little time for freesoftware
<desrt> ispiked; (which is why it took me so long to respond to your bug)
<Diablo-D3> desrt: thats easy to fix!
<Diablo-D3> quit school!
<ispiked> desrt: hopefully I can say the same as you next semester. :)
<desrt> 4 more months.
<ispiked> I've been slacking off waaaay too much. (first sem. or college)
<desrt> jan-april is my last term as an undergraduate
<mjg59> desrt: I've just submitted a patch for gdm, and I'm about to upload a new g-p-m that takes advantage of it
<desrt> mjg59; elite.
<desrt> mjg59; you know that gdm is maintained by queen elizabeth the second, right?
<ispiked> mjg59: this related to me and desrt conversation?
<desrt> ispiked; not really
<mjg59> desrt: So I noticed
<mjg59> So I've just put it in the Ubuntu bugzilla for now, and Seb can deliver it next time he's in London
<Diablo-D3> wtf?
<Diablo-D3> <desrt> mjg59; you know that gdm is maintained by queen elizabeth the second, right?
<ispiked> desrt: anyway, how would I install batstat after compiing from cvs with the new patch applied?
<Diablo-D3> wtf?
<desrt> :)
<desrt> ispiked; the patch is against HAL
<ispiked> desrt: hrm...
<desrt> oh.  i should probably provide you with an actual copy of the patch :)
<desrt> http://desrt.mcmaster.ca/random/hal-rate.patch
<desrt> ispiked; apt-get source hal
<desrt> ispiked; then toss the patch into the patches dir
<desrt> ispiked; and dpkg-buildpackage
<desrt> ispiked; if all goes well you can then dpkg -i the resulting .deb
<Diablo-D3> http://bugzilla.ubuntu.com/quips.cgi?action=show
<Diablo-D3> hehehehee
<Diablo-D3> scroll to the bottom
<desrt> cute.
<Diablo-D3> we really need a qdb setup for feenode
<desrt> Diablo-D3; i didn't make that up :p
<ispiked> desrt: dpkg-checkbuilddeps: Unmet build dependencies: cdbs libdbus-glib-1-dev (>= 0.35.2-0ubuntu3) libsysfs-dev libcap-dev doxygen intltool (>= 0.22)
<desrt> ispiked; sudo apt-get build-dep hal
<desrt> ispiked; also, fakeroot dpkg-buildpackage
<desrt> ispiked; and in order to get the patch to apply cleanly you'll have to erase the first bit that modifies the ChangeLog
<ispiked> fakeroot?
<desrt> dpkg-buildpackage needs to (think that it is being) run as root
<desrt> fakeroot fakes it
<desrt> i think it has to do with being able to assign correct ownership to the files contained inside the .deb
<Amaranth> err, i think i don't know how to read bootchary
<Amaranth> bootchart
<desrt> Amaranth; time flows left to right
<Amaranth> because it looks like this guy is booting suse into a usable kde desktop in 15 seconds
<desrt> Amaranth; the bar is when a process is active
<desrt> got a url?
<Amaranth> http://www.kdedevelopers.org/node/1664
<ispiked> desrt: Trying patch debian/patches/hal-rate.patch at level 0...1...2...failure. :(
<desrt> ispiked; did you remove the changelog part?
<Amaranth> i guess KDE startup spends 1/3 of it's time in the linker
<ispiked> desrt: yeah. let me double check.
<Amaranth> they should love meeks' -Bdirect patch
<desrt> Amaranth; this is just for logging into kde
<Amaranth> oh
<Amaranth> from kdm to usable desktop?
<desrt> from invocation of 'startkde' to usable desktop
<Amaranth> 15 seconds is horrible then
<Amaranth> i guess that includes X though
<ispiked> desrt: http://rafb.net/paste/results/70Ek5A44.html
<desrt> ispiked; err. are you in breezy?
<ispiked> desrt: yes. :(
<desrt> eep.
<desrt> that patch definitely won't work with breezy
<ispiked> desrt: I can install dapper, but not tonight.
<desrt> ispiked; you could try and manually merge the patch in
<desrt> ispiked; but it's a freakin' minefield in there
<ispiked> desrt: that, too.
<ispiked> desrt: what do you mea?
<desrt> ispiked; martin and i backported so much crap into breezy's hal :/
<ispiked> desrt: oh. :(
<desrt> and a lot of it modifies that file and that function in particular
* ispiked looks into upgrading to dapper.
<desrt> don't do it just for testing a dumb patch :p
* Amaranth looks at topic
<Amaranth> they aren't joking
<desrt> heh.
<Amaranth> my vmware player image stopped doing snapshot loading and the kernel is fubar
<desrt> "dapper is actually fine here"
<desrt> ok ya.. the kernel is interesting to say the least
<ispiked> desrt: your patch makes sense, I'm willing to bet it'll work. :P
<desrt> ispiked; i hope so :)
<desrt> ispiked; i've mailed it off to the HAL folks to ask if i can commit it
<Amaranth> wow, i've been connected more than 5 minutes
<Amaranth> i think my dialup stopped sucking for the night
<mjg59> Hmm.
<mjg59> Other than something quite horrible happening in the kernel, that seemed to work
<mjg59> Hurrah. Objective achieved without having to patch hal at all.
<mjg59> Now I just need to worry about the KDE case. And the XFCE case. And, oh well.
<desrt> from my understanding hal is suitably neutered by its not running as root
<desrt> pitti++
<mjg59> gdm, however...
<mjg59> I've added two lines to gdm to check that the person requesting the suspend is on the current VT
<mjg59> Which sorts out the idle suspend thing
<desrt> probably even an improvement compared to what we had before
<Diablo-D3> http://rss.slashdot.org/Slashdot/slashdot?m=2286
<Diablo-D3> took long enough for slashdot to pick that story up
<mjg59> Hm.
<mjg59> So it works fine if I disable screen locking, but otherwise takes ages
<mjg59> Which sounds like some sort of dbus breakage
<zakame> rainy afternoon all :)
<Diablo-D3> I wonder when women will think geeks are desierable.
<LaserJock> probably when geeks stop thinking they are desirable. ;-)
<Diablo-D3> LaserJock: we dont.
<Amaranth> Diablo-D3: When they realize geeks make large piles of money.
<Diablo-D3> Amaranth: except most of us dont
<Diablo-D3> I sure as hell dont
<dholbach> good morning
<yi> daniels: i see that the xmodmap stuff was fixed in xorg 7.0RC3, is that coming to dapper anytime soon?
<Amaranth> let's hope xorg does a mozilla and has rc3 end up being final ;)
<yi> i don't think so, if you take a look at the master bug tracker there are quite a few still outstanding
<Amaranth> shh!
<Amaranth> let me dream
<pitti> Good morning
<ajmitch_> morning pitti 
<pitti> Hey ajmitch_, how are you?
<ajmitch_> good, yourself?
<dholbach> hey pitti
<pitti> fine
<pitti> Hi dholbach 
<infinity> Oh boy, new NVIDIA drivers!
<infinity> Hot on the heels of me, like, updating the drivers.
<infinity> <sigh>
<infinity> Timing.  Mine.  Sucks.
* dholbach comforts infinity 
<minghua> poor infinity
<infinity> I wouldn't complain, except that updating the orig.tar.gz for l-r-m takes FOREVER on my slow DS lline.
<infinity> Like, over and hour to upload the new tarball after I roll it.
<infinity> s/DS l/DSL /
<infinity> s/and hour/an hour/ too.  Time to go sober up after my Saint Nick celebrations.
<sivang> morning all
<sivang> infinity: who's Saint Nick?
<infinity> Saint Nicholas.
<sivang> infinity: eh
<mantiena> doko, hi
<mantiena> doko, are you near the computer ? I have few question about OpenOffice.org plans in Ubuntu
<doko> ?
<zyga> morning
<pitti> hi zyga 
<sivang> hey pitti 
<sivang> , zyga 
<pitti> hi sivang 
<dholbach> ogra: try the patch from Mithrand1r - he fixed a fileselector amd64 issue
<ogra> dholbach, do you really want to document every observation while working on a package ? 
<dholbach> no
<ogra> you wont come around to do your merges if you have to do paperwork all the time ;)
<dholbach> but judging by the bug report, i thought "he's too busy" and i did the merge on my own
<ogra> i grabbed that bug on thursday or friday ...
<dholbach> ok
<dholbach> sorry, didnt see that
<dholbach> try the patch from 0.75-7ubuntu2
<dholbach> Mithrand1r: fixed a fileselector issue on amd64
<dholbach> oops, drop the ":"
<ogra> ah, i didnt try on other arches yet 
<ogra> thats 40_gcc40_64bit_fixes, right ? 
<dholbach> ogra: should be... i read it in the changelog - check if there's something about fileselector stuff in it
<dholbach> hey mvirkkil 
<dholbach> hey mvo
<ogra> yup, matches
<mvo> hey dholbach !
<seb128> mvo: what did you do to him?
* mvo wonders if he scared him
<seb128> hey mvo :)
<mantiena> hi mvo 
* mvo waves around
<mantiena> :)
<mantiena> mvo, I wanna talk with you about gksu and gdebi backports to breezy (I'm main developer of Ubuntu-based Linux distribution - look at http://baltix.akl.lt )
<mantiena> mvo, could you help me ?
<mvo> mantiena: a start would the mail I send to the backports people. it explains what needs to be done to backport gdebi
<mvo> if you /msg me your mail address, I'll do that
<sivang> morning mvo :)
<mantiena> mvo, my email is mantas@akl.lt, but I think I simply could  read backports mailing list archive, I'm right ?
<mvo> mantiena: hm, good point :)
<mvo> mantiena: http://lists.ubuntu.com/archives/ubuntu-backports/2005-November/000460.html
<mvo> this is where it starts
<mvo> http://lists.ubuntu.com/archives/ubuntu-backports/2005-November/000464.html
<mvo> mantiena: if you backport it, plesae let me know about the feedback from your users. it's still pretty fresh software, I would be interessted in their feedback (and bugs found etc)
<mantiena> mvo, thank you very much
* mvo waves to sivang 
<mvo> mantiena: let me know if you have any other questions :)
<crimsun> elmo: please sync pyserial from Sid (ok to override Ubuntu changes), thanks
<infinity> mvo : I just installed gdebi and tested it on the first two .debs I could find, and the version handling is a bit... Annoying.
<infinity> mvo : No option to force a downgrade or force reinstalling.  I assume that's intentional, but maybe if you hid the force options in the menu or something..?
<mvo> infinity: I can add it, I left it out to minimize the "shoot-in-your-food" risk
<infinity> Nice typo...
* mvo glares at his fingers
* infinity shoots in mvo's food.
<infinity> And yeah, maybe it's best for a pretty GUI tool to not allow too much foot-shooting.
<infinity> OTOH, people downloading random debs and installing them with a GUI are already a bit scary, so we should likely allow them to swap older versions easily, etc.
<mvo> re-install seems to be useful, downgrading ... maybe sometimes (I heard about people using multiple versions of cedega because sometimes a older one works better for a certain game etc)
<infinity> (Say you're downloading someone's pre-packagaged device driver or something, you find out the new one doesn't work well, you want to downgrade to the old package you have...)
<infinity> But I was definitely expecting it to allow me to reinstall.  I had to download something I don't have installed just to test the app. :)
<mvo> infinity: heh :) did you download something that needed dependency resolution too? to give it a bit of a real test ?
<infinity> Granted, Debian policy (and people packaging .debs in general) doesn't really make much noise about downgrading, and it's an "at your own risk" deal, but MOST packages downgrade smoothly anyway.
<infinity> mvo : I will.  Hey, I've only had it installed for 6 minutes. :)
<mvo> downgrading is something that I never liked because of it's potential to break in spectacular ways
<mvo> all the scary things that postins scripts do to "upgrade" stuff 
<infinity> <nod>
<infinity> Hence why I said "most". :)
<mvo> yeah :)
<infinity> But I'm not sure "learn to use dpkg" is the right answer to "I want to downgrade my package" either.
<mvo> yes, agreed. I need to ponder a bit how to present it in the gui
<infinity> So, having force options in the menus (users seem to instinctively know that stuff in menus is "scarier" and more "advanced" than stuff on shiny buttons) might go okay...
<infinity> With blinking warnings when you attempt it.
<mantiena> mvo, I've read your email about gdebi in backports mailing list, but there are no info about backporting gksu :(
<doko> fabbione: that works for me: apt-get install openoffice.org2-core-experimental openoffice.org2-common openoffice.org2-l10n-en-us
<doko> I need the two binary-all packages, or else apt-get complains
<fabbione> doko:
<fabbione> The following packages will be REMOVED:
<fabbione>   firefox firefox-gnome-support gnome-app-install yelp
<fabbione> doko: i will try again later
<mvo> mantiena: oh, you want to backport it not because it's a depedency? but because it's cooler and shinnier than the version in breezy :) ?
<fabbione> perhaps my mirror is still not 100% in sync
<fabbione> but it doesn't explain why ppc install fine
<mantiena> doko, what are OpenOffice.org plans in Ubuntu dapper and breezy backport ?
<dholbach> fabbione: does that system have a bunch of other held back packages?
<mvo> mantiena: well, you will also need to backport libgksu1.2, and libgksuui1.0 (in addition to gksu). but that should be straightforward and only a matter of recompiling the sutff
<fabbione> dholbach: not that i know of
<dholbach> ok
<fabbione> 0 upgraded, 5 newly installed, 4 to remove and 0 not upgraded.
<fabbione> so no
<dholbach> *nod*
<doko> mantiena: make it work
<mantiena> mvo, sort of, users of Baltix distribution wanna have *working* choice between sudo and separate root mode
<mantiena> doko, :)
<fabbione> doko: anyway don't get too much headacke now
<fabbione> i will try to rsync my mirror again
<mantiena> mvo, what about these problems: udo dpkg -i /tmp/libgksuui1.0-1_1.0.7-1_i386.deb
<mantiena> dpkg: considering removing libgksuui1.0-0 in favour of libgksuui1.0-1 ...
<mantiena> dpkg: no, cannot remove libgksuui1.0-0 (--auto-deconfigure will help):
<mantiena>  python2.4-gnome2-extras depends on libgksuui1.0-0
<mantiena>   libgksuui1.0-0 is to be removed.
<mantiena> dpkg: regarding .../libgksuui1.0-1_1.0.7-1_i386.deb containing libgksuui1.0-1:
<mantiena>  libgksuui1.0-1 conflicts with libgksuui1.0-0 (<< 1.0.6-1)
<mantiena>   libgksuui1.0-0 (version 1.0.5-1ubuntu2) is installed.
<mvo> oh, right. python2.4-gnome2-extras will need a recompile as well
<mvo> as well as gnome-system-monitor and gnome-volume-manager
<pitti> oh, right
<mantiena> mvo, maybe I should simply recompile the same versions of python2.4-gnome2-extras, gnome-volume-manager and gnome-system-monitor with backported libgksuui1.0-1-dev ???
<pitti> Hi Keybuk, how are you
<mvo> mantiena: yes, absolutely
* mvo waves to Keybuk 
<Keybuk> heyhey
* Keybuk hugs mvo
<mvo> HUG DAY!
<Keybuk> it's always hug day in keybukland
* seb128 hugs Keybuk
* mvo hugs Keybuk 
* pitti wipes the tears off his eyes
* Kinnison hugs keybuk
<pitti> that always reminds me of soap operas
<siretart> mass hugging?
* Keybuk hugs pitti
* pitti hugs Keybuk 
* ogra hugs both
<mantiena> mvo, maybe gksu from dapper could work with libgksuui1.0-0 after recompilation ???
<TerminX> is there an easy fix for gnome-settings-daemon segfaulting with the xklavier error?  didn't restart GNOME for a couple of weeks, heh...
<pitti> ok, with 169 people in the channel, we need (169*170)/2 hugs
<zyga> pitti: d'oh
<pitti> 14365
<zyga> for persion in... : hug(person) everone
<zyga> (and then discard the duplicates)
<Kinnison> for A,B in everyone.cross(everyone): hug(A,B)
<pitti> Kinnison: that's twice as much as necessary
<pitti> although hugging people twice can't hurt :)
<Kinnison> pitti: More hugs == better
<mvo> mantiena: I'm not sure, it may be worth a try. but IIRC the api changed
<zyga> Kinnison: while 1: hug(everyone) ?
* Kinnison grins
<Keybuk> for (;;) hug (everyone);
<siretart> looks similar to a fork bomb: for(;;) fork(); *g*
<Treenaks> is it hug day again?
<pitti> hug([Person|Others] ) :- hug (Person), hug(Others); hug(Person)
<zyga> heheheh
<pitti> hug(Person)
<pitti> -? hug("#ubuntu-devel").
<Keybuk> what language is that?  Haskell?
<sivang> pitti: what is that?
<pitti> Prolog
<siretart> prolog
<sivang> oh prolog
<zyga> for(;;) if (fork() == -1) hug();
<sivang> pitti: what's that :- thingy?
<pitti> oops, the '; hug(Person)
<pitti> ' was wrong
<mantiena> mvo, btw, could you tell what are main improvements from users point of view in gksu from dapper comparing to gksu in breezy ? Maybe it would be better simply to patch config file in gksu from breezy to use sudo mode as default ?
<pitti> sivang: a query to the problem solver
<zyga> does anyone know Henrik Nilsen Omma?
<ogra> sivang, a smiley without mouth ;)
<sivang> ogra: yes, I Was going to say that - but I was very curious to know if it had some sort of meaning in the language, or pitti had just made a mistake.
<Kamion> zyga: yes, he's a Canonical employee; why?
<pitti> sivang: no, it's just the counterpart of the '$' in shell
<zyga> Kamion: I'd like to talk to him about an interesting project, I could mail him but talking on irc is faster
<ogra> zyga, he's not around, mail him
<zyga> k, thanks
<sivang> zyga: what other world taking plans are you plotting ? :-)
<pitti> sivang: oh, no, sorry; the -? is the prompt; :- is 'reverse implication'
<zyga> sivang: sinister, with bloodbaths and screaming :-)
<pitti> sivang: i. e. "hug([Person|Others] )" is true, when "hug (Person)" is true and "hug(Others)" is true
<mvo> mantiena: just backporting the patch is probably the easiest option
<Keybuk> mmmm, bloodbaths
<Keybuk> tricky, you have to keep them warm, otherwise it congeals and you get a crust
* sivang is reminded about PROLOG configuration files in his AIX. (screams)
<zyga> Keybuk: then with hellfires too
<Keybuk> brimstone makes a good pummice
<zyga> anyway back to work
<sivang> Keybuk: dude, that was ick
<siretart> ((define hug persons) (if (not (eq persons 'nil)) (begin (hug-person (car persons)) (hug (cdr persons))))))
<sivang> siretart: ok, this I can read :) lisp
<zyga> okay now anyone with a Basic or Java hugging around? ;-)
<siretart> sivang: scheme, (a lips dialect)
<sivang> siretart: cool
<zyga> siretart: scheme? I thought scheme has eq?
<pitti> zyga: I could still offer x86 and Atmel AVR assembler...
<zyga> (eq with ?)
<sivang> pitti: Atmel AVR assembler ?
<pitti> sivang: I programmed these a lot during my university times; it's a microcontroller for embedded devices
<mantiena> mvo, you are talking only about gconf patch, which sets default mode to sudo ?
<mvo> mantiena: yes
<sivang> pitti: cool :) 
<mantiena> mvo, hehe, gksu in breezy uses /etc/gksu.conf, not gconf :-P
<mantiena> mvo, maybe you know why kov decided to change simple config file to gconf ?
<tepsipakki> hmm, my gam_server seems to be eating memory (breezy), how could I debug that?
<tepsipakki> after two days it had 1gig
<mantiena> doko, did you tried to build OOo any 2.0.1 prerelease or release candidat on ubuntu ?
<mantiena> tepsipakki, 8-)
<infinity> mantiena : The current OOo2 in dapper is a 2.0.1 pre-release.
<ogra> argh ... why do debian maintainers not use the upstream versioning scheme and make 0.7.5 be 0.75 ? 
* ogra prepares his third kino upload ...
<mantiena> infinity, hehe, I didn't noticed ;)
<Keybuk> ogra: sometimes it's because they think upstream are going to change the versioning scheme
<Keybuk> Debian maintainers go through all sorts of evil hacks to avoid epochs
<ogra> tsk ...
<Keybuk> ie. the Debian udev packages were versioned 0.<upstream>
<Keybuk> which is effectively a 0: epoch anyway
<ogra> i can understand the aim to avoid epochs, but thats just silly
<zyga> epochs?
<Kamion> zyga: <number>: at the start of a version number; is the most significant part of the version number
<Kamion> so 1:0 > 0:99999.9.9
<siretart> zyga: short: run away on sight ;)
<mantiena> infinity, it seems OOo 2.0.1RC was uploaded few hours ago ;)
<Kamion> no, not necessarily
<Kamion> its correct use is when upstream changes their versioning scheme, and you need to recover
<sivang> Kamion: also used to sort version conflicts, or is that wrong?
<Kamion> some people use it for rollback, but that's best avoided, especially when libraries are concerned (because you confuse the hell out of shlibdeps)
<Kamion> sivang: what do you mean?
<mantiena> Who is resposible for changelogs pool  ( http://packages.ubuntu.com/changelogs/pool ) ? it misses almost all changelogs from dapper :( 
<sivang> Kamion: sorry, I think I got the question wrong and confused between another term.
<Kamion> mantiena: packages.ubuntu.com is an unofficial service; there is a contact address listed on its front page
<mantiena> Kamion, ok
<mantiena> Kamion,  frank@lichtenheld.de ?
<Kamion> (well, by unofficial I mean not provided by Canonical, and its maintainer isn't generally here; it's maintained by the same guy who does a lot of the work on packages.debian.org)
<Kamion> mantiena: yes
<Keybuk> gah, I still can't train my fingers not to put the "z" in "xzf"/"czf"/"tzf"
<pitti> Kamion: for tar? :)
<Keybuk> right
<mvo> mantiena: I run the changelog thing
<Kamion> mvo: oh, huh, you run the one on packages.ubuntu.com? sorry, didn't know that
<mvo> mantiena: we have our changelogs at changelogs.ubuntu.com
<mvo> Kamion: no problem, I only dothe changelog bits (because update-manager uses them)
<mvo> Kamion: I don't run packages.ubuntu.com, no
<Kamion> http://packages.ubuntu.com/changelogs/ appears to be != http://changelogs.ubuntu.com/changelogs/; I assume the former is an out-of-date mirror of the latter
<ogra> Kamion, did you already try a livefs build ? just to warn you there seems something wrong with xauth, i cant get a xserver to run on my thin clients over here ...
<ogra> havent found out what it is though
<mantiena> mvo, so, I need to write email to frank@lichtenheld.de and ask him to change changelogs URL in packages.ubuntu packages.ubuntu.com, right ?
<mvo> mantiena: probably, I wonder if we shouldn't purge packages.u.c/changelogs then 
<Kamion> ogra: there are other problems with the live CD
<Kamion> ogra: I haven't got remotely that far yet
<ogra> Kamion, yes, just a warning that there is more broken ...
<mantiena> doko, maybe you know are there some plans to backport OOo 2.0.1 RC or final version to breezy ?
<ogra> i'll try to find out the reason sicne i need my thin clients for testing, but there is no obvious indicator ...
<ogra> mantiena, thats something to ask the backports team :)
<mvo> seb128: why does poppler-utils conflict with xpdf-utils? this makes xpdf more or less uninstallable (without removing a bunch of stuff like cupsys)
<pitti> mvo: file conflicts (/usr/bin/pdf2ps etc.)
<seb128> mvo: ask doko, he didn't those change, I just did the sync
<ogra> mantiena, usually we only care for the upcoming version and apply fixes if the backports team approaches us ...
<mantiena> ogra, ok
<pitti> mvo: but it should replace/provide xpdf-utils
<seb128> s/didn't/did/
<seb128> mvo: why do you need xpdf for?
<seb128> s/why/what/
<mvo> seb128: I don't need it, but I got a mail about it and I think we should still provide it (if possible). I sometimes get better results with xpdf than evince
<doko> mvo: it has the same utilities, yes a provides would be ok
<mvo> pitti: cupsys explicitly depends on poppler-utils
<mvo> doko: so I can change xpdf-utils to provide poppler-utils?
<pitti> mvo: shouldn't it be the other way round?
<doko> pitti: yes
<mvo> pitti: probably. I don't know why cupsys explicitly depends on poppler-utils
<pitti> mvo: to make sure to not use xpdf-utils
<pitti> mvo: and to keep xpdf-utils in universe
<mvo> pitti: ok, but that is probably the root of the problem. if people want to install xpdf now, this require them to remove poppler-utils, this removes cupsys. people will not want to do this
<pitti> mvo: hm, what about changing xpdf to Depends: xpdf-utils | poppler-utils?
<doko> why not have xpdf depend on popple-utils as an alternative?
<pitti> hm, well, a poppler-utils Provides: xpdf-utils should work as well
<opi> Oi
<mvo> pitti: xpdf uses a versionized dependency on the exact version for xpdf-utils. is it wise to add "|poppler-utils" in this case? assuming the xpdf-utils=$ver is there for a reason etc?
<pitti> oh, uh
<mvo> yeah :/
<mvo> pitti: is the cupsys dependency for the upgrade case? 
<pitti> so the provides wouldn't work
<mvo> yes
<pitti> mvo: cupsys needs pdf2ps; debian uses xpdf-utils, we use poppler-utils to confine the code to the poppler lib
<mvo> pitti: would poppler-utils|xpdf-utils in cupsys be a option?
<pitti> mvo: yes,  in this order
<pitti> mvo: how urgent is this? shall I do an upload now just for that?
<mvo> pitti: not really urgend, if you could just remember it for the next upload (I can file a bug too if you want)
<pitti> mvo: I'll fix it here right now
<mvo> thanks!
<pitti> mvo: odd though, I do have xpdf-reader installed
<pitti> mvo: since evince crashes all over the place for me
<pitti> mvo: ah, you tried to install 'xpdf', not 'xpdf-reader', right?
<mvo> yes
<seb128> pitti: could you please send me a backtrace for this evince crasher
<pitti> seb128: will do, using xpdf was just a quickfix when I edited the diploma thesis of my gf
<seb128> pitti: we can't fix issues not reported, and some users are likely to have your issue as well
<pitti> right, I didn't forget about it
<seb128> thanks
<lifeless> mvo: I emailed you the trace you wanted
<pitti> it doesn't seem to like changing the PDF file while it is opened
<mvo> lifeless: yes, thanks. I just answered
<lifeless> mvo: sweet, thanks
<mvo> cheers
<torkel> pitti: re USN-224-1, do you know if any of the CVE's are still relevant for heimdal, or are they already fixed in heimdal?
<pitti> torkel: I would assume that heimdal in warty and hoary is still vulnerable
<pitti> torkel: I didn't check thoroughly yet, though (still on my list, but low prio)
<pitti> torkel: the newer three CVEs for krb5 were specific to MIT kerberos
<pitti> torkel: but the two telnet vulns are likely to affect heimdal as well
<pitti> torkel: but heimdal-clients is in universe as well, so unless somebody beats me to it (or gives me a debdiff :) ), it won't happen quickly
<torkel> pitti: you did an update of heimdal in September, no announcement though
<torkel> pitti: https://launchpad.net/distros/ubuntu/+source/heimdal/+bug/1176
<pitti> torkel: oh, right, http://people.ubuntu.com/~pitti/ubuntu-cve/fixed.html says that heimdal is fixed in warty and hoary
<pitti> torkel: that update was done by a MOTU security dude, that's probably why I don't remember
<torkel> pitti: can't say I consider myself a MOTU :-)
<seb128> pitti: I've uploaded a fixed evince for this crash on refresh bug to breezy-updates/dapper
<pitti> seb128: cool, thanks
<pitti> seb128: you rock :)
<seb128> np, thanks ;)
<seb128> (you too)
<seb128> k, time to grab some food
<pitti> enjoy
<dholbach> me too
<pitti> Hi jbailey 
<jbailey> Heya Martin!  How goes?
<pitti> jbailey: pretty fine - I mess up cdbs gnome.mk even further :)
<jbailey> Excellent!
<jbailey> It probably needs some tough love. =)
<pitti> I'm so much not proud of this shell hack, but it avoids touching ~100 packages, so what...
<jbailey> Shell hack? =)
<pitti> jbailey: look at the existing gnome.mk to see what I mean
<pitti> jbailey: the blob to update the pot file at build
<jbailey> Ahahha.
<jbailey> Fun. =)
<pvanhoof> Does somebody know wheter I can find a precompiled Transmeta Crusoe TM5800 kernel? I'm trying to get Ubuntu breezy working on a Xybernaut Atigo
<jbailey> Does this mean that Rosetta isn't expected to export anytime soon?
<pvanhoof> of course the standard 386 kernel works ..
<pitti> jbailey: what does that have to do with Rosetta?
<jbailey> pitti: Isn't this the scrape for Rosetta?
<pvanhoof> just wondering whether there's kernel binaries (I'd dislike having to hassle with crosscompilers bla)
<pitti> jbailey: (I currently add updating .desktop files in gnome.mk)
<pitti> jbailey: right, it is; it'll stay as it is :)
<jbailey> pvanhoof: I think it's unlikely.  If such a target really has obvious wins, then it might be worth talking to Ben about.
<jbailey> pvanhoof: But he'll probably want profile data showing how it's an improvement.
<pvanhoof> jbailey, to get it officially supported by ubuntu you mean?
<pitti> jbailey, seb128: btw, IMHO gnome.mk really belongs into gnome-pkg-tools...
<jbailey> pvanhoof: Right.  I try to discourage people fro doing anything to the kernels if I can.
<pvanhoof> official support isn't extremely important for my case, I'd be glad with a kernel image that would work
<pvanhoof> I understand
<jbailey> pvanhoof: As soon as you replace the kernel, it's not longer a supportable version of Ubuntu.  If you have a serious need, it's best to try and get Ubuntu bent to your needs.  Sometimes we can accomidate, sometimes not.
<pvanhoof> but atm I've installed breezy on the device. X11 works, the USB doesn't and the touchscreen doesn't. And it's extremely slow at startup. So my idea was to try with a transmeta kernel
<jbailey> pvanhoof: For boot speed slowness, best to try dapper.
<pvanhoof> is it stable atm? By that I mean, will it boot?
<jbailey> The other items just sound like real bugs that ought to be filed.
<pvanhoof> some guys told me to hold because of kernel upgrades
<jbailey> It depends how much pain you're willing to risk.  It booted for me 20 minutes ago, fully upgraded.
<pvanhoof> yes, indeed. I'm going to file those issues as bugs
<jbailey> However, there are quirks.
<jbailey> Like, networking doesn't fire up on its own.  You have to ifup it right now.
<pvanhoof> what about the quirks :)? I have a dapper of last week on this laptop, no quirks
<pvanhoof> ah that's an imporant issue .. you see
<jbailey> xscreensaver seems to hang my machine
<pvanhoof> I don't have a keyboard nor touchscreen
<pvanhoof> so if the network doesn't start, I can
<pvanhoof> t use the device
<pvanhoof> :)
<jbailey> and if I type too fast for too long, X hangs.
<pvanhoof> okay
<pvanhoof> going to wait with dapper then
<pvanhoof> :P
<jbailey> Everything else is perfect so far ;)
<pvanhoof> I think slowness is because it's booting from a compact flash
<jbailey> I haven't tried the keyboard problems yet since the xinput update that came recently.  It was usually about 20 or 25 minutes of nethack or writing long emails that would kill it.
<Keybuk> BenC: about?
<pvanhoof> I'm guessing the ubuntu boot isn't optimized for booting from a flash disk
<Keybuk> is there something I need to do to upstream kernel sources to make them work with an initramfs?
<pvanhoof> where it would be better to load as much as possible into ram, rather than reading things random
<Robot101> pvanhoof: reading a flash randomly is surely going to be better than reading disk randomly? seek times are constant on flash.
<Robot101> pvanhoof: I think it's more that flash is very slow. :)
<Diablo-D3> hey man
<Diablo-D3> its not that slow
<jbailey> Keybuk: No.
<jbailey> Keybuk: Are you having troubles?
<pvanhoof> Robot101, not sure, a fsck was blazingly fast
* Diablo-D3 has a 133x 1 gig flash card
<Diablo-D3> 20meg/sec reads.
<Diablo-D3> thats like... a slow harddrive.
<Keybuk> jbailey: yes, it appears I need to add "initrd /..." to the grub menu.lst :p
<pvanhoof> Robot101, an fsck was much faster than booting ubuntu .. 
<Diablo-D3> but still a fuckload faster than a cdrom
<Robot101> pvanhoof: fscks seek a lot but don't read much
<jbailey> Keybuk: It's an excellent start.  Or you can embed it in the data segment of the kernel. =)
<pvanhoof> I see
<jbailey> Booting at what stage?
<Robot101> pvanhoof: booting seeks a lot and reads a lot, it's the latter that will suck on flash. :)
<jbailey> if it's from grub, you're getting non-DMA access to a slow flash device.
<jbailey> It should suck quite badly.
<pvanhoof> well, the "Loading kernel" part isn't fast but also not extremely slow
<pvanhoof> it's rather after gdm started, loading the desktop. And loading the modules
<pvanhoof> but
<pvanhoof> I think the modules is slow because the uhci device fails (the slower usb controller)
<Keybuk> jbailey: we found the cause of the IDE strangeness anyway
<pvanhoof> the kernel module is retrying etc etc
<Keybuk> now when I modprobe alim15x3 (or piix, or via83cxx, etc.) they all find the disks themselves
<Keybuk> you don't need to load ide-generic
<mhz> jdub: ping
<pvanhoof> and about the touchscreen, when I cat /dev/ttyS0 and tap the screen .. I see characters
<pvanhoof> but using that device in X11 doesn't really work
<pvanhoof> so trying to get that working .. is there a way to detect the protocol?
<pvanhoof> it's using a lot '/' characters when moving (my finger accross the screen)
<jbailey> Keybuk: Ah.  Is kmodprobe picking them up now?
<jbailey> Keybuk: When I was doing my tests before I couldn't seem to get kmod to fire.
<jbailey> Andres always said that it was supposed to work, though.
<Keybuk> jbailey: dunno about kmodprobe
<Keybuk> but loading the right ide driver (with udevplug) causes the disks to be detected
<Keybuk> and fires off uevents for each primary block device and udev picks the right ide-cd/disk/etc. module to load
<Keybuk> so modprobe alim15x3 does the right thing for me (with udev running) ... I don't need to modprobe ide-generic to kick it in the balls
<Keybuk> and, in fact, loading ide-generic does absolutely nothing -- it's unused and can be rmmod'd again
<jbailey> That sounds right.
<Keybuk> yup
<Keybuk> do you know what I did to make it work right? :p
<jbailey> Nice, glad that's all sorted out.
<jsgotangco> hello
<jbailey> Keybuk: Mmm..  Replace udev with upstram?
<Keybuk> nope
<jbailey> jsgotangco: g'day
<Keybuk> replaced the kernel with upstream :p
<Keybuk> it's a bug in our patch set
* jbailey blinks
<jbailey> Eh?
<Keybuk> upstream, vanilla, 2.6.15-rc5 works exactly as intended
<jbailey> Oh, hmm.
<Keybuk> loading a particular ide driver scans and takes ownership of the disks
<jbailey> I don't envy you your next 2 days. =)
<Keybuk> its our kernels that are broken
<jbailey> The patch has quite likely been there since at least warty, and possibly slightly before.
<jbailey> Since I think I spoke to Andres about this at UDU
<Keybuk> yup
<Keybuk> it's Herbert Xu
<fabbione> modular-ide?
<Keybuk> fabbione: yeah
<fabbione> it has been in Debian for ages
<Keybuk> it's bust
<fabbione> but upstream has been looking at it
<jbailey> I keep forgetting we had him touch our kernel at one point, didn't we?
<fabbione> and merged a bunch of the bits
<Kamion> jbailey: he was contracted to maintain it for some time
<Kamion> even after fabbione took over, he was still doing security maintenance
<Keybuk> what was it actually supposed to do?
<Keybuk> the ide drivers are modules without it
<fabbione> Keybuk: no they are not
<fabbione> some stuff might build as module
<jbailey> Kamion: Ah neat.  At some point while there's still institutional memory for it, a big chart should be made of who touched what and caused what to happen when.
<fabbione> but they don't work
<Keybuk> right
<Keybuk> well, nothing works with this patch :p
<fabbione> the patch did attempt to fix that
<Keybuk> so I guess that's an improvement of a sort <g>
<Kamion> jbailey: hmm, I wonder how to get that started
<Kamion> it would already be enormous
<Keybuk> yup, the warty kernel exhibits the same bug
<fabbione> Keybuk: the major issue is that you can't even solve it the other way
<fabbione> if you don't make modules
<Keybuk> "the other way" ?
<fabbione> if you revert the patch
<fabbione> you endup to build-in a bunch of ide drivers
<fabbione> that as a consenque you will have no control over their init sequence
<fabbione> so you lose
<fabbione> in one way or another
<Keybuk> but this patch does exactly that
<Keybuk> it disables the init sequence of every driver
<Diziet> `Newsflash: Xen 3.0.0 has been released!'  So is it stable ?
<fabbione> Diziet: no
<Kamion> argh, kernel-image-*-di still provides ext2-modules
<jsgotangco> we wish
<fabbione> it's a cvs snapshot randomly tagged as xen 3.0
<Keybuk> so you also have no control over their init sequence, because they don't have one
<fabbione> Kamion: i can fix that...
<fabbione> Kamion: what arches?
<Diziet> fabbione: !
<Keybuk> instead ide-generic does the init'ing and then you're at hash-table luck as to which driver wins the device
<jbailey> Kamion: No idea.  About the time I came on, we started actually leaving audit trails of what all we were doing with the specs and such.  It would have to have someone with a history bent who's interested in the project to convince others to be interested, I guess.
<fabbione> Keybuk: -> blacklist my friend :)
<pitti> $(patsubst %,binary-install/%,$(DEB_PACKAGES)) :: binary-install/%:
<pitti>   -- jbailey, I love cdbs...
<Keybuk> fabbione: we can't blacklist ide-generic
<Keybuk> which is the principal module that seems to win :D
<fabbione> Keybuk: do in such a way to always try it as last resource?
<Keybuk> I still can't see what this patch is actually trying to achieve though
<fabbione> Keybuk: i don't know all udev internals, but i assume it does some kind of grep to decide what module to load
<Keybuk> why not just let each driver do its own probing?
<Keybuk> you're misunderstanding the problem
<Keybuk> the problem is
<Keybuk> 1) udev loads IDE-driver-of-choice
<Keybuk> 2) driver loads, but has had its init sequence removed by this patch, so does nothing
<Keybuk> 3) ide-generic is loaded by hand ("modprobe ide-generic" in the init script)
<Keybuk> 4) ide-generic's init script probes for devices, and assigns them to the first driver that seems to want them
<Keybuk> s/init script/init sequence/
<Kamion> fabbione: it shouldn't be provided by any arches any more, since ext2 is modular on all arches
<Keybuk> 5) ide-generic wins devices over the driver-of-choice
<Kamion> fabbione: filing a bug now
<fabbione> Kamion: fixing in git :).. don't bother with a bug
<Kamion> too late, #20535; I needed a bug anyway to document the seed workaround I need to make
<fabbione> Kamion: ok
<jbailey> Keybuk: So ide-generic was still wining anyway?
<Keybuk> jbailey: right
<jbailey> That doesn't make sense, since we were actually getting DMA out of drives.
<Keybuk> jbailey: it won sometimes
<jbailey> Mmm.  Joy. =)
<Keybuk> pretty much hash-table-luck
<Keybuk> ie. if your ide driver hashed earlier than ide-generic, you won DMA
<Keybuk> if your ide driver hashed later, you lost DMA
<fabbione> Keybuk: ok.. can't we just fix this hash-table to do what we want?
<Keybuk> fabbione: no
<Keybuk> we should drop this patch
<fabbione> why?
<Keybuk> because it's wrong
<Keybuk> each driver should probe for its own devices
<Keybuk> I don't see why that's a problem
<Kamion> fabbione: while you're there, could you arrange for all arches to generate an ext2-modules udeb? at present hppa and sparc don't
<Keybuk> if I "modprobe piix", I damned well want /dev/hda1 to appear with that driver
<fabbione> Kamion: sure
<Keybuk> this patch seems to do two things
<Keybuk> one adds _exit() functions to each driver
<Keybuk> that seems sane
<Keybuk> the other moves all driver init to ide-generic, which just seems wacky
<Keybuk> unless there's a rationale for that, we should stop it
<Kamion> fabbione: thanks
<fabbione> Kamion: no problem
<fabbione> Keybuk: i am pretty sure herbet has a clear idea on why it has been done that way
<fabbione> Keybuk: you really want to ask him before reverting
<Keybuk> well, doing that breaks everybody
<Keybuk> and the upstream IDE subsystem maintainer thinks it's a very stupid thing to do, also
<Keybuk> which to me is somewhat a clue that we don't want to do it :)
<Keybuk> the patch makes _some_ sense for when we just used to load every ide module and hope for the best
<Keybuk> but even then could be considered a kludge
<Keybuk> (ie. load every ide module, then let them fight to win devices, then remove anything that hasn't claimed a device)
<Keybuk> now we're smarter, we load just the one, right, ide module
<fabbione> IDE upstream is not exactly the most open person in this world
<fabbione> since even Alan Cox has been pushing that patch
<Nafallo> Keybuk: morning. would you care to backport your fix in ifupdown to breezy-updates? the clients get a new ip every time they ask about one :-/.
<Keybuk> fabbione: bits of the patch do look right
<Keybuk> but the patch does two things
<Keybuk> and one of them is clearly wrong
<Keybuk> why would you want to load an ide driver and *NOT* have it claim devices?
<fabbione> Keybuk: revert the patch and try
<fabbione> see how many systems breaks and than we can evaluate :)
<jbailey> Wow.  I setup biarch x86_64/i386 kernel headers in may, and noone noticed that I had the x86_64 headers on there twice and no i386 headers. =)
<fabbione> Keybuk: have you consider ATA-RAID controllers?
<jbailey> Clearly a well used setup. =)
<Keybuk> what about them?
<fabbione> Keybuk: some of them are visible as both raid and ide
<Keybuk> so?
<fabbione> Keybuk: if you allow the ide to claim the device you won't see the raid anymore
<Keybuk> right
<Keybuk> but that would be broken today if that were the case
<Keybuk> because we'd have loaded the ide module and ide-generic, and it would have claimed the device
<fabbione> Kamion: i fixed ext2-modules for sparc64, but hppa has always been there
<Kamion> this all sounds kinda reminiscent of the piix/ata_piix thing we delayed the hoary preview over?
<Kamion> fabbione: well it's not in the archive
<Keybuk> because we were working around this "loading the right ide module doesn't actually claim the devices" problem in breezy
<Keybuk> and, as you say, we can always just blacklist things
<fabbione> Kamion: i am checking
<fabbione> Kamion: the ext2 thing for hppa was added a while ago in .15. The problem is that there is no .15 for hppa in the archive
<fabbione> Kamion: that's something i can't really fix
<fabbione> anyway sparc should be ok
<fabbione> Kamion: done.. BenC needs only to pull from my archive
<Kamion> fabbione: ah, ok
<Kamion> thanks
<fabbione> no problem
<BenC> what's up?
<Kamion> #20535, live CD hosage, fabbione fixed
<Keybuk> hmm, is the config stored in the linux-source package anywhere?
<fabbione> Keybuk: debian/config/$arch/
<Keybuk> I don't have a debian directory
<Keybuk> http://people.ubuntu.com/~scott/fixed-ide.patch
<Keybuk> ^ so this is the patch I'm trying
<Keybuk> it unpicks the part of the modular-ide patch I think is in crackywackyland
<Diablo-D3> am I the only one here who finds linux depressing?
* BenC installs edubuntu for his kids
<BenC> anyone know if there's a way to do parental controls for website access?
<Diablo-D3> yes, but not with any foss tools afaik
<Diablo-D3> /that/ and its impossible
<BenC> impossible?
<Diablo-D3> the tools dont work
<Kamion> dansguardian and something else came up the last time we discussed this seriously
<BenC> works on MacOSX
<Diablo-D3> I mean, they dont filter what they should
<Kamion> squidguard I think
<BenC> I don't want filter, I want a white list
<Diablo-D3> BenC: ahhh
<Diablo-D3> now thats much easier.
<Diablo-D3> yeah, theres some squid-based tool that will do it
<Diablo-D3> BenC: also, what stops you from just whitelisting hosts using iptables
<Diablo-D3> stop them from doing anything
<BenC> I was looking for something integrated that would pop-up and say "You do not have access to this website, please enter the admin password to override"
<Diablo-D3> hrm.
<Diablo-D3> ask kamion =P
<Kamion> no, don't
<BenC> Kamion: I need to ask you a question...
<BenC> :)
* Keybuk gets the rice ready to throw
<mvo> Kamion: do we have a list of expected removals on a dist-upgrade somewhere already? 
<BenC> hotplug is one, and some things with HP print/scan stuff
<BenC> that's all I know of
<Keybuk> modutils and initrd-tools will be going soon
<mvo> thanks, I'm looking for it for the save-dist-upgrade spec, I wonder if we have something for hoary->breezy already for example
<mvo> (not wanting to re-invent the wheel etc)
<BenC> Kaybuk: is initrd-tools dist-wide, or just the archs that support initramfs?
<Keybuk> BenC: the theory is to make all the archs support initramfs
<Diablo-D3> oh wow
<Diablo-D3> debian planet has new articles
<Keybuk> I'm not entirely sure that initrd works now, for example :)
<Kamion> mvo: not that I know of
<StevenK> BenC: However, it would be fairly easy to write a squid filter that grabbed the URL, and returned a 403 if they were denied (which forces the browser to pop up the auth dialog) or 200 if the page is ok.
<Robot101> StevenK: you forgot dbus.!
<jbailey> BenC: No effort will be made to make initrd-tools work without devfs.
<BenC> ah
<StevenK> Robot101: How is dbus supposed to fit in there? :-P
<Keybuk> iirc. I saw a patch for the last arch that didn't work that we care about go in a while back
<jbailey> BenC: So it's one of those moments where the archs have to be able to do it, or they'll die off.  In this case, I think we have patches in hand for all arches now anyone.
<Keybuk> and that was one of lamont's toys
<Robot101> StevenK: not sure, but it's a requirement for new free software projects nowadays. :)
<jbailey> BenC: I have a new patch from kyle for hppa, and lamont has a patch for elilo
* StevenK smirks.
<BenC> jbailey: can you send me the one for hppa?
<BenC> I'd like to test it
<jbailey> BenC: Sorry, it's a klibc patch, not a kernel one.
<StevenK> Robot101: So, how can I debug why gaim won't add itself to the Notification area?
<BenC> do you have a patches klibc though?
<jbailey> BenC: I'll just upload it to the archive over lunch probably.
<BenC> ok
<Robot101> StevenK: oh dear
<jbailey> BenC: The lag to my usual hppa box last night was painful, so I went to bed instead.
<Robot101> StevenK: other stuff does, just gaim fails to?
<StevenK> Robot101: amarok does, printing does, upgrade notification does.
* Diablo-D3 updates his laptop
<Diablo-D3> to dapper mwhahaha
<fabbione> Diablo-D3: read /topic before doing so
<Keybuk> we could probably remove that bit now
<pitti> Keybuk: s/getting/has/, but the unstable part might still be true :)
<Robot101> fabbione: the bit that says "#ubuntu for support and general discussion"? :)
<Robot101> StevenK: and you have the tray icon plugin loaded?
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 1 released | Dapper has new kernels and new world order, upgrading for the adventurous only
<StevenK> Robot101: I have no idea. My .gaim is fairly old.
<jbailey> Keybuk: Mmm, it's probably still worth noting that networking isn't likely to come up.
<Diablo-D3> fabbione: uh?
<Diablo-D3> fabbione: 2.6.15-6.8 is working fine for me
<fabbione> Robot101: more likely the part that says Dapper might be on crack.. if it breaks.. sucks to be you
<Diablo-D3> fabbione: so unless you know of any other new kernels that I should be aware of, please tell me
<fabbione> Diablo-D3: do whatever you want.. 
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 1 released | Dapper has new kernels and new world order, upgrading for the adventurous only (and those with another machine to use)
<fabbione> if it breaks.. sucks to be you
<Keybuk> this is open source development at its best
<Keybuk> when it breaks, you get to keep the pieces
<Diablo-D3> fabbione: dude, quit being lame.
<StevenK> Robot101: Okay, that fixed it.
<Keybuk> and it's usually a good idea to have the glue standing by first
<Diablo-D3> I've been running devel kernels longer than you've ran linux.
<fabbione> Diablo-D3: dapper is not made of new kernels only...
<Diablo-D3> so don't start running you're mouth off to me.
<dholbach> Diablo-D3: stop it
<fabbione> Diablo-D3: and please it's time you moderate your tone here
<zakame> hey all :D wazup?
<fabbione> Diablo-D3: because from me giving you a piece of advice
<fabbione> Diablo-D3: you are turning into something that's not nice
<Robot101> StevenK: phew, it's not a real bug, just Gaim being crack :)
<StevenK> Robot101: The best kind.
<Robot101> StevenK: roll on telepathy... :)
<\sh> ignoring trolls now
* mode/#ubuntu-devel [+o daniels]  by ChanServ
* mode/#ubuntu-devel [+b *!*=diablod3@*.port.east.verizon.net]  by daniels
* Diablo-D3 was kicked off #ubuntu-devel by daniels (daniels)
* mode/#ubuntu-devel [-o daniels]  by daniels
<ogra> daniels, thanks 
<\sh> thx daniels 
* zakame is happy, albeit on a stormy evening :)
<\sh> oh well...security break ...
<crimsun> elmo: please sync pysol from Sid (ok to override Ubuntu changes), thanks
<Kamion> Keybuk: "don't install" is still true
<lll> dss
<lll> 
<lll> asd
<Kamion> lll: take the testing somewhere else, please
<lll> sorry
<lll> hellp
<lll> hello
<lll> hello
<lll> hi
<lll> hi
<lll> hi
<lll> hi
<lll> hi
<lll> hi
<lll> ] 
* mode/#ubuntu-devel [+o Keybuk]  by ChanServ
* mode/#ubuntu-devel [+b *!*i=lll@61.149.242.*]  by Keybuk
* lll was kicked off #ubuntu-devel by Keybuk (stop that)
* mode/#ubuntu-devel [-o Keybuk]  by ChanServ
<jbailey> elmo, Znarl: Can you please update linux-kernel-headers in the amd64 dapper chroot on concordia? (RT #1099)
<Znarl> jbailey : No problem.
<Keybuk> BenC: when is your next planned kernel upload?
<BenC> in about 30 minutes
<Keybuk> ok
<Keybuk> hold it for one second
<Keybuk> I have a patch which reeeeally needs to go in
<BenC> ok, just say when
<Keybuk> I just want to reboot to make sure my machine's still happy with it applied
<BenC> ah, ok
<BenC> what's it for?
<Keybuk> fixes IDE
<BenC> fixes it how?
* BenC didn't know it was broken :)
<jbailey> BenC: You sound suspicious. =)
<Keybuk> http://people.ubuntu.com/~scott/fixed-ide.patch
<Keybuk> reverts some of the "modular ide" patch
<BenC> "fixes IDE" is a slightly broad patch description :)
<Keybuk> let me just check I didn't fluff it, and I'll explain in detail
<jbailey> Keybuk: You're touching exported symbols, hope it was an abi bump anyway. =)
<Keybuk> jbailey: I expect BenC is about to bump the ABI anyway
<Keybuk> ok
<Keybuk> so let me explain it
<BenC> yeah, it's -7.9 so all good
<Keybuk> http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=commitdiff;h=149744c1475cdaf2c6babfd92f163cca8f10c540;hp=5a373d68631531fff09047364be4565d67335f08
<Keybuk> ^ that is our "modular-ide" patch
<BenC> yeah, from breezy
<Keybuk> it's advertised as making more of the IDE drivers work when modules and not built-in
<Keybuk> but it actually does two things
<Keybuk> one is fix those drivers (adding the exit functions, etc.)
<Keybuk> and the other is to prevent ANY driver from claiming devices when loaded
<Keybuk> and instead move device claiming to ide-generic
<Keybuk> the effect of this is:
<Keybuk> modprobe piix
<Keybuk> doesn't claim any devices
<Keybuk> instead you have to wait for that to settle, then modprobe ide-generic
<Keybuk> and ide-generic dishes out the devices to interested drivers
<Keybuk> the bug is
<Keybuk> that ide-generic is also interested, and frequently wins the fight
<Keybuk> now,
<BenC> I remember that same type of thing in breezy
<Keybuk> the rationale for this, afaict, was that we _used_ to load all the ide drivers and let them fight it out
<BenC> right
<Keybuk> ie. we actually loaded every single one, loaded ide-generic last, then removed any driver that wasn't hanging on to a device
<Keybuk> so it makes kinda sense, in a very kludgy way
<Keybuk> but we don't do that now
<Keybuk> now we're clever, we load exactly the right single ide module we wanted
<Keybuk> and we can resolve issues like "piix and ata_piix might claim the same device" in userspace, where we're supposed to
<Keybuk> (by loading the right module in userspace through modprobe blacklists, et al)
<BenC> what about the cases where none of the specific drivers claimed it, and ide-generic needs to be loaded?
<Keybuk> those we can also handle in userspace
<BenC> can or do?
<Keybuk> do
<Keybuk> so back to the patch
<BenC> I just want to know what to look out for so if anything pops up, I know whether you or I need to fix it :)
<Keybuk> this unpicks the part of the modular-ide patch that changed the way drivers grabbed drivers
<Keybuk> so puts us back to upstream in that regard
<Keybuk> so loading the driver for a particular ide device will claim that device
<BenC> back to upstream is good, I didn't much like the way this patch worked
<Keybuk> right
<Keybuk> so things that could pop up, in theory, if you have something that could either be RAID/SATA or IDE
<Keybuk> and the wrong driver gets loaded first
<Keybuk> the way to fix that is to tell me, and we'll arrange for the right thing to happen in the initramfs
<BenC> what sort of troubleshooting do I ask of users having problems with this?
<Keybuk> dmesg output will once again reveal which driver wins the device
<BenC> "load ide-generic", "blacklist module foo"?
<Keybuk> exactly
<Keybuk> does adding "blacklist the-wrong-module" to /etc/modprobe.d/blacklist work?
<Keybuk> (and update-initramfs)
<BenC> one thing we are eventually going to end up dealing with (so I've found out today) is when pata drivers start getting included, devices will go from hda -> sda, for instance, but that will probably be post-dapper
<Keybuk> my favourite debugging trick is to boot with break=premount and get them to step through the process of loading the modules for their rootfs, and seeing which one throws the spring across the room
<Keybuk> yeah
<Keybuk> that will be a nice day
<BenC> ok
<Keybuk> then we can rename sd? to just disk or something <g>
<Keybuk> http://people.ubuntu.com/~scott/fixed-ide.patch
<BenC> we may want to make sure we have the UUID mounting stuff ready in dapper
<BenC> which will make it easier for post-dapper to make the switch
<Keybuk> ^ right, that's the patch.  it applies cleanly to our linux-source-2.6.15-6.8 (it might need a wiggle for your git tree)
<Keybuk> and doesn't break compilation
<Keybuk> and doesn't break booting for my laptop
<Keybuk> <g>
<Keybuk> if it fixes booting on our boss's laptop, so much the better
<BenC> ok, I'll put it in, and trust it (so I don't have to wait 3 hours for my test builds to finish :)
<Kamion> ~ # chroot /target
<Kamion> chroot: cannot execute /bin/sh: Exec format error
<Kamion> I do love broken live filesystems
<BenC> applied, with no fuzz :)
<Keybuk> damn, I give good patch
<Amaranth> pata? why the rename?
<Amaranth> pata == ide, no?
<BenC> pata is done in the scsi layer
<infinity> parallel ata is a superset of ide, if you want to be anal.  But who really cares anymore?
<BenC> so uses scsi device names
<Amaranth> seb128: LaserJock wants a Science menu to be added to applications.menu
<seb128> Amaranth: file a bug on gnome-menus upstream
<Amaranth> seb128: gnome has a bug filed and someone created an icon for the menu, just needs to get used
<HiddenWolf> just hide the menu if it's empty. ;)
<seb128> Amaranth: I've the list of gnome-menus bug at screen atm and there is no one about this
<Amaranth> HiddenWolf: That's default.
<Amaranth> http://bugzilla.gnome.org/show_bug.cgi?id=140900
<Keybuk> Amaranth: you know how SATA devices appear as SCSI drives?
<seb128> -Amaccording to the number that's before gnome-menus
<Keybuk> well, PATA is the same for IDE drives
<Amaranth> it got filed against gnome-icon-theme, i guess because the idea was that once an icon was created it was good to go
<Amaranth> Keybuk: Yeah, which doesn't make much sense to me.
<Keybuk> so you'll have /dev/sda1 instead of /dev/hda1
<seb128> Amaranth: still, don't expect it to move if you don't file a bug on gnome-menus upstream
<Keybuk> Amaranth: the SCSI subsystem is rather better than the IDE subsystem, and it's easier to implement generic bus-of-drive-like-devices in SCSI
<seb128> gnome-icon-theme is not likely to be tracked by markmc
<Keybuk> whatever the underlying protocol
<infinity> Kamion : You never specified you wanted live filesystems to WORK... Just get built.
<Keybuk> if you want to look at it another way, that's semantically less scary
<Amaranth> seb128: It was filed against gnome-menus at one time. Should I file a new bug saying the icon has been created, we just need to include it?
<Keybuk> "there will be a single subsystem for drives of all kinds; SCSI, IDE/PATA, SATA and USB storage will all appear under it"
<Amaranth> seb128: I think the icon needs to get into gnome-icon-theme first though.
<Keybuk> it just happens that the single subsystem is the existing SCSI subsystem, not a new one <g>
<Amaranth> Keybuk: ah, i guess that makes sense
<Amaranth> Keybuk: but the sd naming no longer does
<infinity> Amaranth : We're not the only OS with this oddity.  SCSI programming is easier in Windows too, which is why many 3rd-party IDE controller drivers present themselves in the Windows device manager as SCSI controllers.
<Keybuk> right, device names are userspace though -- we can always drop the "s"
<seb128> Amaranth: that's what bug Depends are for
<Keybuk> or just pretend it means "standard disk" or something <g>
<seb128> Amaranth: create a gnome-menus bug and make it depends on the icon one
<StevenK> Keybuk: "Special Device" :-P
<seb128> Amaranth: and I'm not sure that a science category is useful, want to put to it?
<jbailey> Keybuk: What are you quoting from?
<seb128> what do you want to put to it?
<infinity> StevenK : "storage device", and I think you've nailed it.
<Amaranth> seb128: LaserJock appearently has a large number of programs that fit in it.
<StevenK> Heh, I was joking.
<Keybuk> jbailey: quoting?
<Keybuk> infinity: perfect.
<Amaranth> seb128: I told him to use Categories=Applications;Science;Education; but that doesn't seem to be a good fit.
<jbailey> <Keybuk> "there will be a single subsystem for drives of all kinds; SCSI, IDE/PATA, SATA and USB storage will all appear under it"
<Keybuk> jbailey: ah, English style (at least that I learned) is to use 'blah blah' for real quotes and "foo bar" for quotables
<Keybuk> ie. that was a single sentence that could be less scary
<Amaranth> Keybuk: most people just mix them randomly
<seb128> Amaranth: some example of the "large number of programs that fit in it"?
<Keybuk> I wasn't quoting anyone in particular
<mjg59> Keybuk: Any ideas on how we could sensibly transition people from /dev/hda to /dev/sda ?
<Amaranth> seb128: You'd have to talk to him.
<Amaranth> LaserJock: ping?
<jbailey> Keybuk: Ah alright.  I didn't do english schooling, so I'll remember this. =)
<seb128> Amaranth: I'm not convinced, we are trying to make the menu easier, not to have a zillions of categories with 1 icon
<mjg59> Keybuk: Answers of the form "For certain devices, create hda device nodes that are actually SCSI devices" may be acceptable
<LaserJock> Amaranth: pong. sorry was a little busy ;-)
<Amaranth> seb128: Something about schools and science apps that don't fit into edutainment
<infinity> mjg59 : I'm not sure.  How's it been done in the past (when SATA controllers moved to libata)?
<Amaranth> (which gnome doesn't seem to have an icon for)
<mjg59> I think people had to do manual configuration
<Kamion> Keybuk: we could just symlink sda* to hda* ...
<infinity> mjg59 : Somewhere in the 2.4 series, I had a mess of hard drives migrate to the SCSI side.  I assume some commercial vendors actually had to deal with that, while I did it manually.
<seb128> Amaranth: http://bugzilla.gnome.org/show_bug.cgi?id=321703
<Keybuk> yeah, either works
<mjg59> Basically, there's some chance of migrating to using libata-based PATA drivers for most hardware
<Amaranth> seb128: As usual you're way ahead of me. :)
<mjg59> Which has certain compelling advantages, and the large disadvantage that they're almost untested
<LaserJock> seb128: I can understand wanting to keep the menu clean. It is just frustrating that science applications end up in Other or Education when they aren't really either
<mjg59> seb128: Did you see my gdm patch?
<seb128> mjg59: I've seen the mail/bug but not looked on the patch yet, trying to get gst0.10 packaged this way so my focus is on it atm
<seb128> s/way/week/
<mjg59> seb128: Ok, no problem
<Amaranth> woo, gstreamer 0.10
<seb128> mjg59: it's on my list of stuff ot look after gst, don't worry :)
<Kamion> infinity: any idea what's up with them?
<seb128> LaserJock: please open an upstream bug (bugzilla.gnome.org) against gnome-menus for science category
<LaserJock> seb128: I believe there is one already. Amaranth gave me the url yesterday but I can't find it at the moment
<Amaranth> LaserJock: Yeah, your bug, you file it. :) Give specific examples of what would go in it. Make sure you make it depend on 140900
<Amaranth> LaserJock: That's gnome-icon-theme, to make the icon for the menu.
<infinity> Kamion : No, I'm just being an unhelpfully sarcastic jerk while I wait on some stuff I have building in the background.
<infinity> Kamion : If you want help with (live)cd stuff tomorrow, though, I'm all yours.
<Kamion> infinity: "/mnt/bin/bash: data" according to file
<infinity> !
<infinity> In the base livefs?
<infinity> Kamion : Is bash special in that regard, or is the whole system similarly b0rked?
<Kamion> infinity: full live fs
<infinity> Which arch/date?
<Kamion> infinity: random sample, gunzip's fine, false's fine, ddate's broken
<Kamion> infinity: i386, whatever's in the images I built an hour or two ago
<infinity> Full ubuntu?... That hasn't actually succeeded since Nov 22...
<Kamion> oh, huh
<Kamion> yeah, full
<Kamion> I guess I'm spoiled by late breezy
<infinity> Yeah. :)
<infinity> I'm wondering if it's worth hunting this, or if we should test recent base first to see if it seems transient.
<Kamion> I was mostly just trying to get far enough to be able to port the root fs switchover code to initramfs
<infinity> Okay, the non-compressed image has a working bash.
<Kamion> hmm, powerpc looks like it should succeed if built at the moment
<infinity> Didn't 12 hours ago, but a lot can change in 12 hours..
<infinity> Cute, I don't actually have cloop support on the buildds, so I can't mount the images there.
<LaserJock> seb128: ok, just rereading the log here. So I should file a bug against gnome-menus with info on the need for a science category and then put a dependency on the gnome-icon-theme bug 
<seb128> LaserJock: exactly
<LaserJock> seb128: ok, will do. thanks
<seb128> np, thank you
<Kamion> infinity: the machine COULD be insane
<infinity> Kamion : Would it be beneficial if I included md5sum output of the cloop in the build log somewhere?
<Kamion> sure
<Kamion> pitti: #ubuntu-meeting, opinions on zyga for membership?
<infinity> Kamion : Alright, I'll TODO that.  For now, the MD5 of the image you're trying to use that's broken should be:
<infinity> 734bd42f6097b1232b0144e4435bbf70  livecd.ubuntu-20051122-i386.cloop-1024:65536
<\sh> hmm...who is Fabio Marzocca? 
<ogra> \sh, thesaltydog
<\sh> http://lxer.com/module/newswire/view/49268/index.html nice interview :)
<ogra> and no, he's no ubuntu developer, even if heclaims it in the interview ...
<zakame> er?
<ogra> but he develops his stuf with ubuntu in mind i guess ...
<zakame> ogra: just to be clear, what qualifies as a ubuntu dev? :)
<ogra> zakame, being in one of the launchpad dev teams i'd say 
<ogra> at least if you use it as a headline in an interview
<Kamion> ubuntu-dev or ubuntu-core-dev
<ogra> what Kamion said
<Keybuk> anyone here running dapper, and has a SCSI CD-ROM drive?
<zakame> Kamion: ogra: ah, i see... that was also what I had in mind...
<Keybuk> (or, I guess, SATA CD drive)
<wasabi_> The hotplug stuff in /etc/network/interfaces is confusing.
<Keybuk> wasabi: yeah, it's going
<wasabi_> Suppose it's safe to just rip it out and use traditional "auto"
<wasabi_> I guess what I think would be really nifty is a "mac NN:NNetc" in an iface stanza
<wasabi_> which also took over ifrename heh
<wasabi_> Or something similar.
<Kamion> infinity: md5sum matches
<Keybuk> udev is replacing ifrename
<Kamion> wasabi_: some of that's already changing in netcfg upstream
<Keybuk> as that can actually rewrite the event as it goes and pass the right thing to ifup
<Kamion> only affects new installs of couse
<wasabi_> Ahh nifty.
<wasabi_> Man what I really want though is n-m to become just a frontend to this. =9
<wasabi_> this whole seperation thing bites.
<thierry_> seb128 : if I want to solve a unmet dependencies problem, where do I send the patch? malone?
* mvo is away to buy some food
<desrt> Seveas; ping
<infinity> Kamion : I didn't want to know that.  Yell at me about it tomorrow, and we'll dig deeper.  It'a 4am and bedtime.
<desrt> Seveas; is there any reason you changed my 'install -t dest src' to 'install src dest'?
<Kamion> infinity: ok
<desrt> Seveas; i'm incorporating a bunch of your changes upstream and am wondering about that one
<Kamion> what's install -t? it's not in --help
<desrt> Kamion; destination directory
<desrt> 'target'
<Seveas> -t doesn't work on ubuntu and is not in the manpage
<desrt>        -t, --target-directory=DIRECTORY
<desrt>               copy all SOURCE arguments into DIRECTORY
<Seveas> which version of install is that?
<desrt> works on my ubuntu :)
<desrt> install (GNU coreutils) 5.93
<desrt> (dapper)
<Seveas>        -S, --suffix=SUFFIX override the usual backup suffix
<Seveas>        -v, --verbose
<Seveas>               print the name of each directory as it is created
<Kamion> must be a very new option; it's not in my Debian installation's version
<desrt> if it's not even in breezy then that's definitely reason enough to not include it :)
<Seveas> I've been testing (and using) the pacjage on breezy
<desrt> elite.  i'll be releasing 0.1.1 today
<Seveas> cool
<desrt> do you want me to package it?
<Seveas> neh, I'll do it, gives me some practice :)
<desrt> i was hoping the same for myself :p
<Seveas> hehe
<desrt> anyway.  lunch.  bbl.
<desrt> btw-- any feature requests for 0.1.1?  you've probably been using it more than anyone
<desrt> mostly i've just fixed the licensing problems and added your .desktop file.... but i also added a feature that the gnome-terminals get invoked with a 'keyboardcast' profile (so you can have smaller text, for example)
<pitti> elmo: is it possible to remove evolution | 2.2.1.1-0ubuntu4.1 from hoary-updates? It has been superseded by 2.2.1.1-0ubuntu4.2 in hoary-security
<pitti> elmo: i. e. the -security version includes the -updates fix, so there is no reason to use the -updates version which has vulns
<Keybuk> \o/
<Keybuk> fixed the /dev/sr0 group "floppy" issue
<mdz_> Keybuk: what was it?
<Keybuk> a duff udev rule
<Keybuk> I'd enclosed those in SUBSYSTEM!="scsi_device"
<Keybuk> but block devices are made by the block SUBSYSTEM :p
<mdz_> pitti: if there have been no problems with the -updates version, we can consider folding it into -security so you don't need to maintain two branches
<Keybuk> I really needed ENV{PHYSDEVBUS}!="scsi"
<Keybuk> pitti: I was just about to ping you about your pcspkr problems :p
<xkahn> Okay.  So I made a patch to add pam_xauth to ubuntu.
<xkahn> And then I started the flamewar on the -devel mailing lists.
<xkahn> Now what do I do to get it approved?
<xkahn> Sadly, it wasn't a very GOOD flamewar...
<xkahn> Oh.  And I filed a bug.
<xkahn> Forgot that bit.
<mdz_> pitti: please work with mjg59 to get acpi-support installable in main again
<mdz_> Keybuk: pcspkr was not being loaded for me, but I assumed it was because I was on 2.6.12 on that box
<mdz_> Keybuk: it seems to load fine on my laptop, which runs 2.6.15
<Keybuk> yeah, there was a pnp_modules bug, which I thought I fixed, pitti filed a bug though, but then resolved it again when he upgraded :p
<mdz_> seb128: why is xchat opening hyperlinks in w3m for me now?
<seb128> mdz_: what does gnome-open do (gnome-open http://)?
<Kamion> sigh, I always find the HIG really hard to find on the GNOME web site
<mdz_> Error showing url: There was an error launching the default action command associated with this location.
<mdz_> seb128: gnome-terminal still works (loads it in firefox)
<mdz_> oh, not on this machine
<Kamion> it always seems that it should be under "GNOME Policies" or "Standards" before I think to try "Programming Guides"
<mdz_> on my desktop, xchat uses w3m and g-t uses firefox correctly
<seb128> mdz_: run the preferred app capplet, and set firefox instead of mozilla-firefox
<mdz_> on my laptop, g-t gives an error and xchat uses w3m
<mdz_> seb128: is this because I changed it sometime, or will it affect the default config?
<seb128> mdz_: I'll have a look for xchat, I use xchat-gnome atm I'm not sure it uses the standard gnome_vfs call (like gnome-open). The default system key has been updated so it'll affect only people who did some user change
<mdz_> seb128: that fixed gnome-open; I assume I need to restart xchat?
<mdz_> seb128: is xchat-gnome workable for dapper?
<ogra> mdz_, err, see your alternatives fro x-www-browser
<mdz_> x-www-browser - status is manual.
<mdz_>  link currently points to /usr/bin/mozilla-firefox
<mdz_> /usr/bin/firefox - priority 70
<mdz_> that shouldn't be manual
<seb128> mdz_: I use it for some months, it works quite fine for me but that would be nice to get user feedback on it
<mdz_> seb128: if there are no known showstoppers, let's switch and see what happens
<ogra> mdz_, and it shouldnt point to a non existing binary :)
<seb128> mdz_: it has some nice plugin (can use libnotify, autoset away when gnome-screensaver starts, etc)
<seb128> mdz_: I guess there is no issue to switch now so we can get feedback on it
<mdz_> seb128: ok, go ahead and update the seeds and ubuntu-meta please
<seb128> mdz_: oki, doing that now
<mdz_> seb128,ogra: how about gnome-screensaver?  any reason not to switch that as well?
<ogra> none apart from ugliness ...
<ogra> i havent done the main inclusion report yet ... will do after dinner
<mdz_> ogra: xscreensaver in dapper is ugly already
<ogra> hehe, yes, indeed :)
<seb128> mdz_: for xchat seems that you need to restart it, ype
<seb128> yep
<ogra> if i can get it in without main inclusion report, i'll switch the seeds immediately ...
<mdz_> xchat-gnome looks nice
<Amaranth> isn't some of that integrated into xchat?
<seb128> Amaranth: no
<Amaranth> maybe it's just the silverex windows version that does it but this thing has the treeview for servers
<seb128> ?
<ogra> mdz_, if i can get it in without main inclusion report, i'll switch the seeds immediately ...
<mdz_> GRRRRRR
<mdz_> seb128: xchat-gnome has the ^W bug still
<Amaranth> it's a feature :P
<mdz_> ogra: gnome-screensaver is a new implementation, not just a new frontend for xscreensaver, right?
<mdz_> ogra: as such, it needs a report
<ogra> yup
<seb128> mdz_: what bug? it uses w3m?
<mdz_> seb128: the bug where ^W closes the tab rather than deleting backward one word
<ogra> we switched in breezy without one, thats why i ask
<mdz_> ogra: that was a sab override ;-)
<ogra> hehe, oki
<seb128> mdz_: that's a standard GNOME shortcut :)
<seb128> mdz_: it does the same with gedit by example
<mdz_> seb128: it's a standard UNIX shortcut for something less destructive ;-)
<seb128> right ;)
<Keybuk> GNOME doesn't use Emacs shortcuts
<mdz_> seb128: in xchat, if you use gtk-theme-name Emacs it disables that
<Keybuk> there's a gtkrc recipie you can use to make it
<mdz_> er
<mdz_> gtk-key-theme or whatever
<seb128> I'll bug upstream about that :)
<Amaranth> seb128: http://www.realistanew.com/random/xchat-windows.png
<mpt> This is why GNOME should have used Alt, not Ctrl, when copying Mac shortcuts ...
<Keybuk> it copied Windows shortcuts, didn't it?
<mpt> then Ctrl+W for delete word and Alt+W for close window could have coexisted peacefully, like the humans and the fishes
<jbailey> mdz_: gtk-key-theme-name = "Emacs"
<seb128> Amaranth: weird, it's not the same with linux
<mpt> Keybuk, iirc the only major Microsoft programs where Ctrl+W works are Internet Explorer and Excel
<mpt> Windows programs, that is
<dholbach> anoter pro argument for xchat-gnome would be that we could report bugs to b.g.o and not to sourceforge :)
<Burgwork> dholbach, almost worth it right there
<Diziet> dchroot--
<Diziet> -anarres:~> dchroot -q echo ' 1 ' ' 2 '
<Diziet> 1 2
<pitti> mdz_: that's what I already did, the -security version contains the -updates fix (it was just a fixed bug tracker URL)
<elmo> pitti: who has -security and not -updates in their sources.list?
<elmo> pitti: and why do we care about them?
<pitti> elmo: hm, you mean who has -updates and no -security?
<elmo> err, yes
<pitti> elmo: probably nobody
<pitti> elmo: it's just that we have a vulnerable version in -updates, and it yells at me in the CVE tracker
<elmo> pitti: well I'm kind of reluctant to just remove it
<elmo> because that doesn't help the people who do only have -updates
<elmo> I'd rather propagate it into -updates or something
<pitti> elmo: it would only help for new installs, to prevent silly updates to -updates instead of -security
<elmo> hum
<pitti> elmo: right now I feel obliged to fix -updates, too
<pitti> which I would do if we don't remove the updates version
<pitti> would be fine for me, but I wanted to ask first :)
<mdz_> pitti: I don't think -updates without -security makes much sense, tbh
<mdz_> -updates should imply -security
<pitti> me too
<pitti> mdz_: it's really just a cosmetical issue and removing a branch we have to care for
<zyga> http://ubuntu.suxx.pl/ubuntu-photo-project/
<zyga> ideas/comments welcome
<zyga> gnome comments for the last section welcome
<mdz_> pitti: ok, so further updates need only go to -security
<mdke_> i have a comment on the url
<mdke_> zyga, shocking
<zyga> yes I know I've got a crappy domain name
<mdke_> clicking now
<mdz_> pitti: it would have been simpler to release the -security update with a version >> -updates if it contained the changes already
<zyga> please don't comment that (I tried to buy roxx.pl later but it was sold)
<pitti> mdz_: that's exactly what I did
<mdz_> pitti: then why was a -updates upload required?
<mdke_> zyga, looks like some good ideas, perhaps work with the art team?
<pitti> mdz_: the -updates one was there first, later I did a -security udpate and folded in the -updates fix
<zyga> mdke_: I want to make the template for light/dark photos and maybe modify the background dialog
<mdz_> pitti: oh, i only saw -updates on -changes
<mdke_> zyga, art team sounds like a good place to work then no?
* ogra wonders if its modern to carry underscores around or if its only for nicks starting with m
<zyga> mdke_: #ubuntu-artwork is more less ghostship, but in general yes
<pitti> mdz_: I don't think that -security goes to any -changes list
<mdke_> zyga, you could try a mailing list or wiki pages, or contacting people directly
<mdke> sorry ogra 
<ogra> lol
<mdke> damn home connection
<ogra> i wasnt serious at all
<pitti> mdz_: btw, both evolution uploads are already pretty old, I just noticed today that evolution 2.2.1.1-0ubuntu4.1
<pitti> is still vulnerable
<mdke> ogra, i know :)
<ogra> just waiting for my food to warm up :)
<Keybuk> pitti: you didn't fix the hal.rules file yet, right?
<mhz> jdub: ping
<zyga> mdke: I'll try the mailing list, thanks
<pitti> Keybuk: in my local package here, but I didn't yet upload it
<pitti> Keybuk: I thought it could wait for some days when I have some more fixes
<Keybuk> pitti: could you upload that?
<Keybuk> it's breaking things
<pitti> Keybuk: but if you need it, I can, sure
<mdz_> pitti: hoary-security is a newer version
<mdz_> pitti: I think we can safely say that if someone doesn't have -security in sources.list, they can't expect security updates
<pitti> mdz_: for real branches (i. e. -updates not merged), I also fixed the -updates version, so in a way they can
<mdz_> pitti: we should not give them that expectation
<pitti> i.e. whenever -updates has a higher version than -security, I fix both branches
<pitti> otherwise using -updates wouldn't make much sense
<mdz_> they are separate to allow users to opt out of updates, not opt out of security
<pitti> Keybuk: uploaded
<janimo> pitti, what should I need to be working on of wrt langpacks in xubuntu?
<janimo> I saw it mentioned in the spec
<pitti> mdz_: you say that users who use -updates should not get security updates?
<mdz_> pitti: the two supported configurations are: security+updates, and security-only
<pitti> janimo: you mean in LangpacksDesktopfiles?
<janimo> yes
<pitti> mdz_: right, but if the -updates version is newer than -security, then -updates needs to be fixed as well
<mdz_> pitti: or -security needs a higher version
<pitti> mdz_: right, when the -updates changes are merged into -security; this branch unification helps me, but isn't always appropriate IMHO
<pitti> it was for evolution, that's why I did it
<pitti> janimo: whichever library xubuntu uses to parse desktop files need to be taught to use gettext() for the translation instead of just taking the translated string in the desktop file
<janimo> pitti, ok
<janimo> so .desktop file no longer contain texts for all locales?
<pitti> janimo: the new changes in dapper for ubuntu won't break anything in xubuntu, don't worry; it's just an added feature
<pitti> janimo: they will, for backwards compatibility and e. g. for xubuntu or users of other WMs
<pitti> janimo: we will just additionally use langpack translations to update/add translations
<wasabi_> Uh so what's the "status file" refered to by /usr/sbin/install-docs?
<janimo> pitti, thanks
<wasabi_> ahh.
<pitti> mjg59: ping
<Kamion> mpt: the GnomeDruid class looks ideal for implementing the top level of https://wiki.ubuntu.com/UbuntuExpress/GnomeUserInterface, except that it has slightly different button arrangements which don't appear to be customisable
<Kamion> you always get Cancel, Back, and Forward, and there's a switch to change Forward to Finish
<Kamion> do you feel strongly enough about it that I should use something else?
<mjg59> pitti: Hi
<Kamion> or is GnomeDruid crack?
<Amaranth> Isn't GnomeDruid one of those deprecated "kill me now" kind of widgets?
<pitti> mjg59: I currently review laptop-mode to make acpi-support installable again
<Kamion> Amaranth: I have no idea. How is one supposed to tell?
<Kamion> and what's recommended instead?
<Amaranth> Kamion: Hopefully it'd be in the documentation.
<Kamion> Amaranth: hahahahaha
<pitti> mjg59: the shell script is scaringly long :) but all this code is just called from the /etc/power scripts anyway, so it does not process user input, right?
<Amaranth> Kamion: And _none_ of the documentation says what replaces it.
<ogra> afaik there was momentum to drop GnomeDruid ages ago
<ogra> but since this didnt happen *shrug*
<Diziet> dchroot--
<Kamion> ok, somebody tell me what to use instead and I'll happily use it; I have no attachment to anything in particular, it just seemed plausible
<pitti> mjg59: erm, laptop-mode-tools, of course
<Diziet> Cannot run commands in the chroot when the command starts with a `-'.
<mpt> Kamion, somebody asked me about a design detail for GnomeDruid's replacement recently
<Kamion> Diziet: no --?
<mpt> I don't remember who it was
<ogra> just plain glade with a content win and two buttons at the bottom ? 
<mjg59> pitti: Right
<Burgwork> Kamion, it appears to be here --> http://live.gnome.org/AddedDeprecatedInterfaces
<pitti> mjg59: are you happy with it from a functional POV?
<Diziet> kamion: No.  But you can use the first bug to work around the 2nd.
<Amaranth> What does GnomeDruid get you that a dialog and a couple lines of code doesn't?
<mjg59> pitti: Yup
<Diziet> dchroot ' -command' works but shouldn't.
<janimo> Kamion, do you think the UE installer will need gnome libs besides glade/gtk?
<Kamion> ogra: it wouldn't be a content Window, it would be something else. What would the content widget be called?
<pitti> mjg59: ok, fine, thanks; I'll do a report and some QA review
<Kamion> janimo: pluggable UI
<janimo> yes but the gnome ome
<janimo> one
<Kamion> janimo: and I'm not getting into that now because I have *this* problem to solve
<pitti> mjg59: could you please LSBify the init script?
<mdz_> Kamion: did you do your baz->bzr stuff using tailor, or bzr --baz-import?
<Kamion> janimo: I have absolutely no idea and don't want to think about it now
<Kamion> mdz_: bzr.integration on chinstrap
<Robot101> Kamion: http://live.gnome.org/ProjectRidley_2fEggAssistant
<mjg59> pitti: Sure
<ogra> Kamion, you have a win, a hbox and put the content in the upper part of the hbox.. add a buttonbox at the bottom part 
<Robot101> Kamion: EggAssistant is the mooted replacement for GnomeDruid
<Amaranth> libgnomeprintui is "not a part of the Platform"?
<Burgwork> Kamion, http://bugzilla.gnome.org/show_bug.cgi?id=115348
<Kamion> ogra: seems kind of inconvenient for changeable content; ideally I'd have a top-level widget for the content so that I could put the pages in separate glade files
<Kamion> Burgwork: deprecated> that page lists three gnome_druid_* functions none of which I care about :)
<ogra> you can put whatever you want into the top part of the hbox ...
<Kamion> ogra: not a Window, surely?
<ogra> but EggAssistant might be right, didnt work with it yet
<Kamion> anyway, gotta go for dinner
<mpt> Kamion, I'd rather not have (effectively) two cancel buttons at every step (I'm squeamish even about having two in the first step)
<Burgwork> Kamion, the bug is what you care about, that lists the patches for eggassistant
<ogra> nope, indeed, not a window
<pitti> mjg59: it looks like this package should be shipped for ppc as well, right? hd spindown will likely work there
<Kamion> Burgwork: ok, I don't want to use anything not in the distro yet though, I have enough to do
<mjg59> pitti: Should do, yup
<Burgwork> Kamion, my thought is that eggassisant is sort of a dapper+1 thing
<Robot101> Kamion: it's conventional to just copy egg widgets in to your app :-S
<Kamion> Burgwork: run away, then ...
<Kamion> Robot101: run away harder
<pitti> mjg59: so instead of making it an acpi-support dependency, what do you think of seeding it to desktop?
<Robot101> Kamion: everyone has one in their app somewhere :)
<ogra> Kamion, eggs might fit well with a dapper :)
<Kamion> ogra: I need a top-level widget that can be the root of a glade file
<Kamion> Robot101: not this app
<pitti> mjg59: (assuming that you just added the dependency to pull the package in; not sure if it is actually required by acpi-support now)
<Kamion> well, not copied C code anyway
<ogra> well, the druid widget isstill there ... it just looks a bit ugly imho ...
<Kamion> sounds like it doesn't meet mpt's requirements, so fair enough
<ogra> Kamion, but why do you want a single glade file for every page i wonder ? 
<Kamion> ogra: life is always easier when things are modular
<ogra> you can just reparent non-top-level widgets
<ogra> and keep all in one glade file
<Kamion> ogra: in this case I can put the separate glade files in different packages, conceivably
<Kamion> I do not want one enormous glade file that's a pain to edit and impossible to look back through its history
<ogra> true, but then you will need something like druid ...
<slomo> elmo: please sync swt-motif from debian/unstable... ubuntu changes can be dropped
<pitti> mdz, mjg59: laptop-mode-tools report written and approved (assuming that it get an LSB init script)
<Diziet> Woah, bzr is in universe ??
<slomo> elmo: please sync skippy from debian/unstable... ubuntu changes can be dropped
<slomo> pitti: are the few points by an upstream dev i added to the avahi main inclusion report useful for you?
<Riddell> slomo: got a URL for that?
<slomo> Riddell: https://wiki.ubuntu.com/MainInclusionReportAvahi
<Riddell> thanks
<BenC> FYI, linux-source-2.6.15, linux-meta and linux-restricted-modules all uploaded for 2.6.15-7.9
<ogra> and amd64 already built :)
<BenC> may your machines all reboot safely
<slomo> ppc too
<BenC> yeah, ppc and amd64 seem to be kicking i386's ass
* slomo will test it in a few minutes :)
<BenC> ppc64 beware, I know jbailey is experiencing lockups on his G5 randomly, seems to be X related
<mdz_> seb128: XCHAT ^W FURY
<slomo> Riddell: are you also interested in getting avahi into main for kde?
<Riddell> slomo: certainly am
<mdz_> can someone tell me the IP address from which I connected the last time I connected here?
<Riddell> 19:04 -!- mdz_ [n=mdz@69-175-232-197.vnnyca.adelphia.net]  has left #ubuntu-devel ["Ex-Chat"] 
<mdz_> Riddell: thanks
<mdz_> hmm, no, that's where I'm connected from now
<mdz_> i mean the previous time
<seb128> mdz_: your patches are welcome :)
<ogra> -> mdz_ (n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net
<BenC> mailto:n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net
<mdz_> thanks
<slomo> Riddell: cool, i'll most probably update to 0.6.1 tomorrow... are the kde pieces already 0.6-compatible?
<BenC> s/mailto:/
<ogra> lol
<mdz_> silly dynamic IPs
<ogra> xchat i great
<ogra> *is
<Riddell> slomo: hmm, no idea, I'll ask
<Riddell> slomo: much changed?
<mdz_> seb128: I can send you my old xchat patch which disables the shortcut the easy way ;-)
<slomo> Riddell: the API changes slightly... all current packages we have which are using avahi (i.e. nss-mdns and s-d-a) already work with the new API
<seb128> mdz_: easy fix for you
<seb128> mdz_: open the "Discussion" menu, go on the "close" label, press backspace
<seb128> mdz_: you need to have /desktop/gnome/interface/can_change_accels (gconf) set
<ogra> BenC, if you are interested in a user experiencing #16874 / #1994, there is one in #edubuntu
<BenC> ogra: with dapper kernel?
<ogra> nope, breezy
<BenC> 16874 says it was fixed upstream in 2.6.14-rc
<ogra> he cant use the card on install apparently ... but since he sets up the system for a review, he might be willing to play around with it ...
<ogra> ah, k
<dholbach> brb
<ogra> i just noted the bug was NEEDINFO
<ogra> didnt look deeper into it
<pitti> slomo: everything is useful for these reports :) I didn't yet look at it, though; I'm off tomorrow, and had some higher-urgency things today, sorry
<Burgwork> mpt, ping
<mpt> Burgwork, pong
<Burgwork> mpt, do you have the mockup for the new logout dialog?
<slomo> pitti: np :)
<mpt> Burgwork, no, but I could rustle one up right now if you want
<mpt> (or in six minutes, at least)
<Burgwork> mpt, np if you don't have one on hand
<Burgwork> I thought I saw one
<mpt> Burgwork, you probably saw my shutdown dialog
<Burgwork> mpt, yes, but where is taht one the wiki?'
<ogra> mdz_, pitti gnome-screensaver main inclusion report ready ...
<mpt> Burgwork, https://wiki.ubuntu.com/PowerManagementConfiguration#head-86fd22dbf812daed4c3bcb0d55f12a6b5b9f1f56
<ogra> mpt, where is hibernate ? 
<mpt> ogra, that's what I was discussing this morning with dholbach and co.
<mpt> how to make the distinction between Sleep and Hibernate
<ogra> in german it says sleepmode (Disk) and sleepmode (Memory) here in the current logout dialog
<mpt> eww
<ogra> which is not perfect, but quite good already imho
<ogra> since its both "sleep"
<ogra> Your rationale doesnt cover low battery warnings for wireless mice or keyboards ? 
<ogra> why is that ? 
<mpt> That's not my rationale
<ogra> ah, ok
<ogra> i thought it is ...
<mpt> I did the Use cases and Design sections
<mpt> well, rewrote the use cases to be more than one sentence each :-)
<ogra> heh
<ogra> yes, our specs are all pretty bad literature ;)
* pitti is overwhelmed with the ever-growing set of mdzs we have now
* \sh is updating his profile on linkedin
<ogra> pitti, i'm wondering how long it takes until he draws a full line over the screem :)
<ogra> *screen
<pitti> heh
<sivang> \sh: https://www.linkedin.com ?
<\sh> sivang: jepp
<sivang> \sh: seems cool
<Kamion> oh, that thing that people keep using to spam me
* Kamion doesn't do "social networking tools" - can you tell? :)
<\sh> Kamion: I need to improve my connections to other countries and other people and other managers to have a new job  VERY SOON
<HiddenWolf> jdub, ping
<janimo> pitti, firewall spec is being worked on by someone or deferred?
* \sh will leave ISH very soon..and if I don't have a new job ... I don't see any chance to work for ubuntu at least 5 hours per day :(
<ogra> janimo, isnt that from breezy ? 
<pitti> janimo: that's carstenh 's playground
<janimo> ogra, dapper low prio too I think
<elmo> BenC: server-{high,low}end ?
* ogra wonders if Riddell rewrites cdbs completely :)
<dilinger> hm?
<ogra> dilinger, see dapper-changes :)
<dilinger> heh
<Riddell> ogra: I've added about 4 lines.  (and a lot of debugging due to random buildd breaking)
<mdz_> BenC: I'd prefer that we used server-generic and server-highend, or even just server and server-highend
<BenC> ok, easy change
<ogra> Riddell, i'm just seeing all these uploads :)
<elmo> what _is_ server-highend?
<BenC> > 8 CPU's
<BenC> Summit/ES7000/BIGSMP kernel
<BenC> like machines that cost as much as my house type deals
<elmo> hum
<elmo> not to bikeshed, but wouldn't -bigiron or -moremoneythansense be better?
<Keybuk> -fabbione
<ogra> ++
<elmo> I'd consider a fully loaded 4-way DL585 high end, but maybe mark just isn't buying me the right sort of presents
<BenC> the naming scheme is going to be pretty moot, since we'll have to document what exactly they are for anyway
<BenC> no matter what you call the bigone, people are going to say "well, this is a bug server to me, so let's install it"
<BenC> s/bug/big/
<elmo> oh, oh, I know
<elmo> kernel-server-SUPERSIZEME
<elmo> or kernel-MAXIMUM-server
<BenC> personally I wanted -server-EATS_GOATS_FOR_DINNER
<dilinger> -realultimatepower?
<Keybuk> bigiron is the best suggestion so far, sysadmins tend to know what that means
<Keybuk> the kind of server that you need structural support in the floor to buy
<BenC> exactly
<BenC> ok, -server and -server-bigiron it is
<BenC> you people are never around when I bring this up _before_ releasing it :P
<ogra> change your timezone  :)
<BenC> being online 16 out of 24 hours doesn't matter? :)
<sivang> \sh: I need to add myself there as well .... Or else I will be QAing on windows as well , which is urgh^2 :-/
<\sh> sivang: email?
<sivang> \sh: you mean, mine? :)
<ogra> BenC, hmm, might be the wrong 16h then :)
<\sh> sivang: yes
<sivang> \sh: PM you
<zyga> \sh: kudos for the MOTU school
<zyga> \sh: what is the shedule?
<ajmitch_> morning
<\sh> zyga: 10th dec, ajmitch will held a lesson about "packaging without debhelper or cdbs"
* ajmitch_ is afraid
<zyga> \sh: what time?
<zyga> I'll gladly attend
<zyga> :-)
<zyga> also: are thre any logfiles?
<sivang> \sh: what lessons have I already missed ?
<ogra> shuffling around zeros and ones until you have a deb  ?
<zyga> like irc logging
<ajmitch> still considering what time is going to hurt people the least
<zyga> #ubuntu-school or something :-)
<ajmitch> either 10:00 UTC or 18:00 UTC
<zyga> ajmitch: average of the timezone probably 
<\sh> zyga: #ubuntu-motu-school
<zyga> +18
<ajmitch> I'll be sleeping between those times ;)
<\sh> ajmitch: 18 UTC is quite nice I think for everybody :)
<ajmitch> \sh: that'll put a definite 2 hour limit on it
<zyga> UTC == +0 timezone?
<ajmitch> I need to leave by 20:00 UTC at the latest
<\sh> zyga: yes
<\sh> ajmitch: hmmm...17:00 UTC...I actually dunno what's your local time then
<zyga> that suits me (and probably everyone else from eu)
<fabbione> Keybuk: -fabbione would really sinthetize the size, doesn't it? :P
<ajmitch> \sh: 6AM
<\sh> ajmitch: sunday?
<Keybuk> fabbione: I was just thinking of your love for the big iron, actually
<ajmitch> yep
<\sh> ajmitch: good one :)
<zyga> is there any idea to make a recurring shedule?
<zyga> like every week?
<fabbione> Keybuk: ehehe
<\sh> zyga: there will be a presentation 
<ajmitch> \sh: *maybe* 6 AM is still possible
<ajmitch> if I go to sleep reeally early ;)
<ajmitch> ok, got to run to work
<\sh> ajmitch: would be cool :)
<ogra> \sh, did you ask mike hearn about an autopackage lesson ? 
* ogra runs
<zyga> heh
<\sh> ogra: I'll eat your cats the next time...grrrr
<ogra> *g*
<\sh> oh no...I can't eat your cats...when I'm drinking I never eat .. and you owe me bacardi gold :)
<ogra> granted :)
<\sh> .oO(python and no xml parser in the std lib...lol)
<\sh> and finally my new sempron64 will be delivered tomorrow
<\sh> I can fix the universe at least
<ogra> the powerpc guys didnt answer my mail yet :/
<\sh> ogra: hmmm...create an ebay account dude..
<desrt> can i just randomly create a new upstream project in launchpad for bug-tracking purposes even if it's not packaged by ubuntu?
<desrt> like... is this a kosher use of launchpad?
<ogra> thast the plan of malone at least ...
<Burgwork> desrt, yes, that is kosher
<ajmitch> \sh: who should I give my home phone number to to wake me up? ;)
<desrt> awesome.
<ogra> but i'm not sure if youre supposed to creae a product of it first
<\sh> ajmitch: your mobile number is still valid?
<ogra> *create
<Burgwork> desrt, one might even say that is the whole point of LP
<desrt> Burgwork; that's excellent
<ajmitch> \sh: nope, the phone is probably somewhere in montreal :)
<Burgwork> people seen the new gnome bugzilla interface?
<Burgwork> it doesn't suck!
<\sh> ajmitch: thats why I ask...
<ajmitch> \sh: want to post a mail to the motu list with the new time for me?
<ogra> Burgwork, didnt look different 1/2h ago
<\sh> ajmitch: hmm...send me your new mobile number or homephone...so I can give u a ring :)
<Burgwork> http://bugzilla-test.gnome.org/
<\sh> ajmitch: I'll announce :)
<ajmitch> since 6AM should be mindnumbingly early enough for me
<\sh> ajmitch: u will hear the lovely voice of \sh then :)
<ajmitch> lucky me
<ogra> Burgwork, but still very buggy... every search, no matter what for gives yu a list with 6741 bus
<ogra> *bugs
<Burgwork> ogra, htat is a db issue
<Burgwork> ogra, not a UI one
<ogra> the ui looks like bugzilla with round corners ...
<ogra> just some different css
<Burgwork> log in and go here --> http://bugzilla-test.gnome.org/describeuser.cgi
<\sh> mdz: if you have time..would you be so kind an spare a few mins with amu and me to explain in detail the meaning of http://lists.ubuntu.com/archives/sounder/2005-December/003340.html ? please ping amu or me :) thx :)
<ogra> Burgwork, seems they dont share the same DB, i cant log in there
<Burgwork> ogra, they share the same login ID
<ogra> doesnt work for me ..
<Burgwork> hmm, anyway, it looks good
<Burgwork> will be live on the 18th of Dec anyway
<mdke> Burgwork, shiny
<dholbach> good night
<ogra> night dholbach 
<dholbach> bonne nuit, ogra
<mdke> elmo, jdub, the doc-commits mailing list is still down, can you help?
<elmo> mdke: no it's not
<elmo> mdke: read your email
<mdke> elmo, i read it...
<elmo> http://lists.ubuntu.com/archives/ubuntu-doc-commits/2005-December/001705.html
<elmo> it's working fine
<elmo> you're going to need better details than "it's not working" if you want me to actually look at it
<mdke> ok
<mdke> elmo, that message is the last one we've had, it was last week sometime. Since then we are at revision 2187, and no mails have come through
<mdke> last 13 commits haven't come through
<mdke> elmo, if I can give any more details, let me know what you need
<zyga> bye guys
<\sh> elmo: please sync gtklookat from unstable, dropping ubuntu changes ok
<\sh> elmo: thx
<elmo> mdke: try a dummy commit for me?
<mdke> elmo, sure
<mdke> elmo, sent now
<mdke> (2188)
<mdke> elmo, mail arrived too :)
<elmo> mdke: right, fixed.  sorry about that
<mdke> elmo, np thanks a lot. it was rt 1077 if you wanna close it
<elmo> already have, thanks
<mdke> great, thanks again!
<seth_k> For future reference, how do you mark a bug fixed in Launchpad? I filed a merge bug, the merge was done, but I never could figure out how to mark the bug fixed... dholbach had to do it
<fabbione> hmm
<fabbione> is the new kernel building somewhere for i386?
<fabbione> there are no build logs yet and it has been a few hours
<Kamion> seth_k: edit status, up at the tpo
<Kamion> tpo
<Kamion> GAH, top
<seth_k> Kamion, does launchpad have editbugs privilege requirements or something? I don't have any link like that (I reported the bug, even)
<mdke> yeah, you need to be the assignee i think
<seth_k> ah ha :) alright, no bustage then, I'm happy
<seth_k> cheers Kamion, mdke 
<Kamion> you'd have to ask on #launchpad for a definitive opinion there, I don't know
<Nafallo> maswan: ping :-)
<\sh> jbailey: ping
<greenpenguin13> hey that means im adventurous :)
<greenpenguin13> does anyone apart from me get a seg fault with synaptic on dapper?
<mvo> greenpenguin13: I haven't had any reports about this yet, did you do a compelete upgrade to dapper? or only some packages? when does the segfault happens?
<TerminX> on a similar note, has gnome-settings-daemon been broken since around Thanksgiving for anyone else?
<seb128> TerminX: no bug about this
<greenpenguin13> whenever i start dapper :(
<greenpenguin13> had it for a while
<TerminX> seb128: it dies with some mention of xklavier
<seb128> TerminX: what sort of mention?
<greenpenguin13> whenever i start synaptic even
<TerminX> is there a pastebin site I can use to show you?
<seb128> pastebin by example :p
<greenpenguin13> joseph@pingu:~$ sudo synaptic
<greenpenguin13> Segmentation fault
<greenpenguin13> joseph@pingu:~$
<TerminX> seb128: http://pastebin.com/451563
<seb128> greenpenguin13: sudo gdb synaptic, (gdb) run
<seb128> TerminX: what version of Ubuntu do you use, what keymap have you configured?
<TerminX> I'm using Dapper right now
<greenpenguin13> Program received signal SIGSEGV, Segmentation fault.
<greenpenguin13> [Switching to Thread -1221753152 (LWP 6461)] 
<greenpenguin13> 0xb749746d in __gnu_cxx::__pool<true>::_M_reclaim_block ()
<greenpenguin13>    from /usr/lib/libstdc++.so.6
<\sh> #ubuntu-motu-school: 2005-12-10/17:00 UTC - Topic: Packaging without debhelper and cdbs - Prof.: Andrew Mitchell 
<TerminX> and I haven't changed any key mapping stuff
<seb128> I've to plan a "why starting to package with cdbs" :p
<\sh> mvo: did you rebuild it?
<mvo> greenpenguin13: can you please type "bt" and put the result (a long list) into paste.ubuntulinux.nl?
<\sh> seb128: jbailey just applied...you do "Gnome Packaging the right way" :)
<greenpenguin13> sure
<mvo> \sh: yes, it should work
<ajmitch> \sh: what is jbailey teaching?
<mvo> \sh: but *should* is the important bit here :)
<\sh> ajmitch: cdbs :)
<ajmitch> yay :)
<seb128> ajmitch: your course sucks
<ajmitch> seb128: sure it does
<jbailey> ajmitch: My talk is probably "Enhancing your sex life with cdbs"
<\sh> mvo: you bet :)
<ajmitch> seb128: \sh made me do it
<seb128> I don't get why you guys trying pushing beginner to hard stuff
<jbailey> I'm trying to work on the same theory that the gnome people are.  If a product doesn't help you get laid, it doesn't have mass market appeal.
<seb128> to make them run away?
<ajmitch> jbailey: hm, I didn't find that in the source yet :)
<seb128> jbailey: ah ah :)
<\sh> jdub: please teach me the breezy/dapper/whatever dance..the next time I need to dance with you on the "PR stage" ,)
<ajmitch> seb128: because cdbs is great when you know what you're doing
<seb128> jbailey: what's going on with cdbs2, we still lack multibuild ...
<jbailey> jdub: I vote for the whatever dance.
<seb128> ?
<ajmitch> seb128: plenty of people still just use dh_make templates without understanding debhelper at all
<jbailey> seb128: Aren't you supposed to be asleep? =)
<\sh> ok...just for the rational
<seb128> ajmitch: I don't think you need to know the internals of everything to start
<ajmitch> seb128: certainly not
<seb128> jbailey: it's only 11pm :)
<jbailey> One thing I do appreciate is that at least ajmitch's talk is a *true* bare bones talk.
<TerminX> seb128: do you have any ideas about that gnome-settings-daemon issue?
<jbailey> As opposed to "cdbs it too high level.  Let's use debhelper instead" =)
<ajmitch> jbailey: I'll try & use dpkg-dev at least :)
<\sh> debhelper and cdbs are cool helper applications...but if you don't know what happens behind the scene, it will cause more troubles.
<seb128> ajmitch: packaging without any dh_* is likely to just scare people away
<jbailey> ajmitch: I think you have to.  Last I heard, they're not real ar archives.  They only pretend to be.
<\sh> seb128: no
<seb128> should I start running away?
* seb128 doesn't read dh_ sources every day
<jbailey> Anyhow, really going grocery shopping this time. =0
<seb128> I'm lucking not beeing a motu :p
<\sh> seb128: stop...you are using a keyboard where you enter the numbers with "shift"
<ajmitch> seb128: it's not mandatory to attend :P
<\sh> seb128: so you can't be scared by "packaging without anything"
<seb128> no, but I think that's pretty useless
<\sh> seb128: it's building a wall of knowledge
<seb128> you don't need to be a Makefile wizard to use dh_*
<seb128> that's crap
<\sh> seb128: do you think many people are reading manpages?
<\sh> or info pages?
<seb128> no
<\sh> see..
<seb128> and?
<\sh> we will change it
<greenpenguin13> there
<seb128> that's not showing them 400lines of Makefile that will fix the issue
<seb128> sure
<ajmitch> seb128: I'll try & keep it gentle & explain as much as possible
<seb128> ajmitch: still, reading a "good old way hand made Makefile of 400 lines" is nothing useful to package using dh_*
<ogra> seb128, most packages arent cdbs packaged, soif you have to fix stuff, cdbs is the worst to start 
<seb128> I'm pretty sure nobody will learn for an 1 hour course
<seb128> you should rather teach them to use the dh_*
<ogra> yes
<mdke> hi all, has anyone got time/strength of will for some dapper new kernel/udev debbugging? or shall I just go to bugzilla?
<\sh> seb128: it's a start...and we will build on this knowledge..it's not "use it for daily use" but it's "now you know the truth, and now you can hide the truth as daily business"
<seb128> that's like saying people need to now asm to do python
<ogra> but ajmitch wants to starts the basics of dh_make
<ogra> seb128, thats wrong
<ogra> seb128, most motu work is done on existing packages
<greenpenguin13> all on there
<ogra> most pacxkages we have arent cdbs
<seb128> I'm not speaking about cdbs but the dh_*
<ogra> seb128, if you want to be a car mechanic you shoul knoe what a wrench is, dont you ? 
<\sh> infinity wanted to see that all motus are going the "NM/DD" way...we start it now, alltogether..even ogra will attend and learn
<ogra> bah, my typing sucks
<seb128> modern car have a lot of electronic and people probably don't know how to program the CPU
<seb128> and they don't need to
<ogra> they need to nowadays
<\sh> seb128: see..we will show them :)
<seb128> they just know they have to plug the calculator on it
<seb128> bah
<Kamion> come on, "program CPU" is not a good analogy for "stick files in a package somewhere" - the latter is hardly rocket science
<ogra> seb128, we have a lot of old 2CV in the archive ;)
<\sh> seb128: sorry..there is no way back..not for ajmitch not for me...the announcement is made...and we will stick to it...and I have a lot of feedback
<Kamion> I think you're making it out to be an awful lot harder than it is
<\sh> ogra: lol
<\sh> Kamion: believe me when I say it will be fun...and it's not hard to understand
<seb128> ogra: I doubt you have a lot of packages not using dh_* and having packaging bugs to fix
<Kamion> I think you have a strange idea of fun, but it's up to you :)
<ogra> \sh, he's not opposing you
* Kamion has several such packages; they aren't a problem
<Kamion> generally I've inherited them, but still
* ajmitch will be doing it with a fairly simple gnu package
<ogra> seb128, thats true... butits still good to know the basics 
<\sh> and thinking about jbailey explaining cdbs from scratch...
* seb128 had to redo his first package without dh_* for NM task
<seb128> and I didn't find that fun
<seb128> neither useful for what I'm doing now
<ogra> because you switch everything to cdbs :P
<ajmitch> it's not so much the doing, as the explaining
<seb128> they will not keep anything of what you explain
<Kamion> it's still just cp, install, and a couple of pretty well-documented dpkg-* commands. kind of different from assembly versus python
<ajmitch> we don't expect everyone to run out & package without it
<\sh> seb128: as I said : "How to package gnome/kde software with cdbs"..I'll ask riddell to second you :)
<seb128> we would better explain what the dh_* are and how to use them
<\sh> seb128: when do you have a free timeslot? January that is
<ajmitch> seb128: which is what I'll try & do
<ogra> in my example ite the equivalent of a spark plug and a carbruretor 
<mvo> greenpenguin13: any luck with the backtrace yet? 
<seb128> I don't want to participe to this stuff :p
<\sh> seb128: you just applied :) thx :)
<greenpenguin13> should be on paste.ubuntu.nl
<ogra> seb128, do a class about cdbs :)
<Kamion> I can see why that requirement is there in NM; having been an AM I found it impossible to distinguish actual talent from dh_make, so I had to have *some* way to test people
<Kamion> well, not a requirement, it's one option that AMs use
<\sh> Kamion: AM?
<Kamion> I would prefer some other option if it were available
<Kamion> \sh: Debian application manager
<ogra> \sh, application manager 
<\sh> Kamion: ah
<\sh> Kamion: thx..again I learned something new :)
<seb128> Kamion: I don't say it's not useful for NM, I say I doubt it's really useful for maintaining a package with a modern packaging system 
<ogra> \sh, call it "packaging teacher and tester"
<Kamion> nowadays I imagine I'd say "ok, now please explain to me why each of those bits are there and what they do"
<Kamion> seb128: sure, I'd tend to agree; perhaps ajmitch's talk should be viewed as "a guide to the guts of the Debian packaging toolchain"
<seb128> right :)
* mvo nods and is with seb128 here
<Kamion> rather than a howto
<\sh> Kamion: would you like to speak up for the "Debian way of a packagers life"? I would like to see our ancestors being mentioned...
<daniels> meh, packaging without dpkg is the true test of one's mettle.
<Kamion> \sh: with my current workload, not especially, although maybe later
<seb128> hey daniels
<ajmitch> morning daniels 
* ogra still thinks its helpful to know about wrenches if you want to turn screws
* mvo waves to daniels 
<\sh> Kamion: would be cool...well, this educational thing is growing..I have a load of topics right now..and I have to sort it out
<daniels> yo sebarino, ajmitch, mvo
<\sh> daniels: g'evening :) and thanks for giving back xvfb-run :)
<daniels> mvo: sorry I didn't get back to you about your dri problem; completely forgot
<daniels> \sh	np
<mvo> daniels: oh, not a big issue. I'm just itching to use my shinny r300 for something usefull :)
<seb128> TerminX: what keymaps do you use?
<seb128> daniels: is there any slowness issue due to new xorg? It takes like 1-2s to draw the nautilus background when switching desktops here
<TerminX> seb128: whatever is default AFAIK
<\sh> Kamion: btw...when do you have time to speak about ubuntu-express and kde ui add?
<seb128> daniels: that happens for like 10 days
<seb128> TerminX: gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
<daniels> seb128: not that I know of ... what sort of hardware?
<seb128> daniels: ATI 9600 pro, "ati" driver
<daniels> seb128: weird
<TerminX> seb128: says us pc104 with overridesettings = false and no options set
<daniels> seb128: if anything, it should've got *faster*
<\sh> ogra: do you have a nvidia card in your laptop?:
<mvo> daniels: oh, I have the same issues, I blamed gtk so far :P
<Kamion> \sh: I'm writing the guts of it at the moment, so now is not a great time because I don't actually really know how it'll work yet
<ogra> yup
<seb128> it doesn't happen without nautilus
<mvo> (ati as well)
<Kamion> \sh: I'm hoping to have the structure nailed down a bit more solidly in the next week or two; maybe then
<seb128> daniels: could it be a xrender issue? I know that cairo has some workaround for slowness like this
<seb128> TerminX: could you copy that on pastebin?
<\sh> Kamion: ok...I actually don't know if we can make it for dapper or not...but we need some background about how we can plug in the qt/kde UI and what we can use for some things..speaking of "replacement of gparted", world map for timezones etc.
<\sh> ogra: is it working with the orig. nvidia drivers on amd64?
<Kamion> \sh: oh, all the background for that is already in the wiki; start with https://launchpad.net/people/kamion/+assignedspecs
<daniels> seb128: i think that was only for repeating offscreens though
<ogra> \sh, i didnt try for some time 
<ogra> but it used to
<daniels> seb128: try Option "AccelMethod" "EXA" and run xcompmgr -a if you want a shiny fast desktop
<seb128> daniels: I would like to have the same speed as before without using new options to start
<\sh> Kamion: wow..u improved the specs..I should invest more time, when I'm not working anymore :)
<seb128> daniels: it takes like 2s to switch workspace atm, and I do switch workspaces a lot
<Kamion> \sh: there's a lot more there than there was at the start of UBZ, yes ;)
<TerminX> seb128: http://pastebin.com/451619
<TerminX> (changed it to pc101 in gnome-keyboard-properties because I have a 101 key keyboard but as I expected it didn't do anything)
<mvo> seb128: do you have working dri on your ati with dapper?
<daniels> i think it needs a new drm
<seb128> TerminX: does "setxkbmap -model pc101 -layout us -option '' -print | xkbcomp - :0.0" works as expected?
<daniels> seb128: yeah, I'm just curious if it's a geberal thing or an XAA thing specifically
<seb128> mvo: how do I know that?
<seb128> daniels: BTW while you are around :p
<seb128> $ Xnest :1
<seb128> error opening security policy file /usr/lib/xserver/SecurityPolicy
<seb128> Could not init font path element /usr/share/X11/fonts, removing from list!
<seb128> Fatal server error:
<seb128> could not open default font 'fixed'
<ogra> seb128, do a benchmark with glxgears *giggle*
<TerminX> seb128: apparently nothing on my system depends on package xkbutils because it isn't installed
<mvo> seb128: glxinfo will tell you
<seb128> TerminX: ah ah
<TerminX> shall I install it?
<seb128> yep
<seb128> mvo: direct rendering: Yes
<TerminX> wait, what the hell
<mvo> aoooohhh, I have working dri as well. something happend on the last upgrade. 
<TerminX> seb128: okay, what you told me to do gives me errors, pastebin them?
<seb128> TerminX: ?
<TerminX> that setxkbmap line you gave me gives me errors
<TerminX> http://pastebin.com/451637
<jdong> ugh what a day it's been already.....
<jdong> is elmo around?
<seb128> TerminX: xorg issue, bouncing to daniels ;)
<seb128> TerminX: g-s-d is doing this setxkbmap call
<ogra> xserver-common bg
<ogra> bug
<TerminX> okay
<seb128> this syntax error is weird
<daniels> ARGH!
<daniels> TerminX: you get that too?
<TerminX> yeah
<daniels> it's complaining about compat/misc
<daniels> i haven't been able to track it down
<daniels> seb128: heh, cool
<jdong> I've been getting very frustrated recently at the lack of response from elmo as to backports build requests
<TerminX> in your defense, however, this install has been around forever and might have little bits of other X installs in it still
<daniels> seb128: i'll sort out the xnest thing in a sec
<seb128> daniels: thanks ;)
<daniels> mvo: working dri> kernel
<mdke> jdong, yes he is around. You can leave him a message or email though
<jdong> mdke: you think I haven't been trying e-mail for the past 3 weeks?
<mdke> jdong, i don't think
<daniels> also, xbase-clients depends on xkbutils
<mvo> meh, starting ppracer gave me a blank screen and dosn't want to give anything back
<TerminX> daniels: yeah, that was a mistake on my part
<TerminX> (about it not being installed I mean)
<mvo> (that is, it doesn't want to become a non-blank screen)
<daniels> TerminX: does rm -rf /etc/X11/xkb/{symbols,compat} && sudo dpkg -i --force-confmiss /var/cache/apt/archives/xkeyboard-config_0.6-8_all.deb, help?
<daniels> mvo: heh, cool
<TerminX> I'll check, sec
<jdong> this current Backports system isn't working out... I can't live with an unpredictable build timeframe.... that spikes into 3+ weeks at times
<jdong> I get the feeling like the Backports Project is being ignored around here and shoved to the bottom
* mvo tried restarting gdm already, a reboot is required
<jdong> which is fine and I understand there are other priorities
<jdong> but the current build/mirror/archive architecture is not working too well with me since the beginning of Breezy
<TerminX> daniels: I still get the error
* mvo reboots
<mdke> jdong, if you don't find the right person here in irc, perhaps it would be worth emailing the devel mailing list to discuss it
<daniels> TerminX: argh
<jdong> mdke: thanks; I'll first try leaving him a message, then perhaps I'll go off to the mailing list
<mdke> cool
<jdong> mdke: I'm usually very patient :)... Just with all the forums crap also going on today, I'm getting kinda cranky :)
<\sh> daniels: can you have a look at http://bugzilla.ubuntu.com/attachment.cgi?id=5186 and http://bugzilla.ubuntu.com/attachment.cgi?id=5187..there is some issue with xauth I think
<TerminX> daniels: also, is it normal that I have to manually set mod5 to scroll lock using xmodmap?
<mdke> jdong, i'm sure you can find a solution that works for everyone
* mvo is impressed by the shinny new usplash logo
<elmo> jdong: you're being a little disingenuous - AFAIK there hasn't been a 3+ week delay ever.  backports wasn't created for quite some time due to the various LP vs DAK issues.  then it was created, and someone decided that meant backports was open.  it wasn't.
<jdong> elmo: can you push through the 5 or so outstanding requests, and also a rebuild of vlc?
<elmo> jdong: and your requests aren't making things easier either.  the requests to me should be final "backport this", not 10+ msg threads about whether or not it should be backported, and maybe foo should too
<jdong> elmo: sorry about the occasional trail of messages that tend to go with disagreements about backporting X or Y....
<jdong> elmo: is there a bug tracking system or some other way you'd prefer?
<elmo> jdong: bbias, I need to deal with something else
<daniels> TerminX: that's a symptom of missing xkb
<TerminX> ah
<TerminX> that happened about a year ago I think, I set up a script to fix it whenever I logged in and kind of forgot about it :)
<daniels> \sh: sounds like it's simply not working, though no idea why
<TerminX> I think that was way back when it was still a sid install before warty, actually...
* mvo gets the feeling that X hates him. EXA killed my box solid (no ping, only hard reboot)
* ogra 's X works fine as long as he doesnt try to run it on ltsp clients
#ubuntu-devel 2006-12-04
<wasabi> fun. a new race in evms.
<jdong> oh look at that...
<jdong> bug 74314
<Ubugtu> Malone bug 74314 in dapper-backports "Please backport firefox 2.0 from feisty" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74314
<jdong> another one :)
<wasabi> Silly Firefox.
<desrt> does anyone know if it was a conscious choice to have mdns in the nssswitch on server installs?
<desrt> because that seems like a pretty poor choice for servers
<desrt> or was it more like one of those things that just carried over from the desktop without anyone really thinking about it?
<erdalronahi> Hi, I am from the Kurdish LoCo/Translation team. I have only today realized that the "Kurdish Ubuntu" problem was discussed a lot on the ubuntu-devel mailinglist.
<erdalronahi> We really had difficulties to follow all the discussions on several mailinglists in several languages
<erdalronahi> If there is anything you would like to ask from our team, please do so
<jdong> erdalronahi: I'm not sure how many developers are active at this time though :-/
<gnomefreak> none if any
<erdalronahi> That's okay, I will write to the ubuntu-devel-list, too
<jdong> ok
<jdong> good luck, erdalronahi :)
<erdalronahi> I was only shocked when I just read some of the polemics
<erdalronahi> and thought I'd say hello to you
<erdalronahi> thanks, jdong
* jdong now tries to read the list and figure out what this is all about :)
<jspiro> hi all, idea : when you double-click a .mov file, ubuntu should download and install .mov player software/codecs automatically.
<jspiro> when you double-click a .wmv file, ubuntu should download and install .wmv player software/codecs automatically.
<jspiro> good idea?
<Chipzz> that's actually a spec allready
<Chipzz> but depending on upstream implementing part of it iirc
<jspiro> which part?
<Chipzz> jspiro: actually, the idea is to have a gstreamer plugin which spawns a program when a codec is not found
<Chipzz> the plugin would be reusable over different systems
<Chipzz> the actual program would be different on different distro's
<Chipzz> so I think it's blocking on the plugin being written
<jspiro> cool. couldn't you guys write it yourself to make sure it's done in time for feisty?
<jspiro> (just in case)
<Chipzz> I'm not an ubuntu-developer really :)
<Chipzz> just slacking here
<Hobbsee> jspiro: not sur eif you've seen the common customisations spec - hopefully that will be covered in that.
<Burgundavia> https://blueprints.launchpad.net/distros/ubuntu/+spec/easy-codec-installation
<jspiro> hmm. what if you click on a file you don't have a viewer for at all? like, say, an Inkscape file.
<Burgundavia> inkscape uses svg
<Burgundavia> which works just fine in eog
<Chipzz> Hobbsee: wasn't that what I was talking about?
<Hobbsee> Chipzz: possibly.  not sure @ the gstreamer plugin bit
<jspiro> how about .exe files auto-downloading and installing Wine?
<jspiro> there are always more extensions to handle.
<Burgundavia> not going to happen
<crimsun> "automatically" sounds -crackful- at best.
<Hobbsee> jspiro: does that also apply to viruses that might be downloading?
<jspiro> Hobbsee, if users can untar and launch binaries, why can't they unzip and run .exe files?
<Hobbsee> jspiro: they can.  but the distro shouldnt do that for them.
<Hobbsee> jspiro: ie, let the user shoot themself in the foot if they really want, but dont help them do it.
<jspiro> ok, but what if they mark the .exe as executable themselves?
<jspiro> then why shouldn't it install Wine?
<Hobbsee> because we dont package the latest versions of wine
<Burgundavia> because 9 times out of 10, the app is going to fail
<Hobbsee> +1 Burgundavia.  knew i'd forgotten something there
<jspiro> Burgundavia, what about known-good apps like the top 30 listed at http://appdb.winehq.org?
<Burgundavia> right, and wine breaks things at regular intervals
<zul> anyone who wants to run an .exe should use vmware or something like that
<jspiro> ok, so it should download and install vmware :)
<jspiro> wait, vmware isn't packaged. :(
<zul> vmware-player is
<Burgundavia> and is very non-free
<jspiro> qemu is Free.
<Burgundavia> possibly non-supported files should popup a dialog that links to an online page listing alternatives
<jspiro> Burgundavia, hmm, like in Windows.
<Burgundavia> umm, no version of windows does that
<Hobbsee> it does bring up a dialog, asking what program you want to use to run it
<Burgundavia> that is not what I am talking about
<Hobbsee> i think that's what jspiro is though.  the "like in windows" bit
<Burgundavia> I am talking about saying "we know we don't support this file, here are ways to get it working"
<Hobbsee> that sounds sane
<jspiro> it brings up a dialog offering to take you to FilExt.com or some site like that.
<jspiro> or you can just choose a local app to use to view it.
<Burgundavia> right
<Burgundavia> start a discussion on -desktop and then once a rough consensus is reached, write a spec
<Burgundavia> then find somebody to do it :)
<jspiro> nah :)
<Burgundavia> only way it is going to get into Ubuntu
<jspiro> it's not that important that it's worth bothering for me.
<Hobbsee> then why'd you bother to bring it up here?
<jspiro> Hobbsee, i thought it could be a mere wishlist bug filed against gnome or some such.
<Hobbsee> jspiro: then file it, instead of random wand waving, hoping someone else will do it?  we're not fairies, you know.
<zul> heh some of us ar
<zul> are even
<Hobbsee> heh
<ajmitch> zul: us? you count yourself in there?
<zul> of course
* ajmitch refrains from comments
<Hobbsee> ajmitch: then again, zul *does* work on xen.
<Hobbsee> so he's a bit crazy anyway :P
<crimsun> a man with a stout heart he is.
<ajmitch> Hobbsee: it could be worse
<Hobbsee> heh
<ajmitch> he could work on kde
<Hobbsee> hah!
<zul> no i need some sanity left
<Burgundavia> ajmitch: he works on Xen and he is canadian
<ajmitch> Burgundavia: point
<bhale> Burgundavia: one hell of a beard, too
<Burgundavia> keeps the cold out
<bhale> or wins a ZZ Top lookalike contest
<fabbione> morning
<rmjb> night
<Hobbsee> hey fabbione 
<ajmitch> hello fabbione 
<wasabi> lp broke?
<wasabi> getting timeouts.
<bhale> wasabi: wfm
<wasabi> https://launchpad.net/distros/ubuntu
<wasabi> looks like other URLs work.
<bhale> suppose youre right
<rmjb> hey I see there's a Falcon repository software available?
<rmjb> does that do repo cacheing?
<bhale> falcon is a tool by Seveas to create apt archives
<bhale> i dont see how caching comes into it
<rmjb> is there a repo cacheing software available? for instance, one a company may use to cache packages used on it's desktop fleet?
* Hobbsee waves to bhale 
<bhale> apt-cache, apt-proxy
<bhale> hi Hobbsee 
<bhale> apt-cacher
<bhale> approx
<rmjb> thanks bhale apt-proxy looks like what I was thinking about
* rmjb hugs bhale
<Chipzz> bhale: apt-cacher is really really broken
<bhale> Chipzz: apt-proxy isnt exactly a shining example of good software..
<rmjb> I'm seeing now a lot of these types of projects are abandoned... trying to find one that isn't
<Chipzz> bhale: and apt-cacher just... BREAKS
<rmjb> but at least I have a direction
<Chipzz> bhale: apt-cacher can't resume downloads, and gives garbage when a file is incomplete
<Chipzz> which is bad bad bad
<Chipzz> you manually have to remove the file
<bhale> ok very sorry for mentioning it
<bhale> shrug
<Chipzz> bhale: I wasn't attacking you, just trying to explain why apt-cacher is not a good idea ;)
<Chipzz> anyway, that bug may have been fixed, but I think it hasn't
<Chipzz> I abandonded it quite a while ago
<Chipzz> (abandonded -> using)
<rmjb> Chipzz: since you were using it before what are you using in place of it now?
<Chipzz> rmjb: nothing
<rmjb> because you no longer have the need or there's nothing that works?
<Chipzz> I don't have a large setup anyway; was just trying to save some bandwith
<Chipzz> didn't know about apt-proxy, didn't have the need really
<rmjb> I don't have a large setup either, just a couple vm's to test packages on and I'd like to cache the dependencies for when I'm tweaking the control files and re-testing
<Chipzz> you could manually copy the downloaded files in /var/cache/apt/archive? ;)
<rmjb> that's all?
<rmjb> or! I could nfs mount that directory to a persistent server... one that's not being reverted to a snapshot
<rmjb> that's the ticket!
<fabbione> sfllaw: i am going to prepare an SRU for edgy #67299 today.
<fabbione> sfllaw: just that you know
<sfllaw> fabbione: Thanks for the heads up.
<fabbione> sfllaw: also.. those are a series of bugs. there is one in the group that was identified only later in the process and i will need more work to fix it
<fabbione> sfllaw: (it's some kind of mdadm overlapping with evms/lvm)
<fabbione> sfllaw: but i agreed with the submitter that we will work on it after the first SRU that affects more users
<fabbione> (it's all logged in the bug.. )
<sfllaw> fabbione: Excellent.  I'll look into it tomorrow.
<fabbione> sfllaw: perfect..
<dilinger> are there any xorg 7.2 packages floating around?
<dilinger> i mean, pre-7.2 (as it hasn't been released yet)
<toresbe> thanks for flash 9!
<fabbione> dilinger: no, not yet. I think rodarvus is working on it 
<dilinger> fabbione: is he waiting for 7.2 to be released?
<fabbione> dilinger: not sure to be hounest
<Burgundavia> dilinger: 7.2 is not yet out
<dholbach> <v
<fabbione> Burgundavia: please read a few lines above what he wrote
<fabbione> <dilinger> i mean, pre-7.2 (as it hasn't been released yet)
<Burgundavia> fabbione: right, sorry
<pitti> Good morning
<dholbach> heya pitti
* pitti hugs dholbach 
<_ion> you.each {|person| hi person }
<pitti> _ion: happy ruby morning!
<ajmitch> hi pitti 
<pitti> hey ajmitch, how was the weekend?
<ajmitch> fairly quiet :)
<ajmitch> how was your weekend?
<seb128> is anybody here using procmail to filter its Ubuntu lists with one rule and $MATCH?
<jdub> yeah
<fabbione> seb128: yeah
<jdub> i'll paste
<fabbione> seb128: see /msg
<fabbione> and adapt to your needs :)
<seb128> jdub, fabbione: thanks you ;)
<mdke> ooh. Can I see too?
<pitti> Mithrandir: btw, are you aware of giskard's merge of n-m? http://www.buntudot.org/people/~giskard
<Mithrandir> pitti: yes, I've just failed to act on it so far. :-(
<pitti> Mithrandir: yeah, no hurry, I just wanted to make sure that you know about it
<pitti> ajmitch: what's the status of samba? shall I help you with the merge?
<ajmitch> no, it's done
<ajmitch> I'm just waiting for the archive to unfreeze
<pitti> ajmitch: ah, cool (feel free to upload it already, btw)
<ajmitch> yeah, I probably should upload that & f-spot :)
<seb128> Mithrandir: how is herd 1 going, anything we can do to help?
<Mithrandir> seb128: spinning hopefully final cds now
<seb128> cool
<seb128> unfreeze the archive before we start uploading GNOME 2.17.3 would be nice
<Mithrandir> seb128: so if you want to test http://cdimage.ubuntu.com/daily/20061204/ , please do. :-)
<seb128> otherwise I'm not sure on how cahotic it will go for the buildd ;)
<seb128> let's download a CD image :)
<Mithrandir> cheers
<ajmitch> which ones need testing?
<Mithrandir> all but the amd64 ones are oversized.  GNR
* Mithrandir slashes some langpacks from the list of packs on the CDs.
<sivang> morning
<fabbione> Mithrandir: do you think you can give me sparc server soonish rather than very latish?
<fabbione> (cd image)
<seb128> I hate regexp and procmail :p
<seb128> why something like that doesn't work?
<seb128> :0
<seb128> * ^List-Id:.*<\/\.lists\.ubuntu\.com.*
<seb128> .ubuntu.$MATCH/
<fabbione> :0:
<Mithrandir> fabbione: running
<fabbione> Mithrandir: thanks
<seb128> fabbione: :0 or :0: what difference?
<seb128> :0 [flags]  [ : [locallockfile]  ] 
<seb128> from the manpage
<Treenaks> seb128: I'd also add a check to see if it comes from an ubuntu mailserver... otherwise anyone can create mailboxes for you..
<fabbione> seb128: i don't recall.. but i have :0: everywhere
<seb128> fabbione: I think that's about the same
<Treenaks> seb128: :0: == lock (necessary for mbox files); :0 = don't lock (maildir)
<seb128> Treenaks: ah ok, thank you (for the lock)
<seb128> Treenaks: I've no said I'll not filter on the mailserver, I just want to know what is wrong to that regexp for now :p
<pitti> seb128: where does $MATCH come from? Don't you usually need a () to capture substrings?
<seb128> pitti: \/
<seb128>        MATCH       This variable is assigned to by procmail whenever it is told to extract text from a matching regular
<seb128>                    expression.  It will contain all text matching the regular expression past the \/ token.
<seb128> (from the manpage)
<pitti> seb128: ah
<pitti> seb128: but why do you want to capture 'lists.ubuntu.com>'? don't you want the list name (before the .lists)?
<seb128> pitti: I'm not sure I understand how it works in fact
<seb128> <\/\.lists ... I want to get everything between "<" and ".lists.ubuntu.com"
<pitti> seb128: but that's not what \/ does
<seb128> hum
<seb128> * ^List-Id:.*<\[^\.] *
<seb128> * ^List-Id:.*<\/[^\.] *
<seb128> that then?
<Mithrandir> fabbione: http://cdimage.ubuntu.com/ubuntu-server/daily/20061204.1/ ; the edgy images there are going away, I just forgot to rm them first.
<fabbione> Mithrandir: thanks. i use rsync so that shouldn't be an issue
<pitti> seb128: that will capture e. g. 'sounder.lists.ubuntu.com>'
<seb128> pitti: why? should it capture everything until the first "."?
<pitti> seb128: ah, right
<seb128> shouldn't
<seb128> my regexp foo sucks
<fabbione> seb128: can i quote that in my next gnome bug report? :P
* seb128 slaps fabbione
<Mithrandir> hooray, live images should be testable now.
<Mithrandir> yay, non-oversized alternate images.
<Mithrandir> seb128: please test alternate/20061204.1 instead of 20061204
* ajmitch just finished getting 20061204 :)
<Mithrandir> ajmitch: it should rsync pretty quickly over 1204, it's just a bunch of langpacks that have been removed
* seb128 is still downloading
<ajmitch> Mithrandir: I grabbed with jigdo anyway
* Mithrandir builds ogra some edubuntu images.
<ajmitch> great, nothing to download
<Mithrandir> cjwatson: do we care about DVD images for herd 1?  I think no, since we're already late..
<cjwatson> seb128: how about:
<cjwatson> * ^List-Id:.*<.*\.lists\.ubuntu\.com>
<cjwatson> * ^List-Id:.*<\/[^.] +
<cjwatson> that'll give you the list name in $MATCH
<cjwatson> Mithrandir: no
* cjwatson goes to see if they actually install this time following his PATA fix
<ajmitch> keyboard detection seems odd in vmware (alternate)
<seb128> cjwatson: hum, looks good, let me try, thank you. is [^.]  the same as [^\.] ?
<pitti> seb128: in char classes []  a dot is not magic
<cjwatson> . is not special within []  so you don't need to escape it
<cjwatson> ajmitch: oh?
<seb128> ah ok
<seb128> cjwatson, pitti: thank you
<ajmitch> picks it up as jp after asking me to press various keys
<cjwatson> you sure you pressed the right keys? :)
<ajmitch> yep
<ajmitch> did it a couple of times :)
<cjwatson> what layout do you have?
<ajmitch> standard US layout
<fabbione> score
<ajmitch> it's also not mounting the cd, seems to be missing isofs module?
<Mithrandir> oh well, ogra's images are oversized and he's not around to test them..
* ajmitch is testing on amd64
* fabbione is on sparc netinstall + raid + lvm crackness
<cjwatson> missing isofs> damn
<fabbione> cjwatson: where?
<Mithrandir> Riddell: plz test http://cdimage.ubuntu.com/kubuntu/daily/20061204/ ; I'm rolling -live images for you too now.
<Riddell> Mithrandir: downloading
<Mithrandir> Riddell: great.
<pitti> Mithrandir: summoning powers? :)
<pitti> hi ogra
<Mithrandir> pitti: apparently.
<Mithrandir> ogra: I have oversized images for you.
<ogra> sexy :)
<fabbione> Mithrandir: ogra takes only oversize...
<cjwatson> cjwatson@drescher:~$ for x in ubuntu/pool/main/l/linux-source-2.6.19/*.udeb; do dpkg -c $x | grep isofs && echo $x; done
<ogra> haha
<cjwatson> cjwatson@drescher:~$
<cjwatson> BENC
<Mithrandir> ogra: should I build you livefs-es too?
<Mithrandir> cjwatson: gnr, so all the alternates are busted.
<fabbione> oh great... meh....
<cjwatson> Mithrandir: I think I'm going to upload the kernel
<Mithrandir> cjwatson: go for it
<cjwatson> there goes anything else I was planning to do this morning
<cjwatson> how can I avoid breaking the ABI checker?
<fabbione> cjwatson: i can help you..
<fabbione> just gimme a couple of minutes that i finish my food
<cjwatson> fabbione: can I maybe feed you a patch and you upload it?
<fabbione> cjwatson: sure thing
<cjwatson> chances are I'll get it wrong
<cjwatson> thanks
<cjwatson> ajmitch: thanks for the heads-up
* fabbione clones the tree again
<fabbione> oh actually...
<fabbione> meh
<fabbione> i can't clone
<Mithrandir> Riddell: desktop images up too
<cjwatson> so hmm. traditionally isofs is in ide-modules, but that's gone
<cjwatson> storage-core-modules maybe
<ogra> Mithrandir, live is usualy a bt smaller, try it ...
<fabbione> infinity: do you know if ports is mirroring again?
<elmo> fabbione: no, it's not yet.  ETA is tomorrow or Wednesday
<fabbione> elmo: ok thanks dude
<cjwatson> fabbione: ok, yeah, can you just add 'isofs' on the line immediately after 'cdrom' in debian/d-i/modules/storage-core-modules?
<fabbione> cjwatson: yes.. will do. do we have isofs as module on all arches?
<cjwatson> yes
<Riddell> Mithrandir: thanks
<fabbione> cjwatson: this abi change is going to be painful. i need to do some manual work here..
<cjwatson> ABI change?
<fabbione> or do a global abi override
<fabbione> no
<cjwatson> I really hope you mean lack thereof :)
<fabbione> there is no abi change in adding a module to udeb
<fabbione> the problem is the getabi script.. 
<fabbione> it doesn't cope with the new kernels
<fabbione> and them being in universe
* fabbione needs to do some manual unpacking
<Mithrandir> ogra: running.
<ogra> thanks
<cjwatson> which new kernels?
<infinity> -lowlatency
<infinity> They're in universe.
<cjwatson> ah
<infinity> The getabi script grabs from pool/main/k
<infinity> It's not very bright.
<fabbione> no and it doesn't cope with all new/old kernel flavours
<Mithrandir> you can't just disable the checker for this upload?
<Mithrandir> (yes, I know that's bad)
<fabbione> Mithrandir: that's what i am looking at
<fabbione> Mithrandir: the abi checker kicks in a few places :)
<fabbione> just a minute please
<fabbione> cjwatson: are you sure cdrom module??? it's already in that list
<fabbione> cjwatson: or you meant isofs ?
<fabbione> oh never mind
* fabbione puts down the pipew
<cjwatson> isofs, yes
<fabbione> ok almost done
<fabbione> just doing a last check
<dholbach> ogra: there's a new g-p-m
<cjwatson> I'm just uploading a few bits of d-i to cope with the fs-core-modules/fs-secondary-modules changes
<fabbione> cjwatson, Mithrandir: mind to ask BenC not to rip off my testicles after this upload please? :)
<dholbach> ogra: good morning btw :)
<cjwatson> I'll take the bullet for the emergency upload
<ogra> dholbach, i'm waiting for giskard, he wanted to clearify some things
<dholbach> ogra: alrighty
<cjwatson> fs-core-modules and fs-secondary-modules are both Priority: standard, so hopefully these won't really be needed, but just in case
<fabbione> cjwatson: just kidding.. i have issues to get git working these days and they will have to live with a debdiff
<fabbione> dpkg-source: building linux-source-2.6.19 in linux-source-2.6.19_2.6.19-7.11.tar.gz
<fabbione> getting there
<cjwatson> I'm sure that will be OK
<fabbione> linux-source-2.6.19 (2.6.19-7.11) feisty; urgency=low
<fabbione>   * Add isofs to storage-core-modules
<fabbione>   * Disable abi checker for this upload... brrrrrr....
<fabbione>  -- Fabio M. Di Nitto <fabbione@ubuntu.com>  Mon, 04 Dec 2006 10:52:41 +0100
<fabbione> Mithrandir: do you want a debdiff for approval?
<pitti> fabbione: the last time we disabled the abi checker, we broke many people's X :)
* fabbione uploads in the meantime
<fabbione> pitti: it's no code change this time :)
<ogra> dholbach, likewise i'm waiting for libgnomekbd for gnome-screensaver (its a new builddep)
<Mithrandir> fabbione: I'll look at it when it hits the queue
<sivang> abi checker is part of the kernel or the buildd ?
<pitti> fabbione: out of interest, why does the checker barf then?
<fabbione> pitti: because i don't have the old ABI's from the previous upload
<pitti> fabbione: OIC
<fabbione> pitti: and it would take me a great deal of time to get them
<fabbione> cjwatson: sparc netinstall is good
<cjwatson> sivang: part of the kernel source package
<cjwatson> hmm, yeah, I guess netboot ought to work
<cjwatson> good
<fabbione> do we need a new d-i?.. 
<sivang> cjwatson: thx
<cjwatson> yes, we will
<fabbione> ok
<fabbione> well it's uploading
<dholbach> ogra: hum, who are you waiting for with that one?
<pitti> ogra: I'd like to drop the default dhclient dhcp timeout from 60 to 30 seconds; is that a problem for you?
<ogra> pitti, no, thats fine i think ...
<ogra> dholbach, seb128, he already has a package (showed it to me in SF)
<dholbach> ok
<seb128> speaking about libgnomekbd?
<dholbach> is that waiting in NEW?
<dholbach> seb128: yes
<seb128> no
<seb128> it's waiting on a gnome-control-center tarball not conflicting with it in fact
<dholbach> ahh, good we hired a g-c-c upstream ;-)
* dholbach hugs seb128
<ogra> poset herd1 stuff anyway 
<seb128> :p
<ogra> *post
* seb128 hugs dholbach
<seb128> yeah
<dholbach> ogra: we're packaging gnome 2.17.3 atm
* ogra hugs the desktop team
<dholbach> even if that's post herd 1
<seb128> gnome-control-center and gnome-applets needs to use it in the same time
<dholbach> right
<ogra> oh, my g-ss package is still 17.2, thanks for the info
<cjwatson> ajmitch: *headscratch*. It seems to think that the us layout has a  key
<cjwatson> which us(intl) has, but us doesn't
<ajmitch> yes, my keyboard certainly doesn't
<cjwatson> yeah, it's not meant to
<fabbione> Uploading to ubuntu (via ftp to upload.ubuntu.com):
<fabbione>   linux-source-2.6.19_2.6.19-7.11.dsc: done.
<fabbione>   linux-source-2.6.19_2.6.19-7.11.tar.gz: done.
<fabbione>   linux-source-2.6.19_2.6.19-7.11_source.changes: done.
<fabbione> Successfully uploaded packages.
<fabbione> Not running dinstall.
<fabbione> cjwatson: it's all your
<ogra> Keybuk, !
<Keybuk> ?
<fabbione> Keybuk: RUN RUN RUN you are still in time!
<ogra> Keybuk, i have a longstanding fuse bug i'd love to solve
<Keybuk> ask me about it tomorrow ;)
<ogra> the udev rule for /dev/fuse is shipped in fuse-utils
<ogra> oki
<Keybuk> that's because the user for the device is created by fuse-utils
<ogra> yeah, i'd like to move both into udev somewhere ... people seem to use the module without fuse-utils, so it breaks for them
<Keybuk> group, I mean
<Keybuk> no
<Keybuk> udev will not create groups
<Keybuk> if you want it as a standard group, move it into base-files
<cjwatson> fabbione: thanks
<ogra> well, then into the bits that care for groups, my main concern with udev is the rules file
<cjwatson> Keybuk: that's base-passwd
<cjwatson> and PLEASE nobody edit base-passwd to add groups
<cjwatson> it needs to be ported to debconf first
<Keybuk> err, what cjwatson said -- in both points :p
<ogra> i wont, dont worry :)
<cjwatson> (plus I'd really like to keep base-passwd in sync with Debian)
<ogra> i just want to fix that bug during feisty ;)
<Keybuk> the reason that the udev package shouldn't make groups is that the system needs to still work when udev isn't installed
<cjwatson> is depending on fuse-utils in a few more places a problem?
<Keybuk> udev is just a mechanism for maintaining /dev, as is makedev
<cjwatson> I don't think fuse belongs as a standard group *anyway*
<cjwatson> as in, if I got a request to add it to base-passwd, I would reject it with "use adduser --system"
<ogra> thats what happens currently
<cjwatson> that's good
<ogra> from the fuse-utils postinst
<Keybuk> what's wrong with that?
<cjwatson> if you need to call adduser --system in a couple more places, that's fine too
<ogra> but we ship the module in the kernel package
<Keybuk> you need fuse-utils to use fuse devices anyway
<Keybuk> the module alone isn't sufficient, aiui
<ogra> some people dont ... apparently
<Keybuk> who?
<cjwatson> you clearly need fuse-utils if only for the group. :)
<cjwatson> so we aren't breaking any existing setups - anyone without fuse-utils is broken
<cjwatson> we could consider installing fuse-utils by default
<ogra> Keybuk, bug 74185 and bug 71771
<Ubugtu> Malone bug 74185 in fuse "wrong permissions on /dev/fuse" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74185
<Ubugtu> Malone bug 71771 in fuse "[Edgy]  [Regression]  /dev/fuse should be root:fuse" [Medium,Rejected]  http://launchpad.net/bugs/71771
<ogra> cjwatson, that sounds like the sanest plan 
<pitti> given today's popularity, fuse-utils in desktop is worth considering IMHO; it's only 57kB compressed
<Keybuk> ogra: neither of those bugs make it clear why they don't have fuse-utils installed
<ogra> (i do it in edubuntu and dont have these probs ;) )
<ogra> Keybuk, i know ... but its not there ... no matter why ... and people load the module whith the wrong permissions, that shouldnt be possible ...
<cjwatson> desktop> I'd have said standard, but *shrug*
<Keybuk> loading the module isn't enough to use it though
<Keybuk> you can load the ppp module, but you still need pppd :)
<ogra> but yu can load it ... even if its not a real bug because its not usable, you can still load it into a broken state which i'd like to avoid
<Keybuk> it's not broken
<Keybuk> root can still use it :)
<Keybuk> and only root can install fuse-utils
<ogra> :P
<Keybuk> which postinst fixes the permissions anyway
<ogra> nitpicker, you know what i mean :)
<Keybuk> no, I don't
<ogra> the device permissions should "juat work" if i load the module ... one way or the other 
<ogra> *just
<Keybuk> I don't see a problem here; reject any bugs with "install the fuse-utils package"
<sivang> can anyone confirm that irda-utils works in its current version on feisty?
<ogra> thats what i do 
<Keybuk> and we can arrange for that to be installed
<ogra> right
<Keybuk> solved then
<ogra> :)
<Keybuk> the permissions seem cosmetic, given the device itself is useless without fuse-utils
<ogra> you could hack your own fusermount together ....
<Keybuk> yes ...
<Keybuk> and if someone has the skills to do that, I'm sure they know about adduser
<Keybuk> I could write my own kernel module that needs the "l33t" group
<Keybuk> that doesn't mean we should put that into base-passwd :p
<ogra> the current prposed solution is fine :)
<ogra> *proposed 
<sivang> kent: just to make sure, the AUTOMATIC support and template in irda-utils is to enable upstart to start it on boot when an irda device is detected?
<sivang> hrm
* sivang awaits for Keybuk to return
<cjwatson> smurf: ajmitch reported that us is being misdetected as jp in feisty at the moment; gen_keymap is incorrectly generating a tree claiming that  is in the us keymap. I *think* this is because it decides that us is a submap of us(intl) (which does have a  key, albeit third-level) and making incorrect decisions based on that. Do you have any idea what might be going on here?
<Fujitsu> cjwatson: Can you please let gcl (and maxima, once gcl has built) into dapper-updates?
<cjwatson> Fujitsu: not right now, but in a bit I'll look
<cjwatson> I'm assuming there is a bug to which ubuntu-archive is subscribed
<Fujitsu> It doesn't have ubuntu-archive subscribed, but that can be quickly rectified.
<cjwatson> please do that, yes
<Fujitsu> Done.
<ailean> cjwatson, I noticed this on the ubuntu homepage a few days ago if it means anything. it came up in japanese instead of english until i hard-refreshed it a couple of times. i'm using edgy though.
<ogra> Mithrandir, do you want to build the isos from the edubuntu livefs ? 
<Mithrandir> ogra: running
<ogra> thanks :)
<cjwatson> ailean: I don't maintain the web site; newz2000 does
<ailean> cjwatson, ok
<Mithrandir> ogra: done
* Mithrandir suspects they failed, for some reason
<Mithrandir> ogra: and, I give you OVERSIZED.
<seb128> Mithrandir: desktop i386 liveCD works fine for me, I'm doing an install now
<Mithrandir> seb128: woo
<Mithrandir> ogra: i386 + ppc is oversized.  Enjoy.
<Robot101> ruh-roh
* bhale locks the door as ogra turns into the Hulk
<mnepton> PPC *is* oversized. hence no G5 Apple laptops.
<Mithrandir> ogra: tell me when you've shaved off some langpacks and I'll rerun
<ogra> yeps
<ogra> ouch ...
<ogra> language-pack-kde-$(language) was apparently instaled for *all* langs ...
<smurf> cjwatson: not at the moment. Sub-maps based only on third-level keys are somewhat ugly :-(
<Riddell> Mithrandir: the alternate CD complains about not being able to mount the CD.  and pyqt is entirely broken so ubiquity doesn't start on the desktop CD
<PecisDarbs> elmo: here?
<Mithrandir> Riddell: the former is known; isofs is missing.  Colin and Fabio are in the process of fixing / have fixed it.
<Riddell> yeah, I saw that uploaded
<cjwatson> smurf: maybe it's doing submaps/third-level-exclusions the wrong way round?
<cjwatson> Riddell: pyqt's your problem, I suspect :-)
<Riddell> cjwatson: I know I know
<StevenK> Riddell: Would it be bug 73912?
<Ubugtu> Malone bug 73912 in python-qt3 "[Feisty]  qt module is busted" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73912
<PecisDarbs> anyone knows is elmo is active here? I have several questions to ask him, but he doesn't seem to answer :)
<cjwatson> PecisDarbs: are you sure he's the proper person to ask?
<PecisDarbs> cjwatson: jono sent me to him :) So I don't know, I just want to know some details about one ticket :)
<Riddell> StevenK: sounds likely
<cjwatson> PecisDarbs: often helps to tell people exactly what you want up-front; busy people are sometimes reluctant to answer open-ended pings because they don't know how long they'll take
<StevenK> Riddell: I tried to fix it, and ran out of clues. I tried to dump everything I had figured out into the bug.
<cjwatson> and, dude, six minutes
<Riddell> StevenK: I wonder if it's gcc visibility=hidden being turned on
<PecisDarbs> cjwatson: I understand and that is why I usually lay out concrete question in private, maybe he just missed that
<cjwatson> you could also try e-mail
<smurf> cjwatson:  It tries to not use third-level at all, if possible
<StevenK> Riddell: I didn't even know gcc had that option. :-/
<Riddell> doko_: any opinion on if bug 73912 is likey to be caused by visibility?
<Ubugtu> Malone bug 73912 in python-qt3 "[Feisty]  qt module is busted" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73912
<StevenK> Riddell: And I bet initqt doesn't appear in the installed .so due to being stripped.
<smurf> PecisDarbs: To be brutally honest, not ending every sentence with a smiley would probably improve your chances
<smurf> cjwatson: is there a bug filed on this?
<doko_> Riddell: does 3.16 work, when built in feisty? is sip-qt4 updated?
<ogra> oh crap ... when was linuxprinting.org-ppds added to -desktop ? i totally missed that ...
<StevenK> doko_: No, yes
<StevenK> Actually 3.16 doesn't even build with the updated -qt4
<ogra> Mithrandir, there is a new edubuntu-meta in the queue ... could you please approve it ? the seeds are fixed langpack wise 
<StevenK> Er, sip-qt4
<doko_> StevenK: other topic: do you build python2.5 modules now?
<jono> PecisDarbs, just wait for the ticket to be processed
<jono> PecisDarbs, you will need to be patient
<StevenK> doko_: 3.17-0ubuntu1 does, yes
<doko_> nice
<Mithrandir> Riddell: does this mean kubuntu will just drop herd 1 or do you want to invest effort into fixing it?
<Mithrandir> (before the end of today or so)
<PecisDarbs> jono: I just need answer for other guys, how much do you think it could take, aprox.? 
<jono> PecisDarbs, no idea, they are pretty busy guys
<doko_> Riddell, StevenK: you could build using gcc-snapshot to see if it changes anything
<jono> PecisDarbs, just tell the other guys it will take as long as it takes :)
<StevenK> I was pondering building with __attribute__ ((visibility("default"))), to see if it was visibility related
<PecisDarbs> jono I see
<doko_> Riddell: I had the impression, that you didn't change anything with the visibility attribute
<PecisDarbs> thanks anyway and sorry for disturbance ;)
<Riddell> I don't see visibility in qt causing a problem with exporting a symbol in python-qt
<StevenK> Well, I would if I wasn't falling asleep in front of my machine.
<Hobbsee> StevenK: cold shower.
<Riddell> mm, python-qt is being built with visibility=hidden
<Riddell> wonder what tells it to do that
<Mithrandir> ogra: there is?
<Mithrandir> ogra: nobody seems to have told drescher. :-P
<\sh> Riddell: overwrite it via CXXFlags?
<cjwatson> smurf: there is now; https://launchpad.net/distros/ubuntu/+source/keymapper/+bug/74375
<Ubugtu> Malone bug 74375 in keymapper "us misdetected as jp" [Undecided,Unconfirmed]  
<cjwatson> ogra:  -> http://librarian.launchpad.net/5242936/dMEeyw0GCwPWGI2ee9VXsHPU8R3.txt (GPG verification of edubuntu-meta_1.21_source.changes failed: No public key)
<Riddell> \sh: how?
<StevenK> I note that most of the buildable stuff in -qt is done via SIP
<cjwatson> ogra: that may be a transient error; do you think you signed that upload properly? if so I can attempt to reprocess it
<StevenK> Black magic that it is.
<\sh> Riddell: -fvisibility?
<\sh> Riddell: I'll just try it
<Mithrandir> ogra: if you just changed ship or ship-live, you don't need a -meta upload
<pitti> Mithrandir: just to refresh my mind, this is also true for 'live'?
<Mithrandir> pitti: iirc, yes.
<Mithrandir> cjwatson: ^^ please correct me if I'm wrong.
<pitti> ISTR that this was changed in dapper or edgy or so
<cjwatson> pitti,Mithrandir: yes, changed in edgy
<ogra> Mithrandir, i discovered that linuxprinting.org-ppds was missing as well ...
<ogra> (from desktop)
<Mithrandir> ogra: ok, sure; there's still no upload from you in the queue though, so either you tell cjwatson that you signed the previous one properly and it's a transient error or you should reupload a signed package.
<mvo> can someone please do the smart sync from https://bugs.launchpad.net/distros/ubuntu/+source/smart/+bug/73882 please?
<Ubugtu> Malone bug 73882 in smart "Please sync from debian/incoming (overwrite ok)" [Undecided,Unconfirmed]  
<ogra> Mithrandir, hmm ? i have an .upload file here ... and its surely signed with the keyi always use
<Mithrandir> mvo: is it urgent?  If not, please just leave it on ubuntu-archive's work list
<ogra> Mithrandir, http://paste.ubuntu-nl.org/35280/
<Mithrandir> ogra: 13:38 < cjwatson> ogra:  -> http://librarian.launchpad.net/5242936/dMEeyw0GCwPWGI2ee9VXsHPU8R3.txt (GPG verification of edubuntu-meta_1.21_source.changes failed: No public key)
<Mithrandir> cjwatson: I don't know how to reprocess stuff, so can you either tell me or just do it?
<ogra> weird
<mvo> Mithrandir: no, not urgent
<cjwatson> I'll do it and then tell you, to remind myself. :)
<cjwatson> Mithrandir: find the rejection mail in /var/mail/lp_archive, which gives you a path in /srv/launchpad.net/ubuntu-queue/failed/; as lp_queue, move that directory (in this case, upload-20061204-122619-002149) and the associated .distro file into /srv/launchpad.net/ubuntu-queue/incoming/
<cjwatson> then wait for the cron job to fire
<cjwatson> it's worked now
<ogra> cjwatson, was that an LP hiccup or do i have to be worried about my key ?
<cjwatson> ogra: it was an LP hiccup; I've seen it before on occasion
<ogra> oki, then i'm calmed :)
<Mithrandir> cjwatson: ok, have you deleted the mail or am I incompetent since I don't see any edubuntu rejects?
<cjwatson> Mithrandir: Message-Id: <20061204123208.8092341F06DB@drescher.ubuntu.com>
<cjwatson> I didn't delete it
<cjwatson> I would not like to imply you were incompetent ;-)
<Mithrandir> ah, it's not a reject, it's just an error in a normal cron run
<Mithrandir> it'd be wonderful if those were a bit easier to spot
<seb128> mjg59: are you working on a compiz update? Somebody did an upload of 0.3.4 on REVU, I'll have a look on the update if you are not working it
<mjg59> seb128: There's not a huge quantity of code change, and he's changed the packaging significantly
<mjg59> I'll do an update during the week
<seb128> mjg59: ok
<seb128> mjg59: looks like the guy doing some coding around compiz so he might be interested to maintain it for Ubuntu
<seb128> mjg59: maybe we should try to push him in this way? ;)
<mjg59> Tricky if it's likely to land in main
<mjg59> Unless he wants to go through -core-dev
<cjwatson> Mithrandir: yeah, that's one of the cases where nobody gets notified at the moment - the Soyuz team (arguably rightly) don't want to mail people without a GPG signature saying they can, to avoid being a spam vector
<seb128> he can co-maintain it, I mean if he does a good job having you or some desktop team member reviewing updates and uploading should not be too much work
<Mithrandir> cjwatson: they could mail the archive team or a special list, though.
<cjwatson> true
<Mithrandir> cjwatson: anyway l~bubuntu-queue/failed it is, for now.
<Mithrandir> I'll just keep that in a screen. :-P
<seb128> mjg59: the upload on revu creates a -dev and a -kde which seems reasonable
<cjwatson> big pile of stuff in there at the moment; we don't check it often, afaik
<cjwatson> https://launchpad.net/distros/ubuntu/+source/console-setup/+bug/73955 confuses me
<Ubugtu> Malone bug 73955 in console-setup "Clobbered X screen state during installation" [High,Confirmed]  
<cjwatson> can anyone on feisty try to reproduce that by running 'consolechars -v --tty=/dev/tty1 -f /etc/console-setup/Lat15-VGA16.psf.gz' please? if it corrupts your X screen state, switching to tty1 and back should clear it up
<Treenaks> so that's what happened!
<cjwatson> whether you can reproduce it or not, I'd like to know which X driver you're using. I can't reproduce it here with ati
<seb128> mjg59: anyway I'll let you deal with the update, I was just pointing that it could be nice to work with that guy if he's wanting to have a look on compiz  for Ubuntu (working on packaging or bugs, or sending patches, etc)
<Treenaks> cjwatson: I'm using fglrx, and it happened to me during upgrade
<cjwatson> sorry, you'll need to run that consolechars command as root
<cjwatson> Treenaks: did switching to tty1 and back clear it?
<Treenaks> cjwatson: yes
<Mithrandir> cjwatson: i810 seems unaffected.
<cjwatson> Treenaks: and can you reproduce it now with the same command? (just to confirm it's the same thing)
<Treenaks> cjwatson: I'm not at that machine atm, but I'll try
<Mithrandir> yay, amd64 kernels built.
<tepsipakki> is there a mistake with the postfix upload, latest version is -2 but it
<cjwatson> for anyone who can reproduce the above console-setup problem: please try 'zcat /etc/console-setup/Lat15-VGA16.psf.gz > Lat15-VGA16.psf && psfstriptable Lat15-VGA16.psf > Lat15-VGA16-stripped.psf && sudo consolechars -v --tty=/dev/tty1 -f Lat15-VGA16-stripped.psf' to see if it breaks X in the same way
<tepsipakki> darn
<cjwatson> you may want to run 'sudo setupcon' afterwards to ensure that the console state is sane again
<tepsipakki> is there a mistake with the postfix upload, latest version is -2 but it's waiting for deps which -1ubuntu1 got removed
<giskard> ogra, yes, sorry i was busy with other things, i will prepare the new deb before 6pm
<ogra> giskard, take your time, the archive is frozen until herd1 released
<ogra> wont happen before tomorrow i guess
<ogra> (you can upload to the wueue indeed)
<ogra> *queue
<ogra> (or i can for you ;) )
<Riddell> StevenK, doko_, \sh: removing visibility patch from qt and recompiling it and pyqt fixes pyqt
<seb128> ogra: why not before tomorrow!?
<Hobbsee> Riddell: yay!
<ogra> seb128, because i dont expect the CD to be ready today ?
<seb128> ogra: what is to fix?
<cjwatson> it's waiting for a kernel build
<cjwatson> should be ready in a couple of hours though
<ogra> i still see some bittorrent stuff in the report.html file, dunno if thats fixed already (didnt look into it) and indeed we still have a full testing run ahead after the new kernel is in
<seb128> that long freeze is starting becoming a pain to work with
<cjwatson> doesn't need to be full testing for a first milestone
<seb128> I've scp-ed 4 source packages to people today to allow other people working
<cjwatson> "does it work at all" is enough
<seb128> ok
<seb128> good :)
<ogra> right, but thats still taking at least the time for one install per arch
<seb128> I've tried the desktop i386 CD this morning and the liveCD worked fine
<cjwatson> and I agree we need to get out of freeze ASAP
<ogra> right
<Riddell> recompiling pykde fixes ubiquity
<Riddell> Mithrandir: can I upload qt, pyqt and pykde please
<tepsipakki> cjwatson: not that it's of great priority, but feisty-netboot went fine
<Mithrandir> Riddell: sure.
<cjwatson> tepsipakki: thanks
<cjwatson> Riddell: do they need to be built in that order, or have you included tightly-versioned build-depends?
* Mithrandir waits for the i386 kernel to finish building.
<Hobbsee> Riddell: you fixed pykde too?
<cjwatson> Mithrandir: sparc too please
<cjwatson> oh, it's done
<Riddell> cjwatson: yes they do, I'm adding tightly-versioned build-depends
<cjwatson> meh, having ia64 broken inconsistently will be annoying, but I guess there'll be more d-i uploads
<Riddell> Hobbsee: just needs recompiling against a qt that doesn't use visibility=hidden
<Hobbsee> ah
<jayteeuk> I realise this is a bit like asking what's the best religion, but does anyone have any suggestions for a Python newbie coming from a Java background as to what DB layer to use?
<jayteeuk> I've looked at PDO and SQLObject and currently prefer the latter.
<jayteeuk> It seems to have a feel similar to EJBs with CMP.
<bddebian> Heya
<dholbach> Gloubiboulga: there's another gnumeric release - do you want to take care of that?
<dholbach> TheMuso: do we want to package lsr?
<dholbach> Mithrandir: do we want a ubuntu-meta update for herd-1?
<lamont> tepsipakki: interesting... I wonder why -2 was synced from debian - it shouldn't have been
<Mithrandir> dholbach: for which package?
<dholbach> Mithrandir: it'd be the first upload with feisty seeds. add libnss-mdns, add linuxprinting.org-ppds afaics
<Mithrandir> dholbach: I'd rather not, actually.  Let's try to get herd 1 out the door as fast as possible.
<dholbach> ok
<Riddell> cjwatson, pitti: kubuntu-feisty-adept-changes needs approval, mvo has always approved adept specs in the past, could we set him as approver?
<pitti> Riddell: I would be happy about it if TB agrees
<Riddell> mdz, mjg59: ^^ 
<pitti> ogra: do you want avahi-autoipd and libnss-mdns in edubuntu? (maybe not, since you configure a proper DHCP server)
<pitti> Riddell: do you want avahi-autoipd and libnss-mdns in kubuntu-desktop?
<Riddell> pitti: yes please, if you feel like doing the merge
<pitti> I did the ubuntu.feisty seed changes and can merge them if you want
<pitti> Riddell: I won't actually upload *-meta before herd-1, of course
<Riddell> Mithrandir: can you approve qt3, pyqt3 and pykde?
<pitti> Riddell: ugh, there's much more to merge, also stuff I'm not sure about
<Riddell> pitti: just leave it then
<pitti> ok
<Mithrandir> Riddell: done
<seb128> mjg59: is there anything writing the /apps/gnome-session/ubuntu/window_manager gconf key?
<ogra> pitti, no, i don think so ... i wanted to experiment with avahi for ltsp, but not in feisty
<pitti> ogra: that's what I figured, thanks
<pitti> Gloubiboulga: got a minute to talk about https://wiki.ubuntu.com/GnomeMount and XFCE?
<cjwatson> Riddell: I doubt mdz will have a problem with that; I've set mvo as the approver
<mvo> Riddell: I will try to have a look tonight, otherwise, keep kicking me (gently :)
<Riddell> thanks cjwatson, mvo 
<iwj> --gst-disable-segtrap           Disable trapping of segmentation faults during plugin loading
<iwj> Quality software!
<sivang> iwj: HAHA
<ogra> Mithrandir, cjwatson, my edubuntu-meta build vanished somewhere it seems ...
<ogra> cant find it in the queue nor in the build logs
<ogra> (1.21 that is)
<cjwatson> it's still in the unapproved queue
<Mithrandir> cjwatson: oops, I thought you approved it.  I'll do that.
<ogra> thanks
<dholbach> somebody please give back libgnomeui
<cjwatson> oh, no, I just reprocessed the upload failure; sorry for not being clearer
<Mithrandir> dholbach: done
<Mithrandir> ogra: approved now.
<dholbach> Mithrandir: gracias - that will help to keep random people from adding dbus-glib build-deps all over the place
<ogra> thanks :)
<Mithrandir> ogra: sorry about cjwatson and me miscommunicating.
<seb128> dholbach: please point me to people who did that ;)
<dholbach> seb128: as I said: I did it in one place, but will revert it again ;-)
<seb128> thank you ;)
<cjwatson> the kernel's still going anyway, I see
<ogra> right
<cjwatson> heh, ia64 > i386
<cjwatson> did vernadsky have its go-slow pills this morning?
<Mithrandir> cjwatson: apparently.
<Mithrandir> getting close to five hours now.
<cjwatson> Mithrandir: I've punted debian-installer into the queue; I suggest accepting that source upload once all the kernel binaries are there, just before running the publisher
<elmo> vernadsky is one of the slower buildds
<elmo> and ia64 has less images to build
<cjwatson> the only reason ia64 surprised me was that i386 beat it by 50 minutes last time round
<cjwatson> I assume it hit a faster buildd
<elmo> yeah, it probably hit palmer
<cjwatson> it did indeed
<elmo> yeah, single 2.8 Xeon vs dual 3.2. and kernel is one of the few packages to take advantage of the extra CPU
<cjwatson> 2.6.19 has never built on vernadsky before, but rothera took 5 hours
<cjwatson> are they the same spec?
<elmo> yes
<cjwatson> right, so ETA half an hour or so
<Mithrandir> cjwatson: I'm going out now-ish, if you're still around when the kernel binaries are published, could you spin ISOs?  If not, I'll do it when I get back (~1900 UTC-ish)
<jdong> Mithrandir: your frozen-bubble sync might cost me in over 6 hours of downtime today :D
<jdong> I totally blame you :)
<mdz> Riddell: who's working on adept these days?
<Riddell> mdz: nobody, but I'd plan to be the implementor for kubuntu-feisty-adept-changes
<cjwatson> Mithrandir: sure. I have to go and order meat for Christmas dinner, but I'll be back shortly.
<Riddell> cjwatson: kubuntu-ubiquity-migration-assistant also needs approval, would you be able to look at it?
<cjwatson> Riddell: will do; I've set myself as approver
<sven-tek> I saw there are .udeb packets in the kernel tree. Could someone point me to some place where i can get informations about .udev packets?
<fabbione> cjwatson: while you wait for the kernel to build, can i nag you about my mdadm upload to edgy-proposed ?
<cjwatson> sven-tek: (a) "packages" (b) be careful not to confuse udeb with udev (c) those are part of the installer; see http://wiki.debian.org/DebianInstaller, http://people.debian.org/~fjp/talks/debconf6/paper/
<cjwatson> fabbione: yeah, I guess so, one minute
<fabbione> cjwatson: even 4.. it's no hurry really.. i was just pinging somebody from -archive
<cjwatson> fabbione: somebody from -sru actually, since it hasn't yet been approved AFAICS
<fabbione> cjwatson: ok... will do that too. thanks
<cjwatson> do what? :-)
<cjwatson> (I'm in ubuntu-sru)
<cjwatson> fabbione: please undo the bug duplication as mdz suggested
<fabbione> cjwatson: oh right.. you have too many powers.. i can't remember them all :)
<mdz> fabbione: if the instructions are unclear, please suggest alternative wording
<fabbione> cjwatson: yes.. will undup in a sdec
<fabbione> mdz: i just replied to that email.. that was my understanding since one of the bugs become incredibly long
<fabbione> (brb.. son is crying)
<cjwatson> fabbione: can you please edit the description of 74346 to include an impact description for each of the problems? i.e. a brief description of what effect each bug has on users
<cjwatson> fabbione: also an explanation of how this has been addressed in feisty; see https://wiki.ubuntu.com/StableReleaseUpdates
<fabbione> cjwatson: feisty has the udev-mdadm spec that will replace the whole need of that scripts. but yes i can add.. it will take me a bit tho.. my little shark needs feeding first
<sven-tek> cjwatson, thank you. i got it wrong, i thought it indicates kernel delta patches are upcoming - but udebs are used a long time now ... what a pitty ;-)
<cjwatson> fabbione: saying that this will be addressed by udev-mdadm is fine
<cjwatson> fabbione: what's the change that implements "make an attempt to probe raid once if no RAIDs are known to initramfs"?
<fabbione> cjwatson: configureduuid=none
<pirast> where's doko?
<fabbione> it allows one iteraction in the loop
<cjwatson> fabbione: ah, I see, looking up the context made it clearer. How does that affect systems without RAID configured but with mdadm installed?
<fabbione> no changes...
<fabbione> or better.. no effects
<cjwatson> you've tested that case?
<fabbione> yeps
<fabbione> the loop will go in once, attempting to start the raid. mdrun will find none and exit 0
<fabbione> cjwatson: i changed the description. want to check if it's ok or needs more editing?
<fabbione> (before i run to feed the shark ;))
<fabbione> all bugs undeped..
<fabbione> i think i got it all
<fabbione> the root causes were different.. same final effect.. 3 minutes waiting time at boot
<fabbione> cjwatson: also note that packages have been tested by almost all the submitters and they reported that the new one works
<Riddell> sfllaw: about?
<superm1> ping elmo 
<cjwatson> fabbione: more sanity-checking for mdadm/mkconf outputting ARRAY lines without UUIDs would be nice. I had a look through the source as best I could but haven't satisfied myself that that won't happen
<cjwatson> fabbione: maybe just make the initramfs-hook grep for 'ARRAY.*UUID=' rather than just ARRAY
<cjwatson> ^ARRAY.*UUID= rather
<fabbione> cjwatson: raid  UUID are mandatory. the reason why we run mkconf is to make sure to have UUID.
<fabbione> cjwatson: something that might lack when parsing an existing mdadm.conf
<fabbione> cjwatson: the output of mkconf is standard instead
<cjwatson> like I say, I couldn't satisfy myself that mkconf was guaranteed to do that for all RAID types. Could you add that sanity-check to keep me happy? :)
<fabbione> cjwatson: sure i love to make you happy
<fabbione> cjwatson:         grep ^ARRAY.*UUID= | \
<fabbione>  ?
<fabbione> does that satisfy you?
<fabbione> cjwatson: include/linux/raid$ less md_k.h  and look for uuid too.. it's a mandatory element for md super block on disk.
* fabbione did his homework :)
<cjwatson> fabbione: * needs to be quoted. grep '^ARRAY.*UUID=' | \
<cjwatson> right, it's probably OK, it's just not obvious from the initramfs side and it's trivial to make it obvious
<fabbione> cjwatson: yeps. it's there (you can reject the previous upload in the meantime)
* cjwatson scratches his head over that sed
<fabbione> cjwatson: stolen from mdadm 2.5 in feisty that is used to parse mdadm output properly
<cjwatson> oh I see it's for unwrapping continuation lines
<fabbione> yeps
<fabbione> and skipping comments
<cjwatson> the last bit seems redundant with the grep, but whatever, that's not important
<cjwatson> fabbione: "it's there"> new upload?
<sfllaw> Riddell: I am.
<Riddell> sfllaw: I was wondering if kdebase had been uploaded to edgy-updates, but it seems not, so I just uploaded it
<sfllaw> Riddell: Excellent!
* sfllaw hugs Riddell.
<mjg59> seb128: desktop-effects
<fabbione> cjwatson: no.. waiting for you to reject the old one
<cjwatson> fabbione: you don't need to - please uplad
<cjwatson> upload
<fabbione> cjwatson: ok..
<cjwatson> I've rejected the old one anyway, but it's not necessary to wait in this case
<fabbione> cjwatson: done
<fabbione> adding the new debdiff with new grep to the bug..
<seb128> mjg59: what is the logic behind it?
<seb128> mjg59: gnome-session is already using /desktop/gnome/applications/window_manager/default and /desktop/gnome/applications/window_manager/current, do we need yet another key?
<fabbione> cjwatson: it's all done my side.. upload and so on.. anything more you need?
<seb128> mjg59: in fact I'm switching to the gnome-wm from upstream instead of the debian variant
<mjg59> seb128: It is? As far as I could tell, it doesn't use either
<cjwatson> fabbione: assuming that was the only change you made in the new upload, we should be all set
<seb128> mjg59: Debian (and Ubuntu) patch gnome-wm to do that:
<seb128> +# Get previously set window manager in gconf
<seb128> +if [ ! "$DEFWM" ] ; then
<seb128> +  DEFWM=`gconftool-2 -g /desktop/gnome/applications/window_manager/default 2>/dev/null`
<seb128> +fi
<seb128> +
<seb128> and
<seb128> +# Store the selected WM with gconf
<seb128> +gconftool-2 -t string -s /desktop/gnome/applications/window_manager/current "$WINDOW_MANAGER"
<seb128> +
<seb128> 
<fabbione> cjwatson: no other changes.. no
<seb128> that seems bogus to me
<seb128> the get is on "default" and the set on "current"
<mjg59> Yeah, the current key is never read
<seb128> right
<fabbione> cjwatson: i am off for a bit.. thanks a lot for your help mate..
<seb128> but could we use that one instead of creating a new one?
<mjg59> Ok. Drop the patch I added
<mjg59> Might as well keep things consistent
<seb128> ok
<seb128> we still have time to sort that before feisty if there is some issue anyway
<mjg59> Yeah
<mjg59> I'll change over desktop-effects
<seb128> I'll ping vuntz, I would like to know why upstream is not using the gconf key
<seb128> it's handy to be able to set the window manager to gconf
<dholbach> heno: heya, I had to drop the quit button patch from the feisty gnome-orca. seems that tortoise has to fix it again
<bronson> sabdfl said: "Shortly, we will make it easy for people to biuld their own versions of ubuntu packages, and publish those."
<bronson> https://wiki.ubuntu.com/MeetingLogs/OpenWeek_AskMark
<bronson> What did Mark mean?  Anyone have more info?
<jdong> bronson: I suppose that's PPA?
<jdong> Personal Package Archives
* bronson googles
<jdong> what I've been told is that it's a mechanism on Launchpad for people to host APT repos
<pitti> (and buildds)
<bronson> Interesting.
<bronson> Guess I won't wait for it.  :)
<bronson> I'm off to learn reprepro.
<jdong> bronson: smart choice on that
<jdong> :)
<pitti> bronson: depending on your needs, 'apt-ftparchive packages . | gzip > Packages.gz' might be easier for you
<jdong> bronson: and dpkg-scanpackages . /dev/null | gzip > Packages.gz
<_ion> I find falcon incredibly nice.
<jdong> and look, pitti beat me to it too :)
<bronson> That doen't allow pinning, right?
<pitti> bronson: pinning is purely on consumer's side, not on the archive's
<jdong> bronson: bleh, you need a Release file
<jdong> that's all that's needed for clients to be able to pin
<bronson> cool
<pitti> jdong: you don't need a Release file for apt-ftparchive, and if you want one, it's trivial to generate
<jdong> pitti: don't you need a Release file in order for clients to be able to pin?
<pitti> ah, for pinning on release, I guess so
<bronson> Also, I'm looking for something that will maintain the repo behind my back.
<jdong> lol
<jdong> cron and a shell script :P
<bronson> one-click upload (dput *.changes), get rid of obsolete files, etc...
<bronson> _ion: falcon looks pretty sharp...  Is there a homepage for it?
<_ion> bronson: Seems like the content has disappeared from Seveas's website, but the bzr repository seems to be still there: http://www.kaarsemaker.net/files/Software/falcon/
<Seveas> <bronson> one-click upload (dput *.changes), get rid of obsolete files, etc... <-- that is not yet implemented in falcon, but I'm working on it
<Seveas> so if you want it *now*, look at reprepro or dak or other alternatives :)
<LaserJock> I'm thinking dak  ;-)
<bronson> Seveas: thanks, will do.
<bronson> Seveas: real briefly, can you tell me how Falcon intends to be more useful than the rest?
<Seveas> bronson, it's the easiest to use and will do more automatic magic
<_ion> I can vouch for that.
<bronson> brilliant.  I'll give it a closer look.
<heno> dholbach: that's OK. We'll try to get upstream to do the right thing this time :)
<bronson> Active development counts for a lot too.
<dholbach> heno: rock and roll :-)
* dholbach hugs heno
<Seveas> if you start using it now, beware. I'm changing large parts of it to be even easier to use/configure
* heno hugs dholbach
<bronson> Sounds good to me.  :)
* dholbach hugs keescook ecstatically
<keescook> hiya dholbach!  sounds like your your first DJ session was a hit.  :)  nice!
<Seveas> DJ Daniel?
<dholbach> thanks a lot Kees :-)
<dholbach> hey Seveas
<Seveas> hi
<LaserJock> dholbach: I must confess I don't understand what exactly it is that you do when you DJ but it sounded exciting :-)
<dholbach> LaserJock: it's big fun - if you make it to berlin, let me know and I'm happy to show you :-)
<LaserJock> sure thing :-)
<dholbach> keescook: if the mixtape tonight is good, I'll blog it and try to do so regularly :-)
<LaserJock> we just need a Berlin UDS with an extra 2 days for such things
<dholbach> Berlin UDS! WORD! I'm all for it :)
<dholbach> as long as it's not somewhere in the berlinian outskirts or in berlinian airportland that would be great
<keescook> dholbach: very cool.  I can't wait to hear it.  :)
<Mithrandir> jdong_: oh, because you just "happened" to start it and couldn't quit?
<jdong_> Mithrandir: don't interrupt me. I'm on the 73rd level.
<jdong_> :)
<Mithrandir> :-)
<jdong_> OOH there's a networked mode!
<Gloubiboulga> dholbach: I'll take care of the gnumeric update
<dholbach> Gloubiboulga: new goffice was just uploaded to incoming
<dholbach> Gloubiboulga: so that should be 'only' a merge
<Gloubiboulga> right, 'only' :)
<ajmitch> morning
<keescook> hiya ajmitch 
* dholbach hugs Gloubiboulga
<dholbach> Gloubiboulga: maybe gnumeric 1.7.4 will hit incoming soon too - I'll let you know, if you like
<Gloubiboulga> dholbach: I'll check that, thanks
<Gloubiboulga> dholbach: BTW, there's a small packaging bug in libxml++ (a missing .h)
<dholbach> Gloubiboulga: oh? do we have a bug about that?
<Gloubiboulga> dholbach: not yet
* dholbach test builds and runs dh_install --list-missing
<dholbach> hum, I wonder where /usr/bin/aclocal comes from, installing automake1.9 doesn't give me the alternative and the symlink
<Keybuk> it's an alternative
<Keybuk> check it's not on manual
<Keybuk> the "automake" alternative will set it
<Keybuk> (it's a slave to that)
<dholbach> "on manual"? what do you mean by that?
<Keybuk> $ update-alternatives --display automake
<dholbach> hm, status is indeed manual
<dholbach> I can't remember ever having touched that on that vserver
<dholbach> but thanks keybuk - seems it's happy now
<dholbach> Gloubiboulga: you're right, I'll upload the fix in a bit
<Gloubiboulga> dholbach: thanks
<Mithrandir> cjwatson: I accepted d-i a while ago, so we should have good ISOs tomorrow.
<Riddell> Mithrandir: not doing Herd today then?
<Mithrandir> Riddell: it's close to ten in the evening here, I'm not going to sit up all night testing, so no.
<Mithrandir> Riddell: sorry. :-(  I want to end this freeze just as much as you do.
<Burgwork> Riddell: he mostly wants to end the freeze before all the bugging ends his sanity
<Mithrandir> Burgwork: I haven't had sight of my sanity for > six months, so I think that's a lost cause. :-)
<Burgwork> heh
<mdke> who needs sanity eh?
<LarstiQ> Mithrandir: we still like you without sanity, don't worry!
<LaserJock> I'm not sure, I like the guys spinning the .isos to be somewhat sane :-)
* mc44 resists urge to make Hurd release jokes
<Mithrandir> mc44: do you think we chose "herd" by chance? ;-)
<Burgwork> it being late should have been expected, I guess
<ajmitch> now we know that debian releases hurd cds every few months :)
<mc44> Mithrandir: unfortunatly, I guess you choose it due to collective noun allocation :p
<Mithrandir> it's the usual hard call of knowing when to freeze.  It's so much easier to see the right spot in retrospect.
<Mithrandir> mc44: there are, iirc at least a couple more alternatives.
<mc44> Mithrandir: ah yes, leash parcel and bevy. Personally I would ahvegone with bevy
<LaserJock> sounds a little ... heavy
<mc44> or leash :)
<Mithrandir> mc44: the downside of not being a native english speaker is I tend to fail when it comes to knowledge such as collective nouns.
<mc44> Mithrandir: I'm just a native english speaker with Google 
<Mithrandir> heh :-)
<mc44> although A murder of ravens was always my favourite
<Mithrandir> a murder or ravens?  I thought murder only was crows?
<mc44> bah, Im probably wrong
<mc44> ha, an unkindness of ravens
<mc44> not quite as bad as a murder, I suppose
<Mithrandir> (I know it's a murder of crows, I was just surprised about it being a murder of anything else)
<mc44> but someone clearly had a grudge against birds when it came to dishing hmouttttt
<mc44> *them out
<Mithrandir> cjwatson: hmm, do we need new livefs-es?
<umista> exit
<mariano> anyone familiar with launchpad-integration can tell me if these two gnome-terminal crashes are l-i's <http://bugzilla.gnome.org/show_bug.cgi?id=373488#stacktrace>, <http://bugzilla.gnome.org/show_bug.cgi?id=382174>
<Ubugtu> Gnome bug 373488 in general "crash in Terminal: Iniciando Terminal" [Critical,Unconfirmed]  
<seb128> mariano: look like crash to GTK
<seb128> mariano: feel free to close them as NOTGNOME with a comment saying to open a bug on launchpad, we will open a bug on GTK if required
<mariano> Ok
<mariano> that code path in gtk is quite well tested... ;-)
<seb128> probably
<seb128> debug backtraces would be useful
<seb128> we will deal with that on launchpad
<cjwatson_> Mithrandir: don't think so? assuming they already have initramfs-tools 0.69ubuntu25
<superm1> ping BenC 
<BenC> superml: pong
<BenC> superm1: ^^
<superm1> hey BenC, i wanted to talk to a kernel dev about the possibility of including ivtv and lirc modules in the l-r-m pakcage
<superm1> and i saw your name on linux-source, so i figured you'd be a good start
<superm1> at least building them, similar to how vmware-modules are built during l-r-m generation
<BenC> superm1: #ubuntu-kernel
<superm1> k, anyone in particular to look for in there?
<BenC> superm1: me :)
<superm1> hehe k
<HumanPrototype> cjwatson, Hi - I have been told you are a good person to talk to about ubiquity
<HumanPrototype> cjwatson, I am trying to create a custom distro based on ubuntu and would like to stop ubiquity asking for a username and just creating a standard user called "user"
<keescook> HumanPrototype: have you looked at the OEM installation mode on the alternate CD?  Maybe that would help?
<HumanPrototype> keescook, Will that allow me to create a cd which installs a system with fluxbox with several custom config files and programs? I must say I haven't looked at it at all
<keescook> HumanPrototype: hm, perhaps not.  It's a way to create a common installed image.  Sounds like you'll have to wait for cjwatson to get back.  he's not usually up right now
<HumanPrototype> keescook, do you know when he is up?
<keescook> UTC 900ish maybe
<superm1> keescook, do you work with ubiquity alot?
<keescook> superm1: I don't, no.  Just use it a lot when doing installation testing.  :)
<Burgwork> HumanPrototype: talk with joejaxx. He is working on fluxbox
<HumanPrototype> Burgwork, thanks
<superm1> keescook, well i'm wondering how cjwatson will feel about making a ubiquity derivative for something like ubiquity-mythtv.  For feisty+1, I wanted to work on making a direct mythtv installer, and base it from that - but leave it in Ubuntu.  so that we can generate ubuntu media center or mythbuntu or something like that disks
<superm1> before I started, I wanted to make sure cjwatson and anyone else who works with ubiquity would be cool with this idea
<keescook> superm1: ooh, that'd rock.  I'd help test it too: my myth box is in need of upgrade.  :)  I don't know his development roadmap, though, sorry.
<HumanPrototype> superm1, what are you thinking?
<superm1> well i'm cleaning up the other rough edges first - firmware and drivers, and some metapackages that don't need ubuntu-desktop
<superm1> after i finish that up, i'll have something like mythtv-master-backend
<superm1> and mythtv-backend-frontend etc
<superm1> so i'm thinking this installer would go right off from the get go and get you into these metapackages instead if you wanted
#ubuntu-devel 2006-12-05
<superm1> like install firmware for your tuners, install necessary kernel modules (like ivtv), set up your initial database for you - take out some of the extra pain thats normally involved for new users getting into myth
<superm1> but i really dont want to spin off a derivative distro, i'd like to be able to do these live disks side by side with the normal release disks
<HumanPrototype> superm1, so basically you could use it to set up a mytv server or frontend?
<superm1> either a primary server, a secondary, or a frontend or combination
<superm1> i've got the metapackages in the works right now, and those should show up in feisty
<bronson> superm1: I've been meaning to produce an Ubuntu-derived PVR setup too.  I registered ubuntv.org and then got stuck in a high-pressure contract and forgot all about TV.  :)
<superm1> haha
<bronson> I've been thinking about getting back into that.
<superm1> bronson, are you still interested?
<superm1> we do have a team started
<bronson> Oh yeah.  Got anything for me to look at?
<keescook> superm1: what's the team name?
<superm1> well join #ubuntu-mythtv and we can chat htere
<bronson> will do.
<jdong_> Mithrandir / cjwatson: at your leisure can backports binary NEW be cleared?
<jdong_> s/cleared/taken care of/
<mariano> is edgy having issues with gconv? <http://bugzilla.gnome.org/show_bug.cgi?id=365646#stacktrace>... looks NOTGNOMish
<jdong_> look at that! Azureus 3.0 is out! with more memory usage than ever!
<jdong_> I am so thrilled my 10G of swap is going to something other than my tmpfs pbuilders
<Burgwork> lets! install! it! by! default! cause! that! makes! baby! jesus! cry!
<jdong_> :)
<jdong_> Burgwork: it comes bundled with beryl and automatix :D
<LaserJock> I want automatix-bleeder though :-)
<bhale> oh jeez
* bhale comforts Burgwork 
<jdong_> LaserJock: that's the ONLY automatix I recommend to all the forum members
<Burgwork> I got an email, in response to my compiz post, claiming that beryl "fixes many of your issues"
<rmjb> hey... I like Azureus... very configurable
<jdong_> rmjb: yeah me too... at least 2.5 (I can't comment on 3.0 yet)
<Hobbsee> Burgwork: hah.  
<Hobbsee> Burgwork: have you done a review of beryl yet?
<jdong_> rmjb: but for 99% of purposes the resource draw it asks for are ridiculous
<Burgwork> Hobbsee: not yet in the repos
<rmjb> deluge looks promising though
<Hobbsee> i thought it was in hte process of being added
<jdong_> rmjb: ktorrent ain't bad either
<jdong_> especially svn
<rmjb> yeah well that's a java app for you... a mono one too
<jdong_> rmjb: well I don't know if it's java/mono's fault or the 10 billion pointless graphical visualizations of downloading :D
<rmjb> sorry, meant to say a mono app may also be a resourse hog re: deskbar
<jdong_> rmjb: older Beagle too
<jdong_> but I don't think that can be blamed on the language stack
<bhale> oh jeez
<rmjb> jdong_: I like to watch the pointless graphical downloading... passes the time
<Hobbsee> LaserJock: what's automatix-bleeder?
<rmjb> the oh so long time
<jdong_> rmjb: yeah, it does :)
<bhale> deskbar is not mono
<rmjb> bhale: it isn't? then that doesn't explain things
<Burgwork> it is python
<Burgwork> the issue is that it does lots of stuff
<jdong_> oh sure let's blame it on python now
<jdong_> :)
<jdong_> lol
<Burgwork> doing stuff requires memory
<bhale> you dont have to explain things by saying "MONO, RUN FOR THE HILLS"
<bhale> do real profiling
<Burgwork> beagle does stuff, therefor it uses memory
<Burgwork> so will tracker, once it starts actually doing stuff
<jdong_> Burgwork: I didn't say that mono was to blame. I said the exact opposite
<LaserJock> Hobbsee: it's supposed to be the latest-crack Automatix for Feisty, I think
<Hobbsee> ooh great!
<LaserJock> Hobbsee: Automatix and Automatix2 are the "stable" ones
<Hobbsee> hah
<rmjb> meh, I rather have my mem used 96% most of the time (as linux does) than 30%
<jdong_> Hobbsee: it's like beta automatix :-/
<jdong_> rmjb: and I'd rather not have my torrent client using 3.5GB of virtual memory
<jdong_> ;-)
<rmjb> point
<rmjb> jdong_: care to recommend a good gnome/gtk one?
<jdong_> rmjb: well.. there really isn't one at this point other than deluge
<jdong_> which is still beta-ish
<rmjb> yeah
<jdong_> rmjb: I am a proud ktorrent-in-GNOME user
<jdong_> it's still a better deal than Azureus
<jdong_> and no comment on all you uTorrent-in-WINE fanatics
<Hobbsee> jdong_: FUN!
<jdong_> heck I use klipper in GNOME :D
<rmjb> I tried a kde app in edgy gnome and it didn't start... kreetingcard... amaroK in dapper gnome worked though
<jdong_> rmjb: it sometimes help to run kdeinit first before trying kde apps
<sladen> rmjb: how did you install 'krieetcard'?
<sladen> rmjb: if you did an  apt-get install for using Synaptic Package Manager, it should work fine
<rmjb> download an rpm and use alien :D
<rmjb> nah I did Synaptic
<sladen> rmjb: I thought you said you used 'alien' from an RPM?
<jdong_> rmjb: "well, there's yer problem..."
<rmjb> maybe the kdeinit was missing then
<ailean> what exactly *is* a ribbon?
<jdong_> ailean: http://www.urbandictionary.com/define.php?term=ribbon
<rmjb> something young girls use to tie up their hair
<sladen> rmjb: Debian packages contain the information our resources/libraries and an application needs.  Installing from an incompatible RPM means that that extra information is available.  You'll probably need to install extra KDE applications...
<jdong_> or not? :D
<sladen> KDE libraries
<ailean> ah yeah, there's always a wise guy :)
<rmjb> I didn't use alien and an rpm... I was joking
<rmjb> I'd rather compile from source than do that... and now I don't have to... I'll package it :D
<rmjb> right LaserJock
<jdong_> rmjb: that's what the <sarcasm> tag is for
<LaserJock> rmjb: \o/
<rmjb> jdong_: I'll remember that tag next time... tone doesn't flow well in text chat
<LaserJock> you're kidding! ;-)
<jdong_> wait but my GNOME 2.17.1 aliened RPMs from Rawhide are working just fine
<LaserJock> well, we could always checkinstall just to be safe
* LaserJock whistles back to work
<jdong_> and cheerfully together we will..... never mind
<lamont> anyone know how to sync evo to an ipaq?
<Lathiat> lamont: your probably looking for opensync, no idea if it does ipaqs yet tho
<lamont> Lathiat: ok
<lamont> thanks
<bronson> Is there any way to keep multiple pbuilder distros in flight at the same time?
<bronson> I'd like to build packages for both Dapper and Edgy, but it doesn't look like pbuilder will allow that?
<bronson> It must be one or the other...   Well, unless I use linux-vserver, UML or VMWare.
<LaserJock> nah
<ajmitch> use different pbuilder configs
<bronson> Ah, just create a different config file and then specify it with --configfile?
<ajmitch> yep
<jdong_> bronson: just different --basetgz arguments works :)
<bronson> Would that allow me to get around having to run it as root too?
<LaserJock> or you can use the example script that comes from pbuilder
<jdong_> no
<jdong_> pbuilder needs root to chroot()
<jdong_> you can set pbuilder suid root to work around that
<jdong_> (kidding)
<bronson> Oh, good point.
<bronson> Looking forward to capabilities maybe fixing that.
<jdong_> bronson: if you're really motivated I've seen some Debian docs on workarounds for pbuilder chrooting
<bronson> jdong_: I'm not yet that motivated.  Got to get some real work done first.  :)
<bronson> But I am interested.
<Hobbsee> bronson: see !pbuilder - the last section
<bronson> Hobbsee: !pbuilder?  Does the bang indicate an IRC /msg thing?
<LaserJock> no
<LaserJock> it's for our bot
<bronson> !pbuilder
* bronson looks quizzical
<grexk> What do I need to modify if I'm going to downgrade amd64 to x86? Do I need to reinstall?
<Hobbsee> bronson: in a channel that has ubotu in it.  try in #ubuntu-motu
<vcef> hi
<vcef> batch scheduling?
<grexk> it's not possible,,,bye bye every1
<jdong> <grexk> it's not possible,,,bye bye every1
<jdong> nonsense
<jdong> muahaha
<cr3> when testing the latest netboot for feisty, I should be referring to archive.ubuntu.com/ubuntu/dists/feisty/main/installer-i386..., right? I'm not seeing an installer-i386 directory under feisty-updates
<Mithrandir> Gloubiboulga: hi, is the xubuntu team planning on having a herd 1 as well or should I drop you for this milestone?
<crimsun> it would be nice to have a herd 1
<Mithrandir> crimsun: are any of you able to do testing of it?  I don't have the resources to do so.
<crimsun> Mithrandir: I can test i386, and I'll ping for amd64 and ppc
<Mithrandir> coolie
<Mithrandir> alternate CDs are ready; I'll spin you live cds in a bit
<crimsun> Mithrandir: great, thanks!
<poningru> http://steelgryphon.com/blog/?p=96
<bobsaget> DCC SCHAT isoiledmypantaloon
<elkbuntu> ha
<Dekkard> has anyone seen whiprush?
<crimsun> he did a disappearing act in frustration, but I do not claim to know very much about the whole thing.
<crimsun> argh
<elkbuntu> crimsun, we can only hope he comes back, it's such a shame to lose someone like him
<Amaranth> He was in my hotel at UDS, awesome guy
<elkbuntu> yeah
* ajmitch saw him at UDS too, funnily enough
<crimsun> for Xubuntu's 20061204 i386 daily (alt.), automatic keyboard detection on a Dell 104-key US keyboard gives me 'jp' (but I can back out and choose US English), and the installer can't find any kernel modules, so d-i appears to hang
<crimsun> md5sum appears correct, reproduced on three i386 machines
<crimsun> burned new cd, reproduced again
<Mithrandir> crimsun: thanks.
<zwnj> is there something like kudzu for ubuntu?  what's the hardware detection application on install time?  can't i just rerun that program? [sorry for the noise, but it is not really an #ubuntu question] 
<Mithrandir> zwnj: we use udev for device discovery
<zwnj> yes, but i meant the configuration process.  that's a pity that i cannot tell ubuntu to re-discover my graphic card, and re-configure the xorg.conf
<somian> Hauddhi ubuntoids
<Mithrandir> zwnj: that's an #ubuntu question; dpkg-reconfigure xserver-xorg
<somian> I got the I/O error on CDROM drive bug when trying to boot Drake in live cd mode, asking for "persistent" on the boot command line.
<Mithrandir> somian: this is not a support channel.
<_ion> zwnj: I guess the goal is that xorg.conf mostly doesn't need to exist. I don't know how long that is going to take, though. :-)
<somian> Who is going to fix it, Mithrandir?
* somian guesses that people who develop for ubuntu
<Mithrandir> somian: nobody; a) dapper is released; b) it's probably a dirty CD or CD-ROM drive.
<somian> Dapper is LTS
<somian> (2) No. It isn't.
<Mithrandir> oh, have you tried with multiple CDs and a new drive?
<somian> (1) it is a brand newly burned CD; (2) It boots fine without saying "persistent" on the commandline. (reproducable).
<somian> My cds are not dirty. None of them.
<Mithrandir> and you have prepared a device for persistency before you try booting with persistent?
* somian is meticulous.
<somian> Yes, I did prepare a device, according to the instructions on the wiki.
<somian> I'm using a ext3 filesystem image in the root of a hdd partition, named "casper-rw".
<zwnj> thanks all :)
<zwnj> another problem was that the dpkg-reconfigure xserver-xorg didn't detect my GC, but setting the driver to VESA just works well
<pitti> Good morning
<somian> morning pitti
<pitti> Good morning
<mdke> mdz, cjwatson: would bug 74481 justify an upload to edgy-updates? It's an easy fix, but I'm not sure of how the new SRU policy is applied - it doesn't seem to fall within any of the categories
<Ubug2> Malone bug 74481 in ubuntu-docs "Many scrollkeeper cron.monthly errors." [Undecided,Unconfirmed]  http://launchpad.net/bugs/74481
<lifeless> mdke: I'd say low impact to all our users
<lifeless> I think its probably ok to treat this as something needing an SRU
<mdke> lifeless: aha. Alright. I'm a bit put off by the process required (-proposed, notifying testers, etc) because the fix is so easy, but I'll try and go through the hoops 
<lifeless> mdke: the consequences of a mistake are huge.
<lifeless> mdke: Doing nothing is safer than doing the wrong thing, for stable updates.
<mdke> more scrollkeeper errors?
<mdke> but yeah, I see why the policy is there
<lifeless> no, potentially broken systems across all our users, if the patch is faulty.
<mdke> I'm curious how, but not curious enough to challenge you - I'll take your word for it, and do the procedure
<mdke> infinity: should I wait to ask the sru team, or you think it'll be ok, and I can prepare a fix?
<somerville32> mdke: If you prepare the fix and provide a debdiff and what not with your proposal, then it'll streamline things.
<mdke> ok
<infinity> mdke: Prepare a fix, attach a debdiff to the bug, notify the SRU folks.
<infinity> mdke: Basically, follow the instructions in the wiki.
<infinity> mdke: Don't upload to -proposed until you have approval.
<mdke> that's fine, I haven't got a clue how to upload something
<mdke> I'll ask dholbach to help
<Mithrandir> cjwatson: do you have any idea about the error crimsun reported this morning?
<somerville32> mdke: I have a log that'll help you
<mdke> somerville32: aha?
<somerville32> mdke: I can't find it right now. I'll get it later.
<mdke> somerville32: ok
<ogra> Mithrandir, any chance i can get a new live iso ?
<ogra> install seems fine now (size wise)
<Mithrandir> ogra: need new livefs-es too?
<ogra> i think so
<Mithrandir> can you check?  Look at the livefs build logs.
<ogra> there are only 20061204 logs, so yes, i need a new one
* ogra goes for more coffee
<Mithrandir> ok, livefs-es buildin
<Mithrandir> +g
<seb128> could anybody give a build retry to yelp?
<dholbach> good morning
<dholbach> hi seb128
<seb128> hey dholbach
<Gloubiboulga> Mithrandir: it'd be nice to have a Xubuntu herd 1. Could you build the isos?
<Gloubiboulga> ah, they are up already
<cjwatson> mdke: I'd at least consider that for an SRU
<cjwatson> crimsun: the keyboard misdetection is known; I filed a bug on keymapper following an earlier report
<crimsun> cjwatson: ok
<twb> Howdy.  I'm trying to combine the functionality of the casper and nfs initramfs scripts, in order to mount a read-only NFS filesystem and merge it with a copy-on-write ramdisk.  Can anyone suggest documentation or other resources that I might find helpful?
<cjwatson> crimsun: somebody needs to merge the Xubuntu seeds
<cjwatson> that's the cause of the other problem
<crimsun> Gloubiboulga: would you merge the seeds please?
<cjwatson> <cjwatson@cairhien ~/src/ubuntu/seeds/xubuntu-feisty>$ fgrep 2.6. *
<cjwatson> installer: * Kernel-Version: 2.6.17-10-generic
<cjwatson> etc.
<Mithrandir> cjwatson: while annoying, do you think the keyboard detection problem is a showstopper?
<cjwatson> Mithrandir: no, it's not; you can go back from the screen informing you of the misdetection and select it manually
<Mithrandir> agreed
<Mithrandir> cjwatson: can you test the ppc isos?
<Gloubiboulga> crimsun: yep
<crimsun> Gloubiboulga: great, thanks!
<cjwatson> Mithrandir: if you give me a few hours for the download ...
<Mithrandir> cjwatson: sure, or I can ask pitti
<cjwatson>      5275648   0%   49.71kB/s    4:00:21
<cjwatson> urgh
<cjwatson> I'll leave it going, but evidently I need to go hunting through my local network for hogs
<cjwatson> ah, no, it's down to 1:45 now
<Mithrandir> amd64/desktop seems fine
<Mithrandir> (in vmware)
<pitti> Mithrandir: I started rsyncing the ppc image, but it'll take a while (my network sucks for rsync)
<Mithrandir> pitti: ack
<seb128> do we need to wait on ppc for herd1?
<Mithrandir> desktop/i386 seems unhappy on amd64 vmware.
<seb128> :(
<Mithrandir> I'll try on real hardware.
<Mithrandir> seb128: I'm fairly confident the images we have now are good.
<seb128> rock
<Mithrandir> hmm.
<Mithrandir> it crashes on 32 bit too
<Mithrandir> cjwatson: is current i386 desktop busted for you in vmware too?
<cjwatson> Mithrandir: haven't got that far
* cjwatson adds that to the rsync queue
<Mithrandir> hmm, it only seems to manifest itself on smp machines
<Mithrandir> I'll try it on real hardware
<cjwatson> Mithrandir: it boots OK here, at least. What was the breakage?
<Mithrandir> cjwatson: kernel oopsed.
<Mithrandir> cjwatson: is your vmware instance SMP?
<cjwatson> no
<cjwatson> uniprocessor host
<Mithrandir> it only manifests itself on smp here.
<Mithrandir> UP seems fine.
<cjwatson> has anyone tested ubiquity on i386, or do I need to?
<Gloubiboulga> cjwatson: what kernel are we supposed to have? ubuntu seeds seem to use the same kernel (2.6.17-10)
<cjwatson> DOH
<cjwatson> ok, willfix
<cjwatson> Mithrandir: we'll need to respin all alternates ...
<Mithrandir> cjwatson: I did them after d-i built last night.
<Mithrandir> cjwatson: do we still need to?
<cjwatson> yes, out of date seeds
<Mithrandir> gnr, ok.
<Mithrandir> but -deskop is fine?
<cjwatson> unaffected by this problem at least
<cjwatson> Gloubiboulga: I'll merge everything - we need to do the lot anyway
<cjwatson> sorry about that
<Gloubiboulga> cjwatson: no problem
<Mithrandir> cjwatson: that means we need a d-i upload too, or?
<cjwatson> no
<Mithrandir> hmm, possibly bad media, I'll try burning it again
<pitti> Mithrandir: 'check' mode?
<Mithrandir> pitti: not when it fails to show gfxboot. :-P
<pitti> oh, heh
<Mithrandir> argh, I don't seem to have any working dvd-rw media here.  I'll go find some new disks
<winkle> su
<winkle> ehm
<pitti> winkle: yup, feel free to paste your su password here, too :-P
<winkle> ;)
<mnepton> pitti. it rhymes with kitty.
<elkbuntu> pitti, run, before he tries to pet you
* pitti stumbles over to his mother cat and ruffles mnepton 
<mnepton> slamdance cosmospolis. enlighten the populace. shot into eternity. methadone kitty.
* cjwatson makes a note not to run spamassassin on #ubuntu-devel
<mnepton> cjwatson: bogofilter?
<cjwatson> :-)
<ogra> Mithrandir, edubuntu livefs is done
<cjwatson> - * linuxprinting.org-ppds # We want those in main, but not for desktop.
<cjwatson> + * linuxprinting.org-ppds-exta          # Less common printer drivers we don't want in main
<cjwatson> typo, right?
<cjwatson> yeah, looks like it
<mnepton> there's a linuxprinting.org-ppds-sextra ?
<mnepton> wait, don't tell me. i'm safer not even knowing.
<pitti> mnepton: simple answer: yes, there is :)
<pitti> mnepton: well, an -extra at least
* mnepton schedules his next sleep cycle for january
<ogra> cjwatson, why did you merge avahi-autoipd ?
<cjwatson> why not?
<ogra> i dont think that goes well with a locally running dhcpd
<cjwatson> if you don't want it merged, it's your choice to remove it
<ogra> pitti excluded it ... i'll remove
<cjwatson> pitti excluded it> how so?
<cjwatson> I just did what bzr merge presented
<ogra> well, he asked me if i would want avahi-autoipd and libnss-mdns merged
<pitti> I didn't actively exclude it, I just didn't merge the seeds; ogra didn't want to have autoipd in edubuntu by default
<cjwatson> then the correct thing to do would have been to merge that bzr changeset but remove the change
<cjwatson> it is not everyone else's responsibility to keep track of your choices
<ogra> pitti, oh, then i misunderstood, sorry for the fuzz
<pitti> no problem, just a misunderstanding
<cjwatson> libnss-mdns was already in edubuntu desktop before I got there
<ogra> yep, thats fine
<ogra> providing dns services is ok, but i want to inspect the behavior of the automatic interface configuration before blindly adding it
<cjwatson> Mithrandir: go ahead and rebuild all alternates now; the seeds are up to date
<cjwatson> Ubuntu i386 desktop (ubiquity) tests out successfully
<Mithrandir> cjwatson: thanks, running.
<Mithrandir> cjwatson: ok, i386 on real smp amd64 hardware works fine, so I'll write my problem down to vmware being silly
<pitti> yay, 8 mins ETA for ppc/desktop download
<Mithrandir> pitti: woo.
<Mithrandir> ogra: edubuntu live images for you
<cjwatson> Mithrandir: ok, good
<cjwatson> pitti: you're ahead of me, then. :)
<cjwatson> which is probably just as well - I'm trying to sort out the partman-auto merge into ubiquity, finally
<pitti> alternate is jigdo'ed for ages, but I wait for the new images with fixed kernels
<cjwatson> a.k.a. "big honkin' frontend rearrangement"
<Mithrandir> pitti: fresh alternate should be up now.
<pitti> ah
* pitti cranks up jigdo again then
<Riddell> Mithrandir: there still seems to be a problem with python-kde3, am investigating
<Mithrandir> Riddell: ugh
<pitti> cjwatson: I won't be able to test the ppc/alternate soon anyway, I have an appointment in 50 minutes
<cjwatson> it'll take me another two hours to fetch that
<pitti> I can test it when I return (in about three hours, I'd expect)
<StevenK_> cjwatson: Got a sec? I've done an upload of aircrack-ng twice and I haven't heard a peep from Launchpad about it.
<cjwatson> StevenK: version?
<Mithrandir> StevenK: LP doesn't give any useful error message; I'll try to reprocess it.
<StevenK> 0.6.2-5ubuntu1
<Mithrandir> hmm, no, that's something else
<cjwatson> StevenK: feisty is frozen; all uploads need manual approval
<cjwatson>   139287 | S- | aircrack-ng          | 1:0.6.2-5ubuntu1     | 2 hours 20 minutes
<cjwatson>          | * aircrack-ng/1:0.6.2-5ubuntu1 Component: universe Section: net
<cjwatson> accepted now
<StevenK> cjwatson: But I should get a message saying so
<cjwatson> yes, you should
* StevenK checks his mailserver.
<cjwatson> StevenK: LP thinks it mailed Steve Kowalik <stevenk@debian.org>
<cjwatson> StevenK: your first upload failed due to a known LP bug where it sometimes fails to check the public key; in that case it's known (but hard to fix correctly) that you don't get told about it
<StevenK> Ahh
<cjwatson> hard to fix> because LP tries not to mail anyone before it's done the GPG check, as a spam backscatter prevention measure
<StevenK> Which of course defeats this. :-)
<cjwatson> Riddell: what's the cleanest way to indent a group of widgets by a bit in Qt? as in, I have a set of radio buttons each of which may have some subsidiary options; I'd like to indent them to indicate that they're subsidiary
<Riddell> cjwatson: fixed width spacer
<cjwatson> at the left-hand side of a QHBoxLayout?
<Riddell> yes
<cjwatson> ok, thanks
<Riddell> Mithrandir: I've uploaded python-kde3 with tightened build-deps, could you let it through please
<StevenK> Riddell: That fixes the initkdecore symbol thing?
<Riddell> StevenK: I certainly hope so, I had it fixed yesterday, the only difference is the one I uploaded yesterday built against the old pyqt
<StevenK> Ah.
<Riddell> I would have thought the new qt build would have been enough to fix it, but seems not
* pitti blinks when ppc's usplash suddenly jumps to weird colours
<Mithrandir> pitti: X starting, maybe?
<pitti> Mithrandir: it doesn't start yet
<pitti> Mithrandir: just cosmetics anyway; ppc live system starts up fine
<Mithrandir> ok, goodie.
<Mithrandir> hmm, amd64 alternate doesn't seem to like the SCSI vmware thingy?  I though we fixed that?
<Mithrandir> ogra_: you have alternates ready now too.
<Mithrandir> Riddell: same goes for you ; alternates ready to test.
<cjwatson> Mithrandir: which SCSI vmware thingy? disk or C?
<cjwatson> CD?
<Mithrandir> cjwatson: disk
<Mithrandir> Riddell: python-kde3 accepted, btw
<pitti> Mithrandir: ppc/ubiquity install is running, but I have to run myself now for my 1300 appointment
<pitti> Mithrandir: will continue when I return, sorry
<cjwatson> Mithrandir: that should have been fixed by my initramfs-tools upload, yeah
<ogra_> Mithrandir, thanks a lot
<Mithrandir> so if I tell you there was no \*mpt\* in /lib/modules.
<cjwatson> I blame the kernel then
<Mithrandir> and xserver-xorg's postinst is looping with the resolution question.
<ogra_> edubuntu live-i386 runs fine in qemu
<Mithrandir> or rather, it asks once per driver.
<Mithrandir> rodarvus: do you know anything about the thing I reported above?
<rodarvus> Mithrandir: I joined #ubuntu-devel 20 minutes ago, I'm not sure I have the full backlog of your report
<rodarvus> (but would be quite thankful if you could paste it to me in a privmsg)
<sladen> pitti: is X starting and restoring the palette?
<Mithrandir> rodarvus: basically, I get asked about X resolution about seven trillion times on alternate install.
<Mithrandir> cjwatson: actually, initramfs doesn't matter, it's d-i which matters.  I blame the kernel for not having stuffed the right modules in scsi-modules or similar
<ogra> oh, that wuld break ltsp ...
<rodarvus> Mithrandir: oh
<ogra> but i didnt see it when i built my last ltsp chroot on friday
<Mithrandir> rodarvus: I haven't tried to reproduce on real hardware, this is amd64 vmware.
<ogra> i dont think there were uploads of X 
<rodarvus> ogra: indeed, there were no X uploads yet
<rodarvus> which makes this failure kind of surprising
<Mithrandir> rodarvus: trivially reproducible in vmware/amd64.
<Mithrandir> cjwatson: does alternate work for you at all?
<cjwatson> Mithrandir: oh, I didn't realise you meant d-i
<cjwatson> need to rsync down the seed-fixed alternate image first
<ogra> likewise here, but live seems ok to me
<Mithrandir> yeah, live seems fine.  It's alternate which is bloody stubborn.
<rohan> why is the ubuntu.com home page displaying chinese/japanese characters by default in the search box in the top right ? 
<rohan> and, is there any place where i can file bugs for the main website ?
<rohan> and in the "Welcome" page it displays "Suchen"
<Treenaks> rohan: not for me..
<Treenaks> rohan: what language is your browser set to?
<minghua> yes, I believe you report to ubuntu-website: https://launchpad.net/products/ubuntu-website
<rohan> Treenaks: english
<rohan> minghua: aha, thanks
<minghua> but then like Treenaks it doesn't happen for me here
<rohan> strange .. here it happens in both firefox and konqueror
<minghua> I suspect some browser setting problem as well
<rohan> now its "Cerca" ;p
<rohan> actually, it is changing with each of the tab i click on, in the top navigation pane
<Mithrandir> probably some element which is cached and shouldn't be it
<Treenaks> rohan: it's still not happening for me
<rohan> Mithrandir: this the first time i opened that site in firefox
<cjwatson> could be cached by your ISP, though
<Mithrandir> rohan: stuff aren't only cached on your end
<rohan> ah, i see
<Mithrandir> cjwatson: I see it too
<rohan> true enough, but it changes randomly
<rohan> i.e. not always "Cerca" on support and so on
<ogra> me too, it filps between "buscar" and "search" 
<cjwatson> Mithrandir: alternate hangs for me while trying to modprobe i82365
<cjwatson> booting with hw-detect/start_pcmcia=false may be a workaround; let's see
<finalbeta> I'm getting "Keress"
<Mithrandir> cjwatson: vmware or real hardware?
<cjwatson> Mithrandir: vmware
<rohan> finalbeta: yes, me too
<rohan> but for me, it changes with each tab
<cjwatson> I filed a kernel bug about an oops in i82365 a couple of days ago
<rohan> well, do i go ahead and file the bug on the website ?
<Mithrandir> cjwatson: yeah, it clearly oopses in vmware.
<cjwatson> yeah, hw-detect/start_pcmcia=false works around that crash
<cjwatson> release notes
<minghua> rohan: I would say be bold to file bugs :-)
<minghua> rohan: and maybe invite all these people who see the same thing to comment on your bug as well
<cjwatson> yep, no disk detected here either
* cjwatson retries with IDE emulation
<rohan> minghua: true, but i wouldnt want to file a bug if it is a known issue or so :)
<cjwatson> Mithrandir: can you confirm bug 74122?
<Ubugtu> Malone bug 74122 in linux-source-2.6.19 "oops loading i82365 in installer" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74122
<elmo> Mithrandir: you're running lithium out of space ...
<Mithrandir> cjwatson: done.
<Mithrandir> elmo: I know, I'm going to do something about it RSN.
<elmo> Mithrandir: k
<Mithrandir> elmo: but thanks for the heads-up.
<rohan> https://bugs.launchpad.net/products/ubuntu-website/+bug/74508
<Ubugtu> Malone bug 74508 in ubuntu-website "Text in the search box changes randomly." [Undecided,Unconfirmed]  
<rohan> there .. please comment to help :)
<minghua> rohan: you might want to put the exact url in the report...  http://www.ubuntu.com/ I assume?
* rohan does it
<cjwatson> Mithrandir: I'm not seeing multiple xserver-xorg questions, but I am seeing bittorrent being uninstallable and pkgsel falling over as a result
<Mithrandir> cjwatson: hmm, the start_pcmcia workaround is needed on real hw too.
<cjwatson> Mithrandir: see also http://cdimage.ubuntu.com/daily/current/report.html
<cjwatson> what about real hardware with pcmcia?
<Mithrandir> I don't know, I don't have any such which boots cds.
<Mithrandir> bah
<cjwatson> bittorrent Depends: python (>= 2.5)
<cjwatson> I propose commenting gnome-btdownload out of the desktop seed for now
<Mithrandir> hmm, why haven't the livefs-es ftbfs-ed?
<cjwatson> dunno, and it isn't listed as uninstallable by britney
<Mithrandir> maybe it's just not on the cd for some reason.
<Mithrandir> weird.
<Mithrandir> oh well, can you change the desktop seed and upload?
<cjwatson> hmm, what's going on
<cjwatson> hang on a bit
<cjwatson> I think something is not clever enough to include python2.5 on the CD for some reason ...
<Mithrandir> well, python is version 2.4.3-11ubuntu3 in feisty
<Mithrandir> (    python | 2.4.3-11ubuntu3 |        feisty | all
<Mithrandir> )
<cjwatson> the depends is python (>= 2.5) | python2.5
<Mithrandir> ah
<seb128> do we have access to the frozen packages somewhere?
<cjwatson> I think updating germinate on lithium might help ... I'll test
<cjwatson> seb128: afraid not
<seb128> hum, k :/
<seb128> I should not have deleted after upload
* cjwatson tries a test build
<cjwatson> seb128: what do you ned?
<Mithrandir> seb128: I can give you the sources for single packages, but we don't have binaries yet.
<cjwatson> need
<seb128> k, will do evolution-exchange later
* cjwatson defers to Mithrandir
<seb128> no hurry I'll do it after freeze
<Mithrandir> seb128: 'k
<seb128> thanks Mithrandir, cjwatson
<gicmo> seb128: !!!!
<gicmo> ;-)
<gicmo> ALTER
<seb128> gicmo: Alter! :)
<cjwatson> oh, I see, it's a germinate bug
<gicmo> seb128: if you have time, could you look at the priv msg
<Mithrandir> cjwatson: ok, so we just need to respin the alternate cds?
<Mithrandir> cjwatson: can we disable pcmcia by default too?
<seb128> gicmo: no private msg, you are probably not registred
<seb128> gicmo: use gimpnet or register
<StevenK> Riddell: -0ubuntu5 fixes the import bug.
<Mithrandir> (it's better to piss of those who need pcmcia to install than everybody else who won't be able to install.  IMO)
<gicmo> I am
<gicmo> ahh not authenticated
<cjwatson> bug 74514
<Ubugtu> Malone bug 74514 in germinate "doesn't handle versioned dependencies" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74514
<Mithrandir> cjwatson: ouch.
<Riddell> StevenK: hoorah!  thanks for testing
<Mithrandir> cjwatson: is it a trivial fix in germinate or should we just work around it?
<StevenK> Riddell: No problem. Shall I kill the bug, or do you want to?
<Riddell> StevenK: you have the honour
<Riddell> seems that removing the visibility patch gets rid of a couple of entirely unexpected qt bugs too
<StevenK> Riddell: Do I have to do everything? :-P I reported it, as well.
<Riddell> StevenK: well I can do it if you want, but lets not argue over it longer than it would take to press the button :)
<Riddell> Mithrandir: I'll make new kubuntu desktop CDs 
<Mithrandir> Riddell: you don't need new livefs-es?
<Riddell> oh, yes, so I do
<cjwatson> Mithrandir: we should work around it by either removing gnome-btdownload from desktop or adding python2.5 to desktop; your choice
<Riddell> Mithrandir: I need your help then for that
<Mithrandir> Riddell: kubuntu livefs-es building, then
<Mithrandir> cjwatson: let's remove gnome-btdownload; I'd like not to end up with oversized CDs again.
<cjwatson> I'll do that, then
<Mithrandir> thanks.
<Mithrandir> tell me when I can spin new CDs?
<cjwatson> it'll need {ubuntu,edubuntu}-meta uploads
<StevenK> Riddell: Indeed. I've closed it already anyway. :-)
* Keybuk gets confused by stdio
<Mithrandir> uh, we have an ubuntu-meta upload in unapproved?
<ogra> Mithrandir, "<cjwatson> it'll need {ubuntu,edubuntu}-meta uploads"
<ogra> cjwatson, i'm updateing edubuntu if you didnt do yet ...
<ogra> -e
<Mithrandir> ogra: this one is 22 hours old.  I didn't think cjwatson possessed a time travel device, though that'd explain how he gets so much done..
<ogra> heh
<HumanPrototype> cjwatson: Hi - I have been told you are the best person to talk to about ubiquity, is that correct?
<cjwatson> ogra: go ahead, just make sure gnome-btdownload gets removed
<cjwatson> Mithrandir: can I accept that ubuntu-meta upload first to reduce confusion?
<cjwatson> HumanPrototype: yeah, that's me
<cjwatson> ogra: make sure to s/edgy/feisty/g in update.cfg
<cjwatson> (if not done already)
<ogra> cjwatson, did that a week ago ;)
<cjwatson> ok
<HumanPrototype> cjwatson: I am trying to alter the xubuntu beta 1 cd to setup as a thin client distro and am trying to make ubiquity skip the user setup questions and just create a single user called "user"
<cjwatson> HumanPrototype: unfortunately that can't be done in ubiquity at the moment without fairly sweeping code changes
<cjwatson> you can set a default, but not skip it
<cjwatson> https://blueprints.launchpad.net/distros/ubuntu/+spec/ubiquity-automation is a design for fixing that
<ogra> HumanPrototype, there is no implementation to build the ltsp environment from a live CD yet, you need to use the alternate CD for now
<cjwatson> now, in the alternate install CD, you can skip the user-setup questions fairly easily
<Mithrandir> cjwatson: please do
<HumanPrototype> cjwatson: ok, thanks - how about editing the text on that page to say it wont actually do anything and they changing the script to ignore those variables? is that possible?
<cjwatson> that's probably more work :-)
<cjwatson> HumanPrototype: are you talking about a thin client server, or the thin client itself?
<cjwatson> I thought thin clients were typically booted by delivering an image, rather than by doing an installation as such
<ogra> right
<HumanPrototype> ogra: I must admit I know nothing about ltsp 
<ogra> you either use pxe, etherboot or bootp (the latter is unsupported in ubuntu)
<ogra> if your client sends out a PXE bradcast, the dhcp server answers it, gives it an IP and tells it where to find a tftp server (usually the same machine) to get the bootkernel from ...
<cjwatson> HumanPrototype: hmm, I suppose you could skip a page in ubiquity by modifying the loop in run() in ubiquity/frontend/gtkui.py
<HumanPrototype> cjwatson: my boss wanted a distro that would boot and let him login as a thin client similar to a hp thin client box he brought
<Chipzz> ogra: I'm not sure, but I think you're mixing something up
<ogra> if the kernel is booted the client mounts / via nfs from the ltsp server and boots it ...
<Chipzz> ogra: the dhcp server actually also does bootp
<cjwatson> change the stepUserInfo case to do self.set_current_page(self.current_page + 1); continue in that case
<ogra> Chipzz, well, but not tested or supported in ubuntu
<Chipzz> ogra: so pxe *does* use bootp as a matter of fact iirc
<HumanPrototype> ogra: this is to connect to a windows terminal server
<HumanPrototype> cjwatson: ok, thanks
<ogra> HumanPrototype, hmm, then you would want to boot an ltsp client that starts up an rdesktop client
<cjwatson> HumanPrototype: but, I think this is probably not the ideal option and you should talk with ogra about LTSP
<HumanPrototype> ogra: I'm currently ripping all the guts out of xubuntu and replacing xfce with fluxbox and then install tsclient and rdesktop
<ogra> Chipzz, we dont *officially* test bootp or *officially* support it, indeed dhcpd is capable of doing it ;)
<cjwatson> HumanPrototype: the ltsp-build-client script defines what gets installed in the client chroot
<ogra> (in combination with ltsp that is)
<cjwatson> Mithrandir: publisher disabled while I get this done
<HumanPrototype> ogra: I'm going to carry on with this for my boss but then I will look into ltsp and going down that route
<ogra> HumanPrototype, you can do a standard ltsp install with ltsp-build-client and then install rdesktop in the client environment...
<mvo> just to confirm, we do use alsas dmix by default, right?
<ogra> HumanPrototype, feel free to ping me in #ltsp or #edubuntu where that discussion is more on topic
<ogra> cjwatson, edubuntu-meta should be in the queue
<HumanPrototype> ogra: my boss doesnt really know linux and basically wants something that runs on old machines and will boot to give him a gui to setup an rdesktop connection and can reconnect on startup in the future
<ogra> mvo, we did in edgy at least
<mvo> ogra: thanks
<ogra> HumanPrototype, right, sounds like ltsp is the right option for you ..
<ogra> but you will need a linux server to boot from ...
<HumanPrototype> ogra: could I alter it reasonably easily to get it from a windows server?
<ogra> nope
<ogra> no nfs on windows ....
<HumanPrototype> ogra: i was expecting that somehow
<HumanPrototype> ogra: knowing very little would you be able to use samba instead of nfs?
<ogra> you can tweak a windows dhcp server and you might even be able to server the kernel via tftp from it ... but for nfs i dotn know a free and easy solution
<ogra> i'm not aware of anybody who tried CIFS/SMB for that :)
<ogra> might be possible, who knows :)
<HumanPrototype> ogra: sounds like an excuse for my boss to run a linux server
<ukh> dumb newbie question: why isn't buildlogs for all packages on launchpad?  I'm trying to resolve a nagging little issue that depends on the build environment, but 1.4.2.2-1ubuntu2.1 doesn't expose - however, I find no build log for that one
<ogra> heh, yeah
<ukh> oups.  the package I'm battling with is gnupg
<ogra> thats a security update ... not sure the logs are on launchpad ... 
<ukh> well, that's ok, appears to be a regression in gnupg post-1.4.2...
<pitti> Mithrandir: if it's not yet too late, ppc/live + ppc/ubiquity works fine
<pitti> cjwatson, Mithrandir: shall I test ppc/alternate now?
<Mithrandir> pitti: yay, good.
<Mithrandir> pitti: please do sync ppc/alternate, but we'll need to respin yet another.
<pitti> Mithrandir: oh, ok. I have 1205 already
<pitti> Mithrandir: jigdo'ing a new one is super-fast
<Mithrandir> pitti: yeah, it should be.
<ogra> Mithrandir, seems colin is afk, could you approve the edubuntu-meta uplaod ? 
<ogra> *upload
<Mithrandir> ogra: I suspect he's byhanding the publisher.
<Mithrandir> accepted, though
<ogra> oh, ok
<cjwatson> I was off writing documentation, actually
<ogra> thanks :)
<cjwatson> just accepted ubuntu-meta too
<cjwatson> publisher running
<doko_> cjwatson, adconrad: I uploaded sun-java5 yesterday; it got accepted, but it doesn't show up in the archive. anything I miss?
<Mithrandir> Listing ubuntu/None (UNAPPROVED) 1/69
<Mithrandir> ---------|----|----------------------|----------------------|---------------
<Mithrandir>   139067 | S- | sun-java5            | 1.5.0-10-0ubuntu1    | 29 hours
<Mithrandir>          | * sun-java5/1.5.0-10-0ubuntu1 Component: multiverse Section: devel
<Mithrandir> so no, it wasn't accepted.
<ogra> doko_, we're frozen since some days ;)
* ..[topic/#ubuntu-devel:ogra] : _
<ogra> eek
<Mithrandir> we've frozen for close to a week..
* ..[topic/#ubuntu-devel:ogra] : Ubuntu Development (not support, even with feisty) | #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 | Edgy is released | Feisty is frozen for Herd-1
<_ion> Now that the topic is updated, it might be changed from "Ubuntu Development" to "Development of Ubuntu"
<_ion> OTOH, the people who should read it don't read it anyway. ;-)
<doko_> Mithrandir, ogra: ok, but eclipse got accepted. strange. I thought the freeze was for main only
<Mithrandir> doko_: it is, but I suspect nobody has gotten around to accepting your upload, then.
<cjwatson> doko_: by policy it is for main and restricted only, but our only available way to implement it is by freezing the entire archive and manually accepting universe and multiverse from time to time.
* ..[topic/#ubuntu-devel:cjwatson] : Development of Ubuntu (not support, even with feisty) | #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 | Edgy is released | Feisty is frozen for Herd-1
<HumanPrototype> cjwatson: In ubiquity/components/usersetup could i change the stuff in ok_handler to set username to "user" instead of self.frontend.get_username() to force a username?
* ogra reads the rationale of https://wiki.ubuntu.com/MultimediaProductionKernel and is shocked ...
<ogra> our default kernels "are vulnerable to security issues and missing some hardware support." :(
<cjwatson> HumanPrototype: that would work, but wouldn't be compatible with skipping the user page altogether
<Mithrandir> ogra: no, that's not what it reads.
<pitti> ogra: ?
<cjwatson> HumanPrototype: if you skip the user page, that code won't be run
<pitti> ogra: you mean the multimedia support introduces a security hole?
<ogra> Mithrandir, oh, right, *their* homebrewed ones are
<ogra> sorry
<ogra> pitti, no, i just misread the rationale there 
<zul> ogra: then they should do what we did with xen put a kernel in universe or something for their ubuntustudio
<ogra> zul, thats the plan as i understood from BenC 
<HumanPrototype> cjwatson: ok - i think I will try that as my knowledge of python isnt great enough to find out where to set the username if I do skip the user page
<zul> ogra: ah neat..
<ogra> there was a discussion on ubuntu-devel 
<cjwatson> HumanPrototype: be aware that the UI will be weird if you do that; asking a question and then ignoring the answer, ugh
<HumanPrototype> cjwatson: yeah - good point
* Starting logfile irclogs/ubuntu-devel.log
(cjwatson/#ubuntu-devel) HumanPrototype: and add preseed/file=/cdrom/preseed/filename-of-your-choice.seed to the kernel boot parameters on the append lines in /isolinux/isolinux.cfg
* Starting logfile irclogs/ubuntu-devel.log
* Starting logfile irclogs/ubuntu-devel.log
<Riddell> pitti: http://people.ubuntu.com/~pitti/langpacks/daily/edgy-updates/ ?
<pitti> Riddell: right
<pitti> Riddell: and, if you have a dapper installation around, testing the dapper ones would be great, too
<Mithrandir> Riddell: how does your desktop CDs look?
<Mithrandir> Riddell: actully, ignore that since I'm in the middle of spinning you new ones. :-P
<cjwatson> Mithrandir: I have to go out to order meat for Christmas dinner now; feel free to run the publisher by hand once all *-meta builds are in accepted, or just wait 'til I get back, whatever
<Riddell> Mithrandir: what's new in the new ones?
<ogra> gnome-btdownload was dropped :P
<Mithrandir> Riddell: just the ones from the livefs build an hour or so ago.
<Mithrandir> ogra: I hope that doesn't affect kubuntu CDs.
<ogra> me too ;)
<Riddell> me too!
<Mithrandir> cjwatson: I was thinking of just crashing for a bit; I woke up at 0400 today and I'm going over to some friends later.
<cjwatson> Mithrandir: ok
<cjwatson> Mithrandir: will you be around at all later, if I can get these built? I'd really like to get out of freeze today
<cjwatson> I don't think we necessarily need to rebuild livefses
<Mithrandir> cjwatson: I'm happy with the ubuntu livecds.  Both amd64 and i386 seem to work for me, sans the small problem of i386 blowing up in SMP 64 bit vmware, but I think we can live with that.
<twb> I'm having a lot of trouble booting them over NFS... :-(
<Mithrandir> twb: booting the live cd over NFS?  That might be because it doesn't sound like a remotely supported configuration..
<cjwatson> ok, so rebuild ubuntu/edubuntu alternates, test quickly, go?
<twb> Mithrandir: I realize that.
<cjwatson> twb: we're talking about for a milestone release
<Mithrandir> cjwatson: yup
<twb> I'm trying to implement support.
<Mithrandir> twb: don't bother; the code is in casper in Debian, I just need to merge it in.
<twb> A fuse bug is kicking me in the teeth.
<Mithrandir> cjwatson: I'll byhand the publisher then
<cjwatson> Mithrandir: not *quite* yet ...
<twb> Mithrandir: oh?  I assumed that Debian's casper was older.
<cjwatson> twb: we haven't merged everything since we got out of edgy release freeze yet, so a fair few of our packages are still older
<cjwatson> Mithrandir: go ahead and byhand it now
<Mithrandir> twb: it's forked and requires a fair bit of merging to get their changes back into our code.
<twb> I see.
<twb> Does casper actually have a homepage?  I couldn't find it.
<Mithrandir> not that I know of, and I'm the primary maintainer. :-P
<Mithrandir> Riddell: fresh kubuntu cds for ya.
<Mithrandir> (desktop)
<ogra> https://launchpad.net/distros/ubuntu/+source/casper
<ogra> ;)
<twb> Mithrandir: basically, what I do is mount a read-only NFS filesystem that contains the same data as filesystem.squashfs.  I then unionfs that with a tmpfs /cow and run the casper-bottom scripts.
<twb> Unfortunately, this blows up because (for some reason) unionfs doesn't let anything append to files, although it allows the files to be deleted and created.
<ogra> twb, its probably helpful to have  a look at ltsp (specifically the ltsp-client.ltsp-client-setup.init script) to see the tmpfs workarounds we use there 
<Mithrandir> twb: it might very well be a unionfs bug.  We're run into quite a few of those.
<twb> I also have this problem using unionfs of Knoppix 3.7 through 4.0
<twb> Er, through to 5.0
<ogra> thats why ltsp resorts to tmpfs bind mounts ;)
<twb> I'm trying to avoid doing that.
<Mithrandir> ogra: that doesn't allow you to install packages, for instance.
<twb> (That's what Knoppix did historically)
<Mithrandir> have you looked at how the support in the debian package is done?  Or you could look at some of the fuse unionfs alternatives.
<ogra> well, i can install packages in my fat-client environment 
<bddebian> Howdy
<ogra> which is essentially a ltsp 
<twb> Mithrandir: OK, so this is definitely supported already in Debian's casper?  When you said that before, I wasn't sure you understood what I was doing.
<Mithrandir> ogra: how do you do that without having a writable layer on top of your filesystem?
<Mithrandir> twb: I'm _fairly_ sure what you're trying to do is doable using their casper, yes.
<ogra> Mithrandir, i add the writeable layer via a tmpfs bindmount
<twb> Mithrandir: OK.
<Mithrandir> I keep meaning to merge those bits, but ENOTIME.
* twb snarfs Debian's casper.
<Mithrandir> ogra: like, over /usr ?
<ogra> like over specific dirs or files, yes
<twb> Mithrandir: I am more than happy to help get this fixed; I can't get rid of Knoppix until I do.
<ogra> i wouldnt pick the whole of 7usr though
<ogra>  /usr
<Mithrandir> ogra: so you don't support arbitrary package installations, then?
<ogra> only via chroot on the server ... but you can do temporary installs on the fat client indeed
<Mithrandir> ogra: of any package, and you do this without using unionfs?
<twb> `temporary installs' being until you reboot?
<ogra> twb, yes
<Mithrandir> twb: package installations on a live cd tend to be until you reboot. :-)
<ogra> i'm working on a "master workstation mode" that mounts / in rw mode to have a maintainer machine ...
<ogra> Mithrandir, yes, i do it without unionfs ... but with a huge mtab
<ogra> unionfs via nfs is still to buggy 
<ogra> s/via/on top of/
<ogra> it was like that when mdz started testing it for ltsp and didnt change until edgy ...
<HumanPrototype> where can I get involved with ubuntu development?
<gnomefreak> HumanPrototype: #ubuntu-motu is the best place to ask/start
<ogra> HumanPrototype, https://wiki.ubuntu.com/MOTU
<jdong> keescook: ping
<Mithrandir> ogra: how do you do it when something wants to install a file in /usr/bin?  You copy all of it into a tmpfs?
<iwj> Keybuk: If you have any comments on my discussion of the alleged lvm2 symlink creation race in UdevLvm, I'd be interested to hear them.  But I will press on in the meantime ...
<ogra> Mithrandir, yes ... (i know its ugly) 
<ogra> Mithrandir, usually you dotn do that at all, but its possible ...
<pitti> mdz: can I upload new dapper and edgy -proposed langpacks? (I tested the German ones and checked that a recent major bug in the Kurdish ones was fixed); after they are in -proposed, I'd send out a call for testing to -translators@
<twb> btw, casper-bottom/20xconfig seems to assume xserver-xorg is installed.
<Mithrandir> twb: it does, but it shouldn't.  It should be guarded properly.  If it's not, please file a bug.
<Mithrandir> ogra: so you end up consuming hilarious amounts of memory, then?
<twb> Do bugs filed with reportbug(1) actually make it into launchpad?
<Mithrandir> twb: no
<twb> Bleh.
<Mithrandir> they will, eventually, but not yet.
<twb> What's the process for submitting bugs for people who can't stand web UIs, then?
<Mithrandir> eat a painkiller and use the web UI? ;-)
<HumanPrototype> cjwatson: in the preseed files that are there I notice they install ubuntu-base etc - Do I need to configure a package to depend on everything I want to be installed and call it in the same way?
<Mithrandir> we're going to get an XML-RPC interface which we'll hook reportbug into, but it's not there yet.
<twb> One of the bzr people I was talking to today said he did all his launchpad stuff via mail.
<Mithrandir> oh, true, you can submit and manipulate bugs via mail
<Mithrandir> https://help.launchpad.net/UsingMaloneEmail has some info on it
<twb> Seems a bit silly to break reportbug, then.  I mean, reportbug under Debian basically just sends a mail message.
<twb> Thanks.
<HumanPrototype> gnomefreak and ogra thanks
<Mithrandir> it requires the mails to be signed.
<pitti> Mithrandir: oh, there's a new alternate image 20061205.1 -- is that the good one? or do we need .2?
<Mithrandir> pitti: we need .2 which is building now.
<pitti> ok, thanks
<twb> Argh, that URL doesn't render in html2ps
<\sh> BenC: one short question...do you want to include the EDAC stuff from vanilla kernel or the updated drivers from bluesmoke.sf.net?
<Riddell> pitti: french kde language pack works on edgy
<BenC> \sh: Stock
<Riddell> pitti: I'll make a dapper chroot now
<BenC> \sh: bluesmoke needs to sync up to mainline
<pitti> Riddell: vmware image might be better; thanks for testing edgy
<\sh> BenC: thx for the information :) 
<Mithrandir> pitti: .2 is up; this one ought to work.
* pitti jigdos
<Mithrandir> ogra: you have ISOs
<twb> Mithrandir: you're right; debian's casper does support ro uncompressed nfs roots.
<iwj> root@samual9:~# /lib/udev/vol_id -t wergle -l wergle wergle /dev/hda10
<iwj> root@samual9:~# /lib/udev/vol_id -t wergle -l wergle wergle -t /dev/hda10
<iwj> LVM2_member
<iwj> root@samual9:~# root@samual9:~# /lib/udev/vol_id -t wergle -l wergle wergle /dev/hda10
<iwj> root@samual9:~# /lib/udev/vol_id -t wergle -l wergle wergle -t /dev/hda10
<iwj> LVM2_member
<iwj> root@samual9:~# Oops.
<iwj> Sorry.
<looksaus> not entirely sure if the following question is appropriate here; please refer me to a more appropriate channel if you deem it necessary
<looksaus> the Intel 3945 wifi driver for Linux requires a binary userspace daemon
<looksaus> openbsd people have reverse engineered it (see http://kerneltrap.org/node/6650/print )
<looksaus> I'm buying a new laptop, and I'm willing to spend the discount I get from dell on a machine without windows on porting this thing
<twb> Also, -o dirs=/cow=rw:/rofs=nfsro instead of .../rofs=ro fixes the bug that has been plaguing me for months!
<twb> Hurrah!
<mjg59> looksaus: Intel are planning on fixing the issue in the next month or so
<[A] ndy80> hi
<Mithrandir> twb: yay.
<[A] ndy80> is it possibile to avoid libiberty compilation when I compile gcc? because libiberty is distributed with binutils and gcc too, so one copy overwrite the other one... (I'm making a package with checkinstall and this causes a conflict)
<looksaus> ah? mjg59, source?
<Mithrandir> twb: does nfsro work well with normal volumes as well?  If so, I can change ro to nfsro by default.
<twb> NFI.
<looksaus> would certainly be good news!
<mjg59> looksaus: Personal communication, sadly
<twb> The Debian one uses nfsro ONLY for nfs mounts.
<looksaus> hey, if _you_ say it, that is more than assuring enough
<looksaus> thx mjg59 
<Mithrandir> twb: hmm, ok.
<twb> That suggests that nfsro doesn't work (or is slow) with non-nfs dirs.
<cjwatson> HumanPrototype: is this dapper or edgy?
<ogra> Mithrandir, well, yes, it consumes some memory :)
<Mithrandir> ogra: you saw that you have fresh alternate ISOs, right?
<ogra> yep, already rsyncing
* pitti starts ppc/alternate test install
<Riddell> pitti: dapper language pack works too (Kurdish and French)
<pitti> Riddell: great, thanks; German and English ones work here, too
<malex> I'm looking for pbuilder scripts for Edgy, Dapper, and Breezy. Anyone can help?
<pitti> malex: -> #ubuntu
* pitti answers there
<mdz> pitti: yes
<pitti> great
<pitti> Keybuk: could I ask you to upload new dapper/edgy-proposed langpacks in silent mode for me?
<pitti> Keybuk: (I'm supposed to ask u-archive now, and Colin and Tollef are still busy with herd-1)
<Mithrandir> pitti: also, I have no idea how to make it quiet. :-P
<pitti> there's an option to suppress *-changes@lists mails
<Keybuk> Mithrandir: -M
* pitti hugs desrt 
* desrt is hugged by a pitti
<desrt> hello :)
<dade`> hi
<desrt> goodday, dade
<Keybuk> pitti: err, where do I find said language packs?
<pitti> Keybuk: rookery:/srv/language-packs.ubuntu.com/edgy-updates-proposed-20061205/sources-update/*.changes
<pitti> Keybuk: and rookery:/srv/language-packs.ubuntu.com/dapper-updates-proposed-20061205/sources-update/*.changes
<Keybuk> pitti: what do you want me to do with them?
<pitti> Keybuk: they need to be uploaded in a way that they don't generate -changes emails
<Keybuk> pitti: I have no idea how to do that
<Keybuk> it's the accept phase that generates changes mails anyway
<pitti> Keybuk: I can't do that myself (although I have a long-standing wishlist item for soyuz to allow notification blacklists)
<Keybuk> so if you upload them normally, I can block the mailing list ones
<Keybuk> just not the ones to you
<pitti> Keybuk: ah, ok; so far cprov or malcc did those uploads, but they asked me to delegate this to the archive team
<pitti> so I don't know the magic behind it
<pitti> Keybuk: alright, then I just dput them?
<Keybuk> yup
<Keybuk> afaik
<cjwatson> don't
<cjwatson> I know how to do them
<HumanPrototype> am i correct in thinking that this guide (https://help.ubuntu.com/community/LiveCDCustomization/6.06) wont change the files installed by the ubiquty program?
<cjwatson> HumanPrototype: ubiquity just copies the live filesystem onto the hard disk, then remooves anything that's listed in /casper/filesystem.manifest but not listed in /casper/filesystem.manifest-desktop
<cjwatson> HumanPrototype: so no, if you change the contents of the live filesystem, that will probably change what's installed by ubiquity
<Keybuk> cjwatson: how?
<HumanPrototype> cjwatson: so if i regenerate the manifest as that guide says then copy it to manifest-desktop then remove certain things (like ubiquity) that you dont want installed on the end system would that work?
<cjwatson> HumanPrototype: rigt
<cjwatson> right
<cjwatson> (damn keyboard, sorry)
<HumanPrototype> cjwatson: thanks for all this help :D
<hunger> When will herd1 get released? /me misses the thrill of updating packages in an unstable distribution right now;-)
<cjwatson> Keybuk: let me just do it to refresh my memory, and then I'll tell you what I did ;-)
<Keybuk> cjwatson: uploading should be ok though, it's just queue you have to pass -M ?
* pitti hugs and thanks cjwatson and hopes that it doesn't distract him from herd-1 issues too much
<cjwatson> Keybuk: you can run process-upload with -M too
<iwj> Uh.  I think this livecd is bust.  `Buffer I/O error ...'   `hdc: ide_intr: huh? expected NULL handler on exit' etc.
<mconnor> pitti / iwj: in case no one's linked you to this, I dunno how much caillon has talked to you yet, http://steelgryphon.com/blog/?p=96
<HumanPrototype> in the preseed file can i remove the line about the splash image to not install a splash image?
<mconnor> and wow, you're both here, crazy
<iwj> mconnor: Not at all yet.
* iwj reads.
<pitti> mconnor: hi
<mconnor> pitti: yo :)
<pitti> mconnor: didn't get any mail so far
<mconnor> guess he's just been talking to Debian-only people then
<iwj> mconnor: Hi, btw :-).
<mconnor> iwj: btw, for the record, that was the first time I've seen cops at a Mozilla event ;)
<cjwatson> HumanPrototype: I gather you're using dapper, then. Could you clarify exactly what version?
<HumanPrototype> cjwatson: actually the original cd i was working off is an xubuntu edgy beta 1 cd
<cjwatson> HumanPrototype: why are you using a beta rather than the release?
<cjwatson> there was no "beta 1" - I guess you mean either Knot 1 or the Beta, but I'm not sure
<cjwatson> the final release has no such line in the preseed file, which is why I'm asking
<HumanPrototype> cjwatson: erm... because it was in my cd wallet and a dapper one wasnt and i was at work?
<iwj> mconnor: Right, I believe you :-).
<HumanPrototype> cjwatson: well it claims to be xubuntu but it does have dapper listed in the sources.list file which i did think was odd
<cjwatson> HumanPrototype: that suggests strongly that it's not edgy
<cjwatson> I think you have either a mislabelled dapper CD or a very very early (probably broken) edgy CD. the .disk/info file on the CD would tell me for sure
<cjwatson> HumanPrototype: anyway, have a look at /preseed/server.seed on the CD - there's a bit at the top of that to avoid installing usplash
<iwj> mconnor: Just read that now.  That seems basically what we talked about a few weeks ago.  Nice to see it written down.
<mconnor> iwj: it has all of the right buy-in too, so hopefully that goes a long way to making everyone's job easier
<mconnor> next up is figuring out why we have binary bits in our tarballs :)
<cjwatson> pitti: some of those uploads are older versions than in the archive - there's 6.10+20061019~prop1 in there. Should I just remove those?
<HumanPrototype> cjwatson: thanks
<iwj> mconnor: Have you had any conversations with any of the Debian guys ?  I tried to encourage them to talk to you but I think they're quite busy.
<pitti> cjwatson: yes, please
<mconnor> hey, maybe someone knows this here, someone was talking about an OSS project that distributes the trademarked/copyrighted bits in a second source tarball
<pitti> cjwatson: I should sort those out myself next time, thanks for the reminder
<mconnor> iwj: I have not, but caillon has had quite a few
<iwj> Ah, good.
<pitti> cjwatson: the scripts for handling -proposed uploads are far from being sophisticated and user-friendly yet :(
<cjwatson> pitti: lp_queue@drescher:~/manual-queue/incoming/langpack-20061205$ ls | cut -d_ -f2 | cut -d. -f1,2 | sort -u | xargs
<cjwatson> 6.06+20061130~prop1 6.06+20061201~prop1 6.06+20061202~prop1 6.06+20061203~prop1 6.06+20061204~prop1 6.06+20061205~prop1 6.10+20061019~prop1 6.10+20061025~prop1 6.10+20061130~prop1 6.10+20061201~prop1 6.10+20061202~prop1 6.10+20061203~prop1 6.10+20061204~prop1 6.10+20061205~prop1
* iwj gets out the CD lens cleaner.
<cjwatson> which ones do you want? :)
<mconnor> iwj: things are looking better wrt being able to base Debian/Ubuntu off our stock tarballs by Fx3, instead of you guys needing to do some crazy surgery
<ogra> ARGH
<pitti> cjwatson: packs are only rebuilt if there is new data for them, so versions are all different
<pitti> cjwatson: 6.10+20061019~prop1 is an 'old' one, the rest should be fine
<iwj> mconnor: That would be an improvement, certainly.
<cjwatson> Keybuk: anyway, you make a directory in ~lp_queue/manual-queue/incoming/, punt everything in there, and do 'LPCONFIG=ftpmaster /srv/launchpad.net/codelines/current/scripts/process-upload.py -C insecure -v -v -v -M ~lp_queue/manual_queue/' (i.e. the thing in lp_queue's crontab but adding -M and changing the directory)
<mconnor> iwj: so, uh, question about how you guys handle updates
<HumanPrototype> cjwatson, ogra: thanks again for all the help, ill probably be back again soon
<cjwatson> and when we're frozen you have to use queue -M too, so yes it's true that pitti could just have uploaded them at the moment 'cos they wouldn't have been directly accepted, but it's better not to get into that habit
<ogra> edubuntu-install is broken ... apparently i have no inetd on the CD anymore
<mconnor> if we collect all of the random patches that Debian/Red Hat/Ubuntu/Novell have been collecting and get them on the branch, how is that going to work out?
<cjwatson> ogra: you need to seed an inetd (openbsd-inetd?) explicitly now - netbase doesn't depend on it any more
<cjwatson> Keybuk: actually, I'm using -N 2>&1 first and grepping for Subject: to catch rejectiong
<cjwatson> rejections
<iwj> mconnor: Each time we take a new upstream, we do a merge, essentially.  Patches that have gone upstream turn into conflicts and we double-check that it's all gone right and throw away our diffs.
<ogra> cjwatson, ouch, ok, i used to have netkit-inetd ....
<ogra> hmm
<iwj> Sometimes we do something equivalent which is a bit less painful.
<cjwatson> ogra: what's it used for?
<ogra> actually it is seeded it seems
<iwj> mconnor: Here `upstream' refers both to you and to Debian.
<ogra> ogra@edubuntu:~$ apt-cache show netkit-inetd|grep -i task
<ogra> Task: edubuntu-server
<ogra> cjwatson, tftp
<mconnor> yeah, that complicates things, since their changes always seem opaque until I make Mike Hommey mad enough to explain...
<iwj> mconnor: Anything that hasn't gone upstream, we keep.  Debian do the same.
<Riddell> ubuntu seeds don't seem to have inetd in them except in server-ship
<ogra> hmm, i wonder where it got that task entry from ... its not specifically seeded
<mconnor> and if those aren't "security" patches, is that still ok?
<iwj> mconnor: In theory all of the relevant info should be in the debian/changelog but perhaps not always in the kind of detail you're looking for.
<cjwatson> ogra: ltsp-server depends on netkit-inetd
<cjwatson> ogra: so your server installs should be fine ...
<ogra> ah, right
<ogra> well, it isnt, unless ... hmm, wait
<mconnor> iwj: its hard to tell what's in the current patchset when a lot of the changelog talks about bugs we've fixed upstream
<ogra> tftpd-hpa complains about missing update-inetd ...
* ogra checks netkit-inetd
<cjwatson> that's in the update-inetd package now
<ogra> argh, who makes such silly decisions ....
<cjwatson> I'm not absolutely sure what's going on with that split; you may need to do some research into Debian changes
<ogra> a package for a single script ?
<cjwatson> don't assume it's silly until you've looked into it
<cjwatson> it's separated because it should be used for multiple inetd
<cjwatson> s
<cjwatson> at least that's my understanding of it
<ogra> indeed ... but still ... its not *that* big
<cjwatson> please don't have such knee-jerk reactions
<iwj> mconnor: Yes.  The changelog of the Debian version contains the complete history of the package as seen from Debian.
<cjwatson> I very much doubt that it was split due to size
<ogra> cjwatson, i'll try to hold back in the future ... 
<iwj> mconnor: Our changelogs are a bit different - we have a new policy of recording all of the differences between us and Debian in one entry at the top of the changelog, although lots of stuff may still be duplicated below.
<mconnor> iwj: this is why I like the set of patches approach, since that makes it easier to track and understand the changes (and also to throw stuff away once its no longer needed :))
<keescook> jdong: pong
<ogra> cjwatson, new ltsp in the queue, please approve ...
<pitti> Mithrandir: \o/ ppc/alternate success
<jdong> keescook: bug 71941 seems to imply dapper/universe's heartbeat-2 has an outstanding security vulnerability?
<Ubugtu> Malone bug 71941 in heartbeat-2 "Request heartbeat-2 upgrade to recommended 2.0.7" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71941
<ogra> cjwatson, new ltsp in the queue, please approve ...
<cjwatson> ogra: freeze exceptions -> Mithrandir
<ogra> oki
<Mithrandir> pitti: yay!
<ogra> Mithrandir, ?? 
<Mithrandir> ogra: so you need that + respin of install CDs?
<ogra> yep
<keescook> jdong: yeah, I saw that but hadn't investigated.  have you looked into it by any chance?
<ogra> sorry for no spotting that split earlier ...
<ogra> on the other hand live CDs are all fine
<Mithrandir> ogra: ok; I'll accept it and turn the publisher back on auto since I'm going over to som friends's soonish
<mconnor> iwj: so, backing up for a second, what about the patches from Red Hat to fix pango+mathML, are those going to be a problem?
<ogra> Mithrandir, ok, i'll build the final iso myself then ... no prob
<jdong> keescook: no, not yet, I was thinking you were the security expert :D
<Mithrandir> ogra: anyway, ltsp accepted now.
<ogra> thanks
<keescook> jdong: hehe.  a quick look through their changelog or version announcements will usually say something.  Since it's in universe, it's not too high up on my todo list at the moment
<cjwatson> doko: could you please edit the description of bug 68396 to include a short impact description (i.e. a one-sentence or so description of how each thing you've fixed affects users), and edit debian/changelog of your update to refer to bug 68396? Also mention the parallel build fix in debian/changelog
<Ubugtu> Malone bug 68396 in openoffice.org "openoffice.org for edgy-updates" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68396
<pitti> oh, this update-inetd problem seems to affect ubuntu as well, I cannot configure postfix
<cjwatson> doko: is sd.sal_uInt32_aslong.diff the fix for the amd64 crash?
<Mithrandir> ogra: ogra ok, manual publisher run going now, you'll have one in a little less than an hour.
<ogra> great, ta
<jhasse> How do games edit the highscore files if the files belong to root and can't be edited by others???
<cjwatson> doko: I think you probably only need to mention bug 62432 and not the other duplicates of it in debian/changelog
<Ubugtu> Malone bug 62432 in openoffice.org "Crash when copying text from OpenOffice to other applications" [Unknown,Fix released]  http://launchpad.net/bugs/62432
<cjwatson> doko: other than that, I'm happy with this; when you've corrected the above, attach an updated debdiff to the bug, and go ahead and upload
<cjwatson> thanks
<ogra> jhasse, the files are usually owned by the games group
<iwj> mconnor: I haven't looked at them, I'm afraid, so I don't know.  It doesn't sound harmful offhand :-).
<iwj> mconnor: Usually we take a fairly conservative approach to patches just because we don't want to diverge too much - so we only take a patch from another distro, or cross-ported from another branch, if we're pretty sure we really want it.
* ogra is afk until ltsp is done ...
<mconnor> iwj: hopefully this is one-time pain, at least, since we want to avoid having a bunch of subtle differences in how web content displays
<cr3> just to make sure, I need to build my own boot image to preseed a netinstall, right?
<cr3> oups, that question should've been asked in #ubuntu-installer. nevermind :)
<spike> hi
<lguerra> hi all, 
<spike> using preseeding "d-ipartman-auto/diskstring /dev/discs/disc0/disc" works fine for most of our boxes
<spike> but then we've got this HP servers, with a compaq smart array and for them it doesnt
<seb128> hum
<spike> on the installe dsystem disks show up as /dev/cciss/c0d0p1, where cciss is the compaq thingie
<seb128> I've upload a new upstream version of a package
<seb128> and then a new revision
<spike> but I cant find what I'm supposed topass to preseed to get that working
<seb128> and it did "Unable to find glade-3_3.1.2.orig.tar.gz in the distribution."
<seb128> is that due to the freeze?
<seb128> like the tarball is not published?
<seb128> should I upload the tarball again? or wait for after the freeze to upload?
<pitti> seb128: right, I got the same
<pitti> seb128: I guess you should just wait for unfreeze and stack the uploads somewhere
<seb128> grumpf
<seb128> well, yeah
<seb128> do we unfreeze soon? :p
<pitti> seb128: stacking might be a good idea anyway; I have the feeling that if you upload the same version twice, the newer one overwrites the older upload instead of being rejected
<seb128> it's start being tricky to get work done
<pitti> so I won't know if any of my uploads have been killed by an upload from someone else
<seb128> between sources not available to work on top from, things that can't be uploaded
<seb128> arg
<seb128> that would be bad
<seb128> yeah, will do that
<keescook> zul: have you seen bug 71789?  This sounds like a reasonable change to the package, but I haven't played too much with xen to know.
<Ubugtu> Malone bug 71789 in xen-3.0 "xend has open port" [Undecided,Confirmed]  http://launchpad.net/bugs/71789
* pitti grabs the gettext merge in doko's absence, since it's kind of urgent
<seb128> pitti: be careful, maybe doko already did and upload it ;)
<zul> keescook: ill have a look
<keescook> zul: cool, thanks.
<pitti> seb128: hmm, maybe
* iwj finally gets to burn a non-coaster.
<cjwatson> spike: see what parted_devices prints
<cjwatson> seb128: uploading the second one with -sa should work
<seb128> cjwatson: ok, thank you
<cjwatson> pitti: even if that soyuz bug still exists, at minimum you'll see both uploads in -changes, so you'll know
<cjwatson> but I think now one will get rejected on accept
<cjwatson> (not guaranteed)
<seb128> do you think that herd-1 will be ready soon?
<cjwatson> yes, Tollef said he was planning to do it tonight
<cjwatson> always assuming there are no *more* unexpected roadblocks
<seb128> does it make sense to keep the freeze that long? herd-2 is planned for soon, we should maybe drop on herd-1
<seb128> ok
<cjwatson> yes, it makes sense
<cjwatson> we need to get a milestone out, desperately
<seb128> well, that one is really early in the cycle
<seb128> but right
<cjwatson> yes, there's always one as soon as the installer is ready
<cjwatson> we need that
<cjwatson> you might not, but I do :)
<seb128> right
<seb128> we need to figure a way to not freeze for a week next time though
<cjwatson> I don't hear about new installer problems until awkwardly late otherwise
<cjwatson> I don't really think there's much to figure out - I think we just made a mistake in freezing before it had been basically confirmed to work
<cjwatson> (to some degree)
<seb128> ok
<seb128> I'm trying to read what's going on the chan but it's not real clear to me why it's taking that long
<LaserJock> cjwatson: do you have the script that produces http://people.ubuntu.com/~cjwatson/testing/feisty_probs.html available somewhere?
<cjwatson> seb128: none of the images worked? :P
<seb128> I'll let you guys do your job and keep working where I'm not blocked by the freeze
<cjwatson> also nobody who's off EU-ish timezones has been working on it, so we've only had 10 or so hours per day basically
<cjwatson> having somebody in a different timezone would help
<seb128> right
<cjwatson> however, the desktop CDs are ready now, I believe - it's just a matter of fixing alternates
<seb128> good to know :)
<Riddell> cjwatson: what's wrong with alternates?
<seb128> almost there then ;)
<cjwatson> Riddell: we ran into a germinate bug that meant that bittorrent wasn't installable (it didn't understand "Depends: python (>= 2.5) | python2.5") and therefore gnome-btdownload wasn't uninstallable; didn't affect Kubuntu
<Riddell> oh yes, not my worry
<cjwatson> Tollef has already respun all affected images
<cjwatson> so anyone who cares about the freeze being over and can easily do so, please test
<ajmitch> morning
<cjwatson> (we're not doing a full test matrix for the first milestone)
<pitti> cjwatson: for the record, ppc/alternate worked fine
<pitti> shall I do amd64, too?
<cjwatson> pitti: if you have time, yes please
<cjwatson> although you should enjoy your evening at some point
<pitti> oh, girlfriend is at accordion concert rehearsal, that's fine :-p
<pitti> I'll do amd64 then, but I can't do i386 (not enough bandwidth)
<cjwatson> I'm doing i386 in vmware
<cjwatson> only regression from edgy I've noticed so far is that the new automatic partitioner no longer skips the scary manual partitioning screen
<pitti> hm, I did manual on ppc, so I didn't notice
<cjwatson> which doesn't surprise me really, as that was a very complicated merge
<pitti> I'm going to do automatic 'wipe all' for amd64
<pitti> cjwatson: only major thing I noticed was the absence of update-inetd
<pitti> but that only affects things post-install
<ogra> well, it affected edubuntu and ltsp
<ogra> and i really wonder why its not a dep of netkit-inetd ...
<pitti> ogra: you fixed it in edubuntu?
<pitti> added a dep to it somewhere, or just sticked it into -standard?
<ogra> well, i made ltsp-server depend on it, since ltsp requires tftpd to be run by inetd in our setup
<cjwatson> ogra: I think it not being a dependency of netkit-inetd is a bug
<ogra> right
<pitti> automatic keyboard detecting is screwed (considers my US layout as JP), but oh well...
<pitti> IIRC that was already discussed with smurf, right?
<cjwatson> mind you, netkit-inetd doesn't actually use update-inetd itself
<ajmitch> doko: want me to upload ironpython 1.0.1 to experimental? I haven't started on it yet
<cjwatson> so maybe it is not a bug
<cjwatson> it depends on what's actually failing
<ogra> cjwatson, thats why i choose to make ltsp-server depend on it
<ogra> you cant make tftpd-hpa make depend on it either, since that can also run standalone
<pitti> cjwatson: I noticed that postfix failed to install, so maybe postfix itself should depend on update-inetd
<cjwatson> one alternative would be switching to openbsd-inetd, since that depends on update-inetd
<cjwatson> and then netbase would pull it in
<ogra> does it behave any different to netkit-inetd ? i never tried it 
<cjwatson> we could also just make our netbase depend on update-inetd for a while
<pitti> hmm, seems that vmware install of the alternate is busted, it doesn't detect a drive
<cjwatson> pitti: yeah, you have to use an IDE disk, it's a kernel bug
<cjwatson> scsi-modules is incomplete
<cjwatson> ogra: it's supposed to be better ...
<pitti> ok, maybe I better do this on real hw then
<cjwatson> vmware IDE disk works ifne
<cjwatson> fine
<pitti> see you later, then, rebooting
<ogra> then i'll try it for ltsp 
<cjwatson> pitti: keyboard detection> yes, known, not a showstopper
<pitti> argh, need to burn first :)
<ogra> i think i read somewhere about netkit-inetd being abandoned by debian after etch, but i may be wrong
<cjwatson> I believe that's right
<cjwatson> openbsd-inetd is netbase's preferred alternative in Debian
<ogra> so the best time to switch then :)
<cjwatson> ok, I think I see the partman-auto bug, but I'll test that later
<sfllaw> cjwatson: Is mvo's synaptic package sitting in NEW for edgy-proposed?
<sfllaw> Bug 65553.
<Ubugtu> Malone bug 65553 in synaptic "Synaptic Crashes when changing fonts" [Medium,In progress]  http://launchpad.net/bugs/65553
<cjwatson> sfllaw: no, it's in unapproved
<sfllaw> cjwatson: Thanks.
<cjwatson> that bug should become fix committed when it's accepted
<cjwatson>   113267 | S- | synaptic             | 0.57.11ubuntu12.1    | five weeks
<cjwatson>          | * synaptic/0.57.11ubuntu12.1 Component: main Section: admin
<cjwatson>   137106 | S- | synaptic             | 0.57.11ubuntu12.1    | seven days
<cjwatson>          | * synaptic/0.57.11ubuntu12.1 Component: main Section: admin
* pitti toddles off to dinner while the test install runs
<Riddell> cjwatson: about setting the language for KDM during install (bug 35573), is that a ubiquity or a casper issue?
<Ubugtu> Malone bug 35573 in kdebase "No localizations available" [Medium,Needs info]  http://launchpad.net/bugs/35573
<pitti> hi zyga 
<mdke> cjwatson: ok, thanks. I'll do a bug report
<Riddell> Mithrandir: I need to go out now, but all Kubuntu CDs are good to release for Herd
<dade`> desrt: are you busy ?
<pitti> Mithrandir, cjwatson: amd64/alternate worked, by and large
<ogra> Mithrandir, cjwatson, edubuntu live/install amd64 and ppc are good (i386 running)
<cjwatson> Riddell: (a) localechooser (b) ubiquity
<cjwatson> (i.e. two bug tasks)
<cjwatson> Riddell: actually, no
<cjwatson> Riddell: just localechooser
<cjwatson> it's still annoying that that requires separate configuration rather than using /etc/default/locale or some such
<cjwatson> Riddell: so actually if it's at all possible I would far rather that kdm be changed to use the existing places that the system locale is set
<cjwatson> the same was suggested in https://launchpad.net/distros/ubuntu/+source/kdebase/+bug/35573/comments/8, although since then /etc/default/locale has become the preferred location for this stuff (it's still in /etc/environment too)
<Ubugtu> Malone bug 35573 in kdebase "No localizations available" [Medium,Needs info]  
<cjwatson> Mithrandir: Ubuntu i386 alternate looks OK
<cjwatson> modulo previously-discussed bugs
<ogra>  /dev/hda4 has gone 49710 days without being checked, check forced.
<ogra> o_O
<tsmithe> that's more than i've been alive!
<tsmithe> by a lot!
<Lure> ogra: nice uptime ;-)
<ogra> heh
<ogra> actually thats a fresh feisty install booting ...
<jhasse> ogra, but i am not in the games group, how can they modify the file then?
<pitti> jhasse: most games are setgid games
<jhasse> pitti, how does that work?
<pitti> jhasse: you don't know setuid/setgid file permission bits?
<jhasse> pitti, no sry
<pitti> jhasse: man chmod explains a bit
<jhasse> pitti, ah! I always wondered what the 0 before 0777 stand for...
<jhasse> pitti, How can i make visible the bits set of a certain file?
<pitti> jhasse: do 'ls -l /usr/games' and watch for yourself :)
<jhasse> pitti, okay thx
<pitti> jhasse: ls -l /usr/bin/passwd for the suid root case
<jhasse> pitti, is there a way to display it in number like 2755 ?
<pitti> jhasse: stat works at least
<jhasse> pitti, k thx
<ogra> Mithrandir, cjwatson, from an edubuntu perspective the freeze can end, all arches in all flavours are fine here ...
* keescook uses new-found powers to upload vino for -updates & happy SRU action.
<jdub> fisty becomes awesome!
<jdub> $ sudo apt-get upgrade -u
<jdub> Segmentation fault (core dumped)
<Robot101> closed fist? :)
<Arador> those are the little things that make life fun
<ajmitch> jdub: I believe mvo has a patch for it
<ajmitch> not sure if it was uploaded, in unapproved, etc
<fdoving> hmm.. as per https://wiki.ubuntu.com/StableReleaseUpdates step 5, 'Make sure to generate .changes against the base version in the relevant distribution and not against the version in -proposed or a previous version in -updates.' - does that mean 'edit the -proposed changelog entry' leaving the -proposed entry out, in the package that hits -updates?
<ajmitch> bug 73062
<Ubugtu> Malone bug 73062 in apt "[feisty]  apt and aptitude crashing" [High,Confirmed]  http://launchpad.net/bugs/73062
<keescook> fdoving: I didn't interpret it that way, but I've only done one SRU (and it's waiting to be put into -updates)
<fdoving> keescook: Did you add a new changelog entry with -updates info? In the example bug, cpio, that was done. -> https://launchpad.net/distros/ubuntu/+source/cpio/+bug/59228
<Ubugtu> Malone bug 59228 in cpio "cpio build glitch breaks Unicode char handling" [Unknown,Fix released]  
<keescook> fdoving: yeah, bumped the version and pocket, and I duplicated the prior changelog entry, and added a line about who tested it.
<Mithrandir> cjwatson: yay!
<Mithrandir> ogra: excellent.
<Mithrandir> Riddell: are you happy with Kubuntu?
<keescook> fdoving: but again, beware.  we could both be wrong.  :)
* pitti holds his breath for Mithrandir's next step
<Lure> Mithrandir: [20:50]  <Riddell> Mithrandir: I need to go out now, but all Kubuntu CDs are good to release for Herd
<Mithrandir> Lure: oh, thanks.
<psusi> Keybuk: ping
<Mithrandir> pitti: it'd be to write the announcement, post it, unfreeze, flush the queues, go partying.
<Keybuk> psusi: hi
<fdoving> keescook: I choose to blindly trust you. :)
<keescook> fdoving: heh
<psusi> Keybuk: hiya... are you actively working on the various specifictions for make udev play nice with xxxx?
<pitti> fdoving: if in doubt, don't kill changelog entries; they can't hurt
<Keybuk> psusi: no
<Keybuk> not currently
<psusi> is anyone else? ;)
<Keybuk> not that I'm aware of
<psusi> doh
<Keybuk> I believe iwj may be looking at udev-lvm
<psusi> well I might take a crack at it
<Keybuk> it's still very early in the feisty cycle
<psusi> oh it is?
<psusi> good
<jdong> psusi: I saw that you eventually did patch e2defrag
<jdong> psusi: how confident are you that it works :)
<psusi> jdong: hehe... yea ;)
<fdoving> pitti: it's just that the step-by-step guide at https://wiki.ubuntu.com/StableReleaseUpdates (step 5.3) says I should generate the .changes against the base version in the distro. Is that point obsolete? is it easier for archive admins to review changes if i do this properly as described at that wiki? 
<psusi> jdong: highly confidant... I stress tested it quite a bit
<jdong> cool
<jdong> I'll play with my external then
<psusi> and fixed several bugs
<pitti> fdoving: I guess this alludes to the usage of -v on debuild, i. e. include all relevant changelogs
<psusi> I stressed it good on both ext2 and ext3
<psusi> created under dapper and edgy ( they have different mkfs with different default options, the edgy one uncovered another bug or two )
<psusi> Keybuk: I was wondering why you talk about having udev create the dm device in the spec wiki page?
<fdoving> pitti: ok. keep all changelog entries and use debuild with -v, thanks :)
<Keybuk> psusi: the spec outlines the reasons for that
<Keybuk> if udev doesn't create it, then we have a race condition
<Keybuk> we can't use udev rules and events to use that device
<psusi> Keybuk: as far as I can see, we want udev to respond to the underlying physical devices by probing them and calling the correct utility to set up the device mapper... I see no reason to continue having that utility create the dev node
<Keybuk> which means we won't be able to mount it
<psusi> why do we want any udev rules at all for the virtual device?
<Keybuk> to mount it
<Keybuk> root=/dev/mapper/...
<psusi> sorry, no reason NOT to coninue having the utility create the dev node
<Keybuk> or /dev/mapper/... in fstab
<Keybuk> that won't work unless udev can reliably hang on those
<psusi> how so?  it's the init script that needs to wait for the /dev/mapper/* to be created
<psusi> udev can make sure that happens by responding to the underlying physical device with a scan and dmsetup
<Keybuk> psusi: BZZT
<jdong> psusi: ooh, pretty :)
<Keybuk> init script?
<Keybuk> what's one of those?
<psusi> the init script in the root of the inintramfs
<Keybuk> do you mean an upstart task, which is run as a result of a udev event? :)
<psusi> the one that processes the root= kernel command line parameter
<Keybuk> dmsetup doesn't work
<psusi> doesn't work?
<Keybuk> not for this
<psusi> substitute the correct utility that configures device mapper
<psusi> such as dmraid, or vgchange
<Keybuk> and how do we know when the /dev/mapper/... device is ready?
<psusi> the important thing is that when the underlying device(s) are detected, udev configures the device mapper
<psusi> it is ready when it has been created
<Keybuk> *sigh*
<Keybuk> you've completely missed the point of these specs
<psusi> is the point not to get rid of the horrible local-top scripts and their race conditions?
<Keybuk> no
<Keybuk> the point is to get rid of ALL of the race conditions
<jdong> psusi: if e2defrag is violently interrupted, it's not atomic right? (i.e. I'm gonna end up with a paperweight)
<Keybuk> not just in the initramfs
<psusi> well, yea
<psusi> and to make the system fully plug and play
<Keybuk> so in fstab we have /dev/mapper/wibble
<psusi> i.e. you can plug in a pair of usb disks at run time with an lvm volume on them and it will be recognized and mounted
<Keybuk> yes
<Keybuk> and in those lvm volumes you could have a crypted filesystem that is decrypted and mounted, forming part of another lvm block
<Keybuk> yada yada yada
<psusi> right
<psusi> ohhh
<psusi> ok... I wasn't thinking of the nested case
<psusi> although... still that could be handled in the event handers for the real hardware still
<Keybuk> to be honest, you weren't thinking of the non-nested case either
<Keybuk> to mount /dev/mapper/FOO you need to *know* when /dev/mapper/FOO has been created
<Keybuk> which means you need something watching for it
<Keybuk> this is inefficient
<psusi> ohhhh... ok... I was just thinking about the device creation, not about also mounting it
<Keybuk> udev gets uevents for device-mapper block devices anyway
<Keybuk> so we may as well use those events to create the /dev/mapper/FOO device
<Keybuk> and then we can use the same events to mount the device
<Keybuk> etc.
<psusi> right.... now I see a problem though
<psusi> how do you know what to name it?  vgchange knows what it wants to name it, but when udev gets the event, it only knows it as dm-0
<Keybuk> the spec answers that question
<Keybuk> the kernel knows what name device-mapper has assigned to it
<Keybuk> so udev can know too
<Keybuk> and udev can pass *that* name on to things like HAL
<psusi> wait a second... why can't udev just mount it while handling the underlying physical device insertion event?
<psusi> afaik, the kernel only knows the name 'dm-0'
<Mithrandir> psusi: dmsetup table lists the other name, doesn't it?
<psusi> hrm....
<psusi> maybe the kernel does know it... strange that it still uses the name dm-0 in sysfs
<lexi_> hmm... just learned there is an initialramfs inside the ubuntu-kernel  (at least for 686). what is it for and could one use a copy of it as initrd in /boot ?
<psusi> anyhow... here is how I see the chain of events:  disk1 is plugged in... udev scans this disk to see if it is lvm... if it is, but needs disk2, nothing is done yet
<psusi> disk2 is plugged in... udev scans disk2, and finds that it now has both disks for the vg.... sets up the vg and configures the dm devices to access the volumes, then mounts them
<Keybuk> yes...
<Keybuk> actually, it's far easier
<Keybuk> udev scans disk-1, sees its lvm, runs vmblah (which does nothing as its not complete)
<Keybuk> udev scans disk-2, sees its lvm, runs vmblah (which constructs the map)
<Keybuk> udev sees dm-0 being created, creates /dev/mapper/VG-LV
<Keybuk> udev sees /dev/mapper/VG-LV being created, mounts it
<Lure> Keybuk: s/vmblah/vgchange -a y/ ;-)
<psusi> what's wrong with doing it all in response to the first event instead of splitting the mounting part off into the response to the dm device being created?
<Keybuk> more complicated
<Keybuk> you have to write the same code 10 times
<psusi> 10 times?
<Keybuk> once for normal disks, once for device maps, once for lvm, once for evms, once for raid, etc.
<Keybuk> if you write them as little pieces that stack, you only need to do it once
<psusi> hrm.... well, I guess it is conceptually a little nicer to let udev handle the recursion
<psusi> driven by the dm events
<psusi> instead of scripting it
<Keybuk> much nicer
<Keybuk> and a lot less error prone
<Keybuk> the thing about scripts is that they're racey
<Keybuk> oops, damn, that device wasn't actually *ready* yet, etc.
<psusi> I'm thinking though that the kernel side needs patching to use the given name isntead of the default name
<Keybuk> why?
<psusi> I think the given name can be stored and retrieved via ioctls right now, but sysfs and thus udev are only told dm-0
<Keybuk> the kernel names sysfs objects with an enumerated number
<Keybuk> this is consistent
<psusi> hrm... just seems odd to have it use a generic name when it knows the correct one
<Keybuk> the object should contain a sysfs property with the name, yes
<Keybuk> but it's easy enough to find out until it does
<psusi> ok... I guess that's alright... then udev just needs to look up the proper name and use that to create the dev node
<Keybuk> yes
<Keybuk> just like the spec says
<jdong> Keybuk: could we have that udev max_sectors rule that I need now?
<Keybuk> jdong: maybe
<Keybuk> (the rule's wrong, btw :P)
<jdong> Keybuk: as you well know I know nothing about udev
<jdong> I just did something that worked after 5 tries
<Keybuk> for feisty, it should be:
<psusi> hehe... also need to do the checks in response to md devices so you can support lvm over md ;)
<Keybuk>   SUBSYSTEM=="block", SUBSYSTEMS=="scsi", ATTRS{vendor}=="RockChip", ATTR{max_sectors}="128"
<Keybuk> or similar
<lifeless> Keybuk: btw, look at pyrex for doing bindings
<lifeless> its slick
<Keybuk> psusi: that would be that udev-mdadm spec
<Keybuk> lifeless: for landscape?
<jdong> Keybuk: ok. does that work in Feisty?
<Keybuk> jdong: never tested it, but it should
<jdong> Keybuk: I tried something similar to that in Edgy and ATTR{max_sectors} did not actually set max_sectors
<lifeless> or rctypes, but thats not as slick at the moment IMO
<lifeless> Keybuk: for libupstart
<psusi> well, I might just dig back into the libdevmapper code to take care of that part, then handle the dmraid case
<lifeless> I'd like python bindings in and of themselves :)
<Keybuk> lifeless: yeah, I have no clue at this point how to do bindings
<jdong> ok, psusi, you're not on my hitlist. e2defrag worked
<Keybuk> jdong: that behaviour is new in feisty
<psusi> by the way.... these udev rules and their helper scripts should go in the dmraid/lvm/whatever package not the udev package right?
<lifeless> I'll mail you a couple of files
<jdong> Keybuk: ah, ok, cool
<Keybuk> psusi: right
<jdong> Keybuk: so can we have it? <g>
<psusi> jdong: lol, yay ;)
<Keybuk> jdong: if you test it
<psusi> jdong: now if only I could get it to build on ia64, sparc, and ppc ;)
<jdong> psusi: btw what's the verdict on what happens if e2defrag is interrupted?
<jdong> psusi: I'm guessing bad idea
<cjwatson> fdoving: pitti's interpretation is correct; I've edited the wiki page to clarify
<psusi> jdong: yea... very bad idea
<lifeless> Keybuk: are you familiar with setup.py for python programs ?
<jdong> psusi:  :)
<Keybuk> lifeless: yes
<lifeless> ok
<jdong> psusi: then I won't use it for any serious things\
<jdong> psusi: hence why I still prefer my hackjob copy-move defragger :D
<psusi> jdong: get a UPS ;)
<jdong> psusi: a UPS isn't the catch-all answer ya know ;-)
<fdoving> cjwatson: great. thanks :)
<psusi> I'm also amayzed at how fast that little defragger is... it is very smart
<jdong> psusi: unless it has a built in 9mm pistol for my cat
<jdong> (kidding)
<allee> Hi, I'm trying to hunt down a regression in dapper: usbsticks can be mounted via hal anymore.  hal --verbose showed that hal-system-storage-mount was not found. Copying the script from Edgy solved it.   Where I'm stuck is that all hal version in dapper did not contain this script and the fdi files in all dapper hal pkgs list the script.  But it did work before.  Any hint how to continue nailing down what's wrong?
<pitti> allee: the storage scripts have been explicitly removed from Debian
<pitti> allee: erk, s/debian/dapper/
<pitti> allee: and we introduced them in edgy
<pitti> allee: there were no such scripts in breezy
<fdoving> cjwatson: your edit is also true for step 5 i presume? (i can edit that step, if you ack)
<pitti> allee: that wasn't an accidental regression, but an explicit design decision
<jdong> psusi: e2defrag's script is reasonably speedy
<jdong> psusi: though that's a longer achilles heel than I ever want handling my important data
<allee> pitti: interesting. And how did USB stick mounting work in dapper?  I know it worked today before I dist-upgraded a dapper system not updated since 24-Okt?
<allee> s/?/!/
<lifeless> Keybuk: mail sent
<lifeless> Keybuk: it should be obvious enough to bootstrap you - its a binding to readdir()
<psusi> well, it isn't a script, but yea... the algorithm is nice and quick
<Keybuk> lifeless: converting C idioms into Python is the interesting bit for me
<Keybuk> e.g. how do I make sure that when a python object is freed, I can free the C memory
<jdong> Keybuk: object=None
<lifeless> Keybuk: right. you implement __del__
<jdong> actually, that only strongly hints that it should disappear
<jdong> :)
<Keybuk> upstart obviously uses a hierarchical allocator, which may make things more interesting
<lifeless> Keybuk: thats the only hook you have to run code on object free. 
<lifeless> Keybuk: talloc ?
<Keybuk> no, nih_alloc
<lifeless> !
<allee> pitti: ah, clarification regession is not breezy -> dapper but dapper -> dapper dist-upgrade to get latest sec fixes
<Keybuk> (which I originally wrote during tridge's talk <g>
<lifeless> Keybuk: how does it differ to talloc, so I can make suggestions
<pitti> allee: no, security updates definitively didn't disable storage scripts; they have been removed in dapper final
<Keybuk> lifeless: much, much simpler
<pitti> allee: they might have been present in dapper beta or so
#ubuntu-devel 2006-12-06
<Kano> hi, how did you parse the UUIDs
<Kano> in the fstab
<jdong> vol_id $device | sed -ne (just kidding)
<jdong> actually that would probably work
<Kano> thanks it would
<Keybuk> vol_id -u $device
<jdong> that works too
<Keybuk> (that's how we got them *into* the fstab)
<jdong> sheesh Keybuk why doesn't dpkg-parsechangelog have flags like that!
<Keybuk> jdong: it does
<jdong> really?
<jdong> for just printing the version?
<jdong> nope it doesn't :(
<jdong> oh well, good old sed...
<Keybuk> hmm, maybe it doesn't
<Keybuk> Kano: mount can accept UUID=... directly
<Keybuk> quest scott% sudo mount UUID=43DB-3ADE /mnt
<Keybuk> quest scott% 
<jdong> Kano: are you the Kanotix guy by any chance?
<jdong> Keybuk: and doesn't /dev/disk/by-uuid/$uuid exist?
<Keybuk> jdong: yes
<Kano> jdong: i am
<jdong> cool honor to meet you. Love kanotix :)
<Kano> why do you have it twice in udev + volumeid package
<Keybuk> Kano: have what twice?
<Kano> vol_id
<Keybuk> we don't
<Keybuk> it's only in volumeid
<Kano> i diffed it
<Kano> same tool at /lib/udev/vol_id
<Keybuk> lrwxrwxrwx 1 root root 12 2006-10-17 17:54 /lib/udev/vol_id -> /sbin/vol_id*
<Keybuk> it's a symlink ;)
<Kano> hmm ok, on debian there is no symlink
<Keybuk> yes
<Keybuk> Debian and Ubuntu have entirely different udev packages
<Kano> only at the lib position, so a script should not use it
<Kano> i found some errors directly when i installed ubuntu ;)
<Kano> or better kubuntu
<Keybuk> oh?
<Kano> just counting em ;)
<Kano> streamtuner for example needs xmms dependency and streamripper suggest
<Kano> and it is in main, no excuse possible ;)
<Keybuk> oh, I thought you meant errors in udev
<Kano> no not in udev
<Keybuk> *shrug* there's always bugs
<Keybuk> file them in LP
<Kano> sure, but i know this bug is ubuntu specific
<jdong> Kano: kanotix is moving to a kubuntu/ubuntu base, right?
<Kano> jdong: depends
<Kano> when the error count of ubuntu is low enough, or say lower than etch
<Keybuk> streamtuner isn't in main
<Kano> well maybe universe main
<Keybuk> no such thing as univers main
<Keybuk> main = supported
<Keybuk> universe = community maintained
<Kano> kanotix has a differnet package selection
<Keybuk> streamtuner doesn't appear to need an xmms dependency?
<Kano> well you can configure it differently
<Keybuk> it suggests it already
<Keybuk> arguably that should be a recommends
<Keybuk> anyhoo, file a bug
<Keybuk> or, reopen 46124
<Kano> well i collect em and put em on my homepage when i am done ;)
<Keybuk> put them in Malone, please
<Keybuk> otherwise our developers won't be able to process them properly
<Kano> will look into it
<Kano> just not now, as this is only minor
<Kano> the default homepage of firefox is not available in kubuntu
<Kano> how is the screen res detected?
<Riddell> Kano: should be, except for localised pages, that's a known bug
<Kano> of course i installed it for germany
<Riddell> mm, yes, not sure how to fix that, altough I'll need to ponder it
<Kano> also in the contact module
<Riddell> font DPI is set in /etc/init.d/kde-guidance if that's what you were asking
<jdong> Kano: dpkg-reconfigure xserver-xorg is used
<Kano> jdong: no i mean something like xresprobe
<Riddell> Kano: if you have any kubuntu specific questions feel free to join us in #kubuntu-devel any time (although I'm off to bed now)
<Keybuk> we use xresprobe
<Kano> there is no manpage
<Kano> what is the driver needed
<Riddell> would be cool to have kanotix using Kubuntu, I'd be interested to hear what the issues are
<Kano> Riddell: be sure i find many ;)
<Kano> Riddell: for vfat for example is the default fstab line not optimal
<Kano> maybe utf8 is short for iocharset=utf8,but then you still miss: shortname=mixed,quiet
<Kano> Riddell: did you think of adding ntfs-3g support to pmount
<Kano> same options are needed for pmount of course
<Kano> like when you mount it with the fstab you are getting errors with media:/
<Kano> i found a pcitable file in guidance
<Kano> do you really use it
<Kano> maybe leftover ;)
<Kano> bye for now
<spike> cjwatson: I will try tomorrow. thanks
<cjwatson> fdoving: good point, fixed
<ajmitch> cjwatson: do you have the britney config you use to get the list of uninstallable packages for main? I'd like to check it for universe on a regular basis
<cjwatson> ajmitch: it takes an amount of time I've never determined to run it for universe, but certainly in excess of 6 hours on beefy hardware
<cjwatson> are you sure? :)
<ajmitch> sure
<ajmitch> I've got beefy hardware at home
<ajmitch> I know it's ram-hungry
<cjwatson> ajmitch: ok, well it's http://people.ubuntu.com/~cjwatson/tmp/britney-archive.diff on top of http://people.ubuntu.com/~cjwatson/bzr/britney/cdimage/
<cjwatson> few random other changes in there - the trees aren't very clean I'm afraid
<ajmitch> great, thanks
<twb> Mithrandir: ping?
<twb> Mithrandir: I'm gonna take a crack at integrating Debian's casper changes; I've got nothing else to do.
<bronson> Is anyone working on linux-vserver for Feisty?
<bronson> I remember seeing some discussion on this but I don't see anything in the wiki.
<siretart> bronson: I know some ppl who are using linux-vserver with ubuntu dapper and edgy, but they use custom kernels.
<twb> Are there Ubuntu equivalents of the Debian New Maintainer and Policy manuals?
<Burgundavia> twb: what specifically are you looking for?
<twb> Well, I'm already a Debian developer.  I'm not familiar with creating and maintaining packages for Ubuntu.
<Burgundavia> right
<Burgundavia> are there Ubuntu specific things you want to do to your packages?
<twb> I don't know.
<Burgundavia> basically, the easiest course is to maintain those packages in Debian and they will get autosynced to Ubuntu
<twb> Burgundavia: that assumes that someone from Ubuntu (other than me) wants those packages in Ubuntu.
<Burgundavia> what specific packages are they?
<twb> I currently maintain paredit-el and mg in Debian.
<twb> I mean, I don't even know what the process is that determines if/when/how Debian packages become Ubuntu packages.
<twb> That is the sort of information I would expect to find in the newmaint and policy manuals.
<Burgundavia> right
<Burgundavia> Ubuntu takes nearly everything from Debian and simply rebuilds it
<Burgundavia> http://www.ubuntu.com/ubuntu/relationship <-- this is a good doc
<twb> Similarly, when an Ubuntu user reports a bug (via Ubuntu's reporting process), what is the process whereby it gets pushed to me, the Debian maintainer?
<Burgundavia> http://www.ubuntu.com/ubuntu/components
<Burgundavia> as it that
<twb> Looking...
<Burgundavia> there is no formal method of getting bugs from Ubuntu to Debian, currently
<twb> Is there a committee or working group currently investigating such issues?
<Burgundavia> https://wiki.ubuntu.com/DCT
<lucas> Burgundavia: no.
<lucas> DCT has been dead for months, because nobody is really interested in it
<Burgundavia> lucas: ?
<Burgundavia> ah, yes
<lucas> it's a bit easy to point to it each time a DD asks about feeding bugs back to debian
<Burgundavia> lucas: the problem is mostly time
<siretart> twb: you might find https://wiki.ubuntu.com/DeveloperResources useful
<twb> typo, http://www.ubuntu.com/ubuntu/licensing, first paragraph "and by default" should be "and be installed by default"
<minghua> twb: please report a bug against ubuntu-website: https://bugs.launchpad.net/products/ubuntu-website/+filebug
<minghua> twb: thanks
<twb> OK.
<twb> If someone duploads an Ubuntu package which has (closes Malone #NNNNNN) or similar in the ChangeLog, does Malone automatically know about that and mark the bug as done in that version?
<minghua> twb: I think right now it doesn't.  I heard there are discussions and thing may change soon though.
<Mithrandir> twb: no, but it's a planned feature.
<twb> launchpad isn't letting me complete my registration
<twb> It keeps taking me back to the same page.
<twb> Does it require javascript?
<Burgundavia> quite likely
<twb> Ugh.
<twb> You like locking out blind people?
<mdke> twb: take it to #launchpad
<twb> OK.
<mdke> be a bit nicer though, constructive suggestions work better than sarcasm
<twb> Sorry.
<twb> I get frustrated by `web apps' easily.
<mdke> np, they are a friendly bunch and will listen
<bronson> twb: if so, then lauchpad itself will frustrate you deeply.
<bronson> at least, it does me.  :)
<twb> bronson: yes.
<twb> bronson: once I actually manage to login, I intend to drop the web ui in favour of GPG signed mail.
<mdke> friendly bunch though, told you
<mdke> :)
<HiddenWolf> mdke: "Oh my god, no, what have we done?" ;)
<Mithrandir> crimsun: hi dude, how did the Xubuntu testing go yesterday?
<siretart> twb: malone offers an email interface, so you can report and manipulate bugs via gpg signed mail
<bronson> Is there any way to get a 2.6.18 version of the Ubuntu kernel?  Or did BenC go straight from .17 to .19?
<twb> siretart: right, but I need to login at least once via the web ui to enable the mail UI.
<bronson> I'd like a 2.6.18 so I can apply a recent linux-vserver patch.
<Mithrandir> bronson: there's no 2.6.18 version, no.
<bronson> Is anyone talking about packaging linux-vserver anymore?
<bronson> I'm wondering how much effort I should put into making generic, Feisty-ready packages.
<crimsun> Mithrandir: I haven't tested i386 beyond 20061204 daily, but I'll pull down i386 20061205 daily-live and daily now
<crimsun> Mithrandir: the ppc & amd64 testers are likely asleep atm
<Mithrandir> crimsun: cheers.
<Mithrandir> crimsun: slackers. :-P
<Mithrandir> crimsun: any idea when they'll be around?
<Mithrandir> hi Andreas
<bronson> Hm...  Guess I'll go straight to 2.6.19.  How exciting.  :)
<bronson> Mithrandir: thanks
<Mithrandir> hmm, publishing herd-1 as herd-1 and not knot-3 is probably a good idea..
<Mithrandir> (history ftw)
<Burgundavia> Mithrandir: are we about to go live? shall I move it over to the website?
<crimsun> Mithrandir: found an amd64 & ppc 20061205 daily-live tester
<Mithrandir> Burgundavia: yes, please.
<Burgundavia> moving
<Mithrandir> Burgundavia: can you do the kubuntu one too or should I chase down a kubuntu person for that?
<Mithrandir> crimsun: yay, excellent.
<Burgundavia> Mithrandir: I don't have access to the Kubuntu website
<Mithrandir> Burgundavia: ok.
<Burgundavia> for the Knot pages, they were just left on the wiki
<Mithrandir> Riddell: do you want the herd 1 page to be moved to the main kubuntu website or is it ok to have it on the wiki?
<Riddell> Mithrandir: wiki is fine
<Mithrandir> Riddell: ok
<Riddell> but I should check it for sanity first, what's the URL?
<pitti> Good morning
<Mithrandir> Riddell: https://wiki.kubuntu.org/FeistyFawn/Herd1/Kubuntu
<Mithrandir> at least that was the one I found
<Riddell> that's the one
<Mithrandir> http://err.no/tmp/herd-1.txt is the announcement ; proofreading would be nice.
<Mithrandir> (yes, the ubuntu URL will then need changing)
<Burgundavia> Mithrandir: should probably link directly to https://www-master.ubuntu.com/testing/herd1
<Mithrandir> s/-master// ?
<seb128> Mithrandir: you can mention GNOME 2.17.2 too to the "The primary changes from Edgy"
<Burgundavia> "We refer to..."
<Mithrandir> seb128: I moved that bit from the announcement to the wiki page; do you disagree about that?
<Burgundavia> well, I need to sleep
<Burgundavia> page is up and /testing links to /testing/herd1
<seb128> Mithrandir: no, that's fine with me. You mentioned 2.6.19 in the mail so I didn't notice you did that ;)
<Mithrandir> seb128: yeah, since it's common between all variants.
<Mithrandir> Burgundavia: cheers.
<seb128> right
* pitti grr's at new kernel breaking nvidia even more
* seb128 grrr's at the new kernel breaking his network after some time
<Riddell> Mithrandir: announcement reads good to me
<dholbach> good morning
<pitti> hi dholbach 
* dade` grr's at the new kernel not letting sleep his macbook
<dholbach> hi pitti
<ajmitch> morning dholbach 
<dholbach> hey ajmitch
<sivang> morning
<dholbach> doko: good morning - we had a question about eclipse over here: https://lists.ubuntu.com/archives/ubuntu-motu/2006-December/001000.html
<cjwatson> Mithrandir: all the current CD images should already have hw-detect/start_pcmcia=false, shouldn't they?
<Mithrandir> cjwatson: oh, I didn't see a response to whether you fixed that or not.
<cjwatson> I did. I'll check that they've all been rebuilt
<Mithrandir> cjwatson: if it's there, I'll just add a note saying that pcmcia is disabled.
<Mithrandir> cjwatson: Kubuntu might not have picked it up, since we didn't do the last rebuild for those.
<cjwatson> right, my thought too, also Xubuntu
<doko> dholbach: you can't use uupdate with a zip file
<Mithrandir> cjwatson: ok, expanded a little bit now.  Looks better?
<cjwatson> Mithrandir: Xubuntu isn't fixed, but all the others are, including Kubuntu
<cjwatson> Mithrandir: so s/Ubuntu and Edubuntu/Ubuntu, Kubuntu, and Edubuntu/ but otherwise fine
<cjwatson> is the read-from-wrong-terminal thing new in feisty? what changed?
<dholbach> doko: I passed on the message
<cjwatson> Mithrandir: otherwise all looks fine
<Mithrandir> cjwatson: updated the first one.
<cjwatson> Mithrandir: s/We refer/Please refer/ maybe
<Mithrandir> cjwatson: the casper thing is some weird usplash/upstart interaction.  I'm going to just make casper use the input mechanism in usplash, but I just haven't had time.
<Mithrandir> cjwatson: fixed.
<cjwatson> it's always weird reading your announcements. I can see the bits that were descended from announcements I wrote. :)
<Mithrandir> heh, yeah, it's a cut&paste job from the earlier ones.
<cjwatson> s/The herd images/The Herd images/?
<Mithrandir> sure, fixed
<Mithrandir> the URLs need checking too, but that doesn't happen until I do sync-mirrors
<doko> cjwatson: updated the changelog and description of bug 68396 and uploaded to edgy-proposed. yes, sd.sal_uInt32_aslong.diff the is the fix for the amd64 crash
<Ubugtu> Malone bug 68396 in openoffice.org "openoffice.org for edgy-updates" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68396
<Mithrandir> doko: I presume you saw the sun-java5 build failure on ppc?
<cjwatson> doko: thanks, looks better, will process this morning
<doko> Mithrandir: yes, do you want to port it to powerpc? ;)
<Mithrandir> doko: no, but it should probably be PaS-ed
<Mithrandir> maswan: can you give us a cdimage mirroring run when I ask for it?
<maswan> Mithrandir: sure
<doko> Mithrandir: agreed, then on sparc and hppa as well
<sivang> mjg59: is there anything we do to shutdown idle wlan network interfaces by default?
<sivang> Riddell: I managed to get Belhaven St. Andrew's Ale around here, some private dude that periodically visits the UK and scotland in particular started to import small quantities just for the love of it. There's also a "Scottish Ale" by Belhaven which I didn't taste yet. 
<Riddell> excellent!
<sivang> Riddell: sure is, apparently there's few folks around the north and center of the country then know about it (among them is that importer dude) ;)
<ailean> Belhaven Best is a tasty beer
<sivang> Riddell: right, I need to call him and suggest he'll bring some Best(s) as well
<ailean> Riddell, can i ask you a couple of qs about becoming linux certified?
<ailean> Riddell, i know you're in scotland too, so i was wondering about where to go to learn it and where to go to take the exam
<maxb> Hi. There is a bug filed against apache2 in launchpad with a fairly thorough analysis of the problem, such that it should not be difficult to fix, but the maintainer does not seem to have noticed. What is the best way for me to politely attract the attention of someone who could fix the package? Thanks.   ( the bug is https://launchpad.net/bugs/62748 )
<Ubugtu> Malone bug 62748 in subversion "2.0.55-4ubuntu4 update causes svn failure" [Undecided,Confirmed]  
<Riddell> ailean: #kubuntu better
<ailean> ok
<Mithrandir> maxb: it'll be fixed when apache 2 is upgraded to 2.2
<Ubugtu> Apache bug 2 in Layout "Just testing the Boogzeela setup for log4j" [Normal,Closed: fixed]  http://issues.apache.org/bugzilla/show_bug.cgi?id=2
* Mithrandir kicks Ubugtu 
<pitti> haha
<pitti> Mithrandir: just for the record, apache2 is currently on my merge list, but infinity asked me not to merge 2.2 ATM
<maxb> Well... ok... but it renders libsvn-javahl unusable, so any chance of it being considered for an edgy-update? And if not, could there be an official comment in the bug explaining the situation?
<spike> cjwatson: hi, you around by any chance?
<spike> I had a look into that parted_devices
<spike> unfortunately it's not very helpful, as it just prints the device as in fdsik, /dev/cciss/c0d0 146807930880    Compaq Smart Array
<spike> I'm running it on the installed system, dunno if that makes any difference, tho
<spike> cjwatson: can I just use that /dev/cciss/c0d0 in the preseed file?
<cjwatson> spike: that was the point of getting you to run parted_devices, and why it is helpful. the device names it prints are what you can preseed
<cjwatson> so yes
<cjwatson> would be better to run it in the installer, but it *should* be the same in edgy
<cjwatson> if this is dapper, then you should definitely run it in an interactive installer session to check
<spike> yeah, it's dapper
<spike> cjwatson: can I run the install manully without preseeding, and then choose to drop to a shell? will be the command available via busybox?
<doko> cjwatson: do you know the origin of the gfxboot patch for syslinux?
<cjwatson> spike: alt-f2 gives you a shell (alt-f1 to return); yes, the command will be available
<cjwatson> doko: suse
<doko> cjwatson: do you have an URL for their packages?
<cjwatson> doko: afraid not, I don't seem to have kept it
<spike> cjwatson: ok, cheers. btw, the device will be different anyway, and I dont wanna dup all my preseed file just for those bunch of boxes. I read there are means to include custom bits at runtime, not quite sure what's the right way to do it
<spike> can I just run something with the early_command and the outpu will be included into the preseed file?
<cjwatson> not as such
<cjwatson> there are some related possibilities
<crimsun> Mithrandir: i386 daily fails pretty badly on my hardware (either can't detect atapi cdrom or partitioner fails), but daily-live works fine (both clean install and resizing ntfs)
<cjwatson> spike: you could try something like this in an early_command:
<cjwatson> . /usr/share/debconf/confmodule
<Mithrandir> crimsun: hmm, ok.  Do you want me to drop Xubuntu for herd 1 or respin?  I don't want to hold up the others any longer.
<cjwatson> db_set partman-auto/disk "$(parted_devices | head -n1 | cut -f1)"
<crimsun> Mithrandir: no need to block on xubuntu
<cjwatson> i.e. use first disk no matter what. might need to be careful to exclude floppies and CDs there
<Mithrandir> crimsun: ok, I'll drop it for Herd 1 and wish you better luck next time around, then.
<crimsun> Mithrandir: ok, thanks
<admin123> :)
<Mithrandir> maswan: please sync now.
<maswan> Mithrandir: running
<twb> On my launchpad `homepage', is it appropriate to include a link to my CV?
<pitti> twb: I don't see why not, it's the place for personal information after all (disclaimer: purely my personal opinion)
<twb> That was my expectation.  Some organizations have vehement views about linking to such stuff.
<shackan>  why?
<twb> I guess because its the thin end of the wedge that link-bombing wiki pages is the thick end of.
<sivang> Keybuk: morning
<Keybuk> hey
<sivang> Keybuk: I wonder if you had seen my bug report already, or you need to grab your coffe before checking out ifupdown and possibly related to upstart bugs ;)
<Keybuk> I just read it
<Keybuk> almost certainly kernel
<sivang> Keybuk: okay, so how can we work this out? I'm using 2.6.19-7-lowlatency that crimsun tells me still doesn't really include the pre-empt "fix"
<sivang> Keybuk: (I tried to use the lowlate kerns due to http://sivang.blogspot.com/2006/12/surely-not-way-to-do-performance.html)
<Keybuk> sivang: no idea
<Keybuk> find out when it broke
<sivang> Keybuk: sure, how do I debug something like that?
<Keybuk> sivang: the usual way
<Keybuk> find out how to make it fail consistently
<Keybuk> find out how to make it work consistently
<Keybuk> bisect the difference
<sivang> Keybuk: that's easy, everytime I ifup eth1, it just shuts down the power, consistently :)
<sivang> Keybuk: to make it work, I just ifdown eth1, and dhclient eth1
<sivang> Keybuk: ;)
<Keybuk> ifdown and dhclient ?!
<Keybuk> Now, since about a couple of upgrades, ifupdown seems to have gone mad
<Keybuk> completely:
<Keybuk> -- 
<popey> is there a method for proposing a package for inclusion on the live/alternate CD?
<Keybuk> so find out which upgrade broke it
<sivang> Keybuk: eh :)
<Keybuk> that's a quote from your bug
<Keybuk> you say something broke it
<Keybuk> what broke it?
<StevenK> If the breakage shutdowns the machine, it's a little hard to diagnose, no?
<sivang> Keybuk: If I had known, I would have been a miilionaire :p
<Keybuk> sivang: find out then
<Keybuk> you have /var/log/dpkg.log
<Keybuk> roll back each upgrade until you find the one that makes it work again
<Keybuk> try stock ubuntu kernels
<sivang> Keybuk: I'l see what I can come up with, or just write  a script that probes for DNS and when it can't resolve do the ifdown, dhclient dance for me automatically :)
<Keybuk> if you do that, I'll reject the bug
<sivang> Keybuk: okay, thakns for the guidance
<sivang> Keybuk: that was a joke , seriously
<Keybuk> this is obviously not happening for anyone else
<Keybuk> there's a lot of ipw2200 users out there
<Keybuk> so it must be something you've installed on your machine, or some change you've made, that's caused it to break
<Keybuk> check for scripts in /etc/network/*
<Keybuk> also try booting into windows
<Keybuk> the card might be wedged in some invalid state that only the windows driver can fix
<Keybuk> I don't know if that affects the ipw2200 specifically, but it's a common fix for firmware cards
<sivang> Keybuk: could it be the hardware just broke?
<Keybuk> yes
<sivang> Keybuk: (it works in windows quite fine, although I've had a couple of simialr mishaps there as well)
<Keybuk> ok, if it works in windows, and continues to not work in Linux; I'd suggest the following
<Keybuk> - install stock ubuntu kernel (not the low-latency one)
<Keybuk> - check /etc/network/* for problems
<Keybuk> - check packages are all up to date, and not from other sources
<Keybuk> - is it just "ifup" that breaks?  what about "ifconfig eth1 up" ?
<mnepton> - how about invoke-rc.d network restart
<sivang> mnepton: that's like doing /etc/init.d/network restart no?
<spike> cjwatson: where's the limit with that? cant I just run a shell script I wget from somewhere that will set all the answers I need?
<mnepton> sivang: it is
<cjwatson> spike: sure, that's possible too, noting that early_command only runs after the preseed file has been fetched of course
<mnepton> except you should use invoke-rc.d these days)
<cjwatson> spike: depends on your personal tolerance for maintainability of twisty little piles of shell scripts
<spike> cjwatson: "after the preseed file has been fetched of course", uhm, does that mean I cant modify the answers at that time? ie, from a completely external script
<spike> or couldnt I just wget some script that would rewrite the preseed file, ie, replace variables/placeholders based on the hw/machine
<Keybuk> mnepton: that's a bogus command
<Keybuk> a) you should not use invoke-rc.d; that's for maintainer scripts only
<spike> cjwatson: the idea idea I had was generating the preseed file on the fly, so wget actually calls a cgi that dumps a preseed file run-time generated based on the ip
<Keybuk> b) the network init script isn't what starts hardware network interfaces anyway
<sivang> Keybuk: no luck, the only thing that manages to bring power up on the interface is ifdown eth1
<Keybuk> sivang: does ifconfig eth1 down bring power up?
<cjwatson> spike: there's an example of doing this in the installation-guide, under preseed/include_command; see there
<spike> nmmh, k, ta
<StevenK> cjwatson: Should I remind you at some further point to please accept the wlassistant upload to edgy-updates?
<cjwatson> by "after the preseed file has been fetched", I simply meant the stage of the installer; your preseed file could just be early_command or whatever and nothing else
<cjwatson> StevenK: no need
<sivang> Keybuk: strangely, no
<Mithrandir> maswan: it seems the world is a bit slow now and I really want to release and we're apparently fine when it comes to bandwidth, so I'll drop ACC from the herd 1 announce this time.
<Keybuk> sivang: ok, then it's likely a script in /etc/network/*; what do you have in there?
<Keybuk> and what's in /etc/network/interfaces ?
<cjwatson> spike: note that preseed files are basically just fed to debconf-set-selections. You can do the same thing either in the same way or by using debconf commands directly. If you want to do funky stuff, apt-get source preseed and see how it does it.
<StevenK> cjwatson: Okay, I'll continue to exercise patience. Thanks. :-)
<\sh> Mithrandir: do we have a good traffic report for dapper and edgy for mirrors? I would like to try to setup an official mirror here in our company
<Mithrandir> \sh: ask mirrors@ubuntu.com
<StevenK> \sh: What arches?
<elmo> (the answer is no we don't.  it varies from mirror to mirror.  a traffic report would be non-sensical)
<\sh> StevenK: all
<StevenK> \sh: And source?
<sivang> Keybuk: /me checks
<\sh> StevenK: 10GBit/s needs some action
<StevenK> \sh: Oh, I thought you were talking size.
<Znarl> \sh : Can you join #ubuntu-mirrors and we'll help you setup a mirror, if you like.
<\sh> StevenK: oh I think I can host the complete source/binary collection of debian/ubuntu/redhat/suse on one machine ;) 7TB as Raid6 is enough on one machine? if not I use 3 or 4 of them ;)
<StevenK> \sh: Bastard. :-P
<Mithrandir> \sh: if you have the bandwidth and disk space, cdimage mirrors are always useful.
<\sh> Znarl: sure, but I need some infos about traffic, bandwidth, what you need as lowest level bandwidth etc. to give it to my managers...to decide...the rest will be easy then :)
<Mithrandir> (it's only close to 1T, but still)
<\sh> Mithrandir: shouldn't be a problem with space...not even bandwidth...I just need an ok of my managers :)
<\sh> and right now it's a good time to ask for it :)
<Znarl> \sh : You're in the US?  So your mirror will be listed under United States?
<\sh> Znarl: germany...with decix peering...and officially 20GBit/s level 3 connection...europes finest private datacenter
<fernando> \sh: i can to have a ssh access in this poor machine/bandwidth/storage? heheheh :P
<Znarl> \sh : A full mirror of releases.ubuntu.com is just under 30gigs.  archive.ubuntu.com is around 190gigs and slowly growing.
<fernando> s/i\ can/can\ i/
<dade`> why do you escape spaces ?
<fernando> i need to review my machine/bandwidth concepts hehehe
<StevenK> dade`: Because he isn't quoting it.
* ..[topic/#ubuntu-devel:Mithrandir] : Development of Ubuntu (not support, even with feisty) | #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 1 released
* bhale hugs Mithrandir 
<StevenK> Mithrandir: Nice! Well done.
<Mithrandir> yay us! :-)
<highvoltage> Ubuntu GNU/Herd 1 :)
<HiddenWolf> congrats
<highvoltage> they beat FSF to it!
<sivang> highvoltage: hehe
<bhale> didnt we have a Herd animal before?
<doko> cjwatson: updated syslinux. I would appreciate a review before upload to feisty: http://people.ubuntu.com/~doko/syslinux/
* Starting logfile irclogs/ubuntu-devel.log
* pitti hugs Mithrandir for Herd 1
<pitti> wow, ubuntu-changes spam \o/
<ajmitch> yay!
<spike> cjwatson: /bin/sh: parted_devices: not found , using BusyBox v1.01 (Debian 1:1.01-4ubuntu3) Built-in shell (ash)
<spike> booting dapper amd64 ubuntu-installer
<cjwatson> doko: meep, um, I'm buried in libparted right now, later
<cjwatson> doko: please try a modified Ubuntu CD with your version of syslinux on it to make sure that gfxboot works
<jdub> open("/var/cache/apt/pkgcache.bin", O_RDONLY) = 5
<jdub> fcntl64(5, F_SETFD, FD_CLOEXEC)         = 0
<jdub> fstat64(5, {st_mode=S_IFREG|0644, st_size=9749120, ...}) = 0
<jdub> mmap2(NULL, 9749120, PROT_READ, MAP_SHARED, 5, 0) = 0xb7246000
<jdub> stat64("/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_feisty_main_binary-i386_Packages", {st_mode=S_IFREG|0644, st_size=5684810, ...}) = 0
<jdub> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
<jdub> 
<cjwatson> spike: continue through the installer a bit before running it
<StevenK> jdub: Neat.
<jdub> $ sudo apt-get upgrade -u
<jdub> Segmentation fault (core dumped)
<jdub> 
<cjwatson> spike: it won't be available right at the start. this is normal.
<jdub> ^ awesomo 4000!
<seb128> could anybody give a retry to yelp on all arches?
<spike> cjwatson: oh, I see, thanks.
<StevenK> jdub: Now you have a core file, you can use pitti's leet debug debs to figure it out.
<sivang> jdub: heh
<StevenK> Oh no, qdvdauthor, you will not do this to me.
<StevenK> Sigh. qdvdauthor's upstream, *please* learn to reap your children when you get a SIGCHLD!
<seb128> jdub: does removing /var/cache/apt/*.bin fix it?
<dholbach> jdub: try moving away pkgcache.bin - I think mvo is aware of the problem
<seb128> dholbach: too slow young padawan :p
<jdub> haha
<dholbach> pfft
<seb128> ;)
<gnomefreak> seb128: yes it fixes it he uploaded a fix for it
<Treenaks> The Dynamic Duo Strikes Again :)
<jdub> seb128, dholbach: rock on, thanks :-)
<dholbach> :)
<seb128> np
<seb128> jdub: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=81829 for info
<Ubugtu> Debian bug 81829 in apt "segfaults" [Grave,Open]  
<gnomefreak> seb128: libapt-front_0.3.9ubuntu4 should fix the apt crashing
<seb128> gnomefreak: I don't have a such lib installed
<gnomefreak> he uploaded it this morning sometime according to the bug report
<gnomefreak> bug 61708
<Ubugtu> Malone bug 61708 in apt "apt-index-watcher corrupts the apt cache database" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61708
<seb128> gnomefreak: it looks like that change prevent the corruption for apt-index-watcher
<seb128> gnomefreak: it doesn't fix apt crashing when the index is corrupted
<seb128> gnomefreak: apt is not using libapt-front
<gnomefreak> the index is corrupting apt/cache
<maswan> Mithrandir: *nods*
<sivang> Keybuk: do we have anything to reduce power consupmtion when a NIC is inactive that could come in the way?
<Keybuk> sivang: only the driver
<Keybuk> that I know of, anyway
* sivang wonders if this functionality can be turned off
<sivang> Keybuk: is it reasonable for a straying wpa key specificed to the interfaces file to cause the odd ifdown to bring NIC power up symptom?
* sivang guesses that it isn't
<Keybuk> no
<Keybuk> could be wpa supplicant bug
<sivang> hmm, I wonder if I could just remove wpa supplicant and leave without it, oh it's part of -minimal
<cjwatson> doko: I wish you'd stuck with the applied-patches scheme I was using
<maswan> Mithrandir: I don't quite know why it is slow, but it is updating
<cjwatson> dpatch--
<Keybuk> cjwatson: applied-patches hurts my brain
<Keybuk> I never remember to update them
<cjwatson> it's better than dpatch
<doko> cjwatson: then please show me where upstream has the single patches. the srpm only has one diff.
<cjwatson> doko: please make sure that you carried over my patches
<doko> I didn't convert to dpatch, that was the debian maintainer
<cjwatson> ah, if they did that then I guess we have to :-(
<cjwatson> IIRC I had to extract it from the suse diff
<Keybuk> cjwatson: I dislike dpatch more than the next man, but at least there's a script to deal with it
<Keybuk> I don't need to fiddle with applying and unapplying, just dpatch-edit-patch
<cjwatson> *shrug* it's moot in this case if the packaging's already changed in Debian; I hadn't realised that
<\sh> Mithrandir:congrats to the herd 1 release :)
<Mithrandir> thanks. :-)
<sladen> the FSF will be pleased
<sladen> they've been waiting 20years for that
<cjwatson> doko: you seem to have discarded my DATE/HEXDATE fix and my fix to ensure the screen gets cleared when switching back to text mode on localboot
<cjwatson> (3.11-2ubuntu5)
<cjwatson> and 3.11-2ubuntu4
<doko> cjwatson: do you still know what exactly to remove from the suse diff?
<cjwatson> not offhand
<Keybuk> Mithrandir: you misspelled "Hurd" in the announcement
<cjwatson> doko: sorry, afraid it requires actual thought ;-)
<Mithrandir> Keybuk: I considered using "The Hurd, or the GNU Hurd, is the set of servers, it is not an operating system, and since it runs in user space, it is not what we call a kernel. ``Hurd'' means ``Hird of Unix-Replacing Daemons'' and ``Hird'' means ``Hurd of Interfaces Representing Depth'', but all of them are spelled like the word ``herd'', which is the real meaning of this name: the GNU Hurd is a herd of gnus." as the quote..
<\sh> argl...launchpad fools me
<Keybuk> The launchpad strikes!  You feel fooled!
<\sh> http://bugs.launchpad.net/distros/ubuntu/feisty/+source/xdrawchem doesn't show any open bugs to this source..but http://b.l.n/distros/ubuntu/+source/xdrawchem/+bugs shows open bugs...that's definitly a user fooling experience ;)
<fbond> keybuk: ping
<\sh> or we have to change the "file sync request bug reports" a bit, to include the release
<Keybuk> fbond: hi
<fbond> Keybuk, hi
<fbond> I am supposed to contact you Re: mounting usbfs by default
<fbond> https://bugs.launchpad.net/distros/ubuntu/+bug/70968
<Ubugtu> Malone bug 70968 in Ubuntu "Ubuntu Should Automatically Mount usbfs At Boot Time" [Wishlist,Needs info]  
<Keybuk> usbfs is mounted by default
<Keybuk> quest scott% ls /proc/bus/usb
<Keybuk> 001/  002/  devices@
<Keybuk> admittedly, that's not usbfs, but a gross hack
<Keybuk> but the gross hack should be sufficient for your needs
<fbond> hmm.  My knowledge may not be technical enough in this area to argue the case well.
<Keybuk> what's the problem?
<Keybuk> perhaps we can work out from there
<fbond> I have packaged midisport-firmware for universe.
<doko> cjwatson: suse has integrated your two patches
<Keybuk> ok ...
<fbond> This package uses libusb and udev to load firmware onto the USB device.
<Keybuk> this uses /proc/bus/usb/XXX/YYY to load the firmware?
<Keybuk> right
<fbond> The current situation doesn't seem to be conducive to this approach...
<Keybuk> which current situation?
<fbond> Edgy
<Keybuk> edgy should be fine
<Keybuk> assuming you're using the release
<Keybuk> may I see the package?  is it in the archive?
<fbond> Keybuk, it didn't quite make it into edgy
<Keybuk> is it in feisty?
<fbond> let me see if it's lying around on revu or elsewhere ...
<fbond> crimsun had suggested I bring this up with you.  He knows more technical details related to the problem.
<Keybuk> I suspect crimsun's knowledge is out of date
<fbond> http://revu.tauware.de/details.py?upid=3063
<fbond> Perhaps.
<Keybuk> we implemented a udev-driven /proc/bus/usb for edgy
<fbond> Well, my device does eventually work, if I do one of the following after booting: unplug and re-plug the device or restart udev
<Keybuk> have you mounted usbfs yourself by hand?
<cjwatson> doko: I checked, and that did not appear to be the case.
<cjwatson> doko: unless you mean in a patch that wasn't in the source package you posted
<cjwatson> in which case, great
<fbond> Keybuk, I had done that before, but am not currently.
<Keybuk> fbond: is there anything in /proc/bus/usb
<fbond> yes
<Keybuk> is /proc/bus/usb/devices a symlink?
<cjwatson> \sh: the release should only be used when backporting fixes for bugs to earlier releases
<Keybuk> oh, I see
<fbond> Keybuk, yes
<Keybuk> the udev rules in the orig.tar.gz are COMPLETELY wrong
<Keybuk> that's why it doesn't
<Keybuk> work
<fbond> oh
<cjwatson> \sh: so no, the sync policy should stay as it is
<fbond> interesting
<Keybuk> totally, and utterly bogus
<Keybuk> they should like something like
<doko> * Mon Jan 23 2006 - snwint@suse.de
<doko> - cjwatson@ubuntu.com: support big-endian cpio archives (#140119)
<doko> - support direct driverupdate loading from CD-ROM (feat #152):
<doko>   o initrd loading errors are no longer fatal
<doko>   o if initrd name starts with '+' ask for CD change
<doko> * Wed Dec 14 2005 - snwint@suse.de
<doko> - really disable text messages
<doko> - cjwatson@ubuntu.com: turn off graphics for localboot
<doko> which is in the diff
<Keybuk> ACTION=="add", SUBSYSTEM=="usb_device", SYSFS{idVendor}=="0763", SYSFS{idProduct}=="1001", RUN+="@fxload@ -s @firmwaredir@/MidiSportLoader.ihx -I @firmwaredir@/MidiSport2x2.ihx"
<Keybuk> note the use of the usb_device subsystem, not the usb subsystem (which means you can drop the devpath match)
<Keybuk> that way the RUN rule will be run *after* the device appears in /proc/bus/usb -- rather than before
<Keybuk> <g>
<fbond> Hmm.  Upstream has not been terribly friendly to me, unfortunately.  I do not know if this will forward well.
<fbond> But, at least, I can get this into Feisty in working order.
<Keybuk> udev is still in heavy development
<Keybuk> so what rules work for one distribution, with one version of udev, will likely not work on another
<fbond> I see.
<cjwatson> doko: I checked the diff you posted, and it was definitely missing the DATE/HEXDATE fix, and it looked to me as if it at least did not have all of the localboot fix
<Keybuk> changing the SUBSYSTEM is the key here
<fbond> udev remains to be grey magic to many of us who consider ourselves pretty familiar with Linux systems.
<Keybuk> the "usb" subsystem is responsible for the device itself, and whatever interfaces it exposes
<Keybuk> it doesn't have anything in /dev usually
<Keybuk> the "usb_device" subsystem is responsible for the raw access devices
<Keybuk> you want the raw access devices, so you want that subsystem
<fbond> Is there a good source of information that covers this kind of topic?
<StevenK> fbond: That's because it is. The kernel sends a bunch of strings to a userspace program that just does stuff, based on rules that look somewhat evil. Complete magic.
<Keybuk> StevenK: bah, it's easy
<Keybuk> fbond: lots
<fbond> StevenK, well I ain't afraid of a little magic :)  Documented magic would be nice though.
<cjwatson> doko: they only applied an earlier version of my change, not the whole thing. Please check again.
<Keybuk> start at the udev manpages and documentation
<fbond> alright, I can do that.
<Keybuk> e.g. man udev, and /usr/share/doc/udev/writing_udev_rules/
<StevenK> The manual pages are incredibly terse, from what I recall.
<fbond> thanks very much for your help, Keybuk.
<Keybuk> also look through the kernel documentation on sysfs
<cjwatson> and unless they did something else to avoid the need for this:
<cjwatson>   * Makefile: Just export DATE and HEXDATE rather than playing with $(MAKE);
<cjwatson>     current make applies an extra shell evaluation pass to the latter
<cjwatson> ... it's still relevant
<cjwatson>     approach and so fails.
<Keybuk> fbond: no problem
<StevenK> Maybe I'm just turned off by Marco d'Annoyi^WItri saying "This udev stuff is so important and hard! *snap* *bite*"
<Keybuk> bah
<Keybuk> it's important, yes
<Keybuk> really damned useful
<Keybuk> but not hard
<StevenK> Keybuk: Stop saying bah, Scrooge. :-P
<Keybuk> Every driver, device, interface, etc. in the kernel has a structure of information about it
<Keybuk> it chains those structures up in a pretty tree which it exposes in /sys
<Keybuk> and whenever it adds or removes items, it sends a message out so userspace can react
<fbond> Well, I like udev in principle.  I don't think anyone dislikes the goals of udev.
<Keybuk> udev listens to those messages, and uses them to maintain /dev, and run other programs, etc.
<Keybuk> it's obviously important that you listen to the right messages, and use the right information
<Keybuk> unfortunately that's the poorly documented bit, because it's kernel stuff, and they're notoriously bad at it :p
<StevenK> I recall Herbert Xu somewhat not liking udev, since he didn't see the huge problem of a static /dev in the normal use cases.
<StevenK> But Herbert is strange like that. :-)
<Keybuk> the advantage and disadvantage of a static /dev is pretty much swings and roundabouts
<mjg59> Well, if you never hotplug anything, there's no real problem with a static /dev
<Keybuk> certainly having mknod run for you if you're missing a device is useful
<StevenK> Or if all the devices you hotplug already have /dev nodes.
<Keybuk> the principal advantage of udev is that, once you know you *have* the /dev node, you can do other things
<Mithrandir> having an /etc which actually reflects your system is nice too.
<Mithrandir> makes tab completion and such so much easier.
<cjwatson> you mean a /dev?
<Mithrandir> uh, yes.
<StevenK> Heh
<mjg59> StevenK: Device ordering isn't guaranteed
* StevenK waits for Mithrandir to annouce uetc
<Keybuk> the other useful side-effect of a dynamic /dev is that we can name things statically
<Keybuk> you can't guarantee which disk is sda, and which is sdb
<StevenK> mjg59: That's a good point.
<jdub> Spads: thanks re: ubuntu world wide
<Keybuk> but you can use udev to examine the disks, and give us /dev/disk/by-uuid
<mjg59> StevenK: So if you want specific permissions with a static /dev, you *still* need something like udev
<Keybuk> imagine having /proc/bus/usb as a "static device tree"
<Spads> jdub: no problem
<Keybuk> you'd need /proc/bus/usb/000 thru 999/000 thru 999
<Keybuk> lots and lots of notes
<Keybuk> uh, nodes
<Mithrandir> StevenK: I'm a bit unsure what uetc wouduld do..
<Mithrandir> would, even
<Spads> jdub: I notice that the terminator doesn't shift because it's not regenerating if there's no cache miss
<ajmitch> Mithrandir: I don't think you'd want to know..
<StevenK> Mithrandir: :-P
<ajmitch> sounds like another wild idea of StevenK's :)
<Mithrandir> ajmitch: if I were to write it, I'd surely want to know what it would do..
<StevenK> Oh, I don't have wild ideas.
<Mithrandir> I have some nice ideas and some really insane ones.
<Keybuk> /Programs
<Mithrandir> Keybuk: no, that's just crack. :-P
<Keybuk> /Users/Scott James Remnant/Configuration/Upstart
<Keybuk> /Users/Scott James Remnant/Desktop
* StevenK twitches.
<Keybuk> /Users/Scott James Remnant/Documents
<StevenK> Why the Mac OS X layout....
* thom dunks keybuk in acid
<Keybuk> acciiiiiiiiiiiiid
<pitti> hey thom, how's it going?
<thom> i have just defeated d-i, so it's going well. how about you?
<fbond> Keybuk: little help?
<Keybuk> fbond: ?
<fbond> ENV{PRODUCT}=="763/1014/*" -> SYSFS{idVendor}=="0763", SYSFS{idProduct}=="1001"
* StevenK kicks qdvdauthor hard. Don't touch my sound settings, you stupid program.
<fbond> ENV{PRODUCT}=="763/1031/121" -> ?
<fbond> what do I do with the 121?
<Keybuk> ENV{PRODUCT}=="763/1014/*" -> SYSFS{idVendor}=="0763", SYSFS{idProduct}=="1014"
<Keybuk> :p
<fbond> um, right
<fbond> copied the wrong line :)
* Keybuk is trying to remember what the 121 is
<fbond> question stands, however ... 
* fbond can't do it if Keybuk can't
<Keybuk>         if (add_uevent_var(envp, num_envp, &i,
<Keybuk>                            buffer, buffer_size, &length,
<Keybuk>                            "PRODUCT=%x/%x/%x",
<Keybuk>                            le16_to_cpu(usb_dev->descriptor.idVendor),
<Keybuk>                            le16_to_cpu(usb_dev->descriptor.idProduct),
<Keybuk>                            le16_to_cpu(usb_dev->descriptor.bcdDevice)))
<Keybuk> ok
<fbond> oh right
<fbond> "documentation"
<Keybuk> best kind there is <g>
<fbond> :)
* StevenK tries to expand bcdDevice
<fbond> bcdDevice -> SYSFS{bcdDevice} ?
<Keybuk> ENV{PRODUCT}=="763/1031/121" -> SYSFS{idVendor}=="0763", SYSFS{idProduct}=="1031", SYSFS{bcdDevice}=="0121"
<fbond> ok, thanks!
<Keybuk> on feisty, you'd need to use ATTRS{...}==
<StevenK> Binary Coded Decimal Device .... Hrm, doesn't sound right.
<Keybuk> StevenK: version number
<Keybuk> ie. 1.21 :p
<fbond> hmm.
<StevenK> How does bcd == Version ? :-P
<Keybuk> OMG ... I can recall pieces of the USB spec; I am doomed
<Keybuk> StevenK: version numbers are usually encoded in bcd because hardware people are strange
<fbond> Hopefully the feisty documentation has been updated to reflect that change?
<Keybuk> fbond: yes
<StevenK> Oh, right.
<fbond> Keybuk, in feisty, udev rules are completely different, i.e. don't have all those SYSFS{...} bits?
<jdub> Setting up sun-java5-plugin (1.5.0-10-0ubuntu1) ...
<jdub> update-alternatives: unable to make /usr/lib/iceweasel/plugins/libjavaplugin.so.dpkg-tmp a symlink to /etc/alternatives/iceweasel-javaplugin.so: No such file or directory
<StevenK> jdub: Known. I think ....
<Keybuk> fbond: in feisty, you need to change the word "SYSFS" to the word "ATTRS"
<Keybuk> ATTRS{idVendor}=="0763", ATTRS{idProduct}=="1031", ATTRS{bcdDevice}=="0121"
<Keybuk> ^ like that
<fbond> oh, and that's it; there is a 1:1 mapping from SYSFS -> ATTRS ?
<Keybuk> yup
<Keybuk> the new name is intended to make it more obvious that it checks the attributes in the current sysfs object and all parent objects
<Keybuk> personally I hate it, but hey ho
<fbond> is it also intended to make maintainers of firmware packages have to rewrite their udev rules on a 6 mo schedule? :)
<Keybuk> apparently so
<Keybuk> btw, in Ubuntu you probably want your firmware in /lib/firmware
<Lathiat> jdub:yeh i get the same thing
<fbond> Keybuk: ok, didn't want to step on toes by moving things into /lib/firmware
<fbond> thought that might be reserved for "official" firmware
<pitti> sjoerd: ping
<Keybuk> no
<sjoerd> pitti: pong
<Keybuk> /lib/firmware/$(kernel version) is official
<Keybuk> /lib/firmware itself is intended for unofficial
<pitti> sjoerd: I just fixed hal to not rely on volume.ignore for allowing/refusing mount
<sjoerd> rock!
<pitti> sjoerd: instead I added code to check policy for the non-policykit case
<sjoerd> how?
<pitti> sjoerd: upstream only checks the policy if #ifdef HAVE_POLKIT
<pitti> sjoerd: and didn't check it *at all* if nto
<pitti> sjoerd: not, even
<pitti> sjoerd: so I added an #else and added a function check_nonpolkit_security_policy (privilege, invoked_by_uid);
<\sh> guys, do we have a policy for dealing with iceweasel/icedove build-deps/deps from debian to ubuntu? or are we providing iceweasel/icedove in our ff/tb packages?
<sjoerd> and check_nonpolkit_security_policy does pmount like checking of things ?
<pitti> sjoerd: no, not yet; these checks need to become a bit more invasive
<pitti> sjoerd: most of them shouldn't be a problem to port, but one is hard: replacing getenv ("HAL_METHOD_INVOKED_BY_UID")
<pitti> sjoerd: I have no idea how to determine the uid from the other dbus end from the hal callout
<sjoerd> you can't
<pitti> that's what I thought, too
<sjoerd> you need to trust hal on that one..
<pitti> so the whole 'replace hal property checking by sysfs checks' is pointless
<sjoerd> yup
<pitti> sjoerd: but at least I would like to check for removable/fixed policy on its own rather than relying on volume.ignore
<pitti> sjoerd: specifically because we want to set it to false for non-fstab fixed disks
<sjoerd> yup
<pitti> sjoerd: so that gksu gnome-mount /dev/hdxx works
<sjoerd> i'd like to remove the volume.ignore hack from the debian package completely
<pitti> sjoerd: that's what I am going to do
<sjoerd> rock :)
* pitti wonders whether upstream would accept the current patch
<sjoerd> you could try :)
<pitti> sjoerd: oh, btw, do you still have the debian-ubuntu diff explanation mail I sent you the other day? shall I send it to someone else if you are busy?
<sjoerd> yeah i still have it, sorry about that
<sjoerd> please forward it to the pkg-utopia-maintainers (or whatever it's called list)
<pitti> sjoerd: ok, will do
<sjoerd> did i already say that you rock ? :)
<pitti> thanks ;)
<pitti> sjoerd: hal@packages.d.o. won't work?
<sjoerd> dunno, that'll probably just mail to the maintainers address right ?
<sjoerd> pkg-utopia-maintainers@lists.alioth.debian.org is the right one
<pitti> alright
<pitti> sjoerd: sent
<twb> Who or what is `the SABDFL'?
<xhaker> twb, it's Mark Shuttleworth, Ubuntu founder.
<twb> Ah, BDFL = benevolent dicatator for life.
<sivang> twb: SA=Self Appointed/ SouthAfrica ;)
<twb> Ah.
<sivang> twb: the .za part was my joke
* sivang needs to get a "how to be funny" howto
<xhaker> it was mildly funny
<sivang> xhaker: nah, you're too kind
<sivang> xhaker: it was bad :)
<twb> When I register my key, I get a mail from launchpad with no instructions attached.
<twb> What do I do next?
<twb> s/key/gpg key/
<gnomefreak> good morning mvo 
<twb> Ah, it's encrypted as well as signed.
<mvo> hey gnomefreak!
<ajmitch> hello mvo 
<pitti> Mithrandir: just for the sake of coordination, what are your plans for n-m? (merging, patching, etc.)
<Mithrandir> pitti: it hasn't actually been on my radar yet; I want to update it to the newest upstream version and add a hook for it to call network-admin
<pitti> Mithrandir: ok; I have a pending patch for zeroconf stuff and I wondered whether I should apply it to the current feisty version or wait for the merge
<Mithrandir> pitti: feel free to apply it and I'll bring it forward.
<pitti> Mithrandir: ok; it isn't really intrusive, so it shouldn't cause problems
<pitti> Mithrandir: oh, right, I remember -- the current n-m is FTBFS, so I'd need to throw two patches into it to fix that
<pitti> they can be just dropped when merging
<Mithrandir> pitti: oh, please. :-)
<pitti> Mithrandir: alright, thanks; then I won't get in your way any more with the zeroconf stuff
<Mithrandir> pitti: no worries.
<maxb> pitti | Mithrandir: Any thoughts about my apache2 bug question from earlier today? (62748)
* pitti needs to leave for a bit, bbl
<pitti> maxb: not really from my side, sorry
<Mithrandir> maxb: not offhand, sorry.  My brain is just about fried.
<maxb> Ah. A case of too much going on with feisty, tearing attention away from edgy bugs?
<Mithrandir> a case of "Tollef has been trying to push out a milestone for a week and needs a little more than two hours before he focuses heavily on something else"
<Keybuk> doko: NEVER upload MoM output without altering the changelog to your name, and listing the remaining changes
<Keybuk> you must've tried pretty hard to force that
<doko> Keybuk: ok. no, just signed with -k
<Keybuk> naughty
<sivang> Keybuk: heh
<xhaker> doko: please don't forget eclipse-cdt :P
<doko> xhaker: I don't touch eclipse-cdt
<xhaker> i thought you were the eclipse wiz
<xhaker> nvm then
<pirast> doko, hi
<bddebian> Heya
<pitti> Keybuk: could you please promote avahi-autoipd to main? (binary-only promotion)
<Keybuk> pitti: ok, update the queue please
<pitti> Keybuk: 'update the queue'?
<Mithrandir> pitti: done.
<pitti> Mithrandir: merci
<Mithrandir> Keybuk: binary-only, doesn't need MIR or stuff.
<pitti> ah, that queue; yes, avahi is in promoted already
<Keybuk> good point
<Keybuk> double-done then :p
<pitti> iwj: what's the correct way of renaming a conffile nowadays? IIRC you considered http://wiki.debian.org/DpkgConffileHandling overkill?
<Keybuk> heh
<Keybuk> if anything, that's underkill
<Keybuk> it doesn't account for upgrades being aborted; you need equivalent in postrm and preinst too
<iwj> pitti: Hmmm.  I think the right answer is to have the preinst make a symlink.
<iwj> Certainly you shouldn't do what that wiki page says.
<iwj> No grepping /var/lib/dpkg/status (!)
<pitti> iwj: hm, but I really need to get rid of the old file, or things will break
<iwj> Oh, that's a pain.  Why ?  Can you avoid that ?
<pitti> iwj: is grepping dpkg -s slightly better?
<iwj> Yes.
<pitti> iwj: I could hack around it by changing a conffile in a different package, but then I need to touch two packages, and it would be a *really* nasty hack
<pitti> problem is a script .d directory starting with 'd', but really needs to be executed last
<pitti> so I need to rename it as zzzz_dhcdbd
<iwj> A whole directory ?
<pitti> iwj: no, just the script in the .d directory
<iwj> This is going to be quite complicated and bI'd have to 
<iwj> think about it.
<iwj> Excuse me, I seem to have keyboard/finger interaction problems today ...
<pitti> iwj: I wanted to have a slightly modified recipe: if the old conffile is unmodified, I remove it; if it's modified, I rename it
<pitti> and thus get the dpkg conffile question, which is really what I want here
<iwj> Does the contents as well as the filename change ?
<pitti> iwj: depends, if you upgrade from edgy, yes
<pitti> (so you'd get the question anyway)
<iwj> Keybuk: I need to have a proper conversation with you about UdevLvm and things surrounding it.  I think there are some wrong assumptions in the spec or in me.
<iwj> pitti: But you don't want to get the question if the user's file is identical to the old version.
<pitti> iwj: right
<pitti> iwj: that's why I remove it if the md5sums match
<pitti> (in the preinst)
<pitti> since then the new one will just get unpacked from the .deb
<Keybuk> iwj: oh?
<iwj> Keybuk: Well, the spec deals just with getting vgchange run but it doesn't deal with what happens next.  Which, as it happens, is nothing at all.
<Keybuk> iwj: what should happen next?
<iwj> Keybuk: Well, it should perhaps be mounted by something.
<Keybuk> vgchange is sufficient to get the lvm volume mountable
<Keybuk> which is as far as the scope of that spec cares
<iwj> pitti: Without thinking about it too hard I think that's not an unreasonable approach but you have to think carefully about error handling.
<iwj> You'll have to (eg) save the old file somewhere.
<iwj> Keybuk: The spec doesn't say what happens next.  Apparently the idea is that some udev event calls `the mountroot script' (which I can't seem to find atm ...)
<Keybuk> iwj: the spec doesn't need to
<iwj> But what if it's not / but /usr ?
<Keybuk> its scope is limited
<iwj> I need to understand what's happening next so that I can test it.
<pitti> iwj: http://people.ubuntu.com/~pitti/tmp/dhcdbd.preinst is my current version, with dpkg -s and simplification (no postinst code)
<iwj> I don't care what you think should or should not be in this spec.
<Keybuk> the new block device will cause udev to emit a block-device-added event to upstart
<Keybuk> which will trigger an upstart job that will mount the partition
<pitti> iwj: it would currently do the wrong thing if unpacking the new version would fail
<Keybuk> or, in the initramfs, the device existing will stop the mountroot() function from spinning, and let it mount it
<cjwatson> I wish dpkg -s weren't so slow
<iwj> pitti: Right.  It doesn't look unreasonable.
<cjwatson> I often find myself looking at /var/lib/dpkg/status just because it's slothful otherwise
<iwj> cjwatson: Well, err, yes ...
<cjwatson> why isn't it just morally a sed script, anyway?
<iwj> Keybuk: Where is this code - in particular, the upstart code ?
<iwj> Or doesn't it exist yet ?
<Keybuk> iwj: doesn't exist yet
<iwj> Ah, tricky.
<iwj> Maybe I should wait with this until that's ready.  It's a shame that this interdependency wasn't clearer earlier ...
<pitti> iwj: the good side is that it will never remove a modified conffile, just an unmodified one, so nothing really precious will get lost
<iwj> pitti: Yes, but dpkg treats removed as a kind of changed.
<Keybuk> iwj: it's not a dependency
<Keybuk> the lvm stuff is just as useful beforehand
<cjwatson> removing it works if the thing you're trying to do is move a conffile from one package to another
<iwj> Keybuk: Well, it helps a bit but if it doesn't mount automatically then you've not really gained much.
<Keybuk> iwj: we've gained the loss of a race condition
<iwj> cjwatson: Err, you don't need to do anything special to do that any more.  I fixed that.
<Keybuk> in particular, you should be able to use udevmonitor to see the events happening in the right order
<Keybuk> and write udev rules that use the /dev/mapper directory to access LVM devices
<cjwatson> iwj: you do if you're writing code that needs to run with sarge dpkg, as I was doing last night :-(
<Keybuk> being able to mount an LVM USB stick through HAL would be a good test
<pitti> Keybuk: btw, that test works in feisty right now
<iwj> Keybuk: USB stick> That's exactly what I'm trying.
<iwj> And the current udev rules completely suppress all dm devices.
<pitti> i. e. standard luks-encrypted usb stick will not mount in feisty
<cjwatson> pitti: my usual is (1) preinst install|upgrade: mv -f foo foo.moved-by-preinst; (2) postinst configure: rm -f foo.moved-by-preinst; (3) postrm abort-install|abort-upgrade: mv -f foo.moved-by-preinst foo
<Keybuk> iwj: because udev-devmapper hasn't been implemented yet
<pitti> and suddenly will work as soon as you remove the dmX udev naming rule
<cjwatson> with appropriate version checks, and replace mv with something else as appropriate
<iwj> I think loss of a race which would break something from working is not interesting unless the thing it's racing against might work if the race were fixeds.
<Keybuk> pitti: work with a race condition
<pitti> Keybuk: right, I meant for the sake of testing
<cjwatson> hmm, I suppose I should make that be dpkg-moved-by-preinst to avoid run-parts badness
<iwj> pitti: Yes, cjwatson has the right approach.
<iwj> cjwatson: sarge> Yes.
<pitti> cjwatson: great, thanks
<Keybuk> cjwatson: that's my approach too, iirc
<iwj> Keybuk: So what I'm saying is that udev-lvm doesn't do anyone any good without at least some additional work.
<Keybuk> iwj: yes
<Keybuk> it was one small spec in a set
<iwj> Right.  The `sister' specs like udev-evms were clear to me and are mentioned but the other parts (up and down the stack, as it were) weren't.
<Keybuk> iwj: they're right there, in LP
<Keybuk> marked as dependencies and dependers in either direction
<iwj> Oh, there.  Sorry, I'm a fool.
<cjwatson> sigh, it would be nice if resize2fs had machine-parseable progress display
<Keybuk> cjwatson: yeah, I move the modified in preinst/install|upgrade; remove unmodified or complete the move in postinst/configure; and undo the move in postrm/abort-install|abort-upgrade
<Keybuk> (udev has a copy of my usual prep_rm_conffile/prep_mv_conffile/rm_conffile/mv_conffile/undo_rm_conffile/undo_mv_conffile functions
<Keybuk> iwj: heh, what does that make the rest of us then? :p
<cjwatson> Keybuk: I was having fun with openssh upgrades from sarge last night, so it's still fresh in my mind
<cjwatson> iwj: BTW, do you happen to remember if said conffile bug in dpkg that you fixed was non-deterministic in any way? I couldn't reproduce the ssh->(openssh-client,openssh-server) upgrade problems that people were reporting, but I have no reason to doubt that they're there sometimes
<iwj> Keybuk: Right, UdevDeviceMapper makes life a lot clearer and I'll go away and play with things some more.
<cjwatson> or was it the every-other-conffile-in-status-file thing I vaguely remember?
<iwj> cjwatson: I don't think it was actually nondeterministic but IIRC it could depend on things that the correct processing wouldn't depend on.
<iwj> In particular, it could depend on whether you removed one package and installed the other, or did a Replaces/Conflicts in-one-go.
<cjwatson> oh joy
<cjwatson> hey, e2fsck has nice-ish machine progress information though
<cjwatson> ... but mke2fs' is crap
<iwj> I wish udev had better debugging support.
<Keybuk> iwj: what's wrong with it?
<iwj> Devel team meeting is 0800Z tomorrow, isn't it ?
<iwj> Keybuk: Well, it's a programming language but I can't get a good trace of who did what.
<Keybuk> did you increase the log level?
<Keybuk> udevcontrol log_priority=info
<bluefoxicy> I have a simple question:  Is Ubuntu/Canonical making any money through CD sales?
<iwj> Keybuk: Yes, I had that already.
<bluefoxicy> (More directly, would it be a huge sin to release a program that downloaded an official CD/DVD image and label; printed the label on standard templates; and burned the CD, thus simulating a pressed+printed CD)
<iwj> Keybuk: But I have to go catch my train to Stowmarket to go climbing now.  Talk to you tomorrow if you like ...
<Keybuk> sure
<Keybuk> you can turn on full debugging with a recompiel
<Keybuk> it's off because it can effectively fill an entire disk with a single boot <g>
<Keybuk> anyway
<Keybuk> tomorrow
<dholbach> Gloubiboulga: YOU ROCK :)
* Gloubiboulga hugs dholbach 
<pitti> cjwatson: wrt. your conffile approach, don't the postrm bits need to go into the old version of the package?
<cjwatson> pitti: n
<cjwatson> no
<cjwatson> the new postrm is called when rolling back
<pitti> oh, how convenient
<pitti> thanks
<cjwatson> for precisely this reason, I suspect :)
<pitti> hi erdalronahi 
<erdalronahi> hi
<erdalronahi> Pitti, I always mix up you and doko
<erdalronahi> the openoffice-langpack is his work, isnt it?
<pitti> right
<erdalronahi> the new packs in -proposed are fine as I can see
<pitti> erdalronahi: ah, thanks for testing; did you look at both edgy/dapper?
<erdalronahi> no, not at dapper
<erdalronahi> well, I looked at Dapper,
<erdalronahi> but didn't test it carefully
<erdalronahi> Anyway, as long as there is not multicast, we do not work on Dapper 
<erdalronahi> was it "multicast"?
* dholbach hugs pitti
<dholbach> SUPER-PITTI!
<pitti> hm?
* pitti hugs dholbach back, but is a bit confused about the reason
<dholbach>  P I T T I !
<dholbach> you just uploaded a network-manager fix :-)
<derekS> dholbach: you are a maintener of a package i like, and a new version is out, when you have a minute, can you upload the new one?
<derekS> would help if i gave the package name
<derekS> "tilda"
<dholbach> 0.09.4?
<pitti> dholbach: well, it won't work before I actually finish this dhcdbdbdbd package (2 minutes for the fix, one hour to get the upgrade right *sigh*)
* keescook sobs
* dholbach hugs pitti
<keescook> I reported to someone that they should use strncpy instead of strcpy
<dholbach> keescook: what's wrong?
<dholbach> derekS: 0.09.4?
<pitti> keescook: and they forgot to ensure the terminating 0?
<keescook> They replaced their strcpy with: strncpy( dest, src, strlen(src) + 1)
<cjwatson> haha
<pitti>  hahaha
<cjwatson> please to be aiming gun *away* from foot
<derekS> dholbach: yeah
<dholbach> derekS: already uploaded some days ago
<derekS> dholbach: oh, mybad
<derekS> sorry about that :)
<derekS> thanks
<dholbach> derekS: we were frozen for herd1 for a while
<siretart> is it nowadays possible to configure static ips with network-manager?
<derekS> dholbach: ahh, thats why it didn't make it... i waited for a while, figured i would ask
<dholbach> right
<derekS> thanks
<dholbach> anytime
<derekS> when does the freeze end?
<pitti> derekS: some hours ago
<derekS> pitti: so packages should start to make there way into the repos soon?
<cjwatson> they already have
<pitti> derekS: the sources already did
<pitti> derekS: the buildds have to chew through them now, of course
<derekS> ahh... is there away to get the buildlogs
<derekS> like we used to?
<pitti> derekS: see DeveloperResources wiki page
<derekS> thanks
<HumanPrototype> siretart, I sure hope someone says yes
<derekS> have a nice afternoon
<pitti> cjwatson: ./update'ing ubuntu-meta fails with a 404 on downloading the ia64 package lists; did we drop ia64?
<cjwatson> not to my knowledge, and it worked for me when I last tried
<pitti> hmm, I tried it twice now
<cjwatson> ah, somebody broke ports
<cjwatson> elmo: http://ports.ubuntu.com/ubuntu-ports/ no longer exists; what happened?
<elmo> gar, sorry
<elmo> cjwatson: the machine got upgraded, space wise and apparently that got lost
<alex-weej> so i just installed a fresh ubuntu
<alex-weej> and my LC_* variables are all en_US.UTF-8
<alex-weej> i'm sure i told it to be normal english on installation...o_0
<cjwatson> that is normal English
<alex-weej> or was that just keyboard prefs?
<cjwatson> i.e. it's the default
<cjwatson> YM British English?
<alex-weej> i mean English English, bitch! :P
<alex-weej> (yes)
<cjwatson> I speak British English too, but I'm also aware of what the defaults are ;)
* alex-weej groans
<alex-weej> ok
<alex-weej> so is this a bug?
<cjwatson> alex-weej: hang on
<alex-weej> or did i just imagine that i told ubiquity i was from the UK
<cjwatson> look at /var/log/installer/syslog
<alex-weej> cjwatson: on it
<cjwatson> unfortunately I've just been reminded that I have to go to take the child to chess club
<cjwatson> back in a bit ...
<alex-weej> cjwatson: ok, cya
<Spads> cjwatson: can you check for me if ubuntu-ports looks good now?
<tsmithe> bah british english should be the default! we are the original english!
<pitti> Spads: works here
<_ion> Finnish English!
<alex-weej> Lojban should be the default
<alex-weej> i can't find any reference to locale settings in the installer log
<_ion> alex-weej: http://imgs.xkcd.com/comics/lojban.png
<alex-weej> _ion: :P
<alex-weej> ok
<alex-weej> first of all
<alex-weej> what is the ubuntu way of changing my locale settings to their rightful en_GB? :P
<alex-weej> is it the LANG setting in /etc/environment?
<alex-weej> actually I'm sure i need to generate my locales first
<Lure> alex-weej: there is also /etc/default/locale
<alex-weej> hmm
<alex-weej> not good
<alex-weej> why two places? :S
<Spads> pitti: cool, thanks
<seb128> alex-weej: use system, admin, language 
<_ion> alex-weej: If you're running X, gnome-language-selector handles installing packages and generating locales.
<seb128> alex-weej: otherwise /etc/environment is the place
<_ion> /etc/default/locale doesn't exist on my system.
<alex-weej> seb128, _ion: ok thanks
<seb128> np
<alex-weej> _ion: it does on my fresh edgy
<alex-weej> seb128: interestingly, firing it up for the first time prompts me to install language stuff for Ooo
<alex-weej> should i file a bug?
<seb128> yeah, I think dictionnaries etc don't fit on the CD
<alex-weej> oic
<alex-weej> ok next question
<seb128> speak to cjwatson about it when he's back
<alex-weej> now that I've just set it for "new accounts and the login screen"
<alex-weej> how do i set it for my existing account?
<seb128> he probably knows if those things should be installed with the language-packs after install
<seb128> alex-weej: it'll use the system default, or pick a different language from gdm before login
<pitti> seb128: 'those things'?
<seb128> pitti: <alex-weej> seb128: interestingly, firing it up for the first time prompts me to install language stuff for Ooo
<seb128> pitti: looks like -support not installed
<pitti> alex-weej: ^ right, that's what it's supposed to do, complete language support for you
<alex-weej> pitti: it didn't even give me the option of doing anything, as soon as i ran it it said i was missing stuff
<seb128> pitti: why does it wait for the language-selector to be started? shouldn't that be installed with language-packs from internet by ubiquity?
<pitti> seb128: -en is a special case, since the en-gb OO.o help is not a dependency of l-support-en
<pitti> seb128: so this will happen for en_GB folks
<alex-weej> ok next thing to throw in the pot
<alex-weej> i ran dpkg-reconfigure on locales
<pitti> the reason is that we want l-support-en on CD
<seb128> pitti: well, it's confusing :)
<pitti> and thus it can't depend on the en-gb OO.o help
<pitti> seb128: right, it is
<pitti> alex-weej: that won't do what you want
<alex-weej> it generated all the other en_* locales (en_US was already "up to date"). what's with that? were they not already generated? would language-selector have dealt with it if i hadn't done so prior to running it?
<pitti> alex-weej: I strongly presume that the locales were okay before
<pitti> just the caching code is a bit broken
<alex-weej> pitti: it seems a bit of a coincidence that en_US was up to date
<alex-weej> i will make a note and investigtae
<alex-weej> seb128: did i accidentally choose en_US in ubiquity then?
<alex-weej> seb128: or does it just not even ask?
<pitti> alex-weej: it's been a while since I did an English install, I'm not sure; d-i does ask for a region, not sure about ubiquity
<mjg59> It's based on the area you select in the timezone selection
<alex-weej> i don't think anyone living in Europe/London wants to use en_US
<alex-weej> :P
<mjg59> At least, I think so. I haven't checked the code.
<alex-weej> ok
<mjg59> alex-weej: I always get en_GB
<alex-weej> i will have a look some time
<mjg59> So there's not a general failing
<alex-weej> ok i got another one for yas
<alex-weej> https://launchpad.net/distros/ubuntu/+bug/74657
<Ubugtu> Malone bug 74657 in Ubuntu "floppy0 comes out of nowhere" [Undecided,Unconfirmed]  
<lamont> doko: curious about your bind9 upload...
<lamont> or rather, curious about why ubuntu switched to only allowing recursion on localnets...
<lamont> since (1) localnets is generally incorrect for the application...
<cjwatson> alex-weej: as mjg59 says - I've never encountered that particular problem. wouldn't mind looking at the syslog in case it's illuminating in any way, and a precise description of what you did would be good
<cjwatson> it's possible that going back and forward in ubiquity could confuse that bit of code
<alex-weej> i didn't go back and forth
<cjwatson> ok
<alex-weej> i'll post my installer log later
<alex-weej> mates cooking curry
<alex-weej> gotta join
<cjwatson> sure
<alex-weej> cya in a bit
<cjwatson> lojban> we don't have a lojban installer translation ;-)
<jdong> lol
<Balachmar> Hi, I might have found a bug, which I would like to get resolved.
<Balachmar> I can't seem to find the ubuntu-bugs channel
<Balachmar> So I thought to drop it here...
<Adri2000> Balachmar: /join #ubuntu-bugs
<Balachmar> ok, sorry :)
<Adri2000> any idea how to fix a FTBFS like that?
<Adri2000> /usr/bin/ld: cannot find -ldbus-glib-1
<Adri2000> collect2: ld returned 1 exit status
<mjg59> build-depend on whatever package provides that
<slomo> Adri2000: or add a dependency on libdbus-glib-1-dev to the package that references it via a pkg-config file or .la or whatever...
<Adri2000> the package I'm trying to build is gnome-phone-manager, it built fine on edgy buildds, but now it doesn't build either in an edgy pbuilder or a feisty pbuilder
<Adri2000> slomo: libdbus-glib-1-dev is a new package?
<slomo> no
<Adri2000> currently there is no *dbus* build-dep, and it built fine in edgy
<slomo> it's probably one of the build depednencies of gnome-phone-manager that needs this added
<Adri2000> something that used to depend on libdbus-glib-1-dev, and doesn't anymore in feisty? is it possible?
<slomo> no, something that did not depend on dbus-glib in edgy but does now in feisty... and someone forgot to add the dependency
<Adri2000> slomo: are we talking of the same "something"? :p I meant something = a build-dep of gnome-phone-manager
<slomo> Adri2000: yes, that's the something i meant too ;) well, let's see...
<seb128> I think that's a gnome-vfs change
<seb128> you need libgnomeui uptodate
<seb128> I didn't rebuild 3 packages which mentionned wrongly libdbus-glib after the gnome-vfs change
<seb128> libbonobo(ui) libgnomeui and some other one
<seb128> the libgnomeui build has probably be blocked by the freeze for herd1 though
<Chipzz> seb128: libdbus-glib-1 doesn't exist anymore iirc, it's libdbus-glib-1-2
<seb128> grab the new version now and retry with it
<Mithrandir> Chipzz: next version is going to be libdbus-glib-1-2-3 ?
<seb128> Chipzz: the -dev is still named libdbus-glib-1-dev
<Chipzz> seb128: ah k
<Chipzz> the vmware guys should rebuild vmware player and server against new dbus :(
<seb128> Adri2000, slomo: read what I just write
<Chipzz> bleh
<seb128> wrote
<ulaas> my mx3000 logitech usb mouse went crazy after upg to feisty
<ulaas> where should i report.
<Adri2000> seb128: that is what someone said to me, but I saw a new libgnomeui today, isn't it the right one?
<Chipzz> Mithrandir: dbus is supposed to be stable now ;)
<seb128> Adri2000: grep libdbus-glib /usr/lib/*.la
<Chipzz> didn't we get rid of all .la files?
<seb128> Chipzz: no
<Chipzz> (or most of them anyway)
<slomo> Chipzz: libdbus is meant to be stable now... but not the glib, qt, whatever bindings
* Adri2000 is on edgy
<seb128> Chipzz: we are getting there but not yet
<seb128> going there
<Chipzz> seb128: that's what I thought, but wasn't that like half a year ago or more? I presumed we would already be there by now ;)
<seb128> Chipzz: well, getting ride of a .la usually force to rebuild all the package mentionning it and in the right order
<Adri2000> seb128: grep libdbus-glib /usr/lib/*.la < it should find something?
<seb128> Chipzz: which can be hundred of packages
<Chipzz> Mithrandir: and the next version will probably be libdbus-glib-1-3
<Chipzz> ;)
<slomo> seb128: how would a rebuild fix this? it's a missing dependency of one -dev package... in this case libgnomebt-dev 
<Adri2000> seb128: in my pbuilder-feisty, with libdbus-glib-1-dev, it finds nothing
<ulaas> slomo, oh hi.
<seb128> Adri2000: yep, or the bug is not the one I'm thinking about
<slomo> hi ulaas :)
<seb128> Adri2000: and the package fails to build
<seb128> slomo: it's not, it's an inflated depends to .la
<Adri2000> yes
<seb128> slomo: rebuild get ride of the .la extra entry
<slomo> seb128: ah ok
<seb128> Adri2000: does your package use dbus directly?
* seb128 starts pbuilder
<ulaas> hehe! gotta love bitchx
<seb128> Adri2000: what package do you try to build?
<Adri2000> seb128: it's gnome-phone-manager, and I only made a fix for the icon file
<Adri2000> so I don't really know about dbus :)
<seb128> Adri2000: let me look
<ulaas> no one else has crazy mouse symptoms around?
<seb128> ulaas: no
<seb128> ulaas: xorg didn't change for a while now
<ulaas> seb128 kernel related?
<seb128> might be
<seb128> do you use some sort of special device?
<ulaas> seb128: i have a combo mx3000 from logitech
<sladen> ulaas: PS/2 interface, or USB?
<ulaas> seb128: same conf as then one i used in edgy
<ulaas> seb128: USB
<ulaas> seb128: i mean a usb receiver
<bhale> maybe... you have a dead battery
<jdong> ha
<ulaas> bhale: maybe upgrading to feisty made it die :)
<jdong> hardware problem
<jdong> :)
<maswan> Mithrandir: I have _no_ idea why I'm only getting 200k/s update speed.
<maswan> Mithrandir: I'm getting good numbers to the filesystem
<Mithrandir> maswan: according to Znarl, the routing is fine, so something is really weird, somewhere.
<Mithrandir> (or at least was fine this morning)
<maswan> Mithrandir: *nods*
<ulaas> ok! i am not here for a solution. just wanted you good people to know there is such a thing. If you find out some other people are effected as well please let me know. maybe i can help. my launchpad nick should be ulaas.
<seb128> ulaas: ok, thank you for pointing the issue, maybe opening a launchpad bug would be a good idea too
<ulaas> seb128: will do so when i finished investigating more
<maswan> Mithrandir: Hmm.. I'm not getting better speeds from cdimage.u.c from other hosts though.
<maswan> (just tried 3 different networks)
<Mithrandir> maswan: might be slow now due to herd 1, though I somewhat doubt it.
<Mithrandir> maswan: I also get shit speed to it now.
<maswan> Mithrandir: *nods*, so we'll poke Znarl tomorrow during dc business hours? ;)
<Mithrandir> hmm, something weird here, from a host which usually gives me ~45Mbit, I now get ~4.5Mbit.
<Mithrandir> maswan: yeah, I guess so
<tsmithe> Mithrandir, something weird here
<tsmithe> from a host that usually gives me ~2MBit, i'm getting ~0.5Mbit
<tsmithe> so yours is pretty bloody fast
<maswan> Mithrandir: Well it was slow to begin with, since I only got 400kB/s starting out at the mirroring
<Mithrandir> maswan: yeah, and that was before the announce and all, so it shouldn't have had any load to speak of then anyway.
<maswan> Mithrandir: my first directory (/releases) went at 470k/s, second (edubuntu/releases) went at 222k/s, third dir is still running
<seb128> Adri2000: 
<seb128> # grep dbus-glib-1 /usr/lib/*.la
<seb128> /usr/lib/libgnomebt.la:dependency_libs=' 
<seb128> etc
<seb128> Adri2000: on my feisty pbuilder
<seb128> Adri2000: libgnomebt needs a rebuild, I'll do that now
<Adri2000> seb128: with what packages installed?
<seb128> apt-get build-dep gnome-phone-manager from a clean pbuilder
<seb128> i386 feisty
<seb128> with apt-get update before
<seb128> so it's current uptodate
<seb128> weird that you don't have that
<Adri2000> I had only installed libdbus-glib-1-dev
<seb128> Adri2000: well
<seb128> <Adri2000> seb128: grep libdbus-glib /usr/lib/*.la < it should find something?
<seb128> <Adri2000> seb128: in my pbuilder-feisty, with libdbus-glib-1-dev, it finds nothing
<seb128> that is weird
<seb128> are you sure you had all the build-depends for gnome-phone-manager installed?
<Adri2000> no :) I'm installing all the build-dep at the moment
<Adri2000> with all the B-D it works
<seb128> Adri2000: sure, you installed dbus-glib-dev
<seb128> anyway get the new libgnomebt when gnome-bluetooth has built
<seb128> I've just uploaded the package
<seb128> you can upload gnome-btdownload if you want
<seb128> ups
<seb128> gnome--phone-manager
<seb128> gnome-phone-manager
<Adri2000> seb128: so gnome-phone-manager should build when the new libgnomebt/gnome-bluetooth is built?
<seb128> correct
<seb128> I've deleted /usr/lib/libgnomebt.la in my pbuilder and retried and it built fine
<Adri2000> ok, thank you :)
<alex-weej> ok
<alex-weej> it seems disc drives are statically configured in fstab - is there no way to dynamically detect drives as well as the media that goes in them?
<alex-weej> i don't think people would normally think of updating an fstab if they installed a new DVD burner
<seb128> Adri2000: np
<alex-weej> here's a question for the pros, can i safely read-only mount a filesystem on a loop that is actively being written to?
<alex-weej> sorry wrong channel
<T`> hi.. i want to repackage my own deb package from new sources for verve-plugin... is there some tutorial on how to do this? and is there a .spec equivalent for .deb?
<mc44> T`: ask for help in #ubuntu-motu
<T`> mc44, thanks
<superm1_> i was looking at the source for ubuntu-meta, and I don't see how "ubuntu-desktop" gets placed into the "Meta Packages" section.  debian/control doesn't specify a section.
<superm1_> could someone explain how it is getting placed here?
<jorgp> where should I go for a backporting pbuilder problem? #ubuntu-motu everyone is asleep
<superm1_> jorgp, how did you generate the P builder?
<superm1_> from the ubuntu packaging guide?
<superm1_> *pbuilder
<superm1_> http://doc.ubuntu.com/ubuntu/packagingguide/C/gs-pbuilder.html ?
<jorgp> im using edgy, wanted to backport a package to dapper
<superm1_> right
<superm1_> so did you make a dapper pbuilder
<superm1_> per that guide?
<jorgp> I did sudo pbuilder create --distribution dapper
<jorgp> yes
<superm1_> does the package depend on anything in universe or multiverse?
<jorgp> that part works fine
<jorgp> no
<jorgp> my problem is the package when I run sudo pbuilder build package.dsc
<superm1_> okay well that looks right then
<superm1_> what package?
<jorgp> the configure of the package says configure: error: C compiler cannot create executables
<jorgp> wine
<superm1_> had to pick one i cant try on amd64 huh?
<_ion> Have you installed build-essential?
<Chipzz> jorgp: wrong channel
<Chipzz> jorgp: check config.log
<jorgp> yes
<superm1_> jorgp your not trying on AMD64 too are you?
<jorgp> no
<Chipzz> jorgp: this channel is about the development OF ubuntu, not development WITH ubuntu
<superm1_> okay msg me
<cjwatson> superm1_: metapackages> it's overridden centrally in the archive
<cjwatson> should probably be synced into the package at some point
<superm1_> cjwatson, so if i wanted to create a package that went into the Meta Packages group, would i add "Section Meta\ Packages" to debian/control?
<cjwatson> there is no space, and no capitals
<cjwatson> "Section: metapackages"
<superm1_> ah 
<cjwatson> "Meta Packages" is just presentation
<superm1_> that explains my build problems that were failing at the very end
<superm1_> i see
<superm1_> thanks cjwatson.  your also the main dev on ubiquity right?
<cjwatson> yes
<superm1_> well i wanted to ask you how you would feel about a second ubiquity installer, derived from it for installing a mythtv specific system
<geser> would an update to gnupg2 2.0.1 (plus fix for CVE-2006-6235) be accepted for feisty?
<superm1_> i was planning such a project in the coming months, and would like to have it included during the normal ubiquity build, and jst generate two different binaries
<superm1_> an ordinary ubiquity installer and the mythtv version
<superm1_> the plan would then be to have live disks that could be distributed to install myth specific systems
<superm1_> and i really didnt want to bring this into a derivative project, but keep it in the ubuntu family
<crimsun> geser: what does 2.0.1 add over 2.0.0?
<crimsun> geser: check w/ keescook, btw, since he uploaded gnupg 
<geser> it has some support for the keypad of my smartcard reader which I would like to use
<keescook> geser: from the security perspective, as long as the CVE fix is included, I don't mind (I actually just uploaded gnupg2 with the CVE fixed)
<crimsun> yep, that's what I figured, since I saw gnupg uploaded
<geser> keescook: would you sponsor the upload once I've packages ready?
<keescook> geser: sure. is the 2.0.1 from Debian, or new packaging?
<geser> Debian has no 2.0.1 yet (and with the upcoming freeze I don't really believe it will be included)
<geser> it's a new orig.tar.gz with the current diff.gz (minus the .in changes)
<keescook> geser: sounds like a quick review.  :)  sure, let me know when you have it ready.
<superm1_> cjwatson, i'm not sure you saw what i posted above, but what do you think of this idea?
<linux__> leute
<cjwatson> superm1_: if you just need it to install different stuff, all you need to do is make the fillive filesystem have different contents
<cjwatson> you don't need to modify the installer for that
<superm1_> well some of the installed stuff will be custom
<superm1_> say for a frontend only box
<superm1_> versus a backend only box
<superm1_> but i'd like to be able to install from the same disk for both cases
<superm1_> so i was figuring have the common packages on the disk, but then an extra section to install the extra packages for each in the installer
<cjwatson> I'm happy to discuss that sort of thing, but a separate ubiquity binary isn't appropriate - that sort of thing should be configuration
<superm1_> Ok.
<cjwatson> mail me with specifics of the situation and I can make suggestions
<superm1_> Okay i will do.  i have to finish brainstorming some ideas, and then i will
<superm1_> thanks for the help
<cjwatson> np
<jmg> hello all
<jmg> is anyone aware of issues with lvm support in edgy
<jmg> i only see one open bug in launchpad
<jmg> i am experiencing extremely unusual behavior
<LaserJock> if a bug is open then people then I guess people are aware
#ubuntu-devel 2006-12-07
<jmg> its not relevant
<jmg> to my issue
<LaserJock> ah
<LaserJock> well, if you've searched and can't find a similar bug you can always file one if you think there is indeed a bug
<LaserJock> cjwatson: does/can a sync from Debian overwrite and existing .orig.tar.gz?
<LaserJock> *an
<cjwatson> not one with the same name, no
<LaserJock> we've got a situation where Ubuntu had an .orig.tar.gz before Debian
<cjwatson> the only thing you can do in that circumstance is a "fake sync" using the Ubuntu .orig.tar.gz but producing a result equivalent to the Debian package
<LaserJock> same version, files are the same, just different creation times on the tarball so the md5sums don't match
<cjwatson> normally using the Debian diff, but check that the Debian and Ubuntu .orig.tar.gzs produce basically the same content
<cjwatson> right, so Ubuntu .orig.tar.gz, Debian .diff.gz, new debian/changelog entry with "build1" on the end, upload
<LaserJock> that's what I was thinking, excellent
<LaserJock> thanks
<bhale> would the next sync work after that?
<bhale> or you are stuck until new upstream
<LaserJock> stuck until new upstream I guess
<bhale> thought so
<LaserJock> this has happened more then once I think
<LaserJock> it would be nice if we could just replace the Ubuntu .orig.tar.gz with the Debian one
<shawarma> LaserJock: The problem is the old .dsc files that still contain the old md5.
<shawarma> LaserJock: and they're all stored in the same placed and signed and everything.
<cjwatson> bhale: as LaserJock said
<cjwatson> LaserJock: breaks mirrors, no can do
<bhale> LaserJock: well
<cjwatson> shawarma: also that mirrors would have to use rsync --checksum rather than just relying on filenames, which is a big fat extra load
<bhale> LaserJock: it is often known what cases it will happen in
<bhale> LaserJock: a heads up to the Debian maintainer usually makes it a non-issue in my experience
<shawarma> cjwatson: Oh, i thought they did that already.
<shawarma> cjwatson: But of course, that'd be silly since we never change any existing files.
<shawarma> cjwatson: ..apart from Packages.gz and such.
<shawarma> cjwatson: Are Release, Sources, and Packages rsynced on the side then?
<cjwatson> filenames are unique in the archive; this is an invariant
<cjwatson> sure
<cjwatson> they're often done in a separate
<cjwatson> er
<cjwatson> dists/ is different
<cjwatson> in fact I think it's just pool/ that has the uniqueness constraint - it's the biggest bit by far
<alex-weej> whoever recommended dd_rhelp to me the other day
<alex-weej> you are a LEGEND
<alex-weej> it is closing up dead holes on my disk image really well
<cjwatson> shawarma: I believe so
<cjwatson> see e.g. http://www.debian.org/mirror/anonftpsync
<LaserJock> cjwatson: if we upload as build1 will it cause problems for the Feisty+1 syncing (i.e. normally build1 packages are automatically synced)?
<shawarma> cjwatson: I see. That would explain why Packages sometimes referes to files that are no more.
<cjwatson> LaserJock: no; at worst those syncs will harmlessly fail and will have to be merged
<cjwatson> (this isn't a new problem - we have a fair bit of experience with this :-))
<LaserJock> heh
<LaserJock> ok, thanks
<cjwatson> np
<shawarma> cjwatson: So the complete version would be what? Debian is 1.27-2, so we'd make 1.27-2ubuntu0build1 ?
<cjwatson> shawarma: right
<cjwatson> no, 1.27-2build1
<cjwatson> the effect of "ubuntu" in a version is precisely to suppress automatic syncing
<shawarma> cjwatson: ...which we want?
<cjwatson> in this case you don't want to do that - either there's no new upstream and the sync will fail harmlessly, or there's a new upstream and you want to autosync
<shawarma> cjwatson: ..since manual intervention is needed anyhow.
<cjwatson> only if there's no new upstream
<cjwatson> we don't want to overload people doing merges, so if the worst thing that happens is that a sync fails, big deal, we ignore that
<shawarma> cjwatson: Ah... Yes, now I get it.
<cjwatson> it's better to try to autosync where possible
<shawarma> cjwatson: Indeed. Makes sense. Thanks.
<jdong> bug 54684, it apparently approved for edgy-updates but it hasn't been moved from proposed yet
<Ubugtu> Malone bug 54684 in nautilus "High CPU usage" [Unknown,Fix released]  http://launchpad.net/bugs/54684
<jdong> excuse my ignorance abourt SRU's
<infinity> Stuff isn't moved from -proposed to -updates, it requres a second upload currently.
<infinity> Oh, and the second upload happened.
<holycow> hi guys
<holycow> anyone here good at packaging?  i was curious if i could get someone to compile and package these drivers: http://doc.gwos.org/index.php/Nvidia_nForce_SoundStorm
<holycow> i'd just like to have the .deb around for the future, i won't be buying this damned chipset anymore
<infinity> holycow: Try #ubuntu-motu
<holycow> danke
<infinity> (If you want it packaged in multiverse)
<infinity> It's certainly never going to be in restricted, since nvidia doesn't support the driver anymore.
<holycow> not a bad idea, never thought of it
<holycow> nforce is no longer supported?
<infinity> No, the driver isn't supported.  nvidia tells people to use the open source drivers instead.
<holycow> for nforce?
<infinity> (One would assume they're contributing to the open source drivers sucking less, slowly)
<infinity> For nforce sound, yes.
<holycow> odd
<holycow> well they do provide source files for the chipset, the chipset controls a bunch of things
<Solarion> is the gpg bug set to be pushed out soon?
<holycow> nforce sound eh?  would you know anything about nforce network card or vid support?
<holycow> i presuve nv drivers supports video
<holycow> maybe then just getting a newer kernel might workie
<mjg59> They're all supported with open drivers
<holycow> okay, in that case, it must be just that dapper doesn't have the latest builds of those, cool thats awesome to know
<holycow> i didn't manage to google that up
<holycow> did nvidia open source the drivers or did they just give up when someone reverse engineered them?
<bhale> the later, roughly
<holycow> heh
<Burgwork> holycow: more a matter of poking the hardware and seeing how it jumps
<holycow> aha okay.  
<geser> keescook: I've working packages for gnupg2 2.0.1
<keescook> geser: great, do you have a URL for them?
<geser> what exactly should I upload? is the diff.gz enough?
<holycow> would it be fair to say that the best supported chipset these days are intel chipsets?
<mjg59> Yes
<holycow> then its time to switch i think
<holycow> thank you for the info guys, greatly appreciate that
<geser> keescook: is the diff.gz enough? 
<LaserJock> geser: generally debdiffs are nicer :-)
<geser> also for new upstream versions?
<LaserJock> hmm, I think I'd rather have the whole package in that case
<jmg> topic
<jdong> infinity: thanks for taking care of the gnome-vfs2 thing :)
<keescook> geser: can you get me the URL for the orig too?
<jmg> http://pastebin.ca/270015
<jmg> ideas?
<geser> keescook: I will upload my used orig.tar.gz to some webspace (ftp.gnupg.org has only tar.bz2)
<keescook> geser: okay, thanks.
<jdong> heh, iptables is a LOT more bothersome when it plays music
<jdong> guess that must be why nobody else does it :D
<geser> keescook: I also added libcurl3-gnutls-dev to build-depends as this fixes bug 62864 for me (it also happens with gnupg2). is that ok?
<Ubugtu> Malone bug 62864 in gnupg "[Edgy]  Refreshing my keyring stops after some keys (keyserver time out)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62864
<cjwatson> jmg: pvscan doesn't take a device name, for a start. Try vgscan?
<keescook> geser: I assume so; I've got a path fix for it too, so I'll probably apply that to yours before I upload it
<cjwatson> (or, at least, it didn't take a device name in the sarge system with lvm I have handy. hmm)
<lifeless> jdong: it does not take on on my edgy server
<lifeless> cjwatson: ^s/on/&e/
<lifeless> jdong: sorry, wrong nick
<jdong> cjwatson: no, pvscan doesn't take device names on dapper or edgy
<jdong> jmg: ^^
<geser> keescook: http://members.ping.de/~mb/gnupg2/
<jmg> cjwatson: pvscan/pvdisplay both have null output
<keescook> geser: thanks, snagging now
<jdong> jmg: you sure you've fdisked your partition to have linux LVM type?
<jmg> jdong: yes
<HrdwrBoB> er
<jmg> though that isnt required
<HrdwrBoB> it needs to be made a pv first
<HrdwrBoB> partition type is not enough
<HrdwrBoB> pvcreate
<jmg> HrdwrBoB: see pastebin
<jdong> jmg: IIRC it is required for PV's to be picked up automatically
<jmg> http://pastebin.ca/270022
<HrdwrBoB>  jdong negative
<HrdwrBoB> I have no partitions on my array, works fine
<jmg> jdong: and anyway
<jmg> /dev/sda3 : start= 12578895, size=475813170, Id=8e
<jdong> jmg: does pvdisplay show anything?
<jmg> in the strace of pvscan i can see it reading the lvm tag off the partition, yet it doesnt work
<jmg> jdong: null
<jdong> hmm
<jmg> jdong: if i do it on console it shows "File descriptor 6 left open"
<jmg> note that this box has been dist-upgraded from dapper to edgy
<jdong> strange
<jmg> very
<jdong> should I be breathing a sigh of relief that I didn't dist-upgrade my LVM server to edgy?
<jmg> perhaps
<HrdwrBoB> I haven't upgraded any servers to edgy
<jmg> i wanted to try chuck's xen packages
<rmjb> hello, anyone knows what a driver should build-depend on? I have kernel-package in there, but pbuilder complains about not finding the /lib/modules/2.6.17-10-generic/build directory
<jdong> rmjb: some sort of linux-headers?
<jdong> rmjb: I guess look at how linux-restricted-modules is done
<rmjb> there's no generic headers then...
<jdong> no generic headers?
<rmjb> I mean one that's not specific to an arch
<jdong> l-r-m builds against all
<jdong> a control.in.in generates it
<jdong> I think
<rmjb> I am definitely in way over my head
<jmg> ok
<jmg> i downgraded lvm2 to the package from dapper
<jmg> http://pastebin.ca/270037
<jmg> hmm
<jmg> evms...
<jmg> heh
<holycow> jdong, are you around?
<holycow> i have a question about the possibility of  backporting nforce drivers to dapper
<jdong> holycow: yes I am
<holycow> hi btw
<jdong> what nforce drivers?
<holycow> the open source drivers that i understand are in the kernel
<jdong> in the kernel?
<jdong> I don't handle that. --> #ubuntu-kernel
<holycow> well i don't know if they are modules or built in, i presume modules
<holycow> oh okay at least i get closer 
<holycow> thanks jdong
<jdong> holycow: np, good luck :)
<holycow> :)
<alex-weej> does anyone know if i can safely mount a disk image (read-only) that is actively being written to?
<jdong> alex-weej: no
<alex-weej> is that a "i know, and the answer is no"
<alex-weej> or a "no i don't know"?
<jdong> (1) read-only is not always taken so literally. ext3 actually does a JOURNAL PLAYBACK when you mount it ro :)
<alex-weej> o_0
<bluefoxicy> o.O
<jdong> (2) If significant structures change while you're reading, you'll get a kernel panic or oops
<jdong> I have experienced both
<alex-weej> heh
<alex-weej> ok
<jdong> I am the authority on doing crackful things
<jdong> :)
<bluefoxicy> jdong:  most drivers will rework it and remount ro or just umount
<bluefoxicy> for file system being ass
<jdong> bluefoxicy: in theory :)
<alex-weej> dd_rhelp is really struggling on the last few MB of this disk
<bluefoxicy> yes
<bluefoxicy> that theory is "Faulty hardware means we try to back off safely"
<jdong> bluefoxicy: I've panicked ext3 with -o errors=remount-ro before
<bluefoxicy> I'm aware the reality can be "Let's do a BSOD"
<jdong> bluefoxicy: that's from xen and my system both mounting a disk
<bluefoxicy> XD
<jdong> so alex-weej, either momentarily stop dd-rhelp or wait on mounting :)
<jdong> and make sure you mount a COPY
<jdong> not the original backup image
<jdong> because as I've said, a simple ro mount can change the image
<alex-weej> yeah i'm gonna
<alex-weej> copying a 108 GB image is going to take a while
<jdong> :)
<jdong> the sweet sound of hard disk failure
* jdong knows that sound too well
* alex-weej too now
<jdong> from that first click-click-click to the spindown :)
<jdong> lol
<alex-weej> it's done pretty well tbh
<alex-weej> - Biggest hole size :  800 k - total holes : 4656.0k
<alex-weej> - xferd(succ/err) : 116161327.5k(116161195.5k/132.0k)
<wasabi> Sure wish OCFS2's module was in the -generic kernel. =/
<wasabi> so i could play with it
<jdong> alex-weej: that's very good
<jdong> alex-weej: a helluva lot better than I've ever done
<alex-weej> taken me 6 hours
<jdong> alex-weej: you caught that failure early
<jdong> or you're just lucky
<alex-weej> oop it's off again
<alex-weej> - Biggest hole size :  736 k - total holes : 4212.0k
<alex-weej> - xferd(succ/err) : 116161771.5k(116161635.5k/136.0k)
<alex-weej> :D
<alex-weej> still lost 4k though :(
<alex-weej> do you know if that "err" bit is totally dead disk?
<alex-weej> i might leave it going overnight see how well it is when i wake up
<jdong> alex-weej: the err is how many blocks dd_rescue (not dd_rhelp!) stumbled on
<jdong> alex-weej: when dd_rescue stumbles, dd_rhelp helps dd_rescue fast-forward a bit
<jdong> alex-weej: so in reality succ/err is pretty nonsensical
<jdong> alex-weej: it's the hole sizes that you need to worry about :)
<jdong> alex-weej: I hope that's ext2/3, btw
<alex-weej> yeah, why?
<jdong> alex-weej: for the recovery ;-)
<alex-weej> you think i should make a copy then fsck it?
<jdong> alex-weej: a lot of the other filesystems have a good deal of "magic metadata" that if lost means a good chunk of the structure disappears (!)
<jdong> alex-weej: you should absolutely make a copy of it
<jdong> fscking it is a good start
<alex-weej> uh oh
<alex-weej> don't like the sound of it being a "good start"
<alex-weej> i've put like a whole evening into this already lol
<jdong> well
<jdong> fsck isn't always failproof
<jdong> it can either
<jdong> (1) Die / core-dump in the middle of repairing
<jdong> (2) Give up and start slashing inode entries until you're left with 2 files
<jdong> and then call it "clean" :D
<alex-weej> :|
<jdong> just hope that neither happens :)
<alex-weej> btw
<alex-weej> if i just mount a copy
<alex-weej> without fsking
<jdong> sure, you can try that
<alex-weej> if i try and copy files off will i get potentially corrupt files or is there some sort of checksumming in effect?
<jdong> though there's a possibility a good chunk of directories are not available
<jdong> i.e. you get an IO Error or Operation Not Permitted trying to enter a directory
<alex-weej> hmm
<alex-weej> i'm curious
<jdong> depends on whether or not any of that 4000K is filesystem metadata
<jdong> which I'm betting at least a bit of it is :-/
<jdong> you can try it
<jdong> hence the point of the "copy" :)
<alex-weej> reckon i can hot copy the image that is being written to?
<alex-weej> it's not easy to pause this thing
<alex-weej> it's blocking like a bitch
<alex-weej> and it's uninterruptable 
<jdong> yeah, IO Errors block :)
<jdong> look who didn't build a preemptible kernel
<jdong> (j/k :D)
<alex-weej> what would that have done?
<jdong> given you a much better chance of interrupting the process :)
<alex-weej> blaeh
<alex-weej> seriously i ctrl+c'd this process about 5 minutes ago
<alex-weej> damnit
<bluefoxicy> oh hell yes
<bluefoxicy> libFLAC 1.1.3 is out, and no GNU_STACK
<bluefoxicy> I submitted the changes for that a while back <3
<bluefoxicy> (well it's there on PPC but not on IA-32)
<twb> I wish to file a wishlist bug against the USN (Ubuntu Security Notice) process.  What is the name of the pseudopackage?
<Treenaks> twb: what's the bug? :)
<twb> http://twb.ath.cx/tmp/tmp.txt
<twb> Treenaks: DSEs have a little summary header like that at the top of each message.
<twb> I'd like USNs to do likewise.
<twb> For example if it says "Problem type: remote", I upgrade *immediately* and then read the rest of the message.  If it says "Problem type: local", I don't rush so much.
<Treenaks> I just always run upgrade-cluster.sh :)
<Treenaks> not that it's really a cluster.. but it upgrades all machines I'm a sysadmin for
<keescook> twb: I've been thinking about adding something like that.  However, I worry about serious issues getting ignored due to those classifications, though.  for example, the tar USN would have "local", but there are plenty of websites that automatically process tar files, so really it's remote vuln for them...
<twb> keescook: I suppose...
<keescook> twb: but, I agree: it'd be nice to have a little something more.  :)
<Burgundavia> keescook: see what secunia puts out. Is quite good
<Burgundavia> they also rate the vuln, which is fairly useful, if a little arbitrary
<infinity> Any rating between "minor" and "critical" is pretty useless, IMO.
<keescook> yeah, I like secunia's stuff.  :)
<keescook> hey infinity!  :)
<infinity> "This is something only a pedant will care about" versus "Jumping Judas, update your system yesterday."
<keescook> heh
<infinity> Any in between is so arbitrary that it's worthless, which makes the whole system of ratings somewhat worthless.
<infinity> "Well, this could be sort of bad, on a Tuesday, if you're downloading porn."
<Burgundavia> however, there are vulns which are worse than others
<infinity> There are.  remote/local, root/not, should be enough for most people to decide on their own.
<infinity> Too many factors on the local machine to say beyond that what's "bad" and what's not.
<infinity> I may be some SELinux freak who doesn't even care about privilege escalation, or I may be a bank behind 4000 firewalls who doesn't care about remote vulns, etc.
<infinity> Or, other considerations, like things that rely on poor user habits would be "no big deal" to me, but a huge deal to a corporation full of "regular users".
<Burgundavia> yep
<infinity> And on it goes.
<infinity> Now, we *could* rate vulns based on the potential for humour.
<infinity> "If your friends are caught by this one, you can TOTALLY point and laugh."
<Burgundavia> humour value: 4.3 (likely to be activating while browsing goat porn)
<twb> Bah.  I use wget for all my goat porn.
<twb> I'd like to see someone manage a js exploit in that!
<Burgundavia> hmm, I saw a wget exploit awhile back
<pitti> Good morning
<doko> infinity: apache2 and subversion syncs (subversion is assigned to me, but I would need apache2 first)
<infinity> doko: apache2 is on my list of "things I'm going to be careful about, but I promise to get it done this week before I go on VAC"
<infinity> doko: You can either leave SVN to me (which should be simple enough), or do it after I get apache2 happy.
<infinity> Part of "making apache2 happy" includes a mess of "getting modules happy", I suspect, so perhaps best to leave SVN to me too.
<doko> ok
<infinity> Uhm, since when is python marked Essential: yes
<infinity> ?
<infinity> doko: Do you know about the above?
<pitti> hmm, not for me...
<pitti> only -minimal
<infinity> Which is also pretty sketchy.
<infinity> But here, it's Essential.
<pitti> but wasn't -minimal specifically introduced to become an essential package?
<infinity> No
<pitti> ('yay for writing postinst scripts in python' or so?)
<infinity> minimal has all sorts of stuff in it that doesn't qualify as "Essential", as far as Debian policy would define it.
<infinity> Oh, we're talking about two different "minimals" :)
<twb> Well, Ubuntu doesn't stick to the Debian policy.
<infinity> python-minimal is also not Essential, however.
<infinity> twb: Name one are where we don't.
<infinity> s/are/area/
<twb> infinity: invariant sections of GFDL docs?
<infinity> twb: That's not Policy, that's DFSG.
<twb> Well, I assumed policy said something like `only DFSG in main'.
<infinity> Debian Policy is about packaging, not politics.
<infinity> And we adhere to it as best we can, or the world explodes.
<doko> infinity: hmm, yes, looking at it; the essential attribute was dropped in my last update
<infinity> pitti: python-minimal is Priority: Required, python somehow ended up Essential: yes recently.
<pitti> infinity: ok, my package index is from yesterday still
<infinity> doko: As in, one you just uploaded, or one you're about to?
* pitti is at ISDN ATM, network broken once again
<twb> Section 2.2.1, "Every package in _main_ must comply with the DFSG (Debian Free Software Guidelines)."
<doko> infinity: 2.4.4-1ubuntu1
<twb> Ubuntu concretely does not follow that part of the policy w.r.t. tar-doc, which has invariant sections.
<infinity> twb: Okay, fine, we don't adhere to 2.2.1 (or, you could argue that we read the DFSG differently from Debian)
<infinity> twb: Point taken, though.  We don't adhere to Policy 100%.  That doesn't mean we ignore it.
<twb> I'm not implying that Ubuntu not sticking to Debian policy is a *bad* thing; merely that it is *a* thing.
<infinity> (base)adconrad@cthulhu:~$ apt-cache show python | egrep "^Version|^Essential"
<infinity> Essential: yes
<infinity> doko: ^^^
<infinity> Version: 2.4.4-1ubuntu1
<infinity> doko: Source agrees with me too.
<twb> infinity: fyi, this is shorter
<twb> grep-available -s Package,Essential,Version -X -P python
<infinity> twb: You're assuming I have dctrl-tools available on that machine.
<twb> Sure.
<infinity> (Also, I know)
<twb> Good-o.
<doko> infinity: apt-cache show python-minimal|grep Ess
<infinity> doko: python.  Not minimal.
<doko> python shouldn't be essential
<infinity> doko: I agree. :)
<infinity> doko: The source does not.
* infinity wonders if this is the point where he stops talking and just uploads.
<StevenK> infinity: Thanks for punting wlassistant to -updates.
<infinity> StevenK: Cheers.
<dholbach> good morning
<_ion> Hi dholbach
<dholbach> heya _ion
<infinity> doko: Are we talking past each other, or did you just have another look at python-defaults' debian/control and realise what I'm talking about? :)
<_ion> dholbach: Please take a look at bug 74698.
<Ubugtu> Malone bug 74698 in ubuntu-artwork "Wrong gconf defaults for wallpaper" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74698
<dholbach> _ion: thanks
<infinity> twb: As for the Policy discussion, except for very rare political exceptions (like the DFSG thing, for instance), we *do* stick to Debian Policy, and not doing so would very much be a bad thing.
<twb> Granted.
<infinity> twb: And if you feel like discussing it further, you're welcome to take me to Blue Fire Grill and convince me further.
<infinity> PS: I'm hungry.
<doko> infinity: ? the source never was essential afaik
* twb just had vindaloo
<infinity> Feed your archive admin, lest he become cranky.
<dholbach> hey seb128, hey doko, hey infinity :)
<seb128> hi dholbach
<infinity> doko: From the current python-defaults debian/control:
<infinity> Package: python
<infinity> Architecture: all
<infinity> Essential: yes
<infinity> Priority: required
<doko> infinity: yes, that's the binary
<infinity> Err, yes.  Yes it is.
<infinity> I meant "check the source, it's not fixed"
<infinity> You claimed "python" was no longer marked Essential in that version.
<infinity> Or, as I suspect, we're talking past each other.
<twb> I want to create patches for `casper' in a way that is easiest for the Ubuntu maintainer to integrate.  I suspect this means branching the bzr trunk (and registering the branch with launchpad?)  Is there a tutorial document to walk me through this process?
<cjwatson> twb: https://wiki.ubuntu.com/BzrContributorHowto
<twb> Thanks.
<Mithrandir> twb: actually, what would be easiest for me is if you take the Ubuntu branch and merge each debian feature on its own branch so I can pick & choose.
<twb> On its own branch, eh?
<Mithrandir> yeah, so since you're interested in the NFS support and such, just merge the bits relevant to that.
<Mithrandir> (on one branche9
<twb> Yeah
<Mithrandir> s/e9/)/
<twb> I should also mention that I'm used to darcs, not bzr.
<twb> BTW, I notice the edgy .orig.tar.gz has a .bzr in it.  IIRC that's against policy.
<cjwatson> that's a longstanding debate :)
<twb> OK.
<cjwatson> I don't believe policy specifies; feel free to cite chapter and verse if I missed it
<cjwatson> and I avoid it in my own packages, but Mithrandir likes it that way ...
<Mithrandir> twb: .bzr directories are useful to random people, unlike .svn or CVS directories.
<hunger> Would it be possible to stop the new sun-java5-plugin deb to require an /usr/lib/iceweasel/plugins dir to create symlinks in? That does not exist in ubuntu (yet?).
<cjwatson> hunger: there's no harm in packages providing hooks for extra browsers
<cjwatson> my mozilla-nukeimage package provides hooks for a big pile of browsers that won't be installed. I think that's fine - harmless and easier than divergence
<hunger> cjwatson: Sure, but then it should check for the existance of that dir before failing in the postinst script.
<cjwatson> hunger: oh, it should just ship it in the .deb
<cjwatson> the directory
<cjwatson> that's a bug
<hunger> cjwatson: Yes, that is an option, too:-)
<cjwatson> that's the correct option
<cjwatson> otherwise it breaks on Debian if installed before iceweasel
<twb> Mithrandir: incidentally, you may be interested in this little script: http://twb.ath.cx/~twb/canon/transmuter/transmute.html
<ajmitch> hunger: already filed as bug 74621
<Ubugtu> Malone bug 74621 in sun-java5 "[Feisty] sun-java5-plug fails to install" [Undecided,In progress]  http://launchpad.net/bugs/74621
<hunger> ajmitch: Great!
<twb> Cool, I can correct typos in bug reports!
<twb> (incf malone)
<pitti> twb: you can change the description, but not comments
<twb> Yeah.
<Mithrandir> twb: nice.
<twb> Mithrandir: examples in http://twb.ath.cx/~twb/canon/transmuter-examples/
<Mithrandir> twb: I'm in a meeting right now, but I'll look at it once that's finished
<twb> The coolest part is you say
<twb> transmute --inspect --from ubuntu-desktop-6.10.iso
<twb> and you get dropped into it, as if the .iso was just a chroot dir.
<twb> Righto.
<Mithrandir> that looks really useful; for me as a developer too
<cjwatson> I've been looking for something like that for a long time
<twb> It's actually the third version.
<twb> The previous two were far nastier.
<twb> So when I file a bug via email, I put `affects /distros/ubuntu/PACKAGE', where PACKAGE is the name of the package?
<Mithrandir> I've been doing those kinds of things by hand, which gets tiresome after a while
<cjwatson> twb: yes
<twb> OK.
<Keybuk> pitti: libnss-mdns upgrade worked that time
<pitti> Keybuk: great, thanks for confirming
<jdub> $ ping stanley.local
<jdub> PING stanley.local (172.16.254.1) 56(84) bytes of data.
<jdub> Lathiat: ^ avahi getting my vmnet address :)
<iwj> seb128: `Breaks' as far as apt is concerned is there to cause upgrade of the broken package.  Is that not what you wanted ?
<Keybuk> pitti: my weird behaviour now is that avahi announces the wrong IP address
<Keybuk> in fact, avahi announces my vmnet8 IP, which is perhaps the least useful one it could have picked
<pitti> urgh
<pitti> Keybuk: same problem that jdub has apparently
<seb128> iwj: well, what if the new package is not available yet?
<seb128> iwj: like evolution-data-server 1.9 Breaks evolution << 2.9
<iwj> seb128: Then apt will hold back the breaking package.
<seb128> and e-d-s was available before new evo
<seb128> ok
<seb128> so I did the updates on my box
<seb128> packaged e-d-s first
<iwj> If you dpkg -i it then it deconfigures the broken package and apt is too lame to cope.
<seb128> dpkg -i *.deb for it
<seb128> and from that point apt was stucked
<seb128> I had to dpkg -r evolution
<iwj> But there's nothing fundamentally wrong.
<iwj> Right, that's a fine workaround.
<seb128> I somewhat think that apt should manage and keep working
<iwj> Or --configure --force-depends if you prefer.
<iwj> seb128: Yes, it should.  But it's fundamental to apt's design that it can't ignore some problem even if you don't want it fixed and it can't fix it.
<Keybuk> pitti: I would have thought the IP it announced would depend on the interface that the MDNS packet was received on?
<mvo> iwj: right. part of apts design is that the system shouldn't be broken
<pitti> Keybuk: that's what I would expect as well, and so far it worked fine with my experiments
<mvo> I don't think there is anything wrong with this
<pitti> Keybuk: seems that the vmnet ones confuse avahi; I'll talk to lennart about this
<seb128> iwj: ok, I was expecting it doing the same as for Conflicts, i.e: remove evolution on "apt-get -f install" to "fix" the situation
<iwj> But that doesn't fix it of course.
<Keybuk> pitti: with those up, I can't even look up the address from another machine
<Keybuk> (I assume the replies get lost?)
<seb128> well, that allows apt to work again
<seb128> instead of focussing on the Breaks it can't resolve
<pitti> Keybuk: sounds like it
<Keybuk> actually, I can't seem to look it up anyway
<pitti> Keybuk: the other machine runs avahi as well?
<Keybuk> yes
<pitti> Keybuk: avahi-discovery is quite handy for that, btw
<seb128> iwj: anyway, no big deal, that happened only because I dpkg -i the package using Break on my box, will not happen to users
<Keybuk> pitti: example?
<pitti> if you see the other machine appear, DNS should work
<iwj> seb128: Right.
<pitti> Keybuk: example? it's  just a gui that displays what avahi knows
<pitti> Keybuk: btw, if you try this on powerpc, avahi seems to be seriously broken on ppc ATM
<Keybuk> avahi-discover on the desktop (edgy) shows itself and my laptop (feisty)
<pitti> s/seems to be/is/
<Keybuk> avahi-discover on the laptop (feisty) only shows itself
<Keybuk> both of them say "Timeout reached" if I click the laptop
<iwj> mvo: No, apt demands that the package state database doesn't record that the system is broken.  (Eg, it is happy that the system fails to have evolution installed when the user wanted it, but not happy if the database records that evolution is there but not working.)
<pitti> Keybuk: (later, after discussion in meeting)
<iwj> And in fact apt is willing to break the system further in order to make the status database prettier.
<iwj> But perhaps this is more of a rant for a bar somewhere :-).
<mvo> iwj: I see your point, but from a user perspective it dosn't matter IMHO if its not working because it is not there or not working because it is there but not working :)
<iwj> mvo: Well, yes, except that if it's there and not working at least it gets put back and made to work later.
<_ion> Re: the discussion at -meeting, perhaps there should be a GUI program specifically made to be run if there's <N MiB of free space in /home. *dm would start that application instead of the normal desktop session in that situation. The app would suggest things that could be deleted, and you could start a terminal from that app.
<_ion> It would list .xsession-errors among the suggestions for things to be deleted if its size exceeds some sane value.
<Keybuk> 09:15:56.944097 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF] , length: 57) syndicate.netsplit.com.5353 > 224.0.0.251.5353: [udp sum ok]   0 A? quest.local. (29)
<Keybuk> 09:15:56.944648 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF] , length: 67) quest.netsplit.com.5353 > 224.0.0.251.5353: [udp sum ok]   0*- [0q]  1/0/0 quest.local. (Cache flush) A quest.netsplit.com (39)
<Keybuk> hmm
<Keybuk> I see that on all three sides (quest [desktop] , router, syndicate [laptop
<Keybuk> so it's not a network problem
<doko> infinity, Mithrandir:  the powerpc build of openoffice.org 2.0.4-0ubuntu3 in ubuntu edgy PROPOSED did fail (disk space); please requeue
<infinity> doko: Checking.
<pitti> infinity: while you're at it, can you please give-back uim? it failed due to gettext 0.15 segfaulting, but now 0.16 is in the archive on all arches
<infinity> pitti: Done.
<pitti> cheers
<doko> Keybuk, cjwatson: please sync icu from unstable (#71857), needed for the openoffice.org build
<lucas> hi, I plan to resurrect "debian package a day"
<lucas> if you don't want it to be added to planet ubuntu, say it aloud now ;)
<lucas> (posting rate should be of about twice a week)
<ajmitch> a day? :)
<seb128> twice a week, that's not "a day"
<lucas> it was named like that before, so it's better to keep the name
<lucas> and in case of huge success, I won't have to change the name :-)
<seb128> twice a weeks seems fine
* ogra just discovered x2x on ltsp ... 5 thin clients make a huge desktop :)
<siretart> ogra: sunrays even offer xinerama extensions when joining them into a sunray group. that'll be a nifty feature for ltsp as well ;)
* siretart is currently sitting in front of such a sunray group
<ogra> siretart, well, first i'D have to get this sunray booting .... got it sitting on my desk since three months now and didnt get more than a hourglass out of it yet
<siretart> ogra: you'll need the sunray server software for that. the guy who managed to get this working in debian sits next room to me ;)
<sivang> morning
<ogra> siretart, i know, but sun was planning to opensource the image they provide for that
<ogra> i'd like to support it directly with ubuntu ltsp
<siretart> ogra: err, what image are you currently talking about?
<siretart> the SRRS?
<ogra> the bootimage you apparently need for these boxes
<ogra> i'll look into getting it running in ltsp during feisty but its very low prio ...
<siretart> hm. I'll ask michael about this at lunch. he should have some insight in this
<tepsipakki> are main merges handled completely by core-devs?
<ogra> tepsipakki, you can do merges as "non-core-dev" but should contact the person listed on the merges page for uploading
<pitti> Keybuk: could you please put your interfaces configuration and 'avahi-browse -at' into a bug report about avahi, so that I can point Lennart to this?
<tepsipakki> ogra: yes, sure
<tepsipakki> thanks
<Keybuk> pitti: for which, vmware or the "I get no DNS" ?
<pitti> Keybuk: oh, you don't get any DNS at all, or just not for .local?
<pitti> Keybuk: I mainly meant the vmware issue, although they sound related
<Keybuk> pitti: I don't get any service discovery at all
<Keybuk> even with vmware turned off
<Keybuk> so I have two problems
<Keybuk> 1) when vmware is running, the wrong IP is answered
<cjwatson> tepsipakki: to be honest it's usually not worth it for non-core-devs to do main merges - it tends to be more work to review somebody else's merge than to just do it, IME
<pitti> Keybuk: is that powerpc?
<cjwatson> tepsipakki: except perhaps in very complicated cases
<Keybuk> 2) when vmware IS NOT running, I just don't get any service discovery
<StevenK> pitti: Not with vmware....
<Keybuk> pitti: amd64 on one machine, i386 on the other
<Keybuk> pitti: running avahi-discover on my laptop (feisty i386) does not see any services my desktop (edgy amd64) exports, not even its hostname
<pitti> Keybuk: on powerpc I have to restart /etc/init.d/avahi-daemon to make it pick up new stuff, maybe that's not just confined to ppc then
<Keybuk> the simplest test is "ping quest.local" on my laptop, which returns NXDOMAIN, despite tcpdump showing mdns traffic and replies
<pitti> Keybuk: but on your edgy desktop you have avahi-autoipd running?
<cjwatson> gar, why is there no gtk.Window.get_default()?
<Keybuk> pitti: restarting avahi-daemon on the feisty machine fixed the problem
<Keybuk> pitti: no, edgy desktop just has avahi-daemon running
<pitti> Keybuk: it seems to work without restarting on my amd64 box, but I get the effect on my ibook
<Keybuk> it's the feisty package that seems broken
<pitti> Keybuk: I'll talk to him about that
<pitti> right
<pitti> Keybuk: AFAICS you need avahi-autoipd to actually announce the IP to avahid
<Keybuk> pitti: that's bogus
<Keybuk> autoipd is only if you want a link-local IP
<pitti> Keybuk: but that might just have been a false impression due to the broken feisty avahi
<Keybuk> service discovery and IP discovery is supposed to work on ordinary networks too
<pitti> actually yes
<Keybuk> the problem just appears to be that the feisty daemon doesn't detect or announce things until it's restarted
<pitti> Keybuk: ok, if restarting it fixes things for you then we have the same bug
<tepsipakki> cjwatson: yeah, I was looking at syslinux, but maybe start with something easier instead ;)
<cjwatson> tepsipakki: doko's on that
<Keybuk> bug #72728 is consistent with the problem that I am seeing
<Ubugtu> Malone bug 72728 in avahi "Avahi possible regression in 0.6.10-0ubuntu3.2" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72728
<tepsipakki> cjwatson: cool
<Riddell> mvo: any plans to fix the apt i386 fail to build?
<cjwatson> tepsipakki: even discounting the above, you should ALWAYS check with the person named on merges.ubuntu.com before starting on a merge
<mvo> Riddell: when you build it locally?
<cjwatson> otherwise there's a good chance of duplicating work
<mvo> Riddell: it currently fails for -O0, but I'm fixing this right now
<tepsipakki> cjwatson: yes I've read the docs, just haven't started doing any work yet
<Riddell> mvo: thanks
<pitti> Keybuk: aah, that gives me a good clue, will check that out; thanks for the pointer
<Mithrandir> seb128: I now publish the feisty unapproved queue every 35 minutes past the hour; the deb-src line is "deb http://people.ubuntu.com/~tfheen/unapproved-queue/feisty /" (it's empty now).  JFYI.
* seb128 hugs Mithrandir
<seb128> Mithrandir: thank you!
<Mithrandir> I'll probably crank that up to every 15 minutes or so during freezes, now I just keep it running to keep me on my toes.
<seb128> 35 minutes is fine enough I think
<pitti> Mithrandir: rock
<Mithrandir> seb128: it's hourly; 35 minutes past the hour.
<pitti> Mithrandir: I get a 403 in firefox, though
<seb128> Mithrandir: well, hourly is still good enough ;)
<Mithrandir> pitti: happier now?
<pitti> Mithrandir: yup, thanks
<Mithrandir> ok, good, it just creates new queues with the wrong permissions, they're not reset when my publish-queue script runs.
<Keybuk> pitti: the vmware thing does appear to be interesting
<Keybuk> basically it does answer differently depending on the interface the request comes in on
<Keybuk> if you request from another machine, you get the logical IP for that request
<Keybuk> if you request from localhost, you get a random interface <g>
<pitti> hm, if I do 'ping donald.local' (which is my localhost), I get '10.28.130.200', which is my eth0
<pitti> Keybuk: I also have an eth1, so maybe it just picks the first it comes across
<Keybuk> quest scott% getent hosts quest.local
<Keybuk> 172.16.95.1     quest.local
* pitti reconfigures vmware for the new kernel
<Keybuk> quest scott% ssh syndicate getent hosts quest.local
<Keybuk> 82.108.80.245   quest.local
<pitti> argh, vmware module doesn't build with 2.6.19-7
<pitti> Keybuk: what does 'avahi-browse -at' show to you? I get a 'donald' entry for all local ethernet devices I have configured
<pitti> and the one it actually uses for donald.local is the last one
<gnomefreak> evolution-data-server really doesnt like being installed/upgraded today bug has been filed already
<Keybuk> pitti: command not found
<seb128> gnomefreak: bug on what?
<gnomefreak> evolution-data-server
* Keybuk tries avahi-utils
<pitti> Keybuk: dpkg -S grinding
<pitti> Keybuk: avahi-utils, right
<gnomefreak> hold on a sec ill grab it
<Keybuk> pitti: it shows me an entry for all devices, and seems to pick the first one
<seb128> gnomefreak: thank you; if that's a bug on  e-d-s I'm going to close it right now
<seb128> https://launchpad.net/distros/ubuntu/+source/evolution-data-server/+bug/74797
<Ubugtu> Malone bug 74797 in evolution-data-server "[Feisty] evolution-data-server wont install" [Undecided,Unconfirmed]  
<seb128> hum
<pitti> Keybuk: so it really just seems to pick a random one; funny, though, it should detect this special case and just deliver 127.0.0.1
<gnomefreak> your welcome but closing isnt good
<Keybuk> pitti: indeed :p
<pitti> Keybuk: hm, maybe it was his concern to avoid problems if lo is not configured
<Keybuk> oddly enough, lo is the one device it *hasn't* got :p
<gnomefreak> they are depends 
<Keybuk> if lo is not configured, you will have bigger problems <g>
<pitti> right :)
<pitti> but AFAIK this is only a curiosum
<Keybuk> indeed
<pitti> s/K/CS/
<Keybuk> though I can see it causing people alarm when testing
<Keybuk> like it did for me
<pitti> Keybuk: I'll poke the restart thing this afternoon
<seb128> gnomefreak: bug rejected
<seb128> gnomefreak: why closing is not good?
<gnomefreak> seb128: why? something you already working on?
<seb128> gnomefreak: no, that's just a feature
<Keybuk> I still don't have any real use for avahi of course, since rhythmbox won't share removable devices (pointed look at seb128), but it's nice to see if it would work if I did :p
<seb128> gnomefreak: evolution-data-server Breaks evolution (<=2.9)
<gnomefreak> its a feature that it wont install?
<seb128> gnomefreak: so it'll not install it before having evolution 2.9 instlaled
<gnomefreak> seb128: it didnt have the <= it had <
<seb128> gnomefreak: yep
<pitti> Keybuk: gnome-user-share worked nicely, too
<seb128> gnomefreak: <<
<gnomefreak> k
<seb128> gnomefreak: the point is that e-d-s and evo need to be upgraded together
<gnomefreak> well people cant do updates while its like that unless they use aptitude
<seb128> gnomefreak: so apt will refuse to upgrade e-d-s while evo is not available
<gnomefreak> k i understand
<seb128> gnomefreak: well, that would be an apt bug then
<pitti> Keybuk: and, from what I've heard, vino sessions (not tested myself)
<seb128> gnomefreak: talk to mvo about it
<gnomefreak> k
<pitti> Keybuk: let's avahify ssh, so that every intruder instantly knows where to bruteforce at :-P
<thom> pitti: apple ssh already does that afaik
<pitti> oh, really?
<Keybuk> pitti: doesn't the apple stack already do that?
<thom> yeah, you can click connect in terminal and get a list of local ssh servers
* pitti changed the sshd port on his server to specifically avoid automatic raids
<Keybuk> pitti: I prefer to trust our security team to get ssh fixed very quickly if there's an exploit
<pitti> Keybuk: avahifying apache would be more interesting
<Keybuk> and if they're too slow, and my box gets rooted, I know where you both live <g>
<pitti> Keybuk: for me it's mainly a DoS issue
<pitti> Keybuk: the other day I had MBs worth of auth.log for millions of rejected ssh attempts
<thom> pitti: there're are mdns modules for apache2 already i believe
<pitti> thom: cool
<Keybuk> dbus TCP proxy!
<Keybuk> advertised with mdns!
<thom> pitti: libapache2-mod-dnssd
<Keybuk> inject dbus messages directly into other machines!
<Keybuk> FTW!
<Mithrandir> Keybuk: excellent idea!
<cjwatson> I have a bug about advertising ssh over avahi ...
<pitti> and advertise it as 'support remote hotpluggable devices'
<gnomefreak> ty seb128 i changed the package and made my comments ill ping mvo about it in a bit i still need coffee
<pitti> cjwatson: OMG, I intended this to be a joke
<seb128> gnomefreak: np!
<iwj> gnomefreak: Are you sure people can't do updates at all ?  The idea is that just e-d-s would be held back.  (And its dependencies.)
<cjwatson> pitti: feel free to find the Debian bug and scream at it. :)
<gnomefreak> iwj: i pasted it on there
<gnomefreak> iwj: i had to use aptiutude
<Keybuk> pitti: you should know not to joke at members of this company for fear your oh-so-humorous idea gets implemented
<gnomefreak> iwj: apt-get dist-upgrade would not go further than the depends errors
<gnomefreak> couldnt you just have e-d-s be held back by apt instead of erroring?
<pitti> Keybuk: one interesting thing that I saw was pulse's avahi module; so you can effortlessly route your music output to the kitchen computer when you go downstairs to prepare lunch
<seb128> iwj: https://launchpad.net/distros/ubuntu/+source/evolution-data-server/+bug/74797 has the command line log
<Ubugtu> Malone bug 74797 in apt "[Feisty] evolution-data-server wont install" [Undecided,Unconfirmed]  
<iwj> gnomefreak: That is what it is supposed to do.
<pitti> Keybuk: how could we ever survive without that feature?
<iwj> seb128: Reading it now.
<gnomefreak> it didnt :(
<gnomefreak> brb going for coffee refill
<Keybuk> pitti: I want the telepathy/avahi integration ... so you can effortlessly talk to your partner or housemates without actually having to deal with servers :p
<Keybuk> landscape/avahi integration? <g>
<pitti> brave new world -- 'effortlessly talking to housemate' != 'going over and talk in RL' any more
<iwj> gnomefreak: apt-get upgrade works.
<jdub> Keybuk: did you see the apt/avahi stuff? that's pretty cool
<thom> jdub: um.
* cjwatson dumps Debug::pkgProblemResolver output into that apt bug for the record
<gnomefreak> iwj: it didnt work here as you saw
<pitti> Riddell: ugh, seems my latest dapper-updates hal with the fix for scsi cd-roms broke KDE's media mounting (bug 72869)
<Ubugtu> Malone bug 72869 in kdebase "Latest hal update breaks USB stick mounting in kubuntu dapper kde 3.5.5" [Undecided,Confirmed]  http://launchpad.net/bugs/72869
<iwj> Err, you tried _dist-upgrade_.  What does   apt-get upgrade   do for you ?
<Riddell> pitti: only for kde 3.5.5, which isn't officially supported
<gnomefreak> i already worked around it aptitude puts it in held back
<iwj> gnomefreak: Although I suppose it's too late for you to experiment now.
<Riddell> pitti: but I'll look into making a suitable hal package for those kubuntu.org packages when I have some spare time
<pitti> Riddell: still weird, the change should only cause more CD-ROMs to appear in hal
<Riddell> hmm
<pitti> Riddell: shall I revert the ubuntu-updates patch for now?
<iwj> gnomefreak: Right.  I have a system here which I haven't upgraded yet and   apt-get upgrade   seems to want to do the right thing (I didn't confirm it) whereas dist-upgrade gives the same error as in the bug report.
<pitti> it'll break SCSI and USB CD-ROMs again, but...
<iwj> gnomefreak: What does   apt-get dist-upgrade   do on your system now ?  I think it will complain still.
<Riddell> pitti: I wouldn't revert a fix in ubuntu because it breaks some unsupported packages
<iwj> That is, produce that error.   And apt-get upgrade will just say nothing to be done because everything's held back, I think.
<gnomefreak> when dpkg is done ill run it
<cjwatson> iwj: probably just needs to MarkKeep it?
<iwj> cjwatson: It already does that.
<cjwatson> where?
<iwj> That's how it gets to be held back with `upgrade'.  TBH I need to read the code for dist-upgrade again to know why it hates this.
<gnomefreak> dist-upgrade shouldnt error on it at all
<cjwatson> iwj: I'm looking at pkgProblemResolver::Resolve and don't see it
<iwj> gnomefreak: Yes, I agree.
<cjwatson> gnomefreak: you are stating the obvious
<pitti> Riddell: still curious; do you happen to have an idea where it breaks?
<pitti> Riddell: it shouldn't affect the properties of USB sticks etc. at all
<iwj> cjwatson: My suspicion is that `dist-upgrade' thinks that any held back packages mean it has failed and then it refuses to continue.
<cjwatson> iwj: not in my experience
<gnomefreak> upgrade now has it in held back but so did aptitude 
<cjwatson> iwj: looking at the debug output I think it's simply not marking it as keep, really
<iwj> gnomefreak: And dist-upgrade is still broken for you ?
<iwj> cjwatson: How odd.
<gnomefreak> yes
<pitti> Riddell: aah, presumably because dapper's KDE didn't yet use the hal backend methods, but pmount? and upstream KDE 3.5.5 does?
<gnomefreak> dist-upgrade still wont hold them back 
<iwj> gnomefreak: Right, that's as I expect.  That means that `apt-get upgrade' is a workaround.
* iwj goes to fix apt.
<Riddell> pitti: yes
<gnomefreak> ty iwj 
<Adri2000> Riddell: I had already reported bug 73847
<Ubugtu> Malone bug 73847 in tagcoll "tagcoll has been renamed to tagcoll2 in Debian" [Undecided,Confirmed]  http://launchpad.net/bugs/73847
<pitti> Riddell: hm, in dapper's hal there's only a '<policy at_console="true">' policy for the Mount methods, no 'group=plugdev' as in edgy
<pitti> Riddell: so it actually appears that it should fail the same way with dapper final's hal
<pitti> Riddell: the curious thing is that they claimed that downgrading to 18.1 from dapper-proposed fixed it
<pitti> Riddell: but 18.2 is the same as 18.1, just uploaded to dapper-updates
<Riddell> pitti: the kubuntu.org kde 3.5.5 archive has a modified version of 0.5.7-1ubuntu18.1
<pitti> Riddell: aah, that explains it then
<pitti> Riddell: so reverting the hal fix in ubuntu would not fix it at all then
<Riddell> so I need to (find someone else to) compile hal with the same change for the new version in dapper-updates
<Riddell> fdoving: fancy taking that on?
<pitti> fdoving: what was the change? adding 'group=plugdev' dbus policy for the Mount methods?
<Riddell> pitti: "Install Storage scripts"
<pitti> Riddell: oh, heh :)
<pitti> Riddell: I remember, we removed them from dapper's hal because they were horribly insecure
<Riddell> Adri2000: I'm not sure why it hasn't automatically synced
<xerxas> how can I report a bug to dh_make ? 
<xerxas> dh_make follows symlink ( I did a "ln -s my-stuff  my_stuff-x.x )
<Adri2000> xeros: the package is debhelper
<cjwatson> no it's not
<seb128> xerxas: https://launchpad.net/distros/ubuntu/+source/debhelper/+filebug ?
<cjwatson> it's dh-make
<cjwatson> do not file dh_make bugs on debhelper
<seb128> ups, right
<Adri2000> err, sorry :p
<seb128> xerxas: https://launchpad.net/distros/ubuntu/+source/dh-make/+filebug ?
<xerxas> seb128, but anyway, the bug is to be reported upsteam 
<xerxas> isn't it ? 
<seb128> xerxas: report it to Debian then
<xerxas> ok 
<xerxas> bugzilla.debian.org ? 
<seb128> no
<seb128> bugs.debian.org
<xerxas> yup 
<seb128> what is your bug?
<seb128> Debian doesn't use bugzilla
<seb128> xerxas: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=dh-make;dist=unstable list it maybe?
<twb> xerxas: if you have a Debian system, use reportbug(1) or M-x report debian bug RET
<xerxas> seb128,  maybe 
<dholbach> _ion: thanks for your work - uploaded
<twb> (Those won't work on an Ubuntu host, because they'll be sent to Ubuntu instead of Debian)
<xerxas> I'll have a look
<xerxas> thanks 
<xerxas> twb,  k , thanks 
<twb> See also http://www.debian.org/Bugs/Reporting
<xerxas> seb128,  already reported ! 
<xerxas> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311512
<xerxas> thanks 
<Ubugtu> Debian bug 311512 in debhelper "debhelper: [dh_make]  Does not understand symlinked source directories" [Normal,Open]  
<seb128> np
<twb> reportbug(1) just interactively creates the email in the correct format and sends it to submit@bugs.debian.org.
<xerxas> 1 year and 188 days old 
<xerxas> that's not going to be fixed anytime soon ! 
<xerxas> should be trivial 
<xerxas> let's try to fix it :)
<xerxas> in my dreams 
<twb> xerxas: if you create a patch, submit it to 311512@bugs.debian.org with "tags + 311512 patch" and "thank you" as the first two lines of the message body.
<xerxas> twb,  remind me that when I'll have wrote the patch 
<cjwatson> "tags 311512 patch" not "tags + 311512 patch"
<xerxas> but I don't think I will have :)
<twb> cjwatson: thanks
<cjwatson> or if you use the + put it after the bug number not before
<twb> The problem is actually that dh_make *is* dereferencing the directory name.
<twb> (Personally, I find it easier to just use mv(1) instead of ln(1).)
<xerxas> twb, I think the fix should be pretty simple 
<xerxas> isn't it ? 
<twb> xerxas: broadly, yes.
<twb> xerxas: but I'm not sure that it SHOULD be fixed.
<xerxas> why so ? 
<twb> xerxas: why can't you just use `mv foo foo-1.2' instead of `ln -s foo foo-1.2'?
<xerxas> twb, what about svn stuff ? 
<xerxas> or any vcs 
<twb> I don't understand the question.
<xerxas> you ln -s the directory , copy debian inside 
<Keybuk> don't suppose anyone knows how to stop the mouse inside vmware being so fast?
<xerxas> twb, if you build a package from a vcs, then the directory names are from the vcs 
<twb> xerxas: Debian .orig.tar.gz's should not contain CVS/ other SCM metadata.
<xerxas> making a link allows you to not mv every time you update 
<twb> xerxas: I suggest you take this to #debian-devel on irc.oftc.net.  This is not on-topic here.
<xerxas> twb, right !
<twb> Also, the denizens there will know more than I do.
<xerxas>  denizens ? 
<xerxas> what is it ? 
<xerxas> who are they ? 
<twb> denizen = person
<xerxas> twb, ok , thanks , sorry for my bad english 
<xerxas> patch made !
<twb> xerxas: no problem.
<xerxas> twb, "tags 311512 patch" it's the first line of the mail ? 
<xerxas> or the subject of it , 
<xerxas> ?
<twb> xerxas: OK.  In the body, the first two lines must be as follows:
<twb> tags 311512 + patch
<twb> thank you
<twb> ...OK?
<geser> Keybuk: could you please give back conglomerate to the buildds? thanks
<xerxas> twb,  yes , and the subject ? 
<xerxas> no subject ? 
<twb> The subject can be anything you like.
<cjwatson> you also have to CC to control@bugs.debian.org
<xerxas> <cjwatson> "tags 311512 patch" not "tags + 311512 patch"
<cjwatson> control commands such as "tags" aren't honoured otherwise
<twb> 22:41 <cjwatson> or if you use the + put it after the bug number not before
<xerxas> err, sorry 
<twb> cjwatson: aha, I did wonder.
<xerxas> where do I attach the patch ? 
<cjwatson> xerxas: an attachment in your mailer is fine
<xerxas> ok 
<twb> http://www.debian.org/Bugs/server-control
<twb> http://www.debian.org/Bugs/Developer
<xerxas> thanks guys, sorry for off-topic ! 
<twb> xerxas: those have all the information.
<Mithrandir> geser: given-back
<geser> Mithrandir: thanks
<dholbach> <ctrl>-<cursor> doesn't work in vim any more - did anybody else notice?
<_ion> I haven't ever used that key combination in vim.
<_ion> Aha, it's word-left/right. Use W/B/w/b
<dholbach> so it works for you?
<_ion> E/e to go to the end of the current word, and gE/ge to go to the end of the previous word.
<_ion> I tried it in gvim, it worked in it.
<_ion> But i never use arrow keys in vim.
<_ion> You have to move the right hand too much to use them. :-)
<cjwatson> it's listed in the help file; dunno why it broke
<dholbach> it used to work until yesterday or maybe the day before
<dholbach> doko: Alter! Is http://www.debian.org/doc/packaging-manuals/java-policy/ the key document for Debian java packaging?
<Lathiat> pitti: apache avahifying -> mod_dnssd -> http://0pointer.de/lennart/projects/mod_dnssd/
<pitti> Lathiat: hi! yup, already saw it
<Lathiat> pitti: :)
<pitti> Lathiat: btw, that recent security patch still seems to be buggy, did you see things like bug 72728?
<Ubugtu> Malone bug 72728 in avahi "Avahi possible regression in 0.6.10-0ubuntu3.2" [Undecided,In progress]  http://launchpad.net/bugs/72728
<pitti> Lathiat: I see that on my iBook, I need to restart avahi to make it see changes and even itself
<Lathiat> pitti: yeh i think some netlink messages are coming from elsewhere in some situations i've been a bit busy to debug it
<Lathiat> pitti: i might have a look at it now
<Lathiat> pitti: network manager seems to particularly upset it, it never sees the interfaces come up in the first place
<pitti> Lathiat: still weird, I thought netlink messages would only come from the kernel
<pitti> but I probably misunderstood the concept then
<Lathiat> no they dont
<Lathiat> for eaxmple, when avahi request s list of network interfaces
<Lathiat> the PID is set to that of avahi
<Lathiat> redhats original patch broke avahi _completely_
<pitti> the one which only checked for pid==0, I remember
<Lathiat> yeh
<Lathiat> so i guess they are coming from elsewhere too
<Lathiat> perhaps theres some other kidn of check we can do
* Lathiat fiddles
<pitti> Lathiat: can you only check the pid of the packet sender? or other properties, too?
<pitti> like, uid?
<Lathiat> err, avahi doesnt seem to compile on feisty
<Lathiat> iface-linux.c:192: error: invalid application of 'sizeof' to incomplete type 'struct ifaddrmsg' 
* Lathiat ponders
<Lathiat> oh i think i have a patch for this
<pitti> Lathiat: oh, not any more? it did one or two weeks ago
<Lathiat> i need to make a new release soon i'll try fix this
<pitti> Lathiat: #include <linux/if_addr.h>?
<Lathiat> pitti: avahi from svn
<pitti> ah
<pitti> Lathiat: ah, feisty's package has a patch
<pitti> debian/patches/80_undefined-macros.patch
<pitti> Lathiat: standard fix for kernel 2.6.19 headers
* Lathiat quietly mutters something about sending patches upstream ;)
<pitti> Lathiat: http://people.ubuntu.com/~pitti/tmp/avahi-2.6.19-compile.patch
<Lathiat> err i dont have that patch here
* Lathiat apt-get updates
<StevenK> I had to #include <linux/if.h> in aircrack-ng...
<pitti> Lathiat: I put it there on my people page
<Lathiat> so have they removed that from the headers?
<Lathiat> i love the casting in C sometimes
<pitti> Lathiat: right, apps have to define that themselves for some reason entirely unclear to me
<Lathiat> ok, how to duplicate this
<pitti> (after all, isn't the point of header files to provide such common and horrible things???)
<Lathiat> indeed
<StevenK> pitti: I thought so. :-)
* Lathiat tries network manager
<Lathiat> heh
<pitti> Lathiat: I can replicate it without problem on my laptop - in fact, avahi doesn't work at all until I restart it
<Lathiat> netlink.c: dropped message nlmsg_pid=10350
<pitti> OTOH, on my desktop it works reasonably fine
<Lathiat> netlink.c: dropped message nlmsg_pid=10308
<Lathiat> which is network manager
<pitti> Lathiat: hm, when I think about it, I don't use n-m on my desktop, so the dropped packets seem to confuse avahi eternally
<Lathiat> how do you get the network manager tray icon these days?
<pitti> Lathiat: Alt+F2 nm-applet
<Lathiat> err
<Lathiat> netlink.c: dropped message nlmsg_pid=1536174148
* Lathiat puzzles
<pitti> ugh
* Lathiat checks the data type of that
<Lathiat> __u32
<pitti> a 16 bit int put into an uninit'ed 32 bit int?
<Lathiat> yeh i put %d
<Lathiat> excuse my apparent incomptence what printf argument do i want to print a __u32 ?
<pitti> Lathiat: I thought %d should DTRT for 32 bit, and indeed it prints out a 32 bit number
<Lathiat> yeh
<Lathiat> weird
<pitti> Lathiat: maybe it is written with some pointer conversion magic and only the lower 16 bits get filled?
* Lathiat figures out the contents of that message
<pitti> Lathiat: 1536174148 & 65535 == 64100
<cjwatson> I'd probably use printf("%lu", (unsigned long) u32_variable) myself ...
<pitti> Lathiat: do you happen to have a process with that number? (although unlikely)
<Lathiat> nope
<pitti> Lathiat: for the record, same behavior with 2.6.17, so it's not the new kernel
<Lathiat> interesting network manager makes avahi see
<Lathiat> new interface / withdrawn / net interfaces / withdrawn / new interface
<Lathiat> when enabled (from an alreayd disabled state)
<Lathiat> hrm
<Lathiat> netlink.c: would drop message nlmsg_pid=1536174148 
<Lathiat> New relevant interface eth0.IPv4 for mDNS.
<Lathiat> i cant reproduce that
<Lathiat> ah, yes i can
<Lathiat> this is weird
<Lathiat> pitti: do you know much about how network manager works?
<pitti> Lathiat: not really at the internals
<Lathiat> i see the interface come relevant from root, then disappear, then ti comes back but it fails to join the multicast group
<Lathiat> then its withdrawn from a non root pid
<Lathiat> then comes back from a non root pid
<Lathiat> which if im not dropping them, works
<pitti> Lathiat: I uploaded a new n-m yesterday that disables the internal ipv4ll stack and checks for avahi-autoipd (which is called automatically in latest feisty)
<Lathiat> is there another tool that will monitor ip changes off netlink?
<pitti> Keybuk: ^ do you happen to know?
<Lathiat> hrm, yes, iproute2 has a monitor mode
* Lathiat compares
<Lathiat> yeh network manager definitely adds and removes the ips twice then adds it again
<Lathiat> dhclient byitself does it once
<Lathiat> does network-manager use dhclient?
<giskard> yes
<pitti> Lathiat: it calls dhcdbd which calls dhclient
<StevenK> No, it uses the dbus dhcp client.
<StevenK> Ah. It does, just indirectly.
* StevenK updates his internal mapping.
<pitti> Lathiat: so first it calls dhclient, if that times out, dhclient calls avahi-autoipd through the dhclient-exit-hooks.d script
<pitti> Lathiat: during that process, the interface might go up twice (but shouldn't)
<pitti> Lathiat: which version of n-m do you have?
<Lathiat> Version: 0.6.3-2ubuntu7
<pitti> ok, that should just use avahi-autoipd
<giskard> pitti, uh! i will grab this patch
<Lathiat> so even with using ifconfig, it triggers a series of events that sees the ip added, removed and added again, but network manager seems to remove and add them again
<pitti> giskard: which patch?
<giskard> avahi-autoipd..
<pitti> giskard: if it's the n-m one, I'm about to send it to upstream after it got some initial testing in feisty
<giskard> pitti, do you think it's not "stable" enough?
<pitti> giskard: I discussed the approach with Dan a bit, and he seems to agree; however, my patch is pretty hackish because I didn't want to rewrite half of the logic
<pitti> giskard: oh, it's not unstable, it's just not a nice patch
<giskard> oki
<Lathiat> pitti: what happens on yoru laptop, is it after a certain time it stops working?
<pitti> giskard: the only operational flaw that I see is that the IP address will be shown as '0' in the properties
<pitti> giskard: i. e. it doesn't read it out from the ethX:avahi interface
<pitti> Lathiat: it never really starts working until I restart it
<Lathiat> pitti: so if you start avahi, then use network manager to get an ip
<Lathiat> it doesnt work at all
<pitti> Lathiat: right
<Lathiat> does it do that on a clean boot?
<Lathiat> straight away?
<pitti> Lathiat: ok, TBH I didn't try it recently before I fiddled with n-j
<pitti> n-m even
* pitti tries
<Lathiat> (not a suspend,e tc)
<pitti> Lathiat: is "'avahi-browse -ta' not empty" a sufficient test?
<Lathiat> pitti: ok, your right, i can reproduce that
<Lathiat> start avahi, then use network manager, cant do anything
<Lathiat> i will debug from here
<pitti> great
<pitti> I cross-check on my box
* pitti wonders how hal verifies netlink packets
<Lathiat> and it works if i revert that patch
<Lathiat> i only tested the case of starting avahi with a network already up when i did that patch
<Lathiat> guess i should have done more :/
<pitti> yay, laptop doesn't boot
<Lathiat> and it works using ifconfig
<Lathiat> but not network manager
<Lathiat> i've had this problem befor
<Lathiat> enetwork manager was triggering a different code patch
<Lathiat> *path
<Lathiat> and it works fine with dhclient, just not network manager
<Lathiat> it seems that extra withdraw and add does something magic
<Lathiat> yep, avahi hasnt joined the multicast group
<Lathiat> obviously when it withdraws the interface it drops the membership
<Lathiat> and when it comes back, we're dropping that message because it comes from pid != 0
<Lathiat> so i'll have to chase that up
<Lathiat> thanks for your help
<Lathiat> know anyone that knows network manager enough to have an explanation of why it seems to cause that?
<doko> dholbach: yes, plus some/one wiki page(s)
<dholbach> doko: alright, I needed it to review a java package - if you could give me a link to those wiki pages, that'd be great - for telepathy-wilde and friends too
<dholbach> doko: is that on wiki.debian.net? if so, I shold just be able to find it
<StevenK> Hah, neat. mjg59 has the same problem with Planet Debian that I do.
<sivang> doko: when will we sart with the python transition frenzy? :)
<sivang> (e.g. managing packages that are affected by the new policy, new spec from UDS as well)
<pitti> Lathiat: hal enables sender credentials and refuses uid != 0
<pitti> Lathiat: we probably need the avahi-daemon uid, too, but would something like that work?
<Lathiat> where do you get the uid from?
* pitti msgs some bits
<doko> dholbach: yes, I think it's wiki.debian.net
<jsgotangco> hey sabdfl
<sabdfl> hi jerome
<xerxas_> sabdfl, while you're here, do you know if there's something new on the ambassdor role ? 
<xerxas_> ambassador 
<xerxas_> (if you remember the issue ) 
<sivang> xerxas: forum ambassador?
<xerxas> sivang,  during classrooms we talked about an ambassador role in launchpad / malone 
<xerxas> that would be a role for a assigned to someone for a package , that would be the contact for upstream work
<sivang> xerxas: ah, I see, nice
<cjwatson> pitti: mind if I assign increase-hwdb-participation to you, and you can assign it on further if you don't have time for it?
<cjwatson> (and somebody else does)
<cjwatson> I definitely don't have time :)
<pitti> cjwatson: that's fine
* pitti will implement other specs as fast as possible
<cjwatson> thanks, done
<bddebian> Howdy
<cjwatson> rodarvus: what's happening with bullet-proof-x?
<doko> cjwatson, infinity: should it be considerd a bug, if a universe package is able to build with a multiverse build dependency?
<cjwatson> is able to? no. requires? yes
<cjwatson> if a universe package requires multiverse to build, please file a bug on the package and CC ubuntu-archive to request that we move it to multiverse
<doko> ohh, mysql-connector-java never needed a build since warty
<Riddell> mvo: what does the complex input tickbox do in the feisty gnome language-selector?
<dholbach> doko: gracias
<sivang> can anyone suggest a good package that used debhelper tp update po files? it appears that irda-utils doesn't even include a manual target in debian/rules for updating the translations, I'd like to fix that by adding it. Can someone suggest how?
<sivang> "good package" = goot to learn from
<cjwatson> sivang: you mean stuff in debian/po/
<cjwatson> ?
<sivang> cjwatson: exactly
<cjwatson> sivang: just running debconf-updatepo is usual; I've never seen anyone bother with a debian/rules target for that
<cjwatson> since it's easier to type the command and then it's the same for all packages that have translated debconf templates :)
<sivang> cjwatson: will this also handle updates to the .pot file?
<cjwatson> yes
<cjwatson> see its man page with the command-line options
<sivang> cjwatson: cool , thanks. Somehow I got the wrong impression this needs to happen when building
<sivang> ;)
<cjwatson> it's more usual to run it before building the source package, so that they're up to date in the source
<sivang> cjwatson: right, makes more sense actually, I had based this impression on the gdebi package upon which I based my hubackup package.
<sivang> cjwatson: mvo included there a call to update pot/po files in the form of a call to intltool
<sivang> cjwatson: http://paste.ubuntu-nl.org/35783/ , but this is in setup.py
<cjwatson> sivang: that tends to happen for .pot/.po files outside debian/po/, since the process for updating those is less consistent
<sivang> cjwatson: right, mucho gracias for the help :)
<sivang> cjwatson: on a related note, the changes inside ubuntu's irda-utils for attaching to device while booting is due to the upstart change yes?
<sivang> cjwatson: (e.g. we have a complete question there that is local to us)
<cjwatson> sivang: no idea; I'm not familiar with that package
<slomo> rodarvus: ping?
<cjwatson> TypeError: argument 1 of QButtonGroup() has an invalid type
* cjwatson pokes Qt with a big stick
<sivang> Lathiat: do you know if the prop. ATI driver already merged and installable in fesity?
<iwj> cjwatson: You were right about MarkKeep.
<iwj> I didn't spot this bug in my earlier testing because I foolishly assumed that if upgrade worked so would dist-upgrade.
<iwj> mvo: Do we have the dist-upgrader capable of upgrading dpkg and apt first, yet ?
* pitti grumbles about modprobe nvidia failing
<_ion> benc: nVidia released 1.0.6931, which should fix bug #72805.
<Ubugtu> Malone bug 72805 in linux-restricted-modules-2.6.19 "nvidia-glx 1.0.9629 causes OpenGL programs to segfault on NV2x hardware" [Medium,Confirmed]  http://launchpad.net/bugs/72805
<BenC> _ion: thanks
<cjwatson> iwj: I couldn't get MarkKeep to DTRT in my experiments, but I didn't really understand the structure of that code and didn't play with it for very long. Glad it worked for you.
<sivang> Keybuk: around?
<Keybuk> sivang: always
<sivang> Keybuk: in irda-utils, there are ubuntu changes that add another question to the debconf templtes, for changelog matters, I have assumed this this to accomodate upstart changes? can you please confirm or advice otherwise?
<Keybuk> not that I'm aware of
<sivang> Keybuk: okay, I'll ask mjg59  then, he also touched it
<sivang> mjg59: ^^^
<Keybuk> what's the question?
<Keybuk> irda-utils (0.9.16-9ubuntu1) breezy; urgency=low
<Keybuk>   * Add autoconfiguration support (Debian #324404)
<Keybuk>  -- Matthew Garrett <mjg59@srcf.ucam.org>  Tue, 30 Aug 2005 13:57:21 +0100
<Keybuk> ?
<Ubugtu> Debian bug 324404 in irda-utils "irda-utils: Where possible, use PNP to autoconfigure IrDA" [Wishlist,Open]  http://bugs.debian.org/324404
<sivang> Keybuk: right, but where is that recorded in ubuntu packge where it's already implemented?
<sivang> Keybuk: (changelog, that is)
<sivang> Keybuk: oh sorry, found it now
<sivang> Keybuk: rather, became unblind now :)
<sivang> Keybuk: thanks, and sorry for this terrible noise
<Keybuk> :)
<jdong> Keybuk: can you spare a moment to do a quick backport so someone stops nagging me?
<jdong> this wonderful offer also is available to any other archive admins :D
<Keybuk> I'd prefer not to do "quick" backports ;)  bad things happen
<jdong> Keybuk: mediawiki1.7 needs backporting
<jdong> Keybuk: last week only the metapackage mediawiki was backported
<jdong> which needless to say does nothing :)
<pitti> a-haa
<jdong> I forgot to mention in the bug report that both packages need to be backported
<Keybuk> heh
<Keybuk> jdong: from/to?
<jdong> feisty->{dapper,edgy}
<pitti> slomo: when a sudo'ed program tries to talk to the notification daemon and it hangs, that'd be our famous dbus bug again, right?
<cjwatson> Riddell: could you have a look at kde-ui.py in http://bazaar.launchpad.net/~ubuntu-core-dev/ubiquity/trunk/ and tell me what I'm doing wrong in set_autopartition_choices that means none of the child widgets get shown?
<slomo> pitti: dbus-glib bug, right
<cjwatson> I fixed a few crashes just now, but now it does nothing useful
<pitti> slomo: so since I actually want it to connect to the user's notifyd, I could just apply a similar patch, right?
<dholbach> doko: does <ctrl>-<cursor> give you "5C" in the terminal too? I tried emacs vs. vi now and gnome-terminal vs. xterm - all of them have the same behaviour - could that be libreadline?
<pitti> slomo: or is the get_dbus() thing supposed to properly connect to the user's bus even with uid==0?
<Riddell> cjwatson: branching
<Keybuk> jdong: ok, done
<jdong> Keybuk: thank you! when I get rich and famous you can have a share of my fortune :)
<jdong> (though I wouldn't bank on that)
<slomo> pitti: dbus_bus_get() should return error if uid!=session_bus_uid... so you should apply a setuid patch as for time-admin :)
<pitti> slomo: ok, great; I'll do that then
* pitti hugs slomo
* slomo hugs pitti :)
<slomo> pitti: and it's definitely by design that even connections by uid 0 are rejected... though dbus-glib has this nice deadlock bug somewhere ;)
<cr3> I'm netinstalling feisty herd 1 and I'm getting a failed installation step because: evolution-data-server: Breaks: evolution (< 2.9) but 2.8.1-0ubuntu4 is to be installed
<cr3> is this worth reporting or perhaps I am doing something terribly wrong?
<jdong> cr3: well, you can't really netinstall "herd 1"
<jdong> cr3: you're netinstalling today's feisty :)
<BenC> cr3: The bad thing about net-installs is that you will always be using the current day's packages, where as with a CD install, you are getting a know good set
<doko> dholbach: no, I don't get any characters
<cr3> BenC: during this testing phase, do you think it's actually better to be testing directly against the archive in preparation for building a good known set?
<dholbach> doko: hrm.... I have this since yesterday or the day before on all of my machines - in the shell it's all fine, but in the editor it breaks for me
<BenC> cr3: If you plan on test more than at every herd-X, then netinstall is best
<BenC> my typing sucks, I need sleep
<Riddell> mvo: should the "Input Method" tickbox get disabled in language selector for languages that don't use scim?
<cr3> BenC: good point, so I need to find a way to netinstall using the files from an ISO then
<cr3> BenC: sleep or more coffee
<dade`> macbooks need sleep too
<jdong> cr3: oh, do you not have a CD drive or something like that?
<BenC> jdong: he's trying to automate it over lots of machines
<jdong> oh
<cr3> jdong: what BenC said, and it's not as trivial as I had originally thought :)
<mvo> Riddell: no, just unchecked. the goal is to allow people to have a english environment but still use scim 
<jdong> cr3: considered cheating yet?
<jdong> cr3: like installing one and then cloning it to all the rest :D
<cr3> jdong: the installation process is part of the test :)
<jdong> pffft :)
<cjwatson> Riddell: (checkout (over sftp) may be your friend)
<cjwatson> depends if you want to commit without bothering with a separate branch
<alex-weej> does anyone else think that feisty using compiz/beryl instead of metacity is a bad idea simply because it's just not GNOME anymore?
<jdong> alex-weej: but it's shiny. Shiny always better. shiny shiny shiny
<Keybuk> alex-weej: GNOME appears to be considering compiz
<alex-weej> Keybuk: interesting
<alex-weej> Keybuk: well if they consider Metacity to be a POS then i suppose why not
<Keybuk> I suspect it's more that they consider metacity to not be a compositing window manager
<Solarion> is splice() in the current glibc, or will it be in feisty?
<Keybuk> Solarion: it's in feisty's libc
<Keybuk> the edgy kernel supports it, so you can declare it on your own
<Keybuk> syscall (SYS_splice, ...)
<Solarion> Keybuk: Ah.  I had wondered.
<Solarion> I'll help field-test feisty when it's time
<Solarion> then the splice tasty will be mine
<jdong> hmm, rapidly rolling my mousewheel over the taskbar area triggers the Urgent notification on windows
<alex-weej> what package is dbus-viewer in these days?
<alex-weej> jdong: reproducable
<jdong> is it a bug?
<alex-weej> i guess it's because windows try to raise themselves as soon as they are clicked
<alex-weej> but by the time that happens
<alex-weej> you've already activated another window
<jdong> yeah, that's what I thought too
<alex-weej> and the WM won't let it take focus 
<jdong> and it doesn't sound like there's an easy fix
<alex-weej> no
<alex-weej> other than changing the behaviour of scrollwheel on the window list
<alex-weej> to be totally honest with you i don't think it's a good feature
<alex-weej> i love being able to scroll through tabs and the workspace switcher
<jdong> alex-weej: yeah, i.e. don't allow another window selection until the first one is raised....
<alex-weej> but it just seems a bit odd on the wlist
<jdong> though that could result in a hang condition
<alex-weej> jdong: yeah it could block but that would make it slow
<alex-weej> jdong: the most seamless fix would be to make the windows raise, but not steal focus
<alex-weej> jdong: but that would require to hint the WM as to what is going on
<alex-weej> jdong: as windows don't normally raise if they won't have focus
<alex-weej> then again, i know toss all about WMs, so i might be barking up the wrong tree
<alex-weej> piss. i've forgotten how to use dbus.
<mjg59> sivang: Nothing to do with upstart
<zorglu_> q. i would like to link a programm with glibc in static under ubuntu, is there a package to get gnu libc in static ? (aka without the nss kludge) aka to avoid this kind of message during static linking/usr/lib/libglib-2.0.a(gutils.o): In function `g_get_any_init_do': warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking 
<mdz> Keybuk: say, what's behind the uploads with changed-by: merge-o-matic?
<Keybuk> mdz: doko :p
<mdz> Keybuk: folks forgetting to update the generated changelog?
<mdz> Keybuk: did you say something to him about it already?
<Keybuk> yeah, already pointed it out to him
<doko> yes, he did
<mdz> thanks
<Keybuk> soyuz appears to have lost the "CHANGELOG MENTIONS YOUR MOM!" test that katie had
<Keybuk> last time I asked about adding a check to the uploader, it was suggesting that rewriting the buildd code was easier, so *shrug8
<cjwatson> I know they reckon NascentUpload is horrible, but I don't understand why it's hard to add another check. All it needs is a blacklist of changed-by addresses checked in verify_changes() *shrug*
<sivang> mjg59: right, sorry, Keybuk already referenced me to the changelog entry.  I was just being blind
<bronson> I've built linux-vserver-enabled Dapper and Edgy kernels by following https://wiki.ubuntu.com/KernelCustomBuild
<bronson> works beautifully except for one thing: linux-headers-2.6.17-10-ref-386_2.6.17.1-10.34_i386.deb
<bronson> Where does -ref- come from?  I'd like to change it to -vserver-2.2.0-
<zorglu_> no taker for my question about glibc and static linking ?
<zorglu_> q. is there a channel for people coding on ubuntu ?
<jelmer> I think that's what this channel is intended to be :-)
<cjwatson> no, it's not
<zorglu_> well :) here all my questions are plain ignored :)
<cjwatson> this channel is for the development *of* Ubuntu
<zorglu_> cjwatson: and is there a channel for people coding on ubuntu ?
<cjwatson> not to my knowledge, but your question is not Ubuntu-specific anyway
<bronson> zorglu_: it's a pretty obscure question.  Not many here would have ever done that before.
<bronson> At least, I haven't.  :)
<bronson> anyway, don't feel bad.  My Ubuntu-related kernel question is being ignored too...
<twb> zorglu_: your question would be better addressed to a GCC or glibc forum.  (That's forum as in "a place of discussion",  not forum as in "web forum".)
<twb> zorglu_: plenty of people in here don't even write C programs.  This channel is for people packaging software for Ubuntu, and people building tools to facilitate that.
<zorglu_> for info, the question is ubuntu related as it is directly in relation on how glibc is packaged. but cjwatson answered me privatly
<twb> Oh, I see.
<twb> Excuse my ignorance, then :-)
<zorglu_> and the answer is that it is not possible to link in static under ubuntu except if you compile your own glibc :)
<mjg59> zorglu_: The question is Ubuntu-related, but still not on-topic for this channel
<bronson> Does anyone know why the kernel version appears twice in my AUTOBUILD=1 kernel debs?
<kylem> bronson, why don't you try asking on #ubuntu-kernel?
<zorglu_> i understood that, just fixing the misconception about how related it was to ubuntu
<bronson> kylem: good call; I didn't even realize that existed.  ;)
<kylem> bronson, it appears once because it's in the package name, and once because of the version number of the package.
<kylem> linux-headers-2.6.17-10-ref-386 is the name, 2.6.17.1-10.34 is the version
<kylem> anyway, brb. lunch.
<bronson> kylem: thanks
* bronson investigates
<Riddell> cjwatson: it's something funky to do with having two QButtonGroups for one frame
<zorglu_> as a suggestion, if somebody asks a question offtopic, i think it is nicer to say 'this is offtopic dont ask this here' that plainly ignore him :)
<cjwatson> oh, whee
<zorglu_> see ya :)
<kylem> i'm not sure about the "ref" thing, please ask in #ubuntu-kernel, i'll look if you've not found by the time i get back from lunch.
<Riddell> cjwatson: this fixes it by adding another frame inside the autopartition_frame http://kubuntu.org/~jriddell/ubiquity-part-auto.diff
<Riddell> (without the changed build-deps obviously)
<cjwatson> Riddell: thanks; I'll have a look tomorrow
<cjwatson> (phone call now, then finishing up for the day)
<Riddell> mvo: what happening during the "checking available language support" progress bar in gnome-language-selector?
<hunger> Is NM currently broken? It hangs trying to get a IP here... dhclient eth0 works fine though.
<mvo> Riddell: it reads the apt cache and checks for the available packages
<Riddell> mvo: it seems to take longer than the qt version, which has no progress bar but presumably does the same thing
<mvo> Riddell: right. I can check that, it possible that this is the actual checking code that was not ported yet to the common/ code. or its something stupid/wrong happening in the gtk frontend
<Riddell> mvo: or it might just be my imagination
<mvo> :)
<_ion> hunger: Probably something with interaction between dhclient and avahi-autoipd is broken.
<madduck> df/l
<madduck> sorry
* LarstiQ 1.84m
<sivang> Lathiat: hey dude, you around?
<mjg59> Wow
<bddebian> wow?
<mjg59> Evolution deals really badly with imap folders containing 160000 mails
<_ion> Heh.
<bronson> mjg59: It deals badly with folders containing 1600 messages.  :)
<ppd> hi. I'm sorry for writing here, but I have to ask whether there's some progress fixing the problem that you can't print multiple pages with evince in ubuntu?
<Adri2000> ppd: bug number?
<ppd> Adri2000: I guess it's  https://launchpad.net/distros/ubuntu/+source/evince/+bug/67164 
<Ubugtu> Malone bug 67164 in gtk "Evince print dialog doesn't respect page setup settings" [Unknown,Unconfirmed]  
<LaserJock> ppd: looks like people are definately aware of it
<Lathiat> sivang: am now
<bluefoxicy> huh
<bluefoxicy> Anyone know when security-best-practice became security-vulnerability from Ubuntu's POV, and why I wasn't notified?
* bluefoxicy points at bug 49323
<Ubugtu> Malone bug 49323 in gnupg "gnupg executable stack fix" [Undecided,Confirmed]  http://launchpad.net/bugs/49323
<bluefoxicy> ..... oh thanks Ubugtu, I'm going to have loads of fun with you.  *starts looking for security-sensitive flagged bugs that he can't access*
<bluefoxicy> actually I wonder if that's hidden.
<mjg59> bluefoxicy: Given that ubugtu runs as an unprivileged user...
<mjg59> ubugtu debian 400000
<Ubugtu> Debian bug 400000 in libroxen-imho "libroxen-imho: [INTL:fr]  French debconf templates translation" [Wishlist,Closed]  http://bugs.debian.org/400000
<keescook> bluefoxicy: it's just something I wanted to watch, so I marked it a security vuln.  But you're right, I should just subscribe instead.
<bluefoxicy> mjg59:  yes, interesting.  That bug is marked as a security vulnerability now (for some reason); I was wondering 1) why; and 2) doesn't that hide the bug from normal users?
<bluefoxicy> keescook:  nods.  Not that I'm complaining about the added attention mind you; just I tried that angle before and was told that it was just wishlist-priority (for gaim) (which I fixed)
<keescook> bluefoxicy: there's a difference between "security" and "private"
<bluefoxicy> keescook:  ah.  On most (mozilla at least, and gentoo IIRC) bugzillas security == zomg nondisclosure
<keescook> I was scratching my head for a while when I first read it because there isn't any amd64 asm, so gpg on my machine doesn't have an exec stack.  :P  showed up (obviously) in the i386 chroot
<bluefoxicy> keescook:  by any chance were you interested in looking for these yourself?  :)
<keescook> yeah, it's on my list of general cleanups, hardening, etc.
<bluefoxicy> nods.  Install pax-utils, scanelf -qeR /bin (or /lib or /usr or any combination), and there you go.  There's some good docs .. actually you can just follow the link that's on that bug ;)
<keescook> bluefoxicy: if you've been collecting these, can you make a wiki page (if there isn't one already) of the program that need the exec-stack fixes?
<keescook> yeah, the gentoo hardening docs are great.
<bluefoxicy> keescook:  it's easy enough to generate your own; but sure.  I should move HardenedHacking somewhere easier... and clean it up.
<jdong> bluefoxicy: my grsec+PaX is still acting like while true; do echo Segmentation Fault; done
<keescook> also on my list is to recompile all of main with PIE and see if I still have a functional system.  :)
<jdong> it took them 400 lines of code to accomplish what one bash line could :)
<jdong> </sarcasm>
<bluefoxicy> keescook:  Gentoo is great in general.  Walk their Portage CVS tree, and you'll find tons of patches to kill executable stacks or PIC violations and such.  It probably wouldn't hurt to get in touch with their hardened herd... (bhale/tseng is a former dev)
<LarstiQ> jdong: if all it does is echo.. :)O
<keescook> jdong: hehe, I need to make that into a t-shirt:    while :; do kill -SEGV $$; done
<jdong> :)
<jdong> grsec v3
<jdong> ultimate security
<jdong> bugs: can't secure /sbin/init
<bluefoxicy> jdong:  which kernel version, and can I see your .config for reference (I'll poke #grsecurity on OFTC and see if they see anything; but you'd really be better off asking there)
<jdong> 2.6.19-ish
<jdong> anyway
<jdong> I'm saving trying grsec again for another day
<bluefoxicy> huh.. is that released or from ~/spender?
<jdong> I have better uses of my time for now :)
<jdong> it was the latest released one I found on grsecurity.org
* keescook runs off to snag some lunch
<bluefoxicy> the latest is for .18
<bluefoxicy> I suggest you don't try to wedge it into .19, brad is having problems making that work himself ;)
<jdong> then I meant .18
<jdong> I knew it matched
<jdong> yeah, it was 18
<bluefoxicy> ah ok
<jdong> and I wouldn't try something that silly
<bluefoxicy> jdong:  .config?
<jdong> bleh, I just collapsed all my bzr kernel trees
<jdong> I'll deal with it later
<bluefoxicy> ok
<jdong> we've talked about this before, bluefoxicy :)
<jdong> that was my grsec day :)
<bluefoxicy> yes :P
<jdong> today's my find more bzr bugs day :)
<bluefoxicy> haha
<bluefoxicy> <Bluefox> <jdong> bluefoxicy: my grsec+PaX is still acting like while true; do echo Segmentation Fault; done
<bluefoxicy> <pipacs> tell him that was a very useful bug report
<jdong> LOL
<jdong> you weren't actually supposed to tell them that :D
<bluefoxicy> haha
<jdong> tell him that our senses of humor are quite alike :)
<bluefoxicy> jdong:  if you actually get a chance, can you get a core so you can get a back trace?  Also pipacs is asking you to come over to #grsecurity or #pax on OFTC when you get time
<bluefoxicy> jdong:  and try vdso=0 on the kernel command line if it's breaking that early
<jdong> I will when I get a chance
<bluefoxicy> nods
<jdong> and yeah it's segfaulting in initrd
<bluefoxicy> http://forums.grsecurity.net./viewtopic.php?t=1617
<jdong> in insmod
<jdong> so there's _NO_ system :)
<jdong> bluefoxicy: yeah that vdso forum post looks like exactly what I'm experiencing
<jdong> bluefoxicy: I'm gonna give that a shot sometime this wweekend
<jdong> I'd still like a grsec-hardened kernel for me server
<bluefoxicy> jdong:  he also says something about using the one in ~spender/ for 2.6.19
<bluefoxicy> http://www.grsecurity.net/~spender/dsc18910.jpg
<bluefoxicy> whoops, that's not it
<bluefoxicy> http://www.grsecurity.net/~spender/grsecurity-2.1.9-2.6.19-200612061905.patch
<jdong> bluefoxicy: tell him thanks
<bluefoxicy> k
<jdong> yay for resurrecting my kernel trees :)
<ulaas> sudo apt-get dist-upgrade
<Mithrandir> Lure: thanks for your patch; I'll take a look at it tomorrow.
<Lure> Mithrandir: thank you 
<geser> Mithrandir: could you please give-back gaim-libnotify?
<Mithrandir> geser: done
<geser> thanks
<Mithrandir> and with that, I'm off to bed.
<_ion> Gaim has libnotify support? That's great.
<psusi> right now filesystems are auto mounted by gnome-volume-manager calling pmount when it gets wind of a new disk from hald which finds out about it from udev right?
<psusi> is the goal for fiesty to move to udev doing the mount?  or only to take care of the md/lvm/dmraid parts and leave g-v-m to mount the fs?
<shaya> weird Q, is there a good document anywhere that explains how apt does dependency resolving?
<shaya> or can someone give me a quick and dirty explanation
<shawarma> Where are the ddebs stored? Still in pitti's public_html ?
<shawarma> shaya: About the code or the policy?
<shaya> not so much policy, but given package X, how does it determine closed set of packages it needs to install
<shaya> basically looking for something for a writeup I'm doing (where basically saying we don't need to focus on dependency resolving as its a solved problem)
<psusi> it looks at the packages that one depends on and if they aren't already isntalled, installs them?
<shaya> true, I'm more looking for a specific term, basically we have a huge package graph
<shaya> or directed graph
<shaya> where package nodes point to the package nodes they depend on
<shaya> when you want to install package A, apt-get has to create a "term I don't know"
<psusi> it doesn't have to create anything
<psusi> it just installs the packages listed in the depends header
<psusi> and in doing so, may end up  installing more packages listed in THOSE depends
<shawarma> shaya: You're maybe thinking of the dependency tree?
<shawarma> shaya: And it seems that you're actually curious about the policy that governs what apt is supposed to do rather than the actual code in apt. :-)
<shawarma> shaya: ...and the policy is the debian policy.
<shawarma> shaya: You're still free to ask, of course.
<barrett9h> gcc -m32 won't work on my ubuntu64 system
<barrett9h> can't find stubs-32.h
<shaya> the term I'm looking for is transitive closure
<shaya> basically there's a dependency graph, and apt-get searches for the transitive closure
<geser> barrett9h: install libc6-dev-i386
#ubuntu-devel 2006-12-08
<ailean> composite-by-default has been deferred? :(
<gnomefreak> ailean: not sure i know a package was rejected because it didnt build fine
<ailean> gnomefreak, i just see the deferred notice on LP
<ailean> gnomefreak, i hope not - i really think it's what ubuntu and desktop linux needs
<gnomefreak> i never looked i think its a  big thing with the binary drivers by default
<ailean> well of course i understand that
<ailean> sabdfl convinced me on the subject though :)
<gnomefreak> it was a good idea and i know the beryl devs are working towards it but the binary thing and the fail to build maybe why its deffered but i never saw the notice.
<Burgwork> I never saw it either
<ailean> nahh, i just mean that it's marked as deferred. i didn't see any statement or anything
<gnomefreak> beryl-core was i heard a FTB
<gnomefreak> you have link handy?
<ailean> https://blueprints.launchpad.net/distros/ubuntu/feisty/+specs
<gnomefreak> ty
<ailean> https://blueprints.launchpad.net/distros/ubuntu/+spec/composite-by-default even
<Burgwork> I just don't see any notice in my email, which is odd
<ailean> Burgwork, don't worry -  i haven't received any email about it or anything
<ailean> misunderstanding :)
<gnomefreak> it would have been in feisty-changes?
<ailean> all i saw was the word "deferred"
<ailean> well i'm subscribed to this feature and didn't receive any email about it
<Burgwork> it could be that those changes don't trigger bug mail, which is odd
<ailean> it's just weird that it's essential, but deferred :)
<Burgwork> not the only spec
<ailean> surely if it was essential, they'd find the time to work on it :D
<gnomefreak> i will find out from the effects team whats going on im sure someone there knows. wish i was able to be kept up-to-date being owner of it
<ailean> lol
<ailean> is it possible that some eedjit just went in and changed it without anyone's knowledge?
<ailean> no. it won't let me
<ailean> i'm not important enough
<Burgwork> only keybuk or sabdfl can do that
<gnomefreak> keybuk isnt on atm maybe ill ping him later im sure he did it
<gnomefreak> asbdfl wanted it way too bad to deffer it this early i would think
<Burgwork> mdz may also have done it, now that I think about it
<gnomefreak> s/asbdfl/sabdfl
<gnomefreak> he can change it?
<ailean> i'm glad you agree it's strange
<Burgwork> yes, as he is the registrant
<ailean> unless they decided to go with the metacity composite work . . .
<gnomefreak> beryl-core must really be screwed up if the FTB is the reason
<ailean> FTB?
<ailean> failure to build?
<Burgwork> FTBFS is the more common term
<Burgwork> the metacity stuff is dead
<ailean> what about compiz though, that was a serious option
<Burgwork> soren is now working on compiz
<ailean> why is it dead?
<Burgwork> because it is
<ailean> no one working on it?
<bhale> s'what he said
<ailean> yeah, it doesn't quite explain though :)
<bhale> soren wrote it, and has since moved on to compiz
<bhale> it happens
<ailean> oh right
<Burgwork> compiz has major issues as well
<Burgwork> I wonder if my blog post has anything to do with this
<ailean> someone's changed it
<ailean> cool, back to drafting
<ailean> i'm happier
<Burgwork> hmm, just changed again
<ailean> not for me
<Burgwork> changed from deferred to not started
<gnomefreak> yes its fixed just waits for upload to hit repos :)
<ailean> this was the one feature i wanted to see in the default installation
<ailean> hrm . . . "Sony Adds PS3 Support to Linux Kernel" http://games.slashdot.org/article.pl?sid=06/12/07/211214
<frandavid100> hello
<frandavid100> I'd like to file a bug against the open dialog, what package would be the correct one?
<frandavid100> anyone there?
<xerxas> the open dialog ?
<frandavid100> the open file dialog that appears on any gnome app
<frandavid100> since it's the same in every app, I assume it must be a separate package
<xerxas> I don't understand
<xerxas> but maybe I don't have enough knowledge 
<xerxas> ok 
<xerxas> sorry 
<xerxas> I got it 
<xerxas> that should be gtk ? 
<xerxas> not sure 
<crimsun> if you mean the file chooser, yes, that's gtk+2.0
<frandavid100> well I could try filing it in gtk
<frandavid100> you sure?
<frandavid100> fine then thanks ^^
<frandavid100> alright, bug filed
<frandavid100> https://launchpad.net/distros/ubuntu/+source/gtk+2.0/+bug/74907
<Ubugtu> Malone bug 74907 in gtk+2.0 "nautilus and the "open file" dialog" [Undecided,Unconfirmed]  
<frandavid100> thanks for your help guys, good night!
<crimsun> seb's going to have a field day with that one.
<wasabi> anybody able to speak as to the installability of a feisty daily cd build?
<wasabi> (i have a system that requires 2.6.18+)
<jdong> wasabi: early today it was mentioned that e-d-s was uninstallable
<jdong> wasabi: I'd still say get a herd1 cd :)
<wasabi> grabbing the latest daily build right now. i'll grab a herd1 just in case.
<wasabi> need a solution when i get into work tomorrow. =/
<wasabi> new intel mobo. achi stuff.
<wasabi> ahci
<jdong> ouch
<jdong> yeah
<wasabi> Wonder how hard it would be to backport feisty's kernel to edgy.
<wasabi> probably pretty easy... would just have to go through the trouble of actually making a custom installer.
<kylem> eh? why bother, what pci ids? you can probably work around.
<wasabi> hmm. guess a usb cdrom drive would solve the problem too.
<wasabi> It just can't read the IDE CDRom.
<wasabi> It gets the SATA drives fine though.
<kylem> hmm.
<jdong> kylem: lack of chipset support :(
<jdong> kylem: it's a known issue with like the Core 2 Duo desktop chipsets
<jdong> like the 965/975's
<wasabi> ayup. that'd be me.
<jdong> they have really odd IDE chipsets
<wasabi> dg965
<jdong> that were merged in 2.6.18
<jdong> we tried backporting to 2.6.17 but none of those cherrypicks seem complete enough
<wasabi> are they odd as in "new" or odd as in "stupid?"
<jdong> wasabi: new
<jdong> as in, instead of a shiny well supported intel ICH* chipset
<jdong> you get some random unknown company's cheap IDE chipset
<kylem> hmm.
<jdong> though the SATA chipset is the awesome ICH one
<kylem> we'll see.
<wasabi> Ahh. So it's just the IDE chipset.
<wasabi> The SATA is fine?
<jdong> wasabi: exactly
<wasabi> I might just run by fries and grab a SATA DVD writer to replace my current one then
<wasabi> fry's
<wasabi> and forget the entire problem.
<wasabi> I meant to do it anyways.
<jdong> that'll work :)
<jdong> wasabi: and btw a Feisty kernel should build on Edgy with no problems
<wasabi> suspected as much.
<jdong> wasabi: you can actualyl just install feisty kernel debs on Edgy
<wasabi> just have to get edgy installed first. ;)
<jdong> EXCEPT the gui components in l-r-m aren't gonna work
<jdong> you can install the linux-image packages
<jdong> and you should rebuild l-r-m-2.6.19 if you need them
<wasabi> With another CD drive, or setting up a PXE boot or some crap, I don't have anyway to get into a working system. :)
<jdong> wasabi: I was told also that it behooves thee to backport initramfs-tools from Feisty too
<wasabi> I'll probably just install feisty. I ran it before I got the new box at work anyways.
<wasabi> I love breaking things.
<wasabi> it's going to be a super quick box yum.
<wasabi> 4 HD"s, RAID10
<wasabi> e6600, 4gb ram.
<cjwatson> jdong: backporting the feisty kernel to the edgy installer will be pretty messy unless you revert all the structural udeb changes
<cjwatson> if you do that it should be possible ...
<cjwatson> may not be worth it for one system, though
<wasabi> i'll just install feisty.
* cjwatson nods
<wasabi> and cross my fingers that the installer works. ;)
<bddebian> cjwatson: Hi.  Hey, how do I properly ask to get packages brought from Debian that are not currently being synced? (Not new packages but probably blacklisted?)
<cjwatson> bddebian: check in http://people.ubuntu.com/~cjwatson/sync-blacklist.txt to see if they're blacklisted and why
<bddebian> Hmm, not on that list
<cjwatson> bddebian: if they aren't, they should be brought in automatically; just make a note to file bugs with ubuntu-archive subscribed shortly before UVF if they aren't
<cjwatson> bddebian: example package?
<bddebian> mig and gnumach
<bddebian> And maybe hurd
<bddebian> Because they are ports?
<cjwatson> hurd only builds for an architecture we don't support, so that won't happen
<cjwatson> well, it might get synced I guess but won't build
<bddebian> Aye.  Hurds not as important for now but I would like to get mig and gnumach if at all possible
<cjwatson> err, those are all in feisty
<cjwatson>        mig |    1.3.1-2 | feisty/universe | source
<cjwatson>    gnumach | 2:1.3.99.dfsg.1-1 | feisty/universe | source
<cjwatson>       hurd | 20060825-2 | feisty/universe | source
<cjwatson> all in sync with Debian
<bddebian> Hmm, strange
<bddebian> nevermind... Sorry
<cjwatson> np
<bddebian> Is that new?
<cjwatson> wasabi: I don't know of daily build breakage right at the moment ... well, Kubuntu ubiquity won't be happy, but ...
<wasabi> getting the alt image anyways
<cjwatson> bddebian: no, not at all; those are all there right back to warty
<cjwatson> bddebian: none of them have ever built though
<bddebian> How the hell have I missed those.  Damn, I have GOT to get off the crack
<cjwatson> bddebian: I suspect they need a manual bootstrap by infinity
<bddebian> Not a big deal as long as the source is synced. Thanks man.
* bddebian cowers back to his hole feeling like an idiot
<jdong> cjwatson: you're right, I didn't consider the installer... silly me :)
<cjwatson> there are the following sources currently not blacklisted and not synced from Debian: attal-themes-medieval cdrskin etoile gnuradio iceape preview-latex python-gtk2-doc samizdat tagcoll2 xbase-clients xutils
<cjwatson> I suspect all of those have problems of some kind that make sync-source bail out, and have to be thought about and resolved manually
<cjwatson> for instance: E: tagcoll is in main but its source (tagcoll2) is not.
<cjwatson> so tagcoll2 needs to be checked for suitability in main, and then forced in
<bddebian> I thought I brought in a new attal-themes-medieval in edgy?
<cjwatson> bddebian: it's not a source package in edgy; presumably built by another source
<bddebian> cjwatson: Oh, I think it's built from attal now
<cjwatson> looks like it got split out into a separate source package again in Debian, the way it was up to dapper, or similar
<bddebian> Ahh. Hmm
<cjwatson> again, that's the sort of thing that needs to be resolved manually
<bddebian> Is that list posted somewhere?
<cjwatson> no
* bddebian copy and pasts
<bddebian> pastes even
<cjwatson> probably should be, but you can ask an ubuntu-archive member to run 'new-source' in ~/syncs any time you're curious
<cjwatson> (or in fact just run it, it cds itself)
<bddebian> thx
<cjwatson> that's just main - there are other lists for contrib and non-free
<cjwatson> contrib: acx100 atokx2 dguitar doom-package dynagen freemind fst gcc-doc-defaults googleearth-package groovy gwp horae ifeffit imgtex ipw2200 ipw3945 jabref kfolding libvpopmail-perl nvidia-cg-toolkit ogre-contrib opendict-lingvosoft openjump penguin php4-vpopmail pose pose-skins premail psyco-doc python-doc-defaults python-lame python-ldap-doc python2.5-doc q-tools susv2 tuxguitar vpopmail xserver-xorg-video-ivtvdev
<cjwatson> nothing for non-free
<bddebian> gah, I don't "do" main :)
<cjwatson> some of those should possibly be blacklisted (for now?), e.g. ipw3945 is in l-r-m
<cjwatson> bddebian: Debian main not Ubuntu main
<bddebian> I wondered
* cjwatson goes back to bed and hopes that the dog has stopped noisily licking herself
<bddebian> Heh, gnight cjwatson, thanks
<cjwatson> np
<Kano> hi, are the tools used to create the standard live cds freely available
<Kano> did not find usefull info in the wiki
<crimsun> yes, see http://uck.sourceforge.net/ for example usage
<Kano> thx
<Kano> they are not really speedy but maybe it can be tuned a bit
<Kano> did you ever think of sorting the image
<crimsun> https://launchpad.net/distros/ubuntu/+spec/optimized-live-cd-layout-for-faster-boot
<Kano> thx, will look into it
<Kano> do you know how this is done with knoppix like cds?
<crimsun> no, but Mithrandir may be interested
<Kano> well i know how it is done manually. that basially works well, i c you use bootchart to optimize it
<Kano> not bad that idea
<Kano> opt. cds need a bit longer to install, but boot is faster
<slomo> rodarvus: ping?
<Kano> bye
<pitti> Good morning
<Burgundavia> morning pitti
<pitti> hi Burgundavia, how are you?
<Burgundavia> not bad
<Burgundavia> need to sleep but waiting up for a conference call with jono and christina
<pitti> heh, happy coffee drinking then
<Burgundavia> yep
<desrt> Burgundavia; can't be later than 11:30 there...
<Burgundavia> yes, but the meeting is at 9am UTC
<Burgundavia> and i hate skype
<desrt> shouldn't y'all be using ekiga or something? :
<desrt> :)
<Burgundavia> yes, but it works less well
<desrt> somewhere richard stallman is crying
<Burgundavia> yes, he probably is
<mneptok> good.
<mneptok> cry for me, you stout little emo-hippie.
<Burgundavia> given I run madwifi, he is already crying
<Burgundavia> mneptok: you get very wierd when at work :)
<mneptok> s/when at work//
* pitti hugs desrt
<desrt> "Those who are willing to give up their freedom for a little temporary video conference deserve neither freedom nor conferencing."
<desrt> pitti; hi :)
<Burgundavia> desrt: right
<desrt> Burgundavia; ben franklin.  seriously.
<desrt> the man was a visionary
<Burgundavia> you want the actual quote?
<desrt> i know it, thanks :p
<mneptok> Franklin denied authorship
<mneptok> (but it may still be him. no one will ever know for sure.)
<desrt> for real?
* desrt didn't know that
<mneptok> http://en.wikipedia.org/wiki/Those_who_would_give_up_Essential_Liberty
<Kagou> hi
<pitti> hi Kagou 
<Kagou> hey pitti. How are you ?
<pitti> Kagou: great, hacking on spec implementation like mad :)
<Kagou> :)
<Kagou> pitti: when i do a wish bug asking for a package sync from debian, must i assign someone to it ?
<pitti> Kagou: no, but you need to subscribe ubuntu-archve
<pitti> archive, even
<pitti> Kagou: please read https://wiki.ubuntu.com/DeveloperResources, section 'syncs'
<pitti> Kagou: it links to my script that does everything for you (almost)
<Kagou> thanks pitti 
<pitti> doko_: wrt cyrus-imapd2.2 merge, does Debian use 4.4 or a < 4.3 version?
<doko_> pitti: 4.2
<pitti> doko_: ah, ok; thanks
<pitti> doko_: wrt bug 70957, shall I apply the patch myself or do you prefer doing that yourself?
<Ubugtu> Malone bug 70957 in python2.5 "support apport reporting for python programs" [Wishlist,Confirmed]  http://launchpad.net/bugs/70957
<doko_> pitti: I'm preparing new uploads for python2.4 and python2.5
<pitti> doko_: ah, great
* pitti hugs doko_ 
<tepsipakki> does it need all buildd's to complete before a package is moved to archive?
<pitti> tepsipakki: no
<pitti> tepsipakki: sources go straight in
<pitti> tepsipakki: and binaries come whenever a buildd finishes building them
<pitti> tepsipakki: (in the non-frozen development release case, anyway)
<tepsipakki> pitti: ok, thanks. I'm just wondering why evolution is not in yet, only ia64 build waiting, others completed
<pitti> tepsipakki: probably stuck in NEW, due to a lib rename or so
<tepsipakki> ah, ok
<pitti> tepsipakki: https://launchpad.net/distros/ubuntu/feisty/+queue?start=20 -> there
<pitti> hm, weird, that only talks about translations
<Mithrandir> hmm, it should be possible (in malone) to say that you're not interested in bugs for a particular distribution.
<Burgundavia> Mithrandir: there are a bunch of "don't bug me options", including the team membership one
<Mithrandir> Burgundavia: no such twiddles on https://launchpad.net/people/ubuntu-archive/+subscribedbugs nor the advanced search.
<Mithrandir> I'm not particularly interested in bugs which only affects baltix.
<Mithrandir> (because they've been fixed in Ubuntu)
<Fujitsu> Mithrandir: I've been looking for that option for a while too :(
<opi> morning.
<raphink> hi opi
<lifeless> mvo: can I assign this to you ?
<lifeless> https://launchpad.net/distros/ubuntu/+source/update-manager/+bug/74899
<Ubugtu> Malone bug 74899 in update-manager "crashed in saveDistUpgrade" [Undecided,Unconfirmed]  
<doko_> Riddell: merging libtunepimp
<opi> guys, tell me, was there an new XOrg upload?
<Burgundavia> opi: what is your issue?
<Riddell> doko_: that doesn't need merged, there's a new version out
<opi> Burgundavia, it seems to be ABI incompatible with prev version
<opi> Burgundavia, my friend is using openChrome drivers I've compiled from thier repos (as Edgy driver didn't work)
<doko_> Riddell: ok, please upload :)
<Kano> hi
<Kano> there is a uck to customize a live iso,but how was it created (from scratch)
<opi> Burgundavia, after upgrade hers desktop died and from synopis it looks like a Xorg can't load OC driver
<Kano> especially the rootfs
<Burgundavia> opi: out of repo drivers are not really our issue, tbh
<opi> Burgundavia, yup, I just wanted to confirm if you guys uploaded'em, as I haven't seen this upgrade on my Edgy desktop
<Burgundavia> opi: there was a new xorg upload
<opi> Burgundavia, no that I blame you :-)
<Burgundavia> given I have coded or packaged exactly nothing on Ubuntu, I absolve myself of all responsibility :)
<opi> :P
<opi> OK, then I'm off to "How to compile video driver against Xorg tree in Ubuntu for females" :>
<Burgundavia> opi: is there a reason you need a custom dirver?
<opi> Burgundavia, via drivers provided by Eft are dying with "NO SCREEN"
<Burgundavia> then that is a bug. Please make certain it is filed
<Burgundavia> strong candidate for an SRU, if you can get some good data on it
<Mithrandir> Kano: deboosttsrap and apt-get
<opi> Burgundavia, and since she's living in Holland I have small amount time to debug it, and OC worked OOTB
<opi> Burgundavia, will do, she will be here on XMas and I'll get some time to inspect what's wrong with it
<mvo> lifeless: thanks for 74899
<lifeless> mvo: np. apport++ :)
<lifeless> mvo: also, what do you think of https://launchpad.net/bugs/74747
<Ubugtu> Malone bug 74747 in Ubuntu "Default sources.list file has source packages enabled by default" [Undecided,Confirmed]  
<pitti> nice bug number :)
<doko_> keescook: is the autogen test fix forwarded upstream?
<Mithrandir> lifeless: it's a feature in order to comply with the gpl, really.
<pitti> hm, but for developers it's nice, and for the spirit of free software too, IMHO
<elmo> Mithrandir: that's crack
<lifeless> well
<elmo> Mithrandir: sources.list has nothing whatsoever to do  with GPL compliance
<lifeless> the GPL concept I can see - but having synaptic auto-enable the sources *when requested for source* will achieve that just as well
<Mithrandir> elmo: it is?  "Equivalent access" is the wording in the gpl and it's not hard to argue that it should be just as easy to get the source as the binaries.
<Burgundavia> pitti: lovely, but 95% of the people pulling down those sources.list don't use it.
<lifeless> Mithrandir: you can get to just as easy without downloading gigs of source data over time
<elmo> Mithrandir: the sources are on the same server, in the same directory, it doesn't get much more equivalent
<infinity> I think most people who aren't RMS agree with elmo on this one.
<elmo> Mithrandir: if you want to argue that the GPL enforces equivalence all the way up the stack past simple http/ftp level, I think you're clinically insane
<pitti> Burgundavia: *shrug* 95% of the users will download the daily apt-get update lists in vain, too
<Mithrandir> elmo: oh, lots of people would argue I'm insane. :-)
<pitti> Burgundavia: and sources lists will change very little for stable users
<infinity> I did, however, get involved in a flamewar with RMS about this 5 years ago or so, where I took elmo's position, and RMS *insisted* that the GPL required Debian to ship with deb-src lines in sources.list.
<lifeless> pitti: not really, as the auto-application of security updates is much more realistically useful.
* Mithrandir shrugs and goes back to doing syncs.
<raphink> it seems indeed that most users need universe more than they need deb-src
<infinity> Incidentally, it's the last time I argued with him about anything.  Or spoke to him, for that matter.
<pitti> lifeless: (just reductio ad absurdum, sorry)
<pitti> Sources.gz for stable/main is so small...
<lifeless> well
<elmo> pitti:  it may be small but with as many users as we have, each extra pair of HTTP IMS hits hurts
<elmo> esp. for security.u.c
<pitti> hmkay
<pitti> (for the record, 18 kB for dapper-security main)
<lifeless> yes, but as elmo notes its 50% of the load on security
<pitti> ok, I'm just afraid of those people which will start complaining about 'le huh? apt-get source doesn't work any more in feisty'
<mvo> lifeless: apt-setup is responsible for seting up the sources.list. historically it was always including deb-src lines. but I think that the gpl does not really require that it is enable by default
<Burgundavia> I am mad or is that 103 GB, assuming 18kb and 6million IPs?
<pitti> 'k, the server load argument is pretty compelling to me
<Riddell> doko_: any plans for a merge of subversion?
<doko_> Riddell: no, infinity wants to merge apache2 first, then subversion
<pitti> mvo: if we do that, then IMHO it should become much easier to enable sources; and we have to find a way for non-admins to get source, too
<mvo> pitti: easier than going to "repositories" and clicking on "source code"? its two clicks currently 
<pitti> mvo: ah, there
* pitti didn't see that box, sory
<mvo> np
<Riddell> doko_: right, cool
<jdub> pitti: "le huh?" <- awesome
<_ion> Btw, couldn't archive.ubuntu.com (or e.g. nearest.archive.ubuntu.com, which would then be used in the default sources.list) be made to return the list of mirrors geographically closest to the client? For example, apt-cache show pdns-backend-geo
<mvo> _ion: we have a spec about this for feisty
<mvo> :)
<dholbach> good morning
<_ion> mvo: Ok, i'm reading it now. :-)
<dholbach> hey _ion
<_ion> Hi dholbach
<\sh> moins
<Riddell> Keybuk: is anyone processing sync requests?  I've had no response to bug 73152
<Ubugtu> Malone bug 73152 in pth "sync pth from unstable" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73152
<Mithrandir> Riddell: I am doing it just now.
<Keybuk> Riddell: wasn't any point processing them during freeze
<Riddell> fair point
<Riddell> thanks Mithrandir 
<Fujitsu> Mithrandir/Keybuk: Can either of you please let a universe SRU into dapper-updates?
<Mithrandir> Fujitsu: has the motu SRU team decided on a policy yet?
<Mithrandir> dholbach: ^^
<Fujitsu> Mithrandir: It has gone through the process as was decided a number of weeks ago, and been approved by motu-sru.
<Mithrandir> Fujitsu: ok, if it has ubuntu-archive subscribed, I'll try to get to it today, then.
<Mithrandir> Keybuk: we want people to not drop -Q parameters when calling modprobe, don't we?  (About https://launchpad.net/distros/ubuntu/+source/dmraid/+bug/71980 )
<Ubugtu> Malone bug 71980 in dmraid "Please sync dmraid from Debian unstable (main)" [Undecided,Confirmed]  
<Fujitsu> Mithrandir: Yep, it's been subscribed for some time now. Thanks!
<dholbach> Mithrandir: yeah, they're doing good work already
<dholbach> Mithrandir: http://wiki.ubuntu.com/MOTU/SRU and it's linked from StableReleaseUpdates
<Mithrandir> dholbach: ok, so the policy is in place.  Great. :-)
<Mithrandir> dholbach: yeah, that's fine, but somebody said something about the policy not being finalised yet.
<Mithrandir> dholbach: but if it is, that's good.
<Keybuk> Mithrandir: right
<dholbach> it has been for three or four weeks or something
<Mithrandir> Keybuk: thanks.
<doko_> dholbach: I'm stuck with just one vote from the SRU team for bug 68380 ...
<Ubugtu> Malone bug 68380 in eclipse "eclipse for edgy-updates" [Medium,Confirmed]  http://launchpad.net/bugs/68380
<dholbach> doko_: afaik it's either "votes" or "after ... days"
<doko_> dholbach: no, I don't see that
<dholbach> doko_: "After at least 5 persons have tested the package and attached a "works for me" comment to the bug and after a minimum aging period of 7 days, you may prepare a second upload to release-updates:"
<dholbach> oh, hm
<doko_> dholbach: I'm still at 1) ... "A proposal is accepted, once three people from the MOTU-SRU team give their assent."
<doko_> that's difficult, as the team has just five members
<dholbach> doko_: best to ping on the bug again - if you want to ping them privately: StevenK, crimsun, siretart, sistpoty are on the team
<doko_> and someone called dholbach ...
<dholbach> doko_: somebody called me?
<doko_> Mithrandir: (MoM) I requested syncs for libbsf-java and jakarta-log4j1.2
<Mithrandir> doko_: there's no point asking on IRC; I'm going by the list of bugs ubuntu-archive is subscribed to.
<doko_> Mithrandir: you misunderstand.
<Mithrandir> doko_: ok, please explain then
<doko_> Mithrandir: going through python and java related MoM entries not assigned to me ...
<Mithrandir> doko_: oh, you mean "I stole your libbsf and jakarta-log4j1.2 merges"?  Excellent! :-)
<doko_> and these are/were assigned to you.
<lifeless> doko_: upload python!
<lifeless> doko: so, what do I need to do to get a python2.x upload with the apport hook patch included ?
<doko> <pitti> doko_: wrt bug 70957, shall I apply the patch myself or do you prefer doing that yourself?
<doko> <Ubugtu> Malone bug 70957 in python2.5 "support apport reporting for python programs" [Wishlist,Confirmed]  http://launchpad.net/bugs/70957
<doko> <doko_> pitti: I'm preparing new uploads for python2.4 and python2.5
<doko> <pitti> doko_: ah, great
<Ubugtu> Malone bug 70957 in python2.5 "support apport reporting for python programs" [Wishlist,Confirmed]  http://launchpad.net/bugs/70957
<lifeless> sweet
<lifeless> thanks!
<pitti> heh, I was just going to quote the same
<lifeless> gnight y'all
<lifeless> small suggestion
<mneptok> nighty RC!
<lifeless> record such things in the bug reports
<lifeless> stops folk needing to read every line of IRC to have a feeling for whats happening
<pitti> that should be 'in progress' or 'fixcommitted'
<lifeless> tchau!
<pitti> lifeless: sleep well!
<mneptok> t'pau!
* mneptok forces infinity to choose between the Lurpa and the Ahm-Vhoom
<infinity> mneptok: *blink*
<seb128> hum, ctrl-left write a "5D" instead of going back one word, is that bash to blame?
<mneptok> infinity: Star Trek geekery. sorry. :)
* pitti confirms that bug, that worked a few weeks back
<seb128> it worked a few days back
<pitti> doesn't work on VT either
<seb128> bash has been updated on dec 4th
<seb128> I blame it
<seb128> dooookooooooo
<pitti> oh, bash doesn't use libreadline5?
<pitti> oh, ncurses
* mneptok whispers "zsh"
<pitti> doko, seb128: confirmed, downgrading bash to edgy makes it work again, so it's not ncurses or libreadline
<seb128> ok
<StevenK> mneptok: Which uses zle ...
<mneptok> yup
<doko> pitti: bash uses the statically linked libreadline for performance reasons
<pitti> oh, argh
<pitti> doko: ok, so I suspect it's rather a bug in readline
<pitti> hm, that hasn't been updated since October
<pitti> but might have been synced just recently
<pitti> doko: that's only startup performance? or do they have any patches to it?
<doko> pitti: yes, startup performance
<pitti> I see (although with our /bin/sh being dash now, it won't make much of a difference any more)
* Keybuk giggles at scary comments in source code
<Keybuk> about 2,000 lines into the unit tests, I was clearly losing the will to live
<pitti> Keybuk: *being curious*
<Keybuk>  * everything we do and must live a fully moral and selfless life to avoid
<Keybuk>  * the eternal misery that awaits us.
<Keybuk>  *
<Keybuk>  * The alternative is that we just die, and so does everyone else, so
<Keybuk>  * everything we ever do is ultimately forgotten and therefore meaningless.
<Keybuk>  *
<Keybuk>  * Oh, yeah, check the return value was what we expected, or something.
<Keybuk>  */
<Keybuk> /* If there's a god, and eternal life, then we're all held accountable for
<Keybuk> (first line got eaten by IRC there, oops)
<Riddell> pitti: any plans for main inclusion queue reviews soon?  I've a bunch pending
<pitti> Riddell: right, I saw the wiki mails, and the amount scared me
<pitti> Riddell: can't promise that I'll manage today, but on Tuesday at most
<Riddell> you should finish your gnome-mount patch first of course :)
<pitti> hehe
<pitti> oooh, btw, exactly the right man and right topic
<pitti> Riddell: does KDE pay attention to volume.ignore?
<pitti> Riddell: I'm implementing https://wiki.ubuntu.com/MountAllLocalFilesystems ATM
<Riddell> pitti: don't have a clue, what does it mean?
<pitti> Riddell: if KDE would suddenly display icons for fixed unmounted HD partitions, but you cannot mount them through the UI, we need to figure out something
<pitti> Riddell: gnome-vfs interprets it as 'show an icon for the volume' (false) or 'don't bother the user with that one' (true)
<pitti> Riddell: so far we had volume.ignore for nonremovable volumes
<pitti> (== true)
<Mithrandir> seb128,dholbach: can one of you ACK or NACK https://launchpad.net/distros/ubuntu/+source/gnome-backgrounds/+bug/74416 please?
<Ubugtu> Malone bug 74416 in gnome-backgrounds "Please sync gnome-backgrounds (universe) from unstable (main)" [Undecided,Confirmed]  
<doko> Mithrandir: I don't understand your last comment for bug 74613
<Ubugtu> Malone bug 74613 in python-setuptools "sync request" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74613
<dholbach> Mithrandir: I think seb128 worked with xerxas on it, so it should be fine.
<Mithrandir> doko: there's no copy of debian/changelog from when the Ubuntu package branched off until what you're asking to be synced.
<doko> Mithrandir: ahh, ok thought that was the icu thing
<seb128> Mithrandir: ack
<Mithrandir> doko: I've commented about the same on multiple bugs today; it would simplify my job if you used the requestsync script (or emulated its output)
<seb128> Mithrandir: I've commented on the bug
<Riddell> pitti: I'm told KDE does respect volume.ignore
<Mithrandir> seb128: thanks.
<seb128> np
<pitti> Riddell: ok, can we continue in 30 mins or so? I'm off for lunch
<doko> Mithrandir: what is the rationale for including the changelog? I.e. it's incomplete anyway if we sync a new upstream version
<Riddell> pitti: sure
<iwj> Keybuk: This `watershed' command doesn't exist yet, right ?  So I should go and write it.
<Mithrandir> doko: it makes it possible for me to check that the changes you say are included actually are documented as included, for instance?
<Keybuk> iwj: it does, it's just not in the feisty package yet because I hadn't got to it yet
<iwj> Oh.
<Keybuk> just leave it out for now, for testing purposes without it is good enough
<Keybuk> it's a built-in thing
<iwj> Err, right.
<doko> Mithrandir: no, not if things are changed/integrated upstream
<Mithrandir> doko: if you want to change the policy of what information we want, you're free to do that on ubuntu-devel@lists, but until a change occurs, this is the policy which is in place.
<iwj> Keybuk: Also, I wanted to talk to you about this alleged race which means we supposedly have to move the symlink creation from vgchange to a vgmknodes run by udev.
<Keybuk> iwj: yes
<iwj> In fact it is sufficient to run vgmknodes, and there is no need to change vgchange.
<iwj> Because vgmknodes takes out the vg lock as does vgchange, so vgmknodes does nothing but cannot exit until vgchange has finished.
<Keybuk> ok
<Keybuk> that's sufficient
<iwj> I did have to fix the way the symlinks were dealt with to stop it doing unlink();symlink() and make it do symlink();rename() instead.
<Keybuk> it's basically just so that later RUN rules in the processing of the resulting devmapper block devices can rely on the /dev/VG/LV symlinks existing, as well as /dev/mapper/VG-LV
<iwj> Right.  I just wanted to check that the race you were thinking of was that the udev event for the dm device might be processed with the link not present.
<iwj> Right.
<Keybuk> yes
<Keybuk> it would be nice if udev could say "I have this new devmapper block device, it's dm-0, but really /dev/mapper/VG-LV ... and it's LVM, so also /dev/VG/LV"
<Keybuk> thus it'd work whatever people put in their fstab, etc.
<iwj> OK.  I'll tidy the lvm2 changes up and upload them.
<Keybuk> cool
<Keybuk> thanks
<iwj> Right.
<iwj> The extra udev rule (in the lvm2 package) is harmless if you remove-but-not-purge lvm2 AFAICT.
* Mithrandir just figured that fstab is really shorthand for face-stab, not file system table..
<iwj> Do you want me to do the vgmknodes or are you going to call that ?  And are RUN rules done sequentially ?
<Keybuk> "extra udev rule" ?
<iwj> UBSYSTEM=="block", RUN+="watershed /sbin/vgchange ....
<Keybuk> the vgmknodes rule should be shipped by lvm2 as well
<Keybuk> RUN rules are done in sequence for a particular job, yes
<iwj> shipped by lvm2> Right.  With a lowish priority so it happens early.  Right.
<Keybuk> 85-*.rules
<Keybuk> maybe 82-*.rules given it's for a race checking
<iwj> Right, exactly, that's what I meant.
<iwj> Err, in fact, thinking about it, the dm device itself will case vgchange to run again so that's just as good as vgmknodes.
<iwj> s/ case/ cause/
<Keybuk> shiny
<Keybuk> pitti: talking of which, I'd like to move the hal udev rules
<Keybuk> I think it'd make more sense for it to be 95-hal.rules not 85, as it's being run before udev has really finished
<Keybuk> Riddell: tagcoll vs. tagcoll2
<Keybuk> you requested the latter be sync'd from Debian
<Keybuk> should we remove and blacklist the former?
<Riddell> Keybuk: yes please
<Keybuk> why hasn't tagcoll been removed from Debian?
<Riddell> the source package has as far as I can see, the binary tagcoll package now comes from tagcoll2
<Riddell> oh, except 1.6.3-1: kfreebsd-i386
<Keybuk> oh, fair enough
<infinity> Oh sure, he leaves like 30 seconds before I wanted to ask him something.
<StevenK> infinity: Just so you can have the pleasure of waiting for him. Duh.
<infinity> Damn Seb, always playing hard to get.
<mneptok> infinity: "yes, i'm wearing them. did you get the .jpgs?"
<infinity> StevenK: Feel like being a good samaritan and debugging why the e-d-s build SEGVs on ia64? *bat lashes*
<infinity> (And I don't want to hear "I don't have an ia64 box" as an excuse either, young man)
* StevenK hits Ctrl-U and whistles innocently.
<StevenK> infinity: I wasn't actually going to say that, it was more along the lines, "I don't have an account on an ia64 box that I can install build-deps on." :-)
<Keybuk> Riddell: libapt-front will need changing build-deps
<Keybuk> as well tagcolledit
<Riddell> Keybuk: libapt-front has been renamed to libept (which should be in NEW)
<Riddell> tagcolledit I'll fix
<Keybuk> "ept" ?!  has lifeless been naming our packages? :p
<StevenK> libept fails to build due to no tagcoll2, from what I recall.
<Keybuk> StevenK: ah, we appear to have reached the middle of this conversation
<StevenK> I'm trying to say it isn't in NEW, it's in the archive, it just hasn't built.
* StevenK shrugs.
<StevenK> infinity: I'm happy to do so, if you want.
<cjwatson> Keybuk: one thing that occurred to me when reading udev-lvm and udev-evms in parallel: presumably you either want some option to watershed to tell it where its lock file is, or for it to work that out dynamically based on the command name?
<Keybuk> cjwatson: the one in udev is done on the rule name
<Keybuk> but I was thinking of doing it in upstart instead
<cjwatson> "rule name"?
<Riddell> StevenK: so it is, that means Keybuk can throw out libapt-front
<Keybuk> cjwatson: it's a function in udev, if the RUN+= begins "watershed" it's done inside udev based on the rule id in the parsed table
<cjwatson> oh, I see
<cjwatson> cute
<infinity> StevenK: Would be awesome, if you have access to the hardware.  If not, I'll have to bug someone on staff to do it, or do it myself when I have time.
<infinity> StevenK: Someone like seb!
<StevenK> infinity: ... Ubuntu has ia64 machines. :-P
<infinity> seb128: If I bake you cookies, will you debug the e-d-s segv on ia64?
<infinity> StevenK: Not publically accessible (yet), unfortunately. :/
<StevenK> I have this small feeling that my wife would object to my buying an ia64 on a credit card just so infinity will love me.
<Riddell> enrico: tagcolledit build-deps should be changed in debian too no?
<seb128> infinity: I'll have a look
<seb128> infinity: hum, e-d-s segfault or e-d-s 1.9.3 build failure?
<infinity> seb128: The build failure, if you look carefully, looks suspiciously like a segv in the build.
<seb128> infinity: bah, looks like gtk-doc not being happy with amd64, glade-3 was already failing on documentation build
<infinity> s/amd64/ia64/
<seb128> right
<Riddell> enrico: actually it doesn't compile, any plans for a tagcolledit for libtagcoll2?
<seb128> infinity: I think I'll be lazy and upload a version without --enable-gtk-doc, that's not required, the tarball ships the html files
<infinity> seb128: Laziness works for me.
<infinity> seb128: I can't really ask you to spend any paid time on ports anyway, so whichever lazy route you prefer. :)
<seb128> ok ;)
<seb128> could anybody get evolution out of NEW?
<infinity> seb128: I already did.
<seb128> excellent
* seb128 hugs infinity
<cjwatson> pitti: I have a tiny hal patch which makes it work better with mouseemu; just makes probe-input.c allow the BUS_VIRTUAL type
<cjwatson> pitti: mind if I upload, or should I file a bug?
<mjg59> Hm. I thought we had that already.
<pitti> Keybuk: argh @ conffile transition, but fine for me
<cjwatson> mjg59: apparently not
<pitti> cjwatson: since I need to upload a new hal for Keybuk anyway, maybe just commit the patch into the bzr?
<cjwatson> also need to figure out how to make gnome-power-manager notice new keyboards appearing in hal
<cjwatson> pitti: ah, I didn't check bzr; will do
<pitti> cjwatson: sftp://bazaar.launchpad.net/~ubuntu-core-dev/hal/ubuntu
<pitti> cjwatson: if that's fine for you?
<cjwatson> thanks
<cjwatson> sure
<infinity> seb128: Hrm, if it's gtk-doc hating life, I suppose we could wait for the newly-synced source to build and retry e-d-s to see if it's magically happy again.
<pitti> cjwatson: I'll do Scott's conffile transition this afternoon then, and upload
<seb128> infinity: seems a good idea to me
<seb128> let's do that ;)
<infinity> seb128: Alright, I'll let you know if it remains FUBAR.
<seb128> thank you
<cjwatson> I'll fix up the udev rule installation in mouseemu
<cjwatson> Keybuk: where should a rule to restart a program on add events go? 80?
<pitti> Riddell: so basically you need to decide whether or not you want to handle mounting of fixed non-auto-fstab hard disk partitions in KDE
<Keybuk> cjwatson: 85
<pitti> Riddell: if so, then you can just use the new hal and need a similar trick in KDE that I do in gnome-mount (if you get a permission error, sudo yourself as root again)
<Riddell> pitti: it would be nice, it's kindae a mess at the moment
<cjwatson> oh yes, reading ALL of /etc/udev/rules.d/README helps
<pitti> Riddell: if not, then we need to modify the hal fdi rules or kio's interpretation of it to not show them
<Riddell> pitti: sudo again?  is it already sudoed?
<pitti> Riddell: (gksu in the gnome case, some kdesu GUI wrapper for you)
<pitti> Riddell: the current gnome-mount approach is: try as user, if you get a PermissionDeniedByPolicy error, try 'gksu -- gnome-mount ...'
<pitti> Riddell: for admin members, that is
<pitti> Riddell: so that admins can mount them through the UI, and non-admins don't
<Riddell> pitti: clever
<Riddell> pitti: does gnome-mount replace pmount?
<pitti> Riddell: over three corners, yes
<pitti> Riddell: the hal mounting backend replaces pmount
<pitti> and gnome-mount calls it
<rodarvus> slomo: pong
<Fujitsu> infinity: Apparently I kick you to get the maintainer field unclobbered for my packages.
<infinity> Fujitsu: Indeed.
<infinity> Fujitsu: Or pitti, I suppose.
<slomo> rodarvus: will you merge/update the xorg stuff? if so it would probably nice to include one patch from upstream for the ati driver that is in no release :) shall i file a bug for this or is just giving you the changeset/diff enough?
<infinity> Fujitsu: Specific packages, specific email you want whitelisted, what?
<Fujitsu> infinity: You're significantly closer for kicking :P
<rodarvus> slomo: yes, this is enough, please do
<Fujitsu> infinity: Specific email, if you please.
<rodarvus> (and assign the bug to me)
<slomo> rodarvus: will do, thanks (changeset 9f5ea3981449f29ff204eb154166e8fc813205fa btw)
<infinity> Fujitsu: Given our proximity, I may expect bribery.  pitti wouldn't ask you to hand-deliver a souvlaki from Lamb on Chapel.
<Fujitsu> Hahahahha
<StevenK> Like Fujitsu is old enough to drive.
* StevenK ducks
* Fujitsu attacks StevenK with an infinity.
<infinity> That doesn't work.
<infinity> Anyhow.
<infinity> Fujitsu: Which email do you need whitelisted?
<Fujitsu> (after catching the train, and abducting infinity) So there!
<Fujitsu> infinity: william.grant@ubuntu.com.au
<infinity> Fujitsu: And don't you have an ubuntu.com email?
<infinity> Fujitsu: And if so, why not just use that?
<infinity> (All ubuntu.com is whitelisted)
<Fujitsu> Hahah, that's bug... I forget which.
<Fujitsu> I don't have an ubuntu.com address, because of some bug because my primary address has ubuntu.com in it.
<infinity> Cute.
<StevenK> Ohhhh. Neat.
<infinity> Fujitsu: Do we have other people at ubuntu.com.au?  Should I just whitelist the domain?
<StevenK> Personally, I'd prefer to have my @ubuntu.com be my primary address in Launchpad.
<Fujitsu> I'm the only one with packages at the moment.
<StevenK> I've heard "don't do that", however.
<siretart> infinity: did we or rather team soyuz import the pre-soyuz katie whitelist into soyuz?
<Fujitsu> Yeah, bug 62109 is why I don't use @ubuntu.com.
<Ubugtu> Malone bug 62109 in launchpad "ubuntu.com email address creation" [Low,Confirmed]  http://launchpad.net/bugs/62109
<infinity> siretart: This is an entirely different whitelist.  katie never did what I'm doing now (overwrite maintainer fields in binary builds)
<siretart> ok
<infinity> StevenK: The current system forwards your lpaccount@ubuntu.com to your primary address, and we don't like mail loops.
<infinity> StevenK: I'm sure it could be made smarter to pick the secondary if the primary would be an obvious loop, but whatever.  Social solutions are easier than code sometimes.
<Fujitsu> Which is exactly why mine doesn't exist yet.
<Fujitsu> Somebody forgot a $, I suspect :P
<StevenK> infinity: But it's like two lines of code, surely?
<infinity> StevenK: Not my code, don't know.  I try to avoid touching too much launchpad code, lest someone suggest I move to the launchpad team.
<StevenK> Heh
<infinity> Oh, piss off apt, you filthy... ARGH.
<infinity> Can someone hit Michael for me when he logs on again?  kthx.
<infinity> E: Could not open file /var/lib/apt/lists/ftp.iinet.net.au_linux_ubuntu_dists_feisty_universe_source_Sources - open (2 No such file or directory)
<StevenK> Heh
<infinity> That is NOT a valid reason to refuse to let me apt-get source from main.
<infinity> And running "apt-get update" on a 512k line is painful.
<Fujitsu> Ah, but it is.
* infinity grumps.
<StevenK> infinity: 50KB/s is too slow?
<infinity> StevenK: For a man used to 24Mbps at home, yes, it's too effin' slow.
<StevenK> infinity: I invite you to remember Australia bandwidth, say even 4 years ago.
<infinity> StevenK: I've only lived here for 3.
<StevenK> Yes, exactly.
<infinity> StevenK: And I started with 1.5Mbps when I moved here.  Which *was* painful too, but not as bad as this.
* Fujitsu invites you to remember Optus international bandwidth, even now.
<StevenK> Fujitsu: My carrier is Exetel. It's hard to forget.
<StevenK> infinity: I'm on 1.5 at the moment, trying to decide if I can swing a switch to ADSL2+
<infinity> StevenK: I rather like my ADSL2+
<StevenK> I'm getting that impression. :-)
<infinity> StevenK: Was  abit shaky when it was first connected, now it's solid, fast, and quite nice.
<StevenK> infinity: My main concern is what to do with my mail for 5-8 days while I get disconnected/reconnected.
<infinity> StevenK: Ask some kind soul like me to be a backup MX and spool it all for you?
<StevenK> Or get work to do it.
<infinity> Indeed.
<StevenK> It's also the question of a spare $250. Which around Christmas doesn't exist.
<infinity> Fujitsu: https://lists.ubuntu.com/archives/feisty-changes/2006-December/001980.html
<Fujitsu> Thanks, infinity.
* StevenK wonders when Fujitsu is going to hand deliever the souvlaki.
<infinity> Soon, I hope.  I;'m starving.
<StevenK> deliver, even
* StevenK grins and high fives infinity.
<infinity> Fujitsu: A number 3, please (the L.O.C special)
* Fujitsu rips StevenK's liver out.
<cjwatson> infinity: oh, please whitelist cjwatson@debian.org maintainer fields. kind of a shame it doesn't notice any LP people who have an @ubuntu.com address, and whitelist all of their validatedemail addresses?
* StevenK shrugs and grows a new one
<infinity> Fujitsu: A side of saganaki too.
<Fujitsu> cjwatson: That'd be a good idea.
<infinity> cjwatson: Want it whitelisted, or overridden to cjwatson@ubuntu.com?
<cjwatson> infinity: just whitelisted is fine; is a different hat
<infinity> cjwatson: Fair 'nuff.
<cjwatson> Fujitsu: I actually assumed it worked that way until I checked man-db just now
<cjwatson> infinity: any way to make this configuration on the buildds rather than requiring an upload?
<infinity> cjwatson: It has no LP knowlege whatsoever.  File a bug on launchpad-buildd if you'd like the functionality more integrated, though.  I could waste some cycles on it sometime.
<infinity> cjwatson: Oh, I can change the config in the chroots, but it's easier to just upload.  *shrug*
<infinity> cjwatson: With the exception of today, people don't exactly ask often. :)
<cjwatson> bug> will do
<verwilst> Mithrandir: ping
<infinity> cjwatson: Mangled.
<cjwatson> ta
<infinity> seb128: Err, wait... gtk-doc is arch:all... How can it hate one arch more than another? :)
<Fujitsu> How often is MoM meant to update? I uploaded matplotlib 15 hours ago, it still hasn't updated to reflect said upload.
<infinity> seb128: I'd assume it's a jade bug or something.
<StevenK> jade, on the other hand, hates all arches equally.
<seb128> infinity: good remark, yeah, probably
<infinity> StevenK: I remember it being more often broken than not on many in the past, yes.
<infinity> StevenK: Not the world's happiest codebase.
<StevenK> Yeah, well.
<cjwatson> infinity: launchpad-buildd has no open bugs - is it definitely the right product?
<Mithrandir> verwilst: please include some context with your ping.
<verwilst> Mithrandir: one context, coming up :p
<verwilst> Mithrandir: i just noticed the grub2 spec in the wiki
<verwilst> Mithrandir: is it still on track for feisty? the grub2 site seems pretty scarse with updates/status reports :)
<Mithrandir> verwilst: I haven't yet started actually working on it, just poking it a bit with a stick.
<Mithrandir> verwilst: I'm intending to have it ready for feisty, yes.
<verwilst> Mithrandir: sweet :)
<Mithrandir> verwilst: it won't be default for i386/amd64/ppc, but it should be available in expert mode at least.
<verwilst> Mithrandir: it supports EFI too eh
<verwilst> the wiki says it doesn't
<cjwatson> the status reports are inconsistent
<verwilst> "It is working on PC, OpenFirmware-based PowerPC machines (PowerMac and Pegasos) and EFI-based PC (IntelMac)"
<verwilst> so at least it means they're still actively coding it :)
<infinity> cjwatson: It used to be the right product.  cprov may have moved everything to "soyuz" with tags...
<cjwatson> EFI support is one reason we're pushing for it, for the Intel Macs
<Mithrandir> cjwatson: well, according to mjg59 not doing bootcamp on intel macs is going to just be really painful.   We might want to go that route anyway, though.
<cjwatson> oh, yeah, true
<cjwatson> but even then it's going to be better than lilo, and our grub doesn't do intel-macs-with-bootcamp at the moment
<Mithrandir> yeah, true
<infinity> cjwatson: Yeah, file it on soyuz, and tag it "soyuz-build", I guess.
<cjwatson> oh, damn, that's a point, I need to make mouseemu work on intel macs without visible EFI
<cjwatson> was hoping not to have to shell out to dmidecode
<verwilst> and maybe grub2 will have support for xfs and such?
<verwilst> so i can finally get rid of my ext3 /boot's ;)
<Mithrandir> grub 1 supports xfs, afaik.
<Mithrandir> it just requires xfs_freeze to be run
<verwilst> Mithrandir: myeah it does.. but not enabled in ubuntu i think?
<verwilst> oh?
<verwilst> ReiserFS and graphics-based user interface are still pending items
<cjwatson> Mithrandir: that isn't enough
<verwilst> 2 nice things :p
<cjwatson> I've tested this extensively in the past, and briefly recently
<cjwatson> they've always *claimed* it supports xfs that way, but it doesn't actually work - there's still a fairly wide race condition
<Mithrandir> cjwatson: ok.
<verwilst> cjwatson: maybe grub2 brings some relief ;)
<cjwatson> I don't know the situation with grub2 there. To be honest I think it's an XFS bug.
<cjwatson> but maybe grub2 manages to work around it somehow
* verwilst ponders upgrading to feisty
<mjg59> xfs has different ideas about when data actually hits the disk
<mjg59> Which makes it harder to guarantee that your bootloader is going to be able to find it
<cjwatson> yes, well, I have little sympathy for folks who think pushing the uttermost limits of POSIX is a fun game
<cjwatson> it's technically allowed, but manages to be less useful than all the other filesystems, so ...
<cjwatson> the only real answer I've seen with grub1 is to queue actual grub installation until /target is unmounted, which requires a load more stuff in udebs and has suboptimal consequences for error recovery
<cjwatson> or just to stick a sleep 60 in there, which makes me a sad panda
<verwilst> cjwatson: can't you just sync it or something?
<cjwatson> verwilst: doesn't work, hence my POSIX comment above
<verwilst> oh
<cjwatson> XFS reads the sync spec *very* carefully indeed and does about as little as it can get away with - which isn't enough to let grub actually read the data back
<verwilst> cjwatson: hm
<verwilst> and there's no way to force it to do some more? ;)
<cjwatson> you have to actually unmount the filesystem (or maybe remount it read-only) to force it, and that's logistically very difficult at that stage in the installer, considering that we're running the grub binary from the same filesystem and have other stuff mounted in there
<cjwatson> no other method that's been suggested has worked in my tests
<verwilst> bleh
<cjwatson> you may find it works on some machines - it's a race condition, so that's to be expected
<cjwatson> and sleeping for a minute or so and trying again probably works, but is very unsatisfactory
<cjwatson> meh, where did the dpkg.org A record go??
<cjwatson> s/\?//
<doko> cjwatson, Mithrandir, mdz: who can/wants to comment/approve feistyplusone-toolchain-roadmap ?
<pitti_> cjwatson: oh, I already seriously doubted my memory when I looked for it some days ago...
<pitti_> eventually I found the stuff on wiki.debian.net
<cjwatson> pitti_: thanks, that'll do
<cjwatson> doko: probably not me just now
<pitti_> bhbh bh bh f 
<pitti_> argh
* pitti_ gets rid of the cat
* Ng pictures a cat on a computer with the caption: im in ur laptop, uploadin ur security fixes
<pitti_> wow, that's a pretty amazing pattern it managed to produce while jumping on the keyboard
<_ion> im on ur laptop, developin ur ubuntu
<cjwatson> pitti_: that was almost Irish
* pitti_ tries to pronounce that and wipes off the screen
<cjwatson> "vvvvv", basically ;)
<_ion> I'd pronounce it "bhbhbhbhf", not "vvvvv". :-)
<pitti_> _ion: the cat probably disagrees
* pitti_ imagines the cat would pronounce it as 'get me some attention, you nerd' or so
<pitti_> doko: btw, you know about requestsync? (wrt. changelogs)
<doko> pitti_: yes, but that doesn't solve the problem
<pitti_> yup, just wanted to make sure that you don't file requests manually
<Q-FUNK> it seems that Planner requires an explicit Build-Depends on libdbus-glib-1-dev to build on Ubuntu.  I'll just add it and re-upload to Debian.
<pitti_> Q-FUNK: maybe some later gtk/whatever dropped it? then it might sooner or later bite Debian, too, right
<pitti_> Q-FUNK: hello, bte
<pitti_> btw
<Q-FUNK> :)
<Q-FUNK> I guess it would be a good idea for me to update my ubuntu chroot to feisty and test this before uploading... :)
<pitti_> heh
<seb128> Q-FUNK: that was a transitional bug, time to get some packages rebuilt with the new gnome-vfs, that's fixed now
* pitti_ hails geser for taking over X maintenance
<pitti_> erm, praises
<pitti_> argh @ my English brain cells today
<seb128> pitti_: you want to take over X? ;)
<cjwatson> pitti_: either works
<Q-FUNK> seb128: come again?  would simply re-launching the builds at ubuntu fix it or do I need to update my "upstream" debian package for anything?
<cjwatson> although the latter is slightly better
<pitti_> cjwatson: oh? I thought I mixed it up with 'Uhura, hail the Klingons'
<seb128> Q-FUNK: retry a build should work, if not there is some package still shipping a .la mentioning the lib which should not
<seb128> Q-FUNK: common GNOME libs have been rebuilt, planner might use a "non-common" lib that needs a rebuild too though
<Q-FUNK> seb128: ok.  can you relaunch those or who should I ask?
<seb128> just ask on the chan if somebody can give a retry to the planner build
<seb128> some people can do that
<seb128> infinity, Keybuk
<Q-FUNK> ok
* infinity perks.
<seb128> hey infinity ;)
<Q-FUNK> speaking for the devil^Wangel.
<infinity> planner given-back.
<Q-FUNK> thanks!
* Q-FUNK puts himself a to-do to check the logs again in an hour
<infinity> seb128: For the record, you should recommend me or Mithrandir for give-backs.  Keybuk's more of a last resort. :)
<infinity> seb128: I'll be working on proper docs and ways to contact the buildd team and sending some stuff to -devel-announce in he next week, though.
<seb128> infinity: ok ;)
<cjwatson> pitti_: the word has both meaning
<cjwatson> s
<Keybuk> in fact, I always ignore any requests for buildd work if either infinity or Mithrandir are around
<Keybuk> I only have the power in case either is hit by a bus
<Keybuk> *honk*honk*
<Q-FUNK> if they get hit by dbus, does it count? ;)
<infinity> If people make nerd jokes and are subsequently hit by a real bus, do we care? :P
<Keybuk> it could be worse; one could get hit by the VESA Local Bus
<Mithrandir> I'm not sure whether VLB is better or worse than the PCI Express
<infinity> Die.  All of you.  Seriously.
<Mithrandir> You can get overrun in 16 lanes.  At once!
<thom> i hate geek humour.
<thom> "humour"
<Mithrandir> it's friday afternoon, I'm sorry. :-P
<infinity> thom: And this is why we get along.
<Q-FUNK> how about a nice game of dbus frogger?
<thom> Q-FUNK: how about a nice cup of...
<Q-FUNK> thom: smile!  you're on candid camera! :-P
<Mithrandir> uh, is malone really, really broken right now?
<Mithrandir> ah, no
<Q-FUNK> infinity: it seems that the takeback on planner worked. thanks!
<infinity> Q-FUNK: NP.
<enrico> Riddell: oh, right, tagcolledit!  Glad you mentioned
<enrico> Riddell: it should build with tagcoll (not tagcoll2), does it not?
<Mirv> pitti: hi, about your debian bug 402145. the package does generate different files for low/big-endian systems, should it still be Arch:all?
<Ubugtu> Debian bug 402145 in voikko-fi "voikko-fi: package should be arch:all" [Unknown,Open]  http://bugs.debian.org/402145
<wasabi__> Welp, 2.6.19 doesn't even seem to see this CD drive
<wasabi__> alas
<bddebian> Howdy
<Riddell> enrico: well the configure check fails at least
<Riddell> checking for LIBTAGCOLL... configure: error: Package requirements (libtagcoll) were not met:
<Riddell> No package 'libtagcoll' found
<cjwatson> ogra_,pitti: any ideas on the gnome-power-manager side of bug 67954?
<Ubugtu> Malone bug 67954 in mouseemu "mouseemu prevents detection of Power button event" [Unknown,Unconfirmed]  http://launchpad.net/bugs/67954
<Riddell> enrico: and changing aclocal to accept libtagcoll2 the include's are a problm
<Riddell> enrico: CommandlineParser.cc:22:29: error: tagcoll/stringf.h: No such file or directory
<pitti> Mirv: oh, does it? they had exactly the same size and looked quite arch:all to me; sorry if that's wrong, I'll just close the bug then
<enrico> Riddell: yes.  It should build with libtagcoll-dev, it surely won't build with libtagcoll2-dev
<pitti> Mirv: oh, and thanks for the reports and caring for a good Finnish support
<pitti> cjwatson: will look in a minute
<enrico> I can  try to port it to tagcoll2 now, but that'd be quite late for etch
<Mirv> pitti: http://packages.debian.org/testing/text/voikko-fi <- it is different for hppa/m68k/mips/powerpc/s390/sparc than the rest
<Mirv> pitti: thanks for having good instructions on how to proceed :)
<enrico> Riddell: I'll try to make it work with tagcoll
<elmo> pitti: if that's an ispell thing, they are indeed endian-specific
<pitti> elmo: no, these are rules files for a system called 'malaga'
<cjwatson> pitti: actually, I might be able to figure this out ...
<Riddell> enrico: oh, so libtagcoll-dev is staying in the archive?
<pitti> cjwatson: I don't have mouseemu installed on my system (we don't install it by default)
<cjwatson> pitti: correct, not yet :-)
<Riddell> enrico: why not just port tagcolledit and scrap the old tagcoll?
<pitti> cjwatson: apparently because this guy has an x86 macbooc
<enrico> Riddell: yes, it does, because of apt-front
<cjwatson> pitti: we're going to need to for >1 button mouse support on intel macs
<pitti> right, I figured
<enrico> Riddell: unfortunately, adept hasn't been ported to ept yet
<cjwatson> hence I'm trying to make it work, since intel-mac-support is one of mine
<enrico> Riddell: it requires libapt-front, which requires tagcoll 1
<enrico> Riddell: I'd really like to get rid of tagcoll 1 and apt-front
<cjwatson> pitti: I think I just need to add a device-added signal in gpm-hal-monitor.c
<Mirv> pitti: they are different files (_b and _l) with different contents, but presumably the upstream could make it unneeded at some point. but apparently the libvoikko currently needs them in that way, different byte-order for different endianness
<Riddell> enrico: this is a tangled web of dependencies
<ogra_> cjwatson, that signal should be there already
<pitti> Mirv: I closed the bug; sorry for the noise
<ogra_> cjwatson, there is power_button_pressed in src/gpm-manager.c in the gpm source
<ogra_> it gets the event from hal though
<cjwatson> ogra_: it doesn't notice when new keyboards appear, which is device_added
<cjwatson> ogra_: this is actually a real problem :-)
<ogra_> does hal notice it ?
<cjwatson> ogra_: mouseemu does its work by creating a virtual keyboard device in userspace
<ogra_> ah
<cjwatson> ogra_: yes, it does - g-p-m subscribes to the signal but does nothing with it
<cjwatson> hal definitely notices, I just patched it :-)
<ogra_> heh, ok
<cjwatson> (only in bzr as yet)
<enrico> Riddell: it is, and I'd like to get rid of some, but mornfall's not currently active on adept
<ogra_> i'll look if there is any kind of patch in a newer gpm
<cjwatson> I think gpm-hal-monitor.c is the right place - I'm happy to write the patch if you can review it
<cjwatson> since I have all the stuff set up here
<ogra_> the one we have is pretty old, i'm still waiting for giskard who wanted to maintain it in debian and ubuntu now ...
<enrico> Riddell: tagcolledit built fine with libtagcoll-dev 
<ogra_> but i think i'll package the new one myself if he doesnt soon come up with anything
<enrico> Riddell: post-etch I'll port it to tagcoll2
<Riddell> enrico: ok
<ogra_> cjwatson, i'm fine with the patch, but i suspect it makes more sense with a 2.17 package
<cjwatson> sure
<ogra_> ah, seems device_added is only used in context with bastteries in gpm
<ogra_> *batteries
<cjwatson> I haven't worked out how it's used at all yet - file/line pointer?
<ogra_> gpm-battery.c uses it
<cjwatson> ah, is this in 2.17?
<ogra_> and gpm-hal.c recieves the event 
<ogra_> yep. just got the source
<cjwatson> there's no gpm-battery.c in 2.16.1 - gpm-hal.c's implementation of device_added is basically empty
<ogra_> oh, ok
<ogra_> i didnt compare the two yet ...
<cjwatson> I'll grab CVS
<ogra_> just grap 2.17.3 from http://ftp.gnome.org/pub/gnome/sources/gnome-power-manager/2.17/
<cjwatson> too late
<ogra_> thats what will be in the next package
<ogra_> ok :)
<pitti> Riddell: MIR exiv2 -> it's still in NEW, and the (absent) soname handling of the lib makes me weep
<Riddell> pitti: I've not looked at it (I didn't write the MIR) but the Debian packager did say the versioning is unclear
<pitti> yes, we probably have to live with that
<pitti> I'd just like to take a look at the binaries when they go out of NEW, before that the rdepends won't build anyway
<pitti> the rest is okay
<Tonio_> pitti: hi
<iwj> Keybuk: Do you want me to pick up UdevEvms ?  I have a setup here which would make it quite quick to do I think.
<Tonio_> pitti: yeah sorry I wrote the MIR a bit too soon
<pitti> Hi Tonio_
<iwj> As it's just the same as UdevLvm but for EVMS.
<Tonio_> should have wait for the packages to be out of NEW...
<Keybuk> iwj: sure
<pitti> Tonio_: no problem, I just let it sit there for a while
<Tonio_> pitti: okay
<pitti> Riddell: firefox-themes-ubuntu, rss-glx, gftp, libgd-graph-perl, oo.o, and quagga will work with graphicsmagick, too?
<Riddell> pitti: hmm, good question
<ryanakca> I don't know if this is the right place to say this, but on http://packages.ubuntu.com/cgi-bin/download.pl?arch=i386&file=pool%2Fmain%2Fg%2Fglibc%2Flibc6_2.4-1ubuntu12_i386.deb&md5sum=3d7d40e703e91d16e54e64525174d38f&arch=i386&type=main  ,  there are several broken links 
<spike> cjwatson: dunno if you ever managed to have a look to that email I sent you about preseeding and serial console, but just wanted to update you that the problem exists on "real" servers too, completely different hw than the one reported in my email
<cjwatson> spike: ok, problem is that I have no experience with serial consoles and no hardware here with which to even start trying to reproduce it ...
<spike> cjwatson: actually I 'spose I could give edgy a try before anything else
<spike> I'll do it on moday and report back
<spike> monday*
<cjwatson> spike: could you humour me and try adding 'debian-installer/locale=en_US.UTF-8 kbd-chooser/method=us' to your boot parameters?
<iwj> dbus--
<pitti> hmm, if I fork() in a program, the child looses all global variables?
<cjwatson> spike: because even at priority critical, the locale question is going to be asked, and you aren't preseeding it ...
<pitti> (and allocated heap variables)
<spike> cjwatson: re-read the email I sent: if I remove the serial console it works just fine, which means preseed of itself works
<spike> cjwatson: if I plug in a monitor and let it go, without serial console, it works
<spike> without any change
<spike> besides, I've got d-i debian-installer/locale string en_GB and d-i console-keymaps-at/keymap select uk
<spike> in my preseed file
<cjwatson> spike: localechooser is sensitive to whether a serial console is attached. please humour me.
<spike> oh, good point, will do, thanks
<cjwatson> spike: those preseeds won't do anything in your preseed file - the preseed file is read after that point
<Keybuk> pitti: in which language?
<pitti> Keybuk: C
<Keybuk> err?
<cjwatson> kbd-chooser/method is recommended over console-keymaps-at/keymap
<Keybuk> no...
<spike> cjwatson: ok, updating everything and trying,thanks
<Keybuk> if you fork in C, and have lost access to the heap or globals, then Mr Pointer has fallen out with Mr Boundaries
<pitti> Keybuk: hm, right, I just eliminated the fork(), still doesn't work; nevermind
<cjwatson> spike: there's a special different template that's asked in localechooser in the event that you have a serial console
<cjwatson> so I suspect that preseeding it properly, as recommended, will work
<pitti> Keybuk: in main() I allocate a global char**, and in the child it's suddenly NULL; I suspected the fork() at first, but must be something else
<Keybuk> yeah, definitely not the fork
<cjwatson> global in what way?
<cjwatson> you mean static?
<Keybuk> the only difference after a fork is the return value from that function
<pitti> cjwatson: yes
<cjwatson> file-scoped?
<pitti> cjwatson: right
<pitti> Keybuk: well, and fds are closed
<Keybuk> pitti: no, fds aren't closed
<pitti> argh, /me headdesks
<cjwatson> fds are closed on exec not fork
<Keybuk> cjwatson: and then only if so marked
<cjwatson> indeed
<pitti> yup, found it; PEBCAK of course
<pitti> sorry for the noise
<bddebian> cjwatson: Hey, sorry to bug you more but I don't see an attal-themes-medieval source package on packages.u.c or apt-cache madison??
<cjwatson> bddebian: correct
<cjwatson> what's your point? :-) I said that was a new source, not yet synced
<cjwatson> attal-themes-medieval |    0.9.2-1 |      unstable | source, all
<Keybuk> pitti: Problem Exists Between Coffee And Konciousness?
<cjwatson> it's in Debian
<bddebian> cjwatson: We have 10.x in Ubuntu
<pitti> Keybuk: Between Cut and Krackful paste, rather...
<bddebian> They aren't seperate sources anymore.  The upstream build system changed where you can't build attal without a themes package now
<cjwatson> bddebian: new-source can't tell; if it shouldn't be synced, it needs to be blacklisted
<pitti> Keybuk: 'char ** foo = ..' doesn't really change the global foo that I added after that...
<cjwatson> bddebian: there's no safe way for it to say "the version number of this source package is less than that other version number over there somewhere, therefore I shouldn't sync"
<bddebian> cjwatson: Right, sorry.  How should I handle that?  File a bug to ask for it to be blacklisted?
<cjwatson> bddebian: ask Keybuk, who has the file open in vim such that I can't just do it now ;-)
<Keybuk> heh
<Keybuk> Keybuk ALWAYS has the file open
<Keybuk> he's a bitch for that
<bddebian> hehe
<bddebian> Keybuk: Sooo? :)
<Keybuk> it's in the other blacklist file
<Keybuk> (the one in my head)
<bddebian> heh
<Keybuk> E: attal-themes-medieval_0.9.2-1.diff.gz (from attal-themes-medieval) is in the DB but isn't an orig.tar.gz.  Help?
<Keybuk> ooh
<Keybuk> nice error
<Keybuk> now I remember why I didn't sync it <g>
<Keybuk> you want it blacklisted?
<elmo> wtf
<bddebian> Keybuk: Yeah, in Edgy we jumped the debian version and the themes package is built from the attal source package now
<Keybuk> right
<Keybuk> so you want that blacklisted properly?
<bddebian> Is it my place to make that decision?
<Keybuk> elmo: that's my favouritest EVAH error.  I like it when Soyuz says "Help?"
<Keybuk> bddebian: it is now
<bddebian> hrm
<bddebian> Sure blacklist it and kick the Debian maintainer to wake up and get our version ;-P
<cjwatson> Keybuk: is it randomly matching on filenames in the hope that one of them might be a .orig?
<elmo> Keybuk: that's my code
<elmo> cjwatson: no
<elmo> it's specifically asking for an orig.tar.gz
<elmo> and soyuz said "here have this diff.gz instead"
<elmo> that smacks of some horribleness in the DB
<Keybuk> we had that version in dapper
<elmo> oh, sorry, no, I'm entirely lieing
<Keybuk> as a source package
<Keybuk> elmo: err, this source looks utterly bogus <g>
<elmo> Keybuk: which source?
<cjwatson> ogra_: am I likely to be able to run the gnome-power-manager binary built from CVS without bothering to install it, just with the data from the existing package?
<elmo> sync-source or the package we're talking about?
<Keybuk> elmo: sync-source
<Keybuk> it looks like it'd fail whenever the DB can fess up the source package requested
<Keybuk> it's failing because we do have that source in Ubuntu, just published in an older release
<cjwatson> mm, yeah, we do
<cjwatson> cute
<ogra_> cjwatson, well, you will miss some patches, but yes
<Keybuk> WHAT IN THE NAME OF THE MOTHER OF ALL THAT IS HOLY AND GOOD IS "iceape" ?!
<cjwatson> seamonkey (full mozilla suite) renamed
<Keybuk> sheesh
<Keybuk> Debian are insane
<cjwatson> or maybe just what used to be mozilla-browser. something like that anyway
<cjwatson> the ice{ape,dove,weasel} naming scheme is quite cute, I think :)
<pitti> cjwatson: did you see the icons? they are even cuter
* dholbach likes the humping weasel: http://mik.unpackable.org/humping_iceweasel.gif
<dholbach> and there's icedax too
<Keybuk> what's icedax?
<Spads> chatzilla?
<dholbach> cdrkit stuff
<Keybuk> crazy
* Keybuk adds wildcard support to the blacklist file :)
<dholbach> ROCK :)
<Keybuk> ice* muahahaha
<pitti> Keybuk: while you are at it, can you blacklist enigmail?
<pitti> Keybuk: we have to permanently fork due to that renaming, too
<Keybuk> pitti: what did they call that?  iceotter?
<pitti> Keybuk: icedove
<pitti> (thunderbird)
<Keybuk> icedove is thunderbird, isn't it?
<Keybuk> right ?
* Keybuk confused
<Keybuk> enigmail is its own source
<pitti> right, see above
<Keybuk> yes ...
<pitti> Keybuk: yep, but it produces the tbird enigmail plugin
<Keybuk> but they're not renaming that source?
<Keybuk> sure, but we can merge that, no?
<Keybuk> blacklist = no sync, no mom, etc.
<pitti> they even use icedove'ish sdk tarballs in the upstream package, so there's not much to merge
<pitti> not blacklisting it doesn't really hurt, it's just a bit confusing
<Keybuk> I need to blacklist "mozilla" though
<Keybuk> that's a transitional package to iceape now
<jdub> banshee deps on boo... interesting
<pitti> hey jdub
<keescook> mornin' all
<pitti> Keybuk: ok, so I got the renaming /etc/udev/rules.d/85-hal.rules -> 95-hal.rules ready; that's confirmed to be the One True Rank now?
<Keybuk> pitti: yeah, much better place for it
<pitti> ok, then I upload this now
<pitti> cjwatson: uploaded your hal patch with that version, in case you want to do Malone juggling for that
<cjwatson> pitti: thanks
<Riddell> cjwatson: fancy promoting a bunch of things to main for me?
<cjwatson> pitti: what's supposed to set HAL_PROP_INPUT_DEVICE?
<cjwatson> Riddell: would prefer if Keybuk could do it - I'm beneath a stack of things about six deep at the moment and am terrified of losing context :)
<Keybuk> Riddell: which things?
<Riddell> Keybuk: libofa, libwibble, libpqxx, xdg-utils
<Riddell> all sources and binaries
<Riddell> all approved by pitti
<cjwatson> Keybuk: has DEVNAME gone away?
<cjwatson> hmm, no
<Keybuk> cjwatson: hope not! :p
<cjwatson> just trying to work out why hald seems to think it's empty here
<Keybuk> Riddell: done
<cjwatson> 17:37:07.078 [I]  osspec.c:226: SEQNUM=2755, ACTION=add, SUBSYSTEM=input, DEVPATH=/sys/class/input/input54, DEVNAME=, IFINDEX=0
<cjwatson> 17:37:07.079 [I]  hotplug.c:171: /sys/class/input/input54 is a class device (subsystem)
<cjwatson> (why yes, I am stopping and starting a uinput program rather a lot)
<Riddell> thanks Keybuk 
<Keybuk> cjwatson: what does udevmonitor -e say?
<cjwatson> Keybuk: ... oh, never mind, I've just spotted that the subsequent add of /sys/class/input/input54/event6 came with a DEVNAME
<cjwatson> udevmonitor doesn't list DEVNAME for either though
<Keybuk> weird
<Keybuk> that implies there was no device for it?
<cjwatson> ah, no, it does later on
<Keybuk> [UEVENT]  is what came from the kernel
<cjwatson> that devpath seems to get added, then removed, then added again
<Keybuk> [UDEV]  is what udev thought about it
<cjwatson> oh, ok, I just suck then
<cjwatson> I've been deep in the twisty udev/dbus/hal/g-p-m stack for hours
<cjwatson> damnit, why does gpm_hal_device_has_capability not work
<seb128> could anybody give a retry to gedit build on amd64?
<elmo> Burgwork: ping
<Burgwork> elmo: pong
<Burgwork> geez, everybody is looking for me
<iwj> Keybuk: udev-evms done too.  Let me know if I can be of any more assistance.
<Keybuk> iwj: want to go at udev-devmapper? :)
<Keybuk> complete the trilogy
<Keybuk> udev-device-mapper ?
<LaserJock> Burgwork: you're a wanted man ;-)
<iwj> Keybuk: Sure.  Very much the other end of the spectrum.  I'll take a look at that on Monday.
<iwj> It's good that I've had an excuse to play with udev, which I previously didn't understand at all.
<Keybuk> it's not too difficult really; it's basically just a rule processor for events from the kernel
<Keybuk> the trick is mostly understanding the kinds and content of events for each device
<Keybuk> would be good to have someone else on the team who can grok it
<iwj> mvo: http://www.chiark.greenend.org.uk/~ian/bzr/apt-breaks-iwj/ has that dist-upgrade Breaks: fix.
<iwj> mvo: But I still need to talk to you about the dist-upgrader.
<iwj> Keybuk: It's a crazy crazy programming language.
<dholbach> iwj: mvo is not here
<iwj> dholbach: Oh, is he on holiday already ?
<Keybuk> iwj: it didn't start out as one
<dholbach> no, he was travelling and should be around a bit later
<Burgwork> elmo: pm me if needed
<Keybuk> but has had turingness bolted on
<iwj> dholbach: Ah.  There's no urgency; it can wait until next week.  The apt thing is something mvo asked for.
<dholbach> alrighty
<iwj> Keybuk: Always happens.  It's usually best to design it in.
<Keybuk> iwj: if I didn't know better, I'd say there was a planet-sized hint going on there :p
<iwj> I don't do hints :-).
<iwj> But now that you come to mention it ...
<iwj> *grin*
<iwj> Keybuk: Is that `watershed' feature going to make it into the archive soon ?  I haven't really tested the raceyness or otherwise of the evms change because it depends on watershed to avoid the race.
<Keybuk> iwj: yeah, the patch is sitting in my inbox, I just haven't got around to testing it yet
<iwj> Keybuk: If you mail me a copy when you have a mo I'd be happy to look at it.  It's the kind of thing that can be subtly wrong.
<iwj> So another brain thinking about it would probably be worthwhile.
<Keybuk> I've got a small stack of udev changes that need doing, I should probably tackle them soon next week
<iwj> Right.
<Keybuk> need to see how this modprobe patch works as well
<iwj> modprobe patch ?
<Keybuk> it builds modprobe into udev
<iwj> Yikes.
<Keybuk> so you don't need to parse modules.alias, modules.dep and /etc/modprobe.conf every time a device gets inserted
<iwj> That would be a win, I suppose.
<Keybuk> also means we can do fast lookups of modalias strings into driver names (when we get that kernel patch)
<Keybuk> so can make device/driver binding decisions in udev
<mvo> hey iwj - you wanted to discuss something?
<jdong> keescook: another universe security thing.... flexbackup
<jdong> keescook: in dapper/edgy, temporary file creation insecurity
<keescook> jdong: yeah, I think I saw the CVE go by for that.
<siretart> did anyone already request to get ubuntu-devel-discussed added at gmane?
<sfllaw> kylem: What do you know about ACPI, Power Buttons, and Laptops?
<kylem> not a terrible amount, mjg59 would be your best bet...
<sfllaw> mjg59: What do you know about ACPI, Power Buttons, and Laptops?
<Burgwork> sfllaw: what he doesn't know is a better question
<Adri2000> builds in "dependency wait" are automatically re-ran as soon as the dependency is available?
<sfllaw> mjg59: https://bugs.launchpad.net/distros/ubuntu/+source/gnome-power-manager/+bug/68760
<Ubugtu> Malone bug 68760 in gnome-power-manager "no power button in edgy" [Undecided,Needs info]  
<sfllaw> mjg59: Basically, the system is not responding to the PWRF.
<sfllaw> mjg59: I'm wondering if it's using the PWRB instead?
<sfllaw> mjg59: My machine also exhibits similar behaviour, although it's a Thinkpad T60p.
<giskard> sfllaw, i guess it's an acpi problem
* giskard thinks he should really update g-p-m
<sfllaw> giskard: It looks like some problem with Linux-ACPI and not userland ACPI.
<LaserJock> when is dash used and when is bash used? I don't quite understand
<giskard> bash is used as shell, dash is used for the pre/post script, afaik.
<giskard> sfllaw, if linux-acpi means kernel side, yes.
<LaserJock> well, but on a user's system
<LaserJock> I'm getting bug reports about breakage in apps, supposedly from bash->dash
<_ion> dash is used for scripts, bash is used as the interactive shell.
<sfllaw> LaserJock: /bin/sh is dash now.
<LaserJock> I know
<_ion> Such scripts should be fixed, either by modifying them to POSIX syntax or changing #!/bin/sh to #!/bin/bash
<LaserJock> but the user's shell is still bash, right?
<mc44> yep
<LaserJock> hmm, do we  have any automated way to know when something has broken because of bash->dash ?
<giskard> all script run with  set -e
<cjwatson> LaserJock: checkbashisms (in devscripts) is a pretty good start
* cjwatson makes pbbuttonsd chew marginally less CPU
<Fujitsu> cjwatson: Can you please finish off #43150 if/when you have the time?
<cjwatson> still way too much polling in there, but it's probably a kernel problem ...
<LaserJock> cjwatson: ah, thanks for the tip. texmacs seems to have several plugins with bashims
* Fujitsu chews cjwatson's CPUs.
<cjwatson> Fujitsu: looking
<Fujitsu> Thanks.
<cjwatson> Riddell: thanks for your ubiquity patch yesterday, but unfortunately it still doesn't seem to show the nested list of radio buttons under "Guided - use entire disk"
<cjwatson> Riddell: it's supposed to look like this:
<cjwatson> * Guided - use entire disk
<cjwatson>   * <description of first disk>
<cjwatson>   * <description of second disk>
<cjwatson>   * ...
<cjwatson> * Manual
<cjwatson> at the moment I just get the outermost list
<_ion> Now that ubuntu-devel@ is moderated, i wonder how frequently/actively the moderation queue is checked?
<LaserJock> _ion: heh, I thought it was > /dev/null
<cjwatson> Fujitsu: I believe I have to wait for gcl to build everywhere before accepting maxima. Please https://launchpad.net/distros/ubuntu/+source/gcl/+subscribe yourself in the meantime, as MOTU/SRU says
<Fujitsu> cjwatson: That is correct, and that I shall do.
<Fujitsu> I've subscribed to both.
<cjwatson> I saw you were already in a team subscribed to maxima.
<Fujitsu> That is correct.
<Fujitsu> Thanks for finishing this off.
<cjwatson> sorry for the delay
<bluefoxicy> Alright
<bluefoxicy> I'm gonna go out on a limb and try to get qvm86 to work, and get Edgy or Dapper to boot under it
<bluefoxicy> I'm thinking two things:
<bluefoxicy> A) Someone buy KQemu so that @%*@( gives us the source code
<bluefoxicy> B) Get qvm86 running Ubuntu
<bluefoxicy> (B) will be cheaper, me thinks.  Either way, I want something that I can throw onto the LiveCD that when popped into a Linux/Windows host will go, "Oh, you want to run the LiveCD in a virtualized environment?" and do so at full speed.
<shackan_> you want to ship qemu with the livecd?
<bluefoxicy> (there's also option (C), I start probing KQemu myself and reverse-engineer it)
<bluefoxicy> shackan_:  it's been a flighting fantasy of some liveCD makers to have the liveCD run without booting off it; in fact, IIRC a specific version of Knoppix loads Qemu when it's stuck into a Windows machine
<bluefoxicy> but it's slow as ass.
<shackan_> doesn't seem something worth spending one's time on, especially when you could improve qvm86 instead
<bluefoxicy> qvm86 is a GPL'd RE of kqemu, which is support framework for qemu
<shackan_> I know
<shackan_> vmplayer is too slow too ?
<bluefoxicy> vmplayer is not BSD/GPL/LGPL
<bluefoxicy> I highly doubt they're going to stick that on the LiveCD
<shackan_> ok, and neither is kqemu
<bluefoxicy> qvm86 is
<shackan_> but what's so wrong about kqemu ? it can't be distributed or something ?
<bluefoxicy> kqemu can be, but it'll take money, which can be avoided
<bluefoxicy> yes
<bluefoxicy> hold on a sec
<bluefoxicy> http://qemu.org/qemu-accel.html
<bluefoxicy> The QEMU Accelerator is free to use, but it is a closed source proprietary product. You are not allowed to distribute it yourself to other people without an explicit authorisation. Distributors wishing to include the QEMU accelerator on CDs, ISO images or packages must contact the author to know the exact terms.
<bluefoxicy> shackan_:  he is tightly controlling it because he wants a wealthy venture capitalist to rain money down on him
<shackan_> bluefoxicy, there's nothing wrong with willing to make money from your work :)
<bluefoxicy> if someone wants to buy it off him that's great; but there's no market for it and nobody's paid him anything yet, and i'm not rich, so I need another route
<shackan_> so qvm seems the only way, if you have the skill and a lot of time to invest
<bluefoxicy> shackan_: http://thread.gmane.org/gmane.comp.emulators.qemu.qvm86/19/focus=19 btw updates qvm86 to be closer to kqemu 1.3
<shackan_> (I still don't buy the idea of emulating live cds)
<bluefoxicy> why not
<shackan_> because I don't see the issue in rebooting for a sec
<bluefoxicy> having to close all open programs?
<bluefoxicy> I would hate to reboot right now
<bluefoxicy> my IRC buffers are full etc etc
<bluefoxicy> I have dozens of firefox tabs open and such
<bluefoxicy> And I know a lot of people who think LiveCDs will trash your hard disk
<bluefoxicy> especially college teachers that have a heart attack when i throw one into a machine
<shackan_> which is stupid
<bluefoxicy> I know.
#ubuntu-devel 2006-12-09
<shackan_> I know the hassle of burning a cd and rebooting, I haven't burned isos for years, always installed writing to my real disk from vmware (always without a hitch)
<shackan_> but I install a new operating system at most a couple of times a year, how often do people try out new livecd, actually ?
<bluefoxicy> shackan_:   What would be the overall detriment?
<bluefoxicy> about 400-600k of space used on the livecd...
<shackan_> it's just a lot of work (to get qvm86 into good shape) for an uncommon use case, people will just slap the cd and reboot
<bluefoxicy> shackan_:  if I can make qvm86 run Ubuntu as-is I won't need much work.
<shackan_> then, just do it :)
<jdong> is feisty to adopt cdrkit instead of cdrecord?
<jdong> apologies in advance if that's a stupid question
<cjwatson> I believe so
<cjwatson> it's already been synced and stuff
<jdong> yeah, looking at my madison-lite it seems like it
<jdong> cdrecord is being provided by cdrkit
<jdong> cool
<jdong> cjwatson: who is typicall in charge of the burning stuff?
<cjwatson> we generally go with that sort of thing unless there's a particular reason not to
<cjwatson> jdong: nobody really in Ubuntu
<jdong> ok
<jdong> I was just wondering if it'd be a worthwhile backport for Edgy
<jdong> I've heard cdrkit is supposed to solve some cdrecord bugs
<jdong> and it just built fine for edgy and I'm testing burning some ISO's at the moment
<bluefoxicy> THE CLICKING IS PISSING ME OFF
<cjwatson> it's a bit messy - transitional packages and stuff
* bluefoxicy CPU makes staticey noises when it's busy.. electrical... it's not even the hard disk ugh...
<jdong> bluefoxicy: capacitors
<jdong> bluefoxicy: not CPU ;-)
<bluefoxicy> jdong:  throttle someone
<jdong> I love you too, bluefoxicy :)
<bluefoxicy> jdong:  how's your pax kernel :)
<jdong> bluefoxicy: vdso=0 didn't do the trick
<jdong> but oh well
<jdong> I should play with the options a lot more when I get a chance
<jdong> I definitely believe it's PaX causing it
<jdong> but even pax_softmode doesn't help
<jdong> and I can't exactly stack trace or coredump in initramfs
<jdong> grsecurity.... blocks dumping core because it's greater than 4096bytes
<jdong> and btw, bluefoxicy, I have seen a case where a livecd does cause windows to fail booting up
<jdong> as silly as it sounds
<bluefoxicy> jdong:  nods
<shackan_> how?
<jdong> it happens on a lot of Dell consumer PC's when XP was first released (around that time)
<bluefoxicy> jdong: you got time this weekend to pop in #pax?
<jdong> windows has its special ways of shutting down the machine
<jdong> linux doesn't do it the same way
<jdong> if Linux does the shutdown, XP BSOD's on the next bootup
<jdong> but another 2 or 3 boot cycles will make XP boot ok again
<jdong> really peculiar
<shackan_> eeek
<jdong> but I've personally witnessed it happen
<jdong> and it was the scariest experience
<jdong> so keep that in mind before popping in LiveCD's everywhere :)
<jdong> cjwatson: the transitioning requires a dist-upgrade to effect the upgrade....
<jdong> so hmm
<jdong> though Edgy's update-manager auto-offers dist-upgrade if a standard update can't do the trick
<jdong> wow, update-manager does it without dist-upgrade
<jdong> only at the CLI a regular apt-get upgrade will hold back the cdrecord stuff
<jdong> adept handles it well too
<jdong> requires postinst configuration too
<jdong> ok, no cdrkit for Edgy
<jdong> unless I get a really compelling reason
* jdong installs cdrkit on his laptop anyway
<shawarma> infinity: Do you know anything about the IA64 buildds?
<wasabi> so, there's an odd loop in initramfs which is bugging me. I'd appreciate a knowledgeble body  helping me pinpoint the bug. =)
<wasabi> latest feisty, using md + lvm.
<wasabi> During boot, it looks like, right after premount, the HD's start going into an activity loop.   lights on, lights off, lights on, lights off.
<wasabi> If I run scripts/init-premount/udev and scripts/local-top/mdadm|lvm manually after breaking at premount, and then continue, it works.
<Fujitsu_> wasabi: You can actually tell it to continue? I've never been able to work out how.
<wasabi> just exit apparently.
<wasabi> =)
<Fujitsu_> Argh, that would have made some recovery I was doing a while ago a whole lot easier.
<wasabi> maybe_break seems to just fork a sub shell.
<wasabi> yeah, so I'm running the scripts in order as they're run on their own, and it works fine.
<wasabi> I can only suspect a race.
<wasabi> a race that somehow puts it into a neverending loop...
<sladen> mdz: +1 for -discuss
<sladen> *immediately* and with --force
<psusi> is there a way to set up a batch type postinst step?  that will be done once after all packages are installed?  for something that several packages require, like update-initramfs?
<psusi> rather than having each one do it again and again in their own postinst
<infinity> shawarma: What do you want to know about the ia64 buildds?
<psusi> that reminds me... is there a way to get shell access for pbuildering purposes on an ia64 server?  how about ppc?  the defrag package I updated recently failed to build on those platforms.... unfortunately, I only have amd64/i386
<infinity> psusi: We don't have any machines acceissible for non-staff, yet.  It's on the TODO.
<infinity> psusi: I could give you access to a PPC machine in my house, though.  Bug me on Monday?
<psusi> ok... I'd just hate to upload the package a dozen times trying to get it to build over there
<psusi> heh... ok
<lifeless> psusi: someone needs to update defrag to do ext3 :(
<psusi> lifeless, I have
<psusi> want to be a test victim... err... volunteer?
<psusi> ;)
<lifeless> psusi: you have? seet.
<lifeless> *sweet*
<lifeless> now get ted t'so to review the patch :)
<psusi> ahh, yea... he was one of the original authors wasn't he?
<psusi> didn't he used to hang here?
<lifeless> dont think so
<psusi> hrm... is the man page for udev right or is this an error?
<psusi> it says the key will match if the external program returns NONZERO
<psusi> that flys in the face of convention though... nonzero means it failed
<mjg59> Well, except for APIs where that isn't the convention
<psusi> talking shell here, not C ;)
<psusi> program exit()s with 0 means it worked correctly
<psusi> and the shell treats that as TRUE
<psusi> so it doesn't make any sense that udev would do the reverse
<mjg59> Well, unless the applications tend to do something like return the number of matches
<mjg59> Why don't you test it and find out?
<psusi> I suppose I will have to
<Chipzz> ieks
<Chipzz> after upgrading to feisty, my c's look all weird
<jdong> Chipzz: you mean you c a problem?
<jdong> a ha ha ha
<jdong> I crack myself up
<Chipzz> jdong: no, c's are very thin, to the point of being allmost invisible
<jdong> i c
<Chipzz> :P
<Chipzz> o's too apparently
<Chipzz> jdong: http://chipzz.safehex.be/oc.png
<Chipzz> look at the c in december, and the o in subscriptions
<jdong> O, i C, just with the big letters
* Chipzz slaps jdong ;)
<Chipzz> snap out of it ;)
<jdong> Chipzz: u r acting like you haven't herd 1 or 2 bad puns around here recently ;-)
<Chipzz> jdong: sure I have :)
<Chipzz> but the joke got old real fast ;)
<Chipzz> anyway, Russel Coker doesn't show the problem for some reason
<Chipzz> seems to be a bigger problem anyway
<Chipzz> Subscriptions is antialiassed very badly
<Chipzz> look at the top of the S and T
<Chipzz> any idea which package I should file a bug against?
<Chipzz> Setting up ttf-bitstream-vera (1.10-7) ...
<Chipzz> Regenerating fonts cache... failed; see /var/log/fontconfig.log for more information.
<Chipzz> done.
<Chipzz> hrrrm
<Chipzz> apparently fontconfig problem
<Chipzz> after reconfiguring it it's gone
<holycow> hello
<holycow> not sure if this is the right channel so boot me if its not
<holycow> :)
<holycow> is feisty looking like it will keep metacity or use something like compiz as a compositing manager?
<holycow> just curious about aiglx + metacity and whether or not any discussion has been had around that
<Phoenix7477> well, your in the right place i think, but its late and i think anyone who knows is probably asleep or afk :)
<holycow> fair enough its friday, and unlike me,they have a life
<holycow> -_-
<Hobbsee> and it's a saturday
<holycow> touche
<holycow> lol
<Phoenix7477> lol
<superjon> Is feisty built with the new .gnu.hash improvements to speed up the linker?
<superjon> Or *will* it be built with these improvements?
<deltab> holycow: this? https://blueprints.launchpad.net/distros/ubuntu/+spec/composite-by-default
<holycow> ah okay
<holycow> oh jesus
<holycow> beryl and compiz are actually being considered
<holycow> lol thats what i was afraid of. 
<holycow> k danke sir
<holycow> deltab, appreciate that
<Fujitsu> holycow: I don't believe they are being seriously considered any more, fortunately.
<holycow> really? *phew*
<holycow> would be nice NOT to become fedora i think, officially running pre alpha stuff ... heh
<Fujitsu> A lot of people were rather... angry? ... when it was announced as a specification.
<holycow> yeah, we are starting to weer into some uncharted territories
<holycow> the distro for human beings i think means not using its userbase as a huge guinea pig population
<holycow> there are distros that specialize in running very untested stuff ... some thought needs to be given to stability vs. latest and greatest
<holycow> but thats just an opinion of a nobody at a time when there isn't anyone to read it :)
<superjon> Yeah it is called Foresight Linux... distro that runs broken^H^H^H^H^H^H Bleeding edge code
<holycow> heh never heard of that
<holycow> i was thinking gentoo :) but y'know 
<holycow> still funny
<superjon> http://foresightlinux.com/ based on rpath's conary package manager, bleeding edge gnome+mono, etc, etc
<holycow> wow
<superjon> are you the same holycow that was always in #hula awhile back?
<holycow> hey dude
<holycow> indeed
<holycow> :)
<holycow> its funny you remember the nick i didn't make much noise in there
<superjon> nice
<holycow> i'm still keeping an eye on hula
<superjon> well there were 2 cow users as I remember
<holycow> i know novell stoped dropping resources on it but ya never know it could still end up being the bling
<superjon> So am I, but they are furiously trying to work on hula-store which is a dead end
<superjon> If they would just release a 1.0 of hula-lite, distributions would likely adopt it
<holycow> actually that is probably some of themost sensible opinion i've heard on hula in a while
<superjon> Who *wouldn't* want dragonfly's beautiful webmail ontop of a rock solid postfix / sa setup?
<holycow> superjon, indeed
<holycow> btw, if anyone cares ...
<superjon> Alex Hudson seems to be the new "leader" from what I see in the ML, but he thinks hula-store is the way to go. Rewriting all of that is what caused campd to leave novell
<holycow> the reason i'm asking about the metacity/aiglx stuff is because i'm piloting ubuntu at work
<superjon> For normal desktops, or "techie" desktops?
<holycow> normal deesktops *nod*
<superjon> 3 people on my team of 5 run ubuntu desktops at work
<holycow> i'm hoping NOT to hear that compiz/beryl become some sort of standard especially for the next lts
<superjon> Well people dont quite understand what that means
<holycow> dapper has turned out to be a seriously superb desktop
<superjon> If beryl was used by default, it would use the heliodor window decorator which shares metacity themes and would be seriously toned down
<superjon> No wobbly windows by default
<holycow> its not that, its just seriously faulty software
<superjon> The cube switcher, expose clone, dimming unresponsive windows, and minimize animations are actually more usable
<superjon> Have you actually used a recent release?
<holycow> no its beena while but the stuff is still what ... alpha?
<_ion> Shadows are also nice. They actually improve usability IMO.
<holycow> _ion, they do
<_ion> They have matured nicely.
<superjon> I've ran it for the past 3 months with few problems. The beryl leader, quinnstorm is solely working on bugfixing of the core
<holycow> i think waiting to see how metacity starts handling stuff is a better strategy long term
<holycow> we loooooove to reinvent the wheel in th eopen source world and thats fine as an experiment
<superjon> holycow Read what Elijah Newren, the metacity maintainer says
<holycow> but throwing out years of dev experince on metacity is kinda scary
<holycow> okay googling
<superjon> The guys at redhat (mainly Soren) who were doing the metacity compositor dropped it dead. They moved to compiz
<jdub> holycow: pretty strong agreement on d-d-l that pushing it into metacity *isn't* the right thing to do
<jdub> holycow: while most of the metacity window management rules have been lifted into compiz
<holycow> jdub, really?
<Hobbsee> jdub: d-d-l?
<superjon> From what I read in the gnome mailinglist(s), compiz will likely be the longterm solution with metacity staying as a fallback and for thin clients
<tepsipakki> desktop-devel-list
<Hobbsee> ahhh
<holycow> oh i see
<holycow> hense the reference to metacity being a button / applet or checkbox or somesuch on the above linked page
<holycow> interesting
<holycow> jdub, thx for the heads up onthat
<holycow> gives me a direction to watch for i think
<superjon> jdub: Would you happen to know if feisty is being built with DT_GNU_HASH to improve the linker times?
<tepsipakki> superjon: if that's what glibc-2.5 brings in, then yes, I suppose..
<jdub> superjon: no idea
<superjon> but it has to be enabled in the configure options
<superjon> Just like -fstack_protector has to be added
<superjon> http://www.elfenbeinturm.cc/2006/07/12/dt_gnu_hash-update/
<superjon> http://sources.redhat.com/ml/binutils/2006-06/msg00418.html here is the actual post on it
<Treenaks> superjon: -fstack_protector is being used by default afaik
<superjon> Treenaks: Yes, that is correct. I was using that as an example though
<Phoenix7477> anyone here familiar with programming in C?
<Burgundavia> BenC: your KernelPatches page, can we talk about it in the UWN?
<BenC> UWN?
<Burgundavia> ubuntu weekly news
<BenC> sure
<BenC> is it news worthy? :)
<Burgundavia> sounds good, thanks
<Burgundavia> it is more "public information service" than specific news, but yes, it is news worthy
<BenC> excellent
<BenC> Burgundavia: I'll let you know if I create any more wiki pages out of shear frustration :)
<Burgundavia> will do
<Burgundavia> getting information out is one of the goals of the marketing team
<Burgundavia> sometimes that means internally
<superjon> BenC: Is the Feisty toolchain using DT_GNU_HASH linker improvements by default? You of all people would know this
<BenC> no, doko and jbailey of all people would know this
<superjon> Ok, so you don't know?
<BenC> I've been meaning to ask them though
<BenC> no, not off hand
<superjon> Alright, thanks
<BenC> np
<superjon> I'll shoot them an email
<shawarma> infinity: Well, I have a build that fails on ia64 (and sparc, as it turns out). The package is apcalc and it fails during regression testing. The test that fails is a check to see if file descriptor 3 is attached to a tty.. So it could either be the detection code that messes it up, or file descriptor 3 on ia64 and sparc buildd's could actually be attached to a tty. 
<shawarma> infinity: So the question is: Is anything special being done on ia64 and sparc buildd's that could make file descriptor 3 attached to a tty?
<shawarma> infinity: The Debian builds of it worked fine. :-/
<Fujitsu> Is MoM not updating, or am I imagining it?
<infinity> shawarma: There's nothing "special" about them, compared to the other arches.
<Hobbsee> Fujitsu: i'm not sure, i just tried to do a merge and found it was already done
<Fujitsu> Hobbsee: I've tried to do quite a number, and found they'd been done. Quite a number of syncs have been filed, and they've already been done... It's all being nice and counter-productive.
<Hobbsee> heh
<Riddell> infinity: do you know what the status of the digikam 1:0.9.0~rc2-0ubuntu2 build is?  it seems to have been building since yesterday on i386
<shawarma> infinity: That's odd.
<infinity> shawarma: The existance of that as a rgression test seems odd anyway.  Why would we care if fd3 is a tty?
<shawarma> infinity: Oh, well, qemu can emulate a sparc, so I guess I could try doing a build in one of those.
<shawarma> infinity: Oh, I don't think that's the purpose. I think the purpose is to check if isatty does the right thing, and it's assumed that fd 3 i not a tty.
<infinity> Riddell: Err, it's not building, it's dep-wait.
<Riddell> hmm.  hmm.  launchpad said it was building just a second ago
<infinity> shawarma: Odd assumption to make, given the sorts of perverse shell tricks people like me are known to pull. :)
<shawarma> infinity: But yes, it would seem quite odd to have a regression test that was actually testing the build environment. :-)
<infinity> Riddell: Probably a dep-wait loop, cause it has a build-dep in universe.
<infinity> libexiv2-dev
<Riddell> yep, thanks
<shawarma> infinity: Indeed. Maybe I should just change it to file descriptor 38. That should be good enough for most people. :-)
<infinity> Riddell: Time for an MIR for exiv2.
<infinity> shawarma: Alternately, of course, it could be that isatty is actually misbehaving.
<Riddell> yeah, we have one, it was just for exiv2 to pass NEW
<infinity> shawarma: Given than I can think of no reason why fd3 would be any different on ia64 and sparc than on the other arches.
<shawarma> infinity: True. The code looks very innocent though. And if it fails on fd 38, it's *definitely* the code that's failing.
<infinity> Riddell: Oh, there's an approved MIR already?  I can promote it, if that's the case.  (it's in universe currently)
<Riddell> infinity: it's not been approved by pitti yet
<infinity> Riddell: Ahh, kay.  Check.
<shawarma> Hmm... I just got a second notice about the same build failing.. Why would that happen?
<shawarma> Do I have to acknowledge it or something to shut it up?
<infinity> shawarma: Because I retried it for kicks.
* Hobbsee waves to infinity 
<jdub> oh man
<jdub> i'm || <- this close to turning off my ubuntu and canonical aliases
<Hobbsee> jdub: why?
<infinity> jdub: I'd question why you still have a canonical one anyway. :P
<jdub> Hobbsee: horrific spammage
<Hobbsee> ah
<CyberT3> first_auth_command=<BEGIN_COMMAND>dhclient %i<END_COMMAND>
<CyberT3> whats wrong with above line?
<cjwatson> Riddell: fixed the lack of disk choice in the KDE frontend - just needed to s/disk_buttongroup\.show()/disk_frame.show()/
<cjwatson> thanks for the help!
<szachista_> hello
<szachista_> i'm not sure if it's a good place for this question, but
<szachista_> where can i report misuse of ubuntu licence?
<szachista_> i have read on fsf site that first it should be reported to the copyright holder
<szachista_> does it mean canonical?
<Riddell> cjwatson: cool
<szachista_> the case is there is oen regional distro, just created few day before, which uses packages from ubuntu repository but it licence says the whole distro is freeware
<Riddell> cjwatson: I'm looking at porting it to qt4 just now
<cjwatson> szachista_: I'd be inclined to mail info@ubuntu.com; most of the time that sort of thing is just a misunderstanding
<cjwatson> they probably aren't actually breaking our licence (and note that we are only the copyright holder of parts of it), just misrepresenting it
<cjwatson> Riddell: neat
<szachista_> cjwatson: well, i was talking with it's author and looks like he really interprets gpl the wrong way :/
<szachista_> cjwatson: ohh... and there is no english version for this licence for now, so is worth to write to cannonical about that?
<cjwatson> if you can provide a reliable translation, sure
<cjwatson> (I think there may be a better address than info@, but I don't remember what it would be ...)
<rob> ajmitch: ping
<StevenK> rob: He is likely sleeping, it's around 1am
<rob> in NZ?
* StevenK nods.
<StevenK> Well, ajmitch is, I'm not. :-)
<rob> ah ok, I'm in aus, its only 10am here (should have thought about that)
<rob> yeah
<rob> err 10 pm rather
* StevenK grins
<Fujitsu> rob: SA?
<Hobbsee> yes, but you're in queensland
<Fujitsu> Ah.
<Fujitsu> That'd do it.
<rob> yep
<Hobbsee> Fujitsu: SA's only half an hour behind.  the flight attendants told us so.
<Fujitsu> A..ha.
<jdub> Hobbsee: half an hour and twenty years.
<rob> I just noticed on sourceforge that he is involved with a project called Scrappy, which sounds like something my wife would be interested in using eventually
<StevenK> Yup. And NT is 1 and a half hours, just to be confusing.
<Hobbsee> jdub: *grin*
* Fujitsu looks for the MoM reset switch.
<StevenK> Fujitsu: Commonly called "Keybuk"
<rob> I was thinking chocolates, but sure, ok :D
* Fujitsu presses Keybuk, and doesn't see any useful effect.
<geser> Fujitsu: wait till it pops up again before pressing it
* Fujitsu thinks it is stuck, and presses it repetitively anyway.
<StevenK> Keybuk or MoM? :-P
<StevenK> MoM might be crashing
<Fujitsu> StevenK: I presume it is crashing, yes.
<Fujitsu> It has a habit of that, of late.
<infinity> Special.  apt-get in my hoary chroot has spontaenously decided to start segfaulting.
<infinity> Fanfreakingtastic.
<Fujitsu> Sounds ideal!
<Hobbsee> infinity: *way cool* - why do you have a hoary chroot?
<infinity> Hobbsee: Why not?
<pitti> infinity: it might be aware that its's supposed to be entirely dead now...
* Fujitsu agrees with Hobbsee on the latter point.
<Hobbsee> infinity: because it's EOL'd?
<Fujitsu> +1 pitti 
<Hobbsee> haha
<infinity> Hobbsee: Old habits die hard.
<infinity> I suppose I should delete EOL chroots.
<infinity> Hell, I still have potato chroots.
<Hobbsee> infinity: got warty ones too, then?
<Fujitsu> Buzz!
<infinity> Hobbsee: Yes.
<Hobbsee> heh
<bhale> Hobbsee: at my parents i found a cdr labeled Warty RC
<bhale> with a solid inch of dust on it
<bhale> history in the making
<Hobbsee> bhale: ...wow
* pitti removed his hoary chroot on November 1st, in a devotional ceremony
<infinity> (base)adconrad@cthulhu:/chroot$ find * -maxdepth 0 -type d
<infinity> breezy
<infinity> dapper
<infinity> edgy
<infinity> etch
<infinity> feisty
<infinity> hoary
<infinity> potato
<infinity> sarge
<infinity> sid
<infinity> warty
<infinity> woody
<Fujitsu> Good old woody.
<infinity> Is woody EOL now too?  Or is Debian still doing oldstable updates?
<pitti> ended ages ago
<infinity> Right.  Guess I can make that go too.
* infinity sheds a tear.
<pitti> infinity: woody support ended in June 2006 IIRC
<pitti> (one year after sarge was released)
<pitti> http://www.debian.org/releases/woody/ agrees
<Whoopie> Hi, is there any plan when the edgy-commercial repo is filled with the packages from dapper-commercial?
<cjwatson> Whoopie: I don't believe that's going to happen automatically; it depends what the companies supporting those packages want to do
<StevenK> infinity: Just one?
<Whoopie> cjwatson: ah, I thought somebody of the devs is filling the repo. So you are waiting until the companies are ready with packages for edgy?
<szachista_> errr... what was that email where i can report ubuntu licence violation? 
<szachista_> sorry, my web browser has crashed ;(
<cjwatson> Whoopie: well, it's not my responsibility, that's just what I vaguely remember
<infinity> StevenK: Several, truth be told.  Woody was a good release, with many fond memories.
<szachista_> i mean i use opera for irc ;)
<StevenK> Heh
<cjwatson> szachista_: info@ubuntu.com was what I suggested, although as I said it may not be quite right
<szachista_> cjwatson: thank you :)
<StevenK> infinity: Do packages need to be given back manually if a dependancy didn't exist?
<Whoopie> cjwatson: ok, thanks.
<infinity> StevenK: Should go into dep-wait, which will be auto-cleared.
<infinity> StevenK: Package in question?
<cjwatson> Whoopie: mdy@c.c deals with that sort of thing from the corporate end, I believe
<StevenK> infinity: libept
<cjwatson> well, libtagcoll2-dev still doesn't exist ...
<infinity> StevenK: https://launchpad.net/+builds/+build/282546
<infinity> StevenK: auto-dep-wait.  It'll clear when the dep can be found. :)
<pitti> do import requests from experimental require an ubuntu-archive bug, or is an IRC ping enough?
<StevenK> Ah, I know why. libtagcoll2 has built, and is stuck in binary NEW.
<infinity> pitti: Paper trails are nice, but IRC can do the trick, if someone's in the mood to do the sync.
<pitti> ok; I'd like to get postgresql-8.2 into feisty, but I cannot upload it to unstable yet since it would disrupt the etch release process
* pitti files a bug
<Fujitsu> cjwatson: I note that gcl has built on all archs.
<StevenK> (Well, I think that's it. I can't check, of course. :-)
<Lure> pitti: re exiv2 MIR - are we supposed to hunt upstream regarding soname or is it possible to accept it as is?
<infinity> StevenK: It's not anymore. :P
* StevenK grins.
<StevenK> Neat, so hopefully libept will be stuck in the same fate soon. :-)
<infinity> Ungh, someone put the tagcoll2 source in universe.
<infinity> And it produces binaries in main.
<pitti> Lure: asking upstream about sane sonames is always a good idea, but I won't insist that it's done before promotion
<infinity> And is, I assume, replacing a previous SOVER from main.
<infinity> GO US.
* infinity fixes.
<StevenK> Ohh, nice.
<Lure> pitti: ok, thanks - I will ping upstream
<infinity> StevenK: Should be good after the next publisher run.
<pitti> Lure: great, thanks
<infinity> StevenK: If not... Bug someone else.  I won't be around. :)
<StevenK> infinity: Nice, thanks.
<StevenK> infinity: :-)
<cjwatson> Fujitsu: yes, I went to deal with it earlier this morning but saw the comment on the bug implying that it may not be properly fixed
<cjwatson> Fujitsu: so I'd like an answer to that before proceeding
<StevenK> cjwatson: I've been meaning to ask, why not Kamion any more?
<cjwatson> I switched while away somewhere because I couldn't get to my home server, and liked it better
<StevenK> Heh, fair enough.
<cjwatson> conversations with Keybuk are easier to follow, if nothing else ...
<Fujitsu> cjwatson: Yeah, I noted that... I think it must be a different bug, as it is fixed for everybody else, and the fix makes sense.
<StevenK> cjwatson: Bwaha
<cjwatson> Fujitsu: I'll wait until Monday for a response from that user, then go ahead
<StevenK> cjwatson: My client hilights the nick of people talking to or about me in red, which makes it simpler.
<Fujitsu> cjwatson: Sounds good.
<jdub> freespire shipping upstart
<Fujitsu> StevenK: Have you not read through conversations where K{eybuk,amion} have been talking to each other, and been confused?
<StevenK> Not usually.
<StevenK> It happens occasionally. :-)
<Fujitsu> When is Keybuk normally around?
<cjwatson> StevenK: so does mine, but it doesn't highlight my own statements visibly enough to avoid confusion when reading back through scrollback
<StevenK> Ahh. My own statements have the <> hilighted in red, which gives me enough of a clue.
<sivang> Lathiat: and now? :)
<sivang> Lathiat: Well, when you do see this message, I was just wondering if you could walk me through again to set up Xorg to work using hardware accel, using the ATI prop driver,
<sivang> Lathiat: you see, the FLOSS one is terrible in even movie playing performance wise.
<Treenaks> sivang: it works OK on my mac mini
<Treenaks> but somehow it forces AGP to 1x always
<bhale> cjwatson: this is a silly question, but does ubiquity call xrandr after the keyboard map selector page?
<bhale> cjwatson: the screen goes totally ape, and it even seems to be rotated on its side from what I can make out
<Riddell> bhale: I also get X corruption at that stage
<Riddell> filing a bug is on my todo list
<bluefoxicy> GAH
<bluefoxicy> Qu'vatlh ghuy'cha' ><
<bluefoxicy> bhale:  ping.  Confirm this for me:  NX-bit supplied 32-bit platform (i.e. amd64 in 32-bit mode), no NX bit, edgy, kernel 2.6.19-7-generic
<bluefoxicy> cpuinfo says I have it
<bluefoxicy> maps says it's set
<bluefoxicy> paxtest says vulnerable to every-fucking-thing
<bluefoxicy> it wasn't like this before
<jdong> 2.6.19 made reiserfs stop retardedly caching its bitmaps at mount, right?
<jdong> so it doesn't take 3 minutes to mount my external HD?
<jdong> ok, I'll assume so and install my test feisty partition as reiser
<jdong> and come back here and nag you guys in 3 hours if it wasn't the case
<jdong> sound good? of course it does :)
<wasabi> xfs yay =)
<wasabi> xfs won't kill your wife, just your files.
<jdong> wasabi: xfs is no friend of the pbuilder though ;-)
<wasabi> </bad>
<jdong> lol
<jdong> wasabi: it's a shame XFS doesn't like to delete files in a timely manner :D
<wasabi> Yeah. That is annoying.
<wasabi> I do wish it had optional data journaling just for completeness too
<jdong> aye
<jdong> wasabi: also, on plebian x86 hardware, I can consistently corrupt XFS though intentional resets
<jdong> so it ain't for general usage....
<wasabi> You mean hard power off?
<jdong> right
<wasabi> Totally. It caches too much
<jdong> hard poweroff and hard reset
<wasabi> You need battery backed stuff.
<jdong> well, not just caching...
<jdong> caching can explain DATA being gone or corrupted
<jdong> not XFS refusing to mount, and xfs_repair zapping everything to lost+found
<jdong> that there is metadata corruption....
<wasabi> Hmm. Haven't had that for a long time.
<jdong> well
<wasabi> There was a bug in... <2.6.16 I think
<wasabi> Which introduced silent corruption.
<jdong> this behavior came back in Edgy for me
<jdong> silent corruption was 2.6.17.1-7
<wasabi> Eh? Thought it was way before that.
<jdong> but what I experienced was not that
<jdong> wasabi: unless you aren't talking about that dnode corruption fiasco?
<wasabi> I don't know what the exact issue was.
<wasabi> I just remember using xfs_db to fix it. =(
<jdong> that's dnode
<jdong> introduced early in the 2.6.17 tree
<jdong> fixed in the point-7 release IIRC
<wasabi> Ahh, yeah, you're right. Just looked it up.
<jdong> and to put salt in the wound xfs_repair wasn't able to detect/fix the issue :)
<wasabi> I got bitten by that.
<wasabi> Yeah. I had to backport it from edgy or something
<jdong> yep
<wasabi> That was depressing.
<jdong> I bugged a while to get that updated xfstools past version freeze
<wasabi> I really do like XFS though. It is noticible faster on the systmes I use it on, than ext, anyways.
<jdong> wasabi: I love XFS too
<wasabi> It really loves dual cores.
<jdong> wasabi: I use it to store my multimedia files
<wasabi> /dev/evms/shares      548G  528G   21G  97% /shares
<jdong> which ext3 and reiser simply choke on
<wasabi> same =)
<jdong> aye, exactly
<jdong> torrents, too
<jdong> ext3 fragments my 20GB torrents into 5 fragments or so per MB by the time it's done
<wasabi> I set up a new box at work last thurs... I started with ext3.
<jdong> needless to say it doesn't exactly read back with ease ;-)
<wasabi> As soon as I got under heavy IO node, xchat locked up.
<wasabi> Blocking on it's log files.
<wasabi> s/node/load/
<jdong> yep
<wasabi> That pissed me off, so I tar'd it all up and went back to xfs
<jdong> reiser is better with data writes
<jdong> but has the same issues with metadata
<jdong> delete 1 million files, you won't be able to move your MOUSE until it finishes
<wasabi> heh
<jdong> (though to be fair it does it at a blistering pace)
<wasabi> wonder why that stuff doesnt' get backgrounded in an intelligent manor.
<wasabi> manner
<jdong> if I understand correctly it's an issue of kernel locks
<jdong> especially with reiserfs...
<jdong> there's some serious scalability issues with reiserfs
<wasabi> I've noticed that too though. Blowing away a 4GB file on XFS... basically locks everything up.
<jdong> if you have like 20 or so of them mounted, all of them will be very sluggish
<jdong> the problem isn't nearly as bad on XFS
<jdong> but yes, it does show up
<jdong> I think on XFS it's purely an issue of the IO scheduler not playing fairlty
<wasabi> I don't really understand why.
<jdong> same with ext3
<wasabi> I've always though it would be a relatively small manner to just write down the delete in some log, and work on it in the background.
<jdong> wasabi: apparently xfs deletion is quite some rocket science
<jdong> I was told that on #xfs
<jdong> there's quite a deal of B+tree rebalancing done in the process
<wasabi> hmm.
<jdong> and all that balancing is inturn eventually deleted anyway ;-)
<jdong> especially if your'e removing a large directory tree
<jdong> that is just screaming to be optimized ;-)
<wasabi> guess nobody is being paid to work on it anymore eh?
<wasabi> there were two sgi contractors i thought... before sgi ate it.
<jdong> there's still sgi folk actively working on XFS
<wasabi> sandeen or something
<jdong> yep
<jdong> Sandeen
<jdong> and there's another one too
<wasabi> Do they actually get paid by SGI?
<jdong> based in Australia
<jdong> yes, they're paid SGI employees
<wasabi> I didn't realize SGI still had paid employees. ;)
<jdong> lol
<jdong> probably not for long :D
<wasabi> so sad
<Yagisan> I used to use JFS instead of XFS, almost same performance, but lower cpu use
<jdong> personally... I hope ext4's promised changes will fix it
<wasabi> I never really looked much at JFS.
<jdong> and make it much more performance-competent
<jdong> JFS is pretty nice
<wasabi> It got merged into mainline after I made teh switch to XFS.
<jdong> though there's a few oddities
<wasabi> So I never really started learning about it
<jdong> i.e. NEVER EVER MOUNT BEFORE FSCKING
<wasabi> heh
<Yagisan> it and xfs where slow on delete so I did recently change it
<jdong> journal replay is done by fsck
<wasabi> and mounting doesn't abort?
<jdong> Yagisan: it's apparently due to the B+tree nature and the need to rebalance the trees on delete
<jdong> wasabi: no, it happily mounts and then starts screaming about node corruption
<wasabi> and that's not a 4 line patch? heh
<jdong> wasabi: you're supposed to mount it ro, fsck it , then mount it rw
<jdong> wasabi: apparently "everyone knows that" :D
<Yagisan> first I heard of it
<jdong> Yagisan: well, good I saved you from looking dumb :D
<wasabi> On the topic of obscoure file systems. I started playing with AFS again
<Yagisan> oddly, I found jfs outperformed xfs on my software raid
<Yagisan> and xfs on non-raid
<Yagisan> (media, torrents, and many many pbuilder runs)
<Yagisan> in the end, I went back to slower ext3 with full journalling
<jdong> Yagisan: jfs is not a bad performer by any stats
<jdong> in fact, I have found JFS to be the most responsive under heavy IO
<wasabi> pbuilder sucks because of deletes, right?
<Yagisan> the low cpu usuage is really nice on jfs
<jdong> wasabi: right
<jdong> wasabi: takes 30s to clean up pbuilder on XFS, 10s on ext3, 1s on reiser
<wasabi> heh.
<jdong> Yagisan: JFS has _consistent_ performance
<jdong> sure it may be slow at times compared to the compettiion
<jdong> but it never wildly fluxuates from task to task
<jdong> *ahem* reiser
<wasabi> I'd sure like to see a file system with COW copies.
<jdong> :)
<wasabi> and yes I realize programs would have to take advantage of it
<jdong> bzrfs
<jdong> lol
<jdong> one day
<wasabi> bzrfs? hah
<jdong> it's not at all impossible
<jdong> python-fuse FTW?
<Yagisan> I have resier on my www server for one reason
<wasabi> I bet you could make a fuse thing do it pretty easy
<wasabi> in fact... googles.
<Yagisan> masses and masses of many small files
<wasabi> I bet somebody else has already thought of it
<Yagisan> (gigs of doxigenated source)
<jdong> I have nothing against reiserfs at all
<jdong> it's been rock-stable for me
<jdong> the only complaint I've had about it is reiserfsck
<wasabi> Oh, also, XFS needs shrinking.
<Yagisan> I had it eat data when I first tried it back in the 2.4.x kernels
<jdong> if you ever have a hardware malfunction that leaves you with a corrupt FS
<wasabi> I love that about reiser.
<jdong> YOU ARE SCREWED WITH REISER :)
<wasabi> online shrinking and expanding
<jdong> have fun :)
<jdong> they should just symlink fsck.reiserfs to mkfs.reiserfs
<jdong> it'll save time
<jdong> and code
<wasabi> I'd also like a way to re-collapse sparse files.
<wasabi> Without closing them.
<jdong> :)
<Chipzz> wasabi: just wondering, how do you create a sparse file in the first place? just write all zeroes?
<cjwatson> bhale,Riddell: no, it doesn't. It does call setupcon, which does ioctl(KDFONTOP), which seems to confuse X in various ways; there is a bug filed already
<cjwatson> hoping not to have to turn that off again, as it's nice for setup-console-under-usplash as well as general simplicity, but I may have to if we can't work out the issue
<wasabi> Chipzz: seek ahead in the file.
<cjwatson> problem is that I haven't seen it on any of my own hardware so far
<wasabi> Chipzz: which basically increases it's size, but writes nothing. the FS can interpret that as using fake blank space
<wasabi> dd if=/dev/zero of=file bs=1M count=0 seek=100 or something
<Chipzz> wasabi: wont that just return an EOF?
<cjwatson> Chipzz: no, see lseek(2)
<cjwatson> it has an explicit paragraph about that at the end of the DESCRIPTION section
<Chipzz> uhu
<Chipzz> thx :)
<dLinkCrawxor> Is it true ubuntu dont fix all bugs thus getting more money through supporting the system?
<Chipzz> heh
<mjg59> Not deliberately, no
<Chipzz> you're implying so bad things
<Chipzz> if ubuntu would do that, they would be shooting theirselves in the foot
<desrt> dLinkCrawxor; ubuntu doesn't get money from support...
<desrt> dLinkCrawxor; except indirectly
<dLinkCrawxor> ok
<desrt> dLinkCrawxor; companies involved in (and sometimes working on -- that's the indirect) get the money
<Chipzz> dLinkCrawxor: not every bug gets fixed; but I think that's more of a resources thing as to use for ransom
<wasabi> is it true that mark eat's babies?
<cjwatson> I can confidently say that I've never once deliberately failed to fix a bug in order to increase support revenue, nor have I ever been asked to
<desrt> wasabi; that i can confirm.
<cjwatson> the same is true of every technical company I've worked at
<Chipzz> btw, I was wondering something
<cjwatson> desrt: that's not true though - Canonical has a growing support department
<Chipzz> whoopie brought up dapper-commercial earlier
<desrt> cjwatson; canonical _is not_ ubuntu
<cjwatson> desrt: *shrug* damn big slice of it
<Chipzz> what is supposed to be best practice for commercial apps if they ship their own libraries we also ship?
<Lathiat> desrt: while that is true
<Lathiat> arguably, its a pretty fuzzy line
<cjwatson> desrt: in practice a large chunk of that support revenue is going to feed straight back into Ubuntu
<desrt> cjwatson; as i said above.  indirectly because canonical works on ubuntu.
<Chipzz> make a .deb with their libs included, or alter to structure to have it ue our files?
<cjwatson> desrt: which you may call indirect, but I think is direct
<Chipzz> s/ue/use/
<desrt> cjwatson; i claim that it's indirect for the time being
<cjwatson> desrt: I respectfully disagree, and we can leave it at that
<desrt> cjwatson; since if there was no support money, even now, mark would just be bankrolling the entire thing still
<desrt> cjwatson; but this is not going to be true going into the future
<bluefoxicy> yep
<bluefoxicy> it's official, and it's pissing me off, wtf.
<dLinkCrawxor> Ubuntu is just like everything else. It's about making profit. 
* bluefoxicy lobs this one towards the LKML.
<Chipzz> for example vmware-player ships its own version of gtk+, should we ship that too, or have it depend on our libgtk2-0?
<dLinkCrawxor> Not saying that's a bad thing
<dLinkCrawxor> Linux is a hippie thing anymore
<dLinkCrawxor> isnt*
* Lathiat laughs
<wasabi> Chipzz: I don't believe there is a policy. There should be. ;)
<Chipzz> (maybe I should ask on -motu?)
<wasabi> Chipzz: I'd like to see third parties ship ubuntu-certified packages.
<dLinkCrawxor> Mark is a Giant Pooh. Jesus told me
<wasabi> Chipzz: Like, one package for dapper, one for edgy, one for feisty, etc.
<wasabi> Or maybe just for LTS releases.
<Chipzz> wasabi: well, obviously depending on our own libs is better; otoh, when our libs upgrade to something incompatible with the commercial package, we'll have to include it again, so that makes stuff more difficult to upgrade these packages
<Lathiat> vmware tries to use the distro libs anyway
<Lathiat> if that fails it restarts with its own
<Lathiat> interestingly, in dapper, it would fail with dappers and fell back to its own
<wasabi> Chipzz: I feel the vendor should track our libs, and we should not change our libs in incompatible ways without very good reasons.
<Lathiat> due to some change in gtk that caused vmware to crash
<Lathiat> (it was a vmware bug, but none the less)
<Chipzz> wasabi: yes, but what if the vendor doesn't ship binaries for ubuntu, just general binaries
<Chipzz> and we happen to package their tarball
<Chipzz> (like vmware)
<wasabi> Got me.
<wasabi> Probably up to whomever does the packaging.
<wasabi> I would sure like to see vmware distribute vmware though. I'm not a fan of this commercial repository stuff.
<Chipzz> vmware is not in dapper-commercial btw
<Chipzz> it's in universe I think
<wasabi> vmware-player is in multiverse or some such right?
<Lathiat> vmware is in multiverse
<Chipzz> yeah
<wasabi> Chipzz: http://wiki.ubuntu.com/ThirdPartyApt   I pine about some stuff there. =)
<wasabi> I would love it if we supported ISVs in supporting us.
<wasabi> So they could push their own updates on their own schedules.
<wasabi> But take advantage of our great package management framework, etc.
<wasabi> Also update-manager and friends.
<cjwatson> Ubiquity/DriverUpdates is progress towards that on one front that's perhaps slightly different from what you've been thinking of
<wasabi> Yeah, it is.
<wasabi> I really speak more about the propriatary world.
<Chipzz> vmware should ship a new version compiled against latest dbus btw
<cjwatson> remains to be seen what the vendor takeup would be
<Chipzz> (and latest libsexy)
<wasabi> I think it's a simple reality that all vendors will not want to put their software in our repository.
<Chipzz> I poked chipx86 about that, but got no response
<wasabi> Nor go through us to update/manage that.
<wasabi> Chipzz: Also, as an example, vmware could depend on gtk>=2.5 <= 2.6 or some such.
<wasabi> Or whatever gtk's no-ABI-change policy is
<Chipzz> wasabi: gtk+ is not a problem, really
<Chipzz> dbus is
<wasabi> So, the upgrade to feisty would pop up and say "I can't do this. You've installed a third party piece of software. They need to update first."
<wasabi> "Go talk to them."
<wasabi> Same diff.
<Chipzz> no not really ;)
<wasabi> How so?
<Chipzz> gtk+ is supposed not to be removing/changes functions throughout the 2.0 series
<Chipzz> dbus did change api
<wasabi> That's fine. The vmware guys know what version is going to be shipped in feisty.
<wasabi> They can procuce updated packages. Smae way MS developers all "get ready for vista" and stuff.
<wasabi> With the end goal being of course that Ubuntu is the only Linux distro that ISVs care to target. ;0
<Chipzz> yeah but they seem reluctant to do so
<wasabi> I don't think we engage them enough.
<Chipzz> the problem with the dbus api is not just the library
<wasabi> I've worked with MS ISVs for ages. There are classes you can go to. Services you can buy, programs you can sign up for.
<wasabi> All with teh aim of having the entire ecosystem ready for Vista.
<Chipzz> the bigger issue with dbus is the bus protocol (which is also an api)
<wasabi> It's a matter of us, after freeze, talking to ISVs and helping them get their software in order.
<Chipzz> so, has that happened for vmware yet? :)
<wasabi> Nope.
<wasabi> It was one of the reasons I went to UDS... just couldn't get many people to care.
<okaratas> hi
<wasabi> I think TD showed up, and the entire time was spent talking about autopackage.
<wasabi> Or, less talking, and more arguing?
<imbrandon> moins fellas
<bluefoxicy> Question
* imbrandon hides
<bluefoxicy> 1)  If I check a bug as a security vulnerability, does it become invisible?
<imbrandon> afaik yes
<bluefoxicy> 2)  Should I check a failure to enforce memory protections (PROT_EXEC) as a vuln?
<wasabi> Chipzz: I have a real strong feeling that stuff like that is why we aren't gaining traction as fast as we'd like among the ISVs.
<wasabi> Our community and their... company... just run on different things.
<bluefoxicy> I have a test case to show the failure
<wasabi> MS really has that figured out well.
<Chipzz> autopackage is the biggest pile of crap to come out of the open source community
<wasabi> Haha.
<wasabi> That's basically the position I took, with less nasty words. ;)
<wasabi> Chipzz: So, honestly, as somebody in Vmware (you are still there right?) what do you think the interest would be from their side?
<Chipzz> wasabi: I'm not ;)
* Chipzz != chipx86 ;)
<wasabi> ahh.
<wasabi> Oh.
<wasabi> mistaken identity!
<Chipzz> I did try nagging him though ;)
<Chipzz> (in a polite way :))
<wasabi> Who are you then? :)
<Chipzz> that happens often ;)
* imbrandon is brandon </sarcasim>
* bhale is brandon too
<Chipzz> just some random guy who has contributed some minor things to gnome and ubuntu
<bluefoxicy> oh screw it
<Chipzz> patches mostly
<wasabi> ahh
<bluefoxicy> I'll just leave it out in the open
<Chipzz> and I have been in the gnome packaging team several years ago
<Chipzz> (RH packaging)
<wasabi> Anyways, so, I sort of think it's something somebody up in the Canonical stratosphere is going to have to do.
<wasabi> Ya know, it's marketing at it's heart.
<Chipzz> unofficial rpms
<bluefoxicy> malone #75157
<Ubugtu> Malone bug 75157 in linux-source-2.6.19 "noexec doesn't apply on 32-bit AMD64" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75157
<keescook> bluefoxicy: you have to enable PAE memory layout for nx to work in the 32bit kernel (on nx-enabled hardware)
<bluefoxicy> keescook:  Isn't that enabled?
<keescook> bluefoxicy: I don't think it is by default on the 32bit kernels because it a performance hit.
<keescook> and this is just what I remember from digging around in the kernel code trying to figure out why nx wasn't working
<bluefoxicy> keescook:  someone needs to turn that on then~
<bluefoxicy> HIGHMEM4G is set
<kylem> no. we don't.
<bluefoxicy> kylem:  and why not?
<kylem> if you run a server-bigiron kernel, it will work.
<bluefoxicy> so security doesn't matter for desktops?
<mjg59> bluefoxicy: Do tell us when you've stopped beating your wife
<bluefoxicy> You are aware that every Ubuntu desktop system now has an executable stack and heap in every process, right?
<bluefoxicy> mjg59:  I don't have a wife
<kylem> so does everyone else.
<mjg59> bluefoxicy: Security matters for desktops. So do other things.
<kylem> things which don't matter for desktops: #1) addressing 36-bits of physical memory.
<bluefoxicy> kylem:  I don't care about 36-bits of physical memory.
<bluefoxicy> I care about not being able to blissfully execute memory that's not supposed to be executed.
<bluefoxicy> bah, I'm going to throw this at devel@
<kylem> itym devel-discuss.
<bluefoxicy> itym??
<bluefoxicy> this is stupid, what was the point of fixing #49192 and #49283
<cjwatson> "I think you mean"
<bluefoxicy> there is no devel-discuss
<cjwatson> bluefoxicy: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-December/000227.html
<bluefoxicy> cjwatson:  well, http://www.ubuntu.com/community/lists doesn't list it so I didn't post there.
<bluefoxicy> (yes I looked when he said that)
<bluefoxicy> it's not on the full list either.
<cjwatson> the canonical list of Ubuntu mailing lists is on http://lists.ubuntu.com/, not there
<bluefoxicy> nope, it's not
<cjwatson> it not being on lists.u.c is a bug, which I'll file in RT now
<bluefoxicy> https://lists.ubuntu.com/mailman/listinfo/ re?
<cjwatson> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
<bluefoxicy> well there you go.
<cjwatson> should be sorted out shortly
<bluefoxicy> heh, it would help if I actually read the list instead of just posting to it; it's the third message down
<bluefoxicy> also I'm no longer allowed to post to it, yay.
<cjwatson> "it"?
<bluefoxicy> the list... ubuntu-devel.. am I the only one that has any context?
<cjwatson> there were two possible referents, the other of which is ubuntu-devel-discuss
<cjwatson> messages to ubuntu-devel are moderated, and will be approved if appropriate. if you don't think you'll ever post any appropriate messages, well, I suppose that speaks for itself
<bluefoxicy> I think I'll be adding a new filter to my mailbox.
<cjwatson> https://bugs.launchpad.net/products/ubuntu-website/+bug/75163
<Ubugtu> Malone bug 75163 in ubuntu-website "/community/lists should mention ubuntu-devel-discuss" [Undecided,Unconfirmed]  
<somerville32> Someone should change the topic in here
<somerville32> "Home of the #ubuntu and #kubuntu operators" -> "Home of the #ubuntu, #xubuntu, and #kubuntu operators"
<somerville32> ...
<somerville32> Wrong channel.
<mdke> somerville32: saw your question in -doc earlier. Documentation is subject to the same SRU procedure.
<somerville32> mdke: So documentation doesn't qualify for an SRU?
<mdke> somerville32: it can do, in the circumstances specified by the StableReleaseUpdates wiki page
<somerville32> mdke: Why not have a more lenient SRU policy for documentation due to the low risk of regression?
<desrt> (low risk and low impact)
<rmjb> what's Adam Conrad's irc handle?
<mdke> somerville32: I don't know, that's the policy
<mdke> rmjb: infinity 
<rmjb> thanks
<mdke> somerville32: maybe there can be more lenience in the application of the policy
<rmjb> infinity: I'm gonna try to tackle merging xbvl
<mdke> somerville32: try and see
<somerville32> fabbione, ping
<somerville32> mdke: k
<raphink> anyone has had network issues with feisty?
<raphink> I keep losing my IP
<raphink> and I can't add routes
<raphink> it says 
<raphink> SIOCADDRT: Network not available
<deltab> raphink: you should ask in #ubuntu, if you haven't already
<raphink> how so deltab?
<raphink> I'll go ask in #ubuntu+1 rather
<raphink> :)
<deltab> it just sounds like a support issue, and the topic says this isn't the channel for that
#ubuntu-devel 2006-12-10
<rmjb> infinity: could not merge xbvl, sorry
<jdong> update-alternatives: unable to make /usr/lib/iceweasel/plugins/libjavaplugin.so.dpkg-tmp a symlink to /etc/alternatives/iceweasel-javaplugin.so: No such file or directory
<jdong> ahem, looks like our java stuff didn't merge out iceweasel?
<_ion> Either wait for the package to be fixed, or mkdir -p /usr/lib/iceweasel/plugins
<_ion> AFAIR there's already a bug report.
<_ion> I don't think the package making a symlink for iceweasel matters much.
<cjwatson> mdke,somerville32: I'm happy to apply the policy relatively leniently to documentation
<somerville32> cjwatson: In Xubuntu 6.10, the Firefox welcome/about page says 6.06. It causes a lot of confusion for users.
<somerville32> Some people repeatedly try to reinstall Ubuntu
<somerville32> *Xubuntu
<mariano> in gnome's bugzilla there are a few crashes with stack traces looking like the one on <http://bugzilla.gnome.org/show_bug.cgi?id=384220>: is edgy's dl having issues with gconv?
<Ubugtu> Gnome bug 384220 in general "crash in Terminal: Crashes when launched fr..." [Critical,Unconfirmed]  
* desrt sees mariano in a new place
<mariano> heh
<cjwatson> somerville32: (now is not a good time to bother trying to persuade me; I've just got home from a party and am about to go to bed)
<somerville32> cjwatson: Alrighty :) Should I send you an e-mail?
<cjwatson> sure
<somerville32> Sweet dreams :] 
<jldugger> quick question about ubuntu-desktop: how is it decided whether a package should be a depenency vs a recommendation?
<jdub> jldugger: whine volume
<jdub> ;-)
<jldugger> doh
* jldugger submits 1 whine on behalf of a KSU LUG'er reguarding totem-mozilla
<jldugger> should probably be recommends instead of depends, assuming install recommends by default etc works
<jdub> why so?
<jldugger> the use case I've heard described is replacing totem-mozilla with mplayer plugins
<crimsun> couldn't work currently, as mplayer and its plugin package are both in multiverse
<Burgundavia> jldugger: tbh, I have found totem in edgy and feisty to play more than the mplayer one
<jldugger> tbh?
<Burgundavia> to be honest
<_ion> I'm using the mediaplayerconnectivity extension for firefox.
<jldugger> actually, ive had the best results recently with vlc
<crimsun> heh, you can't be using edgy's vlc, then.
<jldugger> in the past it really was quite awful, but recently it started displaying more stuff and working faster with MKV
<jldugger> totem is quite awful with mkvs
<jldugger> so what section is debian's mplayer in?
<Burgundavia> jldugger: gstreamer and totem is where upstream is at, so that is where we are going
<jldugger> Burgundavia, well, go where you need to, but I'll go where the frame rates are ;)
<crimsun> (main)
<jldugger> anyways, his main complaint was that he couldn't remove totem-mozilla without removing ubuntu-desktop
<jldugger> i thought there was a spec about recommendsSupport that addressed that concept, but it doesn't look like much of anything is recommended in edgy
<Burgundavia> jldugger: a bunch of stuff is recommended
<jldugger> crimsun, would anything even change if whatever effort nessecary was taken to move mplayer to universe?
<jldugger> compared to the amount with explicit depends, it seems quite small. I was just curious how the current division was established, so if my friends complain about such things in the future, I'd be that much more ready to help them
<jdong> is there any known issue with feisty's ssh client?
<jdong> it seems to hang when I try to connect
<crimsun> jldugger: no
<SEJeff> ajmitch: ping
<crimsun> SEJeff: he's away for 2 more days.
<SEJeff> Oh ok thanks
<jdong> debug1: SSH2_MSG_SERVICE_REQUEST sent
<jdong> debug1: SSH2_MSG_SERVICE_ACCEPT received
<jdong> hmm
<jdong> anyone know what it means is SSH hangs after those two messages?
<SEJeff> Would you happen to know if virt-manager is going to be packaged and uploaded for feisty?
<SEJeff> Or should I work on it?
<crimsun> I don't.
<SEJeff> jdong do you have access to the ssh host via other means?
<jdong> does feisty ssh work for you guys then?
<jdong> SEJeff: yeah
<jdong> SEJeff: though I don't think the host is to blame
<jdong> edgy ssh'es just fine
<jdong> and feisty is failing to ssh to any of my hosts
<jdong> running a whole variety of OS'es
<SEJeff> From the server try: sshd -d -f /etc/sshd/sshd_config -p 10999
<SEJeff> From the host do ssh -v user@foo -p 10999
<jdong> aha, figured it out
<jdong> ssh-agent/seahorse-daemon was causing it
<jdong> though I don't know why it would
<SEJeff> jdong: Kill ssh-agent and just use seahorse-daemon
<SEJeff> weird
<jdong> SEJeff: newer seahorse-daemon have a ssh-agent built in, don't they?
<jdong> I didn't start ssh-agent myself
<SEJeff> jdong: You are right, I thought you meant you had them both open.
<jdong> nope
<jdong> somehow seahorse in feisty is causing this
<bluefoxicy> kylem:  What Pentium-M model were you referring to?
<bluefoxicy> mdz:  Did you mention something about users being able to rebuild their own repos earlier?
<Burgundavia> fabbione: ping
<nkassi> #debian
<nkassi> sorry
<somerville32> Can someone review? https://wiki.ubuntu.com/MainInclusionReportXJump
<_ion> xjump rules.
<_ion> Bug 44883, btw.
<Ubugtu> Malone bug 44883 in xjump "Add ion.xpm.gz to the package" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/44883
<somerville32> hehe :] 
<bluefoxicy> is it every time gconfd gets upgraded, or every time I crash without logging out of GNOME that I lose all my settings?
<bluefoxicy> I plugged in an iPod, it decided to instantly take me to my BIOS post
<bluefoxicy> when I get back to my desktop, xchat-gnme has forgotten my color scheme and welcomes me to xchat-gnome; Nautilus needs its settings readjusted; my theme needs to be set again; rhythmbox thinks it's being run for the first time; and gnome-terminal's settings are factory.
<bluefoxicy> I also recently upgraded gconfd
<fabbione> Burgundavia: pong
<Burgundavia> fabbione: the logging bot is toast
<bluefoxicy> anyway I'm going to sleep, only slightly annoyed.
<fabbione> Burgundavia: very informative as usual.. what is toast?
<somerville32> fabbione, Burgundavia: doh, I was going to ask fabbione to add the logging bot to #xubuntu*
<Burgundavia> fabbione: the logging bot in -meeting appears to not be logging
<Burgundavia> haven't tested other channels
<fabbione> Burgundavia: what date and time?
<Burgundavia> fabbione: hmm, appears to be working again
<Burgundavia> sorry for the false alarm
<fabbione> Burgundavia: the logs are sent async to the servers every hour
<fabbione> -current that is
<fabbione> i can't send them realtime
<Burgundavia> yep
<Burgundavia> just the interval was more than that this time
<fabbione> IIRC the scripts start at around *:20 of each hour and they finish around :40
<fabbione> Burgundavia: that might happen if connection to the DC is interrupted.
<fabbione> Burgundavia: nothing i can do about it
<fabbione> they don't allow me to run the bot at the DC
<Burgundavia> ah, ok
<fabbione> somerville32: if you want logs on channels either mail me or open a bug in LP and make sure it's assigned to me
<Hobbsee> fabbione: toast is a food that you eat :P
<Burgundavia> Hobbsee: sassy aussie :)
<Hobbsee> Burgundavia: as always :)
<_ion> Is it just me, or did ubuntu-devel{,-discuss} collectively die after the split and addition of moderation?
<Burgundavia> weekend as well
<_ion> Hm, good point. :-)
<Fujitsu> _ion: Is it a bad thing that they died? Considering what was on -devel before, it's quite a relief.
<Hobbsee> Fujitsu: ++
* Hobbsee wonders if that's only open to core-dev, or just dev
<somerville32> I tried to send in a MIR review request and my message got modded
<somerville32> :(
<Fujitsu> Hobbsee: That didn't make any sense.
<crimsun> she's agreeing that the S:N is far preferable.
<Hobbsee> hrm, okay
<Hobbsee> exactly
<Burgundavia> Hobbsee: all dev, motu and dev
<Hobbsee> Burgundavia: cool
<Burgundavia> plus selected others
<Burgundavia> now, everybody will still be able to join, just only certain people will be able to post, others will go through moderation
<Hobbsee> yep
<LaserJock> who is doing the moderation?
* somerville32 wants to become a selected other.
<Burgundavia> LaserJock: a select group, unknown composition
<LaserJock> somerville32: you could still post it to ubuntu-devel-discuss I suppose
<Burgundavia> likely I will be roped into it, I seem to moderate the world
<LaserJock> but I guess waiting for mods would be best
<somerville32> I've been a happy subscriber to ubuntu-devel for awhile now
<somerville32> Having my posts modded is evil
<somerville32> :(
<LaserJock> why?
<LaserJock> it's just a little bit longer to wait, it's not anything that has to be done within 24hrs
<Fujitsu> `little bit'?
<LaserJock> yeah
<LaserJock> in the whole scheme of things it's really not that long
<infinity> somerville32: MIR reviews aren't meant to go to -devel, since the list doesn't do the reviews.
<infinity> somerville32: This is precisely why the list is modded now.  People just seem to send stuff to -devel when they can't be bothered to figure out who they really should be bugging.
<somerville32> infinity: The MIR reqs page says that sending to -devel is in the workflow.
<infinity> Seriously?
<infinity> If that was the workflow, we'd be flooded.
<somerville32> I wouldn't have sent it otherwise.
<somerville32> I thought it was weird myself
<LaserJock> somerville32: where did you read that?
<somerville32> I'll go find it
* somerville32 will feel really stupid if I misread it.
<infinity> Oh, "hold any necessary discussion on -devel"
<infinity> That would apply if it's a contentious issue.
<infinity> Note the word "necessary".
<somerville32> https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
<somerville32> "The request and the link to the report are sent to [MAILTO]  ubuntu-devel@lists.ubuntu.com."
<somerville32> Note the lack of the word "necessary" :P
<infinity> I'm on a different page. ;)
<somerville32> :)
<infinity> Alright, you're off the hook.
<infinity> Since that page was last edited by Kamion, I'll let it slide as accepted procedure. :)
<infinity> Though it clearly doesn't actually happen that way much.
<infinity> Then again, it's rare for a non-core-dev to try to get something in main in the first place.
<infinity> (Why are you doing so?)
<somerville32> I'm an Xubuntu developer
<somerville32> And hopefully I will be a core-dev someday ;] 
<LaserJock> yeah, I gotta write up some too
<somerville32> Anyhows, can I have a hug now, infinity? You scarred me :P
<infinity> somerville32: I'm not so good with the hugs, but I can get dholbach to hug you when he shows up. :)
<somerville32> Ok
* somerville32 hugs himself in the meantime.
<Burgundavia> elmo: ping (re: -devel-discuss) moderator password
<desrt> why is linux-server in restricted?
<desrt> it doesn't depend on l-r-m....
<infinity> desrt: Because all of the linux-* packages are in restricted, and I doubt we ever stopped to think that the ones without lrm could/should be in main.  *shrug*
<infinity> desrt: The fact that -server has no lrm makes linux-server more or less useless anyway, since it's the same as linux-image-server
<desrt> infinity; that's a good point
* desrt removes linux-server, explicitly requests linux-image-server and removes restricted from apt sources
<desrt> feels good to live a life without restricted :)
<desrt> i guess i'd feel even nicer if i didn't need nvidia drivers for my desktop :/
<Burgundavia> I wish madwifi would die
<desrt> it often does
<desrt> <ha ha ha>
<Hobbsee> i prefer madwifi over ndiswrapper
<desrt> on the heirarchy of evil i pretty much have to agree with that
<desrt> but i prefer intel even more
<Burgundavia> yep
<Hobbsee> what, hte 3945 chipsets?
<Hobbsee> didnt think they were free either
* desrt finds self feeling very mellow
<desrt> i just had the oddest feeling like myself corey sarah and adam were sitting in a room together drinking wine or something
<Hobbsee> ookay?
<infinity> If this is some sort of double-date, I'm claiming Corey as mine.
<desrt> damn.  i was hoping for corey. :(
<Burgundavia> wait a sec
<Burgundavia> don't I get a choice?
<infinity> No.
<Burgundavia> dammit
<desrt> corey; more wine?
<Burgundavia> heh
<desrt> i'm sure everyone here has seen that commercial for that xbox360 game "gears of war"
<desrt> the one with the lone soldier in the burned-out streets and fighting that huge spider-looking thing at the end
<desrt> with the really really mellow music
<Burgundavia> yep
* desrt is listening to that song repeatedly
<Hobbsee> Burgundavia: you dont, unless you say you want both of them
<desrt> weird mood.
<Burgundavia> watched on the big screen, before I saw the new bond
<Burgundavia> Hobbsee: it is a tough choice
<Hobbsee> Burgundavia: indeed
<Burgundavia> they are just so pretty, with such nice asses
<infinity> desrt's pretty?
<desrt> you know.  i still remember some words you said to me at ubz.
<desrt> which i found very oddly placed at the time
<desrt> http://desrt.mcmaster.ca/random/gary%20jules%20-%20mad%20world.ogg
<Burgundavia> desrt: I said?
<desrt> for some reason you felt the need to let me know that you didn't find me attractive
<desrt> like, you specifically mentioned it
<Burgundavia> hmm, that is odd
<Burgundavia> that isn't something I would say, but I take your word for it
<desrt> i only remember it because it was so oddly placed and rather randomly harsh
<Fujitsu> desrt: Unless you're LP in disguise, I can't imagine Burgundavia being harsh like that :P
<Burgundavia> occasionally, when I get drinking, I say harsh things. I blame it on alcohol
<desrt> the aussies are googling me
<infinity> Was looking for pictures of your (apparently) unattractive mug. :P
<desrt> :)
<Burgundavia> heh
<infinity> I feel a bit bad to discover that you were at UBZ, and I don't remember you AT ALL.
<desrt> you just found one :p
<infinity> Though, after 2 weeks there, I was in a bit of a daze.
<desrt> like the scarf?
<infinity> Scarf?
<Burgundavia> http://desrt.mcmaster.ca/images/scarf.jpeg <-- nice scarf
<infinity> I think you're watching Hobbsee, not me.
<desrt> oh maybe.  whois wildit.net.au?
<Burgundavia> unfortunately, you look like a zombie in that picture
<infinity> Oh, NOW I hit the scarf.
<Burgundavia> ah, yes, Canadian winters
<infinity> (wildit is me)
<desrt> my sister googled me at work the other day and yelled at me for having scary pictures online
<Burgundavia> ouch, the only pictures of me online were taken at conferences
<desrt> since we're all googling each other....
* desrt does corey :)
<Treenaks> Burgundavia: mine too :)
<Treenaks> Burgundavia: hub did them :)
<Burgundavia> all of which make me look like hell, because I don't tend to sleep very much at them
<Treenaks> Burgundavia: http://foodfight.org/zut/martijn-hoofd.jpg
<Hobbsee> infinity: why's anyone watching me?
<Burgundavia> http://67.18.254.190/img/15517/linuxworld2.jpg <-- jorge and myself at LWE SF
<desrt> http://en.wikipedia.org/wiki/User:Burgundavia <- heh!
<Treenaks> Burgundavia: you don't look sleepy, you look stoned :)
<Burgundavia> Treenaks: the puffy eyes, etc.
<Burgundavia> there is a great picture of me from UBZ, in which I have eyes of different sizes with huge bags
<desrt> ubz was a lot of fun
<Treenaks> oh man .. Windows virus scanners are crack
<desrt> despite the fact that i was disgustingly ill for most of it
<Burgundavia> it was
<Burgundavia> I am sad I missed both Paris and MTV
<Fujitsu> Treenaks: You don't say.
<Treenaks> Fujitsu: I'm installing .NET, and it keeps popping up "The registry was altered"... DUH
<desrt> mtv was good.  california is a weird place :)
<Fujitsu> Hahahha.
* Treenaks missed Australia, Paris and MTV
* Treenaks hopes the next one will be nearby :)
<Burgundavia> Treenaks: same as me
<desrt> infinity; you know... i'm sure i've met you...
<Burgundavia> I am hoping europe next
<infinity> desrt: You were in MTV too?  Damn.
<desrt> infinity; but i don't know what you look like :)
<infinity> desrt: I'm the guy who was never wearing his own tag.  Ever.
<infinity> desrt: I was quite often LaMont Jones, though.
<desrt> infinity; that's pretty much everyone
* desrt finds a picture of you and tollef
<infinity> desrt: Well, we all statred doing it because I initially refused to wear mine (and stole LaMont's) out of protest because my tag was hand-written.
<infinity> desrt: It got out of hand by day 2 or 3.
<infinity> Oh dear Lord, there are pictures of me online?
* infinity cries.
<desrt> at one point i was ajmitch -and- murray cumming
<Burgundavia> http://www.netsplit.com/events/2005/ubuntu-down-under/ubuntu-down-under-005_screen.jpg <- spotted
<desrt> http://www.mercateo.com/p/102-198785(2d)BP/ADAM_6521_5PORT_ETHERNET_SWITCH_W_FIBER.html
<desrt> a conrad brand "adam" ethernet switch
<infinity> http://cerberus.0c3.net/~adconrad/my_best_friend.jpg <-- There, that's a passable picture, I guess.
<desrt> which one is you?
<Burgundavia> 'he man of intrigue, Adam Conrad" http://images.google.ca/imgres?imgurl=http://seven.com.au/catalogueFiles/ha2-3/images/feature/haa_thmblrg_108x108_headland_rachael.jpg&imgrefurl=http://seven.com.au/homeandaway/feat_promotional_headlands-promotional-page_051111&h=108&w=108&sz=6&hl=en&start=20&tbnid=Z79XjmKNd7smJM:&tbnh=85&tbnw=85&prev=/images%3Fq%3D%2522adam%2Bconrad%2522%26svnum%3D10%26hl%3Den%26lr%3D%26sa%3DG
<infinity> At least I'm not in "tired, conference mode".
<infinity> desrt: The pretty one.
<desrt> infinity; i have to say the bearsuit really does it for you
<infinity> desrt: I know, I really should have bought it.
<Burgundavia> desrt: have to agree with you there
<Burgundavia> who is the lady?
<desrt> his best friend, i'm guessing
<infinity> Burgundavia: My wife.
<Burgundavia> ah
<Burgundavia> desrt: lack of hands showing rings
* desrt wouldn't have assumed wife either
<desrt> bah
<_ion> I just implemented time travel technology.
<desrt> my plans to visit victoria are spoilt
<infinity> ?
<infinity> Planning to come and pick up?
<Burgundavia> desrt: why so?
<infinity> You're not really her type. :P
<Burgundavia> and which victoria?
<desrt> i was gonna drop in on my uncle on the way to linux.conf.au
<desrt> since it's on the way
<desrt> but he's gonna be out of the country :/
<desrt> Burgundavia; the island one
<desrt> :)
* desrt is deliberately obnoxious
<Burgundavia> desrt: both are "island ones"
<desrt> oh.  really? :)
<desrt> yours, silly :p
<infinity> Burgundavia: "both"?  I assumed he meant "Victoria, Australia", which is, y'know, where I live. :)
<desrt> infinity; victoria, BC which is, y'know, where corey lives
<Treenaks> infinity: who'd want to go THERE? :P
* Fujitsu is pleased at the lack of photos of himself.
<desrt> infinity; it's also on an island
<infinity> Treenaks: It's pleasant enough.
* Hobbsee has no photos
<Hobbsee> well, no findable ones
<Burgundavia> infinity: victoria is on vancouver island, unless aussie living has softened your brain that badly :)
<desrt> Hobbsee; my google skills know no bounds.   just wait.
<infinity> Burgundavia: Yes, I recall. :P
<Hobbsee> desrt: go for it
<infinity> Burgundavia: My Victoria isn't on an island, though. :)
<Burgundavia> http://faces.debian.net/ <-- we need this
<Burgundavia> infinity: true
* _ion misread it as "feces.debian.net"
<_ion> Now *that* would be cool.
<desrt> oh man
<desrt> this is like cracking a one time pad
<desrt> even if you _did_ have photos i'd never know
<Hobbsee> desrt: finding nothing?
<desrt> Hobbsee; finding too many people named sarah hobbs
<Hobbsee> haha
<Burgundavia> Hobbsee: what are you hobbies, aside from Ubuntu?
<desrt> and they're all different!
<Hobbsee> try going by hobbsee
<Hobbsee> yes, i'm not the artist
<desrt> there's even a fine picture of you as a table
<desrt> o.
<Hobbsee> haha!
<desrt> so i guess the table isn't you, then
<Hobbsee> nope
<Fujitsu> There are a lot of William Grants around, which is both a curse and a blessing.
<Hobbsee> i dont tend to use my real name online
<Burgundavia> http://images.google.ca/imgres?imgurl=http://lancemc46.topcities.com/prebble/Images1000p/1267v_Kathleen_Sarah_HOBBS.jpg&imgrefurl=http://lancemc46.topcities.com/prebble/284p.html&h=200&w=200&sz=16&hl=en&start=12&tbnid=LxOLk0qxPMDR8M:&tbnh=104&tbnw=104&prev=/images%3Fq%3D%2522sarah%2Bhobbs%2522%26svnum%3D10%26hl%3Den%26lr%3D%26sa%3DN <-- found you!
<desrt> http://www.blastoff.ru/kart/sorev/2006/screens/hobsee.jpg <- this is all you get
<Burgundavia> you into cross county, Hobbsee?
<Hobbsee> heh.  nope, neither are me
<Hobbsee> Burgundavia: nope
<Burgundavia> got a bcomm?
<Hobbsee> dont even know what that is
<infinity> Bachelor of Commerce.
<Hobbsee> oh yes, of course
* Fujitsu is unhappy with the first search result for Hobbsee.
<Hobbsee> thought it was some technical gadget that i'd never heard of
<Hobbsee> haha, yes
<Burgundavia> I have a runner from CO and newfie bcomm
<Burgundavia> but no Ubuntu user
<Hobbsee> heh
<Hobbsee> there's an old granny into knitting, too
<desrt> someone comes in my front door at 4:15am.
<Fujitsu> At least you've got a reasonable title on the forums.
<Hobbsee> Fujitsu: yep :P
<desrt> hah.  my sister is crunked
<Burgundavia> been to any dev conferences?
<Hobbsee> not yet
<Burgundavia> hmm, that removes that angle
<desrt> going to l.c.a?
<Hobbsee> to the open day
<desrt> i'll be sure to bring my camera
* Hobbsee hides
* Hobbsee does have a myspace....
<infinity> And you admit to this?
<_ion> http://johan.kiviniemi.name/stuff/ruby/acme/timetravel.html
<Hobbsee> infinity: visit it and find out
<Treenaks> Hobbsee: IT HURTS MY EYES
<Hobbsee> Treenaks: hush
<Burgundavia> my eyes!!!
<Treenaks> and his :)
<Hobbsee> http://myspace.com/creamier_oak
<desrt> OMG
<Hobbsee> and infinity's probably
<Burgundavia> are you details bunk or real?
<infinity> Christing bananas.
<infinity> THE PAIN.
<desrt> your myspace is throwing me into epileptic fits
<Hobbsee> Burgundavia: they're not real.  duh
<Burgundavia> I wish I mad 250k...
<Burgundavia> http://profile.myspace.com/index.cfm?fuseaction=user.viewprofile&friendid=80008516 <-- little worried this person has hobbsee as a "friend"
<desrt> omg
<desrt> it's 4:20!
* desrt has to go.  bbiab.
<Hobbsee> Burgundavia: yeah, kinda worrying.
<Hobbsee> irc contact only, fortunatley
<Burgundavia> and now, for something different, I give you a singing cat: http://video.google.com/videoplay?docid=-2193241534532350975
<Treenaks> that's shrieking cat.. not singing
<Burgundavia> Treenaks: splitting hairs, really
* Hobbsee dinners
<desrt> brrrr
<desrt> cold outside
<_ion> They call heavy metal... uh, "singing" singing. They call rap singing. :-)
<Burgundavia> desrt: you live in canada...
* desrt just had his first 4:20 meeting in the AM
* Treenaks reads Planet Gnome and sees abiword coolness
<desrt> Treenaks; the pipe thing?
<Treenaks> desrt: yes
<_ion> Has it switched from the toolbar's "font" widget to a semantic "style" widget (alike LyX et al)?
<desrt> Treenaks; ya.  that's quite neat.
<Treenaks> _ion: no, it's now possible to run it as part of a pipeline#
<_ion> Ok, that's cool, too. :-)
<desrt> Burgundavia; hello goodbye
<Burgundavia> bloody madwifi
<desrt> hah!
<desrt> you brought that one on yourself, quite frankly
<desrt> 03:36 < Burgundavia> I wish madwifi would die
<Burgundavia> yes, i probably did
<desrt> Hobbsee; why only open day?
<jdub> desrt: that's the only day for poster sessions
<desrt> but if you're gonna be in the area anyway then why not attend the entire programme?
<jdub> oh, i thought you were referring to having an ubuntu poster session
<desrt> not as far as i know :)
<jdub> is Hobbsee not coming to lca?
<desrt> only for open day, apparently
<jdub> man
<desrt> which is what my question was
<jdub> wasted opportunity
<jdub> 'sonly in town every 6 years ;)
<desrt> that's why i asked!
<desrt> seems just ... wrong to me
<jdub> (not even that!)
<desrt> do you know of any american gnomers going to lca?
<jdub> you.
<jdub> nutball.
<jdub> ;-0
<jdub> ;-)
<jdub> blizzard
<jdub> mjg59
<jdub> oh
<jdub> american
<desrt> your definition of america seems to be different than mine
<Hobbsee> jdub: a ubuntu poster session?
<Hobbsee> desrt: jdub likely work
<iceman> hello
<desrt> Hobbsee; :(
<desrt> Hobbsee; where is this?
<Hobbsee> desrt: the pictures?
<ajmitch> Hobbsee: don't worry, I probably won't be at any of LCA
<Hobbsee> ajmitch: yes, but you dont live there
<desrt> Hobbsee; the job
<ajmitch> quite true, thankfully
<desrt> i miss australia
<desrt> i hope to see him again soon
<Hobbsee> desrt: i dont understand
<desrt> Hobbsee; where is it that you work?
<Hobbsee> a supermarket?
<desrt> gotcha
<desrt> i guess they don't have time off for tech conferences? 
<Hobbsee> nah
<desrt> what is your job?
* desrt used to be a badass cashier
<Hobbsee> just a checkout chick
<Hobbsee> sometimes ordering the other checkout chicks around :P
<desrt> do y'all have the 4-digit codes on produce that usually start with 4s?
<Hobbsee> usually start with 4's?  no
* desrt has always wondered how universal those were
<Hobbsee> they're around 4 digits though, yeah
<desrt> hm.  not _that_ universal then...
<desrt> i know they're the same in the US
<desrt> but apparently not on other continents
* desrt only remembers a handful of them... it's been a long time
<desrt> anyway.  it's now 6am.  definitely time for bed
<desrt> good night.
<Hobbsee> night!
<ajmitch> night desrt 
<gnomefreak> dapper used gthumb to import pics from camera right?
<ajmitch> yes
<gnomefreak> ty
<gnomefreak> ok thats strange
<gnomefreak> edgy has a newer version of OO.o than feisty
<tsmithe> perhaps cos of sync?
<gnomefreak> maybe not real sure just saw it but i would guess on that
<tsmithe> well... depends on the version in debian i guess
<joachim-n> how do I find a string in rosetta?
<Hobbsee> ask in #rosetta or something?
<joachim-n> only one user in there :(
<joachim-n> trying to fix a but with a translated string
<mdke> joachim-n: #launchpad is the appropriate channel. The answer is that you download the po file, search for the string, and reupload it
<mdke> code for searching will arrive soon
<joachim-n> on the bug report, Seb says to fix the string in rosetta
<joachim-n> https://bugs.launchpad.net/distros/ubuntu/+source/language-pack-gnome-en-base/+bug/72304
<Ubugtu> Malone bug 72304 in language-pack-gnome-en-base ""Deleted items folder" name doesn't make sense" [Undecided,Unconfirmed]  
<mdke> joachim-n: that procedure will fix the string in rosetta
<mdke> alternatively, browse through all the strings until you find it
<joachim-n> I don't even see how to browse through strings
<joachim-n> I've looked for 'language-pack-gnome-en-base' in the rosetta list and I can't see it
<mdke> that's a generic package which supplies all translations for that language. You need to identify the package which contains the relevant string
<mdke> like, gnome-panel or something
<mdke> Then you go here, and select it: https://translations.launchpad.net/distros/ubuntu/edgy/+translations
<joachim-n> you mean pick the language, then find the package in that massive list
<mdke> correct
<joachim-n> which has zippo navigation... :)
<mdke> sorry?
<joachim-n> first/previous to go through 1200/75 pages of stuff
<joachim-n> it's pretty heavy going
<mdke> that's why I recommended the other approach
<joachim-n> ah. I couldn't see where to select a package on the url you said, sorry
<joachim-n> anyway, I've got nautilus now. I assume that's where trash is translated
<mdke> I would have though gnome-panel but I'm not 100% sure
<joachim-n> ah
<joachim-n> how to I get to gnome-panel from that page. https://translations.launchpad.net/distros/ubuntu/edgy/+translations ?
<mdke> click the language then gnome-panel-2.0, I suppose
<joachim-n> that goes to the massive pages of stuff I mentioned :)
<mdke> it's on the first page, afaics
<joachim-n> yup!
<joachim-n> just found it
<mdke> now click "download", get the po file, search through it with gedit, and see if you find the string
<joachim-n> it emails me the file?
<mdke> joachim-n: yeah
<mdke> try nautilus too while you're waiting, maybe they both have that string
<joachim-n> got the PO and trash isn't in
<mdke> what about "deleted items"?
<joachim-n> nope
<mdke> my bad then, not that package.
<joachim-n> nm :)
<joachim-n> found it. it's gnome-applets
<joachim-n> though there's some in Nautilus too
<joachim-n> mdke: what do I do with the po files now I've made the changes?
<hunger> Is there some tool that gives readable printouts of /proc/pid/smaps in ubuntu yet?
<bhale> is this in relation to the benm business?
<hunger> bhale: Dunno. Who is benm?
<bhale> the guy on planet gnome who keeps blogging about smaps
<hunger> bhale: I stumbled over smaps in CPAN...
<hunger> bhale: It is available in my feisty kernel, so I wondered whether there are tools already to make use of that info.
<ulaas> Seveas: my laptop + feisty had problems with my logitech mouse+keyb combo connected to a usb hub. (directly to laptop it is ok.) do you think this is worth reporting?
<Seveas> ulaas, sounds more like a hardware problem to me
<ulaas> Seveas: no. works fine with edgy. + windows. i think it is kernel related.
<Seveas> ulaas, in which version of ubuntu do you see the problem?
<ulaas> feisty
<Seveas> then it's a regression, please report it
<ulaas> Seveas: deal
<ulaas> oh one more question
<Seveas> and in the report please say that it's a regression from edgy
<ulaas> what happened to sound device selector in preferences->sound
<Seveas> no idea
<Seveas> maybe crimsun knows, he's a sound guru
<ulaas> crimsun: hey! sound guru. :)
<Seveas> --- [crimsun]  idle 01:03:33, signon: Wed Dec  6 01:01:37
<Seveas> so ask later :)
<ulaas> Seveas: ok.
<ulaas> Seveas: do i report it as a bug in feisty on launchpad?
<Hobbsee> yes
<Seveas> launchpad doesn't have the facility to report bugs as occuring in a specific version, so just say in your report that feist is buggy where edgy worked
<jhasse> Where to post suggestions for the human theme?
<HiddenWolf> jhasse: #ubuntu-art or their mailing list is a good place to start
<jhasse> HiddenWolf: Thank you
<Answer> is logrotate being moved away from logrotate 3.7.1 - Copyright (C) 1995-2001 Red Hat, Inc. ?
<Answer> when I run logrotate on my server it is fine but the clients die at the exact time the logs rotate... it doesnt make any sense.  I would love to see logrotate version 4 Copyright Ubuntu 2006
<Answer> I can stop the server side program, reboot it, turn it off, and the clients continue fine.  but logrotate (only on sunday mornings) kills the clients...  monday-saturday its fine.  just doesn't make any sense
<Pupeno> Hello.
<Pupeno> What do you think about mainstream packages that already include a debian dir, is that a good or bad thing ?
<Answer> example?
<Pupeno> Answer: is that to me ?
<Answer> Pupeno: example of mainstream package that already includes a debian dir?
<bddebian> Howdy
<Hobbsee> Pupeno: bad idea.
<Hobbsee> see the packaging guide as to why
<Pupeno> Answer: Haskell Streams.
<Answer> maybe I could bribe some folks to rewrite logrotate... how does caffeine sound
<Hobbsee> Answer: it'd need to be beer.  and maybe money, too
<Hobbsee> however, it's a sunday
<Answer> Pupeno: everything I have experienced in Haskell needs to be updated... doesn't surprise me if it includes deb dirs
<Pupeno> Answer: I think it is irrelevant the language of the software to wether including the debian is a good idea or not. This is the repo: http://software.pupeno.com/Streams-0.1/
<Pupeno> Hobbsee: I feel it is a bad idea, but I don't have any good reasons. What packaging guide did you refer to ?
<Answer> yeah well the logrotate on sunday morning crashes stuff so here I am :/  I don't even have a clue where to look.  there were no errors yet unrelated programs on the clients crashed.  it works fine monday-saturday.
<Answer> well technically the logs did rotate appropriately.  I just don't see how logrotate on the server could crash programs on the client
<Hobbsee> Pupeno: https://wiki.ubuntu.com/DeveloperResources
<Hobbsee> under "common mistakes"
<Chipzz> Hobbsee: no "common" on that page
<Hobbsee> argh, it pasted wrong
<Answer> https://wiki.ubuntu.com/MOTU/Packages/CommonPackagingMistakes/ChangingTheOrigTarball
<Hobbsee> http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html
<Answer> Hobbsee:  i've got 17 Heineken Keg cans here... already chilled
<Hobbsee> heh
<HiddenWolf> Answer: too bad that heineken is so sucky. :P
<HiddenWolf> At least, people from the north-european parts are used to better. ;)
<Answer> um I got Wolaver Organic sampler pack if you like that
<HiddenWolf> *chuckle*
<Answer> what do you want spaten
<Answer> some nice belgians
<Answer> someone should rewrite logrotate just out of pride to get the redhat copyright out of ubuntu
<thom> Answer: why would anyone care?
<thom> esp given everything else that redhat contribute to the linux community
<Answer> because when logrotate runs on my server it crashes unrelated software on the clients... I have no explanation or even an idea of how this is possible or where to look
<hunger> Answer: I would very much prefer someone taking the time to make the log rotation stuff more uniform.
<bhale> Answer: you may not be aware, but redhat employs the core upstream developers for gcc, glibc, and some top kernel hackers
<bhale> Answer: want to rewrite their code out of pride?
* Answer is aware and just wants attention for his problem without anyone pointing out this is not support channel
<Answer> hunger: what parts of logrotate could be made more uniform?  you mean the config file more like crontab or what
<thom> Answer: well, since you know you're not going to get support here, why are you asking?
<bhale> this is not a support channel, and it does create an agressive mood when you throw out ideas like Fork RedHat
<bhale> a backtrace of the crash on a bug report would be a start
<hunger> Answer: dmesg->dmesg.0->dmesg.1.gz, dirmngr.log->dirmngr.log.1.gz, apport.log->apport.log.1, etc.
<Answer> because I don't know where to look or how to explain these unrelated things crashing... it makes no sense
<hunger> Answer: Everything keeping a different no. of old logs around, etc.
<Answer> bhale: how would I acquire such a backtrace from the client...
<bhale> they would configure their system to allow coredumps (via ulimit) and you would collect the core dump that the crashing process spits out
* Hobbsee wonders about people who just "want attention" and will ignore the rules to get it
<Answer> hunger: well I don't really have a problem with logrotate itself, it seems to work fine.  but on sundays, the client software crashes at the exact time the server runs logrotate, even though logrotate runs fine with no erros
<Chipzz> Hobbsee: I'm not totally impressed with that page
<hunger> Answer: So your apps probably suck and can not deal with the logfiles getting rotated.
<Chipzz> it recommends extracting and recompressing a .tar.bz2 ?
<Chipzz> looks to me like dpkg should be fixed instead
<Hobbsee> Chipzz: well, what else can you do?
<Chipzz> fix dpkg?
<hunger> Answer: Fix the logrotate config for those apps to restart the apps (see eg. /etc/logrotate/dirmngr
<Chipzz> this is just broken
<Answer> hunger: sure but what i'm saying is that they are unrelated.  the client app is not writing or reading to the logfiles on the server.  you can turn off the server and the clients run fine.  also lograte monday-saturday does not cause this problem
<Chipzz> rpm has supported .tar.bz2 for a very long time
<bhale> we don't use rpm :)
<Chipzz> no
<Chipzz> but is really not such a bad thing to require bzip2 to be installed
<bhale> tar.gz is still the de facto standard
<Chipzz> that de facto standard is wrong and over-age?
<hunger> bhale: It is? I have not created a tar.gz for over 5 years now:-)
<bhale> hunger: it is pretty much the standard in OSS software source code distribution, from my perspective...
<hunger> bhale: dholbach was the first to complain about that a couple of days back;-)
<Chipzz> Hobbsee: fwiw, my opinion is actually that a debian dir shipped by upstream is a *good* thing
<Hobbsee> why?
<Chipzz> provided it is actively kept up-to-date
<Chipzz> because you can build .deb's from cvs without the painstaking process of importing the debian dir?
<bhale> that sounds backwards
<bhale> and hyperbole
<bhale> you would normally "export" the source into a released form via make dist
<Chipzz> no, not at all?
<bhale> and uupdate it like every other package
<Chipzz> bhale: no
<bhale> no "sucking in the debian dir"
<bhale> alright, no.
<Chipzz> what I meant is: users (not ubuntu or debian developers) following cvs
<Chipzz> and having the common sense to use a packaging system to install stuff instead of configure ; make ; make install
<bhale> when I follow CVS i install into /usr/local
<bhale> the average user is not a packager
<bhale> multiple prefixes are rad.
<Chipzz> and that's exactly why an upstream up-to-date debian dir is a good thing?
<Chipzz> tell you something
<Chipzz> I have made unofficial packages for gnome in the past
<Chipzz> (rpms)
<Chipzz> me and the other people involved in that effort actually stored the .spec.in files in cvs when the author agreed
<Chipzz> making it easier for people to test stuff
<Answer> bhale: ulimit is already set to unlimited, but there were no core files...
<bhale> Chipzz: it is my strong opinion that unofficial packages should be built to the same methods and standards as a package in ubuntu
<bhale> packaging files go to bzr on launchpad or svn on alioth
<Chipzz> but really, what could you be missing out on if the debian dir was kept reasonably up-to-date upstream?
<Chipzz> conflicts/replaces maybe
<bhale> yes, conflicts/replaces
<Chipzz> I'ld hardly call that critical
<hunger> bhale: You can not force the ubuntu-way on everybody else! People will build their own debs... and having a debian dir in upstream at least channels things.
<bhale> ok, you make some busted packages, get everyone to install them, and slashdot can slam us over and over because people cant upgrade to the next release
<bhale> you are certainly free to do so, it is OSS
<Chipzz> no, because the number of people actually building packages from cvs is limited
<bhale> I will just disagree with you when you throw hyperbole arond here
<bhale> about the massive ammount of work it is to do it right
<Chipzz> what exactly does hyperbole mean, anyway?
<bhale> "a deliberate exaggeration or overstatement"
<bhale> to make a point
<Chipzz> and people building their own packages will damn well realise it invalidates any official support from ubuntu
<bhale> the people using them do not, in our experience
<bhale> over and over
<Chipzz> so why aren't we getting slashdotted over jhbuild and other buildscripts like that then?
<bhale> jhbuild does nessecarily install over the system files, or hork up the dpkg database
<Chipzz> no, it will do way worse things than that
<Chipzz> cause irreproducible crashes
<Chipzz> and stuff like that
<Chipzz> but
<Chipzz> you only get to call me "throwing hyperboles" if you ignore the premise I started with
<Chipzz> that the debian dir is kept reasonably up-to-date upstream
<Hobbsee> the dist-upgrades were very well publisised
<Chipzz> you know, the crap we got with people installing easyubuntu and stuff like that was exactly because of the ease of installing it
<Hobbsee> Chipzz: of course, a lot of upstream people write crap packaging, as they're coders in c++/python/perl/whatever, and dont run ubuntu or debian.  
<Hobbsee> and so dont know how to
<Hobbsee> which is fine - they're not expected to - that's the job of the packager
<Chipzz> that's why you could try to actually coordinate with upstream?
<Chipzz> upstream also knows first about changes *needed* in the packaging
<Chipzz> because of the way stuff works
<Chipzz> let me give you an example: nemiver
<Chipzz> I build a package from svn before it was first released
<Chipzz> yes I did have some problems on upgrade
<Chipzz> but I knew that was to be expected when I installed it in the first place
<Chipzz> but I was glad I could avoid installing all kind of stuff in /usr/local/ that I had to remove afterwards
<Answer> !! Free beer for logrotate v4 (c) Ubuntu 2006 !!
<thom> Answer: please stop being childish
<Answer> thom: children offer you beer... ?
* mode/#ubuntu-devel [+o thom]  by ChanServ
<bhale> yawn, final warning
<thom> Answer: #ubuntu-offtopic or nothing(preferably) would be a more suitable channel for you currently
<Answer> go ahead bring the kline... not getting any help here anyways :(
<thom> that's because it's not a support channel!
<Answer> i've given up on support and i'm hoping that I can bribe someone to write a new logrotate
<hunger> Answer: Sorry, that is pretty childish... grow up... no need to rewrite code just because of the copyright as long as the license is ok.
<Answer> lol that was just an attempt to incite a response from some redhat people :)
* mode/#ubuntu-devel [+b *!*n=hwilde@*.pitt.east.verizon.net]  by thom
* Answer was kicked off #ubuntu-devel by thom (You were asked politely to stop...)
<logrotater> the problem is that running logrotate on a server crashes multiple clients that are not reading or writing those logs
<thom> ban evasion wins you no favours
<thom> and this still isn't a support channel
<logrotater> inquiring about future development of logrotate not support...
<Chipzz> logrotater: yes you ARE asking for support
* mode/#ubuntu-devel [+b *!*n=rugrat@71.16.69.*]  by thom
* logrotater was kicked off #ubuntu-devel by thom (thom)
<HiddenWolf> damn, people just don't get it, do they?
<_ion> hiddenwolf: He very much "got it", but was trolling intentionally.
<mdke> joachim-n: you upload it
<joachim-n> the Upload link says I don't have access
<mdke> joachim-n: are you a member of the appropriate translation team?
<joachim-n> nope
<mdke> joachim-n: then you'll need to find someone who is to make the change
<joachim-n> well I've uploaded the files to the bug report
<mdke> good idea
<lehaid> why does ubuntu baseline kernel make modules_install put the modules not in the correct /lib/modules ?
<thom> lehaid: please don't ask the same question in two channels
<lehaid> thom: but there aren't the same poeple in both
<darek> hi
<bluefoxicy> you have no idea how lame this is.
<bluefoxicy> I forgot to load kqemu before I booted fedora core's livecd
<bluefoxicy> I didn't notice
<bluefoxicy> as in, it's almost native speed anyway.
<shawarma> bluefoxicy: Why is that lame?
<bluefoxicy> shawarma:  because without virtualization I got the impression that it was emulating (interpretive) at 80-90% native speed :|  That can't be possible
<shawarma> bluefoxicy: You lost me. You said you didn't load kqemu, yet it runs at almost native speed.. and that's lame because it's impossible?
<bluefoxicy> shawarma:  it does not make sense; therefor it is lame.
<bluefoxicy> shawarma:  see http://dilbertblog.typepad.com/the_dilbert_blog/2006/11/the_one_problem.html for an explanation of why this concept works
<bluefoxicy> ok I gotta try this with an Ubuntu LiveCD, brb.
<shawarma> bluefoxicy: I see. I was not familiar with the sense of the word.
<bluefoxicy> shawarma:  shrug.  Anyway, I'm going to try this out with a livecd.
<shawarma> bluefoxicy: s/with the sense/with that sense/g
<shawarma> bluefoxicy: Alright.
<bluefoxicy> shawarma:  it's funny, laugh.
<shawarma> shackan: I am already. On the onside. :-)
<bluefoxicy> https://wiki.ubuntu.com/LiveCDQemuWin32 without working qvm86?
<shawarma> inside, of course.
<shawarma> I just cannot type properly today.
<somerville32> pitti: Are you busy?
<bluefoxicy> Amazing.
<bluefoxicy> Edgy boots without Qvm86 or Kqemu in 5 minutes (GDM), 7 minutes (all the way to the desktop)
<shackan> I'm curious to know how long it takes with acceleration
<bluefoxicy> shackan:  approximately native.  I'm using edgy, I'll kill dapper and start it over.
<bluefoxicy> shackan:  note there's like a 1/5 second delay for menus to pop up and  buttons to get depressed, which feels about native.  o.O  Back in the 0.7 days of Qemu it used to take it like 4 seconds to draw a menu and load all the icons
<bluefoxicy> shackan:  GDM loading (~4 minutes)
<bluefoxicy> desktop is up
<bluefoxicy> shackan:  about half the time, and it feels native.
<bluefoxicy> (Dapper takes 8/10 minutes emulated)
<bluefoxicy> shackan:  I am expecting Feisty's numbers to drop if they actually build all the packages with --hash-style=both (or --hash-style=gnu but having both doesn't hurt)
<bluefoxicy> Probably to half of Edgy's
<TheMuso> C
#ubuntu-devel 2007-12-03
 * Hobbsee waves
 * emgent heya
 * emgent heya
 * Hobbsee waves
<_MMA_> Might be better to poke around later but does anyone have a clue where to look for documentation on JeOS?
<f0rqu3> I am using ati driver 7.11 and I cant change gamma in games
<persia> f0rqu3: Have you reported a bug?
<f0rqu3> no
<persia> f0rqu3: OK.  Is it a regression from the previous behaviour, or do you just need help with the configuration settings?
<ion_> Hardy seems to have 7.1.0
<persia> In that case, maybe we can't do anything :(
<jdong> ion_: hardy has 8.42.3....
<jdong> ion_: 7-11 is actually 8.43.3
<jdong> and home of delicious iced soft drinks!
<jdong> both versions are umm... crap. But anyway, too late tonight for me to gain blood pressure for AMD/ATI incompetence and broken promises
<persia> Hurrah.  We can do something.  Still leaves open the question of whether it's an answer or a bug.
<jdong> persia: most people using 7-11 are reporting it represents no change from the hardy 8.42.3 version
<jdong> so I would not expect that version bump to solve any problems
<jdong> a cursory examination by me shows no difference except a broader PCI ID whitelist, i.e. more supported chipsets
<persia> jdong: Right, but we can accept bugs and answers for 7-11 (8.42.3), whereas we can't for third-party stuff.
<jdong> still serious problems with AIGLX performance, xvideo flickering, memory leaks.
<jdong> persia: I'd expect 7-11 (8.43.3) to be in Hardy soon-ish... but IMO both would be identical releases as far as bug triaging goes, so let's get a head start on ATI bickering ;-)
<RAOF> jdong: Any memory leaks as cool as nvidia's TFP leak?
<jdong> RAOF: meh about 500MB in the course of one day
<jdong> RAOF: not assigned to any app, seems like the leak is somewhere in kerneldom
<persia> Ah.  Nevermind.  I though 42=43 for some reason.  We can't support it.  Alas.
<jdong> persia: meh what could we support in fglrx anyway? Nice soft tissues and hugs? :D
<RAOF> jdong: Ah.  Just some random leak, rather than "anytime you need more texture memory we'll take it from the compiz process & never release it".
<jdong> f0rqu3: I'd recommend using the phoronix.com forums for questions related to ATI's fglrx driver -- seems like most people knowledgeable with it hang out there.
<persia> jdong: I like to think we can provide help, and also fix issues in the packaging, even for binary blobs.
<jdong> RAOF: right, just some random leak that affects some midlevel X-series PCI-X
<jdong> persia: I envy your optimism :)
<f0rqu3> thanks I was at phoronix
<f0rqu3> no answer
<f0rqu3> going back to 8.40
<RAOF> f0rqu3: I don't think that'll work on Hardy, our X server is too new.
<jdong> f0rqu3: I did the same.... 8.42+ was lasrgely a disappointment
<jdong> RAOF: did he ever say he was on hardy?
<jdong> *reads scrollback*
<f0rqu3> jdong, gamma was working?
<RAOF> jdong: Uh, no.  I just kinda assume a default of Hardy unless otherwise specified :)
<jdong> f0rqu3: I don't know. The only game I played was UT2004 and it has gamma settings built into the game's settings
<jdong> those did work
<jdong> RAOF: ah :)
<f0rqu3> xgamma -g 1000
<f0rqu3> nothing happens here
 * jdong not at his fglrx machine currently
 * jdong tries to back away from it as much as possible :D
<pipegeek> any idea why compiz.real would slowly eat up all available memory while gnome-screensaver was running?
<pipegeek> as of recently.  This wasn't happening before last week.  I'm assuming it was an update, but neither gnome-screensaver nor compiz fusion seems to have a new version listed in /var/log/dpkg.log
<persia> How about your GL drivers?
<pipegeek> shouldn't have been, but I'll check.  My card's old enough that nvidia's not supporting it with their new drivers
<pipegeek> Hmm.... it's possible.  the driver version number didn't go up, but the ubuntu package revision number went from 14.9 to 14.10 two weeks ago.  Wonder what they changed, and if it's relevant
<pipegeek> persia: d'ye ken how I might find the original version of the package?  I'm assuming it's not hosted on any of the mirrors anymore
<persia> pipegeek: https://launchpad.net/ubuntu/+source/<packagename> should have some pointers.
<pipegeek> page not found.
<pipegeek> found it
<pipegeek> wait, no, no I haven't
<pipegeek> it's not listed there :-\
<mwansa> hey, when i run alacarte i get "ImportError: no module named glade". i have asked this in #gnome & #ubuntu. have googled around cant find anything. just woudering weather its a known bug ?
<Amaranth> mwansa: you broke something, there should be no way to have alacarte installed and not have python-glade2
<StevenK> pitti!
<Hobbsee> hey pitti!
<pitti> Good morning
<StevenK> pitti: Do you think it's safe to NBS out all of the zero sized things on the list?
<pitti> StevenK: most, probably; some might actually be FTBFS or needs-build
<StevenK> I might dig further and feed you lists, then
<StevenK> pitti: Speaking of lists, bug 149275 :-)
<ubotu> Launchpad bug 149275 in tasks "First cut of source packages for -mobile promotions" [Undecided,New] https://launchpad.net/bugs/149275
<pitti> StevenK: ah, right
<Hobbsee> hey, pitti.
 * Hobbsee waits for pitti to stop idling.
 * pitti hugs Hobbsee
 * Hobbsee hugs pitti back :D
<pitti> Hobbsee: I'm not idling :)
<Hobbsee> pitti: i fixed some bits in your buildd.py
<pitti> oh, great
<pitti> what?
<Hobbsee> pitti: it now lets you give stuff back if it's in depwait (in case you want to shove stuff thru in a certain order), and failed to upload, and doesn't die if the source package is not in ubuntu at all.
<pitti> Hobbsee: ah, did you introduce an option for the depwait change?
<Hobbsee> (the previous error checking only would bail if it was in ubuntu, but not in that particular release)
<Hobbsee> pitti: yes
<pitti> since it's something you don't normlaly want to do
<Hobbsee> to cue something out of depwait, so it gets queued to build RSN?
<Hobbsee> s/cue/shove/
<pitti> right, because it should retry automatically
<Hobbsee> sure, but if you want to step it through sensibly.
 * Hobbsee found it useful, anyway.
<pitti> i. e. I don't want to trigger it without checking previously
<pitti> Hobbsee: right, it is
<pitti> but for the occasional "pitti: please retry foo" it isn't (since I don't want to check it closely)
 * Hobbsee thought people ran status first all the time, anyway
<pitti> Hobbsee: there are some people I trust enough to risk the waste of some buildd time :)
 * pitti hugs geser
<Hobbsee> pitti: FWIW, http://wedontsleep.org/~sarah/buildd.py - feel free to change it as you wish
<pitti> Hobbsee: I'll revert your cookiefile glob change
<Hobbsee> pitti: oh, yeah, sorry :)
<pitti> Hobbsee: ah, you don't have my fix yet for version numbers with a + in it
<Hobbsee> pitti: no, i was wondering about that.
<Hobbsee> where is it?
<Hobbsee> ah, found it, i thnk
<pitti> and I don't see an option for retrying depwaits
<pitti> p.u.c./~pitti/scripts/
<Hobbsee> pitti: status == 'Dependency wait'
<pitti> right, but it's not an option, it's done by default
<Hobbsee> i thought i said that, yes
 * pitti commits and scp's it back to p.u.c.
<pitti> Hobbsee: thanks!
<StevenK> You guys need a bzr branch
<StevenK> :-P
<pitti> I have my ~/bin in bzr, just not publicly on LP :)
<StevenK> Heh
<dholbach> good morning
<ion_> Hi
<Fujitsu> Hi dholbach.
<dholbach> hey Fujitsu, hey ion_
<dholbach> hey seb128
<seb128> Hi dholbach
<pitti> hey dholbach
<pitti> Bonjour seb128
<seb128> Hey pitti
<dholbach> heya pitti
 * ion_ faintly recalls a bit of a Monty Python sketch of people greeting everyone.
<pitti> hey ion_!
<ion_> Howdy pitti
<persia> Hi Bruce
<seb128> pitti: when you tag photos you usually decide what categories to use, why do you think that's not working correctly?
<pitti> seb128: I didn't say that tagging photos doesn't work correctly?
<pitti> I don't know how it works in f-spot etc., since I don't tag my photos
<pitti> but WDYM?
<seb128> pitti: well, you wrote that you don't believe in tagging
<pitti> ah, right, there (but that's just my personal preference, I wasn't saying that it cannot work in general)
<pitti> but tags can usually be defined completely arbitrarily, which means that there is no common standard for them
<seb128> pitti: oki
<pitti> and thus it's hard to actually use them
<seb128> well, usually you tag your photos yourself so you decide of what labels make sense to you
<persia> In the case of personal photos that is a feature.  In the case of shared bugs, perhaps less so.
<pitti> so especially on flickr and bug trackers I do think that this is a problem
<seb128> well, who cares about tags in launchpad
 * persia cares
<seb128> you use some you find useful, they are for you
<pitti> persia: yeah, in your personal photo collection you are probably disciplined enough
<seb128> those are not meant to be universal
<seb128> I tag desktop bugs I want to look at for the next lts for example
<seb128> some tag the build issues
<pitti> seb128: right, but as the guys pointed out they create noise in the tag list, bug mail, etc.
<persia> seb128: But when you tag a bug, it sends a message to all bug subscribers, and some subscribers might not like your tags.
<seb128> well, having everything listed in an UI error
<seb128> persia: that would be a launchpad bug
<pitti> yep; sorting those out in the UI is a great and simple solution IMHO
<persia> seb128: OK.  I'll accept that.
<seb128> that doesn't mean you should stop people using tagging their way
 * persia suspects it's easier to ACL tag lists than to fix the UI and notification issues.
<seb128> pitti: so now if I want to tag gvfs switch issues I need to ask for the tag to be defined somewhere?
<Mithrandir> we could just have usertags.
<pitti> seb128: no
<persia> Mithrandir: Hard to share for teams
<seb128> that creates extra work and will just make me not use tagging
<pitti> seb128: but if you want to have a tag that is 'blessed' and gets into the dropdown list for commonly used tags, you need to ask
<seb128> why do you need a dropdown list?
<Mithrandir> persia: No?  Usertags means you have your own namespace, not that nobody can see your tags.
<pitti> well, or the portlet, or whatever
<pitti> just something to avoid seeing 2000 tags with 1980 of them being useless for me
<persia> Mithrandir: Hmm.  I suppose teams could define team namespaces.  Objection withdrawn.
<seb128> why do you need a list? tags are defined by somebody who has an interest to use some tagging
<Mithrandir> persia: so I could tag all bugs whose bugnumbers are prime with "tfheen:prime" or whatever without it being annoying for anybody else, because they wouldn't see them.
<pitti> seb128: of course it would be cool if everyone would see his own tags, but that's more complicated in LP, I guess
<seb128> pitti: the issue is probably to list all of those, they should list none
<pitti> seb128: but if nobody uses the same set of tags, what's the use of them?
<persia> seb128: I like lists because sometimes I want to share common tags when tagging a bug.
<seb128> or only the one your subscribed to or are usingh
<pitti> except for your own personal bug management, which could be done with more structured ways, too?
<seb128> persia: there is hundred of valid tagging cases
<persia> Mithrandir: As long as the notification issue was resolved, yes.
<persia> seb128: Yes.
<pitti> but if bug triagers should help with putting categories to buts, we need some common standards
<seb128> we already do
<seb128> we already have sru tags
<Mithrandir> persia: if you didn't subscribe to a namespace (or something like that), you wouldn't get notified about usertag changes.
<pitti> if someone uses 'graphics', the next one 'picture-viewer', and yet another one the tag 'gthumb', that won't help anyone
<seb128> there is ftbfs, needs-packaging, etc tags
<persia> Mithrandir: For the right spec, you're correct.
<seb128> well, that's an UI probably
<persia> seb128: Right.  Defined, agreed tags.  The barrier can be low, but we've too many similar tags now.
<pitti> seb128: right; and IMHO there's a difference in use cases and applicability for 'i-wanna-fix-in-my-next-upload' and 'patch'
<seb128> when launchoad started using tags I read somewhere that they were going to display only the most used ones
<seb128> which would filter all this user noise
 * persia thinks that fell into the same bucket as "most recently joined groups"
<Fujitsu> persia: Heh. You mean just the first 5 alphabetically?
<persia> Fujitsu: Yes.
<seb128> pitti: try to control what users are doing is likley going to be a constant battle on launchpad and lot of work too
<persia> There being more important bugs in LP that we'd all agree should be fixed first, and limited development time, little things take a while to happen.
<seb128> pitti: much easier to just display the most commonly used tags which are likely the only clearly defined
<pitti> seb128: I agree, that would help
<seb128> hey mvo
<mvo> hey seb128!
<MacSlow> Greetings everybody!
<\sh> moins
<pgquiles> is there any kernel team member here? I'm trying to build a new flavour of the kernel and I was about to modify debian/binary-custom.d/myflavour/config.i386 when I noticed there is a "automatically generated make config: don't edit" at the beginning of the file. Where should I modify the config for my flavour?
<luisbg_> hello everyone
<pitti> cjwatson_: I'm now happy with the SRU debdiff on bug 147800; do you have some minutes to ack the patch? or shall someone else review this?
<ubotu> Launchpad bug 147800 in cupsys "[Gutsy] : bluetooth printing was working but is not (at the beginning of september)." [Undecided,Confirmed] https://launchpad.net/bugs/147800
<pitti> cjwatson_: (rather, ack the SRU itself; I'm quite confident about the AA changes themselves)
<lool> what's this on ubuntu-devel-announce?
<Hobbsee> someone who didn't follow the reply-to, it appears, and someone else who accepted the mail
<lool> Ah simply a moderation slip
<pitti> ArneGoetje: is the merge of ttf-arphic-uming still on your list?
<ArneGoetje> pitti: I will build a new version anyways
<pitti> ArneGoetje: right, but it should still be merged with Debian for mutual patch exchange
<ArneGoetje> pitti: the new version goes into debian and ubuntu at the same time.
<pitti> ah
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<geser> pitti: Hi, doesn't dh_strip like it when a package uses debian/tmp for install? see http://launchpadlibrarian.net/10688624/buildlog_ubuntu-hardy-amd64.gtk-engines-mono_0.0.5-1build1_FAILEDTOBUILD.txt.gz
<saispo> any xen feisty or gutsy git branches exist or not ?
<pitti> geser: ah, seems, pkg-create-dbgsym doesn't get along with compat 3; I do have test cases for level 1 and 4, but apparently this is another corner case
<pitti> hm, correction, I do have a test case for compat 3
<pitti> geser: can you please file a bug about this?
<geser> against pkg-create-dbgsym?
<pitti> yes, please
<pitti> it might very well be that this is actually a packaging error of gtk-engines-mono
<pitti> but we should get along with those in pkg-create-dbgsym
<geser> pitti: bug #173631
<ubotu> Launchpad bug 173631 in pkg-create-dbgsym "dh_strip if package uses debian/tmp for installation" [Undecided,New] https://launchpad.net/bugs/173631
<saispo> kernel-xen have a git repository for feisty and gutsy ?
<pitti> thanks
<soren> Don't we have any cross compilers? I need a ppc compiler on i386.
<geser> soren: qemu?
<soren> geser: I'm not entirely comfortable build-depending on qemu :)
<norsetto> do archive admins receive emails sent to archive@ubuntu.com ?
<Ng> norsetto: no
<Hobbsee> Ng: reads it, and steals it all instead
<norsetto> Hobbsee: naughty ng ....
<persia> norsetto: You may want ubuntu-archive@l.u.c
<norsetto> Ng: I'm having a problem with an upload, and replied to that address. Was the right thing to do or should I talk with, say, Hobbsee, about it?
<norsetto> persia: thats moderated I think? Seems I'm (quite rigthly) moderated everywhere :-)
<Ng> norsetto: if you've replied to archive@ it'll have been eaten by the black hole of doom I'm afraid
<persia> norsetto: Moderated, but you can join.  Also, moderators can be poked.
<norsetto> Ng: oh well, I'm not going in there ....
<Fujitsu> Ng: That sounds like a very silly address to have it come from, then...
<Hobbsee> haha, the black hole of doom :)
<norsetto> anyhow, what should we do when the tarball in debian and the one in ubuntu differs? keep fakesyncing ad libitum or ?
<Hobbsee> yes
<persia> norsetto: Keep fake-syncing until there is a new Debian upload.
<norsetto> persia: yes, thats the proble, upstream is no more so there won't be any new Debian upload I'm afraid
<persia> norsetto: In one case where upstream is no more, the Debian maintainer has grabbed some patches from the -users ML and made a new (false) upstream release to address that.  Alternately, someone could re-host upstream somewhere.
<Hobbsee> norsetto: an archive admin might consent to removing the packge, so you could merge it with teh debian tarball.  *shrug*
<geser> norsetto: become upstream and release a new upstream version. problem solved :)
<norsetto> Well, I've got my package ready but wanted to make sure it is the right thing to do to keep fakesyncing
 * persia thinks that is an ugly solution
<persia> Err.  I think removing & syncing is ugly.  Becoming upstream is good.
<geser> Hobbsee: would that really work? as LP has to store the old tar.gz for the old releases and the new one with the same filename
<Hobbsee> geser: oh, there's a thought.  er...it might.  the old link to librarian would just get lost
<Hobbsee> unsure
 * persia thinks pool would get annoyed
<cjwatson> removing and syncing can easily break mirroring, so we won't do that
<Hobbsee> cjwatson: in the spirit of making more things open w.r.t. release, where is the blacklist's bzr repo?
<Hobbsee> cjwatson: and why isn't it using LP?
<cjwatson> hysterical raisins - it's just a local bzr repository on drescher, not pushed anywhere
<cjwatson> I saw your comment the other day, but you weren't around to reply :)
<cjwatson> I'll arrange to have it pushed somewhere more sensible
<Hobbsee> cjwatson: yeah, i don't live on irc all the time.  i usually have a logger, though :)
<Keybuk> seems logical for it to be on bazaar.lp/~ubuntu-archive
<cjwatson> the actual files are public, so it wasn't a problem until recently ...
<Keybuk> probably only wasn't because that didn't exist at the time
<cjwatson> Keybuk: yeah
<cjwatson> I think it did, but all of ~ubuntu-archive had drescher accounts :)
<Hobbsee> yeah yeah :)
<Keybuk> turn it into a bind-checkout
<Hobbsee> cjwatson: the plebs don't.  we know.  but i'm not stepping out of archive yet :)
<Keybuk> but then you'd have to make sure "bzr update" gets called somewhen useful
<ogra> does anyone have a clue how to solve stuck loop mounts like: http://paste.ubuntu-nl.org/46671/
<ogra> ?
<cjwatson> the awkwardness with moving it to LP is that we'd have to start editing it locally and updating on drescher, rather than editing and updating on drescher
<cjwatson> since I bet ssh agent forwarding doesn't work to drescher, and certainly won't work once you've done sudo -u lp_archive -i
<Hobbsee> hm
<cjwatson> ogra: does 'losetup -d /dev/loop0' help?
<ogra> cjwatson, nope, because the stack still sits on top ...
<ogra>  /tmp/test1 is the unionfs mount
<ogra> below there is /tmp/.test1-{ro,rw}
<ogra> but there is nothing accessing /tmp/test1 anymore
<cjwatson> can you clean up any parts of that stack?
<ogra> nope
<ogra> the toplevel is stuck
<cjwatson> then you might be screwed :)
<ogra> i can forcefully unmount the unionfs .... with the result that the loopdevice stays stuck
<ogra> i.e. get rid of everything in mtab but that still hogs loop0
<cjwatson> forceful unmounting probably just means that userspace forgets about it but the kernel bit is still there
<ogra> ltsp-image-shell is a script ... it works perfectly if i run it in a shell
<ogra> its purpose is to run in an embedded pathon vte though ...
<cjwatson> the process you showed in that paste looks like a kernel thread
<ogra> as soon as i use it there i cant unmount the unionfs and get this strage effect
<ogra> uuuh ...
<ogra> i want a new keyboard ...(and new fingers ...grmbl)
<cjwatson> perhaps 'sudo lsof | grep /tmp/test' to see if anything's still using that
 * Hobbsee slices off ogra's fingers
<cjwatson> Hobbsee: now for step 2 ...
 * cjwatson passes the sewing kit
 * Hobbsee can sew, but would prefer to use a sewing machine :P
<ogra> ogra@laptop:~/devel/hardy/ltsp-image-shell$ sudo lsof | grep /tmp/test
<ogra> ogra@laptop:~/devel/hardy/ltsp-image-shell$ mount|grep test
<ogra> tmpfs on /tmp/.test1-rw type tmpfs (rw)
<ogra> /opt/ltsp/images/test1.img on /tmp/.test1-ro type squashfs (rw,loop=/dev/loop0)
<ogra> unionfs on /tmp/test1 type unionfs (rw,dirs=/tmp/.test1-rw=rw:/tmp/.test1-ro=ro,delete=whiteout)
<ogra> intresting :)
<cjwatson> lsof | grep test?
<ogra> gains the result from the paste above
<cjwatson> anyway, that's clearly what's keeping the loop device busy
<ogra> OH !!
<ogra> no its different
<ogra> ogra@laptop:~/devel/hardy/ltsp-image-shell$ sudo lsof | grep test
<ogra> nbd-serve  8075     nobody    4r      REG        3,4 151134208     783528 /tmp/images/test1.img (deleted)
<ogra> geez
<cjwatson> aha
<ogra> how does that happen
<ogra> nbd shouldnt even know about it
<cjwatson> didn't bind-mount /proc so it couldn't find the process to kill, maybe?
<cjwatson> as in, is that nbd-serve running in the chroot?
<ogra> no, i usually mount and unmount /proc chrooted ...
<ogra> no, nbd-server is started by inted.conf usually
<ogra> and there is no line at all for /tmp/images/test1.img
<ogra> thats very strange
<ogra> well, its my spare time project from the weekend ... i'll investigate more later ... back to regular work now :)
<pitti> seb128: do you remember the reason why you moved the dbus HTML documentation from usr/share/doc/dbus-1-doc/api/ to usr/share/doc/dbus-1-doc/html/api ?
<pitti> seb128: (just merging dbus and wondering about this delat)
<pitti> delta, even
<pitti> oh, sorry, seems you didn't
<pitti> I was just confused:
<pitti> -doc/api/html usr/share/doc/dbus-1-doc/api/
<pitti> +doc/api/html/* usr/share/doc/dbus-1-doc/html/api
<Riddell> doko: which is better, python-support or python-central?
<cjwatson> Package: python-central
<cjwatson> Maintainer: Matthias Klose <doko@ubuntu.com>
<cjwatson> ;-)
<doko> Riddell: you'll get a biased answer from me ;-P
<Hobbsee> doko: think of it this way...
<Hobbsee> doko: if you say py-central, he's going to ask you how to use it
<Riddell> doko: is there a quick guide to how to use it?
<Hobbsee> doko: if you say py-support, he'll go and bug someone else.
<Hobbsee> doko: pick wisely :)
<Riddell> enrico: have you tried libwibble with gcc 4.3?
<persia> In #ubuntu-motu we're discussing analysis of the packages that haven't been rebuilt against the current toolchain.  What do buildd-admins / archive-admins think about a scripted upload rebuilding these rather than a manual effort?
<Riddell> persia: what would be the need for that?
<cjwatson> persia: what numbers are involved?
<persia> Riddell: I've found at least some packages that FTBFS when they haven't been updated for the most current release.
<cjwatson> and yes, there should be an actual need
<cjwatson> persia: it's reasonable to do a test-build but not actually upload the results
<persia> cjwatson: We're currently looking at about half the archive not yet built for hardy, although we're working to refine the numbers.
<cjwatson> a scripted upload of half the archive is definitely unacceptable
<cjwatson> by all means, test-build and fix the ones that fail
<cjwatson> but there's no need to put that kind of load on mirrors just for a test-build
<persia> We've done half the archive in the last 7 weeks, so if we paced it, I wouldn't expect too much impact on development.
<persia> Further, it's not just test-build: we get the new CDBS stuff, etc.
<cjwatson> for a relatively small number of packages, yes
<pitti> not to mention the stress that would be put on the buildds
<cjwatson> I'm not denying that there are advantages, just saying that dumping in new versions of half the archive in one go is not kosher
<cjwatson> the buildds, as pitti says, are already having serious trouble keeping up
<persia> At.  I don't mean one go.  I was thinking something like 500 a week.
<pitti> persia: please keep in mind that buildds never dropped below 2900 needs-build records ever since we opened hardy
<cjwatson> persia: it just sounds gratuitous to me
<pitti> persia: but what's the point in rebuilding  a working package?
<persia> pitti: Yes, but most of that looks like it's one arch.
<Hobbsee> pitti: yeah, but how much of that refers to arches like hppa, and how much of that is actually hardy?
<pitti> persia: after all, the pool structure was designed to avoid this kind of thing
<Hobbsee> (and how much of it is not superceeded source, that has never even tried to be built?)
<pitti> Hobbsee: I don't know exact numbers
<persia> pitti: To be able to support it.  There were a few packages in feisty that I needed to fight with quite a bit to get to compile for either feisty or gutsy, but I don't touch that many packages.
<Hobbsee> pitti: i386 was at 0 last night.  *shrug*
<Hobbsee> pitti: i'ts the belated arches, iirc
<cjwatson> persia: it is a bug if packages do not test-build successfully; you're entirely welcome to file those and have them milestoned for hardy
<pitti> persia: that still doesn't answer the question why all packages need an upload
<pitti> instead of just fixing the ones that FTBFS
<persia> pitti: I agree about pool: I only think it's worth it because it's LTS.
<pitti> persia: why is it worth it?
<pitti> buildds and mirrors aside, I fail to see the need
<seb128> pitti: dbus, you need to install things to the standard location so devhelp find those
<cjwatson> there are clearly some fixed cases where uploads would be worthwhile
<cjwatson> those can and should be enumerated and handled
<pitti> seb128: oh, isn't that what the usr/share/doc/dbus-1-doc/html usr/share/gtk-doc/html/dbus link is for?
<persia> I think a significant number will fail, and that it's easier to track FTBFS from LP.  Separately, I think we've improved the build-support scripts, and want e.g. ddebs for everything.
<cjwatson> so why not just do the fixed cases where they're known to be worthwhile?
<cjwatson> uploading everything should not be on the table
<persia> cjwatson: Mostly a matter of identification.
<cjwatson> persia: it should be trivial
<cjwatson> I don't accept that you need to upload everything. We have done plenty of this sort of thing in the past without needing that
<seb128> pitti: not sure about the details now, but like the tutorial need to be in the directory and the html in a api subdirectory
<enrico> Riddell: don't recall.  Does it give problems?
<persia> cjwatson: I will at least want to upload everything that could produce a ddeb, for which there isn't a reliable one, which definitely means most arch:any not uploaded since mid-gutsy.
<pitti> seb128: I mean, what did this patch actually change?
<pitti> -doc/api/html usr/share/doc/dbus-1-doc/api/
<pitti> +doc/api/html/* usr/share/doc/dbus-1-doc/html/api
<cjwatson> persia: right, that's a much-reduced set, and that sort of thing only needs to be done around feature freeze
<pitti> ah, api/html -> html/api, I see
<seb128> pitti: install those in html/api rather than api/html
<cjwatson> give us as much time as possible for packages to be uploaded in the normal course of events
<pitti> seb128: right, sorry; I'm blind :)
<persia> cjwatson: I still think it's thousands, and wanted to start earlier to reduce churn around feature freeze, but in principal I agree with you.
<nemo_home> Is there any plan to get GIMP off of release candidate 3 in Gutsy?  I'm kind of sick of random crashes.  2.4.1 is a stability improvement
<persia> s/principal/principle/
<cjwatson> persia: churn will be reduced naturally by packages getting normal uploads
<seb128> pitti: no worry, that's just not obvious, I tweaked until having something correctly listed in devhelp in fact
<Riddell> enrico: we currently have this patch http://kubuntu.org/~jriddell/tmp/wibble.diff
<nemo_home> Just want to know, before I go screwing around with 3rd party repos as a fix on the various ubuntu machines I support.
<Riddell> enrico: but it's possible it's not needed any more, I think gcc 4.3 changed since it was made
<seb128> nemo_home: if you have crashes open a bug with a clear description on how to trigger it and we might backport the corresponding change
<persia> cjwatson: OK.  We'll refine the numbers, and push things that have a clear value around FF.
<nemo_home> seb128: oh. that's just silly. there are plenty of documented upstream bugfixes
<nemo_home> seb128: the crashes have been various, and will be rough to track down
<seb128> nemo_home: we don't upload new versions to stable, there is reason for that, you can argue that the new version is a bug fix only one but sometimes they have regressions
<persia> nemo_home: Many of them are in the released package.
<nemo_home> seb128: there's a reason it was a release candidate
<seb128> nemo_home: and a said there is a reason stable is stable
<gicmo> seb128: ALTER
<nemo_home> persia: meh. reason I'm here is I just ran into a script-fu one that blew up my gimp a few moments ago
<seb128> gicmo: Alter!
<gicmo> how is it going?
<nemo_home> seb128: well, you put an unstable product in a stable release, then didn't update it with the bugfixes :-p
<persia> nemo_home: Great.  File a bug.
<nemo_home> seb128: hell. Firefox gets updated regularlyt
<seb128> nemo_home: there is not so many change between rc and 2.4 so maybe your bug is still there
<nemo_home> rc and *2.4.1*
<pitti> seb128: got it now; I'll prepare a patch for Debian and upstream and forward it (sjoerd expressed interest in it)
<nemo_home> not *2.4*
<seb128> nemo_home: firefox is a special case, it's because it's almost impossible to backport cleanly the fixes there
<seb128> pitti: ok, thanks
<seb128> nemo_home: 2.4.n same story
<seb128> nemo_home: we put in a stable whatever was available and a candidate is not exactly an unstable version
<nemo_home> seb128: seems to be making more work for you and the users, just to patch in stuff already solved in an upstream version that is clearly identified as being for fixes, not features
<nemo_home> but whatever
<seb128> nemo_home: the changelog between rc3 and 2.4 is not that many changes
<seb128> nemo_home: well, been there, got screwed by regression in bug fix versions
<seb128> nemo_home: we just don't backport to new version for the sake of changing the version, if there is a fix required we will backport it and test against regressions
<seb128> pitti: there might be a fix upstream already, the change has been copied on the fedora package
<pitti> seb128: ah, we wondered why it isn't in 1.1.2 yet
<seb128> pitti: well, fedora has it for like 1 year so maybe they just didn't bring it upstream for whatever reason
<Hobbsee> rob: since when do you let servers get stoned?
<pitti> seb128: nope, not in git head either; I'll send it there then
<seb128> pitti: ok, thanks
<Riddell> doko: if I'm merging a package with one of your gcc 4.3 changes, should I submit the patch to the debian BTS if it isn't in there?
<seb128> Riddell: looks like a good idea to send build fixes there
<nemo_home> seb128: http://developer.gimp.org/NEWS
<nemo_home> seb128: and they are planning a bugfix 2.4.2
<seb128> nemo_home: I know the NEWS files, I had this discussing already several times
<nemo_home> seb128: the one I ran into was in script-fu
<doko> Riddell: please do; however I did file for every package a bug report ...
<seb128> nemo_home: that's true for lot of project, you could argue we should get GNOME 2.21 to gutsy because it fixes bugs you are having
<nemo_home> seb128: well, typically there is a difference between major/minor release numbers and devs honour it
<nemo_home> it is why, presumably, you won't bring FF3 into Gutsy
<seb128> nemo_home: and stable bug fixes versions already had ugly bugs which have been embarassing
<seb128> nemo_home: we have already been screwed by stable bug fix updates, we learnt
<nemo_home> seb128: but you know, not a big deal.  Answer for me is, I should test GIMP off one of the non-gutsy repos, if that fixes the issues I and other users are running into, I'll make that standard
<nemo_home> no worries.
<nemo_home> seb128: thanks for your time
<seb128> nemo_home: we don't push new versions to stable, there is reasons to that, no point to argue there
<nemo_home> not arguing anymore. conceded point :)
<nemo_home> not going to waste a dev's time. if that's the way it, that's the way it is.
<nemo_home> I'll work around it.
<seb128> nemo_home: using non standard repositories your might break your next updates and drop official ubuntu support for issues you have there
<nemo_home> I know, unfortunate, but what can you do.
<nemo_home> later
<seb128> nemo_home: the right way to do is to report your issues
<nemo_home> these have already been reported upstream, kind of pointless.
<seb128> nemo_home: so we can backport corresponding fixes and you can use the official version
<seb128> nemo_home: report it to launchpad saying it's fixed upstream and needs to be backported to stable
<seb128> nemo_home: or request an official gutsy-backport for the hardy version
<nemo_home> basically, requiring users who encounter bugs with software to report in multiple places. seems having a simple bugzilla query tagging fixed crashers in upstream stable branch might not be a bad idea
<nemo_home> but, yeah. understand the process you want done
<nemo_home> anyway. need to get to work
<nemo_home> later
<persia> cjwatson: Just for reference, what volume do you think would be acceptable?
<enrico> Riddell: looks like the uisual missing header
<enrico> Riddell: worth applying
<Riddell> enrico: certainly doesn't do any harm
<cjwatson> persia: I'm not sure I'm prepared to give a number that will no doubt be quoted :)
<cjwatson> I think it ought to be comparable to normal upload volume
<persia> cjwatson: I understand.  I think we're probably looking at around three thousand, but will keep trying to refine it tighter.  I'm just concerned about waiting to FF for that many. as that won't be "normal upload volume".  Maybe we'll start pushing some of them after DIF?
<seb128> persia: why do you need to rebuild those?
<persia> Also, I'm curious about scripted vs. manual.
<persia> seb128: Still working on specific cases, but CDBS improvements, ddeb generation, SSP, docbook updates, and possibly others.
<seb128> persia: there is no cdbs improvement worth rebuilding afaik
<jdstrand> slangasek: cool by me.  thanks!
<persia> seb128: Since when?  Since warty?
<seb128> persia: right
<persia> OK.  That was the small number anyway.
<seb128> things like calling dh_icons should have been fixed already
<persia> seb128: Well, it's not, for various reasons, but that is also true for packages that don't use CDBS, so I'm less concerned: that falls under normal bugfix maintenance in my book.
<cjwatson> there are 9 packages using cdbs that have not changed since warty
<persia> cjwatson: Right.  Like I said, it was the small number anyway :)
<seb128> I'm fine with rebuild 9 packages ;-)
<seb128> rebuilding
<cjwatson> (csound-doc gkrellm-i8k ldapdiff libmidi-perl mathwar serveez vrflash xmmplayer xzip)
<persia> OK.  Specifics aside (I need to get the reasons, and the counts, and present them), is it better to start early if the volume is high?  Also, should it be a scripted rebuild, or coordination of volunteers for manual rebuilds?
<seb128> better to start early if you touch packages will are not likely to be uploaded during the cycle
<persia> It would also be nice to get a guideline on volume, but I don't want one for the reasons cjwatson mentions above.
<cjwatson> 12 more than that since hoary, 30 more than that since breezy, 77 more than that since dapper, 154 more than that since edgy, 334 more than that since feisty, 969 more than that since gutsy
<cjwatson> persia: it should only be scripted if FTBFS are dealt with at the same time
<cjwatson> there's no point in throwing something at the buildds that you can already know is going to fail
<persia> gutsy/feisty had dh_icons / dh_iconcache, so it's only 572 CDBS packages.
<cjwatson> persia: why 572? the count not rebuilt since edgy is 282
<persia> cjwatson: OK.  That makes sense.  build-test, and push fixes for FTBFS.  Once that's sorted, rerun the counts, and look at the other reasons, present numbers, and possibly script.  Thanks
<cjwatson> and I'm sure a number of CDBS packages don't care about icons
<persia> Because I can't count (oops)
<seb128> persia: I'm not sure we will win a lot of rebuilds, fixing ftbfes would be nice though
<persia> seb128: I think ddebs are a win, but the rest deserve investigation, and I agree FTBFS is a priority.
<seb128> ddebs are nice, but it's likely that the packages not touched in months are not used a lot or maintained actively and don't get that many crash bugs
<persia> seb128: Maybe.  I tend to go hunt universe crash bugs when I'm bored, and point new contributors at them if they've a bit of coding knowledge, and am often frustrated by the lack of symbols.
 * Hobbsee thinks persia should be bored more often, then
<seb128> persia: ok, I used to look at the apport crash bugs and my impression was that most of the crashes where on packages which have ddebs, that's just an impression though
<seb128> persia: anyway having ddebs for everything would be cool, I just don't think it's a priority
<saispo> plop seb128 :)
<seb128> hi saispo
<persia> seb128: I suspect that's because you're closely maintaining a bunch of packages that get uploaded frequently.  I agree it's not a priority, but would find it nice.  I was hoping for a mass-upload of everything to make it easy to force them and find the FTBFS issues, but I understand the counter-arguments, so will resort to manual hunting.
<seb128> persia: when I wrote that I used to look at the apport crash bugs, that means all the bugs sent, not the one on packages I maintain, which I'm still doing
<seb128> persia: I did some round of "closing bugs with broken .crash" before feisty
<persia> seb128: Ah.  You're more ambitious than I thought :)
<seb128> and retracing, tagging (when we had to manually tag those)
<mvo> RAOF_: hello! do you mind if I upload a new xserverx-gl that blacklists radeonhd?
<soren> If a package has replaced files from another package and is then removed, what will happen? Will the files be missing or will they somehow magically be reinstated from the "original" package?
<seb128> soren: no, it'll just not be there
<soren> Ew.
<soren> seb128: Ok, thanks.
<seb128> soren: that's why some people use Conflicts,Replaces
<soren> Sure. That's just not applicable here.
<ScottK> soren: I think you can manage this with update-alternatives.
<soren> I'll probably go with dpkg-divert or something.
<seb128> no alternatives when not required
 * soren looks forward to the days of declarative diversions.. 
<persia> dpkg-divert?
<soren> persia: Yes?
<persia> I just thought that dpkg-divert was "declarative diversions", but will go read documentation :)
<cjwatson> dpkg-divert is imperative, not declarative
<soren> persia: It allows you to move files out of the way in a way that dpkg understands so that you can replace certain files and have them properply reinstated, when you remove the diverting package.
<persia> Ah.
<soren> Right. The thing is that almost every package using dpkg-divert copies the magic bits from other packages' maintainer scripts.
<soren> But since almost every use case is the same, it'd be a lot easier if you just had a DEBIAN/diversions or something, which dpkg would handle for you directly instead of you having to deal with dpkg-divert.
<persia> Or even a Diverts: header that would auto-calculate DEBIAN/diversions based on the current filesystem and listed package names to divert.  I see the difference.  Thanks.
<pitti> soren: as a mitigation, a dh_diversions would probably help a lot already
<soren> pitti: Good point.
<cjwatson> Debian bug 41642
<ubotu> Debian bug 41642 in debhelper "debhelper: dh_diversions script?" [Wishlist,Open] http://bugs.debian.org/41642
<soren> Wow. 5 digit bug numbers.
<cjwatson> (some recent patches in there from Matt Proud)
<cjwatson> any long-time Debian maintainer has plenty of hard 5-digit bugs around
<cjwatson> I have 8 myself, discounting wontfix/forwarded
<StevenK> I think I managed to get rid of all of my 5 digit bugs
<dholbach> 4 one-digit LP bugs are still open :-)
<soren> dholbach: *g*
<StevenK> bug 1, and which others?
<ubotu> Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,Confirmed] https://launchpad.net/bugs/1
<StevenK> shut up ubotu
<dholbach> bug 3, bug 7, bug 8
<ubotu> Launchpad bug 3 in rosetta "Custom information for each translation team" [Wishlist,Confirmed] https://launchpad.net/bugs/3
<ubotu> Launchpad bug 7 in rosetta "Need help for novice translators" [Medium,Confirmed] https://launchpad.net/bugs/7
<ubotu> Launchpad bug 8 in rosetta "Translator forums/means of communication" [Wishlist,Confirmed] https://launchpad.net/bugs/8
<StevenK> Ah
 * Hobbsee wonders why the 7.10 example content mentions 7.04 cds
<seb128> Hobbsee: because nobody updated those?
<Hobbsee> surprised it didn't get checked, i guess
<tjaalton> evand: re syslinux merge. please go ahead :)
<seb128> Hobbsee: I think some people mentionned it before gutsy, not sure now
<seb128> Hobbsee: still the same "too much to do and limited ressources" issue
<Hobbsee> seb128: well understood that problem, yes.
<evand> tjaalton: will do, thanks
<lool> pitti, seb128: devhelp generation in dbus merged in SVN, thanks
<pitti> lool: thanks, you beat sjoerd to it then, it seems :)
<seb128> lool: are you upstream?
<seb128> oh, speaking about debian
<seb128> cool ;-)
 * sjoerd is not hard to beat these days :p
<lamont> mvo: network issues at the house this week (resolution ETA saturday), I may just hold off on the ia64 dist-upgrade until that's done.
<lamont> or I may find a machine at the office to abuse, and add some creative iptables rules. :-)
<lamont> is the list of URLs that must work documented anywhere?
<mvo> lamont: heh :) ok
<ogra> mvo, did you already take a look at the classmate wrt g-a-i speed ?
<mvo> ogra: no :( sorry
<mvo> Amaranth: I just checked xset q, its a missing b-d on x11-server-utils
 * emgent hi
<tjaalton> pitti: sorry for being a bit vague about the i810/intel situation :/
<pitti> tjaalton: no problem, it's restored
<tjaalton> pitti: yep, thanks
<Keybuk> pitti: the sky falls every time I press Play
<Keybuk> apparently playing "The Chicken Song" will cause my laptop to overheat, the sky to fall and the world to end
<pitti> Keybuk: --debug --verbose?
<pitti> Keybuk: does it freeze your laptop/spin 100% CPU? which process?
<pitti> Keybuk: you are playing back in rhythmbox?
<Keybuk> pitti: it seems that rhythmbox when you play a media file uses D-BUS to tell GNOME Power Manager not to suspend the laptop if I should close my lid
<Keybuk> GNOME Power Manager throws up a very very bad sounding bubble to warn me that the end is nigh
<pitti> chuckle
<Keybuk> also, how do I get sound in flash-in-firefox ?
<pitti> Keybuk: hm, it just works for me (adobe plugin)
<Keybuk> doesn't for me today
<stgraber> Any known issue with Compiz+Firefox on Hardy ? Scrolling is extremely slow (smooth scrolling is disabled) ?
<mjg59> Try disabling EXA?
<stgraber> mjg59: any magic xorg.conf option for that ?
<mjg59> Option "AccelMethod" "XXA"
<stgraber> trying
<nxvl_work> jono: around?
<jdong> mjg59: you mean XAA?
<mjg59> Yes
<jdong> mjg59: and curiousity-wise, is it generally true that disabling EXA improves Compiz/Firefox scrolling performance?
<mjg59> It depends on your driver
<jdong> which drivers do?
<jdong> The new fglrx'es have horrible compiz+Firefox performance
<mjg59> I've no idea if fglrx even implements EXA
<jdong> :)
<stgraber> mjg59: worked
<jono> nxvl_work: hey
<stgraber> mjg59: thanks
<nxvl_work> jono: hi, i'm part of the Peruvian LoCo and we are planning getting official, since we are working for some time now, can you help me on that?
<jono> nxvl_work: read the docs about how to become an approved team
<slangasek> jdstrand: I am currently filled with love for libtool, which seems to require rewriting half its guts to be able to support this use case
<jono> https://wiki.ubuntu.com/LoCoGettingApproved
<jono> :)
<nxvl_work> jono: yes, i'm on that, but what i don't understand is about the membership
<jono> membership?
<nxvl_work> jono: members are the ones who work helping on the events and projects, didn't they?
<jono> nxvl_work: members of the loco, yes
<jono> whats the problem?
<jdstrand> slangasek: :(
<jdstrand> slangasek: incidentally, these are the tests that fail: test030-relay test035-meta test036-meta-concurrency
<cjwatson> slangasek: sigh, you just reminded me I have a postponed mail to bug-libtool from Friday about the horrendous way it gets shell feature checks wrong
<nxvl_work> jono: now i'm clear, that point i was a little unsure, because i have a lot of members on the mailing list, but not all them help on the projects, so what i don't know is if i include them as members or not
<jono> nxvl_work: right, the word 'members' usually refers to people on the mailing list :)
<nxvl_work> jono: so i need to include them?
<jono> nxvl_work: what do you mean by include them?
<nxvl_work> jono: there is a point on https://wiki.ubuntu.com/LoCoGettingApproved in which i need to put the number of members we have
<jono> nxvl_work: right - thats the number of mailing list members too :)
<nxvl_work> jono: ok, thnx :D
<jono> :)
<slangasek> jdstrand: sure, that list looks consistent to me.  Solving this requires having a way to declare that back_meta depends on back_ldap, and libtool isn't happy doing this when the module name being linked against doesn't have a name starting with "lib"
<cjwatson> http://algebraicthunk.net/~dburrows/blog/entry/installing-packages-in-safe-upgrade/ <- yay for Daniel Burrows
<ogra> mvo, is there a secret way to use --root= with gdebi-gtk ?
<ogra> (at least there is no obvious one)
<pitti> BenC: do you think that the  2.6.17.1-50.50 edgy-proposed kernel is still useful for anything? If not, I'd like to remove it to clean up the SRUs
<mvo> ogra: I could make you one if you need one
<ogra> mvo, would be helpful
<BenC> pitti: nope, feel free to remove it
<mvo> ogra: but I need to run for the shop before it closes, please tell me afterwards, should be straightforward
<ogra> i was surprised gdebi and gdbi-gtk are so different
<ogra> mvo, fine with me
<ogra> doesnt need to happen *now* :)
<pitti> mvo: any chance you could look at bug 163794? it's in -proposed for 14 days
<ubotu> Launchpad bug 163794 in tzdata "New timezone data 2007i" [Undecided,Fix committed] https://launchpad.net/bugs/163794
<calc> can someone process libfonts-java and libxml-java, they are in NEW
<seb128> calc: accepted
<calc> seb128: thanks :)
<seb128> you're welcome
<Riddell> mvo: is I branch a debian package that's maintained in bzr what do I set XS-VCS-Bzr: to?
<Kmos> Riddell: XS- for VCS is deprecated..
<Riddell> good thing I'm branching the packaging then :)
<slangasek> Riddell: the logical value to use would be the bzr branch corresponding to what gets uploaded to Ubuntu
<mvo> Riddell: what slangasek said, your branch. what package is it? you may want to put it into ~ubuntu-core-dev or something similar
<Riddell> mvo: amarok, I'm putting it into ~kubuntu-members
<mvo> Riddell: yeah, something like this sounds appropriate
<mvo> Riddell: nice to see that its maintained in bzr in debian
<slangasek> dato's rather pro-bzr
<Riddell> mvo: yes, makes using revision control with packaging seem attractive
<mvo> :)
 * jdong pats mjg59's back regarding the MPAA takedown :)
<ion_> jdong: ?
<alex_joni> hello.. if I build a new LiveCD and want to add a custom GPG key to apt, what would be the steps?
 * jdong pats mjg59's back regarding the MPAA takedown :)
<jdong> aah
<jdong> stoopid ssh lag
<jdong> ion_: planet.
<calc> seb128: can you process liblayout as well? :)
<frafu> Hello, If I remember correctly, some time ago I downloaded the changes of which revision of a project in launchpad as a diff file; unfortunately I cannot find anymore how to do it. Has that possibility been removed?
<seb128> calc: accepted too now
<calc> seb128: thanks :)
<cjwatson> frafu: are you thinking of codebrowse.launchpad.net?
<cjwatson> frafu: if you go to code.launchpad.net for a project, you should find a "browse code" link on the left
<cjwatson> at least once you get to the page for a branch
<cjwatson> and, even without going to "browse code", the revision numbers are links to diffs
<nixternal> mjg59: good work!
<cjwatson> for example, try https://code.launchpad.net/~ubuntu-installer/ubiquity/trunk - "2372" links to http://codebrowse.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/2372
<frafu> cjwatson: yes, but if I remember correctly, I could download it as a patch file
<frafu> but I cannot find anymore how to do it
<frafu> :-(
<cjwatson> frafu: not sure - #launchpad would be a better place to ask
<frafu> If I remember correctly, I did it a month ago
<frafu> cjwatson: Thanks; I am going to launchpad...
<cjwatson> there could easily be a way to do it I'm unaware of
<frafu> cjwatson: maybe it was only a test, as I am using launchpad beta (ppa)
<cjwatson> as am I
<cjwatson> doko_: I stole your libwps merge, noticing that it was a sync
<cjwatson> hope that's ok
<doko_> cjwatson: many thanks!
<cjwatson> lamont: ditto for m4
<cjwatson> lamont: what's the state of hppa java nowadays?
<cjwatson> lamont: we seem to be carrying a fair few patches to disable it
<slangasek> last I pinged him about that, he said it was a bootstrapping matter
<slangasek> it's bootstrapped in Debian, so I think it's just waiting for someone to do it in Ubuntu
<cjwatson> doko_: ditto portmap
<cjwatson> doko_: and genromfs. Done for tonight now :-)
<doko_> cjwatson: do we want libssh2 in main (curl wants to introduce it)?
<cjwatson> I don't mind, I don't think it's really duplicating anything
<cjwatson> openssh is unlikely to ever provide or use a shared library
<cjwatson> and it seems useful for there to be one
<doko_> ok
<doko_> cjwatson, lamont: still getting bus errors, so it may be disabled for debian as well. I think jbailey did want to look at the problems
<TheMuso> If I've found a problem with the seeds, where is the best place to file a bug? Its not a big change, just a slight package name adjustment.
#ubuntu-devel 2007-12-04
<etank> bug 2311
<ubotu> Launchpad bug 2311 in gst-ffmpeg "divx videos not working" [Medium,Invalid] https://launchpad.net/bugs/2311
<pygi> hello
<rledge21> I'm wanting to learn how to write a desktop applet, anyone point me to a tutorial or anything to get me started?
<lamont> anyone around with the right access to tell me if queue-builder is running, and if so ETA to finished?
 * lamont wonders if anyone knows how to take apart and iPod nano...
<StevenK> I can make it be in pieces ...
<StevenK> Probably not what you're after. :-P
<lamont> no, she kinda wants it back together at the end.
<lamont> or at least running on power.
 * ScottK is REALLY good at taking stuff apart. ;-)
<StevenK> lamont: I didn't think you could?
<lamont> StevenK: done. :-0)
<StevenK> Heh
<StevenK> lamont: So you should document the process and then get Apple lawyers to hate you
<lamont> google is love
<StevenK> Ah
<dholbach> good morning
<ion_> Hi
<dholbach> hey ion_
<TheMuso> 5~5~/c
<TheMuso> argh
<cjwatson> TheMuso: there isn't really a great choice for where to file the bug, but ubuntu-meta (assuming it's the Ubuntu seeds) will probably do
<cjwatson> TheMuso: BTW, you have a stray identity; you might want to visit https://launchpad.net/people/+requestmerge?field.dupeaccount=luke-themuso
<TheMuso> hmm ok thanks
<TheMuso> cjwatson: And, crimsun took care of the seed change.
<cjwatson> ok
<StevenK> elkbuntu: Back home?
<elkbuntu> StevenK, yep, got back on sunday night
<StevenK> elkbuntu: Sorry I missed you. :-(
<elkbuntu> yeah :(
<posingaspopular> hey elkbuntu
<elkbuntu> hobbsee's car went pop, so i didnt even get to catch up with her :(
<pitti> Good morning
<StevenK> Morning pitt
<StevenK> Err
<StevenK> pitti :-)
 * Fujitsu drops StevenK into a pit.
<sivang> hi all
<pitti> hey StevenK
<pitti> sivang! Long time no see
<sivang> yeah :)
<sivang> how are you my dear friend?
<pitti> pretty well, and you?
<pitti> married, happy, and busy :)
<StevenK> Fujitsu: In terms of WoW, I'm in one ... crawling with level 48-50 insects. *shiver*
<sivang> pitti: I'm trying to find toolchain-source (actually to install it) but it has no installation candidate, I also checked and it appears it does not appear in the lenny/sid repositories, do you have any idea ?
<pitti> sivang: what should that be? it was removed in feisty
<sivang> pitti: ah I see
<sivang> pitti: this is a package that holds sources for binutils and gcc needed for cross compilation of stuff
<pitti> sivang: I'm not sure, but maybe the normal gcc-4.2 source package supports this now?
<sivang> where can I find the log for toolchain-source's deprecation or removal ?
<sivang> is there a channel for ubuntu embedded now? I mgiht ask there
<sivang> and possibly contribute back my findings on the AU1550 amd based box ;)
<sivang> (debian runs beautifully on it)
<pitti> http://people.ubuntu.com/~ubuntu-archive/removals.txt
<sivang> never mind , need to run
<sivang> laters all, wonderful day to you all
<geser> morning
<mdke> does anyone know if newz is on holiday or otherwise off work at the moment?
<soren> Well, he's in the US, so he's probably asleep, but apart from that, I think he should be around.
<mdke> soren: yes, I meant in general, thanks
<tjaalton> what's happening with gtk+/glib-1.2 in hardy? fvwm is uninstallable because it refuses to install libglib1.2
<persia> tjaalton: Library transition: http://people.ubuntu.com/~ubuntu-archive/NBS/libglib1.2 still need a rebuild.
<tjaalton> persia: yeah, I dug a bit more
<soren> mdke: np :)
<seb128> persia: how come that we have a libglib1.2 transition now and why debian doesn't?
<\sh> keescook, jdstrand thx for taking care about the cve uploads....
<geser> seb128: Debian has also libglib1.2ldbl (we have the same revision) and when at least gtk-engines got a binary NMU for it
<persia> seb128: As geser said, Debian does have the transition (with 1.2.10-18).
<pitti> geser, persia: I hope you are using a script for the rebuilds?
<pitti> (such as http://people.ubuntu.com/~pitti/scripts/update-maintainer-transition)
 * persia has only done a few, and didn't script it
<persia> pitti: Should we be batch-scripting and pushing them, or looking at them independently?
 * StevenK has a script for mass-rebuilds, but it's fairly fragile, and doesn't cope with Maintainer changes needing to be done.
<persia> StevenK: Isn't that only the case for the remaining few hundred cases where we have Ubuntu variation and no Ubuntu maintainer?
<StevenK> persia: I've hit at least one during the last few mass rebuilds I've done, so I think I should update the script.
<persia> StevenK: Makes sense.  I keep meaning to quash some of them, and might take advantage of pitti's script to hit a few when I next have a few hours open.
 * TheMuso has done a few rebuilds for libglib, and most were to satisfy depends issues for ubuntustudio.
<geser> pitti: The rebuilds I did were all manual, I will look into your script. Thanks.
 * TheMuso is also looing into the script.
<TheMuso> looking
<mvo> Amaranth: I think we are good to upload the git HEAD compiz to hardy, the only outstanding issue I have is that in plugins-main 02_fix_edge is crashing and needs to be ported or disabled. do you see anything else that is left to be done?
<tjaalton> umm, using "-vversion" for debuild makes it segfault on gutsy
<Amaranth> mvo: I thought that was upstreamed already
<tjaalton> nevermind
<tjaalton> forgot the epoch..
<mvo> Amaranth: last I heard they consider it too much of a hack to include it into the regular tree
<Amaranth> oh, we'll figure that out later i guess
<Amaranth> heh, your changes to compiz where stuff i had locally and forgot to push
<Keybuk> which ungodly hack is that?
<Amaranth> disable wall edges unless you're dragging a window
<Amaranth> so they don't stop you from clicking on things in corners/edges
<Amaranth> mvo: everything else looks good
<mvo> Amaranth: cool, I think I upload later today and use it a bit until then to see if there is other obvious breakage
<Amaranth> well, there is one bad breakage i get with it
<Amaranth> xmoto pops out of fullscreen as soon as it gets the cursor
<Amaranth> but that's small
<mvo> heh :) I should try this
<geser> mvo: command-not-found is missing a build-dependency on python-gdbm. Do you want a debdiff for it?
<mvo> geser: if you have it at hand, yes. I noticed the b-d failure mail a couple of minutes ago
<geser> mvo: http://members.ping.de/~mb/c-n-f.debdiff
<mvo> geser: thanks!
<mvo> geser: I used to be a member of ping.de too in my good old times
<geser> pitti: please give-back extace
<geser> pitti: another two package FTBFS because of the dh_strip bug: dvi2tty and flexml
<geser> pitti: please give-back g15daemon-audacious
<geser> pitti: please give-back gnome-iconedit
<tkamppeter> pitt, hi
<tkamppeter> pitti, hi
<pitti> geser: kicked; dh_strip> can you please mention the packages in the pkg-create-dbgsym bug? I'll give them back once it's fixed
<pitti> hi tkamppeter
<pitti> hey seb128
<seb128> hello pitti
<tkamppeter> pitti, I have re-uploaded the debdiff on for bug 153152, I accidentally deleted it when preparing the SRU in bug 149511.
<ubotu> Launchpad bug 153152 in hplip "[Gutsy SRU request] Fax utility not adding files to job." [Undecided,Fix committed] https://launchpad.net/bugs/153152
<ubotu> Launchpad bug 149511 in ubuntu-meta "[Gutsy SRU request] hplip is needed by HPIJS" [Medium,Fix released] https://launchpad.net/bugs/149511
<pitti> tkamppeter: no problem, that SRU is already in -proposed
<pitti> so no new upload necesasry
<pitti> tkamppeter: I buess bdmurray only updated hplip for testing, not hpijs?
<geser> pitti: I've already added a comment for both packages in the bug
<pitti> geser: ah, thanks
<sladen> who the heck let through that message to ubuntu-devel-announce@lists.ubuntu.com
<Fujitsu> sladen: We were wondering that yesterday.
<geser> pitti: should I mentioned further packages affected in the bug (if I find others)?
<pitti> geser: yes, please
<pitti> geser: oh, how evil
<pitti> geser: dvi2tty has debian/compat '4', but uses debian/tmp
<pitti> argh, and uses DH_COMPAT=1 in debian/rules
<pitti> this is so evil
<soren> pitti: compat 4 and debian/tmp is not kosher? Why?
<pitti> ah, so DH_COMPAT should trump debian/compat
<pitti> soren: debian/tmp is compat level 1 only
<soren> Eh?
<Chipzz> pitti: hrrrm, as far as I understand debian/tmp is used as a temporary directory for moving files to different subdirs of debian/ (and hence different packages)?
<soren> pitti: Ok, we're clearly talking about different things :)
<Chipzz> or am I horribly mistaken?
<pitti> Chipzz, soren: man debhelper  /V1
<tkamppeter> pitti, I have done addtional tests on bug 153152. The fix works perfectly on Hardy, but on an old laptop which I updated to Gutsy, Python errors appear, so it seems that there is a second fax bug which occurs only in Gutsy.
<ubotu> Launchpad bug 153152 in hplip "[Gutsy SRU request] Fax utility not adding files to job." [Undecided,Fix committed] https://launchpad.net/bugs/153152
<pitti> soren, Chipzz: in mode 1, debian/tmp *is* the package directory of the first package in debian/control
<soren> pitti: Right, ok. You left that bit out :)
<pitti> not just a temporary place where to move files to debian/<packagename>/
<pitti> soren: well, geser knew :)
<pitti> tkamppeter: ah, too bad; please test SRUs on gutsy, too
<pitti> tkamppeter: if you want to prepare another update, feel free to sneak in the dependency fix you mentioned
<Chipzz> pitti: ah ok; I see that in the man-page
<pitti> geser: ok, I got it fixed for dvi2tty, testing the other ones now
<Chipzz> pitti: but debian/tmp can still be used as an intermediary place to install files to, which will later be moved to the correct dirs, right?
<tkamppeter> pitti, if you want to see what happens, do the TEST CASE steps on a Gutsy.
<pitti> Chipzz: right, that's common and good practice
<Chipzz> (ie as in 'make install DESTDIR=debian/tmp')
<Chipzz> and use dh_install to move the files in debian/tmp to the correct dirs
<Chipzz> pitti: under V3 I read: dh_makeshlibs makes the postinst and postrm scripts call ldconfig. But since we now use dpkg triggers, shouldn't that be clarified which DH_COMPAT level should be used to rely on that?
<pitti> Chipzz: that's orthogonal to triggers; those are implemented at the dpkg level and within ldconfig itself
<pitti> Chipzz: read /sbin/ldconfig to see the magic
<tkamppeter> pitti, the problem of bug 153152 is non-trivial, I will ask the HP guys to fix it.
<ubotu> Launchpad bug 153152 in hplip "[Gutsy SRU request] Fax utility not adding files to job." [Undecided,Fix committed] https://launchpad.net/bugs/153152
<adrian15> Hello. I am trying to boot an ubuntu cd with grub. Is there any boot option that am I missing? Is there any boot option that it is not written in isolinux.cfg? It is very strange that there is not any root= option.
<adrian15> does not anyone try to build ubuntu cdroms in their own ?
<sladen> adrian15: the initramfs contains 'casper' which goes to hunt for the rest of the LiveCD system to boot
<mvo> ogra: can we have a quick chat about the edubuntu-two-cd changes? I'm currently pondering how this is going to be implemented in the release-upgrader
<ogra> mvo, indeed
<ogra> here or pm ?
<adrian15> sladen: my problem is that I use grub for trying to load it with: kernel /casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper quiet > splash -- ENTER initrd  /casper/initrd.gz ENTER boot                                      and I finish with an initramfs shell
<mvo> ogra: pm sounds appropriate, I don't think its that interessting :)
<adrian15> sladen: you have an screenshot here: http://adrian15.raulete.net/ficheros/u710_chainloaded_isolinux.png
 * Hobbsee waves
<pitti> hey Hobbsee
<mvo> Riddell: could you please have a look at https://wiki.ubuntu.com/LTSUpgrades? there is a question about kde in the "Outstanding issues" section. it would be nice if you could add a comment there
<pygi> hello everyone
<Hobbsee> heya pitti!
<pitti> tkamppeter: ah, seems that Mark Purcell does quite some maintenance on hplip now (we regularly autosync from Debian); does the cooperation in svn work?
<Riddell> mvo: jcastro was looking into that
<mvo> Riddell: nice. if he could just add something to the wiki, that would be cool
<sladen> adrian15: you could look at some of the commandline parameteres in the directory: http://www.paul.sladen.org/ubuntu/qemu-livecd/
<adrian15> sladen: root=/dev/ram taht's what I suspected
<adrian15> sladen: but what I don't understand is why isolinux is not able to boot it. (my modified version of isolinux)
<adrian15> sladen: And I will bet these are the mkisofs options
<adrian15> sladen: I will try these ones: https://help.ubuntu.com/community/LiveCDCustomization#head-ab8f641f4bbc6cbafbe1699b580c06668bf7a484
<attunix> I customized my Ubuntu Server distro installation to have a python script run on startup from /etc/rc.local . How do I make this installed distribution into a Live or Install CD?
<sladen> adrian15: is http://uck.sourceforge.net/  (Ubuntu Customisation Kit) any use
<sladen> adrian15: sorry I can't easily tell more from this distance
<attunix> ok. thank you
<cjwatson> attunix: https://help.ubuntu.com/community/InstallCDCustomization and https://help.ubuntu.com/community/LiveCDCustomization should help you
<attunix> thank you :)
<soren> mvo: You think bug 141601 could be apt's fault?
<ubotu> Launchpad bug 141601 in tasksel "tasksel packages stays at 100%" [Undecided,New] https://launchpad.net/bugs/141601
<mvo> pitti: would you be ok with http://paste.ubuntu.com/2454/ until we have a better fix? this way I can continue testing the upgrade
<mvo> soren: it can certainly be a apt problem
<pitti> mvo: works for me (please check it into bzr)
<mvo> soren: I look at it after lunch
<soren> mvo: Cool. Thanks!
<cjwatson> soren: could also be debconf-apt-progress
<cjwatson> soren: which is sort of suggested by the zombie apt
<cjwatson> I rather hoped we'd nailed all of those though
<cjwatson> soren: strace -f -s 1024 and then stare at the output a lot tends to be the only real way to attack this
<mvo> cjwatson: it looks like a issue in apts internal dpkg-log code, there is a fix in gutsy-proposed for this, I ask if he can install this version and see if that fixes the issue
<cjwatson> mvo: you think? OK ... how would a bug in apt lead to a zombie apt-get lying around though?
<cjwatson> or is it that it's writing garbage down the status fd and confusing d-a-p that way?
<cjwatson> I vaguely remember discussing something like that with you, now that you mention it
<soren> cjwatson: Yes, I've noticed that too.
<cjwatson> debconf-apt-progress is extraordinarily delicate :-/
<mvo> soren: a strace would definitely be good to have
<soren> I think it's debconf-apt-progress. I have a fix I want to test out.
<cjwatson> soren: I wrote that code and would be interested in reviewing a patch
<mvo> ok, I may be wrong, is this reproducable?
<soren> mvo: Yes, apparantly so.
<soren> mvo: Just tasksel install dns-server or something.
<mvo> soren:  ok, thanks. after lunch then :)
<soren> cjwatson: Gimme a few minutes.
<cjwatson> yes, I see the same bug here
<cjwatson> soren: off for lunch soonish anyway
<mvo> pitti: http://paste.ubuntu.com/2455/ <- bzr does not like me today
<mvo> cjwatson: I would be interessted if the apt in gutsy-proposed fixes it or not
<soren> cjwatson: It gets stuck in the select call.
<soren> cjwatson: Or so says strace.
<cjwatson> perhaps it's selecting on no fds
<cjwatson> I'll look after lunch if you don't beat me to it :)
<pitti> mvo: hm, regression in 1.0?
<crimsun> StevenK: thanks for the -meta refresh & upload
<soren> Hehe..
<soren> I think I got it.
<pitti> mvo: u-m processed in gutsy-proposed FYI
<pitti> StevenK, Mithrandir: hm, the mobile packages are still native (no orig.tar.gz) and have funny version numbers like 3.0-sardine1ubuntu2; will that be fixed at some point?
<soren> cjwatson: http://people.ubuntu.com/~soren/debconf-apt-progress.diff   fixes it, but not being familiar with the code, I'm not convinced it's actually a correct fix.
 * emgent heya
<StevenK> pitti: Yes, there will be an on-going effort to clean up the packaging, since some of it is really shocking
<StevenK> pitti: And I'm well aware what native means. :-)
<somerville32> Dear Ubuntu, today I won't be in to work today because I have 30cm of snow outside to enjoy. kthxbi :P
<Amaranth> somerville32: Yay, you can get a head start on hug day :)
<somerville32> \o/
<somerville32> I was thinking about going outside for once but I guess I'll do hug day instead :P
<Amaranth> I should probably do my hug day stuff today as well, I suspect I'll be rather intoxicated tomorrow (it's my 21st birthday)
 * somerville32 cheers
<somerville32> Amaranth, I'll have a drink for you tomorrow than
<jdong> Dear Unnamed Ubuntu Developers With The Day Off:
<jdong> SCREW YOU.
<jdong> JUST SCREW YOU.
 * Amaranth passes the bottle to jdong
<persia> jdong: Everyone is entitled to their separate holidays.
<Amaranth> Oh, that's illegal
 * Amaranth takes it back
<jdong> persia: yeah only if they're separate, but equal duration holidays ;-)
<somerville32> lol
 * somerville32 is in a jolly mood today and decides to eat another poptart (strawberry)
<persia> jdong: I disagree (but I moved to the country with the most public holidays, so perhaps I'm biased)
<somerville32> lol
<jdong> persia: hahaha
<somerville32> I wonder if I could convince work that OSS is a religion :P
<somerville32> "Umm yea, sorry, can't work today - hug day :P"
<jdong> somerville32: just point them to some of Theo De Raadt's quotes. OSS is more than a religion.
<jdong> :D
<somerville32> :D
<somerville32> "Blessed isth the man who is open sourced."
<Amaranth> Ugh I need to stop staying up all night
<somerville32> Amaranth, Yea, today is the first day my sleep schedule normalized
<Amaranth> It's just that I have a LUG meeting tonight that I'm going to sleep through at this rate
<tkamppeter> pitti, Mark Purcell has started this recently by syncing back my newest Ubuntu HPLIP package to Debian. My package is much simpler and much more maintainable as the Debian packages from HMH. So Marc abandoned the CVS from HMH and started a new SVN with my package. Then he asked me whether we should collaborate and he gave me write access to the SVN.
<jdstrand> Keybuk: I am just diving into upstart and read http://upstart.ubuntu.com/getting-started.html.  I'd like some clarification on the statement 'Jobs will be run alongside the init scripts for that runlevel'
<pitti> tkamppeter: right, I read that much on the ML; I was just curious about how well it works
<jdstrand> Keybuk: eg start on runlevel 2
<jdstrand> Keybuk: will the job start before sysvinit scripts for 2, after or anytime during when those scripts are started
<jdstrand> ?
<tkamppeter> pitti, currently, where HP did not release for some time, there is no movement, but I think on the next release the two distros will quickly update.
<jdstrand> s/are started/are being started/
<tkamppeter> pitti, did you also already know that HP upstream also uses the Launchpad as bug tracking system? This is nice, as if someone reports a bug to Ubuntu and it is an upstream, problem, one can move it easily and bring the reporter into direct contact with the HP guys.
<pitti> tkamppeter: I noticed that they are quick on replying, yes
<pitti> tkamppeter: do they actually read all the Ubuntu bugs, or only those which we create an upstream task for?
<tkamppeter> pitti, for example on this failed SRU I have simply added an upstream task to tell HP that it needs more love from them.
<pitti> tkamppeter: ah, cool; yes, that's how it's supposed to work in LP
<Keybuk> jdstrand: alongside
<pitti> nice to see that it actually does :)
<StevenK> pitti: TheMuso will probably be your new best friend tomorrow.
 * pitti hugs TheMuso
<pitti> StevenK: ?
<StevenK> pitti: TheMuso is doing libglib1.2 NBS work
<jdstrand> Keybuk: heh, yes, I guess I am being thick-- that was the word I wanted clarification on. So it will be started *sometime* during when rc2 scripts are being run?
<TheMuso> pitti: Getting ready to do a rebuild run to catch any lingering FTBFS ssues overnight, and a double check that the packages being changed actually need the change.
<pitti> aah, right, we talked about htat this morning (and about scripting it)
<jdstrand> Keybuk: so I can't depend on a certain order
 * StevenK has grabbed the gsl NBS stuff
<kervala> hi there :)
<tkamppeter> pitti, one HP guys is in the bug contacts of the HPLIP package, and I have ususally subscribed some more HP guys (before HP upstream used Launchpad), and then they usually reacted quickly and did the fix in the following release (HPLIP releases every 1 or 2 months). After a freeze I asked for patches and got them quickly, too.
<TheMuso> pitti: Yep with your maintainer script tweaked, the libglib1.2 rebuild work is done, bar a few ones I had to do manually.
<pitti> tkamppeter: awesome!
<pitti> TheMuso: \o/
<TheMuso> Now. To get this shared rebuild script built, and get the two boxes building, and then bed.
<TheMuso> s/built/written/
<tkamppeter> pitti, so in the sense of Linux support HP printers are the most recommended to buy.
<kervala> i have some problems with my PPA (related to missing .mo files in generated .deb) :) who could help me please ? :)
<persia> kervala: You might get help on #launchpad
<persia> Do PPAs run pkgbinarymangler?
 * StevenK grumbles, only getting 23KB/s from archive.u.c
<StevenK> persia: I daresay they do
<jdstrand> Keybuk: maybe if I am more direct.  I'd like to start a script before any run-level scripts.  it sounds like 'start on runlevel 2' is not for me.  will 'start on started rcS' then be guarnateed to run before runlevel 2, for example?
<kervala> persia> thanks, i will see there :) there are too many channels :p
<Keybuk> jdstrand: the job will be started at exactly the same time that the /etc/init.d/rc script is started to run through the scripts in /etc/rc2.d
<Keybuk> jdstrand: started rcS happens before starting rc2 due to the way those scripts work
<jdstrand> Keybuk: ok, so 'start on runlevel 2' is kinda like a 00foo initscript
<jdstrand> in terms of timing
<jdstrand> Keybuk: ok thank you for the clarification
<Keybuk> jdstrand: no
<cjwatson> soren: I'm not convinced either
<Keybuk> jdstrand: 00foo is run by rc, and has guaranteed ordering based on 01aa or 00aa
<soren> cjwatson: It makes sense that it should break the loop when either of the involved parties eof.
<cjwatson> soren: seems like that'll always drop the last messages on either one or the other of the status and debconf command fds
<soren> cjwatson: ...the question is whether it will have any ill side effects.
<cjwatson> it's supposed to break the loop when both of them are closed, not just one
<Keybuk> jdstrand: an "on runlevel 2" upstart job may be run before, at the same time as, after or even pre-emptively with any job in rc2
<Keybuk> depending on your kernel, time sharing, etc.
<soren> cjwatson: Ok.
<jdstrand> Keybuk: ah-- by 'started at exactly the same time', you just meant upstart will begin going through its 'start on runlevel 2' jobs at the same time it begins the first rc2 script
<soren> cjwatson: Ok, so the loop gets progress from apt and sends it to debconf's frontend.. Is that right?
<soren> No, that doesn't smell right.
<soren> cjwatson: I get confused by the fact that we're checking DEBCONF_COMMAND_*READ* to see if it's *wrtiable*.
<jdstrand> Keybuk: you said 'started rcS happens before starting rc2 due to the  way those scripts work
<cjwatson> soren: the loop takes progress-type messages from both apt's status fd and a debconf fd passed through apt, and translates them into the appropriate debconf commands to send to its own frontend
<jdstrand> Keybuk: does that mean that if I use 'start on started foo', that all I am guaranteed is that foo will begin executing, and then my script will start, whether foo is finished or not?
<soren> cjwatson: Oh.. So there's two debconfish things involved.
<jdstrand> Keybuk: or am I reading too much into your statement
<jdstrand> ?
<soren> cjwatson: Er... I'll shut up now, and actually read the code.
<cjwatson> yes, the apt process called by tasksel is configured such that packages it installs will start up an independent debconf 'passthrough' frontned
<cjwatson> frontend
<cjwatson> which means "send stuff to this fd please rather than starting up your own UI"
<Keybuk> jdstrand: correct
<soren> cjwatson: Oh, ok.
<Keybuk> jdstrand: all "start on started foo" guarantees is that foo has at least started before you are run
<Keybuk> it does not guarantee that it hasn't since stopped again
<jdstrand> Keybuk: is there a 'start before runlevel 2' directive?
<jdstrand> Keybuk: or would that just be better served by using a 00.. initscript?
<Keybuk> jdstrand: you want your job to start as rc2 attempts to start, and your job has to complete before rc2 is allowed to continue starting?
<jdstrand> Keybuk: yes
<Keybuk>   start on starting rc2
<Keybuk> (and make sure you don't use the word "service" or "respawn" in your job)
<cjwatson> soren: the only fd being selected on is DEBCONF_COMMAND_READ
<jdstrand> Keybuk: ok cool
<Keybuk> (frankly, since you care about runlevels, I think you'll be better served by writing it as an ordinary init script)
<soren> cjwatson: When it's hanging?
<cjwatson> soren: yeah
<soren> cjwatson: Yes, that sounds right.
<soren> cjwatson: apt seems to terminate just fine.
<cjwatson> (determined by looking through the trace of d-a-p's startup)
<cjwatson> ok, so why is the other end of that pipe not being closed?
<soren> I've not used debconf much, but isn't there something about it not letting go of certain file descriptors when it finishes?
<cjwatson> that shouldn't apply when it actually *exits*
<cjwatson> anyway, meeting, will get back later
<jdstrand> Keybuk: ok, now thank you for clarifying this for me :)
<soren> cjwatson: Sure.
 * Hobbsee pokes infinity with a big stick
 * lamont grumbles at curl, amarok, tuxtype, abiword, aalib, and nspr for build-depend looping
<Hobbsee> they do?
<lamont> Hobbsee: I know they were dep-wait looping on hppa.  or at least they seemed to be...
<Hobbsee> lamont: ahhh
<lamont> I threw them in the cellar and stomped on them last night
<Hobbsee> hehe
<lamont> I fat-fingered it though: nspr wound up at 199 instead of 100 with the rest
<soren> cjwatson: Hm.. strace reveals that DEBCONF_COMMAND_READ gets file descriptor 9, but apt is only told to keep fd's 5 and 6 (and use 4 for status messages).
<tkamppeter> pitti, system-config-printer seems to hang in the queue and does not upload. The bugs still did not auto-close and the LP still shows the old version.
<pitti> tkamppeter: ah, I bet I know why; you forgot to build with -sa, I reuploaded, and forgot to remove the .upload file
<Riddell> dholbach: do you know about dh_icons?
<dholbach> Riddell: what do you want to know?
<pitti> tkamppeter: uploading again
<ogra> oooh. soren you go the same path as i did in gutsy with my ltsp udeb :) book a place in the nearest asylum in advance :) i think the only person not going insane about this debconf fd stuff is actually cjwatson :)
<Riddell> dholbach: we seem to have found a bug in it, and I'm curious why it hasn't affected others
<Riddell> dholbach: bug 173770
<ubotu> Launchpad bug 173770 in kdelibs "kdelibs-data is un-uninstallable" [Undecided,New] https://launchpad.net/bugs/173770
<tkamppeter> pitti, I have a rev1772 which is more complete, should I give you that one?
<soren> ogra: My head is spinning a bit, yes :)
<pitti> tkamppeter: too late now, I already uploaded
<ogra> soren, i tried for a while and then reverted to the old ugly behavior (i'm running two instances of debconf in two stacked chroots ... which actually isnt possible and i didnt find any way around it)
<StevenK> pitti: You mentioned in the bug libfakekey can be promoted, does that mean it has been or will be?
<pitti> StevenK: 'can be', once we actually need it in main
<dholbach> Riddell: which part of the postrm is it that fails?
<dholbach> Riddell: one example I found on my machine: http://pastebin.ubuntu.com/2460/
<pitti> StevenK: if it helps you in any way I can promote it right now, but that might make it harder for people like Adilson who aren't core-devs
<StevenK> pitti: Fair enough. I will work on some of the problems tomorrow
<StevenK> pitti: No no, just curious
<StevenK> Adilson isn't even a MOTU
<StevenK> lool isn't a core-dev, though
<Riddell> dholbach: well the "update-icon-caches /usr/share/icons/crystalsvg" line
<Riddell> dholbach: your one looks quite different
<dholbach> Riddell: it seems they changed it in debian
<dholbach> I filed a bug report once to get the     || true     added
<dholbach> seems it got removed again
<dholbach> or  update-icon-caches  fixed to not fail at all
<Riddell> dholbach: do you know who's best to contact in debian to ask what's going on?
<dholbach> lool: Josselin does dh_icons, right?
<cjwatson> soren: DEBCONF_COMMAND_READ is debconf-apt-progress' private side of it. DEBCONF_COMMAND_WRITE (the other half of the pipe) is duped onto fd 6.
<tkamppeter> pitti, thanks for the upload, I have seen the bugs auto-closing now.
<cjwatson> soren: I think I might see the problem
<cjwatson> soren: oh, hmm, no
<soren> cjwatson: I'm a bit confused. I see a few calls to nocloexec, but in strace, all I see is a whole bunch of "fcntl(various_fd's, F_SETFD, FD_CLOEXEC)".
<pitti> ah, the joys of Debian and upstream accepting patches -- the sudo merge finally is a breeze now
<cjwatson> that's what nocloexec does ...?
<soren> I expected it to unset FD_CLOEXEC?
<soren> Rather than set it.
<cjwatson> oh, sorry
<cjwatson> 14988 fcntl64(4, F_SETFD, FD_CLOEXEC)   = 0
<cjwatson> 14988 fcntl64(4, F_GETFD)               = 0x1 (flags FD_CLOEXEC)
<cjwatson> 14988 fcntl64(4, F_SETFD, 0)            = 0
<cjwatson> that's the sort of thing I see
<cjwatson> the first SETFD is internal to perl
<soren> cjwatson: Oh, you're right.
<cjwatson> soren: OK. I think what's happening is that the apt-get subprocess dies, but doesn't actually get reaped until debconf-apt-progress' loop terminates.
<cjwatson> soren: apt-get probably explicitly closes its status fd, but doesn't close the reserved debconf passthrough fds.
<cjwatson> soren: so the write end of DEBCONF_COMMAND_* doesn't get cleaned up fully until the zombie apt-get is reaped by debconf-apt-progress
<lool> dholbach: I'm not sure; I think Joey Hess + Josselin did
<cjwatson> soren: the fix, I think, is to have a proper SIGCHLD handler which sets a flag that we can use to reap apt-get
<cjwatson> soren: or possibly even just $SIG{CHLD} = 'IGNORE';
<lool> dholbach: But I don't want to touch this; they basically ignore my comments   :-/
<cjwatson> though, well, we do care about the exit status, so not IGNORE
<dholbach> Riddell: ^ what lool said :-/
<cjwatson> soren: you need to be fairly careful when writing a SIGCHLD handler (or indeed any signal handler) in perl, though.
<cjwatson> or in any language :-)
<cjwatson> perlipc(1) may help
<lool> The very thing I asked was to encapsulate the list of directories for which to run gtk-u-ic in some place as to allow us to re-run it or fix stuff in these dirs
<cjwatson> soren: in fact, since select() is interrupted when SIGCHLD arrives, you could just try waitpid $pid, WNOHANG and if you get a child back then save its status for later. You still need to process any remaining input from the pipes, but now the other end of DEBCONF_COMMAND_* should be properly closed and you'll break out at the right time.
<robertj> is anyone intimately familiar with system-config-printer? I added a printer using it to my local machine and the remote print server then lost its association between printers & windows printer drivers. Its probably on the remote end by I'm trying to figure out what it could have done to trigger that.
<soren> cjwatson: I realise that this would fix it, but it it really doesn't seem like the right approach. If the other end is supposed to let go of the file descriptor but doesn't, then something must be wrong?
<Riddell> lool: can you fix it in ubuntu?
<robertj> server is to my best guest held together by voodoo & duct-tape but I'm still trying to figure out what kicked it into action
<cjwatson> soren: no, it's right - the other end doesn't let go until the process is actually cleaned up properly
<cjwatson> this is how Unix works, it's fine
<cjwatson> soren: something like http://paste.ubuntu.com/2461/ (untested, meeting now)
<kagou> hi
<lool> Riddell: I didn't read about the problem yet
<cjwatson> soren: and we really should reap the process ASAP anyway
<lool> Riddell:  bug 173770?
<ubotu> Launchpad bug 173770 in kdelibs "kdelibs-data is un-uninstallable" [Undecided,New] https://launchpad.net/bugs/173770
<Riddell> lool: yes
<cjwatson> we might need to do it each time round the loop as well, since the SIGCHLD won't necessarily interrupt the select
 * soren could have sworn fd's got close()d when exit was called.
<pitti> asac: can you please open a MIR bug for xulrunner? (changed process, see the note on the top of UbuntuMainInclusionPage and MainInclusionProcess)
<cjwatson> they might do, but I suspect the other end doesn't get an exception from select until it's reaped
<asac> pitti: i opened a MIR bug :) ... let me see
<pitti> asac: ah, ok; I just saw your Queue wiki page change
<asac> pitti: its named at the bottom
<soren> cjwatson: That doesn't make sense.
<cjwatson> soren: seems to match what's happening :-)
<asac> pitti: ok subscribing ubuntu-mir
<pitti> asac: ah, splendid; thanks
<soren> cjwatson: Got me there. :)
<cjwatson> select is weird
 * soren looks at strace output some more
<pitti> asac: yay xulrunner :)
<asac> pitti: now that we track it through bugs ... do we still need the wiki pages?
<pitti> asac: the MIRs, yes, but not the Queue page
<asac> e.g. filling out the template in summary?
<asac> ah ok
<pitti> asac: well, if you want you can also put the actual MIR into the bug, I don't mind much
<pitti> but wiki formatting is nicer to read for long reports, and for changes (IMHO)
<pitti> asac: no editmoin for LP bugs :)
 * ogra thought the queue page is obsolete
<pitti> asac: I smell a MIR for ffox 3, too, I guess
<pitti> ogra: it is
<pitti> ogra: that's what we just said
<ogra> oh, blind me
<lool> Riddell: Looking at the postinst snippet, I think it should test for the dir before trying to run this command; I'm checking with Josselin
<lool> Riddell: Josselin said it's a bug; I'm confirming where he wants to fix it, and will upload the same fix
<Riddell> lool: thanks.  let me know when it's in the archive and I'll rebuild kdebase against it
<lool> Riddell: You wont need to; the fix should be applied to the script in libgtk2.0-bin it seems
<Riddell> oh, lovely
<faheem__> Hi. I have a package that needs postgres 8.1 or later on Debian. However, Ubuntu doesn't seem to want to install 8.1. I want to use the same packaging (rules/control files) on both Debian and Ubuntu. Any suggestions?
<faheem__> Well, it complains about 8.1, anyway.
<seb128> Riddell: dh_icons is a debhelper script, not a gtk+ thing
<lool> Riddell: Can you check the new script (copy it over from debian/ to /usr/bin) and sponsor the upload if it works?  http://people.ubuntu.com/~lool/packages/gtk+2.0/2.12.2-1ubuntu1/hardy/gtk+2.0_2.12.2-1ubuntu1.dsc
<lool> Riddell: I'm not finished uploading
<seb128> lool: ?
<lool> seb128: The bug can be fixed in the snippet or in the wrapper script in Gtk+; Josselin wants to fix it in Gtk+
<seb128> lool: do you speak about bug #173770?
<ubotu> Launchpad bug 173770 in debhelper "kdelibs-data is un-uninstallable" [Undecided,New] https://launchpad.net/bugs/173770
<lool> seb128: Check #gnome-debian or my latest commit
<lool> seb128: Yes
<lool> Riddell: Upload complete now
<seb128> lool: we are in sync with Debian for gtk+2.0, no need to do an hardy upload to ask a sync then
<seb128> lool: better to just wait for the new revision to be uploaded in Debian
<lool> Riddell: ^^^
<lool> seb128: Depends how long this can wait
<seb128> there is no hurry imho, it's a corner case
<Riddell> yeah, nobody removes kde once they have it installed :)
<lool> Please discuss what's best; I don't want to upload to Debian nowish though
<seb128> I would say "do nothing and wait for the next upload to debian"
<seb128> we got one bug about that and the bug is likely there for months
<seb128> so I don't think it's an urgent issue
<dragon76> hello all.
<dragon76> tested 2.6.24-1 kernel in hardy last night and kdm doesn't want to start
<dragon76> is there anyway I can help troubleshoot
 * lamont looks around for an RM/archive god
<lamont> https://edge.launchpad.net/ubuntu/+source/curl/7.17.1-1ubuntu1/+build/461099
<lamont> there is no way to tell launchpad to not decide that since libssh2-1-dev is in universe, that it should free the dep-wait
<lamont> it'd be nice to get those fixed (there are about 5 such packages atm)
<Riddell> lool: that does fix it by the way
<lool> Riddell: Cool
<soren> cjwatson: It doesn't add up. Even if I call _exit in the child and don't reap it, the select call still returns.
<cjwatson> soren: select will return no matter what - that's what happens when you get a signal, it interrupts the syscall
<soren> cjwatson: Even if I run it again, it will return right away because the child is gone and there's an eof waiting for me.
<Zic> hi, I can see their is some Â« restricted/multiverse Â» code in main/universe at http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=iwlwifi&searchmode=searchword&case=insensitive&version=gutsy&arch=i386
<Zic> the question is why ?
<soren> cjwatson: Oohh..
<soren> cjwatson: Glancing around in /proc reveals that the pipe is still connected to one of the daemons that got started as a result of installing the task.
<soren> cjwatson: Well, if I can expect  pipe:[6280851]  to uniquely identify the pipe, at least.
<cjwatson> soren: aha
<cjwatson> sounds plausible
<cjwatson> yes, you can
<soren> cjwatson: I thought so.
<cjwatson> I see that sort of as a bug in said daemon
<soren> I'm curious why bind doesn't close superfluous fd's, though.
<cjwatson> but perhaps we can work around it ...
<soren> Something is not setting CLOEXEC, but should.
<soren> There's just too much stuff involved here for me to figure out which component is to blame. :)
<soren> Some sort of tool that could track the life of file descriptors would have been quite helpful here. "strace -f" is confusing :)
<cjwatson> can't set CLOEXEC on this
<cjwatson> that fd has to go all the way to the postinst
<cjwatson> maybe we do just have to ignore trailing stuff on the debconf command fd
<cjwatson> soren: in that case maybe something like 'while (not $status_eof)' would be better, with a honking comment
<cjwatson> but it's unfortunate that bind is going to have that fd hanging around
<soren> cjwatson: Yeah, you'd think that a piece of software that old would have fixed that sort of thing by now.
<cjwatson> well
<cjwatson> packages that use debconf are expected to have to deal with this
<cjwatson> but bind9 doesn't actually use debconf itself
<soren> It does not.
<cjwatson> so historically it wouldn't have shown up in Debian
<soren> With my limited knowledge of the intimate details of debconf, apt and dpkg and how they work together it doesn't seem unreasonable to assume that the last thing to be closed would be the status fd?
<lamont> soren: bind or bind9?
<soren> lamont: bind9
<lamont> grumble
<lamont> oh. right.  no debconf usage in bind9.
<lamont> I win.
<soren> Well... It would be kind of nice if it close()d the superfluous file descriptors.
<lamont> or do I need to fix something>?
<soren> Sure, we should fix our end of things, too, but still.
<lamont> I expect it's a case of "don't run it with extra fds, why should we waste our time running through all the possible fds closing them?" sort of responses from upstream.
 * soren sighs
<lamont> if we started up debconf just long enough to end it, would that solve the issue?
<lamont> so far, bind9 has happily managed to avoid using debconf
<soren> *G*
<lamont> the other bug I need to stare at in bind9 is bug 453765
<lamont> hrm  I wonder if I should say debbug 453765 or debian bug 453765
<ubotu> Debian bug 453765 in bind9 "bind9 stops during upgrade" [Normal,Open] http://bugs.debian.org/453765
<cjwatson> lamont: starting up debconf will not help
<cjwatson> lamont: I think bind should close stray fds (aiui, it's fairly standard practice for daemons to do so), but it's not critical
<cjwatson> soren: yeah, I think that's probably right
<lamont> cjwatson: true enough.
<cjwatson> soren: try it out?
 * lamont wanders afk for a while
<soren> cjwatson: I'm sure it works. It's effectively the same as my original suggestion :)
<soren> cjwatson: I'm just asking for advice as you're more familiar with the possible corner cases, we could come across.
 * soren is assuming that "try it out" referred to just checking for $status_eof
<cjwatson> yes
<cjwatson> I think it's probably equivalent in practice but more accurate in theory
<cjwatson> it works for me
<cjwatson> http://paste.ubuntu.com/2464/ <- what I used
<soren> Makes sense.
<cjwatson> suggestions for a comment?
<cjwatson> (sorry, very little mental bandwidth today)
<soren> cjwatson: "STATUS_READ should be the last fd to close"?
<cjwatson> maybe combined with "DEBCONF_COMMAND_WRITE may end up captured by buggy daemons, so terminate the loop even if we haven't hit $debconf_command_eof."
<soren> You win.
<cjwatson> I included both :)
<cjwatson> is there a bug number for this?
<soren> Yes. Hang on.
<soren> There's more than one, actually.
<soren> bug 165165, bug 141601 at least.
<ubotu> Launchpad bug 165165 in tasksel "tasksell install lamp-server hangs" [Undecided,New] https://launchpad.net/bugs/165165
<ubotu> Launchpad bug 141601 in tasksel "tasksel packages stays at 100%" [Undecided,New] https://launchpad.net/bugs/141601
<soren> I believe ther'es more.
<cjwatson> I'll refer to 141601; please dup the others
<cjwatson> soren: r2249 in svn://svn.debian.org/svn/debconf/trunk/src/debconf
<cjwatson> committed with your name :)
<soren> cjwatson: Excellent. Thanks for helping with this!
<cjwatson> soren: could you deal with getting it into Ubuntu?
<soren> cjwatson: Er.. We should sync it automatically?
<soren> Do we have a debconf delta?
<cjwatson> a gutsy SRU might make sense
<soren> Oh.
 * soren sighs
<cjwatson> then at least affected people could be given a fixed CD image
<soren> Sure. i'll add it to my todo list.
<cjwatson> I agree, for hardy it should just be synced
<cjwatson> I'll see about a Debian upload at some point, though there's also a teletype frontend bug I'd like to clear up
<soren> Mkay. Some time before alpha 2?
<cjwatson> remind me in case I suck
<cjwatson> thanks very much for finding this, I was too close to see the problem
<soren> cjwatson: Always a pleasure. Now I won't be quite as lost if I have to deal with debconf again.
<soren> \o/
<cjwatson> maybe you can draw a diagram for the next guy :)
<cjwatson> did I explain sufficiently how all the bits slot together?
<soren> Honestly, no :)
<soren> Just enough to figure out why this was broken.
<cjwatson> doc/passthrough.txt would be a reasonable thing to read
<soren> cjwatson: Does tasksel use debconf as a frontend somehow?
<cjwatson> "confmodule" maps to your average .config or .postinst, "frontend" is the debconf process that implements both the database and (for non-passthrough) the UI
<cjwatson> soren: oh my, yes
<soren> If so, I think I've got the gist of it.
<cjwatson> tasksel is a debconf confmodule itself
<cjwatson> though an unusually written one
<cjwatson> a debconf application if you like
<soren> Ok.
<soren> Got it.
<cjwatson> though actually, there are two bits
<cjwatson> if you run tasksel in interactive mode, it acts as a debconf confmodule and asks you a multiselect question about which tasks to install
<cjwatson> in the 'tasksel install dns-server' type case, it doesn't start up debconf itself, but runs aptitude under the control of debconf-apt-progress
<cjwatson> and in that case debconf-apt-progress is the debconf confmodule
<soren> Alright.
<cjwatson> so you get debconf (frontend displaying actual UI) --- debconf-apt-progress (confmodule) --- apt-get --- dpkg --- debconf (frontend passing everything through) --- postinst (confmodule)
<soren> Right. Got it.
<cjwatson> dpkg doesn't actually start up debconf directly itself, but that's the conceptual layout
<cjwatson> you really do need paper to figure out the file descriptor plumbing though
<soren> Yeah, I think I got the gist of that, but there certainly details that are a bit opaque still.
<cjwatson> oh, one further wart
<cjwatson> in the installer, it's even more complicated, because the whole thing is running under an existing cdebconf UI
<cjwatson> so in that case debconf-apt-progress is ALSO doing passthrough
<soren> cdebconf is an alternative implementation of the debconf spec, I presume?
<cjwatson> yep
<cjwatson> it has a few deviations, but mostly the same
<cjwatson> mostly things that aren't in the spec ...
 * ogra shudders ...
<cjwatson> this is what makes it possible for packages being installed in the /target chroot to ask questions using the same interface
<cjwatson> and it's how we got rid of the two-stage installer
<ogra> unless you call another debconf in a subsequent chroot insode /target :( then it gets tricky
<cjwatson> ogra: it's not easy, but that *is* what tasksel does
<cjwatson> (indirectly)
<ogra> yeah
<cjwatson> you have to be careful to use a separate database for the inner debconf
<cjwatson> otherwise they clash on the same lock
<ogra> i guess i have to wrap my mind around it again for hardy ... if ltsp goes on -alternate
<soren> cjwatson: Ok, let's agree that I'll remind you of this some time before alpha 2, and you'll remind me about the sru when you upload this. :)
<cjwatson> ogra: did you ever try using debconf-apt-progress?
<ogra> no, i didnt even know about it
<ogra> i tried to get the fd's right
<cjwatson> because it does the database stuff you need to start an inner debconf process - along with a bunch of other stuff
<cjwatson> if you're inside debconf and want to call apt, debconf-apt-progress should normally be involved
<ogra> i'll look at it
<ogra> (currently i have higher prio stuff though)
<cjwatson> at least if you want the installed packages to be able to interact
<cjwatson> ogra: of course, I know about that :)
<ogra> :)
<ogra> crurently what we have is ugly but works ... its all about cosmetics
<cjwatson> aye
<soren> cjwatson: Thanks for the tutorial :)
<cjwatson> soren: any time
<bdmurray> tkamppeter: in regards to bug 153152 the gutsy-proposed package does not fix it - is that correct?
<ubotu> Launchpad bug 153152 in hplip "[Gutsy SRU request] Fax utility not adding files to job." [High,Confirmed] https://launchpad.net/bugs/153152
<tkamppeter> bdmurray, about bug 153152, that is correct, HP's patch generates the file now, but when the generation of the file has completed, hp-sendfax crashes. There is also another bug. I have reported this back to HP.
<ubotu> Launchpad bug 153152 in hplip "[Gutsy SRU request] Fax utility not adding files to job." [High,Confirmed] https://launchpad.net/bugs/153152
<bdmurray> tkamppeter: so verification is no longer needed for that one then?
<tkamppeter> Yes.
<tkamppeter> bdmurray, I have removed the tag now.
<bdmurray> tkamppeter: okay, thanks!
<bpl> sudo apt-get build-dep karm -> E: Build-dependencies for karm could not be satisfied.
<bpl> anybody know how I can get a list of what's missing?
<geser> bpl: is it a versioned dependency?
<bpl> geser: I don't know, that's the problem.  The error message isn't very useful.  How can I find out what build-dependencies cannot be satisfied?
<bpl> Right now I'm trawling through the build-depends line in it's debian/control manually, so I suppose I'll eventually find the problem
<elmo> apt-get -o debug::pkgproblemresolver=1 build-dep blah
<azeem> neato
 * azeem has been feeding those packages to sbuild to get some more info
<bpl> thanks, that found my problem.  Now I'll head over to #kubuntu for more help.
<geser> bpl: sudo apt-get -s build-dep karm works in my hardy chroot
<nxvl_work> is there any way to report bugs for spanish speakers?
<bpl> I'm using gutsy, but I think the problem might be one of my own making, so I'll be quiet until I can confirm that.
<seb128> mdke: hi. The ubuntu layout patch for yelp doesn't apply to the new 2.21 version, could you or don have a look at updating it?
<bpl> thanks all, problem fixed. I apt-get remove'd the conflict (which came from a private repo). Was relatively easy once I knew what the problem was.  I suggest that -o debug::pkgproblemresolver=1 be made default for build-dep or at least added to the man page
<mdke> seb128: thanks for pointing that out. I'll work with Don on that, sure
<seb128> mdke: thank you
<mdomsch> any apt developers around?
<mdomsch> odd apt package version comparison question
<mdomsch>  dpkg --compare-versions a09-1 "<" a09-1
<mdomsch>   returns 0
<mdomsch> yet, apt-get and aptitude repeatedly replaces packages with such versions with another copy of itself
<Kmos> cjwatson: bug 173474
<ubotu> Launchpad bug 173474 in ubuntu "daily live cds not available for powerpc" [Undecided,New] https://launchpad.net/bugs/173474
<azeem> mdomsch: 1. it
<azeem> oops
<mdomsch> azeem, 1.a09 ?
<azeem> mdomsch: 1. it's unclear why you think only apt developers know the answer 2. this is a dpkg question
<mdomsch> azeem, fair enough on both points
<mdomsch> except that dpkg --compare-versions gets it "right"
<mdomsch> which is why I'd think it odd in apt
<ajmitch> mdomsch: is it in a PPA?
<mdomsch> ajmitch, no, it's the Dell BIOS payload debs I've been working on
<mdomsch> firmware-tools and firmware-addon-dell are in a PPA
<ajmitch> ok, because I was going to say that there's a soyuz bug  https://bugs.edge.launchpad.net/soyuz/+bug/165230 about the issue, with the generated package indexes
<ubotu> Launchpad bug 165230 in soyuz "PPA generates an endlessly upgrading package" [Undecided,In progress]
<mdomsch> ah, thanks
<mdomsch> I'm rebuilding all the packages now, with 0.version  if they're version a09 or so, or if they're using the new sane version scheme, 1.3.3 for package version 1.3.3 :-)
<mdomsch> there's a _slight_ chance a system with a bios version a09 would get updated such that the newer version is 1.3
<mdomsch> fwiw, prepending 0. didn't solve it for me
<mdomsch> must be something else
#ubuntu-devel 2007-12-05
<nanley> Hello World! Is it safe to upgrade the hardy kernel to 2.6.24?
<ScottK> nanley: If you want safe, don't run Hardy.
<nanley> lol
<nanley> point taken
 * ScottK is not kidding.
<nanley> well, safe as in the kernel is the same one that will be in alpha 2?
<nanley> or something ready for testing
 * ScottK doesn't know (not running it), but since a lot of kernel stuff is hardware specific, even if I said it worked for me, I don't know what that would really tell you.
<nanley> alrighty =]
 * Hobbsee stabs add & remove programs
<Hobbsee> and apport fails too.  hurrah
<jdong> Hobbsee: but does apport handle its own crashes? :)
<minghua> If it doesn't crash repeatedly, maybe it will.
<wasabi> weird apt-get problem.... dpkg is hanging around defunct for ages after each package.... apt-get is blocking on read(18, ), which is /dev/ptmx
<TheMuso> 0So far, only 8 packages have FTBFS, which is a good sign.
<Hobbsee> surely there should be 0 FTBFS packages?
<TheMuso> Hobbsee: You would hope so, but I haven't investigated the exact reasons yet. I'll get as many cleared as ok building and uploaded as I can, then fix up those that FTBFS.
<slomo> TheMuso: scary how many packages we still have that depend on glib1.2...
<StevenK> slomo: They're fighting for buildd attention, I bet
<TheMuso> slomo: Yes, there are heaps.
<TheMuso> 220 odd source packages that need rebuilding.
<slomo> they should just disappear *shrug* :)
<MacSlow> greetings everybody!
<ion_> Hola
<MacSlow> hi mpt
<mpt> hello MacSlow
<Burgundavia> hey MacSlow, mpt
<MacSlow> hi Burgundavia
<Burgundavia> how goes facebrowser?
<MacSlow> spec is place... now time for research and devel
<mpt> MacSlow, I have a question about Visual Effects
<mpt> I remember back in the 1990s it was a huge advance when OSes got live resizing for windows
<mpt> and with Visual Effects set to "None", windows have live resizing
<mpt> but with the more blingy settings, they don't
<mpt> Any particular reason for that?
<MacSlow> mpt, there was no spec or planning at all for the whole set of settings for compiz-plugins
<MacSlow> mpt, I think to remember that some people replied that window-resizing got "terribly slow" for them
<mpt> oh, ok
<mpt> So live resizing is slower with Compiz than with Metacity?
<MacSlow> mpt, the way the compiz-folks "fixed" it was setting it to this rectangle-mode
<mpt> I see
<MacSlow> mpt, only for some GPUs/drivers
<MacSlow> mpt, e.g. on i915 and i965 I don't see the issues
<MacSlow> mpt, I'm certain that the issue people complain about regarding live-resizing windows under compiz will be a thing of the past once the new DRI2 and other Xorg-related things are fully implemented.
<MacSlow> mpt, it will e.g. also provide "zero copy" texture-from-pixmap
<mpt> ok
<MacSlow> mpt, there are also some ideas floatint around to speed up live-resize under compiz before those DRI2/Xorg-related pieces are in place... one of them is to allocate larger textures for holding the redirected windows, thus a texture does not have to be reallocated if a window is resized, which in turn speeds up the resizing-process under compiz
<MacSlow> hi pitti
<lool> Hi MacSlow
<pitti> Good morning
<pitti> hey MacSlow, hi lool
<MacSlow> Salut lool
<lool> keescook: Congrats!
<sleepster> how do I contribute to the awesome project known as Ubuntu
<pochu> sleepster: it depends on what you want to do :) http://www.ubuntu.com/community/participate
<dholbach> good morning
<gaspa> you too...<ronf>
<ion_> good Chuck Norris
<gaspa> question: can I invalid a bug, even if i'm not a member of anything in particular?(bugsquad or whatelse...)
<sleepster> pochu I want to do everything
<sleepster> pochu I want to make this the best dang OS in the WORLD
<sleepster> where do I sign up?
<pochu> no need to sign up anywhere, just do it ;-)
<Fujitsu> gaspa: Yes.
<gaspa> Fujitsu: ok, thanks.
<dholbach> hey mvo, hey seb128
<seb128> good morning Daniel
<mvo> hey dholbach!
<mvo> hey seb128
<sleepster> how do I get involved with a project?
<sleepster> I read throught he wiki
<sleepster> s/he/the
<seb128> mvo: I didn't do the vte merge so if you want to work on it today ;-)
<seb128> sleepster: do you mean a project in Ubuntu?
<mvo> seb128: sure, I can do it today
 * seb128 hugs mvo
<pitti> good morning mvo!
 * pitti hugs The"âª I shot the buildd! â«"Muso
<seb128> TheMuso: wouldn't it make sense to use some delay between uploads for such transitions?
 * persia wonders why
<seb128> persia: why what?
<persia> Why delay between uploads for a transition.
<seb128> to not overload buildds and let a chance to normal uploads to build
<pitti> seb128: well, most of the stuff is universe, so main packages will be built first anyway
<seb128> pitti: right but still
<pitti> it's more a question of mirror load
<seb128> pitti: I though it was good practice to not upload hundred in packages in a row
<pitti> right, it still is
<pitti> speaking of mirror load, I moved OO.o to gutsy-updates yesterday; the DC will love me, I'm sure
<seb128> pitti: do you know if there is any hardy language pack update scheduled?
<pitti> seb128: in fact the export was started last week, let me check
<pitti> https://translations.edge.launchpad.net/ubuntu/hardy/+language-packs
<pitti> nothing yet
<seb128> oki
<LaserJock> pitti: does language-pack-gnome-*-base get updated in -updates?
<pitti> LaserJock: -base is generally stable in a release
<pitti> LaserJock: we did a refreshing in dapper because the update packages got too big
<pitti> but it's seldom
<LaserJock> ok, so if there are updates they should go in language-pack-gnome-* ?
<pitti> right
 * pitti puts a strawberry and a piece of chocolate on top of bug 163794 for mvo :)
<LaserJock> pitti: do they install to the same place? doesn't that create a conflict?
<ubotu> Launchpad bug 163794 in tzdata "New timezone data 2007j" [Undecided,Fix committed] https://launchpad.net/bugs/163794
<pitti> LaserJock: they do, that's why they Replace: each other
 * mvo hugs pitti
<LaserJock> ah
<LaserJock> pitti: I'm trying to track down why gcompris was not included in the latest lang pack updates
<pitti> hm, but it was in the final gutsy ones?
<LaserJock> yes
<LaserJock> I'm told it's in -base but not in the latest updates
<pitti> ./language-pack-gnome-sv/data/sv/LC_MESSAGES/gcompris.po
<pitti> hm, that's the only one
<pitti> (in -updates)
 * pitti does the magic dance to summon carlos
<LaserJock> hmm
<LaserJock> I gave carlos the .pot and I think he said it should be included in the next update
<\sh> keescook, jdstrand : bug #164501 , gutsy fixes attached...ready for review...thx :)
<ubotu> Launchpad bug 164501 in wireshark "more security issues with wireshark from 0.99.6 down to ..." [Undecided,In progress] https://launchpad.net/bugs/164501
<seb128> pitti: carlos is on holidays for the month I think
<TheMuso> seb128, pitti: Point taken. They were done in batches, 5 or so minutes appart, once I had confirmed that the packages had built. I still have more left, and I will make an effort to stagger them moreso from now on.
<seb128> TheMuso: well, some minutes will make no difference
<TheMuso> seb128: Fair enough, as I said, I'll stagger what I have left moreso than what I tried to do earlier.
<seb128> thanks
<LaserJock> pitti: well, I guess I'll email the Rosetta admins and make sure we can make the next lang pack update
<pitti> LaserJock: right
<LaserJock> I'll make sure to check the PPA language-pack-gnome-* earlier ;-)
<pitti> speaking of which...
 * pitti reenables the dailies
 * LaserJock apologizes to upstream again
<mvo> pitti: #163794 is done
 * pitti hugs mvo
<seb128> bug #163794
<ubotu> Launchpad bug 163794 in tzdata "New timezone data 2007j" [Undecided,Fix committed] https://launchpad.net/bugs/163794
<ogra> pitti, are you caring for the pulse transition ? and are you aware that flash wont work with pulse ?
<pitti> ogra: transition> ted will do the remainign desktop bits (which mixers to install by default, etc.)
<pitti> ogra: flash> no, I'm not; can you please tell my flash plugin that it isn't supposed to work?
<ogra> we'll need libflashsupport if we want to use it as default
<pitti> ogra: IOW how do you mean?
<kagou> Hi
<ogra> pitti, http://www.pulseaudio.org/ticket/43
<ogra> there is a lib that fixes the issue, but its very badly packaged upstream and links against lgpl and libssl ... crimsun has a branch linking against tls we should put in the distro https://code.edge.launchpad.net/libflashsupport-pulse
<pitti> ogra: doesn't it work for you? flashplugin-nonfree works like a charm for me
<ogra> pitti, not on ltsp where we use pulse transport ...
<ogra> i'm assuming with pulse as default for the whole desktop the prob will be similar
<pitti> ah, then it probably works for me because I don't play anythign over pulse while watching a youtube video, or so
<pitti> ogra: can you add that to https://wiki.ubuntu.com/DesktopTeam/Specs/CleanupAudioJumble ?
<ogra> i'm not sure, its probably only netwrok transport related (the bug doesnt say much about that))
<ogra> yup, adding
<ogra> i'll package the lib anyway, just thought i should point you guys to it
<pitti> ogra: thanks
 * TheMuso is actually looking to use padsp to get espeak using portaudio v19 to work via pulse. Initial testing looks good, but I need to play some more.
<TheMuso> ogra: Is setting up LTSP for hardy different to how its done for gutsy et al?
<ogra> TheMuso, nope
<TheMuso> ogra: Great, thanks.
<TheMuso> This release, I *REALLY* want speech for that environment to work.
<ogra> TheMuso, sudo apt-get install ltsp-server ltsp-server-standalone && sudo ltsp-build-client
<ogra> well, it only needs to use the virtual alsa device we have in the users session ...
<TheMuso> ogra: And what needs to happen on the client side?
<ogra> nothing
<TheMuso> Ok.
<ogra> ltsp-build-client sets up everything for you
<ogra> the client just needs to PXE or etherboot from the network
<TheMuso> Ok thanks.
 * TheMuso will obviously have to take down his DHCP server temporarily for this to work, unless theres a way for it to play nice with an existing server
<ogra> if i find the time i'll put up a wikipage how to set up a virtualbox thinclient with sound so you can test (indeed its hard to find out if the sound really comes from virtualbox there :) )
<TheMuso> ogra: Thats why I'd rather use real hardware.
<ogra> yea, me too, but i travel a lot and there virtalbox comes in handy ... ;)
<TheMuso> Yep understandable.
<ogra> and a thin client in VB doesnt take much (no disk involved)
<TheMuso> Yep.
<TheMuso> ogra: SO does ltsp set up its own DHCP? If so, can that be disabled and adjusted to use an existing server? I'd rather not take down my home network DHCP server if I can help it.
<ogra> yup, it can
<TheMuso> Ok thanks.
<pitti> ogra: hm, maybe set up the mixer in the VB instance so that it only outputs to the left channel or so? :)
<ogra> to make it easier, change my above command to:
<ogra> sudo apt-get install ltsp-server  libasound2-plugins ltspfs openssh-server nbd-server && sudo ltsp-build-client :)
<ogra> that will avoid dhcpd to be installed at all
<ogra> but indeed you need some manual work on the existing dhcp server then
<pitti> ogra: but then you certainly have to set up your existing dhcp server to have the tftp?
<ogra> no, you only need a next-server directive to point to your ltsp server
<ogra> so the clients pull their tftp stuff from there
<pitti> oh, handy
<TheMuso> ogra: Ok great. What is this virtual alsa device you create, how is it created, and I assume all pulse utilities will see the pulse server anyway and just work?
<ogra> thats actually all you need nowadays, since we dont use nfs anymore you dont even need rootpath set :)
<Fujitsu> ogra: Oh, much nicer!
<Chipzz> ogra: what do you uuse then?
<ogra> TheMuso, pulse runs on the client listening for connections from the server ... in the users session we a) set PULSE_SERVER to point to the client on login and b) run asoundconf set-pulseaudio which creates a virtual alsa device for that etwork tunnel ... usually apps only need to make use of this alsa device then
<TheMuso> Right.
<ogra> Chipzz, nbd+squashfs+unionfs :) imagine a liveCD netbooting :)
<Chipzz> oh :)
<ogra> th only prob here is that you actually need to reboot all clients if you make changes to the image .... so we keep nfs as an option, but the default is ndb ... which makes ltp booting 10x faster (literally)
<ogra> *ltsp
<Fujitsu> ogra: nbd == network block device?
<ogra> Fujitsu, yep
<Fujitsu> I haven't tried LTSP recently... I probably should soon.
<ogra> yeah :)
<ogra> its just in a massive change though since we make the code ready for fedora upstream ... so things might break along the way to hardy ...
<Fujitsu> Is the new stuff in Gutsy?
<ogra> yep
<soren> Phew.. I think the dpkg merge is done now.
 * soren wipes sweat off of his brow
<StevenK> Heh
<Fujitsu> soren: Yay!
<Amaranth> eep
<Amaranth> remind me to not upgrade dpkg for a couple days ;)
 * pitti hugs soren
<pitti> soren: how bad is the remaining diff?
<pitti> soren: debian bug #308285 mentions triggers, but doesn't point to iwj's patch
<ubotu> Debian bug 308285 in dpkg "Implement triggers to allow running ldconfig" [Wishlist,Open] http://bugs.debian.org/308285
<soren> pitti: Not all that bad now. A lot of this merge was formatting changes that I needed to inspect to see if they snuck some other bits in that way.
<pitti> (nor in any of the 5 duplicates)
<soren> pitti: It's been discussed a bit on the dpkg-dev list. I don't know what the status is, though.
<soren> pitti: I honestly don't know what's keeping it back.
<pitti> http://www.mail-archive.com/debian-dpkg@lists.debian.org/msg11922.html
<pitti> is the start of the thread, ah
<soren> Yeah. Don't waste your time reading all of it. :)
<soren> It branches off into a discussion about whether git is clever or not. :)
<pitti> yeah, I noticed
<pitti> but at least the guys are well aware of its existence, and there were a lot of "I want it, too" replies :)
<soren> pitti: Right. I was kind of hoping they'd adopt it before I had to do the merge, but no such luck. With my luck, they'll probably upload a new version tomorrow with trigger support. :(
<StevenK> ... that doesn't use iwj's implementation
<pitti> soren: still better than uploading in half a year :)
 * StevenK watches soren run screaming
<soren> pitti: point :)
<pitti> pedro_: do you have some time today to verify bug 163794? it's rather urgent
<ubotu> Launchpad bug 163794 in tzdata "New timezone data 2007j" [Undecided,Fix committed] https://launchpad.net/bugs/163794
<pitti> pedro_: sorry, wrong bug; I mean bug 116193
<ubotu> Launchpad bug 116193 in tzdata "error upgrading tzdata_2007e to tzdata_2007f" [Medium,Fix committed] https://launchpad.net/bugs/116193
<pedro_> pitti: sure i'll do it now
<pitti> pedro_: thanks a lot
<pedro_> pitti: in the test case it say have a clean feisty and then upgrade to current gutsy updates is that correct?
<ogra> ArneGoetje, ping
<pitti> pedro_: you don't need to upgrade the entire distro; merely upgrading tzdata to gutsy final or -proposed is sufficient
<pitti> pedro_: (i. e. to gutsy final to reproduce the bug, and feisty->gutsy-proposed to check the fix)
<pedro_> ok cool
<pitti> pedro_: unfortunately feisty->gutsy-final will ruin /etc/timezone, so you have to reconfigure it when reverting to feisty version for the second test
<pedro_> pitti: ok, thanks you
<geser> pitti: please give-back: urca unison. Thanks.
<pitti> geser: done
<pedro_> pitti: we're done!
<pedro_> verification done
<pitti> pedro_: rock, thanks!
<pedro_> you're welcome :-)
 * Hobbsee waves
<soren> Hi, Hobbsee!
<Hobbsee> hey soren!  how's it going?
<soren> Better now that I (think I) am done merging dpkg.
<seb128> hey Hobbsee ;-)
<Hobbsee> soren: hah.  how'd you get stuck with it?  TIL principle?
<Hobbsee> hey again seb128 :)
<soren> Hobbsee: I honestly don't know.
<pitti> Hobbsee: that applies from now on :)
<Hobbsee> heya pitti!
<Hobbsee> pitti: heh
<soren> Hobbsee: Ian TIL, but he's not around.
<Hobbsee> ahhh
<seb128> TheMuso: there is a new at-spi available, it has been uploaded to debian experimental if you want to merge the new version
<seb128> TheMuso: the only ubuntu change has been commited to the debian svn too so it'll be syncable after the next update
<TheMuso> seb128: I knew about the at-spi release, I'm on gnome-announce now. I filed a bug with the bits needed for upload, but I'll merge with Debian and adjust the bug accordingly.
<seb128> TheMuso: ok, thanks
<seb128> TheMuso: no need to bother
<seb128> TheMuso: if you already did the update I'll sponsor this one, there is no debian change
<TheMuso> seb128: Ok.
<highvoltage> anyone know who maintains ubuntustats.com?
<Hobbsee> oh dear, they're in trouble
<Fujitsu> Haha.
<elkbuntu> highvoltage, see info in footer at: http://209.85.173.104/search?q=cache:VCatX8TNPdsJ:bugs.ubuntustats.com/+contact+site:ubuntustats.com&hl=en&ct=clnk&cd=1&gl=au&client=firefox-a
 * elkbuntu <3's google caching :)
<Hobbsee> mvo: any plans to make command-not-found work for zsh?
<Hobbsee> (and why doesn't it already?)
<dholbach> highvoltage: beuno is here :)
 * Hobbsee pokes infinity with a large stick
 * Hobbsee hopes for some l-u-m soon
<\sh> lol
 * Hobbsee would like some wifi
<pitti> Riddell: oh, did you NEW the linux binaries?
<pitti> Riddell: they FTBFSed on most arches, so I'd rather have rejected them
<pitti> (just in case something is wrong in e. g. linux-libc-dev)
<Riddell> pitti: mm, which ones?
<pitti> seb128: weird, your devhelp upload just seems to work; when I built it locally with that change I got a segfault, which is why I didn't upload it
<pitti> Riddell: https://launchpad.net/ubuntu/+source/linux/2.6.24-1.1
<seb128> pitti: dunno why you had a segfault, it was working correctly for me so I uploaded
<pitti> yeah, and the debs from the archive work fine as well
<pitti> *shrug*
<Riddell> pitti: I'm pretty sure that wasn't me
 * Hobbsee looks innocent
<pitti> Riddell: ah, ok
<pitti> seb128: "Who always understands what he is doing stays below his capabilities" :)
<StevenK> pitti: I prefer the other side of that quote.
<seb128> I didn't new linux
<Riddell> it was slangasek's archive day before mine, possibly him
<pitti> seb128: I alluded to me not understanding the devhelp crash, not NEWing
<soren> slangasek has archive days? Which day is that?
<pitti> soren: Monday
<seb128> you guys have been doing some good job, NEW was empty yesterday evening
<Hobbsee> all of 'em
<Hobbsee> still is.  gotta upload more crack, i think
<soren> pitti: Mithrandir doesn't have archive days, then?
 * pitti restrains Hobbsee; it was hard hard work to get it like that :)
<pitti> soren: not any more
<seb128> pitti: I know, I was just pointing it because I though I might be next on the list of people who could have accepted it ;-)
 * Hobbsee tickles pitti
<soren> pitti: Ok. I didn't know.
<Riddell> seb128: when I have an archive day, I don't stop until the job is done :)
<pitti> seb128: it's all GTK's fault anyway, and so is the linux FTBFS!
<seb128> doh
<mvo> Hobbsee: I don't use zsh, the readme has some hints on how to make it work. yeah, we should do that by default I guess
<seb128> ;-)
<Riddell> soren: Mithrandir hasn't done regular archive days since mobile started taking all his time, as far as I know
<Hobbsee> mvo: right, will look then
<pitti> Riddell: http://people.ubuntu.com/~ubuntu-archive/testing/hardy_outdate.txt KTHXBYE :)
<soren> Riddell: Oh. I should stop bothering him about that sort of thing then :)
<Hobbsee> soren: it's him you want to bug about givebacks
 * pitti nudges soren to upload dpkg to resolve some of the depwaits on hardy_outdate.txt
<soren> pitti: Dude, that shit is scary.
<pitti> soren: (just joking)
<Hobbsee> soren: so how about the cdbs merge, for some light relief?
<StevenK> "Light"
<soren> pitti: I'm pushing it to my ppa in a few minutes.
<pitti> Hobbsee: but your long pointy stick is now long enough to reach to the buildd's retry knobs, too
<Hobbsee> pitti: indeed :P
<Hobbsee> pitti: people seem to know this far too well
<pitti> cdbs merge? isn't that mine?
<Hobbsee> pitti: did you merge it first for hardy?
<pitti> ages ago AFAIK
<Hobbsee> oh goody
<StevenK> cdbs was like the first thing uploaded after the toolchain
<Hobbsee> geser: was supposed to.  *shakes fist*
<soren> Hobbsee: I've got plenty of merges on my list already, thank you very much. :)
<pitti> http://merges.ubuntu.com/c/cdbs -> 404
<Hobbsee> pitti: well, thankyou.  that means i can continue to ignore the idea of cdbs and merging :)
<pitti> Hobbsee: it's one of my pet packages and it's rather toolchainish, so it went in very early
<Hobbsee> excellent!  next time, i'll make you sponsor the changes :P
<Hobbsee> pitti: oh yes, that's right, because i called you out on the changelog.
<pitti> Hobbsee: did that happen? I didn't see anything in bzr
<Hobbsee> pitti: when did it go in bzr?
<DktrKranz> pitti, could you please give-back cdd on hardy?
 * Hobbsee did the sponsorship in late feisty
<Hobbsee> DktrKranz: i'll do it
<Hobbsee> DktrKranz: given back
<DktrKranz> Hobbsee, thanks
<pitti> Hobbsee: erm, dunno, must be years
<Hobbsee> pitti: then there are 2 changes that i have never merged in then, sorry :)
<Hobbsee> pitti: does it not have a vcs link, or did i ignore it?
<pitti> $ asrc cdbs|grep Bzr
<pitti> Vcs-Bzr: https://code.launchpad.net/~ubuntu-core-dev/cdbs/ubuntu
<Hobbsee> hmmm
 * Hobbsee wonders why she didn't see this
<Hobbsee> pitti: why asrc, btw?
<soren> pitti: asrc == apt-cache showsrc ?
<pitti> right, sorry
 * Hobbsee uses showsrc
 * pitti believes in Huffmann encoding for often-used aliases
 * Hobbsee wonders how long it's going to take before she's learned that the rmadison aliases have changed
<StevenK> pitti: Take almost every letter until every person needs to ask what it expands to?
<Hobbsee> doesn't help that i occasionally have to do stuff on gutsy, where it's reversed
<StevenK> How did rmadison change?
<Hobbsee> the default distro
<pitti> StevenK: I don't normally paste them in alias form in IRC, was just a mistake
 * Hobbsee was using rmadison and urmadison
<Hobbsee> you should know, you merged it.
<StevenK> I did not.
<StevenK> soren did
<sladen> I think irssi nick completion does this;  it expands a substr to the most used version of the complete nick.  However, that isn't as predicatable (for the human) as pure maximum prefix expansions
<StevenK> I just changed the default distro since cjwatson said it probably should
<soren> Hobbsee: Ubuntu was the default already. I just updated rmadison --help to actually show that that was the case.
<Hobbsee> StevenK: it's your name on the changelog.  you cant blame soren, i'm afriad.
<sladen> and Ctrl-R in bash already gets you more recent, most unique substr completition
<Hobbsee>   * Change the default URL parameter of rmadison to be ubuntu. The old
<Hobbsee>     behaviour can be used by 'rmadison -u debian'.
<Hobbsee>  -- Steve Kowalik <stevenk@ubuntu.com>  Sun, 11 Nov 2007 08:14:51 +1100
<soren> Hobbsee: Oh, it's that recent? I thought I had gone mad!
<StevenK> Bwahaha
<sladen> StevenK/cjwatson: if you fixed it, can you mark the bug report as closed... bug #152424
<ubotu> Launchpad bug 152424 in devscripts "rmadision should default to 'ubuntu' URL when under Ubuntu." [Wishlist,New] https://launchpad.net/bugs/152424
<Hobbsee> soren: it's changed in hardy and gutsy
<Hobbsee> er, between hardy and gutsy
<Hobbsee> so gutsy uses old behaviour, hardy uses changed.
<StevenK> sladen: Aye, thanks
<soren> Hobbsee: I see.
 * soren curses dholbach for not telling him about listadmin a *long* time ago.
<pitti> listadmin FTW!
<Hobbsee> soren: *g*
<soren> You all knew?
<soren> And noone told me?
<soren> I hate you all.
<StevenK> Right.
<Hobbsee> cjwatson: enlightened me when giving me access to ubuntu-devel
<StevenK> soren: Kiss kiss
 * Hobbsee did u-u-s all by hand though, for ages
 * soren feels Hobbsee's pain
 * Hobbsee would prefer not to see StevenK and soren kissing, thanks.
 * Hobbsee covers eyes
 * sladen does u-u-e-n-c-o-d-e- by hand though...
<StevenK> Hobbsee: Did what? It was what, one message every two weeks?
<Hobbsee> StevenK: before you sanitized the filter
<StevenK> Oh on revu
<StevenK> Yeah well
<StevenK> sladen: bug 152424 nailed shut, thanks
<ubotu> Launchpad bug 152424 in devscripts "rmadision should default to 'ubuntu' URL when under Ubuntu." [Wishlist,Fix released] https://launchpad.net/bugs/152424
<Treenaks> StevenK: now try jpeg in your head
<StevenK> Treenaks: u-u-s, ubuntu-universe-sponsors, smartalec
<Treenaks> StevenK: uhr, I meant to say sladen:
<Hobbsee> StevenK: just steal his camera.
<Treenaks> StevenK: pressed tab too often
<Treenaks> Hobbsee: Ha, still scared of that? :)
<Hobbsee> Treenaks: cameras are evil!
 * soren goes to lunch
 * Hobbsee is not photogenic, and therefore hates all cameras.
 * StevenK isn't either
<Hobbsee> unless, somehow, the sky falls in, and they manage to take decent pictures, whcih don't make me look like i'm on drugs or something.
<StevenK> So I switched sides of the camera, I like them better that way
<Treenaks> StevenK: why do you think I'm behind the camera :)
 * StevenK grins
<sladen> StevenK: fixed in 2.10.10ubuntu1, *documented* in 2.10.10ubuntu2  :-P
<StevenK> Actually, it was changed in 2.10.10ubuntu2
<sladen> maybe the changelog is lying;  I could ask the person who did the update
<seb128> TheMuso: could you try to include the LP number in the changelog so the bugs are closed on upload?
<seb128> TheMuso: I did sponsor your at-spi and gnome-orca updates, thanks for the work on those
<asac> ogra: Re: "certificate exception workflow in ffox 3" ... its now like this: http://people.ubuntu.com/~asac/ogra/
 * Hobbsee waves to asac
<asac> hi Hobbsee !!
<Hobbsee> asac: any chance of getting firefox addons upgraded at some point, so it works with ff3?
<ogra> asac, is there a chance to skip shot 3 and 4 ? like it was before ?
<asac> ogra: no
<asac> ogra: imo it does a good job
<asac> ogra: its not just "click through" anymore.
<asac> Hobbsee: yes ... I wanted to sort out xulrunner and the gecko embedders first
<Hobbsee> asac: ahhh, okay.  cool.
<pitti> well, the clicking-through just becomes more lengthy and frustrating now :)
<asac> Hobbsee: of course it depends on extension authors supporting ffox 3
<Hobbsee> asac: well, of course.  most of them appear to work (more or less) fine when forced.
<Hobbsee> the extensions, that is, not the authors.
<ogra> asac, id the url prefilled in the dalog ?
<ogra> *dialog
<asac> ogra: yes
<stdin> mvo: ping
<ogra> asac, perfect then :)
<asac> ogra: good.
<asac> pitti: hmmm ... remember that you don't add exceptions every day ... so making it a bit harder isn't that bad on its own. imo this solution does a good job in getting users attention while not getting in their way
<pitti> asac: I agree
<pitti> asac: the root problem is still that people got used to the fact of bad certificates
<pitti> asac: however, I see a huge benefit in making a big fuss if a cert *changes*
<pitti> accepting the initial one should be much less painful than overiding an unverifieable changed one
<asac> haven't tested what happens in that case
<mvo> stdin: hello
<stdin> mvo: hi, can you take a look at bug #151005 in compiz for me, it's been bugging kde users for a while
<ubotu> Launchpad bug 151005 in compiz "Compiz should use kwin as fallback in KDE" [Low,Confirmed] https://launchpad.net/bugs/151005
<Treenaks> pitti: well, sites change keys all the time.. I wouldn't want a pop-up every year for ssl sites I go to often :)
<mvo> stdin: oh, yeah - this one. do you want this is gutsy? or only in hardy? are you familar what needs to be done to make compiz work on kde out of the box? I would like to suport kde better, but lack knownledge about it
<pitti> Treenaks: well, but you should want it
<pitti> Treenaks: sites which don't have a trusted-path SSL key are bad enough, but if they change their key every other day it's completely pointless
<Hobbsee> mvo: what do you need to konw?
<stdin> mvo: well, for that bug it should work in both, it's just changing the /usr/bin/compiz script to choose kwin if metacity isn't there
<mvo> Hobbsee: how to change the default window manager in the kde session for a start :)
<stdin> mvo: as for making compiz support kde properly, that's a bit harder :p
<pitti> but right now Firefox bothers me everytime with certs I already ack'ed a thousand times; if it would stop doing that and just cry out if it actually changed, that would be a huge improvement IMHO
<mvo> stdin: right
<Hobbsee> mvo: as in, to default to compiz?
<mvo> Hobbsee: yes. I would like to have it so that if you install e.g. compiz-kde (or some other package that is not installed by default) the default kde window manager is compiz
<highvoltage> elkbuntu: oh, cool
<stdin> making kde choose compiz over kde would involve setting $KDEWM somewhere when startkde is called
<stdin> *over kwin
<Hobbsee> stdin: does it call it in startkde, or does it call it from kdm?
<mvo> odes kdm run startkde?
<Hobbsee> wait a sec
 * Hobbsee looks at the kde4 versions
<Hobbsee> Exec=/usr/lib/kde4/bin/startkde
<stdin> Hobbsee: afaik, kdm runs startkde "TryExec=/usr/bin/startkde" /usr/share/xsessions/kde.desktop
<Hobbsee> yeah, as above :)
<Hobbsee> mvo: right, so yes, it's startkde
<mvo> aha, nice. thanks
<stdin> we could also check for $KDE_FULL_SESSION in the compiz script to always choose kdm as fallback in kde sessions
<Hobbsee> #   For $KDE_FULL_SESSION:
<Hobbsee> #     if test -n "$KDE_FULL_SESSION"; then ... whatever
<Hobbsee> looks doable
<stdin> yep, that's my thinking
<Hobbsee> bingo.
<Hobbsee> # if the KDEWM environment variable has been set, then it will be used as KDE's
<Hobbsee> # window manager instead of kwin.
<stdin> the way I did it in the patch was to say if matacity doesn't exist then use kwin, but that ^ is a better approach
<Hobbsee> so, there you go, check if compiz does, if it does, export KDEWM in startkde
<Hobbsee> otherwise, leave it as is.  problem solved.
<Hobbsee> mvo: so we'll have a working compiz in kde by noon?  :)
<Hobbsee> stdin: i presume that wouldnt' cover someone who had kde and gnome, where compiz failed.
<stdin> Hobbsee: the way my patch from the bug works it chooses kwin if it can't find metacity (not great if you have both and are in a kde session), but if you check for $KDE_FULL_SESSION then you can tell if they are in KDE or not
<Hobbsee> stdin: hmmm.  is it guarenteed to be running the full session, whenever starting kde via startkde?
<stdin> startkde sets that variable, so if startkde is ran then it'll be set
<Hobbsee> right
<stdin> if you start kde manually "kwin & kdesktop & kicker..." then you can clean up your own mess :p
<Hobbsee> yeah well
<Hobbsee> you have to be kinda desperate to do that
<Riddell> mvo: you can add export KDEWM at the top of startkde or in /etc/X11/Xsession.d/foo
<Hobbsee> totem + hardy != love.
<seb128> Hobbsee: why?
<ogra> Hobbsee, i dont think thats totems fault .. rather the gstreamer codecs
 * ogra has some probs as well with rhythbox here
<ogra> rhythmbox
<Hobbsee> even with metacity, it occasionally jsut freezes X entirely.
<ogra> oh, but i have 270 pending updates ... :)
 * ogra updates
<Hobbsee> it may well still be -intel, which does have a tendancy to freez
<Hobbsee> e
<ogra> bah, n-m is a liar ... it were actually 320 packages
<ogra> s/n-m/u-m/
<soren> ogra: Everything gstreamer related has been broken on my system too. After yesterday's updates, all is back in working order.
<ogra> ah, great
 * ogra hopes then he can listen to weenradio again after the upgrade :)
<soren> ...both alsa and gstreamer got updated, so I didn't know who to hug :)
<ogra> this oldie station we ship with RB gets boring over time :)
<ogra> "classic rock" sorry :)
<soren> Heh :)
<ogra> even though it has intresting suggestions for the next canonijam i think :)
<soren> Either Exaile or Listen has a fairly long list of stations, some of which are almost half decent.
<ogra> ah, well, i'm somewhat stuck to my favorite :) but that usues mp3 streaming exclusively ...
 * pitti discovers that hardy's RB now shows magnatune and jamendo music shops
<soren> pitti: I've never looked into that. Does it have music you could buy at your local music dealer, or is it more undergroundy kind of stuff?
 * ogra discovered that as well today but didnt look through the titles
<pitti> soren: nothing in the list looks very familiar to me
<pitti> I just browsed through magnatune
<ogra> soren, just try it
<soren> pitti: That could be both good and bad. :)
<pitti> cool, you can just click on it and listen, and if I want I can click the 'buy' button
<ogra> oh you can actually listen for free ?
<ogra> nice
<ogra> i didnt click anything ...
<soren> pitti: What does it give you extra if you buy it?
<ogra> soren, keep it on your disk ?
<pitti> soren: you don't have the "magnatune blabla" ads at the end of each song, apparently
<soren> Oh.
<pitti> and mental peace, too
<pitti> maybe better quality, too, I don't know
<pitti> soren: I just tried it for about 60 seconds :)
<soren> pitti: That makes you the expert :)
<ogra> heh
<soren> "Magnatune - We are not evil"
<soren> That's reassuring.
<pitti> wow, you can select the price yourself
<ogra> cool
 * pitti discovers some blues/country which actually sounds quite nice
 * ogra looks for "canonical all stars" or canonijam ...
 * pitti thinks that THIS is a good way to motivate me to spend 10 bucks
<ogra> hmm
<pitti> ogra: we need to add the Canonical music shop for that :)
<ogra> nothing yet ... i guess our marketing didnt have the right idea yet :)
<ogra> ah, indeed
<ogra> it will become part of shop.ubuntu-com :)
<ogra> (lets walk in apples footprints :P )
<\sh> pitti, jamendo is doesn't have this advert stuff...and ogg is nice to have :) CC lic music, too
<pitti> \sh: I just bought an album from Magnatune, downloading now (I got .ogg, too)
<pitti> \sh: right, just browsing that; but it's a different platform
<pitti> i. e. distributing free music for promotion instead of selling albums
<\sh> pitti, jepp...but it has my favorite songs (jamendo://pornophonique , c64+gameboy+guitar+vocals, germany ... cool stuff...)
<pitti> ah, Jamendo has a 'donate to artist' button :)
<\sh> pitti, and you will get a "thx for your cheers" from artists too :)
<ogra> hmm, thats funny, why did u-m forcefully install nfs-kernel-server during the upgrade just to tell me it will remove it after the upgrade
<ogra> grrr ... and leave portmap behind
<ogra> gah, apport is noisy on reboots
<ogra> asks the same question about 5 times for every app that was open when u-m told me to reboot
<geser> Hobbsee: what was I supposed to do?
<Hobbsee> geser: merge cdbs, but pitti beat you to it
<geser> why should I merge cdbs?
<pitti> MoM clearly assigned it to me, so I didn't make any effort of contacting anyone else
<geser> Hobbsee: I touched scons but not cdbs
<geser> scons is waiting on the next upstream release
<Hobbsee> geser: oh, scons.  whoops
<Hobbsee> pitti: out of the block of evil packages with similar names....
<broonie> scons can be updated now.
<pitti> lol
<broonie> I got fed up waiting for upstream and dumped a snapshot into debian unstable on Monday.
<geser> broonie: is it suitable for a merge or sync?
<broonie> Should be.
<Hobbsee> pitti: where's the dunce cap?
 * Hobbsee can't find it
<broonie> It at least resolves the problem with things that use Configure().
<Hobbsee> pitti: actually, it was the "list of packages that i don't want to do uploads for again"
<Hobbsee> which include things like apt, dpkg, scons, cdbs...
<StevenK> Hobbsee: Ah, the "I feel dirty every time I touch this package" list?
<Hobbsee> StevenK: that's the one
 * StevenK has one of those, too
<ogra> uuuh, ff-3.0 now uses the same icon as ff-2.0 ... how confusing if you have them both
 * geser will investigate the scons merge and let Hobbsee sponsor it :)
<Hobbsee> dream on.
<StevenK> geser: If packages are on that list, we don't sponsor them either
<Hobbsee> i don't even remember what the original one was - or why i ended up sponsoring it
<Hobbsee> geser: or make broonie take the changes if appropriate
<broonie> The change you've got is a workaround for an issue which nobody except launchpad buildds is likely to run into.
<broonie> I'd rather see a proper fix done upstream for it, TBH.
<slangasek> Riddell, pitti: heh, no, I didn't NEW process linux
<pitti> slangasek: good morning
<slangasek> the only NEW stuff I got through was some KDE universe stuff
<slangasek> pitti: morning
<pitti> well, not a biggie now, it doesn't matter much except for linux-libc-dev
<Riddell> it's a mystery then
<wasabi> slangasek, latest samba update broke,    adduser: The user `ISI\jhaltom' does not exist.
<wasabi> No idea why it cares about me. ;)
<wasabi> Ahh.
<wasabi> I see. Ubuntu specific patch.
<wasabi> Funny. Since Winbind is stopped when this is running, it can't resolve me. :0
<wasabi> Guess a better solution would be to not use adduser... or provide adduser some sort of 'don't check' swithc.
<slangasek> wasabi: hrm, which Ubuntu-specific patch?
<wasabi> Adding sysadmin to something
<wasabi> hold on
<slangasek> oh
<slangasek> to the sambashare group
<cjwatson> pitti: I processed linux once alpha-1 was safely out; I think it's important to get boot testing of the new kernel as soon as possible, even if there are some temporary problems
<wasabi> Yeah, that.
<cjwatson> since we'd like to be able to make it the default in hardy over the next few days
<slangasek> yeah, "don't use adduser" isn't really the right answer AFAICS
<wasabi> Sorry, right as I was typing that out I got a phone call. My mind melted.
<wasabi> Heh. Something feels totally wrong about killing Winbind in the middle of an upgrade while the user is using his desktop, too.
<wasabi> Maybe that should be adjusted so the time winbind is gone is minimized.
<wasabi> "You have no name!"
<slangasek> well, all the solutions for minimizing the downtime of daemons during upgrade are fairly kludgy wrt maintainer script interaction
<wasabi> I really dislike how if the winbind upgrade fails, my desktop becomes unusable. =(
<wasabi> Since it's stopped. No new apps can launch.
<slangasek> er, that's an odd failure mode?
<wasabi> Using nss_winbind. Apps taht try to find ~ don't tend to handle it well when you don't exist.
<slangasek> and $HOME isn't set?
<wasabi> It's set. Not everything uses it in my experience.
<wasabi> Hehe. sudo stops working too, so you can't even fix it.
<wasabi> Just saying, Winbind has become a very important member of the running desktop. It should be handled with care.
<wasabi> Much like dbus.
<soren> Not using adduser doesn't smell right to me either, but a --force-something option might make sense.
<wasabi> I might be tempted to argue that winbind should not be restarted.
<wasabi> And should in fact be treated like dbus
<slangasek> I would disagree strenuously with any attempt to argue that
<wasabi> Oh?
<slangasek> though I might be voted down
<soren> slangasek: Which part? Not restarting winbind or adding the --force option?
<slangasek> well, I don't even think it's right to pass on restarting dbus
<slangasek> soren: the not restarting
<soren> slangasek: Ah.
<wasabi> I don't really either. It'd be better if it could be safely restarted like upstart.
<wasabi> But it can't, can it?
<slangasek> if "safe" means "must never fail to restart", then no, nothing is safe ;)
<wasabi> Sure. What I mean is that even during normal operation, a stopped winbind is bad.
<wasabi> During the time of the preinst and postinst is even bad.
<soren> Upgrading dbus displays the "please reboot your system" notification.
<wasabi> Yup.
<slangasek> and if the logged-in user isn't resolved via winbind, that's an unnecessary delay of the restart
<soren> I definitely thinkg winbind should be restarted.
<wasabi> Well, then what's the solution to keeping desktops runnign? =/
<soren> (how did that 'g' sneak in there?)
<slangasek> wasabi: "assume any package upgrade may be disruptive"? hmm, perhaps I'm not on the same page with the rest of the Ubuntu team yet... :-)
<soren> wasabi: winbind is different from dbus in that dbus keeps connections open and various stuff breaks if that connection disappears.
<soren> wasabi: A winbind not running "just" means that while it's not running, things are... interesting.
<soren> wasabi: everything gets back to normal, when it comes back.
<wasabi> slangasek, Heh. Well, as long as the system actually presents the user with an option to upgrade, prompting it non stop with little pops up, it should be expected to work right.
<soren> wasabi: If the maintainer scripts are not robust enough to reasonably make sure it comes back up, *that's* the problem, we should fix.
<wasabi> Alright. So what level of "interesting" are we good with?
<slangasek> wasabi: well, anything that dies without ~ when $HOME is set is buggy and should be fixed, for starters
<soren> wasabi: What amount of security fixes are you good with not getting applied because you refuse to restart winbind?
<wasabi> slangasek, I'd respect sudo's decision to not elevate a user whose name it cannot resolve.
<slangasek> wasabi: for another thing, I hope you have a local, non-winbind user on your system who has sudo privs?
<wasabi> Yes. I do. It's just a pain to get to it.
<slangasek> ok
<wasabi> su won't run without a name either
<wasabi> Are you sure about that? I don't really think it's unexpected for a piece of software to be able to expect to resolve a uid.
<wasabi> Err.
<wasabi> I don't think it's unreasonable.
<slangasek> I don't think it's reasonable for a piece of software to fail if it can't
<wasabi> Hmm.
<slangasek> unless it's something that needs to run setuid()
<slangasek> then not being able to resolve a name to a uid is fatal, sure :)
<wasabi> ISI\jhaltom@station-1:/etc/dbus-1/system.d$ sudo /etc/init.d/winbind start
<wasabi> sudo: uid 1786588783 does not exist in the passwd file!
<wasabi> =(
<wasabi> I dunno. Guess I'm fine with all of that. I retract my statement. The maintainer script still needs to work, though.
<slangasek> su my-local-admin -c "sudo /etc/init.d/winbind start" :)
<wasabi> su fails.
<slangasek> it does?
<wasabi> Yes.
<wasabi> jhaltom@station-1:/etc/dbus-1/system.d$ su sysadmin
<wasabi> ISI\jhaltom@station-1:/etc/dbus-1/system.d$
<wasabi> exit code 1
<slangasek> hmm
<slangasek> maybe worth a bug
<wasabi> slangasek, so is it then accurate to say that apps should not use pam to return home and shell, and should instead use the environment?
<slangasek> wasabi: apps should not use pam to return home and shell, because pam knows nothing about either ;)
<wasabi> su explicitly has a set of code which gets the user's name to ensure he exists.
<wasabi> Err, nSs i mean
<wasabi> * Get the user's real name. The current UID is used to determine         * who has executed su. That user ID must exist.
<slangasek> wasabi: well, it's worth discussing with the shadow maintainers whether this is the Right Thing
<wasabi> Could also solve the problem by doing something creative, like ensuring that the current user can always retrieve his information... local nss_winbind cache for the one user.
<wasabi> That's basically what windows does.
<wasabi> oh, who knows. I don't care.
<wasabi> I just want it to work right. heh
<soren> You clearly do.
<soren> :)
<wasabi> Well, I maintain offices of people. I have an interest in it working.
<keescook> lool: thanks! :)
<slangasek> wasabi: how did winbind upgrading fail?
<wasabi> Don't think it did.
<slangasek> ok
<wasabi> Think winbind was just stopped while the adduser thing ran
<slangasek> right
<wasabi> and thus the upgrade itself stopped
<slangasek> ah, erm
<slangasek> well, that's correctable at least
<wasabi> I did manually start winbind, and the adduser thing proceeded.
<wasabi> Sure. Just worries me that it's so fragile.
<slangasek> we can do a if getent passwd $username ; then adduser ...
<wasabi> Well, it still needs to be added.
<wasabi> Can't skip it completely.
<slangasek> hrm?
<wasabi> My user is in fact a member of the local admins, and I would expect him to be added to this new group.
<wasabi> Just so happens he's a domain user.
<slangasek> which isn't possible when he's not resolvable, so your choices are a) have the samba postinst fail, b) skip the user
<wasabi> c) work right?
<wasabi> =(
<slangasek> nope
<wasabi> Working right is not an option?
<slangasek> you have to decide which of a) or b) is what you consider to be "working right"
<wasabi> Urm.
<wasabi> This is silly.
<slangasek> because those are the only two choices, given the information it's possible to determine from inside the samba postinst
<wasabi> I don't see why we have to talk ourselves into these little corners.
<wasabi> There is a working right. It should do what it's supposed to do, properly, and especially in a support configuration (using WInbind to let domain users log in)
<slangasek> i.e., it's not possible to determine whether a user lookup fails due to a temporary resolution failure, or because there's stale data in /etc/groups
<slangasek> /etc/group
<wasabi> Again, I'd argue that that's missing the problem. A "temporary resolution failure" is silly.
<wasabi> There should be no such thing. Any such thing should be a bug.
<wasabi> User's are not supposed to disappear during normal operation.
<wasabi> Especially one that's currently logged on.
<slangasek> nope, it's not missing the problem.  There are two problems, and one of them is "what do we do if /etc/group references a username that we can't find?"
<wasabi> Hmm. You are right, two issues. But you need to define "can't find" clearer.
<slangasek> not really
<wasabi> can't find because somebody left something left over? or because of a misplanning in how all the software works together?
<wasabi> In the first case, I agree. In the second, we should fix the problem that causes it to not be found.
<slangasek> "we should fix the problem that" is the separate problem, and has no bearing whatsoever on what the behavior of the samba package should be when it fails to find a user
<EtienneG> hey everybody
<EtienneG> ?I have a quick question about apport
 * slangasek waves to EtienneG 
 * EtienneG wave back
<EtienneG> I want to use apport-retrace to figure out a segfault
<EtienneG> it complained that my crash report do not have the Package field
<EtienneG> which is right
<EtienneG> how should I make apport write that field when building the crash report ?
<slangasek> wasabi: there are *only* two options for what samba can do when it reaches this case - it can bail (the current behavior), or it can ignore the missing user, possibly with a warning
<slangasek> if you have an opinion on which is the correct behavior, I'll take that under advisement
<EtienneG> (hopefully I make sense, I am not 100% sure I get all the naming convention right)
<soren> slangasek: Alternatively, the user migration stuff from admin to sambashare (or whatever) can be done outside of the postinst, but that's really not a very desirable solution either.
<soren> slangasek: I was about to say something about an inist script, but that'll get called from the postinst, too.
<slangasek> wasabi: but not all temporary resolution failures are bugs in the local system.  You may have shoved a user into /etc/group that can only be looked up via winbind, has never been in the local winbind cache, and at the point of the postinst running you have no network connection.  Doesn't matter then if you avoid stopping winbind.
<wasabi> I shall then fail a separate bug: "restarting winbind during upgrade causes desktop mayhem"
<wasabi> slangasek, I agree with that.
<slangasek> soren: right, and deferring the decision doesn't solve the problem anyway
<wasabi> what i mostly fear is that fixing the adduser thing will just hide the other issue.
<slangasek> soren: you still have to decide what you think you should do with users you can't find :)
<soren> slangasek: Not the inherent one, no.
<soren> slangasek: ..but this particular one, yes.
<soren> slangasek: The particular problem here is that during the upgrade, we shut down winbind, which causes this migration to fail.
<soren> slangasek: The inherent problem, however, is that we have no way to generally deal with users we can't find.
<soren> ...which we can work around in this case.
<soren> I wouldn't want to that, though. I'm just saying. :)
<slangasek> soren: we stop slapd on upgrade too, what if the users are in LDAP? :)
<slangasek> right
<soren> I'm entirely in favour of just ignoring the user (possibly issuing a warning).
<soren> It's commonplace for this sort of thing to not be enabled on upgrades, because (here's a shocker) there's no completely sane way to do it.
<mvo> Riddell: thanks for this info, I prepared something, but I think i need to keep it disabled, it does not yet work well enough (also the remaining issues get smaller)
<soren> I was surprised to even see an attempt at doing it, actually. :)
<slangasek> heh
<slangasek> soren: have there been other system groups added since Ubuntu's inception where there was a group that could even be sensibly templated from? :)
<soren> slangasek: Well, a lot of packages create system groups that users are supposed to be added to if they should be granted access. In most cases, it wouldn't be a completely braindead assumption that if you're ok with people having sudo powers for your entire system, you'd also be ok with them accessing your scanner or whatnot.
<soren> But maybe that's just me.
<soren> :)
<slangasek> soren: right, but I think in the case of scanners, the relevant group is /older/ than the admin group and created at install time? :)
<soren> slangasek: Ok, bad example. fuse, then.
<slangasek> ok :)
<soren> We talked about this net usershare thing a while ago, by the way. I was against adding that group, but I was clearly too slow to get to have a say in it :)
<slangasek> soren: oh?  what would be the alternative to adding the group?
<soren> I don't see why anyone would want to specifically grant access to sharing via samba rather than some sort of generic "this user is allowed to share stuff to the network". When the next package comes along that does something like this, perhaps using a different protocol, will we add another group? It's kind of like kvm and virtualbox each adding a group to which you can add users if they should have access to that particular virtualisation techniqu
<slangasek> so you would've preferred a generic name for the group?
<soren> Yes.
<slangasek> it's not too late to change :)
<soren> And have it added to base-passwd. (ooh, scary)
<soren> slangasek: True, but the barrier of entry grows significantly when you mention base-passwd. <100 gids are a scarce ressource.
<soren> brb
<slangasek> soren: < 100?  we have way more to play with than that :)
<slangasek> there's no reason this group needs to be statically assigned
<slangasek> and even if it were, there's the 60000-64999 range we've never touched ;)
<soren> slangasek: Well, it's hard to predict the future..
<cjwatson> is "never touched" a synonym for "allocated 18 uids and 8 gids in it"?
<cjwatson> /usr/share/doc/base-passwd/README :-)
<soren> slangasek: At some point, some sort of application that allows you to share stuff over the network might include a sgid binary somewhere.
<soren> slangasek: I had another thought, though.
<cjwatson> setgid binaries can use dynamic system groups provided that the group is created in the preinst
<slangasek> cjwatson: heh, wow, I don't think I've ever seen any of those :)
<soren> cjwatson: point
<thom> tac-plus has a 6400x user? hhuh
<cjwatson> god knows, I just allocate them
<cjwatson> there's enough space in the range and a small enough trickle of requests that all I do is double-check that there's a reason that 'adduser --system' isn't good enough
<soren> It might make more sense to just add the much-talked-about "users" group.
<soren> I think the need for the sambausers group is a technical one rather than a policy related one.
<soren> It depends on a directory somewhere that the relevant users can all have write access to.
<cjwatson> we have a users group; it's just that nothing adds normal users to it
<soren> There are two ways to do that (disregarding acl's): 1) Add a new group and add the relevant users to it or 2) make it world writable.
<soren> cjwatson: Wow... You're right. Why arent' we?
<cjwatson> but if you're going to add all normal users to a group and give that group write access to something, you almost might as well make that thing world-writable
<soren> cjwatson: Not so.
<pitti> (except if you care about not having it writeable for www-data etc.)
<cjwatson> www-data, granted
<soren> cjwatson: You're still protected from various rogue daemons and such.
<soren> cjwatson: Exactly.
<soren> or ftp
<cjwatson> maybe you're right
<cjwatson> anyhow, we're not doing it because we never have, AFAIK ;-)
<soren> gnome-user-share allows every user to share stuff over the network.
<cjwatson> I don't think there's a particular reason
<soren> That's because it uses fancy avahi magic to allow each user his own apache daemon on a different port.
<soren> No such magic can be done with samba (sanely).
<soren> ...which is why it had to be done this way.
<cjwatson> it'd be trivial to do with the EXTRA_GROUPS / ADD_EXTRA_GROUPS variables in /etc/adduser.conf
<cjwatson> but you'd have to do something about upgrades if you actually wanted to rely on it
<soren> ...but since there are loads of ways a user can share stuff to the network anyway, it's kind of odd that you want to add further restrictions because it's done via samba.
<cjwatson> and probably check that users-admin DTRT as well
<soren> ...this would be solved it all (actual, human) users were members of one common group.
<soren> cjwatson: Yes, upgrades are indeed the Achilles heel of this suggestion.
<soren> ...and the very reason I didn't take it any further when we were first approached about it, and then it got swapped out of my working memory when I went on honeymoon, I think.
<cjwatson> it's not rocket science, I just fear somebody having used gid users for something else
<cjwatson> but maybe we can just declare that that's stupid and add a NEWS.Debian item for it
<soren> LOL
<soren> cjwatson: I'd be fine with that.
<slangasek> soren: why would you want all "users" to be able to share things over the network via a samba?  admin users seems a much more sensible default, to me
<soren> slangasek: Because they can anyway by loads of other means?
<soren> slangasek: gnome-user-share, just to name one.
<slangasek> soren: hmm, well, gnome-user-share doesn't give users an opportunity to try to find holes in the samba running as root :)
<soren> slangasek: It seems strange to give them 1000 ways to do it, but because of a limitation in the way samba works (it only sensibly works on one port), each user can't have his own samba daemon to much around with.
<soren> slangasek: That's indeed true.
<soren> hm..
<soren> slangasek: Well... The only additional exposure these users get to samba is by way of putting files into a specific directory.
<slangasek> sure
<soren> It's not like samba is a daemon that's just tucked away in a corner never interacting with users anyhow.
<slangasek> btw, samba 3.0.27a-2 just accepted into sid, should cut the Ubuntu delta by half again
<soren> If you've enabled the [homes] share, you have much of the same access already, anyway.
<soren> And every user has that.
<slangasek> soren: mathiaz has argued against enabling [homes] by default :)
<soren> slangasek: Erm.. Ok. Regardless, the extra attack vector really isn't that much "extra". That's my point.
<soren> Just to clarify: By "And every user has that" I didn't mean "every user has [homes] enabled", but that "if [homes] is enabled, every user has such a share".
<slangasek> sure
<soren> ...which (assuming samba is sane) should expose the same set of potential vulnerabilities as the net usershare stuff.
<slangasek> one difference is that [homes] is commonly configured with valid users = %S, and net usershares can be configured to allow access to any authed user.  I'm not sure this is significant either.
<soren> Remind me what %S expands to?
<soren> Oh, the owner?
<slangasek> "share name"
<soren> Same thing. Ok.
<slangasek> so for each [homes] share, the only valid user is the one whose name matches the share name
<soren> slangasek: Are you pointing this out for the sake of completeness of the discussion, or are you actually saying it's a problem? :)
<soren> I.e. should I bother countering the argument?
<slangasek> soren: completeness :)
<soren> slangasek: Ok, good :)
<soren> So.. Should we make samba the first package to actually use the users group?
 * soren mumbles TIL and points at slangasek
<slangasek> "TIL"?
<soren> Touched It Last.
<slangasek> well, I'm not personally persuaded that the "users" group has the correct semantics for Debian, there may be sites using it that way who don't want all their users to be able to create shares (namespace pollution?)
<soren> The last upload has your name on it. Of course that doesn't de jure means that you're the owner of it, but e.g. for merges, it's often the de facto way to determining who will do it.
<soren> slangasek: True. However, you're also an Ubuntu developer these days, though.
<slangasek> soren: yes, an Ubuntu developer who just spent a bunch of time reducing the Debian/Ubuntu divergence on the Samba packaging ;)
 * soren mumbles TIL again
<soren> :)
<soren> slangasek: If you're too busy, that's fine. We should just do it sooner rather than later.
<slangasek> well, unless that implies I'm also the one who gets to /decide/ whether to use a users group, I'm still going to sit here and raise possible counterarguments :-)
<slangasek> making it "users" does make it more complicated to enact alternate policy decisions
<soren> That's true.
<slangasek> making it "sharing-users" makes it the distro's responsibility to maintain the group
<slangasek> but that would already be the case with "users", AFAICS
<ogra> StevenK, bug 174213 is a present for you :) (just had to build the modules for the new kernel)
<ubotu> Launchpad bug 174213 in virtualbox-ose-modules "cant build with 2.6.24 kernel source" [Undecided,New] https://launchpad.net/bugs/174213
<ogra> (looks like you own vboxdrv :) )
<micahcowan> Is sporadic loss of keyboard input to GTK+ windows a known issue with Gutsy at this time?
<micahcowan> (I'm not sure if it's limited to GTK+, most of my apps happen to be GTK+-based.)
<Riddell> doko: could we build icedtea against libungif instead of libgif?  it's the only thing that depends on libgif and the two confict
<Riddell> or doko_
<doko_> Riddell: ?
<Riddell> doko: could we build icedtea against libungif instead of libgif?  it's the only thing that depends on libgif and the two confict
<doko_> Riddell: could you file a bug, so that I remember? I never tried
<Riddell> sure
<mjg59> Riddell: Why is ungif preferable?
<Riddell> mjg59: just because everything else in the archive uses it rather than libgif
<mjg59> Riddell: That sounds like a bug
<Riddell> libungif is in main, presumably to avoid gif patents
<mjg59> Riddell: Ungif is unmaintained
<mjg59> (upstream)
<mjg59> We should migrate everything to libgif
<mjg59> Riddell: See http://www.advogato.org/person/badger/diary/51.html
<slangasek> wow, that hasn't already been done?
<mjg59> It would seem not
<mjg59> Given there are bugfixes in libgif that aren't in libungif, I think it's certainly worth it for hardy
<Riddell> seems sensible
<Riddell> reported as bug 174252
<ubotu> Launchpad bug 174252 in libungif4 "transition to libgif" [Undecided,New] https://launchpad.net/bugs/174252
#ubuntu-devel 2007-12-06
<slangasek> calc: so mdz_'s suggestion wrt bugs that you're working on but aren't actually RC is to use the "in progress" state.  Does this sound sufficient for your needs?  If so can you please go through https://launchpad.net/ubuntu/+milestone/hardy-alpha-1, dropping the milestone and changing the state for any of these OOo bugs of yours that you don't think are RC?
<slangasek> (for the ones that are RC, feel free to leave them there since there's still some ongoing discussion about how to handle, I'll be happy to shuffle them around for you when the time comes)
<bigon> hi, is someone working on the merge of dpkg?
<evand> bigon: soren took care of it.  It's in the process of being tested.
<bigon> ok thx :)
<evand> anytime
<bigon> is there a place where I can get the pkg to test it too?
<evand> deb http://ppa.launchpad.net/shawarma/ubuntu hardy main
<ion_> Will my system break by testing that? ;-)
<bigon> thx (again)
<evand> Reports so far have been positive, from the two I've seen, but your milage may vary.
<slangasek> ion_: yes, but we're asking for testing anyway because we're sadists ;)
<ion_> Iâll install it after this episode of B5.
<ion_> evand: I installed dpkg from the PPA, removed another package and reinstalled it. No problems so far.
<evand> ion_: soren would be the person to tell.  I'm just the messenger.
<ion_> soren: I installed dpkg from the PPA, removed another package and reinstalled it. No problems so far.
<ion_> soren: apt-get upgrade worked as well.
<ion_> soren: Including the triggers
<bigon> soren: I've quickly read the debdiff of dpkg (between debian and your last version) and it seems that changes in some files (lib/showpkg.c, lib/tarfn.c and src/configure.c) are mostly cosmetical, it's maybe a good idea to resync these files with the debian one
<calc> slangasek: yea that sounds good enough for me
<calc> slangasek: i moved my bugs over to in progress from the milestone if you notice any left laying around elsewhere ping me :)
<slangasek> calc: looks good, thanks
<calc> is there a way to determine what is holding a mount open?
<StevenK> fuser -m
<calc> its a bind mounted /proc and none of the processes look like they could actually be the culprit
<calc> since they were running before the bind mount happened
<StevenK> calc: lsof | grep ?
<calc> StevenK: nothing shows up with lsof -n | grep /path-to/proc
<calc> can the kernel get confused and think mmapped files for real proc are on the bind mount version?
<StevenK> I'm not sure.
<calc> there are only 11 processes running that started today
<calc> and of those only [pdflush] are by root which is who owns the chroot dirs
<lamont> slangasek: core-dev app goes to motu-council?
<slangasek> lamont: so the wiki tells me
<lamont> how very interesting.  OK
<slangasek> lamont: and several apps over the past few months have done so
 * lamont hasn't looked at the process in some time
<lamont> I guess I'll do a group repoly
<lamont> "steve knows processes far better than I do."
<lamont> :-)
 * slangasek snorts
<Hobbsee> lamont: it does, yes.
 * lamont is glad he went through the old core-dev process. :-)
 * bddebian is glad he doesn't have to worry about it :)
 * StevenK was one of the last to go through the old way
<lamont> StevenK: did you hire in that long ago>?
 * Hobbsee was also one of the last
<StevenK> I became a core-dev long before I applied for a position at Canonical
<Hobbsee> oh hang on, no, i was one of the new bunch
<StevenK> Right
<StevenK> You had the public humiliati^Wsponsor begging on the m-c list
<lamont> StevenK: ah, ok.
<Hobbsee> or the sponsors who shoved you into it, if you were unlucky
<lamont> Subject: Your message to Motu-council awaits moderator approval
<lamont> feh
<calc> heh
 * lamont tries another address. :-{
 * ajmitch looks for list password
<StevenK> That reminds me.
<lamont> sending it from lamont@u.c instead of lamont@m.c should prolly work, eh?
 * StevenK wields listadmin
<lamont> StevenK: you might look to see if my mail already made it through first... :)
<lamont> in which case you could discard and add me to accepts, instead of accepting and adding. :-)
<lamont> nope.
<lamont> also held
 * Hobbsee wields listadmin too
<StevenK> lamont: Different lists, but you talking about it reminded me
 * lamont hands StevenK some weights to add to the smacking stick of listadmin
<lamont> ah, ok
 * lamont waits with baited breath for the next data point on graph2
<ajmitch> lamont: sorry, accepted the first
<lamont> heh.  np
<lamont> the second got blockaded too.
<lamont> and mail to the list is more likely to be from lamont@m.c, since I'm too lazy to remember to change it to @u.c
<calc> openoffice.org-2.0.4.dfsg.2/ooo-build/patches/src680/cws-hsql1808.diff |  807 ++++++++++   <- fun stuff to port to 3 unsupported versions of OOo
 * ajmitch still doesn't see slangasek's mail
<lamont> calc: while you're there, please code trampolines for ia64.
<lamont> :-)
<slangasek> ajmitch: https://lists.ubuntu.com/archives/motu-council/2007-December/000583.html ?
<calc> lamont: hahaha yea right ;)
<ajmitch> slangasek: considering that I've had dsl issues all day, it wouldn't surprise me if something went funny with my mail
<ajmitch> but thanks for the archive link
<ajmitch> ah, still in mail queue locally, too many came in at once
<lamont>  /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../lib64/libcdb.a(cdb_init.o): relocation R_X86_64_PC32 against `__fxstat@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
<lamont> I wonder... do I care?
<slangasek> hum, what's linking cdb into a shared lib?
<lamont> backport of postfix to dapper (which lacks libcdb.so), on amd64
<lamont> and, well, it's, um, crackports after all.......
<lamont> and someone would probably shoot me if I backported tinycdb
<slangasek> heh
<lamont> OTOH, I could do a new backport that drops postfix-cdb on amd64. :-)
<lamont> dh_installmenu
<lamont> dh_iconcache
<lamont> make: dh_iconcache: Command not found
<lamont> feh
<lamont> so how come ksocrat built on the other 6 architectures?
<Hobbsee> lamont: use dh_icons now
<Hobbsee> lamont: did they build before the debhelper changes?
<lamont> much
<lamont> like during gutsy
<Hobbsee> and this is a belated gutsy build?
<lamont> hppa still needs to build about 2000 packages that everyone else built in gutsy
<Hobbsee> true
<lamont> or feisty, or (in some really sad cases), edgy
<Hobbsee> do you plan to import them in, or?
<Hobbsee> oh dear.
<Hobbsee> then again, there are some builds scheduled for hoary still, so...
<StevenK> lamont: I can upload a fix0red ksocrat if you wish
<lamont> I just happened to notice it because I was the last one to upload it, so I got the cranky-buildd mail
 * lamont has no clue what ksocrat does, or why he should care, other than in the most general and non-specific of terms
<lamont> (the caring that is.  no clue at all what it is/does...)
<Hobbsee> Description: English/Russian and Russian/English Dictionary
<Hobbsee>  Socrat is a simple English/Russian and Russian/English dictionary
<Hobbsee>  written for Qt3/KDE3.
<Hobbsee> right then
<StevenK> Sounds like it's users number in ... wow, the tens
<lamont> Hobbsee: I think that says something about how much I care, since apt-cache is beyond the limits atm.... :P
<lamont> StevenK: oh, sure... rub in that it has more users than hppa/ubuntu
<Hobbsee> lamont: i'd say "who cares about it in gutsy anyway", and ignore it
<lamont> this is hardy
<Hobbsee> oh
<StevenK> Ha
<lamont> it didn't make the cut for gutsy... they slammed the door on us.. :-)
<Hobbsee> well, that's what i was thinking
<lamont> but if StevenK uploads a new version, then everyone gets new love.  and the package will fail during autotest...
<StevenK> It will?
<lamont> hrm... maybe we can launch a new autotest run, just to help find all these wonderful new ftbfs packages that debhelper has created...
<lamont> well, it doesn't build on hardy, so -autotest will ftbfs........
<Hobbsee> lamont: wouldn't be a bad idea.
<Hobbsee> then we can throw hopefuls at them
<lamont> Hobbsee: but they're not Lions.
<Hobbsee> sorry?
<Hobbsee> well, true
<lamont> I was thinking you were suggesting throwing hopefuls to the lions.
 * lamont throws a new util-linux at the fire
<Hobbsee> hehe
 * Hobbsee smites the evil launchpad
 * lamont remembers to build the ubuntu version of util-linux for his home machine, rather than the debian one
<Hobbsee> what on *earth* has it done with my portal?  again1
 * lamont is in the market for someone who understands autocrap, once he gets around to actually looking at nmap again
 * Hobbsee points to StevenK
<lamont> Hobbsee: I think you mean "smiteseses"
 * lamont hates autocrap
 * StevenK ducks out of the way of Hobbsee's pointing
<lamont> StevenK: it's probably something simple/stupid
<StevenK> I don't know much about autocrap, I try and avoid it.
<lamont> git clone git://git.debian.org/~lamont/nmap.git and then figure out why the experimental branch doesn't like me.
<lamont> StevenK: I guess I'm less successful in avoidance than you...
<lamont> several of my packages use it
 * lamont sleeps before he gets keyprints on his face
 * Hobbsee replaces lamont's pillow with his keyboard
<lamont> feh
<StevenK> I can't see typing on a keyboard being very productive
<MacSlow> Greetings everybody!
<Burgundavia> hey MacSlow
<dholbach> good morning
<ion_> Good time of day.
<dholbach> hi ion_
<ion_> Hi
<Dooms> hey can any of you guys watch this video i made? And yes im the girl
<Dooms> http://youtube.com/watch?v=eXdkyAyOcGo
<pitti> Good morning
<dholbach> hey pitti
<pitti> eek, my fonts in firefox are utterly ugly this morning
<stgraber> moin
<pitti> doko_: ^ your fontconfig merge?
<pitti> hey stgraber
<StevenK> Oh sigh, more fallout from this libgcrypt move
<StevenK> Revenge!
<pitti> StevenK: ?
<pitti> eww -- does anyone know how I can get to a VT in current hardy?
<mjg59> chvt ?
<pitti> no, that doesn't work either
<pitti> I get a black screen, and then it switches back to X
<mjg59> Switches back to X, or X restarts?
<pitti> no, just switches back
<pitti> gnome session continues to work fine
<mjg59> Hm. How odd.
 * pitti tries it after ending the X session, bbl (need to test usplash)
 * pitti blames consolekit
<cjwatson> pitti: there's a bug linked from the hardy-alpha-1 release notes about that
<cjwatson> I blame X personally
<pitti> it works under gdm, and stops working when I'm logged in
<pitti> cjwatson: ah, thanks
<cjwatson> mjg59: I think X is catching the switchaway signal (as it should) and then switching to its own VT rather than the one it's been told to switch to, for some reason
<cjwatson> but stracing X made my system hang so I can't get any further
<cjwatson> I suppose it *could* be consolekit's fault, but why would switchaway signals be propagating up that far?
<cjwatson> I was wondering if it was something to do with the kbd driver
<mjg59> cjwatson: stracing should work, providing it's not from within X itself
<mjg59> chvt should be sending the signal directly to the kernel
<mjg59> At which point the kernel waits for X to release the console (which it does after restoring text mode)
<cjwatson> mjg59: I did 'strace -f -o X.trace -s 1024 -p `pidof X`' from a pterm; why would that be any different from sshing in and doing it?
<cjwatson> right, but X actually does the VT_ACTIVATE ioctl
<mjg59> Not with chvt, surely?
<cjwatson> oh, hm, possibly not
<mjg59> chvt hits /dev/console directly
<cjwatson> but it does have to do that RELDISP thing
<mjg59> Yes - I wonder if that's not actually happening properly
<mjg59> It shouldn't be able to trigger a switch back to itself
<cjwatson> so what do you mean by stracing "not from within X itself"?
<cjwatson> do you mean starting the strace while X isn't active?
<mjg59> Either sshed in or at a console
<mjg59> Did the strace hang immediately, or just when you tried to do something?
<cjwatson> I have trouble understanding why this is any different from stracing with output sent to a file from an X terminal emulator
<cjwatson> it hung all of X immediately
<cjwatson> and there was no output in the file
<cjwatson> it may have oopsed the kernel, I'm not sure
<mjg59> Right. It ptrace()ed X, then pterm attempted to print the command line
<cjwatson> oh
<mjg59> Then it deadlocks
<cjwatson> sigh, ok, fair point
<cjwatson> mjg59: http://people.ubuntu.com/~cjwatson/tmp/X.trace (4MB) - that's from Ctrl-Alt-F1
<cjwatson> no other process has its fd 4 (/dev/tty7) open
<cjwatson> hmm, but console-kit-daemon does have /dev/console open
<cjwatson> pitti: you're right
<cjwatson> I can see console-kit-daemon doing:
<cjwatson> 5523  ioctl(9, VIDIOC_G_COMP or VT_ACTIVATE, 0x7) = 0
<mjg59> cjwatson: Yeah, looks like console-kit
<cjwatson> and when killed, the switch works fine (apart from my consoles displaying nothing due to some unknown funtedness)
<mjg59> X changes correctly, and then something else immediately reactivates its VT
<cjwatson> so consolekit's purpose is to stop us getting to consoles? ;-)
<mjg59> More secure that way
<pitti> hm, we already had that bug when we introduced CK in gutsy IIRC
<pitti> but Ian fixed it back then
<mjg59> Looks like the change from ubuntu1 to ubuntu2?
<cjwatson> I have 0.2.3-2ubuntu1
<mjg59> 0.2.1-1foo, that is
<cjwatson> ah
<cjwatson> yes, we have the change in ubuntu1 (I think) but the change in ubuntu2 was dropped
<cjwatson> somebody reported the same problem in gutsy, and I think bug 131751 is probably mixed up; I asked a question in comments to try to disambiguate
<ubotu> Launchpad bug 131751 in xorg-server "Unable to switch Virtual Terminal with C-A-F[1-6] on Intel-based new laptop" [Undecided,New] https://launchpad.net/bugs/131751
<cjwatson> if it looks separate, I'll try to disentangle things
<lool> pitti: Fonts ugly for me too; fontconfig looks like the culprit indeed
<ion_> Ditto
<seb128> on my desktop fc-cache SIGSEGV since the update
<doko_> cjwatson_: (the installer is the only upx-ucl-beta user) the upx-ucl-beta package is now just an empty dummy package, upx-ucl is now at version 3.01. can that be used directly in the installer?
<cjwatson> doko_: I'll give it a try
<pitti> seb128: not here on amd64, but fonts are still wrong
<seb128> pitti: the crash looks like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452718
<ubotu> Debian bug 452718 in fontconfig "ttf-opensymbol non-installable" [Serious,Open]
<pitti> wohoo, glibc 2.7
<thom> is 2.7 exciting?
<doko_> seb128, lool: the new fontconfig now makes a difference between metric compatible fonts and other fonts; unsure where dejavu ends now. maybe not in metric compatible?
<seb128> that sucks
<seb128> bug #174373
<ubotu> Launchpad bug 174373 in nautilus "[hardy] squares instead of text in nautilus" [Undecided,New] https://launchpad.net/bugs/174373
<seb128> that's due to the fontconfig update, I had it too before restarting
<seb128> the xchat-gnome taskbar text was replaced by squares
<Riddell> pitti: could you look again at MainInclusionReportlibkarma next time you're going MIR?
<doko_> lool: you're rpm uploader ... do you know if rpm should work with neoon >= 2.6?
<doko_> Riddell: bug number?
<Riddell> doko_: bug 89591
<ubotu> Launchpad bug 89591 in amarok "Please package Amarok Rio Karma support (--with-libkarma)" [Wishlist,Confirmed] https://launchpad.net/bugs/89591
<pitti> Riddell: yes
<doko_> Riddell: please subscribe ubuntu-mir (I should post this to u-d-a ...)
<Riddell> done
<lool> doko_: I know we have a very outdated RPM
<doko_> lool: debian as well?
<lool> doko_: Presumably a newer RPM would
<lool> doko_: Oh yeah, Debian as well
<lool> Well the version is recent, but they stopped at 4.2
<lool> Basically I'm not sure there's any consensus on which RPM base we should track anymore
<lool> doko_: Newer rpm can build without neon
<lool> doko_: Since 4.4.2.1
<lool> But it seems they dropped the internal copy
<doko_> hmm, for now I build with the current db4.6 and keep the neon that debian uses
<lool> doko_: I think rpm called from apt or yum doesn't need neon that much, it seems to be used for some webdav stuff
<doko_> googling for "suse gfxboot syslinux" points you to launchpad as the first entry ;) cjwatson: do you know an "suse upstream" location for gfxboot?
<soren> doko_: It's in the most recent copyright.
<soren> doko_: There's not a proper upstream place for it. We extract it from their srpm's.
<soren> http://changelogs.ubuntu.com/changelogs/pool/main/g/gfxboot/gfxboot_3.3.39-0ubuntu1/gfxboot.copyright
<cjwatson> what he said
<cjwatson> I went and looked it up when soren asked a week or so ago :)
<doko_> ahh, ok, will add that for syslinux
<doko_> ohh, no. they only for 3.31 packages, debian has 3.53 ...
<soren> http://ftp.kernel.org/pub/linux/utils/boot/syslinux/
 * torkel hugs seb128. You are my hero!!! Thanks a lot!!! (re #173156)
<seb128> torkel: you are welcome ;-) Thanks for testing the change
<doko_> soren: well, yes, that's *without* the gfxboot patch =)
<torkel> seb128: I had to. I don't like thunderbird :-)
<mvo> what is the best practise for the "remove stop links" changes? do we submit those to debian?
<soren> doko_: Oh, right.
<doko_> emailed the maintainer
<pitti> mvo: debian doesn't have 'multiuser' update-rc.d
<pitti> and IMHO we should get rid of it, too, and replace it with LSB header parsing (Debian's sysvutils has support for that to some degree)
<pitti> that's even in one of Keybuk's specs AFAIR
<mvo> ok, thanks. so I will forward it for now
<cjwatson> doko_: upx-ucl seems to throw an exception while trying to compress our kernels; that said, on looking at an older build log, apparently so did upx-ucl-beta. So I need to investigate some more.
<cjwatson> it worked in http://buildd.debian.org/fetch.cgi?&pkg=debian-installer&ver=20070308&arch=i386&stamp=1173520790&file=log
<soren> slangasek: Do you plan on doing the keepalived merge?
<cjwatson> it broke in Dec 2006 when we switched to 2.6.20
<cjwatson> so I guess we don't lose anything by switching to it ;-)
<soren> :)
<cjwatson> upx-ucl *is* trying - it just can't actually achieve worthwhile compression, so throws an exception
<cjwatson> doko_: committed for next d-i upload
<dholbach> where did read-edid move to in hardy?
<dholbach> it seems its needed for BulletproofX, but not a strict depends somewhere and the read-edid package does not seem to be on hardy/amd64?
<ogra> doesnt ddcprobe provide the same ?
<dholbach> aha... does not exist on amd64
<ogra> ah
<dholbach> no BulletproofX for me?
<ogra> xresprobe ?
<ogra> i think that exists on amd64
<dholbach> it does and it's installed
<dholbach> but I guess it's not used for that purpose
<ogra> not sure if it provides all read-edid gives you
 * dholbach dpkg-reconfigures by hand
<dholbach> other than having no lum, the new kernel seems fine :)
<ogra> for me as well
<ogra> i had to recompile vboxdrv though
<ogra> since i use it extensively for ltsp and classmate development
<cjwatson> I found that b43 was less stable than bcm43xx, although I wasn't sufficiently sure of this to file a bug
<cjwatson> (I'm not in the London office enough to get a clear impression of the stability of my laptop's network connection with WPA there)
<ogra> i havent even tried wireless yet ... booting and wired is fine though ...
<ogra> and i had no lockups yet :)
<lamont> cjwatson: given the debhelper changes, I think it makes sense to do a -autotest run, soonish... thoughts?
<cjwatson> lamont: no complaints from me about more autotests
<slangasek> soren: was planning to, yes.  It's worth bonus points, because upstream "fixed" the ftbfs in the latest version by adding a dep on a different kernel header that we aren't shipping...
<soren> slangasek: I forgot what I asked you.. :)
<slangasek> soren: the keepalived merge :)
<soren> slangasek: Ah, right.
<soren> slangasek: We're not shipping it in linux-libc-dev, or do we not have it all?
<slangasek> soren: not in linux-libc-dev; it seems to be generated in the Linux upstream source, but I haven't checked too closely since this seems to be the only software on the planet that believes it's supposed to be exported
<soren> slangasek: I'm not sure how uncommon that is. I doubt very many other pieces of software will benifit from the various iptables related headers that get to land in linux-libc-dev :)
<slangasek> soren: it's not an iptables header that's missing, it's that keepalived wants UTS_RELEASE
<slangasek> which everyone else gets by without just fine
<soren> slangasek: Sure. I just meant that it's not uncommon to shove stuff into linux-libc-dev that only one software package will need.
<soc> hi
<soc> atm kernel 2.6.24 can't find the necessary microcode image for using my intel3946abg wlan wit iwlwifi?
<soc> am i supposed to download that manually?
<soc> or ist just a package in the repo missing?
<ivoks> look for restricted modules
<soc> can't fin one  ...
<soren> ...it's not there yet, afair.
<soc> ivoks: do you see it yet?
<soc> ah ok thanks+
<ivoks> i don't use hardy yet
<soc> would it be possible to manually download it to test the functunality?
<soc> btw, why doesn't sudo work without network?
<ivoks> misconfigured /etc/hosts?
<soc> didn't change anything
<soc> what should i look for?
<ivoks>  /topic :)
<soc> btw, will users automatically migrated to pulseaudio, or will they have to decide that for themselves?
<Hobbsee> automatically, i'd assume
 * Hobbsee wonders when we get linux-ubuntu-modules
<mekius> hey, trying to modify the default boot menu on the ubu livecd, where are the source files for the menu translations.  the tr and hlp files in the isolinux dir seem to be some compiled binary form
<mekius> anyone know where these translation files are stored?
<lamont> slangasek: linux-libc-dev is from the kernel, yes.
<slangasek> lamont: that... wasn't the question? :)
<lamont> heh
<lamont> it was ancillary....
<lamont> pitti: keescook: see http://bugs.debian.org/454554 re sudo passwd breaking emacs on gutsy et al
<pitti> lamont: ah, cool, fixed upstream already
<pitti> lamont: this looks pretty brittle, though :)
<AlinuxOS> hello all dear people "OEM install (for manufacturers)" - remember that I translated that string before NonLanguagePackTranslationDeadline, but it doesn't compare in a main menu of Ubuntu 7.10. What should I do to solve that problem for the Hardy ?
<mdz_> AlinuxOS: I believe cjwatson usually pulls in translations for the installer etc. around that time
<cjwatson> AlinuxOS: it was marked fuzzy (= "needs review" in Rosetta, I think) in the export I did on 9th October, five days after the deadline
<cjwatson> AlinuxOS: fuzzy strings don't get included
<AlinuxOS> ah
<AlinuxOS> cjwatson, sorry then...
<cjwatson> mekius: they're in the gfxboot-theme-ubuntu source package
<AlinuxOS> cjwatson, mdz_ thanks.
<mekius> cjwatson: ok, will look into it
<cjwatson> mekius: they're translated in Launchpad
<mekius> "This theme does not include any help texts or logos itself"
<cjwatson> mekius: you asked for menu translations, not help texts
<cjwatson> the help texts are in debian-installer
<cjwatson> it's a bit of a mess, I concede
<ion_> debian\control, debian\rules? :-) (gnome-power-manager debian/changelog)
<mekius> cjwatson: gah, i see
<mekius> cjwatson: makes it a major pain to produce a derivate heh
<AlinuxOS> cjwatson, https://bugs.edge.launchpad.net/ubuntu/+source/gfxboot-theme-ubuntu/+bug/62849/comments/10  is it possible to fix that small-bug? It should shouldn't take a lot time. I would be very thankful!
<ubotu> Launchpad bug 62849 in gfxboot-theme-ubuntu "Georgian (ka) letters are very crappy!" [Medium,In progress]
<AlinuxOS> cjwatson, there is a small point/pixel in a wrong place in a letter "tz" = á¬ <- in Georgian.
<m0dY> any idea why after an 'apt-get dist-upgrade' eth0 has change to eth1 ?
<cjwatson> AlinuxOS: unifont done, pcf2bdf hates me but working on it
<soc> hi
<cjwatson> AlinuxOS: in future, please open a new bug rather than reopening an ancient one
<soc> did someone experience that pulseaudio has quite some latency?
<AlinuxOS> cjwatson, thank you. I'll do it!
<soc> starting/pausing a song in amarok e.g. takes a bit more than 1 second
<m0dY> what causes Ubuntu to change eth0 to eth1 for an ethernet controller ?
<Nafallo> m0dY: races in which module gets loaded first if you have another controller that likes to be called ethX
<m0dY> well, from what i can see there's only eth1+lo+sit0 now ! no eth0 at all..
<cjwatson> AlinuxOS: (so gfxboot-theme-ubuntu not done yet, due to the pcf2bdf hatred, but shouldn't take too long ...)
<Nafallo> that's a bit weird...
<cjwatson> I wonder how I did this last time
<AlinuxOS> cjwatson, I'll test everything for future Alpha2.
<m0dY> Nafallo: it just happened after doing an apt-get dist-upgrade
<lamont> GAH
<lamont> so... when I'm building i386 binaries on powerpc... which value does DEB_HOST* get?
 * soren smells a trick question
<slangasek> lamont: DEB_HOST should be i386
<lamont> thanks
<slangasek> lamont: if you can't remember them, you can test with dpkg-architecture -a$foreign_arch :)
<lamont> slangasek: rock
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<cjwatson> pitti: debian-installer 20051026ubuntu36.12 uploaded to dapper-proposed
<pitti> thanks
<pitti> cjwatson: apt sources look good, BTW, no -proposed
<pitti> in fact it's not even commented
<pitti> (we didn't have it at that time yet, after all)
<cjwatson> pitti: oh good
<cjwatson> pitti: doesn't that mean it doesn't install the proposed kernel though?
<cjwatson> pitti: at least when netbooting
<cjwatson> I think netboot tests will probably not be valid until everything's in -updates :-/
<cjwatson> elmo: ^--
<elmo> \o/
<tkamppeter> pitti, ping
<pitti> cjwatson: re (sorry, was at dinner)
<pitti> cjwatson: no, it does install the -proposed kernel, and -proposed lbm
<pitti> netboot> yeah
<geser> what's the best way to break a build-depends cycle?
<geser> mig build-depends on gnumach-dev (source: gnumach) and gnumach build-depends on mig :(
<geser> pitti: please give-back gnumail. Thanks.
<pitti> geser: kicked
<geser> pitti: do you know a way to break a build-depends cycle?
<pitti> geser: how do you define that?
<geser> mig build-depends on gnumach-dev (source: gnumach) and gnumach build-depends on mig :(
<geser> and both are waiting on each other
<pitti> geser: that's not a problem usually
<pitti> but if they dep-wait on each other because the versions are too high, it is of coursee
<pitti> geser: you have to find out if you can build either with the existing version of the other
<pitti> geser: and if so, weaken the versioned build-depends
<geser> both build-depends are unversioned
<geser> we never got any of both build, they are sitting in depwait
<geser> pitti: please give-back: gtkrsync haxe hmisc
<pitti> geser: ah, that requires a manual bootstrap then (-> lamont)
 * lamont grumbles at pitti
<pitti> geser: given-back
<pitti> lamont: not saying that you should do it, but maybe quickly explain how it works?
<geser> lamont: could you please bootstrap mig and gnumach? Thanks :)
<pitti> geser: do you really care that much? it's quite some work
<lamont> infinity would be the target of choice... I'll probably get to it eventually....
<lamont> as in sometime over christmas break, unless too much else gets dumped on me...
<geser> pitti: not really, I try only to clear the list of FTBFS (http://qa.ubuntuwire.com/ftbfs/)
<geser> if it's to much work, it can be ignored
<infinity> pitti: Those requests should definitely go to me, now that I'm back.
<pitti> oh, hey infinity; it's middle of the night for you, isn't it?
<infinity> pitti: I can always enlist LaMont's help, if he feels like working for free, but it *is* my job. :)
<pitti> heh, ok :)
<infinity> pitti: No, no, I'm in Canada now!
<pitti> but well, admittedly gnumach is an interesting academic project, but having it in universe is certainly something very few people will even notice
<lamont> infinity: holler if you need anything - otherwise I'm hip deep atm
<lamont> infinity: ogre$mumble needed love as well
<lamont> I'll have to dig up the email'
<lamont> infinity: email forwarded
<lamont> to @u.c... iz good?
<geser> pitti: please give-back: hg-buildpackage
<pitti> done
<geser> infinity: does the buildds still have the problem that they consider provided packages sufficient for versioned build-depends?
<pitti> geser: why's that a problem? it has been a feature so far
<geser> see http://launchpadlibrarian.net/10570879/buildlog_ubuntu-hardy-i386.libmail-box-perl_2.078-1_FAILEDTOBUILD.txt.gz
<geser> pitti: perl-modules provides libtest-harness-perl which is also a seperate package and that package has a versioned build-depends on libtest-harness-perl
<pitti> hm, real dependencies should be prefered
<geser> afaik versioned (build-)dependencies don't work for provided packages
<pitti> right, they don't
<pitti> Provides: doesn't have versions
<geser> yet the part that installs the B-D is happy with perl-modules but dpkg-buildpackage complains later
<pitti> so that's buggy then
<geser> has someone an idea why libtool looks now for /lib/libgcrypt.la?
<TheMuso> geser: What package are you working on?
<geser> libmrss http://launchpadlibrarian.net/10360063/buildlog_ubuntu-hardy-amd64.libmrss_0.18.0-2_FAILEDTOBUILD.txt.gz
<geser> TheMuso: have you seen http://ubuntu.joejaxx.org/? :)
<TheMuso> geser: Yes, but that doesn't count IMO.
<TheMuso> geser: And, ahve you tried a simple rebuild of the package?
<geser> TheMuso: yes
<TheMuso> geser: I recently had a similar issue with gnunet, and gnunet-gtk. I had to put code into debian/rules for gnunet to clean the .la files. Check out clean-la.mk from cdbs to see what I mean.
<geser> /bin/sed: can't read /lib/libgcrypt.la: No such file or directory
<TheMuso> right.
<TheMuso> libgcrypt had its .la file moved from /lib to /usr/lib.
 * TheMuso has a look at the package.
<geser> libmrss uses cdbs, so I simply include clean-la.mk?
<TheMuso> geser: I think the problem here is one of libmrss' dependencies.
 * TheMuso digs deeper.
<StevenK> I daresay libtool is just taking the library path and s/.so/.la/ and then complaining bitterly.
<StevenK> Stupid thing.
<TheMuso> geser: Looks like something in the dep chain uses gcrypt, and still has stuff in its .la files that tell libmrss to try and find /lib/libgcrypt.la I think.
<geser> libnxml.la references /lib/libgcrypt.la
<geser> so simply rebuild libnxml and then libmrss?
<TheMuso> geser: Rebuild libnxml0 but clean its .la files, and then rebuild libmrss
<TheMuso> I'd try this in a chroot first, just to be sure it works.
<geser> is using clean-la.mk from cdbs ok?
<TheMuso> geser: IMO if the package doesn't use cdbs, manually dropping the code in debian/rules is sufficient.
<geser> it uses cdbs
<TheMuso> Ok, just include clean-la.mk.
<geser> TheMuso: thanks, it builds now with the fixed libnxml
<wasabi> oooh. scarey. All dbus apps just started crashing until I reinstalled libdbus-1-3
<TheMuso> geser: np
<pitti> poningru`: for your in-progress MIR, please use the standard template
<lamont> keescook: I wonder... looking at vim... do we care that edgy backports is afflicted with whatever bug got fixed in ..ubuntu5.2???
<keescook> lamont: generally the procedure is to request an updated backport
<lamont> keescook: I just happened to notice... if you don't care, i don't either. :0)
<keescook> :)
<lamont> I mean, it's... backports...
 * jdong looks at backlog
<jdong> lamont: I'll deal with you for that comment after these 4 pages of chemistry finish themselves.
<jdong> :D
<Nafallo> jdong: new gajim ;-)
<jdong> Nafallo: ok, first "discuss the differences in CFSE between square-planar and octahedral" complexes, and in return I'll deal with that ;-)
<Nafallo> jdong: I think I will just file a bug :-)
<jdong> Nafallo: sounds good ;-)
<Nafallo> Bug #174558
<ubotu> Launchpad bug 174558 in gutsy-backports "gajim_0.11.4-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/174558
#ubuntu-devel 2007-12-07
<apostols__> Hi
<apostols__> I have problem with upgrade timezone in Ubuntu Dapper
<apostols__> This dont have tzdata package and i need upgrade Venezuelan timezone (like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443202)
<ubotu> Debian bug 443202 in tzdata "Venezuelan time zone change, September 2007" [Normal,Fixed]
<Kmos> apostols__: do you have -proposed active on dapper ?
<apostols__> Kmos, No
<Kmos> 2007j-0ubuntu0.7.10
<Kmos> this is the lat one in -updates and -propopsed
<Kmos> -proposed
<Kmos> it has the changes for venezuela
<Kmos> * Replace tzdata2007i.tar.gz with new version tzdata2007j: - Updates DST rules for Venezuela.
<Kmos> https://edge.launchpad.net/ubuntu/+source/tzdata
<Kmos> as you can see here
<apostols__> Kmos, This dont workfor Dapper
<apostols__> Kmos, tzdata package dont exist in Dapper
<apostols__> Kmos, Just exist locales package
<Kmos> apostols__: it must exist
<apostols__> Kmos, dont exist in Dapper
<Kmos> you have all repositories active?
<RAOF> Kmos: He's right.  tzdata was introduced in Edgy.
<StevenK> Kmos: tzdata was split out from locales in Edgy
<apostols__> Kmos, http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=tzdata&searchon=names&subword=1&version=dapper&release=all
<Kmos> ups.. he's right..
<Kmos> StevenK: you're right
<Kmos> as always =)
<apostols__> How to fixed its?
<StevenK> apostols__: Make sure a bug is filed in Launchpad and has a task open against locales in Ubuntu Dappper
<apostols__> Oh
<apostols__> :S
<Kmos> !info locales dapper
<ubotu> locales: common files for locale support. In component main, is required. Version 2.3.18.7 (dapper), package size 3208 kB, installed size 12788 kB
<slangasek> apostols__: have you checked whether version 2.3.18.7 of locales in dapper-updates includes this fix?
<Kmos> https://edge.launchpad.net/ubuntu/+source/langpack-locales
<Kmos> slangasek: that version has the fix..
<Kmos> and it's at -updates
<apostols__> slangasek, I have installed Version: 2.3.18.7
<apostols__> slangasek, in my source.lists have deb http://ve.archive.ubuntu.com/ubuntu/ dapper-updates main restricted
<apostols__> slangasek, this package is in main tree
<slangasek> apostols__: and this version has the wrong timezone data for Venezuela?
<apostols__> slangasek, yes
<apostols__> slangasek, one second. I try test the timezone
<apostols__> slangasek, This work
<apostols__> root@arismendi:~# date
<apostols__> Sun Dec  9 02:59:53 VET 2007
<apostols__> root@arismendi:~# date
<apostols__> Sun Dec  9 02:30:01 VET 2007
<apostols__> slangasek, Thanks for you help
<slangasek> apostols__: are you saying that it works now? I don't understand what you're showing, all I see is that your clock jumped back in time by a half hour. :)
<apostols__> sladen, Yeah, this change of timezone back in time half hour (the change is -04:00 to -04:30)
<apostols__> slangasek, Yeah, this change of timezone back in time half hour (the change is -04:00 to -04:30)
<apostols__> sladen, excuseme
<slangasek> ok
<stratus> slangasek, please come back w/ my vorlon!
<infinity> geser: Have you filed a bug about the versioned build-dep thing?
<infinity> geser: Would be nice to have a way to track it.
 * Hobbsee waves
<pwnguin> which is the best way to measure a program's memory usage in GNOME?
<dholbach> good morning
<pitti> Good morning
<dholbach> hey pitti
<\sh> moins
<dholbach> hey seb128
<seb128> hello dholbach
<seb128> pitti: can you give a build retry to evolution?
<pitti> seb128: done
<seb128> pitti: danke
<seb128> pitti: ditto for nautilus? ;-)
<pitti> done
<seb128> thanks!
<TheMuso> If an archive admin is around and doing duties, could they please promote python-pyatspi from universe? Its source package, at-spi is in main. Python-atspi is needed by gnome-orca to function. Otherwise, I assume I need to file a bug to get this taken care of?
<pitti> TheMuso: no, that's fine
<pitti> TheMuso: done
<TheMuso> pitti: Thanks.
<StevenK> pitti: It seems gcrypt is still causing havoc
<StevenK> creating libqgis_core.la
<StevenK> /bin/sed: can't read /lib/libgcrypt.la: No such file or directory
<pitti> meh; can libtool finally decide where it wants to look for the .la?
<StevenK> It seems not
<StevenK> Should we put the .la in /lib, and have a symlink from /usr/lib?
<pitti> StevenK: I thought Riddell already did something like that?
<StevenK> He did?
<pitti> ah, that was in libgpg-error
<pitti> so, yes
<pitti> (bwah)
<StevenK> So, should I do the same for gcrypt?
<pitti> StevenK: either that, or we give up and revert all our patches *sigh*
<StevenK> pitti: I daresay adding a symlink should be simple-ish
<pitti> it is
<TheMuso> Is libtool just not realizing that .la files it needs to fnd or packages have moved or something?
<TheMuso> find
<StevenK> pitti: I think we need to ask for battle pay, and go on a rampage hurting the libtool authors
<pitti> TheMuso: it's behaving bizarre
<pitti> TheMuso: the basic problem is that libtool seems to have no way to install a lib into /lib
<TheMuso> pitti: No kidding.
<pitti> so, if it's there, it sometimes looks for the .la in /usr/lib, and sometimes in /lib
<TheMuso> Right.
 * StevenK hacks libgcrypt11
<StevenK> pitti: Real file in /lib or /usr/lib?
<pitti> StevenK: /usr/lib, I'd say, but it shouldn't matter much
<pitti> just for consistency with libgpg-error
<soren> dpkg uploaded.
 * soren starts to sweat uncontrollably
<pitti> wooo!
<StevenK> Hah
 * pitti congratulates soren for being TIL now
 * seb128 hugs soren
<soren> pitti: :p
<StevenK> pitti: Giving libgcrypt11 a nice hard test build before uploading
<soren> I've been looking into kvm and qemu a lot lately, and I've stumbled upon bug 64501.
<ubotu> Launchpad bug 64501 in openhackware "FTBFS" [Critical,Triaged] https://launchpad.net/bugs/64501
<soren> It's an arch: all package that needs to be built on powerpc.
<soren> Would be acceptable to change that package to be arch: powerpc, build it, and make an arch: all package that ships the resulting files (kind of like ia32-libs for amd64)?
<pitti> eww
<soren> I know :)
<pitti> soren: why not just keep it as Arch: powerpc?
<soren> Better suggestions?
<soren> Because it's a BIOS image that qemu needs on other archs as well.
<pitti> ah
<soren> ..to be able to emulate powerpc.
<soren> And it only builds on powerpc.
 * pitti rolls back to "Eww"
<StevenK> Hah
<pitti> soren: do you know why it can only be built on powerpc?
<pitti> does it actually compile the bios?
<soren> AFAIR, yes.
<TheMuso> soren: I can test build on PowerPC if you need it tested before you upload.
<soren> TheMuso: I have access to a powerpc machine, but thanks for the offer!
<TheMuso> soren: Ok no problem then.
<soren> pitti: It might just be the case that my crossbuild-fu isn't strong enough.
<StevenK> Or that dpkg stole it
 * StevenK sniggers, and feeds soren's complex
 * soren whimpers
<StevenK> pitti: libgcrypt11 uploaded, and I've upped my bounty on the libtool developers.
<pitti> great, thanks
<pitti> /msg StevenK let's have a good beating at it in the afternoon
<StevenK> The bounty, the developers or libtool? :-)
<Treenaks> StevenK: hmm.. are those devs in paris?
<pitti> libtool; I'm not *that* cruel :)
<StevenK> Treenaks: I'm only naming the guilty party.
<StevenK> :-P
<pitti> StevenK: for the developers, my evil plan is to lock them into a room with libgpg-error and libtool, and not allow them to come out again until they made it work right
<StevenK> pitti: Add libgcrypt11 and cryptsetup with /usr on a seperate partition, and you have my vote.
<Hobbsee> soren: how the *hell* did you manage to bork dpkg like that?
<soren> Hobbsee: :p
<Hobbsee> YOU BROKE IT!  BAD SOREN!
<soren> Hobbsee: You should at least until the thing has actually built and been published before trying that :)
<Hobbsee> soren: haven't you heard that buildd admins can see, even before others can, and can smell breakage almost immediately?
<soren> Hobbsee: No, I must have missed the memo.
<Hobbsee> soren: now you know.
<soren> Noted :)
<soren> You know... One day, a long time from now, I'll stumble upon that note, and wonder why "buildd admins have superhuman sense of smell".
<soren> I could make it even more cryptic and make it say "buildd admins smell really well".
<Hobbsee> haha
 * Hobbsee has uploaded dpkg before, and only just survived to tell the tale
<StevenK> soren: You could make it an in-joke and s/ really well//
 * StevenK hides from Hobbsee, pitti and Mithrandir
 * Hobbsee beats StevenK 
<StevenK> Ouch!
<soren> Hobbsee: That's odd. I don't see your name in the changelog?
<Hobbsee> soren: i sponsored a change
<soren> Hobbsee: Oh.
<Hobbsee> then had iwwj attempting to eat me
<StevenK> Who's change did you sponsor?
<StevenK> Oh damn
<StevenK> pitti: Can you reject libgcrypt11?
<pitti> StevenK: no
<StevenK> Drat
 * StevenK quickly uploads a new version
<pitti> StevenK: nowadays sources wander straight into DONE
<pitti> no reject-from-accepted any more
<StevenK> Bad Soyuz
<StevenK> There we go, uploaded
<Hobbsee> StevenK: no, it's just more efficient now :P
 * StevenK raises an eyebrow.
<Hobbsee> you're complaining about it being more efficient?
<StevenK> It introduces that you can't reject uploads, and besides, it seems to wait until sources are published before creating build records
 * StevenK idly wonders if Soyuz deals with Pending -> Superseded
<StevenK> Hrm. So far both -2ubuntu6 and -2ubuntu7 are Pending
<ogra> urgh, somewhitng really weird happened to my fonts since the last update
<ogra> ah, restarting FF helps :)
<pitti> StevenK: no, it doesn't; build records can be created immediately after upload
<pitti> of course it actually takes eons, but it's not tied to publishing
<StevenK> Oh right, so it the build machinery just taking that long, and not waiting for the publisher
<pitti> right
<pitti> StevenK: ideally build records would be created immediately on accepting, and that's in fact the plan
<lool> Is it easy to run my own local CD builds, perhaps with locally modified packages or package lists, to have ISOs to run in emulators?
<lool> Or are you people using daily images and pushing changes via hardy to see how they affect the live CD? :)
<soren> Hmm... I'm trying to determine what changed in debian-policy between 3.7.2.2 and 3.7.3... The changelog lists only bugfixes afaics, but that would usually cause the version to be bumped to 3.7.2.3 rather than 3.7.3.0 wouldn't it?
<lool> soren: Well there are some changes in upgrading-checklist such as using ${binary:Version} instead of ${Source-Version} which are required by the new version
<lool> soren: Or the recommendation to link to the GFDL in /usr/share/common-licenses instead of copying it
<soren> lool: Hm.. Ok. That's it?
<lool> soren: There are other things as well; upgrade-checklist lists some stuff which you probably wouldn't want to care about, but it has some useful bits I think
<lool> I don't think it's very useful to mention "may do" stuff when it's already widely done for example :)
<soren> lool: I'm just looking for a list of functional changes (not just fixed typos or whatever), so that I can tell if I can update my package to "Standards-Version: 3.7.3". :/
<lool> soren: Well upgrade-checklist is meant to be exactly this
<soren> lool: Ah...
<soren> lool: Ok, now I get it. :) Thanks.
<lool> It's a bit too long to my taste, but it's supposed to list effective things you should check when upgrading to a newer standard-versions
<lool> On my packages, I'd probably double-check binary:Version, check copyright for GPLv3 or GFDL, check menu sections (but probably lintian would tell me anyway), and that's probably all I'm using
<soren>       * The Source field in a .changes file may contain a version number
<soren>         in parentheses.
<lool> Yeah, that's really a lot of chatter for something probably two people care about
<soren> That sounds odd.
<soren> lool: Ok. Thanks for pointing out upgrade-checklist a sufficient number of times for me to actually get it. :)
<lool> soren: Ah you didn't know about the fiel?
<soren> lool: Nope.
<lool> I discovered it after a lot of time too; but it's mentionned in the changelog this time around :)
<soren> Oh, really?
<TomaszD> who can I speak with about whitelisting a laptop for acpi?
<cjwatson> lool: it's unfortunately tedious to run one's own CD builds
<cjwatson> the code's all there, but it's something of a pain to set up
<cjwatson> if you need it, I can help you
<cjwatson> you also need a full local mirror, at least of main and restricted
<soren> lool: Well, even if it did, I wouldn't have considered looking at it. I think I expected it to be a checklist for when upgrading packages, like: "Make sure if files move, you put conflicts: and replaces:" or something. I didn't put much thought into the matter, clearly.
<cjwatson> the Source thing is support for dpkg experiments I think
<TomaszD> someone resigned from triaging my bug and I've been waiting for nine months
<TomaszD> https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/92806
<ubotu> Launchpad bug 92806 in linux-source-2.6.22 "N340S8 laptop needs to have ACPI enabled" [Undecided,Confirmed]
<lool> cjwatson: Is it ok to have a http_proxy like squid?
<cjwatson> lool: no, it really needs a mirror on disk
<lool> Ah
<lool> That sounds like many intermediate steps to reach the point where I can do actual tests; I think I'll defer that a little then
<cjwatson> I suppose you could mount one with something to do with fuse over a squid proxy but argh
<lool> cjwatson: Is it easy to override packages or package lists -- bit still keeping the mirrors a clean true mirror?
<lool> s/bit/but
<cjwatson> lool: the cdimage code has some (unused for some time) support for local packages
<cjwatson> back when we were doing warty it took a while to get Ubuntu itself into shape, so I had local overrides of a few packages in cdimage in order to be able to build installable CDs
<cjwatson> that would be easier than changing the mirror
<lool> Ok; perhaps I'll just boot a CD and use casper USB persistence if that's still available to install my experiments and see how to do that properly later
<cjwatson> typically I just modify things on the fly if I need to do this sort of test, I must admit
<lool> Ok; thanks for the info
<cjwatson> I do think it would be useful to have a facility for this eventually, but no capacity for it for hardy ...
<cjwatson> (as in a proper user-oriented facility for customising CD images; we talked about it at UDS)
<lool> cjwatson: If I wanted to look into building hardy daily images, where should I start?  I think it's "ubuntu-cd"?
<cjwatson> http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ and also check out the bits listed in configs/devel
<soren> cjwatson: How do you usually test stuff like gfxboot and isolinux then? Extract an existing iso, replace the relevant files, re-mkisofs, test?
<cjwatson> soren: I have a little manually-driven test suite for the gfxboot theme
<lool> cjwatson: Noted, thanks
<cjwatson> it's just a thing where I can do 'make -C test' and it fishes stuff out of known places in my local directory layout
<cjwatson> I don't use a full tree for it, just a few files that are enough to test the theme
<soren> cjwatson: Alright.
<cjwatson> soren: http://people.ubuntu.com/~cjwatson/tmp/gfxboot-test.tar.gz
<cjwatson> bit dated but hasn't changed much either
<cjwatson> pitti: I assume you'll want another d-i for dapper-proposed?
 * soren looks
<pitti> cjwatson: yes, please; if that lbm ever condescends to build
<pitti> but yeah, having d-i in the queue would be great
<LongPointyStick> where's my supersonic jet?
<soren> cjwatson: Ah, clever.
<cjwatson> pitti: heading queuewards now
<soren> LongPointyStick: Where are you going in that?
<pitti> Riddell: do you know about libkarma? the MIR (https://wiki.ubuntu.com/MainInclusionReportlibkarma) is almost useless
<pitti> Riddell: does it actually work on a standard Ubuntu kernel? the cited pmount bug is long obsolete
<Riddell> pitti: I'm told it does yes
<cjwatson> TomaszD: the bug was confirmed so there was no longer a need for a triager anyway
<cjwatson> TomaszD: odd though, the patch for your system still seems to be there
<TomaszD> cjwatson, indeed, but it doesn't work :(
<TomaszD> after dapper or edgy I have to acpi=force in menu.lst
<cjwatson> TomaszD: yeah, it's just that you explicitly said the patch was removed and I don't see that it was
<cjwatson> so trying to work out what happened
<TomaszD> cjwatson, ok. You know IANAE, but I thought that once I don't have the functionality the patch must have been dropped by mistake
<cjwatson> TomaszD: to be clear, we're talking about ACPI sleep, right?
<pitti> asac: xulrunner MIR> when we will switch firefox to 3 by default?
<cjwatson> (you just said "ACPI" in the bug)
<TomaszD> cjwatson, we're talking about turning on ACPI at all
<TomaszD> cjwatson, because I get the message about the bios being to old and going under the bios cut-off age
<cjwatson> err, acpi-support doesn't have one of those
<TomaszD> cjwatson, so it's not whitelisted then?
<cjwatson> perhaps it would help if you copied the *exact* message you're seeing into the bug
<asac> pitti: in january i guess ... there is still too much work going on upstream to not cause any confusion ... for now i need xul 1.9 in main to update all the other rdepends.
<seb128> mdke: any news about the yelp layout patch update?
<asac> pitti: maybe b2 will be good enough though (which will be next week i guess)
 * pitti switches his desktop to ffox 3 for testing love
<TomaszD> it appears just for a second, it says your bios falls under the bios cut-off age, because it's older than 1998 (which isn't true, it's 2002), so acpi functions will have to be forced to be enabled cjwatson
<pitti> asac: ah, I see; but we'll definitively drop 2 for hardy
<cjwatson> TomaszD: I've commented on the bug; it's not an acpi-support problem, it's a kernel problem
<asac> pitti: yes. we cannot support ffox 2 for such a long time
<TomaszD> whenever I install a new version of ubuntu cjwatson I just go menu.lst and acpi=force there, I got used to it, but acpi was working in dapper
<asac> pitti: as proposed in https://wiki.ubuntu.com/XulrunnerGecko ... we will allow universe rdepends to switch to xulrunner 1.8 ... in case they don't get ready in time.
<cjwatson> I imagine the kernel got stricter
<pitti> asac: ah, so in ffox 3 I don't have those ugly typewriter fonts (as broken by recent fontconfig), but I don't have the smooth fonts either; but slightly better, I'd say :)
<asac> pitti: yeah ... there is a request to patch xulrunner for subpixel stuff (bug 164640) ... maybe thats the problem?
<ubotu> Launchpad bug 164640 in xulrunner-1.9 "Build Firefox 3 against a subpixel-patched cairo" [Undecided,Confirmed] https://launchpad.net/bugs/164640
<pitti> asac: I guess so
<pitti> asac: ok, promoted
<asac> pitti: rock!
<pitti> asac: but what's wrong with switching to 3 early? after all, testing is why we all run hardy now?
<seb128> xulrunner1.9 promoted?
<seb128> which means we can build the GNOME packages using it now?
<asac> seb128: yeah ... if you apply the patches i have ;)
<asac> seb128: https://code.edge.launchpad.net/~mozillateam/xulrunner/xulrunner-porting
<asac> there is yelp, devhelp and epiphany ... though epiphany is against current trunk
<asac> i will add the python gtkmozembed today i hope (after cleaning things up)
<asac> seb128: ah ... totem is in that xulrunner-porting thing as well
<pitti> cjwatson: WDYT about libssh? There's a MIR for it, but I have some concern about having two ssh implementations in main
<asac> pitti: i wanted to fix xulrunner to consider all the needed plugins/extensions directories before making firefox-3.0 default ... otherwise we will end up installing plugins in a place that is not ment to be the final one.
<pitti> asac: ah, that's a good point, yes
<seb128> asac: do you want to do the upload or should have a look to that? I've nothing special to do this afternoon so I'm fine looking at the changes and the wiki page I said I would read the other day and upload the xulrunner versions ;-)
<asac> seb128: i would prefer if you could take the uploading part and maybe even upstream submission
<asac> seb128: before you touch a package better ask me for any regression i know of ... so you can decide if its good enough for initial upload
<asac> to start with: yelp patch has no known regression for me
<seb128> asac: ok, will do that after lunch then, thanks
<asac> seb128: nothing to hurry ... you need to wait till the xulrunner-1.9 package i uploaded today is build because it changed the names of the .pc files to the final ones
<seb128> asac: ok
<cjwatson> pitti: since openssh is never likely to provide a library, it doesn't hugely bother me
<pitti> cjwatson: yeah, but it just feels...wrong
<cjwatson> your call
 * gicmo yawns
<LongPointyStick> for the love of the great green arklesneezer, this is absolutley ridiculous!
<LongPointyStick> grr!
<Nafallo> hmmm
<Nafallo> LongPointyStick: what now?
<LongPointyStick> my system has frozen 4 times in the past 10 minutes!
<LongPointyStick> that's a new low for hardy.
<LongPointyStick> tjaalton: where should i start looking as to why it's freezing?
<dholbach> MOTU Q&A session in 11 minutes in #ubuntu-classroom
<tjaalton> LongPointyStick: well, there have been no updated x-packages lately, to my knowledge :)
<LongPointyStick> tjaalton: this has happened for a while, but seems worse atm.
<LongPointyStick> oh, interesting.  compiz is showing 100% cpu
<ogra> compiz was updated today :)
<ogra> and yesterday
<tjaalton> well, there you go :)
<LongPointyStick> and now it behaves, with another machine ssh'd in
<Hobbsee> or not.
<StevenK> Heh
<asac> hmm on lpia i get a strange build failure for xulrunner-1.9 : http://paste.ubuntu.com/2524/
<Nafallo> compiz doesn't do the newer Intels yet, right?
<Hobbsee> Nafallo: this isnt' really a newer intel
<Nafallo> Hobbsee: was more of a general question dear :-)
<Nafallo> GM965 / X3100 or so.
<Hobbsee> oh
<asac> pitti: maybe the promotion in the mids of a xul build caused these "failed to upload" errors? https://edge.launchpad.net/ubuntu/+source/xulrunner-1.9/1.9~b1+nobinonly-0ubuntu2
<Hobbsee> tjaalton: actually, i don't think you get blamed for this.  it appears that compiz shows 100% CPU and locks up (while the programs all still run), when more than 1 active "notify me" window is there.
<pitti> asac: right; let me give them back
<Hobbsee> asac: yes, that's correct
<asac> pitti: thanks!
<torkel> Nafallo: they removed the blacklistning of 965 in -0ubuntu3
 * asac lunch
<Nafallo> torkel: cheers. sounds scary 'nough to update according to Hobbsee though ;-)
<Nafallo> ...and Fujitsu
<Hobbsee> Fujitsu: you still around?
<pitti> asac: is there a way to tell gnome to use ffox-3 as my prefered application? it opens ffox 2 on clicking on a link ATM, but ffox 2 doesn't appear in gnome-default-applications-properties
<lool> pitti: You can set a manual command?
<lool> pitti: %s for the URL
<pitti> yeah, of course
<pitti> but it shuold still appear there
<lool> It needs to be patched in control-center IIRC
<seb128> pitti: how is the binary called?
<pitti> firefox-3.0
<pitti> oh, it's hardcoded there?
<lool> Yeah
<pitti> I thought it was some .desktop file somewhere
<pitti> after all, even lynx appears there :)
<lool> I think it has a mapping
<seb128> pitti: /usr/share/gnome-control-center/gnome-default-applications.xml has the list of known applications
<pitti> seb128: aah, I understand; thanks
<seb128> need to patch gnome-control-center
<seb128> I'll do it
<pitti> seb128: well, shouldn't be necessary in the end
<pitti> seb128: once we ship 3 by default, the binary will be 'firefox' (hopefully :) )
<seb128> if the binary is renamed firefox no need to rename
<seb128> right
<pitti> I just wondered by which mechanism a package appears there
<pitti> so I was concerned that ffox-3 needs to ship a .desktop file for that, or so
<seb128> that would be a better way to do things
<seb128> but at the moment the list is in gnome-control-center
<pitti> seb128: ok; nevermind then
<pitti> and thanks for the explanation
<seb128> you are welcome
<xhaker> seb128, can i discuss default torrent client for Ubuntu with you?
<seb128> xhaker: if you want too, I'm not sure I'm the best person for that discussion though since I don't know the alternatives nor use bittorrent
<xhaker> seb128, just thought you were appropriate since you are a "gnome" guy. My take is that gnome-btdownload + bittorrent should step back
<xhaker> I've been thinking to myself, that Transmission is very much the best for a default torrent client
<xhaker> While trying out fedora8 live through an usbkey, i noticed they have transmission there. :) I wish we could do the same.
<seb128> xhaker: maybe mail ubuntu-desktop or ubuntu-devel-discuss list about some rational on why you think transmission is better
<seb128> I think some people did in the past but other users replied that transmission was not stable and crash all the time, etc
<xhaker> seb128, it might be true.. but i've been following the development.. they're really active.. and they're running up for the 1.0 release.. last version on the repositories is 0.95
<xhaker> Will send my rationale to ubuntu-desktop ml
<seb128> xhaker: is there anybody looking at the launchpad bugs for transmission? like an upstream guy?
<azeem> just because they call it 1.0 doesn't mean it's bug-free
<seb128> that would show they have interest to have it used in ubuntu ;-)
<seb128> xhaker: thanks
<xhaker> azeem, it means they're pretty confident it'll be good.. check their trac page.. they look into HIG, and there are lots of worrying with memory leaks :D
 * ogra wonders if there is a way to compile dillo with xulrunner now :P 
 * xhaker is not smart enough to understand why debian and ubuntu build-depend differently in respect of xulrunner-dev and firefox-dev
<poningru>  xhaker please also add deluge to the possibility of default torrenting clients
<xhaker> poningru, don't get me wrong.. I'm using deluge right now.. I have both clients installed.. but Transmission is leaps ahead in ease of use
<ogra> xhaker, lawyers will uderstand that :)
<xhaker> poningru, it just downloads, and does a good job at that. :) hence the proposal for shipping in the default install
<poningru> xhaker, ah k
<poningru> someone also needs to solve the natting problem with those things
<poningru> as in some client program that works with routers that automatically adds a port
<poningru> forwarding
<xhaker> Transmission will use http://miniupnp.free.fr/ projects.. provides upnp and natpmp
<xhaker> It will maybe handle more routers than their solution now
<pitti> seb128: I assume totem-pl-parser should go into main?
<seb128> pitti: yes
<seb128> pitti: totem will depends on it when it's accepted
<seb128> pitti: danke ;-)
<pitti> seb128: looks good to me, accepted
<pitti> *whistle* NEW is empty again
 * Hobbsee uploads more
<ScottK> pitti: Did you figure out how to remove crack from partner yet?
<pitti> ScottK: yes, it's actually gone; I just didn't close the bug yet
<ScottK> pitti: Great.  Thanks for that/
<ScottK> /.
<Nafallo> ehrm
<Nafallo> "remove crack for partner". that can be quite misunderstood ;-)
<pitti> BenC: re lbm patch> I sent a mail about that this morning with a pointer to the patch
<BenC> pitti: oops, must have missed that, sorry
<pitti> BenC: no problem; it's attached to bug 164449, so you can grab it from there
<ubotu> Launchpad bug 164449 in linux-backports-modules-2.6.15 "undefined symbols in mptspi driver" [High,Fix released] https://launchpad.net/bugs/164449
<Hobbsee> BenC: can i ask when we get l-u-m for .24?
<BenC> Hobbsee: before monday
<Hobbsee> BenC: \o/
<pitti> cjwatson: wrt. getting the noptrace group into base-passwd; do you think we should discuss abusing an existing group and put that into a meeting (TB or whatever), or shall I file a bug about adding 'noptrace' to base-passwd?
<cjwatson> I'd like it to be discussed on debian-devel
<cjwatson> base-passwd is one package I really don't want to be out of sync
<cjwatson> and I want complete propriety in how changes to the master files happen
<pitti> ok, I'll send a mail there
<cjwatson> thanks
<ScottK> Nafallo: Pick a better word that characterizes uploading software to a public repository with known remote code exploits unpatched?
<keescook> mornin'
<Nafallo> ScottK: foolness. what did I do now?
<ScottK> Nafallo: Not you.  I was responding to your comment about crack and partner.
<Nafallo> ScottK: ah :-)
<lool> I don't understande why some uploads to hardy-changes aren't signed
<cjwatson> lool: syncs are unsigned
<lool> 3.16.0-4ubuntu1 => probably not a sync; I think the body of the mail has in fact a signature, but Mutt doesn't recognize it as such
<cjwatson> we just copy those from Debian, and they're done on a trusted system and inserted through basically a back door in the queue system rather than inventing a fake key to sign them with
<cjwatson> ah
<lool> Either an encoding issue or a Mutt bug
<cjwatson> ScottK: not that it was the right thing to do; but we did know that the problems in openssl097 did not affect vmware
<ScottK> cjwatson: I understand that.  That was no where publically documented and certainly doesn't help a bit when people (our competition) says ubuntu-server isn't secure enough to take seriously.  The percpetion (if not the fact) was very poor.
<ScottK> It also pained me personally after investing a lot of time in getting it removed from Universe.
<lool> Ah it's UTF-8
<lool> That's the data confusing Mutt
<cjwatson> ScottK: I know, we still have work to do on a proper response that includes documentation on what will be allowed in partner; it's in progress ...
<ScottK> cjwatson: Good to hear.  Thanks.
 * ScottK grumbles again that it'd be better if Partner were more clearly a Canonical production than an Ubuntu one.
<cjwatson> what can we do to make that clearer?
<cjwatson> or, perhaps a fairer question, in what places is it currently unclear?
<ScottK> In LP it's not clear at all.
<ScottK> For example, bugs against things in Partner are described as "in Ubuntu"
<cjwatson> hmm, I didn't realise that packages in partner showed up under Ubuntu
<cjwatson> I agree that that's unfortunate
<cjwatson> (or perhaps I did know and forgot)
<ScottK> If you go to the front page for the 7.10 release, Partner is listed as just another repository.
<ScottK> cjwatson: There's an LP bug.  Let me find it.
<cjwatson> I don't see partner mentioned on /ubuntu/gutsy
<ScottK> cjwatson: Bug #153798
<ubotu> Launchpad bug 153798 in soyuz "canonical partner repo packages showing as "in ubuntu"" [Undecided,Confirmed] https://launchpad.net/bugs/153798
 * ScottK looks again
<cjwatson> ah, it's on /ubuntu
<ScottK> Yes.  Sorry about that.
<ScottK> That's actually worse.
<cjwatson> followed up to the bug
<ScottK> cjwatson: Thanks.
<cjwatson> (not with good news, I'm afraid)
<ScottK> cjwatson: I understand your answer, but as a non-Canonical developer, it's very frustrating.
<blueyed> mjg59`: are you planning to merge powernowd? I've collected a whole bunch of fixes in the last days, which are attached to bug 67341. If you like, I could do the merge and include those - then you could just sponsor it.
<ubotu> Launchpad bug 67341 in powernowd "powernowd doesn't use /etc/default/powernowd anymore" [Low,Triaged] https://launchpad.net/bugs/67341
<geser> pitti: please give-back: compiz-fusion-plugins-extra
<cjwatson> ScottK: some things are frustrating both inside and outside Canonical ...
<ScottK> ;-)
<pitti> cjwatson: d-devel@ mail about ptrace() sent; let the flamefest begin :)
<pitti> keescook: ^ I BCCed you to that FYI
<keescook> pitti: cool; thanks.
 * pitti blinks
<pitti> cjwatson: I just wanted to add a gutsy task to your SRU bug, but guess which release is missing on https://bugs.edge.launchpad.net/ubuntu/+source/finish-install/+bug/174689/+nominate
<ubotu> Launchpad bug 174689 in finish-install "hvc/hvsi consoles not handled" [Undecided,New]
<pitti> cjwatson: any idea why?
<cjwatson> because I targeted it myself 10 minutes ago or so
<pitti> ah, heh; sweet race
<pitti> thanks
<pitti> I stared at the check boxes for at least 10 seconds until I realized :)
<cjwatson> might be worth a Malone bug
<geser> pitti: please give-back: gdome2-xslt
<geser> pitti: please give-back: ocamlgraph
<pitti> geser: both done
<geser> pitti: please give-back: compiz-fusion-plugins-extra
<pitti> done
<geser> thanks
<Eckzillor> Hello
<sistpoty> hi folks
<pochu> hiya sistpoty
<sistpoty> hi pochu
<geser> should build-dependencies on gs-common be replaced with ghostscript or is build-depending on gs-common still ok (especially for a package in main)?
<tjaalton> any hal experts around?
<Burgundavia> tjaalton: you might be better to ask in #hal or #gnome-hackers on gimpnet
<tjaalton> Burgundavia: right, I'll do that if I can't figure it out myself eventually
<tjaalton> the problem, that is
<AgentHeX> i've got a bug in the gnome power manager where the display brightness will "dim" to a value higher than what i manually set with the keyboard shortcut when it thinks i'm idle.  i would like to fix this bug.  what should i download to take a look?
<ScottK> AgentHeX: I have a vague recollection that there was a bug on this already.  Dunno if it's been fixed in Hardy or not.
<AgentHeX> ScottK: i'm on gutsy right now.  i was kind of looking for an introduction to developing in ubuntu.  i'm a C++ coder but i have little experience coding in linux, and i'm looking for a way i can explore.  any hints?
<ScottK> Sorry.  I'm a KDE person.
<AgentHeX> ScottK: i'm pulling eclipse atm, so i'll have that soon, and i figured the gpm bug might be a good start
<AgentHeX> ScottK: how might i go about getting the source for the gnome power manager?
<ScottK> I'd suggest looking for the gdm bug and seeing what's already there (it had a proposed patch, dunno how good it is).
<slangasek> "apt-get source gnome-power-manager"
<AgentHeX> ah
<AgentHeX> slangasek: i was looking in synaptic.
<ScottK> AgentHeX: First lesson is developers will taunt you if you insist on using GUI tools and not command line.
<slangasek> they will?
 * slangasek covers up his update-manager
<Nafallo> hmm. I use sudo update-manager from a terminal ;-)
<AgentHeX> ScottK: i would *rather* use a GUI IDE, but i *could* use a CLI
<ScottK> You'll get over it ;-)
<AgentHeX> ScottK: i'm familiar enough with vim that i prefer it to a generic text editor (gedit, notepad, et al), and it's proably a good thing since i'm on a laptop and the touchpad is kinda annoying
<ScottK> Excellent.
<ScottK> I think your basic strategy of find stuff that annoys you and try to fix it is a good one.
<AgentHeX> ScottK: but i'd still rather use a gui.  if there was a gui version of vim, i'd be in heaven.
<ScottK> I think there is, but I don't recall for sure.
<tkamppeter> pitti. hi
<AgentHeX> ScottK: i'm kinda kidding.  what's the point of having a gui version of vim anyway?  it's designed to be lightweight.  that gui adds tons of cruft
<AgentHeX> ScottK: now once i actually have the source for the package, how do i go about compiling it?  will i need source for all the dependencies as well?
 * ScottK has no idea, but it's FOSS, so all it takes is one coder who feels liek it.
<AgentHeX> i'm pretty sure apt-get source will drop the source in my /usr/src path.  can you confirm?
<ScottK> No, it'll drop it into the current working directory.
<AgentHeX> ah...  do not want in home
<ScottK> https://wiki.ubuntu.com/PackagingGuide/Howtos/BuildingTheSourcePackage?highlight=%28build%29 is a start on how to compile it.  It'll lead you to other quesitons, but I have to run.
<Kopfgeldjaeger> n8
<tophat> has anyone used git instead of svn?
<tkamppeter> doko, did you upload hplip and hal-cups-utils for me?
<geser> tkamppeter: is the new dpkg already built?
<geser> tkamppeter: the current version of hplip needs the newer dpkg for building
<AgentHeX> ScottK: how might i go about running a modified gpm?  do i need to replace the original and hope i don't bork my system?  how might i debug something like gpm?
<slangasek> AgentHeX: anyway, "vim-gnome" :)
<doko_> tkamppeter: yes
<AgentHeX> slangasek: hah.  nice
<tkamppeter> doko_: Thank you very much
<AgentHeX> oh snap.  i can't see my appearances window to turn off compiz.
<AgentHeX> HAH!  i did it blind!
<tkamppeter_> geser, I have taken HPLIP from the Debian RPM as I am working together with Mark Purcell from Debian on the maintenance and so our packages and Debian's are the same.
<tkamppeter_> On this build I had a problem and I had to remove "--dpkg-shlibdeps-params=--ignore-missing-info" from dh_shlibdeps in debian/rules.
<tkamppeter_> My system is a Hardy which I have updated today.
<tkamppeter_> geser, would this mean that I can reintroduce this "--dpkg-shlibdeps-params=--ignore-missing-info" on dh_shlibdeps as soon as the newest dpkg hits Hardy?
<tkamppeter_> dpkg --version
<tkamppeter_> Debian `dpkg' package management program version 1.14.12ubuntu1 (i386)
<tkamppeter_> s/Debian RPM/Debian SVN/
<geser> tkamppeter_: if I understand it all correctly, yes
<tkamppeter_> geser, so which version dpkg must be so that I can re-introduce  "--dpkg-shlibdeps-params=--ignore-missing-info" on dh_shlibdeps?
<geser> --ignore-missing-info was introduced around .8 or .9 and .12 is getting build now
<slangasek> tkamppeter_: if you're working with hplip, how about fixing it so that it has a proper shlibs file and doesn't *need* the --ignore-missing-info?
<geser> according to the changelog --ignore-missing-info works since dpkg 1.14.8
<tkamppeter_> So strange that it did not work with 1.14.12ubuntu1
<slangasek> I don't know what possessed the maintainer to do that instead of looking at the reason why dpkg-dev thought the package was wrong :P
<tkamppeter_> Mark Purcell has introduced --ignore-missing-info. I do not even know for what that is good for.
<slangasek> it's to stop dpkg-shlibdeps erroring out with a message about missing shlibs for a library dependency
<slangasek> and the reason dpkg-shlibdeps was erroring out was because he has a library that's missing a shlibs file (required by policy), which means the package interdependencies are wrong
<tkamppeter_> HPLIP seems to build and install fine without --ignore-missing-info.
<slangasek> not with the new dpkg
<geser> should build-dependencies on gs-common be replaced with ghostscript or is build-depending on gs-common still ok (especially for a package in main)?
<tkamppeter_> geser, I think this can be moved to ghostscript. ghostscript has a transitional package gs-common, but things should depend on the main package.
<slangasek> note that the "ghostscript" package doesn't exist in dapper, so this will affect ease of backporting
<geser> slangasek: it's a change for graphviz, see bug #174749
<ubotu> Launchpad bug 174749 in graphviz "[hardy] Drop libttf-dev from Build-Depends" [Undecided,New] https://launchpad.net/bugs/174749
<geser> gs-common is in universe but ghostscript provides gs-common so build-depending on it should work, but to be on the safe side I changed it
<slangasek> there's no need here to be "on the safe side".  It's perfectly valid to build-depend on virtual packages
<slangasek> and as I said, build-depending on "ghostscript" is an additional change that has to be made for backports (as well as increasing the size of the Ubuntu delta here, of course)
<ScottK> slangasek: If it doesn't exist in Dapper, then I'd just backport ghostscript first (no regression risk).
<geser> so I should revert it back to gs-common?
<slangasek> ScottK: uh?  in what sense is there no risk of regression?  it's a complete reorganization of the source packages
<geser> ScottK: I guess ghostscript was called gs-somehting in dapper
<ScottK> slangasek: I haven't actually looked at it, but generally if a package doesn't exist, it's good for backporting (I do check before I actually approve these things).  Nevermind then.
<slangasek> ScottK: right; this isn't a "ghostscript doesn't exist in dapper", it's a "someone thought it would be clever to rename all the ghostscript-related packages in Debian because renaming is FUN"
<ScottK> slangasek: Ah.  Yes.  That'd be totally different.
<ScottK> slangasek: I'd say you got the first two letters right.
<slangasek> sorry for my hash collision
<slangasek> :)
<tkamppeter_> geser, gs-common is in Universe? I thought we have taken it from the distro? It does not make sense any more with the new ghostscript. ghostscript contains everything now. So please remove gs-common from the Universe.
<tkamppeter_> geser, in dapper the default ghostscript was gs-esp, as alternative there were also gs-gpl and gs-afpl.
<ScottK> tkamppeter_: Does it have any rdepends left?
<tkamppeter_> slangasek, we decided on renaming it /the Debian maintainer and me) to make it searchable more easily. Searching for ghostscript gives better results than for gs.
<tkamppeter_> and with the merger of ESP and GPL Ghostscript (http://www.cups.org/espgs/) which I have done this year all gs-... got obsolete.
<tkamppeter> ScottK, what are rdepends?
<slangasek> tkamppeter_: a) gs-common is being built from the ghostscript source as a dummy package, to facilitate smooth upgrades; I'm not sure why it needs to be a transitional package instead of just the gs-gpl and gs-esp packages, but that's the rationale given. b) "apt-cache search ghostscript" already worked fine?
<tkamppeter> slangasek, is it not the case that for every package which my new package replaces I have to provide a transitional package? And ghostscript replaces gs-common.
<slangasek> tkamppeter: you just said "please remove gs-common from the Universe", how exactly do you expect it to be removed and still be a transitional package?
<slangasek> the gs-common package in universe /is/ the transitional package
<slangasek> as for whether every package needs a transitional package, no; you generally only want transitional packages for things that an end-user is likely to install directly
<tkamppeter_> slangasek, so "apt-get dist-upgrade" would work also without transitional packages? Only "apt-get install gs-common" needs them?
<tkamppeter_> slangasek, then with the gs-common in Universe being the transitional package everything is OK. Nothing needs to be removed.
<slangasek> tkamppeter_: "apt-get dist-upgrade" would not do what you want without /some/ transitional packages.  But I think users are unlikely to have gs-common alone installed, right?  They're likely to have gs-esp or gs-gpl installed?
<slangasek> tkamppeter_: in which case, you only need to provide transitional packages for gs-esp and gs-gpl, since gs-common would be sorted out according to dependencies
<tkamppeter_> slangasek, I understand, gs-common is like a lib... package which does not make sense alone. So can I take it out on the next ghostscript packaging then?
<slangasek> tkamppeter_: since ghostscript also has a Provides: gs-common that will meet the needs of reverse-deps, that's what I would suggest, yes
<tkamppeter_> slangasek, OK and thanks for the help.
<slangasek> sure
#ubuntu-devel 2007-12-08
<tkamppeter_> slangasek, geser. with today's updates --ignore-missing-info in HPLIP works again.
<tkamppeter_> Should I re-introduce --ignore-missing-info in HPLIP's Debian SVN or leave it away for backportability?
<slangasek> tkamppeter_: as I said above, --ignore-missing-info is the wrong solution to the problem
<slangasek> tkamppeter_: the real problem is that hplip contains a library, which binaries in the hpijs package link against, but there's no proper shlib declaration for this relationship
<slangasek> so hpijs just depends on "hplip", which is wrong, because future versions of hplip may ship a lib with a different soname
<tkamppeter_> slangasek, so I will inform Mark Purcell.
<slangasek> ok
<slangasek> or if you like, I can file a bug on the Debian package this weekend
<tkamppeter_> slangasek, this would be great. Please do it.
<StevenK> keescook: Membership to u-u-s; thanks
<StevenK> keescook: Membership fixed, that is -- sorry, I'm a bit scatterbrained today
<Fujitsu> Hobbsee: Apparently not.
<Hobbsee> :)
<minghua> I wonder if there is enough interest to improve the texlive packages in gutsy.
<minghua> The texlive stuff in gutsy is not particularly in good shape, and with the recent security upgrade, people are start seeing upgrade failures, such as bug 174569.
<ubotu> Launchpad bug 174569 in texlive-bin "postinst failure during gutsy security update" [Unknown,Fix released] https://launchpad.net/bugs/174569
<minghua> TeXlive upstream developers, as well as Debian texlive maintainer, Norbert, proposes to upgrade texlive version to at least 2007-11.
<minghua> (gutsy currently have 2007-10)
<minghua> IMHO it's pretty bad to have upgrade failures for security updates...
<StEaLtHtHiEf> I have an easy question.  Can I develop a program that for example, when the user hits a key combination, like shift+enter, a circle is drawn around the mouse pointer until the key's are depressed erasing the circle?
<persia> StEaLtHtHiEf: Yes.
<StEaLtHtHiEf> is there a site that I can go read up on this, i don't wanna both you for info if there is something out there already.
<persia> StEaLtHtHiEf: That's a harder question.  I suspect that x.org likely has some pointers to the right specifications, but I'm not sure.
<StEaLtHtHiEf> ubuntuforums.org isn't working for me
<StEaLtHtHiEf> so that is why I am here, I am looking to try to develop a program so that I can stop using panels.  Sort of a shift+mouse_button_1 menu that comes up around the mouse.
<persia> StEaLtHtHiEf: Ah.  This isn't really a support forum, even for developing applications on Ubuntu or for Ubuntu.  You might look at how fluxbox does it: there is a contextual menu there.
<StEaLtHtHiEf> Not looking for support, just needed an answer to my first question.  second was just idle conversation.
<StEaLtHtHiEf> And I do thank you for pointing me in a direction.
<persia> StEaLtHtHiEf: Ah.  Excellent then :)  Sorry for the confusion.
<StEaLtHtHiEf> no problem!
<Lore2> I've done a little programming in windows, but I've got no experience programming under linux, what kind of material should I read if I want to fix bugs / improve functionality?
<StEaLtHtHiEf> i can't get the ubuntu forum page to come up
<StEaLtHtHiEf> but there is a development forum, might be programming or something.
<StEaLtHtHiEf> Somewhere there, is what your looking for.  As I said, the page isn't working for me, and I can't tell you exactly
<persia> Lore2: I'd suggest looking at similar code as a good way to learn.  Most of the APIs have docs, but it's not often in a HOWTO format.
<Lore2> As i'm very unfamiliar with linux, could you name a couple of the commonly used API's so I can pull up the documentation for them?
<slangasek> "POSIX"? :)
<Lore2> that's it?
<slangasek> that's one of the more important core APIs
<persia> X has a bunch.  GTK and QT are popular.
<slangasek> there are lots of others, but tend to be specific to context
<Lore2> Just out of curiosity is KDE/QT better than GNOME/GTK atm? I've noticed some missing features in gnome that I've heard are in KDE.
<MacSlow> Greetings everybody!
<Hobbsee> ah, good.  gutsy has firefox 3
<geser> infinity: I've now filed a bug for the manual boot-strapping of mig and gnumach: bug #174851
<ubotu> Launchpad bug 174851 in mig "mig and gnumach need a manual boot-strapping on the buildds" [Undecided,New] https://launchpad.net/bugs/174851
<ogra> asac, you dont happen to be around, do you ?
<asac> ogra: more or less yes
<ogra> i'm just looking through these xul hall of fame ... there is a very intresting minimal browser called mybrowser
<ogra> s/these/this/
<asac> is it a xul app?
<ogra> yes
<ogra> http://benjamin.smedbergs.us/xulrunner/
<ogra> it eats 30M RSS (vs 80 here for teh same firefox win open) ... no tabs, no new windows
<ogra> linking the plugin dir from firefox into its work tree makes all plugins work etc ... very nice little thing
<asac> ogra: ok cool ... file a bug requesting to package it (if you don't want to do that on your own) :)
<asac> ogra: we wilil do it then
<ogra> hmm, i never packaged a xul app ...
<asac> ogra: hmm ... it looks like lots of features are missing... like bookmarks et al
<ogra> could be an intresting exercise :)
<asac> ogra: should be fairly simple to package
<ogra> yeah, its very cut down, but could be a base for enhancements
<ogra> (it supports extensions, so bokmarks could as well be an extension :) )
<ogra> in any case its fast, small and compatible that makes it intresting :)
<asac> yeah :)
<asac> you can write your own browser like that in a few minutes ... thats the power of xulrunner
<ogra> well, you have to know the language :)
<asac> its like html (xul) + javascript
<ogra> hmm
<asac> there should be lots of folks that have a similar skillset that can easily be extended
<asac> but in the end its like writing dynamic websites with real widgets :)
<ogra> lol
 * ogra just thought the brwser was broken, but google.de is supposed to be black today :)
<asac> why is that?
<asac> ah lichtaus
<ogra> yeah
<asac> ok i am out ... need food ;)
<swien> hi
<limac> hi can anyone tell me how to be a part of the hardy devel community
<swien> Can anyone tell me how to package java software with maven build-system?
<limac> no clue about java or maven
<Adri2000> limac: hi, join #ubuntu-motu and read https://wiki.ubuntu.com/MOTU/Contributing
<swien> The problem is that maven is quite new in the repo and nobody seems to have a clue how to use it... It automatically fetches dependencies from its own repository.
<limac> thnx
<persia> swien: The Ubuntu build system doesn't allow network access during build.  You'll need to help maven a bit to get it to work.
<swien> persia: exactly. By helping maven you mean patch maven?
<persia> swien: Or just make sure that maven finds everything locally from the build-depends.
<swien> persia: do you know a package that already does this?
<persia> swien: Nope.
<swien> persia: Thanks for your help so far.
<bigon> could someone schedule a new build try for sylpheed?
<geser> bigon: does it build now?
<bigon> I've tested in a pbuilder and it builds fine
<geser> Hobbsee: ^^^ a give-back of sylpheed please :)
<Hobbsee> enobuilddpy.
<geser> what happened to it?
<Hobbsee> doesn't work on windows...
<geser> ah
<geser> you using Windows?
<Hobbsee> unfortunately, yes
<geser> bigon: wait till Hobbsee boots Kubuntu again or till monday when the other build-admins are back (like pitti)
 * Hobbsee isnt using kubuntu.
<bigon> geser: ok thx :)
 * Hobbsee uses ubuntu now
<jdstrand> keescook: I updated ubuntu-cve-tracker to be more flexible with embargoed filenames.  They should now be ^EMB-[\w-]*$
<jdstrand> keescook: so 'EMB-CVE-2007-1234' and 'EMB-foo' are both valid
<ubotu> Multiple cross-site scripting (XSS) vulnerabilities in sitex allow remote attackers to inject arbitrary web script or HTML via (1) the sxYear parameter to calendar.php, (2) the search parameter to search.php, (3) the linkid parameter to redirect.php, or (4) the page parameter to calendar_events.php. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1234)
<bigon> ubuntu changes in lintian seems to have been merged in the debian package, great :)
<bigon> could someone have a look at it and sync if it's ok?
<blueyed> Is http://ddebs.ubuntu.com/ not being updated since end of november?
<oliver_g_> hi
<oliver_g_> I have a PDF file that crashes Evince, but somehow apport is not triggered
<oliver_g_> any idea why that happens?
<oliver_g_> if I run evince with that file in terminal, it prints "Segmentation fault (core dumped)" so I assume apport should indeed come up...
<pochu> Is a crash file in /var/crash/ ?
<pochu> +there
<oliver_g_> pochu: yes!
<oliver_g_> pochu: three actually: from evince, file-roller, and hwdb-gui
<pochu> oliver_g_: open the folder within nautilus and double click it.
<pochu> Apport should open it then
<oliver_g_> pochu: thanks, that worked nicely!
<pochu> yw
<oliver_g_> I have reproduced the crash several times, with different terminal output... Should I submit the new apport crash data as well, and can I attach it to my original bug report?
<geser> oliver_g_: can you also attach the PDF if possible? so others can use it for testing
<oliver_g_> geser: I suppose not
<oliver_g_> it's the user manual for a laptop, and it states clearly that transmission over internet is not allowed without consent of the author
<Fujitsu> oliver_g_: Is said manual not available for download from the manufacturer's website?
<oliver_g_> Fujitsu: good idea - I'll have a look :-)
<oliver_g_> it's named SPR6L45GR0.pdf btw
#ubuntu-devel 2007-12-09
<oliver_g_> ok, I found a similar manual (different revision it seems) on the net, and it crashes evince as well; added to LP
<oliver_g_> thanks for your help!
<JanC> can somebody explain what's the use case for adding an entry for 127.0.1.1 in /etc/hosts ?
<LaserJock> some apps use it?
<JanC> its only purpose I could find seems to be to slow everything down considerably? ;)
<JanC> what apps use it?
<LaserJock> I'm not sure, but I've run across a couple
<JanC> booting goes about 2x faster when I comment it out, and some apps start up 10x faster without it...
<davef> its a loopback address that points to your own local computer. as mentioned, some apps rely on it. i would not recommend commenting it out
<JanC> eh, I think that 127.0.0.1 is perfectly fine for that?
<LaserJock> some apps use 127.0.1.1 for loopback
<LaserJock> I don't know if those apps could be told to use 127.0.0.1 or if there's a reason to separate them
<JanC> 127.0.1.1 has "hostname.local" after it, which causes delays because of DNS-SD timouts or something
<Nafallo> localhost.localdomain
<Nafallo> shouldn't conflict with hostname.local
<JanC> no, it has hostname.local after it...
<Nafallo> mine hasn't
<JanC> so, that would be an installer bug?
<Nafallo> 127.0.0.1	localhost.localdomain	localhost
<JanC> I'm talking about 127.0.1.1
<JanC> which is added to /etc/hosts by the installer
<Nafallo> ah.
<Nafallo> must have changed that on mine :-P
<JanC> I could understand if there was a good reason for that, but i couldn't find one
<LaserJock> mine just has the name of my computer
<Nafallo> I have no domains ;-)
<JanC> Nafallo: I commented it out too  ;)
<Nafallo> I don't think I've touched it.
<JanC> hm, could this be Avahi- or DHCP-related?
<minghua> In Debian, new installs now have two 127.x.x.x IPs in /etc/hosts.
<JanC> minghua: yes, that's what I see too
<minghua> one is 127.0.0.1, mapping to your hostname (and FQDN if you have one).
<minghua> one is 127.0.1.1, mapping to localhost.
<Nafallo> ehrm
<Nafallo> we have the reverse
<JanC> 127.0.0.1 localhost hostname
<minghua> It may be the same in Ubuntu.
<JanC> #127.0.1.1 hostname.local
<Nafallo> AFAIK
<JanC> taht's what I have now
<JanC> the "#" was added by me  ;)
<LaserJock> I have:
<LaserJock> 127.0.0.1 localhost
<LaserJock> 127.0.1.1 photon
<minghua> Nafallo: Maybe it's the reverse, I am not sure on that.
<Nafallo> minghua: I can't figure a reason we would change it, and for Debian for doing wrong :-)
<minghua> JanC: Your slow boot/start time problem is apparently your own.  I don't think .local is a valid domain name.
<davef> if you read the info in 'man hosts', it sounds like /etc/hosts is not widely relied on anymore. but is still needed in certain cases
<JanC> minghua: I didn't put it there  ;)
<minghua> Nafallo: I don't think we changed it either, but I only know the Debian part of the story, and this is an Ubuntu channel, so better be safe. :-)
<minghua> JanC: Your answer in the installation process put it there, I suppose.
<Nafallo> minghua: 127.0.0.1 is localhost, has always been etc.. :-)
<JanC> minghua: Ubutnu doesn't ask such things  ;)
<minghua> I'm not familiar with the ubiquity installer to be sure, though.
<JanC> and .local is the default extension for DNS-SD (aka Avahi / bonjour /etc.)
<Nafallo> minghua: in 50 to 70 years we might have only ::1 though ;-)
<minghua> Nafallo: I'll be dead by then, so I don't care. :-)
<Nafallo> I won't :-)
<JanC> Nafallo: only 1 (consumer) ISP in Belgium offers IPv6 tunnels (and they are mostly business oriented anyway), all others think IPv6 is something for the next century or something  :-/
<Nafallo> JanC: tunnels? what about proper IPv6 then?
<JanC> one problem is that a lot of ISP-size router equipment doesn't support IPv6 correctly, if I understand correctly
<Nafallo> also, isn't the educational sector running on IPv6 already?
<JanC> e.g. Motorola (headend) & Cisco stuff
<JanC> yeah, Belnet has IPv6
<JanC> but consumers can't use that  :P
<Nafallo> that depends on who they know ;-)
<JanC> Belnet has an IPv6 tunnel "entrance"
<JanC> that you can use for free AFAIK
<Nafallo> SixXS?
<JanC> yeah, I think they work with SixXS
<Nafallo> my main transit provider is also a SixXS PoP ;-)
<JanC> http://www.sixxs.net/pops/belnet/
<Nafallo> goscomb :-)
<ion_> I currently use SixXS, but my ISP is going to offer free native IPv6 soon. \o/
<Nafallo> ion_: hehe. I will take a BGP-session with v6 ;-)
<JanC> I should try to set up an IPv6 tunnel one day, but I think it's quite a lot of work for something that should just work  ;)
<JanC> and I would have to buy a new router too
<Nafallo> it's not a lot of work.
<Nafallo> it's dead easy.
<JanC> last time I checked (some years ago) you had to go through RIPE etc.?
<Nafallo> the registration process has nothing to do with setting it up, and RIPE isn't the case anymore anyway.
<JanC> ah?
<bigon> JanC: I use easynet pop for years and it works great :)
<JanC> well, registration *has* to do with IMO  :P
<Nafallo> JanC: SixXS has there own registry.
<JanC> hm, I'll look again then  ã
<Nafallo> I rather peer and have my own /48 to announce anyway :-)
<ion_> tsu
<JanC> hm, their FAQ still mentions RIPE etc. ?
<Nafallo> what does it say about it?
<bigon> JanC: you can use a ripe account
<bigon> too
<bigon> but as said they have their own registry
<JanC> bigon: right, but I don't have one  ;)
<Nafallo> and they sync the ripe into that one ;-)
<bigon> https://noc.sixxs.net/faq/account/?faq=10steps
<JanC> the FAQ points to a form on ripe.net
<bigon> https://noc.sixxs.net/signup/create/
<JanC> so it's probably outdated  :P
<bigon> JanC: enter real informations because they verify them
<JanC> bigon: that's no issue for me
<JanC> I have real data on my domains to
<JanC> (DNS.be also checks it now)
<Hobbsee> geser: sylpheed given back
<crimsun> Hobbsee: do you have any insight into the i386 build of Hardy's pulseaudio 0.9.8-1ubuntu2?
<Hobbsee> crimsun: what about it?
<Hobbsee> crimsun: i think parts of launchpad are lying to you, it appears to be pending build
<crimsun> Hobbsee: I can't seem to figure out anything about the i386 build.  All the other arches have built and are available in pool.
<Hobbsee> wait
<Hobbsee> launchpad is screwing up somewhere
<Hobbsee> crimsun: "launchpad is on crack'
<Hobbsee> crimsun: wait till monday, i guess
<crimsun> Hobbsee: ok, thanks.
<Hobbsee> crimsun: i can't cancel the build, etc
<Hobbsee> maybe i can force it though
<StevenK> "... bang!" Ooops
<Hobbsee> nah, i can't even force it
<Hobbsee> LP is reporting conflicting things
<StevenK> So will require a wizard to make sense of it?
<Hobbsee> it'll require a cprov to fix it, yes
<Hobbsee> i'd guessed queue-builder or something has fallen over, partway thru.  *shrug*
<choudesh> Anyone having issues with sun-java6-plugin in hardy? (icedtea-java7-plugin doesn't work either)
<MuNzE_> where can I find xorg.conf ...in hardy?
<MuNzE_> lol
<persia> MuNzE_: It's gone.
<MuNzE_> i try to find but nothing
<MuNzE_> /etc/X11 ...??
<bryce> MuNzE_: if you miss it, you can just run sudo dexconf to generate it
<bryce> MuNzE_: ideally you should no longer need it though
<MuNzE_> bryce, i need for compiz
<pwnguin> when did xorg.conf die? i missed this
<MuNzE_> lol
<persia> pwnguin: New in hardy.
<pwnguin> as of?
<slangasek> as of the first X upload to hardy
<persia> pwnguin: 1:7.3+4ubuntu1
<ion_> I only have an InputDevice section for my keyboard (so that i can set Xkb* options) and a Device section for my GPU (so that i can use the proprietary :-( nvidia driver). Everything else is handled automatically by xorg.
<pwnguin> well
<pwnguin> im sure my tablet still needs a section
 * Hobbsee waves
<mdke> hi Hobbsee
<Hobbsee> heya mdke!  how's it going?
<mdke> Hobbsee: ok thanks. Busy. What's all this about you using Ubuntu?
<mdke> the rumours are everywhere
<Hobbsee> mdke: i'm afraid that the rumours are true.
<Hobbsee> although compiz and my video card are not in love, for hardy.
<mdke> extraordinary
<mdke> permanent move?
<Hobbsee> so far
<Hobbsee> mdke: i didn't know it was that slow a news day :P
<StevenK> Just wait, she'll start bad-mouthing KDE, and then we'll know we have her...
<mdke> heh
<mdke> welcome to the light
<Hobbsee> StevenK: like i'd be stupid enough to comment on things that i don't like about KDE, or kubuntu for that matter, in a public, logged channel :)
<StevenK> Heh
 * Hobbsee just wishes hardy would stop freezing, and behave.
<mdke> at least you can run a free operating system. I've been stuck on windows for several weeks now
<Hobbsee> ew
<mdke> makes it very hard to get anything done
<Hobbsee> i'll bet.
<mdke> Hobbsee, slangasek - could you have a look at bug 174886, it's not something ubuntu-doc can take care of, I think
<ubotu> Launchpad bug 174886 in ubuntu-docs "Hardy Alpha Release Notes have no links to daily builds" [Undecided,New] https://launchpad.net/bugs/174886
<Hobbsee> mdke: looks like that should be assigned to ubuntu-release
<Hobbsee> mdke: and slangasek remember to do that each release
<mdke> ok. is there a project for that?
<Hobbsee> no
<Hobbsee> u-r is a team
<mdke> fine
<Hobbsee> well, at least, i don't know of one :)
<mdke> assigned :)
<Hobbsee> :)
<geser> Hobbsee: Hi, can you use build.py right now?
<Hobbsee> geser: yes
<geser> Hobbsee: please give-back: libmrss libp11 libpreludedb. Thanks.
<StevenK> geser: It's buildd.py
<Hobbsee> geser: all given back
<LongPointyStick> er, how do i debug why my keyboard and mouse have lockedup?
<LongPointyStick> as in, i can move the mouse, but it won't click, etc, and nothing on my keyboard appears to work
<StevenK> If you force a VT switch does the keyboard work?
<LongPointyStick> hwo do i force a VT switch?
<StevenK> Run 'sudo chvt 1' in an ssh session
<LongPointyStick> ahhh
<LongPointyStick> StevenK: it goes black, and then gets sent back to the X session
<LongPointyStick> you know, i wonder if this is related to the consolekit bug thing
<LongPointyStick> sorry, policykit
<StevenK> I wasn't expecting chvt 1 to send you right back to X
<LongPointyStick> neither
<LongPointyStick> but there is a bug about when you're logging in, where it won't let you get to a VT - it goes black, then sends you back to gdm.
<StevenK> Sounds sinister
<LongPointyStick> ah, bingo
<LongPointyStick> after killing consolekit, chvt 1 works fine, and i have keyboard.
<LongPointyStick> which then locks up again when i go back to X
<StevenK> So X has gotten into some bad state
<LongPointyStick> hrm, X will continually lock, even with consolekit killed.
<LongPointyStick> Amaranth: fix it!  :)
<StevenK> I daresay your video card does hardware pointer which is why the mouse moves -- the graphics hardware is updating the mouse pointer and keeping track of it, but X isn't listening since the keyboard and mouse clicks aren't working
<Amaranth> Does killing compiz help?
<Amaranth> Either X has gotten stuck or compiz has
<StevenK> Right
<Amaranth> compiz usually gets stuck when a driver does something weird
<StevenK> Amaranth: Hopefully my stuff about the hardware pointer isn't complete bollocks
<LongPointyStick> oh yes, i was going to try that
<Amaranth> StevenK: Sounds right
<Amaranth> Although when compiz is the problem it's not actually the case, everything is still getting events and such you just can't see it
<LongPointyStick> Amaranth: then it manages to quit gdm, and drop me back at a console.
<LongPointyStick> Amaranth: what's weird is that with EXA, my screen is still refreshing.
<Amaranth> gah i can't wait for gallium
<LongPointyStick> Amaranth: er, now killing compiz gets me back to a usable X window, yes.
<StevenK> So compiz is busticated.
<StevenK> What else is new?
 * StevenK ducks
<Amaranth> I suck with gdb but isn't it possible to attach to compiz and see what it is doing?
<LongPointyStick> StevenK: heh
<Amaranth> It's obviously not crashed so that would mean it's in an infinite loop somewhere
<Amaranth> or stalled waiting for something
<LongPointyStick> Amaranth: this reproducable by hitting meta+e, then alt+space
<Amaranth> oh that one
<StevenK> Hah
<Amaranth> I hate X11
<LongPointyStick> yeah, that seems to be oen of the easiest ways to do it
<Amaranth> the problem is the menu gets a screengrab
<StevenK> meta+e and then alt-space opens two window menus for me
<Amaranth> and keyboard grab
<LongPointyStick> StevenK: yes, then click somewhere, and try to go back itno one of the desktops.
<Amaranth> it's possible to escape from but not easy
<StevenK> LongPointyStick: Works for me
<LongPointyStick> StevenK: lucky you.
<Amaranth> I manage to get it stuck about every other time I try
<StevenK> I don't think I'll do that again
<Amaranth> hehe
<LongPointyStick> haha
<LongPointyStick> Amaranth: how do i start compiz, etc, on a separate display?
<Amaranth> eh?
<LongPointyStick> displays are always strange creatures to me :)
<Amaranth> DISPLAY=:0 compiz &
<LongPointyStick> surely if i'm running compiz thru gdb, i need to start it from the ssh'd machine?
<LongPointyStick> ahhhh
<Amaranth> i'm not saying to start compiz in gdb
<Amaranth> i'm saying to attach to it when it gets stuck
<StevenK> LongPointyStick: To do what Amaranth is asking, start compiz, get it stuck, find compiz's process id, run gdb and then run attach <pid>
<Amaranth> or gdb -p <pid>
<Amaranth> iirc
<StevenK> That will stop compiz, so you need to run continue, but then how to see what it's doing, I'm stuck
<LongPointyStick> hum.  attaching to it before it gets stuck just makes it freeze.
<StevenK> Of course, you need to run continue at the gdb prompt
<StevenK> gdb sends it a SIGSTOP, from memory
<Amaranth> it's best to attach it when it sticks
<LongPointyStick> so i continue, and it says Continuing, and it does nothing.
<Amaranth> right, don't do that
<Amaranth> attach to it after it gets stuck
<Amaranth> then don't run continue
<LongPointyStick> that was just after it got stuck
<LongPointyStick> oh.
<Amaranth> you should be able to run bt to see what it's just been doing
<StevenK> Maybe the last function on the call stack is annoy_hobbsee_lots_and_lots()
<LongPointyStick> haha
<LongPointyStick> Amaranth: no debugging symbols.
<Amaranth> does the automatic repo thingy have them yet?
<Amaranth> this would be easier on gutsy :P
<LongPointyStick> i have no idea
<LongPointyStick> there appears to be no compiz debug package in the reops
<Amaranth> https://wiki.ubuntu.com/DebuggingProgramCrash
<Amaranth> it's a separate repo
<Amaranth> debug packages are created automatically
<persia> Hmm..  ddebs.ubuntu.com doesn't seem to have updated in the past 10 days
<LongPointyStick> yeah, i thought so
<Amaranth> ok then...
<Amaranth> easier on gutsy :P
<Amaranth> unless you feel like installing basically every X, GNOME, and KDE dev package and building compiz :)
<LongPointyStick> well, i'll see if it crashes on gutsy then
<Amaranth> it does
<Amaranth> this particular bug has been around as long as compiz has
<Amaranth> well, sort of
<Amaranth> expo just made it easier to hit :)
<LongPointyStick> what, the freezes?
<StevenK> Haha
<LongPointyStick> crashes on gutsy too.
<Amaranth> LongPointyStick: good, you can get debug symbols there :)
<LongPointyStick> heh
<Hobbsee> Amaranth: it appears that they're broken anyway, due to the backports
<Amaranth> Hobbsee: oh joy
<Hobbsee> yes...
<android> hi
<android> do you know why zsnes is in multiverse in ubuntu but in main in debian?
<android> I think this is an error
<android> cause zsnes is a free software
<Adri2000> android: I see it in universe
<Adri2000> zsnes |  1.510-1.1 | http://archive.ubuntu.com hardy/universe Sources
<pochu> android: In feisty and Edgy was in multiverse, but Gutsy and Hardy have it in universe.
<android> ok thank you the problem was solved
<yuhong> May I suggest adding a generic-pae kernel to the next version of Ubuntu?
<yuhong> Currently it requires a recompile.
<yuhong> How about making it the default if NX support or RAM mapped over 4G boundary is detected.
<yuhong> Also how about a non-PAE server kernel?
<yuhong> Make that the default if the processor does not support PAE.
<yuhong> And if installing a server version of Ubuntu.
<crimsun> yuhong: please ask on the kernel-team@  list (it's moderated, so please consider subscribing).
#ubuntu-devel 2008-12-01
<grant2328> would this be the place to inquire about built-in sony memorystick reader support?
<dholbach> good morning
<Caveman__> hello there!
<NCommander> hey dholbach
<dholbach> hi NCommander
<NCommander> how goes it dholbach
<dholbach> good good - how 'bout you?
<NCommander> Enjoying the first net access I've gotten in over a week that isn't though a cell phone or dial up
<gurrier> Can anyone help me resolve an md5 inconsistency n the repos for Hardy? pool/universe/n/nuvola/nuvola_1.0.final.orig.tar.gz': md5 expected: bf3e477716fe0b39de81c210d1b5a8d1, got: e08f99c29a9cebf6ae8d8a3e750f17f6
<slangasek> gurrier: the md5sum is correct on the master repository; you seem to be pulling from a bad mirror
<gurrier> slangasek: Hmm, ok, will check. Thanks.
<gurrier> slanasek: You were right, the mirror I was using was outdated (prob just does a file sync).  Then I compounded the issue with wgetting a file without deleting the original. All done now.  Thanks for your help. :)
<gurrier> s/slanasek/slangasek
 * directhex hands slangasek cake
<slangasek> gurrier: no problem
<slangasek> directhex: I don't understand why people are always trying to fatten me up :(
<Hobbsee> slangasek: because you're too skinny, apparently.
<Hobbsee> slangasek: and it appears that beer is slightly out of favour, for some reason
<Mithrandir> beer > *
<Hobbsee> perhaps it's judged to be too early in the day for beer there.
<Hobbsee> hey Mithrandir!
<directhex> Hobbsee, it's xmastime. cake is in wide supply!
<Mithrandir> hiya Hobbsee
<gurrier> <cough> Always time for beer
<Mithrandir> it's never too early for beer
<Hobbsee> directhex: mmm.  You're making me want cake now
<directhex> Hobbsee, well, Laney & james_w have earnt it! and slangasek too, but a smaller piece
<Hobbsee> :)
 * ogra points to http://isitbeeroclock.com/
<slangasek> Hobbsee: I'm pretty sure I haven't been too skinny for a number of years now
<Hobbsee> slangasek: ah
<Mithrandir> slangasek: you're still not exactly fat, even if you're no longer skinny.
<Hobbsee> ogra: haha, nice.
<Mithrandir> s/skinny/too &/
<directhex> <CIA-7> debian-pkg-cli-apps: directhex-guest * r4242 /packages/cowbell/trunk/debian/ (changelog control rules): I've got a fever, and the only prescription is more cowbell!
<zer0_> how to fix slow performance on ubuntu 8.10??
<Hobbsee> #ubuntu for support, please.
<thegve> Hello. I have a problem with running Netbeans 6.5 on ubuntu 8.10 64bit. I have asked on #ubuntu and was directed here. The error java gives is : Problematic frame: C  [libc.so.6+0x315af]
<zer0_> what this room diccussed for??
<Hobbsee> [22:22] *** The channel topic is "Archive: open, MoM running | 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".
<Hobbsee> so, Development of Ubuntu (not support, not app development on Ubuntu)
<Hobbsee> thegve: there is a channel for #netbeans
<ogra> "how to *develop* slow performance on ubuntu 8.10??" would have been the proper question for here  :P
<thegve> cool, another redirect ;)
<Hobbsee> thegve: well, i doubt many people actually use netbeans here, or have seen that error tbh :P
<thegve> Hobbsee, but I guess it is a java problem
<thegve> ah well, I'll try it there
<Hobbsee> thegve: FYI, google looks to have a solution that's worked for a couple of people, too
<thegve> the thingie in /etc/environment I guess?
<thegve> that seems to work for 32bit systems
<Hobbsee> looks like it
<thegve> awt_toolkit=mtoolkit
<directhex> man, java sounds like hard work :|
<thegve> I am developing in PHP
<thegve> But netbeans recently got quite good PHP support (well, at my previous employer I've worked with Ubuntu/Zend Studio, that worked even better..)
<thegve> I have developed most of the stuff in VIM, have done that for 6 months so I know my way around, but as the project grows a real IDE is easier..
<ogra> seb128, any idea whats up with all the gnome-python stuff on armel ? seems it didnt even attempt to build yet and breaks half the world
<ogra> (mainly -desktop and -extras seem to sit and wait for something)
<\sh> thegve: eclipse and the php plugin is very good for php developing...it even works with xdebug and xcache for debugging purposes...no need for netbeans
<thegve> \sh, I am now installing Eclipse, but I guess it won't work either, as it's java that's broken on my system
<thegve> I am currently installing 32bit ubuntu in virtualbox as a last resort
<\sh> thegve: eclipse from eclipse.org (ganymed) + apt-get install sun-java6-jre  on x86_64 works like a charm here :) no need for 32bit, too ,-)
<thegve> \sh, What the... Eclipse works like a charm. Installed from the Ubuntu repo's.
<thegve> Netbeans is still failing
<\sh> thegve: the error of netbeans is what? some libx* foobar crash?
<thegve> I "tested" java using a learning program (for learning swing) I wrote a while ago
<thegve> C  [libc.so.6+0x315af]  catgets+0x1f
<thegve> C  [libc.so.6+0x315af]  catgets+0x1f
<\sh> thegve: hmm...so not this old libx* foobar crash...did you test netbeans with the sun jdk/jre?
<thegve> yes, I am now using the sun ones, as they seemed to perform better when I tested it (some years ago, I admit)
<thegve> Eclipse still has an odd main screen.....
<seb128> ogra: when I looked at it some days ago they did try to build but failed on xvfb errors
<ogra> hmm, k, i'll try a local build
<seb128> it's not armel specific
<seb128> gnome-python built
<seb128> I guess your issue is gnome-python-extras and it failed on all arches the same way
<ogra> i only see ftbfs on sparc and ia64 for -desktop
<seb128> looking
<ogra> but right, -extras seems to have failed everywhere, there was just no attempt on armel yet
<seb128> ask to a buildd admin to bump the gnome-python-desktop build score on armel
<glatzor> mvo, hello. Could you please take a look about my debconf integration proposal for PackageKit?
<glatzor> mvo, http://lists.freedesktop.org/archives/packagekit/2008-November/004138.html
<james_w> hello glatzor
<glatzor> hello james_w!
<ogra> seb128, by experience with other packages, the buildds often dont properly stop xvfb after a build, it could be that it doesnt start because there was an old idling xvfb hanging around fro a former package
<ogra> *from
<Hobbsee> seb128: wish granted.
<seb128> Hobbsee: that was not my wish but thank you ;-)
<ogra> Hobbsee, thank you :) (sine it was my wish)
<ogra> *since
<Treenaks> ogra: you have 2 wishes left 8)
<ogra> Treenaks, until i find another ferry ;)
<Hobbsee> :)
<Treenaks> ogra: fairy?
<ogra> i'm trying to careful loadbalancig :)
<ogra> Treenaks, err, yeah :P
<ogra> s/to/to do/
<mvo> glatzor: thanks, will do
<asac> pitti: a batch for you: ... firefox-3.1 -> bin NEW ... ubufox -> SRU, network-manager-applet -> SRU
<asac> thanks!
<PecisDarbs> hi people, is there any plan to ditch /etc/network/interfaces or NetworkManager will have some compatibility with it?
<hyperair>  /etc/network/interfaces is here to stay, so i suppose nm will eventually have compatibility with it
<ogra> it does since a while
<ogra> just not enabled by default
<hyperair> 0.6 did
<hyperair> i hear 0.7 broke
<hyperair> i didn' bother testing
<hyperair> and so i'm not sure if it's fixed
<hyperair> my static IP's configured in NM anyway
<hyperair> only a server i maintain uses /e/n/i
<ogra> it works with simple /e/n/i configs in 0.7
<hyperair> hmm
<hyperair> how simple is simple
<ogra> just not the complicated cases ... which is why its not enabled by default
<hyperair> can't it be configured to ignore a specific interface if it's defined in /e/n/i?
<tjaalton> doko: do you have an idea how big a task it would be (for me) to update eclipse to 3.4 (and push it to debian too)? shouldn't jaunty/unstable have the prereq's already?
<apw> superm1, hi yas, wondering if you have seen any of your studio 15's getting locked up on the _second_ resume (and its reliably the second) with the network manager spinning round, and a kernel events/N thread burning cpu at 100%
<vishalrao> possible intrepid packaging bug: installed intrepid desktop amd64 on a laptop today. switched package servers to se.archive.ubuntu.com (sweden). ran update-manager. it downloaded two 23mb packages of linux-xxx-generic for kernels 2.6.27.7-16 AND .29-19 . is that right?
<apw> vishalrao, installed it from CD ?
<vishalrao> yes
<vishalrao> original release amd64 desktop live cd
<apw> that is entirly possible, if there was an updated -7 kernel and -9 is now in security
<apw> so you had -7.15 (say), and there is a -7.16 in the archive and a -9.19 is recommended in -security
<vishalrao> alright, not a worry... just checking :) things working fine on my coworker's laptop (acer aspire 4730z)
<apw> you end up with the latest -7 and -9 kernels on your machine
<thegve> \sh, Thanks again for the Eclipse+PDT suggestion. It works great, even better than Netbeans 6.5 (for a relative newbie to both IDE's...). It is quite responsive, and code completion works quite well, it parses my phpdoc comments well. I think I might have finally found a good free IDE.
<\sh> thegve: you're welcome :) we are working here with eclipse + pdt in our company...it's charming :) (forget the large memory footprint of eclipse ,))
<thegve> \sh, I already removed the part of my comment mentioning that ( I typed it at first :) ). 350MB here, ah well, a "modern" workstation has plenty of memory..
<asac> slangasek: pitti, cjwatson gone ... could you process my SRU uploads for ubufox/network-manager-applet please? thanks!
<slangasek> asac: the ubufox bug says it's about installing plugins on the LiveCD - does this also affect installed systems?
<asac> slangasek: yes
<asac> the default pref is wrong
<slangasek> ok
<asac> doko: could you bump build-score for xulrunner-1.9.1 on armel?
<asac> just so we know if everything is fixed in trunk
<ogra> asac, last build worked fine for me btw
<asac> ogra: 1.9?
<asac> nice
<asac> ogra: have you been using it for a long time yet?
<slangasek> asac: what is it that generates 8 lines of diff context instead of the default of 3?
<ogra> asac, my ARM has only a touchscreen (no kbd) ... i only started the app and it properly opened the ubuntu startpage (the online one)
<asac> slangasek: for quilt or in general?
<asac> slangasek: I use -U8 -p
<slangasek> asac: whatever you used when generating the patches for n-m-applet :)
<ogra> asac, 1.9.0.4+nobinonly-0ubuntu1
<asac> slangasek: yeah. -U8 (8 lines context) -p (function signature in hunk)
<asac> ogra: thanks. on sparc we get sigbus due to alignment issues after about 45 minutes
<asac> ogra: i am a bit scared we see something similar on armel as we ignore alignment warnings there
<slangasek> asac: ok, so you've configured a non-default setting, right :)
<ogra> well, not easy to test without kbd
<hwilde> is anyone here knowledgeable about dhclient and roaming in enterprise wireless environments
<hwilde> aka if the wireless client roams to a new wlan controller on a different subnet, but still has a dhcp lease, how does it know that it needs to renew the dhcp request
<hwilde> so what I did was write a script to test IP connectivity with a ping every X seconds, and then renew the dhcp request if there is no ping
<hwilde> but is there some built-in roaming functionality that would detect this scenario and get a new IP  automagically ?
<asac> hwilde: i think thats hooked into wpasupplicant package
<asac> hwilde: there are scripts that get run when roaming happens
<asac> hwilde: but i am no expert in roaming with manual tools ... just NM ;)
<asac> hwilde: anyway. there should be an example in the wpasupplicant package
<asac> e.g. how to setup interfaces
<asac> and wpasupplicant.conf
<asac> as a started: you use the wpa-roam stanza in /etc/network/interfaces
<hwilde> what if i'm not using wpa supplicant
<asac> hwilde: what do you use?
<hwilde> well, in some cases it's WEP
<hwilde> and in some cases it's using a wireless bridge so it's just plugged into the ethernet port
<asac> hwilde: wpasupplicant can do wep and open too ... just that it provides this roaming support
<asac> hwilde: i would suggest that you try that if you dont want to reinvent the wheel. read: /usr/share/doc/wpasupplicant/README.modes.gz
<hwilde> asac, so wpa supplicant specificaly detects the case where it is associated and authenticated wirelessly, and it has a dhcp lease that has not expired, but there is no ip connectivity, and it has to renew dhcp?
 * hwilde is skeptical that wpa supplicant has those brains
<asac> hwilde: give it a try
<asac> not 100% sure about leases. in worst case you get a new lease
<asac> but maybe it just works
<hwilde> supplicant isn't that smart to know
<hwilde> it only knows wireless state
<hwilde> not IP subnets
<hwilde> and in the case I am not using wpa supplicant then what
<hwilde> it seems like a task for dhclient to know when it needs to renew dhcp
<slangasek> it isn't.
<hwilde> :(
<slangasek> you want to trigger lease renewals when there's a new AP association event, not have dhclient guessing randomly about whether it needs a new lease; wpasupplicant is the tool to handle that
<hwilde> well, it doesn't need to renew dhcp on every ap roam
<hwilde> just when it roams to a new controller on a different subnet
<hwilde> and what if i'm not running wpa supplicant
<slangasek> then you should be running wpasupplicant, like asac told you
<hwilde> in the case of a wireless to ethernet bridge, there is no use for wpa supplicant
<asac> hwilde: dont speculate. test.
<hwilde> the wpa supplicant wouldn't do anything
<hwilde> there is no wireless card
<hwilde> just a bridge attached to the ethernet port
<asac> hwilde: there is no need for anything. you can re do everything that exists in userspace ;)
<hwilde> you are not listening to what I am saying tho
<hwilde> the bridge handles the authentication and roaming
<hwilde> the wpa supplicant wouldn't have access to that state
<hwilde> so it wouldn't know when to renew dhclient
<asac> hwilde: why do you have that bridge?
<slangasek> that's definitely not a common use case.  You'll have to hotwire dhclient on your own, then.
<asac> what kind of tool manages it?
<hwilde> bc hardware and software wise the bridge is more robust
<hwilde> it's a cisco 1242ap in bridge mode
<hwilde> (partly to get around incompats with wpa supplicant)
<hwilde> the only problem I have now is when the cisco symmetric tunneling dies between the controllers and it is "online" wirelessly but it needs to renew dhcp
<asac> how do you detect that the bridge roamed?
<hwilde> umm, the lack of ping ? :)
<asac> thats rather an unreliable indicator for a roam
<hwilde> roaming is not an issue
<hwilde> it's when it completely drops association and the symmetric tunneling is down
<asac> if you want to use that you are probably alone and have to do stuff manually
<hwilde> I guess that might come out snmp
<asac> but well. i have no experience with such setups. so cant really tell.
<hwilde> nobody does :)
<hwilde> i was just wondering if there was a roaming flag to set somewhere in dhclient
<hwilde> but I guess that is in wpa supplicant only
<hwilde> my pinger script works really well, it's just such a hack
<asac> but doesnt sound like a good solution. not sure what is better though. i would say that using wpasupplicant instead of the bridge and fixing the compatibility issues would be a better approach to get this sorted in the core distro
<hwilde> wow
<hwilde> the bridge has bigger antennas, a dedicated cpu, and the cisco ios code base so it does all the authentications offiically
<hwilde> it replaces the wireless card, the card firmware, the driver, and wpa supplicant
<hwilde> let's say it was a lan device, and the subnet failed over so it's dhcp address was no longer valid
<hwilde> it would never realize this and renew the dhcp request?
<slangasek> that would be a badly administered lan
<hwilde> :)
<hwilde> also there is this problem:
<hwilde> [69474.503258] BUG: soft lockup - CPU#0 stuck for 11s! [wpa_supplicant:4379]
<hwilde> so wpa supplicant is not really an option for all of my cpus
<asac> hwilde: what i dont understand is that the bridge doesnt do this all transparently for you. why do you need to change your local ip at all?
<hwilde> asac, well the local client has to request dhcp through the bridge
<hwilde> the bridge essentialy just spits all the wireless traffic out the ethernet port
<hwilde> and vice versa
<doko> tjaalton: have a look on the debian-java ML, or one of the bug reports in eclipse debian. Michael Koch did already start some work
<doko> asac: packages from main always get precedence
<asac> doko: always? no way around?
<doko> asac: well, if somebody rescores a universe package ...
<asac> doko: ok so its you ;) ... say that upfront
<doko> asac: yes, gcc-snapshot is worth having around
<superm1> hi apw, due to the kernel race condition bug with the intel graphics, i've not suspended on my one intel graphics model in ages in intrepid.
<asac> doko: heh?
<moquist> popey: ping
<asac> doko: a sense of irony? ;)
<doko> asac: no irony at all
<apw> superm1, ok ... i have an intrepid kernel which seems to make the intel side of it work at least
<superm1> apw, what type of access point are you using?  perhaps can it be asserted to the broadcom driver then that it's happening?
<superm1> particularly what type of security
<apw> i have an interl wireless chipset in mine, the local access point is wep
<superm1> okay nvm then. i've only tested with the broadcom, and i know that there was some annoying stuff with WPA2 enterprise
<superm1> might try suspend/resume with the hw switch flicked off  to take that element out of the picture then
<apw> hw kill switch for the wireless you mean?
 * Daviey prods superm1 to a different channel
<asac> doko: please assume that 1.9.1 is in main then ;)
<superm1> yes
<apw> superm1, will do ...
<asac> doko: i want to know its fine ... so we have the option to use it as default :)
<asac> later in cycle
<doko> asac: really a new package for new subminor version?
<ScottK> superm1: Any word on bluetooth fixes for KDE?
<superm1> ScottK, unfortunately it's gotten put onto the back burner atm for myself because of more critical stuff, i'll double check with the two other fellows that were helping to see where they are at though
<ScottK> superm1: Thanks.  We're getting queries so it'd be nice to give a useful answer.
<asac> doko: subminor? thats a new release target
<asac> ffox/xul has stabilty/security updates that bump the last digit
<asac> every other digit is quite major
<asac> problem is we want it in archive now, so we are prepared to use it in case mozilla manages to get it out in time
<doko> mvo: did you save the uninstallabilty test for another architecture than you are currently running (what cjwatson did post)
<mvo> doko: yes, "chdist -a armel create jaunty-armel"
<mvo> doko: # edit .chdist/jaunty-armel/etc/apt/sources.list
<mvo> doko: chdist apt-get jaunty-armel update
<mvo> doko: chdist apt-get jaunty-armel install <package>
<mvo> doko: that was what you were looking for, right?
<doko> mvo: yes, thanks
<tjaalton> doko: ok, I'll probably ask him how far he got. thanks
<hwilde> can I propose a name for the next release:  Killer Koala
<doko> tjaalton: unlikely that he will reply, he's online since three or four months now
<doko> *not* online
<tjaalton> doko: oh, ok..
<tseliot> slangasek: is nvidia-glx-180 in in NEW?
<ScottK> lool: Just saw your kdebase-workspace upload.  We're in the middle of updating KDE to 4.1.80 (KDE 4.2 beta).  If you've got any more KDE changes, please chat with us on Kubuntu devel so we don't step on each other.
<lool> ScottK: Ok; this was actually my next step, but I got distracted by dinner; I didn't think you were planning a new upload as .73 had just been uploaded, I will check first next time
<ScottK> lool: No problem.  In general you can also just feed us patches and we can deal with it.
<luisbg> superm1: ping!
<psusi> pitti: wondering if you had a chance yet to look at that external drive permissions issue... I'd like to be sure you are satisfied with the options before I start adding them to the other filesystems in the kernel
<DktrKranz> kees, when you have time, mind looking at bug 304117? Thanks.
<ubottu> Launchpad bug 304117 in procps "kernel.maps_protect removed from 2.6.28 kernels" [Medium,Triaged] https://launchpad.net/bugs/304117
<kees> DktrKranz: ah yeah, it was made a non-configurable item (always private now)
<kees> DktrKranz: uploaded
 * DktrKranz hugs kees 
 * kees hugs DktrKranz back  :)
<kees> I need to get 2.6.28 booted...
<mathiaz> kees: did you get a chance to look at the mysql build failure log? http://people.ubuntu.com/~mathiaz/mysql-dfsg-5.0_5.0.67-1ubuntu1_amd64
<mathiaz> kees: are the test failures similar to the ones you've encountered when trying to enable PIE?
<kees> mathiaz: just read it now -- no, that's a huge list.  also, the 4 or 5 that failed would cycle between about 10 different tests, rarely the same two builds in a row
<kees> mathiaz: looks like you'll have to find ones that are stable and dig into them.  I bet 1 small thing changed in output or something that has caused them all to fail.
<mathiaz> kees: well - AFAICT it's always the same that are failing
<mathiaz> kees: what is strange is that they're all related to arithmetics
<mathiaz> kees: average, sum, etc... are returning the correct results.
<mathiaz> kees: building the same package on intrepid works
<mathiaz> kees: average, sum, etc... are returning *incorrect* results.
<kees> highly worrisome!
<rtg> kees: tseliot ran into the same header issues earlier today. It seems many include files were moved around and you now need some different include paths.
<kees> rtg: erk
<kees> yay stable API ;)
<tseliot> hehe
<rtg> kees: I should copy Linus rant from earlier today. oh wait, that was ABI not API :)
<kees> heh
<[Relic]> pitti alive?
<directhex> technically no. pitti merely exists. he's a universal certainty, like matter and energy
<sebner> directhex: personally I think he is a bot and currently charging his batteries :P
<[Relic]> just having problems with no boot for the next proposed kernel version for 8.04 LTS  not sure what the exact error is so not sure what to classify it as
<[Relic]> not sure if it is eth0 set up which has the warning that causes the error of what immediately follows it
<mathiaz> kees: jdstrand: does the test-ispec-tool work in qa-regression-testing?
<mathiaz> kees: jdstrand: it gets stuck at Remote tunnelled network is pingable ...
<cr3> what has replaced cheese, which moved from main to universe, as the recommended webcam application?
<kees> mathiaz: it requires 2 machines, IIRC
<kees> mathiaz: see the text at the beginning of the script
<pitti> Good afternoon everyone
<directhex> it's 11pm!
<directhex> wait......... is pitti in mountain view?
<pitti> [Relic]: hi
<beuno> pitti, hi, are you at the hotel yet?
<pitti> beuno: just came in and set up wifi, yes; now going to take a shower
<pitti> directhex: not quite yet, SF
 * directhex is in runcorn
<directhex> it's a bit less flashy than SF
<[Relic]> Hello :)
<calc> is there a meeting before FooCamp, or some people just like being really early?
<pitti> calc: there's the desktop experience sprint here in SF, Tue to Thu
<calc> ah i see
<calc> how do you delete a subtask (eg Hardy) from a bug?
<calc> iirc you set it to some specific status?
<pitti> calc: set it to invalid or wontfix, whatever is more appropriate
<calc> oh ok, i thought one of those would make it completely disappear
#ubuntu-devel 2008-12-02
<TheMuso> calc: Do you know where I may be able to find a PPS file with audio, so I can test bug 298494?
<ubottu> Launchpad bug 298494 in pulseaudio "OpenOffice.org Impress: Faltering embedded sound in PPS files" [Undecided,New] https://launchpad.net/bugs/298494
<TheMuso> Or anyone else? ^^
<[Relic]> is anyone else alive, or are they all bots like pitti :)
<TheMuso> [Relic]: I'm alive.
<calc> TheMuso: the one in the bug report doesn't work?
<TheMuso> calc: Oh there is one in the bug? Haven't looked at the bug in that much detail yet. Thanks.
<calc> ok np
<TheMuso> calc: Am I correct in deducing that openoffice now uses gstreamer for its audio output?
<calc> TheMuso: yes
<TheMuso> calc: Right, well that audio stutering with pps bug is very weird, because openoffice doesn't seem to be respecting the settings from the sound preferences applet.
<TheMuso> I get audio stutter whether I use OSS, alsa or pulseaudi in those settings. Examining open devices from a terminal, when I have oss selected, no oss device node is being used what soever.
<TheMuso> Only alsa nodes get used.
<TheMuso> So I am not convinced its an audio infrastructure bug.
 * TheMuso will update the bug in a bit when I've done a bit more testing.
<calc> ok well it might not be after all, i just thought it might be since he claimed it worked previously
<calc> feel free to bounce it back to openoffice.org with that info added to the report :)
<TheMuso> calc: Ok will do.
<wasabi> hmm. at some point UDF vols stopped auto mounting.
<wasabi> it's trying iso9660 first and succeeding.
<dholbach> good morning
<vhaarr> Hey, what does "SRU" and "FFE" mean? I see these abbrevations in some bugs on launchpad, for example.
<Hobbsee> !sru
<ubottu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<Hobbsee> !ffe
<ubottu> uvf is Upstream Version Freeze.  For an exception, see https://wiki.ubuntu.com/FreezeExceptionProcess#head-9523bc4076ff011324d67cddc97969ec609618d6
<Hobbsee> ^
<vhaarr> ffe == uvf?
<Treenaks> vhaarr: no, FFE is exception to the freeze
<vhaarr> ah
<vhaarr> thank you
<vhaarr> is jaunty in feature freeze at the moment?
<StevenK> vhaarr: No
<vhaarr> why is it that nvidia-graphics-drivers-180 is stuck in https://launchpad.net/ubuntu/jaunty/+queue then, does it still need some sort of "initial approval" since it's a new package?
<vhaarr> ah, I should probably be in #ubuntu-motu with these questions
<vhaarr> apologies for spamming the devel channel
<Hobbsee> vhaarr: yes
<Hobbsee> @ initial approval
<vhaarr> righty, thanks
<fabbione> soren: ping?
<soren> fabbione: wazzup?
<fabbione> soren: hey.. do you still maintain kvm/libvirt stuff?
<soren> fabbione: Yes.
<fabbione> soren: when you have time, can you give me a crash course on how to setup libvirt networking?
<fabbione> soren: I am fighting with bridges and stuff that I am not very familiar with
<soren> Sure.
<soren> fabbione: With bridging, it's really quite simple. Do you have a bridge setup already and just want libvirt to use it?
<fabbione> soren: i only have the default installation (hardy)
<soren> Alright.
<fabbione> soren: basically i want the guests to access the real network directly
<soren> Right.
<fabbione> soren: not via all that NAT stuff
<NCommander> hey apachelogger
<fabbione> soren: and make that permanent
<soren> fabbione: Could you put your /etc/network/interfaces on a pastebin? I can make the changes there and you can see what I did. That's lots easier than explaining it.
<NCommander> Well, you could just set it up to use IPv6 ...
<fabbione> soren: sure thing.. sec
<fabbione> soren: http://www.fabbione.net/interfaces
<soren> fabbione: I presume it's the bond0 interface you want to bridge to?
<fabbione> soren: well that's connected to the real net.. so yeah
<soren> fabbione: Any particular reason you're not using the "slaves" directive in your interfaces file?
<soren> (for setting up the bonding)
<fabbione> soren: not really
<soren> fabbione: Ok. We can fix that afterwards :)
<fabbione> soren: i didn't even know ifup did grow bonding support :)
<fabbione> soren: <- very very old school
<fabbione> soren: it doesn't really matter as long as it works
<soren> fabbione: Ok, for the really simple, general case: http://people.ubuntu.com/~soren/interfaces-example.txt
<fabbione> soren: looking
<fabbione> soren: well i doubt there is network manager installed on the server
<fabbione> it's not a desktop + kvm thingy
<soren> So, for your setup it, this should probably work: http://people.ubuntu.com/~soren/fabbione.txt
<fabbione> it's a decent _real_ server :)
<soren> Just leave that bit out, then :)
<soren> fabbione: This one should deal with the bonding as well: http://people.ubuntu.com/~soren/fabbione-even-better.txt
<fabbione> eheheh
<fabbione> soren: one thing I am not sure I understand
<fabbione> soren: the bond will not get the ip address
<soren> Hm?
<fabbione> (sec)
<soren> Oh, I think I know what you mean..
<soren> The bond0 interface no longer gets an ip address. Only the bridge interface does.
<fabbione> ah ok
<soren> That's the way it works.
<fabbione> so i also need to make sure the bridge will get the same mac address
<soren> IIRC, the bridge assumes the numerically lowest MAC address of the interfaces attached to it.
<soren> ...so it doesn't change over time, if that's what you mean.
<fabbione> ok perfect :)
<fabbione> yeah
<fabbione> that's what I was looking for
<soren> Ok, so now you've got a bridge.
<fabbione> ok just a sec.. customer on the phone
<soren> To hook a virtual machine into that, you put <interface type='bridge'><source bridge='ifbr0'/></interface>  in your domain XML definition.
<soren> ...and that's it.
<soren> fabbione: sure, take your time.
<fabbione> thanks :)
<RAOF> wgrant: I'm sure you'll be overjoyed to hear that syndaemon in Jaunty fails to work with a BadDevice error.
<fabbione> soren: re
<fabbione> ok... testing fancy-interface-file-from-soren
<soren> fabbione: First: Does the host's network still work?
<fabbione> soren: you need to add auto bond0 otherwise the bridge can't bind
<fabbione> soren: i am fixing bits and pieces :)
<fabbione> soren: bond0 needs to be UP
<fabbione> now.. i am testing again.. one sec
<fabbione> soren: this is that kind of testing that I hate the most.. "if the server reboots.. will it work?"
<soren> fabbione: Ah, yes, good point on the bond0.
<fabbione> soren: and this thing has something like 10 pages of POST before you get to grub
<soren> fabbione: Yikes. What is it?
<fabbione> soren: Dell Poweredge 2900-III
<fabbione> soren: decently equipped
<soren> Yeah, it must be :)
<fabbione> ok
 * soren -> coffee
<fabbione> ifbr0     Link encap:Ethernet  HWaddr 00:1e:c9:eb:2a:1c   inet addr:192.168.1.7  Bcast:192.168.3.255  Mask:255.255.252.0
<fabbione> works :)
<soren> \o/
<fabbione> soren: enjoy your coffee...
<fabbione> soren: i still need to pick your brain a bit :)
<soren> Sure thing. Just shoot.
<fabbione> soren: ok.. host networking works fine now
<asac> doko_: armel seems to have built fine. Thanks a bunch!
<NCommander> doko_, do you know why there seems to be no implicate cast from float to double? (or via versus I suppose, since that works on i386)
<NCommander> (on arm)
<glatzor> morning james_w, do you arrive at sfo?
<glatzor> james_w, if so we could share a taxi, since I would arrive three minutes after you
<tseliot> Riddell: you're the archive admin today, aren't you?
<Riddell> tseliot: I would be if I wasn't on holiday
<Riddell> tseliot: what do you need?
<tseliot> Riddell: can you see nvidia-glx-180 in NEW?
<tseliot> (Jaunty)
<Riddell> tseliot: yes
<tseliot> Riddell: good. Can you accept it, please?
<Riddell> into restricted presumably?
<tseliot> yes
<tseliot> BTW it makes KDE4 usable with nvidia cards
<tseliot> :-)
<Riddell> yay
<Riddell> accepted
<tseliot> Riddell: thanks a lot
<NCommander> hey Riddell
<Riddell> morning NCommander
<NCommander> how goes it Riddell?
<Riddell> NCommander: lovely thanks, currently enjoying the hospitality of the Kubuntu Stuttgart Office
<NCommander> o_O?
<NCommander> Riddell, I'm working on running down the all evil pyKDE4 arm bindings FTBFS
<NCommander> bah
<Riddell> brave man
<NCommander> I can't figure out where its choking
<NCommander> If its the Python-C API, QT, bindings, or sip
<NCommander> :-/
<NCommander> Are we the only distro with KDE4 and an ARM port?
<Riddell> NCommander: there's Debian experimental
<Riddell> NCommander: have you tried asking Sime?
<NCommander> who?
<Riddell> pykde maintainer
<NCommander> armel doesn't appear to have an experimental buildd ...
<Riddell> NCommander: on IRC as Sime_
<NCommander> hrm
<james_w> glatzor: I do, that would be great
 * directhex wonders if ScottK tried to catch up with him again after ~11pm yesterday
<lool> NCommander: Hmm the error in the build log seemed pretty clear, did you get past that one?
<NCommander> lool, it's not clear
<NCommander> lool, its FTBFS on a generated file
<NCommander> (that file is generated by the KDE python binder lexer AFAIK)
<NCommander> I'm hoping once I get a chance to fully look through the lexers output I can see whats going wrong
<NCommander> As far as I can tell from the build log, it LOOKS some stupidity w.r.t. to float/double on ARM
<NCommander> (man, ARM is picky about its floating points)
<NCommander> Since this issue with float/doubles seems to only happen in KDE and Qt, I'm thinking its Qt specific vs. some bug in GCC
<glatzor> james_w, yeah, great. Do you have got a credit card? have already reserved a taxi?
<NCommander> I'm hoping/praying its just something in the input sip file I can change to clear the build failure right up
<NCommander> (although knowing my luck)
<james_w> glatzor: nijaba is arriving at the same time as well, I haven't, but I don't know if he has
<nijaba> glatzor: no, I haven't booked a cab, but there generally is no need to do so, plenty are waiting there.  I do have a cc
<NCommander> man, my external is making death noises
<NCommander> But its working fine
<NCommander> ...
 * NCommander wonders how long until it fails
<nijaba> glatzor: we are you flying in from? International?
<glatzor> nijaba, I will fry from London to SF with UA995
<glatzor> fly
 * NCommander wants to share a cab if possible
<nijaba> glatzor: I certainly hope you won't fry ;)
<glatzor> :)
<glatzor> james_w, nijaba: have you ever been to sf? where is good place to meet?
<nijaba> glatzor: ok, so we'll join at custom exit in the international terminal
<nijaba> glatzor: about a 100 times.  If you do not find me, I might be outside getting stoned from a first cigarette in about 12h
<NCommander> lool, so I found the FTBFS
<NCommander> and its ugly
<NCommander> Real ugly
<NCommander> But it does explain why Qt is a miserable pile of exceptions on ARM
<lool> NCommander: I think I'd file it under sip
<NCommander> lool, its a bug in kdelibs
<lool> NCommander: What did you find?
<NCommander> Under normal cirmstances, qreal is a typedef on double
<NCommander> But on Windows CE, and ARM its a float
<NCommander> kdelibs has a few cases where it explicately assumes double and ...
<NCommander> The hardcoded doubles need to be changed to qreal in kdelibs, AND in kdebindings
<NCommander> (unless we want to change Qt on ARM and then transition Qt's rdepends)
<lool> NCommander: Well are you sure they intended qreal and not double?
<NCommander> lool, http://pastebin.ca/1273380
<NCommander> lool, QList<double> in the source :-)
<NCommander> If we change it to QList<qreal>, it would make the assignments work properly
<ogra> are you sure it gets the QT_ARCH_ARM properly handed over ?
<NCommander> ogra, yeah, qreal becomes a float
<NCommander> I think that check exists because ARM's FPU performance kinda sucks
<NCommander> But there is no comment explaining it :-/
<lool> NCommander: My question is: are you sure they want to handle qreals and not doubles; it's the same question for QList<double> versus QList<qreal>
<NCommander> I'm not sure I'm following
<NCommander> QList is simply a container
<NCommander> lool, http://paste.ubuntu.com/79246/ - this is the generated code its choking on
<lool> NCommander: level 1) qreal is defined to foo or bar depending on various conditions; we could look into this, perhaps armel's qt is using doubles or other projects, and that would make our life simpler; level 2) kdelibs might be using qreal and doubles for various things; perhaps it calls into other APIs or simply wants double in some places
<NCommander> Its two function calls that use double vs. qreal, I think its an isolated fluke that just didn't get catched. Since the behavior is the same on all architectures expect ARM ...
<lool> level 3) sip generates code from kdelibs (AIUI) but doesn't handle some cases of type mistmatches
<NCommander> Qt's docs recommend you use their own types over C's to prevent fun mistakes like this
<NCommander> As a general rule of thumb, I don't like changing library APIs like QTs, and we'd break binary compatbility with Qt on other ARM systems if we changed qreal to double
<NCommander> (not that we really care, but ...)
<lool> NCommander: Sure, but you might have to use other types for various reasons; perhaps it's truly wrong to use double, perhaps it's not?
<lool> NCommander: TBH I don't know how much binary compatibility there is for running qt bits on arm platforms
<ogra> heh
<NCommander> Chanigng qreal's type would break it
<NCommander> Personally, I'm against changing a core library against Qt unless there is a serious reason to do so
<lool> NCommander: Well by changing double to qreal in kdelibs, you'd break kdelibs binary compatibility as well anyway
<NCommander> lool, no it won't
<NCommander> qreal == double on !ARM
<NCommander> ABI doesn't change
<lool> It doesn't change on !ARM
<lool> and !WINCE
<NCommander> Considering KDE doesn't compile on ARM ... :-)
<lool> You want to avoid an ABI change on ARM with an ABI change on ARM
<NCommander> O_o?
<NCommander> oh
<NCommander> I perfer smaller ABI changes
<lool> Anyway, I think we're being distracted
<NCommander> yeah
<NCommander> The question is do we file a bug with the Qt devs, or a bug with the KDE guys :-)
<NCommander> (there a compile time arguements to force qreal to double on ARM it seems)
<lool> Best would be to check what others are doing for qreal (1), and whether upstream kdelibs thinks of this (double -> qreal)
<lool> These are in fact orthogonal and we can solve both
<NCommander> Well, I found the note on why this was done in Qt
<NCommander> Doubles eat performance for lunch on ARM
<lool> Which ARM?  with vfp?
<ogra> which arm ? :) i heard v7 behave differently
<NCommander> We technically target v5, with v7 optimized libraries
<NCommander> and we're softfloated, unless we have an optimized library, VFP isn't used on ARM
<ogra> using the VFP of the v7 will definately be in our focus
<NCommander> Well, to get the VFP used, optimize specific binaries and libraries which would benefit
<NCommander> We'll have to figure out a way to give dpkg a brain for this case
<NCommander> (I think we need subarchitecture support in dpkg/apt TBH, but for another time)
 * ogra didnt say it would be easy ... or happen right now :)
<lool> NCommander: I think I care most for being compatible with Debian on this particular point of ABI anyway
<lool> So let's check whether Debian's qt is patched for armel and live with the same for Ubuntu's armel qt
<NCommander> Good idea
 * NCommander ventures to Debian's source packages
<lool> NCommander: In all cases, why wouldn't we want to fix sip to handle this gracefully?
<NCommander> lool, its not a bug in sip.
<lool> NCommander: Are you subscribed to the upstream kdelibs lists and all?  Perhaps you want to bring this up there
<NCommander> lool, anything trying to use these APIs would have caused a similar issue I think
<lool> NCommander: You're saying sip can't handle API's mixing doubles and qreal?
<NCommander> lool, I don't think its a bug in sip. the API and qreal should always match if you want compability with Qt types
<NCommander> sip can't be blamed if the author ignored the user friendly typedefs
<lool> NCommander: What if I need to pass doubles and qreals to two sub APIs?
<NCommander> We're dealing with the return type here of a template
<ScottK> directhex: No.  I didn't gry to get ahold of you again.  I ran into a related problem that's nothing to do with the mono transition and got stuck. I suspect, but cannont yet prove, that adjusting the build-dep as you suggested is sufficient for the transition.
<NCommander> lool, Debian doesn't change Qt's behavior
<lool> NCommander: yup
<lool> I checked the headers and the patches and didn't find any such change either
<lool> (and it does set QT_ARCH_ARM)
<NCommander> lool, Debian hasn't run into the issue on the virtue they still use KDE3
<NCommander> lool, so now what :-)?
<asac> doko_: do you maintain all java packaging in a svn repo? or are there packages that i just need to upload if i want to extend those Xpp- headers?
<lool> NCommander: Well we eliminated level 1 from the equation
<lool> NCommander: you filed level 2
<NCommander> o_o?
<NCommander> level 1/2? huh?
<NCommander> lool, well, beside KDE, I think the ARM port is fairly good in main
<NCommander> (universe is another story)
<lool> NCommander: levels: see discussion we had earlier here?
<NCommander> lool, nope
 * NCommander has been MIA over a week
<NCommander> lool, well, I looked deep within the sourcecode of kplotaxis.cpp, and its just a return of an internal variable
<NCommander> which boils down to a         QList<double> m_MajorTickMarks, m_MinorTickMarks;
<lool> NCommander: ?
<NCommander> No, I'm finding the code in kplotpoint that we're considering changing to qreal after upstream guidance
<NCommander> I'm seeing what it does specifically :-)
<lool> NCommander: By "earlier" I meant a couple of hours earlier, not days
<lool> NCommander: /lastlog level
<NCommander> ooooh
<NCommander> handy IRC command!
 * NCommander looks for KDE's SVN repo
<NCommander> Time to create a proposed patch now that I know what needs editing
<Silicium> hi there
<Silicium> i want to create a custom installer CD, this works fine with getting the packages from a external repository
<Silicium> now i want to add the custom packages to the local CD Repository
<Silicium> should i create a own new repository or should i merge my packages into the exist hardy repo?
<asac> slangasek: can you take a look at network-manager-pptp SRU in -proposed. has been pending for a while and all bugs fix committed have verification-done. thanks
<doko_> asac: "all java packaging" ?
<asac> doko_: all java plugins ;)
<hwilde> anybody an ssh port forwarding expert
<hwilde> i've got all these leftover sshd's waiting for an EOF that netcat will never send...
<doko_> asac: sun-java* in svn, openjdk in bzr
<asac> doko_: what other java plugins do we have?
<asac> or is that it for jaunty?
<doko_> gcjwebplugin will go away
<lamont> wow.  d-i actually picked the first(?) link-present interface for network config.  kewl.
<lamont> (eth2)
<lamont> dear open&*%)&$%&%vpn.  stop dropping the damn local network route. kthx
<bddebian> Fix it! :)
<lamont> so... at what point does the intrepid openvpn go ripping through the routing table and remove all routes to subnets that have supernets routed over the vpn?
<lamont> thereby leaving me with a default route pointing to, um, me.
<lamont> bddebian: well, I thought I had fixed it.. by explicitly doing the routing table addition myself, rather than telling openvpn to do it via the config.  however... it appears to do it after it runs the up script
<lamont> and it's only a problem when I plug the machine into the lan cable at home...
<bddebian> Ah :)
<psusi> TheMuso: you remember that dmraid bug with isw breakage caused by the raid10 patch I was working on?  I basically gave up as fixing it correctly is far more complicated than I first thought.  What are the odds on just backporting rc15? ;)
<Silicium> hi there
<Silicium> i have created a custom install disk
<Silicium> so how i can regenerate te main Packages file with all hashes?
<asac> doko_: gcjwebplugin.so  or IcedTeaPlugin.so what is used?
<doko_> hardy: gcjwebplugin.so, later: IcedTeaPlugin.so
<asac> doko_: and the  .so filename in the IcedTeaPlugin.so case is "IcedTeaPlugin.so" ... right?
<asac> (seems obvious, but better ask ;))
<doko_> asac: yes
<doko_> asac: but you should only see libjava-plugin.so
<asac> doko_: because of the alternative?
<asac> i need the filename of the link target
<asac> thats what mozilla sees internally
<doko_> asac: this is ugly
<slangasek> tseliot: it appears to be in binary new
<slangasek> asac: published, cheers
<slangasek> kees, Mithrandir: ah, pam_env user-environment support merged upstream
<kees> slangasek: oooh nice
<asac> doko_: you dont even know what this is about ;)
<slangasek> ScottK: thanks for filing the lintian MIRs ahead of me :)
<ScottK> slangasek: You're welcome.  I figured I asked for the sync without checking for that, so I earned it.
<sebner> ScottK: well, no I'm here :)
<ScottK> slangasek: Now we just need someone from the MIR team to actually look at them ...
<slangasek> kirkland: so why is per-user encrypted homedirs preferable to either use of ~/Private, or system-level encryption of /home?
<ScottK> Per user would be better if the user didn't trust the sysadmin?
<slangasek> ScottK: how does ~/Private not already solve that, with less of a performance hit?
<ScottK> slangasek: Dunno.
 * ScottK was taking a stab in the dark.
<lifeless> if you don't trust the sysadmin you're already wedged
<lifeless> once your CPU can read your data, so can they
<slangasek> maybe you're running SELinux at the same time ;)
<lifeless> even so :)
<lifeless> you might think you're running SELinux, but are they :)
<slangasek> my attempts to compromise the machine say yes
<lool> slangasek: Re: p7zip MIR: I wonder whether we could replace zip/unzip with p7zip
<slangasek> lool: possibly!  I have no preference, I just don't want us to ship both zip/unzip /and/ p7zip on the CDs :)
<lool> That would be more functionality and space efficient
<lifeless> slangasek: humour aside, a VM with selinux in it, and you are talking to the VM, sysadmin has raw hardware
<lool> slangasek: full ack
<pwnguin> slangasek: ive been looking at p7zip as part of squashfs
<pwnguin> slangasek: unfortunately, debian packages aren't optimized for compression
<pwnguin> but i hear the livecd doesn't have traditional .debs?
<slangasek> er?  what does p7zip (the userspace package) have to do with squashfs (a kernel fs implementation)?
<pwnguin> p7zip is the lzms implementation ;)
<pwnguin> lzma i mean
<slangasek> AIUI, p7zip is a container format.  We have an "lzma" package that implements lzma compression.
<pwnguin> huh
<pwnguin> look at the lzma package description
<slangasek> what about it?
<pwnguin> it's got 7zip all over it ;)
<pwnguin> i dare say 7zip and lzma are interchangeable terms ;)
<slangasek> they are not
<pwnguin> anyways, back to business as usual
<pwnguin> oh that's right, i remember now; 7z lets you use a lot of compression algorithms but mainly promoted lzma as it's 'new hotness'. clearly i got up too early today
<psusi> 7zip and lzma are as interchangable as gzip and lz
<TheMuso> psusi: There would really have to be a strong case for it. We could try backporting just the intel code.
<pwnguin> its more like avi and divx ;)
<TheMuso> psusi: But even then backporting rc15 is probably not a good idea.
<psusi> TheMuso: even to get it into -updates?
<psusi> err, -backports?  which was it?
<psusi> the one you have to choose to enable to get the latest and greatest
<TheMuso> psusi: -backports if an option of course, but thats not always useful to everyone.
<TheMuso> psusi: I thought you meant intrepid-updates.
<psusi> right.... but it would be better than having them install a broken version from my ppa to get their system working
<TheMuso> Agreed.
<psusi> and don't forget, it is a regression
<TheMuso> Yes I know.
<TheMuso> psusi: But just putting a newer version in backports is not ideal either.
<psusi> all I know is that raid10 patch from mandriva is a lot different than the raid10 implementation in rc15, so it seems a lot easier to just go with that rather than try to fix the very broken mandriva patch
<TheMuso> Yep agreed.
 * TheMuso will have a look at it during UDS, since rc15 allows the creation of dmraid metadata now, so I'll try creating a raid10 vm and get rc14 to try looking at it and see if I can reproduce locally.
<psusi> now if only I could make heads or tails out of this code to figure out why it doesn't like volumes with long names with spaces in them....
<psusi> ohh yea, that's true... good idea
<psusi> I've been using the metadata dumps people have attached to the bug reports to simulate the setup for testing
<TheMuso> that hasn't worked for me I've found, as you need same drives with same models, serial numbers, etc.
<psusi> you have to build dmraid with a testing option so it considers /dev/dm-* as underlying disks, place the drive serial numbers in /dev/dm-*.serial, and use dmsetup to create a device mapper that returns zeros for everywhere but where the metadata is linearly mapped to a loopback device
<TheMuso> meh I think I'll use rc15 and a vm.
<TheMuso> Anyway, I must continue to prepare for my flight today.
<psusi> hehe
<tseliot> slangasek: ok, thanks for the information
<hwilde> last chance before reinstall... anybody know why this is failing reference two different kernels ? http://pastie.org/329186
<Lancao> hi
<ScottK> Is it's a regression that qualifies for SRU, then it's really inappropriate for -backports.
<Mez> can someone confirm me this? if you install a minimal system (mine's done through debootstrap) - and then try to install openssh-server - it won't work
<Mez> I've tested it and it seems to fail with log_daemon_msg
<superm1> Mez, generally you need to divert invoke-rc.d if you are working directly in a chroot doing these kinds of things unless you bind mount /proc and possibly /sys
<ScottK> Mez: Does it depend on lsb-base?
<superm1> Mez, you can look at livecd-rootfs for an example of what's done while live disks get build
<Mez> ScottK: lsb-base is installed, and it has the call for /lib/lsb/init-functions too...
<Mez> other scripts in init seem to work, which is a bit weird.
<Mez> superm1: I am working in a chroot, yes (trying to setup an EC2 image)
<Mez> superm1: seems it was proc
#ubuntu-devel 2008-12-03
<amikrop> How is the icon most upper-left icon, set?
<amikrop> The icon left to the "Applications" menu. The Ubuntu logo in Ubuntu, and the GNOME foot, in Debian or Gentoo, by default.
<amikrop> ?
<Lancao> hi
 * Hobbsee waves
<Treenaks> hi Hobbsee
<Hobbsee> hey Treenaks!
 * Treenaks is trying to wake up, but it's not working
<Hobbsee> heh
 * Hobbsee offers a bucket of ice?
 * Hobbsee is fighting gtk
 * Treenaks runs away from the ice
<Treenaks> Hobbsee: what's the problem with gtk?
<Hobbsee> Treenaks: well, apart from a nutcase user who insists on subscribing ubuntu-core-dev to bugs, i'm looking at the "update manager keeps stealing focus & setting urgency hints while it doesn't require user input" bug
<Treenaks> Hobbsee: I think he might mean the 'updating..' window
<Treenaks> that used to do that, don't know if it still does it (no updates, so can't reproduce ;)
<Hobbsee> it does
<Hobbsee> or at least, sometimes does
<Treenaks> Hobbsee: 'sometimes' bugs are the worst
<Hobbsee> wlel, it may always do it.  i tend to minimise it, so don't see it
<Lancao> I need help on the sound when XP on the ubuntu
<Hobbsee> Lancao: #ubuntu for support, please.
<dholbach> good morning
<jeswhy> :P
<lancao> hello
<lool> slangasek: Re: #291582 you're saying this is also pushed to intrepid-proposed??
<lool> we have no intrepid psb drivers right now
<lool> (well we just got access to them, but they weren't pushed anywhere)
<lool> slangasek: Hmm given that I see no linux intrepid uploads, I guess it was an EBUGNUMBER
<hwilde> how can I send my hostname to dns with a static IP
<RainCT> hwilde: what do you mean?
<hwilde> i mean dhclient is what sends the hostname out and registers with dns right
<hwilde> /etc/dhcp3/dhclient.conf   send host-name "";
<hwilde> what if I'm using a static IP not dhclient, and I want to just send that host-name to DNS
<maxb> hwilde: to *what* DNS?
<hwilde> the dns server in /etc/resolv.conf ?
<maxb> It's sounding you don't understand how DNS works. You don't "send hostnames to DNS" (except in the special case of dynamic DNS, which is very much a special case, not the norm.)
<hwilde> so what does this do:      /etc/dhcp3/dhclient.conf   send host-name "";
<ogra> can you take that to a support channel ?
<hwilde> yeah they don't know over there
<ogra> that doesnt justify anything
<ogra> see /topic
<ogra> seb128, would you kill me if i dropped -Werror from metacity ?
<seb128> ogra: I don't care, I don't work on that one
<ogra> seb128, at least ntil upstream shows some recation on gnome bug 562106 ? so it builds on armel
<ubottu> Gnome bug 562106 in general "build error on x86_64" [Normal,Resolved: duplicate] http://bugzilla.gnome.org/show_bug.cgi?id=562106
<seb128> ogra: tarballs should not have Werror set, that's an upstream bug
<ogra> well, its helpful during development, so i understand why they do it
<seb128> the rules is usually that svn has it set but not tarballs
<ogra> ah, i didnt know gnome had a rule for that
<seb128> not sure that's a rules but that's how it's done usually
<ogra> i foungth endless wars with gnome-powermanager upstream about that
<ogra> and he insisted it had to stay
<seb128> the svn is used to do hacking work, tarballs are for users and should be buildable easily
<ogra> right
<seb128> don't bother in any case just do the change and upload to jaunty
<ogra> will do, gracias :)
<hwilde> dhclient does send the host-name to dns tho
 * hwilde stares at maxb 
<wgrant> hwilde: No, it sends it to the DHCP server. Now back to userland with you.
<hwilde> well ok then the dhcp server sends it to dns, that's not the point
<hwilde> is there any way to do that while using a static IP
<hwilde> just send the hostname, not actually request dhcp
 * ogra doesnt get why libcanberra 0.6-0ubuntu3 still shows up on jaunty_probs
<ogra> should be superseded since weeks
<ScottK> ogra: Any rdepends left?
<ScottK> IIRC NBS still needs to be run manually so it'll hang around until someone does.
<ogra> ScottK, not that i'm aware of ... there is libcanberra-gnome which is nonexisting in 0.10, but there are proper conflicts/replaces lines
<ScottK> Maybe just waiting to get NBS'ed away.
<asac> ScottK: http://bazaar.launchpad.net/~mozillateam/firefox/firefox-3.0.head/revision/380 ... cheers.
<ScottK> asac: Thank you.  That will be welcome news to a lot of Kubuntu users.
<asac> heh
<asac> i hope so ;)
<tseliot1> slangasek: can you do an upload for me (SRU) or are you too busy today?
<pqangel> hi,
<pqangel> i have a lil question anyone care to help me out?
<RainCT> hi pqangel
<RainCT> !ask
<ubottu> Please don't ask to ask a question, simply ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<ogra> meh, what happened to ubuntu-desktop ?
<ogra> ogra@osiris:~/Devel/packages/rpm-4.6.0-rc2$ apt-cache show ubuntu-desktop|grep Version
<ogra> Version: 1.124
<ogra> 1.126 was uploaded last thursday
<gnomefreak> ogra: i have 1.126
<ogra> gnomefreak, yeah, seems i was cheated by myself ... using jaunty for deb-src but intrepid for deb :)
<gnomefreak> ogra: ;)
<ogra> though i still dont get why libcanberra-gnome doesnt go away
<ogra> evil sticky thing
<gnomefreak> its been held back for a while now
<ogra> held back ? libcanberra build a week ago ...
<ogra> libcanberra-gnome doesnt exist in the new package
<gnomefreak> ogra: its replaved with -gtk
<ogra> and ubuntu-desktop shouldnt depend on it anymore
<ogra> right
<ogra> so i dont get why it still shows up on jaunty_probs ... it should have gone since a while
<gnomefreak> ogra: i dont see it as a depends of u-d
<ogra> me neither
<ogra> so whats keeping it there  ? :)
<gnomefreak> if you install it instead of upgrade it installs and removed -gnome but as to why apt isnt upgrading it im not sure
 * gnomefreak blames apt
<ogra> heh
<ogra> so easy to blame :)
<gnomefreak> pulse has almost same issue
<gnomefreak> thats why i blame apt :)
<ogra> hmm
<gnomefreak> ogra: seems any name change isnt being handled properly with apt sox is same way it removes libsox0a and installs libsox1
<ogra> i would expect that to be handled through conflicts/replaces actually
<gnomefreak> ogra: sox is right on depends
<gnomefreak> but no conflicts
 * ogra wonders  ... 
<ogra> Package: libcanberra-gtk0
<ogra> Architecture: any
<ogra> Depends: ${shlibs:Depends}, ${misc:Depends}
<ogra> Recommends: libcanberra-gtk-module
<ogra> Conflicts: libcanberra-gnome (<< 0.10-1)
<ogra> Replaces: libcanberra-gnome (<< 0.10-1)
<ogra> adding a provides might solve it i guess
<ogra> that would superseded the existing libcanberra-gnome
<gnomefreak> if it replaces/conflicts it should be handled properly
<ogra> *supersede
<ogra> not for the archive apparently
<gnomefreak> i see it
<ogra> else jaunty_probs wouldnt show libcanberra-gnome (which it can only find in v0.6)
<gnomefreak> ogra: 0.6-0ubuntu3 is >> not <<
<gnomefreak> << 0.10*1 should be >> maybe?
<ogra> <= ?
<ogra> hmm, no
<ogra> << is ok
<gnomefreak> as of now it conflicts/replaces << 0.10-1 but 0.6 is > than 0.10
<ogra> ogra@osiris:~/Devel/packages/rpm-4.6.0-rc2$ dpkg --compare-versions 0.10 gt 0.6||echo false
<ogra> ogra@osiris:~/Devel/packages/rpm-4.6.0-rc2$
<gnomefreak> hmm
<gnomefreak> it seems all held back packages can be installed but not upgraded
<EtienneG> I have a stupid question here ... can we build chroot of later release using debootstrap?
<EtienneG> ie, building intrepid/jaunty chroot on hardy?
<ogra> EtienneG, yes
<ogra> you usually need the backported debootstrap though
<EtienneG> ogra, I guess I need to get the script somewhere and drop them in /usr/share/debootstrap/scripts ?
<ogra> or install the latest debootstrap from the latest distro
<EtienneG> ogra, thanks, will look in backport then
<ogra> debootstrap is usually just installable
 * ogra always just takes the one from next release and installs it
<EtienneG> 'k
<EtienneG> ogra, shouldn't you be on a a plane already?  ;)
<ogra> tomoroow morning :)
<EtienneG> he
<ogra> EtienneG, and yourself ?
<EtienneG> I am going too, first one since Seville
<ogra> cool, looking forward to meet you
<EtienneG> ogra, same here, we will have a beer
<EtienneG> we will probably have to settle for a creepy hotel bar, but he
<EtienneG> as long as it not a dating nights or anything
<ogra> as long as its better than the wild palms bar we had last time in mountainview all is fine :)
<ogra> they closed at 6:30pm
<EtienneG> no shit!
<ogra> no :)
<EtienneG> now, that *is* bad!
<ogra> and the bus from google only started at 6pm
<EtienneG> ARRRRR!
<ogra> so we always came in for exactly one beer until they closed ...
<ogra> but they left the room open and teher was a liqor store nearby
<EtienneG> ha
<EtienneG> nonetheless, i prefer drinking in bar ... the context is just better
<ogra> yeah, lets see how the new hotel is
<ogra> though i think its the same chain
<EtienneG> there, it works with the debootstrap in backports, thanks ogra
<EtienneG> bars closing so early is kinda weird, it is
<EtienneG> Califoria after all
<ogra> well, its sunnyvale after all ...
<ogra> middle of nowhere village :)
<EtienneG> indeed
<EtienneG> too bad, i guess it will be more productive!
<ogra> heh, by nature
<ogra> since we are locked in at google during worktime
<slangasek> lool: not EBUGNUMBER, EWRONGINVOCATIONOF"sru-accept" I think
<slangasek> lool: I should've used the "-s hardy" argument when sending my autogenerated messages :/
<slangasek> tseliot1: I can do an SRU upload, but usually the SRU team are the last people you want to have sponsoring the actual uploads? :)
<tseliot1> slangasek: ah, ok, I'll keep that in mind in the future. If you're available I would be glad if you could upload the sources listed in this file to intrepid-proposed:
<tseliot1> http://albertomilone.com/ubuntu/newlrm/pitti/destination.txt
<tseliot1> this is the SRU: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/297543
<ubottu> Ubuntu bug 297543 in nvidia-graphics-drivers-180 "Update Package: nVidia 180.11" [Undecided,In progress]
<slangasek> tseliot1: changelogs for SRUs need to reference the LP bug #s for any bugs they're fixing.  Do you want to fix this and feed me new source packages, or should I take care o it here?
<slangasek> +f
<slangasek> tseliot1: also, bug #297543 doesn't currently mention -96 or -173
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/297543/+text)
<tseliot1> slangasek: right, I mentioned them here: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/297543/comments/36
<ubottu> Ubuntu bug 297543 in nvidia-graphics-drivers-180 "Update Package: nVidia 180.11" [Undecided,In progress]
<slangasek> tseliot1: well, there should be tasks open for each package that's being SRUed (either on this bug or another), so that we can track the status
<slangasek> in this case, separate bugs might be better since I guess each package needs to have SRU verification / regression testing separately?
<tseliot1> slangasek: not in this case since the changes to those packages are trivial and are related compatibility with the new driver
<tseliot1> so that installing one driver removes the other
<tseliot1> etc.
<slangasek> ok
<slangasek> then please open tasks for the other packages being SRUed
<tseliot1> ok
<slangasek> tseliot1: 173.14.12-1-0ubuntu7 -- wrong version number, you need to use a version number that sorts earlier than the version in jaunty, not later
<slangasek> e.g. 5.1 << 6
<tseliot1> slangasek: I was told that I couldn't use the same version which is in Jaunty, therefore I bumped the version in intrepid. Would it help if I bumped the version in Jaunty instead?
<slangasek> no, use 5.1 as the version number
<slangasek> there's no reason to do another upload to jaunty for this
<tseliot1> slangasek: aah, ubuntu5.1
<slangasek> yep
<tseliot1> ok
<slangasek> https://wiki.ubuntu.com/SecurityUpdateProcedures includes the best guide to package versioning in SRUs
<ogra> "make it a dolby surround version" ?
<tseliot1> thanks for the link
<tseliot1> ogra: yep 5.1
<ogra> :)
<doko> lool: was there any outcome about the arm double/qreal discussion?
<slangasek> tseliot1: I'll wait for you to post new packages with fixed version numbers and changelog bug references, then
<tseliot1> slangasek: ok, let's see if I got it right this time: 96.43.09-0ubuntu1.1 , 173.14.12-1-0ubuntu5.1, 177.82-0ubuntu1.1 , 180.11-0ubuntu0.1
<slangasek> tseliot1: should -177 be 177.82-0ubuntu0.1?  there doesn't seem to have been an -0ubuntu1 in intrepid
<slangasek> in terms of sorting with what's currently in the archive, though, all of those are fine
<tseliot1> slangasek: 177.82-0ubuntu1 was available in jaunty but now it has been superseeded by ubuntu2. I guess I can use ubuntu1 then
<slangasek> no, you can't use ubuntu1
<slangasek> you can never reuse version numbers
<slangasek> but 0ubuntu0.1 is more correct than 0ubuntu1.1, because it sorts earlier than every version that's ever been in jaunty
<tseliot1> so I was right before
<tseliot1> ah, good
<tseliot1> ok, let me upload the sources again
<tseliot1> slangasek: ok, here you go: http://albertomilone.com/ubuntu/newlrm/pitti/destination.txt
<slangasek> tseliot1: so in the preinst diff, I see that -96 tries to remove its own diversions, is that intentional or a copy/paste error?
<tseliot1> slangasek: it's intentional (because of previous versions)
<tseliot1> it shouldn't cause problems anyway
<tseliot1> since it's in the preinst
<slangasek> this reasoning escapes me
<slangasek> tseliot1: I'm not sure this dkms switch is appropriate in an SRU; is there discussion of that change somewhere in LP?
<tseliot1> slangasek: the dkms switch is not such a big change. It reuses the same directories and lets DKMS apply the patches instead of patching things in advance
<slangasek> tseliot1: how would I confirm that dkms would do the patch applying?
<slangasek> I'm unfamiliar with dkms details
<tseliot1> it is written in the dkms.conf.in
<tseliot1> I'll make an example
<slangasek> nothing there specifically mentions patches; should I just trust that the directory you're copying these into is the directory that dkms looks for patches in?
<tseliot1> slangasek: if I add the following lines to dkms.conf.in: PATCH[0]="NVIDIA-177.82_2.6.28.patch"
<tseliot1> PATCH_MATCH[0]="^2.6.2[8]"
<tseliot1> then the patch is applied only if kernel 2.6.28 is in use
<slangasek> ah - in practice this isn't an issue for 96 because the patch set is empty ;)
<tseliot1> yep
<tseliot1> if you're interested, you can do a "man dkms" and get to where it says PATCH[#]
<tseliot1> for example it says that dkms looks for patches in /usr/src/<module>-<module-version>/patches/
<tseliot1> and currently I copy patches from debian.binary/patches to what will be installed in /usr/src/<module>-<module-version>/patches/
<tseliot1> this will make things a lot easier as I can use the same sources for intrepid, jaunty, etc. just by adding new patches (in theory) and telling dkms when it should apply each patch
<tseliot1> e.g. PATCH_MATCH[0]="^2.6.2[8-9]" means apply patch[0] only if 2.6.28 <= kernel <= 2.6.29
<superm1> it also helps if someone is regressing a problem in a kernel by grabbing the kernel from release+1
 * tseliot1 nods
<lool> doko: Concerning kdebase-workspace or kde4bindings?
<lool> doko: kdebase-workspace was patched, but the new kde4bindings doesn't build anymore because of the new kdelibs
<lool> doko: On #kde-devel, people commented that kdelibs should be patched to move to qreal, but that this should be discussed on kde-core-devel@ or some similar list to make sure nobody has something to raise about the abi change on arm/wince
<lool> doko: NCommander said he would Cc: me when he mails the proposed patch there
 * lool offline now &
<ScottK-laptop> If a package needs a config file to run, but it's not provided (except as examples) and the init just prints a warning to stdout is that a policy violation or merely in poor taste?
<directhex> where are the examples stored?
<ScottK-laptop> In /usr/share/doc/$PACKAGENAME
<slangasek> ScottK-laptop: poor taste, I think; there are cases in which you legitimately want a package to not do anything by default, and I don't see a way to distinguish between those cases and the one you dsecribe, at a policy level
<ScottK-laptop> slangasek: OK.  How about writing to stdout in the init is the only warning you get?
<slangasek> sounds to me these are all bugs, just not policy violatios :)
<slangasek> n
<ScottK-laptop> OK.
<ScottK-laptop> If it was policy it'd be easier to know if it's RC or not (this affects Debian too).
<tseliot1> slangasek: let me know if you see other problems with my source code (for the upload)
<slangasek> tseliot1: sure.  I have two of them uploaded so far, moving on to 177 now
<tseliot1> slangasek: thanks a lot
<slangasek> tseliot1: was there discussion of whether 180 belongs as an SRU, given that it's a new package, vs. backports?
<tseliot1> I talked to superm1 about this. The new driver won't be suggested by Jockey unless the modalias package is installed
<tseliot1> I think it's safe to put it in updates
<tseliot1> instead of backports
<superm1> the converse to that though, considering it's a beta driver, it might make more sense to regularly update it via backports until the stable driver is released in the 180 series
<superm1> rather than always filing SRU's for such things
#ubuntu-devel 2008-12-04
<mathiaz> slangasek: do you know which libc is used in the installer environment?
<slangasek> glibc
<mathiaz> slangasek: apparently getpwuid is not working properly
<mathiaz> slangasek: in the installer environment
<slangasek> the nss modules may not be there
<kirkland> slangasek: this test program doesn't work in jaunty alpha1: http://people.ubuntu.com/~kirkland/test.c
<mathiaz> slangasek: however it ^^ works in interpid
<slangasek> there's a separate udeb, libnss-files-udeb, that contains ./lib/libnss_files.so.2; is that present in the image?
<mathiaz> slangasek: hm - no
<mathiaz> slangasek: only libnss_dns.so.2
<slangasek> well, there's the problem then :)
<slangasek> I'm not sure whether there's anything else in the installer that cares about nss_files by default, though?
<mathiaz> slangasek: awesome - works!
<kirkland> slangasek: anna-install libnss-files-udeb fixes it ;-)
<slangasek> sure
<kirkland> slangasek: we're working on iscsi at the moment
<slangasek> and that needs uids in the installer environment (as opposed to within the target chroot)?
<kirkland> slangasek: and we've got a failure somewhere in there related to a b0rked getpwuid() call
<kirkland> slangasek: well, the source code thinks it does, anyway ;-)
<kirkland> slangasek: the iscsid daemon has to be running
<kirkland> slangasek: for the iscsiadm target discovery to work
<kirkland> slangasek: the iscsid does some getpwuid() checking
<slangasek> ah, and that has to be run in the installer rather than the target in order to support install-to-iscsi, hmm
<kirkland> slangasek: right, needed to establish the scsi device
<ogra> kirkland, iscsi ? fixing the ftbfs on armel for us ? :)
<kirkland> slangasek: okay, so shall we just add a depends in the open-iscsi-udeb on libnss-files-udeb?
<kirkland> ogra: :-P
<mathiaz> ogra: doko fixed it
<kirkland> ogra: i'm sure all the armel customers out there are just dying to run with root on iscsi :-)
<ogra> mathiaz, oh, right :)
<slangasek> kirkland: that would do it, though I wonder if it wouldn't be more technically correct to remediate iscsid's uid checks
<kirkland> slangasek: what's the alternative?
<kirkland> slangasek: slashing them?
<slangasek> probably? :)
<ogra> kirkland, why not ? ARM is the perfect HW to cluster NAS arrays :)
<mathiaz> ogra: BTW are there any chroot available?
<mathiaz> ogra: for arm
<ogra> mathiaz, nope, we dont have enough HW yet, i have a board here if you need a testbuild
<kirkland> ogra: how's qemu's armel support?
<mathiaz> ogra: ok - doko's patch may not be needed anymore with the new upstream version of open-iscsi
<ogra> but the buildd machines are still busy building the archive ... and after that we'll need them for livefs builds
<mathiaz> ogra: but I don't know how to test it
<ogra> kirkland, bad for what we target ... ok for more common arm platforms
<ogra> i think qemu has support up to armv5 we're targeting armv7
<ogra> though armv5 should suffice for bare testing
<persia> No, that's not the issue.
<persia> The problem is that qemu targets armeb, and we have armel
<ogra> ah, right
<ogra> well, whats scratchbox running then ?
<ogra> i thought they use armel
<persia> armv5 vs. armv7 is just having a couple lipcap libraries, or worst-case, parallel installs (a la libc6-i686)
<persia> No, armeb
<ogra> hmm, isnt the n8x0 omap2 ?
<ogra> that should be armel
<ogra> and scratchbox targets the n8x0
<persia> omap2 doesn't require armel.
<ogra> ah
<persia> See http://qemu-arm-eabi.wiki.sourceforge.net/ for work-in-progress
<ogra> ah, right
<ogra> well, i bootstrapped my initial rootfs for the evm board in qemu-arm
<ogra> (not -eabi though)
<persia> Some of the patches were going upstream.  I haven't tested the latest.
<ogra> anyway, i'll better go to get some sleep now ... else i'll miss my train
<ogra> night
<lifeless> persia: what was the session you wanted me at?
<persia> Well, we were discussing https://blueprints.launchpad.net/ubuntu/+spec/archive-reorganization , but it might be a bit strong to say I wanted you there, rather that I thought you might be interested based on your thoughts on the model.
<persia> kirkland, Is armel support included in any of the svn snapshots for the current qemu?
<kirkland> persia: i haven't checked
<persia> kirkland, OK.  I'm not sure of the upstream status, and saw the svn pull and hoped.  I suppose I ought install jaunty on something.
<kirkland> persia: :-D
<kirkland> persia: i'll check for you later tonight
<kirkland> persia: i merged qemu from debian;  soren merged from svn shortly thereafter
<persia> kirkland, Hrm?  That doesn't match the changelogs I see, and now I'm confused.
<persia> I see svn snapshots in Debian experimental, and a changelog with your name claiming a merge from Debian unstable (but it looks like a merge from experimental)
<kirkland> persia: I uploaded 0.9.1-7ubuntu1, -- Dustin Kirkland < kirkland@canonical.com>   Thu, 20 Nov 2008 18:10:36 -0600
<kirkland> persia: soren uploaded 0.9.1+svn20081112-1ubuntu1, https://edge.launchpad.net/ubuntu/+source/qemu/0.9.1+svn20081112-1ubuntu1
 * persia fails at diff-reading
<kirkland> persia: i, too, dislike the fact that Launchpad drops the uploader from the changelog of the last entry at https://edge.launchpad.net/ubuntu/+source/qemu
<persia> At one point it listed it, but it was removed in response to a bug about it usually getting it wrong.
<persia> (for various values of "it")
<persia> I think the plan was to take a deeper look at the concept of "Changed-By" and "Last Changelog By", but that probably awaits the next UI changes.
<kirkland> persia: i am a little puzzled why soren's upload "replaced" my changelog entry ... http://launchpadlibrarian.net/19890588/qemu_0.9.1-7ubuntu1_0.9.1%2Bsvn20081112-1ubuntu1.diff.gz
<kirkland> persia: oh, wait, nevermind ... it's further down in the diff
 * kirkland fails at diff-reading, too
<persia> kirkland, That's just the format.  Scroll down to 0.9.1-7ubuntu1 (confusingly underneath 0.9.1+svn20080822-1 )
<persia> I suspect the version issues are related to the branching on the Debian side : it would be less confusing if there was a common parent between your merge and soren's.
<calc> pitti: you there?
<FAJ> hi, i am trying to set up a ppa, but am having difficulties with signing the ubuntu code of conduct...
<FAJ> can anyone help?
<FAJ> It says that there is no public key?
<Hobbsee> try #launchpad
<persia> FAJ,
<slangasek> kirkland: ok, so open-iscsi uses getpwuid for peercred validation... it's questionable because they're hard-coding a check against "root" instead of just hard-coding one against uid 0, but probably non-trivial to correct, might as well just add the udeb dep :)
<elpargo> hi, anyone knows if they are any plans to upgrade firebug in ubuntu -1
<elpargo> lastest package is a version from svn due to a bug.
 * Hobbsee wonders what ubuntu -1 is, as she heads out
<elpargo> Hobbsee, 8.04 :)
<kirkland> slangasek: so we came to the same conclusion, independently ...  the "root" string check vs. "0" uid check is kinda dumb...
<kirkland> slangasek: but, ultimately, open-iscsi-udeb already depends on the lib-nss-files packages
<kirkland> slangasek: mathiaz and i brought this problem on ourself, though, in testing the installer
<kirkland> slangasek: we were udpkg -i 'ing our own new open-iscsi udeb
<kirkland> slangasek: rather than anna-install'ing the open-iscsi-udeb already on the cd
<kirkland> slangasek: so we hadn't pulled the dependencies
<kirkland> lose.
<slangasek> kirkland: ah :)
<kirkland> slangasek: yeah.  doh.  sorry for your cycles :-)
<fabbione> doko_: ping?
<doko_> fabbione: pong
<fabbione> doko_: what's up? i saw your ping this morning
<doko_> fabbione: sparc ... can you reproduce the build failures of gcc-4.1/gcc-4.2 locally?
<fabbione> doko_: i haven't built gcc.. but I can try
<fabbione> doko_: what release? what chroot? info please? :)
<doko_> fabbione: jaunty
<fabbione> doko_: ok.. i'll give it a shot when I can
<soren> kirkland: My changelog entry didn't replace yours. It's just diff(1) being confusing. Both of our entries were at the top and they looked similar, so diff shows it as though mine replaced yours and then added yours again further down. Check the final changelog.
<soren> kirkland: If you already worked that out, sorry. On this internet connection, even just scrolling back through irc logs is painful :)
<fabbione> soren: everything working like a charm now! thanks for the help the other day
<soren> fabbione: Ay time, dude. Glad to hear it.
<soren> any time, even.
<fabbione> soren: eheh
<fabbione> i just wish virt-manager was a bit more mature to configure machines from remote
 * soren nods
<kirkland> soren: yep, figured that out eventually :-)  sorry
<soren> kirkland: No worries.
<asac> doko: how can #pragma GCC diagnostic ignored "-Wstrict-prototypes"
<asac> be made apply to only a few lines ... or how to unset that if its in a header (so its restricted to that header at least)
<doko> asac: see the gcc-4.3 manual, section 5.52.9 Diagnostic Pragmas
<asac> doko: link?
<doko> asac: apt-get install gcc-4.3-doc
<asac> doko: i can see how i can change it explicitly to warning again. but how can i reset to the "default"?
<asac> or is "warning" default?
<doko> asac: probably depends on the options used to run gcc. I don't know
<asac> doko: yeah. i guess warning is correct
<hunger> Any idea why the kdegames stuff build on LP yesterday is not in the archives yet?
<hunger> other kde stuff build later is available:-(
<hunger> Is it possible that kdegames (and others) contain new debs that require it to get ok'ed before going into the archives?
<NCommander> hunger, yeah
<hunger> Could somebody please OK it then?
<persia> hunger, It is possible.see https://launchpad.net/ubuntu/jaunty/+queue
<persia> The archive admins review that every couple days, and tend to push things through as long as the changes are sensible.
 * hunger sighs.
<hunger> Currently I can not even start the unholy mix of kde 4.2 and 4.1 in the archives:-(
 * NCommander sighs
<NCommander> Binary NEWs
<NCommander> I still don't know if thats a feature or a bug
<persia> Definitely a feature.
<ScottK-laptop> https://launchpad.net/ubuntu/jaunty/+queue?queue_state=0&queue_text=kde
<NCommander> Ok, finally
<NCommander> kde4bindings built
<NCommander> YAY!
<NCommander> er
<NCommander> kde4libs built and installed
<bigon> I have 4 pkg (compiz-fusion-plugins-main libv4l-0 system-cleaner system-cleaner-gtk) installed on my machine (running jaunty since yesterday) that have higher version in intrepid than jaunty :/
<liw> bigon, system-cleaner was updated in hardy to fix some serious bugs, I'll have an update for intrepid as well in the near future, sorry about the confusion
<hunger> Any archive admins around who can push the kde beta stuff through the new queue?
<allquixotic> Hello. I'm looking for approval to do an SRU for a main package in Intrepid. I've filed a bug yesterday and am now informally poking anyone interested to take a look and provide feedback, please. :) https://bugs.launchpad.net/ubuntu/+source/libshout/+bug/304843
<ubottu> Ubuntu bug 304843 in libshout "SRU Request: libshout3 in intrepid" [Undecided,New]
<lifeless> I have a weirdness removing a kernel package, what package should I file the bug on?
<persia> lifeless, What sort of weirdness?
<persia> (and #ubuntu-bugs is generally a better forum for this class of question)
<lifeless> persia: regenerating initramfs for the thing being removed
<persia> I'd file that against "linux", although I suspect it's because there's still some modules package left unpurged.  Probably useful fodder for the kernel packaging UDS session next week.
<lifeless> its related to a linux-restricted-modules removal bug I found too
<lifeless> which is that if someone has removed a kernel by hand
<lifeless> removing the lrm package blows up on System.map missing
<persia> Well, that's arguably a case of someone shooting themselves in the foot, but it's all part of the same collection of scripts to generate maintainer scripts for the kernel packages.
<lifeless> persia: not really, lrm can be configured but no installed
<lifeless> you can't drop it to purged without having the system.map present :P
<persia> Ah.  I had thought that was part of the configuration, but if not, then certainly a bug.
<lifeless> I have a bunch of lrm packages that are state 'c' and can't be removed
<lifeless> I suspect its unusual to get this way, but once here its wedged
<persia> I suspect you'd have to either install the relevant kernels (or at least configure them), or fake it.
 * StevenK returns from breakfast, disenheartened.
<lifeless> oh, I had them installed
<pitti> calc: HI
<Chipzz> persia: I would say it's not someone shooting themselves in the foot. lrm should depend on the corresponding kernel, and hence be removed when the kernel gets removed
<Chipzz> simple matter of dependencies\
<Chipzz> unless by "shooting themselves in the foot" you mean dpkg -P --force-all the corresponding linux kernel :P
<persia> Chipzz, I mean simply rm -f /boot/vmlinuz-${whatever}
<apw> superm1, you about?
<apw> superm1, i have a debdiff against dkms and it looks like you are the man to talk to about getting it applied
<superm1> apw, yeah i just saw it on kernel-team.  i just added it to trunk, go ahead and upload it to jaunty too
<apw> oh is there a spearate tree for it somewhere?
<superm1> apw, only dell employees have access to the git tree
<superm1> apw, so normally submitting patches to dkms-devel ML is the way to go, but i happen to be on kernel-team ML too, so this works
<apw> superm1, thats my bad for not looking for the upstream
<superm1> apw, er you don't have core-dev rights do you.  do you need a sponsor then for that patch into jaunty?
<apw> superm1, any reason for it not to be externally accessible, the git tree?
<apw> superm1, nope, no upload privs here, a sponsor would be great
<superm1> my bad, it's accessible at linux.dell.com, just only writable by internal
<apw> oh then that makes complete sense
<superm1> http://linux.dell.com/git/?p=dkms.git;a=summary
<apw> and my bad for not noticing it, i assume its int he control file
<superm1> apw, okay i'll sponsor it for you in jaunty then.
<apw> yep there it is, my bad
<apw> how does that work then, this is my first time (upload virgin)
<superm1> apw, no problem. i'll just grab that patch out of the email and do the upload for it.  you've got it right with a debdiff in the email
<superm1> is there a bug opened for this though?
<apw> yes bug #300773, referenced in the diff
<ubottu> Launchpad bug 300773 in linux "Removal does not clean up after dkms, l-r-m(?)" [Medium,In progress] https://launchpad.net/bugs/300773
<apw> in the debian/changelog entry i mean
<superm1> ah i read right past it.
<apw> oh hrm, that debdiff is against intrepid, do i need to make a new one against jaunty
<apw> and how indeed do i get the jaunty source ... hmmm ... /me goes find out
<superm1> no it's okay. it's a small change, s/intrepid/jaunty i'll just do and upload
<superm1> apw, but you've got it right putting the debdiff on the bug and grabbing the main uploader or a main sponsor, so good job with that :)
<apw> so how does one get the source for a non-'the one i am running' system
<apw> superm1, one tries.  have to learn somehow and bugging people seems to work :)
<superm1> apw, so it turns out the same version is in jaunty and intrepid.  you can look here:  https://edge.launchpad.net/ubuntu/+source/dkms
<apw> so it is
<superm1> apw, if that wasn't the case, then you could grab the orig.tar.gz and such from launchpad, or you could add a jaunty deb-src entry to sources.list
<apw> ahh i can add just the jaunty deb-src's can i, and then i can use t
<apw> the =version to get the jaunty one i guess
<apw> superm1, ok, as its the same version i wonder if we should SRU it to Intrepid
 * apw is in two minds, its such a small mess made against its pretty simple to fix
<superm1> apw, up to you.  i think with such a simple fix an SRU does make sense
<superm1> so you can nominate it to intrepid on that bug, and then follow the SRU process at https://wiki.ubuntu.com/StableReleaseUpdates
<apw> well i guess then i'll take it under advisement, in that it only makes sense to bother with that if we also fix the kernel issues there too
<apw> so we can have that discussion on the kernel-list in tandem for both
<superm1> what's the kernel side of the issue?
<apw> the kernel makes a mess in the /lib/modules/<version> too
<apw> not cleaning out some of the depmod information
<apw> so that also stops the directory going away when the modules are deinstalled
<superm1> apw, so another comment about uploading methodolgies, don't worry about sending patches for packages that are not within the kernel team's direct responsibility (linux,linux-meta,lrm,etc) to kernel-team ML.
<superm1> ah i see
<superm1> but for those other packages, i'm not sure the kernel-team ML policy.  i thought it was just for SRU's they all needed ack'ing, but perhaps that's changed
<apw> superm1, yeah it seemed appropopriate to send it there too as it was a fix for a problem the kernel people were seeing
<apw> yeah ... as its jaunty it probabally can just be shoved in, but it does change the semantics of when we remove them so some discussion may be appropriate
<apw> and frankly even if i was jsut going to commit it, it being in the logs and recorded seems appropriate
<superm1> right
<apw> i am not used to not sending it somewhere ... too much kernel work in the community
<apw> superm1, so does dkms only build on i386?
<superm1> apw, it only builds on one architecture because it's arch all.  that means the same binary package works on all architectures
<kees> doko: isn't bug 305176 just a complaint about -D_FORTIFY_SOURCE=2 ?
<ubottu> Launchpad bug 305176 in glibc "[PR25509] can't disable __attribute__((warn_unused_result))" [Unknown,Confirmed] https://launchpad.net/bugs/305176
<apw> ahh i see, and that doesn't appear as 'generic' it just appears as i386 or something
<doko> kees: no, just the question why this attribute is set for fwrite, and not for fprintf/printf
<kees> doko: okay, fair enough.
<Tuju> we're packaging fonts to ubuntu, should we use defoma or is that being removed?
<slangasek> defoma is not being removed, TTBOMK?
<Goodi> bug #279824 seems to indicate that
<ubottu> Launchpad bug 279824 in update-manager "ionice Update Manager" [Wishlist,Triaged] https://launchpad.net/bugs/279824
<Goodi> well.. not that :)
<Goodi> on debian side -  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279824
<ubottu> Debian bug 279824 in perlftlib "O: perlftlib -- Perl module for the FreeType library" [Normal,Closed]
<Goodi> the defoma-hints program is broken since the perlftlib was dropped
<slangasek> well, that implies someone's doing a bad job of maintaining it, but doesn't say anything about it being removed
<Goodi> slangasek - jep, but it's been like that for a long time... just makes me wonder how we're actually supposed to use defoma if I can't create new font hintfiles...
<slangasek> Goodi: hmm, I'm afraid I don't know, I'd never heard of defoma-hints before and didn't recall that this was something that had to be run as part of setting up defoma
<Goodi> and what's the big deal with the hintfiles anyway... it's not needed in fedora/rhel.
<Goodi> all the *ttf* fontpackages seem to use defoma
<Goodi> slangasek - then there might be some other way ... but what it would be
<NCommander> Nice codeblocks got rejected
<NCommander> -_-;
<StevenK> NCommander: "U looz"
 * NCommander whacks StevenK with his ARM board
<StevenK> Which is currently, 11,000 km from me
<NCommander> o_o?
<Nafallo> ...details
<StevenK> It's in Sydney, and I'm not.
<lifeless> WTB: 1 suborbital arm whacking launcher
<Goodi> and the defoma-hints segfaults with OTF (opentype) fonts on gutsy (which do have the perlftlib)
<wasabi> heh. wow. i can't eject this CD from the drive.
<wasabi> it keeps trying to remount itself.
<slangasek> with or without the tray opening?
<jdong> lol isn't this a known bug?
<jdong> press the eject button like there's no tomorrow, you'll get the timing right eventually :D
<slangasek> there was a known, release-noted bug in Ubuntu 8.10 about this, yes; the fix is in intrepid-updates
<slangasek> I wasn't sure if he was describing the same bug or a different one, though
<wasabi> tray doesn't open
<wasabi> 'eject' won't do it either. i guess it's being mounted quicker than eject can umount and eject
<wasabi> s/mounted/remounted/
<slangasek> that doesn't really sound like the same bug to me, but ICBW
<calc> pitti: i'll just talk to you when i get to the hotel tonight (if i see you), should be there around 7pm
<calc> pitti: i was going to ask you a question about the email you sent out, but dont have time right now, since i have to catch my flight
<pitti> calc: ah, fine; I guess we'll arrive around the same time, maybe a little later
 * calc bbl
<pitti> calc: safe travels!
<calc> pitti: my flight gets in at 5:40pm
<calc> pitti: so i should be the hotel by 7pm i am guessing
 * calc throws his stuff together to head to the airport, heh
 * calc probably bbia 8hr or so
 * slangasek waves to calc 
<apachelogger> james_w: we just did our first release from a bzr branch :D
<wasabi> while true; do eject /dev/cdrom10; done
<wasabi> That got it!
<wasabi> of coruse now it's opening and closing repeatidly.
<Company> wasabi: try while true; do eject /dev/cdrom`seq 1 100 | shuf | head -1`; done next time
<wasabi> heh.
<wasabi> so now there's no cd, but it's stuck closed
<ion_> Brute force for the win.
<Company> is there a better way to get random numbers in the shell?
<wasabi> and kernel is spewing out drive timeouts.
<wasabi> i wonder if it's still processign my ejects.
<n1lo> How to active the kernel framebuffer?
 * ion_ hadnât noticed shuf before. Thanks. I had used âruby -e 'print ARGF.sort_by { rand }'â in the past.
<Company> ion_: it's pretty new
<n1lo> ?
 * Company uses it for looking for mp3s to play with ls -l | shuf
<Philip5> don't know how offtopic this is but does anyone here know if it's possible to make pbuilder to halt if the the build breaks and if so i would like to login to the pbuilder session and look around.
<Philip5> can it be done?
<directhex> preserve buildplace, something like that?
<Nafallo> Philip5: -motu is probably more correct, and I believe the pbuilder package includes example hooks.
<Nafallo> :-)
<Philip5> oki
<Philip5> :)
<mohbana>  if i install via jreu11 via update-alternatives --config java does the webplugin get installed as well
<tkamppeter> pitti, hi
<tkamppeter> pitti, can you have a look at https://blueprints.edge.launchpad.net/ubuntu/+spec/printer-driver-auto-download-service? Who else from Ubuntu I should invite to that meeting?
<pitti> tkamppeter: hey! greetings from San Francisco
<pitti> tkamppeter: I think we should have mvo, he's a key person for signed archives
<dublpaws> is there a transition team working on python 3.x source updates?
<persia> dublpaws, There's at least some interested parties in making the necessary preparations.  I'm a little out of date, but last I heard the plan was to still target 2.x for Jaunty, while trying to get as much of the source 3.0-acceptable as possible.
<dublpaws> I see.  a daunting task no doubt.
<persia> From the little I understand, yes :)
<exarkun> What kind of source updates are you thinking of?
<directhex> to the debian/patchesmobile!
<persia> exarkun, Aren't there at least some small syntax changes from 2.5 to 3.0?
<exarkun> Yes, indeed
<dublpaws> I guess I'm worried about the packages that are more or less collecting dust, "just work"ing.
<Treenaks> persia: that, and standard library changes
<exarkun> But I'm wonder if dublpaws wants someone to start patching upstream code
<exarkun> Or what
<Treenaks> persia: python 2.6 has a 'warnings' mode
<persia> dublpaws, If you'd like to test and fix, I'm sure the python team would appreciate patches to adjust to work 3.0, as long as it still works with 2.x (I think 2.6, but I could be mistaken)
<ScottK-laptop> We need to get stuff working with 2.6 first and doko hasn't uploaded 2.6 yet.
<exarkun> Most programs cannot be expressed such that they are both valid 2.6 and 3.0 programs.
<ScottK-laptop> exarkun: Isn't that 2.5/3.0.
<exarkun> ScottK-laptop: Nope.
<ScottK-laptop> exarkun: I thought the point of 2.6 was to support transition?
<exarkun> I mean, _more_ programs can't be expressed as valid 2.5 and 3.0 source. :)
<Treenaks> ScottK-laptop: that's waht the warning mode is for
<exarkun> But most also cannot be valid 2.6 and 3.0.
<Treenaks> ScottK-laptop: "This wouldn't work in 3"
<ScottK-laptop> I see.
 * ScottK-laptop anticipates a LONG transition
<exarkun> The best the Python development team thinks you can hope for is to be able to express a program as valid 2.6 source which will be warning free in the "3.0 warnings" mode
<Treenaks> ScottK-laptop: so does the python foundation.. at least a decade
<exarkun> And then run an automatic source translation tool over it to produce the 3.0 source
<persia> But adjusting that which wouldn't work in 3 might not work in 2.6?
<Treenaks> persia: exactly
<exarkun> For a project I'm a developer on, the tool generates a megabyte of diff.
<lifeless> py3 is a new language that happens to look similar :)
<ScottK-laptop> lifeless: It's not that different.
<Treenaks> lifeless: and work similar, too
<persia> Ah.
<exarkun> So "long transition" is a good way to think about it, yea :)
<tkamppeter> pitti, you are already in SF?
<lifeless> ScottK-laptop: for the purpose of this discussion it is different enough
<ScottK-laptop> I suppose.
<tkamppeter> pitt, so I will add mvo.
<lifeless> ScottK-laptop: its not as close as two editions of the C language spec
<persia> lifeless, Is it as different as e.g. C and ObjC ?
<exarkun> aren't all valid C programs also valid ObjC programs?
<ScottK-laptop> persia: No.
<tkamppeter> pitti, added.
<persia> exarkun, No, although I believe that is true for C++
<exarkun> it's not true of C++ because of new keywords at least
<exarkun> Why isn't it true of ObjC?
<exarkun> wikipedia says "Objective-C is a strict superset of C. That is, it is possible to compile any C program with an Objective-C compiler."
<exarkun> if we trust wikipedia :)
 * exarkun checks to see if it also says that about C++
<persia> I seem to remember some issue with treatment of structures, although it's been a decade since I spent much time with ObjC, so my memory is a bit fuzzy.
<exarkun> ah no, it says "C++ is often considered to be a superset of C, but this is not strictly true."
<persia> exarkun, From http://objc.toodarkpark.net/grammar.html it appears ObjC suffers from keyword issues as well.
<lifeless> persia: all C programs are not all valid C++ programs; in that their behaviour may change too
<lifeless> OTOH, stat.st_time added a C keyword by fiat, so I'm sure comparing standards is enough anyhow :)
<exarkun> stat.st_time?
<persia> heh
<lifeless> yes
<jcastro> lifeless: are you here yet? (hotel?)
<lifeless> jcastro: kindof :) - I'm on leave today
<jcastro> no worries
<lifeless> jcastro: I will be swinging by to the hotel a bit later, couple of hours from now
<jcastro> sweet
<lifeless> exarkun: st_*time is now a macro
<lifeless> #ifdef __USE_MISC
<lifeless> ...
<lifeless> # define st_atime st_atim.tv_sec        /* Backward compatibility.  */
<lifeless> ...
<lifeless> #else
<lifeless>     __time_t st_atime;                  /* Time of last access.  */
<lifeless> ...
<lifeless> #endif
<lifeless> this means that if you use st_atime for *anything* other than accessing the contents of a struct stat's st_atime field... it will blow up
<exarkun> ow
<lifeless> and doing #undef st_atime will make people look at you weirdly
<guille_> hi all
<guille_> i'm installing ModPerl in Apache2, and they use the namespace ModPerl for everything, but in cpan it's Apache? (from the start to the end of, am i wrong?)
<ScottK-laptop> guille_: #ubuntu-server is probably a  better place to ask.
<lifeless> exarkun: the particular joy through which I found that out btw - pyrex, writing an attribute on a class, called st_atime
<exarkun> hah, I bet that was fun.
<lifeless> turns out you can't have a C function called _py_2_st_atim.tv_sec
<lifeless> (or whatever the exact pyrex mangling gave, I don't recall)
<NCommander> Can a buildd admin please rescore kde4libs on armel?
<kirkland> pitti: i'm wondering if you might review the adduser patch i attached to https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/302870 and sponsor?
<ubottu> Ubuntu bug 302870 in adduser "add support for setting up encrypted home directory on user creation" [High,In progress]
<mohbana> has anyone installed java 6 update 11, i'm stuck with installing the plugin
<pitti> kirkland: can you please sub me? still @ conf
<kirkland> pitti: already did, "pitti", right?
<pitti> kirkland: right
<kirkland> pitti: awesome, thanks, i'm heading for a plane soon
<kirkland> pitti: be there later tonight ;-)
<pitti> kirkland: looking forward to seeing your again
<kirkland> pitti: likewise!
<mohbana> hello ....
#ubuntu-devel 2008-12-05
<mohbana> do i need nspluginwrapper for java 32bit
<Hobbsee> mohbana: #ubuntu for support, please.
<TheMuso> c
<fabbione> soren: ping?
<soren> fabbione: Wazzup?
<fabbione> soren: nevermind... apt-get install acpid in the guest and virsh define foo.xml did it
<fabbione> soren: the management for that stuff in hardy is really bad.. and unclear
<fabbione> soren: is there a specific reason why virsh reboot <domain> is not supported?
<soren> fabbione: Isn't it?
<fabbione> soren: nope... it's not
<fabbione> soren: keep in mind.. hardy
<fabbione> soren: libvir: error : this function is not supported by the hypervisor: virDomainReboot
<soren> fabbione: Hm... Same in Intrepid (and Jaunty), it seems.
<fabbione> soren: ok..
<soren> Weird. I'venever used it.
<soren> Apparantly.
<fabbione> well it's a pain :)
 * soren wonders how that would work... 
<soren> Is there an ACPI reboot event of some sort?
<NCommander> soren, yeah, there is, but I'd need to look it up
<soren> NCommander: Looking at acpid and friends, I don't thingk we have anything that handles it, though.
<NCommander> handles, what, reboots?
<NCommander> That's all kernel space
<NCommander> Its done via a syscall
<soren> NCommander: Err... Yeah, but something in userspace needs to shut everything down, just like when we handle an acpi shutdown event.
<NCommander> soren, I honestly won't be suprised if halt simply called int 0x80 directly,
<NCommander> soren, shutdown simply changes the runlevel to 0 which handles the shutdown
<soren> Yes....
<soren> When you press your power button, acpid catches this, does a bunch of stuff, and finally calls shutdown.
<NCommander> I think I'm missing your question soren
<soren> a) Does an ACPI reboot event exist?
<soren> b) If it does, is there anything that will handle it?
<NCommander> Define ACPI reboot event
<soren> AFAICS, the answer to b) is "no".
<NCommander> You mean an ACPI event from the kernel to reboot the machine?
<soren> The acpi subsystem can emit events of various sorts.
<NCommander> Oh, I get it
<soren> Like when you press your power button.
<NCommander> Ok, I don't
<NCommander> I assume we're talking about a hardwired reboot button?
<hyperair> the reboot button is generally a hard-reboot button
<hyperair> doesn't even hit the software
<hyperair> i don't think there's an acpi event for that
<soren> I've never seen a machine with a "reboot" button, but that doesn't mean acpi couldn't support it.
<NCommander> I have
<NCommander> as hyperair says
<hyperair> so have i
<soren> "reboot"? Not "reset"?
<hyperair> all the older PCs have it
<hyperair> oh
<hyperair> hmm
<NCommander> Some newer servers do too
<hyperair> reset most probably
<NCommander> Someone would have to go digging in the ACPI specifications to find out the answer to 1.
<hyperair> i don't think there's such a button, really
<hyperair> "reboot" button?
<soren> If b) is "no", a) doesn't matter :)
<hyperair> probably not?
<directhex> calc, FYI: OOo 1:3.0.0-6 from experimental works with the mono 2.0 transition
<NCommander> Nice!
<directhex> NCommander, t'is the only green for debian on http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO o_o
<NCommander> ah
<directhex> lots waiting to be sponsored, some left to be done (for apps, this is)
<_Groo_> hey/all
<_Groo_> is this the right place for kubuntu dev also?
<PeskyJ> ahh, I see from the topic this is not channel for app dev discussion, what is the channel for that? I've never developed an app for X before and want to get started
<directhex> PeskyJ, picking a language or framework is a good starting point, then try channels related to it
<directhex> PeskyJ, if you already program a given framework, you can just go from there. if you want something different, pick it & find some tutorials
<PeskyJ> directhex: well probably C++ will be the language, but I have no idea about programming for X so my initial questions are mostly related to frameworks does KDE* work on gnome and vice versa, is there a portable one that works on more/other systems, etc. etc.
<hyperair> PeskyJ: i'm using C++ and gtkmm
<directhex> Qt is the framework you're thinking of, and yes, you can run Qt apps fine on gnome
<hyperair> actually i think qt is more portable than gtk, and especially if you use qt4, you can get a nice native look even on GNOME environments. the file chooser will be different though.
<directhex> gtk's much more popular for proprietary apps, if you weren't planning on heading down a free software route
<hyperair> directhex: why so?
<directhex> hyperair, LGPL versus GPL/Â£Â£Â£Â£Â£Â£Â£Â£Â£Â£Â£
<hyperair> what's with the pound signs
<directhex> hyperair, qt's the most expensive & restrictive framework on the market if you don't want to GPL your app
<hyperair> i see
<directhex> hyperair, enormous price, per-seat cost, and explicit forbidding in the license to dev against the free one then recompile later against the expensive one
<hyperair> but opera went for qt anyway
<hyperair> and so did virtualbox
<directhex> yep
<hyperair> and skype
<directhex> vmware's gtk though, as an example
<hyperair> yeah
<hyperair> but that's the only one i know of that's proprietary
<hyperair> crossover uses what?
<NCommander> Qt is nice because it looks and feels consistant on all archs
<NCommander> GTK applications stick out on non-*nix architectures
<directhex> true. that's one reason it's used
<PeskyJ> directhex: I haven't even looked at or considered licenses yet.. don't want to be commercial though, whatever is most free (I don't really know much about this area) - I think that means GPL
<NCommander> That being said, I perfer GTK over Qt apps
<hyperair> NCommander: the last time i ran a gtk app on windows, it looked pretty nice
<hyperair> i think it was pidgin
<hyperair> had a pretty native look about it
<NCommander> GTK is getting better
<NCommander> but look at codeblocks
<NCommander> On windows, its hard to tell its not native
<directhex> there's a windows theme for gtk, which hooks into the windows theme subsystem
<hyperair> yes, that's true
<hyperair> directhex: yeah that's what i was talking about
<directhex> but not all gtk widgets can be rendered by windows gdi+
<NCommander> directhex, its similar to SWT
<hyperair> NCommander: wx looks good on windows, but not as good on gtk, especially with dark themes
<directhex> e.g. gdi+ has no concept of a notebook with tabs on the side instead of at the top
<NCommander> GDI is just the drawing API
<NCommander> It has no concepts of widgets and such :-)
<hyperair> the last time i tried my hand at windows GUI programming, everything was statically sized. yuck.
<hyperair> well not really "tried". i carried it through. those were my two a levels computing projects
<NCommander> You need to remember Win32's APIs are similar to say DOS C APIs than something more modern
<PeskyJ> ok... so it seems that GTK or Qt would be the frameworks to use
<NCommander> TBH, I don't actually mind raw win32 too much if I'm not doing something too crazy
<directhex> hyperair, standard windows toolkits use pixel-based layout
<hyperair> PeskyJ: you could also use GNOME and KDE libs, but unless you bind the user to a DE
<NCommander> hyperair, well, GNOME is essentially GTK
<directhex> hyperair, the first "proper" toolkit from MS is the Windows Presentation Foundation for .net. all the nice things like container-based layout.
<NCommander> directhex, well, there was MFC ...
<hyperair> MFC is hell
<NCommander> No denying it
<PeskyJ> hyperair: that's what I wanted to avoid... I have ubuntu gnome and I tried to run something that was KDE specific and it really didn't like it... I want to avoid restricting the environments it can run
<NCommander> But MFC made Win32 programming not be incredibly difficult
<NCommander> Then again, raw Win32 programming with resource files isn't horrible if you know what you are doing
<hyperair> PeskyJ: qgtkstyle is coming. in fact, it's in my PPA. all QT4 applicatiosn can look very native in GNOME. even skype and virtualbox
<hyperair> NCommander: you've got to hook onto the resize event and then resize everything yourself
<hyperair> and do the calculations
<hyperair> bah
<hyperair> what a nightmare
<NCommander> hyperair, no you don't
<hyperair> you don't?
<NCommander> hyperair, don't catch RESIZE, and then let DefProcWindow() handle it
<PeskyJ> hyperair: qgtkstyle? is that yet another framework?
<NCommander> Unless your using custom widgets, it works fine
<NCommander> If your using custom widgets, then you need to have catch the resize event, resize your widgets, and then pass it along
<hyperair> PeskyJ: no, it's a qt engine that uses Gtk to render, so everything coded in qt4 and above looks nice and native in GNOME
<hyperair> NCommander: scary. i never bothered dealing with resizing. it was a visual basic 6 project
<NCommander> ewww
<hyperair> i just arranged my widgets nicely and then removed the resizable property
<hyperair> heh
<NCommander> You shouldn't have to do that in VB6
<NCommander> YOu can get something similar with resource files
<hyperair> wel you know what, that's all they taught
<NCommander> Resource files with raw Win32 APIs aren't too bad
<NCommander> Unless you need to do something nutty
<PeskyJ> hyperair: so it sounds to me like the best recommendation would be to use Qt, then it can run in KDE, Gnome, Windows, etc. right, and with the advent of qgtkstyle it will even look like a native app?
<hyperair> PeskyJ: well, gtk and qt4 are on equal ground on this one i would say
 * directhex uses gtk#, but will not evangelize here ;)
<NCommander> I'd go with Gtk
<hyperair> gtk looks native on kde already
<hyperair> even with kde3
<NCommander> But Qt apps usually look like KDE apps on GTK environments
<directhex> oh, you wanted c++....... iirc qt is threadsafe, gtk is not. if that matters to you
<NCommander> Only parts of Qt are threadsafe (if you use QThreads ..)
<PeskyJ> directhex: I'm not too bothered about the language actually.. C++ is just probable.. I could learn python or something else if required.
<NCommander> ARGH
 * NCommander lets a trail of obscenities go
 * DktrKranz filters NCommander context
<NCommander> DktrKranz, sorry
<NCommander> ANother KDE/Qt FTBFS
<DktrKranz> \o/
<NCommander> I think Qt lies when they say Qt is portable
<PeskyJ> well.. I would likely be using threads a lot, not so sure if I understand what impact the windowing environment being threadsafe is though - surely you can post messages safely from any thread in all windowing environments??
<NCommander> At least I know my fixes will work
<NCommander> If I can stay sane enough to finish writing them all
<directhex> PeskyJ, i think, in essence, in qt you can just do stuff - in gtk, some stuff can only be done in the main application thread, so you need to use your language's method for doing so
<directhex> PeskyJ, try changing a window label outside the main thread in gtk, and the window will just go screwy
<PeskyJ> directhex: I see - I'd likely only have one GUI thread and other threads to do app-specific stuff, though it might be convenient for some stuff as you say to just go ahead and change something without having to post a message about it
<PeskyJ> directhex: tbh, I've not done much window-environment programming, mostly games where you render your own GUI
<PeskyJ> so a GTK app can run on KDE and Gnome, and Windows, right?
<PeskyJ> how about IRIX (is that even still around)?
<NCommander> PeskyJ, Probably.
<NCommander> lamont, morning
<lamont> g'morning
<NCommander> how goes it lamont
<directhex> PeskyJ, irix is dead, but old installations may persist
<PeskyJ> directhex: so what other window environments are there these days?
<directhex> PeskyJ, irix isn't a window environment, it's an os. which are you asking about?
<PeskyJ> directhex: oh.. well the 4DWM that came on IRIX was pretty cool... I'm just wondering what other window environments there are in use these days, other than KDE, Gnome, Windows?
<directhex> xfce, openbox... e17? and minimal things like awesomewm
<NCommander> infinity, hey, are you floating around?
<PeskyJ> and does both Qt and GTK work on those too?
<directhex> bien sur.
<hyperair> PeskyJ: as long as you've got the dependencies, gtk/qt stuff will work on anything. heck, even gnome and KDE specific applications will work. just that kde specific applications start a whole string of unwanted daemons with them if you're not already on kDE
<hyperair> *KDE
<pitti> bryce, tjaalton: a dist-upgrade to jaunty caused X to fail because it couldn't load libdrm_intel.so. Shouldn't -intel Depends: libdrm-intel1?
<tjaalton> pitti: -intel should pick the dependency when building against the new libdrm, but doesn't for some reason I've yet to find out
<kees> so we haven't hit DIF, but I see a gap between unstable and jaunty at the moment -- is there a giant backlog still?
<kees> better question, where can I see the Ubuntu Archive Auto-Synce queue?
 * kees assumes https://edge.launchpad.net/~katie/+uploaded-packages
<kees> which means UAAS hasn't run for 4 days?
<NCommander> hey kees
<kees> heya NCommander
<NCommander> kees, how goes it?
<kees> NCommander: goes busy and well :)
<sebner> kees: well 20 days until DIF, maybe nobody had time because of the UDS
<fta> doko, gcc seg fault: http://launchpadlibrarian.net/20235151/buildlog_ubuntu-jaunty-sparc.xulrunner-1.9.1_1.9.1~b2%2Bbuild1%2Bnobinonly-0ubuntu3_FAILEDTOBUILD.txt.gz
<calc> directhex: ah he finally released 3.0.0-6? :)
<calc> directhex: i'll be uploading an ubuntu version asap in that case, at FOSSCamp right now
<directhex> calc, aye
<directhex> calc, okay, cool, was just keeping you updated
<calc> it will take a little while to get built since i have to get everything pulled in from universe, heh
<directhex> dude, it's OOo. it'll take 8-10 hours to build Lpo
<directhex> :p
<directhex> gah, can't type today
 * StevenK kicks libkdcraw in the -dev
<StevenK> E: Package libkdcraw-dev has no installation candidate
<StevenK> Grah
<calc> directhex: a little while as in several days due to ~ 20 MIRs ;-)
 * directhex whistles innocently
 * calc bbl
<slangasek> directhex: so I guess kdebindings-kde4 needs some kind of migration off of libkimono4.1-cil, do you know if anyone's working on that?
<directhex> slangasek, to the best of my knowledge, nobody's working on it - but if my memory serves me correctly, those libs are already built against CLI 2.0 - so only minor build-dep & rules tweaks should be needed
<directhex> depends on libmono-corlib2.0-cil, so yes, just a little bit of tweaking required
<directhex> slangasek, is that a request, then?
<slangasek> directhex: a subtle hint :)
<slangasek> directhex: you mention only libmono-corlib2.0-cil, though - I'm looking at the NBS list, which shows it depends on the no-longer-extant libkimono4.1-cil?
<directhex> slangasek, still exists - disabled in debian/control due to, well, lack of buildability right now
<slangasek> hrm
<slangasek> k, ignoring that one for now then
<directhex> slangasek, with autofoo, you can override an AC_PROG_PATH by specifying it on the configure line (e.g. ./configure FOO=/usr/bin/bar). do you know if the same or similar can be done with cmake?
<slangasek> my working assumption is that it's impossible to do anything useful with cmake
<directhex> :)
<StevenK> Blah. libkdcraw7-dev does not Provide libkdcraw-dev
<StevenK> NCommander: Why did libkdcraw-dev get renamed to libkdcraw7-dev?
<StevenK> NCommander: And all the other -dev's that kdegraphics build?
<StevenK> Ah ha. Debian did it.
<StevenK> Well, that sucks
<tmccrary> Where can I located the busybox configuration for ubuntu's initrd that comes with kernels?
<tmccrary> is there a source package for ubuntu's initrd?
<tmccrary> does it come in the kernel sources?
<TheMuso> tmccrary: The initrd is made up of files from several packages. The initramfs-tools package is the one responsible for putting it all together.
<TheMuso> tmccrary: You want to look at /usr/share/initramfs-tools for the scripts used to put the initrd together.
<tmccrary> TheMuso: awesome thank you
<directhex> so many build deps..... why does kde4bindings build-dep on so many -dbg packages? o_O
<tmccrary> I need to build the brctl applet into busybox
<tmccrary> I didn't want to go though the entire busybox config ;)
<TheMuso> tmccrary: Your best option is to probably extend the brctl package to add files to the initrd, and run it in the initrd.
<tmccrary> does busybox's brctl not work adequately?
<directhex> apachelogger, ping
<fabbione> who is in charge of the installer these days?
<TheMuso> tmccrary: I don't know, I didn't even know busybox had brctl.
<tmccrary> Well, it has an option in make menuconfig
<tmccrary> ;)
<tmccrary> brctl looks statically linked and is pretty small when built
<tmccrary> so that's not a bad way to go
<directhex> bah
<kirkland> pitti: hey, can we take a quick look at that adduser --encrypt-home patch at some point today :-)
<TheMuso> kirkland: let me know if there is a time today when there are no session s you are interested in, and perhaps we can sit down and have a look at the mdadm merge.
<kirkland> TheMuso: sounds good, perhaps after a quick bite to eat for lunch?
<TheMuso> kirkland: Sounds good to me.
<bryce> pitti: I've added a Depends on -intel for that as a workaround, until the libdrm symbols stuff gets sorted out
<directhex> sigh. kde4bindings fails to build - near the end, in cpp code (ie.. not my fault)
<ScottK> directhex: Feel free to join us in #kubuntu-devel to discuss
<ion_> When will Keybuk return, btw?
<pochu> kees, jdstrand: hi. there is a security update for vinagre upstream, which fixes a printf without format. Should that go through -security or -updates? The patch is this: http://svn.gnome.org/viewvc/vinagre/branches/gnome-2-22/src/vinagre-utils.c?view=patch&r1=528&r2=527&pathrev=528
<pochu> kees, jdstrand: affected releases are hardy, intrepid and jaunty
<nxvl> pochu: there is a bug in launchpad already?
<jdstrand> pochu: also, is there a CVE?
<pochu> nxvl: nope, not yet
<pochu> jdstrand: I don't think so, I've googled for it without luck
<pochu> jdstrand: and upstream doesn't mention it in the changelog or NEWS file
<pochu> see http://svn.gnome.org/viewvc/vinagre?view=revision&revision=529
<pochu> http://svn.gnome.org/viewvc/vinagre/branches/gnome-2-22/ChangeLog?r1=529&r2=528&pathrev=529
<nxvl> pochu: then report it
<kees> pochu: do you have a reproducer for it?
<nxvl> :S
<jdstrand> pochu: is that message user-controllable?
<jdstrand> s/user/remotely/
<pochu> not sure, let me check
<jdstrand> pochu: the changelog would suggest as much
<jdstrand> pochu: if it is indeed a security issue, then it should go through -security
<jdstrand> pochu: I've made a note to look into it-- if you find a reproducer/PoC, that would be great
<kees> and if there's a reproducer, I'd like to try it on intrepid, as I suspect it'll get caught by FORTIFY
<jdstrand> there is a version of vinagre in hardy that'll need to be checked
<pochu> looks like it's not remotely controllable
<pochu> it could be controlled through translations though
<pochu> the bug is on the vinagre_utils_show_error function, which is used 11 times in the source (in the hardy version), and looks like in all of them the string is hardcoded in the source
<pochu> except that in some cases it is translated
<pochu> so a malicious translator could control it... not sure if that's a reasonable situation :)
<jdstrand> pochu: is it pretty much the same on intrepid?
<pochu> BTW I'm no security expert, so would be fine if you could check it too just in case I overlook anything
 * jdstrand nods
<jdstrand> (not at the non-expert part-- at the me checking part :)
<kees> jdstrand: I'll looking through it now, so far so good
<jdstrand> kees: ah, well, if you're looking at it, I'll take it off my TODO list :P
<pochu> looks more or less the same in Intrepid
<pochu> it's used some more, but looks like the messages are all hardcoded in the code
<pochu> if it's hardcoded, then it's no security issue, right?
<pochu> jdstrand, kees: thanks :)
<kees> hrm, it's used on filename errors...
<kees> in vinagre_cmd_machine_open
<kees> vinagre %x
<kees> so, yeah, it's user-assisted, but still an issue
<kees> an on intrepid...
<kees> $ vinagre %n
<kees> *** %n in writable segment detected ***
<kees> heheh
<kees> pochu: so yeah, if you can, can you open a bug report for it an mark it a public security issue along with the links you gave above?
<pochu> kees: sure
<pochu> kees: so this affects intrepid only, or both intrepid and hardy?
<kees> pochu: thx! and thanks for noticing it in the upstream commits.  :)
<kees> looks like hardy through jaunty
<pochu> ah yeah, due to vinagre_utils_show_many_errors right?
 * kees nods
<pochu> ok
 * pochu reports a bug
<pochu> kees, jdstrand, nxvl: reported as bug 305623
<jdstrand> pochu: thanks :)
<pochu> I can prepare debdiffs, but I have never done them before for the -security pocket :)
<mneptok> hrmf.
 * mneptok goes in search of ubottu
<jdstrand> pochu: just follow https://wiki.ubuntu.com/SecurityUpdateProcedures
<nxvl> which package is it again? vinagre, right?
<pochu> nxvl: yup
<pochu> jdstrand: ok, thanks
<nxvl> is it private?
<pochu> nope
<pochu> https://bugs.edge.launchpad.net/ubuntu/+source/vinagre/+bug/305623
<pochu> jdstrand: can you approve the hardy and intrepid tasks?
<kees> pochu: cool, thanks
<pochu> you're welcome :)
<kees> pochu: I'll approve them, one sec
<calc> jcastro: ping
<pochu> kees: what do you mean with segv on hardy? sigsegv?
<pochu> it doesn't crash here on a hardy VM if I launch vinagre as "vinagre %n"
<pochu> it just doesn't display the %n in the error dialog, but with the patched vinagre it does
<pochu> is that alright?
<kees> pochu: yeah, that's fine.  the sigsegv will show up if you add enough %n's.  :)  %n%n%n%n%n%n%n eventually it'll hit bad memory
<pochu> ah, got it now :)
<kees> :)
<mathiaz> evand: http://ubuntumathiaz.wordpress.com/2008/09/18/automate-ubuntu-server-iso-testing/
<pochu> kees: hardy debdiff submitted
<kees> pochu: great, thanks!
#ubuntu-devel 2008-12-06
<pochu> kees: woops, I forgot the changelog "SECURITY UPDATE" magic
<pitti> kirkland: retroactively done :)
<pitti> bryce: saw it, thanks a lot
<pitti> bryce: in other news, are you already aware of the "X doesn't lock Alt+Fn for VT switching any more" bug, or shall I file one?
<kirkland> pitti: sorry, please clarify...  are you waiting on me to fix that detect-if-eryptfs-installed error?
<kirkland> pitti: or did you do that yourself?
<bryce> pitti: file please
<bryce> pitti: but mostly just been looking at X crash bug reports of late
<pitti> bryce: alright, will do
<pitti> kirkland: I was actually waiting for you
<pitti> kirkland: you can probably test it quicker than me
<bryce> pitti: btw at UDS I'd like to sit down with you and maybe jesse or alex and try to sort out getting the x signal handling stuff working
<pitti> bryce: oh yes, that would be nice
<pitti> bryce: done in bug 305641
<ubottu> Launchpad bug 305641 in xorg-server "[jaunty] Does not lock Alt+Fn, now switches VT" [Undecided,New] https://launchpad.net/bugs/305641
<directhex> dum de dum, /me waits for test build
<mathiaz> cr3: https://wiki.ubuntu.com/Testing/Cases/ServerInstall
<pochu> kees: jwendell (upstream for vinagre) has just told me there's a CVE for the vulnerability, but it's not public yet: it will be made public this Tuesday
<Caesar> Where can I find pre-Dapper versions of Ubuntu?
<pochu> kees: I've added a debdiff for Intrepid, btw. I'll look at Jaunty tomorrow
<Caesar> I'm trying to track down a regression in the alternate installer
<directhex> Caesar, there's a domain... oldreleases.ubuntu.com or similar
<directhex> http://old-releases.ubuntu.com/releases/
<Caesar> directhex: terrific, thanks
<Caesar> Damn, no APT repo, just ISOs?
<pochu> that's what (old-)releases.ubuntu.com is for, yes
<kees> pochu: weird, they got a private CVE, but committed the fix in a public repo?
<pochu> kees: looks like, yes
<kees> okay, well, ask them if they want us to make the bug private and wait until Tuesday to release?
<ScottK-laptop> If the code is already pubilshed ...
<Caesar> pochu: but where do I get the source from for these old releases?
<Caesar> nm, I see it
<Caesar> Lucky I have a fat pipe
<Caesar> Is the alternate installer in bzr or svn somewhere?
<directhex> d-i?
<Caesar> Yes
<Caesar> But the Ubuntu modifications made
<Caesar> Found it
<kees> (sorry, I didn't name hilight you earlier) pochu: can you ask them if they want us to make the bug private and wait until Tuesday to release?
<pochu> kees: sure
<kees> pochu: thx :)
<pochu> np ;)
<pochu> kees: he tells me we don't need to, as the bug fix is already on the public svn repo
<kees> pochu: cool, in that case, can you get the CVE from him and add it to the bug?  :)
<pochu> kees: as in, it would be pointless as we wouldn't be hidding the important bits
<mathiaz> cr3: http://paste.ubuntu.com/81125/
<pochu> kees: he doesn't know if he's allowed to tell me the #id
<kees> hah okay, nm, we'll attach it after Tuesday
<kees> pochu: ^^
<pochu> kees: it's his first CVE -> he's a good maintainer who doesn't make lots of security bugs ;)
<pochu> kees: ok, I'll keep an eye on it
 * kees nods
<cr3> mathiaz: w3m http://127.0.0.1/
<pochu> kees: thanks again for your guidance :)
<pochu> good night all
<kees> g'night pochu :) np
<YokoZar> Just to let everyone know, you will probably get a nasty cold at UDS if you haven't had one already :)
<YokoZar> It's "going around"
<calc> YokoZar: yea i think i have it now, i thought it was some weird hangover effect from last night
 * desrt seeks seb
<calc> desrt: seb is in the hotel lobby i think
<calc> desrt: well seb128 anyway
<tonyyarusso> Hey, if pitti, Keybuk, or evand are around, I was just curious what came out of https://blueprints.edge.launchpad.net/ubuntu/+spec/encrypted-filesystems, as it's still marked as "Not started", but I thought maybe at least some of it had been done...
<calc> tonyyarusso: there has been some discussion of it at FOSSCamp i think, not sure what the status is though
<calc> tonyyarusso: well i think it was about that, looking at the blueprint now
<calc> tonyyarusso: oh hmm i'm not sure if it is the same thing i heard about today
<calc> it doesn't appear to be targeted for jaunty though
<tonyyarusso> Specifically, it would rock if Bug #139057:
<tonyyarusso> This report is public
<ubottu> Launchpad bug 139057 in cryptsetup "Should try given password for next partition" [Undecided,Confirmed] https://launchpad.net/bugs/139057
<tonyyarusso> and Bug #155987 were / have been addressed
<ubottu> Launchpad bug 155987 in partman-crypto "Installer doesn't support mounting existing encryption volumes" [Undecided,New] https://launchpad.net/bugs/155987
<chris062689> What is most of the GNOME Suite / Programs (Transmission, Games, Movie Player) written in?  Python or C?
<Keybuk> C
<wgrant> And they seem to have afinity to JavaScript.
<chris062689> Where the heck did I see they were written in python...
<wgrant> We like Python here. GNOME doesn't.
<chris062689> Ah
<chris062689> I just wish GNOME seemed.. more advanced.  Many options are hidden from us..
<chris062689> I don't like running an IdiotOS :P
<chris062689> *Idiot-proof OS
<walters> no; python is fine available platform for writing applications, and there are quite a number of them
<chris062689> So if I wrote something in python, it would have a lesser chance to make it upstream than a C package?
<walters> upstream in what?
<chris062689> I want to begin developing programs to help Ubuntu / GNOME in general, I just don't know if I should wait until after "GNOME 3.0" when everything will supposedly be cleaned up and rewritten for efficiency (right?)
<walters> we're not rewriting much
<walters> no no need to wait to do anything =)  just write your app
<chris062689> I'm not really talking about Ubuntu-itself rewriting these things
<chris062689> The GNOME project; GNOME 3.0, is esentially what KDE 4 was for KDE, cleaning up code, making it cleaner, more efficient, right?
<walters> that's been an ongoing process for as long as GNOME has existed
<walters> what we hope to do for 3.0 is improve the user experience
<chris062689> Well, from what I've seen / heard (which is probably FUD) that GNOME (GTK) is rather... messy to write with
<chris062689> true statement?  :O
<walters> there's a learning curve for the core platform for sure, and we do want to improve that; there are a lot of aspects to that
<chris062689> Well yeah, learning curve of course, but I'm talking about more cleanability / "easy on the eyes" code.
<walters> anyways i wouldn't get caught up in the meta questions - if you have a dream just go for it, dive in
<chris062689> Do you happen to have any Tutorials for C and GNOME?
<chris062689> I'd rather write my GNOME apps in C (just simply because it's more "accepted" in GNOME territory lol)
<walters> i would start out with pygtk
<cliffbreaker> hi everyone. Try to build a package from source and it gives an error (when using debuild -S -sa) -  make: *** No rule to make target `clean'. Stop. How can I fix it?
<azeem> cliffbreaker: that question is more on topic in #ubuntu-motu
<cliffbreaker> azeem: ok, I'm sorry, just didn't know where to go to
<sidd> hi, does any one know why fiesty is not a part of http://archive.ubuntu.com/ubuntu/dists/ ?
<wgrant> sidd: Feisty is obsolete.
<directhex> sidd, because feisty is EOL?
<Hobbsee> sidd: because it's unsupported?
<directhex> try old-releases.ubuntu.com
<sidd> okay, wgrant, directhex, hobbsee, i had a single dvd for ubuntu, my first :) and now i want to upgrade to gutsy. voila, it fails because fiesty is not there :)
<sidd> directhex: thanks. that works.
<directhex> upgrade to gutsy? that's a long term goal if ever i saw one ._.
<yao_ziyuan> ubunbu better rename its default theme as "Outdoors Laptop Use" and its "DarkRoom" as "Indoors"
<yao_ziyuan> and i strongly recommend Murrine + X-Colors as the default theme.
<yao_ziyuan> fedora already takes nodoka, aurora has problems with firefox, and murrine is the best left
<yao_ziyuan> my murrine desktop: http://i33.tinypic.com/2cbuhg.png
<yao_ziyuan> my murrine apps: http://i38.tinypic.com/rkpzy9.png
 * Hobbsee waves to sivang
<sivang> hey Hobbsee !
<Hobbsee> how goes it?
<sivang> Hobbsee: it'll be good eventually :)
<Hobbsee> :)
<ryanhaigh> hi all, i have a problem with hardy that is fixed in the intrepid kernel. i have asked on the normal support channel and i have been told to install linux backports modules hardy but before i go trying to do that i would like to understand what this package actually is because the kernel version they apply to is 2.6.24, I checked the description but it isn't very complete, is there somewhere else i can look?
<pochu> kees: just added the vinagre update for jaunty, will you be able to upload it, or shall I look for an sponsor?
<pitti> tonyyarusso: it's kind of obsoleted by ecryptfs; kirkland is doing an awesome job of integrating this very nicely into jaunty
<calc> pitti: ping
 * StevenK prods calc in the back, just because he can.
<calc> does apt-get in jaunty auto install recommends?
<dholbach> calc: yes, it did in intrepid already
<calc> i'm noticing some packages are getting installed for OOo build-dep that probably don't need to be
<calc> dholbach: how do i disable that for a particular apt-get run?
<dholbach> apt-get --no-install-recommends <bla>
<dholbach> man apt-get :)
<calc> thanks :)
 * calc ran apt-get -h but apparently its not good enough, heh
 * StevenK waits for locale-gen on armel
<calc> pitti: is there a template MIR bug report that I could use?
<calc> reduced the list to 17 source packages :)
<calc> pitti: ah i found the wiki page about it :)
<kirkland> evand: http://pastebin.ubuntu.com/81501/
<calc> pitti: here?
<calc> StevenK: so should i just file the ubuntu-mir bug against OOo then?
<StevenK> calc: Personally, I would find pitti in person, and have a 5 minute conversation. :-)
<calc> StevenK: yea sounds good
<amikrop> In what file are there the configuration rules for apt-get bash autocompletion?
<RainCT> Ampelbein: /etc/bash_completion
<RainCT> err sorry, that was for amikrop
<nxvl> ogra: can you add a copyright and versioning (in a readme file or something) to usb-creator?
<ogra> usb-imagewriter you mean :)
<nxvl> right
<pwnguin> anyone know if evolution-mapi has a package yet?
<ogra> i'll add a script to dump the bzr changelog into a file
<nxvl> that works
<nxvl> i've versioned it as 0.1
<nxvl> but i need a copyright
<nxvl> a license actually
<ogra> there is a sourcepackage in my PPA
 * sebner asks himself if he should write nxvl an email :P
<ogra> that should have a copyright
<nxvl> got it
<ogra> sebner: it's the communication system of the future
<ogra> :p
<sebner> ogra: hahaha :P
<nxvl> sebner: e-mail works better usually
<nxvl> sebner: but take the same time :D
<sebner> nxvl: but messages on IRC are easier to ignore/forget than mails :P
<nxvl> sebner: yup
<nxvl> sebner: that's why i said that works better
<sebner> nxvl: And if that doesn't help there is something like "mailbombs" :P
<nxvl> yeah, that will make you win a filter
<nxvl> :D
<sebner> heh
<kees> pochu: sure, one sec
<kees> pochu: actually, since 2.24.2-1 is in Debian, is there a reason we don't just merge from Debian (instead of uploading a -0ubuntu1 version?)
<pochu> kees: that it's been uploaded a few minutes ago :)
<pochu> kees: I'll merge it
<kees> pochu: sure, but I mean it seems like less work that way.  :)
<kees> pochu: also, I noticed you dropped lool from the Uploaders in both intrepid and jaunty (not that it matters for Ubuntu)
<seb128> kees: the uploaders list is dynamically built using the recent changelog entries
<kees> oh! hah.
<kirkland> evand: so we'd need to add ecryptfs.ko kernel module to the installer kernel modules
<kirkland> evand: i added a linux task to bug #302870
<ubottu> Launchpad bug 302870 in user-setup "add support for setting up encrypted home directory on user creation" [High,In progress] https://launchpad.net/bugs/302870
<kirkland> evand: i manually copied the .ko file into the installing system, insmod'd it
<kirkland> evand: but i can't get the mount established in the installer
<kirkland> "Unable to get the version number of the kernel module....."
<evand> kirkland: not sure
<pochu> kees: thanks for the uploads :)
 * pochu prepares the jaunty one
<pochu> kees: I don't need to mention "SECURITY UPDATE", nor do I need to upload to jaunty-security for the jaunty one, right?
<kees> pochu: nah, it's a new upstream version.  normally, if the CVE# was known, it's nice to add that to the changelog, like a bug#.
<pochu> ok
<pochu> I'll have to wait until it appears on the pool, as it's now gone from incoming :)
<pochu> kees: merge done, debdiff attached to the bug report
<StevenK> pitti: Remember that schroot failureness on armel? It ICE's with -O1 too
<glick> excuse me, for kernel dev on ubuntu what do i need to install?
<Syke1> glick: take a look at https://help.ubuntu.com/community/Kernel/Compile
<Chipzz> glick: ot here; please read the topic
<TheMuso> Yay for a tarball in tarball package with a watch file, which seems useless, since afaik uscan cannot re-create the tarball in tarball setup.
#ubuntu-devel 2008-12-07
<TheMuso> When one wants to close more than one LP bug at once, is only a comma and the next LP bug number sufficient?
<StevenK> TheMuso: From what I recall (LP: #xxxxx, #yyyy) works
<TheMuso> StevenK: Yeah, just confirmed it by checking the resulting changes file, thanks.
<TheMuso> c
<tonyyarusso> pitti: Excellent.
<ScottK-laptop> Anyone around with hardware, inclination, etc, to do an armel test build for me?
<glick> excuse me reading the community Kernel/Compile page and it says i have to do sudo apt-get install linux-kernel-devel among other things, but apt says that there is no such package
<jdong> who's our selinux people? There's so much conflicting info on how to enable SELinux in Ubuntu
<ScottK> jdong: Join #ubuntu-hardened and I'll point you at them.
<soc> hi
<ScottK> Hello soc.
<soc> do i need the mount option "journal_async_commit" when mounting ext4 in jaunty
<soc> or is this already enabled by default?
<bluefoxicy> Question
<bluefoxicy> in Top, what's state D again?
<bluefoxicy> Non-escapable kernel call or something?
<bluefoxicy> Pidgin just froze stuck in state D, and when I killed itand brought it back up it went back to it immediately.
<jdong> bluefoxicy: uninterruptable
<bluefoxicy> ok it's working again
<bluefoxicy> but that's really strange
<jdong> but yeah  you have the right idea; most of the times that state is when it gets stuck on a syscall
<jdong> i.e. disk IO, etc
<jdong> *cough* Pulse/Alsa *cough*
<bluefoxicy> hmm :|
<bluefoxicy> well I didn't strace it and it's working now
<bluefoxicy> If I catch something later I'll file it
<thinkgnu> is there any difference to compile a project and make a package for ubuntu 8.4 or 8.10 while using the same compiler ?
<det> Are there any kind of estimates on how popcon installs figures relate to actual installs?
<RainCT> det: there are 800.000 submissions, so if we guess a user base of like 10 millions it would be around an 5-10%
<det> So, you are saying multiply the number of installs in popcon statistics by 10-20 to get the real number ?
<det> (estimated)
<RainCT> det: Yes. I'm not sure how accurate the 10 millions are, though
<det> Thanks.
<det> I wonder how popcon determines if someone uses a program "regularly".
<det> I'll check the FAQ
<RainCT> iirc it checks if it was executed within the last <insert timeframe>.
<RainCT> Â«A computer 'vote' for a package if according to the data provided in the report, a program provided or depending on the package was used less than thirty days ago. This computation is performed by the popcon server.
<RainCT> Â»
<RainCT> (http://popcon.debian.org/FAQ)
<ion_> Heh. Thereâs a b-boy team called Ubuntu in the documentary Planet B-Boy. :-)
<siekacz> hi
<siekacz> I can't find displayconfig-gtk
<tombee> Is there any recommendations for an IDE when it comes to development within Ubuntu?
<tombee> I've had a look at Anjuta and Eclipse, certain things I like about each of them.
<Company> tombee: there's also kdevelop
<Company> tombee: but most of the ubuntu developers use pure text editors like vim and terminals
<siekacz> is there any replacement for displayconfig-gtk?
<RainCT> siekacz: gnome-display-properties
<RainCT> siekacz: displayconfig-gtk has been obsoleted by changes in X.org
<siekacz> i need to reconfigure my monitor
<siekacz> nly 800x600 is available
<siekacz> xfix doesn't work
<siekacz> editing xorg is the only way?
<RainCT> siekacz: better ask in #ubuntu
<siekacz> RainCT, i know, but i'm banned, don't know why?
<RainCT> siekacz: ask in #ubuntu-ops
<LordMetroid> What do a distro developer do? The kernel and all software is already coded, right?
<RainCT> LordMetroid: package software, write/apply patches when necessary, etc.
<LordMetroid> ok
<Company> LordMetroid: from my point of view, a distro developer a) is a link between his users and the kernel etc developers and b) works on integrating the kernel and all other things so they work fine together
<Company> (but i'm not a distro developer, but a gnome developer)
<LordMetroid> Ohh, I see...
<ebroder> How do I figure out why a package wasn't imported from Debian?
<nhandler> ebroder: What is the package?
<ebroder> The shibboleth-sp2 shource package
<nhandler> It looks like Debian has 2.0.dfsg1-4 as well as jaunty
<ebroder> Oh, hmm. packages.ubuntu.com didn't list it
<sebner> ebroder: it's often outdated
 * ebroder nods
<ebroder> Is there somewhere else I can look for a more updated list? Other than running jaunty
<sebner> ebroder: https://edge.launchpad.net/ubuntu/jaunty/+search?text=
<ebroder> That doesn't find it
<jdong> /usr/bin/madison
<jdong> https://edge.launchpad.net/ubuntu/+source/shibboleth-sp2
<jdong> found it just fine for me.
<nhandler> rmadison should also work
<ebroder> Looks like it FTBFS
<jdong> oh that's a nasty error :)
<ebroder> Yeah...
<glick> excuse me, im trying to build my current kernel.  i got the sources using apt-get. and i installed all the packages from the community doc Kernel/Compile how ever when i try to build it I get this error.../usr/bin/fakeroot: line 164: debian/rules: No such file or directory
<glick> it looks like the kernel debian subfolder is empty
<glick> is there an ubuntu kernel channel?
<RainCT> glick: Sure, #ubuntu-kernel
<glick> cool
<glick> thanks
<glick> hey does anyone know why my kernel debian subfolder is empty?
<glick> when i download the the kernel sources
<ebroder> Did you just download the .tar.gz file? Or did you get the .diff.gz as well?
<glick> so when i try to run debian/rules i get a file not found
<glick> i got the diff file as well
<ebroder> And the diff was applied?
<glick> no
<ebroder> Well...then that's your problem :)
<glick> thast not in the documentation
<ebroder> What documentation did you read?
<glick> https://help.ubuntu.com/community/Kernel/Compile
<ebroder> Did you do apt-get source linux-something?
<ebroder> (That should apply the diff)
<glick> i did apt-get linux-sources
<ebroder> Huh?
<glick> i also did apt-get build-dep linux-source
<glick> which is an error
<ebroder> Running "apt-get linux-sources" wouldn't do anything
<ebroder> Because that's not an apt-get command
<ebroder> Uh...let's backtrack for a moment. What version of Ubuntu are you using?
<jdong> apt-get source linux?
<glick> ibex
<ebroder> jdong: That gives you linux-meta, I think
<jdong> the linux-source-`uname -r` distribution does *NOT* include debian/
<TheMuso> apt-get source linux=version is what works, at least for me.
<jdong> ebroder: no, That's linux-meta :)
<jdong> https://edge.launchpad.net/ubuntu/+source/linux
<jdong> linux is the main Linux source package since hardy.
<glick> whats linux meta?
<ebroder> On Hardy, `apt-get source linux` gives me the source for linux-meta
<jdong> that's the one you want if you want debian/ too
<glick> first, the docs say i need a package called linux-kernel-devel
<glick> when i try to get that it says there is no such package
<jdong> ebroder: ack that's because apt-get source picks *binary* package names first :(
<jdong> stupid thing.
<jdong> grab the version you want from https://edge.launchpad.net/ubuntu/+source/linux then
<jdong> linux-meta generates a binary package called linux
<jdong> now who's idea was that :)
<ebroder> jdong: I know - I'm just saying that `apt-get source linux` won't DWYW
<pitti> calc: MIR> ah, good; yes, it's MainInclusionReportTemplate
<glick> so what do i need to get to compile the kernel?
 * TheMuso is finding himself not entirely surprised that a lot of people are online this morning.
<ebroder> glick: Start with `apt-get build-dep linux-image-$(uname -r)`
<StevenK> TheMuso: Oh?
<jdong> that works too.
<TheMuso> StevenK: I thought that a lot of people would be heading out to do things.
<TheMuso> c
<glick> ok thats done ebroder
<ebroder> Ok. Then I think you want to do `apt-get source linux-image-$(uname -r)`
<ebroder> That'll download the source package for the kernel you're running
<glick> ok
<glick> i got a .dsc file a deff file and a tar file
<ebroder> Yeah, it should unpack everything, too
<glick> into my current folder?
<ebroder> It should make a folder called linux-2.6.27
<ebroder> ...do you have build-essential installed?
<glick> yes ebroder
<ebroder> glick: ok, just checking. So is there a linux-2.6.27 folder?
<glick> yes ebroder
<ebroder> glick: So are you just trying to rebuild the kernel you're running? Or are you trying to do something to it?
<glick> ebroder, im trying to get a built tree so i can do some module devel
<ebroder> glick: Ah, ok. Then just run `AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-FLAVOR`, where flavor is something like generic or server
<glick> ebroder, dont i have to do something with a config file?
<ebroder> Not if you're not changing the config
<glick> sweet
<glick> lemme give it a shot
<jdong> wait why do  you need a built tree to do module development?
<glick> thats what my driver book says :)
<TheMuso> c
 * jdong whispers apt-get install linux-headers-generic
<TheMuso> gah typing
<NCommander> hey TheMuso
<TheMuso> Yo NCommander. Where are you at present?
<glick> jdong, i thought the latest modules link to object files in the kernel tree
<glick> thats why you need a pre-built kernel tree
<NCommander> TheMuso, trapped in the Rochester deepfreeze
<glick> thanks ebroder its workin :)
<NCommander> and praying I can make my connector in Washington DC
<NCommander> If I don't make the connection
<TheMuso> NCommander: Fun.
<NCommander> I won't get to SF until Tuesday likely
<TheMuso> On that really sucks. When were you supposed to get here?
<jdong> glick: no, the headers in linux-headers-generic are all that's necessary to build kernel modules
<jdong> you don't need a fully built kernel tree
<jdong> just like how with a kernel tree you only need "make modules_prepare"
<NCommander> TheMuso, tonight, 8PM PST
<glick> hmm
<TheMuso> NCommander: Oh that really sucks.
<TheMuso> NCommander: You let anybody at SF know this?
 * NCommander makes it personal policy not to fly if at all possible
<NCommander> TheMuso, not yet, the flight is delayed, but not outright canceled (yet)
<TheMuso> NCommander: Right.
<NCommander> If it leaves at the current delayed time
<NCommander> I'll JUST make the connection
<TheMuso> NCommander: Well good luck, I hope you can get here today.
<NCommander> Yeah
 * NCommander is cleanly shaved, and has short hair again
<NCommander> I've been going all around the ****ing country running errands and dealing with stuff that I just finally got around to doing things like getting my jacket pressed yesterday
<jdong> too much information.
<jdong> *ducks*
 * NCommander kills jdong 
<jdong> lol
 * NCommander throws jdong into the Rochester deep-freeze
<sebner> !ohmy NCommander :P
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<sebner> !ohmy! NCommander :P
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<sebner> -.-
<NCommander> ahahah
<NCommander> sebner, I'm censored
<sebner> !ohmy | NCommander :P
<ubottu> NCommander :P: Please watch your language and topic to help keep this channel family friendly.
<NCommander> No need to ohmy me
<sebner> haha!
<jdong> so is shaved or unshaved the new fad? :)
<jdong> wow we've derailed this channel
<NCommander> You'll see when I get to UDS
<sebner> too much information for sebner :P
<NCommander> jdong, it's a talent
<jdong> sigh they change this stuff too often :)
<jdong> there's no lvcreate -s for shaving, is there....
 * NCommander torrents remixs from oc remix
<NCommander> By time I make it to the west coast, my music collection should be fully restored
<NCommander> Wow, impressive, I'm being throttled all the way down to 10kb/s
<sigp226> How do I setup a drag and drop encrypted folder?
 * calc is in pleasanton, ca for the day
<Keybuk> https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/105234/comments/113
<ubottu> Launchpad bug 105234 in network-manager "Network manager says disconnected but is connected and working" [Critical,Fix released]
<pitti> Keybuk: headhunters must really be desperate...
 * pitti finishes wrestling with ekiga and flushing the SRU queue, and wonders if anyone is up for a walk for an hour or two?
<Spads> Keybuk: you should make a linkedin account for that bug and then try to link up with all the networkmanager developers
<NCommander> hey TheMuso
<TheMuso> NCommander: hey again.
<NCommander> TheMuso, now communicating from Washington DC
<TheMuso> NCommander: Is that a good thing?
<NCommander> One connection down
<jdong> TERRORIST!
<NCommander> I'm sitting next to the fight to San Franscisco
<jdong> HE IS IN IRC AT AN AIRPORT
<NCommander> I'm using IRC over a wireless modem at an airport at the nations capital
<NCommander> The FCC should be descending from avoid and shooting my laptop any moment
<TheMuso> lol
 * NCommander wonders if gmail will load anytime soon
<ScottK-laptop> NCommander: Where airport?
<ScottK-laptop> Where/Which
<NCommander> ScottK-laptop, Washington DC/Dulles
<ScottK-laptop> NCommander: You're about an hour drive from my house then.
<ScottK-laptop> Well, between one hour and two days depending on the traffic.
<RainCT> lol
<NCommander> rofl
<NCommander> ScottK-laptop, If you want to meet in real life, lets do it after I return from UDS, Maryland is only a three-four hour drive, and I don't mind doing it
<ScottK-laptop> Sure thing.
<NCommander> It's nice tobe out the deep freeze
<NCommander> My laptop actually running above 70F since I'm someplace with heat :-)
<ScottK-laptop> NCommander: I thought you were in NY somewhere?
<ScottK-laptop> Normally, I mean.
<NCommander> Rochester, NY
<NCommander> But I have family in NYC
<NCommander> And I don't have a huge problem driving across this country
<NCommander> :-)
<ScottK-laptop> I think that's more than 3-4 hours, but ...
<NCommander> from NYC?
<NCommander> (from Rochester, its more in the ballpark of seven or eight)
 * NCommander books the supershuttle from SFO to the hotel
<ScottK-laptop> Maybe 4 from NYC, depending on where.
<Treenaks> so.. is there a special uds channel yet?
<j1mc> Treenaks: #ubuntu-devel-summit
<test34> kernel Ubuntu-2.7.27-4.7 in ubuntu's git ? a mistake  or is a beta ?
<jdong> sounds like a typo to me?
<test34> ok
<test34> I experience a kernel bug with the latest one then: Ubuntu-2.6.27-9.19
<test34> but it doesn't happen with kernel v2.6.27.8
<test34> sorry that doesnt belong here
<RAOF> tjaalton: I've stumbled across your xorg-jaunty blueprint, with the 'status of nouveau' question.  Nouveau is now buildable and useable on Jaunty's standard libdrm, and I've got a dkms'd build of the kernel modules in my PPA.
<directhex> RAOF, is it generally usable, though?
<RAOF> directhex: Absolutely.
<RAOF> directhex: Moreso than nv on my hardware.
<directhex> RAOF, does more than glxgears yet?
<RAOF> Yes.  But the interesting features aren't 3d, at least yet.
<RAOF> We wouldn't be shipping the 3d component.
<RAOF> Interesting features are excellent 2d acceleration, dual head support, etc.
<directhex> which are interesting features, then?
<RAOF> The aggressively-unsupported 3d (still) runs OpenArena at good framerates on my lappy, but many other apps either hit slow paths or don't work properly.
<directhex> the problem with openarena as a benchmark is it's a 9 year old engine
<RAOF> Right.  The 3d isn't ready to be used yet.
 * directhex is mostly waiting for 4000-series intel support to improve enough that he can run a game on his laptop without X falling over dead
<jdong> ha you're joking.
<jdong> I'm still waiting for my 900-series Intel to work.
<jdong> what's red and blue and red and blue and green and blocky all over?
<jdong> xserver-xorg-video-intel trying to wake from suspend while playing xvideo with compiz on.
<jdong> :P
<RAOF> Hah.  Suspend!  Surely you jest?
<jdong> it's amazing that some laptop users might actually want suspend support :)
<directhex> jdong, nothing changes. i remember the good ol' days of ati rage on windows - one driver would cause lockups within 12 seconds of boot, t'other would, on fullscreen 3d apps, only draw half the screen, in purple
<jdong> fast-user switching not having 3D accelerated 2nd users is also a bit mean :)
<jdong> I guess it's a fight for who gets to log in first and have 3D :)
<allquixotic> Hi! I reported the SRU here: https://bugs.launchpad.net/ubuntu/+source/libshout/+bug/304843 and it has been pushed to intrepid-proposed. If someone else can run the test case and verify its correctness, we should be good to go after waiting a week for regressions. Please leave a comment on the bug if you perform the test steps. :)
<ubottu> Launchpad bug 304843 in libshout "SRU Request: libshout3 in intrepid" [Undecided,Fix committed]
#ubuntu-devel 2009-11-30
<superm1> slangasek, i didn't even see an attempt at a mythbuntu build for 11-29 in http://people.canonical.com/~ubuntu-archive/cd-build-logs/mythbuntu/lucid/ but other *buntus were built on 11-29.  any ideas what's going on?
<superm1> i recently made some seed changes, so i'm hoping i didn't bork things badly suddenly
<jdong> [ 2351.982360] ecryptfs_lookup: lookup_one_len() returned [-36] on lower_dentry = [\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
<jdong> oh that doesn't look pretty.
<Romeo_Calif> Hi
<Romeo_Calif> Hello
<Romeo_Calif> Room
<Romeo_Calif> gilir:
<RAOF> Do you have a question about Ubuntu development?
<pitti> Good morning
<plague> morning
<woodbj> haha its 7.30pm where i am, so evening
<plague> lol evening
<plague> how goes it
<plague> hey question from a student developer: how would you recommend starting open source development? specifically what would be good resources and projects to look at?
<geser> pitti: Good morning. Do you have an idea what went wrong here? http://launchpadlibrarian.net/35907181/buildlog_ubuntu-lucid-i386.pion-net_2.2.2%2Bdfsg-2_FAILEDTOBUILD.txt.gz
<geser> objcopy:debian/libpion-net-dev/usr/bin/stGeegc0: cannot create debug link section `debian/libpion-net-dev/usr/lib/debug//usr/bin/PionHelloServer': Invalid operation
<plague> I take it its wakie up time in america?
<\sh> moins
<\sh> who is responsible for the "requestsync" tool? It gives me a wrong information, regarding a version in sid and a version in ubuntu...
<ogra> doko, did you already switch the gcc defaults to implicit-it for armel (i dont see it mentioned in the changelog)
<geser> \sh: any dev can fix it. What problem do you have exactly?
<doko> ogra: no
<\sh> geser, e.g. shermann@wz-pc-010:~$ requestsync -d sid --lp ampache lucid
<\sh> E: The versions in Debian and Ubuntu are the same already (3.5.1-2). Aborting.
<ogra> doko, but you plan to, right ?
<\sh> geser, ampache in sid : 3.5.2-1 and in ubuntu  3.5.1-2
<doko> pitti: please promote the binary xz-utils package (source already in main, eglibc now b-d's on it)
<\sh> geser, the same happens with s/sid/unstable/
<\sh> geser, I tested this on 3 different installations of karmic ... so IMHO it's a bug in requestsync or whereever the info comes from
<geser> \sh: with the --lp flag requestsync uses the LP debian "mirror" (through the LP API) to look up versions and https://edge.launchpad.net/debian/+source/ampache still lists the old version
<\sh> argl
<geser> when you omit the --lp it will don't use any LP API (rmadison instead) and mail the sync request
<dholbach> ttx: somebody requested a sync of libaopalliance-java - does it matter if it depends on default-jre vs default-jre-headless?
<geser> \sh: I guess you can't sync ampache anyways as it uses "Format: 3.0 (quilt)
<geser> "
<ttx> dholbach: I was just looking at those. Yes it matters, and there is another patch that was not merged
<dholbach> alrighty
<ttx> I'll update the bug accordingly
<dholbach> rock on!
 * dholbach hugs ttx
<ttx> jI just need to doublecheck that there weren't some silent fixes in debian, but I doubt it
<\sh> geser, do you think it's fair enough to do a fakesync?
<geser> \sh: not until LP accepts Format 3.0 packages or you change it back to Format 1.0 (don't know how much work that is)
<\sh> geser, rm -Rvf debian/source ;) that's all...I already have this version running on my local ampache server :)
<geser> in that case it's IMHO OK to do a fakesync
<\sh> geser, k...
<matteo> hi all
<Laney> morning fellas
<pitti> doko: done
<pitti> geser: FTBFS> hm, the log doesn't tell why; is PionHelloServer a normal ELF file?
<dholbach> hey Laney
<ttx> pitti: question about subcycle tracking in WorkItemsHowto -- when a spec has alpha-2 items and some later items but you still want to correctly track alpha-2 completion, I can use the subsection trick described in the doc, but should the blueprint be targeted to alpha-2 or to final ? (or changed to final just after alpha-2 ?)
<ttx> pitti: example: https://blueprints.edge.launchpad.net/ubuntu/+spec/server-lucid-eucalyptus-karmic-retrospective
<ttx> pitti: last three items are obviously post alpha-2 but all the others should be completed by alpha-2
<pitti> ttx: if you want it to appear on the server-lucid-alpha2 burndown, target it to alpha-2, and untarget after alpha-2 was released
<ttx> pitti: ok, makes sense. Thanks !
<geser> pitti: debian/tmp/usr/bin/PionHelloServer: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
<pitti> geser: hm, that looks fine; I wonder why objcopy -R .gnu_debuglink --add-gnu-debuglink doesn't work then
<geser> pitti: here are the last lines when run with DH_VERBOSE=1: http://paste.ubuntu.com/331612/
<geser> pitti: it succeeds when I change the call from dh_strip -k to dh_strip (but fails afterwards due to missing files)
<maxb> Does anyone know when james_w is likely to be back?
<seb128> maxb, he should be back today
<geser> pitti: found the problem: the dh_strip wrapper knows about --keep-debug but not about its short name -k. Could you please apply http://paste.ubuntu.com/331631/ to dh_strip from pkg-create-dbgsym?
<maxb> That would be nice - At the moment he's a bit of a single point of failure for UDD matters :-)
<jml> maxb, good point. I'll make a note into seeing what we can do to fix that.
<soren> Does anyone happen to know the HZ kernel setting used on the buildd's?
<maxb> soren: I'd be surprised if they were not running official Ubuntu kernels
<soren> maxb: The buildd's are full of surprises :)
<maxb> Well, true
<maxb> I reckon lamont is the person to give you a definitive answer
<lamont> soren: stock hardy kernels
<lamont> well, unless you're powerpc, in which case, s/hardy/dapper/
<soren> lamont: -server?
<lamont> *shrug*
 * lamont goes looking
<soren> lamont: How about sparc?
<lamont> sparc has hardy
<soren> I have a build that works on powerpc and sparc, but fails everywhere else.
<soren> hm.
<soren> Ok.
<lamont> ppc has dapper because the hardy kernel didn't actually work with the hardware in question, istr
<lamont> though testing that with a more current release of the OS is in plan
<soren> Yeah, that sounds vaguely familiar.
<soren> Oh, sorry, not sparc. armel.
<lamont> armel == jaunty
<soren> armel and powerpc work. None of the other. Upstream suggested it might be the HZ setting.
<lamont> note also that there is absolutely no guarantee or even hint that HZ will be the same on the build machines as it is on the end-user machine...
<soren> Of course.
<ogra> wow, there is an area where armel works better than other arches  ?
<ogra> exciting
<soren> ogra: Don't worry, I'll fix up the other arches so that armel once again will be no better than anything else :)
<ogra> pfft
<ogra> and i thought i could show off with it
<Ng> ogra: show off that it's marginally better at building broken packages, except much, much slower? ;)
<jdong> dpkg-shlibdeps: failure: no dependency information found for /usr/lib/libstdc++.so.6 (used by debian/handbrake-cli/usr/bin/HandBrakeCLI).
<jdong> *scratches head*
<rohdef> where should I ask questions about development on Ubuntu?
<azeem_> rohdef: developing on Ubuntu or Ubuntu development?
<rohdef> developing on Ubuntu, since the topic says that this isn't the right place to ask, hence the question ;)
<azeem_> no idea
<rohdef> ok, mind if I ask here anyway?
<mpt> Does anyone know why there's a "Fonts (universe)" section in Synaptic but no "Fonts (main)" section?
<fagan> mpt: thats weird
<mpt> Without that, there's no way to know Gentium exists unless you know to search for "ttf-"
<mvo> mpt: I think its inconsitent use of the section
<mvo> mpt: the one in main seems to be misc graphical
<mpt> or Liberation (in Karmic, anyway)
<fagan> The fonts need some love
<fagan> The design team need to really look into it
<mpt> "Fonts (universe)" also doesn't contain ttf-mgopen, a really nice set
<fagan> mpt: I was at it too
<fagan> :)
<mpt> My main concern right now is working out a way to show all the fonts by themselves in the Ubuntu Software Center
<mpt> including ttf-mgopen and ttf-sil-gentium, and excluding fontforge-extras :-)
<mvo> I think we should consider this wrong section use a bug
<fagan> mpt: that would be hard since they are packaged together for the most part
<mpt> fagan, oh sure, by "by themselves" I don't mean individually, I mean separate from non-font packages
<fagan> oh now I understand
<fagan> mpt: while we are the the software center, any thoughts on packaging up plugins for applications?
<fagan> I noticed that totem, rhythmbox etc all have plugin systems that not many people know how to use
<fagan> so maybe we can make it easier in the software center
<fagan> plus we can do it locally without root privileges for most of them
 * fagan needs to go to college be back in 2 hours :)
<Keybuk> cjwatson_: FYI http://people.canonical.com/~scott/daily-installer/
<kirkland> pitti: fyi, I just verified the remaining bug for that eucalyptus SRU; you can push to -updates at your convenience
<kirkland> pitti: we're working the next SRU now
<kirkland> pitti: so we'll have a new one in -proposed as soon as you clear that one out
<pitti> kirkland: nice, thanks
<mpt> mvo, so when Synaptic says "Fonts (universe)", does that mean there's a "Fonts" section in Ubuntu generally, and it just happens to have packages only in Universe? Or is the section actually called "Fonts (universe)"?
<mpt> hm, I see apt-cache show shows "Section: universe/fonts"
<mpt> Why is the "universe/" there?
<mvo> mpt: it means that it did not find anything in fonts, only fonts/universe
<mpt> fagan, I do intend to spec how plug-ins and extensions will be shown in a much more helpful way <https://wiki.ubuntu.com/SoftwareCenter#Presenting%20add-on%20packages>
<mpt> fagan, but in general, I think the more integrated plug-in/extension installation is with the actual program that uses it, the better
<mpt> fagan, for example, a directory of installable screensavers probably would work better in the Screensaver preferences than in the USC
<ulath> hi, wich package do i need to develop kde4 apps in kdevelop3 on kubuntu 9.04 ?
<ulath> when i start the "new project" wizward there are no kde4 applications availible
<mpt> mvo, so I'll report individual bugs on packages that have the wrong section
<kirkland> pitti: ttx asked me to ping you; and ask you to hold on that eucalyptus publication to -updates momentarily
<mvo> mpt: yes, its probably good if you tag them as well
<ttx> pitti: around ?
<pitti> ttx: on the phone
<ttx> pitti: ok -- i'll explain the situation here and you can answer when you're done with the phonecall :)
<ttx> pitti: About the eucalyptus karmic SRU (ubuntu7.3) we just discovered that fix for bug 460089 introduced a small regression, basically no easy way the clean the CC state anymore.
<ubottu> Launchpad bug 460089 in eucalyptus "network state is lost if the cluster controller (CC) is stopped" [Medium,Fix committed] https://launchpad.net/bugs/460089
<ttx> pitti: kirkland will upload a 7.4 with a one-liner fix [ "${CLEAN}" = 1 ] -> [ "${CLEAN}" = "1" ] to fix that and we'll restart the SRU testing process (again).
<kirkland> pitti: the change ttx speaks of is this: http://paste.ubuntu.com/331811/
<ttx> pitti: though, given the impact of the one-liner, testing should actually go fast
<kirkland> pitti: I think it should be a pretty clear shell bug
<ttx> and we still hope to publish that SRU soon.
<ttx> pitti: so please reject eucalyptus...-ubuntu7.3 from -proposed, we'll upload and fast-track a new one.
<pitti> re
<pitti> ttx: hm, 1 or "1" shouldn't make a difference..
<ttx> kirkland: ^
<pitti> ttx: I can't "reject" it, and I don't think we should remove it from -proposed after such a long time
<pitti> ttx: we can of course get a new one into -proposed
<ttx> pitti: ok
<pitti> ttx, kirkland: if you do a new upload, please include the previous changelog with -v
<pitti> but I don't understand the impact of changing 1 to "1"
<ebroder> Yeah, I'm confused by that: http://paste.ubuntu.com/331815/
<kirkland>  foo="1"
<kirkland> [ "${foo}" = 1 ] && echo true
<rcbwnka> ==
<kirkland> pitti: I agree with you ... there's something else non-deterministic at play here
<kirkland> ttx: arg arg arg
<kirkland> ttx: sometimes all of those files get cleared, and sometimes they don't
<ttx> ?
<kirkland> ttx: i'm not kidding
<ttx> kirkland: ah, you told me the "1" thing was fixing it, so I believed you
<rcbwnka> "=" mean make this number equal to whilst "==" means "Its equal to".
<kirkland> ttx: i believed me too
<kirkland> ttx: :-) it did work a few times
<pitti> == is a bashism, though
<ttx> I've seen stranger upstart things :)
<pitti> but "" is just quoting, and not part of the actual comparison
<kirkland> ttx: now it's back to the behavior I reported in Bug #490382
<ubottu> Launchpad bug 490382 in eucalyptus "eucalyptus-cc init script doesn't always clear /var/lib/eucalyptus/CC" [Medium,Triaged] https://launchpad.net/bugs/490382
<ogra> rcbwnka, == is not POSIX compliant, it needs to be =
<kirkland> rcbwnka: you're off base, we're talking posix shell code here
<mpt> mvo, reported and tagged: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=metadata
<ccheney> heh OOo apparently now has hppa support
<rcbwnka> kirkland: Im very old in the game, i should know.
<ogra> ccheney, does that move armel one up on your prio list ? *g*
<ccheney> ogra: heh :)
<rcbwnka> Wow! record breaker! :) http://mange.dynalias.org/linux/misc/scripts/sys_uptime/downloads.htm
<rcbwnka> 5200 a few months ago, perhaps now itll be even more cool
<rcbwnka> ogra: #!/bin/bash ... POSIX itll be. Thats not your job, its the job of the underlying C code.
<ogra> ??
<rcbwnka> You cant beat C
<rcbwnka> Ill check out the new "Go" though
<ogra> rcbwnka, note that #!/bin/sh points to dash in ubuntu, so script code used needs to be "bashism free" ... == is bash specific
<ogra> as pitti said above already
<ogra> if you explicitly use #!/bin/bash that doesnt matter ... but we dont use that for system wide scripts usually
<rcbwnka> ogra: Read what i wrote. Youre ok though, as a thinker.
<rcbwnka> "<rcbwnka> ogra: #!/bin/bash" Does not mean anything else then Bash
<rcbwnka> Sorry, go on...
<rcbwnka> Anyone tried "Go" though ?
<rcbwnka> ogra: Whats the need for calling it dash, when in fact its bash ?
<ogra> dash isnt bash
<rcbwnka> :)
<ogra> its a different shell
<rcbwnka> Aha...
<ogra> faster, smaller etc
<ogra> and POSIX compliant ....
<ogra> bash adds specific stuff on top of POSIX
<rcbwnka> Like compliance with C and C++ that are already POSIX you mean ?
<ogra> if you write scripts that should work system wide in ubuntu you are supposed to avoid such "bashisms"
<rcbwnka> ~Posix
<rcbwnka> ogra, is this the Boulder Dash: http://www.brothersoft.com/dash-download-64685.html
<ogra> http://en.wikipedia.org/wiki/Debian_Almquist_shell
<rcbwnka> Read it.
<rcbwnka> Im not saying its bad, but why would he want to diverge from "==" as equal to as you have said ?
<rcbwnka> Thats very much POSIX
<rcbwnka> Do you also think that Wodim isnt CDrecord ?
<rcbwnka> Or derived there from ?
<rcbwnka> All they actually did was fork the name and made sure the author couldnt schock them too much
<maxb> james_w: Hi. If you have a moment, could you go log hunting / retry the UDD import for subversion 1.6.6dfsg-2 ? Thanks.
<rcbwnka> A bit of a change was coded into the argv[] readings
<rcbwnka> maxb: ?
<rcbwnka> Lol, how malplaced
<rcbwnka> Hmm, i have used all Ubuntu releases for some years and now the pulseaudio system doesnt work as well as in Fedora for example. Why not grab their version of pulse-audio and their patches ?
<rcbwnka> Or the Slackware one etc ?
<rcbwnka> Arch, Gentoo...
<Keybuk> rcbwnka: I need to introduce you to some Fedora users I know ;-)
<Keybuk> the Fedora PulseAudio maintainer is absolutely convinced that PA is perfect in Fedora
<Keybuk> Fedora users ... much less so
<Keybuk> obviously Fedora users are much harder to find than the Fedora PA maintainer
<Keybuk> they tend to be quieter, for a start
<rcbwnka> Keybuk: Coders rock, let them rock. Very simple.
<ogra> Keybuk, LOOOOOL
<ogra> !!!!
<rcbwnka> Keybuk: Users will always leve feedback that the coders will fix, or should fix.
<rcbwnka> leave
<kklimonda> Keybuk: are you saying that there are actually some voices that PA may not be the right way? /me is getting scared of another audio revolution..
 * ogra thinks that was actually only funny if you know the PA maintainer :)
<rcbwnka> Ive never seen anyone of you before beeing on irc 24/7 for 20 years now.
<rcbwnka> ogra neither.
<ogra> trhen you missed the last 5 years obviously :)
<rcbwnka> ogra: No. I did not.
<jdong> lol I can't recall the last time ogra wasn't on IRC ;-)
<jdong> and that dates back to crackports days ;-)
<ogra> heh
<jdong> good times... (ok not really!)
<ogra> well, i pretty much hung around here with pre warty
<ogra> i didnt do much IRC before that though
<fagan> mpt: yeah I understand that but having it centralised too would be awesome I think
<rcbwnka> ogra must be very good then. Is this true ogra ?
<Keybuk> rcbwnka: you don't know too many coders, do you? :)
<rcbwnka> Keybuk: I do.
<Keybuk> and the ones you know listen to all user feedback, without ever thinking that they're right, damnit? :p
<rcbwnka> Keybuk: I began patching things back in 1994-5
<rcbwnka> Whats your name ?
<Keybuk> I'm trying very hard to resist replying "Lennart Poettering" for the humour value
<jdong> lol
<rcbwnka> Or Microsoft's Hahn
<Keybuk> I wasn't patching things back in 1994-5
<ogra> *grin*
<Keybuk> I was still at school
<Keybuk> and mostly hanging around in the library being a nerd
<rcbwnka> Im going out. Be all you can be though.
<Keybuk> that was the last year I nearly got expelled actually ;)
<rcbwnka> Keybuk: Define "Nerd". I always thought it was "Entity with a far reaching interrest in something" ?
<Keybuk> rcbwnka: I used to have wear a Starfleet Comm Badge above my school's logo on my uniform? :p
<Keybuk> does that count
<ion> :-D
<rcbwnka> So, if people arent nerds they are zombies ? :) /almost no will to live ?
<rcbwnka> Keybuk: Why ? :P
<Keybuk> because I was a very sad young man
<rcbwnka> Keybuk: I used to keep classes calm. Like beeing an equlibrium.
<rcbwnka> equilibrium
<rcbwnka> I used to beat the hell out of people before that.
<rcbwnka> But they deserved it. Not geeks or so.
<rcbwnka> It was like "Noone messes with my classmates or school" etc.
<rcbwnka> A long time ago.
<rcbwnka> to have an interrest is to have a livna
<rcbwnka> LifeLine
<rcbwnka> Nicotine has a very high soothing effect. Perhaps good for hyperactive children etc ?
<rcbwnka> Bad drug though.
<rcbwnka> My homepage dood seems to be on vacation again. Can someone ping this guy to make some updates? -> http://gadmintools.flippedweb.com
<Ng> my markov bot senses are tingling wildly ;)
<slangasek> superm1: sorry, no idea why mythbuntu was skipped on 1129; seems to have run today, though?
<ebroder> Ng: I'm glad it's not just me
<ManDay_> hey guys, the alternate installation cd is just a mess. did you know that you should never try to install packages through aptitude but rather select them and then quit apitutde with q in order to install them?
<ManDay_> its such a pita
<ccheney> ManDay_: use dselect :)
<ManDay_> dselect?
<ManDay_> the installer opens me aptitude
<superm1> slangasek, yup, okay no problem then.  i was just worried i broke things with the seed changes i made
<ccheney> ManDay_: oh nm i was mostly joking, i haven't done an alternate install in several months so can't remember how it works
<ManDay_> well its onyl for the bloody karmic anyway
<ManDay_> the whole alternate install of karmic seems a mess
<ManDay_> aptitude in the installer one of the smalles problems
<ManDay_> i wonder what they have changed and why
<toobaz_> Is there someone knowing if behind the choice of putting nautilus scripts in /usr/share/nautilus_scripts and assuming they are installed there there was some discussion?
<ManDay_> jaunty worked just flawlessly
<toobaz_> (in case not): is there some place where one can get in touch with Ubuntu Gnome devs?
<ManDay_> #gnome ?
<ManDay_> or gnome.org ?
<ManDay_> just one stupid guess
<rcbwnka> I have 2 problems with the more recent incarnations: 1. Sound blows although on Fedora and other dists its perfect (Check patches /+/-/).
<toobaz_> ManDay_: it's not a general GNOME problem... as far as I know, only Ubuntu installs those scripts system-wide
<ebroder> ManDay_: If you actually have specific problems with the installer, people can try to help fix those. If you're just going to whine, that's not productive and you might as well not waste your breath
<rcbwnka> Cairo makes a total screen redraw
<rcbwnka> Hosed on Debian, Fedora and Ubuntu. Its something that Cairo can be compiled with (Shitty little lib).
<rcbwnka> lib...something...
<rcbwnka> Its not even required
<rcbwnka> Or useful
<rcbwnka> Pixman is ok though
<superm1> maybe i shouldn't feed a troll, but rcbwnka if you have particular things to complain about, it's more constructive to provide specifics about them on bugs than whining "everything is broke, FIX IT" on irc.  Eg, pulseaudio is bad at Y because ubuntu is missing patch X that fedora has, or ubuntu patch Z is causing problems.
<rcbwnka> poppler is also cool
<ManDay_> ebroder, read my first comment
<ManDay_> besides, i can provide you with plenty of bugs
<ManDay_> ;)
<rcbwnka> superm1> Thought someone but me kept track
<ebroder> ManDay_: Have you reported any of the bugs to LP?
<ManDay_> no
<rcbwnka> Im tracking the slowness down, hold on.
<rcbwnka> Maybe its some sv
<rcbwnka> SVG lib
<superm1> rcbwnka,  of course there is a pulseaudio maintainer in Ubuntu and he's watching other distros and upstream for patches all the time i'm sure, but if you have a particular oversight he missed, it's best to direct it to him on a bug in launchpad
 * ogra points rcbwnka to bugs-launchpad.net and calls it a day
<ogra> *bugs.launchpad.net
<rcbwnka> superm1: Assuredly so, i may know more then you know. What i want is input. Dont you want input _
<rcbwnka> ?
<ogra> yes, thats why we have bugs.launchpad.net
<ogra> it keeps noise out of this channel
<rcbwnka> Have you disabled Glitz and patches ?
<ogra> if you have concrete oveseen patches please file bugs
<rcbwnka> IE: Is glitz installed ?
<rcbwnka> ogra ?
<rcbwnka> Im thinking there could be some remnant patches for glitz etc so that the whole desktop etc becomes sucky
<ogra> rcbwnka, if you think so, why not file a bug and wait for respoinse from the maintainer, that would keep the channel a lot quieter
<rcbwnka> Ive given you the search criteria for the issues.
<ogra> and i'm doing actual work
<ManDay> its unbelievable
<ManDay> i cant get that **** to install
<Daviey> rcbwnka: that isn't how the process works.. if you think there is a bug, you need to raise it and it'll go through the normal work flow.
<ogra> i dont do searches for $random_dude_asking_stuff_on_IRC
<rcbwnka> Daviey: If i was a normal user perhaps. /snickers
<superm1> no, this is the process for EVERYONE.
<Daviey> rcbwnka: Are you intentionally trolling?
<rcbwnka> So if i found a fatal flaw or a remarkable "PowerUp" for the dist yould say "Naah, file a bugreport" :)
<ebroder> rcbwnka: Yes
<ebroder> It's exactly what any of us would do in the same situation
<rcbwnka> HAi!
<rcbwnka> Hehe
<rcbwnka> Ive always thought out of the box as i feel sitting in a box would be mindnumbingly odd for me.
<rcbwnka> My iron maiden CD just broke, is it legal for me to download a new one (considering i bought this one) ?
<hyperair> is anyone else noticing dpkg's large amount of memory usage recently?
<rcbwnka> Not that ill care, but...
<Keybuk> rcbwnka: that isn't really on-topic for this channel
<rcbwnka> I know, i got a bit angry considering it broke.
<Keybuk> this still isn't the place
<RainCT> toobaz_: #ubuntu-desktop?
<Keybuk> this channel is for Ubuntu developers to discuss things they're working on
<Keybuk> not a place for users to harass Ubuntu developers
<rcbwnka> Baby wants milk ?
<toobaz_> RainCT: uhm... looks interesting. will try
<RainCT> Keybuk: btw, no hurry from my side, but do you remember the MoM redesign patch is still waiting for review? :)
<Keybuk> RainCT: no?
<RainCT> Keybuk: https://code.edge.launchpad.net/~rainct/merge-o-matic/redesign/+merge/9075
<Keybuk> RainCT: there's lots of unrelated changes in this branch
<Keybuk> e.g.
<Keybuk> -    return md5.new(open(filename).read()).hexdigest()
<Keybuk> +    return hashlib.md5(open(filename).read()).hexdigest()
<Keybuk> why?
<RainCT> Keybuk: because md5 is deprecated :)
<Keybuk> RainCT: bearing in mind this runs on *hardy*
<Keybuk> which has a much older Python
<elmo> Keybuk: it's only python 2.5 :)
<elmo> Keybuk: which has hashlib
<RainCT> Keybuk: Yeah, but new enough for hashlib
<Keybuk> +# Copyright Â© 2008-2009 Siegfried-A. Gevatter Pujals <rainct@ubuntu.com>
<Keybuk> ... I'm pretty sure we'll need copyright assignment for this
<Keybuk> it's not in "the list", but it's a very large patch
<sgallagh> mathiaz: Just a heads-up. We just released our feature-complete beta of SSSD today. We'd love to see it get some exposure in lucid.
<rcbwnka> http://liboil.freedesktop.org/wiki /Hehe
<sgallagh> mathiaz: The plan is to spend the next 2-3 weeks addressing any bugs we can find, then releasing 1.0 final.
<rcbwnka> Seems to be required by gstreamer
<RainCT> Keybuk: Why would you "need" copyright? iirc it's GPL
<rcbwnka> And automatically added to the desktops of caught lingering on the systems as libs
<rcbwnka> of&if
<Keybuk> RainCT: http://www.canonical.com/contributors
<RainCT> Keybuk: Yeah, I know that page, and it contains no rationale to justify what they are asking for.
<Keybuk> RainCT: I'm really not interested with arguing about it with you
<Keybuk> if you're not willing to sign the form, then I'll mark the merge request as rejected and move on :)
<cody-somerville> Keybuk, MoM doesn't appear to be listed on that page as covered under the agreement... or am I just missing it?
<Keybuk> like I said, it's not on the list, but it's a very big patch
<rcbwnka> RainCT> Copyright is good because i assume you wouldnt want to spend years and years only to have some snotnosed punk write their name on your works RIGHT ?
<RainCT> rcbwnka: Right, so that's why I want to keep my copyright and not give the right out to others without a good reason for it :)
<rcbwnka> Yeah, to not have them claim they did the work you performed. The code itself is still HIGHLY USABLE
<elmo> RainCT: http://www.gnu.org/licenses/why-assign.html
<rcbwnka> Its also why youre an outcast if you borrow large chunks of code and never say that in your sources
<rcbwnka> Credits you know
<rcbwnka> RainCT: Do you have any more questions pertaining to this subject ?
<slangasek> rcbwnka: given that TTBOMK you aren't an employee of Canonical, I think it would be best if you not speak for them regarding /their/ motivations for having a copyright assignment policy...
<rcbwnka> Is IBMS Postfix Non/revokable yet btw ?
<Keybuk> rcbwnka: that kind of question is better asked in #ubuntu
<RainCT> slangasek: I'll think about it, but in any case if I sign that I'd change the text to be specific to this particular MoM patch, I suppose that's OK?
<rcbwnka> slangasek: Im a much older entity and i hope Canonical are in line with what this Swede thinks.
<lamont> rcbwnka: 2.0 released with a version that met DFSG guidelines == no retroactive revocation
<rcbwnka> Good!... Finally IBM rocks on this matter as well.
<rcbwnka> Thanks lamont.
<rcbwnka> Now i can constuct some guis for it
<lamont> rcbwnka: mind you, I uploaded 2.0.0 to debian in 2002...
<rcbwnka> lamont: I had many things todo, and now they are done. Almost 40 years earlier then i first thought.
<rcbwnka> I see ill have to make a better version of what microsoft calls IIS. Too easy :)
<rcbwnka> Im gonna download a copy of my original Iron Maiden CD and not think twise about it.
<rcbwnka> I bought it, its mine and its their commitment to provide patches
<rcbwnka> :)
 * cody-somerville twitches briefly.
<ebroder> Can I call the channel ops yet?
<rcbwnka> no
<Pici> rcbwnka: Please be mindful of the channel topic, this is not a chat channel.
<Pici> #ubuntu-offtopic exists if you want to be random somewhere.
<rcbwnka> I shall be utmost that. MIT, please be nice broder
<RainCT> elmo: btw, (just asking out of curiosity), didn't they recently set a precedent for the GPL being enforced by someone other than the copyright holder? Or wasn't that in the US?
<elmo> RainCT: i'm not aware of anything like that happening in the US or the UK but I may have missed it
<rcbwnka> Pici: Some day, as a coder i perhaps can, chat like the do to day, in this chat channel maybe i can ?
<Pici> rcbwnka: you're free to talk here if you're going to be on topic, but it doesn't look like you're doing that.
<rcbwnka> Pici: I was better then on topic. Alright, i shall tryeth.
<pitti> Keybuk: udev bits committed upstream now
<Keybuk> pitti: yup, I saw
<Keybuk> am pulling atm
<pitti> \o/
<rcbwnka> Yawn.
<pitti> Keybuk: for testing, can you please pull the CK packages from https://edge.launchpad.net/~ubuntu-desktop/+archive/ppa ?
<rcbwnka> Im tossing
<rcbwnka> Pappaaa ?
<rcbwnka> Oh my Pappaaa / Got bored there for a while listening to boredom.
<rcbwnka> Have you lost the developing hard rock you once had ? / Focus on getting angry and youll have it back in notime.
<slangasek> rcbwnka: you've been asked repeatedly not to use this channel for off-topic chatting, and you don't seem to be taking the hint
<rcbwnka> No, Dirk.
<rcbwnka> slangasek: How many programs did you create that now reside onj magnetic tape or tractor/hole tape ?
<rcbwnka> Sit back and relax
<rcbwnka> Ill not husrt you or anyone else
<slangasek> rcbwnka: you're diluting the utility of this channel by filling it with irrelevant commentary.  You've been asked to stop.  If you don't stop, you'll be asked to leave instead.
<rcbwnka> slangasek: Youre full of crap. Why shouldnt I have great knowledge over most things, having created things ? / sit back and relax my friend
 * cody-somerville blinks.
<rcbwnka> Nothing to see here... move along...
<rcbwnka> Blink
<slangasek> pah, what's trying to pull all of KDE onto my Ubuntu system when upgrading to lucid?
<jdong> ScottK...
<jdong> *ducks*
 * ScottK blames compiz.
<Tm_T> slangasek: oh, our invasion shouldn't be that obvious
<rcbwnka> jdong: Schloong :P
<slangasek> jdong: nope, quodlibet-plugins
<slangasek> hmm, not that either
<slangasek> oh; yes, yes it is
<rcbwnka> slangasek: Are you spamming this channel with uselessness ?
<slangasek> no, I'm discussing Ubuntu development
<rcbwnka> Good, good.
<rcbwnka> Are you against lesbians then ?
<kirkland> can we please kick/ban rcbwnka ?
<jdong> !ops | rcbwnka
<ubottu> rcbwnka: Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<ebroder> Thank goodness. THank you, Pici
<ajmitch> thanks pitti
<jdong> thanks, Pici :)
<ajmitch> s/pitti/pici/
<jdong> and Pricey you missed the fun!
 * kirkland thanks the IRC gods
<Pici> np
 * lamont now remembers how to become channelop.
<mneptok> dialup. how quaint.
<ajmitch> mneptok: don't swear please
<RainCT> mneptok: must have been trolling to survive the frustration
<mneptok> ajmitch: ISDN you, pal!
<mneptok> hmmm .... ISDN *is* a four-letter word.
<ajmitch> mneptok: it's been awhile since I used that, when it seemed so very fast :)
<Tm_T> what's wrong with dialup?
<mneptok> Tm_T: http://www.techdirt.com/articles/20091014/1201166530.shtml
<mneptok> Tm_T: know your rights!
<Tm_T> mneptok: I know, and I'm still happy with my occasional gprs usage
<mneptok> Tm_T: i'm beginning to doubt your Finnish-ness.
 * mneptok prescribes a sauna, 3 gulps of salmiakkikossu, and a sisu transplant
<Tm_T> mneptok: I got all those here, thanks
<mannyv> What do I have to do if I want to pull a few packages from one package under GPL and use them in a package I am working on  package
<ion> Salmiakkikossu is awesome.
<Tm_T> I really don't use much alcohol internally though, don't like how it affect brain
<pitti> kirkland: hm, so is there a regression in the euca update, or is it just the same race condition that was in final, too?
<kirkland> pitti: it's the latter
<pitti> kirkland: so it's good to go?
<kirkland> pitti: i'm really sorry about the shell quoting noise
<pitti> no problem :)
<kirkland> pitti: yes, go ahead and push
<kirkland> pitti: we'll have a new one for -proposed very soon
<kirkland> pitti: again, my apologies
<micahg> pitti: is there a way to run apport for a single instance anymore?
<pitti> kirkland: no worries, I was just unsure whether the v-failed in bug 460089 still applied
<ubottu> Launchpad bug 460089 in eucalyptus "network state is lost if the cluster controller (CC) is stopped" [Medium,Fix committed] https://launchpad.net/bugs/460089
<pitti> micahg: in lucid that was fixed again (force_restart=1)
<pitti> unfortunately it got broken in karmic
<kirkland> pitti: no worse than in final, as you said
<kirkland> pitti: ie, i don't think the SRU introduces this
<micahg> pitti: is an SRU planned for it?
<pitti> micag: not from my side, it's not that important; if someone else wants to pick it up, it's acceptable, of course
<micahg> pitti: ok, thanks
<ScottK> pitti (or any other DMB member who is around): We approved our first kubuntu-dev application, but are unfortunatlely lacking the one kubuntu-dev who can add people (see ubuntu-devel for details of the meeting).  Would one of you please add https://launchpad.net/~echidnaman to ~kubuntu-dev?
<pitti> wohooo!
<pitti> ScottK: do you use any standard timeout?
<ScottK> pitti: Thanks for taking care of it.  I'm not sure what you mean?
<pitti> ScottK: nevermind, that was set automatically already; so, "done"
<pitti> ScottK: s/timeout/expiry/
<ScottK> Cool.  thanks
<ScottK> I got it.
<ScottK> This is a bit of a historic moment I think.
<geser> pitti: did you see my patch for pkg-create-dbgsym to fix the FTBFS from this morning?
<pitti> geser: sorry, no; is it in a bug?
<geser> pitti: no, didn't file a bug report for it yet
<geser> pitti: found the problem: the dh_strip wrapper knows about --keep-debug but not about its short name -k. Could you please apply http://paste.ubuntu.com/331631/ to dh_strip from pkg-create-dbgsym?
<pitti> geser: aah
<pitti> geser: nevermind about a bug, I'll apply it right now
<pitti> hm, the -k is new?
<pitti> I'm fairly sure it wasn't there when I wrote this initially
<pitti> anyway, good catch, thanks!
<sebner> ScottK: congratulations then. kubuntu ftw!
<sebner> huhu pitti geser :D
 * pitti waves to sebner, guten Abend!
<robbiew> pitti: do you know what's holding up getting bug 451304 processed for karmic-proposed?
<ubottu> Launchpad bug 451304 in devicekit-disks "Partition type 0x12 could be hidden" [Undecided,In progress] https://launchpad.net/bugs/451304
<sebner> pitti: Guter Abend in der Tat, mein erster mathe test war positiv. No need for suicide yet ;)
<pitti> robbiew: someone else than me needs to process it (since I uploaded it); I pinged slangasek/cjwatson
<robbiew> ah...that makes sense
<pitti> sebner: congrats!
<robbiew>  okay, thanks
<sebner> pitti: thx :)
<geser> Hi sebner
<DktrKranz> pitti, geser: ubuntu-dev-tools and buildd share usr/bin/buildd and usr/share/man/man1/buildd.1.gz, what about renaming them to lp_buildds* (or whatever)?
<pitti> DktrKranz: I don't understand -- isn't buildd a script from ubuntu-dev-tools?
<wgrant> DktrKranz, pitti: There is already a piece of software called lp-buildd. Please don't call it lp_buildd.
<mathiaz> sgallagh: great - thanks for the heads up.
<geser> pitti: yes, buildd is a script from u-d-t and also from "buildd" which cause a filename conflict
<pitti> oh, I see
<geser> so we need a new name for buildd (from u-d-t)
<pitti> geser, DktrKranz: since it's not really about the buildds, but the builds, how about renaming it to "ubuntu-build"?
<geser> what about "buildctl"?
<pitti> WFM
<pitti> pkgbuild, ubuntu-build, ...
<soren> buildkit!
 * soren runs away
<ajmitch> soren: no, bad!
<ebroder> Hehe! Linux needs more kits
<soren> If we had a Quickly for writing kits, it could be called KitKit.
<wgrant> soren: But then you need the Quickly mode to edit kit templates...
<soren> KitKitKit? :(
<jjardon> hello, There is https://bugs.launchpad.net/gtk, should  https://bugs.launchpad.net/libgtk be removed?
<ScottK> soren: I think KitKit is reserved for the Kit management service.
<slangasek> bdrung_: why is adblock-plus not a merge from Debian testing?  (looking at it in the NEW queue, and looking at Debian to verify that this change has also been made there, seemingly independently...)
<bdrung_> slangasek: it's a merge
<slangasek> bdrung_: no, it's not; 1.1.1-0ubuntu4 is an additional Ubuntu revision, whereas Debian is currently at 1.1.1-2
<bdrung_> slangasek: ups, you are right (different sources for 1.1.1)
<bdrung_> slangasek: the next upstream release will lead to a merge
<slangasek> okie
<bdrung_> slangasek: all the other xul extension package are merges
<slangasek> alright :)
<bdrung_> slangasek: the plan for lucid is to rename all extensions to xul-ext-$extname
<slangasek> yeah... I've gathered that :-)
<geser> DktrKranz, pitti: going to rename "buildd" to "ubuntu-build" then if nobody objects
<DktrKranz> geser: fine for me, if you do that change now, mind adding (Closes: #558816) to changelog entry?
<geser> sure
<DktrKranz> thanks :)
<jdong> pitti: poke; just out of curiousity, a long time back we talked briefly about ubuntu-sru <-> motu-sru merging; do we still intend to do it?
<pitti> jdong: we should probably, now that packageset based uploaders are a reality; what do you think?
<jdong> pitti: *nods* Yeah, I think it makes sense to do so; the sooner the awkward limbo state ends IMO the better ;-)
<pitti> jdong: ok, so I should write to u-devel@ and the usru/motu-sru team members tomorrow
<jdong> pitti: cool, sounds great
<Keybuk> james_w: how do you want reports of problems with bzr imports?
<james_w> hey Keybuk. Please file a bug against the 'udd' LP project
<Laney> hiya
<Laney> james_w: do you care for bugs for imports which are out of date?
<Laney> (don't know if you have a script to catch this)
<james_w> Laney: yes please
<Keybuk> james_w: should I file bugs for making branches the lp:ubuntu/ branch?
<james_w> Keybuk: you can, if you mailed me then they will be included already
<Keybuk> you haven't done those yet, right? :p
<james_w> nope :-)
<Keybuk> two of the locations have changed, have replied to my mail
<Keybuk> what about new ones of those going forwards?
<james_w> you can just push to the lp:ubuntu/ branches directly
<bdrung_> Keybuk: why is lucid twice in 'lp:~ubuntu-core-dev/ubuntu/lucid/ureadahead/lucid'?
<james_w> oh
<james_w> no, silly me
<james_w> once the importer has imported the new package then you will be able to push
<james_w> we have a bit a bootstrap issue, but the LP devs have ideas
<slangasek> james_w: lp:ubuntu/foo2zjs fails to reconstitute an usptream tarball
<slangasek> (it looks like the Debian branch may also be /missing/ the latest upstream code, fwiw)
<Keybuk> james_w:  push --overwrite ?
<Keybuk> what about when the package doesn't exist? e.g. lp:ubuntu/upstart doesn't exist
<Keybuk> can I just push to that to make it?
<lifeless> Keybuk: thats because the import hasn't worked.
<Keybuk> I'm surprised at that :)
 * Keybuk would have thought upstart was a simple one
<lifeless> Keybuk: I don't think you can push to create it; you can push to lp:~ubuntu-core-devs/ubuntu/lucid/upstart/trunk
<james_w> Keybuk: no, that's what I mean by a bootstrap problem, the short names are like symbolic links
<Keybuk> lifeless: right, and that doesn't make it show up as lp:ubuntu/upstart - which is the beginning of this conversation :p
<james_w> the importer will create one, or I can do it for you
<lifeless> james_w: are you able to tell the importer that a given branch is a *debian* packaging branch?
<james_w> um, set it as lp:debian/foo
<lifeless> yes
<lifeless> and have imports from debian go into it.
<james_w> you mean from the Debian maintainer's Vcs-Bzr?
<lifeless> huh?
<Keybuk> james_w: so, just to clarify -- the lp:ubuntu/mountall is the importer's version.  If I just push --overwrite my mountall branch over that ... things will be nice and shiny?
<Keybuk> or will there be a datacentre holocaust?
<maco> oh oh i have a james question too! on native software, which do we branch? im thinking update-manger.. lp:update-managr, lp:ubuntu/update-manager, tht long ~ubuntu-core-dev/.../lucid one...which?
<james_w> Keybuk: the importer will tell me that someone did a push --overwrite, then I will check that all is well and tell it to use your branch as they authoritative branch
<james_w> maco: it will be lp:ubuntu/update-manager, and perhaps lp:update-manager, but this conversation is partly about how to make that happen
<james_w> the rule will be use lp:ubuntu/<package> to get the content's of Ubuntu's <package>
<james_w> we're just not quite 100% yet
<james_w> lifeless: I don't understand what you are asking for
<lifeless> I have a package I maintain *in debian*
<lifeless> I want the lp:debian/package branch for that to be my bzr packaging branch.
<Keybuk> you want to be able to commit to debian/bicyclerepairman ?
<Keybuk> (to phrase the question properly?)
<lifeless> And for imports the importer does from debian to go to that branch.
<lifeless> Keybuk: actually python-testtools in this case, but yes.
<james_w> lifeless: as I said, make lp:debian/foo point to that branch
<Keybuk> james_w: maybe he's asking how to do that?
<lifeless> james_w: you said something about the Vcs-BZR control field
<james_w> the mechanics are exactly the same as Keybuk is asking about, I just haven't requested people come forward with suggestions
<lifeless> james_w: which confused me.
<lifeless> james_w: so, for things that we maintain in Debian, which is better ?
<lifeless> and, does the importer know enough about only-synced packages to pull from lp:debian/foo
#ubuntu-devel 2009-12-01
<lifeless> james_w: ^
<james_w> lifeless: "which is better?" <- I'm not sure which choice you are referring to?
<james_w> and yes, it knows how to sync]
<lifeless> ok, cool.
<lifeless> james_w: can you make lp:~lifeless/debian/sid/python-testtools/debian lp:debian/python-testtools then ?
<slangasek> Keybuk: hum, the latest bootchart assigns all the disk usage to init? :)
<Keybuk> slangasek: yeah, something wrong there ;)
<Keybuk> I suspect ureadahead isn't working properly
<Keybuk> and in a very strange way
<Keybuk> oh, I see what I've managed to do
<Keybuk> *no* idea why init is spinning though
<Keybuk> that's very strange
<Keybuk> must be something ptracey
<Keybuk> it's not disk usage
<Keybuk> that bright red means something else
<nixternal> heh
<nixternal> bright red isn't a good color to see in relation to a hard drive
<Keybuk> stopped/uninterruptable I think
<Keybuk> nah, it's bootcharts way of trying to highlight a bad/dead process
<Keybuk> the init job is failing because the process doesn't exist
<nixternal> oh, I was thinking the fail led's on some drive cages
<Keybuk> but I guess isn't trapping out of ptrace properly
<Keybuk> slangasek: I'm going to go find joey hess
<Keybuk> and explain to him that "--" is not meant to be syntactically vital
<Keybuk> who does he think he is?!
<Keybuk> Tom Lord?
<lamont> Nov 30 19:49:48 staypuff pulseaudio[6813]: module-console-kit.c: GetSessionsForUnixUser() call failed: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /lib/dbus-1.0/dbus-daemon-launch-helper: Success
<lamont> what an interesting errno
<lifeless> \o/
<Keybuk> haha
<Keybuk> usually means "where did I stash that errno, I'm sure I had it here somewhere"
<Keybuk> most common mistake
<Keybuk>   if (! working) {
<Keybuk>     free (shit);
<Keybuk>     perror ("argh");
<Keybuk>   }
<Keybuk> since free can, of course, modify errno ;)
<lamont> Keybuk: though nothing is supposed to set errno to zero.
<lamont> other than the app, of course.
<lifeless> lamont: uhm, actually.
<lamont> but hey, you know, that's just errno standards...
<lifeless> There is at least one syscall that does
 * Keybuk can think of quite a few that do :p
<lamont> lifeless: according to the manpage?
<lamont> deviants!
<lamont> mind you, I gave up on believing that bit of the spec some time ago
<lifeless> oh, thats right
<lifeless> readdir is what I was thinking of
<lifeless> and its just nasty
<lifeless> end of dir - return NULL and 'errno is not changed'
<Keybuk> can also be
<Keybuk>   int saved_errno;
<Keybuk>     :
<Keybuk>   if (! working) {
<Keybuk>     return -1;
<Keybuk>   }
<Keybuk> type thing where you forget to save the errno
<lifeless> slangasek: hi
<lifeless> lamont: did you comment on that kernel-img.conf bug?
<lifeless> slangasek: I've been keeping an eye out, and lamont and poolie have also had upgrade-to-karmic, look no hooks in kernel-img.conf symptoms.
<slangasek> lifeless: I don't think lamont ever commented on it; he sent me a private url to a tarball instead, which I've had zero time to go chase down
<lifeless> cool
<lamont> meh
<lamont> which bug again?
<lifeless> 470265
<lamont> slangasek: which file did  you like?
<slangasek> lamont: IIRC I asked for you to send the contents of /var/log/installer, yes?
<lamont> yeah
<lamont> but that has lots of files
<lamont> how much if any sensitiveish data is in there?
<slangasek> depends on how private you consider your partition layout tobe
<lamont>  /proc/cpuinfo: model name       : QEMU Virtual CPU version 0.9.1
<lamont> lol wut?
<slangasek> debconf is smart enough not to leave any passwords there
<lamont> so attach all said files to the bug?
<slangasek> well, a tarball will probably be less painful for all :)
<shtylman> for anyone that was interested in following along: http://www.shtylman.com/archives/154
<lamont> thar.  posted^H^Hing
<lamont> and yeah, tarball is less work all around
<lamont> s/ing/ed/
<slangasek> lamont: ta
<lifeless> lamont: thanks
<lamont> (910.0 KiB, application/x-tar)
<lamont> total win
<slangasek> StevenK: libapache2-mod-auth-pam is trying to sneak yada back into main ;)
<lamont> slangasek: so the ~1build1 version of bind9 should get autosync'ed over with the non ~ version, right?
<slangasek> lamont: I think so, yes
<godane> hey everyone
<godane> i was wondering if you going to put the new squashfs 4.0 with lzma in your kernel
<godane> this may allow you guys to have more space
<slangasek> lamont: well, your broken /etc/kernel-img.conf is not the same as lifeless's
<slangasek> which package was it that included the late fix in karmic for the terminal bell?  seems to have regressed for me in lucid
<lamont> slangasek: woot? :(
<lamont> anyway, bed.
<LucidFox> Is there a cleaner way to get the upstream version in debian/rules with dh 7 other than dpkg-parsechangelog?
<slangasek> lamont: add the hook lines to your file by hand, and be merry :)
<slangasek> 'night
<lamont> slangasek: did that a few days back
<slangasek> ok :)
<dtchen> slangasek: libgnome. bug 77010
<ubottu> Launchpad bug 77010 in alsa-lib "Overuse of system beep without volume control" [Medium,Confirmed] https://launchpad.net/bugs/77010
<slangasek> dtchen: hum, ok; but libgnome is still at the karmic version, so that doesn't seem to be the package to blame in lucid?
<dtchen> slangasek: do your mixer element strings match between 2.6.31 and 2.6.32?
<dtchen> (i.e., from 'amixer')
<slangasek> answering that question seems to require me to reboot, yah?
<dtchen> I'll trawl the commit, one sec.
<dtchen> nope, not kernel-side, no need to reboot
<dtchen> (the beep rework won't land until 2.6.33)
<slangasek> fwiw:
<slangasek> Simple mixer control 'Beep',0
<slangasek>   Capabilities: pvolume pvolume-joined pswitch pswitch-joined
<slangasek>   Playback channels: Mono
<slangasek>   Limits: Playback 0 - 15
<slangasek>   Mono: Playback 0 [0%] [-45.00dB] [off]
<slangasek> dtchen: should I file a new bug about this, and if so, on what package?
<dtchen> slangasek: in Sound Preferences's Sound Effects tab, what is the Alert volume set to, and is Enable window and button sounds ticked?
<slangasek> dtchen: alert volume is maxed out; 'enable window and button sounds' is not checked.
<dtchen> slangasek: are you using metacity or compiz?
<slangasek> dtchen: I've also disabled the noises now by disabling the bell in the gnome-terminal config
<slangasek> metacity
<dtchen> slangasek: looks like pulseaudio, then. bug 301174
<ubottu> Launchpad bug 301174 in pulseaudio "Use proper sound event instead of system beep" [Wishlist,Fix released] https://launchpad.net/bugs/301174
<dtchen> you can try 'pactl unload-module module-x11-bell'
<slangasek> dtchen: no change in behavior
<dtchen> slangasek: err, I misread. That was for non-metacity, anyhow.
<slangasek> k
<dtchen> slangasek: well, I can't see anything at a first glance. The only other package I haven't checked is libcanberra.
<StevenK> slangasek: Bah!
<StevenK> "yada is moving, kill it!"
<ScottK> Only 14 reverse build-depends.
<ScottK> None that I care about either ....
<slangasek> dtchen: huh - I see libcanberra has a new version in lucid, but seems odd that the problem would be there when I'm only seeing problems with the terminal bell
<dtchen> slangasek: no, I'm pretty sure it isn't libcanberra. That was the only part that I hadn't checked when I had responded.
<dtchen> it doesn't seem to involve any changes from linux upward through pulseaudio, however.
<slangasek> wah
<ajmitch> StevenK: I'm surprised you haven't removed, burnt & blacklisted it from ever entering the archive
<slangasek> hmm, there's a thought
<ScottK> Three archive admins makes a quorum, right?
<StevenK> Haha
<mathiaz> cjwatson_: hi - why is john in both supported-misc-servers and supported-sysadmin-common?
<mathiaz> slangasek: is it correct to say that every package that will be on the -server isos are listed in http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.lucid/server-ship?
<LLStarks> hi. i'm noticing that pybootchartgui won't function without bootchart installed.
<LLStarks> why does pybootchart now conflict with bootchart?
<slangasek> mathiaz: dunno, sorry
<dholbach> good morning
<pitti> Good mornin
<slangasek> james_w: lp:debian/laptop-mode-tools is lagged behind the archive by about a month and a half (lp:debian/sid/laptop-mode-tools is, however, current)
 * slangasek waves to Germany
<maco> and *now* all of germany has arrived
 * fagan waves from Ireland
 * pitti dist-upgrades and gets a debconf question "Various snmp software needs extracted MIBs from RFCs and IANA"
<pitti> oh, sure, those MIBs are said to be veery tasty!
<dholbach> mdke: thanks
<Arc> I just want to point out
<Arc> USE="python3" emerge portage
<Arc> Gentoo uses Python 3 now
<Arc> and compiles packages which support Py3 for both Py2 and Py3 at the same time
<cjwatson_> mathiaz`: john> I have no idea, try bzr blame or similar ...
<cjwatson_> mathiaz`: not everything on the server image is in server-ship, no; you have to follow the inheritances in the STRUCTURE file too
<Arc> what are the current plans for Py3 in Ubuntu?
<Arc> Gnome 3 with 10.10 is an obvious hard deadline to getting at least many of the python packages >> py3, but is that just going to be flipping a switch?
<maco> Arc: if you wait til its daytime in our tz, you may get an answer
<pitti> py3 will certainly not be the default in 10.10
<pitti> it's available in the archive, though (for quite a while already)
<maco> does fedora even have py3? one of my friends said he hated ubuntu package naming because of the sonames in library package names....and then later switched from fedora to ubuntu because it meant py2.6 and py3 could be parallel installed
<StevenK> maco: But 2.6 and 3 are version numbers, not sovers :-P
<maco> StevenK: its 5am i dont know the difference
<directhex> StevenK, in python terms, what's the difference?
<lifeless> they are nearly different languges.
<lifeless> something, - probably 80% - of packages haven't updated to support python 3 at all
<maco> lifeless: i think directhex is asking the diff between version and so-version in python
<tkamppeter_> pitti, hi
<pitti> hi tkamppeter
<directhex> maco, my point is, given it's not compiled, the target python version is the closest thing to soname versioning
<maco> directhex: fine by me. as i said, im too tired to figure out a difference
<directhex> maco, have you considered this advanced device w/ a duvet & pillows on it?
<maco> yeah yeah im goin im goin
<tkamppeter> pitti, it is about a build failure of HPLIP: See https://launchpad.net/ubuntu/+source/hplip/3.9.10-2ubuntu1/+build/1371109/+files/buildlog_ubuntu-lucid-i386.hplip_3.9.10-2ubuntu1_FAILEDTOBUILD.txt.gz
<tkamppeter> pitti: I have already uploaded 3.9.10 to Lucid earlier and it built correctly.
<pitti> tkamppeter: this seems to be quite an obvious error, tough
<pitti> "though"
<tkamppeter> pitti, now it is not able any more to run dh_installman. The changes done in the meantime do affect the man pages.
<pitti> apparently the debian/foo.manpages specifies a nonexisting file?
<tkamppeter> pitti, hp-devicesettings.1 is present.
<pitti> tkamppeter: what does the .manpages file specify, and where is it present?
<tkamppeter> It simply says
<tkamppeter> hp-devicesettings.1
<tkamppeter> in one of its lines.
<tkamppeter> It is debian/hplip-gui.manpages, by the way.
<tkamppeter> The man page is present in the root of the source tree.
<tkamppeter> It builds locally for me, but on the buildds it fails.
<tkamppeter> And it seems to build on Debian.
<pitti> tkamppeter: so what does debian/hplip-gui.manpages specify for the manpage in question? what's the full line?
<tkamppeter> The full line is
<tkamppeter> hp-devicesettings.1
<tkamppeter> Nothing more.
<tkamppeter> pitti: ^^
<pitti> tkamppeter: that seems to be correct then; try DH_VERBOSE=1 dh_installman -i to see what it does?
<tkamppeter> Locally it works:
<tkamppeter> DH_VERBOSE=1 dh_installman -i
<tkamppeter> 	install -p -m644 hp-devicesettings.1 debian/hplip-gui/usr/share/man/man1//hp-devicesettings.1
<tkamppeter> ...
<tkamppeter> pitti, if I do rm -rf debian/hplip-gui/usr/share/man
<tkamppeter> and try again, the man pages also get successfully installed. dh_installman does
<tkamppeter> install -d debian/hplip-gui/usr/share/man/man1/
<tkamppeter> to create the needed directory then.
<pitti> tjaalton: do you know whether XBACKLIGHT is supposed to work on intel? I only get "No outputs have backlight property", but I'm also using xorg-edgers
<pitti> tkamppeter: so what happens if you don't remove the dir before?
<btm> pitti: do we need to split the patches in bug 488115 into seperate patches to get the SRU reviewed?
<ubottu> Launchpad bug 488115 in ruby "ruby garbage collector segfaults under certain conditions" [Undecided,In progress] https://launchpad.net/bugs/488115
<pitti> btm: the current patch is about 20 times bigger than it should be
<btm> pitti: hahaha. so yes then.
<pitti> so if we have other bugs reported against ruby, they should be referenced in the changelog as well, so that they can be reviewed/tested individually
<pitti> but seriously, I strongly advise to not do such things in the first place
<pitti> do some careful minimally invasive patches to just fix one or two bugs at a time, get them verified, and to -updates
<pitti> with a patch like this, we can hardly ever say whether it breaks something
<tkamppeter> Is it possible that more recent versions of dh_installman do not create the directories any more?
<cjwatson> tkamppeter: no
<pitti> tkamppeter: as you see, it calls install -d, which creates the dirs
<cjwatson> or at least it's astonishingly unlikely
<tkamppeter> Locally, I get the man pages successfully installed both with and without explicitly creating the directory.
<pitti> tkamppeter: you have to reproduce the failing case with DH_VERBOSE, not a working case
<cjwatson> and in any case that error message is not that the target directory doesn't exist
<cjwatson> the error message says that the source file does not exist
<tkamppeter> pitti, then it seems I will have to load a Lucid pbuilder at first.
<cjwatson> it literally just tried to open the file and it wasn't there
<pitti> tkamppeter: it doesn't look very lucid specific to me, though
<pitti> tkamppeter: is the manpage created during package build, or shipped in the orig.tar.gz?
<StevenK> cjwatson: As per the desktop-lucid-une spec, unr.<release> is moving -- do you think it belongs in ubuntu.<release>, or shall I create netbook.<release>?
<tkamppeter> pitti, the .orig.tar.gz seems to generate it.
<pitti> tkamppeter: s/generate/contain/ ?
<tkamppeter> pitti, perhaps Lucid executes some stuff in another order
<cjwatson> StevenK: I think netbook.<release> is more suitable
<tkamppeter> pitti, they get generated by the install-stamp: rule in debian/rules.
<pitti> tkamppeter: ah, then I suppose that the arch-independent packages are generated first, before the arch-dep install rule
<tkamppeter> The binary-indep: and binary-arch: rules run dh_installman
<tkamppeter> Can I make these two rules dependent on install-stamp: to force the needed order?
<tkamppeter> I think in general these rules should only get executed when the installation is completed.
<pitti> at first sight this seems to make sense
<tkamppeter> pitti, it could even make sense to be this way by default.
<pitti> "by default"?
<cjwatson> StevenK: or maybe even ubuntu-netbook.<release>?
<tkamppeter> Are these db_ helpers not generally supposed to be run after "make install"?
<pitti> tkamppeter: as long as people insist on writing the same (buggy?) debian/rules manually over and over (i. e. not using dh7 or cdbs), there is no "default" :)
<cjwatson> tkamppeter: install-stamp is not a required target in debian/rules. If you want inter-target dependencies, you *have* to specify them yourself
<cjwatson> especially for targets that are specific to your debian/rules file
<pitti> tkamppeter: some might well work before, but in general most of them make more sense after the install target, yet
<cjwatson> even 'install' is not a required target, come to that
<pitti> tkamppeter: but install-stamp is just a convention, not something that buildds even understand (or dpkg-buildpackage)
<tkamppeter> pitti, cjwatson, broken debian/rules from Debian maintainer which simply worked by accident for all the time ...
<pitti> seems like it
<tkamppeter> For me it looks like that the quickest solution is to force order by this dependency, the best solution would that the Debian maintainer redesigns the debian/rules file.
<cjwatson> forcing the order is entirely correct and not a workaround at all
<cjwatson> there's nothing intrinsically broken about a rules file written in that way, when the inter-target dependencies are correct
<cjwatson> the smarter helpers tend to centralise things such that we can fix bugs in a single place, but it's not actually wrong not to use them :)
<btm> pitti: uploaded new debdiff to bug 488115 that contains two small patches to fix segv bugs with corresponding lp bugs.
<ubottu> Launchpad bug 488115 in ruby "ruby garbage collector segfaults under certain conditions" [Undecided,In progress] https://launchpad.net/bugs/488115
<ogra> The following packages have unmet dependencies:
<ogra>   lightsoff: Depends: seed but it is not installable
<ogra>   swell-foop: Depends: seed but it is not installable
 * ogra scratches head
 * ogra wonders what in ubuntu-desktop pulls in webkit stuff
<davmor2> ogra: software center?
<ogra> oh
<davmor2> ogra: only guessing
<davmor2> ogra: ubiquity too
<ogra> oooh, right, the new slideshow stuff
<ogra> thanks, i didnt think of that
<cjwatson> interestingly ubiquity-frontend-gtk doesn't actually depend on python-webkit or anything ...
<cjwatson> ev: is that an oversight?
<ev> nope
<ev> because ubiquity can function just fine without the slideshow
<cjwatson> hmm. just feels odd that there's no mention of it in the control file. Maybe a Suggests or something?
<cjwatson> or even Recommends given that we want the slideshow in Ubuntu
<cjwatson> the odd thing I think is that the slideshow essentially only works by accident because python-webkit is in desktop
<cjwatson> which feels odd to me somehow, although I don't know the best fix
<ev> well, we could just add python-webkit to the seeds as well, but I'm equally fine with a Suggests or Recommends.
<ev> I just wanted to make it as easy as possible for derivatives that didn't want the slideshow
<lamont> dear firefox.  why is it that every morning when I get on my computer, your window is dead-n-gone _AGAIN_??
<lamont> no core file, no nothing.
<StevenK> I'd suggest the OOM killer, but it's somewhat suspcious it's always firefox
<tjaalton> pitti: so running 'xbacklight -get' fails? works for me with the karmic versions
<cjwatson> could somebody in the desktop team deal with MIRing 'seed', please? reasonably urgent since CD builds are failing due to this
<tjaalton> pitti: of course -set works too
<tkamppeter> pitti, about the HPLIP I have found the cuase of the problem. HPLIP is running itself to generate its man pages and this is done by the debian/rules script, instead of letting "make install" do it). I think I will remove that unneeded part.
<pitti> tjaalton: right, that gives said error message
<pitti> tkamppeter: ah, good
<pitti> tjaalton: if it's generally supposed to work on intel, then I just blame the xorg-edgers packages :)
<tjaalton> pitti: yep :)
<pitti> cjwatson: it's only required by the "lightsoff" package, AFAICS, and we don't even intend to install that by default any more; thanks for pointing out, on my list now
<cjwatson> pitti: lightsoff and swell-foop
<mr_pouit> w/w 20
<mr_pouit> grr
<goldins> is there a howto recompile packages the dpkg way? I know you start with apt-get source [package]
<cjwatson> debuild
<cjwatson> (in the directory that apt-get source creates)
<cjwatson> see manual pages etc. for more details
<goldins> thanks!
<goldins> the debian administration guide for this thing tells an outright lie
<goldins> "of course we did miss out any editing of the package to make it build differently, but if you know already you need to rebuild a package to change its options, or bahaviour, you will know how to do that!" -- I don't want to edit the package, just change the options passed to the configure script. How do I do that?
<bdrung_> mdeslaur: you fixed the security issue of libgd2 in the stable version, but it is not fixed in lucid.
<cjwatson> goldins: edit debian/rules
<cjwatson> goldins: you *need* to edit the package, even if that isn't what you *want* to do :-)
<goldins> cjwatson: I see! thanks again
<mdeslaur> bdrung_: correct...we track issues that are not fixed in lucid. If the package doesn't get synced or merged with debian, we'll release an update to it long before lucid releases.
<bdrung_> mdeslaur: thank for the info.
 * ttx painfully tries to get a bzr branch from LP... it's... slow... today...
<cjwatson> pitti,sabdfl: TB meeting?
<cjwatson> haven't seen Keybuk around
<sabdfl> cjwatson: thanks, incoming
<h4writer> MacSlow, ping
<MacSlow> h4writer, pong
<h4writer> hi MacSlow, it's about bug #489414, if you think it is easier to debug over chat, go ahead...
<ubottu> Launchpad bug 489414 in notify-osd "Wrong icon gets used" [Undecided,Incomplete] https://launchpad.net/bugs/489414
<MacSlow> h4writer, hm... maybe somehow your from-source installs messed up the system-wide icon-cache
<h4writer> So removing the cache would solve it?
<MacSlow> h4writer, hm... awn installs (or used to install) icons in /usr/share/hicolor maybe those override everything else
<h4writer> MacSlow, I have no /usr/share/hicolor folder
<MacSlow> h4writer, awn used to have a plugin replacing notification-daemon... maybe that's "getting in the way"
<MacSlow> h4writer, but that would not explain why you still see notificatino-bubbles rendered by notify-osd
<h4writer> I have had notification-deamon, but I removed it
<h4writer> *had notification-deamon in jaunty, upgraded and removed it in karmic
<MacSlow> h4writer, http://launchpadlibrarian.net/36182432/Schermafdruk.png clearly is rendered by notify-osd
<h4writer> MacSlow, yeah it is definitly notify-osd ;-)
<MacSlow> h4writer, do you know malept or moonbeam in #awn?
<h4writer> yes
<Arc> pitti: so what is the plan to support both py2 and py3 versions of packages until then?  or is Ubuntu basically dying for Python developers overall?
<Arc> Gentoo did this through slotting; each major.minor python version gets its own slot now, so even if you have py2.5 2.6 and 3.1 packages which support all will be compiled and installed for all
<ScottK> Arc: Debian and Ubuntu share a system for supporting multiple Python interpreters.
<Arc> ScottK: and that is?
<ScottK> Currently a lot of stuff doesn't particularly work on Python 3, so we don't see a great rush.
<Arc> is it not generally understood that developers use Ubuntu too?
<ScottK> Certainly.
<ScottK> That's why we ship python-3.1
<Arc> but do you, for example, ship cherrypy for py3?
<Arc> or sqlalchemy, or even wsgi
<ScottK> Nope.
<kklimonda> Arc: there is no stable release of sqlalchemy that supports python 3.x
<kklimonda> Arc: and that's similar for most libraries and applications
<ScottK> I'd expect after Lucid there will be a lot more of a push to support Python 3.
<Arc> kklimonda: im using sqlalchemy on py3 right now.
<ebroder> Arc: Then you're using a prerelease version
<ebroder> 0.6 isn't the stable release yet
<Arc> so? it will be by the time my software is ready to release
<Arc> developers need to target tomorrow, not today, or the entire community plays a continual game of catch-up
<Arc> Ubuntu doesn't support packages for tomorrow, or today, but yesterday.  there isn't even an option to install new versions of libraries
<Arc> I'm frustrated that at the end of 2009 I still have to maintain my Gentoo workstations and on my colocated servers because Ubuntu fails to meet my needs as a developer
<ScottK> Arc: This channel is for development of Ubuntu, not complaing about it.  I think you probably want #ubuntu-offtopic.
<Arc> I was hoping that this may be useful feedback, but I guess it'll be ignored
<ebroder> There was a valid point in there - do we have an answer yet for dealing with python 3 packages? Most of the things that have "Python 3 compatibility" just work after you run them through 2to3. Separate source packages?
<ScottK> It's not that I don't understand your problem (or care) but that there's a lot of extra work involved in supporting what you ask for and we really don't have the resources.
<cjwatson> he's left
<ScottK> ebroder: We have other, more pressing, problems in the Debian/Ubuntu Python stack.
<ScottK> Ah.  Thanks.
<cjwatson> I believe we have a general expectation of python3-* binary packages
<cjwatson> and separate source packages if they need more than 2to3
 * ebroder nods
<kklimonda> ScottK: btw, how can we (and by we I mean 'me') help with Python stack if you need more resources?
<ScottK> kklimonda: Well at the moment the blockers are primarily not resource driven.  Once we get Python 2.6 into Debian and work on a new Python policy moving forward, then I think there will be more to do.
<ScottK> kklimonda: I was more responding to his complaints about lack of development versions of libraries than Python specifically.
<mathiaz> cjwatson: hi - I'm looking at the ubuntu-server package set in lucid
<mathiaz> cjwatson: libgtop2 is part of it - why?
<mathiaz> cjwatson: seems to be gnome related
<cjwatson> something depends or build-depends on it. check germinate output
<mathiaz> cjwatson: and what's the difference between the ubuntu.lucid and platform.lucid seeds?
<cjwatson> the package sets are unlikely to be tightly closed in the way you expect
<cjwatson> platform.lucid is stuff that's shared between flavours
<mathiaz> cjwatson: is the former only used for iso/image creation?
<cjwatson> err - no?
<mathiaz> cjwatson: ok
<cjwatson> mathiaz: libapache2-mod-perl2 build-depends on libgtop2-dev
<mathiaz> cjwatson: how did you find that information?
<cjwatson> I grepped germinate output
<cjwatson> cjwatson@rookery:/home/ubuntu-archive/public_html/germinate-output/ubuntu.lucid$ grep ^libgtop2 *
<cjwatson> or you can run germinate yourself locally
<mathiaz> cjwatson: great - thanks!
<mathiaz> jdstrand: hi!
<mathiaz> jdstrand: where is the list of server supported files for hardy?
<superm1> mathiaz, moving lilo to universe might have implications for installer, and it's rdepends list tons of kernel packages
<mathiaz> superm1: right - I think that point was mentioned during the UDS discussion - the notes are unclear - cjwatson may have said it was ok though.
<mathiaz> superm1: if you have other concerns for lilo don't hesitate to add it to the wiki page
<superm1> mathiaz, i was gonna add those comments last night (if they weren't there), but couldnt get to the wiki page.  nothing else comes to mind though
<cjwatson> I'm unsure about lilo
<cjwatson> if we remove it from main, that will indeed basically take out that installer component as well, which is currently an option
<cjwatson> that may be OK, we just need to be aware it's a pretty firm commitment!
<jdstrand> mathiaz: hi! it has not been generated yet
<jdstrand> mathiaz: ie we have this http://people.canonical.com/~ubuntu-security/dapper-lts-server-supported.txt, but not one for hardy yet
<mathiaz> jdstrand: ok - has the list been generated by hand?
<jdstrand> mathiaz: I think it is mostly automated. see seed-report in UCT
<mathiaz> jdstrand: ok - thanks.
<kirkland> mvo_: howdy, around?
<kirkland> mvo_: i'm having a few issues merging/building eucalyptus for Lucid, looks like problems with librampart
<kirkland> mvo_: i noticed that you're the maintainer ;-)
<kirkland> mvo_: hmm, well, you're listed as the maintainer, but have no changelog entries; perhaps I'm mistaken :-)
<kees> mathiaz: the dapper supported list was reviewed by hand, yes.  it required a lot of seed splitting
<kees> mathiaz: hardy will likely require the same attention.
<kees> (as will lucid, etc)
<mvo_> kirkland: I helped soren with rampart, but he took over then
<kirkland> mvo_: okay, thanks!
<kirkland> mvo_: i'm having a build issue with eucalyptus that I *think* I can solve with a symbol|shlib file in rampart
<kirkland> mvo_: i was looking for someone to confirm this with
<maxb> james_w: Could I get an UDD nudge for missing import subversion 1.6.6dfsg-2 ?
<Laney> maxb: file bugs: lp/udd
<james_w> hi maxb.
<james_w> sorry for the delay, done now
<maxb> Thanks. Is there anything I can do to assist in figuring out why it happens?
<maxb> And for that matter, is the importer code open-source?
<jono> didrocks, are you planning on making a panel applet Quickly template?
<slangasek> kirkland: what exactly is the build issue?
<kirkland> slangasek: http://paste.ubuntu.com/332545/
<kirkland> slangasek: any help would be *much* appreciated
<kirkland> slangasek: I've spent my entire day so far on this
<slangasek> interesting error; one sec
<james_w> maxb: most of the logic is in bzr-builddeb, the stuff that polls LP is a couple of hacky scripts
<didrocks> jono: not sure, as the panel will be deprecated in GNOME3, I'm waiting for the replacement model
<kirkland> slangasek: thanks for looking; standing by ....
<slangasek> kirkland: the issue is that the library is installed in /usr/lib/axis2/lib instead of /usr/lib; this a) is probably an FHS violation, b) requires passing a -l option to dh_shlibdeps if you *really* want to do this (and assuming the rpath is correctly set) - but I suggest fixing a) instead
<slangasek> all shared libraries in Ubuntu are supposed to be installed to /usr/lib, and that appears to apply here
<jono> didrocks, the panel is in a state of flux, but indicators are not going away though
<kirkland> slangasek: cool, thanks
<kirkland> soren: any idea why you chose to install rampart to /usr/lib/axis2/lib ?
<slangasek> kirkland: oh, the dpkg error even tells you that the binary has no rpath set - so yeah, as built this would never work anyway
<didrocks> jono: I'll log a bug to remind me to take a look at that. But gedit plugin is on a higher priority for 0.4 (next January) :)
<slangasek> (setting rpath might fix the shlibdeps problem; moving the library to /usr/lib is still preferred)
<jono> didrocks, np :)
<jono> was just curious :)
 * didrocks logs a bug as a reminder :)
<kirkland> slangasek: okay, i'll fix up rampart, and pass the debdiff by you for verification
<kirkland> slangasek: i haven't done too much library work
<slangasek> kirkland: the key bit is probably just setting --prefix=/usr instead of --prefix=/usr/lib/axis2 in debian/rules; there's probably some other cleanup to do of various extra symlinks, though
<kirkland> slangasek: okay, i'm looking into that now
<slangasek> lrwxrwxrwx root/root         0 2009-10-12 10:57 ./usr/lib/axis2/include/axis2-1.6.0/rampart_token_processor.h -> ../../../../include/rampart-1.3.0/rampart_token_processor.h:  do not want
<kirkland> slangasek: i was wondering if a set of symlinks in /usr/lib/ might suffice?
<slangasek> oh damn; we really need that link farm, because the include option we use is -I/usr/lib/axis2/include/axis2-1.6.0
<kirkland> slangasek:         cd debian/$(cdbs_curpkg)/usr/lib ; for x in axis2/lib/*.so*; do ln -s $$x; done
<kirkland> slangasek: something like that
<slangasek> the /usr/include/axis2-1.6.0 looks redundant then, however
<slangasek> kirkland: mumble; that part needs fixed up to make sure we really get our links in /usr/lib
<slangasek> oh, that's what you're doing, so... right
<slangasek> well, no
<slangasek> the current linkage is only because of the modules/ subdir
<slangasek> if you set the prefix right, the main lib should land in /usr/lib automatically, and the modules fixup just needs adjusted to not include axis2/lib in the path
<slangasek> oh, that will install to /usr/modules, hah
<slangasek> yeah, so s/ln/mv/ :P
<kirkland> slangasek: fun
<slangasek> kirkland: --prefix=/usr/lib/axis2 --libdir=/usr/lib, I think
<slangasek> (and shame on upstream for this build system)
 * kirkland tries
<kirkland> slangasek: um ... are you sure about that?
<slangasek> nope
<kirkland> slangasek: should it be: --prefix=/usr/lib --libdir=/usr/lib ?
<kirkland> oh, hmm
<slangasek> no, I'm sure it's not that :)
<kirkland> slangasek: i see now
<kirkland> slangasek: yeah, my bad
<kirkland> slangasek: okay, building/testing
<slangasek> kirkland: doesn't work, because the upstream build doesn't use --libdir as God intended
<kirkland> slangasek: my build agrees with you
<kirkland> slangasek: arg... and this package does not debuild repeatedly cleanlyh
<kirkland> what a mess
<slangasek> yep
<slangasek> prglibdir=$(prefix)/lib
<slangasek> DIE
<slangasek> kirkland: well, quick-and-dirty will be to just move the files around in the debian/rules target
<slangasek> librampart.so* to /usr/lib; libmod_rampart.so* symlinked to /usr/lib from the axis2 dir (because there's a modules.xml used by axis2 which I guess needs to be in the same directory as the files)
<kirkland> slangasek: why mv and not ln ?
<slangasek> because there's no reason for librampart to be in a subdir of /usr/lib at all
<deryck> jcastro, ping
<slangasek> the only reason to leave libmod_rampart in a subdir is the modules.xml that references it
<slangasek> module.xml, rather
<kirkland> slangasek: gotcha
<kirkland> slangasek: okay, well i had build an ln'd one in the meantime; i've built/installed that; testing the eucalyptus build now
<kirkland> slangasek: if that works, i'll go back in and mv those .so's around
<jcastro> deryck: pong
<mathiaz> cjwatson: in the germinate output, what's the difference between all and all+extra?
<slangasek> interesting that the utility lib provides no .so link at all
<kirkland> slangasek: \o/  it built!!!
<kirkland> slangasek: that's the first time this build has completed for me in ~1 week!!!
<jcastro> slangasek: I think I just ran into the japanese symbol for death.
 * kirkland hugs slangasek 
<jcastro> slangasek: fscking it now
<slangasek> jcastro: heh
<slangasek> kirkland: eep
<kirkland> slangasek: http://paste.ubuntu.com/332560/
<kirkland> slangasek: that was my quick/dirty fix
<slangasek> kirkland: minor buglet I just noticed, btw: linking to -lmod_rampart is actually the wrong thing to do, we should be linking against librampart.so instead... :)
<kirkland> slangasek: now i'll try to clean it up a bit
<slangasek> the symbols it uses are provided by the utility lib - the only reason this links against -lmod_rampart is that this is the only .so available (!)
<slangasek> so if rampart were fixed to provide librampart.so, and eucalyptus were then fixed to use -lrampart, all the libmod_rampart symlinking could be tossed
<kirkland> slangasek: hrm, okay ...  there seems to be too many options on the table for me right now
<slangasek> kirkland: understood - don't let me get in the way of your progress
<kirkland> slangasek: i am going to have to modify both rampart and eucalyptus at this point
<kirkland> slangasek: if you have a preferred methodology, let me know which it is ;-)
<kirkland> slangasek: but i want something that can get my eucalyptus build going today-ish
<james_w> maxb: failure information is now available at http://package-import.ubuntu.com/failures/.bzr/failures/
<maxb> excellent
<james_w> maxb: I had to work out how to bypass loggerhead so that I could make it public
<james_w> sorry for not doing that early
<slangasek> kirkland: well, the right thing to do here really is to have librampart-dev provide /usr/lib/librampart.so, *not* libmod_rampart.so, and have eucalyptus link to -lrampart
<slangasek> kirkland: but that doesn't need to be addressed right now
<james_w> I'm going to file an RT now to take down loggerhead as we don't need it and to just serve the logs directly
<kirkland> slangasek: okay
<slangasek> kirkland: doing it the way it's done now does incur some overhead because eucalyptus never uses anything that's in mod_rampart itself... but I suppose the overhead is negligible, all things considered ;)
<soren> kirkland: Yes.
<soren> kirkland: Give me a second, it's going to take me a bit to phrase this tactfully.
<kirkland> slangasek: gotcha
<soren> kirkland: Axis2/C and Rampart/C are both rather new to the notion of being installed in a manner roughly corresponding to the FHS. Some might even say that they're not quite there yet.
<soren> kirkland: I may or may not be one of the people of that opinion.
<slangasek> soren: right, we covered that in the interim
<slangasek> 11:31 < slangasek> prglibdir=$(prefix)/lib
<slangasek> 11:31 < slangasek> DIE
<slangasek> :-)
<kirkland> heh
<soren> Well :)
<soren> Right, and the point is that none of the projects that use axis2 have the faintest clue where to find things if we put them were people who are used to dealing with sensible libraries expect to find things.
<soren> Namely with libraries in /usr/lib or /usr/lib/axis2 and headers in /usr/include/axis2 or whatnot..
<kirkland> slangasek: I *think* this covers your first suggestions -> http://paste.ubuntu.com/332570/
<kirkland> slangasek: http://paste.ubuntu.com/332571/
<soren> So in order to adhere as much as possible to the FHS while doing as little work as possible and not confusing the heck out of every project depending on them, I opted for the slightly odd ball directory layout, sprinkled with a metric ton of symlinks.
<soren> The end result is a train wreck, but the starting point was a natural disaster.
<kirkland> slangasek: hmm, based on what soren is saying now, i'm wondering if ln might be preferred over mv
<maxb> james_w: How do you configure loggerhead to do that? (Hierarchical display of a big directory tree of branches)  I tried to make it do that for me, and failed!
<slangasek> kirkland: since nothing else depends on librampart.so (because it can't), mv won't hurt any other projects, and will be beneficial in the long run
<kirkland> slangasek: ack; done
<kirkland> slangasek: i'll be uploading shortly ;-)
<slangasek> cheers
<kirkland> slangasek: anything else lowhanging with this mess that I should clean up while I'm in here?
<james_w> maxb: loggerhead has a serve-branches script that I think does it
<slangasek> kirkland: hmm, /usr/lib/libmod_rampart.so.0 -> axis2/lib/libmod_rampart.so.0 - not axis2/modules/rampart/libmod_rampart.so.0?
<maxb> james_w: And should I be concerned that there isn't a 'subversion' failures file?
<james_w> maxb: well, subversion has caught up now, so normally that would be correct
<slangasek> AFAIK, axis2/lib/libmod_rampart.so.0 was itself created by the debian/rules, and we can get rid of that indirection
<james_w> maxb: it does mean that I'm not sure why the upload was missed
<kirkland> slangasek: true
<james_w> maxb: I don't suppose LP backdates the publishing record creation date to the time of the Debian upload when it is imported?
<maxb> That sounds entirely plausible
<james_w> that would certainly explain it
<slangasek> kirkland: here's what I would do: http://paste.ubuntu.com/332577/
<maxb> Interesting that there's a zero-length failures file for python-defaults, but no branches in launchpad for it
<kirkland> slangasek: hmm, why the for loop over a single file?
<soren> kirkland, slangasek: The current state of things is the result of a long, long night of trial-and-error. If you guys can get it to be sensible and still have stuff build *and* run against it, more power to you :)
<slangasek> kirkland: ask soren, that's just me editing what was already there :)
<james_w> maxb: the zero length files are holders
<soren> slangasek: Sorry, what?
<slangasek> soren: the "for x in librampart.so" at http://paste.ubuntu.com/332577/
<james_w> maxb: when codehosting ran out of space I was asked to pause the imports, and haven't asked it to try all those yet
<maxb> ah, ok.
<james_w> maxb: most of those are ones that we may want to use older branches for, but I think the best way to deal with it might be to import them all, and then overwrite the ones that we wish to do that for
<soren> slangasek: Err.. Good question. I think perhaps in an earlier version, it iterated over more than just the one file, and when I removed the other(s), I didn't notice there was just the one left, and just left the loop there.
<soren> slangasek: That's my best guess. I have no actual recollection.
<soren> Of anything. Ever.
<slangasek> soren: fair 'nuff, doesn't really matter :)
<slangasek> I have now looked at this package name long enough that it has decomposed in my brain into "the library containing parts of rams"
<kirkland> slangasek: many thanks for your help
<slangasek> n/p
<kirkland> slangasek: i had not made much progress until our conversation
<cjwatson> mathiaz: extra is "stuff that came from the same source package as something that's seeded, but isn't seeded itself"
<mathiaz> cjwatson: could all be considered a good list of all packages in main, with the (multiple) reasons why they're in main?
<pitti> Keybuk: I uploaded your udev today, and CK; works fine
<Keybuk> pitti: I saw, great :D
<pitti> hah! DeviceKit-disks is obsolete!
<ebroder> ...that didn't take long
<Keybuk> there were more input_id changes in GIT head since I last pulled, do you want those uploaded too? :0
<cjwatson> mathiaz: I'm afraid not
<pitti> Keybuk: would be nice, yes
<Keybuk> pitti: oh, that reminds me, I noticed last night that you removed the "and started hal" from gdm.conf ... that was a bad idea :p
<cjwatson> mathiaz: "all" is all the packages seeded *in the flavour of Ubuntu you're looking at*
<slangasek> pitti: huh, obsoleted by what?
<pitti> Keybuk: eww, oops; I better put that back for now
<cjwatson> mathiaz: but main = Ubuntu + Kubuntu + Edubuntu + Xubuntu + ...
<mathiaz> cjwatson: right.
<Keybuk> pitti: X seems to spin if it doesn't have it though :)
<Keybuk> pitti: so don't worry about putting it back
<pitti> slangasek: just renamed; but I was curious how people would jump at it :)
<cjwatson> (actually not all the specific examples I listed but you get the idea)
<Keybuk> I was just surprised :D
<slangasek> pitti: heh
<mathiaz> cjwatson: that would be enough though - I'm trying to get a list of package in main "related" to the server team
<Keybuk> slangasek: iz now udisks
<pitti> slangasek: since DeviceKit is no more, it's now renamed to "udisks"
<slangasek> buh?  DeviceKit is no more?
<slangasek> crack fiends, the lot of them
<Keybuk> DeviceKit was stillborn
<pitti> slangasek: it only existed for a couple of weeks
<cjwatson> mathiaz: it's actually Ubuntu + Kubuntu + Edubuntu + UNR, right now
<ebroder> So it's all udev now?
<Keybuk> I think the first release was the week before LF Collaboration Summit last year
<slangasek> the crucial couple of weeks that led us to shipping it in 9.10? :)
<Keybuk> and at LF Collaboration Summit we had that udev security bug where you could send messages over netlink to it
<Keybuk> and we went "ooh, didn't know you could *do* that"
<Keybuk> fixed the security bug
<Keybuk> then actually extended udev to *use* that functionality
<Keybuk> then we didn't need the DeviceKit daemon anymore
<cjwatson> mathiaz: sure, that's enough. Bear in mind that it only gives you the first reason though. If you want everything, look in rdepends/ in the output of a full germinate run
<slangasek> so devicekit-power is also gone?
<Keybuk> slangasek: we didn't ship DeviceKit in 9.10 I don't think
<mathiaz> cjwatson: oh - cool.
<Keybuk> maybe 9.04 briefly
<cjwatson> slangasek: we shipped DeviceKit-* in 9.10, but not DeviceKit itself
<Keybuk> slangasek: devicekit-power will be upower I think
<slangasek> oh, you mean the daemon specifically, ok
<Keybuk> the design is quite nice now
<superm1> seriously devicekit is no more?
<Keybuk> the kernel deals directly with hardware, and sends update events via uevents to udev
<Keybuk> udev does basic processing of them and maintains a db of extra information
<Keybuk> and sends further update events out back over netlink to things like udisks, upower, PulseAudio, NetworkManager, Upstart, etc.
 * ajmitch can't keep up with all these moving pieces
<slangasek> things are converging on an architecture
<slangasek> previously, they weren't
<slangasek> this is an improvement :)
<sebner> slangasek: hi! Can you tell me the percentage of  main <-> universe packages? My grades at university are thanking ;D
<superm1> but this also means an app that needs to work on say 3 releases needs to know how to talk over dbus to udisks, and then if they want karmic support devicekit-disks, and if they want jaunty support HAL
<superm1>  /shrug
<Keybuk> superm1: so don't do that then :)
<Keybuk> write your app to support lucid
<Keybuk> which is an LTS
<slangasek> sebner: zgrep -c ^Package: /var/lib/apt/lists/*lucid_*Packages ?
<sebner> slangasek: not on ubuntu right now :(
<sebner> hi pochu :)
<slangasek> sebner: 6707 binary packages in main (on amd64), 22277 in universe
<pochu> sebner: yo :)
<ion> keybuk: Re: <http://people.canonical.com/~scott/daily-bootcharts/>, it could be neat to have a system that upgrades the system in small parts (e.g. dividing the upgrade at the points where apt would do separate dpkg invocations) and measures a new entry for that list after each part, pointing out which packages were upgraded. So, instead of daily bootcharts, weâd have a bootchart roughly for each upgradable upload.
<Keybuk> ion: whuh?
<Keybuk> how would that help anything?
<slangasek> he wants 'bootchart blame' :)
<sebner> slangasek: cool thanks!
<kirkland> slangasek: wow, 1/4 are in main ...  i had no idea that percentage was so high
<slangasek> kirkland: I blame UEC ;)
 * kirkland ducks, covers
<Keybuk> it's generally pretty obvious what's to blame for any major change
<kirkland> slangasek: i suppose i did serve that one up to you, underhand
<kirkland> Is there anyone around with buildd super powers might be able to increase the priority of https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1374891 ?
<pitti> kirkland: nudged
<kirkland> pitti: thanks martin!
<kirkland> arg
<dipponaught[away> im trying to create a debdiff of the linux-image-2.6.32-6-generic sources (directions from wiki://PackagingGuide/Recipes/Debdiff) but debuild -S overwrites the original stuff. how do i increment my version from linux_2.6.32-6.8 to linux_2.6.32-6.9?
<Keybuk> dch -i
<Keybuk> though it's harder with the kernel stuff ;)
<Keybuk> think you have to edit debian.master/changelog instead
<Keybuk> and if you increment the version, you'll run into the ABI CHECKER OF DOOM
<dipponaught[away> yeah i did the dch -i but no avail... whats that?
<Keybuk> I suggest reading through the kernel packaging knowledge base
<dipponaught[away> and on the same note is there a debian/ubuntu prefered way of enabling the boot menu? (beside editing grub.conf or whatver)
<dipponaught[away> ok will do
<dipponaught[away> ugh. i assume ur referring to the wiki page of the kernelteam?
<Keybuk> yes
<dipponaught[away> ugh. tmi.
<dipponaught[away> the wiki isnt really helping. no mention of debuild anywhere. the closest I can find is "submit patches to Linus"...
<dipponaught[away> Iim pouring over FAQ right now)
<dipponaught[away> ok, so does changing the debian/changelog change the version thats built?
<dipponaught[away> heh, Bug #444683 : Document need for "-c debian.master/changelog" arguments to dch -i.
<dipponaught[away> Keybuk: thanks
<ubottu> Launchpad bug 444683 in linux "Document need for "-c debian.master/changelog" arguments to dch -i." [Undecided,New] https://launchpad.net/bugs/444683
<kirkland> cjwatson: hrm, ubuntu-server dailies seem to be missing
<jdstrand> soren: I'm close to having the libvirt merge done
<jdstrand> soren: fyi-- with a small change to the 9007* patch, I am able to get the test suite to work as well
<soren> jdstrand: On the buildd's?
<soren> jdstrand: The eventtest unit test only fails on the buildd's.
<soren> Well..
<soren> Only on systems with a kernel with a HZ=100 setting.
<jdstrand> soren: I was just looking at that-- I didn't fix it
<jdstrand> soren: I had a different failure cause daemon-conf dies if the unix socket is in too deep of a directory
<soren> jdstrand: Yeah, don't worry about it.
<soren> jdstrand: Oh.
<soren> jdstrand: Sounds like fun.
<jdstrand> soren: well, I worked around it in the test
<soren> jdstrand: I'll take a stab at the eventtest thing tomorrow.
<jdstrand> soren: I report the failure, but don't 'fail=1'
<jdstrand> soren: I need to test the merge, which I hope to do today/first thing tomorrow
<jdstrand> soren: you'll see it wasn't the most straightforward merge when you see the changelog ;)
<cjwatson> kirkland: have you checked the logs?
<jdstrand> soren: it took a bit of time
<kirkland> cjwatson: nope ...
 * kirkland does that now
<cjwatson> kirkland:
<cjwatson> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/lucid/
<kirkland> cjwatson: thanks
<cjwatson> Missing debootstrap-required nih-dbus-tool
<cjwatson> Missing debootstrap-required ureadahead
<cjwatson> which amounts to "priority: required and the seeds aren't in sync, pls fix"
<cjwatson> two possible fixes depending on desired state
<pitti> meh, who broke ubuntu-dev-tools -- NameError: name 'EDGE_SERVICE_ROOT' is not defined
<cjwatson> kirkland: I'll look tomorrow if it's still breaking; too late for me now
<kirkland> cjwatson: sure thing, no worries
<kirkland> cjwatson: it's not urgent for me
<kirkland> cjwatson: just making sure someone was aware
 * soren calls it a day
 * Daviey tends to be more accurate and call it a "Tuesday"
<jdstrand> soren: fyi-- I'm going to add a patch to disable eventtest for now
<jdstrand> soren: that will get it building and into the archive while you work on the proper fix
<jdstrand> soren: I'll ping you when I upload the merge
<jdstrand> soren: it's looking more like first thing tomorrow for me...
<tjaalton> lifeless: you created la_AU, but upstream refused to include it. now our libx11 has some sort of support for it, and it's never going upstream (or debian). Shouldn't the patch be dropped from libx11 for lucid?
<tjaalton> (upstream glibc refused it..)
<lifeless> tjaalton: upstream are bigoted :)
<lifeless> we carry other patches they reject
<tjaalton> but our glibc doesn't have that either?
 * slangasek creates a separate la_US translation team to put all the 'z's back where they belong and take out the extra 'u's
<lifeless> ?
<tjaalton> at least the changelog doesn't mention it
<lifeless> tjaalton: try the locale, it works :)
<lifeless> though the x11 support has glitched, I need to fix it.
<tjaalton> so we are going to carry it forever?
<lifeless> that was my understanding when pitti landed it. Its not the first such thing.
<tjaalton> well it's one of the (very) few X libs that can't be synced as of now
<lifeless> you could push it to debian, if thats what you mean.
<tjaalton> they won't accept it
<tjaalton> we discussed it briefly
<lifeless> I'm on a call at the moment, I can't give you proper attention now, sorry.
<tjaalton> ok, np
<tjaalton> I should be in bed anyway..
<slangasek> Keybuk: seen that pybootchartgui and bootchart aren't co-installable?  (pybootchartgui Provides: bootchart-java, bootchart Breaks: bootchart-java
<slangasek> )
<garrythefish> a bunch of lesbos banned me from #ubuntu-women. can't believe it
<slangasek> garrythefish: I suggest you apologize for the preceding remark if you don't want to find yourself banned from here as well
<garrythefish> eeh, what now?
<slangasek> if you think it's appropriate to denigrate members of the Ubuntu community as "a bunch of lesbos", I have an inkling of why they would have banned you
<ion> slangasek: Itâs just a troll. Letâs not indulge it. :-)
<garrythefish> your mother is a troll
<slangasek> !ops garrythefish
<garrythefish> ops?
<slangasek> bot fail
<garrythefish> what's that? a type of garlic?
<slangasek> !ops | garrythefish
<ubottu> garrythefish: Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<garrythefish> ion: your mom screwed your dad to death before your birth
<garrythefish> hmm, i can confirm they are lesbos. want evidence?
<kklimonda> it looks like the number of ops have decreased lately?
<garrythefish> nope, its just a drinking holiday :P
<slangasek> ion: labelling everyone who behaves poorly on IRC a troll is necessarily polarizing; I think it's far preferable to express expectations clearly on the off chance that the offender is capable of modes other than "antisocial idiot"
<slangasek> garrythefish: no, because the sexual orientation of anyone who banned you is irrelevant to this discussion, and whether or not you happen to be correct, it's inappropriate for you to make it a point of discussion
<garrythefish> is it?
<garrythefish> if you show me that rule in written form, i'll be convinced
<garrythefish> maybe its one of the reasons they behave like that
<Pici> was afk, sorry
<pitti> thanks Pici
<sbeattie> Pici: thanks
<porthose> Pici, ty :)
<chrisccoulson> well, he was a pleasant character :-/
<kirkland> so what's the secret in karmic to drop to the grub2 menu?  i thought it was holding ESC ....
<slangasek> shift
<kirkland> slangasek: thanks
 * mneptok returns clad in the golden raiment in which he was born
<mneptok> ugh. trollfest.
<ajmitch> mneptok: yes, you missed it, though there wasn't really anything funny about it
<chrisccoulson> and he's been visiting all the other channels now, leaving similarly vulgar comments
<mneptok> ajmitch: i guess it's "funny" in the same way tumors are "funny"
<ajmitch> pretty much
<mneptok> *sigh*
<Keybuk> slangasek: already fixed that
<slangasek> Keybuk: ah, stuck on the buildd, ok
#ubuntu-devel 2009-12-02
<Cytotoxic> !ops
<Cytotoxic> ops
<Cytotoxic> !troll
<Cytotoxic> !staff
<jpds> Hmm.
<Cytotoxic> !ops
<lifeless> Cytotoxic: please, not again. Its really disruptive you doing this.
<Cytotoxic> why dosent it work?
<tsimpson> Cytotoxic: ubottu will ignore any request by you until we can trust you not to abuse it
<Cytotoxic> awww did the baby ubuntu developers filter me from it?
<tsimpson> no, I did
<Cytotoxic> good for you
<tsimpson> I don't want you to abuse the bot, so I made it so you could not
<Cytotoxic> since i am a lymphocyte i can adapt to this
<tsimpson> good luck with that
<Cytotoxic> i will develop antibodys to this filter
<Cytotoxic> goodbye baby
<LjL> also known as "alternative ips", i suppose
<lifeless> or a new registered username
<Meow234> !OPS
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<Meow234> told you i would adapt
<Meow234> !ops i told you i would adapt
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<lifeless> thanks
<Meow234> magic of lymphocytes
<lifeless> Meow234: its disruptive and wastes peoples time. We would like you to stop.
<lifeless> Keybuk: they go bye Cytotoxic too
<lifeless> s/bye/be/
<Keybuk> same person I think
<lifeless> Keybuk: and like to do it in #ubuntu-kernel as well, if you're in a banning mood.
<Keybuk> IP should cover him for a while
<lifeless> Keybuk: yes, same person.
<Keybuk> I'm not an op in #u-k afaik
<lifeless> comes in every few days
<mneptok> is there a full moon or something?
<zul> i think there is
<zul> or just more trolls
<slangasek> $ pom
<slangasek> The Moon is Full
<slangasek> fyi
<weremnep> aaaaaaOOOOOOOOOOO!
 * Keybuk wishes that dh_makeshlibs supported debian/$package.shlibs
<slangasek> hrm, didn't it previously?
<slangasek> or maybe I just never found a reason to need that, because I never needed more than -V
<Keybuk> right
<Keybuk> but then you need to override -V every damn time
<slangasek> anyway, .symbols
<Keybuk> and with dh 7, that's annoying ;)
<Keybuk> especially since you need to override -V individually for each library package produced
<Keybuk> don't you have to do *both* .symbols and shlibs?
<Keybuk> if not, why do packages still have shlibs in them at all?
<slangasek> if you have .symbols, the contents of shlibs are completely irrelevant
<slangasek> nothing current will look at the shlibs in that case, so it doesn't matter what they contain
<Keybuk> so why have shlibs at all?
<slangasek> in general?  because not all library packages have adopted symbols (nor are we likely to get 100% coverage)
<Keybuk> right, I mean why do you get a shlibs in your package info if you have symbols?
<Keybuk> shouldn't dh_makeshlibs/dpkg-gensymbols only include the symbols file in that case?
<slangasek> because the dpkg transition is incomplete, and is still generating stuff that's only relevant for compatibility when installing on ancient systems
<slangasek> ScottK: do you understand boost?  I'm unable to figure out why it's failing to find python 2.6 headers (after further patching it to not try to build for python2.5, given that 2.5 isn't pulled in by python-all-dev)
<Keybuk> so you do have to care about shlibs ;)
<ScottK> slangasek: I don't think anyone actually understands boost.
<Keybuk> if you're giving the file in your package, it should be at least useful
<Keybuk> second silly question
<Keybuk> how do I unmark a bug as private? :p
<ajmitch> slangasek: I've touched boost recently & haven't uploaded it
<slangasek> Keybuk: nah, you don't have to care about them, it's a dpkg bug that they're being output :)
<ScottK> There's an icon on the page, I think near the upper right, that gives you no earthly clue it's the right one, IIRC
<ajmitch> I built it for lucid in my PPA after changing it to use only python 2.6
<slangasek> if you have .symbols, there's no reasonable way anyone is going to need the .shlibs
<ScottK> slangasek: I've patched it for new Python versions before, but if ajmitch already got it working, I'd say use his.  If not, I'll have a look.
<slangasek> ajmitch: url?
<ajmitch> slangasek: there's an additional patch needed for python 2.6 compatibility, I've just been slack with getting it into lucid
<slangasek> ajmitch: ok; howzabout I let you take care of that part, and then I don't have to be TIL anymore? ;)
<ajmitch> slangasek: sure
<slangasek> (it's making a mess of components-mismatches again, trying to pull in the mpi stack)
<ajmitch> https://edge.launchpad.net/~ajmitch/+archive/ppa/+files/boost1.40_1.40.0-2ubuntu3.dsc was what I had, I'll update it for the latest merge
<slangasek> ajmitch: cheers!  please pull in the changes from my own 1.40.0-2ubuntu3 in the archive, to drop the mpi bits
<ajmitch> will do
<slangasek> (uploaded in full knowledge that it would FTBFS due to python, alas)
<ScottK> slangasek: Are you moving 1.40 into Main?
<slangasek> ScottK: it's already there by virtue of boost-defaults
<ScottK> Ah. Cool.
<ajmitch> boost 1.38 going to universe, or being dropped altogether?
<slangasek> the latter is preferred, I'm sure
<ajmitch> there's only a couple of packages that don't work with 1.40
<ScottK> Definitely Universe.  Dropping all together is a goal.
<ajmitch> one of them (python-visual) I haven't seen a fix for yet, but I might try & find out on the upstream mailing list about it
<ScottK> ajmitch: Then they may have to die in the end.
<ScottK> That'd be cool.
 * ajmitch knows some people who rely on it for their thesis :)
<ScottK> Motivated assistants ....
<slangasek> perhaps they'll finish their thesis before security support for jaunty ends ;P
<slangasek> s/jaunty/karmic/, I guess
<ajmitch> yeah, karmic is in need of a SRU for boost 1.38 to handle it, which will need to be looked at soon
<ajmitch> boost stuff is just so much fun though
<ajmitch> james_w: how often do branch imports from debian happen?
<ebroder> bryce: Is it worth my time to try and pull an SRU together for bug #311076? We apparently triggered it here on Jaunty today
<ubottu> Launchpad bug 311076 in xorg-server "hang on BOGUS LENGTH in write keyboard desc" [Undecided,Fix released] https://launchpad.net/bugs/311076
<james_w> ajmitch: 4 times a day
<ajmitch> james_w: ok, I'll file bugs about the out-of-date branches then :)
<ajmitch> boost1.40 1.40-4 hit squeeze 3-4 days ago & the branch hasn't appeared to update
<vorian> hello all, I was wondering if you all would be willing and able to give a testimonial on my wiki page for my run for the IRC council
<vorian> https://wiki.ubuntu.com/StephenStalcup
<lifeless> !ops | MBCR (on #ubuntu-motu) - not feeding the troll directly
<ubottu> MBCR (on #ubuntu-motu) - not feeding the troll directly: Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<RAOF> And #ubuntu-kernel, while you're at it.
<lifeless> vorian: are you freenode staff or just ops on motu?
<vorian> lifeless: i'm staff
<lifeless> vorian: he's pesting in #launchpad too
<lifeless> and #ubuntu-kernel
<lifeless> If you could just kline, that would be great.
<vorian> and he's now gone
<lifeless> thank you very much
<vorian> no problemo
<PhrkOnLsh> hello everyone. I'm a Fedora developer, and a few of us have recently started on a project to create a sort of "Welcome to Fedora" application that would launch when the user first logs in and gives a tour of desktop and list features, how to get help, etc. Along the lines of Windows' Welcome to Windows application. Does any buntu have such a similar application?
 * PhrkOnLsh idles, good night
<james_w> maxb: so apparently gina uses UTC_NOW as the date_created of the records it creates, so that's not the reason we are dropping these Debian uploads
<lifeless> PhrkOnLsh: I'm not aware of one ;)
<mneptok> PhrkOnLsh: as of Karmic the installer does the "show some helpful messages during the install process" thingy, but IIRC Anaconda already does that.
<PhrkOnLsh> You guys use anaconda?
<mneptok> no, but Fedora does ;)
<ajmitch> mneptok: wasn't this about first login, rather than install?
<PhrkOnLsh> aha.
<mneptok> ajmitch: yeah. just saying the closest thing *buntu has is already part of existing Anaconda functionality.
<PhrkOnLsh> For an idea of what I'm looking for our (messy, thinkbucket) wiki page http://fedoraproject.org/wiki/Fedora-tour
<PhrkOnLsh> but thanks everyone :)
<ajmitch> there was the 'about ubuntu' app which I'm not sure what it includes
<PhrkOnLsh> Was looking for some ideas on it, but looks like we're on our own ;)
<ajmitch> or that the few people online at the moment are just clueless :)
<PhrkOnLsh> I'll try again later, then :) going to sleep
<mneptok> PhrkOnLsh: personally, i'd ditch "Fedora Tour" and go with something like "GNOME Tour" and "KDE Tour." then you get far more eyes and interest, and the solution can be implemented in multiple distros.
<mneptok> bah.
<ajmitch> he fled!
 * mneptok 's reputation (obviously) precedes him
<jdong> where is the check bulletproof X uses to determine whether or not to go into panic mode?
<ajmitch> jdong: gdm, perhaps?
<jdong> on my VMWare Karmic workstation after applying the bulletproof X related updates,  it always drops into bulletproof X recovery mode when starting kdm
<jdong> *kdm* :)
<ajmitch> it might live there too :P
<jdong> claiming the reason it failed is because "cannot find /dev/fb0"
<jdong> I can find that line in my old working Xorg.log.*'s
<jdong> but it's clearly not fatal
<jdong> *starts rm'ing files*
<ajmitch> oh dear
<jdong> err after the 4.3.4 kdm ppa updates it works again
<jdong> heh the PPA must not incorporate whatever patches enable bulletproof X :)
<ajmitch> so yeah, i'm thinking that the bulletproof X stuff does live in *dm
<ajmitch> I recall gdm updates around karmic release because of it
<jdong> indeed even a regular startx shows (EE) cannot open /dev/fb0....
<jdong> but it goes right on to start X perfectly fine
<ajmitch> even with an EE?
<jdong> but bulletproof X seems to be interpreting that as X failed.
<jdong> indeed.
<jdong> surprising, isn't it?
<ajmitch> well it is meant to be a fatal error, from what little I know of X
<jdong> http://paste.ubuntu.com/332887/
<jdong> brief snippet
<jdong> as you can see, indeed there's an EE on that module but X continues on
<ajmitch> I'm guessing the various fb drivers don't work in vmware?
<jdong> *nods
<pitti> Good morning
<jussi01> Mornign pitti!
<jussi01> pitti: did you manage to get that jockey bug sorted?
<micahg>  is an SRU allowed to switch the order on depends for a dummy package?
<pitti> hi jussi01; "that" jockey bug?
<pitti> micahg: depends; what effect does it have?
<jussi01> pitti: the one I showed you at UDS
<micahg> pitti: it's for libsdl1.2debian
<micahg> pulseaudio seems to work where alsa doesn
<micahg> 't
<pitti> jussi01: no, I didn't get to work on jockey so far
<bryce_> heya pitti
<dholbach> good morning
<dholbach> hey mvo
<dholbach> doko, mvo: how does https://bugs.edge.launchpad.net/ubuntu/+source/python2.6/+bug/223281 look to you?
<ubottu> Ubuntu bug 223281 in python2.6 "locale._parse_localename fails when localename does not contain encoding information (was: alacarte crashed with ValueError in _parse_localename() )" [Medium,Confirmed]
<mvo> hey dholbach!
<ajmitch> morning mvo
<mvo> hey ajmitch
<dholbach> jmarsden: the patch has landed upstream already? in which release will it be included there?
<jmarsden> It is in their bugtracker for 3.0, I don't think it landed yet.  The patch creator suggested I might open a bug upstream against 2.6 and see if upstream will incorporate it that way.
<jmarsden> dholbach: http://bugs.python.org/issue6895 is the original bug I got the patch from.
<dholbach> jmarsden: the result is that all python scripts explode for certain locales?
<jmarsden> dholbach: All that are locale sensitive (anything using Lib/locale.py )
<dholbach> can you put the link to the upstream bug in the ubuntu bug too?
<dholbach> jmarsden: ^
<jmarsden> dholbach: It's there in comment #6 already
<dholbach> ahhh ok, missed it
<jmarsden> all I did was grab the patch, test it fixes the bug, and package it up, basically.
<dholbach> right
<dholbach> pitti: for some reason I can't get "community-lucid-" blueprints/workitems to be seen by the launchpad-work-items-tracker
<dholbach> pitti: I guess we're doing something differently compared to the desktop team, but I dunno what it is :)
<pitti> dholbach: oh, want me to set up tracking for community-lucid-* on my server?
<pitti> dholbach: do you have an URL for an example BP?
<pitti> dholbach: https://blueprints.edge.launchpad.net/ubuntu/lucid/+specs?searchtext=community -> has four
<dholbach> pitti: https://blueprints.launchpad.net/ubuntu/+spec/community-lucid-adopt-an-upstream
<pitti> right, that's there
<pitti> dholbach: let me set it up
<dholbach> thanks pitti
<dholbach> I'm just setting the series goal for a few where we didn't do it yet
<pitti> MAILTO=daniel.holbach@canonical.com,jono@ubuntu.com ?
<dholbach> mail for what exactly? :)
<pitti> "spec has no work items", "invalid work item state", etc.
<pitti> cron spam
<dholbach> just set it to my mail :)
<pitti> it's set up now, but complains about having no WIs
<pitti> hmm
<pitti> dholbach: did you just target those to lucid like 5 minutes ago?
<dholbach> some, yes
<maco> haha missed the last cron run?
<pitti> no, production always lags behind changes on edge
<pitti> ah, works now
<pitti> WARNING: community-lucid-application-indicators-outreach has no work items
<pitti> dholbach: ^ that's the kind of spam you get
<pitti> (four of those ATM)
<pitti> dholbach: http://piware.de/workitems/community/lucid/report.html
<pitti> the next run should have some meat in it, when production catches up
<ajmitch> pitti: your workitems stuff still screen-scrapes?
<pitti> ajmitch: give me a launchpadlib API, and I'll stop :)
<dholbach> thanks pitti
<ajmitch> pitti: yeah, I was working on that the other day in fact, after seeing your scraping ;)
 * pitti huds dholbach
 * dholbach huds pitti back
<pitti> ajmitch: oh, mdz was as well AFAIR
 * pitti doesn't like being hudded
<ajmitch> yeah, the bug was assigned to jml, he said he wasn't working on it at the moment
<pitti> nice
<soren> Any chance an archive admin could review libcloud some time today? It's been in NEW for over a week.
<soren> cjwatson: You seem to be the "on duty AA" this morning. ^^ Pretty please?
<cjwatson> mkay
<cjwatson> soren: accepted. (sorry, had to fix our local lintian installation first)
<geser> argh, someone an idea why the buildd didn't upgrade pkg-create-dbgsym? http://launchpadlibrarian.net/36328245/buildlog_ubuntu-lucid-i386.pion-net_2.2.2%2Bdfsg-2_FAILEDTOBUILD.txt.gz
<soren> cjwatson: Lovely. It's already in binary NEW, if you're up for it..
 * soren still gets excited about soyuz building stuff so quickly
<soren> cjwatson: Oh, and thanks! I really appreciate it.
<cjwatson> soren: done
 * soren hugs cjwatson 
<soren> cjwatson: Thank you!
<ogra> The following packages have unmet dependencies:
<ogra>   libglib2.0-data: Depends: libglib2.0-0 (>= 2.23.0-1ubuntu1) but 2.22.2-0ubuntu1 is installed
<ogra> E: Unmet dependencies. Try using -f.
<ogra> hrm, is someone taking care of that ?
<ogra> (thats from an armel livefs build attempt)
<pitti> just looks like a normal arch all/any buildd issue
<ogra> hmm
<asac> yes, i would wait a bit ;)
<ogra> but glib was uploaded yesterday
<asac> (if you are on 64bit)
<ogra> i'm on armel
<asac> even more so there ;)
<ogra> and i have no chance to get to reproduce the mksquashfs failure without getting through the package installation
<asac> ogra: failed to biuld on armel ;)
<ogra> which effectively means we wont be able to fix it
<asac> https://edge.launchpad.net/ubuntu/+source/glib2.0/2.23.0-1ubuntu1/+build/1374402
 * ogra checks
<asac> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I/build/buildd/glib2.0-2.23.0/glib -I.. -I/build/buildd/glib2.0-2.23.0 -DG_LOG_DOMAIN=\"GLib\" -DG_ENABLE_DEBUG -DG_DISABLE_DEPRECATED -DGLIB_COMPILATION -DPCRE_STATIC -DG_DISABLE_SINGLE_INCLUDES -pthread -g -O2 -Wall -g -O2 -MT gatomic.lo -MD -MP -MF .deps/gatomic.Tpo -c /build/buildd/glib2.0-2.23.0/glib/gatomic.c  -fPIC -DPIC -o .libs/gatomic.o
<asac> /tmp/cc7twNnB.s: Assembler messages:
<asac> /tmp/cc7twNnB.s:161: Error: selected processor does not support `swp r3,r5,[r4]'
<asac> /tmp/cc7twNnB.s:179: Error: selected processor does not support `swp r3,r5,[r4]'
<geser> pitti: do you know if it's safe to let pkg-create-dbgsym upgrade again on the buildds? it's on hold because of a problem with 0.32
<pitti> geser: still? I thought lamont removed that again
<pitti> yes, should be safe
<ogra> -Wa,-mimplicit-it=thumb is missing in the rules :/
<asac> ogra: or toolchain ;)
<asac> doko_: there?
<ogra> we wont get it in the toolchain before alphga
<ogra> seb128, ^^^
<ogra> seb128, could you add a contidional -Wa,-mimplicit-it=thumb CFLAG for armel to the package ?
<pitti> ogra: right, FTBFS on armel
<ogra> *conditional
<pitti> ogra: is that package specific?
<ogra> pitti, no
<lamont> pitti: we're going to test it to be extra sure, then unhold it
<pitti> then it doesn't belong into glib for sure, but in the default gcc flags?
<seb128> ogra, hum...
<ogra> its a temporary workaround so we have a chance to make alpha
<ogra> pitti, right
<seb128> ogra, what pitti said
<ogra> pitti, gcc builds to long
<ogra> no way for us to make alpha then
<ogra> there is a bug open for the toolchain
<pitti> ogra: it's faster to reupload a zillion packages than gcc?
<ogra> but it wont be fixed pre alpha
<ogra> i wouldnt say glib is a zillion packages
<pitti> ogra: but you said it affects all packages?
<ogra> it only packages that actually have assembler bits in their code
<asac> it should go into rules
 * pitti doesn't know about those build flags, sorry
<ogra> right
<pitti> ah
<ogra> its just a CFLAG in rules
<asac> and maybe a bug filed upstream
<asac> to make assembly thumb2 compliant
<ogra> not really, once the toolchain is right it can go again
<ogra> hmm, or that, yeah :)
<asac> i will check with dmart
<pitti> well, then go ahead :)
<asac> but for now we definitly should put it in glib rules
<seb128> I'm trying to get glib in sync with debian
<asac> seb128: ^^ can you upload that?
<asac> also see: https://wiki.ubuntu.com/ARM/Thumb2
<seb128> can you get those changes in debian?
<ogra> yeah
<asac> seb128: its really temporary
<ogra> asac, we should mail that URL to ubuntu-devel probably
<seb128> asac, yes but please upstream or send to debian
<ogra> to make sure maintainers make sure their packages are correct
<asac> seb128: we dont have a patch to upstream yet. i take the action to drive that though
<pitti> ifneq ($(findstring $(DEB_BUILD_ARCH), sparc alpha),)
<pitti> sorry
<pitti> ifneq ($(findstring $(DEB_BUILD_ARCH), armel),
<seb128> asac, ok, I trust you on that, do whatever you need to get running there
<pitti> CFLAGS += ...
<ogra> yeah, there
<pitti> endif
<pitti> ?
<ogra> right
<ogra> -Wa,-mimplicit-it=thumb
<ogra> thats what you want to add
<ogra> or -marm ... but that disables thumb2 completely
<seb128> when is the first alpha due btw?
<ogra> tomorrow
<pitti> uh, there wasn't even an announcement
<pitti> no, it's next week
<cjwatson> next week, according to the release schedule, not tomorrow
<ogra> ah
<pitti> December 10th
<seb128> pfious
<ogra> yeah, i got my schedule wrong
<asac> ogra: ... good to know that you feel overly pressured ;)
<pitti> should that be 'nuff time for a proper gcc fix?
<ogra> asac, i always do :)
<ogra> pitti, doko could tell :)
<seb128> I didn't see the announcement either and did some disruptive changes (ie new glib and new gtk)
<seb128> but that's all good apparently ;-)
<asac> not sure if doko is on vac though
<asac> let me check
<ogra> seb128, well, its A1 anyway .... i.e. all good as long as it boots somehow
<asac> seems not
<seb128> ogra, well I was rather concerned about you complaining about installability
<asac> doko_: when do you plan to update the implicit-it default? (or do you plan to not do that at all)?
<seb128> ogra, because armel is slow to catch up on gtk builds
<ogra> seb128, yeah, sorry ... i was reading my schedule wrong
<seb128> don't worry, it's all good ;-)
<asac> ogra: ok. so ok to wait for doko to answer ;)?
<ogra> we should mark https://bugs.launchpad.net/bugs/488302 critical or some such
<ubottu> Ubuntu bug 488302 in gcc-4.4 "Pass -mimplicit-it=thumb to as by default on in lucid armel" [High,Triaged]
<asac> ogra: well. it basically hides things
<asac> also i am not really sure implicit-it will help for the "swp" thing here
<ogra> hmm
<ogra> but i thought we will enable it anyway by default
<ogra> if you actually want to fix all assembler in all packages i doubt we can make lucid *g*
<asac> if it doesnt hide real thumb2 issues then its probably ok
<asac> to enable by default. what would be bad if we hide it and dont get properly optimized code
<ogra> indeed
<asac> but i can chcek that with dmart. let me open a bug for the glib build failure like the wiki page says
<asac> so he can take a look
<ogra> i think he was the one that suggested to change the defaults
<ogra> actually he filed that bug :)
<asac> yes. i think its good for default as it does not disable/convert instructions. which is why i think it wouldnt really help here
<ogra> "will allow most traditional ARM syntax inline assembler in C/C++ source to be assmbled in Thumb-2, and will not impact other code"
<ogra> i think thats the key sentence here
<ogra> so it doesnt actually "hide" stuff ... its just another way of applying the optimization as i understand
<asac> bug 491342
<ubottu> Launchpad bug 491342 in glib2.0 "assembly fails to build on armel/lucid " [Undecided,New] https://launchpad.net/bugs/491342
<asac> ogra: right.
<cjwatson> mvo: I don't know if you remember, but in your auto-update branch of ubiquity from years back (now merged), you removed the local fork of updateInterface on the grounds that you'd merged its changes into python-apt proper
<cjwatson> mvo: unfortunately it turns out you missed a bit :) could we get a fix into python-apt today, rather than reintroducing the fork to ubiquity? I think that would be preferable really
<cjwatson> mvo: it's a fix to handle non-blocking fds properly - I'll get you a patch as soon as I've tested it
<mvo> cjwatson: certainly, thanks for the patch!
<cjwatson> mvo: I think it's http://paste.ubuntu.com/333072/ - want me to just commit it directly to the core-dev branch, or something else?
<mvo> cjwatson: commiting is fine, but I can also merge it if that is the final patch. i will also apply it to the debian branch
<cjwatson> waiting for the test to complete ...
 * soren boggles
<soren> I had a bunch of rendering artifacts after having suspended/resumed my laptop.  They had been there for hours (possibly days, I forget when I last rebooted).
<soren> I'm in the middle of a dist-upgrade in the background, and suddenly all the artifacts disappear, and everything looks perfect again.
<soren> I glance over at the dist-upgrade, and it seems to have fixed itself while it was /unpacking/ xorg.
<soren> Very, very odd, if you ask me.
<soren> Well, xorg, xserver-xorg, or xserver-xorg-video-all.
<soren> Very, very odd.
<hakaishi> Hi folks, I'd like to debianize a qt-project. The problem I have is, that I don't know how to customize the .pro-file. I'd like to copy the binary into /usr/share/... . I tried DESTDIR but this throws an error (permission denied) while making the .deb. Hence I tried BIN.path += [...] and BIN.file += [...], but as the file isn't compiled yet, it won't do. What shall I do?
<seb128> slangasek, hey, any reason you didn't upload your gnome-screensaver merge?
<seb128> slangasek, (just curious on whether that was wanted or if you forgot to dput it)
<seb128> jdstrand, hey, I'm not sure I agree with the closing of this evince fileselector issue as wontfix...
<seb128> jdstrand, being able to store documents on shared vfat disks is a valid user scenario
<jdstrand> seb128: I agree-- but the user mounted it in a non-FHS directory. we allow access to /mnt and /media
<seb128> oh ok, fair enough then ;-)
<jdstrand> seb128: hmm, actually-- I thought it did. seems I mixed up the profile with the firefox one
<jdstrand> seb128: I'll fix that
<seb128> jdstrand, thanks
<jdstrand> seb128: non-FHS-- won't fix, FHS, fix
<jdstrand> seb128: thanks for the followup
<seb128> right, having mnt and media should be enough
<seb128> thank you for looking at those issues ;-)
<jdstrand> seb128: oh np! :)
<doko_> asac, seb128: this is code which should be fixed upstream, it won't work on multi cores. the atomic helpers should be used
<asac> doko_: right. my question was more about an ETA for the implicit-it flag in general
<doko_> asac: should be with the next upload
<asac> when is that ;)
<asac> ?
<doko_> when the eglibc build is fixed
<asac> ok
<asac> guess i wont get an estimate from you ;)
<doko_> no not a specific one :-/
<asac> about a week, two, a month etc.
<robbiew> cjwatson: I can't make the weekly meeting today due to conflicts...can you cover it? or should we cancel?
<cjwatson> I can cover it, can you let me know anything I should cover other than the spec approval deadline?
<cjwatson> mathiaz: you're currently listed as drafter on foundations-lucid-puppet-installer. Is that correct? Are you going to have a draft ready for the spec approval deadline tomorrow?
<mathiaz> cjwatson: hmmmm -?
 * mathiaz checks
<mathiaz> cjwatson: I'll draft something up today
<cjwatson> thanks!
<cjwatson> mvo: patch committed, I'll go ahead and upload now
<cjwatson> er, actually, I say that ...
<cjwatson> *actually* committed now
<mvo> thanks!
<ion> keybuk: Ok, posted bug #491389 and a merge request.
<ubottu> Launchpad bug 491389 in mountall "Start all fsck instances in parallel, but set their priorities so that thrashing is avoided" [Undecided,New] https://launchpad.net/bugs/491389
<smoser> wiki is dead?
<smoser> nope
<lamont> ogra: setarch vs arm - if you want to give me details on what the different personalities should be, and all that, I can see about pushing that upstream... OTOH, that may involve tweaking the kernel, maybe?
<ogra> lamont, i think lool had some patch in mind already
<lamont> woot!
<lamont> I'm happy to push it after signing off
<lool> lamont: I only checked out the source code quickly
<lool> lamont: What I had in mind as the best option for the situation at hand was to add a --force flag to allow (trying) to set any uname
<kirkland> Keybuk: syntax highlighting for vim would be really nice :-) :-)
<kirkland> Keybuk: for upstart scripts
<lool> lamont: Otherwise, we could allow armv7 -> armv6 -> armv5 kind of transitions only, and change the default in qemu
<slangasek> bryce_: is it known/expected in lucid that input devices connected after X has started aren't detected? :)
<lamont> lool: well.... we should at the very least make setarch believe in the various kernel-supported personalities provided on armel
<lamont> that much of a patch is simple to push upstream
<slangasek> bryce_: n/m, apparently it works if hal is running :-P
<lool> lamont: Oh absolutely
<lamont> slangasek: I have another machine where, after the upgrade to karmic, no console kit love.  it's quite possible that the issue also existed on jaunty, since my daughter's long complaint has been that thumbdrives don't work on her computer....
<lamont> but I can't for the life of me remember how I tracked down and fixed it last time
<slangasek> lamont: hum?  is that in response to my comment about input devices?
<lamont> lool: I'm not sure that forcing arbitrary uname returns is something I believe to be a good thing
<lamont> slangasek: well, your comment got me thinking
<lamont> and you know all, so I figured you were a good target. :-p
<lool> lamont: So {PER_LINUX32, "armv7l", NULL}, and the like, one per arch should do it; I dont have a definitive list though, perhaps the kernel does
<slangasek> lamont: consolekit WFM and millions of others out of the box, I haven't had any reason to know anything about it :)
<lamont> lool: OTOH, adding more personalities to the kernel, and teaching qemu about them?  sounds like a win
<lamont> slangasek: well, ISTR the last time I fixed it by reinstalling the machine.
<lool> lamont: Not sure what you mean on the kernel side?
<lamont> as in cruft from edgy-days?  something  in there hates on the console kit
<lool> lamont: Are you using startx?
<lamont> lool: if there are more personalities we want from the kernel, I mean
<lamont> lool: gdm
<slangasek> lamont: right, I'm entirely free of edgy cruft too :)
<lamont> mind you, this is also the box that has been faceplanting about once every 20-30 hours since I upgraded it to karmic... not sure if that's related
<lool> lamont: Actually you just made me realize that patching setarch was completely useless here
<lool> lamont: setarch asks the kernel to set the personality; but qemu intercepts uname calls to always return the emulated uname
<lamont> lool: PROGRESS! :(
<lamont> lool: ergo, qemu uname interception needs more smarts
<lool> So even if we make setarch allow fixing up armv5 to v7l or vice-versa, it wont help qemu-arm
<lool> lamont: Agreed
<lamont> but we should fix setarch, too.
<lamont> if only "because we can"
<lool> Tss I hate you, not only you make me realize that my own idea was wrong, but you manage to double the work in fixing this stuff!   ;-)
<lamont> OTOH, if qemu thinks it's running v5, it should at least log that it executed a v7 instr - the fact that the qemu-v5 implementation of that unsupported instruction happens to have the same results as the actual v7 instr? that's OK.  not logging it and having someone run that code on a v5 box?  kinda rudxe
<lamont> s/xe$/e/
<lool> lamont: TBH I feel Qemu should actually emulate only the instruction set it's told to emulate and return that; it can SIGILL when emulating a full system, it should just do the same when running in syscall emulation mode
<lamont> oh agreed most certainly
<ogra> lool, well, that still leaves the question how we set the default for qemu-arm
<ogra> if we hardcode v7 people wont be able to run anything but lucid binaries
<lool> As I said, qemu should allow setting what's it's emulating
<ogra> if we dont, wheer does it know from what to use ?
<lool> You can run v5 binaries on armv7 hosts
<ogra> oh, right
 * ogra slaps forehead ... i was thinking in the wrong direction
<lool> lamont: bah now that I've checked the kernel code, I see how it would need implementation of personalities for all this stuff
<lool> I thought it was taking the string as input, but it's PER_LINUX or PER_LINUX32 so no support for armv*
<lamont> heh. ok
<lool> probably nobody cares supporting older arms as personalities
<lamont> well then.. just fix qemu to say 'armel7v' :-p
<lool> armv7l ?
<lamont> lool: whatevah
<kklimonda> Keybuk: ping?
<cody-somerville> pitti, Curious. Why is the launchpad registry team a member of ubuntu-sru?
<slangasek> kklimonda: I understand that he's out sick today
<kklimonda> slangasek: thanks
<micahg> nixternal: I think that LP can merge teams, it's just not available to normal users
<kirkland> Keybuk: slangasek: hiya ... couple of upstart questions for you guys
<kirkland> Keybuk: slangasek: we're trying to support a couple of functions that the deprecated eucalyptus initscripts used to support ... namely "cleanrestart", "cleanstart", "cleanstop"
<kirkland> Keybuk: slangasek: these simply need to rm -f some /var/lib/eucalyptus/[stuff]
<kirkland> Keybuk: slangasek: i think when we discussed this previously, we were told to pass a variable to the upstart script
<kirkland> Keybuk: slangasek: something like "sudo restart eucalyptus CLEAN=1"
<kirkland> Keybuk: slangasek: did we understand that advice correctly?
<slangasek> ScottK: who should be assigned to the work items listed on https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-supportable-binaries ?
<slangasek> kirkland: (takes a moment to get over the horror at needing such an option) yes, that looks like a sensible way to do it
<kirkland> slangasek: is the syntax correct, "sudo restart eucalyptus CLEAN=1" ?
<kirkland> slangasek: ie, putting the CLEAN=1 as an argument?
<kirkland> slangasek: or is it expected that CLEAN=1 be defined in the environment calling it?  <--- seems nasty
<slangasek> kirkland: as an argument
<kirkland> slangasek: hmm, okay; that's what i'm doing;  will need to troubleshoot some more
<slangasek> kirkland: can I see the job?
<kirkland> slangasek: sure ... there are multiple levels, though
<kirkland> slangasek: i'll start you at the top
<kirkland> slangasek: sudo restart eucalyptus CLEAN=1"
<kirkland> slangasek: whoops ...
<kirkland> slangasek: http://pastebin.com/f60592b90
<kirkland> slangasek: lines 26 and 27 are my debug
<kirkland> slangasek: annoyingly, they're not executing at all
<kirkland> slangasek: on "sudo restart eucalyptus"
<slangasek> kirkland: did you force a reload after editing the script?
<slangasek> s/script/job/
<kirkland> slangasek: umm ... i edited the script and just "sudo restart eucalyptus" ... is there more i need to do?
<slangasek> yes, 'sudo initctl reload-configuration', I believe
<kirkland> slangasek: hrm
<soren> That's the thing with upstart..
<slangasek> "restart" restarts the current job with the existing job config
<soren> When you edit a job, it thinks it's a new job.
<slangasek> i.e., the already loaded in-memory job config
<soren> So restart will restart the one that's already running with the definition it had when it was started.
<kirkland> slangasek: okay, now i've done your initctl, and restarted; same behavior, no /tmp/env
<slangasek> kirkland: ok, then that just means I was mistaken :)  Do a stop && start, then try the restart
<kirkland> slangasek: aha
 * kirkland notes something non-intuitive about this particular quirk of upstart
<slangasek> kirkland: is that doing the trick, or is $CLEAN missing from the env?
<kirkland> slangasek: now my changes to the upstart script are registered and executing
<kirkland> slangasek: let me go hack on it some more, now that I know how to test my fudging
<slangasek> kirkland: does the test show that $CLEAN is getting set?
<kirkland> slangasek: yessir!
<slangasek> ok, cool
<zul> cjwatson: mind if I merge openssh?
<ScottK> slangasek: It'll be wgrant and myself working on it in the near term.
<cjwatson> zul: I'd rather I did it if you don't mind
<zul> cjwatson:no problem
<cjwatson> (must get the Debian history converted to bzr)
<soren> jdstrand: Is this perhaps a karmic chroot that was upgraded to Lucid?
<jdstrand> soren: possibly, but I don't think so...
<soren> I'm just puzzled how one would have a lucid chroot without libnih-dbus1 in it.
<cjwatson> zul: uploaded
<zul> cjwatson: thanks
<soren> ..unless it's an upgrade from a version of Ubuntu where libnih-dbus1 was not Priority: required.
<jdstrand> I can recreate it-- I remember I created it shortly after lucid opened
<jdstrand> maybe that required business wasn't there when I created it
<soren> Perhaps.
 * jdstrand goes to recreate it
<soren> libnih didn't come into existence as a separate souce package until a week ago, at least.
<cjwatson> Priority: required isn't enough to cause anything except debootstrap to autoinstall it, of course
<jdstrand> oh, well, I created the schroot much earlier than that
<cjwatson> now, mountall pre-depending on it *is* enough
<jdstrand> soren: well, the libnih-dbus thing might be a red herring... I just mentioned it cause that was a difference in the builds
<soren> jdstrand: Gotcha.
<jdstrand> soren: also, I just remembered, my debmirror script has been dying lately, so the lucid chroot is certainly out of date
<jdstrand> (I fixed that today)
<blackxored> how can I unregister a branch from launchpad? I have two packaging branches on bzr which I don't longer maintain since I switched to git
 * jdstrand waits to rebuild his chroot
<cjwatson> blackxored: there should be a delete button in the UI for the branch, looking like a trashcan icon
<cjwatson> ScottK,ogra: FYI -Wa,-mimplicit-it=thumb makes no difference to the qt4-x11 failure.
<cjwatson> the error is on a QT_MMAP call ...
<blackxored> cjwatson, inside the brash on the sidebar, yes, thanks
<blackxored> does launchpad provide any kind of git integration?
<cjwatson> no. this is intentional, part of the point of bzr is to be able to interoperate well with other systems
<cjwatson> you can ask Launchpad to *import* git branches into bzr
<blackxored> cjwatson, how can I do that, and that automatically fetch my changes?
<cjwatson> blackxored: https://help.launchpad.net/VcsImports
<blackxored> cjwatson, thanks, it is ok to let launchpad import my branches for debian packages, right?
<blackxored> or it is overkill?
<cjwatson> you can ask it to import whatever you like
<cjwatson> (BTW this is probably more appropriate in #launchpad ...)
<blackxored> cjwatson, thanks
<LaserJock> right now Launchpad only imports git master branches
<cjwatson> yes, although that at least stands a reasonable chance of getting fixed soonish
<LaserJock> sounds like it, would make it much more useful for packaging
* mbarnett changed the topic of #ubuntu-devel to: **Launchpad will be down/in read-only from 22:00 UTC until 23:30 UTC for a code update ** Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu
 * maxb reads the help of bzr merge-upstream
 * maxb is confused
<FishEatFish>  hello, i have probleme with dh_make, it can't create debian/ in my sources folder !! can anybody help me please ?
<maxb> Sure - but not here, #ubuntu-motu
* mbarnett changed the topic of #ubuntu-devel to: **Launchpad will be down/in read-only from 22:30 UTC until 23:30 UTC for a code update ** Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu
<jcole> is there a way for gcc to compile a 32bit app on a 32bit kernel so it cat access more than 4gb? the server has 32gb of ram
<FishEatFish> maxb : thank you i'll go there
<kirkland> cjwatson: sorry to bug you again about the daily builds ....
<kirkland> cjwatson: i'm wondering if it makes sense for cdimage to trash the previous completed ISO build, if the current ones are failing
<kirkland> cjwatson: it would be nice if the "current" symlinks continued to point to the last good build, -> http://cdimage.ubuntu.com/ubuntu-server/daily/current/
<superm1> kirkland, how would cdimage know it's a bad build?  it's not the one testing them
<kirkland> superm1: hrm, i don't know the inner workings ... i'm just suggesting that whatever is reaping the old builds and updating the symlinks *not* do so if the incoming "current" is missing any *.iso
<superm1> kirkland, oh by failed build you mean failed build, not failed build
<kirkland> superm1: that's a confusing sentence
<superm1> er i forgot emphasis there, you mean "failed to build", not the "build fails to install"
<kirkland> superm1: right, of course
<kirkland> superm1: notice that http://cdimage.ubuntu.com/ubuntu-server/daily/current/ is empty
<kirkland> superm1: as is http://cdimage.ubuntu.com/ubuntu-server/daily/20091202/
<kirkland> superm1: as well as http://cdimage.ubuntu.com/ubuntu-server/daily/20091201/
<kirkland> superm1: fortunately, I happened to have had testdrive cache an ISO from 2009-11-27 for me :-)
* mbarnett changed the topic of #ubuntu-devel to: **Launchpad will be down/in read-only from 23:00 UTC until 23:45 UTC for a code update ** Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu
<slangasek> kirkland: hmm, I suspect the symlink was updated because the source ISO build succeeded
<slangasek> so the build as a whole was a "success", I guess
<kirkland> slangasek: that's, um, cute :-)
<slangasek> seems sensible to ignore source ISOs for this, though I'm not sure offhand how deep the surgery will be
<cjwatson> kirkland: it's not trivial, multiple different pieces involved. The reason I've never bothered to fix it is that if the dailies are failing for many days in a row then we ought to be fixing that anyway
<kirkland> cjwatson: okay, thanks
<fagan> maco: hehe I tried kubuntu because I had a problem with gnome and it refused to connect to my network
<pitti> cody-somerville: hm, no idea I'm afraid
* mbarnett changed the topic of #ubuntu-devel to: **Launchpad will be down/in read-only from 0:00 UTC until 01:30 UTC for a code update ** Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu
#ubuntu-devel 2009-12-03
<maxb> How do I import a new upstream tarball using bzr-builddeb!?
<maxb> I'm completely failing to grok how to make this happen, even after reading the sourcecode a bit
<lifeless> maxb:I posted to udd
<lifeless> maxb: bzr merge-upstream is the comand you need.
<lifeless> maxb: and you need to commit after that to record the change (but resolve any conflicts fist)
<maxb> I read it's help message, and couldn't figure it out. I read its sourcecode and still couldn't make it work
<lifeless> details
<maxb> I've found your mail wherein you suggest you have to build the new source manually and then import-dsc it
<maxb> which is... not intuitive, shall we say
<maxb> Hmm.... and now it has gone and imported the debian directory into the upstream branch?
<lifeless> maxb: hangong
<lifeless> maxb: firstly, 'does not work' is about as useful as a first time cygwin user asking for help.
<lifeless> you can do better :)
<maxb> What I would like, is to know how someone learning bzr-builddeb is supposed to get started.
<maxb> Because at the moment it seems to be substantially impenetrable
<lifeless> I agree
<lifeless> I nearly wrote a complete replacement for merge-upstream
<lifeless> but right now, I want to help you use it.
<lifeless> if you can just describe what you've tried, and what happens when you do, I may be able to help.
<maxb> Ok: I have a branch. I have a new upstream tarball. What is the most basic thing I should do next?
<lifeless> is the branch a packaging import branch, or something else?
<maxb> It's rather a something else. It's a bzr-git pull of the debian packaging
<lifeless> ok
<lifeless> so firstly, bzr-builddeb as packaged has bugs that will make it impossible to diagnose what you will encounter. They don't trigger so much on package import branches.
<lifeless> so, you'll want to bzr branch lp:bzr-builddeb ~/.bazaar/plugins/builddeb
<maxb> already running trunk
<lifeless> or do a pull - the fixes were merged last night
<maxb> pulled, no changes
<lifeless> ok, cool
<lifeless> secondly, does the branch you have in front of you contain the full source
<lifeless> or only the debian dir ?
<maxb> yes
<maxb> full source
<lifeless> ok, thats good.
<lifeless> now, does it have an upstream-CURRENT_UPSTREAM_VERSION tag
<lifeless> (bzr tags)
<maxb> yes, it does
<lifeless> e.g. upstream-1.2.3
<lifeless> merge-upstream makes a child of that tag as part of its work.
<lifeless> what command did you run, when you expressed surprise at an upstream code dump being done?
<maxb> bzr merge-upstream ../tortoisehg-0.9.1.tar.gz --version 0.9.1
<lifeless> ok. what that should have done, if you look at bzr st is,
<lifeless> created a pending merge from a commit 'new upstream 0.9.1'
<lifeless> updated debian/changelog
<lifeless> and done a merge of all the upstream source files that are contained in that tarball
<lifeless> maxb: if thats the case, then when you run 'bzr commit' you'll have done the bzr equivalent of 'uupdate'.
<lifeless> maxb: further, 'bzr diff -r tag:upstream-0.9.1' will show you the current packaging delta.
<maxb> Except the new "Import upstream version 0.9.1" commit actually contains an addition of all the debian/* files in my current working tree, instead of any upstream updates
<lifeless> maxb: did you start with a clean tree?
<maxb> yes
<lifeless> how are you determining that that is what the upstream commit contains?
<maxb> bzr qlog.... but it seems my previous grappling with merge-upstream managed to replace the upstream tarball with one containing my debian dir!
 * maxb redownloads, reverts, retries
<lifeless> if you have altered tags you will need to zap those, or start with a fresh branch.
<lifeless> hmm, sorry if I was grumpy before, it was meant to be humour emphasis.
<maxb> ok... so actually it seems it does work now, and something in my previous flailing had caused it to overwrite my upstream tarball with a nonsense one
<lifeless> excellent
<lifeless> the revision tagged upstream-0.9.1 contains pristine tar metadata in a revision property.
<maxb> I think I should go pore over the sourcecode at some point when I'm not actually trying to achieve some packaging and write a wiki page about it
<lifeless> totally
<lifeless> the biggest problem I had was having no model of the bits inside
<lifeless> so I couldn't guess at commands or solutions.
<lifeless> sadly I haven't had time to write up my learnings yet
<maxb> Does it make more sense to discuss changes to bzr-builddeb on ubuntu-distributed-devel@ or bazaar@ ?  I'd like to try to sort out some of the copy-and-paste code from bzrtools
* mbarnett changed the topic of #ubuntu-devel to: **Launchpad will be down/in read-only from 01:30 UTC until 02:30 UTC for a code update **  Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubunt
<Ryan52> where's doko? is he on vacation or something?
<ScottK> Ryan52: He was on vacation last week and he's sick now.
<ScottK> (conference the week before)
* mbarnett changed the topic of #ubuntu-devel to:  Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubunt
<Ryan52> mbarnett: missing the last u in /topic
<mbarnett> Ryan52: ta!
* mbarnett changed the topic of #ubuntu-devel to:  Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu
<Ryan52> ScottK: ugh, okay, thanks.
 * Ryan52 needs his advice :(
<whatchasay> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<ebroder> Haha. Congratulations - you got what you wanted
<lifeless> sigh, cyto is back. Can we ship them a psychiatrist?
<Hobbsee> lifeless: or make them play in the traffic.  i wish
<lifeless> Hobbsee: we need a kline
<lifeless> he'll just rotate through ubuntu-kernel, ubuntu-motu etc.
<Hobbsee> lifeless: i know.  if i could hand them out, this guy would be history..
<dtchen> will likely reappear with the same hostmask, too
<lifeless> vorian: ^ (pici)
<lifeless> vorian: I hate to bug you, but you're the only staffer I know :)
<Pici> lifeless: We're taking care of it
<lifeless> Pici: thanks
<lifeless> Pici: I didn't mean to nag:)
<dtchen> slangasek: do your speakers pop on reboot/shutdown, too?
<ebroder> Hmm...is there any standard advice for how to deal with the Maintainer/Original-Maintainer fields in Ubuntu derivative distributions?
<ebroder> (Options we're currently debating include "Original-Original-Maintainer" and dropping the maintainer if original-maintainer is already set, since the maintainer in that case isn't likely to contain a lot of information)
<tsimpson> ebroder: you should probably move the the Maintainer to Original-Maintainer, and set whoever maintains the package in the derivative as the Maintainer
<ebroder> tsimpson: What if there's already an Original-Maintainer? Frequently in that case, the Maintainer is just "ubuntu-motu" or "ubuntu-devel", which is far less interesting, unique, and informative than the Debian maintainer listed in Original-Maintainer
<tsimpson> ebroder: the original Original-Maintainer should be dropped then probably
<tsimpson> the reason we have Original-Maintainer is because Debian wanted to make sure they got some attribution for the packaging
<ebroder> tsimpson: Sure, and if we re-package your re-packaging, presumably that doesn't change the fact that the Debian maintainer is interested in attribution
<tsimpson> there is no need to keep adding Original-XYZ every time someone forks the package
<tsimpson> ebroder: if you want, keep the Original-Maintainer as the debian maintainer, and change the Maintainer to your packagers
<ebroder> tsimpson: I actually just had the thought of putting both the Debian maintainer and the Ubuntu maintainer in our XSBC-Original-Maintainer, comma separated
<tsimpson> if you want to be really nice, mention that you derive from the Ubuntu package in the debian/copyright
<tsimpson> ebroder: it should be a single field, in the exact form "Packager Name <packager email>"
<ebroder> tsimpson: That's not actually specified anywhere in policy for Original-Maintainer (it is for Maintainer)
<ebroder> (Unless it is and I just haven't found it yet)
<tsimpson> but it's derived from Maintainer
<tsimpson> so anything in there needs to be compatible, right?
<tsimpson> but I think my second suggestion is closer to what you want. replace the Maintainer field, and mention in the debian/copyright that the package is derived from the Ubuntu package
<tsimpson> that way, everyone gets attribution
<ebroder> tsimpson: That process is harder to automate :)
<tsimpson> and the right contact is set
<tsimpson> ebroder: 'cat "This package is derived from Ubuntu" >> debian/copyright' ;)
<tsimpson> though you'll probably want to put a link or something in there too
<ebroder> tsimpson: I'm having a hard time understanding why Original-Maintainer should be format-compatible with Maintainer - as I see it, it's some made up field we happen to have standardized, but has no meaning through policy, and presumably no software with format expectations
<tsimpson> but just a note at the end saying that it's based on Ubuntu is perfectly fine
<tsimpson> ebroder: you don't know that no software anywhere doesn't use it in some way
<tsimpson> well, you do already know that lintian uses it
<ebroder> This is true. I might be willing to take that chance, though. I can certainly make arguments about the /types/ of software that would care about the Original-Maintainer
<tsimpson> how will it react to a comma separated list?
<ebroder> Most of the types of software that might care are p.u.c, lintian, etc - developer tools, not user tools. It's more OK if those break
<tsimpson> if developer tools break, you'll have an even harder time packaging
<ebroder> Eh - but I find it unlikely. Incidentally, I checked lintian - it doesn't currently do any checks for original-maintainer other than making sure it isn't there if the version number doesn't match /ubuntu/
<tsimpson> it checks that it has an @lists.ubuntu.com address if it does have ubuntu changes
<ebroder> That's Maintainer, not Original-Maintainer
<tsimpson> oh yeah, right
<ebroder> What other things are there that care about Original-Maintainer besides p.u.c? That's all I can think of at the moment...
<tsimpson> it's mostly for decoration
<ebroder> p.u.c can already deal with multiple Uploaders, so presumably it wouldn't be hard to extend it to deal with multiple Original-Maintainers, even if it doesn't now
<tsimpson> but adding yet-another-field feels wrong to me
<ebroder> (Also, my derivative isn't currently using p.u.c against our repo)
<tsimpson> I don't see why you need to have multiple original maintainers anyway
<ebroder> For the same reason that you have Original-Maintainer in the first place - we want to show the parentage of our modified packages, without implying that they're not our responsibility
<tsimpson> what's wrong with just adding it to debian/copyright or debian/README
<tsimpson> ?
<ebroder> Why didn't Ubuntu do that for Debian packages?
<tsimpson> probably because Debian wanted otherwise
<sladen> ebroder: the Original- prefix was added later so that some non-Ubuntu DDs would not risk getting further debbugs/etc automated reports
<ebroder> sladen: Sure, and I realize that specific motivation is largely gone now that ubuntu doesn't ship reportbug
<sladen> ebroder: there's a little bit of coverage on http://wiki.debian.org/Xcontrol
<ebroder> sladen: Interesting - I hadn't seen that page
<ebroder> sladen: But the page seems to be a bit short on actual ideas for solving the Original-Maintainer problem
<sladen> ebroder: what /is/ broken?
<sladen> ebroder: the ideal would be not to modify it---to preserve the credit where credit is due
<ebroder> sladen: The problem of wanting to give credit to the Debian and Ubuntu maintainers without implying responsibility
<ScottK> There was actually a poll among DD's to help set the policy
<ScottK> ebroder and sladen: https://wiki.ubuntu.com/DebianMaintainerField is a more detailed history.
<ebroder> ScottK: I did read that
<ScottK> The biggest problem with not changing the maintainer field is that we'd get the derivatives bugs.
<ScottK> People do regularly mail the maintainer with bugs/questions.
<ScottK> IMO a derivative's users bugs/questions are their problem, not mine.
<ebroder> ScottK: I totally agree
<wgrant> ScottK: But people also file Linux Mint bugs against Ubuntu, so I'm not sure the maintainer is much of a problem.
<ScottK> wgrant: I also mark them invalid unless they can explain why they think the apply to Ubuntu.
<ScottK> I know nothing about Linux Mint and what they change or don't change.
<sladen> wgrant: Please change them to be against 'linuxmint', rather than marking invalid
<ScottK> sladen: That was me.
<sladen> ScottK: https://bugs.launchpad.net/linuxmint
<ScottK> sladen: Usually it's an Ubuntu task added to a derivative's bug (I actually see this as much or more with baltix (although not recently)
<ScottK> sladen: I don't think it would be appropriate for me to say something is a bug in linuxmint.  I don't know anything about it.
<sladen> ScottK: you're not decreeing it;  you're redirecting it to the appropriate project
<ScottK> I don't see it that way.
<ScottK> It I mark a bug as applying to a project, I think that means that I think that the bug applies to the project.
<sladen> ScottK: Ubuntu and Mint happen to use not just the same bugtracker, but the *same instance* of a bug tracker
<ScottK> It's hardly worth arguing about because except for Baltix and backports bugs (which I never understood) I find it rare.
<ScottK> sladen: I understand that.
<ScottK> That choice doesn't give me any insight into what may, or may not, be a bug in linuxmint.
<sladen> ScottK: marking it Invalid results in an alienated user;  redirecting a mis-filing is instead a progressive, helpful engagment
<ScottK> sladen: Not my user.
<ScottK> I know that sounds harsh, but i really can't solve the world's problems.
<sladen> if a person filed a bug in the Linux Mint bug tracker (also the Ubuntu bug tracker) with the wrong meta-data, that's a keying/understanding error---not something invalid
<ScottK> Could be.
<ScottK> I get enough Ubuntu bug mail without trying to sort out ones that belong to other distros.
<sladen> ScottK: the same happens with Ubuntu One bugs filed against Ubuntu, and Ubuntu bugs filed against Ubuntu One (same instance of a bug tracked, shit UI)
<ScottK> That one I know a little more about and can, in fact, sometimes have a useful opinion about.
<sladen> ScottK: sorry, I thought in the cases you were aware they were filed against Linux Mint
<ScottK> sladen: It is.
<ScottK> I just have no idea how or if they should be applied somewhere else or not.
<sladen> indeed
<ScottK> The fact that some Ubuntu derivates choose to use the same bug tracker as Ubuntu does not create a moral obligation for me to care about their bugs.
<ScottK> But it's late here and I need to get to bed, so have a good day/night (whichever it happens to be)
* cjwatson changed the topic of #ubuntu-devel to:  Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
* cjwatson changed the topic of #ubuntu-devel to: Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<dholbach> good morning
<pitti> Good morning
 * pitti goes to fix the runaway input_id process in udev 148, sorry for that
 * jussi01 hugs pitti
<free> mvo: hi! around?
<mvo> hey free, yes
<free> mvo: I was testing a non interactive upgrade from dapper to hardy, and I think I've hit a bug in the upgrade tool script.. http://pastebin.com/m4431c1e8
<mvo> free: thanks! let me check
<free> mvo: it looks like the solution would be as easy as adding the [NonInteractive] stanza to DistUpgrade.cfg.dapper
<free> mvo: with ForceOverwrite=no, as in DistUpgrade.cfg
<mvo> free: thanks, let me fix it in the code.
<mvo> free: the trunk/ version of u-m is not well tested yet with dapper->hardy (it may have regressed since the hardy version of u-m was released). so its probably best to use the hardy version of the upgrade tool for dapper->hardy (or do you see the bug there as well?)
<free> mvo: I used the hardy script from http://archive.ubuntu.com/ubuntu/dists/hardy-proposed/main/dist-upgrader-all/0.87.30/hardy.tar.gz
<free>  
<mvo> free: oh, thanks. thats a bug there then too :/
 * mvo scratches his head
<free> mvo: on a dapper minimal system, kvm
<free> mvo: there's also another problem I'm trying to understand, but couldn't yet
<mvo> free: thanks, either you need to modify the DistUpgrade.cfg.dapper in the way you described in landscape then or we need to do a SRU to fix the bug
<mvo> free: what is it?
<free> mvo: with the modification suggested the script moves on, but fails with this https://pastebin.canonical.com/25309/
<free> (sorry pastebin.com is rejecting it as spam)
<mvo> free: the crash in the earlier pastebin is fixed in trunk/ now, many thanks
<free> mvo: cool
<free> mvo: however the network is okay, wget-ing the Packages.bz2 manually and checking the md5sum looks okay
<mvo> free: uh, hash-sum mismatches - are you behind a proxy of some sort?
<free> mvo: nope, doesn't really seem a network problem, as said it works with wget
<free> mvo: oh well, I'm in a NAT but that shouldn't matter
<mvo> no, NAT should be fine
<free> mvo: I can try from an ec2 instance if needed
<mvo> free: give me a sec, I need to think how to add debug output to it
<free> mvo: thanks a lot
<free> mvo: I'm not sure but I think that code is inside some backport package which is downloaded at runtime?
<mvo> yes
<mvo> free: can you login into the machine with the failure? or is it "destroyed" after the failed upgrade attempt?
<free> mvo: I'm in
<mvo> oh, cool
<free> mvo: it's up and working, the script just fails gracefully
<free> mvo: if you feel better, I can give you the ubuntu-vm-builder command line used to build the KVM machine, so you can reproduce it on your side fairly easily, I guess
<mvo> free: could you please add http://paste.ubuntu.com/333734/ and run it again?
<mvo> free: should be in /tmp somewhere
<free> mvo: I'm truing
<free> mvo: hmm, I can't find that file
<mvo> free: nothing with "find /tmp -name "dist-upgrade.py" ?
<free> mvo: nope
<free> mvo: the only file with that name is in the root of the extracted hardy.tar.gz
<free> but it looks like a different one
<mvo> oh, sorry. please try that one then, it probably changed a bit, my diff is against trunk/
<mvo> but that should not matter, the apt_pkg stuff will work
<free> oh okay
<mvo> and give lot of debug output of the http transfer
<mvo> free: I see if I can find a dapper image in the meantime
<free> mvo: probably an ec2 instance would do it as well
<free> mvo: the log seems to be the same, no additional info
<free> oh wait, my modifications got overwritten
<free> I think I have to put them in ./hardy instead of ./dist-upgrade.py
<free> yes, better now
<free> mvo: http://people.64studio.com/~free/output
<mvo> free: hm, that looks ok :/ could you please also add "apt_pkg.Config.Set("Debug::pkgAcquire::auth","true") ?
<free> mvo: sure
<free> mvo: done, please just refresh the link above
<free> there are a couple of HTTP/1.1 206 Partial Content at the end
<mvo> free: and some empty RecivedHash entries. I think I need to try to reproduce this locally, could you please give me the vm-builder commandline you used?
<free> mvo: yes, hold on
<mvo> free: could you please rm /var/lib/apt/lists/* /var/lib/apt/lists/partial/* and give me the output afterwards as well ?
<mvo> (in a different file if possible so that I can compare)
<free> mvo: something like sudo ubuntu-vm-builder kvm dapper --mirror=http://it.archive.ubuntu.com/ubuntu --ppa=landscape/ppa --addpkg=landscape-client --addpkg=openssh-server
<free> mvo: the --ppa=landscape/ppa shouldn't be relevant
<mvo> thanks
<free> mvo: http://people.64studio.com/~free/output2
<mvo> ubuntu-vm-builder is running
 * mvo waits patiently
<free> mvo: once you have the VM, what I did was basically wget http://archive.ubuntu.com/ubuntu/dists/hardy-proposed/main/dist-upgrader-all/0.87.30/hardy.tar.gz, untar and then ./hardy --frontend DistUpgradeViewNonInteractive (with the .cfg.dapper fix mentioned above)
<ogra> cjwatson, qt4-x11 ... bah, thats unfortunate
<pitti> wgrant: so there was a LP rollout yesterday? Any idea whether this brought support for 3.0 format packages?
<pitti>  [dpkg-source output:] dpkg-source: error: Unsupported format of .dsc file (3.0 (quilt))
<wgrant> pitti: The rollout failed.
<pitti> apparently not
<wgrant> pitti: And no, it didn't quite land. Reviews, etc.
<wgrant> But 3.1.12 is in two weeks.
<pitti> :(
<pitti> thanks
<xartigas> Hello there! Noob speaking
<xartigas> Is this the right place to ask for help regarding building gtk+?
<xartigas> nvm, found the gtk+ channel :p
<slangasek> dtchen: I don't recall
<t3rm1n4l> hi
<t3rm1n4l> i am looking to develop a boot from wifi system
<t3rm1n4l> by keeping an initrd+kernel at client
<t3rm1n4l> and root filesystem at the serversude
<t3rm1n4l> then client will mount the serverside root filesystem via wifi and chroot and execute further
<t3rm1n4l> is there some problem in implementing this ?
 * seb128 kicks karmic and grub2 creating invalid winxp boot stanzas
<pitti> seb128: still fighting with your uncle's computer?
<pitti> t3rm1n4l: isn't that pretty much what ltsp already provides for ethernet?
<seb128> pitti, no, my parents one this morning
<seb128> I installed karmic which broke winxp boot
<seb128> it doesn't chain on the right disk or something
<seb128> a found a grub entry to put manually on the forum which works now
<t3rm1n4l> pitti: i need to implement it through wifi
<pitti> t3rm1n4l: right, that's why you need a local kernel/initrd; but ltsp still provides loading of the root fs, chroot building, remote mounting, etc.
<t3rm1n4l> but ltsp wont work in wifi right ?
<pitti> t3rm1n4l: I'm not a specialist (ogra, stgraber), but I don't see a reason why it wouldn't, once you set up wifi on the client side
<pitti> t3rm1n4l: the PXE/kernel/initrd loading won't work, of course
<ogra> there is no PXE for wifi
<pitti> BIOSes usually don't support that
<t3rm1n4l> yea
<t3rm1n4l> it can be implemented easily right ?
<ogra> use a wifi bridge
<ogra> no
<ogra> it cant
<pitti> ogra: right, but once you set that up locally (local kenel/initrd), can you use it to load the chroot, etc.?
<t3rm1n4l> yes
<t3rm1n4l> that is my idea
<t3rm1n4l> mount root filesystem using sshfs
<mvo> free: fun! (well, not) - dappers ssh keeps crashing in my lucid kvm, might be a kvm issue, i have seen those before, but makes testing hard :(
<ogra> you need either local media with kernel and a specifically hacked up initramfs or a wifi bridge
<ogra> beyond that its highly insecure
<free> mvo: ouch
<mvo> free: I will re-try on my karmic system after lunch
<mvo> sorry
<ogra> pitti, yes, but indeed you have to promote your wifi keys publically to the world in your rootfs for i.e. reconnects
<ogra> we never implemented it in LTSP because there are to many security holes
<pitti> sure
<pitti> I had assumed this was for open wifis anyway
<ciphergoth> hey lovely people.  I know that packages in Debian unstable automatically trickle into Ubuntu, but I haven't managed to find the page that describes the timing.  When does a package have to make it into "sid" in order to make it into "Lucid Lynx"?
<ogra> t3rm1n4l, pitti, there is no point in using sshfs though ... since you have to make both keys public anyway
<ogra> use nbd or nfs
<t3rm1n4l> okay
<t3rm1n4l> i am looking at it as my academic project
<ogra> have a look at the ltsp_nbd initramfs script in the ltsp-client-core source package
<t3rm1n4l> okay
<ogra> you can just add the wifi stuff there and indeed need to somehow get the key into the initramfs
<t3rm1n4l> thanks
<FIN__Master> Could someone help me with patching a few xorg files with .patch files and building xorg or making a package with the files?
<ciphergoth> from this lovely picture I gather that alpha one is in a few days: http://anotherubuntu.blogspot.com/2009/11/lucid-lynx-timeline.html
<ciphergoth> do I need to do anything to get my package in there?
<slangasek> james_w: pristine-tar failed for lp:ubuntu/portma
<slangasek> +p
<free> mvo: no worries!
<davmor2> pitti: jockey is crashing on live desktop startup are you aware of this?
<pitti> davmor2: in lucid?
<davmor2> yes
<pitti> dbus.exceptions.DBusException: org.freedesktop.PolicyKit1.Error.Failed: Error parsing subject struct
<pitti> davmor2: yes, I am; some weird regression in polkit, haven't found time to track it down yet
<davmor2> pitti: this bug Bug 491429 so we are on the same page
<ubottu> Launchpad bug 491429 in jockey "jockey-gtk crashed with DBusException in call_blocking() (dup-of: 403955)" [Undecided,New] https://launchpad.net/bugs/491429
<ubottu> Launchpad bug 403955 in jockey "jockey crashed during installation of xubuntu, apparently no effect on the installation, which continued normally" [Medium,Incomplete] https://launchpad.net/bugs/403955
<pitti> davmor2: thanks
<pitti> davmor2: hm, that's for karmic
<pitti> that bug doens't affect karmic
<davmor2> pitti: the first one isn't though it's lucid
<davmor2> pitti: the one that retrace duped it as is karmic
<porthose> will source format 3.0 (quilt) packages be supported in lucid?
<siretart`> porthose: they actually already are since ages, it's just that launchpad doesn't accept them yet
<porthose> siretart, ty :)
<porthose> siretart, I was just wondering, one of the packages I look after in debian, someone did a fakesync from debian sid and removed the 3.0 formating :(
<siretart`> porthose: AFAIUI that feature is already implemented in launchpad and 'just' needs deployment
<Laney> that's the way to do it currently
<Laney> apparently the LP rollout is on the 11th
<porthose> Laney, so we create a delta instead of just waiting until the 11th?
<Laney> if you want the package in
<porthose> Laney, Ok ty for explaining :)
<geekles> to anyone doing gnome-dev work on karmic, are you using jhbuilb from source or from jaunty?
<geekles> *jhbuild
<tjaalton> there are now 44 X packages waiting to be synced ;)
<tjaalton> protos, libs
<ogra> /usr/share/gnome-pkg-tools/1/rules/check-dist.mk:19: Unknown distribution: lucid
<ogra> ... we should really fix that
<seb128> ogra, it's only a warning, the rules is to avoid to upload experimental packages to unstable
<seb128> it's of no use on ubuntu
<ogra> ah
<siretart`> any library packaging gurus around that has fun with analysing a library problem involving transitive library dependencies and symbol versioning? slangasek perhaps?
 * slangasek warbles
<ScottK> siretart`: Sounds like you need to drag sistpoty back.
<siretart`> slangasek: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/100196 is the upstream thread with full context. Michael Niedermayer is the lead of ffmpeg and claims that either the gnu linker or debian's ld is just 'too' broken for this situation
<siretart`> I try to argue against, but I cannot really call myself an expert when it comes to symbol versioning.
<slangasek> siretart`: do I have to actually read this thread, or can I just jump straight to the conclusion that ffmpeg upstream is crazy?
<siretart`> slangasek: http://article.gmane.org/gmane.comp.video.ffmpeg.devel/100343 is the relevant mail. the rest is only for full context
<siretart`> the first mail explains the exact situation, the longer thread is probably not that instersting here, it shows my results with experimenting with symbol versioning
<slangasek> siretart`: what you appear to need is not somebody who enjoys analyzing library linkage issues, what you need is someone with the time and energy to set your upstream straight
<siretart`> highlight from that mail: "Possibly RTLD_DEEPBIND could solve the problem. Drepper is quite vocal
<siretart`> on arguing against it which is a sign that this might be the right direction."
<siretart`> slangasek: I'd be willing to go that way, and actually already started to do so, but now I'm at a point where my experience with thist stuff endds
<slangasek> RTLD_DEEPBIND doesn't solve the problem, because a) it applies only to dlopen(), b) it applies to intra-library symbol lookups only
<slangasek> symbol versioning is a longstanding and well-understood solution to this problem
<slangasek> "Either way, ffmpeg isnt the only thng that seems to have been hit by this" - correct, and other libraries that get hit by this are reasonable about implementing symbol versioning
<siretart`> slangasek: thanks, that helps me to draft an answer
<mvo> kirkland: hi, are there any known issues with kvm in lucid currently? my auto-upgrade tester with the lucid kernel as host is having some trouble it seems, seems to be hanging in FUXTEX_WAIT_PRIVATE (this is with virtio in the client)
<kirkland> mvo: hmm, i haven't uploaded a new kvm yet to lucid
<siretart`> slangasek: just a last question, in http://article.gmane.org/gmane.comp.video.ffmpeg.devel/100328, I notice that some functions (av_packet_*) have been moved from libavformat to libavcodec
<kirkland> mvo: sounds like a lucid kernel bug with virtio
<siretart`> slangasek: upstream claims this move of symbols is no ABI breakage, since libavformat links against libavcodec
<siretart`> question: should libavformat's SONAME be bumped or not?
<slangasek> siretart`: should not - but your symbol versioning therefore needs to take this into account
<slangasek> otherwise, the symbol versioning /itself/ introduces an ABI break
<mvo> kirkland: thanks. probably, I was just curious if it was anything you might know about
<siretart`> I see
 * mvo will just use the karmic kernel in the meantime
<kirkland> mvo: i don't;  please file a bug, though
<mvo> ok
<soren> mvo: The guest is Lucid as well?
<mvo> soren: hardy (its currently testing hardy->lucid)
<kirkland> mvo: oh, wait ...
<kirkland> mvo: guest is hardy?
<soren> virtio is a communication channel between the guest kernel and the host userspace. I think it's extremely unlikely to be a Lucid kernel bug.
 * kirkland checks something
<kirkland> mvo: what version of qemu-kvm is on the lucid host?
<kirkland> mvo: actually, what is the host running?
<mvo> kirkland: 0.11.0-0ubuntu6.3
<mvo> oh, but kvm-source is installed, could this be the problem?
<kirkland> mvo: hmm, yeah ...  that would constrain you to running a much older kernel kvm module than karmic's
<kirkland> mvo: ie, kvm-source no longer exists in karmic
<kirkland> mvo: so you're running a jaunty-or-older kvm module
<mvo> thanks, I will remove it
<kirkland> mvo: fwiw, that version, 0ubuntu6.3 specifically fixes a problem with virtio with hardy guests
<mvo> if its actually causing problems, I can add it to update-manager so that it will ensure its getting removed on upgrade
<kirkland> mvo: cool, thanks.
<mvo> kirkland: thanks, commited
<kirkland> mvo: cheers
<kirkland> mvo: hey, i have another one for you, btw ....
<kirkland> mvo: i don't think /etc/update-motd.d/91-release_upgrade is ever being run
<kirkland> mvo: because pam_motd uses run-parts --lsbsysinit
<kirkland> mvo: which, I think, dislikes "_"
<kirkland> mvo: i *thought* i committed a fix for that sometime during karmic, but doesn't look like it's there any more
<mvo> oh, hrm. let me fix it in bzr
<kirkland> mvo: this might be worth an SRU, at some point, so that karmic users get the upgrade notification in MOTD once lucide releases
 * mvo nods
<soren> mvo: What are /var/cache/apt/{src,}pkgcache.bin for?
<mvo> soren: its the mmap cache of the package data, why?
<mvo> soren: if its not there, it will just rebuild it (or build it in memory if it can not write there)
<soren> mvo: I just noticed it's taking up 24 MB of space in my VM images.
<soren> mvo: That's what I wanted to hear. Yay.
 * soren fiddles with vmbuilder some more
<soren> mvo: Thanks.
<mvo> :)
<ScottK> cjwatson: I have a couple of more questions about the kubuntu packageset.  Do you have a preferred venue for such discussion?
<cody-somerville> pitti, did you ping me?
<cjwatson> ScottK: u-d's fine
<ScottK> Thanks.
<pitti> cody-somerville: hm, can't remember any more
<kirkland> pitti: how often does http://www.piware.de/workitems/server/lucid-alpha2/report.html run?
<pitti> kirkland: hourly every :12
<kirkland> pitti: cool, thanks
<pitti> but of course feel free to poke me if I should do a manual run
<slangasek> pitti: eep, why does http://piware.de/workitems/foundations/lucid/report.html think there are 105 work items for https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-distributed-development ?
<pitti> hm, looks more like 50
<slangasek> 35, by my count
<pitti> slangasek: looks like a big; I'll have a look soon, thanks for pointing out
<pitti> a bug, too
<pitti> "too big" bug
<cjwatson> pitti: that's odd, my local version shows 35
<pitti> I hope it's not a weird bug in lenny's sqlite
<dtchen> slangasek: (WRT AD1981 and powerdown pop) thanks. I'd appreciate your confirmation, but it isn't pressing; asac has also confirmed on his codec. It affects the linux patch I'm working on.
<slangasek> dtchen: ok, cheers
<Keybuk> slangasek, kirkland, soren: FYI you should never need to use that "reload-configuration" thing
<Keybuk> it's there for people who compile inotify out of their kernel
<soren>  Ah.
<slangasek> okie
<kirkland> Keybuk: hrm...  so inotify picks up changes to /etc/init automatically in karmic?
<kirkland> Keybuk: and if it doesn't, is it a bug?
<soren> Yes.
<slangasek> kirkland: yes, but you still have the issue of job != jb
<slangasek> job
<Keybuk> Upstart (and its test suite) are very good at finding inotify kernel bugs ;)
<Keybuk> right
<soren> kirkland: It does notice changes in /etc/init, but it considers a changed file a new job, not a change to the old job.
<Keybuk> the strange behaviour that kirkland was having is because "restart JOB" restarts the running job
<Keybuk> with the configuration it had when it was first started
<kirkland> Keybuk: so stop/start != restart
<Keybuk> kirkland: right
<soren> Precisely.
<Keybuk> if stop/start == restart, there wouldn't be a restart ;)
<kirkland> Keybuk: ah
<kirkland> Keybuk: a little non-intuitive, but now I know
<Keybuk> for example
<Keybuk> restart might not run the pre-stop/post-stop/pre-start/post-start scripts
<Keybuk> it does right now, but that's not a guaranteed thing
<Keybuk> restart might just kill and respawn the daemon itself
<Keybuk> I'm not entirely sure that this is desired behaviour or not
<Keybuk> I added restart quite late in 0.6
<Keybuk> and didn't anticipate it's odd behaviour
<Keybuk> it was put in as an atomic stop/start
<Keybuk> and the whole "doesn't use the new config" thing is a side-effect
<kirkland> Keybuk: well, my natural expectation was that restart would reload all configurations, in between stop and start
<kirkland> Keybuk: perhaps that's just an uneducated expectation
<Keybuk> kirkland: not necessarily
<Keybuk> it may be an uneducated implementation :p
<ttx> pitti: about http://piware.de/workitems/server/lucid-alpha2/report.html, some strange things
<ttx> pitti: shows 272 wi for canonical-application-support, while there are only 79 in the whiteboard
<pitti> ttx: seems to be the same problem that slangasek was pointing out above; I'll have a look now, I'm done with my previous task
<ttx> ah sorry for the duplicate :)
<mvo> free: I have my dapper VM running now, but I was not able to reproduce the hashsum issue (both with interactive, non-interactive, archive.u.c and it.archive.u.c :/
<pitti> ttx: no worries, I'm glad that it is a dupe :)
<free> mvo: ah :/
<free> mvo: I'll ask other Landscapers to test the same too see if we can reproduce it
<free> mvo: thanks for now
<pitti> ttx: or later on, rather; got a conf call in 5
<kirkland> Keybuk: i think what you've described is more what i'd expect from an init "reload" action
<kirkland> Keybuk: for an init "restart", i'd expect the job to stop and start again
<mvo> free: thanks
<kirkland> Keybuk: doing whatever is involved with both "stopping" and "starting" the process
<Keybuk> right
<Keybuk> that's what it does
<Keybuk> but the problem here is the definition of "the job" :)
<free> mvo: btw, what is the timeframe for the .cfg.dapper fix to be published in the meta-release file?
<mvo> kirkland: kvm seems to be much more reliable now, but also much slower (same test, hardy->lucid on a lucid system). nothing to worry about just yet, I keep a eye on it
<kirkland> mvo: hmm...  are you sure you're running with kvm acceleration?
<mvo> free: no schedule for this yet, if you manage the upgrade with landscape and do the unpacking yourself, you might as well just add it yourself into the config, that will be much quicker than doing a SRU
<kirkland> mvo: and are you sure that virtio is working?
<kirkland> mvo: did you reboot after uninstalling kvm-source?
<free> mvo: I see, sounds reasonable
<kirkland> mvo: what does kvm-ok say?
<mvo> kirkland: it used to warn me when kvm was not available, it did not complain
<mvo> kirkland: kvm-ok> neat! does not complain either
 * mvo was not aware of kvm-ok
<slangasek> Keybuk: you marked "package plymouth" done as a work item, but I haven't seen it land in lucid yet, nor in the new queue?  (also blocks my cryptsetup upload, so just wondering when that's going to land - not urgent)
<Keybuk> hand intended it to land a couple of days ago
<Keybuk> but been off obviously
<Keybuk> and found bugs in the meantime
<Keybuk> I'll probably work on that tomorrow
<slangasek> okie
<Keybuk> too many other things being distracting today
<davmor2> okay come on own up who put shiny stuff out side keybuk's
<Keybuk> sadly not shiny
<ion> keybuk: Can you push your current stuff to some public repository? Dunno whether iâll get around to implementing the selectable-progress/input-dialogs-from-programs thing, but having plymouth code that already builds and more or less integrates with my lucid system would be a motivator. :-P
<Keybuk> ion: what current stuff?
<Keybuk> plymouth is pushed
<cjwatson> Keybuk: do we want ureadahead in the required seed (i.e. do we want it on server installs)? it's priority: required but currently due for demotion
<Keybuk> cjwatson: yes, it should be in server
<Keybuk> ion: https://code.launchpad.net/ubuntu/+source/plymouth
<cjwatson> I'll seed it then. thanks. (hmm, perhaps minimal rather than required though; first-stage debootstrap doesn't need it)
<cjwatson> so that'll make it prio: important
<Keybuk> cjwatson: I think I just guessed at priority ;)
<cjwatson> required is the stuff that needs to be dpkg -x'd in the first stage of debootstrap
<ion> keybuk: Ah, thanks. I had only checked apt-cache showsrc plymouth.
<cjwatson> actually - standard would be fine, thinking about it
<cjwatson> but I think I'll put it in minimal anyway to propagate it as widely as possible
<CarlFK> seb128: bug 491732 "fixed upstream in git now!" - what is the schedule for it hitting the repo?  and is this the place I would watch: https://edge.launchpad.net/ubuntu/+source/gtk+2.0
<ubottu> Launchpad bug 491732 in gtk+2.0 "GDK_BUTTON_MOTION_MASK appears to be broken" [Medium,Fix committed] https://launchpad.net/bugs/491732
<CarlFK> no hurry, I just want to know when to test that the app it depends on (dvswitch) works
<seb128> CarlFK, not sure it will go in karmic, lucid did you check if 2.19.1 has it?
<pitti> ttx, slangasek: work items by assignee fixed; was a bad SQL join
<LucidFox> Er... I uploaded qutim to NEW three times in a row, could someone nuke the earlier two uploads?
<ttx> pitti: ok, thx
<pitti> LucidFox: done
<LucidFox> Danke.
<CarlFK> seb128: gtk resolution "Fixed in master (b509f28559dba03684ecc88acac498b6f27d2ebf) and on the 2.18 branch."  I assume that means 2.19.1 has it
<seb128> CarlFK, well depends if that commit was before or after tarball
<CarlFK> seb128:  patch date  Wed, 02 Dec 2009 10:09:37 +0000  so 'yesterday'
<seb128> so no
<CarlFK> if I get gtk to back port it to 2.16, is there a chance it can get into karmic?
<CarlFK> does it matter that I need this so I can record Suttleworth ?  it shouldn't, but it's kinda funny:)
<CarlFK> oh wait.. I am not sure if karmic is using 2.16 or .18... checking
<pitti> cjwatson: "status by work item" -> sweet, thanks!
<cjwatson> works for me ... :-)
<seb128> CarlFK, 2.18 it uses
<seb128> CarlFK, I guess it could yes
<CarlFK> seb128: anything I can do to push it along?
<seb128> add a debdiff to the bug?
<seb128> and do the sru work
<seb128> ie add a testcase, etc
<CarlFK> debdiff and testcase - no prob.  whats is sru?
<seb128> CarlFK, stable release update
<seb128> CarlFK, https://wiki.ubuntu.com/StableReleaseUpdates
<CarlFK> seb128:  got it - thanks
<seb128> np, thank you for looking at the issue
<sleepy> in theater huh ? interesting
<cody-somerville> pitti, did you get my question the other day about launchpad-registry being a member of ubuntu-sru?
<cody-somerville> Cody A.W. Somerville  â Canonical Launchpad Engineering  â Registry Administrators  â Ubuntu Stable Release Updates Team
<ScottK> Cool.
<ScottK> You can approve all my SRUs then.
<micahg> pitti: I just attached the debdiff for the apport bug 476513 if you wanted to push it through...
<ubottu> Launchpad bug 476513 in apport "/etc/default/apport comment outdated" [Undecided,Fix released] https://launchpad.net/bugs/476513
<pitti> cody-somerville: I got your q, but I don't know the answer
<RoAkSoAx> slangasek, I was wondering when are the daily builds for the Ubuntu Server ISO restart?
<ScottK> RoAkSoAx: It's more a question of when they will succeed.
<enzotib> Hi, can I ask a question about package dependences and automatically installed packages?
<RoAkSoAx> ScottK, ah! so its still "that" broken then
<tjaalton> how often does the autosyncer run?
<pitti> tjaalton: it's not automated; an archive admin has to run it
<pitti> since it falls apart very often, it's actually a fairly interactive process
<tjaalton> pitti: ah ok
<pitti> cjwatson: would you know which team membership/privilege bit is necessary to be able to prioritize specs? dbarth can't prioritize dx-lucid-* specs himself
<pitti> cjwatson: is that ubuntu-drivers?
<Eren> kees, hello
<Eren> kees, it seems that mitre isn't informed about the issue
<kees> Eren: privmsg please
* mbarnett changed the topic of #ubuntu-devel to: **Launchpad will be down/in read-only from 22:00 UTC until 23:30 UTC for a code update**Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-b
* mbarnett changed the topic of #ubuntu-devel to: || Launchpad will be down/in read-only from 22:00 UTC until 23:30 UTC for a code update || Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubunt
<mpt> robbiew, I've now specced all except one of the features listed on <https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-software-center-ui-improvements>
<robbiew> mpt: okay, thank you
<mpt> robbiew, does <https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-ratings-and-reviews-in-software-center> need any more detail for approval from the Ubuntu side?
* mbarnett changed the topic of #ubuntu-devel to: || Launchpad will be down/in read-only from 23:00 UTC until 23:45 UTC for a code update ||Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubunt
<robbiew> mpt: I can approve it
<mpt> mbarnett, there's no such channel as #ubunt :-)
<mpt> thanks robbiew, I will draw and attach a diagram of the rating/review dialog tomorrow but it's 10.30pm here now
<Tm_T> mpt: there is, join and see
<mpt> Tm_T, there wasn't three minutes ago, anyway
<Tm_T> mpt: (:
* mbarnett changed the topic of #ubuntu-devel to: || Launchpad will be down/in read-only from 23:00 UTC until 23:45 UTC for a code update ||Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu
<mbarnett> it really likes to truncate that message
<slangasek> I'm pretty sure that used to say something more than "see #ubuntu" :)
<Tm_T> for support or something
<Tm_T> but it hits the maxlength
* mbarnett changed the topic of #ubuntu-devel to: || Launchpad will be down/in read-only from 23:00 UTC until 23:45 UTC for a code update ||Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu
* slangasek changed the topic of #ubuntu-devel to: || Launchpad will be down/in read-only from 23:00 UTC until 23:45 UTC for a code update ||Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs 
<slangasek> closer ;)
<mbarnett> yeah, that is as long as it allows
<mbarnett> See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<mbarnett> is what used to be there
<ajmitch> the info about 9.10 being released probably isn't needed now
* mpt changed the topic of #ubuntu-devel to: ## Launchpad will be down/read-only from 23:00~2345 UTC for a code update ||Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs
<mbarnett> once the outage is done i swear i will set it back
* slangasek changed the topic of #ubuntu-devel to: || Launchpad down/read-only 23:00-23:45 UTC for a code update ||Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com
* slangasek changed the topic of #ubuntu-devel to: || Launchpad down/read-only 23:00-23:45 UTC for a code update || Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<slangasek> there :)
<mbarnett> whee!
<mpt> What does "See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs" mean anyway? :-P
<mbarnett> i think you are suppoosed to parse the end of that url
<mbarnett> mentally
<mpt> and ignore the protocol and hostname
<slangasek> or use moin as your IRC client
 * mpt -> home now, really
<cjwatson> pitti: prioritise specs> I think it's drivers, yes
#ubuntu-devel 2009-12-04
<RoAkSoAx> hey guys vol_id has been dropped for karmic, correct?
<dtchen> RoAkSoAx: correct. See the udev changelog entry for 141-2+git4a74214.
* mbarnett changed the topic of #ubuntu-devel to: || Launchpad down/read-only 23:00-05:00 UTC for a code update || Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
* mbarnett changed the topic of #ubuntu-devel to: Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<LucidFox> I'm rather shocked nobody seems to have packaged clang for Debian or Ubuntu yet
<RAOF> Yeah, I was a bit surprised, too.
<LucidFox> There's an ITP in Debian, though.
<pitti> Good morning
<micahg> morning pitti
<micahg> thank you for sponsoring my patch :)
<pitti> you're welcome
<dholbach> good morning
<ttx> pitti: hey -- I was wondering if you planned to add "by assignee" workitems report at some point
<ttx> sometimes it's difficult to get a picture of where you stand, especially if you have work items assigned from several teams
<pitti> ttx: like the ones that we have since yesterday?
<pitti> ttx: http://piware.de/workitems/server/lucid/report.html, "Status by work item"
<ttx> pitti: not exactly
<pitti> ttx: it's per team right now indeed, there's no global by-assignee report yet
<pitti> (it's a little trickier to do, since there are separate DBs for each team; not really hard, though)
<ttx> pitti: I was thinking about "my own burndown chart" grouping items from all projects, whatever team they belong in
<ttx> i.e. "am I late ?" rather than "is this project late ?"
<seb128> hey
<seb128> did yesterday's evening upload got accepted but silently dropped?
 * seb128 uploaded some packages while launchpad was supposed to be in update and those got accepted for upload but dropped apparently
<seb128> I wonder if I should upload again
<pitti> seb128: reuploading worked for me
<pitti> my gnome-menus upload last night was silently dropped, too
<seb128> grrr
<seb128> I'm not sure I kept sources for all the uploads I did
<seb128> screw you launchpad
<seb128> and I'm not sure which ones got dropped now
<pitti> seb128: check the "accepted" mails?
<seb128> pitti, didn't got those
<pitti> then you can safely assume that all got dropped
<seb128> launchpad just dropped the uplaods silently
<seb128> well I managed to pass some before shutdown
<seb128> but I'm not which rebuilds I did exactly for gir now
<seb128> anyway, let me think about what I did ;-)
<seb128> that will teach me to work after hours
<LucidFox> seb128, I noticed that the recent upload of gnome-shell depwaited on the Debian version of gjs, so I merged it.
<seb128> LucidFox, I did that yesterday but it got dropped cf log
<LucidFox> Weird
<seb128> LucidFox, I reuploaded my version now, yours was bugged
 * LucidFox nods
<seb128> LucidFox, thanks anyway
<LucidFox> Out of interest, how was it bugged?
<seb128> didn't use replaces or conflict
<seb128> debian uses different name
<seb128> it wouldn't install because it conflict with the ubuntu gsj-dev
<seb128> gjs
<LucidFox> ...Oh.
<seb128> or rather install would break on file conflict
<micahg> pitti: any idea when the my apport fix will go to proposed?
<pitti> micahg: soon
<micahg> pitti: ok :)
<micahg> it's hard to triage crashes without apport :)
<LucidFox> mc must have the weirdest build system I have seen.
<LucidFox> Debian build system, not upstream. debian/rocks, "Colin's Build System"...
<seb128> pitti, so our libx11 is too old
<pitti> tjaalton: is there a newer libx11-dev available, or should we sync from Debian?
<seb128> some things you synced don't build
<seb128> that break gtk installability
<seb128> and all desktopish builds
<pitti> there are also quite some bits in NEW
<pitti> (metacity, gir, etc.)
<seb128> libxinerama failed to build too
<seb128> which is part of the issue
<seb128> https://edge.launchpad.net/ubuntu/+source/libxinerama/2:1.1-1/+build/1378080
<seb128> I'm wondering if some build-depends are not tight enough
<pitti> this looks more like a missing b-dep?
<pitti> most syncs were requested by bryce and tjaalton, so they should have gotten the mail spam
<seb128> ok, my mailbox got flooded during night
<seb128> none of my uploads from this night built
<seb128> I guess we just have to wait for tjaalton or bryce to be around now
<pitti> I give back xinerama
<seb128> thanks
<seb128> we will need to sort the libx11 question though
<tjaalton> pitti, seb128: once libxext is in the archive I'll file rebuilds
<seb128> tjaalton, things depwait on a newer libx11 that the one we have too
<tjaalton> pitti: I'm merging libx11, there's one change that apparently needs to be preserved
<seb128> tjaalton, thanks
<pitti> great, thanks
<pitti> tjaalton: "file" -> just ping on IRC
<pitti> with a list of packages to retry (no commas)
<tjaalton> pitti: ok
<pitti> tjaalton: or just use the ubuntu-dev-tools "buildd" script yourself
<pitti> buildd package lucid retry
<tjaalton> the reason for the failed builds was that we had a newer libxext than what the new x11proto-xext Breaks, so they weren't held in the queue
<tjaalton> pitti:  oh cool
<pitti> $ cat /home/martin/bin/giveback
<pitti> #!/bin/sh
<pitti> for i in $@; do
<pitti> buildd $i lucid retry
<pitti> done
<pitti> ^ for even lazier people :)
<tjaalton> pitti: hehe, I'll steal that one :)
<tjaalton> hmm, libxext was built 2h ago but still not in the archive..
<tjaalton> pitti: who is responsible for the publisher? there is certainly something wrong with it, since built packages are not being pushed to the archive
<cjwatson> 2009-12-04 09:03:20 DEBUG   Publishing custom gnome-menus, gnome-menus_2.28.0.1-0ubuntu3_sparc_translations.tar.gz to ubuntu/lucid
<cjwatson> 2009-12-04 09:03:20 ERROR   Failure processing queue_item 1460701
<cjwatson>  -> http://launchpadlibrarian.net/36423030/bDF1qc8NVJ5FX6mGghGbd19C93f.txt (permission denied for relation translationgroup
<cjwatson> )
<cjwatson> I'll follow up with the Soyuz people
<tjaalton> thanks :)
<cjwatson> tjaalton: looking happier now ... (thank bigjools)
<tjaalton> cjwatson: great
<ttx> cjwatson: hey -- I had a couple questions for you about the SC announcement (that affect how I'll do the NC announcement)
<ttx> cjwatson: If we are to follow spec we should publish when eucalyptus-sc in installed and sshd is running. Currently its run at eucalyptus-sc start.
<ttx> cjwatson: Any plans to upstartify openssh-server ? :)
<cjwatson> ttx: upstartifying openssh-server is dependent on upstart being able to function reasonably in a chroot
<ttx> cjwatson: so we would fix the announcements later, when that support is added ?
<cjwatson> Keybuk: ^- is that planned for lucid?
<ttx> cjwatson: Question #2: It's better if SC announces "I'm an SC for cluster FOO", so adding a dest="CLUSTERNAME" thing in the TXT record.
<ttx> cjwatson: Is that destination info currently propagated by the installer in one of the /etc/eucalyptus files ?
<cjwatson> I suppose I could hackily ship both an upstart job *and* an init script somehow ...
<cjwatson> ttx: yes, eucalyptus-cc.conf
<cjwatson> ttx: see eucalyptus bzr
<cjwatson> I've already done this :)
<ttx> cjwatson: ok, I thought that file didn't get installed on the SC and the NC, will check
<cjwatson> I actually added a eucalyptus-sc.conf with the same info
<Keybuk> cjwatson: no
<cjwatson> Keybuk: ok, any suggestions for how to best satisfy what the server team need for euca?
<Keybuk> I don't know what the server team need
<cjwatson> it's encapsulated quite accurately in the last couple of dozen lines of scrollback
<ttx> Keybuk: we want to write an upstart job that is started "when sshd is running"
<Keybuk> cjwatson: why not make an upstart ssh job?
<cjwatson> because sshd is very commonly run in chroots
<cjwatson> and I will not break that
<Keybuk> fair enough
<cjwatson> so if there's a way to upstartify it without breaking chroot operation as well, that would be OK; e.g. shipping the init script as well
<Keybuk> no idea
<Keybuk> don't really care
<ttx> cjwatson: I guess the publication upstart script could loop/test for sshd existence before publishing.
<cjwatson> ttx: let me see if I can get openssh to DTRT somehow
<ttx> cjwatson: ok :)
<ttx> cjwatson: I looked at eucalyptus-sc.conf... Would eucalyptus/cluster-name also be available to the NC installer ? i.e. can I add a eucalyptus-nc.postinst to put the destination cluster-name in a eucalyptus-nc.conf file ?
<ttx> cjwatson: the intended behavior being, existing cluster is detected, select NodeController install, end up with the detected cluster name in a file on the NC.
<ttx> ... so that I can pick it up when announcing "I'm an NC for cluster foo"
<cjwatson> ttx: it won't actually quite work yet for the SC anyway :) we'll need to arrange for it to be preseeded, so we can do the same thing for the NC
<ttx> cjwatson: right. I'll do a placeholder announcement, sufficient to test the autoregistration, and we'll refine later
<cjwatson> ttx: fixed it to preseed eucalyptus/cluster-name now
<cjwatson> ttx: so you can just copy the same bit from eucalyptus-sc.{postinst,templates}
<perecastanyersar> hi all only one question:
<perecastanyersar> If I need to download a package from ubuntu hardy partner..where I must go?
<ttx> cjwatson: cool thx
<cjwatson> perecastanyersar: 'deb http://archive.canonical.com/ubuntu hardy partner' in /etc/apt/sources.list
<perecastanyersar> how I can download the package from apt? it's the -d option? apt don't listen to me
<cjwatson> perecastanyersar: 'aptitude download' is the most straightforward
<perecastanyersar> ah thanks i'll try
<cjwatson> perecastanyersar: 'apt-get -d install <package>' will do it too but will leave the package in /var/cache/apt/archives/ rather than in the current directory
<perecastanyersar> I'm trying to install the IDS from partner ubuntu sources: sudo apt-get install informix-ids-demo (for amd64)
<perecastanyersar> and apt-says that need a dependency from informix-ids...that is a package that is missing in the repository
<perecastanyersar> any ideas how I can install informix from partner sources?
<cjwatson> perecastanyersar: looks like it's only available for i386. You should file a bug
<tjaalton> pitti: buildd says "Unable to find source package 'libxinerama' in the Lucid-release pocket." and the same for every package I try
<tjaalton> oh well, lunch ->
<cjwatson> Keybuk,slangasek: is it just me or is /usr/share/debhelper/autoscripts/postinst-upstart-restart wrong? it starts with 'if [ -x "/etc/init.d/#JOB#" ]; then' ...
<cjwatson> and indeed it doesn't seem to be adjusted for upstart at all
<cjwatson> is it relying on the upstart-job stuff or something?
<Keybuk> might be
<Keybuk> dunno
<ogra> hmm, could someone promote libicu42 and friends ?
<ogra> seems webkit FTBFS on armel because of it missing in main
<cjwatson> ogra: done
<cjwatson> (architecture mismatch)
<ogra> thanks
 * ogra waits for the publisher until giving back webkit ...
<seb128> tjaalton, how are things going with libx11?
<tjaalton> seb128: I could upload it now, since libxext is in the archive
<seb128> do it then! ;-)
<tjaalton> surely :)
<seb128> thanks
<pitti> tjaalton: hm, weird; works for me here
<cjwatson> pitti: can you reset the foundations db please? modulo one or two glitches (esp. the upstart server review) we're done with work items
<pitti> cjwatson: just ditch the db, so that it starts back from 0?
<pitti> tjaalton: hm, works here; given back
<cjwatson> well, whatever you normally do when teams are finished preparing WIs
<cjwatson> if you want to just restart the graph position, that's fine too
<pitti> easier to delete the db; done, and regenerating now
<pitti> cjwatson: done
<tjaalton> pitti: it seems to work on my lucid laptop, but not on jaunty desktop
<cjwatson> thanks
<ogra> hmm, whats up with gstreamer ?
<seb128> what do you mean?
<fagan> ogra: whats wrong with it?
<ogra> gstreamer and gst-plugins-bade are all dep wait
<ogra> http://qa.ubuntuwire.org/ftbfs/
<seb128> gstreamer is not depwait
<seb128> your webpage is buggy or outdated
<ogra> https://launchpad.net/ubuntu/+source/gst-plugins-base0.10/0.10.25-5 didnt build
<seb128> yes
<seb128> xorg breakage
<seb128> tjaalton just uploaded libx11
<ogra> ah, k
<seb128> that should make gtk installable again...
 * ogra will just wait then
<seb128> then we can retry desktop things
<ogra> yep, understood
<ogra> thanks 1
<ogra> !
<seb128> you're welcome
<cjwatson> Keybuk: I think I've confused upstart somehow. 'sudo start ssh' hangs; 'initctl log-priority debug' shows "init: ssh goal changed from stop to start" in syslog but that's about it
<cjwatson> Keybuk: http://paste.ubuntu.com/334466/ is the configuration file
<Keybuk> bug 406397 probably
<ubottu> Launchpad bug 406397 in upstart "init: job stuck with expect fork/daemon when parent reaps child" [Low,Triaged] https://launchpad.net/bugs/406397
<Keybuk> for a start
<Keybuk> your "script" calls grep
<Keybuk> so Upstart will follow that fork, and get the pid of grep
<cjwatson> ah, could be. in my previous version of the job, I forgot the 'exec'
<cjwatson> oh, even with 'expect daemon'?
<Keybuk> why are you mucking with OOM_ADJ like that ?!
<cjwatson> because I forgot that upstart supported it :)
<Keybuk> :D
<Keybuk> oom -17
<Keybuk> should just dtrt
<cjwatson> is there a way to deconfuse upstart without rebooting at this point?
<cjwatson> yeah
<Keybuk> "oom never" actually I think you mean
<Keybuk> no
<Keybuk> you have to reboot at this point
<cjwatson> ok, thanks
<shankhs> what is a template for packaging? Please.
<shankhs> i know dh-make is used to create template
<shankhs> i am a noob
<Keybuk> shankhs: -> #ubuntu-motu
<shankhs> Keybuk: thanx
<pitti> Keybuk: does bug 491162 ring a bell for you?
<ubottu> Launchpad bug 491162 in gdm "gdm does not start X unless remove "tty-device-added KERNEL=tty7" from upstart gdm.conf" [High,New] https://launchpad.net/bugs/491162
<Keybuk> pitti: the bug description is wrong
<Keybuk> there are lots of problems with the gdm start on line
<dpm> pitti, I'm looking at http://piware.de/workitems/community/lucid/report.html and I can't get some of the other community blueprints to show up there. For example, https://blueprints.launchpad.net/ubuntu/+spec/community-lucid-community-participation-in-coordinating-translations is there anything else needed to do to get blueprints picked up?
<pitti> dpm: right, that's only "proposed" for lucid, not accepted
<pitti> done now
<dpm> pitti, ah, I see, thanks, I'll get jono to accept the rest.
<daanemanz> hi all, does anyone know where I can find the source code for php5-uuid?
<daanemanz> installing using pecl doesn't work
<ogra> pitti, report.html should have a link somewhere on the page to https://wiki.ubuntu.com/WorkItemsHowto
<mdz> kane_, hi
<doko_> seb128: do you know why the cairo/gtk/xtst -dev packages are not installable?
<seb128> doko_, because of the zillion xorg lib synced yesterday didn't build it
<seb128> the new libxi conflicted with other updates
<seb128> and depended on the new libx11 that tjaalton uploaded some hours ago
<seb128> should be sorting itself now
<pitti> new libx11 is published, anyway
<pitti> just getting it through dist-upgrade
<seb128> pitti, gtk installability fixed now indeed
<ogra> seb128, anything i need to give back on arm ?
<seb128> ogra, not that I know, I'm giving back things on all archs
<ogra> k, thanks ...
<ogra> feel free to dump such stuff on me for armel at least if you dont find the time in the future ...
<seb128> ok
<Keybuk> pitti: so what's actually wrong with the whole floppy thing?
<pitti> Keybuk: if only I knew -- I asked for ssh access on a machine with a floppy
<Keybuk> I have a machine with a floppy drive
<pitti> I haven't had a working one in 5 years
<Keybuk> no floppy disks though ;)
<Keybuk> but if I select Floppy from the Places menu, the little light comes on and it goes KER-CHUNK-THUNK for a second
<pitti> I see the reason why it can't work in a stock karmic -- blkid is never called
<pitti> but I don't see why it still doesn't work even with that extra testing rule
<Keybuk> why does blkid need to be called?
<pitti> to tell dk-disks that there's an useful fs on it, and gvfs that there's a volume available
<Keybuk> why does it need to  know that?
<Keybuk> mount -t auto ? :p
<Keybuk> if I see any floppy disks for sale, I'll pick one up and put it in the drive, then you can ssh in and play
<pitti> sale? haha
<ogra> lol
<pitti> well, I might still have some deeply buried in my cellar
<pitti> but no drive to put them into
<Keybuk> yeah I have the drive but no disks :p
<pitti> I still have a zip drive, though :) (not used in years either)
 * ogra has a box behind him on the shelf ... no drive either 
<ogra> though i have a usb drive but it registers as /dev/sdX
 * pitti -> meeting
<Keybuk> I don't think I have _ever_ used the drive
<mjr> just about any hd-lookalike will register as sdX these days
<pitti> given my salary rate, it'd probably be ten times cheaper to just ship that poor guy an usb key instead of spending half a day fixing floppies :)
<pitti> "there, fits 40.000 floppies"
<Keybuk> ROFL
<Keybuk> "Economics, with pitti"
<ogra> mjr, well, its a floppy drive :)
<mjr> oh *blink*
<mjr> makes sense though
<gorgapor>  how would I find out where the gnome-terminal color schemes are located, like tango, rxvt, xterm, linux console, etc? I'm sure they are some xml file somewhere, but I can't find them
<sebner> pitti: poor you! devicekit-* gets renamed. surely a bad transition for everyone :\
<pitti> sebner: I heard; I proposed the name :)
<sebner> pitti: ahahaha!!!!!!!!
<pitti> sebner: it's actually not too bad, only two or so rdepends
<pitti> sebner: well, I didn't decide _that_ to rename it :)
<sebner> pitti: oh fine than but for upstream projects ...
<pitti> I just avoided having it called "disks"
<pitti> yeah, it's a bit hairy for those; OTOH, gdu'sagvfs' API didn't change at all, which is what most apps really want to use
<sebner> heh
<pitti> argh, what did I write
<pitti> "gdu's and gvfs'"
<maco> renamed to...?
<pitti> udisks
<sebner> pitti: fine thenm, and with plymouth we are on the edge again :D (kernel guys decided to be funstoppers though :P)
<Keybuk> pitti: wow
<Keybuk> you're quite right
<Keybuk> we should have totally named udisks in Klingon instead!
<pitti> you found a translation for it? :-)
<maco> Keybuk: then we'd be red hat
<maco> (since someone in here, i think you, was recently complaining about opaque red hat naming)
<pitti> oh, gdu'sagvfs'
<ogra> when did redhat step back from all the kit names ?
<ogra> shouldnt it be udiskit ?
<pitti> isn't that "mount my disk now or I'll slice your throat"?
<pitti> ogra: David wants to get away from that
<ogra> haha
<Keybuk> DaHmeyjaj!
<ogra> i guess he gets tired of all the jokes
<Keybuk> (lit. many good arrays :p)
<Keybuk> ogra: s/redhat/David/
<ogra> indeed
<Keybuk> RH's preferred naming scheme of the week is "towns in MA"
<ogra> as long as they dont start using animals :)
<pitti> Keybuk: hm, "jaj" is "day", isn't it?
<Keybuk> I thought -jaj was the good suffic
<Keybuk> though google says it means "May"
 * pitti looks for his muhaQwi
<ion> keybuk, pitti: http://www.youtube.com/watch?v=LBtj4WoC6XA
<pitti> lol
<mdz> cjwatson, the fix for bug 364649 was not evident in my server test install
<ubottu> Launchpad bug 364649 in ubiquity "Please include installation media build number in installation logs" [Wishlist,Fix released] https://launchpad.net/bugs/364649
<mdz> there's no /var/log/installer/media-info
<Keybuk> ion: heard that before ;)
<Keybuk> ion: he does a fun Metal version of the Klingon Anthem (Qoy qeylIs puqloD)
<mdz> cjwatson, should I file a new bug or reopen that one?
<cjwatson> mdz: please reopen it; I see the problem (it tries to copy /cdrom/.disk/info after /cdrom is unmounted)
<mdz> cjwatson, so it will not have worked in 9.10 either?
<cjwatson> correct :-/
<cjwatson> ubiquity should still have been fine
<Keybuk> huh
<Keybuk> that's odd
<Keybuk> I definitely see a /var/log/installer/media-info from u6y
<Keybuk> in fact, I rely on it :p
<cjwatson> "ubiquity should still have been fine"
<cjwatson> it's d-i that's broken
<Keybuk> ah, I was misunderstanding your use of "should"
<cjwatson> mdz: actually, if you haven't reopened it already, the simplest fix is in cdrom-detect, if you could give me a new task there
<Keybuk> and affirming that u6y *does* work fine :p
<mdz> cjwatson, can do
<cjwatson> mdz: fixed, sorry about that
<mdz> cjwatson, no worries. did the ubiquity part take?
<cjwatson> mdz: yes, as Keybuk confirmed above
<mdz> ah, missed that,
<mdz> and as you said as well
 * mdz curses multitasking
<tripzero> any idea when ubuntu will be getting a 2.6.31.{5,6} backport?
<tripzero> ubuntu 9.10*
<kees> asac: around?
<seb128> is merges.ubuntu.com supposed to be regularly updated?
<vimpulse> hi all.  I think that when Xorg is running, Control+Alt+Delete should pop up the Linux task manager.  That's what users migrating from Windows will expect.  What do you think?
<maco> i think ctrl alt del means reboot in the *nix world
<vimpulse> maco:  I think not in Xorg
<vimpulse> maco:  also, Ctrl+Alt+Delete used to mean reboot in the Microsoft world, then MSFT changed it.  You can change it too.  :)
<maco> wouldnt it be confusing if in X it gave you a task list but in a shell, instead of top it rebooted you?
<maco> seems like a good way to lose your data
<vimpulse> maco:  true.  I didn't think of that.
<vimpulse> maco:  is there a way to prevent mode errors like the one you described?  Maybe the init maintainer could change init to listen for a different reboot key combo other than Control+Alt+Del?
<maco> dunno about that
<vimpulse> anyone?
<Smwn> VAGINA!
<vimpulse> cjwatson:  thanks.  :)
<ikonia> cjwatson: thank you
<slangasek> cjwatson: postinst-upstart-restart> - this is deliberate, see the 7.3.15ubuntu3 changelog entry for debhelper
<cjwatson> slangasek: ah. thanks
<smoser> slangasek, around?
<slangasek> smoser: hi
<smoser> you have thoughts ... i have to make a -desktop version for uec
<smoser> for where i put it, i think /srv/ec2-images/uec-desktop/{karmic,hardy,lucid}/YYYYMMDD
<smoser> rather than intermingling output with the -server stuff , which is in
<smoser>  /srv/ec2-images/{karmic,hardy,lucid}/YYYYMMDD
<smoser> does that sound right to you?
<vimpulse> maco:  here's an idea.  Ctrl+Alt+Delete should not start up the task manager, since that would lead to mode errors.  But it should make an xmessage pop up telling users how they *can* start the task manager.
<vimpulse> maco:  also, if it doesn't already, then Ctrl+Shift+Esc should cause the task manager to pop up.
<smoser> slangasek, ^
<slangasek> smoser: that seems reasonable
<smoser> ok. thanks. and since i've got you here, could you read over the command at https://wiki.ubuntu.com/UEC/Images/Publishing "for-project ubuntu publish-release" ...
<smoser> to make sure it is sane
<vimpulse> maco:  gtg.  you can email me at jspiro at jspiro dot com
<slangasek> smoser: mm, will be a bit before I can get to it; heading out to lunch shortly
<superm1> can we sync v3 source packages now with the new launchpad?
<smoser> no problem. thanks slangasek
<cjwatson> superm1: sadly apparently that slipped to the *next* lp release
<superm1> boo :(
<superm1> and i don't suppose there's any chance for an out of band update for it then
<crypt-0> hi
<crypt-0> if i select a diffrent device other than the primary hard rive for /boot will grub and the MBR be installed to that device?
<cjwatson> sort of. it isn't reliable right now. I have plans to fix that for lucid
<Flannel> Did ubiquity (or any installer) get some fancy "I'm going to install -pae even though its not on the CD because you have 4GB of RAM" feature?
<cjwatson> yes
<Flannel> cjwatson: How does one disable it?
<crypt-0> cjwatson, is there a way to manually install it ?
<cjwatson> Flannel: not sure you can right now short of installing without a network attached, sorry
<cjwatson> crypt-0: sure, grub-install ...
<Flannel> Right, that's what I just suggested he do.
<Flannel> cjwatson: Please fix that!
<crypt-0> i want it to be reliable, because i want to be able to boot my primary HD from a usb stick
<cjwatson> Flannel: why?
<cjwatson> I mean, what active problem is it causing?
<Flannel> cjwatson: Because -pae kernel panics for him
<cjwatson> then surely to goodness that should be fixed in the -pae kernel
<Flannel> True, but having a system is important in the meantime.
<cjwatson> well, I can't fix it for karmic now anyway
<crypt-0> cjwatson, the alternate installer will me choose where to install correct?
<cjwatson> crypt-0: in expert mode, yes; as does ubiquity, in the Advanced dialog
<crypt-0> also, since i will be installing to encrypted device, ...
<crypt-0> ah ok
<Flannel> cjwatson: It also should *say* that its doing so, since otherwise its magic handwaving that no one knows about
<cjwatson> Flannel: it was a last-minute hack for karmic because we were getting lots of requests for it at a high level. please file bugs about problems
<crypt-0> [ubiquity] is that the Desktop Cd with the GUI?
<cjwatson> the installer is entirely entitled to do magic handwaving, though :)
<cjwatson> crypt-0: yes
<Flannel> cjwatson: Not without -pae being on the CD it isn't.
<cjwatson> and I actually don't think it's appropriate for the desktop installer to tell you details like which kernel it's using
<cjwatson> if the kernel doesn't work, that's what needs to be fixed
<crypt-0> cjwatson, https://help.ubuntu.com/community/FeistyLUKSTwoFormFactor
<crypt-0> i will be improving this guide
<cjwatson> Flannel: it absolutely is; the kernel is not the only thing it installs from the network
<crypt-0> im going to use TFA, so i will make a guide for 9.10
<cjwatson> crypt-0: er, ok, I'm not going through that on a Friday night :)
<crypt-0> if i want to improve that quite dated guide where could i do it?
<Flannel> cjwatson: That's news to me.  Is this documented anywhere?
<cjwatson> Flannel: no
<cjwatson> it installs language packs from the network because they won't fit on the CD, in general
<cjwatson> all points where it tries to download anything have (or at any rate should have) a Skip button
<crypt-0> cjwatson, in short it is two-factor-authentication for LUKS, but it is for Feisty
<crypt-0> i want to modify it and bump it up (update) some of the things for 9.10
<cjwatson> Flannel: I'd like to fix the problem here, but I just want to do so by starting from the problem rather than by starting from a proposed solution :)
<cjwatson> I usually find the former approach produces better results
<Flannel> cjwatson: Bug report is being filed.  But again: doing magic handwavey things that potentially cause problems (and won't let you disable) is a pretty straight forward fix-- let you disable them.
<crypt-0> and possibly have someone review it :) two factor authentication would be nice to document. Furthermore, it would be nice if i could code a script to do it with the automated crypto installer for the next release of Ubuntu.
<cjwatson> Flannel: I agree that in this case it ought to be preseedable somehow
<Flannel> I agree that problems are better than proposed solutions, but I juts don't think there's much debate in the matter.
<cjwatson> one man's magic is another man's Doing The Right Thing
<cjwatson> (oops: sorry, unintentional sexist language)
<crypt-0> Basically, i want to get more involved in the Ubuntu development. Cryptography is my strong point, Two factor auth with your MRB and boot partition on a thumbdrive counter a lot of the new attacks on encryption.
<cjwatson> Flannel: the thing to remember is that that isn't a fix, it's a workaround.
<cjwatson> quite possibly a valuable one, but nevertheless a workaround
<cjwatson> the installer does in general support lots of preseedable tweaks to its behaviour, we were just too rushed in this case
<crypt-0> This would be very nice for people working with laptops that have to keep cooperate files secret.
<Flannel> cjwatson:  https://launchpad.net/bugs/477050 is the PAE panic
<ubottu> Ubuntu bug 477050 in linux "Fresh Install of Karmic, Boot ends with Kernel Panic " [Undecided,New]
<cjwatson> I think I'd want to refactor the rather grotty hack in the process of making it more controllable
<crypt-0> cjwatson, do a lot of the issues with 9.10 have to do with the new kernel being so much different than the old one?
<cjwatson> crypt-0: I'm sorry, that's too vague a question for me to even contemplate answering
<cjwatson> the kernel changes very substantially from release to release; and any operating system of the size of Ubuntu has lots of problems
<crypt-0> I noticed the new version of g++ and c++ complicate the compiling of some programs (older versions do it fine)
<cjwatson> g++ gets stricter with most releases
<cjwatson> it is still fundamentally the fault of the program for not complying with the standards
<crypt-0> for example turning a "warning" that the developer knows about into a fatal build error?
<cjwatson> g++ used to be very permissive, and people got used to it; but I rather suspect it caused wider problems because lots of people wrote code to g++ that worked nowhere else
<crypt-0> cjwatson, i agree.
<cjwatson> if you have an issue with what g++ is doing, I suggest taking it to the g++ developers
<cjwatson> it won't get noticed here
<cjwatson> but I suspect they will simply tell you to either (a) fix your code or (b) use an older version of g++ until you can
<crypt-0> well the forums are very helpful.
<crypt-0> [older version] i do
<crypt-0> i downgraded
<cjwatson> there you go. it's not as if it expires. :)
<crypt-0> right :D
<cjwatson> it is not viable for Ubuntu to remain on older versions of the compiler suite forever.
<mneptok> crypt-0: the Ubuntu forums are not the proper venue for filing bugs or feature requests against compilers
<crypt-0> mneptok, im well aware of that. However some of the problems i have encountered with the new compiler were fixable with help from the forums.
<mneptok> crypt-0: as cjwatson says, g++ does not throw errors for no reason. if you want to ignore them and have code that is out of language spec, use an old version. but the real solution is a code cleanup.
<crypt-0> correct.
<crypt-0> I compile a *lot* of code, i noticed the problems mostly with poorly maintained code or code that has not been updated for ages.
<mneptok> so we're agreed it's not an issue with Ubuntu development, but rather an issue with a more strict compiler, and crufty code? if so, it's probably better to raise these issues with g++ maintainers, or seek c++ gurus to help clean up the cruft. :)
<crypt-0> Yes.
<crypt-0> I was just stating the problem.
<mneptok> no worries.
<mneptok> i say that not to be dismissive, but rather to point you at resources more likely to help solve your issues.
<crypt-0> Im also looking for a "proper" way to package sun java so i can build packages for it.
<crypt-0> I can make my own packages to update myself, but i want to help the community in general.
<mneptok> !info sun-java6-jre
<ubottu> sun-java6-jre (source: sun-java6): Sun Java(TM) Runtime Environment (JRE) 6 (architecture independent files). In component multiverse, is optional. Version 6-15-1 (karmic), package size 6270 kB, installed size 14360 kB (Only available for all amd64 i386 lpia ia64)
<crypt-0> there are some complaints about the version being old, and i know it is "discontinued" and community maintained.
<cjwatson> one would package it by updating the packaging already in the archive
<cjwatson> I wouldn't recommend trying to create new packaging from scratch
<crypt-0> Again, im not saying this is your fault: Im saying you have much bigger issues to deal with that building a java package. It is no problem for me to manually update, but i would like to be able to package java and build it so it can get included in updates. In case you are not aware it is still at 1.6.16 and 1.6.17 has been out for a while. Hardy already updated to 1.6.17 is there an easy way to grab the packages from the heady update repositories and
<crypt-0>  port them to 9.10?
<cjwatson> sure, grab the source package and debuild
<crypt-0> cjwatson, in other words  apply a patch or a diff and upload the old pacage along with the patch and or diff?
<cjwatson> debuild is a program name
<cjwatson> it's odd that it's newer in hardy than in newer releases, I'm sure that could be fixed (in lucid at the very least)
<crypt-0> i have tried to crawl through the mirror via a web browser to find the package. I do not want to enable hardy repos on my machine.
<crypt-0> is there a way i can request the package from the hardy updates repo with wget?
<cjwatson> sure, use packages.ubuntu.com
<crypt-0> i tried i think the version was still at 1.6.6 :S
 * crypt-0 tries again
<cjwatson> http://packages.ubuntu.com/hardy-updates/sun-java6-bin
<cjwatson> panel at the right has source download links
<crypt-0> 6-17-0ubuntu1.8.04: amd64
<crypt-0> cool
<cjwatson> the source isn't architecture-specific, of course
<crypt-0> last i checked the package was out of date on that
<crypt-0> right.
<cjwatson> I'm referring to the links under "Download Source Package sun-java6"
<crypt-0> and the hardy package will *probably* install fine on 9,10
<cjwatson> http://packages.ubuntu.com/source/hardy-updates/sun-java6 is probably clearer
<crypt-0> cjwatson, do you have 2e6035430545cc59c3fd6f68f7b00708 as the md5sum for sun-java6_6-17.orig.tar.gz?
<crypt-0> at the link you just pointed at.
<cjwatson> crypt-0: I'm not going to answer that question because it's silly to compare md5sums over IRC. :)
<crypt-0> true :)
<crypt-0> unless this was a SSL network.
<cjwatson> SSL is not a substitute for trust
<crypt-0> any encryption is meaningless if the other end is compromised.
<cjwatson> it's entirely possible to add deb-src lines to /etc/apt/sources.list and then use apt-get source sun-java6/hardy-updates (or something like that)
<crypt-0> or in the case of an irc server, the other end or the server.
<cjwatson> you can always remove it afterwards - and then you'll get signature checking
<crypt-0> oh ok, so it will check the gpg sig for it?
<crypt-0> ok :)
<cjwatson> encryption/compromised> you're missing the point. the problem here is not the software, it's the people. I could be anybody.
<cjwatson> yes, it will check the signature chain from Release.gpg through Release and Sources to the source files. you can do this by hand but it's tedious.
<crypt-0> right, but chances are if someone was doing an attack on the ubuntu packages...they would not be hanging out here ready to give out evil MD5 sums...but they may.
<crypt-0> GPG signing is much more secure, agreed.
<crypt-0> $ gpg --verify MD5SUMS.gpg
<crypt-0> gpg: no signed data
<crypt-0> gpg: can't hash datafile: file open error
<crypt-0> ah nevermind
<crypt-0> gpg --verify MD5SUMS.gpg MD5SUMS :)
<crypt-0> "While security flaws in the MD5 algorithm have been uncovered, MD5 hashes are still useful when you trust the organization that produces them. Moving to more secure hashes like SHA-256 and Whirlpool is under discussion. "
<crypt-0> gpg-signed MD5 hashes are still secure.
<crypt-0> Someone can also just make a SHA256 sum of the evil .iso file if the wanted.
<crypt-0> I suppose suing SHA2 or Whirlpool could help. But a gpg signed MD5 i believe is as secure as GPG itself.
<cjwatson> crypt-0: you know that we also have SHA256SUMS files on our CD image mirrors, right? ...
<cjwatson> so this is moot
<crypt-0> Yes.
<cjwatson> the reason we still ship MD5SUMS has not a lot to do with its security, and a lot to do with the fact that md5sum.exe tools are more widespread on Windows than sha256sum.exe tools or equivalent
<cjwatson> and for CD images this does matter
<crypt-0> What i am saying is that regardless of how strong the hash is, someone can still hash their evil iso with it.
<crypt-0> So no need for a stronger hash, when you give the gpg signed hashes already, assuming you can trust the integrity of the GPG key.
<crypt-0> Dont get me wrong, this is not really a complaint, just my two cents.
<cjwatson> the need for the strength of the hash is second-preimage resistance
<jmarsden> crypt-0: Well, if the has were so weak one could deliberately create evil ISOs with the same hash as the non-evil one, there would be a problem... but I'm not sure #ubutnu-devel is the right place to be learning about cryptography
<cjwatson> in other words, the ease of creating a second message with a known hash
<cjwatson> MD5 is not at the stage yet when that is trivial, although I think you are a little blase in saying flatly that it's still secure. That's probably the case right now but it will probably not be the case in a few years, which is why we're migrating away from MD5.
<jdstrand> cjwatson: it is my understanding that LP still can't do source format 3.0 (quilt). is that correct?
<jdstrand> cjwatson: hi btw
<cjwatson> jdstrand: that is unfortunately still the case - pushed back to the next LP release
<jdstrand> k
<crypt-0> Im saying it is secure if you trust the GPG key that signed the hashes.
<jdstrand> cjwatson: are we doing anything special wrt to Debian packages using 3.0?
<jdstrand> (with syncing)
<cjwatson> crypt-0: you are mistaken.
<cjwatson> jdstrand: putting them on hold
<jdstrand> cjwatson: ok
<jdstrand> cjwatson: thanks
<cjwatson> jdstrand: I think in the odd case people have reverted to 1.0 and fakesynced
 * crypt-0 has more reading to do :)
<crypt-0> I usually check both the MD5, SHA1 and SHA256 sums, and their gpg signatures anyway.
<cjwatson> crypt-0: the GPG signature is on the *hash*, and a hash can always (by the pigeonhole principle) be valid for more than one message. If you can discover another message with the same hash that's also a valid ISO image (and I have some reason to suspect that this might not be as hard as people tend to think; published manually-constructed MD5 collisions often seem to differ in quite a small number of bits), then the trust ...
<cjwatson> ... assigned to the GPG key that signed it matters not one whit
<cjwatson> crypt-0: it's a waste of time to check the weaker hashes
<cjwatson> crypt-0: I haven't done the maths for SHA256, but checking both MD5 and SHA1 adds an upper bound of only six bits of security over checking SHA1 alone
<crypt-0> Not to mention, SHA1 was broken in 2005.
<cjwatson> that's slightly dodgy collision resistance. don't confuse it with second-preimage resistance
<cjwatson> (source for my claim regarding only six bits of additional security from checking both hashes: http://cm.bell-labs.com/who/akl/hash.pdf)
<cjwatson> argh, that link has died
<crypt-0> confirmed.
<cjwatson> at any rate the lay summary is that MD5 and SHA-1 (and similarly SHA-256) are not fundamentally sufficiently different algorithms in a strong enough sense for multiple checks to provide much extra security
<crypt-0> would be nice to add it to my stack of white papers though.
<cjwatson> the reference is Antoine Joux' multicollisions paper from CRYPTO 2004, if you can find an online copy.
<cjwatson> there's a slightly stronger result in http://eprint.iacr.org/2004/304.pdf, but I haven't finished reading that.
<wgrant> jdstrand, cjwatson: Note that the next LP release is supposedly a little under two weeks away, so it's not toooo long.
<jdstrand> wgrant: appreciated, I'm just putting a comment in the sync bugs for now
#ubuntu-devel 2009-12-05
<Kmos> ja /quit
<douglasawh-work> I have a quick technical documentation question. I asked in ubuntu+1 and no one knew and was directed here -- what encryption does eCryptfs use?
<constantine9> have you ever install chillispot on ubuntu server?
<tapan> i am getting problem in installling joomla. what should i do??
<geser> any main sponsor around to "sponsor" bug #490731?
<ubottu> Launchpad bug 490731 in distribute "python-setuptools: import setuptools returns ValueError: ("Missing 'Version:' ...)" [Undecided,New] https://launchpad.net/bugs/490731
<geser> while I can technically upload it (the source is still in universe) but as it builds packages in main, I'd better get it sponsored (or at least ACKed)
<ScottK> geser: Looking
<ScottK> geser: Looks good.  Thanks.
<George_E> Is there an easy way to install a large number of packages in a folder without manually installing one by one?
<ebroder> George_E: #ubuntu-devel is for Ubuntu development, not questions about how to use Ubuntu. You want #ubuntu
<debfx> siretart`: there's a bug in vlc that causes the fullscreen mode to fail when using kde >= 4.3.3 (and possibly other window managers). currently it affects lucid and users of the kubuntu-ppa, but kde 4.3.4 might go into karmic-updates. bug #485030
<ubottu> Launchpad bug 485030 in vlc "Full-screen mode has panel showing on KDE4" [Undecided,Confirmed] https://launchpad.net/bugs/485030
<kaipanoi> Greets. I recently noticed this: http://www.debian.org/News/2009/20091007. Curiosity compels me to ask if such a port may one day be found among the existing PowerPC, IA-64, Marvell, Freescale and Atom ports?
<ScottK> kaipanoi: There is no longer an Ubuntu Atom port.  We are using regular i386 starting in Lucid.
<kaipanoi> Interesting. Thank you.
#ubuntu-devel 2009-12-06
<jdong> hmm, BFS is actually noticeably more responsive...
<jdong> heh of course I only have 1 and 2 core machines and gut feeling to back that up
<ion> BFS?
<matgeek> thumper:  notice you are doing miniconf at linuxconf.  I am seriously thinking of coming along.  Is there anything I can do to help you out?  How about an account of using launchpad as a Debian Developer?  I am moving to get one of my packages on it this week.
<ScottK> Is there an archive admin in the house?
<ScottK> odbcinst is a new binary (split out from odbcinst1debian1) that landed in Universe.
<ScottK> So now the -dev package is uninstallable on the buildds
<ScottK> (for main uploads)
 * ScottK plays archive admin roulette and asks if StevenK might be around to help out?
 * StevenK lunges for cocoplum
<ScottK> StevenK: Thanks.
<StevenK> ScottK: Done.
<ScottK> StevenK: Thanks again.  Got it in before the publisher run even.
<StevenK> ScottK: That was my plan
<ScottK> Good plan that.
<diwic> I'm trying to git pull, but it claims that my working tree is not up-to-date
<diwic> It complains about files I haven't changed, at least not on purpose.
<diwic> What is the easiest way to resolve that issue?
<maco> diwic: try "git stash ; git pull ; git stash apply" ?
<diwic> maco: stash, that was a new one :-)
<maco> diwic: it stashes all your changes elsewhere so you can pull as if it were a clean tree
<maco> did it work?
<diwic> yes, thanks :-)
<maco> yay!
<maco> i had to learn that yesterday when i got too behind on pulling at work
<diwic> I'm not going to do the apply part though
<maco> ok
<diwic> oh, next problem
<diwic> pristine-tar: There's no local pristine-tar branch. Several remote pristine-tar branches exist.
<diwic> Run "git branch --track pristine-tar <remote>" to create a local pristine-tar branch
<diwic> maco: I remember you saying quilt was the most difficult part of becoming MOTU, but I must say git is three times harder
<maco> diwic: most motu dont have to deal with git...
<maco> diwic: just us weirdos who touch kernely thingies
<diwic> maco: perhaps you're right. This is actually debian work
<maco> ive never used pristine-tar thouhg
<maco> *though
<diwic> maco: perhaps it is Linus's way of keeping amateurs away from the kernel. ;-)
<maco> diwic: my boss was watching me trying to use git yesterday and going "wish we could go back to ___" and named something older than CVS that is apparently found on mainframes
<jdong> older than RCS?
<jdong> SCCS?
<jdong> the former doesn't follow from the latter.
<diwic> maco: we use a serial VCS at work and it actually works pretty well.
<StevenK> I thought they just paid to keep the programmers in cold storage along with the mainframes
<spO> does changing my gcc version matter with regard to the kernel? IE, i can do it and it is not a big deal?
<maco> jdong: possibly RCS
<ebroder> maco: RCS isn't that old. The sipb.mit.edu AFS cell has way too much RCS in it. It's really sad
<jdong> RCS is still cool in some ways :)
<ebroder> Actually...that second sentence didn't follow from the first
<maco> ebroder: i work for a company that does stuff on afs, so this makes sense coming from my boss
<jdong> namely if you're trapped on a FreeBSD system...
<jdong> that seems to be the scenario for all vintage tools :)
<ebroder> Yeah, I'm told the sipb cell still have a copy of iexplore for Sun lying around somewhere. Ugh
<mneptok> foxbuntu: ping
<foxbuntu> mneptok, pong
<mneptok> foxbuntu: could you join #ubuntu-ops for a moment, please?
<foxbuntu> mneptok, sure.
<mneptok> thanks!
<lifeless> `/win 41
<OC1> hi everybody
<OC1> is there anyone who can read me :(
<OC1> do u hear me :(
<micahg> OC1: how can we help you?
<OC1> hi micahg
<OC1> I am new in ubuntu
<OC1> I install ubuntu 9.1
<OC1> but I can't update my system
<micahg> OC1: #ubuntu is for support
<OC1> thank you
<micahg> OC1: good luck
<OC1> see u
<juliank> Is it normal that a NEW package (libslab in its own source package) available in Debian testing since Oct 22 is still not available in lucid?
<slacker_nl> who should I notify if packages.u.c is down?
<tsimpson> slacker_nl: try #canonical-sysadmin
<slacker_nl> thnx
<cjwatson> juliank: it's on the list, but it requires manual attention because it produces binaries that override binaries from a different source package that's modified in Ubuntu
<cjwatson> E: libslab is trying to override libslab-dev_0.9.12+dfsg-0ubuntu4 without -f/--force.
<juliank> cjwatson: Actually, gnome-main-menu (which previously contained libslab) should be synced as well.
<cjwatson> juliank: that's fine, but we don't take these requests by IRC :) https://wiki.ubuntu.com/SyncRequestProcess
<cjwatson> if you (or somebody) file a bug and subscribe ubuntu-archive to it, it'll be processed
<juliank> cjwatson: I just said this because I wanted to wait for libslab before renaming https://bugs.edge.launchpad.net/ubuntu/+source/gnome-main-menu/+bug/428860 to a sync request. So it seems the gnome-main-menu sync must come first, and then libslab (gnome-main-menu depends on libslab, so this seems a bit strange)?
<ubottu> Ubuntu bug 428860 in gnome-main-menu "Please update gnome-main-menu to 0.9.13" [Undecided,Fix released]
<cjwatson> juliank: please file a bug about libslab, then
<cjwatson> the gnome-main-menu sync doesn't have to come first; but the archive admins are not in a position to review every package in this state, so we rely on bugs
<slacker_nl> hi all, got a problem with apt, debsums apt reports: missing file /usr/lib/libapt-pkg-libc6.10-6.so.4.8.1 (from apt package)
<juliank> cjwatson: The libslab sync request was stopped by ubuntu-universe-sponsors because we are before import freeze (it is https://bugs.edge.launchpad.net/ubuntu/+bug/428968)
<ubottu> Ubuntu bug 428968 in ubuntu "Sync libslab 2.27.91-1 (universe) from Debian testing (main)" [Wishlist,Invalid]
<cjwatson> juliank: they were wrong. sorry about that.
<cjwatson> please reopen it and feel free to quote me. the sync won't happen (semi-)automatically because it overrides binaries from another modified source package.
<cjwatson> the required bit for sponsorship is an explicit check and statement that all changes in gnome-main-menu are no longer required.
<cjwatson> there are a couple of dozen packages in this state. I should probably put the list somewhere ...
<juliank> cjwatson: Why not allow the archive to contain two versions of a binary package from two different sources? This would make such syncs easier; but one would have to cleanup afterwards.
<cjwatson> not going to happen, sorry :)
<cjwatson> it would be pathological for users because apt will only ever use the latest one, so we don't really want to allow the archive into such a state
<cjwatson> it's not a big enough problem in general for that sort of wide-ranging change to be worthwhile
<juliank> cjwatson: Both bugs updated. And I guess after the sync, we should move libslab to main and rebuild gnome-control-center against it instead of its own copy.
<juliank> Thanks for the information!
<squirrelpimp> is packages.ubuntu.com down or deprecated?
<juliank> squirrelpimp: It just seems to be down; at least there is still an IP for it.
<craigbass1976> Is poppler something I can install, or it comes with cups?
<craigbass1976> https://bugs.launchpad.net/ubuntu/jaunty/+source/poppler/+bug/382379/+activity  The last entry is something about  lp:ubuntu/jaunty-proposed/poppler   Does that mean I should see this by changing my software sources to include proposed updates?
<ubottu> Ubuntu bug 382379 in poppler "pdftops CUPS filter has several problems" [High,Fix released]
<craigbass1976> thanks ubottu, I knew that.
<maxb> craigbass1976: poppler is a piece of software that cups may use, why do you ask?
<craigbass1976> I can't print pdfs, and experience what's mentioned here:  https://bugs.launchpad.net/ubuntu/jaunty/+source/poppler/+bug/382379
<ubottu> Ubuntu bug 382379 in poppler "pdftops CUPS filter has several problems" [High,Fix released]
<craigbass1976> I've been trying to dork with this for a couple months, but today I grabbed the woman's computer and printer and have them at my house for the day
<craigbass1976> maxb, I'm not sure how to implement the change, other than run an update
<craigbass1976> maxb, no idea?
<maxb> The bug is huge, I am reading
<craigbass1976> thanks
<maxb> There are no pending SRUs for cups or poppler.
<maxb> -proposed is not relevant here
<craigbass1976> I'm thick... is there a fix or not?
<craigbass1976> And how do I implement it if there is.
<maxb> bug 382379 is deemed fixed some time ago
<ubottu> Launchpad bug 382379 in poppler "pdftops CUPS filter has several problems" [High,Fix released] https://launchpad.net/bugs/382379
<maxb> poppler and cups have both been SRUed in jaunty multiple times since that, for other issues, apparently
<craigbass1976> I thought it looked like that; I wonder why I still have such trouble then
<maxb> I would suggest trying a Karmic livecd if that is an option for you
<craigbass1976> Is there an L out yet?
<maxb> pre-alpha
<craigbass1976> maxb, well, karmic is an option, but I was hoping to avoid installing a new os.  Question for you...  I hear tell there is some trouble upgrading to Karmic.  Is there going to be the same kind of trouble upgrading out of Karmic?
<craigbass1976> This woman has so much stuff on her box that wipe/reinstalls are a wicked pita
<maxb> All upgrade paths out of jaunty lead through karmic anyway
<FishEatFish> hello, can someone help me with the void * type ? i don't know how to deal with an array assignement
<craigbass1976> maxb, I forget I can just throw this lappy drive in my desktop.  Dumping's quick.  I'll go karmic.
<maxb> FishEatFish: Are you really in the right channel?
<maxb> craigbass1976: Dumping? Please note that I am not unequivocally recommending karmic, I was just suggesting you try a livecd
<FishEatFish> maxb : there is other channels dedicated to programming ?
<maxb> FishEatFish: This isn't a channel dedicated to programming.
<maxb> "Development of Ubuntu (not support, not app development on Ubuntu)"
<FishEatFish> ok thank you maxb i apologize
<maxb> ##c might help you
<FishEatFish> :) i'll go there
<aburch> Is there any historic data for popcon.ubuntu.com available?
<aburch> I miss the nice graph that popcon.debian.org provides, so I build a small site to generate them, but only have data for the last 10 days.
<aburch> FWIW the graphs are available from ubuntu-popcon.43-1.org for now.
<yofel> hi, would bug 491483 qualify for an SRU?  if gdm and kdm are installed and kdm is used, kdm and failsave-x will race against each other to start X since failsave X thinks that gdm being disabled equals X not starting up.
<ubottu> Launchpad bug 491483 in xorg "after recent update which included xorg, xserver etc causes low-graphics mode error at start" [Undecided,Confirmed] https://launchpad.net/bugs/491483
<craigbass1976> Is this channel logged somewhere?  I need to see what I said in here earlier
<ebroder> !logs | craigbass1976
<ubottu> craigbass1976: Official channel logs can be found at http://irclogs.ubuntu.com/ - For LoCo channels, http://logs.ubuntu-eu.org/freenode/
<craigbass1976> ebroder, thanks
<craigbass1976> maxb, you there?
<maxb> craigbass1976: intermittently - ask and IO'll get back to you
<craigbass1976> maxb, wanted to let you knwo that karmic prints pdf no better than jaunty.
<craigbass1976> maxb, and I guess the netowrk doesn't matter; this thing suck via usb too.
<maxb> craigbass1976: In that case, I think you should file a new bug
<craigbass1976> maxb, lazyart's post here http://ubuntuforums.org/showthread.php?t=223819 has fixed my issue with the karmic livecd.  Now I'll see what happens on the jaunty install.  be back later..
<craigbass1976> maxb, dude...  this is retarded.  use an HP laserjet foomatic driver to print to a networked brother mfc 7820N and all your troubles will go away.
<craigbass1976> maxb, and I added to the bug thread you were reading earlier.  I don't know as this qualifies as part of the bug though.
<maxb> I seek a main-sponsor for a subversion merge, is anyone interested?
<maxb> bug 483953
<ubottu> Launchpad bug 483953 in subversion "Merge subversion 1.6.6dfsg-2 (main) from Debian unstable (main)." [Undecided,In progress] https://launchpad.net/bugs/483953
<fbond_> Where can I read about the relationship between -updates and -security?
<kees> fbond: does this answer it for you? https://wiki.ubuntu.com/SecurityTeam/FAQ#Repositories
<fbond> kees: Not really, I guess.  What I'm wondering is, if the updates pocket has a different version of a package than the release pocket, which version is the security update based on?
<fbond> kees: And when do security updates also get published to the updates pocket?
<fbond> kees: I think this will help me: https://wiki.ubuntu.com/ArchiveAdministration
<fbond> Let me look that over for now.  Thanks for your help.
<fbond> kees: Okay, I understand the policy.  Security updates would be based on packages in the updates pocket.  But wouldn't this lead to users that don't have the updates pocket enabled getting -updates changes via -security?
<kees> fbond: yes.  that can happen and is accepted as the least bad of possible options.
<fbond> kees: In other words, the cost of maintaining two separate security pockets would be too high?  Makes sense.
<kees> fbond: yeah, correct.  I've updated the FAQ a bit to help clarify.
<mun24> I have a requirement where I need to wait for 2 events, if event 1 occurs then do something and if event 2 occurs then do something else.  How can I achieve this.
#ubuntu-devel 2010-12-06
<highvoltage> ScottK: what's an AM?
<ScottK> highvoltage: Application Manager (for Debian New Maintainer process)
<highvoltage> ScottK: thanks. stgraber showed me how to google that properly :)
<dholbach> good morning!
<didrocks> good morning
<dholbach> salut didrocks
<didrocks> hey dholbach, did you have a good week-end?
<dholbach> yes, I did - how about you?
<didrocks> nice, snowy and cold :)
<dholbach> yeah, same here - I did a long walk with the dog through a forest yesterday - it was great :)
<didrocks> nice! :)
<RAOF> A white dog in a snowy forest? :)\
<dholbach> the dog was a bit whiter afterwards, yes :)
<lifeless> how does one manually trigger a pyshared update?
<mdz> pitti, I finally got a full retrace on my g-s-d crasher (bug 685785)
<ubottu> Launchpad bug 685785 in gnome-settings-daemon (Ubuntu) "gnome-settings-daemon crashed with SIGSEGV in __libc_free()" [Medium,New] https://launchpad.net/bugs/685785
<geser> did the plymouth theme dropped on quality? it looks pixelized to me
<tumbleweed> geser: mine appears to have a corrupt pallete, so it could be that the anti-aliasing is using the wrong colours.
<geser> I don't know what exactly happened, but the "ubuntu" doesn't look as smooth as before
<tumbleweed> geser: yeah, the same, but the "waiting for foo to be mounted" text is completely unreadable (and I get a brief flash of a yellow-text tty0)
<geser> yes, I saw that too. It looks like some ASCII block chars got displayed on top the text
<micahg> can an AA please delete aspell-id from NEW, the packager is working on getting it in through Debian
<micahg> slangasek: or james_w ^^ re aspell-id in NEW
<c2tarun> can anyone please tell me about some small packaging bugs like spelling mistakes of something like that. i want to work on them.
<geser> try one of the "bitesize" tagged bugs: https://launchpad.net/ubuntu/+bugs?field.tag=bitesize
<dnivra> hello. I am running apt in gdb and when i print the value of a variable, output is "value optimized out". what does this mean?
<geser> that the compiler (gcc) got rid of the variable in the optimization stage during compilation
<dnivra> so that variable is not necessary for the correct functioning of the program?
<Chipzz> no
<Chipzz> it is
<dnivra> then what did geser mean by "got rid of the variable"?
<dnivra> so is there a way for me to get the value of a variable? normal printing out doesn't seem to work: using cout.
<geser> dnivra: you have to rebuild without optimization (-O0)
<Chipzz> dnivra: let me try to give a stupid example. lets say you write a program to print the value 2
<dnivra> geser, there's a small problem with that. how do I specify that? I did in the makefile but it shows an error. hold on let me tell you what the exact error is.
<Chipzz> int willbegone=1; printf("%i\n", i+1);
<dnivra> okay.
<Chipzz> i is constant so can be optimized away
<dnivra> wait i isn't declared is it?
<Chipzz> but it is still necessary to calculate 2
<Chipzz> euh
<Chipzz> sigh
<Chipzz> int willbegone=1; printf("%i\n", willbegone+1);
<Chipzz> s/i/willbegone
<dnivra> oh okay i see. sorry should've seen through that.
<Chipzz> that being said
<Chipzz> your question is off-topic here ;)
<dnivra> sure sure. no more on this. but i can still ask doubts on how to compile apt without optimization right?
<Chipzz> my example is contrived, but a better example would be inline functions
<geser> dnivra: use 'DEB_BUILD_OPTIONS="noopt"' when rebuilding apt
<dnivra> use this option with './configure'?
<geser> I'd use the apt source package for rebuilding (and get .deb without optimization)
<Chipzz> dnivra: no, you have to change/add that Makefile
<Chipzz> debian/rules
<dnivra> i have actually been compiling that source to get the binary direct and not the deb.
<dnivra> i just have to add " export DEB_BUILD_OPTIONS="noopt"" to debian/rules?
<geser> in that case using "DEB_BUILD_OPTIONS="noopt" debian/rules build" should be enough to get the binary
<dnivra> this is a very beginner question i know. where am i supposed to specify that option?
<dnivra> where am i supposed to specify DEB_BUILD_OPTIONS="noopt"? i added it to debian/rules still am getting optimized output.
<geser> it's an environmental variable which gets checked in debian/rules
<geser> set it before you build the package
<geser> if you have the apt source package and the build-depends for apt installed then the command I posted should get you an apt binary without optimization
<dnivra> did you mean build-essential?
<geser> build-essential and the packages listed in debian/control (Build-Depends and Build-Depends-Indep)
<Chipzz> geser: shouldn't that work if you put it at the top of debian/rules too?
<dnivra> i don't think it does in my case cos I don't have those packages listed in debian/control installed perhaps. lemme check.
<Chipzz> anyway I think you have 4 options: put it in the makefile, DEB_BUILD_OPTIONS="noopt" debian/rules, debian/rules DEB_BUILD_OPTIONS="noopt", export DEB_BUILD_OPTIONS="noopt"; debian/rules
<dnivra> Chipzz, yeah got it! i did export DEB_BUILD_OPTIONS="noopt";debian/rules. it worked. thanks! i'll keep this in mind. thanks to you too geser. now to understand and try to fix the bug.
<\sh> moins
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Natty Alpha 1 released! | Archive: Open | 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: mdeslaur
<sebner> slangasek: hi, on archive duty today? Mind rejecting one of the two monobristol uploads (maverick-proposed), and if bored approve it? :)
 * dholbach hugs mdeslaur
<dholbach> enjoy your flight with mdeslaur airlines :)
<ScottK> micahg: If you still need something rejected, let me know what.
<ScottK> sebner: I can reject one.  Which one?
<sebner> ScottK: doesn't matter, both are the same
<ScottK> sebner: Done.
<bdrung> persia: around?
<sebner> ScottK: take my thanks :)
<persia> bdrung, What's up?
<bdrung> persia: what are the responsibilities for the chair (except leading the meeting)?
<persia> bdrung, Typically handling admin stuff (group adds, etc.), sending announcements, and writing minutes.
<bdrung> persia: do we have a wiki page for that?
<persia> Not to my knowledge.
<bdrung> persia: then we need one
<persia> I think there was one for the MC though.
<persia> I think that got cleaned up when MC went away.  Why do we need one?  99% is self-evident from the meeting results (stuff being agreed), and the rest is just minutes.
<persia> Ah, digging about, I think I agree we need one :)  There's some fair inconsistency historically.
<ScottK> cjwatson: Nice post (and nice work) on fixing time synchronization.
<cjwatson> thanks.  apparently I offended s-t-b upstream by not waiting for the upload :-/
<bdrung> cjwatson: s-t-b?
<cjwatson> system-tools-backends
<bdrung> cjwatson: a, i got the mail.
<zaytsev> [FAILEDTOUPLOAD] Failed to upload on litembilla (virtual) Retry this build
<zaytsev> anybody has a clue what's wrong with this builder?
<persia> zaytsev, #launchpad often is able to answer that sort of question.  I recommend providing a link to the LP page for the build.
<zaytsev> persia, thanks
<bigbrovar_> Hi guys, I installed Ubuntu 10.04 on a friend's sony vaio and sound did not work, even after installing all the restricted/backport modules for linux and alsa. The only thing which worked was compiling the latest stable version of alsa. Now is there a way I can write a dkms script to compile auto compile the module so that the next kernel updates wont break sound again.
<bigbrovar_> would appreciate if anyone could point me to a doc somewhere google didn't help
<geser> persia, bdrung: don't forget the update of the TeamReport wiki page
<bdrung> geser: that demonstrates that we need a wiki page for it
<geser> bdrung: updating the TeamReport is mentioned on the Agenda page
<persia> geser, Good point.  Perhaps rather than a new page, we just need to break out the last bullet point a bit.
<geser> what we regularly miss is mailing the outcomes of the applications to devel-permissions@ (see https://wiki.ubuntu.com/DeveloperMembershipBoard/)
<persia> geser, Good point.  I've been sending individual announcements to u-d@ and minutes to d-p@+u-d-a@, which doesn't match what is written there.
<bigbrovar_> are there docs on how to create dkms script to auto compile alsa modules I compiled on Ubuntu whenever I do a kernel upgrade, or am I asking a dumb question?
<TeTeT> bigbrovar_: I'm only aware of http://linux.dell.com/dkms/, not sure if there's a better guide
<bigbrovar_> thanks :)
<didrocks> cjwatson: hey, is grub 1.99~20101126 is known to not starting X/gdm with nvidia proprieraty driver? I didn't find a bug in LP about it
<didrocks> I think that dholbach got that as well
<dholbach> didrocks, yes, same problem - but I'm not close to the machine right now
<cjwatson> didrocks: not specifically, but please see https://blueprints.launchpad.net/ubuntu/+spec/packageselection-foundations-n-grub2-boot-framebuffer
<cjwatson> didrocks: we knew we were going to trigger some kernel problems with this change; we deliberately changed it early in natty so that the kernel problems could be worked out.  thus, please raise this with the kernel people
<didrocks> ahah gfxpayload=keep, I already got that issue in maverick IIRC
<cjwatson> yes
<cjwatson> but please do raise it on the kernel side rather than just working around it and forgetting about it
<dholbach> didrocks, I didn't use the 'nvidia' driver in maverick, so I probably wouldn't have noticed :)
<didrocks> cjwatson: ok, I'll raise that with kernel people then just now. I'm not changing the config file to keep it in mind :)
<didrocks> cjwatson: thanks :)
<SpamapS> ari-tczew: to answer your question from a couple of days ago: yes I do these patches primarily as an employee of canonical.
<ari-tczew> SpamapS: thanks
<smoser> cjwatson, i'm sure you've got good reasoning for this, but I wondered why openssh-server installs both /etc/init.d/ssh and /etc/init/ssh.conf rather than using dh_installinit
<cjwatson> smoser: bug 531912
<ubottu> Launchpad bug 531912 in openssh (Ubuntu) "[LUCID] /etc/init.d/ssh seems to work, but actually upstart is used." [Medium,Triaged] https://launchpad.net/bugs/531912
<cjwatson> (tl;dr: upstart can't supervise services in chroots yet)
<nemo>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
<nemo>  2287 nemo      20   0 1562m 657m  13m S    0 17.2  25:16.21 nautilus
<nemo>  1239 root      20   0  861m 515m 100m S    7 13.4 246:16.89 Xorg
<nemo> looks like it is time for my bi-weekly ubuntu 10.10 reboot
<jdstrand> didrocks: hey, so I am going through the unity bugs that affect me and commenting on them as well as filing my own. so, one thing that I think is a design decision (and therefore a bug would be possibly pointless) is not being able to use applets in the panel
<jdstrand> didrocks: I typically use a hardware sensors, a system monitor and the hamster-applet (time tracker)
<didrocks> jdstrand: yeah, it's a design decision. what you need is indicators
<seb128> jdstrand, right, applet are deprecated in GNOME3
<didrocks> and gnome-shell either won't support applets
<jdstrand> didrocks: in Unity, I can no longer use these. I depended on the hardware sensors one for keeping tabs on my temp so my laptop doesn't melt
<jdstrand> seb128: so all that code is now dead?
<seb128> well you can use the logic and write an indicator
<seb128> but it needs work yes
<jdstrand> seb128: or is there some other way that I can use it in the new Unity world
<seb128> no
<jdstrand> *sigh*
<jdstrand> seb128: so for my 3 favorite panel applets, I need to write the code to make them appindictor aware?
<didrocks> jdstrand: right
<Laney> could you have a panel-indicator? ;)
<jdstrand> man...
<jdstrand> didrocks: what is gnome3 doing about this?
<didrocks> jdstrand: exactly the same, there is still gnome-panel for non accelerated support cases which still have applets
<jdstrand> I mean surely, they plan to have some sort of equivalent functionality? I mean to just say "yeah, nobody uses the applets" is a little hard to swallow
<seb128> they don't
<jdstrand> didrocks: can I launch a gnome-panel in unity?
<seb128> you can
<seb128> you can put a gnome-panel at the bottom of screen if you want
<didrocks> jdstrand: well, you can, but you will have conflicts as there will be two pagers (if you still keep the appplet)
<jdstrand> I know you guys didn't design this, but this decision really sucks
<jdstrand> there is good stuff in the old panel applets...
<seb128> GNOME did a review by then
<jdstrand> seb128, didrocks: again, I am not criticizing your decisions, just venting at the state of affairs
<seb128> there was not so many things in applets that useful
<seb128> not sure applets are the right way to display those infos
<seb128> it's just that they are there
<didrocks> most of applets are geeky, I agree
<seb128> but maybe gadgets on the desktop would make sense
<didrocks> I kept the default one + tomboy in my case, which is now an indicator
<seb128> or you can write indicators as well
<jdstrand> well, developers are geeky and need a dev environment. I would use the system monitor to make sure I didn't have runaway process
<jdstrand> processes
<didrocks> seb128: isn't why "The board" is aiming at, don't you think?
<seb128> didrocks, sort of yes
<mvo> yep, system monitor, network load, all useful info
<jdstrand> I would use the hardware sensors to make sure my system didn't melt when compiling code
<mvo> geeky, true
<jdstrand> and hamster applet is a wonderful time tracking tool
<mvo> timetracker
<mvo> ++
<seb128> nothing stop porting those to indicators
<jdstrand> and arguably not geeky
<jdstrand> sure, except time
<jdstrand> (which is scarce in these parts)
<seb128> well, nobody forces anybody to stop running gnome-panel
<jdstrand> seb128: except that didrocks said there are conflicts in unity
<seb128> it's just that standard users should not need them so it's not a priority
<didrocks> jdstrand: the pager one (the window list)
<seb128> jdstrand, if you keep the gnome-panel pager applet and run unity
<seb128> just don't set any pager on gnome-panel
<jdstrand> I'd like to run unity. I want to know what people see and file bugs so it is great by release
<seb128> ok, so add an extra panel with only what you need
<jdstrand> ah, just the window list
<seb128> then put it at the bottom or something
<jdstrand> well, maybe I can just do that then
<didrocks> jdstrand: the good news is that you will have then alt + F2 before it's implemented in unity :)
<jdstrand> \o/
<jdstrand> (another annoying bug :)
<jdstrand> didrocks, seb128: so how do I autostart the gnome-panel in the unity world?
<seb128> jdstrand, go to system, preferences, session softwares and add a gnome-panel
 * jdstrand doesn't see a System anymore
<didrocks> hum, thinking about that, the new system session won't allow thatâ¦
<jdstrand> I'll admit, I am fairly confused by Unity's organization. maybe it'll be better when Places is around
<seb128> run gnome-session-properties
<didrocks> jdstrand: yeah, without place, is harder :) ctrl + alt + t to open a terminal and then the command seb128 told ^
<jdstrand> yes that works
<seb128> jdstrand, there is no organisation yet, and yes should be better once you get the dash and places done
<jdstrand> didrocks: are you saying that gnome-panel will not be able to be launched in the future?
<jdstrand> autolaunched that is
<didrocks> jdstrand: well, I'm thinking about the new session system I'm backporting and as unity will be told as providing a panel, that can be annoying
<didrocks> jdstrand: so I'll get some test and work with upstream on it
<didrocks> (upstream being there gnome-session)
<seb128> didrocks, jdstrand: the way I described just adds an autostart desktop to the session
<seb128> there is no reason that should stop working
<seb128> that's how you would run your im client as well
<seb128> or other things you want to start with your session
<didrocks> seb128: not exactly, as unity will provide:panel now with the new system
<jdstrand> seb128: ok, so if I do that, then make sure that I don't use the window list, I should be fine to sue my applets for the forseeable, yes?
<didrocks> seb128: so gnome-panel will maybe tell "there is already a panel in that session"
<seb128> didrocks, well, I described a way that doesn't touch required components
<didrocks> seb128: hence the fact I'm thinking about it
<didrocks> seb128: I'm talking about the new system which needs to touch required components
 * jdstrand is worried
<seb128> hum ok
<seb128> I will let you sort that
<seb128> jdstrand, yes
<bdrung> cjwatson, cody-somerville, geser, persia, soren, stgraber: Quick reminder: DMB meeting it three hours.
<didrocks> jdstrand: no worry, I'll look at that
<jdstrand> didrocks: thanks. please at least allow for a way for us geeky developers to run some of our stuff, even if we have to jump a hoop or two to get there :)
<didrocks> jdstrand: well, I think adding to the session is a reasonable tradeoff
<didrocks> jdstrand: the thing is that it will impact your ubuntu classic session
<jdstrand> didrocks: I am totally fine with that
<didrocks> jdstrand: so, you will get the same one panel, and suchâ¦
<jdstrand> hmmm, I am going to really screw up my Classic Desktop if I fiddle with this enough...
<sebner> jdstrand: without using compiz \o/
<didrocks> jdstrand: yeah, the configuration is common, it's basically the same issue I got in lucid for UNE vs gnome session
<jdstrand> I wonder if I can just remove top_panel_screen0 from the /apps/panel/general/toplevel/toplevel_id_list...
<didrocks> jdstrand: you can, but it will still impact both sessions
<jdstrand> well, I can at least do gconftool-2 --dump /apps/panel > classic-panel.xml
<jdstrand> and then use --load to get it back
<jdstrand> that should be ok
<didrocks> jdstrand: quite hackish but yeah :)
<jdstrand> didrocks: sound reasonable?
<didrocks> that should work :)
<jdstrand> I hope to not go back. I just want a safety net :)
<didrocks> in fact, it's not very different to what compiz is currently doing with the gconf backend on profile change
<doko> ScottK: any progress on 661901?
<hallyn_> hm, if i don't miss my guess, installing banshee caused me to lose all my radio links in rhythmbox
<micahg> ScottK: aspell-id, the packager is going through Debian instead and the version should've been different
<ScottK> Looking
<ScottK> micahg: Looks like someone got it already.
<micahg> ScottK: ok, great, thanks
<ScottK> doko: Updated.
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Natty Alpha 1 released! | Archive: Open | 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:
<doko> ScottK: did you look at these packages at all?
<ScottK> doko: I did not review the source.  I was just trying to help clear up component mismatches and Main depwait when I filed the original bug.
<ScottK> doko or barry: Will you merge python-defaults from Experimental (I don't have time to look at it this week, but it would enable me to sync the last non-dh_python2 Python package I maintain in Debian).
<doko> I can do this this week
<cjwatson> ScottK: if it helps any by way of motivation, I just merged ebroder's backport-helper branch into ubuntu-archive-tools
<ScottK> cjwatson: That's great news.
<cjwatson> I would love to have a real backport request to try it out on. :-)
<ScottK> cjwatson: Bug #685982
<ubottu> Launchpad bug 685982 in maverick-backports "Please backport gmtp 0.7-1 from Natty to Maverick" [Wishlist,In progress] https://launchpad.net/bugs/685982
<ScottK> That should be good to go.
 * cjwatson gives it a go
<cjwatson> (looks ok, I'm just beefing up the script a bit in light of that)
 * ScottK nods
<quadrispro> hi all!
<quadrispro> ScottK, thanks for bug #685982
<ubottu> Launchpad bug 685982 in maverick-backports "Please backport gmtp 0.7-1 from Natty to Maverick" [Wishlist,In progress] https://launchpad.net/bugs/685982
<cjwatson> quadrispro: we're running it as a test case for the new archive admin backport-helper tool
<quadrispro> good to know
<cjwatson> ScottK,ebroder: excellent.  I made some extensions (although ebroder's initial version was perfectly functional), and this seems to be working quite smoothly now.
<cjwatson> ScottK,ebroder: I think I can commit to running this just as frequently as I run sync-helper now, which is normally at least once per working day.
<ScottK> cjwatson: Great.  It seems then that some documentation on the archive-admin page and we're done.
<ScottK> cjwatson: Thanks.  That will help a lot.
<cjwatson> yep, off to do that now
<cjwatson> mind you, sync-helper isn't documented either
<ScottK> Ah.  Good point.
<cjwatson> done now
<cjwatson> ebroder: the one thing this doesn't get quite right is that it uses the requestor as the Changed-By, rather than the backport-approver as specified in ArchiveAdministration.  Maybe this needs to scan through comments for a backports team member or something?
<cjwatson> (Changed-By> i.e. -b in mass-sync.py input)
<tkamppeter> pitti, I have loaded a bug fix on the PDF filters into the CUPS repo, please take it into account when uploading.
<mterry> RoAkSoAx, were you going to do the -V thing for cluster-glue or were you still waiting on feedback?
<pitti> tkamppeter: why did you "merge" the new upstream release commit?
<tkamppeter> pitti, I did the following:
<tkamppeter> I did "bzr pull" and got "up to date", then I applied the patch from Koji Otani and tested it, taking something like half an hour. Then I made a debian/changelog entry.
<pitti> tkamppeter: ok, I cleaned up; can you please do "bzr pull --overwrite" in your checkout?
<tkamppeter> pitti, after that I did "bzr commit" and "bzr push"
<pitti> tkamppeter: oops, forgot something; fixed, please pull --overwrite again
<tkamppeter> So my patch is now in the repo, too?
<\sh> micahg: I'm preparing zend-framework 1.11.1 for upload...could you do the backport stuff later on? :)
<pitti> tkamppeter: yes
<tkamppeter> pitti, thank, and sorry, it was really a coincidence, we worked on CUPS exactly at the same time.
<micahg> \sh: yep, thanks
<pitti> tkamppeter: right, apparently; sorry for the mid-air collision
<pitti> tkamppeter: do you have other things you want to land in cups, or should I do an upload?
<\sh> micahg: thx a lot :)
<tkamppeter> pitti, now you can do it, thanks.
<pitti> ok
<\sh> micahg: uploaded
<RoAkSoAx> mterry: I'm doing the -V thing, I just wanted to test some other unrelated stuff before uploading
<mterry> RoAkSoAx, OK, no rush.  Just wanted to make sure you weren't waiting on me
<RoAkSoAx> mterry: ok :). Will let you know when I upload! Thanks!
<kees> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Natty Alpha 1 released! | Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: kees
<ari-tczew> kees: could you sponsor this one? https://code.launchpad.net/~clint-fewbar/ubuntu/natty/php5/fix-mssql-segfault/+merge/42705
<kees> ari-tczew: sure, let me take a look at it. thanks for bringing it up. :)
<kees> ari-tczew: can you flip your review to "approved" for that one, if you're okay with it?
<ari-tczew> kees: for above case I need again testbuild, let me look
<kees> ari-tczew: oh, I thought your review comments were mostly about the patch format?
<ari-tczew> kees: quite. why you ask?
<kees> ari-tczew: I guess I meant, it doesn't need a rebuild test if it was just the patch formatting you wanted to see changed. if the way it looks is good with you, I can upload it.
<kees> ari-tczew: but I was hoping you could change your review from "Needs Fixing" to "Approved"
<ari-tczew> kees: aha, I would like test build again.
<kees> ari-tczew: okay, sounds good
<ari-tczew> to make sure
 * kees nods. good idea
<ari-tczew> kees: so for time building, could you sponsor my merge? bug 684874
<ubottu> Launchpad bug 684874 in rabbitmq-server (Ubuntu) "Merge rabbitmq-server 2.2.0-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/684874
<kees> ari-tczew: sure! let me go read that one too.
<ari-tczew> kees: btw I had an a case to security team and I would to be on meeting, but I've falled asleep :/
<ari-tczew> fallen *
<kees> ari-tczew: no worries, feel free to email too.
<ari-tczew> kees: nothing important
<kees> ari-tczew: so, for rabbitmq-server, did you review the diff between 2.2.0-0ubuntu1 and 2.2.0-1 ?
<ari-tczew> kees: yes
<ari-tczew> I have it on disk
<kees> okay, cool.
<lifeless> kees: hey hey
<kees> let me finish the php5 thing, and I'll do this one next. one moment...
<lifeless> kees: so, i didn't hear back
<kees> heya lifeless
<lifeless> kees: hows the performance?
<kees> lifeless: let me start a quick download, one sec.
<kees> lifeless: reasonably fast, no 503s. I remain happy. :)
<lifeless> :)
<zzak> Hello everyone, I was wondering where might be the best place to ask about maintaining an out of date package for ubuntu? It's been over 2 years since the last release.
<kees> ari-tczew: okay, looking at rabbitmq-server closely now. Usually, it's easier to review a debdiff between the Debian package version and the to-be-uploaded Ubuntu package version. In this case, 2.2.0-1 vs 2.2.0-1ubuntu1. Your debdiff is between 2.2.0-0ubuntu1 and 2.2.0-1ubuntu1.
<kees> I think what you've got is very close to correct if not already 100% correct, but I'm just poking at it from the other direction now.
<mterry> lifeless, ping about python package names
<vorian>  /12
<lifeless> mterry: hi
<mterry> lifeless, I just fixed a bug you filed about the name of python-quickly-widgets (nee quickly-widgets).  But realized that in your bug, you recommended python-quickly.widgets.  Is that right?  With the period instead of a dash?
<lifeless> mterry: foo-bar isn't a valid python module name
<lifeless> mterry: is the code accessed via 'import quickly.widgets' ?
<lifeless> mterry: if so then the package/module *is* 'quickly.widgets' and the package name should be python-$packagename -> python-quickly.widgets
<lifeless> mterry: see e.g. python-zope.interfaces
<kees> ari-tczew: I'll be uploading this shortly; have you forwarded the delta to Debian for rabbitmq-server by any chance?
<ari-tczew> kees: I thought that this is Ubuntu-related delta.
<kees> ari-tczew: there's a debian change to the watch file too, which I figure should probably track Debian.
<mterry> lifeless, understood.  I just had a hard time finding that in the policy manual, so I thought I'd ping you.  This package also provides quickly.prompts, but that is a secondary smaller module, so I believe the policy says it can just be subsumed into the more important quickly.widgets package?
<kees> ari-tczew: it's not clear to me. neither Ubuntu nor Debian had rabbitmq-server packages prior to version 1.6.0, so I'm not sure why that delta is there at all.
<lifeless> mterry: policy is pretty flexible here, for good or bad :)
<ari-tczew> kees: I also dunno.
<ebroder> mterry: It's in the Python policy. http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names
<ebroder> Err...I thought it was. Maybe it's not
<lifeless> ebroder: its not precise enough to disambiguate
<lifeless> ebroder: perhaps we should propose a patch to clarfiy
<ScottK> Patches welcome.
<lifeless> ebroder: the handling of multiple modules is there.
<ebroder> lifeless: I definitely saw something somewhere recently that wasn't ambiguous...
<mterry> lifeless, a simple example would be good
<kees> ari-tczew: actually, based on bug #506985, I think this delta should have been dropping in maverick/
<ubottu> Launchpad bug 506985 in rabbitmq-server (Ubuntu Lucid) "Upgrade from rabbitmq-server 1.54 -> 1.7.0 wiped users and vhosts" [High,Fix released] https://launchpad.net/bugs/506985
<kees> zul: can you verify that to be true?
<kees> zul, ari-tczew: if so, this should just be a sync.
<zul> reading backlog
<ari-tczew> +1
<zul> kees: yeah it was in the release notes when they upgraded from the previous verison they get a warning
<lifeless> mterry: anyhow, long answer short: the . is deliberate and appropriate
<kees> zul: right, but it should have only been for Lucid, right? If that's true, we can just drop this delta and sync?
<mterry> lifeless, gotcha, will fix
<zul> kees: right
<kees> zul: sync it is. :)
<kees> jdstrand: can I borrow you for a moment to perform a sync for me? rabbitmq-server care of bug #684874?
<ubottu> Launchpad bug 684874 in rabbitmq-server (Ubuntu) "Sync rabbitmq-server 2.2.0-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/684874
<jdstrand> kees: sure
<ari-tczew> kees: or you can use script syncpackage :)
<kees> ari-tczew: that just creates a new bug; I wanted to actually close the merge you had open (I converted that merge bug into a sync bug)
<ari-tczew> kees: syncpackage rabbitmq-server -b 684874
<ebroder> kees: You're confusing requestsync and syncpackage
<ari-tczew> kees: however, I'm fine with converted request. let's jdstrand do this (:
<kees> ebroder: ah, so I am. what does syncpackage actually do? isn't it preferred for archive admins to do the sync?
<cjwatson> It is.
<cjwatson> syncs happen in <1 working day nowadays.
<kees> ah, righto. quick read of the code shows that syncpackage is just a manual sync. I'll wait for jdstrand to DTRT instead. :)
<ebroder> cjwatson: Is there an interesting difference in end result between the archive admins doing a sync and syncpackage doing a sync?
<kees> SpamapS: I'll be uploading your php5 merge in a few minutes; waiting for the testsuite to finish now.
<ebroder> cjwatson: Oh, also - I'll take a look at fixing the uploaded-by for backport-helper. I wasn't paying attention when I picked what name to use there. Something like looking for the "last backports team member that set the bug to IN PROGRESS" should be easy
<cjwatson> ebroder: we might be willing to debug it if something went wrong with the former. :)
<cjwatson> (it's a verbatim copy and there are essentially no checks that it really is verbatim - having it be server-side is more robust)
<cjwatson> ebroder: cool, thanks
<SpamapS> kees: awesome thanks! :)
<kees> jdstrand: thanks!
<kees> ari-tczew: thanks for the help! php5 has been uploaded, and rabbitmq-server synced. :)
<jdstrand> kees: sure!
<ari-tczew> kees: np. I want to review also main requests as it's helpful to clean up SQ.
<ari-tczew> kees: every patch pilot from Canonical works on cleaning up ?
<smoser> cjwatson, you have a suggestion about how i can put a change into /etc/grub/default and register that change such that subsequent 'update-grub' will not prompt user for merge ?
<smoser> (this is on lucid)
<kees> ari-tczew: well, I'm just trying to knock items off the sponsor queue, yeah
<cjwatson> smoser: update-grub never prompts for mergign
<cjwatson> *merging
<smoser> oh. you're right. it does not. i should have subsequent grub-pc install/upgrade
<cjwatson> smoser: you can't, then, it's a dpkg conffile
<cjwatson> trying to muck with that makes the problem worse
<cjwatson> it's best to keep conffile changes simple
<smoser> hm... well, maybe you can suggest a different path for me then.
<cjwatson> currently in an overrunning meeting and with a splitting headache ... not really in the right frame of mind to be able to think creatively :)
<smoser> alright. i'll send a mail then.
<ari-tczew> kees: btw, you have 2 things sponsored for me (non-security stuff), I'm curious whether this number will grow up. (:
<soren> cjwatson, smoser: /etc/default/grub isn't a conffile.
<soren> (assuming that's what is meant when you say /etc/grub/default)
<smoser> soren, (at least on lucid) try changing a value there, and then 'apt-get install --reinstall grub-pc'. you'll get a prompt that is a result of
<smoser>     ucf --three-way --debconf-ok --sum-file=/usr/share/grub/default/grub.md5sum ${tmp_default_grub} /etc/default/grub
<soren> Precisely.
<smoser> so no, not a conf file, but that is my issue.
<soren> ucf => not a conffile
<smoser> you're right.
<soren> I've seen various tricks applied for this sort of thing.
<soren> grub (old grub) had some magic for it.
<ebroder> soren, smoser: I thought the fact that ucf is doing a 3-way meant that you should only get prompted once (at least until the next time upstream /etc/default/grub changed)
<soren> True.
<smoser> ebroder, while that may be the case, its still less than ideal for me.
<soren> There's a command line option to update ucf's cache.
<smoser> it doesn't work here, as far as I can tell. i've tried.
<soren> smoser: Really? Sorry, I must have misunderstood what you're trying to achive?
<kees> jdstrand: can I bug you for another sync? this time from experimental? bug #686099, request from the debian maintainer.
<ubottu> Launchpad bug 686099 in packagekit (Ubuntu) "Sync packagekit 0.6.10-1 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/686099
<smoser> because sum-file comes from /usr/share/grub/default/grub.md5sum (which is part of the package, and will contain the new version).
<jdstrand> kees: sure
<kees> jdstrand: thanks!
<ebroder> smoser: That's only for versions of the file that existed before the package switched to ucf. ucf also maintains its own cache
<smoser> i've tried, mabye i'm missing something.
<soren> Explain what you've tried.
<smoser> sudo ucfr --debug --verbose grub-pc /etc/default/grub
<smoser> ie, a.) make change to /etc/default/grub b.) run ucfr grub-pc /etc/default/grub c.) run sudo apt-get install --reinstall grub-pc
<smoser> d.) get prompted
<smoser> soren, is that not what i should expect would tell ucf that I have updated that file?
<soren> smoser: Er... Even on reinstall?
<jdstrand> kees: done
<soren> smoser: That should never trigger a prompt. Even if you didn't muck about with ucfr.
 * jdstrand waves hi to soren 
<soren> smoser: If the package being installed doesn't contain a change to the contents of the file compared to the last installed version of the same package, any changes you made to the file are just kept.
<soren> jdstrand: dude!
<jdstrand> :)
<soren> smoser: That's what dpkg does (and ucf attempts to mimic).
<smoser> well, it is doing that for me. on ec2 instance.  possibly i'm doing something terribly rude in image build
<soren> smoser: Possibly.
<soren> smoser: Can you reproduce it on your laptop?
<soren> smoser: My test involes changing one of the comments in the file.
<smoser> comment wont work.
<soren> Oh, it's filtered?
<smoser> has to be somethign that will get through to /boot/grub/grub.cfg
<soren> Bah, of course.
<soren> Same thing.
<soren> Oh, hang on.
<smoser> the thing i'm changing is '#GRUB_TERMINAL=console'
<smoser> uncommenting
<smoser> but also changes to GRUB_CMDLINE_LINUX_DEFAULT= like adding 'foo=bar' affect it (on 10.04)
<soren> On 10.10 as well.
<soren> That shouldn't happen.
<smoser> tried on natty, and do not get prompted
<soren> Aah...
<soren> Ok.
<smoser> its strange, i'm not seeing the issue now though. soren did you have an explanation ?
<soren> Half.
<smoser> do you care to share ?
<soren> I'm trying to :)
 * smoser puts hands to temples and attempts to get soren's mind message
<soren> Don't. You'll be as confused as I am.
<RoAkSoAx> slangasek: howdy!! I have a question regaring a library split. In debian/rules, there's a binary-common: target on which dh_makeshlibs is without the -V option. This -V is necessary if there are no .symbols files, right?
<mdeslaur> cjwatson: we're not installing gnome-system-tools anymore in natty? no more graphical tool to add a second user?
<soren> smoser: Sorry, I don't think I can wrap my head around this at this hour.
<smoser> no problem. have a nice night soren.
<RoAkSoAx> win 5
<SpamapS> woohoo.. cassandra packages running unit tests. :)
<lifeless> nice
<RoAkSoAx> mterry: ok I think i'm ready to upload. Were you able to get feedback for the -V to dh_makeshlibs?
<mterry> RoAkSoAx, oh no, I wasn't yet.  I'll ping tomorrow
<RoAkSoAx> mterry: should I wait to upload, or should I just go ahead and do it?
<mterry> RoAkSoAx, uh I guess upload and we can always back it out.  I think the assumption was that if this other package did it, it was the correct thing, right?  I'm just double-confirming with someone who would actually konw
<RoAkSoAx> mterry: alright then. it is done :)!
<Sarvatt> nasty, I've counted at least 150 bugs here so far caused by this limitation not being more common knowledge - https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/562312/comments/7
<ubottu> Ubuntu bug 562312 in initramfs-tools (Ubuntu) "package initramfs-tools 0.92bubuntu71 [modified: usr/sbin/update-initramfs] failed to install/upgrade: lzma: Encoder error: -2147467259" [Undecided,Triaged]
<ebroder> Sarvatt: Workaround: use a USB drive larger than 4G, so that the FAT file size limitations prevent users from actually using all remaining space
 * ebroder ducks
<bdrung> persia: around?
#ubuntu-devel 2010-12-07
<kees> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Natty Alpha 1 released! | Archive: Open | 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:
<bdrung> persia: can you please have a look at https://wiki.ubuntu.com/fakesync and extent it / improve the wording?
<ebroder> ari-tczew: I was skimming the sponsorship queue and noticed bug #615734. Was there a particular reason you asked tjcasey to switch to bzr? As long as both bzr and debdiffs are considered acceptable ways of getting sponsorship, I don't think we should be asking contributors to jump back and forth between the two based on personal preference
<ubottu> Launchpad bug 615734 in libass (Ubuntu) "Update to version 0.9.11" [Wishlist,Incomplete] https://launchpad.net/bugs/615734
<YokoZar> latest natty kernel package doesn't seem to be installable on my natty vm...
<RAOF> Installed for me :)
<yao_ziyuan> i think the no.1 problem in gnome is probably the desktop icon text color. it's white and just doesn't work with light wallpapers. i found a perfect solution.
<yao_ziyuan> put a gtkrc-2.0 file in your home dir with this content: http://fpaste.org/jpvP/ . this will set your desktop icon text color to black, and put a 50%-translucent round-cornered box around the text.
<yao_ziyuan> the purpose is that whether your wallpaper is dark or light, desktop icon text will always be highly contrasted. i recommend it be a default configuration for ubuntu.
<StevenK> yao_ziyuan: That sounds like a great suggestion -- I'd recommend you file a bug so it doesn't get lost.
<yao_ziyuan> StevenK: thanks for encouragement
<yao_ziyuan> StevenK: i'm actually using fedora but it doesn't matter
<yao_ziyuan> StevenK: i found an existing ubuntu bug report concerning exactly the same issue: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/643836
<ubottu> Ubuntu bug 643836 in nautilus (Ubuntu) "desktop icon text hard to read on white backgrounds" [Low,Triaged]
<yao_ziyuan> StevenK: it blamed the upstream (gnome). should i add a comment providing my near-perfect solution, or create a new bug report
<yao_ziyuan> i guess adding a comment
<omdag> hi
<omdag> anyone around
* omdag changed the topic of #ubuntu-devel to: NO FUCKING NIGGERS ALLOWED!
* omdag changed the topic of #ubuntu-devel to: NO FUCKING NIGGERS ALLOWED! We hate niggers! We hate faggots! Fun nigger facts: 1/3 of all adult male niggers will spend time in jail or prison. 70% of niglets were shit out of wedlock
* omdag changed the topic of #ubuntu-devel to: NO FUCKING NIGGERS ALLOWED! We hate niggers! We hate faggots! Fun nigger facts: 1/3 of all adult male niggers will spend time in jail or prison. 70% of niglets were shit out of wedlock
* omdag changed the topic of #ubuntu-devel to: NO FUCKING NIGGERS ALLOWED! We hate niggers! We hate faggots! Fun nigger facts: 1/3 of all adult male niggers will spend time in jail or prison. 70% of niglets were shit out of wedlock
* omdag changed the topic of #ubuntu-devel to: NO FUCKING NIGGERS ALLOWED! We hate niggers! We hate faggots! Fun nigger facts: 1/3 of all adult male niggers will spend time in jail or prison. 70% of niglets were shit out of wedlock
* omdag changed the topic of #ubuntu-devel to: NO FUCKING NIGGERS ALLOWED! We hate niggers! We hate faggots! Fun nigger facts: 1/3 of all adult male niggers will spend time in jail or prison. 70% of niglets were shit out of wedlock
* cjwatson changed the topic of #ubuntu-devel to: Natty Alpha 1 released! | Archive: Open | 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:
<cjwatson> (sorry for slow reflexes)
<CarlFK> http://dpaste.de/LZ1X/  software-properties$ bzr diff - what is the process for submitting a patch?
<micahg> CarlFK: https://wiki.ubuntu.com/Bugs/HowToFix#Using%20Ubuntu%20Merge%20Proposals
<CarlFK> micahg: thanks.  figured there was something like that
<didrocks> good morning
<dholbach> good morning!
<didrocks> hey dholbach!
<dholbach> salut didrocks
<didrocks> dholbach: I filed a bug against the kernel as I got no answer in #ubuntu-kernel, want to subscribe?
<dholbach> sure
<didrocks> dholbach: bug #686070
<ubottu> Launchpad bug 686070 in linux (Ubuntu) "black screen (no more gdm/X server) with nvidia propriatery after gfxpayload=keep activation" [Undecided,New] https://launchpad.net/bugs/686070
<dholbach> gracias
<didrocks> yw :)
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Natty Alpha 1 released! | Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: didrocks
<didrocks> "welcome onboard" :)
<ebroder> Whooo!
<dholbach> yooohoooo!
<pitti> Good morning
<Huawei> hello
<hekireki> Hey guys
<hekireki> I've built a deb package for my app, and i'd like it to be downloadable via apt, how can i do that ?
<CarlFK> hekireki: /j #launchpad and ask about PPA
<hekireki> thanks you carl
<\sh> hmmm...why is dh_autotools-dev_{restoreconfig,updateconfig} in autotools-dev and not in debhelper ? even if the man page says, that it belongs to debhelper 7?
<hyperair> wait, there's a dh_autotools-dev?
<hyperair> what happened to dh_autoreconf?
<\sh> hyperair: since maverick it seems...
<hyperair> what
<dapal> \sh, hyperair: they're different
<hyperair> dapal: eh?
<dapal> dh_autoreconf runs "autoreconf -f -i"
<hyperair> ah yes
<hyperair> config.guess/sub
<dapal> thus changes Makefile.in's, for example
<dapal> exactly
<dapal> dh_autotools-dev_* only changes config.{guess,sub}
<dapal> and that's the reason why it's in autotools-dev: they need the config.guess/sub copies
<dapal> i.e. /usr/share/misc/config.sub and /usr/share/misc/config.guess
<hyperair> makes sense.
<hyperair> what 's config.sub and config.guess for again?
<dapal> they're for architecture-specific things, AFAIR
<dapal> but please don't ask more, I hate autofools :-p
<dapal> (just because I don't know much)
<hyperair> heheh
<\sh> dapal: but wouldn't it make more sense, to include the debhelper scripts into debhelper itself and not in packages which are not related to debhelper actually?
<hyperair> \sh: it's autofools specific
<hyperair> just like how dh_quilt* is in quilt.
<dapal> \sh: and then make debhelper depend on autotools-dev? Nasty. :)
<dapal> hyperair: (or dh_bash-completion is in bash-completion, or [..])
<hyperair> yeah
<dapal> anyway, who uses dh_quilt these days? 3.0 (quilt) rocks \o/
<\sh> hmm...I see it a bit different...someone who wants to change config.{sub,guess} will always include autotools-dev, the dh_autotools-dev_* stuff is a wrapper to some manual shell magic imho (i didn't take a deeper look at those scripts), so for me it belongs more into debhelper then in another package..anyways...it's probelmatic now to build a source package on lucid with those commands inside debian/rules...
<hyperair> dapal: i use it when i need to do things before patching.
<hyperair> dapal: on older ubuntus
<dapal> ah, yes. :)
<hyperair> stuff like ltmain.sh
<hyperair> speaking of which, i hear that libtool's been fixed and we can drop the patch now
<hyperair> is that true?
<hyperair> and since when?
<dapal> oh, well
<dapal> I've been patching ltmain.sh since ages
<hyperair> yeah same here
<hyperair> rather, ever since i inherited banshee, i've been patching ltmain
<dapal> is libtool being fixed just a rumour? :-p
<hyperair> lol, maybe. =p
<DktrKranz> mvo: I wonder if you had the time to look at a synaptic merge proposal I did some time ago (https://code.launchpad.net/~dktrkranz/synaptic/manual/+merge/42026)
<mvo> DktrKranz: briefly, let me check it out again
<mvo> DktrKranz: I commented on the bug, I'm a bit unsure about it, but I guess its the right approach
<DktrKranz> mvo: it won't exclude other important bits (i.e. some key packages installed by tasksel, or equivalent), but at least it doesn't show apt, dpkg, tar, and thelike
<DktrKranz> I'm trying to see if there's a way to do so, didn't come to a solution yet, though
<pitti> mdz: did you recently change the tech-board LP settings? the moderation queue now gets tons of merge proposals, and I started getting every TB mail twice
<mdz> pitti: yes, I set the contact email address for the team to the mailing list
<pitti> mdz: seems TB is somehow involved in all these merge proposals then
<mdz> pitti: should I undo that change?
<mdz> while we track down why?
<pitti> mdz: it's not hard to delete them from the moderation queue, but I wonder why they are landing there in the first place
<pitti> seems tech-board is a default reviewer for ubuntu branches or so?
<pitti> mdz: you did that because someone used "contact user" for the xubuntu  mail, right?
<mdz> pitti: probably we are a member of some other team which is
<pitti> mdz: I guess it just landed in a different folder for me then, thus I didn't see the original email where I saw sabdfl's reply
<mdz> pitti: I'm actually subscribed to merge proposals for Ubuntu anyway, so I didn't notice
<didrocks> pitti: btw, I didn't touch the language-selector and gdm changes for $LANGUAGE. I think the reporter subscribed you, the diff is quite large and you know the issue/functionnality :)
<pitti> didrocks: right; I unsubscribed sponsors for that, for this very reason
<pitti> it'd take ages for someone else to catch up
<didrocks> that was my guess :)
<hron84> Hi! I would like to know where finds the GDM its configuration file.
<hron84> I use Ubuntu Lucid
<pitti> hron84: gdm has a lot of configuration; what kind of config are you looking for?
<pitti> (per-user or global, autologin vs. how to start the session, language vs session type, etc.)
<hron84> I would like tell to it to donÂ´t start Xorg as first VNC server, but Xvnc
<hron84> ahh
<hron84> I would like tell to it to donÂ´t start Xorg as first  server, but Xvnc
<hron84> i have a config file, i know what i need to do, but gdm doesnÂ´t accepts the config file from standard places.
<pitti> erm, Xvnc isn't an X server
<hron84> Ok.
<hron84> I know
<hron84> pitti: i know. IÂ´mnÂ´t a newbie of linux or Ubuntu, just i use GDM and Xvnc very rarely on Ubuntu, i usually config it on Debian.
<pitti> hron84: you might be able to set it in /etc/gdm/custom.conf, but I'm not sure whether the X server to use is configurable
<hron84> pitti: i tried it, but GDM doesnÂ´t accepts the config from here.
<pitti> hron84: it does use the file, though; it's where we put autologin etc. settings
<Kano> hi, is it a running gag that your iso images even for natty use a new enough isolinux version but they are still not hybrid because of missing isohybrid command?
<ScottK> cjwatson: grantlee (via build-depends from kde4libs) is only used by KDE in Main, but isn't in the Kubuntu packageset.  It may be just because it's newly in Main, but it seems to me that it should be.
<cjwatson> ScottK: kde4libs has to be overridden into the kubuntu set because it's so deep in the dependency chain.  I've added an exception for grantlee to match.
<ScottK> cjwatson: Thanks.
<ScottK> barry: Looks like pyrex is blocking 2.7 for some other packages (it's built for 2.7, so it's a works with 2.7 problem, not a rebuild issue). http://launchpadlibrarian.net/60079969/buildlog_ubuntu-natty-i386.python-evas_0.5.0%2Br49677-1build1_FAILEDTOBUILD.txt.gz
<Kano> cjwatson: whats up with your iso builds, cant you trigger isohybrid at the end
<Kano> bug 524803
<ubottu> Launchpad bug 524803 in Ubuntu CD Images "isolinux hybrid mode should be used - all other major distributions do so since last year" [Undecided,New] https://launchpad.net/bugs/524803
<cdbs> kees: there? Does the fetchmail package create a fetchmailrc? I don't think so, and it has START_DAEMON=yes by default in the /etc/default/fetchmail .
<cdbs> so this is a clash
<Daviey> Hmm... Does pbuilder standard config rebuild the debian.orig.gz?  I have the one that went in, and the one that came out (result), and they binary differ by sum.. but diffing contains the same contents... I'm quite suprised it seems to have repacked it... any ideas?
<didrocks> ok, time to fully switch again to normal day job, ejectionâ¦ :)
<didrocks> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Natty Alpha 1 released! | Archive: Open | 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:
<et_> Can someone help disable cd rom drives on ubuntu?
<et_> Need it for a project
<et_> I need to deny access to CD ROM drive to certain users.  But so far, I'm unable to do so
<et_> can anyone give me a pointer?
<cdbs> !support | et_
<ubottu> et_: The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.
<et_> sorry.. & thanks.
<kenvandine> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Natty Alpha 1 released! | Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: kenvandine
<avinashhm> hi, any one tried copying kernel source repos from one PC to another using NFS mount ??? stuck with 'Stale NFS file handle' errors .. any help ??
<dnivra> hello. I am working on LP: #647045 and have something weird happening. I edit the only occurrence of the 'Handler silently failed' in the entire source code of apt and yet it displays the same error. How is that even possible?
<dnivra> LP:#647045
<ScottK> bug 647045
<ubottu> Launchpad bug 647045 in apt (Ubuntu Natty) "apt-cache rdepends returns cryptic error message" [Medium,Confirmed] https://launchpad.net/bugs/647045
<dnivra> Thanks ScottK.
<ScottK> You're welcome.
<juliank> dnivra: In which file is the message?
<dnivra> juliank, apt-pkg/contrib/cmndline.cc
<juliank> dnivra: Then, did you set LD_LIBRARY_PATH? And really, that
<dnivra> juliank, it should point to? currently it points to /usr/local/lib.
<juliank> dnivra: If you are running ./build/bin/apt-get you must also set LD_LIBRARY_PATH=./build/bin, otherwise it loads the old library
<dnivra> which is the already existent unmodified library! well i didn't know that. thanks juliank!
<dnivra> is it enough if I append './build/bin' to LD_LIBRARY_PATH or should it be the only value?
<dnivra> juliank, thanks a lot! I've been breaking my head over this for whole of today-nearly 12 hours now.
<juliank> dnivra: That's your thing. But the bug has to be fixed in cmdline/apt-cache.cc anyway, not in cmndline.cc
<dnivra> juliank, i think the function 'DispatchArg' in cmdline.cc is what is called from apt-cache.cc, which prints the dependencies. I check it with gdb-it's immediately after the function call 'CmdL.DispatchArg(CmdB)' in line 1865 of apt-cache.cc that the dependencies are printed. but I'm not too sure about that.
<juliank> dnivra: The bug is around line 590 of cmdline/apt-cache.cc
<juliank> it returns false without creating an error first
<dnivra> juliank, gotta check it out then. i'm still learning how apt works. and all I know for sure is that DumpErrors prints out the errors :D.
<juliank> dnivra: I already pushed a fix into the debian-sid repository (mvo: fix for 647045 is in debian-sid)
<dnivra> juliank, oh! okay then. time to find another bug. can i see the fix you made-link?
<mvo> juliank: thanks
<juliank> dnivra: The fix can be seen at http://bzr.debian.org/scm/loggerhead/apt/debian-sid/revision/2054
<dnivra> it fixes both rdepends and depends? cos I had the same problem with depends too. just asking.
<juliank> It prints 'E: No packages found' now if no package could be found.
<juliank> dnivra: rdepends just calls depends with a reverse switch on.
<juliank> => yes
<dnivra> juliank, oh yeah true the same function! i forgot :).
<juliank> dnivra: I did not want to take away your bug fun, but this was just too simple to have the ping-pong a patch involves.
<dnivra> juliank, can i ask something- in the patch made, return _error->Error(_("No packages found"));, why is there an _ after Error(. i edited a line exactly like this-added to cmndline.cc actually but it complained error: stray '_' or something.
<juliank> dnivra: _ is a function (well, it's a macro that calls gettext())
<juliank> _("DD") == gettext("DD") == your translation of "DD"
<dnivra> i see. hmmm wonder why that error arose then. oh well bug is fixed good enough :)
<dnivra> juliank, not the first time :). i patched a bug in gedit long ago but then it was rejected by gnome/ubuntu desktop-i forget. i followed the discussion for a long time and after that lost interest seeing it won't be fixed and so unsubscribed. then, i used this bug to do a session on contributing to ubuntu-thought of showing this as a live fix-and so downloaded the latest source file only to find that the bug was fixed :).
<juliank> dnivra: APT has around 700 other bugs (600 in Debian, 100 in Ubuntu), so if you want something to work on something in APT, you might find something.
<dnivra> juliank, i'm okay with any bug-i'm pretty new to bug fixing. still finding my way around. been working on this bug for nearly a week now so you get the picture right :).
<juliank> dnivra: Than you might want to hack on something else than old obscure complicated APT code.
<dnivra> oh okay then. will do.
<barry> ScottK: reading backlog.  re: pyrex issue.  is there a bug open on that yet?
<ScottK> barry: no.
<ScottK> (or not AFAIK)
<dnivra> i picked this apt bug randomly and started on it. learnt a lot while attempting to fix it.
<barry> ScottK: ok
<barry> ScottK: https://bugs.launchpad.net/ubuntu/+source/python-evas/+bug/685492
<ubottu> Ubuntu bug 685492 in python-evas (Ubuntu) "FTBFS in natty" [Undecided,New]
<barry> ScottK: if it turns out to be a pyrex bug, i'll open a new one
<slangasek> RoAkSoAx: 'dh_makeshlibs -V' is low-maintenance and usually works, but it's also usually not very accurate
<doko> seb128, pitti: could you have a look at the libgda4 build failure? gir issues
<pitti> I have a meeting now, so afterwards
<mdz> thanks for the brainstorm reply, pitti
<geser> lucas, lool: re the apport FTBFS: I can reproduce it with my natty pbuilder. I usually also use tmpfs for it, so I tried without tmpfs (ext4 instead) -> same FTBFS. I've put both logs on http://www.bienia.de/tmp/ubuntu/ if you want to compare both (they differ).
<pitti> mdz: yw; please let me know if you think I should take this anywhere else
<mdz> pitti: I wish brainstorm had anchors for the comments; it's impossible for me to link directly to your response
<pitti> mdz: fortunately the thread isn't very long
<cjwatson> lamont: dunno if you noticed, but making the livefs builds use --force-unsafe-io took 16 minutes or so off the amd64 and i386 build times
<cjwatson> (out of ~38 minutes)
<mdz> cjwatson: is that a dpkg option?
<ebroder> cjwatson: Do the buildds have enough RAM and/or swap that you could do the builds into a tmpfs? That made a *huge* performance difference for my livefs builds
<cjwatson> mdz: yes, new
<cjwatson> ebroder: https://blueprints.launchpad.net/ubuntu/+spec/other-foundations-n-cd-build-speed
<cjwatson> "[lamont] Switch to tmpfs for non-DVD builds: TODO"
<ebroder> Haha, ok :)
 * ogra_ac doubts that building in swap makes a huge difference
<ebroder> Yeah, sure - you've lost once you hit swap. The concern is more over OOMing before you can finish
<ogra_ac> well, my builds usually happen on machines that dont have much ram
<ogra_ac> (read ARM)
<cjwatson> powerpc only got 6 minutes faster out of 40; armel+omap4 got 3 minutes faster out of 62
<cjwatson> (haven't checked how much variance there is there, though!)
<cjwatson> I imagine you need to be bottlenecked on I/O before it makes much of a difference
<pitti> sconklin: oh, I eradicated the lucid-proposed dove kernel as well
<sconklin> pitti: thank you
<Daviey> Riddell: Hey!  Are you doing AA work at present? :)
<Riddell> Daviey: at some point today i
<Riddell> will
<Daviey> Riddell: great..  there is a libvirt, lucid sru - i'm interested in.  no hurry. :)
<Riddell> Daviey: bug no?
<Daviey> Riddell: bug #668042 , in lucid unapproved queue
<ubottu> Launchpad bug 668042 in libvirt (Ubuntu Lucid) "If Libvirtd is restarted, libvirt drops active domains lose network interface info." [Low,Fix committed] https://launchpad.net/bugs/668042
<doko> ScottK: do you requeue the arm builds? do you some the order to build?
<ScottK> doko: For qt/kde?  Yes.
<doko> ok, thanks
<ScottK> kde4libs should go in about 15 mnutes.
 * doko curses Riddell for pre-promoting packages without checking that they are built
<ScottK> doko: For reference, here's the KDE build order: https://wiki.kubuntu.org/Kubuntu/Ninjas/DependencyGraph
<pitti> sconklin: ah, bummer -- it seems the debdiffs generated at https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages?field.series_filter=maverick are against maverick final, not what's in -updates/-security
<sconklin> pitti: sorry. That's an easy mistake to make, and we're working on some tools to prevent that
<pitti> sconklin: ?
<sconklin> (among other common errors)
<pitti> sconklin: that's a Launchpad bug
<pitti> the Launchpad generated debdiffs in the Ubuntu unapproved queue are fine, but it seems the ones in PPAs don't do what we need
<sconklin> oh, sorry. We often forget to generate packages as a diff.
<pitti> sconklin: no, that's not what I mean
<sconklin> pitti: yeah, I get it now
<pitti> sconklin: I mean, for review I need a debdiff against the version that's currently in that release
<pitti> sconklin: well, at least I sufficiently fixed my tools to open all the bugs, get the .changes, etc.
<doko> ogra_ac: your `shadow' upload doesn't build
<RoAkSoAx> pitti: is there a change you could review bug #527195
<ubottu> Launchpad bug 527195 in pacemaker (Ubuntu) "[MIR] pacemaker" [Undecided,New] https://launchpad.net/bugs/527195
<pitti> RoAkSoAx: sorry, no; I'm not a MIR reviewer any more, and I'm in a meeting ATM
<RoAkSoAx> pitti: oh ok thanks! no worries then. sorry to bother :)
<doko> RoAkSoAx: mterry did start these reviews in the past
<mterry> doko, yeah, I'm looking at the cluster-glue one anyway
<RoAkSoAx> doko: yes he is doing cluster-glue :) IDK about pacemaker though.
<jdstrand> pitti, sconklin: just a thought, as an interim solution, it should be possible for the kernelteam to add a manually generated debdiff to the SRU master bug.... not ideal, but could work until LP is fixed
<pitti> that'd be awesome
<pitti> (and actually that's already part of the SRU policy..)
<pitti> bonus points if you can filterdiff -x '*/debian.master/*'
<pitti> and all the ABI diffs (which usually account for 90% of the size)
<jdstrand> sconklin: to generate a debdiff: debdiff <current kernel in -updates/-security>.dsc <-poposed kernel>.dsc
<jdstrand> sconklin: and then filter as pitti mentioned
<pitti> sconklin: alternatively, using git diff across all commits to that upload
<jdstrand> (should be scritable-- we do it on our team)
<cjwatson> https://help.launchpad.net/API
<cjwatson> oops
<pitti> if you diff against the previous tag, that should also be scriptable
<sconklin> in a meeting, but looks like a good idea
<mterry> doko, but actually, I wanted you to look at cluster-glue a bit.  There were some issues with libraries being bundled into one package.  That's fixed now, but then the question became to add .symbols or use makeshlibs -V.  How to best use -V with a source package that doesn't use cdbs/dh7 with lots of libraries in it?
<doko> mterry: hm, ok, will look at these, but it's end of day for me today, and tomorrow I did plan the python transition ...
<mterry> doko, OK.  I guess I didn't want you to look at it so much as advice regarding -V.  I'll ask another MIR person though.  See ya later
<mterry> asac, ^
<asac> mterry: does it use dh5?
<pitti> barry, doko: are we going to drop support for Python 2.6 from natty, or keep 2.6 and 2.7? the former would reclaim the 9.5 MB of extra CD space that 2.7 added
<mterry> asac, it uses dh at compat level 7, but not new-style dh.  Still lists all the dh_* items to run and such
<doko> pitti: can we discuss this at the sprint?
<pitti> doko: sure; I was just curious whether this was already planned, or still in the air
<pitti> doko: thanks
<cjwatson> .symbols means that packages depending on this one get fine-grained calculation of dependencies based on exactly which symbols they use.  -V just sets a fixed >= minimum.  you can use either - in many cases it isn't worth bothering maintaining symbols file.
<doko> pitti: stop shipping the compiler on the CD
<cjwatson> *files
<cjwatson> it doesn't make much difference what source helper is involved
<pitti> doko: which compiler?
<doko> gcc
 * doko is now afk
<pitti> ergh, this isn't even meant to be shipped
<cjwatson> yeah it is
<pitti> doko: right, thanks for pointing out
<cjwatson> there's a comment in the seeds about why, and everything
<cjwatson> Here we provide a minimal development environment sufficient to build kernel
<cjwatson> drivers, so that this is possible on the live CD and in scenarios where
<cjwatson> it is problematic to get these packages onto the installed system in order
<cjwatson> to compile a driver. -mdz
<james_w> pitti, hi, could I trouble you to take a look at https://code.launchpad.net/~james-w/launchpad-work-items-tracker/multi-project/+merge/42893 soonish? We need some solution for this to have useful charts for Linaro this cycle.
<doko> but how many people do this?
<cjwatson> it's certainly one of the things that is debatable.  I was merely saying that it wasn't as simple as being there by accident
<cjwatson> I have no idea how to get data
<pitti> ah, so indeed; I thought this accidentally slipped in as a dependency
<pitti> james_w: I got your mail; will look at it ASAP
<asac> mterry: it probably runs dh_makeshlibs ... you just use the -vVERSION there iirc
<pitti> so, the rallye will be a nice opportunity to have another one of these "what to kick off the CD" fights then
<james_w> pitti, thanks. Doesn't need to interrupt your work, but I promised a solution to this this week.
<asac> mterry: dh_makeshlibs -V'packagename (>= explicit.version)'
<mterry> asac, yar OK.  thanks
<RoAkSoAx> asac: but other packages don't have symbols file nor dh_makeshlibs -V'packagename (>= explicit.version)'
<RoAkSoAx> and they just have dh_makeshlibs -V
<cjwatson> dh_makeshlibs(1) documents what that does
<cjwatson> and why you might or might not want to use it
<cjwatson> the paragraph in question starts with "Beware of"
<kees> cdbs: hi! no, it doesn't create /etc/fetchmailrc and doesn't set START_DAEMON=yes.
<RoAkSoAx> indeed
<cdbs> kees: hmm? /me confirms
<cdbs> since it did that in mmy case
<kees> cdbs: hm, did you apt-get purge fetchmail before you started? I tested in a fresh chroot.
<cdbs> kees: well, my case is different. I installed on maverick and then upgraded to natty
<asac> RoAkSoAx: right. but those dont track the API explicitly which is not good
<cdbs> kees: ah, maybe a case that came up due to the upload. I can't see anything wrong with the code
<ScottK> cjwatson: In maverick I can do a fresh install on a broadcom wifi system and get working wireless with dkms, etc from the ISO.  If we gave up on that, I would consider it a significant regression for such systems (another reason for gcc).
<asac> e.g. indicates that the packager doesnt care about API/ABI imo
<cdbs> s/upload/update/
 * kees tries
<RoAkSoAx> asac: right, but something is for sure in cluster-glue and pacemaker, ABI changes (iirc verioning of the library) doesn't happen quite often
<cjwatson> ScottK: that's a good example, yes
<cjwatson> (until/unless broadcom fix their stuff ...)
<kees> cdbs: hm, nope. same thing for me still. installed maverick fetchmail in a fresh chroot, START_DAEMON=no, did an update to natty fetchmail, still set to =no.
<cdbs> kees: okay, I am closing bug, Thanks for testing!
<kees> you bet!
<cdbs> Don't know how it happened, I surely remember I never modified any file there
<asac> RoAkSoAx: right. but even there its more important to see that maintainer double checks to catch upstream mistakes etc.
<RoAkSoAx> asac: indeed, to tell you the thruth, at first they didn't even wanted to do the library split! So it's been an strugle to get this to happen in debian
<asac> RoAkSoAx: thanks so much for convincing debian on this!
 * mterry has to run out. bbl
<RoAkSoAx> asac: was not exactly convincing :) but they finally realized it was a blocker on Ubuntu after various attempts to get these packages into Main, and of course, varios rejections of patches from their side
<asac> hehe
<pitti> skaet_, sconklin: I made two followups to bug 683422; please let me know if you are ok with the current problems and want me to go ahead with the publication
<ubottu> Launchpad bug 683422 in linux (Ubuntu Maverick) "Maverick: 2.6.35-24.42 -proposed tracker" [Undecided,New] https://launchpad.net/bugs/683422
<sconklin> looking
<pitti> sconklin, jdstrand: FYI, I updated https://wiki.ubuntu.com/ArchiveAdministration#Copying%20PPA%20kernels%20to%20proposed%20(DRAFT) to show how to use queuediff (I just updated it to work with PPAs)
<sconklin> pitti: I thin that for this cycle we'll (meaning the kernel team people) just manually update the bug with the typo and keep you informed as needed, and I'll find out why armel didn't get built
<pitti> sconklin: ok, so we'll just try and see whether it gets a proper build record in -proposed now?
<jdstrand> ack
<pitti> erk, this new launchpadlib keyring is awkward
<pitti> sconklin-lunch: yup, building: https://launchpad.net/ubuntu/+source/linux/2.6.35-24.42/+build/2084938
<BlackZ> kenvandine: bug #685860: I'm not sure I understand your comment. I built the package with the "-v" option. That debdiff will not apply to the currently package in natty, rather you should apply that debdiff to the latest version of the package available in Debian unstable (it's a debdiff debian â ubuntu)
<ubottu> Launchpad bug 685860 in nfs-utils (Ubuntu) "Please merge nfs-utils 1:1.2.2-4 (main) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/685860
<kenvandine> BlackZ, i see
<kenvandine> i thought the debdiff was the diff to ubuntu
<BlackZ> kenvandine: no, it's not :)
<kenvandine> so i need to get the debian unstable version, and apply the debdiff :)
<kenvandine> sorry
<kenvandine> will do
<kenvandine> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Natty Alpha 1 released! | Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<hallyn_> zul: for daily builds, have you switch to natty as the release, or are you still using maverick?
<zul> im still using maverick i havent had a chance to switch to natty yet
<hallyn_> zul: which do you think is more useful?
<hallyn_> zul: i was thinking more ppl filing bugs fo whom i ask to use upstream would be on maverick...
<zul> maverick for now...
<hallyn_> kthx
<RoAkSoAx> mterry: btw.. you working on pacemaker as well? :)
<janimo> .join #ghc
 * janimo oopses
<tkamppeter> pitti, still there?
<kklimonda> jdstrand: do you remember why have you removed locales-all from the Build-Dep of python-django? The comment is "don't Build-Depends on locales-all, which doesn't exist in maverick" but the build-dependency is locales-all | language-pack-en-base which should work on both Debian and Ubuntu (the idea was to limit delta between debian and ubuntu to bare minimum, and to make package syncable)
<jdstrand> kklimonda: off-hand? no. but it is very likely that it didn't build with only the main component enabled
<kklimonda> hmm, weird - I'll have to test it once more.
<jdstrand> kklimonda: in other words, I don't change debian/control in a -security update unless I have to
<kklimonda> jdstrand: right, I understand
<jdstrand> kklimonda: and that is the only reason I can think of why I would do that
<jdstrand> kklimonda: cool
<hallyn_> where do debian syncs come from - sid?
<hallyn_> oh, hm.  ubuntu package is patched.  so then syncs don't apply, i recon'?
<RoAkSoAx> hallyn_: if there's an ubuntu delta, no auto-syncs will be performed for that package
<hallyn_> RoAkSoAx: yup, thanks :)
<ogra_ac> doko, yeah, i know, one patch needs some adjustments, i'll care for it first thing after my vacation
<mr_pouit> mmh, I think the archive admin who accepted the new binary packages libthunarx-2-0 and libthunarx-2-dev put them wrongly in mainâ¦ (thunar is in universe)
<hallyn_> james_w: cjwatson: pitti: do you know of anyone in particular interested in being the ubuntu maintainer of multipath-tools?
<james_w> nope
<hallyn_> ISTM the package is bit-rotting bc of ubuntu-specific changes which should be pushed back to debian
 * hallyn_ strokes his imaginary beard, pondering
<hallyn_> is there any particularly good place to talk about the ubuntu package?
<james_w> I don't know of a better one than ubuntu-devel@ or ubuntu-server@
<hallyn_> james_w: ok, thanks
<Roey> hi
<Roey> Hey all, using the latest KDE 4.6 beta PPAs here.  I have Capslock mapped to an additional control, keyboard layout switcher mapped to two shift keys pressed together, and repeat delay to 200ms.  I upgraded to the latest PPAs and now these settings no longer seem to be respected, even though they show up as I configured them in System Settings
<Roey> Has anyone else seen this?
<soren> :( ttf-mscorefonts-installer from maverick-updates just asked me to accept an EULA.
<ion> Whatâs the problem?
<soren> I would have expected that stuff from -updates didn't require prompting.
<soren> Unless it functionally changed stuff that I needed to be aware of. I have to expect that I've already accepted said license agreement.
<soren> Ah, the EULA is new since maverick's release.
<doko> barry: nipy fails on i386 only
<barry> doko: okay thanks. i'll do a build there
<xnox> barry, raphael hertzog recommeds to have debian/source/local-options to have unapply-patches
<xnox> that way the tree stays "reverted" after each debuild
<xnox> in-tree.
<xnox> unfortunatly local-options do not make their way into source package.
<xnox> they only stay in vcs
<Laney> soren: the eula is new, but there's nothing stopping you patching it out AFAICS (without changing the license, which I don't think has been done). :)
<doko> barry: and marked as a sphinx 1.0 failure
<barry> xnox: thanks, i'll have to digest that later ;)
<xnox> maybe our imports should generate debian/source/local-options on the checkout.
<barry> doko: yes, bug 685180, which i'm working on now
<ubottu> Launchpad bug 685180 in nipy (Ubuntu) "ftbfs with python2.7 / sphinx 1.0" [Undecided,In progress] https://launchpad.net/bugs/685180
<xnox> barry: lp:xiphos/debian for you to play around =) it is managed like I describe
<doko> barry: and binary-indep packages are only built on i386
<achiang> i've a question re: bzr-style development (cf. https://wiki.ubuntu.com/DesktopTeam/Bzr)
<achiang> the page doesn't really explain how to update a patch, say if the package uses quilt
<achiang> or if it does explain, it's too subtle and i'm not tall enough.
<achiang> can anyone clue me in?
<barry> doko: nipy built fine for me on natty-i386 chroot
<barry> i guess i'll try a ppa just to see if i can reproduce the failure
<doko> barry: in such cases, you can give back the build and see if it still exists
<barry> doko: i don't think i have permission to do that, but i will still try the ppa first
<doko> barry: https://launchpad.net/ubuntu/+source/nipy/0.1.2+20100526-2build1/+build/2076394
<doko> can you click on "Retry this build?"
<micahg> achiang: I would think you use quilt to update a patch
<barry> doko: no such button for me
<doko> ok, I'll do it
<barry> doko: thanks
<achiang> micahg: but if i say: bzr branch lp:~ubuntu-desktop/package/ubuntu ... all i get is the debian/ dir. i can issue a pbuild because there is a file named debian/watch that will download the .orig.tar.gz
<micahg> achiang: what does that have to do wtih anything?
<achiang> micahg: but the source isn't unpacked... i guess i could just manually unpack it, drop the debian dir in and see what happens?
<achiang> micahg: i must be really confused. how can quilt push possibly work if there isn't actual source code to patch? all you have is the debian/ dir...
<micahg> achiang: oh, sorry, you're referring to the -desktop branches, you should ask them
<achiang> micahg: oh, do they not hang out here?
<micahg> achiang: try #ubuntu-desktop
<achiang> micahg: thank you
<RAOF> achiang: âbzr bd-doâ should do what you're after.
<achiang> RAOF: wow! that's magic! thank you
<achiang> RAOF: shall i update the wiki?
<RAOF> Which wiki?
<achiang> https://wiki.ubuntu.com/DesktopTeam/Bzr
<RAOF> Yeah, that's probably a good idea.
<achiang> it has a long section about autotools, but you kinda have to read between the lines to figure out how to update a package with a patch system
<doko> barry: still FTBFS
<barry> doko: huh.  it definitely builds in my natty schroots.
<doko> buildds are not lying (according to lamont)
<lamont> barry: which package?
<achiang> RAOF: https://wiki.ubuntu.com/DesktopTeam/Bzr?action=diff&rev2=26&rev1=25
<barry> lamont: nipy
<barry> doko: i'm sure they're not.  but... what's different?
<RAOF> achiang: Looks pretty good to me.
<RAOF> You might possibly want to link to more information on bzr bd-do; possibly just a pointer to âbzr help bd-doâ.
<barry> well, the ppa is building so let's see what happens
<achiang> RAOF: thx.
<achiang> RAOF: oh hm. sure, I guess i can do that
<lamont> barry: the only difference between your natty chroot and the one on the buildd should be that you have a maverick kernel, and the buildd has a hardy kernel
<RAOF> achiang: That points out other interesting things, like the ability to run a command and the ability to cancel changes.
<achiang> RAOF: nod. adding a small little pointer now
<barry> lamont: hmm. i wouldn't expect that to be relevant in this case, but let's see how the ppa build goes
<lamont> ppa should be identical.
<barry> lamont: to...? :)
<lamont> archive builder
<lamont> that difference is only xen vs non-xen
<barry> and indeed it is.  ftbfs from the ppa just showed up in my inbox
<barry> well, at least i get a different build failure now
#ubuntu-devel 2010-12-08
<ebroder> Whooo python 2.7!
<Pici> woo
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
* Ssk` changed the topic of #ubuntu-devel to: We hate niggers! ABSOLUTELY NO NIGGERS ALLOWED!!!! FUN NIGGER FACTS: 1/3 adult nigger males will spend some time in prison. 70% of niglets are shit out out of wedlock. niggers have the LOWEST high school graduation rate. in spite of apefirmative action, niggers have the LOWEST college graduation rate. over 2,000,000,000,000 DOLLARS have been spent on nigger "poverty" since 1970
<IdleOne> thank you marienz
<hyperair> marienz: thanks.
<IdleOne> can you just delete that topic
* ChanServ changed the topic of #ubuntu-devel to: Natty Alpha 1 released! | Archive: Open | 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:
<marienz> does someone still have... ah, there we go
<IdleOne> thank you again
<tsimpson> thanks marienz
 * hyperair thinks someone deserves a ban though
<elky> hyperair, he'll move on to another channel now and earn a k-line
<marienz> the reset wasn't me :)
<hyperair> marienz: hmm who did it?
<IdleOne> question I have is why was the topic not locked
<micahg> thanks Pici
<elky> IdleOne, because numerous people here who are not ops need to change it
<hyperair> thanks Pici
<hyperair> what we need are topic acls!
<IdleOne> elky: then a bot should be set up and access given to the non-ops for topic change
<tsimpson> marienz: you may want to watch #kde too
<hyperair> so who's up to creating a topicbot
<micahg> Pici: maybe this channel should be +t?
<tsimpson> IdleOne: the channel was -t before the bot needed to change the topc
<IdleOne> tsimpson: in light of the new trend of looking for channels that are -t and setting racist topics I think it's time to revisit that policy
<tsimpson> IdleOne: there is no policy on channel modes
<wgrant> The number of inappropriate topic change incidents is tiny.
<IdleOne> ok. just trying to offer a sane solution
<Pici> Nevertheless, perhaps we should use +t and give the same flag to ubuntu/member/*
<hyperair> well then, if that's the case, shall we set it back to -t again until the next bot comes along?
<IdleOne> Pici: +1
<hyperair> Pici: yeah i think that's a good idea.
<micahg> Pici: +1 only ubuntu people should be changing the topic
<Pici> Let me bounce it off the rest of the IRCC just to make sure we're all in agreement first.
<ScottK> Pici: This isn't an IRCC controlled channel.
<ScottK> (yes, IRCC has ops, but it's my understanding that ubuntu-dev controls the policies for #ubuntu-devel)
<IdleOne> ScottK: not about who controls it, should be about security and IMHO -t is a security risk
<IdleOne> in any *buntu channel
 * ScottK is unclear on the relationship between a channel topic and security?
<ScottK> If there is a link, it would be safest if no one could set the topic.
<spm> well yes. everything is a security risk. as wgrant mentioned, the number of unauth changes is tiny. you're trying to spend $100,000 in securit ymeasures to proect something worth $1000. not worth it.
<Pici> ScottK: I didn't say we'd change it, but I think that the IRCC should be in agreement before we propose the idea to the tech board, or whomever claims control nowadays.
<wgrant> It takes about 30 seconds to fix the incidents that happen once every few months.
<hyperair> it's unnecessary annoyance
<ScottK> Yep.
<wgrant> It takes a lot longer than that to grant someone permissions if they need them.
<IdleOne> spm:  setting +t and leaving it is a one time thing. really isn't hard to do
<micahg> wgrant: it seems like requiring an ubuntu cloak for changes to topic is simple enough, no?
<hyperair> wgrant: how often does someone without an ubuntu member cloak need to set the topic?
<hyperair> wgrant: i've never changed the topic of any #ubuntu- channels even once.
<spm> every losa every month, sometimes more often.
<ScottK> micahg: We've already spent more effort on dealing with a tiny problem than it's worth.
<wgrant> Well, the LOSAs are canonical/*-cloaked, so they should probably be whitelisted too.
<micahg> ScottK: this is twice in 24 hours
<hyperair> well yes, so whitelist canonical and ubuntu cloaked people.
<spm> wgrant: I'm not
<ScottK> wgrant: I object to priviledges in an Ubuntu channel based on place of employment.
<wgrant> ScottK: True.
<wgrant> spm: Hm, I may indeed be mistaken.
<micahg> why do LOSAs need to change topic in ubuntu-devel?
<wgrant> LP downtime, among other things.
<ScottK> That's how they keep us informed (quite appreciated too)
<micahg> ah, ok
<hyperair> here's an idea, let's have a launchpad bot.
<wgrant> So, we've spent longer arguing about this than it has taken to resolve all of the inappropriate topic changes since the channel was started in 2004.
<micahg> wgrant: right, but as I pointed out this is the second time in 24 hours this has happened
<ScottK> Pici: I can't stop you and the IRCC from formulating a solution, but I would suggest there are more productive ways to spend your time.
<micahg> so, I guess we wait to see if it gets worse :)
<hyperair> i wonder how long it would take to give cloaked people access to the topic.
<IdleOne> I think part of the IRCC mandate is worrying about IRC namespace and its proper functioning.
<IdleOne> anyway, have a good night folks. +t is a good solution
<aroman> hey all, I'm working on a new app that is currently in alpha right now, but I could really use bugs/support in improving the app's experience. What is the best way to get people interested in this project? It's on launchpad with a PPA right now.
<ssj6akshat> aroman, name?
<aroman> ssj6akshat, It's called purple.
<hyperair> i wouldn't call it purple if i were you
<hyperair> it promotes confusion with libpurple, which is part of pidgin
<pitti> Good morning
<pitti> tkamppeter: hi
<pitti> hallyn_: I have no idea at all about multipath-tools, I'm afraid
<ebroder> udienz: There's no need to both submit a merge proposal and subscribe ~ubuntu-sponsors to a bug. Either one is sufficient
<ebroder> (Just FYI)
<didrocks> good morning
<tkamppeter> pitti, hi
<tkamppeter> pitti, it is about bug 680628, I have applied also the Cairo patch. Can you upload the new Cairo package? Thanks.
<ubottu> Launchpad bug 680628 in cairo (Ubuntu) "Unable to print a document with evince, works correctly with Adobe Acrobat Reader" [High,Fix committed] https://launchpad.net/bugs/680628
<pitti> tkamppeter: yes, can do
<pitti> tkamppeter: is there an upstream bug for the cairo patch? when sponsoing, I'd like to add a proper patch header
<tkamppeter> pitti, the Cairo patch is taken from the upstream VCS repo, so it is already upstream.
<pitti> tkamppeter: ah, thanks
<tkamppeter> pitti, the link is in the LP bug report.
<tkamppeter> pitti, another thing is CUPS and Samba, it still does not seem to work for everyone, see bug 494141 for example.
<ubottu> Launchpad bug 494141 in cups (Ubuntu) "CUPS starts after SAMBA; printers are not available (convert cups to upstart)" [Undecided,Fix released] https://launchpad.net/bugs/494141
<soren> Laney: I'm not so much concerned about the EULA itself. It's a multiverse package after all, so it's not entirely unexpected. It's just that packages from -updates generally shouldn't need to prompt the user unless there's a functional change that the user needs to be aware of.
<dholbach> good morning!
<didrocks> hey dholbach
<dholbach> hi didrocks
<didrocks> hey dholbach (not sure if you see my first message, as I was just disconnected :))
<dholbach> didrocks, j'ai seulement vu "hey dholbach" :)
<didrocks> dholbach: oh ok, the lag showing in my weechat before I just disconnected was false then :)
 * dholbach hugs didrocks :)
 * didrocks hugs dholbach back
<soren> pitti: I have a server written in Python. When something inside it throws exceptions, they're caught and logged and then it moves on with its life. I'd like to use apport to report bugs about these exceptions. Are there other projects doing something like that that I can learn from?
<pitti> soren: not off the top of my head, but it's not too difficult
<pitti> soren: you have to set sys.excepthook to your own crash handler, and inside that, you can import apport_python_hook and call apport_excepthook() with the exception
<ebroder> pitti: I don't think you can recover if you make it to sys.excepthook
<pitti> well, you can call it from any exception handler
<pitti> but I thought the point of this was to have a fallback for uncaught exceptions
<pitti> if you are there, you can at least go back to a defined state
<soren> pitti: Cool, thanks. I'll see how that works out.
<ebroder> soren: I think you could just call apport_python_hook.apport_excepthook(sys.exc_type, sys.exc_value, sys.exc_traceback) from any exception handling block
<pitti> soren: note that apport_excepthook() calls sys.__excepthook__ in the end (to have the default handler), so you need to take care not to end up in an endless recursion
<soren> Hm... Ok.
<brendand> Hi
<brendand> I have a question about update-manager
<brendand> Trying to write a test which triggers an update
<brendand> but the initial update that happens at the start is getting in the way
<brendand> i'm trying to add an options which disables this
<brendand> option
<brendand> is there any straightforward way to do this, first of all?
<brendand> otherwise I have some more specific questions
<mvo> brendand: you can disable the daily update by modifying /etc/apt/apt.conf.d/10periodic
<brendand> thanks
<brendand> let me see if that does the trick
<mvo> brendand: what kind of test is this (out of curisoty) automatic or manual?
<brendand> automatic
<brendand> basically
<brendand> start update-manager
<brendand> connect to d-bus
<brendand> call (new) update() method
<brendand> check return code
<brendand> fail if return code is wrong or can't connect to dbus
<mvo> nice, is that part of a broader testing approach?
<brendand> the problem is i need to introduce a delay because it always does an initial update
<brendand> it's part of SRU testing
<brendand> to check that if an SRU borks your machine at least update-manager works to recover it
<brendand> having arbitrary delays in test scripts is not my idea of maintainability
<brendand> i already have one to 'make sure' that update-manager started enough to expose the dbus interface
<brendand> don't want another if i can avoid it
<mvo> brendand: sure, that is reasonable. let me know if I can help in any way, this sounds like a great project
<janimo> what exactly does the suffix nobinonly stand for in mozilla package version names?
<soren> pitti: Is there any way I can use apport to report bugs about packages in a PPA? Right now it complains it's not an Ubuntu package.
<pitti> soren: yes, you can, ubuntuone-client does that; /usr/share/doc/apport/crashdb-conf.txt and /usr/share/doc/apport/package-hooks.txt.gz have the details
<soren> pitti: ta
<pitti> soren: /etc/apport/crashdb.conf.d/ubuntuone-client-crashdb.conf defines an "upstream project" crash database
<pitti> soren: and /usr/share/apport/package-hooks/source_ubuntuone-client.py shows how to use it
<pitti>     if not apport.packaging.is_distro_package(report['Package'].split()[0]):
<pitti>         report['CrashDB'] = 'ubuntuone'
<pitti> soren: that means "if this isn't a native package, then use the upstream crash DB"
<soren> And that just makes it report it against ubuntuone rather than ubuntu/ubuntone?
<pitti> soren: (you can also set it unconditionally if you always want to report against the upstream project, or set any other condition)
<soren> Or is crash DB an actual thing I need to set up?
<soren> Coolness.
<pitti> soren: no, the "ubuntone" is the name of the crashdb that is defined in /etc/apport/crashdb.conf.d/ubuntuone-client-crashdb.conf
<soren> Ah, right. I see it now.
<soren> Thanks, I'll look into that.
 * pitti smells tight OpenStack apport integration :)
<soren> :)
<soren> Does dh-apport deal with crashdb.conf?
<pitti> I don't think it does
<soren> ok.
<pitti> just debian/package.apport
<soren> np
<pitti> soren: patches accepted :)
<soren> pitti: Thanks a lot!
<pitti> soren: (I don't use dh_apport myself, I'm not that familiar with it)
 * soren shakes his fist at launchpad for being read-only right now
<pitti> ogra_ac: is there an ogra_battery as well?
<ogra_ac> pitti, lol
<ogra_ac> i'm just redoing my home network during my vacation, an IRC proxy is part of the plan
 * ogra_ac hugs mvo for enabling a flawless gutsy->hardy->lucid upgrade of my firewall
<mvo> ha! thanks ogra_ac, nice to hear
<ogra_ac> finally i can use ufw :)
<janimo> micahg: hello, what does nobinonly mean in the mozilla package version strings?
<janimo> ChrisCoulson: hello. Is it possible to use xulrunner in firefox and thunderbird builds? I know this comes up from time to time but I can't find a recent writeup of why this is not done
<janimo> chrisccoulson: planned to be done on tbird or stopped by upstream issues?
<chrisccoulson> janimo, oh, sorry, i didn't see your message here
<janimo> chrisccoulson: my fault, I asked in private first by mistake
<chrisccoulson> that's ok
<chrisccoulson> OOI, why do you ask?
<janimo> ARM FTBFS fix needs to be done in both xulrunner and tbird
<janimo> it is the same xpcom code
<chrisccoulson> ah, ok. yeah, that's a bit of a pain
<janimo> but I guess it is a common maintenance problem with the duplication
<chrisccoulson> which xulrunner version isn't building? if it's 1.9.2, don't invest any time fixing that
<chrisccoulson> we'll drop that from the archive before release
<janimo> yes, it is that one
<janimo> ok
<janimo> chrisccoulson: what does nobinonly mean in the mozilla package names? I did not see that in other contexts
<chrisccoulson> it means we've stripped out some binary files from the source tarball
<janimo> thanks
<phlax> hi can anyone tell me what the right way to overwrite an upstart .conf script is? If I use "alternatives" it seems the job is not recognised as the script is a symlink
<pitti> sconklin: I published lucid/karmic kernels as well now; is there an update how to publish the pure security hardy/dapper updates?
<pitti> sconklin: btw, the hardy kernel was misbuilt -- ERROR   linux 2.6.24-28.82 in hardy (linux_2.6.24.orig.tar.gz already exists in destination archive with different contents.)
<Keybuk> jhunt: so, I've had an epic idea of epic epicness
<jhunt> Keybuk: I'm all ears... err eyes!
<Keybuk> it should help with the visualization part of the spec quite a bit
<Keybuk> but it also helps massively with the event bridges
<jhunt> gr8
<jhunt> intrigued!
<Keybuk> simply the idea is to export the start_on and stop_on trees as properties
<Keybuk> using reverse polish notation, they'd be an array of variants, that would basically end up looking something like
<Keybuk> start on = [ "AND", ["started", "dbus"], ["started", "apache"]]
<jhunt> I like.
<jhunt> :)
<Keybuk> so for viz, you can just pull that array, and quickly see everything the job "depends" on
<Keybuk> now, for bridges, this makes a big win too
<Keybuk> bridge starts, walks the jobs and gets their start_on propeties
<soren> That's not RPN.
<soren> RRPN, perhaps :)
<Keybuk> err, sorry, Polish
<Keybuk> though RPN is what I mean to do, since that's easier to push back out to a tree
<Keybuk> annnywayy
<Keybuk> so let's say you wanted to do an inotify bridge
<Keybuk> you need to know what filenames to look for, right?
 * soren apologises for the interruption :)
<Keybuk> but they're all tied up in the job configs
<Keybuk> e.g. start on file-created /foo/bar
<Keybuk> now the bridge just needs to make a D-Bus call to fetch all the stat_on properties
<Keybuk> and it can trivially extract the events it's going to generate and know what files to listen for
<ion> Nice
<jhunt> +1!
<Keybuk> so this does most of the "event match" stuff from 0.10, but in 0.6 :p
<apw> cjwatson, could you remind me which bit of the installer does the 'if we have too little ram enable ram swap support'
<mdz> cjwatson, pitti, the brainstorm review deadline is today, and I have all of them except amitk's
<mdz> I haven't been able to track him down
<mdz> kiko is trying to help put something together, but it would be great if you could help
<kirkland> @pilot in
<ScottK> doko: No need to worry about boost1.40 for the Python transition.  We should be ready to remove it be the end of the week.
<pitti> mdz: what was his question?
<mdz> pitti: power management in Linux :-/
<mdz> a complex one
<kirkland> dholbach: hmm, i did "@pilot in" but nothing happened
<kirkland> dholbach: topic still the same
<mterry> kirkland, odd, worked yesterday
<kirkland> @pilot in
<kirkland> mterry: ^
 * mterry shrugs
<pitti> !hello | pitti
<pitti> at least ubottu seems to be alive
<pitti> (got a /msg)
<pitti> !pilot | pitti
<pitti> !ask | pitti
<ubottu> pitti, please see my private message
<Keybuk> jhunt: https://wiki.ubuntu.com/FoundationsTeam/Specs/MaverickFinishUpstart?action=diff&rev2=8&rev1=7
<Keybuk> jhunt: I've added the "manual" stanza as an explicit extra work item to the spec because it deserves a unique definition outside of the disabling of jobs
<Pici> kirkland: try again
<Keybuk> jhunt: and I've added the start_on/stop_on bits as a dep of the visualization bits
<Keybuk> do you want to check over what I've put to make sure it's right?
<pitti> chrisccoulson: you said the other day that we want to drop xulrunner somehow?
<pitti> chrisccoulson: I just tried to build OO.o in current natty, and it dies with
<pitti> Please recompile Libxul with --enable-ldap or use --with-openldap.
<pitti> chrisccoulson: do you know anything about that? was that changed recently?
<chrisccoulson> hmmmm :/
<chrisccoulson> i thought openoffice was just using the npapi headers
<chrisccoulson> that sounds suspicious
<chrisccoulson> do you know what openoffice is doing with it? i downloaded the source the othe day, but decided it would be too painful to even unpack it ;)
<pitti> chrisccoulson: http://paste.ubuntu.com/541008/
<pitti> chrisccoulson: not really, I'm afraid; it already took me over an hour to even get that far :)
<kirkland> !pilot | kirkland
<kirkland> !pilot
<doko> chrisccoulson: openoffice.org-officebean, should be possible to disabled that
<kirkland> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Natty Alpha 1 released! | Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: kirkland
<kirkland> Pici: thanks, that worked
<chrisccoulson> pitti - hmmm, i'm not sure how that ever worked then. --enable-ldap is tbird-specific, and firefox has no ldap code in it :/
<pitti> doko, chrisccoulson: ok, I'll try --disable-ldap
<chrisccoulson> thanks
<chrisccoulson> if it needs ldap, then it needs to use thunderbird-dev instead
<chrisccoulson> but that doesn't even have any pkg-config files, so it might be difficult to use that
<ScottK> doko: Any idea about http://launchpadlibrarian.net/60320546/buildlog_ubuntu-natty-i386.python-dns_2.3.4-4build2_FAILEDTOBUILD.txt.gz
<jhunt> Keybuk: thanks! looks good to me.
<Keybuk> ok, coo
<Keybuk> will add my other bits next then
<chrisccoulson> pitti - oh, i really don't envy you today :)
<chrisccoulson> i just unpacked OOo
<chrisccoulson> ;)
<pitti> chrisccoulson: if you want to build it, pull from lp:~pitti/openoffice/3.2.1-natty to get around the first few stumbling blocks
<doko> ScottK: no, builds locally
<ScottK> OK.
<sconklin> pitti: thanks for publishing those, we'll take a look at Hardy. We're currently in discussion about how the pure security kernels will be handled - they'll get the same testing that security kernels in the past have gotten. It's not well documented, and we'll fix that. I'll keep you informed. In the past, the security team has published those.
<chrisccoulson> pitti - are you sure you're not just missing a build-depends btw?
<pitti> chrisccoulson: none that debian/control demands
<chrisccoulson> "checking which LDAP SDK to use... Netscape/Mozilla" versus "checking which LDAP SDK to use... OpenLDAP" on the last build
<pitti> chrisccoulson: I might have additional b-deps installed, of course
<pitti> chrisccoulson: right, indeed
<chrisccoulson> so, it just looks like it picks the wrong one, but i've got no idea how it works that out ;)
<ScottK> doko: That package built on Debian Experimental with the most recent dh_python2 changes, so I'm really in doubt about where to look.
<doko> pitti: http://launchpadlibrarian.net/60320147/buildlog_ubuntu-natty-i386.python-hildon_0.8.8-1ubuntu8_FAILEDTOBUILD.txt.gz
<doko> which -dev package should have the dependency on libgdk-pixbuf2.0-dev ?
<pitti> hildon? I think we should just remove that
<pitti> nobody touched or cared about the hildon stack for ages
<seb128> kklimonda was asking about that to mvo before
<pitti> unless our mobile team still is intersted in it
<seb128> I think they agree on dropping the only rdepends
<seb128> which was udpate-manager-hildon
<kklimonda> doko: it wont build, even after you add /usr/include/gdk-pixbuf-2.0 to setup.py, I've already tried and failed :)
<kklimonda> yes
<pitti> StevenK, lool, persia: ^ should we just remove the hildon bits?
<kklimonda> I have reported bug 687353 and will subscribe archive admins when udpate-manager-hildon is gone
<ubottu> Launchpad bug 687353 in python-hildon (Ubuntu) "remove python-hildon from archive" [Wishlist,Incomplete] https://launchpad.net/bugs/687353
<doko> kklimonda: thanks!
<kklimonda> I've written some more rationale there
<pitti> doko, chrisccoulson: ah, apparently my local --disable-ldap workaround at least got me to actually compiling bits \o/
<pitti> (I won't upload it like that; seems I just have some additional package installed which made it want to use the wrong backend)
<Keybuk> jhunt: the only thing I'm not sure about is the config name for the override files ;-)
<Keybuk> I vaguely like the idea of naming them /etc/default/*.conf ;-)
<Keybuk> ie. for /etc/init/apache.conf you could create /etc/default/apache.conf
<Keybuk> or perhaps better, /etc/override/apache.conf
<jhunt> Keybuk: or maybe even /etc/init/override/apache.conf?
<Keybuk> the only problem with that latter is that an existing path of that name is already supported
<Keybuk> it'd create a job called "override/apache.conf"
<ion> /etc/init/apache.conf.override
<jhunt> Keybuk, ion: yes - I had just assumed ".override": by having a different extension we might avoid confusion as it is very clear they are not (standard) .conf files purely from the name.
<Keybuk> we appeared to have hit the second unsolved problem of computing
<Keybuk> jhunt: yeah, I think that's probably best
<Keybuk> and they are alphabetically greater than ".conf"
<Keybuk> so they appear afterwards
<Keybuk> ok, let's just go with that
<Keybuk> I'm persuaded by the alphabeticalness
<Keybuk> apache.conf
<Keybuk> apache.override
<Keybuk> dbus.conf
<Keybuk> squid.conf
<Keybuk> it looks ok
<ion> aye
<jhunt> cute. I guess if, when updating a package that supports upstart we detect that the .conf file on disk is different to the new .conf file in the package we're updating, assuming no existing .override, we could rename the .conf to .override to get the best of both worlds: keep the (new) .conf file, but retain the admins current behaviour? Or would that just be too crazy/weird?
 * jhunt takes deep breath to recover.
<mvo> I will kill update-manager-hildon with the next upload
<Keybuk> a bit weird I think :p
<ogra_ac> mvo, but how will i upgrade my ubuntu wrist watch then ?
<doko> kklimonda: http://launchpadlibrarian.net/60320774/buildlog_ubuntu-natty-i386.python-visual_1%3A5.12-1.1build2_FAILEDTOBUILD.txt.gz
<doko> in atkmm1.6 you didn't package the .la file. by intent?
<tumbleweed> ScottK: re python-dns, the problem is that it doesn't BD on python-all (like dh_python2 packages should), and we have python2.6-minimal in our chroots
<kklimonda> doko: once bug 662572 is fixed (there is a branch waiting for a sponsor) it can be rebuild
<ubottu> Launchpad bug 662572 in gtkglextmm (Ubuntu) "gtkglextmm libtool archives broken" [Medium,Triaged] https://launchpad.net/bugs/662572
<kklimonda> doko: yes, missing .la file is by design, we just have to rebuild gtkglextmm so it doesn't use it
<doko> kklimonda: could you do that?
<kklimonda> doko: I don't have upload rights yet :)
<kklimonda> the branch is linked in the bug
<kklimonda> and python-visual doesn't have to be changed in any way - it just have to be rebuild once new gtkglextmm is ready
<ScottK> tumbleweed: Thanks.
<doko> Riddell: thanks so much for your kdebindigs upload :-(
<kklimonda> doko: you remind me of http://dilbert.com/2010-12-06/ ;)
<doko> heh ...
<doko> kklimonda: could you prepare a debdiff?
<kklimonda> doko: sure
<kklimonda> doko: attached to the bug
<cdbs> doko, barry: Anyone of you working on bug #685177 ? I have a patch, can I go ahead and upload it?
<ubottu> Launchpad bug 685177 in psyco (Ubuntu Natty) "ftbfs with python2.7" [High,Confirmed] https://launchpad.net/bugs/685177
<barry> cdbs: i haven't gotten to it yet.  please upload a patch.  i'll review and test, but i cannot upload
<barry> cdbs: thanks!
<cdbs> barry: okay, I meant to say I can upload directly
<barry> cdbs: ah cool.  if you're confident about the fix, jfdi :)
<cdbs> barry: Testing via a test build, though it should work
<doko> cdbs: yes, please go ahead
<barry> cdbs: is it a patch upstream should be interested in?
<xperia> hello to all. i am trying to build "swftools" on ubuntu but i get allways this error message here.
<cdbs> barry: will forward
<xperia> *** No rule to make target `xpdf-*tar.gz', needed by `xpdf/Gfx.cc'. Stop.
<xperia> http://paste-bin.com/view/94604b8a
<xperia> looks like maybe i a missing here some dev lib. can anybody help me resolving this problem.
<cdbs> barry: yes, its a must-needed change
<barry> cdbs: cool, thanks
<Keybuk> jhunt: added the other bits now, have a read through
<jhunt> Keybuk: thx, will do.
<Keybuk> cjwatson just needs to add the plymouth stuff :p
<micahg> janimo: it means that the binary components are removed
<janimo> micahg: thanks, chris has answered that a while ago too :)
<janimo> micahg: do you prefer getting patches for tb or shall I make an upload if I have changes?
<janimo> there's an ARM FTBFS I am fixing
<micahg> janimo: patches please
<janimo> also I think libhal may not be needed as a dep
<ScottK> pitti: Would you please rescore kde4libs.  I'd like to get it started on the slow archs asap to minimize failures due to archive skew.
<janimo> micahg: simple diff or debdiff with changelog?
<micahg> janimo: debdiff with changelog, or merge proposal into lp:thunderbird if you like
<janimo> micahg: ok, thanks
<didrocks> barry: hey
<pitti> ScottK: done
<didrocks> barry: I have an issue with dh_python/dh7 not taking care of what's needed when you have some python + autotools
<ScottK> pitti: Thanks.
<barry> didrocks: hi
<didrocks> barry: I workarounded it badly and was looking for you to get a proper fix :)
<ScottK> didrocks: Did you look at the new update that just hit today.
<ScottK> There's some new capabilities in dh_python2 now.
<didrocks> ScottK: oh really? No I didn't
<barry> didrocks: what package?  but yeah, as ScottK says, the new dh_python2 could improve things
<ScottK> didrocks: Now if you get your file into /pyshared, dh_python2 will automatically do the symlinking.
<ScottK> That should simplify things.
<didrocks> barry: it was compizconfig-python, branch is at lp:~compiz/compizconfig-python/ubuntu/
<didrocks> I have already talked with ScottK about the override I had to do in debian/rules
<didrocks> ScottK: hum, it's not related to the symlink in fact
<ScottK> OK.
<didrocks> but that's nice :)
<ScottK> It was long enough ago I forgot what it was
<didrocks> ScottK: so no more trigger for the symlinking? it was already doing that, isn't it?
<didrocks> (as a postinst IIRC)
<ScottK> No, it makes the symlinks at build time.
<ScottK> postinst just does pycompile
<barry> right, which is it's huge advantage
<didrocks> oh, symlinks at build time now, nice! Did you check it didn't break my --prefix patches btw? :)
<doko> --prefix patches?
<ScottK> pitti: It still says kde4libs is build score is 2505.  Doesn't look rescored?
<pitti> ScottK: oh, seems ubuntu-build didn't pick the latest version
<didrocks> doko: yeah, for installing with python-support using cdbs in other path, like the /opt/extras.ubuntu.com/â¦
<ScottK> pitti: I guess because the source isn't published yet?
<doko> ScottK: rescored
<ScottK> doko: Thanks.
<didrocks> barry: so, I think my issue is still valid, I have to do that to avoid dh_auto_install to become confuse: http://bazaar.launchpad.net/~compiz/compizconfig-python/ubuntu/annotate/head:/debian/rules
<barry> didrocks: sorry, i don't understand why you have to make this override?
<pitti> ScottK: done now
<ScottK> Thanks.
<didrocks> barry: without it: http://paste.ubuntu.com/541058/
<doko> is there even one kde package which does *not* fail to build?
<barry> didrocks: huh.  weird
<ScottK> doko: It's because they were all uploaded at once.  once kde4libs is built we'll retry them in order and they should be fine.
<barry> didrocks: my stack is a bit deep at the moment, but if you want me to look at it, please make sure there's a bug open with a `python27` tag
<didrocks> barry: ok, doing it right now, thanks :)
<didrocks> barry: subscribing you as well?
<barry> didrocks: yep, though i'll see it either way :)
<didrocks> barry: ok ;)
<doko> didrocks: what is the complete setup call?
<barry> so, i guess my nipy local build is failing because, even though i'm using natty-i386, the host is still amd64, so the chroot is not a true i386 architecture?
<barry> er, my nipy local build is *succeeding* where it fails on the buildds
<doko> barry: do you use schroot?
<barry> doko: yes
<didrocks> doko: seems it tries to make install (it calls make -j1 install DESTDIR=/home/didrocks/work/compiz/compiz-config-python/build-area/compizconfig-python-0.9.2.1/debian/python-compizconfig)
<doko> barry: add personality = linux32 to the config
<doko> didrocks: and then?
<barry> doko: it's got that already
<didrocks> doko: well, the rest is the trace you got: http://paste.ubuntu.com/541064/
<doko> didrocks: what is the call for the error message from line 8?
<barry> but something is very strange because i can see it installing the i386 packages, even though the build log claims it's an amd64 build: nipy 0.1.2+20100526-2build1 (amd64)
<BlackZ> kirkland: bug #685860: I'm not sure how kenvandine applied my debdiff but it has not any conflict (please review the attached debdiff instead)
<ubottu> Launchpad bug 685860 in nfs-utils (Ubuntu) "Please merge nfs-utils 1:1.2.2-4 (main) from debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/685860
<didrocks> doko: you want me add some debug in setup.py? like print sys.args?
<barry> maybe i need to blow away that chroot and rebuild it...
<kenvandine> BlackZ, conflict?  i applied it to the bzr branch
<BlackZ> kenvandine: as I said you yesterday it should be applied to the latest package available in Debian unstable
<doko> kenvandine: any news about bug #684949?
<ubottu> Launchpad bug 684949 in libindicate (Ubuntu Natty) "FTBFS in natty (gir version conflict)" [High,Confirmed] https://launchpad.net/bugs/684949
<doko> didrocks: no I would like to see the call itself (python setup.py --install ....)
<janimo> stgraber: hello, mind if I take your build lightspark for armel WI ?
<kenvandine> doko, i have it fixed in bzr, but it is blocked on a new dbusmenu
<kenvandine> BlackZ, that is what i did, i just pushed the result to the source package branch
<didrocks> doko: is there a way with dh7 to get you that?
<BlackZ> kenvandine: well, I can cleanly apply the debdiff without any conflict to the Debian package
<doko> pitti: ^^^ dh7
<kenvandine> BlackZ, yeah, it applied cleanly for me too
<kenvandine> and i pushed the result to bzr
<BlackZ> kenvandine: I rarely use bzr to merge packages :)
<kenvandine> built it in pbuilder and everything looked good
<doko> kenvandine: who can I poke about dbusmenu?
<kenvandine> me :)
<kenvandine> doko, i am blocked on tedg though
<kenvandine> but he is working on it as fast as he can
<doko> kenvandine: desktop installability is now blocked on you ;)
<kenvandine> doko, indeed :)
<kenvandine> fun times
<kenvandine> i like how tedg drops off after i mention him
<janimo> micahg: any plans to change tbird packaging format to (quilt 3.0) sometime?
 * barry -> lunch
<BlackZ> kenvandine: do you mind if I remove the proposed bzr branch link from the bug report and ask the sponsors to review the debdiff, instead?
<kenvandine> BlackZ, i guess
<kenvandine> BlackZ, is there something wrong with it?
<BlackZ> kenvandine: like I said up, I rarely use bzr to merge packages; I usually attach a debdiff (ubuntu -> debian) containing the merge, instead
<kenvandine> sure, ok
<kenvandine> either way works
<kenvandine> i reviewed it and it looked good to me, just would rather someone more familiar with nfs actually upload it
<BlackZ> kenvandine: yes, I see. Thanks a lot for your work, though :)
<kklimonda> doko: gtkglextmm on powerpc has failed because gtkmm 2.22.0 still waits on atkmm1.6 to build - just saying so you don't waste time investigating it :)
<GrueMaster> pitti: Ping - When will linux-image-2.6.35-903.19-omap4 be moved from proposed to maverick-updates & natty?  I did the testing for it 2 weeks ago now.
<GrueMaster> Bug 673504
<ubottu> Launchpad bug 673504 in linux-ti-omap4 (Ubuntu) "Pandaboard chooses a new IP address on each boot" [High,Triaged] https://launchpad.net/bugs/673504
<CarlFK> barry: does this look like a python 2.7 issue: /usr/lib/python2.6/dist-packages/GnomeCodecInstall/PackageWorker.py line 16: from aptdaemon.defer import inline_callbacks - there currently is no aptdaemon.defer in Natty.
<pitti> GrueMaster: sorry, sconklin asked me to remove the remaining flavours in -proposed yesterday, as we are in a new round
<CarlFK> issue = https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032224.html  " Some parts of the archive will be uninstallable or not upgradeable for a few days; please wait with upgrades until the rebuilds are done, and for the next two days, also avoid bug reports about upgrade problems. "
<GrueMaster> Does this mean I have to retest yet again?  Come on.
<pitti> GrueMaster: no, we don't; but the kernel team needs to reupload it
 * GrueMaster is getting seriously frustrated with the inefficiency of the kernel sru processes.
<GrueMaster> If this were an isolated incedent, we'd fix and move on.  This has happened to me now for going on 4 cycles.
<SpamapS> Keybuk: + [scott] socket activation: TODO  .. .DONE yet? ;)
<Keybuk> actually yes
<Keybuk> it's been done for months, I just couldn't persuade the author to sign copyright assignment
<GrueMaster> pitti: sconklin:  Could you guys figure out why the current process is broken?  I really don't like having to retest patches that should have been released (even if you say this one won't need retesting - inevitably it will).
<smoser> smb, are you around ?
<seb128> cjwatson, should libcanberra be in the desktop set?
<SpamapS> Is there any way to get apt-cache rdepends to only show you Depends: and not Recommends: ?
<seb128> SpamapS, --show-recommend=no?
<ebroder> SpamapS: aptitude search ~D^my-package$ ? :)
<seb128> SpamapS, --show--recommends
<seb128> rather
<doko> seb128: he's sick today
<seb128> doko, ok thanks
 * SpamapS should have rtfm'd .. oops ;)
<SpamapS> thanks guys
<seb128> cjwatson, same question for gobject-introspection
<seb128> cjwatson, (just letting in the backlog, no hurry)
<barry> sbuild is really confusing me.  i'm not sure if i've set something up wrong or this is the normal way it should work.  i rebuilt my natty i386 chroot it definitely has personality=linux32.  when it updates it pulls the i386 packages, but when it builds it claims the architecture is amd64.  why is that?
<Keybuk> barry: dpkg doesn't check that kind of thing
<Keybuk> it uses either dpkg --print-architecture
<Keybuk> or gcc -dumpmachine
<Keybuk> so if you have an amd64 chroot, you always get amd64 out, no matter what personality
<barry> Keybuk: dpkg --p-a says i386; gcc -dumpmachine says i686-linux-gnu
<Keybuk> oh, then no idea what sbuild is doing ;)
<doko> barry: do you start sbuild with linux32?
<ebroder> barry: What's uname -m?
<Keybuk> dpkg will certainly build i386 things
<ebroder> doko: You shouldn't have to if you set the personality right in the sbuild config file
<barry> ebroder: uname -m says i686
<ebroder> barry: Fascinating
<barry> doko: [natty-i386] definitely has personality=linux32
<barry> yes, if "fascinating" means damn perplexing ;)  let me try forcing sbuild -arch=i386
<barry> well, that does make the sbuild log claim it's i386.  so maybe it's just ignoring the personality=linux32 in the conf file
<barry> i suppose it could be a bug in sbuild
 * barry files a bug
<ebroder> barry: Were you using the -c argument to sbuild?
<barry> ebroder: yep
<ebroder> barry: Don't do that :-P. You want -d natty --arch i386
<ebroder> And let sbuild figure out which chroot to use
<barry> ebroder: okay!  thanks, that does seem to work.  command line options could be better (esp. with schroot -c ;)
<ebroder> barry: Yeah, I don't know where I learned to use -d, but it wasn't from the manpage
<barry> ebroder: yeah ;)
<Keybuk> I know this is hyretical within Ubuntu
<Keybuk> but I really prefer the GiT-style of branch submission where you clean up the branch first
<Keybuk> and submit it in the form of nice atomic patches
<Keybuk> rather than "here's a mess of commit logs"
<ebroder> Keybuk: Agreed. Somebody should write bzr rebase -i
 * apw prefers to think of that as 'every commit is sacred/history should be understandable' rather than bzr/git issue
<ebroder> apw: Sure, except that bzr doesn't seem to have the tools to let me choose my philosophy
<Keybuk> apw: I think the problem is that I can't see any benefit to history reflecting development process
<Keybuk> six months later, it doesn't *matter* that you had three abortive attempts to get the patch to work, and eight paper bag commits to fix typos, missing ;s, build errors, etc.
<apw> Keybuk, indeed i can't say i can see any point to thinking of all of history as sacred at all, but i am also not allowed to commit things which don't build ... so i have to think that way
<Keybuk> hmm
<Keybuk> I hate test suite failures
<Keybuk> oh, I remember this one
<Keybuk> this is a D-Bus regresson
<Keybuk> doko: you realise the test you commented out was an actual BAD FAILURE right?
<Keybuk> ie. rather than fix a bug that can cause kernel panics, you simply commented out the test case?
<Keybuk> Missing The Point Of Test Suites
<RoAkSoAx> mterry: howdy!! Ok, so talked to upstream and he said that only the libs are intended to be LGPL. So I'm presumming that some of the headers that say 2.1 should also be changed to 2
<Keybuk> oh
<Keybuk> guess who changed this code
<Keybuk> fortunately the person who didn't bother to actually test their change didn't write an init daemon or something
<mterry> RoAkSoAx, OK, so sounds like some bits need the 2.1 to be changed to 2 and some bits need the word Lesser inserted?  Those seem like important details to clear up
<RoAkSoAx> mterry: yes! I'm currently waiting for upstream's response on how to move forward with this
<doko> ScottK: I assume you will take care of obmenu yourself (control file still mentions 2.6)
<RoAkSoAx> mterry: alright, figured it out. Upstream will review my patch
<mterry> RoAkSoAx, nice
<RoAkSoAx> mterry: will let you know when it's applied in Ubuntu ;)
<mterry> k
<ScottK> doko: Then it's unlikely to get fixed.
<doko> ?
<ScottK> doko: I'm not sure why you assume I'll do anything with it.
<doko> ScottK: well, you're the maintainer?
<ScottK> No.
<doko> ahh, ok
<ScottK> I fixed it for the 2.6 transition, but that was a LONG time ago.
<ScottK> Currently my time for Python stuff is very limited.  My Ubuntu time is focused on trying to figure out how to get stable symbols for C++ packages with gcc4.5.  Unfortunately the only advice I got from the gcc maintainer was a pointer to a man page, so it's likely to be awhile before I get that sorted (if at all).
<seb128> kirkland, hey
<kirkland> seb128: howdy
<kirkland> seb128: just about to step out to a meeting, what's up?
<seb128> kirkland, I just wanted to comment on this indicator sponsoring you did
<seb128> that's something that should be discussed with design
<kirkland> seb128: oh?  hmm...
<seb128> we don't usually change the default because one user disagrees with what has been selected for Ubuntu
<seb128> I've asked ted to get some design input on this bug
<kirkland> seb128: sorry, seemed like a sensible change;  shall i revert it, or would you like to?
<seb128> but just for next time, you might want try to check with people working on the project, especially for canoncial projects
<kirkland> seb128: okay, no problem
<seb128> kirkland, let's say what dx people say
<ScottK> Why especially for Canonical projects?
<kirkland> seb128: what should I do with that upload?  revert the change?  leave as is?
<seb128> ScottK, because we know we have responsive people on those
<ScottK> Seems to me that's good advice for any packages with people regularly working on them.
<seb128> kirkland, let it for now
<ScottK> seb128: Those aren't the only ones for which that's true however.
<seb128> kirkland, ted mentioned that showing the real name can be an issue in some countries when people don't like having their name displayed
<seb128> ScottK, the wording I used was maybe not adapted sorry
<kirkland> seb128: sure;  presumably those people wouldn't want their login/nickname displayed either?
<seb128> ScottK, I meant "you can find easily somebody to check since it's coming from dx"
<kirkland> seb128: in any case, sorry, I didn't realize this was controversial
<seb128> kirkland, not sure but we probably want some discussions before changing defaults in any case
<kirkland> seb128: i suppose we might talk to dholbach and figure out how we can filter controversial/design bugs out of the patch pilot queue
<seb128> kirkland, nothing to be sorry about, thanks for review the patch ;-)
<seb128> kirkland, well, they should still be in the queue
<ebroder> seb128: I've noticed a handful of dx-sensitive issues in the queue. If you guys want to hoard those bugs (which I have no problem with, as long as they're actually going to get dealt with), it would be helpful for the DX team to comment *early*
<seb128> kirkland, the pilot is there to let the contributor know that someone has been considering the work done so it's fine to subscribe the designers and to say that we need design input
<kirkland> seb128: okay, no problem, i did test it here, and i wondered myself why my login was being used instead of my real name, so i really honestly thought it was perfectly straightforward
<ebroder> https://code.launchpad.net/~udienz/ubuntu/maverick/light-themes/light-themes.fix549365/+merge/42840 is another good example
<seb128> we could probably use a wiki note on what to do for design issues
<seb128> like add an ayatana task
<kirkland> seb128: yeah
<seb128> I will check that with dholback and dx tomorrow
<seb128> ebroder, indeed
<ebroder> seb128: I think this issue is probably more generic than DX, but I'm not entirely sure how I think the net should be cast
<seb128> we need to have a defined way to deal with those
<seb128> right
<ebroder> And I am a little bit worried about obstructing work to shrink the sponsorship queue
<seb128> the goal is not to shring the queue
<seb128> is to let people know their work is being considered
<seb128> or that we care
<seb128> it's fine to tell them the change needs design thinking
<kirkland> seb128: agreed;  i just sent my results to the list, noting that
<seb128> kirkland, thanks
 * micahg thinks sponsors should be able to recognize something as controversial and ask the appropriate team
<seb128> kirkland, thanks was an useful controversial upload ;-)
<kirkland> seb128: np;  thanks for ping me in a friendly manner ;-)
<seb128> we need to hit some of those cases to affine the rules
<ebroder> seb128: Yes, but it's important that we don't switch from "ignoring patches" to "thanking people then ignoring patches". There's a balance out there somewhere
<seb128> or at least document what to do in those cases
<seb128> ebroder, indeed
<micahg> ebroder: patch pilot is supposed to guide patches to the right place as well, not just sponsor
<seb128> well it means we need a way to ask for design input
<seb128> or for other people input
<seb128> not only design
<seb128> then to make sure the input comes in a timelined way
<ebroder> Yeah, I think that's key
<CarlFK> natty alt instller % done bar is jumping backwards
<CarlFK> In whatever comes before "Select and install softwre" step.
<CarlFK> i think it was "retrieving packages"
<CarlFK> even if no one cares much about the graph (i don't), it might be a symptom of a real problem.  any suggestions on how I can get more details?
<ebroder> CarlFK: I think what you're seeing is multiple stages of the installer, although I'm not sure
<CarlFK> welp, whatever i was seeing, i don't see it on a 2nd run.
<CarlFK> ah - it was "configure apt"  and it did it again, around 20 - 25%.
<CarlFK> it jumped from 71% to 65%.
<doko> seb128: any idea about the uninstallability of the thythmbox build dependencies?
<seb128> doko, let me check
<doko> must be something which went into the archive within the two last hours
<seb128> doko, it's building on armel so not sure
<doko> seb128: armel still has a backlog
<doko> setting up a new chroot
<seb128> doko, <robert_ancell> seb128,   libgirepository-1.0-1: Conflicts: libgirepository1.0-1 but 0.9.12+git20101124-0ubuntu2 is to be installed.
<seb128> doko, python-gobject needs a rebuild
<seb128> doing it
<SpamapS> james_w: around?
<james_w> hi SpamapS
<SpamapS> james_w: looking at your bp api merge for the wi tracker
<SpamapS> james_w: fails on bp's that don't have bugs associated
<SpamapS> james_w: but I think thats easily solved
<james_w> SpamapS, fails how?
<james_w> ah, forgot to mention in the merge proposal
<james_w> the bug links aren't exported on production yet
<SpamapS> james_w: *ahh*
<james_w> you can test by changing it to service_root=EDGE_SERVICE_ROOT.replace("qastaging", "")
<SpamapS> james_w: I just did if lp and hasattr(bp, 'bugs'):
<james_w> replace("edge", "qastaging") I mean
<james_w> that's fine by me
<doko> seb128: version too? libgirepository1.0-1 (>= 0.9.3)
<james_w> it would obviously mean that bug links weren't counted as workitems until that change is deployed to production
<SpamapS> james_w: ahh, that would be important. ;)
<SpamapS> james_w: so thats coming very soon though, right?
<seb128> doko, the naming changing to match the debian one
<seb128> doko, which is -1.0
<seb128> it has a provide
<seb128> but provides are not versioned
<james_w> SpamapS, the code is in trunk, it just needs a rollout, which can happen without downtime
<james_w> SpamapS, I'm agitating to get it done sone
<doko> ahh, ok
<SpamapS> james_w: awesome. :) I'll note that in my review of the MP. Otherwise it seems to be working fine
<james_w> SpamapS, great, thanks for the review
<hallyn_> cjwatson: for a low priority ssh bug which was also filed against debian and has a trivial patch - should i bother to do a bzr merge proposal, or will you get that through the debian bug if/when it patches anyway?
<hallyn_> (sorry, I still get confused about exactly how syncs from dbian generally happen for ubuntu-patched packages)
<SpamapS> james_w: set it to Work in Progress.. we should review again when the LP change lands.
<james_w> SpamapS, yes
<james_w> SpamapS, could you look at my other branch? It is rather urgent for Linaro
<SpamapS> james_w: oh right the alt project one. Totally forgot that
<james_w> SpamapS, I assume you are in ~platform?
<james_w> (on people.canonical.com)
<SpamapS> james_w: yes
<SpamapS> james_w: doing test run on natty right now.. then will try the new stuff. ;)
<james_w> SpamapS, could you get me a crontab -l from there?
<SpamapS> james_w: sure, standby
<SpamapS> james_w: something's broken there
<james_w> SpamapS, with my branch?
<SpamapS> james_w: yes, I posted the error I got in the MP
<SpamapS> james_w: looks fairly simple to resolve
<barry> python-gobject is broken: http://launchpadlibrarian.net/60345542/buildlog_ubuntu-natty-i386.nipy_0.1.2%2B20100526-2build1ppa1_FAILEDTOBUILD.txt.gz
<micahg> barry: a new version was just uploaded
<james_w> SpamapS, please pull and try again
<james_w> that'll teach me not to test fully after each merge
<barry> micahg: cool, thanks
<GrueMaster> pitti: sconklin:  I have tested linux-image-2.6.35-24-omap for bug 673509 and it passed.  I have updated the bug accordingly.  Please see that this gets into -updates so I don't have to test it again, thanks.
<ubottu> Launchpad bug 673509 in linux (Ubuntu) "Beagleboard-xm chooses a new IP address on each boot" [Undecided,Confirmed] https://launchpad.net/bugs/673509
<SpamapS> james_w: alright, merged and pushed
<james_w> SpamapS, woop, thanks
<SpamapS> james_w: did you need extra projects added to the configs for linaro too?
<james_w> SpamapS, yes, but I'm just testing to make sure I request the right ones
<SpamapS> james_w: alright. I think we need to put the configs in their own branch and let people edit those more readily than the code itself.
<james_w> that would make sense
#ubuntu-devel 2010-12-09
<cnd> I'm trying to push to a ppa, but twice now I've received the following error back in the rejection email:
<cnd> Rejected:
<cnd> Unhandled exception processing upload: 'NoneType' object has no attribute 'md5'
<cnd> any ideas?
<kirkland> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Natty Alpha 1 released! | Archive: Open | 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:
<ScottK> cnd: PPA support is in #launchpad.
<cnd> ScottK, ahh, thanks :)
<twb> Is rmadison broken for anyone else just now?
<twb> nm, it just returned... probably the server is just under load
<pitti> Good morning
<pitti> GrueMaster: that kernel needs a reupload now (and will presumably get further updates), I'm afraid
<avinashhm> hi, i am facing an error with inserting ko's and removing them .. not able to remove them ... more logs @ http://paste.ubuntu.com/541312/ .. any help ???
<pitti> SpamapS, james_w: hm, your new WI tracker change makes it crash now
<pitti>     report_tools.blueprints_base_url, project.name)
<pitti> AttributeError: 'str' object has no attribute 'name'
<pitti> SpamapS, james_w: you once call it with a name (strnig) and once with an LP project object
<pitti> I committed a fix now
<didrocks> good morning
<dholbach> good morning!
<didrocks> hey dholbach!
<dholbach> salut didrocks
<raphink> hi there
<raphink> how would I go about finding which packages Build-Depend on a given package?
<raphink> say I want to find all the packages that Build-Depend on package foo
<raphink> I can't seem to achieve this with apt-cache
<raphink> and hi dholbach  :-)
<didrocks> raphink: you should check build-rdeps in the ubuntu-dev-tools package
<dholbach> salut raphink
<raphink> thanks didrocks (and hi, too)
<didrocks> raphink: it has some grep-dctrl magic IIRC
<raphink> alright
<raphink> I also just thought that I could grep in Sources.gz on my local mirror :-)
<raphink> that might be faster :-)
<raphink> thanks for the suggestion didrocks
<didrocks> raphink: you're welcome :)
<ev> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Natty Alpha 1 released! | Archive: Open | 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: ev
 * dholbach hugs ev
<ev> :)
<pitti> doko: FYI, I'm looking at fixing python-launchpad-integration
<pitti> doko: python-indicate is in progress, but has some more dependencies, so it'll take a bit to fix still
<pitti> seb128: you're looking at python-ubuntuone? I can take a look at ubuntu-sso-client after lpi
<pitti> then there's python-uno and hplip left (which breaks CD builds)
<seb128> pitti, I will ask rodrigo to debug libubuntuone
<seb128> rebuild is not enough it has gir issues as well
<pitti> ok
<pitti> python-uno will take more time
<pitti> my first attempt to monkey-patch one of the three current OO.o build failures failed :-(
<pitti> GrueMaster: oh, the maverick ti-omap kernel is still in the queue; releaseing now
<sabdfl> is this the best channel to ask about / report vanishing partition UUID's?
<sabdfl> cjwatson: who's the best person to talk to re blkid?
<sabdfl> i noticed that i had no swap
<sabdfl> there's an entry in fstab for a swap partition, with UUID, and a note when it was created during an upgrade
<sabdfl> however, the partition still existed (according to fdisk) but sans UUID
<sabdfl> it was an sda5 inside an extended partition
<sabdfl> so i deleted it and recreated it as an sda2 primary
<sabdfl> but it still seems to have no UUID
<sabdfl> any ideas?
<pitti> sabdfl: can you pastebin the output of sudo BLKID_DEBUG=0xFFFF blkid -p /dev/sda2 ?
<cjwatson> hallyn_: multipath-tools> perhaps you might volunteer? :-)
<cjwatson> apw: RAM swap support> not quite sure what you mean ... do you mean compcache/ramzswap when booting the live CD?  that's mostly in initramfs-tools, with a configuration file in casper to enable it
<pitti> sabdfl: I created a swap partition here, and I do get an uuid, so it's not trivial to reproduce
<cjwatson> seb128: I've added exceptions for libcanberra and gobject-introspection
<seb128> cjwatson, thanks
<seb128> cjwatson, I hope you feel better today!
<cjwatson> doko: on seeing what dh7 is doing: try DH_VERBOSE=1
<cjwatson> CarlFK1: installer progress jumping backwards: it's not a symptom of anything other than that we haven't always gardened all the little tedious progress bar bugs :-)
<cjwatson> hallyn_: what ssh bug is this?  I normally merge openssh into Ubuntu immediately after uploading it to Debian
<cjwatson> sabdfl: Keybuk or pitti probably
<cjwatson> seb128: somewhat ... not doing anything too strenuous
<cjwatson> sabdfl: or lamont, he maintains util-linux in Debian
<rodrigo_> hi
<rodrigo_> doko, ping
<seb128> rodrigo_, hey ;-)
<seb128> doko, better to ping with context I guess
<rodrigo_> hi seb128 :)
<seb128> other people might be able to reply and doko would know what you want ;-)
<rodrigo_> well, I wanted to ask doko about his libu1 submission:
<rodrigo_>   * Rebuild to add support for python 2.7.
<rodrigo_>  -- Matthias Klose <doko@ubuntu.com>  Fri, 03 Dec 2010 00:04:06 +0000
<seb128> rodrigo_, doko has been doing no change uploads for everything using python basically
<rodrigo_> I guess that was for fixing the multiple python versions issue we were having
<seb128> so they get rebuilt with 2.7
<rodrigo_> right, so it's still failing for me, with: configure: error: source directory already configured; run "make distclean" there first
<rodrigo_> so I guess I need to upgrade some package?
<seb128> rodrigo_, no,it failed in the archive as well
<pitti> rodrigo_: sounds like this was a hidden bug all along
<rodrigo_> but have already upgraded everything I can think of
<pitti> rodrigo_: presumably you do two build trees?
<rodrigo_> seb128, ah ok
<seb128> rodrigo_, doko probably didn't investigate each upload, he did some hundred uploads
<seb128> rodrigo_, that's mostly scripted I guess
<pitti> rodrigo_: if you run configure from another directory which has the source, that directory must be clean
<pitti> i. e. unconfigured
<rodrigo_> pitti, yes, it configures several times, then make for each build tree
<rodrigo_> ok, so it's not fixed then
<pitti> rodrigo_: that's wong -- the source tree must be clean; then create the build trees, and call configure there, and only there
<pitti> not in srcdir
<pitti> rodrigo_: I guess it didn't matter as long as we just had one supported python versions
<pitti> s/s$//
<rodrigo_> right
<apw> cjwatson, yeah thats the one thanks
<axp2> hi all
<doko> rodrigo_: yes, seen, and I submitted bug #684983
<ubottu> Launchpad bug 684983 in libubuntuone (Ubuntu Natty) "FTBFS in natty" [High,In progress] https://launchpad.net/bugs/684983
<rodrigo_> doko, ok, fixing it then
<axp2> hey guys, i'm currently working on a bug in software-center, wondering if someone can point me to the right channel to discuss it with someone?
<soren> doko: python-greenlet needs a rebuild for python 2.7. Are you doing a mass upload for these rebuilds or should I just go ahead and do it myself?
<soren> cjwatson: The dh_apport helper has your name on it.. Would it be ok to subscribe you to a bug about it? Don't know how closely you watch apport bugs (if at all).
<ev> axp2: this is seemingly the right place.  Might want to flag down mvo if you have questions.
<cjwatson> soren: not at all.  feel free to subscribe me
<soren> cjwatson: Ta. done.
<soren> doko: Just let me know. I've got it ready to go, since needed it in a ppa.
<axp2> ev: thanks. have done that, looks like he's not here atm. will try him again later
<doko> soren: please just do it yourself, some are still missing
<soren> doko: Alrighty, thanks.
<doko> soren: ahh, it doesn't have *any* deps on python, therefore I missed it
<soren> doko: Hm.. Yeah.
<soren> doko: It only provides a .so, so I suppose it doesn't really need the interpreter, but it still looks odd.
 * soren wonders if there are others like it
<soren> It b-ds on python-all-dev, though. (Naturally)
<doko> soren: would be reason to use dh_python2 to generate these, and then explaining in the debian report, why you did it
<soren> doko: Too late, I'm afraid. Already uploaded it 5 minutes ago.
<doko> lucas: do you have any recent debian rebuilds of synopsis, obmenu, mirage?
<doko> pitti: cdbs question: http://launchpadlibrarian.net/60353084/buildlog_ubuntu-natty-i386.obmenu_1.0-1ubuntu3_FAILEDTOBUILD.txt.gz
<doko> the build tries to build for all supported python versions, not just for the default one
<mvo> hey axp2
<cjwatson> ev: could you please use lp:ubuntu/initramfs-tools?  it would have saved our uploads clashing ...
 * cjwatson tries to sort out the history
<ev> ah, sorry.  Is there a way of telling whether a package is just imported or people are actively using branches for it?
<cjwatson> I'm not sure it matters in this case - you can just use the branch as a default if it's available
<lucas> doko: I did a debian (squeeze) rebuild two days ago
<cjwatson> ev: hm, your upload contained a .bzr-builddeb file - did you actually build it from a bzr branch and just forget to push?
<doko> lucas: could you point me to the build logs? even if these were sucessful?
<ev> cjwatson: indeed, I thought the way this usually worked was that the branch was constructed by using the regular uploads
<ev> thus why I didn't bzr commit
<cjwatson> oh.  it's usually best to commit/push if you can.  never mind, how about I just reconstruct it here since I need to merge anyway?
<cjwatson> the importer won't overwrite the branch if there's a commit tagged with the version number of the upload
<cjwatson> so you can interleave work in bzr with work not in bzr
<lucas> doko: http://blop.info/pub/synopsis_0.12-6_lsqueeze64.buildlog http://blop.info/pub/obmenu_1.0-1_lsqueeze64.buildlog http://blop.info/pub/mirage_0.9.5.1-1_lsqueeze64.buildlog
<lucas> doko: (all 3 successful)
<doko> lucas: ok, thanks
<ev> cjwatson: ahh, that alleviates all of my worry
<ev> thanks for clearing that up
<cjwatson> ev: np - the importer has beaten me to merging it so I'll just recommit on top
<ev> thanks
<tkamppeter> Anyone knows whether there is any problem with libxml2 in Natty? See bug 687973.
<ubottu> Launchpad bug 687973 in foomatic-db-engine (Ubuntu) "[FTBFS] package 'foomatic-db-engine' (4.0.5-0ubuntu6) failed to build on natty" [Undecided,New] https://launchpad.net/bugs/687973
<ScottK> tkamppeter: Are you subscribed to ubuntu-devel-announce?
<tkamppeter> ScottK, I do not know.
<tkamppeter> ScottK, seems not.
<ScottK> tkamppeter: If you read that mailing list, you'd have read a mail from doko warning that we were switching to python2.7 as a default yesterday  and that a few days of problems with Python related packages are to be expected.
<ScottK> I suspect that's the source of your current trouble.
<doko> ScottK, tkamppeter: commented instead of suspecting.
<tkamppeter> ScottK, I have read that, but is libxml2 Python-related?
<tkamppeter> ScottK, I have also not done any update after reading that mail.
<tkamppeter> ScottK, libxml2 depends only on libc6 and zlib1g, not on anything with Python.
<cjwatson> tkamppeter: I suggest reading doko's comment on the bug before commenting further on IRC :-)
<tkamppeter> cjwatson, sorry, did not see from doko's message that he meant that he has commented on the bug.
<tkamppeter> doko, did gcc change to strikter requirements of command line order recently?
<doko> tkamppeter: heh, *now* we come back to the u-d-a question ;)
<doko> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-November/000783.html
<doko> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-October/000772.html
<pitti> doko: obmenu> doesn't seem to be specific to cdbs; I can have a look later on
<pitti> distutils.core not found looks weird
<doko> pitti: obmenu has another cause, as I found
<doko> pitti: but synopsis and mirage do build in debian, and don't try to use all python versions
<pitti> doko: not sure what you mean? debian/rules explicitly does for buildver in 2.6 2.7 .., so why shouldn't it build for both?
<tkamppeter> doko, thanks.
<pitti> doko: ah, no, that seems to be distutils.mk; so is that wrong?
<doko> pitti: it seems so, but it doesn't do that in unstable, trying to find out why ...
<pitti> doko: ah, ok; I got the source now, and it's not even a python-* library, so building with the current versino should be sufficient
<doko> pitti: otoh, I think this one is correct to fail, although I don't know why it doesn't fail in unsable: http://launchpadlibrarian.net/60373280/buildlog_ubuntu-natty-i386.python-opster_1.1-1_FAILEDTOBUILD.txt.gz
<doko> pitti: yes, generally all the packages (applications) with a private python lib ftbfs
<soren> distutils.core is in the python2.x packages, right?
<soren> They are in Maverick, at least.
<doko> soren: yes. the package thinks it should build for all supported python versions, and fails for 2.6, because the b-d is just python-dev. this behaviour is not seen in debian. trying to figure out why
<soren> And the build log looks like python2.6 doesn't get pulled in.
<soren> Ah.
<janimo1> out of curiosity is it possible for a package to specify that it should be built with a non-default gcc (4.4 in this case) on the build servers?
<seb128> janimo1, yes
<seb128> you can set CC=gcc-4.4 or equivalent in the rules
<seb128> with an adapted build-depends
<janimo1> seb128: and add the explciit build depends
<janimo1> aha, ok thank
<seb128> but usually you probably want to fix your code to build with the current compiler
<janimo1> this may temporarily needed only
<janimo1> for ghc6
<seb128> ok
<seb128> check with doko maybe
<janimo1> as it uses itself to build
<janimo1> yes
 * Laney sees ghc6
<Laney> what's the problem?
<janimo1> Laney: ARM FTBFS of many haskell packages because -lpthread is not passed, so Setup.hs does not compile
<Laney> oh, yes
<janimo1> ghc6 itself does not build with such a ghc6
<Laney> I've fixed that locally I hope
<Laney> -optl-pthread is the secret flag
<janimo1> so first it may be fixed using gcc 4.4 which does not exhiobit that
<janimo1> Laney: secret flag to be passed where?
<Laney> to ghc
<janimo1> upstream issue http://hackage.haskell.org/trac/ghc/ticket/4523 I think this is the same
<Laney> you can put it in SRC_HC_OPTS in mk/build.mk
<doko> <doko> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-November/000783.html
<doko> <doko> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-October/000772.html
<janimo1> Laney: but that owuld mean changing every package
<doko> janimo1: ^^^
<Laney> that patch too
<janimo1> ?
<Laney> no
<Laney> fix it in ghc, add that patch
<Laney> then you can remove those changes on the next upload
<janimo1> Laney: indeed ghc6 is the one needs fixing
<Laney> (the pthread ones)
<doko> but even then, haskell had a lot of build failures in maverick
<Laney> on armel?
<Laney> it's not fully supported, only a stage one compiler unfortunately
<doko> yes
<janimo1> doko:  I know the cause, gcc 4.5 is more strict it is ok
<Laney> ...
<janimo1> hence ghc6 needs to be patched
<janimo1> permanently
<janimo1> Laney: what I ws thinking is fix ghc6 - maybe using a 4.4 gcc to build itself
<Laney> i don't think it's necessary
<janimo1> and then remove that change (gcc 4.4 dep) but leave the pthreaf fix
<Laney> let me do this upload
<janimo1> ok I was about to try the build
<janimo1> as part of a caonfigure step ghc6 calss ghc6
<janimo1> which on armel FTBFS for me
<doko> janimo1: no, we made some changes in the linking behaviour, so if ghc drops something, then please add it, and use --no-as-needed for this particular link
<Laney> yes you can pass -optl-pthread there
<Laney> edit theh configure script
<doko> janimo1: no, gcc-4.4 is not an option
<janimo1> doko: yes, I know , I said ghc6 needs to be changed, ghc upstream agrees and knows about the issue
<doko> ok
<janimo1> doko: 4.4 as a temporary oncshot build in case the self bootstrap needs it
<doko> sure
<Laney> i'll upload now
<janimo1> Laney: I got FTBFS on ghc6 ./configure since it calls the existing ghc6 which doesn ot pass the proper flags
<janimo1> Laney: ok, fingers crossed
<janimo1> :)
<Laney> janimo1: you can fix that in the configure script
<Laney> i did test build ;)
<janimo1> Laney: ok, have you seen the patch in the issue abobe?
<janimo1> Laney:  is it the same probelm you fixe
<Laney> yes, that's the real fix
<janimo1> d?
<janimo1> but sligtly differently?
<Laney> but ghc ftbfs because of the original problem so you have to add the explicit links to get it to build
<Laney> because it build-depends on itself which is obviously already broken
<janimo1> BD on itslef ins not broken imo
<janimo1> gcc bd on itself
<Laney> not inherently, in this case
<Laney> it's why you get ftbfs
<janimo1> Laney: ok, will wait for your upload to build and hope it solved the issues then
<janimo1> but the real fix is needed right? You mean there needs to be a new upload anyway with that?
<Laney> you need to add the configure fix to get ghc built correctly
<Laney> you need to add the explicit linking to hack the broken archive ghc into functioning so that you can build the new fixed one
<janimo1> Laney: I see, that's what I thought was one of the two solutions (the other being GCC=4.4)
<janimo1> figuring there may be more than one call to ghc6 while bootstrapping and instrad of hunting them all down, just build it with a known good gcc
<janimo1> but since your change fixes it as well it is fine :)
<janimo1> Laney: you are the de facto ubuntu gch maintainer? I don;t mind then if you add the 'real fix' as well as part of one of your uploads
<Laney> i am adding both
<janimo1> great :)
<hallyn_> cjwatson: ssh bug - i was looking at bug 686671
<ubottu> Launchpad bug 686671 in openssh (Ubuntu) "ssh-copy-id assumes $HOME" [Low,Confirmed] https://launchpad.net/bugs/686671
<hallyn_> cjwatson: as for multipath-tools, yes - i wantted to make sure noone else was interested, and otherwise i volunteer
<sabdfl> pitti: http://pastebin.ubuntu.com/541455/
<doko> seb128: is an evolution upload planned, just wanting to do a rebuild
<seb128> doko, if we do a rebuild we will probably want to get some fixes in as well yes
<seb128> doko, is that for the python transition?
<doko> yes
<seb128> doko, ok, don't bother about it, we will do an upload
<doko> I'll just skip it, if you upload it
<seb128> we have some pending fixes to do so we can as well make the upload useful
<doko> seb128: anything else on this list: http://paste.ubuntu.com/541459/
<seb128> doko, linbindicate is being worked by kenvandine
<seb128> that's python-indicate as well
<seb128> doko, rodrigo is doing libubuntuone
<seb128> doko, let xchat-gnome we need to update it as well for the as needed
<seb128> doko, eog and gedit you can drop as well
<seb128> that's all I see
<kenvandine> seb128, i am going to talk to tedg about uploading dbusmenu from before the gdbus port now... i have it all ready and it will fix the build issues
<seb128> kenvandine, ok great
<kenvandine> he didn't want to because of breaking the api twice...
<doko> ok
<kenvandine> but that is better than this
<seb128> kenvandine, right, seems a safe way to go for it
<pitti> sabdfl: ugh, "180388658839 bytes by 612718282101927924 read() call(s)
<pitti> sabdfl: I hope that's a bug due to long ints :) (but I'm on amd64 as well and don't get that)
<pitti> sabdfl: how did you create that swap partition? I think you said you just created it from scratch, right?
<brendand> i'm working on the testability of update manager
<brendand> i'm trying to work out a criteria for 'success' of an update action
* pitti changed the topic of #ubuntu-devel to: Natty GDM login broken, see bug 654578 | Archive: Open | 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: ev
<seb128> brendand, you might want to talk to mvo
<seb128> mvo, ^
<pitti> sabdfl: (currently busy fixing gdm); would you mind filing a bug about it, add that pastebin, and create a snapshot of that partition's first MB? sudo dd if=/dev/sda2 of=/tmp/swap.dump bs=1M count=1
<pitti> sabdfl: that image should help us to reproduce the bug and fix blkid
<pitti> sabdfl: I used mkswap on a spare partition and that worked, so please describe how you created it
<mvo> brendand: hey, well that the updates installed without a problem I guess :) what exactly do you need? a way to figure that from the windows being presented?
<brendand> more looking at the internal state of the update manager
<brendand> i've added a signal which is sent out when the update is done
<brendand> with a success value
<brendand> at the moment this is derived from whether the network mgr is connected
<brendand> somehow i don't think is a comprehensive definition of success
<brendand> what does a failed update look like?
<brendand> i guess an empty update list isn't it
<brendand> because the repositories could be empty
<mvo> brendand: hold on a sec, I check what the best approach might be
<pitti> ok, so it's not gdm
<seb128> pitti, it's some xorg script failing?
<seb128> like X11 scripts?
<pitti> seb128: I don't think so; startx works fine
<seb128> (just guessing)
<pitti> seb128: my current best candidate is dbus
<seb128> oh, keybuk patched that yesterday
<pitti> seb128: give me some more minutes to bisect the packages that I upgraded this morning
<seb128> that = dbus
<sabdfl> pitti: i created this partition today with fdisk
<pitti> sabdfl: right, but did you mkswap it?
<sabdfl> deleted the old extended and logical partition (2 and 5) and added a new primary, 2
<mvo> brendand: there is a action-done signal that is emited, you could use that, its ok if that is natty, right? I can add a signal to the dbus iface that emits done and a success/filure state
<sabdfl> pitti: i didn't do mkswap, just fdisk with setting the type to 82
<pitti> sabdfl: ah
<sabdfl> why would it need mkswap to get a uuid?
<pitti> sabdfl: that'll just create a partition with random garbage in it; you need to manually create a file system
<brendand> i'm catching the action-done
<pitti> sabdfl: (btw, gparted or the disk utility in system -> admin are much more comfortable)
<brendand> couldn't see that it provided any success information
<pitti> sabdfl: sudo mkswap /dev/sda2
<brendand> i've added the signal
<sabdfl> ok. somehow, in various upgrades, the uuid went titsup, because the original problem was that the UUID in fstab wasn't being found, and blkid had no idea of the UUID for the partition
<brendand> just need to sort out the logic of success/failure
<mvo> brendand: ok, hold on a minute and I will commit something
<pitti> sabdfl: right, I read that; but I'm afraid due to the repartitioning the original data is now gone :/
<pitti> sabdfl: well, unless you can recreate it exactly as it was before
<pitti> and you didn't write anything to the new partition yet
<sabdfl> pitti: ok, mkswap created a uuid, and updating the fstab then made everything work
<sabdfl> thanks
<pitti> sabdfl: ah, good
<sabdfl> i should have called out before removing the problematic partition
<pitti> sabdfl: there are some cases where old (i. e. hardy or so) blkids would still have identified as swap, but newer ones didn't
<pitti> sabdfl: how old was that old swap partition?
<cjwatson> hallyn_: OK, I'll get that forwarded upstream for starters
<pitti> sabdfl: a few years ago, mkswap and various mkfs.* were pretty sloppy and didn't properly zero out the first blocks
<pitti> sabdfl: so if you e. .g first created an ext4 and then a vfat on top of that, the first blocks had signatures for _both_ file systems
<pitti> sabdfl: in the past, blkid made a random choice, and now it just says "erm, dunno"
<pitti> (for safety)
<pitti> sabdfl: but that's the only known case to me
<doko> soren, pitti: I think I found the cause for the failure: python2.7-dev and python2.7 are installed, and python2.6 is still pulled in by a library depending on libpython2.6. and both cdbs and debhelper use pyversions -vr / -i, and are not looking at the build-depends, here the python-dev, or python-all-dev package
<cjwatson> sabdfl: I used to hear of issues which implied that software somewhere had run mkswap without preserving the swap UUID, which would leave any other OS on the same system that was trying to use that swap partition by UUID without swap.  The Ubuntu installer has preserved the UUID since feisty.  I've never been able to track down what the other problems might have been (we usually only hear about the problem some arbitrarily ...
<cjwatson> ... long period of time after the fact).
<cjwatson> haven't heard much of such issues for a while though ...
<cjwatson> that may not be the same as what you're reporting though
<brendand> mko: thanks
<mvo> brendand: please check my latest commit 1994
<mvo> brendand: it adds a new boolean "success"
<soren> cjwatson: I'm not entirely sure of the details, but I swear at some point, every time I hibernated, my swap partition would get a new UUID.
<cjwatson> soren: it's possible.  is that still happening?
<soren> cjwatson: I remember which laptop it was, and I stopped using that one while Breezy was still The New Thing[tm].
<ogra> i think swap encryption also calls mkswap on boot, no ?
<soren> cjwatson: Not that I've noticed, no.
<cjwatson> I have a vague memory that at one point cryptsetup was fouling things up.
<soren> Hm... I don't remember if I used encrypted swap on that one.
<soren> I don't recall seeing it since then, though, so it's probably solved.
<james_w> pitti, sorry for the bug, here's a good fix: https://code.launchpad.net/~james-w/launchpad-work-items-tracker/multi-project/+merge/43221
<cjwatson> hallyn_: actually, it's already fixed in upstream / Debian experimental / natty
<pitti> james_w: thanks! merged
<cjwatson> I'll close it
<james_w> pitti, thank you
<james_w> pitti, sorry again
<pitti> james_w: no problem at all; stuff just happens :)
<pitti> james_w: it's not like this was gdm not working any more or so *cough*
<kirkland> pitti: james_w: are you talking about whatever reason I can't login to my desktop?
<james_w> heh :-)
<pitti> kirkland: yep, I just hunted that down, see bug 654578
<james_w> kirkland, I'm not, no
<ubottu> Launchpad bug 654578 in libcanberra (Ubuntu) "Returned to gdm screen after logging in" [Critical,In progress] https://launchpad.net/bugs/654578
<pitti> itz mterry bug
<kirkland> pitti: cool;  is there a workaround at the moment?
<pitti> kirkland: (I also updated /topic for that)
<kirkland> pitti: thanks, i'm trying to figure out how to read the topic in irssi :-)
<pitti> kirkland: sudo rm -r /etc/X11/Xsession.d/52libcanberra-gtk3-module_add-to-gtk-modules/
 * mterry fixing now
<pitti> kirkland: that's actually the proper fix :)
<kirkland> pitti: coolio;  trying now ...
<kirkland> pitti: worked ;-)  thanks
 * pitti adds that to the bug description
<kirkland> pitti: i was deathly afraid that it was an ecryptfs problem at first
<pitti> kirkland: wb :)
<kirkland> pitti: :-)
<kirkland> pitti: much as I like w3m/irssi/sup-mail running in byobu, this is way better :-P
<pitti> hehe
<smoser> pitti, general question... i do a verify of -proposed, like in bug 651370
<ubottu> Launchpad bug 651370 in linux (Ubuntu Maverick) "ec2 kernel crash invalid opcode 0000 [#1]" [Medium,Fix committed] https://launchpad.net/bugs/651370
<smoser> should i add 'verification-done' and remove the '-needed' ?
<pitti> smoser: please do; thanks!
<kirkland> pitti: also, i forgot how dependent I am on networkmanager, as I was trying to molest iwconfig/ifconfig into getting me on my wireless from the command line :-D
<pitti> kirkland: right; I think last time I tried that it took me a while to figure out
<mterry> fix uploaded
<sabdfl> pitti: i *think* that partition was created with mid-cycle lucid
<pitti> kirkland: it's actually much easier if you put that into /etc/network/interfaces and let ifup do it for you
<kirkland> pitti: yeah, i spent 5 minutes and then grabbed an ethernet cable!
<pitti> kirkland: way to go :)
<pitti> mterry: cheers
<kirkland> pitti: good idea;  i'll use that next time
<cjwatson> kirkland: there's cnetworkmanager in natty ...
<cjwatson> and maverick come to that
<smoser> pitti, thanks. i just wasn't clear if i was supposed to do that, or just comment that i did and then have someone on the SRU team do the tag change.
<kirkland> cjwatson: interesting;  never heard of it
<kirkland> RoAkSoAx: hey, looks like testdrive is broken in natty, presumably python 2.7 issues
<kirkland> RoAkSoAx: can you take a look?
<pitti> smoser: if you do it youself, you save me 10 seconds
<smoser> great. sorry for wasting more than that asking you :)
<czajkowski> ev: just did a clean install of lucid and came across this when it had finshed, ever seen this happen http://twitpic.com/3ecx13
<hallyn_> kirkland: nmcli works
<hallyn_> I was even able to join a vpn with it
<kirkland> hallyn_: hrm, didn't know about that one either
<hallyn_> (which i had defined through the nm-applet before)
<hallyn_> i think it's only become really useful in natty
<apw> cjwatson, i was thinking about the grub background thing ... i wonder if just having a small 'purple background' as the image would work ... ie the plymouth screen with no text etc
<rodrigo_> doko, seems I fixed it, so submitting the package, so take a look at it if you want later one
<rodrigo_> later on
<doko> rodrigo_: which one?
<rodrigo_> doko, oh, sorry, the libu1 issue
<doko> rodrigo_: uploaded?
<rodrigo_> doko, doing it now
<rodrigo_> doko, I have the code in a branch, do you want to look at it now?
<doko> rodrigo_: sure
<rodrigo_> doko, http://pastebin.com/aLL3cw8d
<cjwatson> apw: it's possible, but I'd rather start off making it as close to the plymouth image as possible
<cjwatson> apw: it would certainly make scaling issues go away, but on the other hand it's not clear whether it meets the mandate I've been given
<doko> rodrigo_: mkdir build seems to be missing
<rodrigo_> hmm
<rodrigo_> ok, it worked ok without it, but I guess it indeed needs to be added
<doko> rodrigo_: maybe you should remove it clean?
<rodrigo_> yeah
<doko> make sure that it does build twice in a row, and doesn't include generated files in the diff
<SpamapS> pitti: re wi tracker.. I tested it extensively on my machine (ran through collect on two different cfg files) is it a python version thing?
<pitti> SpamapS: it's all good now
<geser> doko: is it planned to do a no-change rebuild of packages build-depending on python-dev now the default python version changed? (or did it already happen?)
<SpamapS> pitti: what was ths issue?
<pitti> SpamapS: it passed once a string and once an lp project object
<SpamapS> pitti: also, I'm not getting any emails even though I am subscribed to the ML
<cdbs> doko: It appears package miro didn't build against python2.7 in its rebuild. A test build with the proper build-dep and proper pyversions set to 2.7 worked fine. Are you working on it or should I upload the change? I have test-built it successfully
<doko> geser: already done, I have one more batch. Here are our current issues: https://launchpad.net/ubuntu/+bugs?field.tag=python27
<SpamapS> pitti: in fact, the mailing list just isn't getting messages
<pitti> SpamapS: right, not sure why; seems lillypilly can't send there
<doko> cdbs: please upload
<SpamapS> pitti: thats weird.
<SpamapS> pitti: is it subscriber only?
<pitti> SpamapS: presumably
<geser> doko: is vim in this second batch? vim has no dependency on libpython2.6 anymore as it dlopen() it (but vim has a build-dependency on python-dev)
<pitti> but I'm getting my own mails just fine
<doko> geser: no, please upload
<ev> czajkowski: sorry, was on a call.  Yes, that's entirely harmless and is documented in the 10.10 release notes.
<doko> geser: please coordinate with barry on the bug list
<cdbs> doko: done, thanks!
<czajkowski> ev: that's rather annoying :(
<czajkowski> ev: thanks though
 * doko is cursing quit build logs
<doko> even quiet
<sveinse> Anyone knows if emacs has a different font redering system than rest of gnome? My fonts become larger in the emacs editor than the rest of gnome. Even emacs' font picker displays the font differently then inside the editor.
<RoAkSoAx> kirkland: will do. Will upgrade to Natty and work on it!
<kirkland> cjwatson: hey question for you ... i was thinking about sending ssh-import-id to the upstream openssh devel list (and make the import URL configurable) ... what do you think?
<achiang> cjwatson: i have seen that before too
<achiang> oh, i guess it's a known issue
<cjwatson> kirkland: go ahead
<cjwatson> kirkland: I would much rather this sort of thing went upstream in general anyway
<doko> rodrigo_: should I upload something?
<kirkland> cjwatson: agreed, thanks.
<rodrigo_> doko, no, already uploaded
<rodrigo_> doko, with the 'mkdir build' thing you mentioned
<doko> rodrigo_: thanks
<rodrigo_> doko, you're welcome :)
<nmarques> anyone can gimme some help with libindicate building ?
<seb128> nmarques, hey, what are you trying to do?
<james_w> SpamapS, https://code.launchpad.net/~james-w/launchpad-work-items-tracker/blueprints-api/+merge/43240 if you have a few minutes please
<doko> rodrigo_: http://launchpadlibrarian.net/60384209/buildlog_ubuntu-natty-i386.libubuntuone_0.3.8-0ubuntu4_FAILEDTOBUILD.txt.gz
<rodrigo_> doko, yes, saw it
<doko> seb128: is there any doc/announcment how this kind of thing has to be fixed?
<SpamapS> james_w: so one other thing I didn't mention yesterday was that this was a bit slower than the page scraping method...
<james_w> SpamapS, really? It's faster for me
<SpamapS> james_w: it may have been a temporary issue
<james_w> SpamapS, I'll run another test with the real data and see
<james_w> in theory it does an order of magnitude fewer round trips, and avoids downloading all the superfluous stuff that you get in the HTML page
<james_w> plus I would have thought less regex matching would cut a further couple of percent
<doko> mterry: +build2 for a sourceful change in seed doesn't seem to be correct
<seb128> doko, rodrigo_: you need to b-d on the gir you use
<mterry> doko, I agree.  build1 was just a rebuild, but I accidentally left build2 on when I made a change.  Is such a mistake worth a new upload?
<rodrigo_> seb128, it doesn't use atk gir
<seb128> rodrigo_, well then one of the gir you use does and doesn't depend on it
<SpamapS> james_w: right, I was surprised too.. my thought was just that the API code might not be optimized yet
<rodrigo_> yay, gtk I guess
<nmarques> seb128, just a bit please... need to care for something real quick
<james_w> SpamapS, the API usage code I wrote, or the Launchpad API?
<james_w> SpamapS, I'd agree either way though :-)
<doko> mterry: I don't know if it will be autosynced, sorry
<seb128> rodrigo_, well it does
<seb128> rodrigo_, but seems you don't db on gir1.0-gtk...
<rodrigo_> yes
<mterry> doko, well it still has an ubuntu suffix, so I doubt it will get autosynced
<seb128> rodrigo_, yes?
<SpamapS> james_w: the LP API
<rodrigo_> yes, I don't db on gir-gtk :)
<doko> seb128: osm-gps-map, this seems to be included in the package itself, but the .gitignore ignores it
<cjwatson> mterry: indeed it won't
<cjwatson> +build1 was wrong in the first place
<mterry> cjwatson, oh really?  We just bump ubuntu for no-changes?
<cjwatson> that should just have been -0ubuntu2 ... the only value in "build" is to change the version in a way that doesn't involve adding an "ubuntu" substring to the version
<james_w> SpamapS, it's certainly not great, but the code organisation means that it should generally be <= the time taken to get the HTML page
<mterry> cjwatson, noted
<seb128> doko, I guess that was for someone else?
<james_w> SpamapS, though the blueprint code is rather neglected, so maybe that's not true here
<seb128> rodrigo_, ok, that's your bug ;-)
<doko> seb128: no, but if somebody else can help ...
<seb128> doko, I've no clue about osm
<SpamapS> james_w: my observation was just on the first 10 bp's .. but it seemed consistent yesterday. I will give it a look again later.
<geser> barry: any reason I should wait with getting bug 688149 sponsored? (no-change rebuild with python 2.7)
<ubottu> Launchpad bug 688149 in vim (Ubuntu) "No-change rebuild with Python 2.7" [Undecided,New] https://launchpad.net/bugs/688149
<barry> geser: nope.  i can't do it for you though (yet ;).  ping doko
<doko> cjwatson: I'd like to upload a "hack": in python2.6, add a dependency on python2.6-dev. this works around the current build failures when a package b-d's on python-dev, but python2.6 is pulled in via libpython2.6, and the package tries to build with python2.6 and cannot find the python2.6-dev headers. as a temporary change until packages are rebuilt.
<doko> barry: ^^^
<cjwatson> ew.  um, not sure what that will do to CD builds
<cjwatson> I'm a bit concerned that that means people upgrading through natty will all end up with python2.6-dev installed
<cjwatson> how many such failures are there?
<doko> cjwatson: it won't make them worse. this problem will settle, when we don't have that many deps on libpython2.6 anymore
<doko> ~50
<geser> cjwatson: as you sponsored vim for me in the past, have you got a minute to sponsor bug 688149? or should I ask someone else or add it to the sponsoring queue?
<ubottu> Launchpad bug 688149 in vim (Ubuntu) "No-change rebuild with Python 2.7" [Undecided,New] https://launchpad.net/bugs/688149
<cjwatson> geser: I can do it now
<geser> thanks
<cjwatson> doko: it will certainly make the upgrade situation worse, won't it?
<doko> cjwatson: how?
<cjwatson> 17:10 <cjwatson> I'm a bit concerned that that means people upgrading through natty will all end up with python2.6-dev installed
<doko> cjwatson: it will help the ugprade. I'll revert that in a week or so.
<cjwatson> it won't help the upgrade for people running non-development systems upgrading through natty
<nmarques> seb128, I'm trying to build libindicate, but it breaks, by not finding a file (bindings/mono/indicate/indicate-api.raw.pre) on the mono bindings. I'm wondering if I could get a pointer in the right direction to overcome it
<cjwatson> of course you might make the argument that there shouldn't be so many of those
<cjwatson> if it's strictly time-bounded, I guess I don't mind so much, but you will very likely get annoyed bug reports
<doko> yes, known. the alternative would be to add b-d's for all these packages
<cjwatson> which you'd then have to revert again later, I suppose?
<doko> cjwatson: I'll add it on libpython2.6. this way less people are affected
<doko> yes, reverting these 50
<cr3> cjwatson: preseed question for you, if you happen to have a moment: might you happen to know, or point me to someone who does, how server environments preseed the network interface on servers which might have several interfaces, so eth[0-9]+ might not always point to the same physical device and therefore diffrent mac addresses which might not be configured on the dhcp server
<seb128> nmarques, try talking to kenvandine
<seb128> or ted
<nmarques> seb128, thx... I think I might have got some advancements here :)
<cjwatson> cr3: sorry, I don't know exactly.  it's entirely possible it just doesn't work all that well right now.
<cjwatson> cr3: there's a bug somewhere for allowing mac preseeding
<cr3> cjwatson: early_command is run immediately after getting an ip address, right?
<cjwatson> more or less
<cr3> cjwatson: a possible solution might be to configure the dhcp server differently too, preseeding might not necessarily where to fix the problem
<cjwatson> certainly after, in the case of netboot installs
<nmarques> seb128, you know if Ted's around on IRC and where I can poke him ?
<seb128> nmarques, he's usually on #ayatana when he's online
<seb128> he left less than hour ago but he should be back later on
<seb128> ben maybe kenvandine can help you
<nmarques> will ask, thx for your help :) most appreciated
<kenvandine> hey ben
<kenvandine> whoops
<kenvandine> nmarques, what can i help with?
<nmarques> kenvandine, just a simple question... I'm trying to build libindicate... I've patched it with 2 minor patches to fix some stuff (python include paths)... my question though is if any of it's dependencies requires 'special' patching... as it's being a bit of unstable process for me... sometimes it builds, others it just complains that it doesn't find a file in the mono bindings
<kenvandine> nmarques, well i am about to upload libindicate
<kenvandine> with a bunch of GI related fixes
<kenvandine> been blocked on dbusmenu
<nmarques> kenvandine, I'll wait for the new release :)
<kenvandine> :)
<kenvandine> are you building on natty?
<kenvandine> also, you need to be careful to not set deb options to do parallel builds
<kenvandine> it breaks building the mono bindings sometimes
<nmarques> kenvandine, unfortunatly no, but parallel builds are on
<kenvandine> yeah, that won't work
<kenvandine> sharing violations
<kenvandine> never figured out exactly why
<nmarques> kenvandine, the strange part if that if I order it to rebuild without clearing the build root
<kenvandine> that is probably your only problem then
<nmarques> kenvandine, it builds... but it's a wildcard
<kenvandine> yeah
<nmarques> kenvandine, that will sort my issue then... nevertheless I'll wait for the new release :)
<kenvandine> it is one process reading a file that gets regenerated or something
<nmarques> ;)
<nmarques> yeap on bindings/mono/indicate
<kenvandine> exactly
<kenvandine> the other fixes i am uploading is for multiple python versions and GI changes in natty
<kenvandine> not a new version
<nmarques> kenvandine, I'll pick it up ;)
<kenvandine> anyone around that can promote a couple packages to main that have had approved MIRs?  they are blocking one of the indicators i need to get rebuilt
<doko> kenvandine: which ones?
<doko> kenvandine: commented, MIR for ofone is missing
<doko> ofono
<cyphermox> doko, what about ofono?
<doko> see bug #686034
<ubottu> Launchpad bug 686034 in geoclue (Ubuntu) "[MIR] geoclue" [Undecided,Incomplete] https://launchpad.net/bugs/686034
<cyphermox> ah
<cyphermox> I'd just need someone to finish reviewing my ofono merge.
<cyphermox> micahg, ping ^
<cyphermox> micahg, it would be really cool if you could take another look :)
<micahg> cyphermox: can't do it right now, but can tonight, was I the original reviewer?
<cyphermox> yea
<cyphermox> to me, it's fine for tonight. not sure if others are more in a rush for e.g. the geoclue MIR
<micahg> cyphermox: I can't seem to find it, do you have a link handy?
<cyphermox> oh, also missing a MIR for ofono?
<cyphermox> huh, sure, hold on
<cyphermox> micahg, https://code.edge.launchpad.net/~mathieu-tl/ubuntu/natty/ofono/merge-683302
<micahg> cyphermox: oh indeed, I do have a mail for it, I apologize
<cyphermox> micahg, don't worry about it
<micahg> cyphermox: I think they're more interested in teh MIR for ofono ATM, but I'll review the merge again tonight
<micahg> kenvandine: ^^ so do you need this merge done today, or will it take time to prepare the ofono MIR
<kenvandine> ugh... geoclue needs ofono?
<kenvandine> sorry... don't know how we missed that
<Darxus> The unity plugin for compiz is only in natty, right?  Is it included in alpha1?  Mark Shuttleworth asked me to try it.  I'm a little confused about why, but....
<kenvandine> i'll do the mir right now, we need it pretty quickly... it will break the desktop
<kenvandine> Darxus, it is in alpha1
<Darxus> kenvandine: Thanks.
<cyphermox> kenvandine, why does geoclue require ofono?
<cyphermox> ah, nevermind, I didn't read everything :)
<micahg> cyphermox: I still don't see the override in teh diff since the package switched to CDBS
<micahg> unless the diff is broke
<cyphermox> micahg, huh, weird, I triple checked it.
<kirkland> hey desktop guys ... i'm running stock natty/unity ... i'd like to "speed up" the transition between applications when using alt-tab
<kirkland> it seems too "slow" for me, with the fade in/out effect
<Darxus> Is it known that the natty alpha 1 image doesn't fit on (some?) blank CDs?
<kenvandine> Darxus, yes
<Darxus> Yeah, just found that on the alpha1 page, sorry.
<Darxus> Is there a natty testing specific irc channel?
<Darxus> kirkland: Do you know which unity backend you're using, clutter or compiz?  I've read the switch to compiz is partially to increase speed, but I don't know which is default in natty at this point.
<kirkland> Darxus: not sure;  how do i tell?
<kenvandine> Darxus, only the compiz based unity is in natty
<kenvandine> the mutter based isn't
<kenvandine> Darxus, and not just for speed, better hardware coverage too
<Darxus> kenvandine: I did say "partially" :)
<kenvandine> it will work well on a much broader range of video cards
<kenvandine> :)
<Darxus> The unity vs. gnome shell drama is fascinating.
<kenvandine> so if you see unity on natty, you are using compiz
<ScottK> pitti or cjwatson: Would you please rescore kdegraphics (just affects armel) - I need that one built so I can test another FTBFS fix.
<kirkland> kenvandine: okay, i'm using unity + compiz ... how do i speed up alt-tab?
<kirkland> kenvandine: i don't think it's hw accel related ... just looks like a config tweak
<kirkland> kenvandine: things want to fade in an out slowly/smoothly, while I want them to fade instantly, so I can keep working :-)
<kenvandine> yeah, i agree with that
<kenvandine> in ccsm, you can adjust the speed of the application switch
<kenvandine> +er
<kenvandine> alt-tab was slow...
<kirkland> kenvandine: okay, thanks, i'll install that
<Darxus> Before I ask Mark Shuttleworth, andybody want to try to interpret what he's asking me to do here?  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/688171
<ubottu> Ubuntu bug 688171 in unity (Ubuntu) "Installing and uninstalling unity destroyed my desktop" [Undecided,New]
<Darxus> There is no unity plugin for compiz on maverick, which is what I reported the bug for.
<Darxus> Does he want me to try installing natty, switching to a gnome desktop, enabling compiz, and then enabling the unity plugin for compiz?
<Darxus> I'm guessing he just missed the fact that I'm running maverick?
<stgraber> Darxus: yes, sabdfl probably didn't notice you were running 10.10.
<ScottK> Nevermind on rescoring.  It's up soon anyway.
<Darxus> stgraber: Thanks.  I ended up replying based on that belief.
<ScottK> cjwatson: It seems that scribus is in the Kubuntu package set.  I'm not sure that's appropriate as Kubuntu doesn't ship it and it's a Qt3 application (we don't have any of those left in Kubuntu).  I'm not sure what brought it in, but I think that might merit some reconsideration.
<mrenouf|work> CDBS python packaging question: I'm getting "unsupported Python system: python-support (select either pysupport or pycentral)"
<mrenouf|work> I'm setting DEB_PYTHON_SYSTEM="python-support"
<mrenouf|work> I've also tryied pysupport
<boscowitch> hi i wanted to ask if there is a way to let remotly build my  binary deb packet for almost all ubuntu versions currently used (or the last 2)
<boscowitch> or if have have to maintain lokal schroot with all the os versions ?
<boscowitch> (i don't use ubuntu anymore so i'm not really up to date with ubuntu development)
<Sarvatt> doko: so apparently debian is patching out some of the Requires: in libsm libxt and libxmuu and -lX11/-lICE is getting dropped in a ton of places because of it, am I right in thinking we could get an insane amount of ftbs fixes by reverting those 3 patches? :)
<Sarvatt> in sm.pc xt.pc and xmuu.pc I mean
<james_w> SpamapS, you are right, it is a little slower (~10%), I'm going to look at why
<SpamapS> james_w: damn, I was hoping I was wrong
<CarlFK> http://dpaste.de/5FQJ/  "python-uno : Depends: python (< 2.7) but 2.7.1-0ubuntu1 is to be installed"
<CarlFK> guessing this is part of python 26->27 that is still being worked on?
<james_w> SpamapS, could I get you to make a config change to activate yesterday's branch?
<SpamapS> james_w: yeah, what do you need?
<SpamapS> CarlFK: yeah, is there a debian/pyversions file with '2.6' only in it?
<james_w> SpamapS, extra_projects = ['linaro', 'linaro-multimedia-wg', 'linaro-graphics-wg', 'linaro-toolchain', linaro-kernel', 'linaro-pm-wg', 'linaro-infrastructure', 'linaro-project-management', 'linaro-landing-team-ste'] please
<SpamapS> james_w: for natty.cfg ?
<CarlFK> SpamapS: how would I check?  (i don't have a working natty box)
<CarlFK> SpamapS: I do have the busybox shell of the installer
<SpamapS> james_w: ???
<james_w> SpamapS, sorry, had a network outage. Yes please
<SpamapS> james_w: done
<cjwatson> ScottK: have you checked germinate output?
<cjwatson> ScottK: I don't really want to be the central bottleneck for seed debugging - I think most of the resources are available to debug it, and if not I'd like to know so that I can make sure they are
<cjwatson> Sarvatt: that sounds as though it would be incorrect - objects should only be linked against libX11 if they actually use libX11 symbols directly, not merely via libsm/libxt/libxmuu
<cjwatson> Sarvatt: it might fix things temporarily but at the cost of losing out on the leaner-and-meaner linkage
<cjwatson> CarlFK: don't expect daily CDs to work at all for some days while this transition is sorted out
<cjwatson> CarlFK: the installer is definitely not the right environment to debug that kind of thing from :)
<CarlFK> cjwatson: figured as much.  wasn't sure if it was worth reporting.  guessing I should wait a few days.
<RAOF> cjwatson: I'm looking at those packages; libxmu uses libXt symbols in #defines in its headers, libXt uses libX11 symbols in #defines in its headers, so adding the Requires: for those are correct IIUC.
<CarlFK> will there be a "we think we are done, report any problems" event?
<ScottK> cjwatson: I'll investigate it further and see if I can figure it out.
<james_w> thanks SpamapS
<cjwatson> CarlFK: the best way to tell is to watch for desktop CDs actually starting building again. :-)
<cjwatson> RAOF: ah, well that sounds reasonable yes ...
<cjwatson> (but I'd say the right answer is to argue that with Debian rather than to just revert it, right?)
<doko> Sarvatt, cjwatson: is this now pressing? just would like to avoid to look at this this week
<RAOF> cjwatson: Yes; I'm updating the patches in debian now :)
<Sarvatt> doko: getting fixed up in debian, no worries
<doko> ok, thanks
<Sarvatt> ran into this when trying to upstream this crapload of --no-add-needed fixes in X apps
<hallyn_> i'm looking at grub2/debian/patches - there's no debian/source and a bunch of diffs - what is the proper way to apply all the patches and create a new one on top?  I.e. what format is this?  I've done dpatch and quilt, but dunno what this is...
<hallyn_> Daviey: zul: ^
<hallyn_> help? :)
<hallyn_> I guess fakeroot debian/rules apply-patches works
<hallyn_> oh, cdbs-edit-patch?
#ubuntu-devel 2010-12-10
<kenvandine> any archive admins around that can look at some packages in binNEW that are holding up builds?
<AbsintheSyringe> cjwatson, about recent talks about "slashdot" releasing false claims that ubuntu was moving to rolling releases, this is what I had in my mind when I supported this idea of being future for all linux platforms not just ubuntu http://theravingrick.blogspot.com/2010/11/ubuntu-is-not-moving-to-rolling-release.html
<AbsintheSyringe> google picked it up
<didrocks> good morning
<axp2> Hi didrocks
<didrocks> hey axp2
<axp2> Or good afternoon
<dholbach> good morning!
<didrocks> hey dholbach!
<dholbach> salut didrocks
<cdbs> Hi dholbach !
<dholbach> heya cdbs
<dholbach> pitti, james_w: could it be that the workitems tracker is a bit broken right now?
<dholbach> it tells me that we have all kinds of unknown milestones
<cdbs> Can someone please look at bug #688002 and its attached patch? Currently the hplip package is uninstallable and broken. This patch fixes it. Thanks!
<ubottu> Launchpad bug 688002 in hplip (Ubuntu) "Natty broken dependency with python" [High,In progress] https://launchpad.net/bugs/688002
<cdbs> s/uninstallable/non installable/
<cdbs> its a debdiff
<tumbleweed> tkamppeter: cdbs's fix isn't right
<pitti> good morning
<pitti> ScottK: kdegraphics> built now
<micahg> pitti: could you please take a look at bug 685421
<ubottu> Launchpad bug 685421 in hedgewars (Ubuntu) "Packaging bug - Image file alteration causes issues" [Undecided,Confirmed] https://launchpad.net/bugs/685421
<pitti> micahg: ah, thanks; will respond in the bug report
<micahg> pitti: thanks
<pitti> micahg: I'll get to it today
<pitti> dholbach: yes, over night I got tons of cron mail from it; I'll have a look later on
<micahg> pitti: great, thanks, let me know if there need to be any rebuilds because of it, I'll be happy to help
<dholbach> super
<pitti> micahg: I'll care about hedgewars; if you see another one being affected, feel free to upload a rebuild once the fixed mangler is in natty
<micahg> pitti: ok, I was just wondering if there's any way to tell if something would've been affected
<pitti> micahg: not without actually trying to run the game, I think
<micahg> I'll keep an eye out for bugs though
<pitti> but I guess we should hear about the games people care about
<ev> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Natty GDM login broken, see bug 654578 | Archive: Open | 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> ogra: I can't help it, but kiko's mugshot on https://launchpad.net/~kiko just looks like you
<cdbs> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Natty GDM login broken, see bug 654578 | Archive: Open | 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: cdbs
<cdbs> :)
<dholbach> cdbs, woohoo!
 * dholbach hugs cdbs
<dholbach> hey sabdfl
 * cdbs hugs dholbach 
<sabdfl> good morning, /hugs back :-)
 * cdbs hugs sabdfl 
<sabdfl> prescience
<dholbach> cdbs, thanks for patch piloting
 * dholbach hugs sabdfl too
<sabdfl> i love visiting here, /hugs dholbach
<dholbach> :-)
<cdbs> dholbach: yup, but there's barely anything in the sponsor queue for universe packages
<cdbs> :)
<dholbach> http://reqorts.qa.ubuntu.com/reports/sponsoring-stats/ looks GOOD if you ask me :)
<cdbs> Its like the stock market during the recession :D
<tumbleweed> cdbs: you can also help pilot things that you don't have upload rights for
<cdbs> tumbleweed: which is what I am doing ATM
<dholbach> the sponsoring queue is getting emptier, but we still have LOADS of patches sitting in launchpad
<dholbach> and branches for that matter :)
<cdbs> yup, UDD merges need attention
<dholbach> I hope that harvest can help with that in the future: http://harvest.ubuntu.com/opportunities
<dholbach> and people will pick up opportunities when doing an upload anyway
 * dholbach releases a new harvest
<pitti> james_w: what was the rationale of this "extra-projects" branch? if there are blueprints which aren't against the ubuntu project for linaro, why not just track them in a separate linaro.cfg and output?
<pitti> james_w: otherwise we'll have to either ignore one set of milestones, or merge them, which is also confusing (and would break the auto-reset, etc.)
<Riddell> cdbs: aren't I ment to be the patch pilot today?
<dholbach> Riddell, there can be more than one :)
<cdbs> Riddell: I think many people can patch pilot at once
<Riddell> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Natty GDM login broken, see bug 654578 | Archive: Open | 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: cdbs, Riddel
<dholbach> woohoo!
 * dholbach hugs Riddell
 * cdbs hugs Riddell 
<cdbs> though this channel topic just hit its maximum char limit
<cdbs> Riddel is written, not Riddell
<cdbs> I think it would be good to remove the Natty GDM login broken thing
<seb128> you can drop the natty gdm login issue
* dholbach changed the topic of #ubuntu-devel to: Archive: Open | 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: cdbs, Riddell
<cdbs> tkamppeter: Thanks for those uploads :)
<cjwatson> hallyn_: I switched to quilt for later versions of grub2, but if you're looking at lucid then yes it's cdbs-edit-patch
<cjwatson> kenvandine: it helps if you give specific package names when asking that sort of thing
<cjwatson> no idea what to prioritise here
<seb128> cjwatson, what did kenvandine ask to do?
<cjwatson> 03:01 <kenvandine> any archive admins around that can look at some packages in binNEW that are holding up builds?
<seb128> cjwatson, ok, pÃ®tti sorted it since
<seb128> it was libdbusmenu I think
<cjwatson> ok
<ogra> pitti, you mean like http://www.grawert.net/230405_030.jpg ?
<ogra> (sorry, missed to scale it down)
<pitti> ogra: 'zactly :)
<ogra> *g*
<cdbs> g2g, did some patch-piloting on -motu
<cdbs> and elsewhere
<cdbs> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 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
<Q-FUNK> is anybody taking care of doing a rebuild upload for eog and gedit?  they seem to be the last two bits of gnome that use python2.6 here.
<Q-FUNK> I can only upload to main for one package, so I cannot act upon these myself.
<Laney> seb128: ^^^
<seb128> Laney, thanks
<kenvandine> cjwatson, doko_ did it fo me last night
<kenvandine> s/fo/for
<mbiebl> superm1: hi
<mbiebl> superm1: you wrote the upstart job for mysql?
<mbiebl> looks like there is a race condition on shutdown
<mbiebl> mysql.conf has stop on runlevel [016]
<mbiebl> I have /var/lib/mysql on a separate partition
<mbiebl> and the rc.conf job is basically run at the same time on shutdown as the mysql.conf job
<mbiebl> as shutting down mysql takes quite a bit of time here, the umount scripts try to unmount /var/lib/mysql before mysqld is down
<mbiebl> that leads to a correupted fs on every boot
<mbiebl> superm1: want a bug report for that?
<mbiebl> seems other jobs have the very same problem (dbus, rsyslog) but probably nobody noticed because stopping those jobs should be rather quick
<mbiebl> So I'd say it is a general problem of using "stop on runlevel [016]" because it is not race-free
<sladen> rickspencer3:
<didrocks> jdstrand: hey, can you binary new unity-common please?
<doko> james_w: how do I make sure that I get the unmodified upstream tarball for merge requests? e.g. #685180
<jdstrand> didrocks: hey, sure
<didrocks> jdstrand: thanks :)
<jdstrand> didrocks: done
<jdstrand> didrocks: fyi, only i386 was needed, the other three were already accepted
<pitti> jdstrand: (it's presumably an arch-all package, and thus only gets built on i386)
<didrocks> jdstrand: it's arch:all, hence only i386 :)
<jdstrand> oh duh
<jdstrand> that is precisely it
<didrocks> :)
 * pitti ^5s didrocks
 * didrocks ^5s pitti back
<pitti> jdstrand: thanks
<didrocks> jdstrand: thanks a bunch ;) you will make a lot of user happy with intellihide available now :)
<jdstrand> nice!
<fbond> c
<pitti> didrocks: no more fiddling in ccsm to get rid of it? indeed!
<didrocks> pitti: it's not the default yet, will be next week normally. You still have to enable autohide :)
<didrocks> (autohide is now "intellihide" even if the name of the option is the same)
<pitti> didrocks: a day, a week, doesn't matter; I'm just happy to see the feature
<didrocks> :)
<didrocks> I recommend particularly the new effect on minimize now, with the launcher visible
<pitti> didrocks: in classic gnome my screen "overhead" is just the top panel right now; with that, we're getting back to that state
<didrocks> pitti: exactly
<udienz> hello ubuntu-devel
<udienz> i have merge proposed
<udienz> https://code.launchpad.net/~udienz/ubuntu-docs/natty-ubuntu-docs.fix677998/+merge/42857
<udienz> fixing #42857
<udienz> bug 42857
<ubottu> Launchpad bug 42857 in nautilus (Ubuntu) "Cannot rename files on an FTP connection" [Medium,Invalid] https://launchpad.net/bugs/42857
<udienz> and here https://code.launchpad.net/~udienz/ubuntu/natty/aspell-en/aspell-en.fix687483/+merge/43124
<udienz> my pleasure if you want to reviewing it
<Daviey> doko: I don't suppose you have thoughts on bug #688522?  It's pretty urgent, that one :/
<ubottu> Launchpad bug 688522 in eucalyptus (Ubuntu) "[FTBFS] Eucalyptus doesn't build on maverick, with -security pocket enabled " [Undecided,New] https://launchpad.net/bugs/688522
<Daviey> doko: I wondered if we need something similar to http://icedtea.classpath.org/hg/release/icedtea6-1.8/file/eab926d1eb04/patches/openjdk/6650759-missing_inference.patch
<G__81> is there a separate channel for unity where in i could submit patches etc to unity ?
<beuno> G__81, try #ayatana
<G__81> ok
<cjwatson> Riddell: why did you merge the patch in bug 686607?  I already followed up to the merge review asking for it to be sent upstream instead, and wanted to wait for a response there.
<ubottu> Launchpad bug 686607 in openssh (Ubuntu) "ssh client should mention ssh-keygen on mismatched keys" [Low,Confirmed] https://launchpad.net/bugs/686607
<cjwatson> not happy about that, really
<cjwatson> it's a low-priority bug, we don't need to rush on it
<Riddell> cjwatson: oh sorry, I saw that it had been submitted upstream and thought that would satisfy your request
<cjwatson> as I said in the merge request, I'm generally trying to reduce the number of distribution-specific patches we carry.  openssh upstream often doesn't accept patches anything like verbatim
<cjwatson> and if they don't accept it I have the choice between carrying the patch forever, or regressing, either of which is worse than not applying the patch to start with
<cjwatson> doko: taking bug 687488
<ubottu> Launchpad bug 687488 in lilypond (Ubuntu Natty) "lilypond fails to build from source in natty" [Medium,Confirmed] https://launchpad.net/bugs/687488
<james_w> pitti, because linaro has blueprints spread over multiple projects, and we would like to track them together
<pitti> james_w: I updated the merge proposal with some details
<james_w> thanks
<james_w> pitti, which merge proposal? I don't see your comments on either of mine
<james_w> oh, found it
<pitti> james_w:
<pitti> https://code.launchpad.net/~james-w/launchpad-work-items-tracker/multi-project/+merge/43221
<doko> cjwatson: thanks
<james_w> doko, if you do a "bzr builddeb -S" in that branch, you can compare the checksum in the .dsc with the upstream one
<doko> lamont, cjwatson: we need an update of the chroots. every build still has python2.6-minimal installed, which lets builds fail ...
<doko> james_w: thanks
<lamont> doko: awesome
<lamont> doko: so I assume you'd like that "now"?
<doko> :-) well, it's just failing builds
<doko> lamont: does python2.6-minimal need the priority changed for that (still required)?
<lamont> I'll tell you in a few min
<lamont> doko: shure looks like debootstrap grabs required and base..., and it defintitely grabbed python2.6-minimal
<lamont> so... fix that and poke me when it's clear?
<doko> ok
<cjwatson> also python2.6 -> standard
<cjwatson> and python2.7-minimal -> required, python2.7 -> important
 * lamont wanders off for a few
<doko> standard? not optional?
<cjwatson> http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt
<cjwatson> except that much of that should be ignored due to the temporary python2.6-dev dependency
<cjwatson> I assume something in standard still wants python2.6.  it'll drop out once the rebuilds complete, probably
<lamont> The following packages will be REMOVED:
<lamont>   python2.6-minimal
<lamont> 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
<lamont> cjwatson: ^^
<cjwatson> ack
<chrisccoulson> does anyone have any idea why this link fails: http://paste.ubuntu.com/541643/
<chrisccoulson> i've tried pretty much everything i can think of now, and still can't get it to work :/
<cr3> cjwatson: to follow up on yesterday, might you have a bug number for the mac_address feature request to d-i?
<jcastro> mdz: do you have a method of updating the brainstorm ideas to point people to the answers?
<jcastro> and also resolving the ideas when they've been reviewed?
<cjwatson> cr3: bug 56679
<ubottu> Launchpad bug 56679 in netcfg (Ubuntu Natty) "provide a method to use a specified MAC-address as the installation device" [Wishlist,Triaged] https://launchpad.net/bugs/56679
<mdz> jcastro: I don't; is that something you could help coordinate?
<jcastro> I can do them all now.
<mdz> jcastro: awesome, thanks
<jcastro> mdz: I just update the status and add a link in the developer response area so I can just take that recurring WI
<mdz> jcastro: cool, I'll mention that to the TB for future editions
<ogra> pitti, i'm getting WI tracker spam like " [WARNING] milestone "natty-alpha-2" is unknown/invalid" same for ubuntu-11.04-beta and ubuntu-11.04 milestoned specs ... any idea why ?
<pitti> ogra: please ignore, I fixed this this moring
<ogra> ah, thanks
<pitti> erm, bzr, where are thou? "ImportError: No module named bzrlib"
<pitti> doesn't work with python2.6 either
<pitti> but the package ships it for both versions, hmm
<jdstrand> I've got a bit of an emergency security update I need to work on and my archive admin duties will be likely postponed (I typically focus on NEW). if anyone really needs something deNEWed today, feel free to ping me
<cjwatson> doko: what's happening with bug 605042?  last comment from you was moving it to maverick-updates
<ubottu> Launchpad bug 605042 in eglibc (Ubuntu Natty) "[armel] java fails to start with eglibc-2.12-0ubuntu4" [High,Triaged] https://launchpad.net/bugs/605042
<cjwatson> mvo: what more is needed to close bug 671016?  just getting the new page written?
<ubottu> Launchpad bug 671016 in update-manager (Ubuntu Natty) "EOL needs to be handled more elegantly" [High,In progress] https://launchpad.net/bugs/671016
<doko> cjwatson: I think this is still blocked on the kernel side. I don't know what I can do more than backing out this upstream change
<cjwatson> bjf: could you please look at bug 605042?  see above
<ubottu> Launchpad bug 605042 in eglibc (Ubuntu Natty) "[armel] java fails to start with eglibc-2.12-0ubuntu4" [High,Triaged] https://launchpad.net/bugs/605042
<mvo> cjwatson: yes, the page is missing, a bit more testing and then it should be done.
<bjf> cjwatson, afraid i've not done arm for a couple cycles now and have no HW
<dvanstone> how do I add a disk that was solo to current boot options
<cjwatson> bjf: who should be responsible for that bug?  it's assigned to canonical-kernel-team but nobody has taken responsibility
<cjwatson> bjf: and it's blocking something that the foundations team is being asked about every release meeting
<bjf> cjwatson, well, we lost our ARM devs to linaro, i'll send some email and see if I can get it on someones radar (will cc you)
<cjwatson> thanks
<cjwatson> given that this is the hardware that runs our buildds on the LTS release, we have to be able to support those kernels somehow
<cjwatson> lamont: are the chroots updated now?
<lamont> cjwatson: was in a meeting.  kicking things now
<lamont> cjwatson: debootstrap --variant=buildd still gives python2.6-minimal in the resulting chroot
<cjwatson> doko changed that I believe, maybe it hasn't finished publishing yet
<cjwatson> that would be odd though
<cjwatson> I've given it a kick
<cjwatson> should be available in <1.5 hours
<doko> was just published with the last publisher run. amd64, i386, powerpc, but not yet armel
<cjwatson> /home/lp_archive/ubuntu/indices/override.natty.main:python2.6-minimal   required        python
<cjwatson> disagrees
<doko> cjwatson: does the overwrites file need patching?
<cjwatson> I ran change-override.py
<cjwatson> did you try to upload to fix that?
<doko> http://launchpadlibrarian.net/60435630/buildlog_ubuntu-natty-i386.python2.6_2.6.6-6ubuntu4_BUILDING.txt.gz says optional:
<cjwatson> uploading to change Priority has zero effect
<cjwatson> Priority and Section are set in overrides
<doko> no, didn't change anything there
<lamont> bzr branch lp:~lamont/launchpad-buildd/chroot-scripts; sudo chroot-scripts/make-chroot.sh -d natty --lp  <-- should you care to duplicate
<cjwatson> ok, well I've fixed it in the archive now
<lamont> cjwatson: I assume we need a publisher run?
<smoser> i thought htat i had seen a way to transparently cat a file that was compressed or uncompressed.
<cjwatson> lamont: yes
<smoser> ie, something like an option to zcat or something.
<cjwatson> zcat will cat uncompressed files
<smoser> $ zcat foo
<smoser> gzip: foo: not in gzip format
<cjwatson> hm, my mistake
<smoser> ah. --force will do it
<cjwatson> zcat -f, yes
<tgardner> is there a known way to work around the python2.7-minimal install problem?
<cjwatson> tgardner: what's the error message?
<cjwatson> installed fine for me
<cjwatson> bug 687524 I suppose
<ubottu> Launchpad bug 687524 in python2.7 (Ubuntu) "package python2.7-minimal 2.7.1-1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 3" [Undecided,New] https://launchpad.net/bugs/687524
<tgardner> cjwatson, I got caught by the archive being unbuildable earlier this week (I missed the memo). Now I consistently get:
<tgardner> dpkg: error processing python2.7-minimal (--configure):
<tgardner>  subprocess installed post-installation script returned error exit status 3
<tgardner> No apport report written because the error message indicates its a followup error from a previous failure.
<tgardner>  dpkg: dependency problems prevent configuration of python2.7:
<tgardner>  python2.7 depends on python2.7-minimal (= 2.7.1-1); however:
<cjwatson> (and bug 687658)
<tgardner>   Package python2.7-minimal is not configured yet.
<ubottu> Launchpad bug 687658 in python2.7 (Ubuntu) "package python2.7-minimal 2.7.1-1 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 3" [Undecided,New] https://launchpad.net/bugs/687658
<tgardner> dpkg: error processing python2.7 (--configure):
<tgardner>  dependency problems - leaving unconfigured
<cjwatson> the operative line from the bug reports is actually "E: pycompile:240: Requested versions are not installed", which is before the output you showed
<cjwatson> but anyway
<cjwatson> doko: ^- could you have a look at that please?
<tgardner> cjwatson, yep 'E: pycompile:240: Requested versions are not installed'
<doko> looking ...
<cjwatson> in general anything from "dpkg: error processing ..." onwards is just like "make: error 1" - follow-on errors
<tgardner> cjwatson, ack
<doko> tgardner: which versions of python and python-minimal are installed?
<tgardner> python-minimal                  2.6.6-2ubuntu1
<tgardner> python2.6                       2.6.6-6ubuntu3
<tgardner> python2.6-minimal               2.6.6-6ubuntu3
<doko> tgardner: could you unpack python and python-minimal (2.7.1-*) and try again?
<tgardner> doko, what do you mean 'unpack' ? apt-get install ?
<doko> aptitude download python python-minimal, then dpkg --unpack these
<doko> then dpkg --configure --pending
<doko> looks like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605356
<lamont> cjwatson: guesses on eta to publisher being done?
<doko> I should fix that in maverick-proposed
<Riddell> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 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:
<cjwatson> lamont: 16:15 <cjwatson> should be available in <1.5 hours
<cjwatson> lamont: it'll be the publisher run that's about to start
<doko> tgardner: did that work?
<tgardner> doko, no, but I might just be caught in some intermediate state. I can just reinstall this server...
<cjwatson> soren: do you have an example case for bug 687584 to hand?
<ubottu> Launchpad bug 687584 in apport (Ubuntu) "dh_apport installs source package hook in every package" [Undecided,New] https://launchpad.net/bugs/687584
<lamont> cjwatson: afk for a few hours, and then I'll get the chroots updated, will advise :(
<cjwatson> ok, thanks
<pitti> slangasek: ah, thanks for the clarification in bug 395281
<ubottu> Launchpad bug 395281 in consolekit (Ubuntu) "pam_ck_connector.so is called for non-login sessions" [Undecided,Triaged] https://launchpad.net/bugs/395281
<pitti> sconklin: should I reject the linux-lts-backport-maverick upload sitting in the lucid-proposed queue? this was already copied from the PPA
<pitti> sconklin: in fact, it's older (23.40, where 23.41 is in -proposed); rejecting, FYI
<bdmurray> barry: is bug 688655 python2.7 related?
<ubottu> Launchpad bug 688655 in redland-bindings (Ubuntu) "ImportError: /usr/lib/python2.7/dist-packages/Redland.so: undefined symbol: raptor_version_decimal" [Undecided,New] https://launchpad.net/bugs/688655
<barry> bdmurray: it could be some dependent package is broken or different in 2.7.  doesn't strike me as immediately caused by 2.7, but i'll add the tag and take a look
<doko> janimo: ping
<janimo> doko: pong
<smoser> ok. so i'm writing a utility that stuffs a MBR in front of a partition image.  failing 'splice' from the kernel, i basically have to write the MBR, then append the data from the source to the destination.
<smoser> it appears dd with 'conv=sparse' never happened http://www.mail-archive.com/bug-coreutils@gnu.org/msg11804.html
<smoser> can anyone think of a way that i can keep the destination file sparse using utilities in ubuntu (ideally main)
<smoser> basically i need something to open a file for append and copy sparsely from another.
<slangasek> pitti: n/p - not sure what the explanation is for the currently reported behavior, though
<sladen> smoser: suggestions are that cp /dev/fd/0 /dev/fd/1  or something
<sladen> smoser: but I do really wish that they would accept the desire for conv=sparse
<ebroder> sladen: You'd need some way to talk cp into opening /dev/fd/1 with O_APPEND
<sladen> ebroder: I ended up writing a tool
<sladen> ebroder: turned into this  http://blog.alex.org.uk/2010/12/02/copying-sparse-files/
<smoser> sladen, i didn't realize you were involved in that.
<smoser> i had talked to alex and he pointed me at it.
<sladen> smoser: perhaps we should get that into the distribution now it's been released separately
<sladen> smoser: it should already be packaged ;-)
<smoser> sladen, right. thats definitely an option.
<alexbligh> smoser: ok I was quietly betting you'd get no replies on alternatives, but did not anticipated sladen would point you back at the same thing :-)
<smoser> entrapment!
<cjwatson> smoser: is conv=notrunc not sufficient?  I wouldn't have thought that would have changed anything after the endpoint of the write?
<smoser> cjwatson, conv=notrunc works, but if it reads 1G worth of zeros , it will (i assumed) write 1G worth of zeros
<smoser> rather than seeking.
<cjwatson> oh, I read your problem the wrong way round
<cjwatson> thought you were overwriting data at the start, not inserting
<cjwatson> is inserting really the right way to go about it?  perhaps reframe your design
<cjwatson> after all the distance between the boot sector and the partition will not always be the same, probably
<smoser> cjwatson, i'm probably messing this up badly. but http://paste.ubuntu.com/541997/ is what i have.
<ScottK> cjwatson: Would you please rescore the gtkglextmm build (only affects powerpc) - I think that's the blocker on getting python-visual built.
<smoser> i've got process in place that builds partition images, i want to be able to produce disk images from those, and have those disk images boot in a full virt env
<ScottK> (which in turn blocks boosts1.40 removal)
<ebroder> smoser: Does this need to work as not-root? If it can be root-only, will cp work if the destination is a block device? You could use kpartx to create a device-mapper object for the partition, and cp --sparse=always onto that
<smoser> i just really dont want to be root.
<ebroder> smoser: btw, you know about blockdev(8) for probing for things like the size of block devices?
<smoser> ebroder, i'd seen it, but didn't worry to much at this point about block devicesa
<cdbs> IS python-webkit working properly with python 2.7 ?
<barry> cdbs: working, or building?
<cdbs> barry: working
<cdbs> I don't know about its build status
<kirkland> cjwatson: hi...  i just did two preseeded installations of natty;  one on ext3 and the other on ext4
<kirkland> cjwatson: the ext3 one took <6 minutes, the ext4 one took 12 minutes
<cdbs> Since I am getting ImportError: AttributeError: 'module' object has no attribute 'WebView'
<kirkland> cjwatson: what ever happened with that dpkg issue?
<cdbs> barry: ^
<kirkland> cjwatson: did we get that fixed?  or decided not to?
<barry> cdbs: it's possible.  i haven't looked at it yet.  can you file a bug and tag it with python27?
<barry> i can at least look
<cdbs> barry: okay then
<barry> cdbs: thanks
<cjwatson> ScottK: done
<cjwatson> kirkland: it's in progress.  dpkg has a --force-unsafe-io option now, and there are other changes in progress.  I'll adjust the installer before natty to use that
<cjwatson> (or something similar)
<cjwatson> kirkland: Debian is thoroughly on top of the issue at this point.
<kirkland> cjwatson: okay thanks;  i'll set my preseeds to use ext3 for speed for now, and test ext4 once you get a fix committed
<ScottK> Thanks for the rescore on gtkglextmm.
<cdbs> barry: will file tomorror, thanks!
<cjwatson> kirkland: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605009 in particular - finally got some proper attention from tytso, including a specific suggestion to use sync_file_range which will be implemented in the next dpkg release
<cjwatson> kirkland: so I'm holding off doing anything with --force-unsafe-io in the installer until I see whether that makes a difference
<kirkland> cjwatson: okay, thanks;  i'm now subscribe to that debian report
<kirkland> cjwatson: i'll monitor it there;  please poke my if and when you specifically want my testing feedback
<cjwatson> ok
<cjwatson> kirkland: no need to tell me when it gets closed though, I'll get e-mailed
<kirkland> cjwatson: ack
<kirkland> cjwatson: somewhat related to that ...
<kirkland> <kirkland> cjwatson: so i have a preseed with "d-i partman-lvm/confirm boolean true"
<kirkland> <kirkland> cjwatson: but I'm being held at that question anyway
<kirkland> <kirkland> cjwatson: any hints?
<kirkland> <kirkland> cjwatson: full preseed at http://pastebin.com/ME2CDpnx
<cjwatson> kirkland: I can help if and only if I see a DEBCONF_DEBUG=developer syslog
<kirkland> cjwatson: okay, i'll get you one
<kirkland> cjwatson: the only thing odd i see is that the root disk where the installation is taking place is registered as sdb (instead of sda) in the installer
<kirkland> cjwatson: post install, it's sda in runtime
<kirkland> cjwatson: and the installation proceeds just fine as sdb
<cjwatson> anything that that breaks is a bug in its own right
<kirkland> cjwatson: okay
<kirkland> cjwatson: i can't find anything else odd going on there
<kirkland> cjwatson: i'm working around this for now with:
<kirkland> -       preseed_file.write("d-i partman-auto/method string lvm\n")
<kirkland> +       preseed_file.write("d-i partman-auto/method string regular\n")
<cjwatson> it's not worth speculating.  it's about a hundred times quicker to look at a debug log
<kirkland> cjwatson: okay, i'll send another install through with that cmdline option
<jono> hey all
<jono> I have a USB keyring running natty, but persistence is not working, can anyone recommend how I fix it
<jono> ?
<kirkland> cjwatson: well darn;  not reproducing it today :-/  happened several times yesterday
<kirkland> cjwatson: i'll keep the cmdline debug parameter on there though, and grab the syslog if it shows up again
<d-kessel> barry: considering python 2.7/natty - what do you guess when it will be safe to upgrade packages?
<barry> d-kessel: you can upgrade packages now.  which one in particular are you thinking about?
<d-kessel> thanks. well all ~170 update manager tells me to
<d-kessel> barry: thanks. well all ~170 update manager tells me to
<barry> d-kessel: i've been updating my vms today and it seems okay to me
<micahg> hi robbiew, do you have time for a PM?
<robbiew> micahg: sure
<d-kessel> barry: thx, I'll see what it does to my "real" netbook installation
<ebroder> jono: Honestly, if you have a spare USB key, running usb-creator on one key, then using that to do an actual install onto another key is going to be a truer testing environment. It will also get testing for things like the text-free boot changes
<ebroder> I think I saw some discussion about expanding testdrive to install onto a USB key, which would remove the need for the spare
<ebroder> jono: In the mean time, can you start by pastebining the syslinux/syslinux.cfg file on the USB drive?
<jono> ebroder, I just talked with ev about this
<jono> I am not entirely sure what the issue is
<jono> and I have just wiped the stick to install it another way
<ebroder> jono: Ah, ok
<jono> ev would you mind filing a bug for this?
<jono> as you have the outputs I pasted
<ev> jono: those all just show that it isn't a problem in usb-creator
<jono> gotcha
<ev> what we need is something with the issue to post a bug against casper with their /var/log/casper.log attached
<ev> preferably with debug set on the kernel command line
<d-kessel> barry: upgrading failed, it is running dpkg --configure -a now
<barry> d-kessel: dang
<Keybuk> The next time Lennart sarcastically suggests it only took him a year to write systemd, I'm going to reply that it only took me *two hours* to add socket activation to Upstart
<ebroder> Oooh, looks like fun
<Keybuk> https://code.launchpad.net/~scott/upstart/bridges
<Keybuk> adds an upstart-socket-bridge binary
<ebroder> Keybuk: Yeah, I was skimming that and the session-support branches
<Keybuk> if you stick "start on socket PROTO=inet PORT=1234" in your job, the bridge makes a listening socket on port 1234 for you, and when it gets a connection, sends the event with the socket
<ebroder> Keybuk: Uh, don't you need to deal with SOCK_DGRAM vs. SOCK_STREAM?
<Keybuk> ebroder: sure, at some point :p
<Keybuk> that'd be just adding an int type to the Socket structure
<Keybuk> defaulting to SOCK_STREAM
<Keybuk> then adding
<ebroder> socket(2) talks about AF_INET being a "domain", not a protocol
<Keybuk> SOCK=STreaM
<Keybuk> SOCK=DGRAM
<Keybuk> etc.
<Keybuk> yeah, I think I picked up "proto" from inetd
<ebroder> Sure, I agree it's easy, I'm just nitpicking your terminology before anybody commits to it
<Keybuk> noted, shall check I'm using the right thing there
<ebroder> Keybuk: What's the plan for dealing with "start on socket PROTO=unix PATH=/var/run/dbus/system_bus_socket" having an implicit dependency on /var/run being mounted? Do you force the developer to make that explicit by adding an " and local-filesystems" or whatever?
<Keybuk> hmm
<Keybuk> that'd need to be a depedency on the socket bridge for now
<Keybuk> I think the best thing is just to have the socket bridge started on virtual-filesystems
<Keybuk> so /var/run is always available for it
<Keybuk> 0.10 handles this stuff rather better
<Keybuk> but we wanted to have it in 0.6 for fun
<ebroder> I'm not familiar with the changes for 0.10. I'm guessing it rolls mountall into upstart and gives upstart stronger filesystem awareness?
<Keybuk> nah
<Keybuk> but it does actually roll the socket listening into upstart itself
<Keybuk> where this is using a bridge
<ebroder> How does that help?
<Keybuk> because then upstart knows when it should be listening on the socket and when it shouldn't
<Keybuk> e.g.
<Keybuk> while apache
<Keybuk> listen inet 80
<Keybuk> exec ...
<Keybuk> says to only listen while apache is running
<Keybuk> and to only exec on connection
<ebroder> Oh, interesting
<Keybuk> it's the whole "while" thing that helps
 * ebroder nods
<kirkland> jjohansen: hey, would you mind joining #ecryptfs on OFTC?
<lamont> cjwatson: doko: building tarballs now
<lamont> cjwatson / doko: new python2.6-minimal-free tarballs uploaded
<lamont> have a nice day
<doko> lamont: available for builds *now* ?
<doko> lamont: yes, and hurray! seeing now different build failures ;p
<lamont> doko: uploaded == what LP will serve to the buildds the next time they ask
#ubuntu-devel 2010-12-11
<Keybuk> http://paste.ubuntu.com/542196/
<Keybuk> Ugh, just ugh
<ebroder> Are you seriously setting people up to write "start on easter" jobs?
<Keybuk> it's an ... err ... easter egg :p
<ion> hah
<ebroder> Oof
<Keybuk> oh, c'mom
<Keybuk> it's funny
<ebroder> Yes, but only the kind of funny where I feel bad acknowledging that I think it's funny
<Keybuk> who won't be able to resist writing a job with "on easter" or "while not lent"
<Keybuk> cat /etc/init/turkey.conf
<Keybuk>   on thanksgiving
<Keybuk>   kill -TERM
<Keybuk> too much? :-)
<ion> Wouldnât SIGKILL be more appropriate? TERM would be like saying âwould you mind dying, thanksâ to the turkey.
<Keybuk> perhaps
<Keybuk> maybe it's a halal turkey
<Keybuk> what would that signal be? :p
<sabdfl> SIGBLEED
<Keybuk> heh, only you could actually answer that ;-)
<lucas> what's the status of lucid-backports? it seems that there are a lot of pending requests
<ari-tczew> doko_: could you take a look on python-django from unstable? It's to sync, but it's FTBFS due to python.
<kklimonda> ari-tczew: django is sensitive to python upgrades
<kklimonda> ari-tczew: can you paste a build log somewhere?
<cjwatson> lucas: nothing in the queue for archive admin action, anyway ...
<ari-tczew> kklimonda: http://paste.ubuntu.com/542235/
<geser> cjwatson: could you add "libfwbuilder" to PPU for Sylvestre Ledru (sylvestre) (see also his mail to devel-permissions)? we granted him PPU for all his Debian packages. Or do we need to discuss it at a meeting first?
<geser> only a TB member can add PPU right? (or is DMB member enough?)
<kklimonda> ari-tczew: it seems to be related to the python transition that is still in progress. It doesn't ship any compiled libraries so there should be no reason to depend on python-dev or python-all-dev
<cjwatson> geser: can you remind me of the URL to the meeting minutes/logs where we granted that?
<cjwatson> just for my reference
<geser> cjwatson: http://irclogs.ubuntu.com/2010/05/11/%23ubuntu-meeting.html#t16:28 and https://lists.ubuntu.com/archives/devel-permissions/2010-March/000026.html for the application (the wiki page seems to be gone)
<cjwatson> ah, ok - yeah, I think that's fine without a meeting
<cjwatson> geser: done
<geser> thanks, I'll reply to that mail and let Sylvestre know
<cdbs> Due to the python transition, package pywebkit is installing a file /usr/lib/python2.7/dist-packages/webkit/__init__.pyc which wasn't installed in the previous package. This file is breaking the package, and removing the file fixes the problem. Now, what would be the proper method to prevent the installation? The module is a C module. I know I can manually edit debian/rules to remove the file from $(CURDIR)/debian/usr/lib/blahblah/__init__.pyc 
<kenvandine> doko_, can you look at bug 688732 ?  pywebkitgtk is installing a rogue __init__.pyc file
<ubottu> Launchpad bug 688732 in pywebkitgtk (Ubuntu) "package no longer has WebView attribute after transition to python 2.7" [High,Triaged] https://launchpad.net/bugs/688732
<kenvandine> in /usr/lib/python2.7/dist-packages/webkit/__init__.pyc
<kenvandine> which breaks anything using webkit with python2.7
<kenvandine> including gwibber
<kenvandine> i am assuming it must be something with python handling, it doesn't look like the package itself to me
<bluefoxicy> Hey, has anyone considered instant rebooting off the LiveCD after install?
<bluefoxicy> like, kexec load the kernel and initrd, then umount everything disk-based (all USB devices, all hard drive partitions)
<bluefoxicy> don't bother shutting X down, don't bother logging out, don't bother shutting down services
<bluefoxicy> just sync and then kexec exec the kernel
<bluefoxicy> No bootloader, no bios, just right from the livecd straight into the boot cycle
<ebroder> You can't do it like that, because all of your programs have open file handles on the cd
<bluefoxicy> ebroder,  if something physical refuses to unmount then you can cancel the process.
<bluefoxicy> but the CD is immaterial
<bluefoxicy> Are you saying kexec will refuse to run if something is still open?
<bluefoxicy> ebroder, I'm pretty sure kexec will happily run...heh.  hmm.
<ebroder> It usually screws things up in my experience if you don't shut down X, etc. first
<bluefoxicy> ebroder:  Graphics hardware state gets corrupted?
<ebroder> I guess? I'm not really sure
<bluefoxicy> ebroder, what I eventually want is the"system needs a reboot after updates" mechanism to load the kernel and then shutdown properly, but kexec back into the new kernel rather than rebooting through bios
<bluefoxicy> but a quick jump off the livecd seems like an amusing, nondestructive place to play with the code
<bluefoxicy> oh well, no matter.
<ebroder> Are there any ubuntu-dev-tools scripts that upload things to a PPA? I'm looking to see if there's any precedent for interface/process/etc.
<tumbleweed> ebroder: sponsor-patch
<ebroder> tumbleweed: Does that to PPA uploads, or just archive?
<ebroder> I guess that's not all that relevant
<ebroder> Ah, it can do both. Spify
<ebroder> *Spiffy
 * ebroder hates packages that need their build-deps for the clean step
<ebroder> bdrung: ping?
<ebroder> bdrung: For backportpackage, do you want DEB_VENDOR set for pull-lp-source, or for debuild -S?
<tumbleweed> ebroder: you should set it when building / unpacking packages for ubuntu (without any other possible, non-ubuntu use cases)
<ebroder> So for both, then
<tumbleweed> yeah. It sohuld be a no-op on ubuntu, but is a good do-the-right-thing convenience for people who do ubuntu-dev stuff on debian
<bdrung> ebroder: tumbleweed was faster :)
<ebroder> And it's DEB_VENDOR=Ubuntu, not ubuntu?
<tumbleweed> I think both will actually work, but Vendor=Ubuntu in /etc/dpkg/origins/ubuntu
<ebroder> Ok
<ebroder> Oh, whoops - clicked the resubmit button a little too soon. Sorry for the extra spam
<ebroder> I want to start trying to work my way through some of the backports backlog and quickly got stuck on bug #582228. It's a request to backport a version of a package that's no longer there, and there's been no action from the requestor in response to vorian's testing requests. Should I just leave it marked Incomplete as is?
<ubottu> Launchpad bug 582228 in lucid-backports "[test-pkg-a] Please backport Redis" [Undecided,Incomplete] https://launchpad.net/bugs/582228
<ebroder> ScottK: ^
<ebroder> (I'm ignoring for the moment the fact that the bug reads like it really wants to be an SRU, not a backport)
<ebroder> tumbleweed: The quick review turnaround is much appreciated, by the way
<tumbleweed> ebroder: np, and good night :)
<ari-tczew> could someone sponsor bug 669363 ?
<ubottu> Launchpad bug 669363 in lilo (Ubuntu) "Please merge lilo 1:22.8-8.3 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/669363
#ubuntu-devel 2010-12-12
 * penguin42 wonders how many people still use lilo (and why)
<ari-tczew> penguin42: anyway, we should grab changes from Debian for it.
<penguin42> indeed, I'm just curious
<ari-tczew> penguin42: we supply great quality packages even to small number of consignees (:
<penguin42> indeed
<ari-tczew> cjwatson: again MoM is hanging :/
 * maco  tries to find examples on the google
<maco> stupid irc client
<maco> stupid irc client
<ssj6akshat> sam-_-, wow what a nick
<sam-_-> hmm?
<sam-_-> ssj6akshat, hmm?
<ssj6akshat> sam-_-, i mean it is awesome
<ion> dendro-afk: Thanks for the information!
<sam-_-> ssj6akshat, why?
<sam-_-> ssj6akshat, ironie?
<ssj6akshat> sam-_-, the -_- part
<sam-_-> ssj6akshat, ok...
<sam-_-> ssj6akshat, steal it then :-)
<ssj6akshat-_-> sam-_-, :P
<sam-_-> ssj6akshat, your welcome
<bdrung> ebroder: hi
<ebroder> bdrung: Hey, what's up?
<bdrung> ebroder: we just commented your merge proposal at the same time. :)
<ebroder> Ha, so we did
<ebroder> I'll take care of your stuff while I'm rearranging the interface
<bdrung> ebroder: and you could wrap at 80 lines
<ebroder> Sure
<bdrung> ebroder: the "still" in the question sound weird in my ears.
<ebroder> I...honestly don't know why I wrote it like that
<bdrung> the "Something" too
<bdrung> ebroder: the params "<source package> <source release> <dest release> <upload target>" looks to unflexible to me.
<ebroder> bdrung: I'm going to switch those to required options
<bdrung> ebroder: i have a local script that works with one parameter
<bdrung> ebroder: and please allow specifying a version
 * ebroder needs to start taking notes so I don't forget all of this
<bdrung> ebroder: and one feature request: allow building the package before uploading (refer to sponsor-patch)
<bdrung> ebroder: if a version is specified, i use "dget -xu https://launchpad.net/ubuntu/${SRC_DIST}/+source/${PACKAGE}/${VERSION}/+files/${PACKAGE}_${NOEPOCH_VERSION}.dsc"
<ebroder> bdrung: Hmm...I think that for this script it's actually more desirable to verify the version and bail if it's not current
<ebroder> ScottK actually asked me to include a version, since we have a bunch of backport requests like "please backport foo (1.2.3)" when 1.2.3 is no longer current and we can't actually process that request
<bdrung> ebroder: in my use cases pull-lp-source gives me an older version :)
<ebroder> Ok, how about this: if you specify both a source release and a version, they have to match. If you specify just a source release, use pull-lp-source. If you specify just a version, use your dget invoke
<bdrung> ebroder: yes
<bdrung> ebroder: why do you call dch with --preserve?
<ebroder> Because I don't want it renaming the directory on me
<bdrung> aha, ok
<bdrung> ebroder: suggestion: if no source release is specified, use the latest
<ebroder> That's reasonable. For my first draft I was trying to avoid using any more lplib than I had to
<bdrung> ebroder: will the logging print something to the terminal?
<ebroder> Yeah, although I wouldn't mind cleaning that up into something more structured
<bdrung> ebroder: i will ditch my backport script in favor of you backportpackage script (once it allows test building)
#ubuntu-devel 2011-12-05
<Riddell> doko: hmm probably my fault with delay caused by my injury, I should take a look tomorrow
<doko> Riddell, strange, it seems to be just installable. just did give it back
<doko> Riddell, infinity looks like a temporary uninstallability. package started to build
<infinity> doko: Does compiz correctly find its own lib with the build-dep dropped, you didn't need to mangle the CMake mojo at all?
<infinity> doko: (I was about to look into the same thing, since webkit's getting close to done)
<infinity> doko: Oh, I guess the successful builds say yes. ;)
<broder> slangasek: interested in uploading http://web.mit.edu/broder/Public/libsigc++-2.0_2.2.10-0ubuntu2.debdiff ?
<broder> (i'm writing up the corresponding debian bug report now)
<micahg> pitti: did you decide chromium was sitting in -proposed long enough?
<pitti> micahg: there was a v-done on it
<micahg> orly?
<pitti> was that wrong?
<micahg> pitti: oh, that was on one of the other bugs in the changelog :), meh, I just never got to testing it on oneiric since I had to update it to a newer release anyways, there was an issue with M15 which I was hoping was fixed in a newer stable release that I haven't pushed yet
<pitti> micahg: it seems Pedro tested it quite extensively
<micahg> I think I pushed it to lucid though, and there was only the one complaint
<micahg> pitti: ah, let's run with that then :)
<pitti> micahg: so, should the SRU team generally refrain from pushing chromium until you say the word?
<micahg> pitti: well, there were multiple bugs, not all v-done, I would think it's the same as any other SRU in that regard
<micahg> pitti: but in general, it needs someone to ACK that it's been tested
<micahg> in this case, i'd say pedro's testing can suffice
<SpamapS> anybody want to try pounding on this website? curious to see how much punishment it can take and whether or not I can get juju to scale it up fast enough tomeet demand..
<SpamapS> http://ec2-50-16-128-14.compute-1.amazonaws.com/
<SpamapS> nijaba: ^^ your limesurvey charm BTW ;)
<dholbach> good morning
<Laney> bdmurray: Morning, looks like your ubuntu-reviewers automated notice talks about unsubscribing ubuntu-sponsors ;-)
<pitti> so, the next precise_probs.html will look like http://people.canonical.com/~pitti/tmp/precise_probs.html
<infinity> pitti: Including teeny-tiny fonts?
<pitti> infinity: oh, are they too small in your browser?
<pitti> I can bump them from x-small to small
<pitti> but it reads quite fine here
<infinity> I can read it, but I also have fairly good eyesight. :P
<infinity> pitti: Also, when the apt message is "not going to be installed" instead of "not installable", you may want to drill down further to find the root cause.
<pitti> indeed I also played with -o Debug::pkgProblemResolver=true, but it's not particularly helpful
<pitti> but yes, trying to install both will give a better error message then
<pitti> I'll look into this
<infinity> If "apt-get install foo" gives you "Depends: bar, but it is not going to be installed", then "apt-get foo bar" will give you the next level of icky.
<infinity> I also had some nice Perl lying around that does all this by parsing package files.
<pitti> right, that's what I usually do
<infinity> Was written by wouter to do sane dep-wait detection in sbuild.. And I never integrated it into the Ubuntu sbuild (don't ask me why).  I can dig it up.
<infinity> I really should polish it off and get it in lp-buildd.
<infinity> pitti: http://grep.be/blog/en/computer/debian/dep-wait-parser
<pitti> infinity: at that point it's pretty much recursive britney :)
<pitti> thanks for the link
<infinity> pitti: Yeah, reuse of britney's code in britney would lead to similar results (and, I assume, less forking).
<infinity> pitti: Was just example code. ;)
<infinity> pitti: (And a reminder to myself to jam it into launchpad-buildd... Three years late isn't too late, is it?)
<cjwatson> pitti: precise_probs> nice one
<pitti> http://people.canonical.com/~ubuntu-archive/testing/precise_probs_hack.html
<pitti> cjwatson: ^ more useful apt output now
<pitti> kubuntu-full is still a mystery to me (it doesn't have apt output because it succeeds)
<cjwatson> I didn't understand that either; I assumed it must be a bug somewhere inside britney, but couldn't see what
<cjwatson> you probably need to step through it to figure that out
<pitti> *nod*
<pitti> jamespage: taking libxalan2-java FTBFS
<jamespage> pitti, ack
<pitti> infinity: ^ FYI (as you were the last uploader)
<jamespage> pitti: OK if I grab the merge for debian-science?
<pitti> jamespage: please
<jamespage> pitti: great
<Laney> does the britney run for precise_probs only consider main packages?
<pitti> Laney: yes
<Laney> I'm wondering if we can get the raw uninstallable data out somehow, even better for the whole archive
<pitti> Laney: IIRC running it on the whole universe would take weeks, it's an O(n^2) or worse problem
<cjwatson> I believe it's NP
<Laney> yeah, it is
<cjwatson> but there's debcheck already
<pitti> Laney: apt-cache unmet with some filtering might do perhaps
<cjwatson> http://qa.ubuntuwire.org/debcheck/
<Laney> yeah
<Laney> why isn't that used for probs?
<cjwatson> err because different software stacks and no time
<Laney> ok I was just wondering if one was different somehow
<cjwatson> (also I don't know how long it takes to do a full run; precise_probs is hourly and needs to be quick
<cjwatson> )
<Laney> also "broken" on debcheck doesn't mean uninstallable
<Laney> priority mismatch too
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
 * dholbach hugs pitti
 * pitti hugs dholbach
<dholbach> :)
<dholbach> siretart, hey Reinhard - ready to sync xine-lib? :)
<dholbach> (just asking because it's in testing now and we should able to close 835437)
<pitti> meh, armel buildds are severely underpowered now that we lent many of them to armhf
<tsdgeos> pitti: i think you guys don't understand that poppler-data is not only for CJK languages
<pitti> tsdgeos: I do understand it
<tsdgeos> pitti: so? why cripple pdf viewing by default?
<pitti> tsdgeos: but the chance that e. g. an English speaker needs it is quite small, whereas in the CJK area you pretty much need it all the time
<pitti> tsdgeos: as I said, we don't put it on the CD because it's quite large and not needed in areas with latin languages
<pitti> tsdgeos: we could certianly have language-selector install it for all languages, though
<pitti> that should provide a better compromise
<tsdgeos> "an English speaker needs it is quite small" <- why?
<pitti> tsdgeos: well, because they don't usually read Chinese documents?
<tsdgeos> and as i told you
<tsdgeos> you do not understand that poppler-data is not only for chinese documents
<tsdgeos> there is English documents
<tsdgeos> that need it
<tsdgeos> to be properly viewed
<pitti> cmap-adobe-{gb1,cns1,korea1,japan1,japan2}
<tsdgeos> yes
<tsdgeos> that's just a mapping
<pitti> all these encodings apply to CJK langauges only
<tsdgeos> no
<tsdgeos> it's a mapping
<tsdgeos> it's "usually" used for CJK languages only
<pitti> right
<pitti> e. g. I never looked at a document which needed it
<tsdgeos> well
<tsdgeos> i have
<tsdgeos> differene i'm the poppler maintaner and you are not ;-)
<pitti> yes, I believe you
<pitti> I did NOT say that no non-CJK speaker would ever need it
<pitti> I said that the chance is considerably smaller
<tsdgeos> ok
<pitti> so we install it from the network for langauges with a high chance of needing them
<tsdgeos> fair enough
<pitti> and as I said, we could extend that to install it for all languages
<pitti> it's an additional 11 MB for everyone then, which will rarely, if ever, be used, but it would provide that support for legacy encodings
<tsdgeos> it's up to you
<tsdgeos> i can only say that there is regular bug reports about people not being able to read documents because poppler-data is not installed
<doko_> libproxy (0.3.1-2ubuntu2) natty; urgency=low
<doko_>   * debian/control:
<doko_>     - Drop KDE from build-deps on ARM to workaround FTBFS due to KDE stack
<doko_>       being broken due to toolchain issues. This will be reverted after
<doko_>       Alpha 1 (LP: #683072)
<doko_>  -- Michael Casadevall <mcasadevall@ubuntu.com>  Mon, 29 Nov 2010 16:00:27 -0800
<tsdgeos> i only wanted you guys to know it
<tsdgeos> if you can live with that
<tsdgeos> good
<doko_> we need a better way to track work-arounds
<pitti> tsdgeos: right, thanks; I'll go with installing it for all languages, as it keeps coming up occasionally
<seb128> tsdgeos, hi
<tsdgeos> seb128: hi
<seb128> tsdgeos, could the pdf viewer detect when opening a document that poppler-data is needed to view some glyphs?
<seb128> tsdgeos, like could we do some "install on demand" in i.e evince?
<tsdgeos> seb128: yes it could
<tsdgeos> but then you'd need to add that
<tsdgeos> to pdftotext too
<tsdgeos> :D
<seb128> tsdgeos, ;-)
<doko_> pitti, did you fix openoffice.org for armhf as well?
<pitti> doko_: yes, it wasn't an exclusion but an inclusion
<pitti> doko_: i. e. -base only gets built on the arches that libo-base actually exists for, i. e. i386 amd64 powerpc
<pitti> seems to make more sense to me
<pitti> even if it exists on arm* some day, the oo.o-base transitional isn't needed as oo.o-base never existed on arm* before
<pitti> the oo.o source can go away entirely after precise
<infinity> pitti: Erm, you fixed it by making the source not build on arm at all?
<pitti> infinity: yes, so that it'll become NBS
<infinity> pitti: Oh, derp.  It's all arch:all.
<infinity> pitti: Nevermind. :)
<pitti> infinity: not any more :)
<infinity> pitti: I was just wondering why there were only 3 arches building, then brain kicked in.
<pitti> it should be NBS after the next publisher
<pitti> then I'll remove it
<infinity> pitti: Yeah, I meant "all the packages arm cares about are arch:all".
<cjwatson> infinity: ~ubuntu-archive/public_html/armhf/ doesn't seem to be owned by ubuntu-archive throughout
<infinity> cjwatson: I've been rsyncing to it as me, so yeah, seems possible.
<cjwatson> infinity: could you 'mkdir -p dists/precise/main/debian-installer/binary-armhf && touch dists/precise/main/debian-installer/binary-armhf/Packages' in there, please?
<cjwatson> oh, and possibly regenerate Release
<infinity> My hackish Release gen script won't do that.  But can fix.
<cjwatson> that'll help the debian-installer build
<cjwatson> Ah, if you've scripted it, possibly best that I couldn't write to it directly.
<infinity> cjwatson: Regenerating now.
<cjwatson> pitti: I fixed the ordering in archive-reports a bit so that the chdist update is guaranteed to complete before precise_probs is generated, since you're relying on that now
<pitti> cjwatson: oh, thanks
<shnatsel> cjwatson: thanks again for your help on the doc about building large-scale derivatives! Really appreciated.
<cjwatson> glad it helped
<infinity> cjwatson: That look good?
<cjwatson> infinity: should be, I'll give d-i a shot again
<infinity> cjwatson: Was it just barfing because it expects a main/d-i component matching every line in sources.list?
<cjwatson> yep
<cjwatson> and it's easier to adjust the bootstrap archive for that than to filter it out in d-i
 * infinity nods.
<cjwatson> (and arguably less wrong)
<infinity> cjwatson: And... I broke my own Releases file somehow.
<cjwatson> wuh
<cjwatson>  e659416b35f5f28f15a677eaa8411ba5    1666282 main/binary-armhf/Packages
<cjwatson>  d41d8cd98f00b204e9800998ecf8427e  0 main/debian-installer/binary-armhf/Packages
<infinity> Yeah, wuh indeed.
<cjwatson> two missing spaces maybe?
<infinity> Maybe?  Is it that picky?
<cjwatson> oh, I see
<cjwatson> SHA256:
<cjwatson>  22a0ff9ffeb9ff014eec2543adeb78a71d810fd64969fbf4a24af4b94a71ed26    1666282 main/binary-armhf/Packages
<cjwatson>  e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  1666282 main/binary-armhf/Packages
<cjwatson> pretty sure that's not what you meant
<infinity> Oh, err.  Oops.
<infinity> Except, that shouldn't matter.
<infinity> Cause it's not checking the d-i bits...
<infinity> At that point.
<cjwatson> But it might well pick the last of two claimed distinct SHA256 sums for a given file.
<cjwatson> Which would make the checksum of main/binary-armhf/Packages incorrect.
<infinity> Oh.
<infinity> I missed the duplicate filename. :)
<infinity> la la la.
<cjwatson> Should reduce the build queue length really quickly, though.
<infinity> And how!
<infinity> You'd think lillypilly would be faster than my Panda for this.
<shnatsel> pitti: I came here to bug you about bug 899568, but you've approved the merge before I even pinged you ^^ Thanks!
<ubottu> Launchpad bug 899568 in gnome-session (Ubuntu) "gnome-session is registered in alternatives system by wrong package" [Undecided,Fix released] https://launchpad.net/bugs/899568
<infinity> I should have just hand-edited the Release file. :P
<infinity> (But wanted to make sure the script was right)
<pitti> shnatsel: heh :) thanks
<pitti> shnatsel: I also uploaded the package
<shnatsel> oh, that's why it's "fix released" already
<shnatsel> pitti: twice the thanks then! :D
<infinity> Oh, there's a germinate eating all my CPU.
<infinity> Kay, fixed.
<pitti> shnatsel: see /topic, I'm patch pilot ATM :)
<cjwatson> Maybe I'll convert update-germinate to something like the prospective Launchpad multi-germinate magic at some point.
<cjwatson> Although I think it spends a lot of its time writing out giant rdepends listings anyway ...
<infinity> cjwatson: That seems happier.
<infinity> cjwatson: And d-i is happy with the fake indexes. \o/
<infinity> .. and fails right after.
<infinity> Rather mysteriously and non-verbosely...
<cjwatson> Not a giant surprise.  (Is there a porter chroot around somewhere?  I was flying blind.)
<infinity> I don't think lamont's got one on scheat yet.
<infinity> You could ask nicely, now that precise/armhf is actually debootstrappable.
<infinity> There's a ticket for it.
<infinity> RT#49685
<cjwatson> Maybe it doesn't like empty Packages files or something
<infinity> You want some udebs in there for the lolz?
<infinity> I happen to have some.
<infinity> Though that sounds a lot like writing an actual apt-ftparchive config.
<lamont> infinity: it's debootstrappable now?
<infinity> Or, I could just generate a one-off.
<infinity> lamont: Should be.
<infinity> lamont: But please don't replace my buildd chroots. :P
<lamont> I shall attempt this
<cjwatson> infinity: It really ought not to need them.  It's a bug if it does.
<lamont> infinity: are they dirty dirty little chroots/
<infinity> lamont: Not really.  Not anymore. :P
<infinity> lamont: But still, I'll let you know when we're ready to swap them for scripted versions.
<cjwatson> infinity: In fact, I see where it might be.  I can test it once lamont's done. :-)
<infinity> lamont: porter chroot on scheat, however, would be lovely.
<cjwatson>                 grep-dctrl -! -rFKernel-Version . $KV_COND "$packages" > "$packages.tmp"
<cjwatson> ^- probably needs || true
<infinity> That seems likely.
<infinity> Shouldn't that fail on building against proposed/updates too?
<infinity> Or do we never rebuild against post-release pockets until we have new kernels? :P
<infinity> (ie: we get lucky)
<cjwatson> That's probably so.
<infinity> lamont: Oh, not to put undue pressure on you or anything, but Nafallo led me to believe that rescuing gourd and acorn would have to be a group effort between the two of you.  If you could make that happen, I'll love you forver (until the next time I want something).
<lamont> you are so ephermal that way
<Nafallo> infinity: only gourd.
<infinity> Nafallo: Oh, you can make acorn happy all by yourself?
<infinity> Nafallo: Even better.
<Nafallo> infinity: potentially.
<Nafallo> infinity, lamont: nvm. gourd is happy this time.
<Nafallo> lamont: ^-- cleanup of these two however.
<infinity> Nafallo: Oh, huzzah.
<infinity> adconrad@cocoplum:~$ suite-diff.py /srv/launchpad.net/ubuntu-archive/ubuntu/dists/precise/main/binary-arm*/Packages.gz gt | wc -l
<infinity> 243
<infinity> ^-- Getting there.
<lamont> nasl has 109
<infinity> Thanks.
<infinity> Can worry about the rest when we do the mass 110 rollout.
<infinity> Which will hopefully be after armel is done building several multi-day builds... :/
<infinity> In retrospect, stealing all the pandas for armhf may have been cruel.
<lamont> armel still has nasl... :)
<infinity> Yeah. ;)
<infinity> I gave it to armel when I realised it had an outdated lp-buildd.
<infinity> I'll leave it there for now.
<infinity> And maybe give them one more too.
<cjwatson> infinity: Better d-i uploaded now, though it'll dep-wait on a few u-boot-ish things that haven't been arwoofed yet.
<infinity> arwoofication incoming shortl.
<infinity> y
<infinity> lamont: Say, where's the 10th Panda?
<infinity> lamont: Oh, that's the one you asked Nafallo to wiggle cables on, right?
<lamont> altais hates us all
<infinity> Check.
<lamont> caph is the 11th though
<cjwatson> K observed (or possibly passed on an observation) this morning that Scotland now has more pandas than Tory MPs
<cjwatson> though that's a different kind of panda ...
<lamont> heka also hates us all
<lamont> cjwatson: heh
<infinity> adconrad@scheat:~$ dchroot -c precise-armhf
<infinity> (precise-armhf)I have no name!@scheat:~$
<infinity> Nice hostname. ;)
<lamont> I suspect it may be true for our kind of pandas, too
<lamont> infinity: I'm still building it, and your bits are clearly broken. :-p
<infinity> lamont: They are?
<lamont> infinity: please score libnss-db through the roof
<infinity> Oh, libnss-db.  Right.
<infinity> lamont: Err, it's built.
<infinity> lamont: 6 days ago.
<infinity> lamont: Which would explain why it's installed in the chroot. :P
<infinity> lamont: Any more simple requests?
<lamont> I just installed it manually :-p
<infinity> Sure, blame my archive for your script.
<infinity> I bet it was special-cased out for armhf by dannf.
<siretart> dholbach: thanks for the reminder, I can do that in a minute
<cjwatson> lamont: I don't suppose I could get RT#49745 (germinate/mawson) done too?  I have a dependency stack a mile deep for this and would like to start whittling it away. :-)
<cjwatson> Or is that a webops thing?
<mthaddon> nope, that's a GSA thing
<mthaddon> cjwatson: anyone in #canonical-sysadmin should be able to help
<mthaddon> actually...
<mthaddon> yeah, I'd better defer to the GSAs there
<cjwatson> k
<lag> A little help: My panel resets to default on reboot and I can't change my clock display settings (related?)
<infinity> doko_: Why the build-dep change for libproxy?
<doko_> mozjs not in main
<infinity> Ahh, didn't notice it getting dropped.  Fair enough.
<infinity> And after I put in a whole 5 minutes of effort to make it build, too.
<siretart> dholbach: done
<doko_> Daviey, what's the story about squid/squid3? I assume squid3 is used, but squid is still in the archive (and fails to upload for armhf). should it be removed?
<doko_> infinity, do you work on u-boot-linaro?
<chrisccoulson> pitti, you might like bug 900280 ;)
<ubottu> Launchpad bug 900280 in zarafa-drag-n-drop (Ubuntu) "Please remove source and binaries from Precise" [Undecided,New] https://launchpad.net/bugs/900280
<chrisccoulson> is there any way to blacklist all packages with pkg-mozext-maintainers as the maintainer?
<cjwatson> Not as yet.
<chrisccoulson> i feel like this is a game of cat and mouse every cycle now
<cjwatson> I thought I saw a bug for that earlier
<cjwatson> I mean for this batch of removals
<cjwatson> We may be able to do more fine-grained blacklisting once we have autosyncing moved over to the API, but that still has at least one blocking Launchpad bug in the way.
<chrisccoulson> oh, i did look and didn't see any
<cjwatson> chrisccoulson: bug 891484
<ubottu> Launchpad bug 891484 in uppity (Ubuntu) "Please remove these Firefox extensions binaries and source + blacklist" [Wishlist,Confirmed] https://launchpad.net/bugs/891484
<cjwatson> Overlapping set of packages.
<chrisccoulson> oh, it doesn't contain most of them, that's why i didn't see it
<infinity> doko_: I was going to get jcrigby to to the Linaro stuff, but if he doesn't have the time, I will.
<Daviey> doko_: fails to upload?  As in a Launchpad buildd issue?
<Daviey> doko_: squid is planned to still be in universe, with squid3 in main.  The was the last plan i heard.
<infinity> Daviey: Fail to upload usually means a package building a binary older than what's in the archive.
<Daviey> Ahhh, i'm going to bet there is a transitional package in squid3 causing this
<infinity> Daviey: In other words, if you want that source around, kick out the offending binaries that were replaced elsewhere.
<Daviey> infinity: thanks
<Daviey> doko_: I think squid can actually go, but i'd like to confirm with zul who was mostly handling the transition - i believe.
<cjwatson> That's what I understood to be the plan when I NEWed squid3, I think
<pitti> chrisccoulson: heh, yay cleanup
<pitti> debfx: ah, so your upload of step counteracts my upload of meta-kde :) so we can probably revert the latter
<doko_> Daviey, yes launchpad issue, both packages build the squid binary
<debfx> pitti: first let's see if it really builds ;)
<infinity> debfx: It builds in experimental on armel.
<infinity> debfx: I like our odds.
<cjwatson> doko_: Not a Launchpad issue in the sense that this isn't a Launchpad bug, though.
<debfx> infinity: Debian's Qt uses OpenGL on all architectures so that's no indication that it builds on Ubuntu
<infinity> debfx: Ahh.
<zul> squid can go
<infinity> debfx: https://launchpad.net/ubuntu/+source/step/4:4.7.3-0ubuntu2/+build/2986704
<infinity> debfx: Looks good.
<pitti> cjwatson, doko_: docbook5-xml is a newer version of docbook-xml, docbook-xsl b-deps on that now; just data files; I'd just promote it, or do you want a full MIR?
<infinity> pitti: step on armhf built.  Probably fair to assume armel will too.
<dholbach> siretart, thanks! :)
<doko_> pitti, sure
<pitti> superm1: can you please have a look at https://code.launchpad.net/~pitti/mythtv/font-rename/+merge/83047 ?
<Daviey> pitti: I believe it has landed, http://bazaar.launchpad.net/~mythbuntu/mythtv/mythtv-fixes/revision/450
<pitti> Daviey: oh, thanks; so apparently it wasn't "formally" merged, closing my MP then
<Daviey> pitti: I think it was proposed against lp:mythtv rather than, lp:~mythbuntu/mythtv/mythtv-fixes
<Daviey> pitti: So, i think Mario rebased, which is why it didn't auto close.
<pitti> Daviey: anyway, as long as it's fixed, I'm happy :)
<Daviey> \o/
<pitti> just wanted to prevent longer-term uninstallability
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> cjwatson: is there an easier trick to build britneymodul.so  than scp'ing the whole dir to local workstation, building there, and scp'ing back?
<pitti> (lillypilly doesn't have apt -dev stuff)
<infinity> pitti: My guess is that, until you started hacking on it, it hadn't been rebuilt in years. :P
<infinity> (But I could be wrong)
<pitti> 240522 2011-11-23 17:38 britneymodule.so
<pitti> not _that_ long ago :)
<infinity> I stand corrected. ;)
<infinity> Or sit.
<pitti> I'm ok with the rsync-twice dance, just wondered whether I'm missing something obvious
<infinity> You could be missing the part where Colin just has a local tree for it and builds and pushes in one direction.
<infinity> (again, guessing)
<pitti> probably that, yes
<pitti> kubuntu-meta 1.241 kubuntu-full (amd64) uninstallable
<pitti> I want to see why it's telling this lie
<pitti> ooh, I bet I know
<pitti> it depends on nvidia-current
<pitti> main -> restricted dependency
<infinity> Ew.
<pitti> well, recommends:
<infinity> So, not a lie.
<infinity> Or, that reports on recommends?
<pitti> and it sounds wrong, too -- this would break all non-nvidia systems
<infinity> Yeah...
<infinity> Need to get 1278 MB of archives.
<infinity> After this operation, 3399 MB of additional disk space will be used.
<infinity> Note to self: never actually install kubuntu-full.
<pitti> debfx, ScottK, Riddell: ok if I drop this: dvd: * (nvidia-current)
<pitti> debfx, ScottK, Riddell: it breaks non-nvidia systems (as it diverts libGL) and also is a main -> restricted dependency which counts as uninstallable
<debfx> pitti: yes and fglrx too
<pitti> debfx: thanks for confirming; seed updated, rebuilding -meta now
<doko_> Daviey, MIR for suds needed (pulled in by fence-agents, which looks serverish)
<debfx> pitti: what's the exact result of the image size debate this cycle? can each flavor decide if they want 750 MB images?
<pitti> debfx: I guess so; sabdfl said he was ok with 750 MB images, but for ubuntu itself we want to try and stick to 700 MB for precise
<Daviey> doko_: that is raised, isn't it?
<Daviey> doko_: bug 898268
<ubottu> Launchpad bug 898268 in suds (Ubuntu) "[MIR] suds" [Undecided,Incomplete] https://launchpad.net/bugs/898268
<doko_> Daviey, yes, but incomplete, and needed for armhf
<Daviey> doko_: ok
<debfx> pitti: so ubuntu desktop is sticking with the 700 MB as the default installation medium? would it be an option for kubuntu to have a 700MB cd image but use a 1.5 GB usb/dvd image as the default?
<pitti> debfx: I guess so
<debfx> ok, thanks
<jbicha> over 900,000 bugs!
<pitti> jamespage, jibel: do you see what's wrong in https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/lastFailedBuild/ or https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/lastFailedBuild/PROFILE=lts-server-amd64,label=upgrade-test/ ?
<pitti> for the first URL, I looked at the "ubuntu" profile
<pitti> I can't see any error in apt-term.log or main.log
<pitti> ooh, it's probably the tests after that
<pitti> console output has some stuff
<jamespage> pitti: it looks like something went wrong during the test to me "Connection to localhost closed by remote host...."
<jamespage> https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/lastFailedBuild/PROFILE=ubuntu,label=upgrade-test/console
<jibel> pitti, server doesn't restart after upgrade,  it can't find the rootfs anymore after the upgrade
<jibel> jamespage, ubuntu upgrade is fine, it just the status on the public jenkins that is not updated.
<jibel> jamespage, it failed last night because I tried to run 2 tests simultaneously on the same server but there was conflicting ports to communicate with the testbed.
<pitti> ah, thanks
<psusi> smoser: I've worked up some patches to util-linux now for the online resize support... including a simple wrapper command
<psusi> smoser: also an update mode to partx
<smoser> psusi, you're too kind.
<smoser> that is awesome.
<psusi> hehe
<smoser> do you have a bug for this ? or blueprint or something?
<psusi> it just dawned on me that is kind of the canonical reference implementation of the user side of the blkpg ioctls
<psusi> I filed a bug against the kernel and attached the patch asking that it be added, and I have proposed a branch of parted for merging
<smoser> bug number ?
<psusi> actually I also filed one to fix the loopback device to clean up partitions when you detach the backing file.  bugs #899717 and #899723
<ubottu> Launchpad bug 899723 in linux (Ubuntu) "[PATCH] Add partition resize function to BLKPG" [Medium,Triaged] https://launchpad.net/bugs/899723
<ubottu> Launchpad bug 899717 in linux (Ubuntu) "[PATCH] Loopback device partition cleanup on detach" [Medium,Triaged] https://launchpad.net/bugs/899717
<smoser> psusi, are/were you going to send util-linux upstream ?
<psusi> smoser: going to as soon as I finish a bit more testing
<psusi> smoser: but with these changes, you will either be able to run partx -u /dev/sda or respart /dev/sda start size
<psusi> smoser: after using sfisk to update of course
<cjwatson> pitti: it's annoying; I think I built it in a porter-amd64 chroot.
<psusi> so basically when sfdisk complains about BLKRRPART, just run partx -u and you're done
<cjwatson> [5~/wg 295
<cjwatson> gah
<Laney> impressive number of windows
<Daviey> or a really intelligent walking across the keyboard.
<l3on> cjwatson, hey! :) ... I'm looking at libparse-http-useragent-perl ... last entry in changelog says:
<l3on>   * Pre-Depends: dpkg (>= 1.15.6) for xz compression support.  Needed until
<l3on>     after Ubuntu 12.04 LTS.
<l3on> Do you think we still need it ?
<stgraber> l3on: that's needed for 10.04 => 12.04 upgrade IIRC
<psusi> xz is required anyhow
<stgraber> l3on: to force dpkg to upgrade itself first before trying that one
<psusi> dpkg pre-depends on it
<l3on> ah ok, cjwatson I can take it ? (last change has done by you)
<l3on> thanks stgraber and psusi  :)
<cjwatson> l3on: When I said we needed it until after 12.04 LTS, I meant it.  Please keep that change.
<cjwatson> psusi: You missed the point, I'm afraid.
<psusi> cjwatson: I figured that a moment later ;)
<cjwatson> l3on: If you dropped that change, then Launchpad would refuse to accept the upload of any binaries built from that package.
<cjwatson> l3on: I left that very specific note in the changelog so that people wouldn't need to ask when they could drop it.
<l3on> thanks cjwatson :)
<psusi> smoser: by the way, yesterday I played around with getting my desktop to boot without an initrd.. got boot time on my ssd down to just under 8 seconds from about 12... had to build the achi module into the kernel though, and of course, without the uuid kernel patch, the root= argument is fragile...
<cjwatson> l3on: You can take that merge if you like.
<l3on> I took :)
<smoser> yeah. thats cool.
<psusi> smoser: I was wondering about those cloud images... what vm are they running under?  qemu?  and when they boot, do they use grub, or just directly load the kernel?
<tedg> What's the default optimization level in Ubuntu?  -O2?
<smoser> psusi, they boot from grub. and will boot under kvm or xen (xen with pv-grub)
<smoser> https://help.ubuntu.com/community/UEC/Images#Ubuntu_Cloud_Guest_images_on_Local_Hypervisor_Natty_onward
<smoser> you can play with an image by following that.
<psusi> smoser: could probably shave off a bit more boot time skipping grub
<smoser> skipping ?
<psusi> I'm pretty sure qemu-kvm had a switch where yuo can pass it the kernel image to boot directly rather than have it load and execute the MBR in 16 bit mode
<smoser> psusi, yes, you can.
<smoser> and that is actually how uecalyptus loads... but then you have to deal with the host knowing the kernel parameters of the guest, and you can't (easily) update your guest kernel and reboot.
<smoser> so... grub makes lots of sense. timeout is zero on EC2 images, but we do have a 5 second (i think) timeout in the images by default. that could be addressed. the reason is to allow the user to get in if they're booting in kvm. thats less important now than it used to be, thoug. previously the only way you could reasonably use the image in kvm was to modify the command line parameters.
<psusi> true...
<doko_> bryceh, you did merge libdvdread, but didn't fix the ftbfs on amd64
<pitti> cjwatson: so kubuntu-full still pulls in sl-modem-daemon and bcmwl-kernel-source in the "dvd" seed, but these packages are in restricted
<pitti> cjwatson: this is what makes kubuntu-full uninstallable
<pitti> cjwatson: I don't think bcmwl should be in that metapackage, as the installer will automatically pull it, right?
<pitti> cjwatson: should these two perhaps go in to dvd-live?
<pitti> cjwatson: handled bcmwl, already in kubuntu's ship-live
<pitti> so I wonder what to do with sl-modem
<pitti> moving it to dvd-live would take it out of kubuntu-full and should fix the problem
<doko_> didrocks, please could you look at the unity-lens-files build failure on armhf? such a pkgconfig file doesn't exist. https://launchpadlibrarian.net/86366105/buildlog_ubuntu-precise-armhf.unity-lens-files_0.6.12-0ubuntu1_FAILEDTOBUILD.txt.gz
<doko_> should fail on intel too?
<jimbauwens> Anyone here that works on the Ubuntu installer?
<didrocks> doko_: yeah, we discusssed it with lool, the new zg doesn't contain it and it will be fixed in the next u-l-f upload
<doko_> didrocks, when about?
<didrocks> doko_: which is not there yet, but will happen at some point
<didrocks> doko_: next unity release, still under discussion when it will be
<doko_> didrocks, could it be fixed for the armhf bootstrap in the mean time?
<didrocks> doko_: I can distro-patch which is a little bit ackward for me right now, but if you need it urgentlyâ¦
<doko_> didrocks, not urgent, but then the gnome desktop would be complete :-)
<didrocks> doko_: will do it shortly then, if we can't release that week
<doko_> thanks
<ogra_> would surely speed us up in starting to build images
 * infinity picks up the librest FTBFS.
<didrocks> yw
 * ogra_ was glaring at that ... weird xml trash
<infinity> ogra_: Nah, it's just stuff trying to hit the internet.
<infinity> ogra_: Easy fix.
<ogra_> oh, i probably titnd scroll far enough up yet :)
<didrocks> ogra_: you have weird stuff to glare at :)
<ogra_> heh
<pitti> jamespage: FYI, fixing the python3-gobject NBS
<pitti> jamespage: and I'll commit the python-gobject-cairo bits into ubiquity/software-center bzr
<pitti> ah, ubiquity already has it
<pitti> mvo, tremolux: I can't commit to lp:software-center/5.0; can you please s/python-gobject-cairo/python-gi-cairo/ ?
<pitti> ok, really leaving now, good night!
<tremolux> pitti: hello! yep, will do
<tremolux> pitti: have a good night  :)
<jimbauwens> The ubuntu installer sets too big swap partitions on modern machines. The system will become quite unstable before it can even use the half of it.(for most applications)
<mvo> pitti: why for 5.0? does this need to go into oneiric?
<jimbauwens> Should I make a report on launchpad about this?
<jimbauwens> s/sets/creates/
<doko_> cjwatson, infinity: is there an easy way to look for packages in main, which are not yet built on armhf? promoted packages keep their low build score, and starve to build ...
<tremolux> pitti: if you are still around, about your request, seems you mean for us to change the dep in trunk, no in the 5.0 (Oneiric) branch, correct?
<seb128> tremolux, he left it seems but yes, that's for precise only
<seb128> tremolux, the renaming didn't happen in oneiric ;-)
<tremolux> seb128: yep, thanks for confirming!  :)
<cjwatson> pitti: dvd-live has a confusing name - that's analogous to live (i.e. on the live filesystem) rather than to ship-live (i.e. in a pool alongside the live filesystem)
<cjwatson> pitti: we could abuse or rename dvd-live-langsupport, if it's not suitable for ship-live ...
<cjwatson> doko_: I guess this is what quinn-diff is for, although I don't know if anyone runs it for Ubuntu
<cjwatson> doko_: shame the build queue doesn't seem to be exposed in the API
<doko> Laney, https://launchpadlibrarian.net/86705706/buildlog_ubuntu-precise-armhf.gnome-desktop-sharp2_2.26.0-6_FAILEDTOBUILD.txt.gz
<infinity> I'll never understand why people think it's sane to patch *after* you autoreconf.
<Laney> infinity: it's a legacy ltmain.sh --as-needed patch
<Laney> doko: thanks, I'll just replace it with dh_autoreconf
<lifeless> I have a q about apt & debtags: do the tags need to be in the packages file, or is there a lookaside file that can be used ?
<broder> i didn't think debtags were published in the main archive at al
<lifeless> they are not currently
<broder> oh, is that changing?
<lifeless> What I want to know is where apt etc look for them today
<lifeless> software centre would like them published; we're trying to see what can be done
<tumbleweed> on debian, they are in Packages
<Laney> doko: uploaded, sync when LP knows about -7
<Laney> or I will
<enrico> lifeless: apt looks for them in the Packages file; software-centre uses apt-xapian-index for searches, and apt-xapian-index can be fed using plugins
<enrico> lifeless: however, I'm not sure what software-centre does for visualization of tag data
<lifeless> enrico: doesn't today as they aren't published
<enrico> lifeless: tags can be extracted from apt-xapian-index rather easily
<lifeless> enrico: so apt can't use a lookaside file ?
<enrico> lifeless: a-x-i can read them from /var/lib/debtags/package-tags using its debtags.py plugin, for example
<enrico> lifeless: apt can't use a lookaside file afaik
<enrico> lifeless: for the record, the procedure to extract them from a-x-i is to look for all terms starting with 'XT' in a document
<enrico> lifeless: the document can be looked up searching the term 'XPpackagename'
<lifeless> https://dev.launchpad.net/LEP/DebTags
<lifeless> that lep talks about using a separate file
<lifeless> I guess based on this discussion that that is science fiction?
<enrico> lifeless: I don't know APT or software-centre's code enough to be able to tell, I recon you'd have to talk to the respective authors
<enrico> lifeless: tags don't change that often, so pdiffs would have little size difference with/without tags
<enrico> lifeless: but I'm more the right person for tag algorithms, or for setting up tag feeds from Debian to Ubuntu and vice versa, for example, rather than for apt or software-centre work
<slangasek> I don't believe Ubuntu is currently doing pdiffs at all, though
<slangasek> or is that part of the proposal?
<lifeless> its not
<enrico> slangasek: it's not. Sorry for mentioning them, I didn't know Ubuntu wasn't doing them
<lifeless> the question revolves around the cost of change for the publisher
<slangasek> yes, we'd like faster publishing, not slower, please ;)
<lifeless> adding in a new table, API's to maintain it, and retuning the publisher to snarf the additional data is a bit of work
<lifeless> doing an async snarf-and-emit of a tag set to a separate unsigned file would have less impact and be easier I suspect
<lifeless> the more we shove into the publisher the tighter the critical section is
<iamfuzz> any openssl gurus about?  I'm having some linkage troubles
<Ampelbein> iamfuzz: Might be useful to include such things as error message, linker command etc ;-)
<iamfuzz> Ampelbein, http://pastebin.com/dNNw98sf
<iamfuzz> :-)
<iamfuzz> it's a strange thing. It never happened against 0.9.8
<iamfuzz> but the symbols ARE  present in libcrypto.a
<iamfuzz> and -lcrypto is being passed
<cjwatson> link order matters
<Ampelbein> iamfuzz: objects go before libs
<cjwatson> you need to put -l<foo> after anything that uses symbols from it
<roadmr> foo :)
<cjwatson> this isn't an OpenSSL change; but more recent Ubuntu versions are stricter about this
<cjwatson> http://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries
<iamfuzz> cjwatson, ah ok, I'll switch the order around and see if I can sort it out
<iamfuzz> the libs are needed
<cjwatson> indeed, but the purpose of this linker change was to allow us to drop DT_NEEDED entries for libraries that weren't needed
<cjwatson> https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition also
<cjwatson> essentially the linker used to be doing loads of extra work both at build time and at run time to support people linking things backwards :-)
<iamfuzz> cjwatson, but it allowed people like me to be lazy!
<cjwatson> that's nice, but. :-)
<iamfuzz> ;-)
<iamfuzz> cjwatson, many thanks, that's all it was
<psusi> hrm... it appears that util-linux isn't using a patch system.. so if I cherry pick an upstream commit and commit it in bzr, won't that cause a conflict on future merge that will be a pita to resolve?
<infinity> psusi: Don't really care if it's in bzr or not.
<roadmr> Hi, SRU versioning question! I want to SRU some changes to checkbox 0.12.8, what should the new version number be? is 0.12.8ubuntu1 OK? (trunk has moved on and is now at 0.13, my changes are cherry-picked from that)
<infinity> psusi: But converting it to 3.0 (quilt) is on my todo.
<infinity> psusi: When I can sneak it past lamont. ;)
<broder> roadmr: i probably wouldn't introduce an "ubuntu" component since there wasn't one there before. i think i would pick something like 0.12.8.1
<roadmr> broder: oh that looks nicer
<infinity> Err.
<infinity> No.
<stgraber> roadmr: I usually use the example from https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging as they cover most use cases. So based on that it should be 0.12.8ubuntu0.1, but as broder said, as your package is native to Ubuntu and not Debian, just adding .1 is probably fine
<infinity> Oh, if it's Ubuntu-native, then yeah.  No ubuntu needed.
<roadmr> stgraber: yep, that's the example I'm looking at
<stgraber> infinity: yeah, checkbox is one of these weird ubuntu-native packages that's not a meta package :)
<infinity> stgraber: One of the three? ;)
<roadmr> infinity: yep, native (i.e. we're the upstream anyway) - but I don't think I can do a "microrelease" as our 0.12 branch is up to 0.12.11 and has some non-sruable changes
<roadmr> infinity: so ubuntu's 0.12.9 would be different from upstream's 0.12.9 (feels wrong)
<infinity> roadmr: Right, that would be wrong.
<infinity> roadmr: 0.12.8.1 is fine.
<broder> that being said, it's pretty weird that checkbox is versioned as debian/ubuntu-native
<infinity> If it has "upstream" releases, it shouldn't be natively-packaged, no.
<infinity> But fixing that in an SRU is also wrong. :P
<broder> agreed :)
<stgraber> yeah, checkbox really should split its packaging out of the upstream branch, actually make proper release tarball and have a nice -0ubuntuX version number like the rest of the world
<stgraber> but I know I've already been complaining a few times about it (every time I have to review/sponsor it) without much changing so far...
<roadmr> stgraber: sorry, I'll try to have a look at the versioning for this cycle, I'm just getting acquainted with how versioning works
<infinity> stgraber: Offer to maintain it in Debian, but only if you can have shiny upstream tarballs?
<roadmr> Oooo, checkbox in debian!
<infinity> Original-Maintainer: Marc Tardif <marc@ubuntu.com>
<infinity> I take it back.
<stgraber> roadmr: that'd be great if you could fix that this cycle indeed. Would make packaging by other distros much easier and also make reviewing/sponsoring easier because you'd be like the rest of the world :)
<roadmr> stgraber: but we want to be different, just like everyone else :P
<infinity> Well, "other distros" won't happen unless it has pluggable backends or something, I suspect.
<roadmr> stgraber: hehe no, seriously, I'll definitely have a look
<broder> i thought the LP-submission was the only thing ubuntu-specific
<broder> i'm using checkbox at work and just tore that out :)
<stgraber> infinity: I thought checkbox was all about flexibility and you just need something parsing/pushing the xml output
<infinity> stgraber: Maybe.  I've never looked at the code. ;)
<roadmr> stgraber, broder, infinity: I'll go with 0.12.8.1 then, and I'll look into versioning / debianizing things too. Thanks!
<broder> roadmr: sounds awesome :-D
<lamont> infinity: util-linux will not implement a VCS in the source package.  and that's all 3.0 (quilt) is
<lamont> infinity: :-p
<infinity> lamont: Yeah, yeah.
<infinity> lamont: Give me write access to git, then. :P
<psusi> lamont: so if I make changes, just make them directly?  won't that cause a conflict when merging the same change from upstream later though?
<infinity> psusi: Not if it's identical to an upstream commit, no.
<psusi> right, but if there is the slightest little difference...
<infinity> Then there's a conflict.  We're smart people.
<infinity> Ish.
<psusi> hrm... trying to figure out how to effectively deal with that... I mean, as far as I know, you can't see ohh, local commit foo and remote commit foo are the problem... they look the same, so drop local foo, the way you can with quilt patches
<infinity> Of course you can.
<lamont> psusi: it's doable.  sometimes it sucks, but mostly it's not so bad
<infinity> psusi: We import your change as a revision in git.  We merge upstream git.  Conflict.  Resolve.  It's obvious which was from where.
<psusi> how?  I mean, bzr just tells you there's a conflict, go fix it.. but not the conflict is between local commit foo, and remote commit bar
<infinity> psusi: (Granted, it's even better if you just tell lamont which upstream commit you want, and he can cherry-pick the actual commit)
<infinity> psusi: Cause then that will retain ancestry and auto-resolve its own damned self.
<psusi> it's not committed yet, just posted to the ml today :)
<infinity> Ahh. ;)
<dr3mro> hello , I am trying to create a ppa for daily build of a project i am not the owner of it hosted on google code but it fails when i enter the repository address in launchpad https://code.google.com/p/plowshare
<micahg> dr3mro: you probably #launchpad for recipe help
<micahg> * want
<htorque> bdmurray: hi! about bug 899683 - are you sure it should be a dupe of the no space left master bug?
<ubottu> Launchpad bug 220961 in ubiquity (Ubuntu) "duplicate for #899683 [MASTER] ubiquity crashes instead of notifying the user of not enough disk space" [High,Triaged] https://launchpad.net/bugs/220961
<htorque> bdmurray: i installed oneiric a couple of times with the same settings during the last six months, now precise fails with that weird partition sizes.
<bdmurray> htorque: nope, I'll fix it
<slangasek> cjwatson: hi, question on bug #771372
<ubottu> Launchpad bug 771372 in procps (Ubuntu Oneiric) "procps runs too early in the boot process" [Medium,Fix committed] https://launchpad.net/bugs/771372
<slangasek> cjwatson: why does this only show up when the installer is upgrading the package, vs. initial install?
<slangasek> cjwatson: i.e., is there an installer bug there too, which causes diversions to be removed between the install and upgrade bits?
<slangasek> hmm, looks like debootstrap diverts initctl, after which it's restored
<cjwatson> slangasek: Possible, but fixing that in a stable release seems even sketchier ...
<cjwatson> chroot-setup.sh is supposed to divert initctl too
<slangasek> right; I'm not proposing fixing that in a stable release, but I want to understand what's actually happening here - and make sure the bugs get fixed for precise if need be
<bdmurray> htorque: could you elaborate regarding what you choose when partitiioning?
<htorque> bdmurray: the default "erase all and use whole disk"
<cjwatson> slangasek: There is something odd there, indeed.  I don't quite see what; visually, the code seems right
<slangasek> cjwatson: should I raise a bug on debian-installer?
<cjwatson> slangasek: yes please
<slangasek> ok
<cjwatson> (probably belongs on either pkgsel or debian-installer-utils, but debian-installer is the place to start)
<robert_ancell> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell
<slangasek> cjwatson: bug #900526
<ubottu> Launchpad bug 900526 in debian-installer (Ubuntu Precise) "d-i fails to divert initctl when upgrading packages during install" [High,New] https://launchpad.net/bugs/900526
<cjwatson> thanks
<cjwatson> incidentally, it's not technically impossible to fix post-release, just difficult to ensure that the fix goes everywhere relevant ...
<slangasek> cjwatson: right :)
<slangasek> oh heh; I've just realized that the procps change that was being SRUed is broken on lucid/maverick/natty anyway.  Guess I'll rescind that
#ubuntu-devel 2011-12-06
<micahg> infinity: any idea why my armhf failures seem to automatically get retried?
<chihchun> hi there, anyone how the ubuntu-core been created? is it done by debootstrap?
<stgraber> chihchun: I'm not really familiar with core but I'd say it's likely live-build and the logs also point in that direction http://people.canonical.com/~ubuntu-archive/livefs-build-logs/precise/ubuntu-core/20111205/livecd-20111205-i386.out
<chihchun> stgraber: thanks
<pitti> good morning
<pitti> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html -> YIPPIE!
<pitti> jamespage, wendar: ^
<wendar> pitti: huzzah! :)
<pitti> tremolux: I meant trunk, but that's what Vcs-Bzr: points to, so I thought that would be the current branch
<pitti> cjwatson: ah, so it won't actually work in dvd-live as restricted stuff can't go into the live system
<pitti> cjwatson: hm, I'm still confused; dvd-live depends on dvd-live-langsupport, so would that actually change anything?
<YokoZar> Do we have an automatically generated list of non-multiarched libraries somewhere?
<pitti> YokoZar: I think grepping Contents.gz for /usr/lib/lib.*\.so ought to produce something like that
<pitti> I'm not aware of a more automatic tracker
<pitti> wendar: thanks for the libsoup2.4 multiarch patch!
<pitti> wendar: BTW, I can just apply them in Debian and then sync, so no need for an intermediate ubuntu upload
<wendar> pitti: you're welcome
<wendar> pitti: yes, I only did a straight Debian patch, didn't bother with anything Ubuntu-specific
<infinity> micahg: And by "automatically", you mean lots of people are watching it like hawks and retrying things here and there?
<micahg> infinity: that could be :), I just know as soon as I get it, when I click, the log isn't there :)
<micahg> pitti: is there a reason we got postgresql-8.4 back in precise?
<infinity> Nostalgia, I'm guessing.
<micahg> heh
<infinity> But more realistically, I bet it has to do with LTS->LTS upgrades.
<infinity> psql is known for unfortunately needing binaries from old version to do DB converdsions, and other pain.
<micahg> :(
<infinity> (But that's my guess)
<infinity> micahg: Err, to be fair, it never went away...
<infinity> postgresql-8.4 |    8.4.8-2 | oneiric/universe | source, amd64, armel, i386, powerpc
<infinity> micahg: So, not sure about the "getting it back".
<micahg> infinity: ah, just not getting updates, wonderful :)
<micahg> pitti: nevermind, rmadison output was larger than my terminal :)
 * infinity starts a local build of libreoffice to find the 13-hour-in failure. >:(
<micahg> infinity: I'm excited that I should be able to cross-compile chromium now :)
<pitti> micahg: I do intend to drop it, but so far it never left precise
<pitti> micahg: still need to fix/drop a couple of rdepends
<pitti> micahg: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=psql-8.4-deprecation;users=mpitt@debian.org FYI
<pitti> but we additionally have glom and another package
<micahg> pitti: right, infinity pointed that out to me, I just saw lucid-maverick w/security updates, then precise, so it looked like it was missing from oneiric, I didn't realize that it just dropped to universe
<pitti> infinity: nope, we don't need 8.4 in precise for upgrading from it
<infinity> pitti: Yay.
<pitti> I fully intent to ship both precise and the next debian stable with 9.1 only
<infinity> pitti: Was just a guess based on micahg's question, which was based on misinformation. ;)
<micahg> pitti: heh, I've got a list myself of things I'd like gone from the next release, unfortunately, I'm not the maintainer of any of them :)
<infinity> Is python on that list?
<micahg> oh, I was wondering why python2.6 was still around
<infinity> I meant python*
<micahg> infinity: I don't think that's possible in Ubuntu :)
<infinity> I'm going to try.
<infinity> I'll call my derviative Perlbuntu.
<micahg> so far I have, sqlite2, wxwidgets2.6, yada
<pitti> hm, http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html is clearly boring
<broder> pitti: time to start running it on universe! :)
<infinity> pitti: testing-ports seems like a fat lie, though..
<infinity> pitti: Shouldn't I at least see all the openoffice* packages as uninstallable on armhf?  Since, like, there's no libreoffice yet.
<infinity> ... except that they're in universe... Didn't we fix that?
<infinity> pitti: Didn't we promote openoffice* transitional stuff once this cycle? :P
<pitti> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html -> there, that's better
<micahg> hehe
<pitti> infinity: let me check about -ports
<infinity> pitti: It's not a problem with ports, it's a problem with openoffice-* being in universe.
<infinity> pitti: When it needs to be in main for the upgrade.
<pitti> infinity: you mean s/armhf/armel/?
<pitti> there's nothing to upgrade _from_ for armhf
<infinity> pitti: Err, It's in universe for everyone!
<infinity> openoffice.org-calc | 1:3.3.0-7ubuntu5 | precise/universe | all
<infinity> For instance.
<pitti> right
<pitti> I'll go seed it
<infinity> I could have sworn I seeded the whole source package at UDS.
<pitti> openoffice.org | 1:3.3.0-7ubuntu5 |       precise | source, all
<pitti> seems only parts of it are in universe
<infinity> Maybe I just asked someone else to fix the seeds cause my laptop was dead. :P
<pitti> infinity: did you touch ubuntu or platform seeds? there's nothing like that in ubuntu
<infinity> pitti: Like I said, I think I just asked someone else to do it.  Obviously a mistake. ;)
<pitti> ok, will seed the bits
<infinity> pitti: But it should be in platform/supported-desktop, IMO.
<infinity> There needs to be a platform/supported-upgrade-cruft
<pitti> hm, we already have "transitional packages" for OO.o in ubuntu/supported
<pitti> but I don't mind much where it lives
<infinity> pitti: Or there, I suppose.  But it's obviously missing some. :P
<infinity> Should probably just be an all-source stanza.
<pitti> I think some OO.o bits were in universe in the past
<infinity> Oh, not quite.  Yeah.
<infinity> Ugh.
<pitti> extra styles, mysql connector, and what not
<infinity> Why do we do this to ourselves? :P
<pitti> well, we can drop the whole oo.o thing after precise, so that pain is finite at least
<micahg> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: micahg, robert_ancell
 * slangasek checks his clock and gives micahg a funny loouk
<infinity> slangasek: Hey, no funny looks.  I just woke up an hour ago.
<infinity> DON'T JUDGE US.
<micahg> heh
<pitti> m -s lucid $(m -s precise -S openoffice.org | grep universe | cut -f1 -d'|') | grep -v universe
<pitti> infinity: ^ I think these are the ones we need, seeding now
<micahg> infinity: I think you're more rested than I am ATM then :)
<infinity> What happens in your world when you have more than 26 commands to run?
<pitti> except -galaxy which we deliberately dropped
 * micahg wonders if the shell can handle accented keys
<pitti> infinity: seeded; let's see how precise_probs explodes under us now
<jamespage> pitti: thats great
<pitti> jamespage: good morning
<pitti> jamespage: what do you want to tackle today?
<pitti> jamespage: right now I thought about killing some NBS, starting with libgail-3-common and the poppler transition
<pitti> help with the latter is greatly appreciated, of course, but there's enough fodder in there
<pitti> jamespage: v8 is almost gone, just one rdep left; nice work on libv8!
<jamespage> pitti: v8 will disappear once nodejs builds (this morning)
<micahg> broder: is there a reason you didn't use Pre-Depends: ${misc:Pre-Depends} instead of Pre-Depends: multiarch-support (needs compat level 9 IIRC)
<micahg> broder: sorry, this was for libsigc++-2.0
<micahg> broder: same on glibmm2.4
 * micahg guesses robert_ancell is done piloting
* micahg changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: micahg
<pitti> err, how about I actually _promote_ the oo.o-* transitionals instead of just seeding them
<pitti> apw: is user-mode-linux something we want to keep around? is it still maintained?
<pitti> apw: it's the only remaining reverse dependency of linux-source-3.0.0 which isn't built any more
<slangasek> hallyn: did you test the full qemu-linaro build using this 'dh_install --sourcedir' override?  I'm getting a very strange build failure that I'm struggling to make sense of
<slangasek> hallyn: ah, the .install looks for usr/bin/qemu-spice which doesn't exist
<doko> Sweetshark, libreoffice build failure on armhf, in testtools
<dholbach> good morning
<jelmer> moin dholbach
<dholbach> hey jelmer
<dholbach> jelmer, how are you doing?
<wendar> doko: I'm running across several packages FTBFS with errors like "libemosR64.so: undefined reference to `sqrtq'"
<doko> wendar, pointers to the build logs?
<wendar> https://launchpadlibrarian.net/86672854/buildlog_ubuntu-precise-i386.code-saturne_2.1.0-3_FAILEDTOBUILD.txt.gz
<wendar> is one
<broder> micahg: to avoid having to bump the debhelper dependency
<micahg> broder: is there a reason not to?
 * broder shrugs
<broder> i was trying to avoid being overly invasive
<wendar> doko: another is hidden behind  AC_CHECK_LIB, so doesn't show in the build log, but shows in the config.log
<micahg> broder: that's a good point
<broder> and i didn't really see pre-depends: multiarch-support as any less elegant than pre-depends: ${misc:Pre-Depends}
<doko> wendar: --no-add-needed, libmei.so not linked with libm
<micahg> broder: well, it makes so that Pre-Depends: multiarch-support being killed in a single place with no-change rebuilds, ISTR a discussion somewhere about this
<broder> micahg: hmm, ok. i hadn't seen that
<micahg> broder: or semi-magically when people update their packages, it'll just disappear when it's no longer necessary
<wendar> doko: so lingering as-needed problems?
<doko> wendar, no, no-add-needed
<broder> micahg: i'll take another look at some other time. -> sleep for now
<pitti> infinity: ah, there we go: http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
<wendar> doko: is there a difference in the default on no-add-needed between Debian and Ubuntu anymore?
<micahg> wendar: if it's GTK based, this change prompted it http://mail.gnome.org/archives/desktop-devel-list/2011-August/msg00236.html
<micahg> slangasek: should we push Pre-Depends: ${misc:Pre-Depends} usage in multiarch conversions, or should I take stuff with Pre-Depends: multiarch-support
<wendar> micahg: not gtk but does use libpng12, so may be relevant
<pitti> infinity: but testing-ports is still broken, there's a ton of armhf/powerpc stuff in ./update_out/check_out.py data/precise; investigating..
<pitti> oo.o fix uploaded
<doko> wendar, no, there shouldn't. but hmm, this is a convenience lib, and the order of -lm and libmei.so is wrong too.
<wendar> doko: asking because magics++ (the one I'm working on at the moment with this problem) only has the problem on Ubuntu
<wendar> doko: on sid, it has no errors about undefined references, and builds fine
<doko> wendar, I only see magics++ failing because of monkey patching
<pitti> infinity: http://people.canonical.com/~ubuntu-archive/testing-ports/precise_probs.html -> that's more like it
<pitti> seems powerpc finally caught up
<infinity> doko: I'm doing a local build of libreoffice to see if I can find the issue.
<infinity> pitti: Hrm, the gcc-multilib stuff looks suspect.  Looking into it.
<doko> infinity, it's most likely the uno bridge code
<doko> Sweetshark, ^^^
<infinity> pitti: Oh, multilib is the victim of overzealous demotion (or bad binary NEWing)...
<pitti> wendar: perhaps you can try without this manually applied no-as-needed patch?
<pitti> infinity: c-m doesn't take armhf into account yet?
<pitti> well, the code says it does
<pitti> but it might be broken, of course
<infinity> pitti: It might be broken.  Given that gcc-4.6-multilib is in main, but c-m wants to demote libc6-armel.
<wendar> pitti: at the moment I'm working with the raw upstream sources, to minimize interference from the patches
<doko> infinity, pitti, afaik, cjwatson did disable component-mismatches for armel
<doko> armhf
<infinity> Perhaps we should fix that now that almost all of main is built. :P
<pitti>         for arch in [ "i386", "amd64", "powerpc", "armel", "armhf" ]:
<pitti> hmm
 * pitti checks on lillypilly
<pitti> no bzr diff
<infinity> ubuntu-archive@lillypilly:~/ubuntu-archive-tools$ grep armel component-mismatches  for arch in [ "i386", "amd64", "powerpc", "armel", "armhf" ]: for arch in [ "i386", "amd64", "powerpc", "armel" ]:
<pitti> infinity: the second one is for seeds
<pitti> but let's add armhf there as well now
<pitti>  o libc6-armel libc6-dev-armel                                        {eglibc}
<pitti> ^ from c-m
<infinity> I'm going to pre-emptively promote everything.
<pitti> infinity: I suppose these should stay, too?
<infinity> pitti: Yeah, which is wrong. :P
<infinity> pitti: Those should stay in main, yes.
<pitti> infinity: c-m armhf added for germinate, and rolled out
<cjwatson> pitti: oh, sorry, for Kubuntu it's just 'dvd' that goes on the pool on the DVD, apparently.  I always have to look this up in cdimage list-seeds ...
<cjwatson> infinity: yeah, I disabled it because at the time it made c-m explode insanely
<infinity> pitti: Alright, libsf* promoted.
<infinity> cjwatson: Makes sense.
<infinity> I guess I should let gcc-4.4 and gcc-4.5 build and clear those out of the list.
<cjwatson> having only Arch: all and not anything else confuses the bejesus out of germinate, it turns out
<cjwatson> and it starts picking random things that provide something kind of similar
<infinity> cjwatson: hahaha.
<doko> infinity, wait with gcc-4.5/gcj-4.5
<infinity> doko: ?
<doko> new packages underway
<infinity> Kay.
<infinity> So gcc-4.4, then.
<infinity> doko: Did you snag the linker patches from gc[cj]-4.[45] and push them to Debian?
<doko> infinity, yes
<infinity> \o/
<infinity> Hey, armel's almost caught up from the weekend pain we put it through.
<infinity> I can steal buildds back for armhf again!
<wendar> michag: so, -lm was on the right track, but also needed -lquadmath and -lgfortran
<seb128> is there anything that needs to be done when a conffile is moved to another binary (but keeps the same location)?
<seb128> bug #900515
<ubottu> Launchpad bug 900515 in evince (Ubuntu) "evince-common conflicts with old evince package" [Undecided,New] https://launchpad.net/bugs/900515
<seb128> the conffile was in "evince" in lucid and is in "evince-common" in precise
<seb128> is a Replaces enough?
<seb128> the dpkg-maintscript-helper documentation doesn't cover that case nor does http://wiki.debian.org/DpkgConffileHandling
<pitti> it should at least be enough to fix the upgrade conflict
<pitti> but it should be verified that the ownership of the conffile indeed goes to the new package
<seb128> I will try that to start and see how it goes
<pitti> and what happens if it is modified
<seb128> if somebody tells me that it needs extra tweaking I can do those later on
<seb128> pitti, dpkg -S /etc/apparmor.d/abstractions/evince is enough to know what claims to own the file right?
<pitti> seb128: right
<pitti> seb128: dpkg -s <package> also shows confflies and obsolete conffiles
<seb128> let me try locally to move it to evince in the current version and see how it goes
<pitti> infinity: ah, eglibc -armel binaries fell off http://people.canonical.com/~ubuntu-archive/component-mismatches.txt; good
<infinity> pitti: Which means it also got the sf stuff right, cause I promoted those in this last run.
<pitti> and non-ports is once again empty, seems oo.o is happy enough now
<pitti> testing-ports is pretty much the LibO FTBFS now
<pitti> the gc{c,j} stuff is just catch-up with builds
<infinity> pitti: Time to start tackling outdate.txt? ;)
<pitti> yep
<pitti> infinity: hacking at NBS now
<pitti> (which is a subset of outdate)
 * infinity nods.
<pitti> jamespage and I are attacking NBS, wendar is looking into FTBFS
<apw> pitti, that is an interesting question as it is clearly recently updated if it has a dep on -3.0.0 source, as that only appeared in oneiric
 * pitti sees his 4 cores glow with building jigabytes of poppler rdepends
<infinity> seb128: Replaces is all you need to move a conffile.
<doko> infinity, pitti: testing a fix for the libreoffice ftbfs
<infinity> doko: \o/
<infinity> doko: Does that mean I can kill the build on my panda?
<doko> infinity, if it's an unmodified build, yes
<infinity> doko: It is, yeah.  I was building to get to the failure, then I was going to dig.  if you're one it, I'll stop. :P
<robert_ancell> @pilot off
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<robert_ancell> @pilot out
<pitti> apw: linux-headers-omap4 and linux-image-omap4 still depend on the old linux 3.0.0 omap packages; does the -meta package need a bump there?
<pitti> apw: oh wait, our current linux doesn't even seem to build an -omap4 flavor?
<apw> pitti, right omap4 is out of another source package, and is being worked right now in my other ear
<ogra_> hmm, i knew ppisati moved, i didnt know he moved into apw 's other ear though
<ogra_> not much space in there ... is there ?
<ogra_> (but probably a nice view)
<micahg> doko: could adding LDFLAGS upstream fix a linking issue with no-add-needed? context is bug 899315, https://launchpadlibrarian.net/86640020/ebtables.debdiff, http://ebtables.cvs.sourceforge.net/viewvc/ebtables/ebtables2/userspace/ebtables2/ChangeLog?view=markup, and http://ebtables.cvs.sourceforge.net/viewvc/ebtables/ebtables2/userspace/ebtables2/Makefile?r1=1.60&r2=1.61
<ubottu> Launchpad bug 899315 in ebtables (Ubuntu) "ebtables crashed with SIGSEGV in ebt_initialize_entry()" [Medium,Confirmed] https://launchpad.net/bugs/899315
<doko> Sweetshark, infinity, pitti: testing http://paste.ubuntu.com/761459/
<apw> ppisati, when you have ti-omap4 'fixed' i can probabally test it, so push it up somewhere i an grab it
<seb128> doko, could you give a bit extra context on the intltool issue you fixed? do you plan to open a bug about it?
<Sweetshark> doko: dont waste too much time on 3.4 for precise as we will ship 3.5 and it has been completely mostly rewritten there anyway: http://cgit.freedesktop.org/libreoffice/core/tree/bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.cxx
<doko> Sweetshark, yes, just running this build to see if it fixes the build
<doko> when do you expect 3.5 in the archive?
<doko> micahg, the upstream Makefile still lists the libs before the objects
<doko> micahg, is this still the case in the ubuntu package?
<Sweetshark> doko: branchoff is about right now
<doko> the LD change seems to be a no-op
<doko> micahg, please use dpkg-buildflags
<doko> Sweetshark, when do you expect 3.5 in the archive?
<Sweetshark> doko: ah, forget that: I got it wrong -- its uno2cpp and not cpp2uno which is pretty much unchanged. so yes, I would be still interested if that builds.
<Sweetshark> doko: the beta will be there before christmas.
<doko> Sweetshark, maybe ask caolan if he already had to build on armhf
<Sweetshark> doko: will do
<seb128> doko, hey?
<pitti_> jamespage: FYI, I'm now through all libpoppler13 rdepends except karbon and luatex, which you were looking into
<pitti_> james_w: pdftoipe is FTBFS due to a missing poppler-dev dep (not sure yet), seb128 is looking into this
<pitti_> sorry, jamespage ^
<pitti_> james_w: unping, tab failure, sorry
<seb128> pitti_, I've uploaded the fix, should be good to retry soon
<pitti_> seb128: oh, cheers
<pitti_> seb128: my colo hoster shut down, don't get mail right now
<doko> seb128, ?
<seb128> doko, could you give a bit extra context on the intltool issue you fixed? do you plan to open a bug about it?
<doko> seb128, see the exo build failure on armhf
<pitti_> jamespage: oh, and cups, which is still on my plate
<pitti_> jamespage: starting with the libpoppler-glib6 rdepends now
<seb128> doko, it would be nice if you could at least open a bug in such cases, or give a pointer to the issue in the changelog entry so other can understand why we have a diff in Ubuntu and get it fixed upstream or in Debian
<micahg> doko: I didn't try to fix the issue yet, but was wondering if the new upstream release would help, I guess not (there were some other changes to the Makefile: http://ebtables.cvs.sourceforge.net/viewvc/ebtables/ebtables2/userspace/ebtables2/Makefile?revision=1.67&view=markup seems to be the latest upstream), we don't seem to be patching it at all for , but it seems to build happily, oops I mean no-as-needed before
<micahg> , I guess I can try to patch the makefile to work properly or maybe I'll just leave a note in the bug to patch the make file rather than disabling --as-needed
<micahg> *for --as-needed
<seb128> doko, can you open a bug against intltool? danilo and dobey are upstream and they maintain it on launchpad, launchpad.net/intltool
<doko> dobey: ^^^
<doko> micahg, I would fix the linker order first, before reverting to no-as-needed
<doko> not that you should link with -lc explicitly
<micahg> doko: -lc is upstream craziness :)
 * micahg leaves a comment on the bug
<seb128> doko, no, dumping an hack this way with an IRC ping is not the way to work, please open a bug on launchpad explaining the issue and your fix
<seb128> doko: by doing workaround this way and not sending back the issue where it should you create a diff in ubuntu we need to maintain for no reason and work for other people
<doko> seb128, bullshit, it's not a hack
<seb128> doko, well then open a bug with the patch so it goes upstream and in debian?
<seb128> since when did we stop upstreaming fixes?
<pitti_> we didn't
<pitti_> we expect everyone to do it
<doko> seb128, you are pestering me 5min after the upload. I'll remind you the next time when I have to wait 10min
<seb128> doko, I'm just asking if you will open a bug, not to do it now
<seb128> doko, I've seen some cases recently where you moved on and didn't upstream or documents fixes you did
<Sweetshark> 12:00 <@caolan> are you sure it shouldn't just be #if (!defined(__ARM_PCS_VFP) && defined(__ARM_EABI__)) || defined(__SOFTFP__)
<Sweetshark> doko: ^^
<Sweetshark> doko: maybe join us on #libreoffice-dev?
<seb128> doko, but yes, if I do any upload with a fix not commit from upstream git without a bug reference in the changelog or patch please tell me off for doing it
<seb128> not commit -> not backported
<ockham_> hi, can someone tell me what's wrong with
<ockham_> override_dh_installdocs:
<ockham_> 	dh_installdocs --exclude COPYING --exclude ChangeLog
<ockham_> ?
<ockham_> 'cause those files still keep getting installed...
<tumbleweed> the changelog gets installed by dh_installchangelogs
<pitti_> COPYING is weird, though; I know no dh_* tool which would install that by its own
<pitti_> and it's in fact a slight policy violation to install it for the case of GPL, etc.
<micahg> doko: thanks for the help BTW
<micahg> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<ockham_> pitti_: yeah, that's why i'm trying to exclude it...
<pitti_> ockham_: perhaps it's in some debian/*.install or *.docs file?
<ockham_> pitti_: there was an install file, but i've already removed it.
<infinity> DH_VERBOSE=1 debian/rules binary
<infinity> | grep COPYING :P
<ockham_> infinity: yeah, i'll try that
<pitti_> doko: do we still need this change? https://launchpad.net/ubuntu/+source/python-poppler/0.12.1-4ubuntu1
<jamespage> pitti_: ack, just uploaded karbon rebuild; still working on luatex
<doko> pitti: $ apt-cache show libxcb-render-util0-dev|grep Filename
<doko> Filename: pool/universe/x/xcb-util-renderutil/libxcb-render-util0-dev_0.3.8-1_amd64.deb
<pitti_> doko: (I guess that's not the full answer yet?)
<doko> well, it's a universe package
<pitti_> right, but why can't we use that?
<pitti_> it's our only delta
<pitti_> oh, did python-poppler use to be in main? it's in universe
<pitti_> pretty much forever
<pitti_> doko: so it was just for the component, not a functionality issue?
<ockham_> hm, still no luck. http://pastebin.com/y3HhyK1S
<doko> looking
<seb128> pitti_, it was never in main I think
<infinity> ockham_: I see no verbose debhelper there.
<ockham_> infinity: but i generated it with DH_VERBOSE=1 debuild > ../build.log
<ockham_> btw, just re-uploaded to http://revu.ubuntuwire.com/p/unity-lens-bliss
<infinity> /usr/bin/install -c -m 644 AUTHORS ChangeLog COPYING NEWS README '/home/bernie/src/packages/unity/unity-lens-bliss/debian/unity-lens-bliss/usr/share/doc/unity-lens-bliss'
<infinity> ockham_: Is your upstream Makefile installing those?
<infinity> (Sorry, that was verbose, I'm just not used to seeing dh_ do so little)
<ockham_> infinity: yup, it's apparently in my upstream Makefile.
<ockham_> infinity: so i need to exclude it there...
<doko> pitti_, hmm, no, that was the time for the rebuild tests. I assume that lp couldn't resolve the b-d's. so maybe try without the patch, and then re-add it if necessary. maybe it was armel only?
<pitti_> doko: ok, doing that then
<pitti_> doko: thanks
<doko> heh, neat +build1 trick. but how would add an ubuntu change now?
<pitti_> +ubuntu1? :)
 * Daviey does wonder why people do no change rebuilds, adding ubuntu to the version string. :/
<pitti_> Daviey: uh, did I?
<Daviey> no, in general
<micahg> Daviey: maybe people don't know about dch -R vs dch -i :)
<doko> Daviey, which ones?
<Daviey> doko: i've seen a few, have you not?
<pitti_> I've seen them occasionally, but they looked more like accidental
<doko> Daviey, only if they already have an ubuntu version
<cjwatson> ockham_: 'DH_VERBOSE=1 debuild' needs to be 'debuild -eDH_VERBOSE=1' - debuild filters the environment
<ockham_> cjwatson: oops, thx
<pitti_> Daviey: in general, the debuild -S failure ought to yell at you for not changing the Maintainer: field; that has caught a few cases where I forgot it :)
<doko> pitti: time for +ubuntu1 ;-P
<micahg> hehe
<pitti_> ah, failed on amd64 due to a pointer cast problem (didn't fail here)
<micahg> pitti_: only works if you have an ubuntu address :)
<pitti_> that doesn't seem immediately related to the build dep change, though
<micahg> s/have/use/
<cari_veri_dt> hello: what is the easiest way to combine multiple windows? like editor, terminal, other views ?
<pitti_> dholbach: are you still interested in glom, or know someone who is? it's several versions behind and now unbuildable (still uses gtksourceviewmm2 which doesn't exist any more, and builds against psql 8.4, etc.)
<pitti_> upstream's wiki says to install a third-party repo if you want to use it
<dholbach> pitti_, not so much interested really - I can add it as a low prio entry into my TODO list and do it if nobody beats me to it, but it might still take a while
<pitti_> ah, bug 871276 (nobody picking it up)
<ubottu> Launchpad bug 871276 in glom (Ubuntu) "Please update to Glom 1.19.x" [Wishlist,Confirmed] https://launchpad.net/bugs/871276
<pitti_> dholbach: well, if you aren't interested, it might be better to just remove it?
<dholbach> I dunno - it might still be useful to a lot of people, no?
<pitti_> well, we can't leave it as it is -- we need to remove or upgrade it
<dholbach> pitti_, the Openismus folks seem to have it updated to 1.20.1 in their ppa
<dholbach> is that the latest & greatest?
<dholbach> yes, looks like it
<micahg> dholbach: pitti_: goocanvas 2.0 is in progress in Debian
<dholbach> micahg, do you know where it's currently sitting?
<pitti_> dholbach: yes, it is: http://ftp.gnome.org/pub/GNOME/sources/glom/1.20/
<micahg> dholbach: mentors I think
<dholbach> alright - I'll have a look
<pitti_> ah, we need those libraries first
<micahg> right, I think that's the main reason it wasn't updated last cycle
<dholbach> I'll have a chat with the Openismus folks - they seem to actively care for their stuff, so they might want to have upload rights at some stage - at least I'll tell them to ask for review of their PPA packages, etc etc etc
 * pitti_ hugs dholbach, that sounds great -- teach a man to fish etc.
<ogra_> if you teach them all there wont be any fish left though
<ogra_> :P
<dholbach> ogra_, we're not there yet :)
<ogra_> :)
<seb128> dholbach, pitti_: hey (was at lunch)
<dholbach> hey seb128
<seb128> dholbach, pitti_: don't remove glom please, murray (upstream) cares about it, I meant to email him about the stuff he maintains and the version he would like to see in the LTS
<dholbach> seb128, I'll CC you
<dholbach> just writing the mail
<seb128> dholbach, pitti_: we (desktop) will find some time to update gda, glom, etc
<seb128> dholbach, thanks
<dholbach> seb128, oh yeah? if you do, check out https://launchpad.net/~openismus-team/+archive/ppa/+packages - the work seems to be done there already
<dholbach> (hopefully) just a matter of trimming the changelog entries and uploading
<seb128> dholbach, well, I first want to ask murray what version should go in the LTS
<dholbach> 1.20 I guess is a stable version
<dholbach> but yeah, I'll mention it in the mail as well
<seb128> dholbach, I guess it will requite updates for some other stuff like goocanvas libgda, gegl, etc
 * dholbach nods
<seb128> dholbach, thanks, or just email what you wanted and I will follow up with my questions on what version he wants
<doko> Laney, gnome-do ftbfs the same way as gnome-desktop-sharp2: https://launchpadlibrarian.net/86763720/buildlog_ubuntu-precise-armhf.gnome-do_0.8.5-1ubuntu2_FAILEDTOBUILD.txt.gz
<lool> pitti_, cjwatson: Could we remove and blacklist the squid source from precise?  we generate transitional "squid" binaries from the squid3 source package while Debian ships squid 2 in its squid binaries built from the squid source; zul said he was ok with this approach
<lool> pitti_, cjwatson: Essentially we can't upload the squid source and binaries in Ubuntu anymore, so I think we should removeit
<Daviey> lool: What upload are you planning?
<cjwatson> lool: sure, file a bug and subscribe ubuntu-archive
<cjwatson> (or subscribe us to an existing bug)
<cjwatson> I don't do source removals outside the context of a bug normally, as they need an audit trail
<infinity> lool: It's already planned for removal.
<infinity> (Was discussed here a couple times over the last few days)
<lool> Daviey: No upload
<lool> cjwatson: Ok
<lool> infinity: Oh ok thanks
<lool> infinity: I couldn't find a removal bug against squid, is it against ubuntu?
<infinity> I suppose it's hyproctical of me to complain about people uploading and filling the buildd queues after my weekend, isn't it?
<infinity> lool: Oh, no, there's no bug filed.  Please do.
<infinity> lool: It's just been discussed a few times and concensus met that, yes, we want to remove it, not modify it.
<infinity> (Honestly, I would have just removed it on the weekend, but I've been frying larger fish)
<Daviey> Using the grill is more healthy.
<ogra_> heh, and you seem to have scared away the fish_
<doko> Daviey, Dave Waker?
<infinity> ogra_: That was odd timinig, wasn't it?
 * ogra_ liked it :)
<lool> filed LP #900741
<ubottu> Launchpad bug 900741 in squid (Ubuntu) "Remove and blacklist squid" [Undecided,New] https://launchpad.net/bugs/900741
<lool> doko, infinity ^
<infinity> Yeah, AA will get to it.  No big rush.
<infinity> Daviey: Does the squid transitional package actually migrate configs sanely and such?
<Daviey> infinity: believe so.. i'd need to check.
<Daviey> doko: wassup?
<infinity> Daviey: I think doko just realised who you are.  After years on IRC.
<infinity> Daviey: Don't you feel loved?
<ogra_> haha
<Daviey> infinity: No, i think he realised i am not who i claim to me in From: fields of email addresses :)
<Daviey> (i sent him an email, with a typo in my From)
<infinity> Ahh.
<infinity> Well done.
<cjwatson> You write From: by hand?  What is this, 1990? :-)
<Daviey> cjwatson: You clearly need to look at my headers closer :)
 * cjwatson blinks at User-Agent.
<ogra_> heh
<cjwatson> What impresses me is that it's also GPG-signed ...
<doko> heh
<doko> good, that he just left out a letter, and didn't miss-type it =)
<Laney> doko: the bony fingers of RAOF yet again!
<soren> Daviey: Where can I see this infamous e-mail?
<Laney> doko: -2 uploaded
<tremolux> pitti_: re: software-center, thanks and sorry for the confusion, I updated Vcs-Bzr: in trunk to fix that
<ogra_> slomo, pingaling
<smoser> i'm interested in seeing what other people think about bug 726635
<ubottu> Launchpad bug 726635 in udev (Ubuntu) "udev should not create a persistency-rule for virtualbox virtio network card" [Undecided,New] https://launchpad.net/bugs/726635
<smoser> whoops
<smoser> wrong bug.
<smoser> bug 724601
<ubottu> Launchpad bug 724601 in cloud-init (Ubuntu) "UEC images should disable udev persistent net rules" [Low,Triaged] https://launchpad.net/bugs/724601
<smoser> alexbligh, there suggests we could add an empty /etc/udev/rules.d/75-persistent-net-generator.rules, which would then override the persistent-net rules for udev entirely.
<smoser> what do others think of that?
<smoser> i'm interested both in "you should/should-not do that because..." and "that will break because..."
<doko> cnd, utouch-qml ftbfs, please see https://launchpad.net/ubuntu/+source/utouch-qml/1.0.4-0ubuntu1/+build/2968980
<Laney> is there a bug about being able to subscribe to ftbfs?
<doko> infinity, ^^^ I think you once did subscribe me to these reports
<doko> Laney, you should get email, if one of your own uploads ftbfs. else you could use the ftbfs ubuntuwire pages
<Laney> yeah, i'd rather not have to poll
<Laney> also api syncs still don't mail about ftbfs
<Laney> afaik
<ogra_> ubuntuwire lists them though
<tumbleweed> Laney: there's a bug for the api syncs bit, IIRC
<infinity> doko: We used to send them all to a list, didn't we?
<Laney> there is
<infinity> doko: It's been a long time.
<infinity> doko: If you still get them all, check your headers...
<doko> launchpad-buildd-admin
<slangasek> micahg: I would certainly prefer Pre-Depends: multiarch-support
<cnd> doko, thanks, I'll take a look
<pitti_> good night everyone!
<pitti_> jamespage, wendar: FYI, my server is still down, so I won't have IRC scrollback for the night; mail is down, too :( (but should be back in a few hours)
<wendar> pitti: okay, I won't send you merge requests until tomorrow :) good night!
<micahg> slangasek: can I say I'm shocked that you prefer that version  :)
<slangasek> micahg: as the author of both the wiki page and the debhelper support, I would wonder why ;)
<Cas> something changed with python in ubuntu oneiric that has broken the namespaces for our plugins and i cannot find a solution?
<micahg> Cas: partial dh_python2 conversion?
<Cas> this is before packaging, just building the plugin
<micahg> slangasek: so, I should take Pre-Depends: multiarch-support and tell people who use Pre-Depends: ${misc:Pre-Depends} in Ubuntu directly not to?
<ScottK> Is the package publisher broken?  I've got a build that finished 2 hours ago still showing pending.
<infinity> ScottK: Not so much broken as "not running".
<Cas> here is what ive encountered: http://dpaste.com/hold/666142/
<ScottK> OK.  On purpose?
<infinity> ScottK: We had an oops with the librarian, publisher is on hold while things get un-oopsed.
<ScottK> Ah.  Thanks.
<infinity> micahg: Doesn't misc:Pre-Depends populate with useful things like dpkg-with-xz-support and such?
<infinity> (If you build your debs with xz)
<broder> how could it? don't you set xz with dh_builddeb?
<broder> (i.e. after gencontrol runs)
<micahg> infinity: not that I know of, but I think the idea was to be able to add other magic there as well eventually
<infinity> Hrm, fair point.  But I could have sworn I saw mention of such madness earlier. :P
<broder> hmm. looks like dh_installdeb has new <package>.maintscript support which injects a pre-depends on dpkg (>= dpkg-maintscript-whatever-version)
<broder> but that and multiarch-support are the only things that grep misc:Pre-Depends $(dpkg -L debhelper) finds
<broder> (in fairness, that's pretty useful, but i don't know if i've seen anyone using it yet)
<micahg> infinity: ^^ you're right :)
 * micahg starts using that on his own packages
<cjwatson> ScottK: right, what infinity said - FWIW it's apparently a hardware problem, and it will be OK once the RAID array rebuilds, but for a while there (possibly still) several hours' worth of data was missing from the librarian, and we didn't want to inflict that state on the publisher
<ScottK> cjwatson: Thanks.  Might be worth a mention in /topic.
<infinity> cjwatson: Definitely still.
<cjwatson> oh, yes, I forgot it wasn't in the topic here
* cjwatson changed the topic of #ubuntu-devel to: Archive: open | Publisher stopped pending librarian recovery | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * ScottK did look there before asking ....
<chrisccoulson> infinity, thanks for fixing this problem, but it should have been done as a merge proposal: http://launchpadlibrarian.net/86490977/firefox_9.0~b4%2Bbuild1-0ubuntu1_9.0~b4%2Bbuild1-0ubuntu2.diff.gz
<infinity> chrisccoulson: I already talked to micahg about it.
<chrisccoulson> also, i generally avoid doing single change, single architecture uploads like that, as it's essentially a no-change rebuild on i386, amd64 and armel (which takes more than a day now)
<chrisccoulson> in addition to that, it caused us to push the same breakpad symbols to mozilla's server twice for no reason, which is a waste of their space ;)
<chrisccoulson> we get regular (weekly) firefox releases to fix things like this already :)
<infinity> To be fair, I would have just committed it to your packaging branch, if I could.
<infinity> I'm going to point out that it's a bit annoying for core-dev to not be able to, despite us obviously being able to upload the package. :P
<chrisccoulson> right :)
<infinity> Either way.  It was part of an arch bootstrap.  Not an every day thing.
<infinity> I look forward to annoying you siilarly in 6-12 months with arm64. ;)
<infinity> similarly, too.
<chrisccoulson> we have a significantly different workflow from everyone else though, which is why we don't have everybody committing to our branches :)
<infinity> I don't think "everybody" would.
<cjwatson> Core is full of things that are special-snowflake in one way or another.  Part of the reason core-dev has a high bar is that you're supposed to be able to recognise that.
<infinity> cjwatson: Oh, was there a specific reason that omap4/armhf support in d-i seems to be slightly incomplete, or was it just a quick pass?
<infinity> cjwatson: (Missing s/armel/armel armhf/ on the u-boot-*-panda bit, for instance... Don't recall if there was other stuff)
<cjwatson> infinity: I didn't have an omap4 kernel yet, so couldn't build the omap4 flavour, so I left out the omap4-related build-deps.
<cjwatson> infinity: Feel free to add them in if it's buildable nw.
<cjwatson> *now
<infinity> cjwatson: Well, not buildable *now*, but will be after the publisher gets to run.
<infinity> cjwatson: And we'll need a new d-i anyway to pull in my new libc-udeb.
<infinity> cjwatson: Cause, apparently, I hadn't thought about the fact that eglibc mindlessly smooshes /lib/*/*.so* into /lib
<infinity> cjwatson: Turns out, that doesn't work so well when your interpreter lives in /lib/<triplet>/
<cjwatson> Hah, yes.  I wasn't really expecting it to be usable quite yet anyway.
<infinity> That was the only bug.
<cjwatson> Wow.
<infinity> Tobin moved the file manually in his initrd, and the installed did instally things.
<cjwatson> Even boot loader installation worked?
<infinity> installer*
<infinity> As far as I know, yep.
<cjwatson> (Well, whatever you call the stuff partman-uboot and flash-kernel conspire to do)
<barry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Publisher stopped pending librarian recovery | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry
<infinity> He ran into some userspace issue after first-boot, but that's not d-i's fault.
<cjwatson> Did somebody fix flash-kernel?
<infinity> Well, it was uploaded for armhf.
<infinity> So, sure?
<infinity> Did it need fixing?
<cjwatson> We might even be able to get ubiquity working then.
<infinity> I'd assume it never asked about dpkg arch anyway.
<cjwatson> I thought it had some arch hardcoding, but didn't look too closey.
<infinity> Since it was arm-only.
<cjwatson> or even with typing.
<cjwatson> ./debian/control:12:Architecture: arm armel armeb
<cjwatson> I'm assuming that wanted fixed :-)
<cjwatson> Wow, my tree dates from natty, *cough*
<infinity> Oh, yeah.  debian/control was fixed.
<infinity> When the publisher comes back to life, I'll regen ubuntu-meta (assuming we've picked up anything new), and do some preinstalled builds for giggles.
<infinity> All we're missing is libreoffice, and, well, who cares?
<cjwatson> Fastest bootstrap evah.
<cjwatson> Apart from the bits I didn't see.
<infinity> Not from my perspective. ;)
<infinity> But once I hit the archive, yeah, it was quick.
<cjwatson> That's because you didn't have to timeshare on N900s.
<infinity> *cough*
<infinity> I sold my last N900 to Sledge.
<infinity> I may or may not have employed other phones, however.
<cjwatson> How many of them did you set on fire?
<infinity> My Panda overheated a few times.  But no actual flames.  Very sad about that.
<infinity> I did actually promise myself that when the bootstrap was done, I'd find a nice tall building and teach my panda to fly.
<stgraber> infinity: millbank tower is kind of nice for that :)
<Laney> as demonstrated by Edward Woollard
<infinity> stgraber: That's an expensive flight just to throw 200 dollars off a roof.
<cjwatson> I think MI5 might look askance at hunks of metal hurtling towards their office.
<cjwatson> On the whole possibly not the best idea ever
<infinity> cjwatson: That actually makes it more appealing.
<cjwatson> Please remind me not to be in the same building at the time
<infinity> Some people have no sense of adventure.
<cjwatson> Ah, finally managed to set up mawson for something resembling a germinate speed comparison test
<infinity> If only mawson was an even vaguely reasonable guage of production speed.
<cjwatson> Well, yeah, but I don't have to talk to the database (which IIRC makes a fairly large difference) and I mostly care about checking that this is actually the ~three times faster I expect it to be
<cjwatson> Actually it seems to be running germinate at a fairly similar speed.
<cjwatson> 18s for the most recent run, *40 == 12mins, give or take.  Close enough.
<cjwatson> (This is for https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/+merge/84624)
<micahg> before I stick my foot in my mouth, for the last comment in bug 899315, isn't that the perfect case for dlopen?
<ubottu> Launchpad bug 899315 in ebtables (Ubuntu Precise) "ebtables crashed with SIGSEGV in ebt_initialize_entry()" [Medium,Incomplete] https://launchpad.net/bugs/899315
<slangasek> micahg: oh, sorry - apparently I completely misspoke
<slangasek> micahg: I *meant* to say that I prefer Pre-Depends: ${misc:Pre-Depends}!
<micahg> slangasek: heh, ok, my hunch was correct then :)
<micahg> broder: ^^ can you fix please :)
<slangasek> the reason being that this eventually goes away in the future when debhelper decides this dependency is no longer needed
<broder> micahg: this evening, but yes
<micahg> slangasek: right, and it can disappear centralized at the beginning of a cycle
<micahg> broder: sure , no rush
 * broder pulls his patches from the sponsor q for the time being
<Daviey> smoser`: Are you currently looking at cobbler-devenv?
<Daviey> with lxc?
<barry> does anybody know what "Unhandled exception processing upload: 26130185" means?  I tried to dput an update to gftp, and all i get back is a rejection message with that message in it
<cjwatson> rejection at upload time or at dput time?
<cjwatson> er, I mean, s/at upload time/by e-mail/
<barry> cjwatson: i dput the package which appeared to succeed, and then a little bit later, i got that message in an email from archive@ubuntu.com
<cjwatson> hm, yes, I see the rejected package here
<cjwatson> http://launchpadlibrarian.net/86795637/fmw5h2ageMsHnQI7HrJvMRHh7kE.txt
<cjwatson> I suspect this is fallout from librarian hardware trouble
<barry> ouch. i must have missed hearing about that trouble.
<cjwatson> because that's it trying to fish the orig out of the librarian and failing
<barry> i guess re-uploading won't help.  maybe build w/ -sa and re-upload?
<cjwatson> leave it for now
<cjwatson> we should be able to flush the rejected upload(s) back into the queue once everything is back to normal
<barry> cjwatson: okay, thanks.  i'll note it in my patch pilot report
<cjwatson> actually it's a bit weird that that's missing because the orig shouldn't have been in the time window affected; I'll ask ops
<cjwatson> barry: I suspect trying to work around it with -sa wouldn't help anyway, since it still has to compare it against what's in the librarian; but it doesn't sound like an experiment I'd want to run
<barry> cjwatson: fair enough.  i guess that means there's not much i can do on my side...
<cjwatson> probably not, sorry
<barry> k, thx
<barry> i guess we'll see if any other uploads hit the same problem
<cjwatson> it'll be easy enough to grep for similar failures in the logs and retry appropriately
<broder> SpamapS: could you take a quick look at bug #886205? based on my understanding of the issues, it sounds like a dup of bug #580319, but i'd like someone with more domain expertise to double-check
<ubottu> Launchpad bug 886205 in upstart (Ubuntu) "Disabling network-interface break rc-sysinit compatibility script" [Undecided,New] https://launchpad.net/bugs/886205
<ubottu> Launchpad bug 580319 in upstart (Ubuntu Natty) "init.d controlled services launch before all interfaces are up, thus failing to start" [Medium,Triaged] https://launchpad.net/bugs/580319
<SpamapS> broder: well.. yes and no. His firewall script still may not work right.. since the order is still in hardware detection order, not /etc/network/interfaces order
<broder> err, right, but his patch is a less evolved version of /etc/init/failsafe.conf, right?
<SpamapS> broder: indeed it is
<SpamapS> broder: (and a wrong one at that, as networking does not mean that all those interfaces were actually around when it ran 'ifup -a')
<bdrung> tumbleweed: the script fails due to wrong option
<bdrung> tumbleweed: the output isn't structured nicely
<tumbleweed> bdrung: will look in a minute
<bdrung> tumbleweed: and it contains some merge markers
<tumbleweed> bdrung: just pushed lp:~stefanor/ubuntu-dev-tools/native-sync-sponsorship which should work (I think) when bug 827555 has been QA-ed
<ubottu> Launchpad bug 827555 in Launchpad itself "native syncs have no way to indicate sponsorship" [Critical,Fix committed] https://launchpad.net/bugs/827555
<bdrung> tumbleweed: the OptionGroup warning should exclude fakesyncs
<tumbleweed> bdrung: well, they aren't part of that group
<bdrung> tumbleweed: so --fakesync does not require --no-lp?
<bdrung> tumbleweed: "Did Ubuntu modify this (and mark the version appropriately?" -> missing )
<bdrung> tumbleweed: i would try to split long lines into two commands.
<bdrung> e.g. "ubuntu_source = get_ubuntu_srcpkg(src_pkg.source, release.split("-")[0])" -> series = release.split("-")[0]
<bdrung> ubuntu_source = get_ubuntu_srcpkg(src_pkg.source, series)
<tumbleweed> bdrung: --fakesync implies --no-lp
<bdrung> and second: "subprocess.Popen(cmd, stdout=subprocess.PIPE).communicate()[0]" -> process = subprocess.Popen(cmd, stdout=subprocess.PIPE)
<bdrung> process.communicate()[0]
<bdrung> tumbleweed: you may want to adjust the man page too
<tumbleweed> indeed
<bdrung> tumbleweed: --help doesn't tell you that --facesync does a local sync (and is the correct way to do it)
<tumbleweed> bdrung: --help improved. manpage next
<bdrung> tumbleweed: "it will leave a signed .changes file for you to upload." could be also added to --no-lp
<tumbleweed> yeah, just thought that too
<bdrung> tumbleweed: W: ubuntu-dev-tools: debian-changelog-line-too-long line 29
<bdrung> good night
<bdrung> tumbleweed: found nothing to complain any more. you can merge your branch. besides that, sponsor-patch should be modified to use the new feature of syncpackage (code is there and just needs little adjustment)
<bdrung> now really good night
<tumbleweed> yeah, that should happen
<tumbleweed> I won't merge it until the feature is live
<psusi> shouldn't udisks --inhibit prevent the desktop from fscking with new mounts that show up?  I'm trying to run the parted test suite and the tests are failing because gnome is fscking with the temp test mounts
<broder> i don't see how anything gnome could fsck - it all runs unprivileged
<barry> smoser: ping
<psusi> by fsck I mean generally fucking with ;)
<psusi> like looking for cat photos or music albums or whatever it does when it sees a new disk.. it keeps popping up and trying to tell me things about the new fs that was mounted in some deep tmp dir during the tests, even though I use udisks --inhibit
<broder> but the point stands. gnome can't do anything to anything without udisk-daemon agreeing to it, so start there
<psusi> hrm... killing udisks didn't help either
<broder> i would assume that its udev rule hits it over dbus so it gets autospawned
<psusi> I meant kill -STOP
<broder> well then it must be the udev rules
<psusi> I thought udisks was the bridge between udev and gnome?
<psusi> if it is frozen... gnome shouldn't be doing anything right?
<psusi> bwahah!  suck it gnome!  wrapped make with unshare -m and nobody else gets to see the new mounts
<broder> oh, if the tests are mounting things i don't think that's mediated by udisks
<barry> well, it's dinner time so...
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Publisher stopped pending librarian recovery | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<SpamapS> broder: were you going to mark bug 886205 a dupe of bug 580319 ?
<ubottu> Launchpad bug 886205 in upstart (Ubuntu) "Disabling network-interface break rc-sysinit compatibility script" [Undecided,New] https://launchpad.net/bugs/886205
<ubottu> Launchpad bug 580319 in upstart (Ubuntu Natty) "init.d controlled services launch before all interfaces are up, thus failing to start" [Medium,Triaged] https://launchpad.net/bugs/580319
<broder> SpamapS: i was planning to take another look at it this evening while holding out silent hope that you'd deal with it first :-P
#ubuntu-devel 2011-12-07
<SpamapS> broder: haha ok :) I think just a simple "hey thanks for the patch, we fixed that in 11.10 in this bug report" comment suffices + marking it as a duplicate.
<SpamapS> broder: 1 2 3 NOTIT
<broder> SpamapS: :-P. ok, i'll deal when i get home from work, then
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Publisher stopped pending librarian recovery | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso
* cjwatson changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso
<infinity> cjwatson: If you feel a strange urge to make d-i work with omap4 tonight, it should work as of, well... Now.
<infinity> cjwatson: if not, I'll do it tomorrow. :)
 * infinity is, shockingly, not working past quitting time tonight.
<cjwatson> Not tonight, darling, I've got a headache^Wset of germinate uploads to do
<micahg> what's the proper way to defer startup of a service in upstart w/out depending on the display manager starting
<broder> defer until what?
<micahg> I guess either the display manager starts or other more critical services are done, I guess
<broder> i'm not sure that upstart acknowledges the concept of differing importance of services
<micahg> was taking a look at merging pppconfig
<micahg> infinity: wait a second, if something's in the minimal task, I thought we didn't need to depend on it
<cjwatson> micahg: no, that's only packages that are Essential: yes
<cjwatson> infinity's fix wasn't theoretical; his build chroots are <minimal.
<cjwatson> or rather, neither a subset nor a superset of minimal
<micahg> cjwatson: ah, ok, not sure where I heard that before then
<cjwatson> There are various misunderstandings of this floating around :-(
<cjwatson> Have been for a long time.
<micahg> cjwatson: so, how do xz/lzma debs work then?
<cjwatson> micahg: hmm?
<broder> micahg: dpkg has a dependency on xz-utils
<broder> (pre-depends, even)
<cjwatson> micahg: dpkg is Esential: yes and Pre-Depends: xz-utils
<cjwatson> snap
<cjwatson> Essential isn't transitive
<micahg> cjwatson: ah, that's the other half of the trick :), ok
<cjwatson> I mean, not transitively closed.  Essential packages can depend on packages that are non-Essential (all such packages would be Priority: required, but the reverse is not true)
<micahg> but inherently, we shouldn't rely on something being available unless it's Essential:yes
<broder> if you're using it directly, no
<broder> if the essential tool you're using relies it, that's an implementational detail and not your problem
<micahg> right, ok
<micahg> so if I'm using lzma/xz directly, I should depend on what I need, but WRT dpkg being able to use it, that's implementation
<cjwatson> exactly
<psusi> question.. since xz is required now anyhow, why is initramfs-tools still defaulting to using gzip?
<TheMuso> psusi: Who maintains ureadahead in Ubuntu these days? have they had a look over your ureadahead changes?
<psusi> TheMuso, tag, you're int ;)
<psusi> seriously... since Keybuck left, nobody wants it
<TheMuso> psusi: lol! I think not.
<psusi> that's why I held off proposing a change for 11.04, then I kind of forgot about it
<TheMuso> psusi: Perhaps it may be worthwhile putting these changes in a PPA, and put out a call for testing. I don't feel comfortable uploading this change unless its been tested/looked over by a few people who know the code.
<psusi> I poked him a few times to see if he wanted to merge the changes to his upstream project that lp still says is his... he doesn't seem interested
<psusi> in maintaining the upstream that is
<TheMuso> Right.
<psusi> he just kept saying that keybuck@ubuntu.com was dead or something
<psusi> I did that 12 months ago ;)
<TheMuso> Ok.
<TheMuso> And?
<TheMuso> Any responses good or bad?
<psusi> got a few people giving me positive feedback on the forums
<psusi> of course, I'm now banned from the forums due to a power mad admin not liking his decisions questioned and their governing board apparently not functioning anymore... they don't have meetings and ignored the issue when I kept putting it to them on the ml...
<TheMuso> Right.
<TheMuso> I take everthing from the forums with a grane of salt anyways.
<TheMuso> everything
<TheMuso> Having said that, I practically never read the forums.
<psusi> yea, it was mostly a time waster for me anyhow... I like askubuntu better now anyhow
<psusi> at any rate, I originally made the changes in maverick, and posted them to my ppa... got a few positive feedback... then ran it myself in natty for a while... then forgot about it
<psusi> just realized yesterday when I was looking over my branches on lp that I never did get it merged...
<JackyAlcine> psusi: +1
<TheMuso> Right.
<JackyAlcine> askubuntu's so much better.
<psusi> I can tell you this; I spent many hours last year staring at blocktrace logs working on that ;)
<broder> seems like jhunt would be the obvious person to review ureadahead changes these days
<TheMuso> psusi: Given our focus on testing this cycle, I'm not sure if I want to be the one who screws people's systems up. Yes I know you have run it for a while, but was testing carried out on different systems with rotery and SSD drives?
<psusi> and I also was playing with using e2defrag to pack the files tight at the start of the disk to make it even better
<psusi> yes
<psusi> I have 3 rotational and one ssd
<psusi> mixing lvm, regular partitions, and dmraid ;)
<TheMuso> Ok
<psusi> hrm.. I guess I should go make sure it doesn't break anything on btrfs though
<psusi> it shoulnd't, but not tested yet I guess
<TheMuso> Actually, thats a good point.
<TheMuso> But it begs the questino how much we support BTRFs at this stage.
<TheMuso> As in, helping users with problems, support contracts etc.
<psusi> not much I think ;)
<psusi> but I have been playing with it a lot lately... aside from the dpkg/fsync issue, it's frigging awesome
<broder> "aside from hanging my entire machine for 10+ seconds at a time whenever i do anything with dpkg"
<psusi> hehe... I just wrap it in libeatmydata now automatically... makes it twice as fast on ext4 too
<psusi> I worked up a patch to give dpkg a --force switch to disable all the fsync calls too, but debian doesn't seem to like the idea
<psusi> makes it very snappy and can easily be done automatically with the apt-btrfs-snapshot package after it makes a snapshot of the root fs before it starts having dpkg upgrade/install packages
<psusi> I was thinking of doing that, and making grub smart enough to fall back to the snapshot if the system crashes during the upgrade
<psusi> it is pretty damn cool though, to be able to install natty, make a snapshot, install the hundreds of upgrades, then decide you're going to roll back... reboot, and 20 seconds later, you're back to base install being prompted that there are 300 upgrades available ;)
<TheMuso> Yeah that is cool.
<psusi> I made some improvements last week to this nifty btrfs-gui utility too that helps visualize the fs layout
<TheMuso> So... I am wondering what to do next. I'd like to see this get in, but I don't feel comfortable uploading it. I guess I could build it here, and run it for a little while to see what happens...
<psusi> TheMuso, that works ;)
<TheMuso> Yeah I know it works, but I've never been a fan of WFM tests.
<psusi> TheMuso, add a comment saying you're testing it for now... maybe someone else will do the same... even if it doesn't end up getting merged by anyone this cycle, if a few devs end up testing it and saying it looks good, should be an easy merge for 12.10 as soon as it opens
<psusi> or maybe merge it, but pull it back out for final beta, just in case?  at least that way it gets plenty of testing between now and then
<TheMuso> Yeah, will leave a comment for now I think.
<TheMuso> psusi: Actually, it FTBFS for me...
<psusi> roh roh... I guess I didn't actually test it on precise, I'm still running oneiric
<TheMuso> heh
<psusi> I wonder what changed...
<psusi> guess I'll have to work on that
<TheMuso> Are you doing that now, or should I move onto something else and come back later?
<psusi> move on... I'm trying to write a new parted test suite test to get some patches merged upstream right now
<TheMuso> Ok no worries.
<TheMuso> psusi: BTW I also referred your parted branch to cjwatson, as he knows that code far better than I do. Hell I can't even remember much about the linux device-mapper code that I touched back in 2008. :)
<psusi> I figured ;)
<psusi> I'm really excited about finally not having to tell people they need to boot from the livecd to use gparted
<TheMuso> Cool.
 * psusi beats this test suite into submission
<psusi> damnit... how did you get a shell expression to substitute a variable, then append more text?  I thought it was {$foo}bar, but that seems to be leaving in the P{
<psusi> {} rather
<TheMuso> psusi: Is $(commands-here etc) what you want?
<psusi> TheMuso, no.. I want to test for the existence of /dev/foop1 when DEV=/dev/foo, so I want $DEV+"p1"
<psusi> oddly, $devp1 seems to work, though that doesn't seem to be a good idea... what if there were a variable named devp1?
<stgraber> psusi: ${var}text
<stgraber> stgraber@castiana:~$ blah=abc
<stgraber> stgraber@castiana:~$ blahvar=test
<stgraber> stgraber@castiana:~$ echo ${blah}var
<stgraber> abcvar
<psusi> DEV=/dev/sda echo ${DEV}1
<psusi> just spits out "1"
<psusi> I thought that was how it was done, but it just is't working for me...
<stgraber> just like "DEV=/dev/sda echo $DEV" will spit out nothing
 * psusi just had the world turn upside down
<stgraber> my understanding is that $DEV is substitued before echo is actually called
<psusi> you mean before the assignment?
<stgraber> right
<stgraber> so if you do it in two steps it works fine
<psusi> bah.... damn shell ;)
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti_> good morning
<pitti_> cjwatson: want me to do a d-i upload for the bumped omap4 kernel? (I guess it couldn't hurt for me to actually get some practice how to do that)
<micahg> pitti_: quick question, any extra checking I need to do before uploading something from core?  I test built and tried running it
<pitti_> micahg: sorry, which "core"?
<micahg> pitti_: sorry, it's libvdpau
<pitti_> micahg: oh, your core-dev application got approved?
<micahg> pitti_: yep :)
<pitti_> micahg: congrats! well earned
<pitti_> (FWIW, I thought you had been core-dev for ages already :) )
<micahg> pitti_: thanks!
<pitti_> micahg: no extra formal checks, no; just "don't upload something broken", as usual :)
<micahg> ok, great
<pitti_> RAOF: hey Chris, how are you?
<pitti_> cjwatson: I committed the actual ABI bump to bzr, but I'll wait for your guidance how to build the source package from bzr
<pitti_> cjwatson: when I just run debuild, I get http://paste.ubuntu.com/762512/ (NB I didn't tag the release yet); do I need to run anything else like pulling in udebs or other sources, etc?
<pitti_> jamespage: I fixed poppler-sharp harder and will then upload another rebuild of pdfmod; now the remaining poppler-glib6 rdepends are all due to the dropped poppler_page_render_to_pixbuf(); yay for copy&pasting code there :(
<TheMuso> micahg: Oh congrats.
<micahg> TheMuso: thanks :)
<dholbach> good morning
<pitti_> wendar: any progress with the magics++ FTBFS? do you need some help there?
<wendar> pitti: it's done, submitted upstream to Debian
<wendar> pitti: the guy said he'd apply it over the weekend, then we can sync
<pitti_> wendar: oh, nice! well done
<pitti_> jamespage: ^ that'll resolve the remaining libgrib-api-0d-1 NBS, so let's ignore this for now
<pitti_> jibel, jamespage: current server tests failed due to uninstallable grub-pc and language-pack-en; I really don't see how this happened, though, they both have been installable in the past few days
 * pitti_ downloads server ISO and tests for himself
<doko_> infinity, gcc builds currently fail in stage2 (gcc-snapshot, gdc-4.4, ...)
<pitti_> jibel, jamespage: the image's report.html is clean as well
<jibel> pitti_, good morning. looking
<pitti_> jibel: I'll try to reproduce it locally
<jibel> pitti_, I'm replaying a server amd64 default install
<jibel> pitti_, grub failed to install
<pitti_> jibel: presumably due to the failure to instsall grub-pc?
<jibel> pitti_, right, but the vm shutdown before I had time to look further. I'll mount the disk and search what's wrong
<jibel> Dec  7 08:21:49 in-target: Errors were encountered while processing:
<jibel> Dec  7 08:21:49 in-target:  /var/cache/apt/archives/language-pack-en-base_1%3a11.10+20111006_all.deb
<jibel> Dec  7 08:21:49 in-target: E
<jibel> Dec  7 08:21:49 in-target: :
<jibel> Dec  7 08:21:49 in-target: Sub-process /usr/bin/dpkg returned an error code (1)
<jibel> pitti_, bad news
<pitti_> EINVAL?
<jibel> pitti_, Dec  7 08:21:49 in-target:  failed in write on buffer copy for backend dpkg-deb during `./usr/share/locale-langpack/en_GB/LC_MESSAGES/libnih.mo': Invalid argument
<pitti_> bah
<pitti_> so that's on amd64, too
<pitti_> just a lot less often
<jibel> apw, ^
<pitti_> jibel: ah, will search for that in the syslog next time, thanks
<jibel> pitti_, np. if dpkg and ubiquity are affected on both arch that will become a problem for daily testing
<pitti_> soren: do you have a particular interest in updating user-mode-linux for 3.2.0? it's currently unbuildable, so I removed the binary for now
<pitti_> soren: if it's obsolete, I can remove the package, too
<soren> pitti_: I do, I just haven't gotten it to work yet.
<micahg> doko_: remember bug 899315 and --as-needed, the guy responded saying that the symbols aren't used except by a plugin so they'll get stripped even in the correct order, but isn't this what dlopen is for, or is that asking too much for a distro patch?
<ubottu> Launchpad bug 899315 in ebtables (Ubuntu Precise) "ebtables crashed with SIGSEGV in ebt_initialize_entry()" [Medium,Incomplete] https://launchpad.net/bugs/899315
<slomo> ogra_: pong
<slomo> ogra_: next time with some context please :)
<soren> pitti_: You deleted the binary already?
<pitti_> soren: yes, as it's unbuildable
<pitti_> but I kept the source
<micahg> pitti_: if you're in the mood for going removal happy, I have bug 891484 :)
<ubottu> Launchpad bug 891484 in uppity (Ubuntu) "Please remove these Firefox extensions binaries and source + blacklist" [Wishlist,Confirmed] https://launchpad.net/bugs/891484
<soren> pitti: Well, yeah, but when did we start blowing away binaries of packages that ftbfs?
<soren> pitti_: I mean, sure, if we were close to release or something, but now?
<pitti_> well, our goal is to drive NBS to zero and keep it that way
<jibel> pitti_, I ran 3 installations of server amd64 and they all failed in "Unpacking language-pack-en-base" during the extraction of a .mo file but a different one each time.
<pitti_> it prevents us from accidentally releasing with an unbuildable binary if we forget to fix it
<soren> pitti_: ?!? How is this NBS?
<pitti_> soren: linux-source-3.0.0 does not exist any more, so u-m-l can't be built
<pitti_> soren: FTBFS for u-m-l, sorry
<micahg> pitti_: FWIW, I would think it reasonable to give someone a little time to fix before removing the binary (unless we're close to a milestone)
<soren> pitti_: It just seems quite heavy handed at this stage.
<micahg> and even with the milestones, I think that should come with an announcement so people are aware
<pitti_> well, can do, but we don't really have a tracker for these
<pitti_> we could file release critical bugs and hope that someone picks them up
<micahg> pitti_: file a bug with a new tag that can go on a report?
<pitti_> but it would be wrong to actually nail down someone to fix some universe package
<pitti_> and removing just the binary doesn't actually block people from uploading or introduces source NEW or so
<micahg> pitti_: you can file the bug and subscribe the last uploader or 2
<micahg> pitti_: it does prevent someone from using the app in the devel release
<soren> pitti_: It doesn't block people from uploading a new u-m-l, no, but it could certainly block other things. I have some tests that involve u-m-l that now won't work.
<pitti_> (bug 901118 )
<ubottu> Launchpad bug 901118 in user-mode-linux (Ubuntu) "Needs porting to linux-source-3.2.0" [Undecided,New] https://launchpad.net/bugs/901118
<pitti_> soren: ok, so maybe this was a little premature, sorry; we started doing that in oneiric when we started the goal of actually not releasing with FTBFS packages
<soren> pitti_: I'm pretty sure u-m-l somehow evaded that effort in Oneiric.
<soren> pitti_: It wasn't until less than a week before release I finally cracked it and got it work with 3.0.0.
<pitti_> soren: it is buildable in oneiric, as oneiric does ship l-source-3.0.0
<soren> pitti_: Yes, and up until 4 days before release, it depended on l-s-2.6.38.
<pitti_> soren: right, that happened with quite a lot of packages; their binaries got removed, and the ones which actually got fixed just reappered
<pitti_> micahg: removals> doing
<micahg> pitti_: thanks
<micahg> infinity: I finally got to an armhf FTBFS build log and sync'd the (hopefully) fix :)
<cjwatson> pitti_: no, that's all you need and there's nothing special about building a d-i source package from bzr, but I'd like to add armhf/omap4 while we're there
<cjwatson> now that it's in the archive
<pitti_> cjwatson: ok, so that's just for ubiquity
<cjwatson> yeah, ubiquity is weird
<jamespage> pitti_: I did a few more uploads for the libpoppler-glib8 transition last night
<cjwatson> pitti_: uploaded now
<pitti_> jamespage: ah, thanks; i. e. the ones that just needed a rebuild?
<jamespage> the remaining few need patches as they all use the gtk API in poppler which disappears in 0.18
<cjwatson> (d-i)
<pitti_> jamespage: I'm still without email, so I can't follow -changes@ ATM
<pitti_> cjwatson: cheers
<jamespage> pitti_, yep - thats right
<pitti_> jamespage: right; we probably need to do some copy&pasting there, to counteract http://cgit.freedesktop.org/poppler/poppler/commit/?id=149b7fec4
 * pitti_ sighs at this
<pitti_> jamespage: we have a patch like that in gimp now
<pitti_> jamespage: I did a few more syncs/uploads/binNEW this morning, and after cjwatson's d-i upload NBS should clear up a lot
<pitti_> jamespage: do you want to do the libcegui-mk2-1 transitions? (presumably just rebuilds)
<jamespage> pitti_: sure - leave it with me
<pitti_> jamespage: ok; I suppose we'll divide the poppler porting between us in the next days then
<jamespage> pitti_: ack
<apw> jibel, pitti_, i have at least identified the underlying issue.  i think i have a fix for it which i am discussing with upstream currently.  it is possible a wholesale backout of some new code may be on the cards.
<apw> jibel, if i get you a ker
<micahg> pitti_: thanks for the removals, is there any other info you need in those bugs in general?  (I'll try to do a run at least monthly to keep those extensions out of the archive)
<pitti_> apw: oh, that sounds promising; OOI, what is it?
<apw> jibel, if i get you a kerel with a fix is that something we can test easier
<pitti_> apw: it at least seems that the whole python part is irrelevant, so it's really write()
<pitti_> apw: I suppose, jibel now has a jenkins set up to exercise/reproduce this
<apw> pitti_, an issue with handling of partial writes at the very begininning of files, the code which tried to sanitise the buffers before return misses
<pitti_> micahg: not for my purposes, I know the context
<micahg> thanks
<pitti_> apw: ah, so it's not a problem with cache handling? I tried VMs with little memory, but it didn't reproduce more often there
<apw> pitti_, i don't believe any data is at risk, just buffers are attempted to be dropped, and we try and drop one whic
<apw> which was never made
<jibel> apw, I've a VM setup to reproduce this. I can update the kernel easily on it.
<apw> pitti_, i think they key is speed, the faster the host the better, which is why we see it more on VMs, the disks are soooo much quicker on a fast host than real spindles
<apw> pitti_, and is why i couldn't reproduce it on my laptop, my build monster could repro it 99% of the time like jibel's (which i assume is a biggie)
<apw> jibel, ok will get you a test kernel shortly
<jibel> apw, that would explain why we can reproduce it very frequently on our big boxes in the test lab
<jibel> apw, thx
<pitti_> apw: ah, and since I have SSD, it was only seldom for me, too, supposedly
<apw> jibel, yeah, i was stumped for a bit till i got sick of my laptop going soooo slow and booted up one of my test boxes, there it was impossible to install the VM to have a test, i had to copy it over
 * pitti_ does a process-removals run
<pitti_> there, boost1.42 finally gone
<micahg> \o/
<pitti_> (only one remainging rdep, toonloop, rebuild uploaded)
<doko> mvo, E: Internal Error, AutoRemover broke stuff
<doko> multiarch issue, how can I just remove the offending package?
<mvo> doko: uhh, is that on your machine? what was the command you run? what does -o Debug::pkgAutoRemove=true output (a lot probably)
<doko> mvo: see query
<YokoZar> dput by sftp broken?  launchpad refusing ssh connections
<YokoZar> ...and it's already fixed
<pitti_> Daviey: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt -> shall I demote mysql-5.1 to universe, or keep it there as a reminder to do the remaining transitions?
<pitti_> Daviey: there's also the option of removing it now, then the remaining rdeps will appear on http://people.canonical.com/~ubuntu-archive/nbs.html
<pitti_> Daviey: but of course that'll firmly commit us to fully complete the transition (I suppose we want to do that anyway, though)
<apw> jibel, ok http://people.canonical.com/~apw/lp894768-precise/ the 0916 kernels there should have the proposed fix if you could bash them
<infinity> doko: I'm assuming the gcc* builds that fail are lacking the linker path patch.
 * pitti_ sends apw a big hug and a bottle of beer
<infinity> doko: So, stage one builds a new binary with the incorrect interpreter, and stage two tries to run it and it fails, cause, well, that interpreter doesn't exist. :P
<Daviey> pitti_: Unless it's causing an issue, i'd like to defer judgement to SpamapS.  He is driving this, too many cooks etc.
<pitti_> Daviey: no, it's not urgent, I was just wondering; thanks
<Daviey> super.
<doko> infinity, right, seen that at least for gcc-snapshot
<doko> infinity, and need to add this to ghdl, gccxml (?)
<infinity> doko: Look like what's happening in gdc too: "configure: error: cannot run C compiled programs"
<doko> yes, will merge that from debian
<infinity> doko: I guess anything that's technically "just another gcc frontend in a split source package" will need the patch.
<doko> infinity, can you build ghc using the debian binaries in your archive?
<doko> probably the linker changes are needed there too. didn't check ocaml
<infinity> doko: Did markos build ghc in Debian?  If so, yeah, I can cross-strap it here.
<infinity> doko: (After I sleep)
<doko> infinity, yes, it's in the ports archive. I'll start a build here
<doko> libreoffice doesn't work yet
<infinity> Dang.
<infinity> And we were doing so well in main too.
<Laney> oh, thanks for ghc; I saw the depwait
<infinity> doko: Don't worry about ghc, I'll kick it off before I go to bed.
<doko> going back to gnat ...
<doko> Laney, infinity: any idea about fpc?
<Laney> the pascal thing? not really
<infinity> fpc may need porting.  Pretty sure it's not been done in Debian yet.
<Laney> nothing in ports, possibly because it is in p-a-s
<doko> yes b-d's on itself
<Laney> http://lists.freepascal.org/lists/fpc-devel/2011-September/025911.html
<Laney> (and following)
<Laney> â not ported
<infinity> ghc building.  Nap time.
<doko> Laney, are you know comfortable with these kind of build failures? ;-P https://launchpad.net/ubuntu/+source/libdap/3.11.1-9/+build/2964286
<l3on> hey gusy... each package with xz compressor needs a Pre-Depends: dpkg (>= 1.15.6), right ?
<l3on> *guys
<Laney> doko: argh!#
<Laney> is nobody running debian rebuild tests any more?
<micahg> l3on: with xz debs, yes
<l3on> micahg, thanks :)
<Laney> lucas: ^ did your minions fall away or is there one coming up soon?
<micahg> Laney: ISTR lucas asking for help and the request falling on deaf ears
<Laney> no, some other people did run them
<OdyX> there are some people processing the logs now, but actually running the rebuilds is still (AFAIK) in lucas' hands.
<Laney> I suspect that is the more automatable part anyhow
<l3on> pitti_, hey! I'm looking at gnome-applets, can I do the merge ?
<pitti_> l3on: of course, thanks!
<l3on> :)
<pitti_> l3on: it's maintained in lp:~ubuntu-desktop/gnome-applets/ubuntu, perhaps you can do a merge proposal?
<pitti_> yay, I'm through with process-removals, after only 2.5 hours or so
<l3on> ah... I'm doing it in the classic way... bug :)
<pitti_> l3on: ok
<pitti_> lamont, elmo: any chance to kill the glib2.0 build on zirconium? it's once again stuck in an infinite loop in the test suite
<pitti_> cjwatson: I finished the ttf-* -> fonts-* transition as far as Debian did it (syncs, removals, seed changes, etc.); this changed some names in platform/installer-gtk; does this need corresponding changes in d-i/ubiquity?
<sladen> pitti_: there's our fonts to do aswell, when I get some firm guidance from other pkg-fonts people about exactly what they want
<lucas> Laney, micahg, OdyX: it's still up to me to run the rebuilds, but others have been processing the logs. Nobody asked me for fresh logs recently, so it's true that I did not run any rebuild recently.
<cjwatson> pitti_: d-i build/pkg-lists/ might need some changes
<pitti_> cjwatson: ok, will change it there as well; I kind of assumed it would be generated from the seeds
<pitti_> cjwatson: committed; I'll upload it once fonts-sil-abyssinica-udeb gets published; thanks!
<MSK> i am interested in contributing an application software to ubuntu. how do i get started?
<ubuntu_love> how do i get started to contribute an application to ubuntu
<hrw> eglibc maintainers: can you take a look at http://bazaar.launchpad.net/~hrw/ubuntu/precise/eglibc/fix-hardening-for-cross-builds/revision/239 and give opinion?
<smoser> barry, here now. i'm guessing you were pinging regarding the python-boto
<smoser> i can upload that, and thank you for reviewing.
<l3on> cjwatson, around ? I would like to talk with about the importance about have "Pre-Depends: dpkg (>= 1.15.6)"
<l3on> I wrote a very spartan pyscript that looks for packages don't have this, I found many of them...
<tumbleweed> l3on: that contain data.tar.xz ?
<l3on> yes
<l3on> tumbleweed, for example... packagesrc colord has colord_0.1.12.orig.tar.xz
<tumbleweed> l3on: this is about xz compression in binaries, not sources
<tumbleweed> i.e. debs with xz compressed contents
<l3on> tumbleweed, ahhh... :)
<l3on> tumbleweed, could you provide me an example ?
<tumbleweed> l3on: dovecot
<l3on> I thought that if a source has something with *.xz, binaries should have the Pre-Depends
<tumbleweed> no, they are unrelated
<stokes_> _jmp_: o/
<l3on> tumbleweed, for example... libparse-http-useragent-perl has the Pre-Depends
<l3on> what have I look for ?
<l3on> â http://debomatic.debian.net/precise/pool/libparse-http-useragent-perl_0.33-1ubuntu1/libparse-http-useragent-perl_0.33-1ubuntu1.contents
<tumbleweed> l3on: http://paste.ubuntu.com/762791/ <- note the data.tar.xz
<l3on> ah ok :)
<l3on> do you think we have some package without the Pre-Depends ?
<tumbleweed> no, the builds would have failed to upload
<l3on> ah ok, thanks tumbleweed  :)
<soren> What is it that mounts a tmpfs on /run?
<soren> Oh.
<soren> Found it.
<soren> (mountall (due to the hidden fstab in /lib/init))
<cjwatson> l3on: I don't think you need to do any of this.  I know that there are no outstanding problems of this kind in precise, because I've been squashing every single one of them as I see them show up in the "Failed to upload" state.
<kees> hrw: that seems sane to me. I still wish we could build without those disabled.
<hrw> kees: ok, so will propose for merging
<SpamapS> pitti_: ping, ahead of the actual micro release exception for OpenStack, I was thinking we'd waive the normal rules and let the diablo stable branch uploads into oneiric-proposed.. we can delay their entry into -updates until the TB weighs in on their application for a microrelease exception.
<pitti_> SpamapS: ok, we'll review it like a normal SRU then
<SpamapS> pitti_: its 25 distinct bugs
<ScottK> SpamapS and pitti_: working on KDE 4.7.3 for oneiric-proposed.  We're going to do it in two parts: l10n and the core apps.  We will also need to sort out updating soprano as upstream has VERY strongly recommended updating it with 4.7.3 (it's a KDE support package, so not formally covered under the release exception, but I think it needs to get in this time).
<pitti_> SpamapS: do we have a large-ish test suite for these packages?
<SpamapS> pitti_: the patch is very large, but *VERY* well tested upstream.
<pitti_> ScottK: ok, thanks for the warning
<SpamapS> openstack has a ridiculous amount of testing
<SpamapS> pitti_: yes, thats why I think they're a slam dunk for the micro release exception
 * SpamapS goes afk.. brb
<broder> ooc, are there any docs on the form an RM bug should take? (looking for something to point somebody else at)
<pitti_> broder: there's no form or so; describe the reason, check rdependencies, and subscribe ubuntu-archive
<broder> ok
<SpamapS> pitti_: ok back.. so anyway, the last upload they did I rejected because the diff was pages and pages long
<SpamapS> pitti_: but they definitely match up with the MRE process exactly.. heavy upstream testing, supported "fixes only" stable releases.
<hallyn> pitti: could you drop the libvirt-bin uploads for lucid-proposed and maverick-proposed (versions 0.7.5-5ubuntu27.21 and 0.9.2-4ubuntu15.2, which I think have not yet been accepted)
<pitti_> hallyn: you mean libvirt?
<hallyn> pitti_: yeah
<pitti_> hallyn: rejected lucid upload, no upload for maverick
<pitti_> https://launchpad.net/ubuntu/maverick/+queue?queue_state=1
<hallyn> drat!  i meant oneiric, not maverick
<pitti_> hallyn: *flush*, gone
<hallyn> pitti_: thanks!  now i just need to put out the precise fire
<jibel> apw, I can't reproduce the EINVAL bug with kernel 201112070916.
<pitti_> jibel, apw: \o/
<jibel> apw, I let the test run 50 rounds with and without cpu and disk activity and no crash
<jibel> so looks good
<apw> jibel, most excellent, will see about gettting soemthign commit while we wait for upstream to decide
<cking> nice one apw
<pitti_> really, it's still a totaly miracle for me how you guys debug somethign like this
 * pitti_ bows
<pitti_> (and my typing sucks more and more after 11 hours on the computer, argh)
<apw> pitti_, your own stuff is always easier ... but primarily using brute force, i have build and booted about 20 or so kernels to track this puppy down
<apw> a fast builder is essential
<pitti_> apw: yeah, bisecting would be pretty much the only thing that would come to my mind, if it wouldn't take two hours to verify each step
<apw> pitti_, in this case we had some luck in that it is not normal to return EINVAL from write, so it was a detectible and therefore debuggable issue
<pitti_> seb128: bah, the new <glib.h> enforcement is nasty
<pitti_> seb128: I'm trying to fix awn-extras
<pitti_> but the part that includes parts of glib is in the vala-autogenerated .c source, so I can't patch it :(
<broder> pitti_: the includes to use come from the .vapi file, so you should be able to edit /usr/share/vala-0.14/vapi/glib-2.0.vapi
<broder> (vapi/glib-2.0.vapi in the vala source)
<pitti_> that seems fine, though
<pitti_> oh no, there it is
<pitti_> glib.h,glib/gi18n-lib.h
<pitti_> broder: thanks, will do that
<seb128> pitti_, we should maybe backport a patch in our vala if there is one needed
<pitti_> yes, I'll check this upstream
<seb128> pitti_, check if that's maybe fixed in .1, I just uploaded that vala update
<ant30> Hi, any body knows about sane-pnm (debugging module scaner) on oneiric or +1
<pitti_> seb128: I'll fix debian/watch for .tar.xz
<seb128> pitti_, oh, I forgot that right, thanks
<pitti_> seb128: how did you get the source?
<seb128> pitti_, wget
<seb128> I usually use the gnome ftp list emails and just wget the url
<seb128> I got used to that because at some point the watch integration stuff was downloading the tarballs twice
<seb128> I should check if that's still the case
<pitti_> seb128: ok, not fixed in 0.14.1
 * pitti_ checks trunk
<seb128> pitti_, we could also distro patch the single requirement out of glib
<seb128> pitti_, it's not something we technically "need"
<seb128> i.e I don't think it solved anything for us
<pitti_> also not fixed in vala trunk
<seb128> we might maybe just avoid the work for this cycle
<pitti_> seb128: yeah, it'll just cause tons of FTBFS :(
<pitti_> it's somethign nice for jhbuild and upstream devs
<pitti_> I'll report a bug against vala
<seb128> pitti_, http://git.gnome.org/browse/glib/commit/?id=7455dd370eb37ce3b0b409ff6120501f37b50569
<pitti_> but +1 for dropping the #error for now
<pitti_> seb128: I guess we could just turn #error into #warning to get an one-line patch?
<seb128> wfm
<seb128> it's probably easier that playing catchup on what they will change
<seb128> that->than
<seb128> pitti_, well it seems you will need to do it in each .h still?
<pitti_> I think it comes from /usr/include/glib-2.0/glib/gmacros.h:32
<pitti_> well, at least that's what I stumbled over, seems like a common include
<pitti_> seb128: ah, you are right :(
<seb128> pitti_, the commit says they do single include warnings since 2.17 which is years old, are we sure that's a very common issue?
<pitti_> I've seen it in two different packages now since I upgraded to 2.31 again today
<pitti_> I might just have been unlucky, of course
<seb128> pitti_, what include was it?
<pitti_> filed as gnome bug 665739
<ubottu> Gnome bug 665739 in Bindings: GLib "glib-2.0.vapi must only generate #include <glib.h>" [Major,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=665739
<slangasek> doko: what uploads are needed for libjpeg-turbo?
<pitti_> seb128: I'll send a patch there and upload vala for now; but we should still keep reverting this as an option if it causes too much failure IMHO
<doko> libjpeg-turbo, and libjpeg8, prepared by tgall_foo
 * tgall_foo appears
<seb128> pitti_, $ find . -name *.h | xargs grep include | grep "#include <glib/"
<seb128> pitti_, did that on my disk with 164 different subdir in my ubuntu packages checkouts dir, I found only awn which has issues
<slangasek> doko: ok, just the two packages then?  that doesn't sound too bad :)
<slangasek> doko: I was worried when you said "uploads" that reverse-deps needed rebuilt or something
<seb128> pitti_, it doesn't seem very common, at least in the default install desktop set, I think I've most of it covered on my disk
<doko> slangasek, no, just replacing the jpeg implemenation. it should work fine (tm)
<slangasek> right :-)
<pitti_> seb128: why do you only consider .h files?
<seb128> pitti_, "find . -name *.h | xargs grep "#include <glib/"" is probably easier ;-)
<pitti_> seb128: yes, I'm working on awn-extras ATM
<bdmurray> slangasek: so multiple languages are affected by bug 898787?
<ubottu> Launchpad bug 898787 in ubiquity (Ubuntu) "(k|l|x)ubuntu 11.10 failed to install with error in install_misc.py assert cache._depcache.broken_count == 0" [High,Triaged] https://launchpad.net/bugs/898787
<pitti_> seb128: but good to know
<slangasek> bdmurray: yes - we can probably scrape the relevant language info from each of the reports
<bdmurray> slangasek: of the bug reports or ...?
<seb128> pitti_, it's running for .c now, I could have done both in one run indeed ;-)
<slangasek> bdmurray: the bug reports, yes - that's where I found sv_SE for the one
<seb128> pitti_, same for .c, only awn that I can see
<pitti_> cool
<pitti_> and vala stuff can be fixed in one go
<seb128> pitti_, let's wait a bit see how it goes, if it turns to be an issue we can turn if off
<pitti_> seb128: I had one other rebuild yesterday which failed, someting in the poppler chain
<seb128> pitti_, well I'm sure we will have some issues out of the desktop set
<seb128> pitti_, GNOME seems to be well disciplined on fixing that sort of stuff, other upstreams might care less
<pitti_> seb128: yeah, using jhbuild as a developer helps a lot with that
<seb128> pitti_, oh btw, it's 6pm you really should stop working :p 6am to 6pm is enough ;-)
<seb128> pitti_, you make me feel bad for starting hours later than you if you don't finish hours earlier than me :p
<pitti_> heh
<pitti_> seb128: I took a long break two hours ago, 'sok
<seb128> ;-)
<pitti_> I think I got awn-extras to build, just one remaining thing
<pitti_> so that, forward vala patch to gnome, upload vala, upload awn, then done :)
<pitti_> built! yippie
<nxvl> pitti_: i'm trying to sync virt-viewer and i get a "package is blacklisted" message from syncpackage, how can i check why is it blacklisted?
<nxvl> pitti_: or who should i poke
<cjwatson> nxvl: It has Ubuntu modifications.  You need to use -f
<Laney> it is syncpackage telling you that there's an ubuntu diff
<Laney> what did the message say?
<pitti_> nxvl: it's not blacklisted in dak; does it really say "blacklisted"?
<Laney> https://launchpad.net/ubuntu/precise/+localpackagediffs?field.name_filter=virt-viewer&field.package_type=all&field.package_type-empty-marker=1
<nxvl> cjwatson: oh, that's the blacklisting for? that's what i wanted to make sure before i force it
<nxvl> pitti_: http://paste.ubuntu.com/762936/
<nxvl> pitti_: but cjwatson might just posted the answer
<pitti_> nxvl: so, not blacklisted in DAK; I suppose it's blacklisted in Launchpad's brain
<Laney> I just linked that.
<nxvl> pitti_: yay for lp
<cjwatson> Right, so it told you what option to use, it was just unclear about why.  (I'm pretty sure there's a bug about this.)
<Laney> it's actually fixed in newer versions to ignore that
<nxvl> cjwatson: yes, indeed, i just wanted to make sure it was blacklisted because of the ubuntu changes and not really blacklisted because something else
<nxvl> cjwatson: thanks!
<jamespage> cnd: python-libavg has been dropped from the archive in precise which puts a question mark over empcommand - is this something that you want to see in the archive still?
<pitti_> cnd: we can also reintroduce libavg as an ubuntu-only package, when we need it (it was removed in Debian and we followed suit)
<cnd> pitti_, jamespage: ubuntu's libavg was different than debians
<cnd> ubuntu's was being maintained by libavg directly, with my help
<pitti_> cnd: ok, so we should reintroduce it?
<cnd> pitti_, yes please
<pitti_> cnd: ok; sorry for the hassle
<cnd> pitti_, np, it's a corner case :)
<pitti_> jamespage: hrmpf, awn-extras is FUBAR; I'll continue this tomorrow
<pitti_> hm, is it just me, or is uploading packages really slow today?
<pitti_> jamespage: I'm uploading libavg, and then call it a day
<jamespage> pitti_, I think it is a bit - I had put it down to my ADSL upstream being slow
<pitti_> cnd, jamespage: libavg source NEWed, will binNEW later when it's built
<jamespage> pitti_, thanks!
<seb128> jamespage, pitti_: uploads are slow today, I dputed from a canonical box to avoid downloading and uploading a tarball from here and it was slow as well
<pitti_> hmm
<pitti_> Package: python-libavg
<pitti_> Architecture: i386 amd64
<pitti_> jamespage: ^ how come that empcommand is also broken on armel/powerpc?
<pitti_> cnd: ^
<pitti_> it seems libavg was only available on i386 and amd64 before
<pitti_> jamespage: so we might need to fix empcommand to be on those two arches, too
<pitti_> instead of arch: all
<pitti_> or build libavg on arch: any if possible
<jamespage>  pitti_: it looks like there is a really old version of libavg in for armel,powerpc
<jamespage> 1.0.1-1ubuntu4
<pitti_> but there can only be one version of libavg
<pitti_> unless you copy/rename the source
 * pitti_ waves good night, cu tomororw
<cjwatson> jamespage: we aren't always great at removing stale binaries when architectures stop being built
<pitti_> oh, that wouldn't hit the NBS report?
<pitti_> i. e. if you change a package from all/any to e. g. i386 amd64?
<cjwatson> I'm not sure it necessarily dodes
<cjwatson> *does
<pitti_> or it did and we just didn't clean it up so far?
<cjwatson> just going from empirical evidence I've vaguely noticed ...
<pitti_> ok, thanks
<pitti_> anyway, that's all "tomorrow" stuff; good night everyone!
<pitti_> I'm still server-less and thus without IRC proxy and mail FYI :(
<RoAkSoAx> can an AA please process gfs2-utils from the new queue?
<tsdgeos> hi, why is there no xcb-xinput-dev  ?
<tsdgeos> are we blocking it for any particular reason?
<micahg> cnd: re libavg, is there any reason why it couldn't be maintained in Debian as well?  The RC bugs were things that we would've fixed along the way anyways (binutils-gold and boost transition)?
<cnd> micahg, the libavg team wanted to maintain it, and they felt they were not fit to maintain it for debian
<cnd> they came to the utouch team showing us how they had integrated multitouch
<cnd> so it seemed silly to turn them away
<cnd> so I helped them get it packaged for ubuntu
<cnd> the libavg team only runs ubuntu, no debian installs
<cnd> there's no reason it couldn't be maintained in debian, it just wasn't a feasible option at the time
<cnd> tsdgeos, there's no such thing as xcb-input-dev because xcb doesn't support XInput yet :(
<micahg> Laney: or tumbleweed ^^ is there anything we can do in this case?  would it be better to blind upload to Debian (I assume the sponsor will build test at least) or just have the package in Ubuntu?
 * broder maintains a package in debian in spite of not having any debian installs
<broder> (just debian chroots)
<tumbleweed> micahg: I mailed the ubuntu uploader about this too
<tumbleweed> the bug for filing its removal from debian clearly noted that there was active maintainance in UBuntu, and offered sponsorship
<micahg> cnd: ^^ so, would you be willing to move the maintenance to Debian then, might get a few more bugs?
<tumbleweed> broder: ...I only have one Ubuntu install... (and don't do much real work on it :P )
<cnd> micahg, I personally don't have enough time to move it to debian :(
<cnd> at least, not in this cycle
<tsdgeos> cnd: are you sure? i have someone here in archlinux that says to have that file
<tsdgeos> or is the file there but just does nothing?
<cnd> tsdgeos, 99% sure
<cnd> unless it's something that was created in the past two months
<tsdgeos> cnd: http://xcb.freedesktop.org/manual/group__XCB__Input__API.html ?
<cnd> tsdgeos, http://lists.freedesktop.org/archives/xcb/2010-August/006414.html
<cnd> I think that is still the case
<tsdgeos> ok
<cnd> but I could be wrong
<cnd> tsdgeos, you should ask on xorg-devel@lists.x.org or on #xcb
<cnd> if you want to be sure
<stgraber> Is it just me or is upload.ubuntu.com horribly slow today? (as in, multiple minutes for a few KB to upload)
<stgraber> (latency looks good and I didn't notice any slowness on anything else in the DC)
<broder> pitti and jamespage were complaining earlier
<stgraber> good, not just my broken internet then :)
<hallyn> stgraber: it's not jsut you
<hallyn> and now i'm about to upload a new qemu-kvm .orig.tar.gz.  this is gonna be painful
<stgraber> hallyn: yeah, so far I pushed really small packages, next ones are a few SRUs for Edubuntu, these are ~10MB so won't be as much fun :)
<kees> where did the launchpad.net/bugs/NNN short-cut go?
<broder> kees: wfm, though i've started using pad.lv/NNN instead
<jelmer_> kees: still seems to work here
 * kees scratches his head
<kees> ah! it's not there for http.
<mdeslaur> kees: huh? wfm
<kees> mdeslaur: it wasn't for me.
<infinity> Yeah, works over http too...
<infinity> kees: Still, Martin's pad.lv is less typing. :)
<kees> weird. not it works.
<kees> *now
<mdeslaur> kees: must be your arp-spoofed default gateway
<kees> hrm. chromium doesn't show failed connection attempts.
<kees> I wonder if my vpn broke DNS for a minute or something
<kees> and https must have triggered a re-pinning or something.
 * kees shrugs
<hallyn> cyphermox: the libnl3 fix for bug 856209, is there a reason not to forward that to debian?
<ubottu> Launchpad bug 856209 in network-manager (Ubuntu) "NM fails to set IPv6 default route when IPv6 details entered manually" [High,Fix released] https://launchpad.net/bugs/856209
<cyphermox> hallyn: yes, now there is ;)
<cyphermox> hallyn: I'm working with Heiko Stuebner to get libnl3 3.2.3, which should be in experimental real soon; and includes that fix
<cyphermox> unless you're running in a debian issue with this? but NM was afaik the only thing affected, and mbiebl is also very eager to get the new libnl3 in debian
<hallyn> cyphermox: ok, cool!  I was just considering syncing from sid to get rid of the classid warning with netcf
<hallyn> i can wait for a better sync :)   thanks much
<cyphermox> ah, but we should indeed fix this
<cyphermox> merge maybe?
<cyphermox> actually, give me a second, I think I've already looked at it, and there's an issue with that debian revision anyway
<hallyn> sure, should be trivial, but how soon will the 3.2.3 be coming?
<hallyn> oh
<cyphermox> soon depends on how fast d-i, wpasupplicant and others can be fixed (transition from libnl3-dev to (libnl-3-dev and maybe others))
<hallyn> cyphermox: ok, well netcf doesn't *break* bc of it, it just spits out warnings
<cyphermox> hallyn:   * debian/libnl-3-200.install: netlink config files should be installed to /etc/libnl, not /etc/libnl3.
<cyphermox> that seemed to be important, the files in /etc/libnl3 wouldn't get searched for anyway
<cyphermox> so if you want to fix it (and I think we should), it's just a matter of installing the classid and that other data file to /etc/libnl
<cyphermox> hallyn: or I can take care of it
<hallyn> cyphermox: whatever is your preference.  Well, if you don't mind, I'll leave it to you :)
<cyphermox> hallyn: ok ;) I'll re-test it just in case, but I'm pretty sure the files didn't get read if they were in /etc/libnl3
<hallyn> cyphermox: thanks again
<bdmurray> @pilotin
<udevbot> Error: "pilotin" is not a valid command.
<infinity> bdmurray: Every day, you're pilotin'?
<bdmurray> I'm plotin everyday
<RoAkSoAx> TheMuso: ping
<bdmurray> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bdmurray
<kees> infinity: thanks, now I have to get that earworm out of my head
<infinity> kees: Try tweezers.
 * kees will use Nyan Cat
 * infinity has had Tim Minchin's "If I Didn't Have You" stuck in his head for days.
 * kees is worried
<kees> infinity: heh, this is good :)
<bdrung> tumbleweed: ubuntu-safe-to-upload is a long name. what about "safe-ubuntu-upload"?
 * micahg thought it was going to change to is-seeded
<tumbleweed> yeah, that's probably a reasonable name for it
<hallyn> hm, can't get to lp right now
<slangasek> ScottK, cjwatson: I'm not sure what pitti did the other day to fix the langpack problem, but I still see a lot of langpacks in oneiric-proposed that have not been copied to oneiric-updates, and they're *not* showing up as candidates on http://people.canonical.com/~ubuntu-archive/pending-sru.html
<ScottK> slangasek: AFAIK he copied the one I was missing (It was the KDE en base one, whatever that's called)
<ScottK> I don't think he did anything else.
<slangasek> ok
<bdmurray> is pending-sru tied to bugs?
<slangasek> bdmurray: tied how?  It tries to grab a list of SRU bugs from the .changes files and track their verification status
<slangasek> oh, you mean, does it depend on there being bugs in the changelog for a package to show up there?
<bdmurray> yes
<slangasek> it doesn't - but language packs are special cased anyway
<slangasek> and the special-casing keys on the English langpack
<seb128> slangasek, I don't know the details but I will mention that anyway in case:
<seb128> https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA
<seb128> slangasek, it seems they upload all locales to proposed but move to updates only the one verified by their team doing the translations
<slangasek> seb128: right, well, the current problem is that only some packages were copied to -updates for each language, making some of them uninstallable
<slangasek> can't copy language-pack-$foo-$lang without also copying language-pack-$foo-$lang-base, etc
<seb128> slangasek, ok, that's where I step out and pretend I was not there ;-)
<bdmurray> seb128: why was the sponsors subscribed to bug 886205?
<ubottu> Launchpad bug 886205 in upstart (Ubuntu) "Disabling network-interface break rc-sysinit compatibility script" [Undecided,New] https://launchpad.net/bugs/886205
<seb128> bdmurray, because of https://launchpadlibrarian.net/84431732/rc-sysinit.conf.diff ?
<slangasek> seb128: https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA is completely outside the standard SRU process and this is the first I've heard of it as a member of ubuntu-sru... do you know who's managing this publication process?
<seb128> bdmurray, why shouldn't sponsor be subscribed?
<doko> infinity, we should have finished the armhf builds before new glib/gtk uploads :-/
<bdmurray> I thought the sponsors team was more for debdiffs than just diffs
<bdmurray> and that the ubuntu-reviewers team was for patches
<seb128> slangasek, no, I just know that a "Kenneth Nielsen" does call for testing and thanks for testing emails to ubuntu-translators@lists.ubuntu.com listing that wiki
<seb128> slangasek, so it seems their process is "publish to proposed, call for testing on the translator list, move things which get validated"
<seb128> slangasek, but I'm not well informed, it's my view as an external watcher
<seb128> bdmurray, we have some thousand said "patches" in launchpad and ubuntu-reviewers is pretty much stalled
<seb128> bdmurray, I try to push things that seems like they would be useful to sponsors so they get a chance to make it in
<bdmurray> seb128: okay, I was asking because I was worried by bug bot had made a mistake
<seb128> bdmurray, it usually works fine, most sponsors are happy to sponsors patches which are not debdiff and we got quite some fixes uploaded this way
<slangasek> SpamapS: ^^ hi, is there some under-documented policy for langpack SRUs being followed nowadays?
<seb128> bdmurray, they is lot of noise and useless stuff in the review team queue though, I usually spend an hour to take 15 out of the most recent hundred or something
<bdmurray> seb128: sure, that makes sense to me
<seb128> bdmurray, great ;-)
<bdrung> tumbleweed: there are still merge markers in this branch
<tumbleweed> bdrung: ok, let me clean it up and rename it...
<SpamapS> slangasek: I had wondered the same thing last cycle when a similar flood of SRU's arrived for natty.
<slangasek> SpamapS: well, historically the SRUs are all batch-processed... but something else has happened this time and I'm not sure what
<bdmurray> where did the packaging guide go?
<slangasek> SpamapS: there was an SRU regression alert a week ago because of resulting uninstallabilities, and I've just tracked down another 3 packages that had the same problem :/
<SpamapS> slangasek: ugh
<seb128> bdmurray, http://developer.ubuntu.com/packaging/html/
<bdmurray> seb128: thanks
<seb128> yw
<broder> bdmurray: oh, sorry - i meant to deal with bug #886205 last night and forgot. i'll do so now
<ubottu> Launchpad bug 886205 in upstart (Ubuntu) "Disabling network-interface break rc-sysinit compatibility script" [Undecided,New] https://launchpad.net/bugs/886205
<tumbleweed> bdrung: done
<seb128> broder, thanks ;-)
<bdrung> tumbleweed: "audacity's binaries are not seeded" is a full sentence
<bdrung> tumbleweed: the seeded list isn't nicely formatted
<bdrung> maybe use more lines
<tumbleweed> bdrung: micahg was complaining that there was too much duplicated output when I used more lines :P but I can do something inbetween :P
<ScottK> Use both more and fewer lines.  That will make everone happy.
<broder> Not me. I want exactly the same number of lines
<bdrung> tumbleweed: maybe with a switch
<tumbleweed> noooo
<bdrung> --long
<bdrung> ubuntu-upload-permission output looks nicer
<ScottK> tumbleweed: Make the option --bdrung
 * tumbleweed should have named wrap-and-sort's -s  --stefanor
<doko> In file included from ../../src/ario-util.h:21:0,
<doko>                  from ario-filesystem.c:28:
<doko> /usr/include/glib-2.0/glib/gslist.h:28:2: error: #error "Only <glib.h> can be included directly."
<doko> seb128: ^^^ what is the recommend recipy to fix this?
<doko> seeing ~100 build failures because of this
<seb128> doko, what the message say
<seb128> doko, just include glib.h, not the individual ones like gslist.h
<doko> seb128, I do see 100 build failures for the time after glib was uploaded. so this will turn into some hundreds in the end
<seb128> doko, we discussed it with pitti, see log around 19h european time
<seb128> doko, we discussed whether revering it, seems like we should do it
<seb128> doko, the commit upstream is http://git.gnome.org/browse/glib/commit/?id=7455dd370eb37ce3b0b409ff6120501f37b50569
<seb128> doko, basically that's a warning since 2.18, which means since 8.10, upstream though most softwares would have been fixed in 3 years, seems not
<doko> seb128, please could you revert it for now? it really hurts the armhf bootstrap
<seb128> doko, ok, we were discussing it with pitti earlier as said but we were unsure if that was a frequent issue, good to get some datas, sorry that it has been hitting you in your work :-(
<doko> seb128, I'm fine to do a test rebuild with this upstream change, but getting this untested into the archive is the wrong way
<seb128> doko, we didn't get this in the archive, we got a new glib where they enforced something which was a warning for 3 years
<seb128> well we got it, but we didn't mean to break stuff
<seb128> it was just part of a new glib version
<doko> yeah, so please could you revert it for now, at least until armhf is built?
<seb128> I'm on it
<doko> thanks
<seb128> you're welcome
<bdrung> ScottK: --bdrung or the env variable WORLD_DOMINATOR is set to true :D
<seb128> sorry for the issues
<tumbleweed> bdrung, micahg: http://paste.ubuntu.com/763211/ compromise?
<cjwatson> hallyn,stgraber: we should have escalated that upload slowness earlier :-(
<cjwatson> hallyn,stgraber: seems that it was an early warning sign of impending LP lots-of-stuff-falling-over that we failed to pass on
<tsdgeos> cnd: you are in the xcb channel, but i'll repeat it here "does xcb support xinput?" <pharris> Most of it.
<bdrung> tumbleweed: yes
<doko> infinity, ^^^ now that hubbard is turned to manual and after the glib update it would be good to give back all armhf builds
<bdrung> tumbleweed: i maybe would start the line always with the binary package, e.g. glibc-doc (from eglibc) is seeded in:
<infinity> doko: Yeah, can do.
<infinity> doko: Why manual hubbard, though?
<doko> <doko> hmm, https://launchpadlibrarian.net/86854809/buildlog_ubuntu-precise-armhf.acetoneiso_2.3-1ubuntu1_FAILEDTOBUILD.txt.gz
<doko> <doko> Architecture: linux-any
<doko> <doko> isn't this handled by soyuz?
<doko> <wgrant> doko: We patched sbuild last week to use the chroot's dpkg-architecture.
<doko> <wgrant> That version of sbuild isn't out everywhere.
<infinity> Oh, bah.
<infinity> doko: Someone swapped hubbard to armhf. :(
<infinity> doko: Any idea who?
<infinity> doko: It should be armel until the updates.
 * infinity fixes.
 * doko avoids the question
<infinity> So, it was you?
<doko> infinity, ENOPERM
<infinity> You have perms...
<wgrant> infinity: 'twasn't me.
<infinity> Did you give back all of hubbard's failures?
<infinity> Well, all the ones due to that? :P
<infinity> Doesn't matter if I'm doing a mas-give-back after glib2.0 anyway, I guess.
<doko> I assume so
 * cjwatson does a quick grep for those failures
<lardman|home> evening, I'm trying to boot an ARM core image and can't seem to find what the username:password combo should be, any hints?
<infinity> lardman|home: There isn't one.
<infinity> lardman|home: You can't just boot core as-is, you need to set up either a password for root or create a user, or seed in an installer to do those for you.
<infinity> lardman|home: It's meant as a small rootfs to build on top of, not a bootable system.
<lardman|home> infinity: ah I see
<lardman|home> sure, I'd installed some other packages but didn't think to create a user, my fault
<lardman|home> thanks
<infinity> lardman|home: If you have no actual need for users (plenty of embedded systems run as root only, for instance), you could just chroot in and run passwd for root.
<lardman|home> infinity: it's a direct boot on a Samsung Galaxy Tab, so I will need to login somehow
<lardman|home> I'll chroot on my pc and give root and password and go from there
<hallyn> drat.
<cnd> tsdgeos, argh, he quit before I could ask a follow up
<cnd> I'm wondering if it's still disabled by default
 * infinity taps his foot and glares at this GHC build still going.
<cnd> if not, then it should be packaged up in debian
<infinity> I guess I should be happy that it hasn't failed...
<doko> infinity, with the give back you'll get the gdc rebuilds for free
<cjwatson> infinity,doko: I've given back the five linked from the ubuntuwire index (acetoneiso advi afterstep anjuta open-invaders)
<doko> \o/
<cyphermox> hallyn: there's a merge bug and branch up for sponsoring; bug 901438
<ubottu> Launchpad bug 901438 in libnl3 (Ubuntu) "Please merge libnl3 (3.0-2) from Debian" [Wishlist,In progress] https://launchpad.net/bugs/901438
 * cyphermox -> dinner
<hallyn> cyphermox: great, looks good, thanks.
<Juayz> Hello
<Juayz> is there support for Malay Brunei language in ubuntu?
<slangasek> Juayz: information about Ubuntu language support in general can usually be found at https://translations.launchpad.net/ubuntu.  However, it doesn't appear that there's a recognized international language code for "Malay Brunei" at all, making it impossible for me to say if there's any support for that - is this language known by another name?
<slangasek> alternatively, if you happen to know the ISO code for this language...
<Juayz> Melayu Brunei
<Juayz> this is the official Malay language of the State of Brunei
#ubuntu-devel 2011-12-08
<slangasek> the ISO language list (ISO 639-3) mentions languages "Bisaya, Brunei" (code: bsb) and "Brunei" (code: kxd) as well as a lot of different "Malay" languages
<slangasek> there is Malay support in Ubuntu, but I don't know if it's a dialect that's acceptable / understandable in Brunei
<cjwatson> http://en.wikipedia.org/wiki/Brunei says "Bahasu Melayu" and following links says that's msa
<cjwatson> (ISO 639-2T/3)
<cjwatson> oh, or ISO 639-1 "ms"
<cjwatson> eglibc has an ms_MY.UTF-8 locale
<broder> that article also claims that the variant of Malay in Brunei and most other Malay dialects aren't mutually intelligible
<cjwatson> however I gather that Malay as spoken in Malaysia vs. Brunei isn't ... what you said
<cjwatson> there's no msa_* or *_BN in /usr/share/i18n/SUPPORTED so I conclude that there is very little if any support for this language right now
<Juayz> who is the boss of this project?
<cjwatson> looking for bosses of free software projects generally indicates some degree of confusion :-)
<cjwatson> http://www.eglibc.org/ is the eglibc project
<broder> cjwatson: would eglibc not use something like kxd_BN? (http://www.sil.org/iso639-3/documentation.asp?id=kxd)
<Juayz> they are responsible for translations?
<cjwatson> no, only for the base locale metadata
<cjwatson> broder: ah, maybe - but they don't have that entry right now
<Juayz> ok if someone is doing this project for malay i want to know because many people here want to see it
<cjwatson> https://wiki.ubuntu.com/Translations has a bunch of information on how translations in Ubuntu work in general
<cjwatson> e.g. https://wiki.ubuntu.com/Translations/KnowledgeBase/AddingNewLanguage
<slangasek> Juayz: as a general rule, free software translations happen when people who speak the language and care about the software get involved and make it happen from the ground up
<cjwatson> if there is anyone working on this project, then they have not got very far yet, so if I were you I would treat it as if you were the first and maybe you'll link up later
<Juayz> ok cjwatson thank you mr.
<slangasek> we can provide pointers to help you get started (as cjwatson is doing), but that's probably about all
<Juayz> also slangasek
<Juayz> how much is to translate?
<Juayz> how many words?
<cjwatson> an absolutely ginormous amount
<Juayz> estimate?
<broder> it looks like oneiric had something on the order of 380000 strings
<Juayz> 380,000 lines?
<broder> more like phrases
<broder> some would be long and some would be quite short
<Juayz> ok.
<cjwatson> ideally sentences, although not all projects will keep to that
<Juayz> is there statistics for this?
<Juayz> how long it takes for how many people to make it
<broder> there's no requirement that *everything* be translated for a language to be included at all, though
<cjwatson> somebody on #ubuntu-translators might have more idea about that kind of detailed question
<Juayz> ok thank you.
<cjwatson> most developers would be aware of the basic infrastructure involved but not of the quantities
<Juayz> this is important for investment calculations
<cjwatson> I understand, but don't have the numbers you want
<Juayz> Is there some country that uses linux in government and municipal office computers?
<Juayz> in desktops
<cjwatson> Juayz: http://en.wikipedia.org/wiki/List_of_Linux_adopters#Government has a number of examples
<bdmurray> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<micahg> tumbleweed: seeded-in-ubuntu or ubuntu-seeded?
<ScottK> lool: clamav built on armhf in Debian.  Thanks for the tip: https://buildd.debian.org/status/package.php?p=clamav
<pitti_> good morning
<psusi> good night ;)
<micahg> pitti_: are the font renames done?  I was going to spin up a new xubuntu meta
<pitti_> micahg: so far, yes
<pitti_> eh? the -omap4 kernel went to -1402, and now back to -1401?
<dr3mro> please I need to know something .. does ubuntu sync packages with debian stable ?? when they are released ?? or just keep the unstable snapshot it had and wait for the next sync with next ubuntu release ??
<micahg> dr3mro: we normally sync with unstable until Debian Import freeze which is 7-11 weeks into the development cycle, for the LTS, we've been syncing from testing
<pitti_> dr3mro: we don't sync with debian stable
<pitti_> dr3mro: we stop auto-syncing as micahg says, but we often manually sync individual packages when checking that they don't break
<dr3mro> I mean if app X for example is in unstable repo of debian .. when it reach the stable repo .. does all fixes ported to ubuntu ?
<dr3mro> pitti_, what about fixed bugs upstream ?
<pitti_> dr3mro: no, we don't update ubuntu stable versions with all fixes, just selected ones
<pitti_> which are particularly urgent (data loss/security/regression), or particularly safe
<dr3mro> pitti_, does this apply even for LTS ?
<pitti_> yes
<pitti_> dr3mro: we _sometimes_ update stables to new upstream microreleases
<pitti_> e. g. we often upload new KDE 4.7.x or GNOME 3.2.x releases
<dr3mro> excuse me but doesn't that mean ubuntu will always has bugs debian has fixed months ago ??
<pitti_> dr3mro: https://wiki.ubuntu.com/StableReleaseUpdates has the details
<pitti_> in essence, yes
<pitti_> hundred known small and non-fatal bugs are much better than accidentally introducing just one regression
<dr3mro> pitti_, but why just use a branch of unstable and do whatever we ahve to to create ubuntu then merge back and release ?? so we benefit from upstream work ??
<pitti_> dr3mro: if someone actually _does_ this cherrypicking, it's fine
<pitti_> dr3mro: we just don't have a thousand developers to do this for all 30K packages for all N supported releases :)
<dr3mro> pitti_, so if i use LTS ? it has more bugs than lets say debian 6.0 ??
<pitti_> so in practice it only happens for a small subset of packages
<pitti_> same argument -- it needs someone to do it
<micahg> the same package in Debian stable might behave differently in Ubuntu due to different library versions and toolchain feature
<pitti_> dr3mro: is this a general question, or do you have a particular package in mind?
<dr3mro> pitti_, general as I am experincing alot of crashes and lock downs since ubuntu 9.10
<dr3mro> pitti_, these never happend when i installed slackware, arch ,, i googled and find out about this unstable thing
<dr3mro> I Like ubuntu specific things .. like unity .. global menu .. PPAs , but I have another Q? are those apps avail to other distros ?
<pitti_> DreamThief: yes, of course; Debian packages some
<pitti_> they have upstream releases, project pages, upstream bug trackers, VCS, etc.
<pitti_> and are GPL
<pitti_> cjwatson: are the things in http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt generally important? i. e. should this really be zero, or is this more cosmetical for the optional <-> standard things, etc.? (I know that the required/essential bits are breaking bootstrapping)
<pitti_> jibel_: I noticed the new https://jenkins.qa.ubuntu.com/view/Precise/job/precise-problems-check/, nice! I have some ideas what else we should add there; can this be extended or is it meant to look at just one report
<pitti_> jibel_: in particular, it would be nice if this could yell if some reports few, if anyone ever looks at have something
<rickspencer3> hey pitti_ love to see that beer mug each morning :)
<pitti_> :)
<pitti_> rickspencer3: we got a fixed kernel for the EINVAL bug now, so the image tests should be a lot more stable now
<rickspencer3> yeah!!!!
<pitti_> jibel_, jamespage: propsed addition for the precise-problems jenkins test: http://paste.ubuntu.com/763513/
<pitti_>  it's in shell, if you need a script in a different language I'm happy to write one
<smoser> it looks like http://cdimage.ubuntu.com/releases/ has some incorrect stuff for 8.04/hardy
<smoser> ubuntu-8.04.1-dvd-amd64.iso
<smoser> i would have expected ubuntu-8.04.4-dvd-amd64.iso
<micahg> smoser: dvds aren't necessarily respun for point releases IIRC
<smoser> ubuntu-10.04.3-dvd-amd64.iso
<smoser> so they were for 10.04. maybe not for 8.04, but then we have the directories there, and there.
<smoser> i'm off to bd.
<micahg> smoser: no mention of DVDs here: https://lists.ubuntu.com/archives/ubuntu-announce/2010-January/000128.html
<micahg> whereas here there is: https://lists.ubuntu.com/archives/ubuntu-announce/2011-July/000150.html
<smoser> good enough.
<micahg> smoser: although neither does this, so no proof there: https://lists.ubuntu.com/archives/ubuntu-announce/2008-July/000112.html
<micahg> smoser: so I guess there could be something wrong :)
<cjwatson> pitti_: things below priority: important are relatively cosmetic
<pitti_> cjwatson: good morning
<pitti_> cjwatson: so e. g. py3.2 should move to "important" now, because it's in teh default install
<pitti_> cjwatson: I'm happy to make the adjustments
<cjwatson> yes, lsb-release has started depending on it again
<pitti_> cjwatson: I also proposed to include arch/prio-mismatches into the new precise-problems jenkins job, as usually few people look at it
<pitti_> and they aren't obvious
<cjwatson> jenkins seems a bit heavyweight, I don't want it showing up as failures
<cjwatson> also it's actually impossible to get priority-mismatches to zero right now due to some differences across architectures
<cjwatson> (anyway, I'm on holiday, I just looked in on the red window, so if you want to fix things up be my guest)
<pitti_> cjwatson: yep, thanks
<pitti_> jibel_, jamespage ^ ok, so let's skip the prio-mismatches addition
<jibel_> pitti_, good morning
<pitti_> jibel_: bonjour, ca va?
<jibel_> pitti_, Ã§a va et toi ?
<pitti_> jibel_: je suis bien, merci!
<jibel_> pitti_, I discovered this check this morning. patrickmw set it up, you should ask him for any change to this script.
<pitti_> jibel_: so, I'm happy to fix the one entry at http://people.canonical.com/~ubuntu-archive/architecture-mismatches.txt, but I'll hold off if you want to/can integrete it into precise-problems
<pitti_> jibel_: ah, will do; which timezone is he in?
<pitti_> jibel_: (I pretty much depend on IRC these days, still no email)
<jibel_> pitti_, he leaves in the middle of the desert, let me check
<pitti_> anyway, I'll watch out for him
<jibel_> pitti_, UTC-7
<pitti_> jibel_: thanks; so will try to catch him next week then, as I'll have to leave in the late afternoon today/tomorrow
<jibel_> pitti_, ok
<pitti_> jibel_: do you know whether the alternate/server tests already look at the generated report.html?
<pitti_> jibel_: e. g. http://cdimage.ubuntu.com/daily/current/report.html
<pitti_> if these are non-empty, we should totally have a red light
<pitti_> it's usually not even worth testing the images if there's anything in there
<pitti_> jibel_: looking at the current desktop/alternates failure
<pitti_> Dec  8 08:09:05 in-target: Error: update-openoffice-dicts not present or executable. Missing dependency on dictionaries-common?
<pitti_> dictionaries-common is installed on teh images
<pitti_> ok, it's due to https://launchpad.net/ubuntu/+source/dictionaries-common/1.12.0ubuntu1
<pitti_> rickspencer3: ^ it dropped update-openoffice-dicts, I'll figure out where it should live now
<pitti_> yay for catchign real issues
<pitti_> I'll re-spin once that's fixed
<rickspencer3> thanks pitti_ ... and well done, jibel_ and QA too!
<pitti_> rickspencer3: excellent case for the "revert" procedure
 * pitti_ grabs the fireman helmet and gets going
<pitti_> rickspencer3: bug 901572 FYI
<ubottu> Launchpad bug 901572 in hunspell-en-us (Ubuntu Precise) "update-openoffice-dicts not present or executable. Missing dependency on dict ionaries-common?" [High,In progress] https://launchpad.net/bugs/901572
<rickspencer3> thanks pitti_
<micahg> pitti_: are we not able to remove the need for that script?
<pitti_> micahg: yes
<pitti_> micahg: I'll investigate which dictionary packages are affected
<pitti_> micahg: I don't intend to permanently re-add update-openoffice-dicts
<micahg> ah, ok :)
<pitti_> question is now whether I should start fixing dictionaries first, or put back a no-op script first
<pitti_> and I think the latter is quick, safe, and unbreaks the world
<micahg> makes sense
<pitti_> workaround uploaded
<pitti_> takes the pressure out
<pitti_> looks like we'll need to rebuild 47 dictionary packages
<jibel> pitti_, is anyone working on bug 850264
<ubottu> Launchpad bug 850264 in apt (Ubuntu Precise) "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Triaged] https://launchpad.net/bugs/850264
<jibel> ?
<jibel> it's assigned to you but is a bug in apt
<pitti_> jibel: I'll work on a reproducer, and I also talked about it with Michael
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks
<pitti_> jibel: so yes, it's high-prio
<jibel> pitti_, ok thanks
<pitti_>  ppisati: hello Paolo
<pitti_> ppisati: the omap4 kernel went to -1402 and now _back_ to -1401; did something go wrong there or is that really deliberate?
<pitti_> ppisati: it's currently in binNEW and I didn't release it as it looks wrong
<ppisati> 3.0.0-1402.3 -> 3.2.0-1401.1
<ppisati> new kernel version, ABI reset
<ppisati> pitti_: ^^
<pitti_> ppisati: oh, that's not monotonous then
<pitti_> ppisati: ok, I'll update seeds and rebuild d-i for it, thanks
<pitti_> and binNEW it
<ppisati> pitti_: it's the same for master kernels
<ppisati> pitti_: it went to 3.1-[12345...].x -> 3.2-1.x
<pitti_> ppisati: ok, so "1400" is just the general offset for omap4 then?
<ppisati> yep
<ppisati> righty right my friend :)
<pitti_> ppisati: ok, thanks; that looked confusing at first :)
<pitti_> alright, binNEWed
<seb128> pitti_, did you talk to slangasek today?
<pitti_> seb128: no, I didn't
<seb128> pitti_, he was wondering about language packs and srus yesterday
<seb128> he said only part of the sets were copied and that it created issues
<pitti_> I thought I fixed all these
<seb128> <slangasek>	ScottK, cjwatson: I'm not sure what pitti did the other day to fix the langpack problem, but I still see a lot of langpacks in oneiric-proposed that have not been copied to oneiric-updates, and they're *not* showing up as candidates on http://people.canonical.com/~ubuntu-archive/pending-sru.html
<seb128> <slangasek>	seb128: right, well, the current problem is that only some packages were copied to -updates for each language, making some of them uninstallable
<seb128>  <slangasek>	can't copy language-pack-$foo-$lang without also copying language-pack-$foo-$lang-base, etc
<seb128>  
<seb128> pitti_, that's basically the summary
<seb128> he maybe sorted it, dunno
<seb128> I figured I would mention it
<pitti_> these are two different things
<pitti_> we only move the stuff to -updates which actually has been tested
<pitti_> but we forgot some -base packs from the previous run
<seb128> right, that I told him
<pitti_> that's a bit confusing
<seb128> pitti_, I pointed him to https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA
<seb128> pitti_, oh, he said "<slangasek>	SpamapS: there was an SRU regression alert a week ago because of resulting uninstallabilities, and I've just tracked down another 3 packages that had the same problem :/"
<pitti_> hm, we really should have a britney run for stable and stable-proposed
<seb128> pitti_, so yeah, he probably fixed them but he was unsure what is the process for those
<pitti_> in that case, just copying the missing -base packs as well
<seb128> pitti_, anyway I was just mentioning it for the record
<pitti_> seb128: thanks
<seb128> yw
<seb128> pitti_, still no server btw?!
<pitti_> ok, brb, switchign to IRC proxy
<pitti_> seb128: it came back 5 mins ago
<seb128> nice ;-)
<micahg> pitti: for magyarispell, you could've switch to source format 3 instead of repacking
<pitti> micahg: I actually tried merging with Debian's changes (whci also does that), but that package is such a mess that it'll take some time to actually finish this cleanly
<jamespage> pitti: Jenkins job setup - publishes to here - https://jenkins.qa.ubuntu.com/view/Precise/job/precise-priority-mismatches-check/
<jamespage> and notifies via email to ubuntu-testing-notifications of any mismatches!
<pitti> jamespage: nice, thanks!
<pitti> jamespage: can we get one for architectures-mismatches, too?
 * jamespage gets out his copy/paste magic
<jamespage> sure
<pitti> (which is actually the more interesting one)
<pitti> wget -q -O- http://people.canonical.com/~ubuntu-archive/architecture-mismatches.txt | grep -E '\[[[:alnum:]]+\]$'
<pitti> jamespage: ^
<pitti> if that succeeds, that's a FAIL
<jamespage> great - on it now
<pitti> ok, I think I nailed bug 901572 now
<ubottu> Launchpad bug 901572 in dictionaries-common (Ubuntu Precise) "update-openoffice-dicts not present or executable. Missing dependency on dict ionaries-common?" [Medium,In progress] https://launchpad.net/bugs/901572
<pitti> once it's all published, I'll re-spin images
<pitti> rickspencer3: so, 3 mins for the workaround vs. 2 hours of fixing it properly, I'd say it was worth it
<pitti> jamespage: remaining prios fixed, so that should go green in the next hour
<pitti> jamespage, cjwatson: uploading d-i for new omap4 kernel FYI
<pitti> (NBS)
<jamespage> pitti: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-architecture-mismatches-check/
<pitti> jamespage: nice, thanks!
<pitti> will upload the fix now
<pitti> pretty funny game, this "introduce new red dots and then catch up with them"
<jamespage> lol
<didrocks> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<bkerensa> seb128: bug 805480
<ubottu> Launchpad bug 805480 in gnome-utils (Ubuntu) "gnome-system-log crashed with SIGABRT" [Undecided,Invalid] https://launchpad.net/bugs/805480
<seb128> bkerensa, what about it?
<bkerensa> interesting bug
<bkerensa> :D
<bkerensa> lots of dupes and most have been invalidated
<bkerensa> :D
<bkerensa> I was able to reproduce in Oneiric and Precise so I moved it to confirmed and linked
<seb128> bkerensa, right, and what that has to do with me? seems like duplicates have been wrongly duplicated
<seb128> like they are not the same errors not the same steps
<seb128> somebody should open a proper bug for it
<bkerensa> seb128: k I will crash it and report it here in a sec :D
<seb128> thanks
<seb128> bkerensa, is your issue happening when uninstalling gnome-utils?
<seb128> bkerensa, urg, please undo what you did, you clearly dupped stuff which have nothing to do with that bugs and were valid bugs
<seb128> like the invalid free, the abort in the log function and yours are 3 different issues
<pitti> jibel, jamespage: rebuilding desktop/alternate/server images to pick up dictionaries-common fix
<doko> pitti, seb128: MIR needed for libpst (evolution)
<seb128> doko, it was in main until natty and demoted,stopped used by error in oneiric
<seb128> doko, do we need a mir again for it?
<seb128> like the build-depends was dropped by error which is why it got demoted, it seems like we should just promote it back?
<doko> ok, promoting
<seb128> doko, thanks
<infinity> It pretty much hasn't changed since natty, even.
<seb128> doko, did the glib update worked? i.e did it fix your build issues with the single include error?
<doko> seb128, yes, see http://qa.ubuntuwire.org/ftbfs/primary-precise-armhf.html
<seb128> doko, great ;-)
<jibel> pitti, alternate is back to normal but there's something wrong with oem install
<jibel> desktop and server are running/queued
<pitti> back from lunch
<jamespage> pitti: ack
<pitti> jibel: ah, that's why they are yellow now? looking at logs..
<pitti> jamespage: ok, so much for http://people.canonical.com/~ubuntu-archive/architecture-mismatches.txt, jenkins report is green now; thanks for adding this!
<jibel> pitti, Dec  8 13:21:09 finish-install: warning: /usr/lib/finish-install.d/01oem-config-udeb returned error code 100
<infinity> doko: Were you doing an upload for gnat* at some point, or should I?
<infinity> doko: (Although, it'll need some actual bootstrapping anyway... *sigh*)
<jamespage> pitti, np
<doko> infinity, I don't doing you the bootstrapping =)
<infinity> doko: You also don't Englishing the morning this.
<ogra_> lol
<doko> infinity, I'll get a coffe now, get a single malt yourself ;)
<jibel> pitti, it's yellow because some post-install test failed
<pitti> jibel: right
<jibel> pitti, you can see the results of the tests in http://10.189.74.2:8080/job/precise-alternate-amd64_oem/105/artifact/105/test-results/TEST-oem.xml
<pitti> jibel: right, the assertion error
<jibel> pitti, in this case oem-config is not installed and there is no desktop link to prepare for shipping in the first stage of an oem installation
<pitti> jibel: I'll investigate this more closely in a bit, just finishing up something else
<cjwatson> oem looks broken due to hunspell-en-us, like everything else
<pitti> cjwatson: no, I rebuilt images an hour ago for thsi
<pitti> this
<cjwatson> oh, I'm looking at out-of-date jenkins logs then
<pitti> https://jenkins.qa.ubuntu.com/view/Precise/job/precise-alternate-i386_oem/lastSuccessfulBuild/
<cjwatson> (anyway, SEP today)
<pitti> ^ from 41 mins ago
<pitti> cjwatson: whatever "SEP" is, I think you're on vac :)
<infinity> pitti: Somebody Else's Problem.
<pitti> aah
<cjwatson> oh, it wants to remove python-gobject-cairo
<cjwatson> that's easy, we just uploaded ubiquity to fix that
<cjwatson> rebuild in an hour or two
<cjwatson> hm, wait
<pitti> that was yesterday already
<cjwatson> I think perhaps something else with a python-gobject-cairo dep needs to be fixed
<cjwatson> software-center maybe?
<pitti> yes, that's in bzr, but not uploaded yet
<cjwatson> that's what NBS says.  fix that and it should go away
 * cjwatson vacs
<pitti> mvo: ^ ok to upload current s-c bzr head?
<pitti> mvo: the changes in http://bazaar.launchpad.net/~software-store-developers/software-center/trunk/view/head:/debian/changelog look both safe and exactly what we need
<mvo> pitti: right, let me quickly look at a outstanding branch, ok? should also be safe and good and then I do the upload?
 * pitti hugs mvo, danke
<mvo> yw - I was slacking a bit with the recent merge requests, so I want to at least pick the easy ones into this upload
<doko> does somebody want to merge isdnutils?
<pitti> doko: hm, debian's version is even older than our's..
<doko> pitti, right, but never merged
<jibel> pitti, I can't install alternate, same update-openoffice-dicts error than this morning but on hyphen-en-us
<pitti> jibel: argh, that too? looking
<pitti> jibel: weird that the auto tests seemed ok?
<pitti> jibel: confirmed; I'll check these packages, too, thanks for pointing out
<jibel> pitti, indeed, I'll compare what's different from a manual install
<pitti> jibel: oh, that's presumably one of the packages which is installed from the network through the check-language-support stuff
<pitti> jibel: i. e. it's not in the live system
<pitti> jibel: the tests might do a networkless install?
<doko> barry, could you have a look at https://launchpad.net/ubuntu/+source/cython/0.15.1-1/+build/2961231
<doko> I assume it's the same for other archs
<barry> doko: sure, looking...
<jibel> pitti, the tests are running with full network support. Do you know what pulls hyphen-* during install ?
<pitti> jibel: if select English, it should be part of the extra language support for English
<jibel> pitti, ok, I'll diff both installs and will see
<pitti> jibel: I'm about to upload the fix, is that ok? or do you want to keep the current situation for examining this?
<jibel> pitti, that's fine I saved the logs
<pitti> uploaded
<pitti> jibel: doing an archive grep now for finding similar issues
<pitti> jibel: I added teh remaining affected packages to bug 901572, will go through them
<ubottu> Launchpad bug 901572 in hunspell-en-us (Ubuntu Precise) "update-openoffice-dicts not present or executable. Missing dependency on dict ionaries-common?" [High,Fix released] https://launchpad.net/bugs/901572
<pitti> jibel: but none of them are on the images or should be covered by the tests, so fixing them shouldn't block the next image test run
<doko> pitti, Sweetshark: these SA dictionaries really should be updated
<pitti> yeah, four years might be a bit outdated
<pitti> although I figure only we Germans are crazy enough to try and officially change our language once a decade :) but there's certainly a lot of new words
<doko> Riddell, qtmobility ftbfs on armel/armhf (symbols mismatch)
<slangasek> pitti: right, cjwatson is already looking into a britney for SRUs; in the meantime I've copied over the missing -base packages, but I'm still left wondering what the actual process is for publishing langpack updates - is it you personally monitoring that wiki page for test results?
<pitti> slangasek: when the official testing time is over, we copy the stuff that has been marked on the wiki page
<slangasek> pitti: but who is this "we", because this all lies outside of any SRU process I'm familiar with :)
<pitti> slangasek: but that process failed in that case, as the update _before_ the most recent one was a -base refresh
<pitti> so I need to look more carefully when copying next time and watch out for missing -base updates
<pitti> slangasek: ubuntu-translators are doing the actual verification, I'm just pushing the buttons for moving stuff between ppa, -proposed, and -updates
<pitti> we have a plan which apps to test to call a language update "verified"
<pitti> which is coordinated on https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA
<pitti> sorry, need to run for today, have an appointment; will catch-up tomorrow
<elmo> https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/extension-list <-- I don't understand this - isn't it outdated by firefox's modern works-with-anyversion plugin stuff?
<pitti> now that I actually have a server again, I'll have scrollback
<elmo> chrisccoulson: ^--
<chrisccoulson> elmo, that wiki is ancient and from a time when we had extensions in the archive
<elmo> chrisccoulson: it's referenced from the sync blacklist
<elmo> chrisccoulson: do we now not do extensions in the archive at all?
<elmo> I started a top this rabbit hole wondering why foxyproxy was packaged in Debian but not ubuntu
<slangasek> mvo: I've kicked bug #901638 in your general direction; if there's something I can do better in the tdsodbc metadata to make this upgrade work, please feel free to kick it back
<ubottu> Launchpad bug 901638 in update-manager (Ubuntu Precise) "tdsodbc failed to upgrade from Oneiric to Precise" [Undecided,New] https://launchpad.net/bugs/901638
<chrisccoulson> elmo, only for very special cases, decided mostly by me (ie, lightning and enigmail)
<chrisccoulson> and any extensions maintained by us
<chrisccoulson> but that's it
<elmo> chrisccoulson: ok - it'd be lovely if we could update sync-blacklist to say that
<elmo> (if someone wants to point me at bzr, I can propose a merge - the file helpfully says it's under bzr, but not where the canonical repo is)
<elmo> chrisccoulson: but umm, sorry, one other thing - why?
<chrisccoulson> elmo, because there is a significant overhead with maintaining in-archive extensions, and we can never do a better job than addons.mozilla.org
<chrisccoulson> eg, AMO provides updated compatibility metadata for addons hosted there, to prevent developers having to respin addons for new versions
<chrisccoulson> extensions in the archive don't benefit from any of that, meaning they need manual uploads every 6 weeks
<elmo> hmm, ok
<chrisccoulson> in addition to that, addons are frequently updated upstream to fix stability / security issues, and the ones in the archive were always left to rot and ended up hopelessly outdated
<elmo> chrisccoulson: well, that's not a firefox specific argument and just indicates packages that aren't well maintained
<mvo> slangasek: thanks slangasek, I will have a look (unfortunately burried in $stuff currently)
<slangasek> mvo: no hurry :)
<bolo56> hail !
<bolo56> o/
<bolo56> i upgrade ubuntu 11.04 kernel from 2.6 to kernel 3.0
<bolo56> but i can't mount the CD
<bolo56> also when i try to start xconfig i get an error
<bolo56> can anyone help me ?
<soren> If I install a package for the first time, and it contains a conffile, but that file is already on the filesystem... What happens? Does it get overwritten?
<barry> doko_: this is an interesting one.  package builds fine in an oneiric chroot for py2.6 and 2.7.  upstream tarball fails exactly the same way in a virtualenv w/2.7 on precise.  i'm testing upstream tarball in a virtualenv on oneiric in 2.6 and 2.7.  i wonder, could this possibly be a gcc issue?
<barry> doko_: source tarball in 2.6 virtualenv on oneiric passes
<doko_> barry, you could check with gcc-4.5 instead
<barry> doko_: will do after my 2.7+upstream+oneiric completes.  otoh, i'm using gcc 4.6.1 on oneiric and 4.6.2 on precise.  i wouldn't *think* that would make a difference, but i guess you never know ;)
<jamespage> doko_, do we have a icedtea-plugin package for openjdk-7? or is that superceeded by something else?
<doko_> jamespage, no. we need to build it for both openjdk's
<barry> doko_: is there a good way to change the default gcc?  i tried `export CC=gcc-4.5` and that builds source, but the tests fail with the following error
<barry> gcc-4.5 -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c a.cpp -o build/temp.linux-x86_64-2.7/a.o
<barry>  
<barry> gcc-4.5: error trying to exec 'cc1plus': execvp: No such file or directory
<barry>  
<infinity> barry: cc1plus?  You have C++ hidden in there?
<infinity> barry: If so, you want a CXX=g++-4.6 too.
<infinity> barry: It also could just be that you don't *have* g++-4.6 installed, so when you ask gcc-4.6 to operate on that obviously-C++ file, it has a sad.
<infinity> barry: s/4.6/4.5/
<doko_> barry, install g++-4.5 too
<barry> infinity, doko_ thanks, that looks like it did the trick
<micahg> elmo: re addons in the archive> we don't have the people power to update extensions in the archive in the stable releases, Debian has a frozen Iceweasel version in their stable release which allows them to package extensions
<barry> doko_: https://bugs.launchpad.net/ubuntu/+source/cython/+bug/901840
<ubottu> Ubuntu bug 901840 in cython (Ubuntu) "FTBFS due to test failures" [Undecided,New]
<nigelb> kees: Did Nyan Cat help? ;)
<nigelb> kees: unping. I was responding to something *ages* back.
<kees> nigelb: hehe :)
<nigelb> :D
<hallyn> smoser: fwiw, nested containers just worked fine for me - just make sure you use different subnets and differnet names (for different cgroups) for both
<Cheery> it's simple question and I know the answer, but I'm interested to hear if you've got something to add.
<Cheery> if I'd like to write an opengl application for ubuntu, what could I do?
<Cheery> my other information sources stay quiet
<Cheery> so I guess there's nothing done by ubuntu for that..
<hallyn> Cheery: maybe #ubuntu-desktop would have answers
<Cheery> hallyn: thank you. I'll check that channel
<hallyn> np
<hallyn> (it's not that we don't want to help, opengl is just probably not our forte :)
<Cheery> hallyn: there's large amount of 'you'. and ubuntu partially stands on a huge layer of other devs outside ubuntu.
<hallyn> of course.
<hallyn> that's how i can get away with not coding opengl myself :)
<Cheery> I don't worry about not signal on the channel.. because it seems ubuntu as a channel seem to sink into questions. ^^
<Cheery> still it's sort of funny I haven't seen widespread tools you use with ubuntu to develop content for it.
<broder> Cheery: you mean like http://developer.ubuntu.com/ ?
<Cheery> yeah. sort of like that
<Cheery> broder: though it's quite late and you'd have lot of other domains to go through as well.
<Cheery> of course, tools for just tools sake doesn't do much.
<Cheery> in particular what bothers me is that you haven't taken concepts of css and brought them into desktop GUI
<Cheery> yet in about every distupgrade you've had a new desktop style.
<infinity> Cheery: Eh?  Have you actually seen a GNOME theme?
<infinity> Cheery: "dpkg -L light-themes" and check out what comprises them.
<Cheery> oh you've gotten there..
<psusi> TheMuso, ping
#ubuntu-devel 2011-12-09
<TheMuso> psusi: Just ask your question, and I'll respond when I'm around. Whats up?
<psusi> TheMuso, are you going to take over maintainership of dmraid in debian, or do you just have upload rights?
<psusi> TheMuso, I have been trying to get our dmraid pages merged upstream and today I realized that debian has not updated to upstreams's last 3 releases... probably because they decided to call it .rc16-1, -2, and -3
<psusi> TheMuso, so today I rebased the patches on -3, which game out last year... and half of the patches went away as they were already merged.. I'd like to get debian and ubuntu both synced and up to date
<psusi> TheMuso, the one patch I wasn't sure about was the disable-dmreg one, as it appears to disable important upstream functionality dealing with failed disks in a mirror, so I just left that patch disabled for now
<bdmurray> slangasek: missing firmware for a network card on the alternate is a linux-firmware bug or something else?
<doko> infinity, https://launchpadlibrarian.net/87009585/buildlog_ubuntu-precise-armhf.hscolour_1.19-2_FAILEDTOBUILD.txt.gz  please build it in the bootstrap archive
<user> h
<user> hi
<bolo56> hail
<micahg> infinity: will germinate ignore packages that are missing in the archive for a certain arch?  I'm missing 8 packages for xubuntu-meta
<ScottK> micahg: It will
<micahg> :(, I guess I'll wait till the weekend
<ScottK> micahg: I don't understand why you'll wait?  It gives you a metapackage with whatever is there.   Once you get the rest, then you just upload it again.
<micahg> ScottK: xfwm4 is missing :)
<ScottK> I guess that's important ...
<micahg> and a few other xubuntu core packages
<micahg> hopefully by Sat night, I should be able to upload (no rush anyways)
<broder> micahg: got around to updating bug #900421 if you're bored and in a sponsoring mood
<ubottu> Launchpad bug 900421 in libsigc++-2.0 (Ubuntu) "Please convert libsigc++-2.0 for multiarch" [Wishlist,New] https://launchpad.net/bugs/900421
<broder> the glibmm one will come in a few minutes
<broder> ..oh, ugh. glibmm just stopped building because...glib killed off g_thread_init?
<broder> no, moved it to a separate library
<micahg> broder: ok, might take a look over the weekend if no one beats me to it
<mgodby> hello; my name is Matthew Godby, and I am currently diving into linux system administration and learning programming. I have the aim of becoming an Ubuntu developer, but I have a
<mgodby> couple of questions first
<mgodby> In the development of linux-based operating systems, is it more critical to know C or C++?
<ScottK> !ask | mgodby
<ubottu> mgodby: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<ScottK> It depends on where your focus is.
<ScottK> Generally I'd say C though.
<mgodby> could you give me one or two examples of advantages for each of those two languages?
<ScottK> Most Ubuntu development tasks are integration of code that's written elsewhere, so knowing something about shell and make is sufficient.
<broder> i think i'd recommend python as a starter language these days, though
<broder> and move to c after that
<ScottK> Agreed.
<mgodby> ah
<ScottK> If you're learning to program, Python is a very good place to start.
<mgodby> I started trying to learn Python but found it much more confusing than C
<ScottK> Also there is a significant amount of Ubuntu specialized code written in Python.
<mgodby> however, since it seems that it is a critical language, I will tackle it
<ScottK> (for example the Ubuntu graphicall installer is in Python)
<mgodby> excellent; I will look into the python tutorials suggested by the Ubuntu Wiki
<mgodby> I'm currently reading Ubuntu Unleashed and just finished the section "automating tasks" it taught me tons about shell scripting
<mgodby> alright, well thank you for your time! I will continue to work on C and learn Python as well; I appreciate the help
<ScottK> pitti: Uploaded KDE 4.7.3 for oneiric-proposed. It'd be nice to get it in on Friday so it can build over the weekend when things are usually quieter.
<pitti> Good morning
<pitti> ScottK: ack
<sladen> is it that time already.  oh
<slangasek> bdmurray: I would send it to debian-installer first
<slangasek> bdmurray: (the missing firmware on alternate issue)
<rickspencer3> pitti, yet another morning of having beer for breakfast!
<pitti> rickspencer3: hehe
<pitti> rickspencer3: I'm like a hawk on this now
<rickspencer3> :)
<pitti> rickspencer3: and so is jenkins, we have jenkins reports for this and {archive,priority}-mismatches
<rickspencer3> I saw that one
<pitti> today's alternates ought to fix the oem test failures
<pitti> (currently yellow)
<pitti> so we are pretty much down to fixing upgrades now
<pitti> that's now our top priority
<pitti> infinity: committed your d-i changes to bzr
 * pitti uploads another d-i to play whack-a-omap4-abi
<bolo56> hi guys
<infinity> pitti: d-i still seems a bit confused on armhf anyway.  I need to do some debugging tomorrow.
<pitti> infinity: and it failed to build, just filed bug 902051 about it
<ubottu> Launchpad bug 902051 in utouch-frame (Ubuntu Precise) "libutouch-frame1-udeb 2.0.0-0ubuntu1 causes d-i FTBFS" [High,New] https://launchpad.net/bugs/902051
<pitti> cjwatson: ^ I'm afraid I need your advice here; does d-i somehow blacklist/prevent libstdc++6?
<infinity> pitti: There's no libstdc++-udeb.
<infinity> pitti: udebs can't depend on normal debs.
<pitti> oh
<pitti> thanks
<pitti> infinity: I'll bug cnd then
<infinity> (And I'm not sure that bloating the installer with C++ is sane)
<pitti> agreed
<pitti> I wonder why we need a touch udeb in a text-based installer in the first place, but I might be missing something
<infinity> The udeb might be meant for ubiquity usage?
<pitti> infinity: I don't claim to understand the architecture there, but ubiquity runs in a full live environment, why does it have to rely on udebs? ubiquity itself isn't one
<pitti> and neither are many of its dependencies
<infinity> pitti: It doesn't.  It may be misguided on someone's part.
<pitti> cnd: input on bug 902051 appreciated
<ubottu> Launchpad bug 902051 in utouch-frame (Ubuntu Precise) "libutouch-frame1-udeb 2.0.0-0ubuntu1 causes d-i FTBFS" [High,Triaged] https://launchpad.net/bugs/902051
<infinity> pitti: (ubiquity imports d-i-related sources to build itself, someone may be missing how all that works)
<infinity> pitti: Or maybe we really do want a touch UI for text-based d-i.  I mean, at least an on-screen keyboard would be helpful. :P
<pitti> but multitouch?
<infinity> Probably less helpful.
<infinity> Gestures for quick navigation from combo boxes to buttons? :)
<infinity> Yeah, I've got nothin'.
<pitti> jibel: FYI, filed lts->ubuntu as bug 902077, reproducing/confirming/working on fix now
<ubottu> Launchpad bug 902077 in libdrm (Ubuntu Precise) "lucid->precise upgrade failure due to libdrm-nouveau1a Conflicts:" [High,Triaged] https://launchpad.net/bugs/902077
<pitti> jibel: hm, I don't think it's that Conflicts:; dist-upgrade will install -1a and remove -1 just fine, must be something else; I'll dig deeper
<pitti> jibel: oh, are the lts->ubuntu tests done with main/restricted only? no universe?
<pitti> if so, then I know what's wrong
<pitti> hm, same problem with universe; argh
<pitti> jibel: ok, got it; the question is still interesting, though; I'll fix it for "universe enabled", but "only main" needs a quirk in release-upgrader
<infinity> pitti: Ugh.  Why the quirk? :/
<infinity> I hate having to have upgrader workarounds...
<pitti> infinity: better ideas appreciated
<pitti> infinity: we can add a Conflicts: to all of them
<pitti> infinity: but that would break people who actually _use_ these drivers
<pitti> even those who have universe enabled, which should be "almost everyone"
<infinity> pitti: What's the actual issue?
<pitti> infinity: bug 902077 has the full story
<ubottu> Launchpad bug 902077 in xserver-xorg-video-nouveau (Ubuntu Precise) "lucid->precise upgrade holds back X.org video drivers" [High,Triaged] https://launchpad.net/bugs/902077
<infinity> (And, actually, I run a lot of main-only systems)
<pitti> infinity: in short, lucid's xserver-xorg-video-all depends on a few old drivers which went to universe
<pitti> so with a "main only" system, the upgrade to precise will hold back the entire X.org stack
<pitti> (with apt-get dist-upgrade)
<pitti> or just fail the update (do-release-upgrade) as it can't calculate an upgrade path
<infinity> I don't suppose we can question why the drivers are in universe at all?
<pitti> you mean instead of killed completely?
<infinity> I know it's "old hardware" and all, but it seems unclever to drop support for old video cards.
<pitti> they still work, just aren't supported any more (LTS/X.org team)
<pitti> or even upstream, I suppose
<ogra_> infinity, oh, while i see that, did you plan to work on the in-initrd drm libs issue ?
<pitti> but that's a question for RAOF, bryceh, Sarvatt, or tjaalton
<infinity> ogra_: As in, merge plymouth changes from Debian?
<ogra_> ah, debian has fixed it ?
<ogra_> cool !
<infinity> ogra_: Yeah, but it's a bit of an upstream re-architecting.  vorlon said he'd poke at it.  if he doesn't get to it, I will.
 * ogra_ wasnt aware, i only had that on my issues list for precise :)
<infinity> We don't really want to merge the new plymouth wholesale from Debian, could be a bit diruptive.
<infinity> So, going to see if there are some simple backportable fixes to get rid of the DRM dep where it's not needed.
<ogra_> well, if we merge it broken, it will at least be long term broken :P
<infinity> pitti: Really, the problem here is that xserver-xorg-video-all shouldn't be seeded (IMO).
<infinity> pitti: But it may be too late to fix that.
<ogra_> ++
<pitti> infinity: if it wouldn't be seeded, there's not much point in having it, thoughh
<infinity> pitti: video-all should be in universe, and we should be picking the drivers we support and putting them in platform/desktop-common.
<ogra_> xserver-xorg-video-all would be worth a spec for next UDS actually
<pitti> it's the "set of video drivers we install by default"
<pitti> infinity: but that is exactly what video-all is :)
<ogra_> there are many situations wehere we dont want all these drivers
<infinity> pitti: We already define "stuff we install by default" as "seeded".
<pitti> ogra_: you can uninstall video-all and drivers you don't need
<ogra_> i.e. on arm we usually want xfbdev and some usb drivers ...
<pitti> infinity: that would remove the possibility of trimming them down locally, though
<pitti> i. e. what ogra_ says
<pitti> right now you can easily remove all but e. g. -intel
<pitti> if ubuntu-desktop depends on them all, you couldn't any more
<infinity> If ubuntu-desktop recommended them all, you could.
<infinity> But meh.
<ogra_> ubuntu-desktop depends on xorg, no ?
<ogra_> which in turn depends on -all
<pitti> ogra_: no, -all | x-x-video
<ogra_> or did that change (i havent looked in a while)
<pitti> it's been like that for ages
<ogra_> ah, k
<pitti> as long as you have _one_ driver installed which provides x-x-video, apt is happy
<infinity> It's been like that ever since -all was done.
<infinity> I believe.
<infinity> I vaguely recall doing this with Daniel long ago.
<pitti> but anyway, v-all is there, in lucid, and we need to deal with it
<infinity> But I think it's always been a bit wrong.
<pitti> infinity: and also, it's not _at all_ the problem
<pitti> if ubuntu-desktop depended on them instead of video-all, we would be in the exact same situation
<infinity> s/Depend/Recommend/
<pitti> either way
<infinity> Really, the real problem here is that forcefully removing video drivers can break a system.
<pitti> the problem is that due to the demotion, a particular driver is not available any more, and thus breaks the upgrade
<infinity> Which is why dropping support is a bit nasty.
<pitti> so in that situation we have two options:
<pitti> - remove the driver entirely and add a conflicts:
<infinity> I can think of several ways to force the removal other than dist-upgrader hacks.
<pitti> - warn the user and don't upgrade, if he is using that driver
<infinity> But the end solution could still be an s3 system with no video.
<pitti> infinity: yes, adding Conflicts:
<pitti> it's easy to remove a driver, that's what I'm going to do for -nv and -v4l
<pitti> but then we don't need to have them in universe any more, we could just remove them completely
<mvo> release-upgrader-python-apt is build now too, waiting in NEW - I'm excited!
<ogra_> what always kept me from changing it in arm is that they actually dont take up much space after all ... we disussed dropping -all in favour of a list several times in the past
<ogra_> but in the end you only gain a meg or two
<infinity> pitti: Can't xserver-xorg (or -video-all) just conflict 'xserver-xorg-video-6'?
<infinity> pitti: Surely we don't need explicit conflicts for every old driver.
<pitti> infinity: x-x-core already does
<pitti> well, Breaks:
<pitti> that's what makes apt hold it back :)
<infinity> Oh.
<pitti> it rather keeps the old packages than removing/upgrading
<infinity> I wonder if this is one of those cases where converting a Conflict to a Break caused problems instead of solving them.
<infinity> (That used to be a Conflict...)
<pitti> I'll try with a Conflict
<infinity> I wonder if we can even remotely try to cleverly determine the video driver in use and warn main-only users that they need to enable universe (that, obviously, would be a dist-upgrader hack, but I'm okay with that sort of hack)
<pitti> infinity: ah, indeed, that'll convince apt enough
<infinity> Having a situation where the archive just plain doesn't upgrade without the dist-upgrader, though, feels wrong. :/
<tjaalton> infinity: those drivers are abandoned upstream, so there's really no other option than get rid of the ones that don't even build anymore, and let the xserver use a fallback driver (fbdev or vesa)
<pitti> tjaalton: so should we remove the lot from the archive instead of keeping it in universe?
<tjaalton> pitti: it was a plan yes
<pitti> infinity: thanks for the Breaks -> Conflicts trick
<tjaalton> the plan
<infinity> tjaalton: Oh, if fbdev and/or vesa are guaranteed to bring them back to a graphical desktop, I retract my "warn them about the situation" arguments.
<pitti> mvo: so, much easier then
<tjaalton> infinity: well, depends if the kernel even boots :)
<infinity> :P
<tjaalton> those are for really old hw
<infinity> I had an i686 system with an s3virge.
<infinity> I think.
<ogra_> with pae ? :)
<infinity> Possibly an i128 too.
<mvo> pitti: indeed
<pitti> tjaalton: are you ok with promoting the Breaks: to Conflicts:, to tell apt to actually go and do remove the old drivers instead of holding them back?
<pitti> tjaalton: (I can do the upload, just want to check if the breaks: was deliberate)
<tjaalton> pitti: haven't read the bug or the backlog in detail yet, lunch in 5min :)
<infinity> I'd have to re-read the Breaks code, and/or the policy description, but I suspect that Breaks on virtual packages (as opposed to versioned Breaks on real packages) will never really do what you were hoping.
<infinity> Cause we'll want to deconfigure the virtual provider, hoping for an upgrade to come along and fix it, and no upgrade will happen.
<infinity> And no guarantee of an upgrade (or even a hint at one), because it can't be versioned.
<tjaalton> but i think this is an issue that debian has had too, I'll ask
<infinity> pitti: My gut feeling would be to move all the virtuals out of xserver-xorg-core's breaks line and make them conflicts, and leave the versionable breaks on real packages in the Breaks line.
<infinity> (And make sure they're versioned)
<pitti> infinity: yes, that's pretty much what I just successfully tested
<pitti> tjaalton: so do you want to dwell on this a bit, or should I upload this?
<jamespage> pitti (or anyone else): is there a nice way to determine the installed size of a package?
<ogra_> jamespage, apt-cache show <package>|grep Installed
<ogra_> (thats in kilobytes i think)
<Randolph> hi all
 * apw looks for an AA to stroke the ti-omap4 kernel through on precise
<jamespage> ogra_, thanks - just what I was looking for
<tjaalton> pitti: yeah it needs to be pushed to git anyway
<infinity> apw: I may have already done it while you were asking who to ask.
<apw> infinity, thanks :)
<infinity> (cd conf && patch < ../debian/as-needed.patch)
<infinity> patching file ltmain.sh
<infinity> Hunk #1 succeeded at 5512 (offset 12 lines).
<infinity> Hunk #2 FAILED at 6155.
<infinity> 1 out of 2 hunks FAILED -- saving rejects to file ltmain.sh.rej
<infinity> ^--- Dear god, how many of these do we have in the archive?
<infinity> doko: libdap needs as-needed patch unbuggering.  I'm going back to bed. ;)
<Laney> infinity: we already fix that (in Debian)
<Laney> fixed
<Laney> -10 can be synced when LP learns of it
<tjaalton> pitti, infinity: debian-x doesn't like the change, instead conflicts should be added for just drivers that are gone
<infinity> tjaalton: Hrm.  They do realise that breaks on virtual packages are kinda meaningless, right?
<tjaalton> infinity: apparently it works just fine, as long as there is an installable candidate that fulfills the dependency
<tjaalton> so for packages that are no more conflicts should be used
<infinity> tjaalton: But the virtual is no more...
 * infinity gives up.
<tjaalton> hehe
<infinity> Laney: Thanks for the tip, synced.
<Laney> huh, that was fast
<Laney> or did you do a manual sync?
<infinity> Sync from incoming.  Magic.
<Laney> HAX
<infinity> It unsnags a long armhf dep chain, I'm impatient. :)
<Laney> dh_autoreconf --as-needed is a blessing
<mvo> meh, can someone moderate my message to ubuntu-app-devel?
<tjaalton> infinity, pitti: I'll upload with the changes you proposed, plus added -nv and -v4l in conflicts
<tjaalton> believe it's the only sane way to fix it for the case where universe is not used
<pitti> tjaalton: if you turn the Breaks: video-6 into a Conflicts:, you don't need to special-case -nv and -v4l
<pitti> tjaalton: these two will be removed with universe, and the 8 or so without universe
<pitti> tjaalton: I tried this, works fine
<pitti> tjaalton: ah, you already uploaded, thanks! so, the two extra conflicts: don't hurt, that's fine
<mbiebl> RAOF: uploaded a new policykit package which contains the owner patch.
<mbiebl> (to Debian i.e. but I assume it will be synced soon)
<mbiebl> RAOF: you can update colord now
<pitti> mbiebl, RAOF: synced polkit, thanks Michael
<mbiebl> well, thanks RAOF for getting this patch/functionality into upstream :-)
<pitti> tseliot: did you see https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/873058/comments/18 ?
<ubottu> Ubuntu bug 873058 in nvidia-common (Ubuntu Oneiric) "Jockey fail to install binary ati driver (post release) version" [High,In progress]
<tseliot> pitti: not yet, I'll have a look at it soon, thanks
 * tseliot -> lunch
<mbiebl> pitti: hm, got the reject messages for policykit-1
<mbiebl> does the ubuntu archive not yet support the introspection section?
<pitti> mbiebl: uh, which?
<pitti> ah, I guess not
<pitti> mbiebl: I'll ask around how to get it
<mbiebl> http://paste.debian.net/148710/
<pitti> yep, it's also in the build log, https://launchpadlibrarian.net/87079157/upload_3145846_log.txt
<pitti> mbiebl: filed as bug 902130, asking LP now
<ubottu> Launchpad bug 902130 in Launchpad itself "Need to add allowed section "introspection" for ubuntu packages" [Undecided,New] https://launchpad.net/bugs/902130
<mbiebl> pitti: you already have metapackages, I guess?
<mbiebl> that the other new section that was added to Debian recently
<pitti> mbiebl: yes, we've got that pretty much forever
<pitti> and "translations"
<mbiebl> :-)
<mbiebl> pitti: here is the announcement http://lists.debian.org/debian-devel/2011/12/msg00051.html
<pitti> mbiebl: thanks
<mbiebl> seems I missed education
<mbiebl> and some packages already started using it
<pitti> mbiebl: seems fixed :) I'll retry the build, thanks for pointing out!
<mbiebl> heh, that was quick
<pitti> indeed!
<pitti> err.. https://launchpadlibrarian.net/87079108/buildlog_ubuntu-precise-armhf.policykit-1_0.103-1_FAILEDTOBUILD.txt.gz
<pitti> unknown Debian architecture armhf, you must specify GNU system type, too at /usr/bin/dpkg-architecture line 144.
<pitti> doko, infinity ^ do you see what's wrong there?
<infinity> pitti: That buildd needs an lp-buildd upgrade.
<tjaalton> pitti: yeah at least it's more "detailed" as it is now
<infinity> pitti: And that package actually lists armhf in its Arch line, which is rare.
<infinity> Wait.
<ogra_> why would it do that ?
<infinity> Which machine is that?
<ogra_> shoulodnt it just be any ?
<infinity> SONOFA.
<pitti> genip
<infinity> pitti: yeah.  Fixing.
<infinity> Not happy.
<wgrant> Who keeps moving them? :/
<wgrant> infinity: (feel free to request a global upgrade next week if you want)
<pitti> infinity: where do you see the explicit armhf in architecture:? I dont' see it in debian/control
<pitti> they are all "any" or "all"
<pitti> infinity: thanks for fixing
<infinity> pitti: linux-any is explicit, from the POV of sbuild.
<infinity> pitti: Anyhow, genip is back to armel again, that build won't have the same explosion.
<pitti> ah
<infinity> And "any all" is also explicit.  Sort of.
<pitti> âª it's a kind of maagiiiiic â¬ â©
<infinity> wgrant: Yeah, I was going to do it this week, but armel was chugging away on seriously long builds.
<infinity> Though, it doesn't seem like a terribly harmful Friday thing, given that it's well-tested in production.
<doko> stgraber, parti-all was removed in debian, should it still stay in precise? ftbfs on armhf, likely on other archs
<doko> stgraber, I'm told this is replaced by xpra, and should be removed?
<guilez> hello
<ScottK> pitti: Would you please also have a look at soprano with 4.7.3 as it goes with it.
<pitti> ScottK: yes, getting there
<ScottK> pitti: OK.  No rush, just wanted to make sure it wasn't forgotten.
<ScottK> Thanks.
<stgraber> doko: it's a bit weird at the moment, I see both parti-all and xpra in the archive, probably both building python-xpra. The former has some patches I made for it, the later doesn't.
<doko> stgraber, right, but parti-all ftbfs
<stgraber> doko: So I guess we can also remove parti-all and just re-apply the patches on xpra
<doko> infinity, https://launchpadlibrarian.net/87085147/buildlog_ubuntu-precise-armhf.happy_1.18.6-1_MANUALDEPWAIT.txt.gz needs a bootstrap build
<stgraber> they were minimal patches, just changing a default flag on the X server and another changing the default framebuffer resolution, so I can easily re-apply them to the new source package
<stgraber> (still need to poke upstream about these, they're not really Ubuntu specific so may be suitable there, if they agree with these defaults too)
<smoser> hallyn, thank you for the nested container info.
<DktrKranz> Has the autosyncer from debian been launched during the last few days? I can't find some packages recently appeared in testing.
<pitti> autosyncer doesn't sync new packages
<pitti> that's a manual process
<DktrKranz> ah, so should I file a sync request for those?
<pitti> DktrKranz: no, it's still done in bulk
<pitti> but it's a separate action / process
<pitti> DktrKranz: just poke today's archive admin
<pitti> (sorry, I have about 10 things to finish in the next two hours, can't do it now)
<DktrKranz> np, thanks for the info
<doko> stgraber, https://launchpad.net/ubuntu/+source/xpra/0.0.7.30+dfsg-1/+build/2969603 built fine. so maybe drop parti-all, or fix the ftbfs
<doko> asac_the_engine?
<ogra_> haha
<asac_the_2nd> doko: thats also tryue ... but i ment the engineer :)
<asac_the_2nd> now i am the king again
<ogra_> asac_the_geraet :P
<stgraber> doko: ok, can you remove parti-all from the archive? I'll deal with applying the patches to xpra when I have some time (not having them won't break anything, just won't be as secure and will be a bit weird on dual-head setups)
<doko> stgraber, done
<stgraber> doko: thanks
<doko> jelmer, still ftbfs on armhf, see https://launchpad.net/ubuntu/+source/bzr/2.5.0~beta4-1ubuntu1/+build/2994205. any idea?
<jelmer> doko: argh, that's yet another one. Filed bug #902182
<ubottu> Launchpad bug 902182 in bzr (Ubuntu) "spurious failure of test_readv_with_adjust_for_latency(HttpTransport_urllib,HTTPSServer_urllib) on armhf" [High,Triaged] https://launchpad.net/bugs/902182
<psusi> cjwatson: I'm trying to get gparted and dmraid resynced with debian... doing so requires the corresponding patch to parted ( dm_p_seperator.patch ).  Do you think you could upload that to debian if themuso uploads dmraid?
<hallyn> smoser: np, i'm going to fix the cgroup thing today, the network of course is same as with qemu, nothing to be done about it
<smoser> hallyn, i assume, though, that you were testing those rarely used tools
<smoser> (ie, not libvirt ;)
<smoser> i ask because in the target case, we'd be using juju->localprovider (which uses lxc package), and inside the localprovider's containers we'd have nova-compute, which is going to use libvirt-lxc
<hallyn> i wasn't using juju or libvirt.  I was using lxc in precise which has its own bridge
<hallyn> libvirt's bridge, just  like lxc's, can't be used nested without changingn the address for the nested virbr0
<pitti> gilir: hello Julien, how are you?
<pitti> gilir: do you particularly care about awn-extras?
<gilir> hi pitti
<gilir> pitti, euh yes, but I know I need to fix a couple of things on awn-extras and some of its depends
<pitti> gilir: I tried to build it against current precise, and it fails in multiple ways; several plugins get disabled now as the libs changed, etc.
<pitti> so before I spend more hours on it I wondered if you already have something in some git tree
<gilir> pitti, yes, it's in a pretty bad shape currently
<pitti> vala-awn is gone, it's in libawn-dev now; that part works at least
<gilir> pitti, yes, I can work on it this week-end, I have already some fixes on my system
<pitti> oh, good
<cnd> pitti, I'm taking a look at bug 902051 now
<ubottu> Launchpad bug 902051 in utouch-frame (Ubuntu Precise) "libutouch-frame1-udeb 2.0.0-0ubuntu1 causes d-i FTBFS" [High,Triaged] https://launchpad.net/bugs/902051
<pitti> cnd: good morning! thanks, appreciated
<pitti> gilir: so maybe we can sync up next week and see what's left, and I might be able to give a hand
<gilir> pitti, ok thanks :)
<cnd> pitti, the udeb will go away in precise, but is still needed for now
<cnd> but only the utouch-frame 1.x functionality
<pitti> cnd: any chance to build it without C++ then?
<cnd> so I just need to figure out how to strip out the utouch-frame 2.x stuff for the udeb
<pitti> if it goes away anyway, I guess it's not worth changing gcc to build a listdc++ udeb
<cnd> yeah, it's definitely something we should fix in utouch-frame for now
<doko> Riddell, please update the opengtl symbols file for armhf
<Riddell> doko: ok,  on the todo list
<doko> thanks
<cnd> pitti, would you by any chance now how to delete symbols from an so?
<cnd> that would be the easiest solution :)
<pitti> cnd: you mean from a binary? no
<cnd> hmm, ok
<pitti> cnd: I think you'd need to do a multi-build, and disable the 2.0 parts in the build-udeb/ tree
<pitti> that's the usual way of doing things like taht
<cnd> yeah
<pitti> cnd: this is actually a single .so?
<cnd> I'm just trying to find the easiest way for now
<cnd> yeah
<pitti> cnd: if it's separate ELF files in one package, you can do it more easily
<cnd> it's a single .so.1 with both 1.x and 2.x symbols
<cnd> once we've transitioned everything in ubuntu off of the 1.x symbols we'll bump it to .so.2 and remove the old stuff
<pitti> so, I think multi-build is the best option here; hacking the .so doesn't sound any easier and robust TBH
<cnd> ok
<cnd> pitti, got any examples off the top of your head that I could look at?
<pitti> udev
<cnd> ok
<pitti> cnd: basically, in build: you mkdir build-deb/ build-udeb, then for each variant cd into the build dir and ../configure [...]
<pitti> to get two independent out-of-tree builds
<cnd> alright
<pitti> cjwatson: do you have a sec to look at bug 897880 and check if my reasoning is correct? I'm not able to reproduce the problem, but I think I know why it fails
<ubottu> Launchpad bug 897880 in doc-base (Ubuntu Precise) "package doc-base 0.10.3 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 127" [High,In progress] https://launchpad.net/bugs/897880
<sladen> tjaalton: http://old.nabble.com/-PATCH--Add-support-for-Lenovo-tablet-ID-0xE6-td31294086.html  Do you know what became of that?
<pitti> cjwatson: ah, unping; perl 5.14.2-6 does exactly what I proposed in the bug, so I'll merge that
<pitti> cjwatson: in fact, we can sync
<pitti> jibel: bug 897880 should be nailed now as well
<ubottu> Launchpad bug 897880 in perl (Ubuntu Precise) "package doc-base 0.10.3 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 127" [High,Fix released] https://launchpad.net/bugs/897880
<pitti> jibel: that was another major upgrade breaker
<hallyn> edgy: qemu-kvm-spice package in precise should work
<jibel> pitti, cool. I re-ran the upgrades with u-m from bzr
<pitti> jibel: well, fix uploaded, but buildds are clogged, so it won't actually hit the archive for another few hours
<pitti> jibel: the upgrade tests are run daily anyway, right? that sounds good enough
<jibel> pitti, ok. For info server upgrade fails because of unexpected debconf prompts
<SpamapS> pitti: got a minute to talk about openstack (nova, keystone) SRU's ?
<pitti> SpamapS: yes
<SpamapS> pitti: So the number of bugs is gigantic...
<jibel> pitti, every morning at 06:07UTC
<SpamapS> Launchpad-Bugs-Fixed: 727502 814561 834633 837687 838581 845714 850389 850602 851374 854614 856527 856721 858679 859587 859679 861160 861310 861582 862633 862672 862969 863305 865399 868360 869153 870495 873156 874472 876663 879582 881649 882742 883233 883253 884527 884534 884863 885462
<SpamapS> pitti: I don't think we can do this like a normal SRU. :-P
<pitti> SpamapS: no, certainly not; also not patch review
<pitti> SpamapS: TB meeting is next Monday, we can sort out the MRE there?
<SpamapS> pitti: I think thats probably the best way to handle it.
<pitti> SpamapS: as long as there is a thorough test plan/suite, this should be fine
<SpamapS> pitti: I'll make sure openstackers are present to help explain their testing and release regimen.
<SpamapS> actually.. Soren is heavily involved
<SpamapS> soren: ^^ will you be able to attend next week's TB meeting?
<SpamapS> pitti: I'm a tiny bit concerned that there's no "releases" of the stable branch... just commits to the stable branch
<RoAkSoAx> can/topic
<pitti> SpamapS: that doesn't matter much, though; "what's in a version number?"
<pitti> SpamapS: in a world of TDD and VCS and "trunk always works", versions tend to matter less :)
 * slangasek looks at pitti skeptically :)
<SpamapS> pitti: I'm glad you say that, because thats what OpenStack is built on. :)
<SpamapS> The version numbers / releases are mostly used to coordinate features vs. bugs development effort. :)
<pitti> slangasek: well, in my own projects I'm doing releases rather arbitrarily; it's more important for large projects like gnome or ubuntu when you need to coordinate, of course
<slangasek> pitti: I think my skepticism is around the idea that TDD plus a committment to an always-working trunk is sufficient to result in a trunk that's actually always usable ;)
<pitti> SpamapS: but anyway, version numbers don't matter for SRU; the kind and volume of the changes do
<cnd> pitti, do you know how to define separate .symbols files for deb and udeb?
<pitti> cnd: I wasn't actually aware that you can share them :)
<cnd> maybe I'm just doing something wrong :)
<pitti> cnd: in general, they are debian/binarypackagename.symbols ?
<pitti> cnd: I don't actually know whether udebs can/should have symbol files
<cnd> oh right, I was thinking it was libutouch-frame_<ver>.{,udebdeb}
<cnd> but they actually have different names too
<cnd> libutouch-frame_<ver>.{,udeb,deb} is what I meant
<cnd> or something like that <sigh>
<guilez> hello
<cnd> pitti, I've tried to copy the relevant stuff from udev over, but I'm getting the following: http://paste.ubuntu.com/765118/
<cnd> do you know what is going wrong?
<bryceh> Sweetshark, bug's got a fix now
<Sweetshark> bryceh: do you have a commit, link or some other trophy I can hand back to mst_ ?
<bryceh> Sweetshark, he's already on the bug report
<Sweetshark> bryceh: ah, heh ;)
<bryceh> albeit a bit grumpy
<bryceh> commit 429a36f7481b9bfd5ed137642d2916d69a713557
<bryceh> going to look and see if that'll apply to our -intel
<bryceh> yep looks like
<Sweetshark> bryceh: well, I should have pinged mst_ that I forwarded it to you, but it was 2am local already :/
<bryceh> it's ok, red hat people being grumpy is hardly unusual ;-)
<Sweetshark> bryceh: well, I worked >2 withthis guy at Sun/Oracle. And had some beer with him and a few others just before this yesterday ;)
<Sweetshark> s/>2/>2 years/
<Sweetshark> bryceh: he sat right next to me at sun.
<Sweetshark> bryceh: my comment on the bug hopefully helps ;)
<bryceh> Sweetshark, ah, yeah thanks
<Sweetshark> bryceh: he is usually a cool guy. see for example http://lists.freedesktop.org/archives/libreoffice/2011-December/021923.html you will likely know similar comments in Xorg ;)
<Sweetshark> bryceh: and thank you very much for getting this stuff fixed that quick.
<bryceh> Sweetshark, no prob :-)
<bryceh> alright, now let's get the fix into ubuntu...
<cnd> pitti, kees and vorlon helped me out
<cnd> thanks :)
<bryceh> Sweetshark, omg I'm looking at the patch and see this:
<bryceh> +			int X1 = x1, X2 = x2;
<Sweetshark> bryceh: yikes ;)
<bryceh> fg
<tjaalton> sladen: what do you mean? it's upstream since may, unless i'm mistaken about the patch (cant check now)
<bryceh> Sweetshark, the fix does indeed fix it.  I've packaged and uploaded it.  Should be available in a few hours.
<Sweetshark> bryceh: great!
<micahg> SpamapS: can I ask you a question about upstart and pppconfig? or would there be someone better to ask? (regarding starting on gdm)
<bryceh> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bryceh
 * lardman|home waits for packages to install in chroot on an SD card
<lardman|home> has anyone here had to use mtev rather than evdev?
<micahg> infinity: would you mind if I grabbed the synaptic merge from you over the weekend?  you were TIL to drop a spurious dependency
<Keybuk> I don't suppose anyone here has a Dell Mini 10v to hand? :p
<slangasek> Keybuk: they seem to be in short supply anymore :)
<Keybuk> indeed
<Keybuk> I just need the output of /sys/block/sda/device/model & queue_* from them
<Keybuk> someone *eyes elmo* deleted my people directory with all of its useful content
<elmo> it's not deleted, it's just disabled
<elmo> there's 2.3G of "useful content" - if you want it put somewhere temporarily so you can rehost it (on people.ubuntu.com), just let me (or RT) know
<elmo> Keybuk: ^--
<bryceh> micahg, I see bug #900421 is in the sponsorship queue but slangasek suggests you're already coordinating with broder about it, is that true, or is the patch on that report ready to be sponsored?
<ubottu> Launchpad bug 900421 in libsigc++-2.0 (Ubuntu) "Please convert libsigc++-2.0 for multiarch" [Wishlist,New] https://launchpad.net/bugs/900421
<Keybuk> elmo: if you can, that would be appreciated
<mdeslaur> Keybuk: would a mini 9 do? I believe it's the same hardware save for the screen
<Keybuk> yes that would do
<mdeslaur> Keybuk: one sec
<mdeslaur> Keybuk: http://paste.ubuntu.com/765398/
<Keybuk> thanks
<mdeslaur> yw
<bjf> SpamapS: feel like pocket copying the oneiric kernel (3.0.0-14.23) to -updates ?
<SpamapS> bjf: I can't do it, the launchpad API times out, and I don't have direct access to do it "the old way"
<SpamapS> bjf: slangasek, cjwatson, and pitti, can do it
<bjf> SpamapS: thanks for trying
<SpamapS> bjf: I didn't actually try. Its just a known issue. :-/
<bjf> SpamapS: ok, thanks for nothing.       :-)
<SpamapS> bjf: thats more like it!!
<slangasek> bjf: copieded
<slangasek> (ish)
<bjf> slangasek: thanks
<slangasek> bjf: linux-meta not copied yet; I don't know if pitti usually copies these as part of the same publisher run, or waits for it to settle first?
<bjf> slangasek: i don't know either
<slangasek> bjf: assuming you can wait another hour, then, I'll do the latter
<bjf> slangasek: it's just been sitting for 20 hrs. waiting for a copy, i can wait another hour
<wgrant> SpamapS: What is a known issue?
<wgrant> SpamapS: You're still using the syncSource API call?
<slangasek> wgrant: copying the linux kernel between pockets through the web interface times out
<slangasek> so nothing to do with APIs on our side :)
<wgrant> You can't copy between pockets with the web UI :)
<wgrant> There's no UI to select the pocket.
<wgrant> So I doubt it times out...
<slangasek> oh
<slangasek> then I don't know :)
<slangasek> sorry, I assumed the new stuff was full of webly goodness
<wgrant> Not quite yet.
<wgrant> Now, the old syncSource API is likely to time out too. But the new asynchronous copyPackages API should work for everything pretty much.
<SpamapS> wgrant: let me show you the thing that times out...
<SpamapS> wgrant: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/sru-release
<SpamapS>                     archive.syncSource(from_archive=archive, include_binaries=True,
<wgrant> RIght, we should probably test and alter that to use copyPackage instead of syncSource.
<wgrant> syncSource requires the whole copy to complete in just 4-5 seconds.
<wgrant> Which it should, but you know how fast LP can be...
<SpamapS> so are you saying there is a change we can make in sru-release to get this to work?
<wgrant> Yes.
<wgrant> Using the new asynchronous copy job infrastructure introduced for the web sync UI.
<wgrant> It behaves slightly different (eg. respecting overrides properly, and sending emails)
<wgrant> So will need a bit of testing.
<SpamapS> wgrant: cool, how can one test this in a non destructive way?
#ubuntu-devel 2011-12-10
<wgrant> SpamapS: dogfood.launchpad.net is probably handy here.
<wgrant> Although only LP devs can upload to it.
<wgrant> It is where we do Soyuz QA.
<SpamapS> ah
<slangasek> hallyn: so qemu-linaro 2011.12 is based on qemu 1.0, which I'm told will break libvirt :)
<slangasek> hallyn: (due to version number problems)
<slangasek> hallyn: I guess this might be fixed in libvirt 0.9.8?  If you want to merge that from Debian unstable
<hallyn> slangasek: fix is already in precise :)
<hallyn> slangasek: (bc qemu-kvm 1.0 is in precise)
<hallyn> slangasek: did you want to talk about the lvm initramfs/udev fix?
<slangasek> hallyn: I do, but I keep not having time to do so :)
<slangasek> hallyn: let me see if that doesn't make it back to the top of my queue next week
<hallyn> slangasek: cool, thanks - ttyl
<SpamapS> slangasek: I just opened up a MP against sysvinit.. I want to get your thoughts on the approach.. its quite untested.. but I'm having a hard time getting a precise VM setup on my laptop at the moment..
<SpamapS> slangasek: https://code.launchpad.net/~clint-fewbar/ubuntu/precise/sysvinit/wait-for-long-shutdown-jobs/+merge/85208
<slangasek> SpamapS: any reason not to handle stop/killed jobs the exact same way as those that are still start/ ?
<slangasek> SpamapS: also, your wait seems to not have a break for the case where there are no jobs left running
<slangasek> SpamapS: which means it *always* waits 300 seconds if there are any matches the first time around, even if the job we were waiting for was killed long ago
<SpamapS> slangasek: oh right I forgot that break ;)
<SpamapS> slangasek: on the why not handle them the same.. I find this easier to analyze.. separation of concerns. It may be more elegant to just omit those as well and increase the timeout from 10 to 300 seconds..
<SpamapS> slangasek: also we don't want to wait *at all* for start/ 's .. they're being omitted.
<slangasek> SpamapS: oh, wait vs ignore, right
<slangasek> ok
<SpamapS> my thinking is that stop/killed is a better clue than "just hanging around" so it gives us a good reason to wait longer than 10 seconds
<slangasek> right
<SpamapS> I think we may also need to add a note in init(5) about kill timeout only being respected up to 300 seconds.
<slangasek> well, what about waiting indefinitely?
<SpamapS> thought about that.. its an option
<slangasek> except that has the problem that if an upstart job *never* shuts down, your ttys are gone and you have no way to usefully inspect
<SpamapS> I figured we want a safety valve for the dork who does 999999999999
<slangasek> what does that matter?  the process shouldn't actually take that long to die?
<SpamapS> it might if it ignores signals
<slangasek> yes
<slangasek> otoh, 300 is an arbitrary cutoff
<slangasek> and I hate those :)
<SpamapS> I'm not married to this.. its just the more conservative approach.
<slangasek> both options have downsides
<SpamapS> it actually has some thought in it (mentioned in another bug about mysql) ...
<slangasek> you can be conservative about not prematurely killing processes that are still shutting down
<slangasek> or you can be conservative about ensuring the system doesn't hang on reboot
<SpamapS> 300 seconds is a long time, but no longer than most battery backup systems will be available.
<SpamapS> so for me, 300 is as long as I'm willing to wait for one service, before we start risking the whole system
<slangasek> ok
<slangasek> I can buy that
<SpamapS> there's no actual research in that battery number.. just personal experience.
<SpamapS> so I can totally be swayed on that
<SpamapS> slangasek: also no need for a break, while [ -n "$(upstart_killed_jobs)" ] means it will exit the loop when there are no more jobs stop/killed
<slangasek> well, I don't have a better magic number to offer, and you've convinced me that there are more advantages to not waiting indefinitely :)
<slangasek> SpamapS: aha, I think I missed the while condition
<SpamapS> ok, I'll try to get this tested in a VM next week
<SpamapS> for now I need to hit the road ... Big Bear and 12-24 inches of man made snow await me. ;)
<slangasek> SpamapS: :)
<SpamapS> slangasek: thanks for the second pair of eyeballs!
 * SpamapS disappears
<slangasek> SpamapS: I do need to look at more of the diff context; I have a concern I can't currently articulate about making sure we're not delaying other parts of the shutdown waiting for these jobs
<psusi> TheMuso, so I've managed to overhaul the dmraid package; rebased it on a new upstream release and upgraded it to 3.0 (quilt) format... and tested it on debian.  Do you think you could review it and upload to debian, then sync it back to ubuntu?
<slangasek> SpamapS: right, so, I think the jobs that are in state stop/killed should *also* be excluded from the kill list because otherwise the process is being killed twice, which it seems to me can only lead to slowing down the graceful shutdown
<slangasek> SpamapS: incidentally, I definitely see some weird behavior on shutdown here in precise; the killing of processes seems to take much longer than it seems it ought to
<arekm> hi, is your php dying on this, too? (can be run from cmdline): http://pastebin.com/xjCppEfS
<bahr> Hi, I'm currently a .NET developer, and want to learn a new language, and thought contributing to ubuntu would be a nice way to do this. Which languages should I consider if I want to contribute? I would like to start on Python, but are there any projects using this or is it all C and C++?
<penguin42> bahr: There is a lot of python, plenty of C and C++
<sladen> bahr: Python is a good choice.  There is also some CLR/Mono/C# stuff, but it's not in the default install anymore
<sladen> bahr: it's probably easiest if you have a particular goal in mind
<bahr> sladen: hm well my main goal was actually just to learn a new programming language, and I though python would be a nice choice, as it is not statically typed compared to c#, and I like ubuntu, and this would give me some kind of motivating project to work on imeediately, and get practical experiences
<sladen> bahr: if you select a bug-report in a particular python-based program, you could perhaps work though and try to fix it by changing things
<sladen> bahr: most of the Python syntax should be fairly familiar if you know other languages
 * lamont struggles to understand why unity/firefox think that my non-fullscreen firefox window should always go full screen when I switch to that workspace
<bahr> ok thanks. Does ubuntu have any specific python projects, cause I would like to contribute to it, as I love the operating system :)
<bahr> or should I just find a bug on the launchpad thing and work on it?
<penguin42> bahr: There is python itself, but I don't think packages that use python are tagged in any particular way
<tumbleweed> packages that use python depend on python
<bahr> ok
<jtaylor> you could learn boo, its dynamic and static typed, similar syntax to python and runs with mono/cli :)
<bluefoxicy> ok
<bluefoxicy> apt-get install -f .
<bluefoxicy> "install ALL the things"
<bluefoxicy> .... apt apparently installs regexes.
<Ampelbein> of course it does
<bluefoxicy> I tried to install ./somefoo.deb :|
<Ampelbein> From 'man apt-get': "If no package matches the given expression and the expression contains one of '.', '?' or '*' then it is assumed to be a POSIX regular expression"
<Ampelbein> bluefoxicy: You are looking for 'sudo dpkg -i ./somefoo.deb'
<bluefoxicy> Ampelbein:  with dependency resolution.
<geser> sudo dpkg -i ... ; sudo apt-get -f install
<Ampelbein> bluefoxicy: You can use 'sudo apt-get -f install' after the dpkg -i and it should install the deps
<bluefoxicy> heh
<geser> and check that apt doesn't propose to remove it again
<bluefoxicy> interesting
<geser> that's how I do it if I'm to lazy to create a repository for it (apt-ftparchive or dpkg-scanpackages)
<broder> alternatively, there's gdebi
<Frosty-nee> blist
<Frosty-nee> whoops, wrong window
<Frosty-nee> this isn't &bitlbee :P
<infinity> Riddell: opengtl seems incredibly unhappy on all 32-bit arches.
<Riddell> infinity: yes I've been getting a bunch of error messages, it's on my todo
<infinity> Riddell: Kay, just wanted to make sure it was somewhere on the list.  It's literally the only FTBFS in main for most arches right now, and it offends me. ;)
 * infinity discounts the bizarre fact that gcc-4.5 is FTBFS everywhere except for the one arch I expected it to fail on...
<infinity> doko: Any idea what's up with gcc-4.5?  Was it a build-dep that was broken and god fixed (ie: why did armhf succeed and everything else not?)
<infinity> s/god/got/
<infinity> doko: The logs almost make it look like the testsuite is deleting the build tree.  Which seems insane.
 * infinity retries on amd64 for kicks.
<doko> infinity, killed by intent. ICE's in the testsuite
<doko> all with whopper
<infinity> doko: Oh, kay.  They all seemed to die at around the same time, didn't realise it was intentional. :P
<infinity> doko: So, the fact that the armhf build succeeded is a bad thing? :/
<infinity> doko: You might want to do a -10ubuntu2 upload that's actually just reverting to -9ubuntu1.
<infinity> doko: Cause accidental retries will land this in the archive.
<infinity> doko: Oh, -9ubuntu3, rather.  But whatever.
<infinity> doko: In fact, I might do that right now.  You okay with that?
<doko> yeah, won't work on this for a while
<infinity> Kay, I'll revert then.  Seems saner.
<doko> ohh, and we should try to demote it
<infinity> MySQL still builds with it. :/
<doko> bad pitti
<infinity> doko: Revert uploaded.
<infinity> doko: I'll jam it through on armhf ASAP to replace the broken one that built.
<infinity> And MySQL is SpamapS, not pitti.
<infinity> But I believe it was due to an ICE or miscompilation or something?
<doko> enoclue, lets get rid of it. you could recheck once -ubuntu1 is built
<infinity> -- precise/main build deps on g++-4.5:
<infinity> mysql-5.1
<infinity> mysql-5.5
<infinity> openjdk-6
<infinity> -- precise/main build deps on gcc-4.5:
<infinity> grub2
<infinity> mysql-5.1
<infinity> mysql-5.5
<infinity> u-boot-linaro
<infinity> grub2 is just a question of Colin confirming that bits don't grow too large for the boot sector when built with 4.6, I think that was on his TODO.
<infinity> So, MySQL and u-boot.
<doko> opendk-6? I think I did drop it
<infinity> https://launchpadlibrarian.net/86468559/openjdk-6_6b24~pre1-1ubuntu3.dsc
<infinity> 4.5 on arm*
<infinity> Any idea why that was?
<doko> ice, which is now fixed
<doko> will fix with the next upload
<infinity> Shiny.
<infinity> I'll poke jcrigby about u-boot.
<infinity> It may have similar "need to verify code generation" issues as grub.
<infinity> Bootloaders are touchy.
<infinity> doko: MySQL may take some extra fiddling.  I think SpamapS tried to switch to 4.6 while he was packaging 5.5 and ran into the same bug as before.  But it might be something we can workaround by dumping optimisation on a single file or something.
<infinity> doko: Dumping optimisation on the entire build would probably be a Bad Thing for one of our two flagship SQL databases, though.  Worth keeping an old compiler around just for that, if we have no sane choice. :/
<doko> well, find out the exact file, and only build that without optimization
<infinity> If it was an optimisation issue.
<infinity> Let me see if I can find the bug.
<infinity> Grr, I know there was an upstream bug somewhere.
<infinity> doko: http://bugs.mysql.com/bug.php?id=61509
<infinity> doko: And patch attached a month ago!
<infinity> doko: I'll test with that a bit later.
<infinity> doko: Oh, wait.  That patch is supposedly backporting something from 5.5 to 5.1... And Clint says 5.5 still fails.  Hrm.
<infinity> doko: Running mysql-5.5/gcc-4.6 test builds on amd64, powerpc, and armhf here at home to see if I can figure out what the fuss is about.
#ubuntu-devel 2011-12-11
<micahg> bryceh: I just a cursory review before, anyone could grab it, I said if I had time, I'd try to sponsor over the weekend
<micahg> psusi: idr being asked about the lm-sensors merge, it's generally polite to ask the person who touched it last so as to not duplicate work
<psusi> micahg, ohh, I didn't know that.. not done a merge from debian before...
<micahg> psusi: yeah, this one wasn't on merges.ubuntu.com which has the notice on the top of the page, it's fine, I hadn't started, just had it on my to do list, glad to have you working on merges :)
<psusi> micahg, I just noticed that sensors-detect still wasn't recommending the right module for my motherboard even though I know support for it got added upstream like 8 months ago, so I looked and noticed the ubuntu version was out of date and the debian one was newer so I went for it;)
<broder> fyi, in case anybody's curious, here are the dependency_libs lines from all packages .la files that still have a non-empty one: http://paste.ubuntu.com/766579/
<micahg> broder: you seem to have multiple entries that are the same on the list
<broder> yeah, those are for different architectures
<broder> here's one that's explicit: http://paste.ubuntu.com/766587/
<broder> (it's only looking at i386 and amd64 because that's all i scan currently for lintian.uw.o)
<infinity> doko: Yeah, so on powerpc and armhf, MySQL is still failing way too many tests in the testsuite with 4.6 compared to 4.5.  Unfortunately, it could take some serious effort to find the miscompilations, since the tests are more task-based than code-based, so it's kinda hard to tell at a glance which bits of code are to blame.
<infinity> doko: (At least, for someone who doesn't know the code inside out, which I don't)
<infinity> doko: Interestingly, on amd64, it fails no tests.  I guess we know what Oracle's test platform is. :/
<micahg> infinity: would you mind if I grabbed the synaptic merge from you over the weekend?  you were TIL to drop a spurious dependency
<micahg> cjwatson: can I grab reiser4progs from you?
<broder> micahg: in the mood to look at sigc++? :)
<micahg> broder: yeah, I guess I can do that :)
<broder> there's more in that line of bugs, too, if you're interested - bug 902703
<ubottu> Launchpad bug 902703 in atkmm1.6 (Ubuntu) "Please convert atkmm1.6 to multiarch" [Wishlist,New] https://launchpad.net/bugs/902703
<broder> micahg: also, do you have the url handy for tumbleweed's udd sponsor/sponsoree report thing?
<micahg> broder: http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi
<broder> thanks
<micahg> broder: have you checked any of the reverse depends of the dev package of libsigc++-2.0?
<broder> you mean to see if they still work?
<micahg> yeah
<broder> i've built some of the cairomm example programs with multiarched sigc++ + multiarched glibmm + multiarched cairomm
<micahg> ok
<micahg> broder: I'm tempted to wait until Sunday night to upload in case there are any issues, is that ok?
<broder> that's fine. there's nothing urgent about the transition
<mainerror> Hello.
<mainerror> I'd like to give bug #893926 a shot but I'm not quite sure which IRC channel to join.
<ubottu> Launchpad bug 893926 in eucalyptus (Ubuntu) "Contains traces of UEC" [High,Triaged] https://launchpad.net/bugs/893926
<ScottK> mainerror: I'd ask in #ubuntu-server.
<mainerror> Thanks ScottK!
<ScottK> You're welcome.
<infinity> micahg: You generally don't need to ask to hijack my TIL unless it's a package I actively work on. ;)
<SpamapS> infinity: re mysql and gcc 4.6, its an open bug in MySQL that a certain code path segfaults when compiled w/ 4.6
<SpamapS> doko: ^^
<infinity> SpamapS: Which one, and where's the specific bug?  The bug I found earlier doesn't seem quite right.
<infinity> SpamapS: (Also, the testsuite is flawless on amd64... I only got extra failures on powerpc and arm, so that might be a pointer to what they're doing wrong)
<infinity> (Or to what GCC is doing wrong)
<infinity> SpamapS: Ultimately, though, pushing bug to Oracle/MySQL on non-x86 platforms without a patch will just lead to said bugs rotting, in my experience.  If we want it to work on, say, ARM, we'll need to fix it ourselves.
<SpamapS> yeah, the bug has no patch, let me look it up.. I thought it was in the changelog
<infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614044 ?
<ubottu> Debian bug 614044 in src:mysql-5.1 "mysql-5.1-server: fails to build from source" [Grave,Fixed]
<infinity> Err.
<infinity> That was a Debian bug.  Not awake.
<infinity> I swear I had an upstream one in my browser history..
<SpamapS> http://bugs.mysql.com/bug.php?id=61509
<infinity> http://bugs.mysql.com/bug.php?id=61509
<infinity> Heh.
<SpamapS> Thats the one that forced using gcc 4.5 ...
<infinity> But, here's the thing.  That bug is old, stale, and wrong.
<infinity> Since it talks about issues in YaSSL.
<SpamapS> http://bugs.mysql.com/bug.php?id=62856
<infinity> And the tests we're failing right now aren't.
<infinity> http://bugs.mysql.com/bug.php?id=62856 isn't relevant, we still fail tests with that.
<infinity> (Our current 5.5 has that patch)
<SpamapS> I had the yassl tests fail with 4.6 just like 61509 said
<infinity> On which platform?
<SpamapS> amd64
<infinity> Like I said, I have no tests failing on amd64 now.
<infinity> And powerpc and arm are failing... Other tests.
<SpamapS> Ok so maybe 4.6 was fixed?
<infinity> Completed: All 1692 tests were successful.
<infinity> ^-- amd64 build yesterday.
<infinity> That said, armhf will still fail > 10 tests with gcc-4.6.
<infinity> So, we still have bugs.
<infinity> (It fails a few with 4.5 too, mind you, just fails "too many" with 4.6)
<SpamapS> infinity: it seems things are quite different now than they were 3 weeks ago when I was working on this, so I don't know if I can offer much insight.
<infinity> Fair enough.
<infinity> I'm tempted to merge 5.5.19 before I do any more testing.
<infinity> But I realy would like to get MySQL using the default toolchain somehow.
<penguin42> is there a bug filed against the mysql failing on armhf with 4.6 ?
<infinity> penguin42: Not yet, I just did the test build last night.
<penguin42> infinity: Does armel work with 4.6 - i.e. is it an arm issue or an armhf specific issue?
<infinity> penguin42: Not sure, haven't spun an armel test yet.
<penguin42> nod; still failures on 4.6 will probably attract more interest than failures on 4.5
<doko> I don't understand multiarch (on armhf):
<doko> $ dpkg-architecture
<doko> DEB_BUILD_ARCH=armhf
<doko> DEB_BUILD_ARCH_OS=linux
<doko> DEB_BUILD_ARCH_CPU=arm
<doko> DEB_BUILD_ARCH_BITS=32
<doko> DEB_BUILD_ARCH_ENDIAN=little
<doko> DEB_BUILD_GNU_CPU=arm
<doko> DEB_BUILD_GNU_SYSTEM=linux-gnueabihf
<doko> DEB_BUILD_GNU_TYPE=arm-linux-gnueabihf
<doko> DEB_BUILD_MULTIARCH=arm-linux-gnueabihf
<doko> DEB_HOST_ARCH=armhf
<doko> DEB_HOST_ARCH_OS=linux
<doko> DEB_HOST_ARCH_CPU=arm
<doko> DEB_HOST_ARCH_BITS=32
<doko> DEB_HOST_ARCH_ENDIAN=little
<doko> DEB_HOST_GNU_CPU=arm
<doko> DEB_HOST_GNU_SYSTEM=linux-gnueabihf
<doko> DEB_HOST_GNU_TYPE=arm-linux-gnueabihf
<doko> DEB_HOST_MULTIARCH=arm-linux-gnueabihf
<infinity> doko: What's there not to understand?
<doko> ahh, you can just confuse dpkg by changing gcc, had a armel snapshot build installed and used
<doko> no, not in this paste
 * infinity wonders why we needed a bunch of uploads for an ocaml transition we did a month ago...
<doko> vector-algorithm sync was needed. doesn't transition to testing, because vector and primitive are too new
<infinity> That's haskell.  Though I'm almost as puzzled by those uploads too. :P
<infinity> Ilya doesn't seem to be on IRC, or I'd ask him about both.
 * infinity shrugs.
<infinity> doko: Still planning on a binutils upload today before I merge eglibc?
<doko> yes, should stop messing around with clang
<doko> Laney, ocamlfind: Not supported in your configuration: ocamlopt
<doko> Command exited with code 2.
<doko> any idea why this fails on armhf, but not armel?
<infinity> doko: Because ocamlopt needs porting.
<infinity> doko: I've been talking to upstream about it.
<doko> ahh, thanks
<htorque> hello everyone! when trying to connect to my wireless AP i'm asked for the root password: http://img.xrmb2.net/images/508877.png
<htorque> this happens after installing A1 without connecting to my AP during the installation process. against which package should i file the bug report?
<htorque> (sorry if that's the wrong place to ask)
<penguin42> htorque: #ubuntu+1 is the place for PP questions; but I'd go for ubiquity for all installation issues - althought hat looks Netowrk manager specific
<htorque> penguin42: will try ubiquity then, thanks!
<micahg> infinity: thanks
<infinity> micahg: In fact, I'd go so far as to say "please, hijack my TILM on anything I'm not actively maintaining". :P
<micahg> infinity: ok, will do :)
<infinity> doko: Alright, your binutils is installed or accepted on all arches, I'll finish up the eglibc merge this afternoon/evening, so it's built by my Monday morning.
#ubuntu-devel 2012-12-03
<dholbach> good morning
<ion> hi
<ev> pitti, bdmurray: https://wiki.ubuntu.com/ErrorTracker/ReducingRetracerDiskUsage
<pitti> Good morning
<ev> pitti, mpt: https://docs.google.com/a/canonical.com/document/d/1BWOIRdJvUueJa4cWV68UEY3nlmHgAVJY6aNGo6YSCQg/edit
<pitti> ev, bdmurray: bug 1084996
<ubottu> Launchpad bug 1084996 in Apport " StacktraceAddressSignature is missing" [High,Fix released] https://launchpad.net/bugs/1084996
<bdmurray> pitti: so with that SRU also bug 1084296 should be fixed
<ubottu> Launchpad bug 1084296 in apport (Ubuntu Quantal) "possible for a 2nd occurrence of a crash not to be sent to errors" [High,Triaged] https://launchpad.net/bugs/1084296
<mpt> ev, bug 1056061
<ubottu> Launchpad bug 1056061 in Errors ""First seen" version is wrong in release-specific table" [High,Triaged] https://launchpad.net/bugs/1056061
<mpt> ev, bug 1020988 is fixed now, right? :-)
<ubottu> Launchpad bug 1020988 in Errors "The Whoopsie Daisy infrastructure should be charmed (juju) for testing and development" [Medium,In progress] https://launchpad.net/bugs/1020988
<mpt> ev, bug 1068060 looks like another example of a typo-test-level bug with a decent-sized benefit
<ubottu> Launchpad bug 1068060 in Errors ""the past week" is missing from table period menu" [Medium,Confirmed] https://launchpad.net/bugs/1068060
<bdmurray> ev: is bug 1021326 fixed too?
<ubottu> Launchpad bug 1021326 in Daisy "Only show version numbers from official Ubuntu sources in "First seen" and "Last seen" fields" [High,Fix committed] https://launchpad.net/bugs/1021326
<mpt> ev, bdmurray: reported bug 1085853
<ubottu> Launchpad bug 1085853 in Errors "Errors code revision number not shown on the Web site" [Undecided,New] https://launchpad.net/bugs/1085853
<mlankhorst> slangasek: is a rebuild of the non-ddx reverse-depends of x11proto enough?
<mlankhorst> slangasek: https://launchpad.net/~mlankhorst/+archive/ppa/+packages pushed there, libxcb on armel failed on uploading, building went fine and it wasn't a rdepends anyway, just thought I'd test it
<pitti> mvo: have you ever used python-apt to construct an apt cache for a different architecture?
<pitti> mvo: I tried to call apt.apt_pkg.config.set('Architecture', 'armhf') before apt.Cache(rootdir=...), but it isn't taken into account
<cjwatson> mlankhorst: I think that's possibly transient, as it seems to just have fallen over trying to upload to the librarian - retry that build?
<mlankhorst> yeah it's fine, armhf worked so no need to try again..
<didrocks> cjwatson: FYI, as you didn't attach any bugs to https://code.launchpad.net/~cjwatson/frame/cross/+merge/137457, I think that tomorrow's frame daily build will only be "Automated snapshot from rev <â¦>" (nothing wrong with that personnaly), just a warning :)
<cjwatson> didrocks: Ah, fair enough, I wasn't sure how to interact with it from a patch submitter's point of view
<cjwatson> didrocks: Not a big deal, it's one of hundreds ...
<didrocks> cjwatson: exactly :)
<cjwatson> So, what, it uses the bug title by default?
<didrocks> yeah, the bug title
<cjwatson> Would it be helpful if I filed a bug now and attached it?
<didrocks> it's trying to search for an attached bug for all merges branches (whatever the deepness of the merge is), and as well, trying to fetch bug #<...> and a tons of variations of it in the commit message if you didn't attach it
<didrocks> cjwatson: hum, now that the upstream jenkins merger is doing its job, I think it's too late TBH
<cjwatson> OK
<cjwatson> I'll live
<didrocks> same for me ;)
<didrocks> I just prefer to warn beforehand :)
<mvo> pitti: I used this before, yes, let me check whats going on, maybe multiarch oddness
<pitti> mvo: or does root= reset this?
<mvo> pitti: and its generally a important and useful use-case
<mvo> pitti: could be, give me a minute to create a test
<pitti> mvo: danke!
<cjwatson> doko__: Have you had any opportunity to consider Debian #693220 yet?
<ubottu> Debian bug 693220 in build-essential "Add crossbuild-essential support" [Wishlist,Open] http://bugs.debian.org/693220
<cjwatson> doko__: My cross-build environment has some corner-case difficulties with including wookey_'s bootstrap archive, and I'd like to get to the point of being able to work in plain raring ASAP
<doko__> cjwatson, yeah, will look at it this week
<cjwatson> Thanks
<mvo> pitti: http://paste.ubuntu.com/1407600/ <- that seems to be doing what needs to be done (modulo that archive does not have armhf but if I use ports there it seems to be fine
<pitti> mvo: odd, that's pretty much what I did
<mvo> pitti: do you have anything in your rootdir that migh reset something in the config? a apt.conf or apt.conf.d snippets?
<pitti> mvo: ok, if that works for you, then I probably just did something wrong
<pitti> mvo: a sources.list with http://ports.u.c/, just like you
<pitti> mvo: (currently discussing stuff with ev, getting back to this soon)
<pitti> mvo: thanks!
<mvo> pitti: odd, happy to dig more with you once you have a spare minute :)
<pitti> Get:3 http://ports.ubuntu.com precise/main armhf Packages [1258 kB]
<pitti> mvo: ok, your test case works here
<pitti> mvo: ooh
<mvo> pitti: \o/
<pitti>         apt.apt_pkg.config.set('Architecture', 'armhf')
<pitti> mvo: spot the error :)
<pitti> yay, works in apport now
 * pitti hugs mvo, sorry for disturbing then; just blindness
<mvo> pitti: :)
<ogra-cb> oh, when did we drop the requirement for the /ubuntu-ports dir ?
<mvo> pitti: no worries, the config synatax is archane
<ogra-cb> it always needed to be http://ports.ubuntu.com/ubuntu-ports in the past
<pitti> hm, I guess not since I got my first arm device :)
<ev> pitti: https://wiki.ubuntu.com/ErrorTracker/MapReduce - what I just explained in written form
<ev> pitti: https://dev.launchpad.net/LEP/BugsToFixedBinaries
<ev> mpt: http://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/whoopsie.c#L87
<mpt> ta
<bdrung> cjwatson: can you please look at https://code.launchpad.net/~logan/ubuntu/raring/partman-basicfilesystems/debian-merge/+merge/135032 ?
<cjwatson> I'm going to reject it because it's against the wrong branch, but OK ...
<ev> pitti, mpt, bdmurray: https://bugs.launchpad.net/whoopsie/+bug/1085987 - created this from our batches discussion
<ubottu> Launchpad bug 1085987 in Whoopsie "Submitting batches of error reports to daisy.ubuntu.com" [Undecided,New]
<bdrung> micahg: can you look at the SRU at bug #1027977 (you sponsored the quantal fix)?
<ubottu> Launchpad bug 1027977 in valgrind (Ubuntu Precise) "strstr() function produces wrong results under valgrind callgrind" [Low,Triaged] https://launchpad.net/bugs/1027977
<bdrung> xnox: can you look at the SRU in bug #1027977 (you sponsored the fix to raring)?
<ubottu> Launchpad bug 1027977 in valgrind (Ubuntu Precise) "strstr() function produces wrong results under valgrind callgrind" [Low,Triaged] https://launchpad.net/bugs/1027977
<mpt> bdmurray, bug 1084979
<ubottu> Launchpad bug 1084979 in Apport "Submitting error report asks confounding questions" [Medium,Confirmed] https://launchpad.net/bugs/1084979
<mpt> bdmurray, https://bugs.launchpad.net/ubuntu-error-tracker
<xnox> bdrung: Can you explain how you calculate micahg for quantal & me for raring?
<xnox> bdrung: micahg sponsored it into quantal, when quantal was the dev release. I was looking at the bug, but didn't review it for sru.
<bdrung> xnox: hm, there is a copy-paste mistake
<bdrung> xnox: bug #973014 is for you
<ubottu> Launchpad bug 973014 in gst-plugins-bad0.10 (Ubuntu Quantal) "gstreamer0.10-plugins-bad, (libgstvideoparsersbad.so), causes a failure to decode many common video files encoded as AVC 1 Baseline - L2.1, Baseline - L1.1 & others" [High,Confirmed] https://launchpad.net/bugs/973014
<bdrung> xnox: my calculation was to look at the sponsor who uploaded the fix to the development version
<xnox> bdrung: I see now what you did there =)
<bdrung> xnox: :D
 * bdrung tries to be a load balancer
<cjwatson> xnox: Any thoughts on http://paste.ubuntu.com/1407904/ ?  (still testing)
<pitti> ogra-cb: IIRC you used qemu-user in the past to run arm binaries on x86, didn't you?
<ogra-cb> pitti, sudo apt-get install qemu-user-static && sudo qemu-debootstrap ....
<micahg> bdrung: sorry, not this week
<pitti> ogra-cb: oh, I just found the -L switch
<pitti> ogra-cb: I was trying LD_LIBRARY_PATH=`pwd`/lib qemu-arm /tmp/sandbox/usr/bin/gdb
<xnox> cjwatson: looks ok. As long as it boots & still shows ubuntu logo with christmas lights going on and off again, this should be fine.
<pitti> ogra-cb: but that tried to use /lib/ld-linux-armhf.so.3 still; but with -L it seems to work
<ogra-cb> pitti, better use qemu-debootstrap and create an arm chroot ;)
<pitti> ogra-cb: nah, I want this for the apport retracers
<cjwatson> xnox: seems to in kvm -snapshot at least
<ogra-cb> pitti, ah, k
<pitti> ogra-cb: they already build a sandbox with all hte necessary debs and ddebs unpacked; I just want to rum armhf's gdb in there
<pitti> ogra-cb: and that actually seems to work
<ogra-cb> yeah, as long as it finds the libs
<ogra-cb> you shouldnt need to call qemu-arm explicitly though
<ogra-cb> binfmt shoould take care
<ogra-cb> read: LD_LIBRARY_PATH=`pwd`/lib /tmp/sandbox/usr/bin/gdb ... should just work as well
<pitti> ogra-cb: ah, maybe I didn't install that properly
<ogra-cb> qemu-arm-static should handle it in its postinst
<ogra-cb> or qemu-user-static as it is called nowadays
<bdrung> pitti: can you look at bug #1070581 (you are the last uploader of that package)?
<ubottu> Launchpad bug 1070581 in langpack-locales (Ubuntu) "Name of the language spoken in Bangladesh" [Undecided,In progress] https://launchpad.net/bugs/1070581
<stokachu> tjaalton: would it be possible to get a debdiff for bug 1012900 so we can get it through SRU?
<ubottu> Launchpad bug 1012900 in sssd (Ubuntu Precise) "Using SSSD, PAM error when exiting su session" [High,Confirmed] https://launchpad.net/bugs/1012900
<tjaalton> stokachu: I'll push 1.8.5 for precise
<tjaalton> it's maintained in git
<stokachu> tjaalton: perfect thank you
<tjaalton> i'll pull some packaging fixes too
<tjaalton> that landed raring on saturday
<stokachu> tjaalton: even better! :D
<tjaalton> +in
<tjaalton> I'll finalize the package tomorrow
<stokachu> tjaalton: thats perfect, ill look for an update tomorrow, thanks again
<cjwatson> xnox: Righto, pretty sure this is right, so uploading; wanted you to have a heads-up though :-)
<xnox> cjwatson: ok. i will reboot today =)
<pitti> ogra-cb: eek -- we have no armhf ddebs for quantal and raring
<pitti> ogra-cb: I fixed the ddeb-retriever configuration, but urgh..
<pitti> seems nobody was missing them so far
<pitti> ogra-cb: how would qemu-user integrate itself with binfmt-misc?
<pitti> ogra-cb: shouldn't it ship a file in /var/lib/binfmts/ the or so?
<cjwatson> qemu-user-static does
<pitti> oh, -static
<cjwatson> Which is almost more useful since you can copy it into chroots and such
<pitti> hm, but I guess I still need to explicitly call qemu-arm, for the -L option (LD_LIBRARY_PATH doesn't seem to work)
<ev> pitti: https://bugs.launchpad.net/daisy/+bug/1086014
<ubottu> Launchpad bug 1086014 in Daisy "Generate reports for testing programmatically" [Medium,Confirmed]
<ev> pitti: also, can you track your progress in the ARM retracer work in https://bugs.launchpad.net/daisy/+bug/1044437
<ubottu> Launchpad bug 1044437 in Daisy "Retracer ARM support" [Low,Confirmed]
<slangasek> mlankhorst: yes, that's fine for a test
<mlankhorst> slangasek: good enough then?
<slangasek> mlankhorst: yep, looks like it - I'll get those processed today
<ScottK> pitti: Is there a reason to leave jockey in the archive?
<pitti> ScottK: did kubuntu stop using it?
<pitti> Package: jockey-kde
<pitti> Task: kubuntu-desktop, kubuntu-full, kubuntu-active-desktop, kubuntu-active-full, kubuntu-active
<ScottK> Hmmm.
<pitti> ScottK: if you don't need it any more, I'll happily kick it out
<ScottK> Let me make sure.
<Riddell> ScottK: muon doesn't yet replace it
<Riddell> JontheEchidna needs more poking
<ScottK> Ah.  OK.
<shnatsel> cjwatson: Hello! Could you point me to the scripts that generate the "/efi" folder on Ubuntu ISOs? I can't find anything relevant in lp:ubuntu-cdimage
<cjwatson> shnatsel: tools/boot/<blah>/boot-amd64
<cjwatson> shnatsel: in lp:~ubuntu-cdimage/debian-cd/ubuntu
<mlankhorst> normally x11proto won't break anyway, ddx depend on xserver abi and xserver abi just doesn't use the extra fields unless available.
<ricotz> infinity, hi :), i hope you can cherry pick the mentioned fix for eglibc here: https://bugzilla.gnome.org/show_bug.cgi?id=687265#c9
<ubottu> Gnome bug 687265 in general "deadlock in libcanberra-pulse with gstreamer 1.0.2" [Normal,Unconfirmed]
<shnatsel> cjwatson: thanks a lot!
<shnatsel> found it :)
<pitti> slangasek: ah, so I did try gdb-multiarch, but didn't set a target so it coulnd't decipher the core properly; do you happen to know the option for this?
<pitti> ah, 'set architecture'
<smoser> slangasek, around?
<pitti> slangasek: hm, with value "arm" I still get "/tmp/tmpQ9sZpI" is not a core dump: File format is ambiguous", and arm-linux-gnueabihf or armhf are not valid
<pitti> and "show architecture" from arm's gdb is just "arm"
<shnatsel> oh, one more question: I see Precise seeds have been converted to using 3.5 kernel backported from Quantal by default for x86 architectures. I wonder if I should use 3.2 or 3.5 for a derivative distro? I'm primarily concerned by two things: for how long will it be supported and will hardware support patches be backported to 3.5 like they are being backported to 3.2?
<cjwatson> The point of the 3.5 kernel is to provide improved hardware enablement
<cjwatson> Though I think the plan is to supersede it with whatever's in raring after raring's out
<shnatsel> cjwatson: ah, so Ivy Bridge works OOTB, etc? I hear it doesn't work in 3.2
<cjwatson> No idea about that
<cjwatson> Not a kernel guy, I just do what I'm told with the seeds :)
<shnatsel> cjwatson: thanks, I'll ask in the kernel channel then :)
<smoser> it would seem that mountall is likely the difference between pretty green dots at https://jenkins.qa.ubuntu.com/view/ec2%20AMI%20Testing/view/Overview/job/quantal-server-ec2-daily/153/ and red ones at https://jenkins.qa.ubuntu.com/view/ec2%20AMI%20Testing/view/Overview/job/quantal-server-ec2-daily/154/ . the difference in manifests of those 2 builds are http://paste.ubuntu.com/1408166/ . seems bug 1059471 to have regressed.
<ubottu> Launchpad bug 1059471 in mountall (Ubuntu Quantal) "2.41 fails to mount root partition" [High,Fix released] https://launchpad.net/bugs/1059471
<xnox> ev: http://tldp.org/HOWTO/LVM-HOWTO/
<xnox> ev: http://tldp.org/HOWTO/LVM-HOWTO/commontask.html
<infinity> ricotz: I'll have a look at it.
<mlankhorst> slangasek: just leaves the rest of the stack then :)
<ricotz> infinity, thank you
<slangasek> pitti: can you toss me a sample core file so I can poke at it?  the documentation on 'set architecture' is lousy IME, I generally find I have to do this by feel
<pitti> slangasek: I was using the one from bug 1070952
<ubottu> Launchpad bug 1070952 in nux (Ubuntu) "unity_support_test crashed with SIGSEGV in omap_device_del()" [Undecided,New] https://launchpad.net/bugs/1070952
<slangasek> smoser: hey there - otp, but go ahead :)
<pitti> slangasek: we don't have debugging symbols for quantal/raring, but at least a stack of ?? without error messages would do fine
<smoser> slangasek, i did. see above.
<smoser> and comment added to bug 1059471
<slangasek> smoser: right, reading now
<ubottu> Launchpad bug 1059471 in mountall (Ubuntu Quantal) "2.41 fails to mount root partition" [High,Fix released] https://launchpad.net/bugs/1059471
<smoser> and i apologize
<smoser> for not testing as solid as you woudl have liked. but sometimes it doesnt fail, and I *did* test.
<slangasek> smoser: unfortunately, the tests being run here aren't very diagnosable, "assertTrue" doesn't give us any other debugging information; can you reproduce these failures?
<smoser> slangasek, yes.
<smoser> they fail > 50% of the time on canonistack and on ec2
<slangasek> smoser: oh, the console output looks more interesting though... seems you're getting 'Permission denied'?  Do the cloud-init jobs need any tweaking to work correctly with the changed mountall?
<smoser> where do you see permission denied?
<slangasek> smoser: https://jenkins.qa.ubuntu.com/view/ec2%20AMI%20Testing/view/Overview/job/quantal-server-ec2-daily/154/ARCH=i386,REGION=eu-west-1,STORAGE=ebs,TEST=simple-user-data,label=ubuntu-server-ec2-testing/console
<slangasek> smoser: in response to the ssh attempts
<smoser> well, if fails to ssh in
<smoser> because the instance failed to import hte keypair
<smoser> becaus the instance failed to find the datasource
<smoser> ie, there was no way into that instance.
<smoser> the data you want is actually
<slangasek> ah; where's the datasource failure?
<smoser> https://jenkins.qa.ubuntu.com/view/ec2%20AMI%20Testing/view/Overview/job/quantal-server-ec2-daily/154/ARCH=i386,REGION=eu-west-1,STORAGE=ebs,TEST=simple-user-data,label=ubuntu-server-ec2-testing/artifact/None/i386/m1.small/ebs/i-aa125fe1/uec2-20121128-1030-297e755409fb4e-terminated.console.txt
<smoser> wait
<smoser> thats a bad one.
<smoser> well, sor of a bad one
<smoser> it demonstrates the "plymouth ate output" bug
<smoser> slangasek, the "good news" is that when i add --verbose to kernel cmdline it gets much harder to reproduce
<smoser> :)
<slangasek> heh
<smoser> (ie, i cant reproduce with that on just yet)
<smoser> i'm 0/5
<smoser> slangasek, can you confirm that you want me to try to get failure with --verbose ?
<smoser> because if so, i'll work on that.
<smoser> but i can give you access to an instance to poke around on and just look if you'd like
<smoser> your choice of raring or quantal
<smoser> ok. i have it failing. console output is very limited, but i'll get it and let you into instance.
<slangasek> smoser: thanks
<smoser> slangasek, console log at: http://paste.ubuntu.com/1408297/ .
<slangasek> smoser: thanks.  which part shows me the failed access to the datasource?
<smoser> :) plymouth ate that output
<slangasek> hmm
<smoser> but its in /var/log/boot.log and /var/log/cloud-init.log
<slangasek> ok
<smoser> and you can correlate timestamps
<slangasek> which is one is the expected data source?
<smoser> EC2.
<slangasek> ok
<smoser> slangasek, there is a big hint in that the EC2 datasource didn't run until uptime of 136 seconds.
<zul> barry: ping
<smoser> cloud-init-nonet waiting 120 seconds for a network device.
<smoser> cloud-init-nonet gave up waiting for a network device.
<smoser> it would appear to me that the race condition that we're seeing stops the network device added hooks from firing and bringing up network.
<slangasek> smoser: eth0 was seemingly not found until 5 minutes after boot... any idea there?
<slangasek> smoser: /var/log/udev confirms that the kernel didn't turn up eth0 until 265.527315 after boot
<slangasek> so this is triggered by mountall, yes, but the real problem is that something's preventing the network interface from being found in a timely manner by the kernel
<smoser> well, the reason for so long after is proably that cloud-init-nonet blocked for 120 seconds, and then cloud-init (which was blocking) looked for the datasource for probably the remaineder of that time.
<slangasek> cloud-init-nonet shouldn't be blocking udev
<smoser> i agree.
<smoser> but it is
<smoser> :)
<slangasek> how?
<smoser> well some race there i think.
<slangasek> udev is 'start on virtual-filesystems', udevtrigger is 'start on startup and started udev and not-container'
<slangasek> so as soon as virtual-filesystems is emitted, udev runs; and the virtual-filesystems event does not block on the rootfs, which is where cloud-init-nonet hooks in
<smoser> 265 = 10 seconds of boot time + 120 timeout + 126 seconds of "look for datasource"
<slangasek> ok
<slangasek> so process list confirms udev didn't start until 17:35
<slangasek> I think I need mountall --verbose output to diagnose further :/
<smoser> slangasek, ok. i'll work on that.
<smoser> you have any ideas on the "plymouth ate my output" issue ?
<smoser> (which i'm opening a separate bug for now)
<slangasek> not really
<slangasek> other than that I'm not sure 'console output' is actually a good idea
<slangasek> (*because* it's probably incompatible with plymouth)
<smoser> well thats a bug in plymouth/upstart
<smoser> if console output doesnt work
<smoser> i need some way to get stuff to the console
<smoser> (which i can see remotely)
<slangasek> smoser: it may be a bug in plymouth, but not the bug you're thinking
<slangasek> plymouth itself is supposed to replay output to the console
<smoser> right
<smoser> it does the ioctl to /dev/console that says "give me all that stuff"
<smoser> and then nis supposed to replay it
<smoser> slangasek, you want --verbose or --debug for mountall
<slangasek> smoser: --verbose is sufficient
<slangasek> smoser: you're familiar with the dance for /etc/init/mountall.conf to capture the output off somewhere?
<slangasek> pitti: 'set gnutarget elf32-littlearm'
<smoser> slangasek, i don thtink so. but it *should* go to console i think :)
<slangasek> smoser: yeah, if plymouth doesn't eat it ;P
<pitti> slangasek: oh, how obvious! merci beaucoup
<pitti> slangasek: this goes on top of "set architecture arm", I figure?
<smoser> but it stlil gets into /var/log/upstart/mountall.conf i think
<slangasek> smoser: I generally disable 'console output' and do '> /run/mountall.log 2>&1' in the script when I'm debugging mountall; you can also just omit 'console output' and it'll capture to /var/log/upstart automatically, yeah
<slangasek> pitti: well, seems that it gives me the same output with or without the 'set architecture arm'
<slangasek> pitti: that output is not particularly pretty though :)
<pitti> slangasek: I still get "warning: wrong size gregset struct in core file"
<slangasek> yeah, I get that too; not sure what it means
<pitti> slangasek: with qemu-arm gdb it is slightly bigger than just one line
<slangasek> digging further
<pitti> slangasek: and it at least gets addresses
 * slangasek nods
<pitti> slangasek: thanks
<slangasek> pitti: maybe the original binary is also needed?
<pitti> slangasek: I do have that
<slangasek> hmm
<pitti> slangasek: I have a complete apport-like sandbox from apport-retrace
<slangasek> can you give me a pointer to it?
<slangasek> ah ok
<pitti> $ du -hs /tmp/sandbox/
<pitti> that's not too bad, I could tar it up
<pitti> OMGupload speed from the office
<slangasek> :)
<pitti> http://people.canonical.com/~pitti/tmp/sandbox.tar.bz2
<pitti> slangasek: http://paste.ubuntu.com/1408422/
<pitti> slangasek: these are my two commands (slightly hacked in-place, as I was running them out of apport-retrace)
<pitti> slangasek: (the sandbox has armhf's gdb package and dependencies unpacked)
 * slangasek nods
<smoser> slangasek, http://paste.ubuntu.com/1408434/
<smoser> slangasek, appears mount of /run was blocked
<slangasek> smoser: where do you see this?  I'm not seeing any of the mountall --verbose output in the console log
<smoser> its not there.
<smoser> in instance, /var/log/boot.log
<slangasek> ah, ok
<slangasek> I do however see 'mounted-run' running at 15s, so that doesn't seem to have been blocked
<slangasek> right, so /run is *mounted*, but something prevents 'mounted MOUNTPOINT=/run' from returning
<slangasek> smoser: there are only three jobs on this system which start on that event: resolvconf, container-detect, and mounted-run.  container-detect doesn't do anything that should block, and in any case the timestamp on its log shows that it completes quickly; that means we need to look at the other two to see what's blocking
<slangasek> smoser: in theory the only long-running code in mounted-dev shouldn't block because it's backgrounded, but you could try commenting out the 'run-parts' line
<smoser> slangasek, sure.
<smoser> slangasek, it hink you meant mounted-run
<slangasek> smoser: yes :)
<barry> xnox: thanks for porting gnome-menus to py3
<arosen> I'm trying to modify an existing package; if I do apt-get source <package>; how can I recreate the package using those files?
<penguin42> arosen: dpkg-buildpackage
<smoser> slangasek, i think i've reproduced with "#    [ -d "/etc/update-motd.d" ] && run-parts --lsbsysinit /etc/update-motd.d > /run/motd &"
<smoser> (ie commented out)
<smoser> i will wait a bit to be sure.
<smoser> yeah, definitely reproduced there.
<ev> mpt, bdmurray, pitti: http://www.toptable.co.uk/opentables.aspx?m=72&p=6&d=03/12/2012%2019:00:00&lat=51.5063116&lng=-0.0998713999999836&di=0.5&ula=Bankside,%20London%20Borough%20of%20Southwark,%20London%20SE1%200SU,%20UK&t=loc&fsr=1&rp=opentables.aspx
<slangasek> smoser: ok, that seems to leave only resolvconf as a possible culprit, hmm
<ev> http://www.blackandbluerestaurants.com/page/home/11/11
<ev> totes workin hard ;)
<mpt> #ubuntu-devel, The Food Channel
<smoser> slangasek, 10.55.60.136 if you want to check my work
<micahg> Are we serving Raspberry Pi? /me ducks
<slangasek> smoser: looks sane to me; resolvconf seems to be the only possible explanation
<slangasek> smoser: how about a set -x in /bin/resolvconf for debugging?
<slangasek> smoser: sorry, /sbin/resolvconf
<smoser> slangasek, [   14.223470] init: resolvconf state changed from post-start to running
<smoser> that is the last occurance of 'resolvconf' in the console log
<slangasek> yep
<smoser> shouldn't we see a stopped or killed ?
<slangasek> no
<slangasek> though, the fact that it goes to 'running' that early means that the pre-start script has finished
<slangasek> hmm
<slangasek> ok, this may be a straight up bug in mountall then
<smoser> oh yeah. you're right. about the running
<slangasek> unfortunately we have asymmetric debug output here, so we don't actually see when the mounted event is emitted
<smoser> http://paste.ubuntu.com/1408556/ is console output
<slangasek> but given that none of the three dependent jobs seem to be buggy, I suspect that 'mounted /run' isn't being emitted until after the rootfs is mounted rw
<slangasek> and that's a bug
<smoser> well, that is one of the resonss i put utc and kernel uptime in cloud-init output
<smoser> so you can correlate if you have symettric logs
<smoser> err... if you only have separate logs
<smoser> anyway.
<slangasek> smoser: could I have you test a patch to mountall to add more debugging, while I start looking for this bug?
<smoser> remember when we had /dev/console, and writes there were not masked by some complex daemon ?
<smoser> that was cool
<slangasek> :P
<smoser> slangasek, sure.
<slangasek> yes, I believe that was before we had an event-based init system and you could actually rely on writes to the console happening in some meaningful order
<slangasek> smoser: http://people.canonical.com/~vorlon/mountall-better-debugging.patch
<slangasek> smoser: oh, at least I have a clue now why this change triggered the problem: the initramfs is mounting /run with the device name "tmpfs" whereas /lib/init/fstab lists "none", so I guess before this fix we were maybe not emitting mounted MOUNTPOINT=/run at all?
<slangasek> that should have manifested as broken resolvconf handling in the cloud images though, AFAICS
<smoser> well, i've not seen broken resolvconf handling in images.
<smoser> certainly not at the 50% failure rate that we're seeing this.
<slangasek> yeah, it seems that would've been a 100% failure rate, not 50%
<slangasek> hmm
<slangasek> smoser: you could try changing "none" to "tmpfs" in /lib/init/fstab, see if it's reproducible then
<smoser> slangasek, sure.
<slangasek> smoser: (would still like to see debug output with that mountall patch first, however, to make sure this isn't a red herring)
<smoser> slangasek, ok. i'm building that, and will build an image with it.
<slangasek> cheers
<smoser>  sbuild-build-depends-mountall-dummy : Depends: plymouth-dev (>= 0.8.5.1) but it is not installable
<smoser> that happened when trying to build patched mountall. :-(
<smoser> in schroot
<infinity> rly?
<infinity> E: Unable to locate package plymouth-dev
<infinity> That's a more helpful error message.
<slangasek> should be  plymouth-dev (>= 0.8.5.1) | libplymouth-dev
<slangasek> and we have the latter
<smoser> probably some user error. http://paste.ubuntu.com/1408628/
<penguin42> I'd appreciate a review on the following trivial crash fix at some point; https://code.launchpad.net/~ubuntu-treblig/ubuntu/raring/xpilot-ng/bug-1033250
<infinity> slangasek: plymouth-dev is a virtual...
<slangasek> infinity: shouldn't be?
<slangasek> infinity: it's the divergent Debian package name
<infinity> Oh, it's a virtual in Ubuntu only.  Ick.
<penguin42> you can't do version comparisons like that on virtuals can you?
<slangasek> smoser: I think there's a toggle you have to set somewhere to get sbuild to behave correctly and not ignore alternate build-deps
<slangasek> i.e., to get the Ubuntu buildd behavior
<infinity> Pretty sure that versioned build-deps on virtuals explodes the apt resolver, hence the buildd sbuild is fine, the one on my system, not so much.
<infinity> Oh, or maybe it's just the alt toggle.
<slangasek> infinity: it's not "virtual", it's *non-existent*
<mlankhorst> yeah if only i could do versioned virtuals :/
<slangasek> the only reason apt reports it as "virtual" is mountall's own reference to it
<SpamapS> slangasek: I know for php I have to use the aptitude build dep reosolver
<infinity> slangasek: Oh, so it is.  That helps.
<slangasek> really seems like we should set this toggle by default in the Ubuntu sbuild package
<SpamapS> slangasek: the man page claims that the aptitude resolver is not the default because of performance concerns
<SpamapS> I can't imagine it adds more than a few seconds to any given build
<smoser> what is the toggle ?
<infinity> No need to use aptitude.
<infinity> smoser: Add "$resolve_alternatives = 1;" to your ~/.sbuildrc
<smoser> gracias
<slangasek> right, there it is
<infinity> slangasek: If we toggle it by default, it breaks my sid builds, mind you.  I'm not sure there's a right answer here.
<slangasek> infinity: I guess you could be fancy and make it vary with build target? :)
<infinity> Yeah, which is the glory of config files that happen to be perl code.
<infinity> But that's harder to enforce at the packaging level, since the package doesn't know what you've named all your chroots/targets.
<infinity> Easier for a user to mangle.
<infinity> Maybe our default sbuildrc could include a commented-out snippet, though.
<ScottK> Probably something the sbuild wrapper in u-d-t could handle though.
<infinity> There's a wrapper?
 * ScottK thought so.
<slangasek> I thought there was just mk-sbuild
<ScottK> Yeah, that's what I was thinking of.
<infinity> Yeah, that's all I see.
<slangasek> oh, but does that generate sbuildrc snippets?  I don't recall
<ScottK> Sorry for the distractin.
<ScottK> distraction even.
<infinity> Although, Andy just did some mangling to do proper pocket/component manipulation, and I should massage that and figure out if it belongs in sbuild or u-d-t.
<infinity> Maybe an ubuntu-sbuild wrapper that employs his hacks, plus sets the right variables (resolve_alternatives can be set in the environmnet too) might do the trick.
<ScottK> This is how pbuilder-dist got started ...
<infinity> On balance, though, I'd prefer sbuild DTRT out of the box, if that's plausible.  The alternative thing is a minor mess, that's all.
 * slangasek runs away
<ScottK> (see pbuilder-dist-simple for the simple idea from which the monster grew)
<infinity> Actually, I should turn that off in my .sbuildrc again before I forget and do a Debian upload with it on.
<infinity> And remind myself to make it conditional later.
<slangasek> pitti: do you also get this error? seems some deps are missing from the tarball: warning: Could not load shared library symbols for 17 libraries, e.g. /usr/lib/arm-linux-gnueabihf/libX11.so.6.
<arosen> When I do apt-get install package vs apt-get source package for some reason a different version of package is received
<arosen> any ideas why?
<micahg> source files from other releases?
<arosen> micahg: yes
<micahg> arosen: there's your answer
<arosen> micahg: also I was wondering if there was anyway to use dpkg-buildpackage without it having to look for an upstream tarball and instead use the untar'ed code from the current working directory ?
<smoser> slangasek, 10.55.60.188 has reproduced raring+debug patch
<smoser> there is no swap on those instances though
<slangasek> smoser: random aside, do you have an .ssh config snippet of some kind to not save fingerprints for cloud hosts? :)
<slangasek> smoser: ok, very interesting output, it shows the mounted event is sent *very* early but doesn't complete until we hit those timeouts
<slangasek> so the device mismatch was a red herring after all
<smoser> slangasek, http://paste.ubuntu.com/1408767/
<smoser> oh. do you want the console output for that ?
<smoser> http://paste.ubuntu.com/1408769/
<smoser> duh.
<smoser> i completely wasn't thinking. and didn't realize your patch added debug in both swap and "other"
<slangasek> smoser: there's no chance I'm missing something here, is there?  like an upstart job that starts on /run and deletes itself on first boot?
 * slangasek keeps living in denial that this is his bug :)
<smoser> slangasek, no. nothing evil like that.
<slangasek> mmk
<smoser> slangasek, i was about to comment that cloud-init in "config" does execute a 'mount -a' as it might update /etc/fstab.
<smoser> but it doesn't get to the point where it would/could do that.
<slangasek> yep
<slangasek> smoser: ok, am going to have to meditate over this code for a bit :/
 * infinity hands slangasek an Amiga.
 * ScottK thinks whisky might work better.
<slangasek> smoser: aha
<slangasek> smoser: try_mounts(), once it's seen that all mounts are attempted, loops waiting for each of the outstanding events to finish; and it happens that the outstanding event for / is in the list ahead of /run :P
 * slangasek claims his whiskey reward
<infinity> slangasek: Hrm, could that be the source of my on-again-off-again "waiting for /tmp" bug that I keep forgetting to file?
<slangasek> infinity: shouldn't be, no
<infinity> Hrmph.
<infinity> Alright, I should do a few dozen reboots and see if I still have that bug, and then file it.
<infinity> And we can go spelunking.
<smoser> infinity, i see a waiting for swap all the time
<smoser> (encrypted swap)
<smoser> it ends up being mounted, just annoying.
<smoser> i dont have /tmp on separate mp
<infinity> smoser: The special thing about my case is that /tmp isn't actually a mountpoint here.
<slangasek> smoser: does it time out?
<slangasek> smoser: or do you only see the message briefly because it really is taking a while to find itself?
<smoser> slangasek, briefly during boot... i dont knwo tha tit goes away, but it goes to login screen. (i didn't know if it was the login screen that wiped it off the display). it does get mounted.
<smoser> but in most cases where i have swap i see the message on the boot screen
<slangasek> hmm
<smoser> granted i probably have encrypted swap everywhere
<smoser> as i have a encrypted home user everywhere.
<slangasek> yep
<slangasek> smoser: build-tested only: http:?/people.canonical.com/~vorlon/mountall-more-asyncer.patch
<slangasek> er
<slangasek> http://people.canonical.com/~vorlon/mountall-more-asyncer.patch
<smoser> more asyncer.
<smoser> nice
<smoser> slangasek, did you see the complaints in some logs about dbus and ...
<smoser> process 329: arguments to dbus_server_unref() were incorrect, assertion "old_refcount > 0" failed in file ../../dbus/dbus-server.c line 749.
<slangasek> smoser: there's a bug report about that; I don't yet understand that one either
<slangasek> there's only a single call to dbus_server_unref() in all of mountall, so I'd love to know who is unreffing it for us :P
<arosen> If you do apt-get installl <blah> apt will automatically resolve the dependencies for you. Is there anything like that if you do dpkg -i foo.deb?
<ion> arosen: Offtopic for this channel, but anyway: dpkg --unpack foo.deb && apt-get -f install
<slangasek> or just 'gdebi foo.deb'.
<ion> If iâm on a desktop, i just use xdg-open, which opens it in software-center nowadays.
<slangasek> smoser: can I ask you to open a new bug report about this mountall race?
<smoser> are you not happy with the one i have open ?
<smoser> https://bugs.launchpad.net/ubuntu/+bug/1078926
<ubottu> Launchpad bug 1078926 in Ubuntu "raring instance failed to find EC2 datasource" [High,Confirmed]
<slangasek> smoser: no, because you didn't file it against mountall ;)
<slangasek> moving it
<smoser> slangasek, i should spin the kernel issue off to another bug though.
<slangasek> ok
<urgodfather> hello room, does anyone have experience in the gma500 (Poulsbo) chip? im looking to update to the 3.7 kernel, as it has additional bug fixes, but cannot get much insight as to update it properly
<ScottK> barry: Did the pykde4 import fail because someone had pushed to it before the upload?
<slangasek> smoser: ok, bug paperwork done.  do you expect to be able to test that proposed patch today?
<barry> ScottK: i'm only guessing on that one.
<ScottK> OK.
<ScottK> Because that package even has Vcs-foo pointing elsewhere ...
<slangasek> smoser: btw, I guess this is a regression vs. 2.42, but I think it's probably just a partial reintroduction of the same problem we had before 2.41?
<smoser> slangasek, well, this is probably critical or greater at the moment.
<slangasek> so is that a yes? :)
<smoser> as anyone who upgrades on a running cloud instance is looking at a boot time of 260 seconds
 * slangasek nods
<cjwatson> "critical or greater" - signs of severity hyperinflation
<smoser> and if we were to promote a daily we'd have 50% failure boot.
 * cjwatson looks for the wheelbarrows full of bug comments
<smoser> megahyper inflation
<smoser> cjwatson, what would you call it if you regressed grub to having new installs boot only 50% of the time.
<smoser> and existing installs take 4 minutes additional
<smoser> slangasek, i've just built a image with that new deb.
<smoser> i will launch a bunch of instances later.
<slangasek> smoser: ack, thanks
<smoser> and see if it seems fixed.
<cjwatson> smoser: "critical", not "critical or greater" :P
<slangasek> supercritical
<ScottK> hypocritical
<ScottK> No, wait.  That's something different.
<ScottK> ;-)
<mlankhorst> tjaalton: ohey new patch to make libgallium shared on mailing list btw
<slangasek> smoser: have trivially proven to myself that this patch is broken; fixing now
<slangasek> smoser: ok, have pushed a better patch now, this time it survives my own test. http://people.canonical.com/~vorlon/mountall-more-asyncer.patch
 * mlankhorst pokes slangasek 
<slangasek> smoser: I'm sufficiently convinced of it's correctness that I'm going to push it to Debian unstable now so we can get it on its way; but please test and let me know if I've missed anything
#ubuntu-devel 2012-12-04
<Monotoko> hey guys... I was just wondering why there isn't an option on install for partner repos? I installed Linux for someone the other day and they couldn't figure out how to get Skype installed...
<xnox> barry: no problem, it was a small script that we don't even use by default ;-)
<Monotoko> is it a licensing issue or something else?
<xnox> barry: i have gnome-sudoku done as well but hoping robert_ancell will look into merging it upstream in gnome =)
<barry> xnox: hey, as long as i can turn a row green, i am happy :)
<barry> xnox: \o/
<xnox> =))))))
 * xnox has a headhacke so zzzz now =)
<slangasek> Monotoko: aren't these applications visible in the software-center without first enabling partner?
<Monotoko> slangasek, she said she had an error while trying to install... something about the repos... so I installed the partner ones via SSH
<Monotoko> and it seems to have worked
<Monotoko> but if the error was something else I apologise
<cjwatson> Monotoko: As far as the Ubuntu installer is concerned, partner is enabled by default.
<cjwatson> Monotoko: There was an error in a skype update the other day that might have been what they ran into.  It was fixed shortly afterward, but it would depend on the time window in question.
<cjwatson> Monotoko: (If it was last Wed/Thu or thereabouts, it was probably that error.)
<smoser> slangasek, i'll rebuild, but the first patch of more asyncer was 6/6 in the ones i launched. i'll rebuild, and then do a test of at least 20.
<slangasek> smoser: 6/6 success or fail?
<slangasek> because it failed consistently here for me, there was an obvious bug once I looked at it
<smoser> 6/6 success. it found the datasource in all, and imported ssh keys and such.
<smoser> http://paste.ubuntu.com/1409242/
<smoser> (console log, the portion that plymouth didn't eat)
<smoser> but i'll re-try
<slangasek> smoser: right, so it /happened/ that in your case, the events from both / and /run were ready to go in the same iteration of the loop so you're unaffected by my bug; adding a hard 'sleep 60' to a job exposes it nicely
<slangasek> smoser: so the new patch should work equally well for you
<smoser> slangasek, its wierd.
<smoser> there has to be some relation to this and the plymouth issue.
<smoser> as with your newly patched version (2.46) i see the cloud-init local messages in every one
<arosen> zul:  ping
<zul> arosen: pong
<slangasek> mlankhorst, bryce: for wayland and libdrm, it seems that only the -dev packages have the "xorg-renamed-package" provides; shouldn't the other packages have this too?
<slangasek> bryce, mlankhorst: the xorg-server-lts-quantal in the new queue is based on an xorg-server that's still awaiting verification in quantal-proposed; any chance we can get that verified quickly, so we don't have to worry about accidentally letting wrong changes into precise-updates (since this won't hit the normal verification checks)?
<dholbach> good morning
<pitti> Good morning
<pitti> slangasek: some deps> yes, I also get it; I know why, but I didn't address that yet
<mlankhorst> slangasek: renamed libs are special
<mlankhorst> since only the -dev packages would conflict, I only added xorg-renamed-package on those
<mlankhorst> however for mesa, everything would conflict, so they all provide it
<mlankhorst> but yeah I should have kept in mind about the quantal -proposed queue, I would have expected things to clear sooner but not going to happen. :P
<tjaalton> stokachu: it is done
<mlankhorst> hold on let me check if I can put up a 10.8 version instead..
<mlankhorst> woops wrong version, meant the one not from proposed in quantal, anyhow the proposed quantal version should be reasonably safe, let me reverify quantal fixes just in case. :-)
<infinity> xnox: Gah.
<xnox> infinity: =))))
<infinity> xnox: If your pkg-create-dbgsym changelog is accurate, DO NOT WANT.
<xnox> infinity: why not? pitti, Daviey & me do want it.
<infinity> xnox: xz -9 will take FOREVER to compress.
<cjwatson> Yeah, surely it will kill our build queue.
<xnox> infinity: do you want -6
<infinity> xnox: There was a reason we agreed on -6 or -6e
<infinity> xnox: -6 is the default, even, for this same reason.
<xnox> infinity: me didn't recall if it was which one it was. Will the xz -6 be ok?
<cjwatson> Just lose the -z6
<cjwatson> Or the -z9
<xnox> infinity: -6e is not supported by dpkg in precise which we need in the retracers.
<infinity> xnox: 6 is fine, which is the default, so just drop the -z9, as Colin says.
<xnox> (dpkg-deb that is)
<infinity> xnox: Don't do 6e anyway, I just looked up the CPU use tables.
<xnox> cjwatson: infinity: ack.
<xnox> cjwatson: infinity: can you block the upload from migrating? /me will be away from the keyboard for ~0.5h now.
<infinity> Switching to xz will slaughter ARM on some of the large packages anyway, but no need to make it worse. :P
<xnox> or I will fix it in an hour =)
<infinity> xnox: I'll fix it right now.
<xnox> infinity: thanks
<cjwatson> I don't suppose we can use xz just on fast architectures?
<cjwatson> (I guess this was discussed ...)
<infinity> cjwatson: If it looks awful, we can always back off.
<cjwatson> Fair enough
<infinity> xnox: Uploaded.
<infinity> cjwatson: I expect it'll look pretty ugly for, say, webkit, but in most cases, should be fine.  I guess we'll see over time if it's a loss we're okay with suffering, or if we have to exclude armhf until we have arm64 buildds.
<didrocks> hey infinity, maybe you will have an idea: seems that rebuilding compiz (the distro version) with no code change shows a lot of new issues like bug #1085581
<ubottu> Launchpad bug 1085581 in Compiz "new windows open below panel and launcher (raring staging ppa)" [High,New] https://launchpad.net/bugs/1085581
<didrocks> rebuilding the same on quantal doesn't show this kind of issue, running compiz built on 2012-11-12 doesn't show the issue as well
<didrocks> rebuilding the same code today is experiencing that
<didrocks> (but I don't know when the regression started)
<didrocks> I tried (but maybe wrongly) to downgrade binutils and gcc, without any luck
<didrocks> doko would maybe have an idea as well ^
<didrocks> (it's like if some compiz plugins, despite telling they are loaded are ignored)
<infinity> didrocks: Diff the build logs for new warnings?
<infinity> didrocks: And if it's plugins failing to load, that should be easy to trace, right?
<didrocks> infinity: they don't fail to load though
<didrocks> it's like if they were not acting
<didrocks> infinity: so, let me try to send that in ppa
<didrocks> and then do the diffing
<didrocks> to ensure having the same env
<infinity> didrocks: Well, there's likely one of three options here.
<infinity> 1) The toolchain got stricter, and some bad code got a bit worse due to it.
<infinity> 2) The toolchain has a regression somewhere.
<infinity> 3) A build-dep had an SOVER bump and the new version of libfoo is broken.
<didrocks> infinity: apart from gcc and binutils (that I maybe missed something in the downgrade path), for the "toolchain", do you see anything else?
<infinity> didrocks: So, check all your dependencies on the Q and R builds to see if they're actually the same (they may well not be), and then go from there.
<didrocks> infinity: yeah, I'll do that as well
<infinity> didrocks: linux-libc-dev and libc6-dev would be the other major toolchain changes, but unless compiz is using libc internal symbols (which I wouldn't put past it, I suppose), libc shouldn't have broken it, and it really shouldn't be using much scary from linux headers.
<didrocks> infinity: indeed, I'll try the libc6 road anyway. Boost is out because it didn't change since the last upload to raring
<infinity> didrocks: build-deps changing would be the most likely scenario, though, IMO.  And if it was an ABI bump, that would explain why Q builds work fine on raring (cause they'd use the old lib).
<didrocks> infinity: yeah, I'm going to diff the deps of compiz
<infinity> didrocks: Are the two plugins mentioned (place and grid) shipped in the main compiz package?
<didrocks> infinity: yeah, all plugins are in the main compiz source now
<didrocks> (apart from unity)
<infinity> Not the main source, I meant the main binary package.
<didrocks> ah, its in compiz-plugins-default
<infinity> (Just trying to figure out what I should be drilling down to)
<infinity> Kay.
<didrocks> and the other bin is in compiz-core, containing the main compiz bin
<infinity> So, the only bumped dep I see is libdecoration0, but not an ABI bump.
<infinity> Not terribly exciting, unless its headers broke.
<infinity> Oh, that comes from compiz.
<infinity> Nevermind.
<didrocks> infinity: so it seems that compiz-core is the guilty one
<didrocks> infinity: if I install locally built compiz-plugins-default and old-distro-build compiz-core, it's working
<infinity> didrocks: Due to the SOVER and ABI bump?
<infinity> Files in second .deb but not in first
<infinity> -------------------------------------
<infinity> -rw-r--r--  root/root   /usr/lib/libcompiz_core.so.0.9.9
<infinity> -rw-r--r--  root/root   /usr/share/doc/compiz-core/changelog.gz
<infinity> lrwxrwxrwx  root/root   /usr/lib/libcompiz_core.so.ABI-20121130 -> libcompiz_core.so.0.9.9
<infinity> Files in first .deb but not in second
<infinity> -------------------------------------
<infinity> -rw-r--r--  root/root   /usr/lib/libcompiz_core.so.0.9.8.5
<infinity> -rw-r--r--  root/root   /usr/share/doc/compiz-core/changelog.Debian.gz
<infinity> lrwxrwxrwx  root/root   /usr/lib/libcompiz_core.so.ABI-20120927 -> libcompiz_core.so.0.9.8.5
<seb128> infinity, there is an ABI bump in the ppa but didrocks is testing by simply rebuilding the current raring version atm so that rules the ABI change out
<didrocks> infinity: oh, I'm just doing a 1:0.9.8.4+bzr3412-0ubuntu1 rebuild in fact
<infinity> didrocks: Or is this all rebuilding the old version?
<didrocks> to remove this parameter
<infinity> Kay.
<didrocks> so yeah, staying on the same version
<infinity> So, compiz-core is being misbuilt (or, more likely, has buggy code that a new toolchain is less forgiving about).
<infinity> Definitely diffing build logs would be a good next step.
<didrocks> infinity: can you rescore https://launchpad.net/~didrocks/+archive/ppa/+build/4035589 please?
<infinity> Yep.
<didrocks> so that we have a clean ppa build
<didrocks> thanks :)
<infinity> Is that enough 9s?
<didrocks> I will live with this :)
<didrocks> I see no warning, nothing weird on my local build
<didrocks> diffing will be better
<infinity> That's disconcerting.
<infinity> What's compiz's build time?  I'll throw it at a couple of local sbuilds.
<didrocks> no change in dep
<didrocks> infinity: on a i7, it's 6-7 minutes
<didrocks> 25 minutes on a normal machine
<infinity> 6 it is, then.
<infinity> Well, my i7 is only 2 cores, so maybe not 6. :P
<didrocks> 14:45:24   didrocks | no change in dep -> I meant, compiz-core still have the exact dep, so no soname bump
<didrocks> infinity: heh, should still be quicker than my old laptop :)
<infinity> Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz
<infinity> Yeah, it's not awful.
<infinity> The 16G of RAM and building everything in a tmpfs also helps.
<didrocks> I saw worse :-)
<didrocks> I feel so unpowered with 8G of RAM now! :)
<infinity> I kinda want 32...
<didrocks> heh
<infinity> didrocks: Oh, wait, you said a build in raring on 2012-11-12 was also okay?
<didrocks> infinity: right
<didrocks> if you takes those debs (the one you currently have in raring), they are working fine
<didrocks> well, more exactly, we now know that it's the compiz-core from that date which is fine contrary to one we can produce today
<didrocks> I wonder if something changed in the dlopen world, as it's what compiz is doing for its plugin (but it's still dlopening as we have unity loaded and some other plugins like the ws one seems to work)
<infinity> Okay, that rules out glibc 2.16.  It might implicate binutils 2.23.
<infinity> glibc was a week or two before that, but binutils landed right in your window.
<didrocks> I tried to downgrade it to 2.23-2ubuntu1 (and I removed ccache)
<infinity> So, I'd be inclined to try hard to downgrade binutils. :P
<infinity> didrocks: No, no.  To 2.22.90... from quantal.
<infinity> didrocks: If this is a binutils bug, it would have likely come with 2.23
<didrocks> but it landed the 6?
<infinity> didrocks: In proposed.  Your PPA doesn't build against proposed.
<didrocks> it wasn't the PPA at the time
<didrocks> just a direct upload to proposed
<infinity> Oh, this 2012-11-12 build you speak of was in the archive?
<didrocks> let me grab the build log :)
<seb128> infinity, https://launchpad.net/ubuntu/+source/compiz/1:0.9.8.4+bzr3412-0ubuntu1
<seb128> didrocks, Get:9 http://ftpmaster.internal/ubuntu/ raring/main binutils i386 2.23-2ubuntu1 [2439 kB]
<infinity> Kay.
<didrocks> Setting up binutils (2.23-2ubuntu1) ...
<didrocks> yep
<infinity> Toolchain package versions: libc6-dev_2.16-0ubuntu3 make_3.81-8.2ubuntu2 dpkg-dev_1.16.9ubuntu1 gcc-4.7_4.7.2-5ubuntu5 g++-4.7_4.7.2-5ubuntu5 binutils_2.23-2ubuntu1 libstdc++6-4.7-dev_4.7.2-5ubuntu5 libstdc++6_4.7.2-5ubuntu5
<infinity> That rules out most of the usual suspects, unless doko pulled in some breakage in a GCC SVN cherrypick.
<didrocks> cmake
<didrocks> it is cmake ! :/
<infinity> Oh, right.  cmake.
<infinity> It's always cmake.
<didrocks> thanks for the suggestion seb128
<seb128> didrocks, yw!
<didrocks> cmake, 2 unity strikes in 1 upload :/
<infinity> didrocks: Did you find it in a log diff, or just manually?
<seb128> see, I don't like autotools but cmake is in another league :p
<didrocks> infinity: manually up to now
<didrocks> let's see the build logs if nothing relevantâ¦
<seb128> the ppa build is almost done, will be able to diff the build logs
<infinity> didrocks: Oh, you're blaming cmake without having actually found an issue yet? :)
<infinity> I'm all for that.
<didrocks> infinity: ah no :)
<didrocks> infinity: manually -> just downgraded cmake
<didrocks> and built
<infinity> Ahh.
<didrocks> installed the new compiz-core
<infinity> Effin' cmake.
<didrocks> and it's working
<didrocks> I'm mad TBH :)
<infinity> Wait.  I thought I saw some cmake spew scroll by in one of my logs..
<infinity> Oh, no, that happened in the old build too.
<infinity> Anyhow, if you're down with blaming cmake, I can stop panicking about base toolchain malfunctions.
<didrocks> infinity: indeed :-)
<didrocks> infinity: well, at least, I'm happy it's scoped now
<infinity> Now, if we could only remove cmake, and everything that {build-,}depends on it from the archive.
<bregma> +1
<didrocks> ;)
<ogra-cb> add a Provides: cmake to autotools ?
<pitti> infinity: I thought you had that power :)
<infinity> pitti: I do.  It conflicts with my power to draw a paycheque.
<didrocks> :)
<didrocks> one cmake, 2 hairy unity issuesâ¦
<tumbleweed> xnox: isn't xz -9 a little excessive?
<tumbleweed> oh infinity noticed
<infinity> tumbleweed: You're living in the past, catch up on -changes.
<infinity> :P
<didrocks> infinity: anyway, let's see if I can dive a little bit more than a revertâ¦ Thanks a lot for testing in //, that helped to keep me motivated :)
<infinity> No problem.  Always happy to wear skis for a coworker.
<xnox> tumbleweed: you should lock responding until finishing the daily catchup.
<didrocks> :)
<xnox> tumbleweed: =)))))))
<tumbleweed> xnox: that was actually a 15 minute catchup. I'm waiting for a build :)
<xnox> tumbleweed: ah, fair enough then.
<pitti> didrocks: for your magic PPAs which produce ddebs, do you need to do anything else than just build-dep'ing on p-c-dbgsym? I suppose you need dpkg-distaddfile the ddebs?
<didrocks> pitti: so normally, there is a configuration to ask to be checked
<pitti> didrocks: I think that already has been done when we asked for the PPA
<didrocks> pitti: but for copying to the archive, this config was occuring to create another issue for copying the ddebs to the distro
<pitti> didrocks: ah, this package is not ever going to land in the archive
<pitti> in Ubuntu, I mean
<didrocks> pitti: so normally, you just open a RT to add ddebs to the ppa
<infinity> pitti: No build-dep needed, it's in the chroots.
<infinity> pitti: But yeah, there's a config twiddle.
<pitti> didrocks: I mean, did you have to add distadfile to get the .ddebs into the .changes?
<didrocks> no, you don't need it as infinity said
<infinity> pitti: The config twiddle tells pkg-create-dbgsym to add it to changes.  Didn't you write that code? :P
<pitti> infinity: ah, ok; because it didn't seem to be installed in the https://launchpad.net/~daisy-pluckers/+archive/daisy-seeds/+packages builds
<infinity> if [ "$add_to_files" = "1" ]; then
<infinity>     dpkg-distaddfile "$ddeb" "$ddebsection" "$ddebpriority"
<infinity> fi
<infinity> pitti: Yeah, it's a PPA twiddle.
<pitti> infinity: ah, so I guess they missed that part of our request
<infinity> pitti: But, we should get down to testing and fixing soyuz ASAP and get rid of these tiwddly hacks.
<infinity> Maybe I can try to schedule that before Christmas holidays happen.
<pitti> infinity: write that code> argh, but this was years ago or so; don't expect my brain to work _that_ well :)
<mvo> cjwatson, ev: not sure if you are still right people but at some point a quick review of https://code.launchpad.net/~mvo/ubiquity/ssologin/+merge/137264 if the basic structure makes sense would be nice from one of the real ubiquity developers :)
<infinity> stgraber / xnox: ^^
<xnox> mvo: yeah about that.
<infinity> mvo: Props on revision 5801. :P
<pitti> infinity: ok, so I'll sent an RT to get that PPA ddebified
<infinity> pitti: Which is a PPA that will never be copies to the archive, I assume?
<pitti> infinity: b-deping on p-c-d isn't sufficient then?
<infinity> s/copies/copied/
<pitti> infinity: right
<xnox> mvo: there were a few of us discussing sso in the bluefin office on friday & there is an idea to show it on first-login after install or upgrade, when there is network connectivity to catch more userbase.
<infinity> pitti: There's no need to build-dep on it at all, it's in all the chroots anyway.
<pitti> we just need it for some test packages for daisy/apport/juju chamrs
<xnox> mvo: since if ubiquity is run offline there isn't much that can be done.
<infinity> pitti: It just keys off a CurrentlyBuilding twiddle.
<mvo> xnox: indeed, either way is fine with me
<pitti> infinity: right, but I wondered if an RT is mandatory for this
<infinity> pitti: An RT, or a #webops ping.
<xnox> mvo: ok. I will send an email out and CC you on it, such that you are up to date.
<mvo> xnox: great, thanks. if its going to be in the installer this branch is probably the right starting point, if not, well, the glade and the logic is still a good starting point
<infinity> elif grep -qs '^Build-Debug-Symbols: yes$' /CurrentlyBuilding; then
<infinity>     addtofiles="-a"
<infinity> else
<mvo> infinity: *coug* ;)
<mvo> (re 5801)
<xnox> mvo: I looked at your branch & I like it better than the qt stuff in the u1 installer visual-wise. But visuals may or may not change come the release time.
<mvo> xnox: *nod*
<jcastro_> infinity: hey, this is is the sort of thing you always know, any idea why natty isn't on old-releases yet?
<infinity> jcastro_: Lack of round tuits.
<cjwatson> http://people.canonical.com/~cjwatson/cross/armhf/raring/ for the interested/borderline-insane
<cjwatson> (results of attempting to cross-build all of raring/main from amd64 to armhf)
<infinity> jcastro_: By which, I assume you mean the archive portion, not the ISOs (which seem to be on old-releases)
<infinity> cjwatson: Oh joy, this would be where we get our "fix five broken packages" from? :)
<cjwatson> infinity: Aye
<jcastro_> oh am I looking in the wrong place? http://old-releases.ubuntu.com/ubuntu/dists/
<infinity> jcastro_: That depends on what you're looking for.
<infinity> jcastro_: Images, or packages?
<jcastro_> packages
<infinity> jcastro_: If you want packages, you're looking in the right place, and correct that they're not archived yet.
<infinity> cjwatson: Oh, hey, apache2 looks like an easy fix (famous last words).
<mdeslaur> jcastro_: every time you ask a question like that, I always find out why by looking at askubuntu.com :)
<penguin42> cjwatson: gawk just seems to be making the mistake of running a test suite on itself
<jcastro_> mdeslaur: hey it's a legit question!
<mdeslaur> hehe :)
<infinity> penguin42: Yeahp, most of these are simple fixes.  Just lots of them.
<cjwatson> infinity: Possibly, yeah
<OdyX> pitti, tkamppeter__ : fyi: security fix uploaded for Wheezy / cups 1.5.3 .
<penguin42> it might work if you installed qemu :-)
<cjwatson> penguin42: Yeah, let's not tell me about all of them
<cjwatson> penguin42: It's deliberate this way
<pitti> OdyX: thanks muchly for handling this!
<cjwatson> penguin42: You can cross-build more if you use qemu-user-static, yes; but that won't help with bootstrapping arm64
<infinity> cjwatson: Do you have simple destructions for reproducing the cross build environment?
<cjwatson> gawk is probably a matter of honouring DEB_BUILD_OPTIONS=nocheck
<infinity> nocheck, but it should probably also have an if HOST != BUILD guard.
<infinity> All testsuites should, IMO.
<infinity> (Well, all testsuites that run native code)
<cjwatson> Then you can't run them under qemu if you have that set up.
<cjwatson> nocheck is sufficient, I think - sbuild sets that for host != build at the moment
<infinity> Oh, I suppose.
<infinity> Actually, glibc's is wildly perverse (and works in the qemu case).
<infinity> It tests if ld.so can be run. :P
<infinity> cjwatson: So, yeah, if you have "this is how to reproduce this madness" steps somewhere, I'll pick off a bunch of these.
<infinity> cjwatson: Since I'm assuming cross-build-whatever doesn't exist in the archive yet, etc.
<cjwatson> infinity: mk-sbuild --target=armhf, move the chroot to the right name if slangasek hasn't fixed that bug yet, do the crazy buildflags.conf thing from https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/arm64bootstrap if doko hasn't fixed the toolchain yet (you probably want to ignore the rest of that page), and put "$crossbuild_core_depends = { armhf => ['build-essential', 'gcc-arm-linux-gnueabihf', ...
<cjwatson> ... 'g++-arm-linux-gnueabihf', 'pkg-config-arm-linux-gnueabihf', 'dpkg-cross'] };" in .sbuildrc if we haven't yet got crossbuild-essential-armhf
<cjwatson> That should be close enough for government work, anyway
<cjwatson> Then sbuild --build=amd64 --host=armhf -d raring -c raring-armhf blah.dsc
<infinity> Oh, wait, can I just reuse the armhf chroots I already have?
<infinity> (removing qemu to force failures, I guess)
<cjwatson> Are they full of x86 binaries?
<infinity> No, they're full of... Oh, --TARGET, not --arch.
<infinity> Derp.
<cjwatson> Right
<cjwatson> --arch=amd64 --target=armhf in fact
<cjwatson> If you're on an i386 host
<infinity> Which I'm not, but yeah.
<cjwatson> Oh, and please forward fixes to Debian with User: crossbuild@debian.org Usertags: cross
<infinity> Will mk-sbuild bomb out if it tried to build over an existing chroot?
 * infinity kinda doesn't want to blow up his current ones.
<tumbleweed> yes
<infinity> (base)adconrad@cthulhu:~$ mk-sbuild --arch=amd64 --target=armhf raring
<infinity> E: /var/lib/schroot/chroots/raring-amd64 already exists; aborting
<infinity> Indeed.
<cjwatson> You can use --name=random-garbage or something if you want to make sure
<cjwatson> And move at the end
<infinity> What should these actually be named when all is said and done?
<infinity> -amd64-armhf or something?
<cjwatson> Probably something like that
<infinity> Well, I mean, so sbuild finds them magically. :P
<cjwatson> I'm using -armhf because I have no native chroots here
<cjwatson> I think we'll need to patch sbuild to look for $build-$host if we want to support both native and cross chroots on the same system
<infinity> I'd certainly like to.
<infinity> I realise I'm a weird corner case, but I do a lot of native armhf testbuilds on my laptop.
<infinity> For now, though, I can stop doing that.
<cjwatson> One other thing: the build coordination is fairly bodgy at the moment, and I'm occasionally prodding it by hand
<infinity> It's not like I don't have a bunch of faster-than-qemu ARM kit.
<cjwatson> So it's not *quite* completely automatic
<cjwatson> Though it's close
<cjwatson> Most of the BD-Uninstallable entries amount to "need to multiarch some stuff"
<cjwatson> The bulk of which is complicated: python, perl, gobject-introspection
<cjwatson> There are probably a handful of bits of low-hanging fruit left, though, where we just need to make some tool M-A: foreign or need to make some simple library M-A: same
<mlankhorst> would be nice if some of the -dev packages would coinstall too, is M-A: same ok when some headers are not installed on all archs, but otherwise the same?
<cjwatson> Quite a lot of -dev packages are coinstallable
<cjwatson> In such a case I suppose you'd need to think about whether having the union of all installed headers would confuse things
<infinity> Problematic if headers of the same name end up on the search path in different spots, otherwise generally okay.
<mlankhorst> probably not, libdrm_intel.pc would still not be available on arch
<infinity> Ish.
<infinity> But yeah, you need to look at it case-by-case.
<mlankhorst> so having a global i915_drm.h should be harmless
<mlankhorst> shrug, I'll try building and find out
<infinity> mlankhorst: Well, harmless, unless a configure script considers the existence of the header to mean something.
<infinity> mlankhorst: But this is why we have arch-specific include paths.
<shadeslayer> chrisccoulson: I see that you're the one usually uploading ubufox, I was wondering if you know of a way to ship a systemwide firefox profile
<mlankhorst> only packages that care about libdrm are mesa and plymouth, and i think they properly use pkgconfig
<infinity> mlankhorst: Famous last words. ;)
<infinity> mlankhorst: For MA -dev packages, you really do want the headers in arch-specific paths, IMO, even if they're 99% the same.
<infinity> Then you avoid worry about if it's a problem.
<infinity> s/worry/worrying/
<mlankhorst> might actually break things though, most are lazy with path..
<infinity> Hrm?
<infinity> GCC has the paths by default.
<infinity> People who can't sort out how to type #include <foo.h> get what they deserve.
<infinity> (Or people who build with -nostdinc)
<mlankhorst> shrug we used to build libdrm_intel on arm
<infinity> mlankhorst: You could follow glibc's lead, and put only arch-specific stuff in arch dirs, but that requires actually paying attention.
<infinity> mlankhorst: (See 'dpkg -L libc6-dev')
<mlankhorst> yeah probably will do that, wine build-deps for i386 is a good testcase btw..
<mlankhorst> tons of -dev without m-a same..
<infinity> There's no harm (other than wasted disk space) in just shoving all your headers in the arch-specific path.
<infinity> If our toolchain didn't work with that, we'd be pretty screwed already.
<mlankhorst> considering how some utils like to hardcode path for libdrm, would prefer not to change it
<infinity> Well, wasted disk space, and possibly broken configure scripts, but testing for the latter is just some rdep rebuilds.
<doko> cjwatson, what do you mean by "fixed'? the linker paths?
<infinity> mlankhorst: Things hardcode the path to the HEADERS?
<cjwatson> doko: Yeah, the -rpath-link thing that we talked about at UDS
<cjwatson> Or rather the need for it
<cjwatson> I thought Steve was getting you a reduced test case for that?
<mlankhorst> infinity: cant remember where I saw -I/usr/include/libdrm though
<cjwatson> doko: Oh, possibly it was a cross-toolchain issue that Steve was going to talk with hrw about
<infinity> mlankhorst: Eww, instead of #include <libdrm/foo.h>?
<cjwatson> There's an item for it on foundations-r-improve-cross-compilation
<cjwatson> Which I'm going to mark done because it's bug 923779
<ubottu> Launchpad bug 923779 in armel-cross-toolchain-base (Ubuntu) "cross-linker behaviour differs from native linked" [Undecided,Triaged] https://launchpad.net/bugs/923779
<cjwatson> hrw: Have you been able to get anywhere with that bug ^ ?
<mlankhorst> infinity: well libdrm fails without $(pkg-config --cflags libdrm) anyway..
<infinity> cjwatson: Hrm, sbuild seems to want to use my raring-amd64 chroot by default for this.  That's a bit suboptimal.
<infinity> Ahh, I can feed it --chroot
<cjwatson> infinity: Yeah, that's why my directions included -c
<infinity> Bingo.
<cjwatson> (I have an sbuild-cross wrapper to make it less tedious)
<infinity> Let's see how this goes.
<infinity> Hrm, except for the odd failure to umount my overlay, that seemed to go well.
<doko> cjwatson, hrw's cross-use-multiarch-dirs.patch is not yet in binutils, and probably it shouldn't. 129_ld_mulitarch_dirs.patch should do the trick
<doko> and the 4.diff is definitely wrong how to derive the multiarch name
<cjwatson> infinity: Not a problem I've seen ...
<cjwatson> doko: Oh, so this might just be a matter of updating the -base packages?
<cjwatson> Against new binutils source?
<infinity> cjwatson: No, it's a random schroot hiccup, I think.  Trying again.
<infinity> cjwatson: What's the expected failure mode if I don't do the rpath-link twiddle?
<infinity> Granted, my testcase of GNU hello was a bit simplistic, but it went fine without.
<cjwatson> infinity: It's in bug 923779
<ubottu> Launchpad bug 923779 in armel-cross-toolchain-base (Ubuntu) "cross-linker behaviour differs from native linked" [Undecided,Triaged] https://launchpad.net/bugs/923779
<doko> cjwatson, given that the toolchain is from april, probably yes
<cjwatson> I think it only fails when you have indirect library linkage; hello won't have that
<rbasak> infinity: around? Do you remember the conversation a long time ago about update-initramfs parameters when called from flash-kernel-installer.postinst?
<rbasak> infinity: it's broken ATM because the installer is using 3.5.0-17-highbank but the installer installs 3.5.0-19-highbank, so update-initramfs fails
<rbasak> Is the solution just to bump d-i's kernel, or is there a better answer?
<rbasak> I don't recall the details of that previous conversation and why we went with in-target update-initramfs -c -k $(uname -r)
<infinity> rbasak: Wait, what's using $(uname -r)?
<infinity> rbasak: That's going to be wrong more often than right.
 * rbasak looks
<infinity> Ugh, f-k-i does?  Eww.
<rbasak> infinity: I think it's http://paste.ubuntu.com/1410440/ line 75
<rbasak> infinity: IIRC, -k all didn't work or something like that? I'm sure I had a conversation with somebody along these lines
<infinity> Yeah, like I said, f-k-i.
<infinity> rbasak: Is this actually causing a problem?  Installing kernel packages should be generating a proper initrd anyway.
<rbasak> infinity: there is a problem. I might have the root cause wrong though. ATM, quantal highbank d-i netinst is broken.
<infinity> Oh dear.  No, installing kernel packages won't generate an initrd, cause update-initramfs is diverted.
<ogra_> in-target update-initramfs -c -k $(uname -r) || true
<ogra_> it cant cause a problem
<ogra_> unless 7bin/ture is gone :)
<rbasak> $(uname -r) doesn't match the installed kernel
<rbasak> I think that's the issue
<infinity> ogra_: Yes, the problem is that it doesn't generate an initrd. :P
<ogra_> */bin/true
<infinity> This code is terribly wrong.
<infinity> rbasak: So, this is going to need a more clever in-target to find the installed kernels, if -k all really isn't working right.  But I'd like to know why that is first.
<ogra_> we have a function for that iirc
<infinity> ogra_: For which "that"?
<ogra_> finding the latest kernel
<ogra_> oh
<ogra_> no, its inline, its not a function at all :/
<ogra_> latest_version=$(linux-version list | linux-version sort | tail -1)
<ogra_> but that should do it for f-k-i too
<infinity> ogra_: Except that we don't have linux-version in d-i.
<ogra_> but in the target
<infinity> Oh, fair point.
<ogra_> needs some chrooting etc
<infinity> That'd do the trick, then.
<ogra_> but essentially just replacing uname -r with the value of $ latest_version should do
<infinity> I do wonder if it's intentional that -c -k all doesn't work.
<infinity> Let me dig into that.
<ogra_> i think it is
<ogra_> at some point in time -u did just work for creating them
<ogra_> was so much easier
<mvo> stgraber: \o/
<infinity> ogra_: Reading the code, '-c -k all' should work.
<rbasak> Please don't take my word that -c -k all doens't work. I just vaguely remember something about it and I'm sure we tried using -k all at the time, that's all
<ogra_> iirc i tried it back then with rbasak and it didnt for him
<infinity> ogra_: If version is "all", it just rexecs itself with "-mode -k ver" for all versions.
<ogra_> well, i dont mind using "all"
<ogra_> bug 1056482
<ubottu> Launchpad bug 1056482 in flash-kernel (Ubuntu) "/dev/mmcblk0p1 is not a block device when installing flash-kernel" [Undecided,Fix released] https://launchpad.net/bugs/1056482
<rbasak> it looks like I tried -k all a minute ago and it didn't work, but I'm going to reproduce from scratch to make sure
<rbasak> Will be about 15 minutes I think
 * cjwatson greps old IRC logs
<cjwatson> I remember talking about this
 * ogra_ too
<ogra_> bug 1035269
<ubottu> Launchpad bug 1035269 in The Eilt project "highbank quantal installer regression" [Critical,Fix released] https://launchpad.net/bugs/1035269
<infinity> Oh, hahahaha.
<ogra_> thats it
<infinity> Okay, so "-c -k all" totally rexec with "-c -k $ver" for all versions.  But the version list is from the state dir.
<infinity> Which is empty if you have no initrds.
<infinity> That should be fixed, but not for an SRU.
<ogra_> funny
<infinity> For now, yeah, futzing in the chroot to find the highest installed kernel is the sane route.
<ogra_> oh, wait, we talk about an SRU here ?
<cjwatson> #ubuntu-release 2012-09-26 perhaps?
<infinity> ogra_: Yeah, this is for Q.
<cjwatson> Not as explicit as I remember
<infinity> ogra_: Where d-i/kernel skew is breaking ARM installers.
 * ogra_ isnt sure we had the f-k dep on linux-version back then
<ogra_> have to check
<ogra_> ah, yeah, its 3.0, we should
<infinity> It's basically the same version.
<infinity> R's only one revision ahead.
<stokachu> tjaalton: awesome! thank you so much
<ogra_> k
<infinity> ogra_ / rbasak: Who feels like working up an f-k-i patch for this?
<ogra_> so: latest_version=$(in-target linux-version list | in-target linux-version sort | tail -1)
<ogra_> does that look ok ?
<infinity> If it works, sure. :P
 * rbasak will try it in a moment
 * ogra_ wonders if the pipe will behave
<ogra_> cjwatson, there must be something older
<ogra_> flash-kernel (3.0~rc.4ubuntu20) quantal; urgency=low
<ogra_> * seemingly -k all doesnt want to work with -c, use -k $(uname -r) for now
<ogra_>  -- Oliver Grawert <ogra@ubuntu.com>  Fri, 10 Aug 2012 18:29:34 +0200
<ogra_> we surely discussed it before the upload date
<cjwatson> Yeah, I failed to find it
<infinity> ogra_: If there isn't a Debian bug for that, can you file one?  My gut feeling is that -kall for create should include all kernels installed EVAR.
<infinity> ogra_: But I'd rather fix it upstream with maks reviewing it, than hack it in Ubuntu for no good reason.
<rbasak> http://irclogs.ubuntu.com/2012/08/10/%23ubuntu-devel.html#t15:09 perhaps?
<ogra_> heh awesome
<ogra_> and it has the answer for my "in-target" question from above ... cjwatson pro-actively answered it back then already
<rbasak> Running two in-targets in a pipeline screwed up. I guess it's trying to do the setup and teardown twice concurrently
<cjwatson> Yeah, I can believe that
<cjwatson> either use a temporary variable or use   in-target sh -c '...'
<ogra_> yeah, was just looking at the latter
<rbasak> Everything seemed to stop working so rather than poke I just set off a reinstall
<rbasak> "in-target: Unexpected error; command not executed: 'echo yes'"
<ogra_> latest_version=$(in-target sh -c 'linux-version list | in-target linux-version sort | tail -1')
<ogra_> try that
<cjwatson> tail -n1 please
<cjwatson> may as well be POSIXy
<ogra_> k
<rbasak> ack
<cjwatson> rbasak: command not executed> I think that's what you get if you omit the sh -c?
<cjwatson> Oh, no
<cjwatson> That's if chroot_setup fails
<cjwatson> So, yeah, reboot :)
<infinity> Temp variables are way more readable than nested sh -c
<rbasak> cjwatson: I think in-target completely broke after attempting the double in-target pipeline. No command worked after that. I'm just reinstalling rather than worrying about the stuffed environment
<cjwatson> It's rescueable by hand but not worthit
<rbasak> Yeah
 * ogra_ grumbles about linux-version 
<ogra_> why doesnt it just ahve a --latest option
<infinity> Because it hates your freedom.
<ogra_> heh
<rbasak> ogra_: a couple of minor corrections: latest_version=$(in-target --pass-stdout sh -c 'linux-version list | linux-versi
<rbasak> on sort | tail -n1')
<ogra_> oh, right, forgot about --pass-stdout
<rbasak> this appears to work from the shell. Note that I'm testing with only one kernel installed currently. I'll see if I can try with a second.
<cjwatson> Heh, yes, I should have spotted that
 * rbasak learned about --pass-stdout the last time round
<infinity> rbasak: in-target apt-get install linux-image-3.5.0-17-highbank should do.
<ogra_> well, i was even referring to it above :)
<infinity> rbasak: Since we know that one exists. :P
 * rbasak tries
<rbasak> Though I wonder. Will f-k-i.postinst ever run with two kernel installed, OOI?
<ogra_> rbasak, pretty unlikely but you never know
<cjwatson> On cross-building: somebody brave might try to get qt4-x11 to work.  It's possible it just needs to be told to use the correct compiler and linker
<rbasak> I've broken something. Is this because I used in-target apt-get install instead of apt-install?
<infinity> Oh, maybe.
 * rbasak reboots again
<ogra_> btw, why dont we have the kernel version exported in some variable or sitting in some preseed value we could ask
<ogra_> (by the code that selects the right kernel during installation i mean)
<infinity> You could source /usr/lib/base-installer/kernel.sh and use arch_get_kernel_flavour with some archdetect magic.  But that's way more hassle than just checking what's in the chroot.
<infinity> Plus, also fails with different installer types.
<infinity> So, don't do that. :P
<ogra_> yeah, i was more thinking about a preseed template from base-installer or so
<ogra_> it already has a bunch of kernel things
<ogra_> well, rather initrd
<ogra_> oh !
<ogra_> base-installer/kernel/image
<ogra_> i wonder if we could rely on that
<cjwatson> Won't work for server images which use live-installer
<ogra_> ah, indeed
<rbasak> OK it works for two kernels too
<rbasak> Tested from the network console shell thing
<ogra_> great
<rbasak> latest_version=$(in-target --pass-stdout sh -c 'linux-version list | linux-version sort | tail -n1')
<ogra_> k, will upload to raring in a minute
<rbasak> ogra_: bug 1084106
<ubottu> Error: Launchpad bug 1084106 could not be found
<rbasak> It's private but I'll make it public in a moment
<ogra_> http://paste.ubuntu.com/1410585/
<ogra_> just a final cross check
<infinity> That || true there annoys me.
<infinity> Fine for the SRU, since it was there before anyway.
<infinity> But... If that fails, the system likely won't boot. :P
<ogra_> well, thats raring atm
<infinity> Seems silly to short it.
<ogra_> let me drop it there then
<ogra_> (note that one comes from debian)
<infinity> Keep it in Q, on the off chance it had a purpose I can't divine.
<infinity> But, yeah, drop it in R. :P
<infinity> And we'll find out!
<ogra_> in-target update-initramfs -u || true
<ogra_> thats the original line
<rbasak> lgtm. Unless the version has spaces in it :-P
<infinity> rbasak: That would be a neat trick.
<ogra_> hard to do :)
<unshadow> Hi guys, sorry if this is the wrong channel for that but do you think Ubuntu is going towards or away from mono ?
<ogra_> depends on your speaker setup
<infinity> *rimshot*
<ogra_> most are using a 5,1 one nowadays though
<infinity> unshadow: And yes, this is the wrong channel for that.
<infinity> Oh look, our first build failure in the shiny new daily-upstart PPA.
<infinity> Off to a great start.
<infinity> jodh: *slow clap*
<jodh> infinity: you spotted it, so you get to help fix it :)
<infinity> jodh: If by "spotted", you mean "got emailed about it", sure.  I spotted it.  As did all your teammates. ;)
<infinity> jodh: Public shame fixed many bugs.
<infinity> s/fixed/fixes/
<jodh> infinity: share the love I say
<jodh> infinity: The shame is that we've never had a daily build before. I'm trying to rectify that :) Upstart builds in every other environment and platform we have, so any ideas as to why this is failing welcome.
<infinity> BAD: wrong content in file 0x95464e0 (output), expected 'UPSTART_INSTANCE=
<infinity> ' got 'PWD=/
<infinity> '
<infinity> 	at tests/test_job_process.c:682 (test_run).
<infinity> That's some failure.
<jodh> infinity: something is causing the environment to be different to that expected. It w
<infinity> Seems odd to be that strict about what you expect the environment to be.
<infinity> I'd call that a broken test.
<infinity> Assuming the env *does* have UPSTART_INSTANCE= in it somewhere (and I bet it does), whining because it also has PWD is a bit odd.
<jodh> infinity: it is not a broken test - every aspect of a newly created upstart job is checked - file descriptors, env vars, etc. That way we can guarantee behaviour.
<infinity> So, it's actually a bug to have PWD in the env?  Hrm.
<jodh> infinity: no - it's a bug to have PWD in the environment array at that index.
<jodh> infinity: I think I've just worked out what is causing this behaviour! Thanks for being the sounding board :)
<infinity> :P
<arosen> zul: you aroudn?
<zul> arosen: in a meeting
<zul> arosen: should be available about in a hour
<natschil> Hello. Does the program that mounts things in nautilus for ubuntu completely ignore fstab?
<natschil> I have some mount options I need for a certain usb device I've put into fstab. Whenever I mount it manually using mount(8) it mounts the way I want it to, and clicking the relevant icon in unity brings me to the right place. If I, however, unmount it and then let nautilus mount it, it gets mounted in the wrong mountpoint. I'm now wondering whether this is the way it's supposed to work, or whether there is a bug somewhere.
<mspencer> pitti: png re. bug 657275
<ubottu> Launchpad bug 657275 in apport (Ubuntu) "ubuntu-bug should save reports offline automatically rather than giving a cryptic error message" [Wishlist,In progress] https://launchpad.net/bugs/657275
<pitti> slangasek: actually, I think "set gnutarget elf32-littlearm" might just work; thanks for this!
<pitti> mspencer: hello
<mspencer> pitti: You were suggesting asking the user where to save the report. However, it looks like apport only has the ability to show an open file dialog.
<mspencer> pitti: what would you like me to do about this? add a new function, modify the current one to add a type option, or what?
<mspencer> pitti: The UserInterface.ui_question_file function only shows an open file dialog.
<cjwatson> doko: Hm, you said that armhf-cross-toolchain-base has a toolchain from April, but the changelog for 1.91 said it was updated to the raring toolchain?
<cjwatson> doko: Was that the version you were looking at?
<pitti> mspencer: it doesn't need to use the ui_question_file() method, that's only for hooks
<pitti> mspencer: well, of course you can use it if it works for you; I thought you could set a title there?
<pitti> mspencer: so I think it's best for now to add new Gtk.* code to the place where you do the saving
<natschil> Anybody know what program mounts external media in ubuntu?  Something mounts my external vfat disk with the showexec flag set, and it's driving me insane because there seems to be no documentation I can find to tell me what is responsible.
<slangasek> pitti: really?  I still didn't get it working here, glad it's working for you :)
<mspencer> pitti: Don't I need to use the ui_ methods so it works with the apport-cli and apport-gtk?
<sarnold> natschil: I think I'd suggest starting with udev; rules somewhere in /etc/ tell udev what actions to take when what kinds of usb devices are plugged in, and it probably kicks off the automatic mounting
<pitti> slangasek: at least the output now is identical for both qemu-arm gdb and gdb-multiarch
<sarnold> natschil: I think all the programs it runs are in /lib/udev/
<slangasek> pitti: huh, would love to see the full command you're running
<pitti> mspencer: yes, if you want to implement it in those other two UIs as well
<mspencer> pitti: Yes, the title can be set, but the button says 'Open' and there is no place to type a file name.
<pitti> slangasek: I now produce a set of test .crash files for various classes (GTK, Qt, CLI, d-bus) for all arches and releases, in https://code.launchpad.net/~daisy-pluckers/+archive/daisy-seeds
<sarnold> mspencer: iirc, some dialogs don't show a place to type until you've started typing
<natschil> sarnold: Of course udev is involved somewhere, but it isn't what's responsible for the mounting.
<pitti> slangasek: so that we can use those for testing retracer rollouts, daisy branches, etc
<pitti> slangasek: I now took the "sleep 10" raring core dump
<natschil> sarnold: I know this because I created an udev rule to set MODE to something permissive, but that changed nothing.
<pitti> slangasek: but otherwise the exact same command line as yesterday
<sarnold> natschil: oh, damn :/
<natschil> I suspect there's some level of "make it insanely hard to configure external devices to be mounted with executable permissions, because it's unsafe"
<pitti> slangasek: it's still not a "good" trace, though, I need more armhf ddebs
<slangasek> pitti: hmm, same commandline but different test case?  Because I still get 'wrong size gregset struct in core file' unconditionally
<mspencer> sarnold: But where the File chooser dialog is created the type defaults to an Open dialog.
<pitti> slangasek: I guess what I do next is to (1) fix armhf indexes on ddebs.u.c., (2) fix the horrible hacks which I currently have in my apport branch, so that other people can actually try this by themselves, and (3) run this against the "test .crash" files that are in the PPA
<mspencer> pitti: So do you want me to add an optional parameter to the ui_question_file implementations that allows the file chooser type to be set?
<sarnold> mspencer: so it's not just a misleading title then :(
<mspencer> sarnold: No, this is actually an Open dialog.
<sarnold> mspencer: sorry for the distraction then :)
<pitti> mspencer: yes, if you want to implement it in all three, this would make most sense
<mspencer> pitti: That's what I'll do, thanks for your advice.
<cjwatson> natschil: udisks2 in current versions of Ubuntu; I don't know the details of how you might remove showexec though, so this is just a pointer
<natschil> cjwatson: http://www.kirsle.net/blog/kirsle/rant--arrogant-developers suggests that the options have become hardcoded
<slangasek> pitti: sorry, I'm still not following how you got this to work; I'd really like to understand why I got stuck here
<cjwatson> natschil: I think that's best regarded as somebody blowing off steam about difficulties (and probably representative of poor documentation) rather than a true reflection of the state of affairs.
<natschil> cjwatson: the reason: exposing mount options to end users is apparently not a useful thing to do
<natschil> the arrogance.
<natschil> it astounds me.
<cjwatson> The code does not seem to bear that out.
<cjwatson> At least not entirely; there is definitely some degree of support for configuration there.
<ev> bdmurray: http://www.mariterra.co.uk/page/location
<cjwatson> I just don't know the details since it's not a codebase I'm particularly familiar with.
<cjwatson> (And the documentation certainly leaves something to be desired.)
<natschil> cjwatson: but where? neither gconf nor dconf editors seem to show anything of that sort.
<natschil> cjwatson: I think I will download the source code.
<cjwatson> It at least seems to be trying to pick some of it up from fstab ... perhaps it's picky
<cjwatson> Anyway, I'm not going to stare at this any longer :)
<pitti> slangasek: for the xeyes crash it looks like this now: http://paste.ubuntu.com/1410821/
<natschil> cjwatson: probably. Those developers are idiots
<cjwatson> natschil: Please take the rants elsewhere.
<cjwatson> They are not appropriate here.
<natschil> cjwatson: my bad, I should probably be more objective and say that the software is a failure, because it fails to read options from fstab.
<pitti> slangasek: and with "qemu-arm -L /tmp/sandbox usr/bin/gdb" I'm getting an identical trace
<cjwatson> natschil: That is not yet supported by evidence (perhaps it's simply overly selective), and in any case is a distinctly unhelpful way to approach the problem that I don't think is useful in #ubuntu-devel
<slangasek> pitti: oh, cool; so there was just a problem with that particular test case we were working with yesterday
<slangasek> (the nux one)
<pitti> slangasek: at least I hope so, yes
<pitti> raring armhf ddeb indexes are back, BTW
<pitti> quantal's should be produced over night
<natschil> cjwatson: I have evidence to support it on my machine. Steps to reproduce: create something in fstab that uses an uuid. watch devicekit fail.
<cjwatson> It hasn't been called devicekit for quite a while ...
<slangasek> pitti: sweet
<natschil> cjwatson: sure, calling the developers idiots may not be that productive. The thing is that I'm annoyed that their arrogance seems to be the cause of me wasting my day trying to find said configuration options.
<cjwatson> And we use UUIDs absolutely everywhere in Ubuntu, so I do not think that this is a systemic failure
<cjwatson> It is often useful to distinguish between "fails for me" and "fails for everyone"
<cjwatson> This is a developer channel, not user support, so please take a more productive line
<natschil> cjwatson: what is it called nowadays?
<cjwatson> devicekit-disks became udisks became udisks2
<cjwatson> ish
<pitti> slangasek: I also noticed that our standard "gdb" amd64 package can seamlessly process i386 core dumps, which is really nice; I don't need i386 dchroots on the retracer machines any more
 * cjwatson -> dinner
<slangasek> pitti: indeed :)
<infinity> xnox: FWIW, you can stop fretting about iptables, the latest kernel upload fixes it (see the successful powerpc retry)
<slangasek> mlankhorst: why does xorg-server-lts-quantal include a patch not in the quantal-proposed version of xorg-server (xorg-server-legacy-bgnone.patch)?
<seb128> slangasek, if the xserver-xorg-lts-quantal breaks multimedia keys in Unity/GNOME is that something we want to handle with a break statement or something? or do we just need to land the corresponding fix?
<slangasek> seb128: hmmm, we ought to fix it
<seb128> slangasek, that's https://bugs.launchpad.net/bugs/1034090 for which I uploaded a SRU fix today
<ubottu> Launchpad bug 1034090 in gnome-settings-daemon (Ubuntu Precise) "Hotkeys not functional after upgrade to quantal's xorg (new xinput version)" [High,In progress]
<slangasek> well, by "fix" I mean either that the incompatibility needs to be reverted *or* an update like g-s-d is needed, yeah
<seb128> slangasek, right, the fix is in the queue, I'm wondering if we should ensure both get updated in locked steps in some way
<slangasek> in the latter case, there should also be a breaks
<seb128> so xserver-xorg-lts-quantal needs to Breaks gnome-settings-daemon (<< 3.4.2-0ubuntu0.6.1)
<seb128> http://launchpadlibrarian.net/124872994/gnome-settings-daemon_3.4.2-0ubuntu0.6.1_source.changes
<seb128> is the upload
<seb128> there is a SRU in proposed for g-s-d atm but it should be good to move tomorrow (I will try to make sure it's verification-done tomorrow)
<mlankhorst> slangasek: it's required for -nc to work
<mlankhorst> else it will fail to start
<slangasek> mlankhorst: and that's something that's relied on by some software in precise?
<mlankhorst> yeah
<slangasek> mlankhorst: could you please reupload the package adding an explanation of this to the changelog and adding the Breaks: on gnome-settings-daemon that seb128 says above is needed?
<mlankhorst> slangasek: well I tend not to explain those specific things since I autogenerate the entire stack
<slangasek> mlankhorst: ok - I'm not really happy about changelogs being autogenerated, but we'll roll with it.  how about the Breaks, then?
<mlankhorst> entire stack is generated by running xorg-pkg-tools/lts-stack, I'll take a look at the breaks..
<slangasek> mlankhorst: do you prefer that I accept the current version of this package without the Breaks and you upload again with a new version number, or should I reject this one and wait for a reupload?
<seb128> slangasek, mlankhorst: thanks
<mlankhorst> slangasek: might be best to accept the current version to build the rest, then I'll reupload?
<slangasek> mlankhorst: yep, fine with me
<mlankhorst> and the script is automated because it's the only way I prevent human mistakes from being a problem :/
<slangasek> mlankhorst: yep - I certainly approve of this kind of automation, I just would prefer that it not be applied in a way that prevents changelogs from working the normal way :)
<mwhudson> hm
<mwhudson> what is stdin for an upstart job?  /dev/null?
<slangasek> unless you use a different 'console' option, yes
<slangasek> (or use a redirect in the script itself)
<mwhudson> well yes, the latter point had occurred to me :-)
<mwhudson> hmm
<mwhudson> although this upstart job says "console output:
<mwhudson> oh nevermind
<slangasek> in that case, IIRC stdin is also attached to the console
<mwhudson> it's other bits of my code doing something odd
<mwhudson> slangasek: yeah, that's what the docs say
<mwhudson> i think i am just going to go and hate bash a bit, brb
<mwhudson> while read line ; do
<mwhudson> er mischan
<arges> whats the process for adding a patch to a package that doesn't have a patch system set up yet?
<penguin42> arges: I just had a look at edit-patch, I wondered whether that might set ione up, but it doesn't seem to
<arges> penguin42, thanks,yea I've got it working with quilt and adding the necessary files. but was wondering how I can properly prepare that to fix a bug.
<slangasek> cyphermox: does the dnsmasq conversion to use of dbus in quantal mean we no longer have a config file on disk anywhere that shows the current dns server settings?  if so, how can one see this list for debugging?
<cyphermox> ah, it does. In the file I wrote that it will be listed in /var/log/syslog when NM changes it
<cyphermox> if you want to query it, it's sending a USR1 signal to dnsmasq
<slangasek> cyphermox: USR1 causes dnsmasq to echo it to syslog?
<cyphermox> yes
<cyphermox> it causes dnsmasq to write statistics data to syslog, and that includes the servers
<infinity> Huh, so it does.
<infinity> Handy.
 * infinity tries to remember that for when it'll be useful.
<cyphermox> indeed. it's documented in the manpage, not sure if there should be more obvious docs for this
<cyphermox> slangasek: seen the other SRU for dnsmasq though, since it's required for these changes?
<cjwatson> arges: If there's no patch system, and the source is format 1.0 (no debian/source/format or it just contains '1.0'), then just apply the patch directly to the upstream source code.
<arges> cjwatson, ok i'll do that then for bug 1071209 . thanks
<ubottu> Launchpad bug 1071209 in memtest86+ (Ubuntu Raring) "memtest86 test #7 false positives (random number sequence error)" [Medium,In progress] https://launchpad.net/bugs/1071209
<cjwatson> arges: Yes.  If you look at memtest+'s .diff.gz, you'll see it already has some patches applied this way.
<arges> cool fixing it now
<doko> cjwatson, the linaro page you did mention, only has this old one. So I think you are talking about armhf, not am64?
<cjwatson> doko: Um, you mean about -cross-toolchain-base?  Right now I'm not looking at the arm64 cross-toolchain at all, only armhf
<stgraber> hallyn: oh well, looks like I'll need to split the container-detect job into container-detect and container-detect-write, so I can make the first be "start on startup" and only have the second do the /run writting.
<slangasek> stgraber: why's this?
<stgraber> hallyn: that way we can start using the "container" and "not-container" events very very early on and prevent stuff like plymouth, console-*, setvtrgb, ureadhead, ... from starting
<stgraber> slangasek: ^ that's why
<slangasek> cyphermox: SRU for dnsmasq> hmmm no, sorry, my question came from a completely different context of resolvconf bug reports
<stgraber> basically we have a bunch of stuff that tries to start at boot time and either fails miserably (because we don't have real ttys) or starts but doesn't do anything useful (like plymouth)
<cyphermox> slangasek: ok..
<stgraber> we have nice events to deal with those case, but currently the container-detect job depends on /run being mounted so we can't use those very early in the boot sequence
<slangasek> stgraber: console* and setvtrgb don't happen pre-virtualfilesystems; and I would assert that suppressing plymouth and ureadahead in a container is a wrong fix
<slangasek> stgraber: and I'm not sure why plymouth "doesn't do anything useful" for that matter, the existing job setup should allow it to connect to the text-only console and do any necessary mountall handling
<slangasek> stgraber: so, can you please file a bug against plymouth about this :)
<stgraber> well, containers aren't allowed to access block devices, so it's unlikely to be really useful (we support cryptsetup but it's a pre-startup hook outside the container). Anyway, doing some specific plymouth testing now to confirm that it fails to render anything on the pts
<slangasek> "containers aren't allowed to access block devices" - not universally true :)
<slangasek> and even if it were, I'm very concerned about adding additional complexity to the common jobs on the grounds that they're deemed not useful in some contexts
<stgraber> slangasek: so, I have plymouthd running, how do I get it to show me something?
<slangasek> stgraber: did 'plymouth show-splash' get called?  (/etc/init/plymouth-splash.conf)
<stgraber> slangasek: I called show-splash manually, so yeah
<slangasek> start plymouthd; call 'plymouth show-splash'; then call, e.g., 'plymouth ask-for-password --prompt 'open sesame: '
<stgraber> ok, the ask-for-password just returns and nothing is shown on /dev/lxc/console (my current tty)
<slangasek> er, ok, that's weird
<slangasek> (and a bug)
#ubuntu-devel 2012-12-05
<stgraber> slangasek: bug 1086612
<ubottu> Launchpad bug 1086612 in plymouth (Ubuntu) "plymouth isn't working in lxc containers" [Undecided,New] https://launchpad.net/bugs/1086612
<stgraber> slangasek: as for ureadahead, it attempts to write to debugfs which isn't allowed in containers (/sys/kernel/debug/tracing/events/fs/do_sys_open/enable). We're not allowing that path for obvious reasons as kernel tracing from a container would let the user access everything that's going on on the host and any other containers.
<slangasek> stgraber: ta, will see what I can figure out there
<slangasek> stgraber: right, but ureadahead should also fail gracefully with minimal impact on the system, shouldn't it?
<stgraber> slangasek: sure, none of the failures I'm trying to fix are causing breakage or we'd have fixed them a while ago. I'm just trying to get /var/log/upstart into a reasonable state on a clean container :)
<stgraber> as currently we're getting errors in there at every boot because of those various jobs failing
<slangasek> stgraber: heh, I don't even have that clean on a real system :P
<stgraber> slangasek: well, I'm certainly ignoring the usual ones (networking, procps, ...) where the output is actually useful to have and those jobs are actually working :)
<slangasek> stgraber: I'm certainly ok with improving the code to not output spurious errors, I just am reluctant to see this done by adding further complexity to the job start rules
<slangasek> stgraber: please make lxc-create fail when given a --dir argument pointing to an already-existing directory :P
<stgraber> slangasek: oh, interesting, I never looked at the "dir" backingstore plugin but yeah, it's definitely broken, will add that to my todo unless hallyn beats me to fixing it (as I believe that's his code ;))
<slangasek> stgraber: heh :)
<stgraber> it's the first time I use any of the fancy alternate backingstore, I tend to just use the default, which happens to properly check for existing rootfs :)
<ikepanhc> @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 dicussion 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: ikepanhc
<penguin42> ikepanhc: If you fancy a nice simple 1 line change (+ comment) bug 1033250 I've got a branch against
<ubottu> Launchpad bug 1033250 in xpilot-ng (Ubuntu) "crash on asking for internet game" [Undecided,In progress] https://launchpad.net/bugs/1033250
<ikepanhc> penguin42: that looks nice, let me try that first
<penguin42> ikepanhc: There's a bzr branch against it I made marked for review
<ikepanhc> @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 dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dholbach> good morning
<rbasak> ogra_: I can't check highbank due to a separate issue, but flash-kernel-installer appears fixed for armadaxp at least. Do you have SRU plans?
<dholbach> Amaranth, happy birthday! :)
<Amaranth> dholbach: Thanks! :)
<dholbach> didrocks, you are a hero!
<didrocks> hey dholbach ;)
<didrocks> dholbach: please install from the ppa and keep me posted how it goes :)
<didrocks> (and thanks)
<pitti> Good morning
<ev> bdmurray: https://launchpad.net/~ev/+archive/whoopsie-daisy/+build/4037968
<mpt> pitti, bdmurray, xnox, ev: bug 1072854
<ubottu> Launchpad bug 1072854 in Errors "Handle bugs in libraries better" [High,Confirmed] https://launchpad.net/bugs/1072854
<bdmurray> pitti, ev: https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fshare%2Fapport%2Fapport-gtk%3AOSError%3A%3Cmodule%3E%3Arun_argv%3Arun_crashes%3Arun_crash%3Amark_report_upload
<ev> xnox: https://docs.google.com/a/canonical.com/document/d/1BWOIRdJvUueJa4cWV68UEY3nlmHgAVJY6aNGo6YSCQg/edit#heading=h.kqe6vo42l0y7
<pitti> hm, is dput/ftp upload broken for anyone else than me?
<ev> bdmurray: https://errors.ubuntu.com/api/1.0/most-common-problems/?limit=0&release=Ubuntu%2012.10&format=json
<ev> bdmurray: https://errors.ubuntu.com/api/1.0/most-common-problems/?limit=100&release=Ubuntu%2012.10&period=day&callback=YUI.Env.DataSource.callbacks.yui_3_5_0_3_1354703350440_3040
<bdmurray> ev: https://errors.ubuntu.com/api/1.0/most-common-problems/?limit=0&release=Ubuntu%2013.04&format=json
<blackz> can someone please reject my ppa-purge upload to precise-proposed? thanks
<bdmurray> blackz: I'll do it
<blackz> bdmurray: thanks
<pitti> bdmurray: python -c 'from apport.crashdb import get_crashdb; db=get_crashdb(None); r=db.download(1070952); r.write(open("/tmp/foo.crash", "wb"))'
<mpt> mvo, in June someone with Launchpad karma of 6 marked bug 975320 as fixed. Today it's the most common error reported for all Ubuntu users, so I suspect it isn't fixed at all.
<ubottu> Launchpad bug 975320 in aptdaemon (Ubuntu) "update-manager crashed with Depends in _run_in_dialog(): libx264-120 but it is not installed" [Medium,Fix released] https://launchpad.net/bugs/975320
<ev> pitti: we're talking about https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/979278 specifically
<ubottu> Error: launchpad bug 979278 not found
<mlankhorst> will the quantal nexus7 ppa still receive updates or is it all going to be for raring?
<bdmurray> pitti: modified_since is the searchTasks parameter
<mpt> ev, pitti: bug 1086754
<ubottu> Launchpad bug 1086754 in Errors "Some linked bug reports are private duplicates" [Undecided,New] https://launchpad.net/bugs/1086754
<mlankhorst> ugh the raring image is corrupting crazily :P
<mvo> mpt: oh, thanks! let me have a look
<mdeslaur> @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 dicussion 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: mdeslaur
<seb128> can somebody reject https://code.launchpad.net/~andrikos/ubuntu/quantal/xserver-xorg-video-intel/fix-ati-hybrid/+merge/132956 ?
<seb128> pitti, stgraber: ^
<seb128> mdeslaur, since you do reviewing, what do you think about the popularity-contest 1 liner changes in the queue?
<mdeslaur> I was just about to take a look at them, one sec
<seb128> mdeslaur, I wonder if that should be || true rather than || exit 0... if no conffile is shipped it's probably not required (or the package should ship one)?
<pitti> seb128: done
<mdeslaur> seb128: the package installs the file in the postinst
<seb128> pitti, danke
<mdeslaur> seb128: it's an ec2 problem because of a bug in the script: http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/revision/524
<mdeslaur> seb128: I don't think this is actually needed
<seb128> mdeslaur, oh, doh, I was looking at the deb content, I didn't think it was coming from the postinst
<seb128> mdeslaur, I see, that explains it, thanks ;-) you are going to close it with a pointer on the ec2 fix then?
<mdeslaur> seb128: yes
<seb128> mdeslaur, thanks
<mdeslaur> seb128: are you patch piloting? why were you looking at that?
<seb128> mdeslaur, I'm trying to help to clean a bit the queue recently, since quite some people don't do their shifts and things just stack ...
<seb128> mdeslaur, but I'm done for now so don't worry about conflicts ;-)
<mdeslaur> ok, cool, thanks
<seb128> mdeslaur, I was also a bit annoyed by those populary-contest 1 liners taking 3 slots in the queue for over 1 month and being ignored ... seems like a trivial "|| exit 0" should be reviewable by any pilot...
<mdeslaur> yeah
<mdeslaur> I get the feeling people only look at packages they are familiar with
<mdeslaur> not that I'm not guilty of doing that myself sometimes
<pitti> tseliot: hey Alberto, how are you?
<pitti> tseliot: still remember bug 1054458?
<ubottu> Launchpad bug 1054458 in ubuntu-drivers-common (Ubuntu Quantal) "nvidia-detector crashed with ValueError in __get_value_from_name(): invalid literal for int() with base 10: 'experimental-304'" [High,Triaged] https://launchpad.net/bugs/1054458
<pitti> tseliot: this has been the #1 issue reported by users for a while
<pitti> tseliot: tedg submitted a patch in https://code.launchpad.net/~ted/ubuntu/raring/ubuntu-drivers-common/nvidia-experimental-number/+merge/137754
<pitti> tseliot: do you think you can look at this to ensure it's DTRT and commit/upload?
<herton> @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 dicussion 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: herton, mdeslaur
<bdmurray> mpt: bug 1086796
<ubottu> Launchpad bug 1086796 in Errors "html title does not change" [Undecided,New] https://launchpad.net/bugs/1086796
<rbasak> ogra_: I can't check highbank due to a separate issue, but flash-kernel-installer appears fixed for armadaxp at least. Do you have SRU plans please?
<pitti> ev: juju ssh errors/0 -L 8081:localhost:80
<ev> pitti: \o/
<tseliot> pitti: sure, I'll have a look at it
<seb128> tseliot, hey, did you look at the fglrx requests from the queue I pointed the other day as well?
<ogra_> rbasak, trying to get that done before end of the week, there are other f-k SRU bits i want in the same upload too
<rbasak> ogra_: OK, thanks!
<rickspencer3> good morning all
<shadeslayer> evening rickspencer3
<rickspencer3> :)
<didrocks> hey rickspencer3
<rickspencer3> bonjour didrocks
<seb128> salut rickspencer3
<rickspencer3> bonjour seb128
<herton> @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 dicussion 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: mdeslaur
<infinity> Aaaan, APR cross-builds, but drops symbols along the way.  Fun.
 * infinity compares native/cross configure output.
<cjwatson> seb128: hey, are you already on top of the gnutls26 merge?  You're down as TIL via sponsorship.  I'd like to fix its build failure but perhaps if I'm doing that I should merge at the same time (though unstable's package fails in the same way)
<seb128> cjwatson, I was trying to avoid it in hope somebody else would steal it, so if you want to grab it please do ;-)
<cjwatson> heh, ok
<infinity> And Colin once again accidentally ends up TIL on the entire archive.
<infinity> cjwatson: Oh, do you want me to steal dpkg back from you, by the way?
<vibhav> I was doing a merge for gnome-pp and saw that the Debian version had added wvdial to Build-Depends
<vibhav> This was a fix for the armel architecture
<vibhav> Should I include this fix? armel is obsoleted in raring
<infinity> vibhav: Merges should be as close to Debian as possible.
<mdeslaur> vibhav: that's a useless merge, don't do it
<mdeslaur> vibhav: aren't you supposed to ask me first, since I TIL?
<infinity> (Also, what's "gnome-pp", no such source package exists)
<mdeslaur> gnome-ppp
<vibhav> mdeslaur: yes, I was sending off an email to you
<vibhav> :P
<vibhav> infinity: gnome-ppp
<vibhav> s/sending off/writing/
<vibhav> Anyways, thanks mdeslaur
<infinity> vibhav: For added bonus, even when we had armel, that patch did nothing for us.
<infinity> Cause wvdial works on Ubuntu/armel.
<mdeslaur> vibhav: there's plenty of other stuff I TIL that you can steal though :)
 * vibhav takes a look
<vibhav> infinity: ah yes
<infinity> vibhav: Anyhow, the general rule of thumb is to not waste time on merges that do nothing at all, but if you were talking about a merge that also had other useful changes, yes, you should include the "do nothing" changes too, to keep the delta low.
<vibhav> But there are not any changes, we can wait for a new version
<vibhav> Thanks infinity
<cjwatson> infinity: Yeah, if you could steal that back from me that'd be great
<infinity> cjwatson: Will do.
<dholbach> can somebody please moderate ubuntu-devel-announce?
<cjwatson> dholbach: done
<dholbach> thank you cj
<dholbach> thank you cjwatson
<dholbach> (sorry)
<mpt> ev, bug 1086850
<ubottu> Launchpad bug 1086850 in Errors "Bucket page graph shows instances rather than error rate" [Undecided,New] https://launchpad.net/bugs/1086850
<infinity> pitti: Sweet merciful ARGH.  Why is /usr/bin/pg_config a binary instead of a script?
<arges> hello
<infinity> Hi!
<infinity> arges: bug 943502, why are you doing backports there instead of just cherrypicking the correct TLD lookups?
<ubottu> Launchpad bug 943502 in whois (Ubuntu Oneiric) "whois doesn't properly query .hr/.sx/.pe TLDs and incorrect format for whois.arin.net" [Medium,In progress] https://launchpad.net/bugs/943502
<arges> ok looks like its working
<arges> infinity, i think that was my initial approach... trying to remember why I didn't do that
<smoser> infinity, so what is the correct policy for the un-namespaced "needs-verification" tag when there are multiple -prposed uploads
<arges> infinity, let me give that a shot again
<infinity> arges: tld_serv_list seems pretty straightforward.
<smoser> ie, as in bug 1078926
<ubottu> Launchpad bug 1078926 in mountall (Ubuntu Quantal) "raring instance failed to find EC2 datasource" [High,Fix committed] https://launchpad.net/bugs/1078926
<infinity> smoser: Keep verification-needed set, but add verification-done-precise (or whatever) for the ones verified.
<infinity> smoser: The little tag box should autocomplete those.  I think.
<smoser> ah. ok.
<infinity> smoser: This may not be the right advice for that specific bug, I'm just saying in general.  -needed while some task skill needs verification, and -done-$foo for the series that have been done.
<infinity> smoser: This all falls apart miserably on bugs with multiple packages too. :/
<smoser> right.
<infinity> (The SecureBoot metabug is going to be a nightmare)
<infinity> Gaze upon bug 1075181 and weep.
<cjwatson> I'm pretty sure that's "wait for it all to work, and promote all at once" ...
<ubottu> Launchpad bug 1075181 in ubuntu-defaults-builder (Ubuntu Precise) "Backport UEFI Secure Boot support for Ubuntu 12.04.2" [High,Fix committed] https://launchpad.net/bugs/1075181
<infinity> cjwatson: Yeahp, but we need to go through each task and double-check it's all sane, then promote in a batch.  Will be fun.
<smoser> could someone on SRU please look at my cloud-init upload in -proposed?
<cjwatson> Because, you know, how else are you going to know :)
<smoser> https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=cloud-init
<barry> jodh, slangasek give me just a couple of minutes... if now is a good time
<slangasek> barry: wfm
<hallyn> stgraber: slangasek: update to refuse --dir option which already exists to lxc-create sent to the mailing list, thanks.
<slangasek> hallyn: thank you :-)
<hallyn> funny thing, I see I wrote it, but I don't remember doing the --dir...  oh well.
<stgraber> hallyn: :) I'll take a look at the patch and apply it
<hallyn> thanks both
<hallyn> now back to my qemu packaging disaster
<barry> slangasek, jodh okay, i have the machine in the stalled state, and i'm ssh'd in.  the last thing i see on the console is "Stopping save kernel messages".  twisty maze and all that. :)
<slangasek> barry: yep.  what's the output of 'sudo initctl list', and if the rc job is still running, what does ps fxwa show for its children?
<tseliot> seb128: yes,
<barry> slangasek: http://paste.ubuntu.com/1412816/
<tseliot> seb128: yes, but I haven't merged them yet
<seb128> tseliot, ok, do you plan to merge them soon? we are trying to clean the sponsoring queue and they are sitting there for some weeks...
<slangasek> barry: please run 'sudo chvt 1'
<barry> slangasek: i'm on vt1 w/ login prompt on console
<tseliot> seb128: I have more urgent changes to work on but I can do it next week
<slangasek> barry: right - so now you're seeing what you're expecting?
<jodh> barry: what are all those '*.sh' jobs?
<seb128> tseliot, ok, thanks, I though those would be trivial and like 15min to merge ignore, no worry
<slangasek> jodh: those are mountall being enhanced to neuter sysvinit in Debian
<barry> slangasek: yes, this is what i'd expect by changing the vt
<slangasek> (runtime neuter)
<barry> jodh: dunno ;)
<slangasek> barry: ok, so would it be fair to characterize this bug as "console is left on wrong VT at end of boot"?
<slangasek> barry: or is there still another bug?
<barry> slangasek: well, i would expect the greeter
<slangasek> oh, you have lightdm installed
<barry> slangasek: yep. and when the boot doesn't stall, i see the expected greeter screen
 * slangasek points barry in the direction of the desktop team, then :)
<slangasek> barry: it's either a kernel or an X bug; doesn't appear that the plumbing is doing anything wrong here
<barry> slangasek: we've ruled out kernel
<barry> slangasek: okay. if you're sure the plumbing is working properly, i'll retarget it against x and see what they say ;)
<seb128> stgraber, pitti: can you reject those?
<slangasek> barry: well, I'm also not sure why neither the lightdm nor the failsafe-x jobs are running
<seb128> https://code.launchpad.net/~utlemming/popularity-contest/quantal.lp707311/+merge/131877
<seb128> https://code.launchpad.net/~utlemming/popularity-contest/precise.lp707311/+merge/131876
<pitti> oui, je peux
<jodh> barry/slangasek: this might be bug 969489.
<ubottu> Launchpad bug 969489 in lightdm (Ubuntu) "lightdm tries (and fails) to start too early?" [Undecided,Confirmed] https://launchpad.net/bugs/969489
<slangasek> barry: do you have any suggestive logs under /var/log/upstart?
<pitti> seb128, stgraber: done
<seb128> pitti, danke
<barry> jodh: i'll look at that bug in a sec
<barry> slangasek: % ls -lt *.log
<barry> -rw-r----- 1 root root 2747439 Dec  5 11:36 ureadahead.log
<barry> -rw-r----- 1 root root     105 Dec  5 11:35 hybrid-gfx.log
<barry> -rw-r----- 1 root root     180 Dec  5 11:35 alsa-restore.log
<barry> -rw-r----- 1 root root    3774 Dec  5 11:35 modemmanager.log
<barry> -rw-r----- 1 root root    1071 Dec  5 11:35 procps-static-network-up.log
<barry> -rw-r----- 1 root root      90 Dec  5 11:35 kmod.log
<barry> -rw-r----- 1 root root      90 Dec  5 11:35 module-init-tools.log
<barry> -rw-r----- 1 root root     256 Dec  5 11:35 rsyslog.log
<barry> -rw-r----- 1 root root     192 Dec  5 11:35 dbus.log
<barry> -rw-r----- 1 root root     138 Dec  5 11:35 container-detect.log
<barry> -rw-r----- 1 root root    1071 Dec  5 11:35 procps-virtual-filesystems.log
<barry> -rw-r----- 1 root root     129 Dec  5 11:35 console-setup.log
<barry>  
<slangasek> barry: and that's the time the machine booted?
<barry> slangasek: no, it's in the stalled state right now
<dholbach> didrocks, You're a hero!
<slangasek> barry: er, the machine is booted, it just doesn't have lightdm running
<didrocks> dholbach: I wasn't alone, but thanks :)
<dholbach> awesome
<barry> slangasek: sorry, yes, correct
<ogra_> dholbach, two heros !
<ogra_> (he is)
 * didrocks hugs dholbach and ogra_
<dholbach> :-)
 * dholbach hugs you all
<barry> slangasek, jodh: there's nothing in the upstart logs that standout to me
<slangasek> barry: did timestamps on /var/log/lightdm/* or /var/log/Xorg.* update?
<barry> slangasek: lightdm logs all show 11:35 or :36 today, so in line with upstart logs
<slangasek> barry: hmmm.  and the contents of those logs?
<barry> same with xorg
<barry> slangasek: yep, looking now
<slangasek> barry: best to attach them to the bug report
 * barry nods
<mdeslaur> @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 dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<slangasek> barry: mmm, you don't have this set to autologin or something?
<barry> slangasek: nope
 * dholbach hugs mdeslaur
<slangasek> barry: and the lightdm.log that's attached is definitely from this latest boot?
<barry> slangasek, jodh: interestingly, re bug 969489.  if i chvt 1 then sudo start lightdm, i get the greeter window
<ubottu> Launchpad bug 969489 in lightdm (Ubuntu) "lightdm tries (and fails) to start too early?" [Undecided,Confirmed] https://launchpad.net/bugs/969489
<slangasek> barry: because at +3.62s, there's something interesting happening
<barry> slangasek: definitely
<slangasek> barry: yes, I would fully expect 'sudo start lightdm' to work; that's not dispositive of it being related to bug #969489
<barry> do you mean the "greeter start authenitication for barry" and beyond bit?
<barry> slangasek: ^^
<slangasek> yes
<slangasek> oh, I bet "start" just means that's the user that was last selected, and whose password box is popped up
<barry> that makes more sense (and is what happens)
<slangasek> barry: can you show the output of this command, please: grep -l 'start on runlevel .2345' /etc/init/*
<barry> slangasek:
<barry> /etc/init/acpid.conf
<barry> /etc/init/alsa-restore.conf
<barry> /etc/init/anacron.conf
<barry> /etc/init/apport.conf
<barry> /etc/init/atd.conf
<barry> /etc/init/cron.conf
<barry> /etc/init/dmesg.conf
<barry> /etc/init/irqbalance.conf
<barry> /etc/init/pulseaudio.conf
<barry> /etc/init/whoopsie.conf
<barry>  
<barry> mine never drops into low-graphics mode, but it might be worth playing with some of the lightdm start hacks mentioned in bug 969489
<ubottu> Launchpad bug 969489 in lightdm (Ubuntu) "lightdm tries (and fails) to start too early?" [Undecided,Confirmed] https://launchpad.net/bugs/969489
<slangasek> barry: hmm, how about this: grep -l 'start on runlevel .2345' /etc/init/* | xargs grep -lE 'kill|stop'
<barry> slangasek: oops, i just rebooted it (but i saved the state, so hang on a sec)
<slangasek> er, wait, that one's not useful
<slangasek> grep -l '^start on runlevel .2345' /etc/init/* | xargs grep -l kill
<barry> slangasek: i'm back in the stalled state.  that command returns nothing
<slangasek> barry: ok. what it comes down to, I think, is that something non-standard is killing lightdm that shouldn't be; /var/log/lightdm.log gives us enough info to know the pid of what's doing the killing, but not the name.  Given that at and cron have just started, it *could* be a strange cronjob or at job; it's more likely to be something called from an upstart job; booting with --verbose and cross-referencing that output against the 'initctl
<slangasek> ... and the /var/log/lightdm.log from the same boot *may* help isolate this
<slangasek> barry: is this a pristine install of quantal?  no chance of extra or modified jobs in /etc/init/
<slangasek> ?
<barry> slangasek: it's running raring, but probably upgraded from quantal->precise->raring
<slangasek> ok
<slangasek> so you've said it's not reproducible with a clean precise userspace; have you checked with a freshly installed raring userspace?
<barry> slangasek: i haven't but that's a good thing to try
<barry> slangasek: can you (or i will) paste your longer message above into the bug?
<barry> slangasek: so i think at this point, it's worth bringing up a fresh raring and seeing what happens.  i'll follow up on the bug report once i've done that.  for now... lunch :)
<slangasek> barry: dumped that to the bug, along with some further thoughts
<barry> thanks!
<jono> is anyone else experiencing random lockups in raring?
<jono> Unity seems to lock up
<jono> and if I switch to a virtual terminal and back it is fine
<seb128> jono, when did that start?
<jono> seb128, I noticed it at the end of last week
<jono> I do get a "I detected a lockup" error
<seb128> not sure what changed around that time but it's not a known issue afaik
<jono> and I mention it happens a few times a day
<seb128> seems like an #ubuntu-x question/issue
<jono> but then I am not sure if that data goes anywhere
<jono> seb128, will mention in there
<seb128> jono, the data should go to errors.ubuntu.com
<jono> seb128, ok, there doesnt seem to be confirmation that the data was sent
<seb128> jono, no, there is none, I think it's a design decision to get out of the user way as much as possible, it's a fire and forget dialog
<jono> I see
<jono> np
<jono> thanks seb128
<seb128> jono, yw!
<seb128> jono, you can try to run: firefox 'http://errors.ubuntu.com/user/'$(printf $(sudo cat /sys/class/dmi/id/product_uuid) | sha512sum)
<seb128> jono, that should open a page showing all the issues you reported, it's not sorted in an useful way though ...
<jono> thanks seb128
<marrusl> Hello.  I'm having some trouble with multi-arch dependencies.  I understand apt and dpkg understand :any for build-deps, but do they understand :any for regular depends?  I am not having luck with this.
<marrusl> the depended-on package is marked "multi-arch: allowed"
<exilarch> http://vbox7.com/play:4c0c38de34
<jtaylor> isn't the :any implicit if the dependency is allowed?
<marrusl> jtaylor, i think that would be the case if the depended-on package was marked "multi-arch: foreign", but with "m-a: allowed" I think the :any is needed.
<marrusl> or else a 32-bit package depending on it will still insist on :i386
<jtaylor> right allowed is only for arch all
<marrusl> so in this case i'm testing gdb which is in -proposed now with "m-a: allowed" (it was explained to me that "foreign" wouldn't be correct for something like gdb)
<marrusl> and when I create a dummy 32 bit package that depends on gdb:any, it's not working.
<marrusl> i may retry on raring or quantal.  though this is intended for precise.
<micahg> AIUI, binary :any is only recognized on raring+
<marrusl> micahg, aha.  that could be it.  i'll recheck on raring.  thanks!
<slangasek> marrusl, jtaylor: :any is intended only for use with packages that are M-A: allowed (and has nothing to do with whether the package is Arch: all).  This should work with apt and dpkg as for back as oneiric.
<slangasek> whether it's *allowed* in the archive is another question
<slangasek> micahg: do you have a source for the claim that :any is only recognized post-raring?  This was supposed to have been supported all along
<marrusl> slangasek, oh no, no worries.  we know it's not going there.  :)
<micahg> slangasek: oh, hrm, I thought dpkg had issues with it and that was the problem
<slangasek> yeah - but it should *definitely* work in precise
<marrusl> I must be doing something wrong.  I have to run afk for a bit, but I'll go back over it when I get back.
<slangasek> micahg: not that I was aware
<slangasek> marrusl: right, so I'm not sure why you're having the problem that you are; it was on my radar to try to test this locally but I haven't gotten to it yet
<marrusl> slangasek, ok.  I'll catch up with you later after I retry.
<marrusl> thanks
<phillw> Hi folks, is there a way to pull in a release from debian/unstable? https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1086974/comments/2
<ubottu> Launchpad bug 1086974 in libguestfs (Ubuntu) "libguestfs: error: cannot find any suitable libguestfs supermin" [Undecided,New]
<tumbleweed> phillw: it needs to be merged. xnox touched it last, prod prod
<phillw> thanks tumbleweed
<infinity> We're already up to date on libguestfs, unless it was mismerged.
<tumbleweed> ah, I saw ubuntuX and didn't look at the version
<phillw> infinity: I'm on Package: libguestfs-tools 1:1.18.5-2 the newer one is 1.18.5-3
<tumbleweed> phillw: 1:1.18.10-1ubuntu2 is published
<infinity> phillw: Oh, you're running Quantal.
<slangasek> phillw: the new version is merged in raring, not in quantal
<phillw> I'm on quantal, do I need to grab this from raring?
<slangasek> if you're requesting that this be fixed in quantal in particular, you'll need to 'nominate for release' on the bug.  But if you just want to test, yes, you should be able to grab the package from raring.
<phillw> I'm okay with temp allowing raring to test. which deb would it be? (universe / main etc..) So I can add it, then disable to confirm it works for Q
<slangasek> phillw: you can find the .deb in launchpad by browsing https://launchpad.net/ubuntu/+source/libguestfs/
<slangasek> (click on version; click on architecture; find .deb file on page and click)
<phillw> slangasek: sorry to be pain, I'm on https://launchpad.net/ubuntu/+source/libguestfs/1:1.18.10-1ubuntu2/+build/3960859 in order to get all the updates which should I choose?
<infinity> phillw: dpkg -l \*guestfs\* | awk '/^i/ {print $2}'
<infinity> ... Which won't get guestfish.  What a silly name.
<infinity> phillw: dpkg -l \*guestf\* | awk '/^i/ {print $2}'
<phillw> infinity: ooh.. depedency hell :P Let me have a play.
 * infinity facepalms as he realises that the linux32 personality for aarch64 is armv8l instead of armv7l.
<infinity> That's remarkably... Useless.
<infinity> But at least they have a 32-bit personality to fix.
<slangasek> armv8l - that's just the name, yes?
<infinity> slangasek: It's what "linux32 uname -m" produces on an aarch64 kernel.
<infinity> slangasek: About as useless as if x86_64 said "i786" instead of the much more pleasant lie of "i686".
<slangasek> right
<infinity> Anyhow, I think I'll bug someone about that, since the most obvious use-case for "linux32" most of the world over is "building brain-dead software on a 64-bit host", all of which has configure scripts looking for armv7l. :P
<phillw> slangasek: how do I add a 'nominate for release' to the bug? https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1086974/comments/3
<ubottu> Launchpad bug 1086974 in libguestfs (Ubuntu) "libguestfs: error: cannot find any suitable libguestfs supermin" [Undecided,New]
<phillw> zero regression risk, as it didn't use to work :D
<mwhudson> that's the "upstream developer thinks ubuntu is stupid" bug?
<slangasek> phillw: there should be a link with that as its title; or maybe 'Target to release'
<cjwatson> You only get either if you're in at least ubuntu-bugcontrol
<slangasek> ah
<slangasek> right, I assumed phillw was
<phillw> cjwatson: slangasek I'll go a hunting 'TheLordOfTime" in that case :) But, it does work and I hope I've put enough information on there for you guys to allow it into 'Q'.
<phillw> slangasek: I'm only bug-squad, not bug-control :)
<arosen> Anyone know off hand if there is a way to make debchange not prompt for input in an editor?
<sarnold> arosen: try unsetting TERM first?
<sarnold> (there's surely a better way, but I've seen some of those scripts say "TERM unset, <skipping something>"
<arosen> sarnold: nope it says Error opening terminal: unknown.
<maxb> arosen: In what mode?
#ubuntu-devel 2012-12-06
<sarnold> arosen: aha, debconf(7) (from debconf-doc) suggests DEBIAN_FRONTEND=noninteractive
<maxb> passing it am empty argument may work, e.g. : dch -r ""
<maxb> sarnold: dch doesn't use debconf
<sarnold> oh hell, wrong thing :)
<sarnold> sorry arosen :)
<arosen> I tried export DEBIAN_FRONTEND=noninteractive same thing :/
<slangasek> if you pass it an explicit string to use for the changelog entry, it won't prompt for input; for dch -r, the "" also works
<arosen> thanks guys!
<bdrung> micahg: re debian bug #650348 - would it be okay if dh_xul-ext fail instead of install-xpi?
<ubottu> Debian bug 650348 in mozilla-devscripts "install-xpi: please fail the build if minVersion is greater than maxVersion" [Wishlist,Open] http://bugs.debian.org/650348
<bdrung> dh_xul-ext does all the version calculation stuff
<micahg> bdrung: sure, that's fine, the idea was to have the build fail on it :)
<bdrung> micahg: okay, i will add that support (probably tomorrow)
<micahg> bdrung: it would also be nice to calculate proper binary dependencies for binary addons, but idk if we can do that
<bdrung> micahg: can we distinguish binary from non-binary extensions?
<micahg> arch: all vs arch:any?
<bdrung> that might work. on what does these binaries depend on?
<bdrung> micahg: isn't dh_shlibdeps enough?
<micahg> bdrung: we don't have symbols files for Firefox/Thunderbird as they're not "shared libraries" per se
<bdrung> micahg: against what kind of api/abi are the binary addons compiled?
<bdrung> which libraries?
<micahg> bdrung: thunderbird/firefox, I'm not sure offhand about specific
<bdrung> even if Firefox/Thunderbird do not have "shared libraries", you could maintain a shlibs file that make dh_shlibdeps work.
<bdrung> s/\./?/
<bdrung> s/\./, couldn't you?/
 * bdrung thinks that it's time for bed.
<micahg> yeah, could probably use something similar to libav-extraa
<micahg> just the one a there
<micahg> it's pretty simple though, for Firefox/Thunderbird and I think Seamonkey, an increment in the first or second number in the version breaks ABI
<bdrung> micahg: what does libav-extra do?
<micahg> has a SHLIBS variable in debian/rules, but I don't think we even need that
<bdrung> micahg: dunno if SHLIBS is enough to permit a newer Firefox with an older addon built
<micahg> I don't want to use SHLIBS as it seems like overkill
<micahg> if it's a binary addon, it works with only one major.minor version
<bdrung> which binary addons do we have in the archive?
<micahg> enigmail and lightning-extension (which was just solved)
<micahg> lightning, not enigmail
<bdrung> libcalbasecomps.so from lightning-extension links against libxpcom.so, libmozalloc.so, libxul.so
<bdrung> micahg: these files are in /usr/lib/firefox or /usr/lib/thunderbird
<micahg> yes
<micahg> well, in Ubuntu
<bdrung> what does upstream?
<micahg> same, xulrunner on its own isn't officially supported anymore
<micahg> idk what Debian does at this point though
<bdrung> http://packages.debian.org/search?suite=default&section=all&arch=any&searchon=contents&keywords=libxpcom.so
<bdrung> it seams that icedove, iceape ships their own libraries, but iceweasel uses xulrunner
 * bdrung will go to bed.
<bdrung> micahg: restricting the dependency for binary addons should be doable, but there is probably no perfect solution (unless upstream uses proper so versioning)
<micahg> bdrung: it's not a shared library anymore, why should they care? (and binary addons are discouraged at this point)
<bdrung> micahg: so binary addons will go away?
<micahg> idk about that :), they're discouraged though as the interface isn't stable
<dholbach> good morning
<didrocks> hey dholbach
<dholbach> hey didrocks
<pitti> Good morning
<xnox> tumbleweed: ok, I will look at remerging and uploading that.
<xnox> tumbleweed: never it's fully up to date in raring....
<tumbleweed> xnox: yeah, nevermind me
<pitti> jodh: good morning
<pitti> jodh: so I have a job which does something like
<pitti> exec /my/program >> /var/log/retracer.log 2>&1
<pitti> jodh: is there any chance to make this actually work somehow? it seems upstart does something to stdout and stderr to make this not work (xnox just confirmed that)
<pitti> jodh: I tried "script" instead of exec, and "console output", but that doesn't help
<xnox> pitti: exec /my/program &>> /var/log/retracer.log ?
<pitti> same result with &>>
<pitti> jodh, xnox: I also tried dropping the redirection and use "console log", but /var/log/upstart/ doesn't have anything
<xnox> pitti: script
<xnox>     myawesomeprog 2>&1 | logger -t myawesomeprog
<xnox> end script
<jodh> pitti: wfm: http://paste.ubuntu.com/1414330/
<pitti> jodh: that's precise, maybe it doesn't work there?
<zequence> Is there a reason for extra and partner repos not to be included when installing using wubi.exe?
<pitti> jodh: when I change stuff in /etc/init/, upstart should pick that up right away, right?
<jodh> pitti: this works in precise too. assuming you haven't invalidated the config file, yes Upstart picks changes up immediately. Use init-checkconf /etc/init/myjob.conf to establish that.
<jodh> pitti: the only other case where changes to .conf files won't be picked up is on the live cd.
<jodh> pitti: well, to be more precise in overlayfs envs (bug 882147)
<ubottu> Launchpad bug 882147 in linux (Ubuntu Precise) "overlayfs does not implement inotify interfaces correctly" [High,Triaged] https://launchpad.net/bugs/882147
<pitti> jodh: no, it's a standard precise VM in juju without overlays
<jodh> pitti: does /var/log/upstart/ actually exist? There was a bug a while back where it wasn't being created in cloud images.
<pitti> jodh: yes, it has gssd.log and statd.log
<jodh> pitti: ok - great.
<jodh> pitti: any chance I can see the .conf file? Also, see: http://upstart.ubuntu.com/cookbook/#checking-how-a-service-might-react-when-run-as-a-job
<pitti> jodh: http://paste.ubuntu.com/1414378/
<pitti> jodh: (sorry, in meeting)
<jodh> pitti: I think that redirection is the problem - for /bin/sh it means background process_core.py, whereas I assume you intended it to mean redirect both stdout+stderr to the file?
<jodh> pitti: upstart runs all jobs that need a shell using '/bin/sh -e'
<pitti> jodh: I also tried with >> log 2>&1
<pitti> (in fact that was my first code, xnox suggested trying with &>>
<pitti> but right, that's a bashism
<pitti> jodh: http://paste.ubuntu.com/1414384/
<xnox> ack. /me overuses bashism
<jodh> pitti: I guess the script is failing due to the minimal environment that Upstart provides the job. Try adding 'set' or 'env' calls just prior to calling the python script.
<jodh> pitti: or try my cookbook test mentiond above.
<pitti> jodh: oh, with exec >? trying
<jodh> pitti: silly question maybe, but is the script executable? Also, what's the first line of the python script?
<pitti> #!/usr/bin/python
<pitti> jodh: yes, it is
<pitti> jodh: I can call that very command in a shell, and it works
<pitti>   exec >> /var/log/retracer.log 2>&1
<pitti> that doesn't seem to work either
<jodh> pitti: when you say 'in a shell', you mean you've confirmed that the 'env -i' invocation works?
<pitti> jodh: no, I mean when I ssh, sudo -i, and run that command there
<jodh> pitti: please try the cookbook method.
<pitti> jodh: isn't that 17.4.2? that's what I tried
<pitti> I also tried env -i /var/retracer/daisy/process_core.py [...]
<jodh> pitti: no - http://upstart.ubuntu.com/cookbook/#checking-how-a-service-might-react-when-run-as-a-job
<pitti> (bbl, discussion here)
<bdrung> micahg: dh_xul-ext: xul-ext-test-package contains an invalid version range for {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
<bdrung> dh_xul-ext: minVersion <= maxVersion is required, but 10 > 8.
<bdrung> dh_xul-ext: xul-ext-test-package contains an invalid version range for {92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}
<bdrung> dh_xul-ext: minVersion <= maxVersion is required, but 2.4 > 2.0.
<bdrung> micahg: is this error message verbose enough or is something missing?
<pitti> jodh: re
<pitti> jodh: so that recipe means to run the service through nohup env -i?
<jodh> pitti: yes.
<jodh> pitti: what actually happens when you attempt to start this job? What output from start(8) do you get?
<pitti> $ sudo start retracer
<pitti> retracer start/running, process 18783
<pitti> jodh: still no change with
<pitti> http://paste.ubuntu.com/1414489/
<pitti> jodh: I'm beginning to suspect that the .conf file is not being re-read correctly, as none of the changes that I did in the past hour had any visible effect
<pitti> oh, it does; I now see /bin/sh -e nohup env -i ... in ps aux
<pitti> so reloading works
<jodh> pitti: sorry, what I mean is please run the exact example using nohup and env -i in the cookbook on the command-line, not in the job.
<jodh> pitti: well, to check that, just copy your updated job to some new name and start that job.
<jodh> pitti: or try 'sudo telinit q'
<jodh> pitti: you should also do 'sudo initctl log-priority debug' before attempting to start the job and then check /var/log/syslog
<jodh> pitti: is this python script forking by any chance? maybe you could just get a simple hello-world python script to convince yourself that that works as expected on this system?
<pitti> I'll try a job which is a simple echo
<pitti> so simple echo works
<jodh> pitti: a python script doing an echo?
<pitti> jodh: ok, thanks; the script doesn't fork, but it might do something funny
<pitti> I tried python -c "import sys; sys.stderr.write('world\n')" >> /tmp/logtest.txt 2>&1
<pitti> and that works, too
<_jmp_> micahg: ping
<_jmp_> micahg: unping sorry
<dholbach> can somebody please reject https://code.launchpad.net/~chilicuil/ubuntu/raring/cdo/fix-1023329/+merge/135245?
<dholbach> (explanation in the last comment)
<pitti> kicked
<dholbach> thanks pitti
<arges> micahg, infinity : hey wondering about bug 943502 still. Should I re-request a Backport or go for an SRU?
<ubottu> Launchpad bug 943502 in whois (Ubuntu Oneiric) "whois doesn't properly query .hr/.sx/.pe TLDs and incorrect format for whois.arin.net" [Medium,In progress] https://launchpad.net/bugs/943502
<ev> mpt: http://www.microsoft.com/en-us/pixelsense/default.aspx
<ev> pitti: https://errors.ubuntu.com/api/1.0/most-common-problems/?limit=0&format=json
<ev> bdmurray, pitti, mpt, xnox: https://bugs.launchpad.net/daisy/+bug/1052954/comments/2 and https://bugs.launchpad.net/daisy/+bug/1052954 - I'm having a hard time understanding the exact contours of this algorithm. Help wanted :)
<ubottu> Launchpad bug 1052954 in Daisy "top-k for arbitrary ranges is complex" [High,Triaged]
<mlankhorst> nooo why did synergy have to update :(
<mlankhorst> pinned it back to 1.3.8, stay!!
<mpt> ev, bug 1087290
<ubottu> Launchpad bug 1087290 in Apport "No easy way to test the various error types" [Undecided,New] https://launchpad.net/bugs/1087290
<micahg> arges: I think it's still a backport (new feature), I was just waiting for a signoff on the testing...did I miss it?
<micahg> arges: ah, if infinity said it's SRU worthy, run with that, if it was an ARIN change, that makes sense to SRU
<micahg> (sorry, I check IRC before E-Mail :))
<arges> micahg, cool its no problem, I think SRU makes sense in this case too. Sorry about all the back and forth on this bug.
<p0s> i want to help with packaging software for which no packages are available at all yet. can someone give me a link to an official guide for packaging new stuff?
<highvoltage> p0s: https://wiki.ubuntu.com/PackagingGuide - and perhaps #ubuntu-motu and #ubuntu-packaging might be better channels to ask about that
<p0s> highvoltage: thank you
<highvoltage> (or as that page rightly points out, http://developer.ubuntu.com/packaging/html/ )
<burlak> Guys, I'd like to contribute in ubuntu project but i have no idea how.
<penguin42> burlak: What do you know? Programming? Art? Docs?
<burlak> I'm RTOS developer
<burlak> penguin42: but I can do anything.
<penguin42> hmm ok
<burlak> penguin42: can I send my resume to someone?
<penguin42> burlak: Well not really unless you're looking for a job
<burlak> penguin42: I have a job :D
<penguin42> burlak: http://www.ubuntu.com/community/get-involved
<burlak> penguin42: is there somewhere something like project list so i can choose the one which is the best for me?
<burlak> penguin42: thx
<hallyn> if pkg A Breaks: B (<< ${source:Version}) then pkg A simply won' tinstall.  If it Conflicts, will it remove pkg B before installing A?
<stgraber> hallyn: I think http://www.debian.org/doc/debian-policy/ch-relationships.html should answer any question you have :)
<hallyn> no i'm looking at that
<stgraber> hallyn: but basically you probably want a Breaks + Replaces if the goal is to have a package replace another
<hallyn> oh, yes
<hallyn> stgraber: that is not sufficing
<hallyn> let me give a fuller version :)
<cjwatson> Conflicts is stronger than Breaks
<hallyn> meaning it will uninstall the conflicting pkg?
<cjwatson> Conflicts: A and B may not be unpacked at the same time
<hallyn> lemme go read the doc
<cjwatson> Breaks: A and B may not be configured at the same time
<hallyn> ok that sounds like something in eed, but still perhaps not enough
<cjwatson> apt often has a choice about what to do and it depends on scoring
<cjwatson> Policy has general instructions on what you should do in a variety of situations
<cjwatson> So you should definitely read that first
<hallyn> ok, will do before babbling more here, thanks
<brendand> mvo, mpt - i've just been watching a user focused video on youtube where someone was trying to use software center to actually locate an app to use. would there be any harm in having an 'open' button on an apps page in software-center (kind of like on android)?
<mpt> brendand, the issue has always been that people wouldn't then learn how to launch it outside of USC
<mpt> brendand, that's why the app icon flies into the Launcher, to show you where to find it.
<mpt> brendand, did the icon fly into the Launcher in the video?
<xnox> mpt: it would not have if an app doesn't have desktop file =)))))
<mpt> xnox, it's unlikely that's the kind of app brendand is talking about
<xnox> mpt: true.
<brendand> mpt - so the particular circumstance here was someone asked to find the calculator app
<mpt> brendand, do you have a link to the video?
<brendand> mpt - gcalc is already there, so no flying
<brendand> mpt, https://www.youtube.com/watch?feature=player_detailpage&v=PgGbZfR6Vec#t=641s
<mpt> ta
<mpt> ergh, that LibreOffice Calc name+icon keeps coming up as a usability problem
<brendand> something that always strikes me from those videos is how it often takes people a long time to discover the dash
<brendand> seems like there should be a big arrow pointing at it on first boot
<mpt> Yes, there hasn't been much effort into that
<mpt> I know there were proposals for a different icon
<mpt> e.g. a home icon instead of the Ubuntu logo
<mpt> brendand, "I thought all those things were installed." She was a bit misled by the moderator, I think. :-)
<mpt> He gave the impression it was like the Applications folder
<brendand> mpt, that's true
<mpt> "I just stumbled across that" -- the Dash button
<penguin42> mpt: I've seen some experienced people also have difficulty noticing it was special
<mpt> yeah
<mpt> Bug 552920 makes an appearance at https://www.youtube.com/watch?feature=player_detailpage&v=PgGbZfR6Vec#t=14m06s
<ubottu> Launchpad bug 552920 in unity (Ubuntu) "Moving diagonally from narrow menu title often opens adjacent menu" [Medium,Triaged] https://launchpad.net/bugs/552920
<brendand> also, i know it's a touchy subject but it seems to bug a lot of beginners that the window controls are hidden by default
<mpt> brendand, it bugs me too :-)
<brendand> have there been any experiments with perhaps having the window controls always there alongside the title/menus?
<mpt> brendand, not publicly
<penguin42> there seem to be lots of things where the fortify stuff triggers in Ubuntu for trivial (non-exploitable) 1 char overruns, that probably never actually cause any harm; is it normal to raise Debian bugs for those even though they don't trigger in Debian?
<slangasek> penguin42: there are real-world exploits demonstrating that a 1-char overrun is sufficient to compromise the system
<slangasek> if the overflow exists in Debian, certainly it's reasonable to raise a bug against Debian
<penguin42> slangasek: Yep; I just keep finding 1 char overflows in static data where you can see the compiler will have padded the allocation to the next word so it'll never overflow
<slangasek> (providing sufficient additional information to let the Debian maintainer reproduce and understand the issue, of course)
<penguin42> sure
<slangasek> penguin42: the allocation may be padded, but is it guaranteed to be zero-filled?
<mvo> brendand: what mpt said, impleenting open is trivial (and there is a branch for this already) - there is also work to make the fly-in feature better
<penguin42> slangasek: Not necessarily a problem; I just keep finding ones where someone has forgotten the space for the \0 and we fall over when it copies the initial string in
<slangasek> ah
<mvo> brendand, mpt:  lp:~mvo/unity/sc-launcher-integration-fixes  <- that will hopefully make the fly in feature better
<penguin42> slangasek: Although there is one which turned out to be a y2k problem because the date was being printed as 2112 :-)
<penguin42> sorry, 20102 I think
<slangasek> penguin42: well, the path of least resistance may still be to clean this up rather than trying to argue with the compiler.  Debian packages should be using fortify too nowadays, though it does require debian/rules to be properly constructed
<brendand> mvo, i'm playing devils advocate, but i don't necessarily see people continuing to use the hypothetical 'open' button in swc once they discover the dash
<brendand> but i'm absolutely no usability expert
<penguin42> slangasek: Yep; most of these things are in universe packages that have just always failed in ubuntu for years
<mvo> brendand: I personally would not mind getting the open-button branch landed, but its not my decision
<mvo> lets see what the new fly-in branch will do :)
<cjwatson> I'm surprised there are all that many; there were 83 failures total in quantal/i386, according to the rebuild test a little before release
<mvo> I hope it fixes the problem
<cjwatson> I can believe there are some, certainly
<penguin42> slangasek: Like bug 1033250 (which I've linked a branch against)
<ubottu> Launchpad bug 1033250 in xpilot-ng (Ubuntu) "crash on asking for internet game" [Undecided,In progress] https://launchpad.net/bugs/1033250
<cjwatson> xpilot-ng doesn't seem to have failed in the rebuild test ...
<cjwatson> Ah, failing to run not to build
<penguin42> cjwatson: Yeh it's a fail to do internet games, it's a 1 char overflow (they have a magic constant of 10000 for the pingtime to mean there was a problem, but they try to print the ping time into a 5 char buffer)
<ScottK> Adri2000: I see you're the Debian maintainer of actionaz.  It fails to build with the new opencv in both Debian experimental and Ubuntu raring.  I was wondering if you could have a look at it.
<Adri2000> ScottK: sure, I'll have a look
<ScottK> Adri2000: Thanks.
<hallyn> stgraber: ok, things are a tiny bit better now.  apt-get dist-upgrade with qemu-kvm installed does:  qemu-kvm depends on qemu-system (which conflicts/replaces/provides qemu-kvm which itself becomes a metapkg) which recommends qemu-utils which conflicts/replaces qemu-kvm (has to bc qemu-io is in both) - so qemu-kvm gets removed, removing the qemu-system dependency, so you end up with only qemu-utils installed.
<hallyn> i get the feeling i'm making things more complicated than they need to be
<cjwatson> Trying to forcibly remove transitional packages is usually a mistake
<ricotz> infinity, hi, did you had a look at https://bugzilla.gnome.org/show_bug.cgi?id=687265#c9 ? it is pretty much needed if a newer glib/gstreamer lands
<ubottu> Gnome bug 687265 in general "deadlock in libcanberra-pulse with gstreamer 1.0.2" [Normal,Unconfirmed]
<psusi> andreas__: why does the upstream landscape-client have a debian/ directory?  isn't this wrong?
<hallyn> cjwatson: i want to remove the old (real pkg) qemu-kvm, replaced with the new (meta) one
<cjwatson> Err, that's an upgrade not a removal ...
<andreas__> psusi: we have it in the bzr branch, because we do daily builds, but the tarball doesn't include it, and the ubuntu package has its own
<hallyn> cjwatson: i don't know how to express that in debian/control
<cjwatson> You're moving files from qemu-kvm to qemu-system/qemu-utils, yes?
<hallyn> yup
<infinity> hallyn: You can't force removal of yourself like that.
<cjwatson> Then qemu-system/qemu-utils Breaks/Replaces: qemu-kvm (<< first-version-not-to-contain-those-files)
<psusi> andreas__: I see.. so if I'm patching it, should I just patch the sources without bothering with quilt and submit a merge proposal?
<cjwatson> Don't use Conflicts
<hallyn> cjwatson: breaks/replaces didn't work: it simply refused to install qemu-utils
<psusi> andreas__: and should I update the changelog?
<cjwatson> Then you made some other mistake
<andreas__> psusi: yes, worry just about the ubuntu package, we merge back to our branch what is needed
<hallyn> likely
<cjwatson> The usual mistake is to forget to version things correctly
<infinity> hallyn: As you described it, that's just not going to work.
<hallyn> i did also change versioning just now.
<psusi> andreas__: ok
<hallyn> infinity: even if i do breaks/replaces the way cjwatson says?
<cjwatson> Change it back to Breaks and make sure the << versioning is there.  That should be enough.
<infinity> hallyn: If you do breaks/replaces (versioned!) with no conflicts, it'll be fine.  But it won't result in what you thought it would.
<cjwatson> I'm assuming that qemu-io is not in the new version of qemu-kvm.
<hallyn> cjwatson: ok, thanks.
<infinity> hallyn: As in, it won't remove qemu-kvm.  Which is fine.
<hallyn> no
<hallyn> ok lemme try that again.  thanks
<hallyn> (before i was doing breaks qemu-kvm << ${source:Version},  now im' doing <= (the-old-version)
<hallyn> maybe that's what i was doing wrong with the breaks.
 * hallyn goes to try
<cjwatson> As I say, it should be << first-version-not-to-contain-those-files
<infinity> hallyn: Either of those works, but being strict is more correct, yes.
<cjwatson> Not ${source:Version}, and not <= (otherwise trouble with derived versions)
<infinity> hallyn: << source:Version still would have "worked", though, in your testing, so something *else* was wrong on top of that.
<hallyn> that's what i'm seeing in what cjwatson says too.  grr
<cjwatson> Yeah.  If it still doesn't work, post `debc foo.changes`
<cjwatson> (of the built version)
<hallyn> i can't test this just with dpkg right?  ihave to go through ppa and apt-get?
<infinity> No need to use a PPA, but yes, a local apt repository is a saner test.
<cjwatson> You certainly *can* test it with dpkg but it may not be as good a test
<infinity> Still, "dpkg -i foo bar baz" isn't an awful first test.
<infinity> It just misses out on some pseudo-intelligent ordering apt might do.
<infinity> hallyn: Can I just see your control file?  This might be easier to help with if it's not being turned into IRC English.
<hallyn> infinity: actually i just caught a mistaken << last-bad-version in place of <= , that might be why it broke this time.  but i'm in the process of changing it to << first-good-version as cjwatson said
<hallyn> i'll pb the previous control file in just a min
<hallyn> infinity: well http://paste.ubuntu.com/1415346/ is the version I'm about to push
<hallyn> infinity: http://paste.ubuntu.com/1415348/ is the last bad version - note i had bad comparisons in qemu-system replaces
 * hallyn hopes the new version finally does the right thing
<infinity> Looks like it should, assuming the versions are all correct.
<infinity> I went cross-eyed at this, though:
<infinity> Breaks:  qemu-system (<< 0.12.4+dfsg-4), qemu-kvm (<< 1.2.0-z-dfsg-1), qemu-common (<< 1.2.0-z-dfsg-1)
<infinity> Replaces:  qemu-system (<< 0.12.4+dfsg-4), qemu-common (<< 1.2.0-z-dfsg-1), qemu-kvm (<< 1.2.0-z-dfsg-1)
<infinity> (position of -kvm and -common swapped on the two lines makes it a bit harder to notice the matched pairs)
<andreas__> psusi: you could make a merge proposal against the landscape-client source code, not worrying about the packaging stuff
<hallyn> infinity: d'oh, yeah, i'll change that (for the next upload)
<hallyn> one unrelated question - to remove the old /etc/init/qemu-kvm.conf, i gather i need to do that in qemu-system.postinst?
<psusi> andreas__: should I do that, or did you say not to worry about it?
<hallyn> (it offers a /etc/init/qemu-system.conf which takes the palce of that one)
<andreas__> psusi: I meant not to worry about packaging if making a MP against the upstream branch, sorry :)
<psusi> andreas__: ahh, ok
<arosen> If I do debchange --create --package foo -v  200.1-bar-1; then Run i run dpkg-buildpackage it looks for ../foo_200.1-bar.orig.tar.bz ; I'm wondering why it isn't also searching for the -1 ?
<arosen> If I change - to . it works fine. I'll just do that for the version instead.
<Adri2000> arosen: because what is after a '-' is the debian revision. the original tarball's name should contain upstream version only. maybe what you are looking for is native package. anyway, #ubuntu-motu is probably better for this kind of questions
<ScottK> Adri2000: I saw your comment on #d-devel about the opencv bug.  Could up upload a fixed version to raring?
<ScottK> up upload/you upload
<Adri2000> ScottK: just with the bug fix right? 2.4.3 seems to have a number of other changes so I'd rather let that to the debian maintainer if we don't want particularly need this specific version now
<ScottK> Adri2000: Someone uploaded 2.4 and then blew off the rest of the library transition.  I'm just trying to get everything built.
<ScottK> So I'm fine with just the bug fix.
<Adri2000> ah I see :)
<Adri2000> will do that then
<micahg> ScottK: no, there was an attempt at the transition, not sure what happened
<ScottK> micahg: Only one of the redepnds was uploaded.
<ScottK> And it's FTBFS on armhf
<micahg> ScottK: I count 10
<ScottK> OK
<ScottK> I guess I started with the list of what wasn't done
<micahg> I know he was having some issues with it though, not sure what exactly went wrong
<ScottK> I'm only trying to get digikam to transition without taking any of the extreme measures I could as an archive-admin or release team member.
<micahg> ScottK: there was an attempted rebuild of it yesterday :)
<ScottK> It would be nice if someone who knows something about java would look at sikuli
<ScottK> It FTBFS for Java'ish reasons unrelated (I think) to opencv
<micahg> jamespage: ^^
<ScottK> org/sikuli/ide/PreferencesWin.java:499: error: cannot find symbol
<ScottK>       DefaultComponentFactory.setTextAndMnemonic(_titleAppearance, I18N._I("PreferencesWin.titleAppearance.textWithMnemonic"));
<ScottK> wallch and libav-extras were no-change rebuilds.  I uploaded those
<ScottK> Once Adri2000 fixes opencv, he can upload actionaz.
<ScottK> Then it'll be down to sikuli and the armhf failure on sivp
<infinity> ricotz: I'll get a fix for that in before the weekend.
<ricotz> infinity, great, thanks
<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 dicussion 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
<jandrusk> Anyone know why libssh2-1 is in repo Universe and not the Main repo?
<ScottK> Because nothing in Main needs it in Main.
<jandrusk> Doesn't libcurl3-gnutls need it to be compiled with SSH support?
<micahg> libssh is in main
<hallyn> infinity: alas, the new packages with that versioning gave me http://paste.ubuntu.com/1415560/
<jandrusk> Trying to figure out why libcurl is compiled without SSH support.
<micahg> who says it is
<jandrusk> It's been discussed on the sword-devel mailing list. Is it compiled with SSH support?
<jandrusk> Should I just reach out to the libcurl Ubuntu package maintainer?
<micahg> hrm, doesn't seem to have it
<micahg> jandrusk: I'd suggest asking teh Debian maintainer
<jandrusk> micahg: thanks, i will do that.
<infinity> micahg: Err, no, asking the Debian maintainer will get him LARTed.
<infinity> +  * Resynchronise with Debian.  Remaining changes:
<infinity> +    - Drop dependencies not in main:
<infinity> +      + Build-Depends: Drop stunnel4 and libssh2-1-dev.
<infinity> +      + Drop libssh2-1-dev from binary package Depends.
<infinity> ^-- That's an Ubuntu-specific delta.
<micahg> jandrusk: ^^ sorry
<micahg> infinity: apparently I'm not quite awake yet, thanks
<infinity> hallyn: Curious.  Is this source package in a PPA somewhere or something?
<infinity> hallyn: I kinda want to take a closer look. :P
<hallyn> infinity: yeah, ppa:serge-hallyn/crossc
 * hallyn wishing he'd picked a different lp username years ago
<infinity> If you don't mind losing all your PPAs, you can always rename. :P
 * infinity wonders why there's a sparc cross toolchain in here.
<hallyn> and code branches
<hallyn> weren't you there last time we discussed that? :)
<infinity> Nope.
<infinity> Also, on a side note, this version number is crack.
<hallyn> infinity: it's workaround for bug 217427 (the cross compiler that is)
<ubottu> Launchpad bug 217427 in Launchpad itself "Please support arbitrary arch/buildd affinity for arch:all builds" [High,Triaged] https://launchpad.net/bugs/217427
<hallyn> or, attempt at working toward one...
<infinity> It would take more than arch affinity to fix the ability to build sparc packages. :)
<hallyn> same for powerpc though
<micahg> jandrusk: here's your reason: https://bugs.launchpad.net/ubuntu/+source/libssh2/+bug/173783
<hallyn> infinity:  as for version #, yes, i've been looking for a solution, dont' have one yet.
<ubottu> Launchpad bug 173783 in libssh2 (Ubuntu) "main inclusion request" [Wishlist,Won't fix]
<infinity> Yeah, I know.  SLOF is currently in that predicament.
<hallyn> infinity: the debian version is 1.2.0-dfsg, the ubuntu one is 1.2.0+noroms and 1.2.0-2012something
<hallyn> infinity: and we're switching to the debian versions.  so other than switching to 1.3.0 source, i'm not sure how best to force revert to debian versions
<hallyn> now i guess i'm not entirely opposed to running 1.2.0 out of a ppa until 1.3.0 comes out and onlys witching archive over then
<hallyn> but it seems like there must be a better answer :)
<infinity> hallyn: As in, this source is going to be uploaded to Debian as well?
<hallyn> infinity: right, this is from the debian qemu team's experimental branch
<hallyn> it's the qemu tree to supplant qemu-kvm
<infinity> hallyn: Well, I hate to break it to you, but 1.2.0-z isn't higher than 1.2.0+noroms
<infinity> hallyn: Which could be your problem here. :P
<infinity> hallyn: + sorts higher than -
<hallyn> well shoot
<hallyn> now i don't even know if i meant to do 1.2.0+z, 1.2.0z, or if i was jsut wrong all along
<ScottK> micahg: Considering things like MaaS get accepted directly into Main days before a release, I think that's hardly reason to keep stuff out anymore.
<infinity> hallyn: 1.2.0.dfsg-1
<infinity> hallyn: Unless there's likely to be a 1.2.0.1
<ScottK> Also, it's no longer a young project ... (5 years later)
<infinity> hallyn: Or 1.2.0+zzzz+naps+lolcats-1
<hallyn> ooh i like that
<micahg> ScottK: right, but I don't think the security team would want to support 2 libssh packages
<hallyn> infinity: let me try 1.2.0.dfsg-1, thanks.
<hallyn> infinity: one other q,
<hallyn> am i right that qemu-system.postinst needs to rm /etc/init/qemu-kvm.conf ?
<hallyn> (dpkg isn't going to do that for me right?)
<slangasek> hallyn: no
<hallyn> the file /etc/init/qemu-system.conf will take its place
<hallyn> slangasek: no i shouldn't do that, or no it wont' do that for me?
<slangasek> hallyn: dpkg-maintscript-helper(1), "mv_conffile"
<infinity> hallyn: Potentially both of those answers.
<slangasek> hallyn: which can be automated using debhelper by creating a debian/qemu-system.maintscript file, containing a mv_conffile [...] line
<infinity> slangasek: Will mv_conffile still do sane things if it's also being bounced between packages at the same time?
<infinity> (Which is the case here, I believe)
<slangasek> infinity: provided you include the "package" argument, I believe so
<infinity> Which package would that be?  The old or the new?
<hallyn> slangasek: thanks, looking at the manpage
<hallyn> infinity: thanks much, have high hopes that it'll work after next build :)
<infinity> hallyn: Well, fixing the versioning can't make it any worse off anyway. :P
<infinity> hallyn: Also, dpkg --compare-versions is your friend.  Especially before you accidentally paint yourself into crazy corners you can't version out of.
<infinity> (But once you do, it's also your partner in crime in trying to come up with evil hacks to make things even worse)
<hallyn> infinity: that's the thing, i *did* use dpkg --compare-versions.  which makes me wonder what concoction i was drinking that day.
<infinity> hallyn: Whatever it was, you should send me a thermos full.
<infinity> hallyn: (Don't forget to fix all your replaces and breakseses while you're changing your version, since those ones will never sort sanely for the +noroms upgrade case)
<hallyn> infinity: fix the << 1.2.0-z to be << 1.2.0.dfsg-1 right?
<infinity> Aye.
<hallyn> yup, that's one, now i'm just trying to figure out how to use dpkg-maintscript-helper
<infinity> If there *is* a danger of a 1.2.0.1, you don't want to use that scheme, BTW.
<infinity> Since alpha sorts higher than num.
<hallyn> well, upstream has 1.3.0, so i sure hope debian won't decide to do a 1.2.0.1
<infinity> You could also go German and have 1.2.0+zfsg-1 ;)
<hallyn> :)
<slangasek> 1.2.0+zfsg-1GmbH ?
<bdrung> gladk: thanks for the sync requests.
<bdrung> gladk: i guessed that the upload to experimental was due to the freeze. :)
<bdrung> gladk: feel free to ping me to get packages synced (if you want to avoid filing sync requests)
<gladk> bdrung: Ok, thanks!
<bdrung> you're welcome
<gladk> bdrung: it would be good to sync freecad, but it should be better tested before
<gladk> bdrung: I will let you know
<bdrung> okay
<bdrung> the ubuntu diff is funny :)
<gladk> I have requested a month ago a bug LP:1072053 to fix a couple of annoying bugs in paraview-package, which shipped in 12.04 LTS
<gladk> but no reaction since
<gladk> should it get "freeze-exception" first?
<bdrung> gladk: you got no reaction, because ubuntu-sponsors is not subscribed and therefore it does not show up on http://reqorts.qa.ubuntu.com/reports/sponsoring/
<bdrung> gladk: for stable release updates, please follow https://wiki.ubuntu.com/StableReleaseUpdates
<gladk> bdrung: ok, thanks
<bdrung> time to bake a cake
<penguin42> wow - an sprintf into a parameter; no wonder it crashed       sprintf(client_server,"%s_%s_%s", client_server, servername, getportname(server_port) );
<infinity> penguin42: What could possibly go wrong?
<penguin42> infinity: Well.... according to the manpage of sprintf the standard explicitly disallows it (only as of C99 and Posix.1-2001!) and actually notes that somethings rely on it
 * penguin42 doesn't understand how this code doesn't die on debian
<infinity> I wouldn't have needed a manpage to point out that sprintf(foo, format, foo) might be a bad idea.
<penguin42> infinity: Indeed, I thought I'd just better check though
<penguin42> infinity: The fact that there is an explicit note about it in the man page and that it was only in C99 that it was explicitly disallowed is worrying
 * penguin42 thinks this code is probably unsalvegable
* You're now known as ubuntulog
<penguin42> for ref that's bug 1026902 / debian bug 695312
<ubottu> Error: Launchpad bug 1026902 could not be found
<ubottu> Debian bug 695312 in tcpick "tcpick write.c seg" [Normal,Open] http://bugs.debian.org/695312
<infinity> penguin42: It could segv on Ubuntu but not Debian because we build with FORTIFY_SOURCE=1
<Adri2000> is it possible to see why a package hasn't yet migrated from the proposed pocket to the release pocket? (in the current developement release)
<ScottK> Adri2000: Yes.http://people.canonical.com/~ubuntu-archive/proposed-migration
<ScottK> The britney output is not the easiest to parse, but the data is there.
<Adri2000> ScottK: thanks. btw, just uploaded opencv. once it's built everywhere, I will upload an actionaz rebuild
<ScottK> Adri2000: Thanks.
<penguin42> infinity: I was more surprised that it managed to survive even on a system without fortify
#ubuntu-devel 2012-12-07
<mfisch> mhall119: I'm around now, missed you on G+
<mhall119> mfisch: ?
<mfisch> mhall119: you invited me to a hangout
<mfisch> mhall119: about an hour ago
<mhall119> I did?  I didn't mean to
<mhall119> I hope it didn't invite the entire community :(
<mhall119> I was just trying it out, to see if it could be made on-air
<dholbach> good morning
<achiang> dholbach: good morning
<dholbach> hey achiang
<pitti> Good morning
<pitti> ev: https://code.launchpad.net/~daisy-pluckers/+recipe/apport-test-crashes
<jamespage> @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 dicussion 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: jamespage, mterry
 * dholbach hugs jamespage and mterry
<cjwatson> jdstrand: Have you had a chance to consider bug 1077484?
<ubottu> Launchpad bug 1077484 in shadow (Ubuntu) "[MIR] libsemanage (shadow's rdep to continue SELinux support in shadow)" [Undecided,Confirmed] https://launchpad.net/bugs/1077484
<mpt> ev, please update bug 1084624 with the conclusion of yesterday's discussion (I don't know what it was, exactly)
<ubottu> Launchpad bug 1084624 in Apport "Can't provide comments when submitting an error report" [High,Triaged] https://launchpad.net/bugs/1084624
<ev> will do
 * apw wonders where /etc/mailcap comes from, which package ... (so he can file a bug against it)
<seb128> diwic, hey, do you know what configuration file tells pulseaudio what components to load? jason is having an issue where pulseaudio refuses to start without pulseaudio-esound-compat ... or the esound compat shouldn't be required
<diwic> seb128, that's a known bug, let me find it
<diwic> seb128,  that said, I still don't understand why it happens *now*
<diwic> seb128, I think it's bug 1078543
<ubottu> Launchpad bug 1078543 in pulseaudio (Ubuntu) "[raring] Pulse audio fails to start with error 'Failed to open module "module-esound-protocol-unix": file not found'" [Undecided,Confirmed] https://launchpad.net/bugs/1078543
<diwic> seb128, I believe the problem is that the esound compat file is the wrong arch
<seb128> diwic, correct, from jason's log
<seb128> ii  pulseaudio                                1:2.1-0ubuntu4                              amd64        PulseAudio sound server
<seb128> ii  pulseaudio-esound-compat                  1:2.1-0ubuntu4                              i386         PulseAudio ESD compatibility layer
<seb128> diwic, thanks
<cjwatson> LoganCloud: Do you think you could merge dpkg-cross from Debian experimental?  Looks like you touched it last (if I've got the right Logan)
<mlankhorst> dpkg-blame should be a command ;-)
<vibhav> mlankhorst: heh
<jamespage> @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 dicussion 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
<jdstrand> cjwatson: not yet, hope to get to it today
<jamespage> arges, OK if I steal the rsyslog merge for raring from you?
<seb128> could somebody set those "work in progress":
<seb128> https://code.launchpad.net/~brightbox/ubuntu/quantal/lvm2/fix-for-1075994/+merge/133645
<seb128> https://code.launchpad.net/~brightbox/ubuntu/quantal/lvm2/fix-for-1076304/+merge/133438
<seb128> https://code.launchpad.net/~lqs/ubuntu/precise/tcc/tcc-fix-mmap-leak/+merge/134058
<seb128> thanks
<seb128> stgraber, pitti, cjwatson: ^
<seb128> https://code.launchpad.net/~andrikos/ubuntu/quantal/fglrx-installer/fix-switch-to-igpu/+merge/132962 as merged as well
<cjwatson> WIPs done.  Where's that been merged?
<seb128> cjwatson, thanks,http://www.phorogit.com/index.php?p=fglrx-packaging.git&a=commitdiff&h=a1d481315f8ffffcd3ca67f9d6c581f1cf44b9fa&hb=8bf73d7de86f2ee105ece1daa2a143e9c55cb255 where tseliot seems to maintain his vcs...
<seb128> cjwatson, well http://www.phorogit.com/index.php?p=fglrx-packaging.git&a=commitdiff&h=9eaed4a5fee3d67c8ca8cd026189f8cc461a532a&hb=a1d481315f8ffffcd3ca67f9d6c581f1cf44b9fa rather
<xnox> seb128: is it uploaded?
<seb128> xnox, not yet, but it doesn't need to stay in the sponsoring queue...
<xnox> ok.
<seb128> xnox, isn't "merged in the vcs" equivalent to "merged"?
<seb128> xnox, if you merge to lp:ubuntu/<source> without uploading launchpad would set it to merged as well
<xnox> unless you haven't already, comment on the merge proposal such that the sponsoree knows it's merged there and will be in the next upload.
 * xnox not fully sure about the correct application of double negative above....
<seb128> xnox, well, tseliot commented yesterday saying it's fixed upstream with a link to git diff url
<xnox> good enough for merged status then =)
<arges> jamespage, hey. are you talking about bug 1059592 ? I thought raring was already fixed in comment #8
<ubottu> Launchpad bug 1059592 in rsyslog (Ubuntu Quantal) "Message and memory corruption in rsyslog" [High,Fix committed] https://launchpad.net/bugs/1059592
<jamespage> arges, no - there is a new upstream version in Debian I want to merge; it fixes that problem
<arges> jamespage, yea that'd work too if its > 5.8.7
<jamespage> arges, 5.8.11 - I'll merge it if thats OK with you (polite to check with last uploader before stealing merges :-))
<arges> jamespage, yup no problem. I figured that's what would happen for that one anyway
<cjwatson> seb128: OK, marked as merged then
<seb128> cjwatson, thanks
<marga> seb128, I'm looking at https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1035219 (the bengali issue outside of Unity).  It says that you made an upload fixing it, for raring, posibly.  Are there plans to push it to quantal/precise?
<ubottu> Launchpad bug 1035219 in Baltix "In System Settings preference tool/keyboard layouts page automaticaly wrong language selectedGNOME" [High,In progress]
<marga> The patch looks ugly and big, so I guess probably not.
<seb128> marga, hey, "bengali"... that sounds like a different bug
<marga> It's what the bot said
<seb128> what bot?
<marga> the wrong language gets selected if you go to the regional settings and don't click on anything, using gnome/cinnamon
<seb128> marga, that bug is about having the wrong language selected when you open the region capplet
<marga> Up there ubottu
<seb128> marga, yeah, and you wrote "the bengali issue outside of Unity"
<marga> Yeah, bengali is the first in the list.
<marga> So, everything turns to bengali.  At least here.
<seb128> oh, ok ... it's chinese for most people
<seb128> yeah, depends of the langpacks installed
<seb128> marga, I got confused because I was reading https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/991002 earlier
<marga> Oh... Right, I guess we have more languages installed.
<ubottu> Launchpad bug 991002 in lightdm (Ubuntu) "Change name for bn-BD from 'Bengali(Bangladesh)' to 'Bangla(Bangladesh)')" [Undecided,In progress]
<marga> Anyway, that patch looks like it probably fixes what needs to be fixed, but it's an aweful lot of code for an SRU.
<seb128> marga, in any case I didn't fix that bug, the comment that closed the bug is confusing
<seb128> gnome-control-center (1:3.6.3-0ubuntu3) raring; urgency=low
<seb128>   * debian/patches/60_ubuntu_nav_bar.patch:
<seb128>     - restore the navigation bar interface
<seb128> that's nothing to do with that issue
<seb128> ok, I guess it's the workaround from jbicha in 1:3.6.3-0ubuntu1
<marga> Oh.  I thought it was a very complicated way of fixing the widget.
<seb128> marga, it seems like it was workaround in http://bazaar.launchpad.net/~ubuntu-desktop/gnome-control-center/ubuntu/revision/505
<marga> Ah, I see... Silly me.  It's patch 52
<seb128> marga, I'm fine SRUing the workaround, it's not perfect but better than the bug for sure
<seb128> marga, is there any chance you could test if that fix your issue?
<marga> Sure, yes.
<marga> I can test the patch for precise and quantal
<marga> Prepare the package and stuff
<seb128> marga, that would be great, thanks
<marga> Ok, I'll get on with that.  Thanks to you :)
<seb128> yw ;-)
<jamespage> ScottK, micahg: taking a look at sikuli now
<jdstrand> kees: hey, libseccomp has an MIR and I noticed that 1.0.0-1 has been sitting in Debian NEW for 4 months and we don't have it in Ubuntu yet. can you elaborate?
<jdstrand> (I do see this in the changelog: Change the API to be context-aware; eliminates all internal state but breaks compatibility with the previous 0.1.0 release
<jdstrand> )
<jdstrand> hallyn: will that ^ affect lxc?
 * xnox ponders if stgraber has lxc highlight or not ^
<jdstrand> xnox: thanks
<arges> micahg, infinity : just to triple check, are you guys ok with SRUing bug 943502 ? Or did we want to go forward with the backports?
<ubottu> Launchpad bug 943502 in whois (Ubuntu Oneiric) "whois doesn't properly query .hr/.sx/.pe TLDs and incorrect format for whois.arin.net" [Medium,In progress] https://launchpad.net/bugs/943502
<hallyn> jdstrand: yup, more than likely.
<stgraber> xnox: no but I pretty much always read the scrollback for this channel :)
<xnox> stgraber: I am so sorry, sir. I will improve, sir. =)
<marga> seb128, if the package version was ubuntu1, should the version in my debdiff be ubuntu2 or ubuntu1.1 ?
<seb128> marga, 1.1 for a SRU
<marga> ok, tnx
<seb128> yw
<hallyn> jdstrand: unless stgraber wants to do it, i guess i'll put looking at the new seccomp api on my todo list, but i've *got* to figure out the qemu mess first
<dholbach> jodh, you might be interested in having a chat with the guy in https://plus.google.com/109795858099658821877/posts/192eMwxNAtF
<jodh> dholbach: thanks - on it.
<dholbach> jodh, awesome :-D
<seb128> hallyn, ^ in the URL dholbach just pointed the guy mentioned working on "seccomp filter support to Upstart" ... not sure if that's related with what you were talking about
<hallyn> seb128: not particularly, but interesting.
 * hallyn goes to read
<dholbach> give the guy a hug! :)
 * dholbach likes the new G+ communities already
<hallyn> too much brightness and pictures, can i get a text feed? :)
<dholbach> right :)
<jdstrand> hallyn: that's fine-- no rush on my end
<jodh> dholbach: I've provided some details for David now.
<dholbach> jodh, great - I hope he'll become an active contributor!
<marga> seb128, there, built and tested it for both precise and quantal, uploaded the diffs to the bug.  I'll add the SRU header now.  Let me know if I need to do anything else.
<seb128> marga, looking
<marga> Writing Regression Potentials is always the hardest part of filing an SRU
<marga> I have no idea of the regression potentials that this might have.
<seb128> marga, yeah, that section is not easy, it's meant to be a "what should the person doing the verification test for regression"
<marga> Yes, and I know that it's important, but most of the time I have no idea of what to put there.
<seb128> marga, so for those sort of bug it's something around the line of "using the region panel, in a non unity session, to change languages and check that the result is the one wanted"
<marga> But that's the test case
<marga> Regression potential is other stuff that could break
<seb128> well, there is little potential to impact on anything else
<seb128> I often end up by writing lame "regression potential" sections and I guess others do the same...
<marga> Well, there, I did my best.
<marga> Let me know if I need to do anything else.
<seb128> marga, looks good to me, I'm sponsoring the updates, thanks
<marga> Thanks for the sponsoring :)
<seb128> marga, btw "  * Non-maintainer upload." ... that's not needed in Ubuntu ;-)
<marga> heh, I wasn't sure, that's dch -n default behaviour.
<marga> I'll keep it in mind for the next time.
<hallyn> slangasek: so i'm trying to use dpkg-maintscript-helper mv_confile (in some dummy test pkgs).  I want an upgrade from v1 to v2 to move apkg.conf from pkg apkg to bpkg.conf owned by bpkg.  I'm not sure that's doable?
<hallyn> if i have bpkg.preinst, postinst and postrm doing mv_confile apkg.conf bpkg.conf 1.0 apkg, then nothing happens...
<hallyn> trying calling them apkg.* now...
<hallyn> hm maybe that works
<xnox> hallyn: dpkg-maintscript-helper doesn't quite work across package renames.
<hallyn> yay it works
<hallyn> xnox: it did!
<hallyn> oh it's not a pkg rename
<hallyn> the confile is moved to another pkg
<xnox> hallyn: Hmm.. See interesting discussion about ~ similar issue here: http://debian.2.n7.nabble.com/Renaming-packages-maintscripts-td1058526.html#none
<hallyn> looking
<infinity> hallyn: Having it in apkg.preinst probably works, except for the unwind cases, I suspect.
<infinity> hallyn: The reason it needs to be in apkg.preinst, FWIW, and not in bkpg, is because dpkg won't remove the ref to the conffile from apkg.list if it's still on-disk (it'll just list it as obsolete), so it needs to be moved before apkg is unpacked.
<infinity> hallyn: But that would, I suspect, lead to other surprising oopses because if apkg depends on bpkg, then you're unpacking the new one before overwriting it, thus creating a potential conffile prompt on the next upgrade of bpkg.
<infinity> hallyn: (This is all just trying to follow the logic through in my head, anyway)
<infinity> hallyn: Ultimately, I think the answer here is that mv_conffile can't quite do this right.
<hallyn> infinity: it handles 'apt-get dist-upgrade' with modified confile right.  but the link suggests that 'apt-get install bpkg' might not work - testing now
<infinity> hallyn: It handles the first upgrade right, or so you think.
<hallyn> xnox: infinity: actually apg-et install bpkg worked too.
<infinity> hallyn: My bet it that the NEXT upgrade of bpkg will get confused.  But maybe not, if apkg.conf and bpkg.conf were identical in the original packaging (were they?)
<hallyn> infinity: no they were not,
<hallyn> and i changed them locally,
<hallyn> and dpkg -S bpkg.conf shows owned by bpkg now
<infinity> Yeah, but it's a modified conffile by default now.
<hallyn> apt-get install --reinstall bpkg still works
<infinity> If apkg.conf and bpkg.conf aren't the same.
<hallyn> hm
<hallyn> good point
<infinity> So, the next time you change bpkg.conf, people who never modified apkg.conf will get a prompt.
<infinity> And they shouldn't.
<hallyn> now, in the case i care about,
<hallyn> which is qemu, they will be identical :)
<hallyn> are you sure?  what does it compare against?
<infinity> It compares the dpkg database to the file on disk.
<hallyn> note i am note getting a prompt at all.  not sure if i'm doing something funky
<infinity> If they don't match, you get prompts.
<hallyn> ok, not the dpkg-preinst or somesuch?
<infinity> You won't get prompts on the moves.
<infinity> I meant the next upgrade that changes the conffile.
<hallyn> oh
<hallyn> i see
<infinity> But, if they're the same in old and new packages, that's not going to be a problem.
<hallyn> infinity: which means it's worth making sure they're identical
<infinity> Yes.
<infinity> If they're not identical, this really won't work.
<hallyn> problem: does this mean they have to be identicl for a whole LTS cycle?
<infinity> For the move to work without later prompting, yeah.
<infinity> Now, there are clever ways around that.
<infinity> But mv_conffile won't do them for you.
<infinity> You can work up a hash of every packages version of the old conffile.
<infinity> And on upgrade to the new package (in preinst), check if their current one matches one of those hashes.
<infinity> If so, delete it outright, and let dpkg create the new one as it was going to.
<infinity> If it doesn't match, move it to a temp file, then copy it to the new location in postinst.
<hallyn> given that these are actually upstart jobs, i wonder if i'm better off having qemu-system.conf gracefully do nothing (and be commented) if qemu-kvm.conf exists
<infinity> These are some of the same steps mv_conffile takes, but with the addition of maintaining history.
<infinity> hallyn: If you read the manpage and understand what mv_conffile is trying to achieve, homebrewing it with the addition of the sums checks will make the moving between packages thing work, even if you have several potential pristine files to move from.
<cjwatson> Wait, are you actually changing the file name, or just moving it from one package to another?
<infinity> cjwatson: filename and package move, in one shot.
<cjwatson> If you can get away with not changing the filename, I think Replaces is enough these days
<infinity> cjwatson: So neither replaces nor mv_conffile is a fit.
<hallyn> uh.  well.  but maybe i don't need to
<infinity> hallyn: But yes, Colin has a point, Replaces will take over conffiles if you don't rename them.
<infinity> hallyn: And if the name offends you in two years, you can mv_conffile it then. :P
<hallyn> then i'll just keep it as qemu-kvm.conf!  thanks
<hallyn> but if i have several pkgs doing Replaces: qemu-kvm, will it know to use the one which ships that file?
<infinity> Yes.
<infinity> Replaces just means "if there's an overlap, this one wins".
<hallyn> cool, thanks.  so taht issue is solved :)
<hallyn> leaving only the original problem
<infinity> This is a problem if more than two packages provide a file and have replaces, but. Uhm.  Don't do that.
<hallyn> infinity: the upgrades still aren't working.  but when i mimick the situation with dummy pkgs it seems to work
<infinity> hallyn: Curious.  Is this all in the PPA again?
<hallyn> it seems like 'apt-get dist-upgrade' is saying "qemu-kvm depends on qemu-system which recommends qemu-utils",
<infinity> Right, which is correct...
<hallyn> "and qemu-utils breaks qemu-kvm so let me uninstall that,  now i don't need qemu-sytem any more"
<hallyn> or something
<infinity> That shouldn't happen if all the versions are sane now.
<hallyn> infinity: yeah, in ppa - right now it's got a broken mv_confile line, but you don't get that far with 'apt-get dist-upgrade' so i gues that's ok
<hallyn> they're all in same source pkg
<infinity> Let me have a look after I go abuse my lungs.
<hallyn> :)
<infinity> hallyn: qemu-common has gone away completely, right?
<hallyn> infinity: yes
<infinity> hallyn: So, I have a theory I'm testing here.  But while I'm on that.  Why did you remove the versioned dep on qemu-system?
<hallyn> infinity: at soren's suggestion, in case apt is doing something funky with the extra constraint
<infinity> No, pretty sure that's not the issue.  But gimme a few minutes here.  This silly thing takes a while to build.
 * infinity kills firefox and reclaims half his laptop.
<kees> jdstrand: libseccomp> yeah, nothing is passing NEW in debian because they're stuck in freeze. *roll eyes*
<hallyn> infinity: yeah that's why i took jamespage's advice and tried to reproduce with dummy pkgs
<tseliot> seb128: it's all merged and uploaded
<seb128> tseliot, thanks a lot!
<hallyn> but i'm clearly missing some aspect of it in my dummy versions
<hallyn> now i'm not accounting for qemu-keymaps in my dummies, maybe it changes something
<infinity> hallyn: I'm almost positive I know what the issue is, as I've seen it before.  dist-upgrade is outsmarting you here in an attempt to not break your system.
<infinity> hallyn: If you can gimme a $while to test this theory, I'll get back to you.
<hallyn> infinity: awesome, thanks
 * hallyn loves software smarter than myself
<infinity> You'll note, though, that "apt-get install qemu-kvm qemu-system" works fine.  Pretty sure dist-upgrade's just unwilling to remove common, and that's a solvable problem.
<hallyn> huh
<infinity> One I'd have solved by now if this didn't take SO LONG to build.  Wow.
<infinity> I swear I'm just seeing the same files over and over again in the build log here.  Does it build N flavours or something?
<infinity> Or maybe everything's just very similar looking.
<hallyn> infinity: it does build a whoel slew of targets
<hallyn> infinity: tried to reproduce the qemu-commnon bit, didn't reproduce the problem (bu ti probably did it wrong)
<infinity> hallyn: Also, why does qemu-system Break and Replace itself? :P
 * infinity fixes that while he's in here.
<hallyn> infinity: oops, yeah that's mine, not from original debian.
<slangasek> hallyn: I'm not *sure* it's doable either, but I think it *should* work :)
<jdstrand> kees: hrmm, that is a bummer. I figured it could go to unstable or experimental
<jdstrand> kees: fyi, you might be interested in the conditional ack of bug #1082431
<ubottu> Launchpad bug 1082431 in libseccomp (Ubuntu) "[MIR] libseccomp" [Undecided,In progress] https://launchpad.net/bugs/1082431
<jdstrand> kees: that says, doesn't sound like it can get into Ubuntu until lxc is fixed
<jdstrand> s/says/said/
<jdstrand> kees: and hi! :)
<jamespage> ScottK, that FTBFS is due to that specific method call being remove in jgoodies >= 1.5.0
<arges> seb128, hi
<seb128> stgraber, is there any chance you could review/get off the list the edubuntu misc:Depends item in the queue?
<seb128> arges, hey
<arges> seb128, regarding bug 943502, I have a branch linked for the oneiric  sru
<ubottu> Launchpad bug 943502 in whois (Ubuntu Oneiric) "whois doesn't properly query .hr/.sx/.pe TLDs and incorrect format for whois.arin.net" [Medium,In progress] https://launchpad.net/bugs/943502
<seb128> arges, so you want that branch to be sponsored? the bug is confusing, it has a bunch of debdiff and no clear summary
<arges> seb128, yea I apologize that bug has gone back and forth between being a backport and an SRU. It seems that an SRU is the correct direction now.
<arges> so the latest branch should be the right one. I can make a debdiff
<seb128> arges, ok, I will just sponsor that branch and let the SRU team decide on the SRU validity
<arges> seb128, sounds good thanks
<seb128> arges, btw you want to target -proposed for srus, not the stable serie (which is closed for uploads)
<arges> seb128, ok should i fix my branch? or will you change that
<seb128> arges, I'm fixing it, it's just a fyi for next time
<arges> seb128, cool i'l write it down : ) thanks
<seb128> arges, the version number, also it's better to append .1 that to increment ... e.g 0ubuntu3 -> 0ubuntu3.1 and not 0ubuntu4, since the next number is often already used in a new serie of Ubuntu and can't be reused
<arges> ok i just did ' dch -i '
<Quintasan> persia: ping
<seb128> mdeslaur, hey, you might want to sponsor https://code.launchpad.net/~nobuto/ubuntu/raring/ecryptfs-utils/record-passphrase-dialogue-translatable/+merge/133860 ... the contributor added the changelog you asked for and you seemed happy with the other changes?
<seb128> jodh, hey, is the debdiff on https://bugs.launchpad.net/ubuntu/+source/runit/+bug/245728 maybe something you would feel like reviewing when you have some time next week? it's an upstart job patch and in the sponsoring queue for a while
<ubottu> Launchpad bug 245728 in runit (Ubuntu) "runit doesn't stop and /var isn't umounted on shutdown" [Medium,Confirmed]
<stgraber> seb128: yeah, I'll have a look. When I first saw the MP my thought was that it was somewhere between useless and inappropriate as those are meta packages, but I need to have a closer look to be sure.
<seb128> stgraber, well, feel free to reject it, it seems wrongly targetted anyway since the packages are autogenerated so it's not the right vcs to change
<seb128> stgraber, it would just be good to get it out of the sponsoring queue since it has been there for several weels
<seb128> stgraber, thanks
<infinity> seb128: Targetting the stable series instead of -proposed is fine now.
<infinity> seb128: It rewrites the same way it does for the dev series.
<infinity> arges: ^
<seb128> infinity, oh ok
<arges> infinity, ack
<seb128> that explains why I saw a SRU from ev which was targetting the stable serie and went in ... I though he had tweaked the .changes or something
<infinity> seb128: I used to always do that and tweak .changes, but yeah, on tweaking required now.
<seb128> infinity, good to know, thanks
<infinity> I figure if we socialize this hard enough, we may stop seeing -proposed in changelogs by, oh, say, 2015.
<arges> seb128, and thanks for the uploads btw  : )
<seb128> arges, yw
<seb128> infinity, lol, announcing that it's possible on u-d or u-d-a would be a first step for sure ;-)
<infinity> It may have come up in Colin's mail about the whole proposed-migration thing, but if it did, it would have been a bit of an aside.
<infinity> But it doesn't bug me if people discover this on their own, either.  It's not "wrong" to have series-proposed in your changelog, after all.
<infinity> I just find it slightly prettier not to both, cause the archive DTRT.
<infinity> s/both/bother/
<mdeslaur> seb128: ok, thanks
<hallyn> jdstrand: kees: where is the new package source for new libseccomp?
<jdstrand> hallyn: http://ftp-master.debian.org/new.html has 1.0.0-1
<jdstrand> I imagine that is good enough for the lxc work, but 1.0.1 is available upstream
<infinity> I suspect the uupdate from 1.0.0 to 1.0.1 would be clean and trouble-free.
<infinity> Of course, the part where one can't download from the NEW queue makes it problematic to play around.
<jdstrand> hallyn: (to get the package itself, go to http://ftp-master.debian.org/new/)
<infinity> Unless kees still has the sources somewhere.
<jdstrand> oh wait
<jdstrand> that's right
<jdstrand> hmm
<jdstrand> hallyn: please disregard the parenthetical :)
<infinity> kees: You haz seccomp upload on a hard drive somewhere?
<infinity> kees: (Also, that NEW may have gone a bit quicker if it was to experimental, where people are concerned about ABI transitions in the middle of freezes)
<infinity> s/are/aren't/
<infinity> hallyn: So, I couldn't actually find a magical combination of Replace/Break/Conflict/etc that would make apt happily remove -common from the system, and I settled on this (which works):
<infinity> hallyn: http://paste.ubuntu.com/1417371/
<micahg> infinity: even if apt was happy, update-manager wouldn't be, so your solution is best
<infinity> micahg: Yeah, this is definitely the safest solution in the face of all possible resolver confusions.
<hallyn> infinity: thanks, i still don't understand why i can't reproduce it with a set of empty packages with teh same relations, which suggests id on't actually fully understand hwo qemu-common and qemu-keymaps are doing it, but that's not to say I don't beleive you :)
<infinity> hallyn: The problem is that to successfully complete the upgrade, -common needs to go away or be upgraded.  The latter is something apt is happy to do, the former is something it ends up in a tizzy about because of the interdependencies of the previous versions.  This corner case may arguably be a resolver bug (as it does handle removals in more simple cases), but the workaround it much safer anyway, and will work for all resolvers.
<infinity> s/it much/is much/
<hallyn> infinity: i wonder if my tests failed because my qemu-common dummy pkg was empty...
<hallyn> and apt was smart enough to say "ok then delete it"
<hallyn> infinity: thanks, pushed to ppa.  hopefully this all works and i can send out final call for testing!
<kees> infinity: yeah, on my disk. I can upload 1.0.1 to experimental, sure.
<kees> jdstrand: what would be best for lxc? you want me to upload to ubuntu too?
<infinity> kees: Just giving hallyn and stgraber the sources so they can play might be good, rather than uploading and forcing a transition.
<infinity> kees: But yeah, uploading 1.0.1 to experimental, and asking ftpmaster to remove 1.0.0 from the unstable queue may go well for you.
<infinity> (Unless you really have reasons to want it in wheezy)
<kees> it's already been removed from testing. :P
<infinity> Oh, so not much harm in it getting into sid.  Fair enough.  I hadn't checked.
<kees> that's why I'm so confused about why it's not in unstable. why can't they just deNEW it?
<infinity> Perhaps someone dislikes you personally. :P
<infinity> Given your history with kernel patches, that could be a few someones. :)
<kees> haha
<infinity> It's one of the only old ones in the queue, which is curious.
<infinity> Maybe you dropped an email on the floor with feedback?
<kees> maybe
<kees> I'll go review the bugs
<hallyn> kees: thanks, i'll look in experimental for it in awhile
<infinity> kees: Or just hunt down a friendly ftpmaster for a realtime WTF.
<infinity> kees: But given it's been removed from testing, 1.0.1 to unstable makes perfect sense, no need to go experimental.
<infinity> kees: I assumed (incorrectly) that there might actually be an older version in testing/unstable that you didn't want to force a transition on.
<kees> infinity: yeah, nothing was using it yet, so that's why I did the 1.0.0 upload and asked for the bump into testing, but they opted for the other direction, which is fine.
 * infinity raises an eyebrow at kees.
<kees> dude was reconnect storming last week.
<slangasek> autopasting the works of Cervantes to the channel upon connect will have that effect
<kees> infinity: so... with 1.0.0 in NEW, should I upload 1.0.1 and merge the changelog like 1.0.0 never happened?
<kees> slangasek: hahah
<infinity> kees: You could do that, or just add a new changelog entry for 1.0.1 and -v the .changes
<stokachu> stgraber: does pastebinit use debian's xmlrpc interface?
<stokachu> paste.debian.net
<stgraber> stokachu: no, it uses the form
<stokachu> thats what i figured
<stokachu> http://paste.debian.net/paste.pl?show_template=clients
<stokachu> says its xmlrpc
<stgraber> it'll be at some point ;) the paste.debian.net maintainer has been complaining about it for a while now
<stokachu> thats cool i was just looking at some of the bugs on lp for the app
<stokachu> and came across 1055522
<kees> infinity: cool, yeah, I wasn't sure if debian DTRT for that or not. I only ever learned that for LP :)
<kees> infinity: just to double-check, but "i386" means "linux-i386" not "any-i386", right?
<infinity> kees: Right.  i386 refers to the dpkg arch.
<infinity> kees: (As is true of any bare arch words)
<infinity> kees: Oh, is hardening-wrapper still your baby?  If so, it's probably about time it learn about gcc-4.8
<kees> yeah, I'd like to start getting people to move off it now that dpkg-buildflags is mostly sensible.
<infinity> Can't disagree there.  I just saw it's diversion madness scroll by in a build log, which is why I thought of it.
<kees> is 4.8 in raring already?
<infinity> No, but doko has a PPA, and an upload to experimental.
<kees> righto
<slangasek> hrm, how did xserver-xorg-dev-lts-quantal land in universe
<hallyn> infinity: mostly seemed to work only one issue - /etc/init/qemu-kvm.conf is still owned by qemu-kvm <shrug>.  oh, maybe i need to call it qemu-system.qemu-kvm.upstart.
<infinity> hallyn: If it's not actually being installed by the new package...
<hallyn> infinity: debian/rules had dh_installinit -pqemu-system --name qemu-kvm
<hallyn> i figured that would be enough
<hallyn> (it was enough in the dummy tests)
<infinity> I haz no idea what magic dh employs there.
<infinity> And I'd look at my local packages, but I baleeted them all.
<hallyn> i'm going to have to play with that tonight
<hallyn> infinity: thanks very much!
<slangasek> hallyn: pointer to the debian/ directory you're using?
<hallyn> slangasek: https://launchpad.net/~serge-hallyn/+archive/crossc/+files/qemu_1.2.0.dfsg-4.dsc
<hallyn> i'm pretty confident that renaming the file will work...
<hallyn> confident enough to leave for a walk and come back later :)
<kees> hallyn: I uploaded it to unstable, hopefully it'll deNEX
<kees> W
<hallyn> kees: thx.  i'll have to look at this later this weekend or monday
 * hallyn bbl tonight
<ScottK> jamespage: Can you see what needs to be done to fix it?
<cjwatson> hallyn: yeah, you don't want to use completely empty packages for testing - you might trigger dpkg's "disappeared" state which will change things around.  a trivial doc dir with changelog/copyright should be enough to avoid that
<cjwatson> slangasek: Cervantes> I should totally do that some day.  In Latin
<slangasek> cjwatson: Cervantes in Latin?  Heresy!
<slangasek> hallyn: so yes, you need to name the file debian/qemu-system.qemu-kvm.upstart for this to work
<slangasek> hallyn: you decided not to rename the upstart job?
<cjwatson> slangasek: well, y'know, I can't read Spanish so that would be *silly*
<infinity> slangasek: Not renaming it avoided a lot of potential hassle.
<jamespage> ScottK, I think so
<ScottK> jamespage: Excellent.
<slangasek> infinity: yep, clearly avoids hassle, I just missed the memo that the goal had changed
<jamespage> ScottK, fix uploaded to raring
 * jamespage feels dirty as he had to patch IDE generated code
<israeldahl_> HELP!!!  software-center doesn't find  a program, but apt-get does!!  what file is missing (the desktop file is present)
<israeldahl_> what files does the software-center look at to display a program??  I am at a loss
<israeldahl_> I was assured that the desktop file is the key componant for the software center
<israeldahl_> this is not the case
<israeldahl_> Anyone have any clue???
<sladen> israeldahl_: what is the example search search and the program that is found/not found?
<sladen> israeldahl_: what is the example search string and the program that is found/not found?
<israeldahl_> in raring ringtail lmms.
<israeldahl_> lmms the program is NOT EVEN FOUND!
<freedomrun> is there a way to enable minimise on click function in ubuntu 12.10 Unity??!
<israeldahl_> sladen: I merged a new version into raring... however now software center cannot see it.
<sladen> israeldahl_: so the package is 'lmms'.  Exactly what "apt-get search ..." string are you typing, and exactly what search are you typing in Software Centre?
<israeldahl_> sladen: in USC I type "lmms"  and for apt-get I type "sudo apt-get install lmms"
<israeldahl_> sladen:  the package doesn't exist in the USC.
<xnox> israeldahl_: desktop file data needs a refresh & reupload after that it will appear in USC.
<xnox> israeldahl_: an easy way to check for this mismatch is by install lmms & then trying to look it up in the USC. Does it appear then?
<israeldahl_> xnox: what do you mean?  it was freshly merged in.  the version I merged in is 0.4.13  the one in quantal and precise is 0.4.10
<israeldahl_> xnox: no I tried that
<xnox> israeldahl_: package in the archive and package appearing in USC is not an instant transition.
<israeldahl_> xnox: so it may just be a delay??
<xnox> give me a second to look at the package.
<israeldahl_> xnox: OK... it is for RARING, not the LTS or quantal
<xnox> israeldahl_: yes, i know.
<israeldahl_> xnox: OK.. sorry I just wanted to be absolutely sure
<xnox> israeldahl_: dpkg-deb -c lmms_0.4.13-0ubuntu1_amd64.deb | grep desktop returns nothing.
<israeldahl_> xnox: well how does it install the desktop file?  I know the desktop file was in the source?
<xnox> israeldahl_: the desktop file is in the lmms-common package, which is incorrect. It should be together with the executable it points to.
<xnox> israeldahl_: and then there is propagation delay to refresh USC data. (which I am not sure how long it is).
<israeldahl_> OH... so the lmms.install file should have the pointer, not lmms-common.install! :)
<israeldahl_> xnox:: does that seem right?
<xnox> israeldahl_: yes.
 * xnox needs to make sure USC is documented somewhere.
<israeldahl_> xnox: I feel really quite silly.... ok, can I just recommit it back into my bzr branch and it will send the fix to the merge???
<israeldahl_> xnox: yes.. USC documentation would be awesome (as well as changelog formatting)
<xnox> israeldahl_: please push a branch & make a new merge proposal (that way it will end up in the sponsorship queue for sponsors to re-upload)
<israeldahl_> xnox: So, I have to go through the same thing again?  Can I just use the same branch?
<xnox> israeldahl_: what do you mean by changelog formatting?
<xnox> israeldahl_: yes you can use the same branch, but open a new merge proposal, if the previous one is already completed (status = "merged")
<israeldahl_> xnox: Oh...  the "dch -i" then I have to use minus signs and only so many characters per line, and other stuff
<israeldahl_> xnox: it is merged... I will do this right now
<xnox> israeldahl_: the changelog formatting is documented here http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog and there is a general sense of "style" but inherently it's not structured.
<israeldahl_> xnox: Ok, well I was told to format my changelog entry differently than I had... I differently than I had.
<xnox> israeldahl_: can you point me to the comment?
<xnox> israeldahl_: generally a tool lintian can tell me many small things about changelog & etc. Run $ lintian -i -I -E --pedantic -v lmms*.dsc
<xnox> israeldahl_: you can also run against lintian against lmms*.changes file.
<israeldahl_> xnox: well someone changed the way I had it.  I used TAB instead of spacing (python) and I used + instead of  -
<israeldahl_> xnox: OK... I am running that now... I noticed lintian warnings when I used pbuilder
<israeldahl_> xnox: where do I run that command from?
<israeldahl_> xnox: oh wait
<israeldahl_> xnox: http://ubuntuone.com/3kwVRUIm2CTjEI8P0ouKOd
<ScottK> jamespage: Thanks.
<israeldahl_> xnox: that is the lintian.  I just finished proposing the merger... the warnings seemed light enough
<xnox> israeldahl_: the ones that are W: are important enough to fix.
<xnox> israeldahl_: ideally you should fix all of them.
<israeldahl_> xnox: Yeah... well this is my first time of doing anything like this.
<xnox> israeldahl_: =) I'm trying to nudge you to improve your skills =)))) for upload after this one, ok ? ;-)
<israeldahl_> xnox: yeah sure!!  the next version 0.4.14 is coming out next.. and I will try to fix it for that merger,
<israeldahl_> xnox: if they can wait?
<israeldahl_> xnox: does lmms-common.install still need /usr/share/applications as well as lmms.install?
<darkxst> Sarvatt, whenever you get a chance can you review/merge these https://code.launchpad.net/~darkxst/ppa-purge/bash-completion  https://code.launchpad.net/~darkxst/ppa-purge/lp706774
<achiang> jtaylor: hi, still around?
<jtaylor> achiang: yes?
<achiang> jtaylor: hey, i'm looking to make a patch for valgrind for the R cycle, recommendations on how to proceed? the patch i want landed in upstream valgrind trunk this week. debian is still in a freeze so i'm thinking just make a debdiff against most recent valgrind in raring (which is still the Q) version and subscribe u-sponsors to bug?
<jtaylor> I'd prefer to get the debian exp version of valgrind in raring
<jtaylor> what kind of patch?
<achiang> https://bugs.kde.org/show_bug.cgi?id=310792
<ubottu> KDE bug 310792 in general "[PATCH v2] search additional path for debug symbols" [Normal,Resolved: fixed]
<achiang> jtaylor: this will be extremely helpful for our "ubuntu pilates" effort centered around the nexus 7
<jtaylor> achiang: I'm no coredev so I have no rights to valgrind, but I'm sure they'd appreciate if you could get the patch in via debian
<jtaylor> it should be no problem to add it when we merge though
 * achiang groans to self...
<achiang> i guess i've never worked with the valgrind maintainer in debian. maybe that person is fast :)
<jtaylor> he is very fast in uploading new versions
<infinity> jtaylor: I don't see a valgrind in experimental...
<jtaylor> oh unstable even
<infinity> Oh indeed, we seem to be a bit behind.
<infinity> I should bug that Julian Taylor guy, he's TIL.
#ubuntu-devel 2012-12-08
<jtaylor> ._.
<achiang> nod. looking at changelog in ubuntu, last time we sync'ed was precise
<infinity> jtaylor: Did you just want it synced wholesale, or do we have a delta you want to merge/preserve?
<jtaylor> I didn't look at it yet
<jtaylor> I only fixed two bugs for quantal, I have no history in the package
<achiang> perhaps i could persuade janimo to do so, he's made a few uploads...
<achiang> s/a few/one/
<infinity> achiang: You could possibly talk me into it.
<infinity> achiang: But it won't be this evening.
<jtaylor> if you do, I'd also like a backport to precise ;)
<infinity> achiang: Want to give me a URL to the svn commit of the bit you're interested in, rather than the bug with your patch?
<achiang> infinity: yes, you've been a good robot and you need to power down for a few hours while we change your oil
<achiang> infinity: let me check what is in unstable. my patch touched an internal API that changed between our version in Q and what is in svn head (or trunk or whatever they call it)
<achiang> infinity: so i have 2 patches, one that works w/ubuntu and the one that landed upstream
<infinity> Unstable is 3.8.1
<achiang> (just trying to save you some time)
<infinity> achiang: dget http://http.debian.net/debian/pool/main/v/valgrind/valgrind_3.8.1-1.dsc
<achiang> thanks, that's handy
<infinity> ('pull-debian-source valgrind' would do the trick too, I'm still trying to train my fingers to do that)
<ScottK> So.  I have this bzr branch that I've pushed to LP.  How to I make a merge request out of it?
<infinity> ScottK: Wherezit?
<ScottK> https://code.launchpad.net/~kitterman/+junk/ubiquity-encryptcheckbox
<infinity> ScottK: You need to use predictable namespacing to make it work.  No junk.
<ScottK> Sigh.
<ScottK> OK.
<infinity> ScottK: bzr push lp:~kitterman/ubiquity/my-fix
<ScottK> OK.
<infinity> I believe.
<achiang> infinity: ok, unstable has the new API, so the version from svn should Just Apply(tm).
<infinity> I never use this feature. :P
 * ScottK tries.
<infinity> ScottK: If the namespace matches, then you magically get LP sorting out ancestry and offering you the MP option.
<ScottK> Right.  It made a stacking branch this time, so I think it got it.
<ScottK> Thanks.
<infinity> achiang: Shiny.  URL me up, I'll drag it out of backcroll.  Food time.
 * achiang attempts to find a url to valgrind's svn
<xnox> ScottK: do i have something to review and merge =))))?!
<infinity> achiang: A pointer to the repo and revision number works too, doesn't need to be a silly web view. :P
<achiang> infinity: oh, heh. ok. sorry, "URL" confused me. ;)
<ScottK> Depends on if you want to make sure I didn't screw up a Qt .ui file change.
<achiang> infinity: email ok or irc preferred?
<ScottK> xnox: You should have mail.
 * xnox waits for launchpad to generate review diff and finally send mail
<ScottK> The .ui file presented correctly in Qt Designer, so I imagine it's correct ....
<xnox> ScottK: i'm not entirely familiar with qt format. But I do wonder if this option is displayed correctly in either gtk & kde with a Right-To-Left locale.
<ScottK> Good question.
<ScottK> Would you leave a comment in the merge proposal.
<ScottK> Perhaps Riddell will know (I marked him down as reviewer since it's Qt .ui stuff)
<xnox> ScottK: if it doesn't work I open a new bug.
<xnox> ScottK: I have been told many times RTL "just works" but I'm not conviced.
<slangasek> marrusl: ping
<marrusl> slangasek, hey.
<slangasek> marrusl: hi - did you see my follow-up questions on gdbM?
<slangasek> gdb
<slangasek> IWFM
<marrusl> slangasek, yes.  thank you kindly.  just haven't had a chance to catch up with it.
<marrusl> :)
<slangasek> ok cool
<slangasek> just making sure you'd seen
<slangasek> from my POV, we should be able to consider the SRU verified
<marrusl> slangasek, I won't argue with that.  I have a feeling I know what I'm missing.  but I need to go back.
<marrusl> technically, well, I take your word for it!
<stokachu> slangasek: i think we should mark that gdb one verified as it fulfills what the actual issue is being reported
<slangasek> stokachu: yep, done
<stokachu> cool man, thanks!
<hallyn> slangasek: no, i did rename the upstart job.  in .dfsg.5.
<hallyn> ah, and seems to be right now.  at least it's shipped with qemu-system.*.deb.
<puff> Evening, I'm looking for the proper channel to discuss something odd that happened when I upgraded from 11.10 to 12.4, to see if I should file a bug report.
<slangasek> jelmer: fyi your samba4 sru .changes looks like it was generated on Debian and is missing the bug closure field; also, the setoption conversion from perl to python doesn't look like an SRU-appropriate minimal change.  I'm rejecting the package from the queue; if there's a reason setoption needs to be converted to python instead of just adding a dep on perl-modules, please document this in the appropriate bug report, and in either case pl
<slangasek> ... with a correct .changes
<mitya57> Is there a way to generate correct .changes on Debian?
<slangasek> mitya57: set DEB_VENDOR
<mitya57> thanks slangasek
<Monotoko> is there any particular reason that the amazon search isn't run through HTTPS?
<mlankhorst> slangasek: yay, just need to figure out how two make mesa -dev packages coexist now and xorg package approval and then it should just be maintenance:)
* bdrung 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 dicussion 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:
<vibhav> If a new version of a package in Debian ONLY introduces a Ubuntu change is merging it useless
<vibhav> ?
<israeldahl> xnox: are you around?  I wondered if you had any links to fixing those lintian warnings
<vibhav> xnox: Do you mean https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative
<vibhav> We have some lintian warnings there
<israeldahl> vibhav: xnox was helping me yesterday and noticed the program had some lintian warnings that needed fixed, so now I want to fix them since I have to re-merge the code anyway
<israeldahl> vibhav: do you know much about lintian warnings?
<ubuntu-tester> Hi people, is there special channel for Unity dev?
<ubuntu-tester> or where can I reach Unity team?
<ubuntu-tester> found it, sorry for bothering
<israeldahl> ubuntu-tester: no bother
<ScottK> jamespage: Thanks again for fixing sikuli.  There is an armhf specific FTBFS for sivp that also looks Java'ish.  Could you have a look at that as well?  That's the last blocker for the opencv transition.
<OdyX> tkamppeter_: would it be possible to have the printers supported by splix be shown in the Openprinting database ?)
<slangasek> mlankhorst: nice!  (well, at least until 6 months from now when we have to do the same thing for the raring stack ;)
<mlankhorst> why do you think I used a script :p
<mlankhorst> no way I'm going to keep track of all the changes by hand!
 * ScottK wonders how many gcc uploads there will be this weekend to ensure powerpc never catches up ...
<kees> i want syncpackage to work without gnome-keyring
<SpamapS> kees: s/syncpackage/launchpadlib/
<SpamapS> kees: actually if there's no gnome keyring it will use the more generic keyring thing
<SpamapS> kees: but yeah, its annoying when it finds a gnome keyring but cannot use it because you're actually just ssh'd in
<ricotz> hallyn, hi, maybe you are familiar with that problem http://paste.debian.net/plain/215121 -- this is raring armhf ppa builder failing, always on setting up libgtk-3-0
<israeldahl> dpkg-source: error: add data/themes/default/icon.png in debian/source/include-binaries if you want to store the modified binary in the debian tarball      anyone know what include-binaries is?
<israeldahl> do I have to tar up the source and use that or use a commit?  anyone know where i need to go?
<ScottK> israeldahl: Start with man dpkg-source.  Look in the section on format version 3.
<israeldahl> ScottK: thanks but what or where is debian/source/include-binaries
<ScottK> It would be in the debian directory of the source package.  You may have to create it.
<israeldahl> ScottK: Thanks is it a text file that I put file paths into or a directory?  The only thing there is format
<israeldahl> I don't mean txt file, sorry... I just mean a file with txt in it
<ScottK> include-binaries is a vile
<ScottK> file
<israeldahl> ScottK: OK, thank you and I just put a path like data/themes/default/icon.png i suppose
<ScottK> IIRC, yes.
<israeldahl> Thank you immensely!!
<israeldahl> ScottK: it worked to get me past the error!  I appreciate your help very much!
<ScottK> You're welcome.
<hallyn> ricotz: sorry, no.
<ricotz> hallyn, i see, since the version the builders are running is older than the current raring one, maybe this is something which got fixed, and i am hoping you can pass that into the right direction
<hallyn> ricotz: any chance you could file a bug on that?
<hallyn> ricotz: was that an update on an arm box?  an error during a pkg build on builder?
<hallyn> multilib pkg upgrade on x86?
 * hallyn bbl
<ricotz> hallyn, this is building on an official armhf ppa builder
<hallyn> ricotz: yikes.  can you paste a link to the full build log on launchpad here?  i'm not sure who supports the arm builders  (stgraber or infinity?)
<cjwatson> hallyn: infinity deals with the chroots
<stgraber> hallyn: so, my understanding of the armhf PPA builders is that those are essentially armhf chroots running on a x86 precise host or maybe even a precise VM on top of a hardy xen server (like the other PPA builders)
<hallyn> ah
<stgraber> hallyn: those are pretty different from the distro builders and non-virt PPA that build directly on pandaboards and so don't use any of the crazy qemu-user-static magic
<cjwatson> and yes, the armhf PPA builders are emulated
<cjwatson> the virtualised ones I mean
<stgraber> so it may be that qemu-user-static can be updated in the armhf chroot which may or may not fix the issue, infinity should be able to help with that. If it's a problem with the qemu outside of the chroot, then I guess you'd need to talk to IS
<stgraber> in any case, it should be easy to check whether the failure happens with a recent qemu, just create an armhf chroot or container on raring and do the build in there, if it passes, then there's hope that updating the qemu on the builders will fix it, if not, well, that'd be a qemu bug I guess
<hallyn> would still be worth first seeing the source pkg which caused this so we can try and reproduce it - though i guess if IS runs the hosts it'll be hit-or-miss on reproducing it anyway
<hallyn> ricotz: ^ worth trying as stgraber said
<hallyn> probably using a lxc-armhf container on raring :)
<stgraber> yeah, lxc-armhf is probably the easier, install lxc and qemu-user-static, then just do: lxc-create -t ubuntu -n builder -- --arch armhf --release raring
<ricotz> hallyn, stgraber, i have checked with a raring pbuilder chroot which worked fine here
<ricotz> hallyn, and sorry, i canceled the failing builds to free the builders since they didnt stop itself (also not after 2 hours)
<ricotz> so no log
#ubuntu-devel 2012-12-09
<kees> hallyn, jdstrand: libseccomp 1.0.1 now in debian unstable and raring
<slangasek> smoser: bug #978127> OOI, what's the reason to not handle this by having the ephemeral image run ntp?
<ubottu> Launchpad bug 978127 in cloud-init (Ubuntu Precise) "incorrect time on node causes failed oauth" [High,Triaged] https://launchpad.net/bugs/978127
<infinity> tjaalton: BTW, I'm still getting i915 GPU hangs.  But they're no longer triggering apport popups.  I'm not sure this is progress. :/
<lifeless> infinity: you're getting less apport errors, so the strategy is winning
<infinity> lifeless: *smirk*
<lifeless> :)
<lifeless> Cheap shot, I know.
<infinity> tjaalton: Readily reprodible (several times an hour) by watching The Walking Dead in mplayer.  I suspect it's the content that matters, turning my GPU into a zombie.
<lifeless> nice
<infinity> tjaalton: (It's also possible that my debugging skills and ability to tie cause to effect diminish slightly on weekends)
<infinity> tjaalton: In all seriousness, though, there could be a bit of cause and effect here, as I can go hours working in terminals/firefox/etc and usually not tickle the bug, but it's never more than 15 or 20 minutes of x264 playback in mplayer before my GPU has a sad.
<tjaalton> infinity: ok that's good to know, since I've been unable to make it hang myself (with normal "office" usage)
<tjaalton> infinity: also, are you able to reproduce bug 1086123
<ubottu> Launchpad bug 1086123 in linux (Ubuntu) "3x power consumption compared to quantal" [High,Incomplete] https://launchpad.net/bugs/1086123
<tjaalton> this after suspend/resume
<tjaalton> haven't bisected it yet
<infinity> tjaalton: Hrm.  I have no /sys/kernel/debug/dri ... Do I need to do something magical to get that?
<tjaalton> guess you should see it as root?
<infinity> tjaalton: (But I haven't noticed power consumption going up, I've been on AC since I got back from UDS)
<tjaalton> heh, ok
<infinity> (base)root@cthulhu:~# ls /sys/kernel/debug/
<infinity> (base)root@cthulhu:~#
<infinity> No such luck.
<infinity> Did just get another:
<infinity> [600472.021256] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
<tjaalton> debugfs is mounted here, dunno how to turn it on
<infinity> tjaalton: Since apport's now failing to pick these up, how do I get more debug info than that for you?
<tjaalton> infinity: "enable debugfs" would be the first step, but it's just working for me..
<tjaalton> so I'm not sure how to enable it
<tjaalton> i915_error_state would be there
<infinity> Oh, hrm.  Maybe something's gone sideways here.
<tjaalton> there were patches to make it root-only, but should still be available
<tjaalton> this happened for precise I think
<infinity> Yeah, there's an upstart job that makes sure it's read-only, but I can't find anything that's meant to actually mount it.
<infinity> Perhaps mountall does it.
<infinity> But clearly failed to.
<infinity> Anyhow, manually mounted for now.
<infinity> CAGF: 650MHz
<infinity> Mine doesn't seem to be spinning at 1300.
<infinity> I haven't rebooted into the -5- kernel yet, though.
<infinity> So, that might break it.
<infinity> Which would help your bisect.
<tjaalton> another thing would be to give 'drm.debug=0x0e' to the kernel and then reproduce the hang
<infinity> I'll have to give that a whirl when I'm not in the middle of being lazy at midnight. :P
<tjaalton> infinity: have you suspended it?
<tjaalton> sure
<infinity> It's been suspended dozens of times since the last cold boot, I'm sure.
<tjaalton> ok
<infinity> Also, your bug report says "only the discrete GPU is in use", did you mean the inverse?
<infinity> Or is your i915 spinning out of control despite you using the NVIDIA one?
<tjaalton> I'm not using hybrid
<tjaalton> oh
<tjaalton> duh
<tjaalton> fixed
<tjaalton> this is slightly better with the current kernel
<infinity> Oh, you're using -4.12- in that bug report too.  Same as me.
<infinity> Weeeeeird.
<infinity> Maybe we need to get our 420Ss to compare notes.
<infinity> Or go to some sort of reform boot camp together.
<tjaalton> hehe
<tjaalton> with -5 it's slightly better
<tjaalton> takes 22W, and 13W after fixing the stuck gpu
<tjaalton> but still 5-6W extra
<infinity> And every watt counts on this thing, with the teeny-tiny battery...
<infinity> Anyhow, debugfs manually mounted, back to my TV.  I look forward to more apport popups again. :/
<infinity> Maybe I'll reboot later.
<tjaalton> cool, thanks
<tjaalton> (i've got an extra battery mounted on the ultrabay ;)
<tjaalton> gives 2-3h extra
<infinity> tjaalton: Yeah, I've been considering that.  I'm miffed that their online custom ordering thing forces you to put a CD/DVD drive in the ultrabay, or I'd just order it with a battery straight up.
<infinity> (Who needs optical media anymore?)
<tjaalton> indeed..
<vibhav> People still use it here :(
<infinity> Alright, screw these hangs.  Rebooting.
<infinity> tjaalton: drm.debug=0x0e you say?
<infinity> tjaalton: What will that do?  Just more vomit in the ringbuffer?
<tjaalton> infinity: more vomit in kern.log
<infinity> tjaalton: That's what I said. :P
<infinity> Haha.  Speaking of ringbuffer vomit, since I remounted debugfs, apport-gpu-erro broke.  Nice.
<tjaalton> then when you get the hang, collect /sys/kernel/debug/dri/0/i915_error_state and attach to a bug (ubuntu-bug xorg, dmesg will be attached by it)
<infinity> http://paste.ubuntu.com/1420467/
<infinity> cat: /sys/kernel/debug/dri/0/i915_error_state: Cannot allocate memory
<tjaalton> huh
<infinity> My laptop is so confused right now.
<infinity> We'll see how it fares after a reboot.
<infinity> (base)adconrad@cthulhu:~$ ps ax | grep apport | wc -l
<infinity> 22
<infinity> Turns out this can bring a machine to its knees...
<jtaylor> infinity: you can sync cython from experimental
<jtaylor> the ubuntu diff is not needed anymore
<jtaylor> but did not test build it yet
<voldyman> guys i want to modify/write-from-scratch the lock screen. is there any documentation/reference?
<voldyman> anyone ? ^^^
<jtaylor> where can I see why a package does not migrate from proposed?
<cjwatson> jtaylor: http://people.canonical.com/~ubuntu-archive/proposed-migration/
<blami> is there some description of unity? I don't understand if it's just couple of things built around gnome 2 compiz thing or gnome 3 shell ...
<ScottK> blami: #ubuntu-desktop might be a better place to ask.
<blami> ScottK: aha, thanks
<Laney> More likely #ubuntu-unity ;)
<ScottK> Even better.
<jtaylor> bdrung: I attached a patch to 1088051 which fixes the fftw uninstallablilty
<jtaylor> seems to work fine in debian
#ubuntu-devel 2013-12-02
<pitti> Good morning
<dholbach> good morning
<ogra_> pitti, hmm, so i'm maintaining my cdimage branches on a precise desktop ... it uses python-mock ... and apparently uses tests that use the trusty python-mock, do you plan to SRU this ?
<ogra_> (so i can go on testing the branch on an LTS)
<pitti> ogra_: err, sorry, context/
<pitti> ?
<ogra_> http://paste.ubuntu.com/6508783/
<pitti> ogra_: i. e. SRU what?
<ogra_> thats what i get when running the self tests under precise
<ogra_> pitti, python-mock changes
<pitti> ogra_: so apparently python-mock 0.7 doesn't yet know this syntax
<ogra_> right, thats what i mean
<pitti> ogra_: if you want them to work under precise, I suggest you use the 0.7 API (which hopefully is forward compatible)?
<ogra_> do you plan to backport such stuff for people developing on the LTS
<pitti> ogra_: why me, specifically?
<pitti> also, we don't generally SRU new versions
<ogra_> isnt python-mock your child ?
<pitti> we can certainly ask for a backport
<pitti> ogra_: no, it's not; I guess you mean dbusmock :)
<ogra_> i know how to work around that, but was wondering about others that use LTS versions for developing tip branches of newer stuff
<pitti> ogra_: anyway, python-mock is fairly isolated, so we can build it as backport or put it into a PPA or something if needed
<rbasak> ogra_: I've hit the same issue, FWIW. But I didn't think that new features were SRU-able in this way. Annoyingly this means that I can't run tests as part of a package build for a precise target.
<ogra_> well, you can run them in a trusty chroot
<ogra_> just forces you to maintain two branches or to bind mount it into the chroot or some such
<pitti> or just change the tests to split the command into two, and set mymock.return_value explicitlY?
<rbasak> I can, but that's no good when the final target is the cloud archive on precise. Though we may be able to backport python-mock there; I'll have to check.
<pitti> (that syntax works with older p-mock)
<pitti> that seems like the least painful approach
<pitti> it's indeed nice to be able to run tests on precise to ensure that all deps are there, and the actual code doesn't use anything from newer pythons, etc.
<ogra_> it requires that upstreams have that self discipline though
<Saviq> rsalveti, ping
<rsalveti> Saviq: pong
<Saviq> rsalveti, hey man, I've a .crash with... a LOT of question marks
<Saviq> rsalveti, I'm starting to think it's crashing on android side - do you have any pointers on getting some useful data out of there?
<mitya57> cjwatson: Can you please check why wxwidgets3.0 still isn't getting auto-synced? The conflicting binary package has been dropped from wxwidgets2.8 in -proposed.
<rsalveti> Saviq: sure, https://wiki.ubuntu.com/Touch/Core/UbuntuDebugAndroid
<rsalveti> Saviq: easier if you have the android build locally, let me know if you don't, then I can provide the lib with debug symbols
<rsalveti> once you check it with maps
<Saviq> rsalveti, it's the first time I'm doing it, so no, I don't have anything
<rsalveti> Saviq: ok
<Saviq> rsalveti, it's unity8... it's going to have everything in its maps...
<Saviq> rsalveti, any way to reduce the scope?
<rsalveti> Saviq: but checking the stack trace, you should be able to find the first maps that brings the ???
<rsalveti> and the related library
<Saviq> rsalveti, here's the .crash, what should I be looking at? http://paste.ubuntu.com/6509647/
<rsalveti> let me check
<xnox> mitya57: i filed a bug about it. basically wx-common binaries need removal, and a sync forced.
<xnox> mitya57: cause at the moment wx-common binary has "ubuntuX" suffix version in -release pocket. And wxwidgets2.8 cannot migrate without new wx-common from 3.0, which can't be synced because of the first reason =)
<mitya57> I expected the autosyncer to look at -proposed
<xnox> mitya57: so someone with archive admin powers needs to stab it =) i hope infinity or cjwatson will get around to doing it.
<rsalveti> Saviq: the stack seems to be in the ubuntu side, maybe opening the core dump with gdb to check
<mitya57> xnox: OK
<ogra_> Saviq, we got a new glib exactly that day the install is from
<xnox> mitya57: well it can't, because -proposed is an overlay (e.g. there is no way to tell between wx-common binary dropped in -proposed, vs wx-common is at *ubuntuX version at the moment)
<ogra_> well, not exactly ... but its definitely using the new one there
<xnox> mitya57: -proposed & -release are merged and then compared.
<xnox> mitya57: from archive point of view there "wx-common is fully migrated to release pocket" =)
<mitya57> Right.
<Saviq> ogra_, shall I try in the previous image then?
<ogra_> well, might make sense to do some comparison
<ogra_> Saviq, http://people.canonical.com/~ogra/touch-image-stats/20131129.2.changes
<Saviq> ogra_, will do, thanks
<ogra_> thats the respective change set
<Saviq> rsalveti, yeah, there's just no more symbols I can think to install to get anything - it's all ??s
<Saviq> rsalveti, in gdb, too
<rsalveti> Saviq: have the dump somewhere I can take a look?
<hakermania> If I have uploaded an earlier version of my application and thus I had a sponsor for it, should I contact him for a new version of the app and a new library not in the repos which is a dependency of this new version of the application?
<xnox> mitya57: interesting I got accept from wxwidgets3.0 source =/ it's now in bin new.
<xnox> mitya57: \o/
<mitya57> xnox: \o/
<zyga> mhall119: do you know who manages irc cloaks for ubuntu members?
<mhall119> zyga: #ubuntu-irc if I remember right
<zyga> are there any ubuntu developers from ukraine present here?
<happyaron> cjwatson: can you have a look at this merge request when you have time? https://code.launchpad.net/~penghuanmail/ubiquity/lp.1197220/+merge/195712
<mitya57> zyga: I'm not aware of any Ukrainian Ubuntu developers.
<ScottK> balloons: DMB time.
<ScottK> Sorry
<ScottK> barry: DMB time.
<shadeslayer_> doko: I don't suppose you're aware of some sort of porting guide that allows me to port an application from graphviz 2.26 to 2.34
<shadeslayer_> doko: currently stuck on http://paste.ubuntu.com/6510818/
<ryao> Does Ubuntu place mount and umount into /bin?
<ryao> Nevermind. happyaron helped me. Long story short, I am writing an upstream patch and I wanted to be certain that it worked on Ubuntu.
<smoser> anyone have an example of a service that does not have an upstart job ?
<smoser> ie, sysvinit only ?
<JanC> smoser: I think maybe apache & postgres?  (I would have to check the latest packages though)
<xnox> smoser: apparmor profiles, x11 common - in the default install.
<smoser> JanC, apache2 seems good.
<smoser> fwiw, this is https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1257036
<ubottu> Ubuntu bug 1257036 in sysvinit (Ubuntu) "services started with eatmydata should remove eatmydata by default" [Medium,Confirmed]
<smoser> hm..
<smoser> so that bug above, i assumed was present
<smoser> but it seems that most services clean their own environment
<smoser> (tested so far postgress, apache2, postfix)
<smoser> if i'm going to make cloud-init install packages by default with libeatmydata
<smoser> should i fix this even thought it seems that most packages don't need the help ?
<stgraber> cjwatson: I just uploaded a merge of LTSP and a sync for LDM, I think you were technically TIL for those two because of small arm64/d-i fixes, I hope you don't mind (I wrongfully assumed that I was TIL on both ;)).
<xnox> smoser: hm, would cloud-init leak LD_PRELOAD to e.g. juju / user logged-in session? ( i guess not, since cloud-init is managed by upstart). If it doesn't leak it, no need to fix "service" command since it's environment is clean.
<xnox> invoke-rc.d should be enough.
<smoser> xnox, you're right in that service is enough in that case.
<smoser>  but fixing service *also* is a more genericly safe path.
<kees> slangasek, tyhicks: apparmor 2.8.0-2 uploaded to Debian with multiarch and dh(1).
<xnox>  \o/
<tyhicks> kees: nice! :)
#ubuntu-devel 2013-12-03
<slangasek> kees: woohoo
<pitti> Good morning
<dholbach> good morning
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.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 lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<Laney> rawr
<doko> shadeslayer_, no, unfortunately not
 * dholbach hugs Laney
<seb128> Laney, enjoy the piloting!
 * Laney salutes
 * xnox ponders what/where/how intel graphics are screwed up on my desktop.
<seb128> how screwed?
<mpt> Laney, coincidentally I have just learned what a Patch Pilot is, while wondering what to do with a patch in a bug report
<mpt> Is there a simple how-to somewhere for turning a patch into a Bazaar branch proposed for merging? The closest Iâve found is <http://shallowsky.com/blog/linux/making-an-ubuntu-diff.html>, which is discouraging.
<mpt> (And not entirely relevant to an upstream project.)
<Laney> You can just subscribe ubuntu-sponsors if you like
<Laney> It's not hard to do for someone who knows how
<Laney> dholbach: how do I get to the packaging guide from http://developer.ubuntu.com/ ?
<mpt> Laney, ok, I subscribed ubuntu-sopnsors to bug 965953. Thanks.
<ubottu> bug 965953 in Indicator Applet "Indicator menus are too short and scroll when opened from screen bottom" [Low,Confirmed] https://launchpad.net/bugs/965953
<Laney> ta
<dholbach> Laney, the page is currently broken and we're talking with IS to get it off of there and on to packaging.ubuntu.com so we also don't to keep the packaging guide css and the developer.u.c style in sync, etc
<dholbach> Laney, I'll ping IS about it again
<Laney> dholbach: oh ok
<Laney> I googled for it and got the old wiki at number 1, then a pdf of the guide at number 2 (removing the filename from the url took me to a page about click packaging), then some other random stuff
<dholbach> yeah, I know - something in the new wp deployment (and some links) broke
<Laney> ah well
<Laney> thanks for following up
<xnox> seb128: i think it was a lockup "reboot" fixed it. but i do have a few crash files to upload.
<cjwatson> stgraber: ltsp/ldm> not a problem, thanks
<Laney> Mirv: want to take care of https://code.launchpad.net/~dandrader/ubuntu/trusty/qtdeclarative-opensource-src/backport_fix_qtbug_32004/+merge/195761 with your new powers ?
<Laney> Wait, you don't have them yet
 * Laney fixes that
<Mirv> might do at some point, although as pointed out it's a bit slow process since I'd need to build it for armhf first and then run all AP:s
<Mirv> it's in the 5.2 PPA builds now
<Mirv> so if the patch needs modifications, it's good to know
<Laney> Well, it's right near the top of the sponsorship queue now
<Laney> So if it's good to get in then it'd be nice to help that, otherwise reject it
<Laney> No good letting it sit there really
<Mirv> right, makes sense. I'll raise it on my todo list.
<Laney> ty
<Laney> cjwatson: do you have launchpad.Edit? could you add ubuntu-qt5-dev to the qt5 packageset uploaders please?
<cjwatson> Laney: launchpad.Edit on what object?
<Laney> (<Archive at 0x16beb610>, 'newPackagesetUploader', 'launchpad.Edit')
<cjwatson> Laney: nope, launchpad.Edit on the primary archive => techboard
<cjwatson> Laney: you could ask a webop to do it though ...
<Laney> ah, I thought ~launchpad gave you that
<cjwatson> ~launchpad doesn't give me admin, no
<Laney> ok
<cjwatson> it gives some magic things but not that :)
<cjwatson> launchpad.<PermissionName> is always contextual - depends on the object it's operating on
<Laney> yeah, I just overestimated the power of that team
<Laney> done
<Laney> Mirv: you should be good to go
<Laney> Riddell: ScottK: also kubuntu-dev can now upload qt5 stuff FYI
<Riddell> thanks Laney
<Mirv> thanks Laney
<dholbach> Laney, http://packaging.ubuntu.com/ is up and running, mthaddon is putting up rewrite-rules and the landing page will be maintained in a branch (and made a bit prettier)
<tedg> jodh, Could we have the upstart logs for stuff put a generic timestamp in for start and stop?
<tedg> jodh, I could do it for my jobs in a pre-start type script, but it seems more generic.
<jodh> tedg: https://bugs.launchpad.net/upstart/+bug/1154207. Not a priority for trusty, but patches welcome :)
<ubottu> Ubuntu bug 1154207 in upstart "console log should have an option to add timestamps" [Medium,Triaged]
<jodh> tedg: oh wait, you're talking about upstarts output itself? if so, feel free to raise a bug as that's different :)
<tedg> jodh, I was thinking a single timestamp "started at 23245345" type of thing, more than per message.
<tedg> per message would mostly implicitly add that though.
<xnox> tedg: what would be more interesting, is to record events in the job log which job is sensitive to "232122456 event: desktop-started SESSION_TYPE=Ubuntu" "Starting" ...... "Started"......"Stopping"....."Stopped"
<xnox> (that way one sees lifecycle of a single job, and it's stages)
<shadeslayer_> doko: drat :(
<knocte> Cimi: ping
<dobey> anyone know why the "show-hud" keybinding in dconf would keep getting reset, after i changed it?
<Cimi> knocte, pong
<Cimi> knocte, you ok in one hour?
<Laney> doko: looks like pcre3 has done Bad Things
<knocte> Cimi: in 1hr I don't think I'll be here; anyway I sent you a review-request for a merge, just try to ping me if you have any thing to discuss
<doko> Laney, ?
<Laney> doko: e.g. https://launchpadlibrarian.net/158171405/buildlog_ubuntu-trusty-i386.msva-perl_0.9.2-1ubuntu1_CHROOTWAIT.txt.gz
<Laney> http://paste.ubuntu.com/6514370/
<wgrant> Yeah
<wgrant> Someone probably wants to delete that from -proposed :)
<doko> wondering why ... https://launchpadlibrarian.net/158168960/buildlog_ubuntu-trusty-i386.pcre3_1%3A8.31-2ubuntu1_UPLOADING.txt.gz
<doko> looks ok
<Laney> blocked until someone can delete it
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.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 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:
<wgrant> doko: The file list at the end of that log looks pretty wrong
<wgrant> -rw-r--r-- root/root    247196 2013-12-03 12:12 ./lib/i386-linux-gnu/libpcre.so.1.0.1
<doko> ugh, soname change?
<wgrant> doko: Heh
<wgrant> doko: The soname is patched into configure by quilt
<wgrant> So your dh-autoreconf will just clobber it
<doko> wtf?
<wgrant> Yep.
<Laney> yeah ...
<doko> ok removing the binaries
<doko> and will add a symbols file to catch that
<cjwatson> Yeah, this is why I said to check the patches :)
<cjwatson> and why people patching only generated files should be Taught The Error Of Their Ways
<wgrant> s/patching only generated files/including generated files in source tarballs/? :)
<cjwatson> I'm fine with that personally
<xnox> wgrant++
<xnox> it's embedded copies of source, not preferred form of modification.
<xnox> we force regenerate valac, strip out included java libraries, yet somehow configure/config.guess/config.sub are all fine =/
<xnox> (i understand there is no licensing issues with configure/config.guess/config.sub but still)
<cjwatson> I'm a big fan of regenerating them in the packaging, but it makes sense for upstream to include them IMO
<xnox> quite.
<xnox> i wish it would be RC bug if autoreconf -f -i fails for example. Because, in practice it means inability to modify sources in the preffered form.
<doko> ok, binaries removed
<pitti> doko: ^ that's for the broken pcre, right?
<doko> pitti, yes
<pitti> (causing nice havoc in jenkins)
<pitti> doko: danke
<doko> every day you find some worse packaging bits, it doesn't stop ...
<mdeslaur> So, I've just rebooted saucy, and every time I start xchat from the message indicator, it comes up without global menus
<mdeslaur> tedg: is there a race with upstart user sessions or something that could result in that? ^
<tedg> mdeslaur, Not sure if saucy got the upstart restart patch for env vars?
<xnox> mdeslaur: cat /proc/`pidof xchat`/environ | grep -a unity-gtk-module ?
<xnox> mdeslaur: GTK_MODULES should have "overlay-scrollbar:unity-gtk-module"
 * xnox is still confused why GTK_MODULES are *opt-in* instead of *opt-out*
<mdeslaur> xnox: nope, not there
<mdeslaur> GTK_MODULES=overlay-scrollbar
<xnox> mdeslaur: then you will not have global menuabar.
<mdeslaur> xnox: looks like the messaging indicator managed to start without it
<xnox> mine starts with.
<mdeslaur> xnox: mine starts with it 99% of the time
<mdeslaur> xnox: once in a while, it doesn't
<xnox> mdeslaur: I see that overlay-scrollbar is reliable added in /etc/X11/Xsession.d/.... let's check unity module
<mdeslaur> xnox: could the indicator have started before /etc/X11/Xsession.d/81overlay-scrollbar got run?
<xnox> no, but that script doesn't set unity-gtk-module.
<mdeslaur> oh, duh -NEEDCOFFEE
<xnox> so unity-gtk-module should be set in Xsession.d to be reliable and I don't see it set.
<xnox> seb128: Laney: where is unity-gtk-module added to GTK_MODULES?
<seb128> xnox, Xsession.d
<seb128> hum, I though
<xnox> $ grep unity-gtk-module -r /etc/X11/Xsession.d/ || echo fail
<xnox> fail
<xnox> =/
<mdeslaur> heh
<seb128> xnox, oh, upstart job
<xnox> seb128: maybe there is some-wrapper or some-such side-effect.... if it's not set there, it's not guaranteed that all processes in the user session will inherit it.
<xnox> right, i see.
<seb128> I think ted suggested that (unsure though)
<xnox> well it can't be because of touch right?
<seb128> the upstart job should be reliable no?
<seb128> what do you mean "because of touch"?
<xnox> sure, for everything that is start on started dbus, but not before.
<seb128> I guess people though using upstart job was a more modern way that using Xsession.d
<mdeslaur> where are user session upstart jobs?
<seb128> indicators shouldn't start before dbus is started...
<xnox> mdeslaur: /usr/share/upstart/session; XDG_CONFIG_DIRS/upstart (array); XDG_CONFIG_HOME/upstart (single)
<mdeslaur> xnox: ah! thanks
<xnox> mdeslaur: i gave it in the order of last one wins, and overrides from the last one wins
<xnox> mdeslaur: so you can e.g. drop an override into ~/.config/upstart/
<mdeslaur> so...unity-gtk-module.conf may not get launched before the other jobs
<xnox> so, it's doing "start on starting dbus" which we know is racy in saucy (fixed in trusty), as in dbus started event is emitted before dbus actually is available and therefore extra dbus gets autolaunched by indicators without enheriting the variable.
<xnox> Laney: what's odd about the unity-gtk-module & overllay-scrollbars is that they are loaded unconditionally, regardless of the Desktop ENvironment.
<mdeslaur> xnox: what ensures unity-gtk-module.conf gets loaded before, say, gnome-session.conf?
<xnox> mdeslaur: when that happens, you should note that $ status dbus, doesn't match the dbus that is actually in use by the indicators.
<brainwash> speaking of overlay scrollbars, can maybe anyone here explain why bug 1239014 happens? trace log included
<ubottu> bug 1239014 in xfce4-settings (Ubuntu) "xfsettingsd unable to daemonize properly when overlay scrollbars are activated" [Undecided,Confirmed] https://launchpad.net/bugs/1239014
<xnox> mdeslaur: "started on dbus" in the gnome-session.conf. "started dbus" is not emitted until all tasks/jobs that are "start on starting dbus" are complete.
<xnox> but the buggy dbus job (in saucy) means that "started dbus" is emitted before it has completed (too early).
<xnox> mdeslaur: if you want to fix it for yourself, drop a file into XDG_CONFIG_DIRS after overlay-scrollbar, to add unity-gtk-module to the GTK_MODULES. that is guaranteed to be enherited by all processes in the user session.
<xnox> (upstart and non-upstart managed and children of thereoff)
<mdeslaur> xnox: ah! I see starting dbus vs started dbus
<mdeslaur> xnox: I understand now, thanks
<xnox> yeap =))))
<mdeslaur> xnox: so this should be fixed in trusty?
<xnox> yes, i believe it is.
<mdeslaur> xnox: awesome, thanks
<xnox> i don't find it important enough to fix in saucy =))))
<seb128> mdeslaur, you are not running trusty?
<mdeslaur> xnox: yeah, that's ok...I just wanted to make sure we were aware of this
<mdeslaur> seb128: I have to wait until the desktop team stops breaking it first :)
<mdeslaur> jk :)
<seb128> mdeslaur, I'm going to show you what we can do :p
<xnox> mdeslaur: well. I think it's a side-effect, of the same root cause which has been rectified.... =)
<smoser> any one using trusty and finding 'apt-get dist-upgrade' to just be painfully slow ?
<pitti> I find de.archive.u.c. to be painfully slow, but apt-get itself seems fine to me
<smoser> well, this is the 'dist-upgrade' part itself which is painfully slow.
<smoser> when it finishes, i'll pick the timestamps out of the log
<seb128> tseliot, hey, why did you set the xrandr/optimus/g-s-d issue back to triaged on g-s-d? is g-s-d doing anything wrong? (it seems like an issue in the nvidia xrand handling)
<tseliot> seb128: I was about to write the explanation. There's an error we should trap in libgnome-desktop
<seb128> ok, good
<tseliot> seb128: and I have a simple patch for that
<tseliot> seb128: also worth SRUing
<seb128> tseliot, sorry, just checked email after lunch and that one was in the batch ;-)
<tseliot> :)
<seb128> tseliot, great, it would be nice it you could upstream it as well (if it still applies to trunk)
<tseliot> seb128: yes, things seem to have changed quite a bit but if they're still doing that, I will
<seb128> tseliot, thanks
<tseliot> seb128: yw
<smoser> ugh.  there is a major lack of information here. i know that the dkms build was slow as I watched it, but for example /var/lib/dkms/virtualbox/kernel-3.12.0-5-generic-x86_64/log/make.log has only a start time
<smoser> not a stop time.
<Laney> xnox: I never set that stuff up
<Laney> Xsession.d was working fine as far as I was concerned
<xnox> ok.
<Laney> you probably want to talk to ted
<smoser> well, not very scientific numbers, but http://paste.ubuntu.com/6514743/
<smoser> pitti ^. generally i do think that 'apt-get dist-upgrade' is much less performant than it was in say saucy. not sure what would have caused this, but 17 minutes for ~ 45 packages is pretty bad (even though one was kernel)
<smoser> anyone else have non-scientific feelings that something in the path excercised by a genera 'apt-get dist-upgrade' is slower ?
<mlankhorst> ok does anyone want to test mesa 10 before I upload it? it passed all tests I threw at it locally :P
<xnox> smoser: is that amd64? or more specifically are there any foreign architectures defined?
<xnox> (e.g. on amd64, by default i386 is enabled. and the only big features in trusty so far is to switch to using python:any dependency....)
<smoser> xnox,
<smoser> $ x=$(dpkg --print-foreign-architectures); echo "arches: $x"
<smoser> arches:
<xnox> horum.
<smoser> it really feels like general IO to me.
<xnox> very odd, indeed.
<tseliot> seb128: so, shall I upload the quilt patch in gnome-desktop-3 in trusty and SRU the same package in precise? How do you suggest that I do it?
<smoser> i admit to not having cutting edge hardware here.  T400 with spinning disk (2009 era thinkpad). but really...
<seb128> tseliot, can you merge request it or put the diff up for review on the bug?
<tseliot> seb128: a merge request using bazaar? (svn is listed in the control file)
<seb128> tseliot, oh, we don't have a vcs ... I just want a diff/peer review
<seb128> tseliot, can you put the debdiff on the bug?
<tseliot> seb128: sure
<seb128> thanks
<spy6> cheers!
<spy6> is there a way to request a merge for a package from debian?
<spy6> #1244713 smells fishy and there arrived also a duplicate today
<mlankhorst> spy6: requestsync ?
<mlankhorst> although i guess that is a copy
<cjwatson> xnox is touched-it-last for that package
<spy6> mlankhorst: that is for pacakges without modifications ... nagios-plugins has ubuntu specific changes
<tseliot> seb128: the debdiff for trusty is there now
<seb128> tseliot, looks good to me ... could you upstream it and include the bug reference in the patch? then feel free to upload
<tseliot> seb128: isn't this enough as a reference? http://paste.ubuntu.com/6515056/
<tseliot> I'll try to upstream it too
<seb128> tseliot, upstream bug reference is nice because it tells us it has been upstreamed
<seb128> so we don't have to look for the info through logs and launchpad next time we merge
<tseliot> seb128: oh, so you mean the upstream bug number. Ok, good
<seb128> tseliot, right, sorry the upstreaming and bug references parts there were supposed to be one item ;-) thanks
<tseliot> ok :)
<mdeslaur> infinity: hrm, ruby-ffi needs some arm64 love
<mdeslaur> infinity: I'm guessing lib/ffi/platform needs a new platform definition
<tseliot> seb128: after a quick look I'm convinced that my patch is not upstreamable, as they moved all the RandR logic into Mutter: http://paste.ubuntu.com/6515114/
<tseliot> seb128: and while I can try to contribute to mutter, it will be irrelevant to the bug report on launchpad
<infinity> mdeslaur: Be my guest. :P
<mdeslaur> infinity: ah geez, I asked nicely didn't I? :)
<seb128> tseliot, it's still worth filling it in case they want to commit to 3.8, I think e.g the new RHEL might be based on GNOME 3.8
<seb128> tseliot, just write that it applies for 3.8 and can be wontfixed if they don't want it there
<tseliot> seb128: fair enough
<mdeslaur> infinity: do I have access to a porting box somewhere?
<infinity> mdeslaur: Sort of.
<Laney> qemu seems to work
<mdeslaur> infinity: oh, wait a sec...it compiled successfully before
<mdeslaur> infinity: ignore me for now
<mdeslaur> infinity: is DEB_HOST_ARCH still set to "arm64"?
<mdeslaur> infinity: sorry, I mean dpkg-architecture
<mdeslaur> infinity: ignore me again, I'm looking at the wrong issue
<xnox> mdeslaur: $ mk-sbuild --arch arm64 trusty should actually work now. I fixed up last hurdles it was having.
<mdeslaur> xnox: oh, cool, i'll give that try, thanks
<xnox> rbasak: do you know if anyone can steal nagios-plugins merge away from me? i did it for a transition, but the 1.5.x is non-trivial.
<xnox> alternatively i'll cherrypick fix for bug #1244713
<ubottu> bug 1244713 in nagios-plugins (Ubuntu) "invalid syntax for check_ssh plugin" [Medium,Triaged] https://launchpad.net/bugs/1244713
<bdmurray> seb128: a few weeks ago you'd asked about the discrepancy between bucket numbers on the landing page and on the problem page.  I have some information for you regarding that.
<seb128> bdmurray, hey, I read your comment on "asana" (received those by email)
<bdmurray> seb128: ah, okay then I won't repeat myself ;-)
<seb128> bdmurray, thanks for investigating ;-)
<bdmurray> seb128: no problem
<tseliot> seb128: ok, the upstream report and reference are there, and I've also filed an SRU for Saucy and Precise
<seb128> tseliot, thanks!
<tseliot> seb128: you're welcome
<doko> xnox, ping about demoting gccxml (split the boost python package)
<plars> slangasek: hi, is there someone that can help us with https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1256695
<ubottu> Ubuntu bug 1256695 in rsyslog (Ubuntu) "Trusty desktop Installation logs are not copied to /var/log/installer/" [Undecided,Confirmed]
<cjwatson> plars: I was going to look at that
<cjwatson> plars: (p.s. slangasek is on holiday)
<plars> cjwatson: ack, thanks
<cjwatson> plars: however, I have to fetch a current image first, so it probably won't be until tomorrow
<jdstrand> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.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 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: jdstrand
<bdmurray> seb128: you set bug 1024590 to In Progress for Saucy.  Do you plan on uploading an SRU for it?
<ubottu> bug 1024590 in aptdaemon (Ubuntu Saucy) "update-manager crashed with AttributeError in _on_download_changed(): 'NoneType' object has no attribute 'get_value'" [Medium,In progress] https://launchpad.net/bugs/1024590
<seb128> bdmurray, I was discussing it with mvo this morning, he did merge it in http://bazaar.launchpad.net/~aptdaemon-developers/aptdaemon/ubuntu-trusty/revision/308
<seb128> bdmurray, not sure if he was going to upload or if he would welcome somebody else to deal with those bits though
<seb128> mvo, ^^?
<seb128> sorry for the double ^, that key stopped doing what it should somewhat for me
<bdmurray> seb128: I saw the branch, thanks for chasing that
<seb128> yw
<bdmurray> mvo: I can do the SRU
<seb128> I had enough to see that topping e.u.c, just tried to come with some sort of solution, mvo was nice enough to pick it up, improve a bit and get it commited ;-)
 * seb128 hugs mvo
 * ogra_ hugs mvo
 * xnox hugs mvo 
<infinity> mdeslaur: It compiled fine both times, didn't it?  It's the testsuite that fails.
<mdeslaur> infinity: yeah, it's gem2deb that's broken, I uploaded a fix now
<infinity> mdeslaur: Oh, shiny.
<infinity> mdeslaur: Oh, "fixed".  I see.  Not quite as fixed as actually passing tests. :)
<mdeslaur> infinity: oh, hehe, no :)
<mdeslaur> infinity: it still needs love, but at least it won't be stuck in proposed :P
<mdeslaur> infinity: oh, hehe, that last changelog was a bit misleading...I'm not the one who disabled the tests
<vood> Hello, I have a question about myapps.developer.ubuntu.com, does somebody know, why application still apears in a Draft state even after ppa-info.txt upload ?
<sarnold> vood: #ubuntu-app-dev might be a better place to ask
<vood> thanks a lot!
<mdeslaur> doko: mind if I merge ruby-mocha?
<mdeslaur> doko: too late
<jdstrand> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.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 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:
<chiluk> are there any pilots left?
<chiluk> can I get some upload lovin for bug 560839 ... at this point I think it only pertinent that the fix be applied to trusty
<ubottu> bug 560839 in memtest86+ (Ubuntu) "error: too small lower memory (0x99100 > 0x98400)" [Medium,In progress] https://launchpad.net/bugs/560839
<chiluk> once it bakes there, I'll submit an sru for p,q,r,s
<xnox> stgraber: in mountall, you added /sys/fs/cgroup with size=1024. Why 1024? it appears to be by default mounted with size=4k
<infinity> chiluk: We don't need two copies of the same binary in the package, surely?
<infinity>  	install -D -m644 memtest.bin debian/$(PACKAGE)/boot/$(PACKAGE).bin
<infinity> +	install -D -m644 memtest debian/$(PACKAGE)/boot/$(PACKAGE).elf
<infinity>  	install -D -m644 memtest debian/$(PACKAGE)/usr/lib/$(PACKAGE)/$(PACKAGE).elf
<infinity> chiluk: If that second one is a well-known location we're afraid users might need a migration path for, install it as a symlink to the one you just put in /boot perhaps?
<stgraber> xnox: well, maybe 4K is fine, I don't really care, I just wanted the smallest quota possible which will still let us create directories
<xnox> i see.
<xnox> ack.
<chiluk> infinity, hmm good point.
<chiluk> infinity ... Is there  a special way to "install a link" or would just calling ln from the rules file be sufficient.
<xnox> chiluk: $ man dh_link ?
<chiluk> thanks...
<xnox> (just add "src dest" pairs in debian/$pkg.links)
<xnox> chiluk: for added bonus it corrects the links to be policy compliant (relative/abolute as needed)
<doko> xnox, ping about demoting gccxml (split the boost python package)
<xnox> doko: you need it now?
<xnox> i don't mind, it was demoted to Recommends in debian, but I guess we need it down to suggests.
<doko> xnox, no, but please still this year
<xnox> doko: ok.
<doko> well, split it out, then you don't need to recommend it
<xnox> doko: please elaborate, how are you suggesting to split it?
<doko> xnox, move the pyste module into a separate package
<xnox> ack.
<xnox> doko: thanks, that will simplify a few things.
<infinity> chiluk: As xnox says (or just do it in debian/rules with ln, given that there's variable exansion going on there)
<infinity> chiluk: And make it an absolute link, since /boot and /usr can be different filesystems.
<chiluk> infinity, trusty debdiff uploaded in bug..
<chiluk> infinity how do you feel about specifying elf vs not specifying it in the menu-entry titles?
<chiluk> I lean towards not doing so..
<chiluk> but the original fix for this had elfs all over
<infinity> chiluk: I don't see any reason for the GRUB entry to tell people things they don't need to know and won't understand.
<chiluk> ok .. one sec.. I'll revert that bit as well.
<infinity> chiluk: We don't tell people what sort of vmlinu{z,x,x.coff,etc} they're booting either.
<chiluk> i tend to agree with you.
<chiluk> infinity ... alright... it's all yours..
<infinity> chiluk: Oh, if you're doing dh_link in debian/rules like that, you really should probably just use 'ln' directly, so you're not accidentally creating links in packages you didn't mean to (if it's a multi-binary package), etc.
<infinity> chiluk: The correct way to use dh_link is with a debian/package.links file, but that would make the variable substitution bit hard, so I'd just use ln in rules with the install calls there.
<chiluk> all I know is what I have there worked when I tested it...
<infinity> chiluk: ie: "ln -s /boot/$(PACKAGE).elf debian/$(PACKAGE)/boot/$(PACKAGE).elf"
<infinity> chiluk: Sure, but it could have surprising and unexpected results if there's a bit of a packagin reorg or someone adds another binary package to the source, etc.
<chiluk> yeah that would work too
<doko> pitti, jibel: please could you let tcl8.5 migrate? python-imaging is removed, and it's the only test failing
<doko> infinity, or you: ^^^
<chiluk> infinity,  so you want me to change it back to ln ?
<infinity> chiluk: Yeah.
<infinity> doko: You want release team for that, yeah, and I can do it.
<infinity> doko: Done.
<doko> thanks
<infinity> doko: I'm confused by the python-imaging removal...
<chiluk> alright last times a charm right?
<infinity> doko: The comment you made was "NBS", but how can a source package be NBS? :P
<doko> infinity, called pillow now
<doko> hmm, maybe I should have written, removed from the archive ...
<infinity> doko: Ahh, the binaries moved to another source, and the source had no binaries?
<doko> yes
<infinity> doko: Kay, cool.
<infinity> pitti: Can you remove python-imaging tests from jenkins, or does that happen automatically (eventually) when sources are removed from the archive?
<xnox> infinity: it has to be done manually, as typically packages drop tests by accident and that's considered a regression. Last time jibel removed it for me, I think.
<chiluk> infinity new debdiff is attached... any more suggestions?
<infinity> xnox: This isn't a package that dropped tests, it's a package that stopped existing.
<infinity> xnox: But, indeed, the "dropped tests" case is what made me think maybe the "dropped package" case would be manual too.
<xnox> infinity: i guess that's cruft, and britney will not request / consider that package anymore?
<xnox> anyway, i don't actually know, so i should shut up.
<infinity> chiluk: If I was nitpicking, I'd say that my "ln -s" paste probably should have been "ln -sf", so subsequent runs of the same target don't fail.  Of course, that might fail anyway if the directory wasn't yet created.  Let's see.
<chiluk> I was going to suggest the f...
<chiluk> apparently I have too much faith in you.
<infinity> chiluk: I tend to talk more in pseudocode than actual copy-and-waste snippets.  I expect review and thought before application. :)
<chiluk> hah...
<chiluk> if you knew what i'm on you wouldn't expect much out of me at the moment... *(back surgery)
<infinity> chiluk: Anyhow, let me apply this, look at it in context, fix if necessary, and upload.  More back and forth is probably a waste of time.
<chiluk> agreed.
<chiluk> the basic fix is there.
<chiluk> but you have more experience with what I consider to be packaging issues..
<chiluk> infinity do you want to upload for pqrs as well?
<infinity> chiluk: Nope!
<chiluk> just checking.
<chiluk> I'll backport and create debdiffs
<infinity> chiluk: But you should subscribe to bugs on the package and watch how the trusty upload fares for a month or so to see if this was a Bad Idea for any reason.
<chiluk> and follow regular sru process
<chiluk> will do.
<doko> infinity, cjwatson: do you have an idea how dh-autoreconf should be called with cdbs?
<infinity> doko: I thought cdbs had its own weird equivalent, but I'm fuzzy on that.
<infinity> doko: seb128 or one of the GNOMEy people who use cdbs heavily might be best to ask.
<infinity> doko: cdbs does have an autoreconf.mk, though, so I'm guessing that's the way to go.
<tseliot> infinity: please approve bug #1255583 when you can, I'd like to upload a new nvidia-prime with the correct dependencies
<ubottu> bug 1255583 in bbswitch (Ubuntu) " [MIR] Main inclusion request for bbswitch" [Medium,Triaged] https://launchpad.net/bugs/1255583
#ubuntu-devel 2013-12-04
<xnox> doko: DEB_AUTO_UPDATE_AUTOCONF=2.69
<xnox> .... and similar for automake (if needed) and etc.
<xnox> doko: working example http://sources.debian.net/src/libshout/2.3.1-3/debian/rules?hl=23#L21
<slangasek> xnox: ITYM DEB_AUTO_UPGRADE_TO_DH
<xnox> slangasek: yeah, i'm gonna write cdbs snippet to execute dh_autoreconf with a single include =)
<slangasek> no, I mean a command to replace debian/rules with /usr/share/doc/debhelper/examples/rules.tiny
<xnox> heh
<infinity> slangasek: I think that command is "cp", but ymmv.
<sarnold> xnox: hello :) what's happening re: samba and samba4 packages in trusty? samba4 appears to be based on 4.0.3, samba appears to be based on 4.0.10, but launchpad thinks trusty samba is based on "samba 3.4 series".
<xnox> sarnold: "based on series" is bogus metadata, can be fixed.
<sarnold> xnox: okay, I figured as much there.. :)
<xnox> sarnold: samba4 src package and binaries should be removed from the archive, once ready.
<xnox> sarnold: fully superseeded by samba src package, which has now switched to 4.x series in debian and ubuntu
<sarnold> xnox: cool! thanks. :)
<xnox> sarnold: but, do note that upgrade story is aweful. If one had samba4 package installed on upgrade, it is removed =(
<xnox> sarnold: if one had samba installed -> it's upgraded to samba (3.x -> 4.x)
<xnox> sarnold: if one had both samba & samba4 installed, there are held packages and both are removed \o/
<xnox> slangasek: ^ =)))))
<sarnold> xnox: oh. that's .. less than ideal, hehe. is that something do-release-upgrade can paper over? or is just going to be slightly ugly? or an ugly transitional pacakge in trusty?
<sarnold> xnox: hahah, that's even more special :)
<xnox> i filed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730650
<ubottu> Debian bug 730650 in samba "samba: wheezy -> jessie upgrades may fail" [Important,Open]
<xnox> i think with http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730090 it will be better
<ubottu> Debian bug 730090 in samba,samba-common-bin "samba,samba-common-bin: leaves alternatives after upgrade from wheezy" [Important,Open]
<xnox> but still....
<sarnold> xnox: thanks for finding this so early :) it'd be a lot less pleasant to find this in february or march. :)
<infinity> sarnold: This isn't the sort of thing do-release-upgrade should be papering over, we should make apt-based upgrades DTRT.
<infinity> xnox: Are you keeping an eye on this one to make sure it ends up being sane?
<infinity> xnox: Also, wouldn't a samba4 transitional package help here a bit?
<sarnold> infinity: I've been lucky enough to not need the details of what apt can and can't fix itself :)
<infinity> sarnold: apt can fix pretty much anything if the packages are sane. :P
<xnox> infinity: well, look at the current samba4 package ;-) it is already transitional in ubuntu.
<infinity> About the only thing we should be doing in do-release-upgrade are the post-upgrade "make sure the packages we care about are installed" bits.  Most other quirks SHOULD be in packages.
<sarnold> infinity: oh, nice :D
<xnox> infinity: but it needs to happen in debian as well. Also not sure what's suppose to be done no all the LDAP databases and such. As if someone had both samba & samba4 I presume the'd want both to still be functioning........
<infinity> xnox: It... is?  Not according to rmadison.
<xnox> infinity: but I don't know if there are samba4 -> samba config migrations or not.
<xnox> infinity: samba4:any transitional package is built from samba4:src
<xnox> infinity: i did it to bypass NEW and get the migration rolling, when everyone was away =)
<infinity> xnox: It wouldn't have been NEW.
<xnox> (it was blocking eds/libav9 transitions)
<xnox> my bet then.
<xnox> i should upload proper one then.
<infinity> xnox: New is literally new.  As in, binaries not yet in the archive.  Moving a binary from one source to another isn't new, unless you delete the first before you upload the second.
<xnox> infinity: ... same in debian?
<infinity> I'm not sure how deeply we should care about the samba4 migration path.  But if we can do it without TOO much effort, we might as well.
<infinity> We really should never have shipped it in the first place. :(
<infinity> xnox: Same in Debian, yes.  A binary takeover from one source to another doesn't bug DAK.
<xnox> we have never shipped it ;-) (*) in an LTS
<xnox> wait, we did.... nevermind me.
<stgraber> xnox: FWIW I'm running samba4 on 12.04 and will want to upgrade those servers to 14.04 at some point :)
<xnox> stgraber: heh =) last time i touched samba, was when we were doing medical ORM on top of LDAP.....
<xnox> stgraber: once transition packages are fine, maybe you can test how bad/well the samba4 -> samba upgrade goes? (can you snapshot boot those samba servers?)
<stgraber> xnox: my domain has 4 domain controlers, so just upgrading one should be easy enough
<infinity> stgraber: 4 DCs?  Overengineered house much?
<stgraber> infinity: that's 4 different locations on 2 continents ;)
<roadmr> talk about a house...
<xnox> stgraber's neighborhood http://xkcd.com/1298/large/
<arun> help
<xnox> pitti: jibel: squid3 autopackagetest is failing because "/var/log/syslog" is not there. It's very odd, given one would expect all computers to have that available. Is there something wrong with the test-bed?
<slangasek> infinity: 'cp' - that's not very cdbsish!
<slangasek> xnox: samba upgrade> yes, have seen the bug report :/
<pianogmx> hey im an extra hand.  does anyone need any help with anything?  I don't mind volunteering my time.  and I want to expand my programming skills as well by helping someone.
<sarnold> hey pianogmx :) it's a bit late for north america and a bit early for europe..
<sarnold> pianogmx: is there anything in particular that's most interesting to you?
<pianogmx> sarnold, idk... im just bored and want to help someone... lol... i get lost on the forums and howtos for ubuntu because there is so much info.
<pianogmx> sarnold, my last projects were with a professor at my university but now I finished them all so thus im bored
<pianogmx> C# windows forms apps
<sarnold> pianogmx: bored is good, that's what drives you to find something fun to do! :)
<sarnold> pianogmx: the first thing that comes to mind is you could download the new ubuntu sdk and try it out, build a few qml-based applications
<tarpman> pianogmx: http://harvest.ubuntu.com/ is a neat site listing some not-too-difficult bugs that people could use help working on
<sarnold> pianogmx: I'm sure those teams would love some feedback from users and you could probably find things to work on that would be small enough and yet meaningful enough to be fun to work on them
<sarnold> ooh, I've never seen harvest before. neat. :)
<tarpman> sarnold: :)
<pianogmx> yeah i saw harvest but it started to hurt my head... because i was just searching and searching for something I could do...  i understand form applications but i saw some pretty freaky code for some ubuntu apps
<pianogmx> lol
<pianogmx> sarnold, so lets say after i build a few qml based apps, what would be useful to ubuntu that I could try making?
<sarnold> pianogmx: well, it's a -huge- undertaking, but I think a nagios frontend that doesn't use garish horrible colors would be nice :) but ... man, that'd be a huge pile of work.
<pianogmx> :( information overload...
<pianogmx> i loved it when people would break things into smaller tasks for me to accomplished
<pianogmx> now I just use the computer to stare at it ... because if no one manages me, i love my television
<sarnold> pianogmx: ah, yes, the television, I call that my "stupid time" :) time to turn off the brain and just giggle at the same old jokes..
<sarnold> pianogmx: perhaps a simpler problem -- our phone is going to need some RPN-based calculators, most platforms have five or six to choose from, it'd be nice to have some of our own :)
<pianogmx> huh?   you mean the ubuntu phone project?
<pianogmx> sounds cool...
<sarnold> pianogmx: yeah, I saw your message in there after seeing this channel. go figure. :) hehe
<pianogmx> do TI 84 use RPN?
<sarnold> no, they use algebraic input
<pianogmx> lol... id have to understand RPN first then it would be simple... yeah thats doable :)
<pianogmx> all i would need help with is how the community would like the UI to be... then I would be set
<sarnold> RPN is simpler than algebraic; there's a stack that supports "push" and "pop" types of operations; you put two pieces of data on the stack, then a command. the command takes arguments off the stack and puts results onto the stack.
<sarnold> the end result is you get to type things like 14 21 + 7 *  rather than (14+21)*7
<pianogmx> interesting, reminds me when I stared at a sample assembly code... yeah I get it
<pianogmx> so the ubuntu phone uses the QML development stuff?
<sarnold> yes
<sarnold> qml is going to be the "preferred" method of programmer advertised to most developers, though other options such as python and java and phonegap and C and C++ are all available...
<pianogmx> lol... i remember back in high school when making an algebraic calculator in java was an assignment
<sarnold> same here, I cringe when I think of how poorly mine worked. yes, it worked, but no, it wasn't pretty. :)
<pianogmx> i just never really stepped up my game since 07 to devbelop my skills...
<pianogmx> stopped programming for like 3 years
<pianogmx> made me depressed because i forgot shit
<pianogmx> oh mine used a java jpanel and i had it scroll 7 lines until it disappeared
<pianogmx> + i take mind altering medications... also upset because it screws with my thinking a bit...
<pianogmx> but... at least my body aint shaking
<sarnold> oh man, I'm sorry :/ programming well takes an unreal level of concentration. It wouldn't be fun to be fighting medication to make that happen. :(
<pianogmx> as for an RPN calculator on a ubuntu phone... is there an emulator for the ubuntu phone?
<pianogmx> and if someone gave me an interface mockup, that would be better than me trying to spend a few days hitting my head until i hullcinate something that looks nice (lol)
<sarnold> pianogmx: I think the emulator is called "goldfish", and I'm not sure, but I think last I heard graphics didn't work at all. most folks currently working on it have a nexus 4 or similar to play with.
<pianogmx> im on boost mobile (cant afford contract phones) thus i cant get a nexus 4 (cries)
<pianogmx> if nexus 4 did CDMA then it would be cool.
<pianogmx> i was happy when I got my HTC phone to run a partially working CM10
<pianogmx> but then went back to a modified stock instead...
<sarnold> heh yeah, for your _phone_ that makes sense. :) some folks do rely upon their ubuntu phone as their only phone though, so they'll have plenty of incentive to file bug reports and fix things :)
<infinity> https://wiki.ubuntu.com/Touch/Emulator <-- The emulator.
<pianogmx> exactly... is ubuntu phone OS going to have CDMA, EvDo compatbility in it?
<sarnold> break=bottom?? o_O
<infinity> sarnold: Instructions for how to recover a system that got hosed due to earlier emulator versions...
<infinity> (Well, due to a libc6 bug tickled by earlier emulator deps)
<sarnold> infinity: yeah, looks very unfun. I've never seen break= before, hehe.
<infinity> sarnold: break= refers to breakpoints in the initramfs's init.
<infinity> sarnold: bottom being the last thing before it pivots.
<sarnold> infinity: very cool, where's this thing documented? I don't see 'bottom' in upstart-events(7)..
<infinity> sarnold: initramfs init isn't upstart.
<infinity> Also, I lie, the last breakpoint pre-pivot is "init", bottom's a bit higher.  Anyhow, you get the point.
<geofft> man initramfs-tools
<pianogmx> OH.... android emulator requires the rolling release of trusty...
<infinity> Wow, it is kinda documented.
<infinity> I just read /usr/share/initramfs-tools/init when I want to refresh my memory.
<sarnold> thanks infinity, geofft :) I love learning new things. I'm not an entirely old dog yet! :)
<pianogmx> i wish gparted / ubuntu could shrink a partition when its in use (kindof like windows)... but the live usb always works :)
<pianogmx> is trusty tahr stable enough to handle QML app development for the ubuntu phone?
<pianogmx> (idk yet because im downloading it)
<pianogmx> sarnold, for the ubuntu sdk and the ubuntu phone, are all of the updates being pushed into the 13.10 for download?
<pianogmx> reason i ask, is i found an error that is supposedly already fixedx...
<geofft> While I'm here, anyone know if there's a data dump or API for www.ubuntu.com/certification?
<geofft> (or where I should ask?)
<pianogmx> and i noticed the ubuntu phone emulator asks for a trusty tahr environment...
 * pianogmx waves at geofft
<sarnold> pianogmx: it's possible to get updates to 13.10 but it requires more process; see https://wiki.ubuntu.com/StableReleaseUpdates  for more information
<pianogmx> sarnold, yeah, thats why im thinking to just shrink the ubuntu partition i have right now to keep it on stable packages
<pianogmx> and install another installation of trusty tahr for pre-release
<pianogmx> would be cool if rolling releases used p2p
<pianogmx> put less strain on the server...
<pianogmx> sarnold, so basically right now most people are using trusty tahr to develop QML apps for the Ubuntu Phone?
<sarnold> pianogmx: I've seen some efforts to get apt to do bittorrent or steal packages from peers in some fashion; most people with more than one machine (or lots of VMs or chroots or whatever) use either squid-deb-proxy or apt-cacher-ng -- a pretty ugly bug in apt-cacher-ng made me switch away from it a few days back, but squid-deb-proxy seems faster anyway. that helps immensely. :)
<sarnold> pianogmx: trusty tahr will be our next LTS release; it'll be the new flagship release for ubuntu for all uses -- phones, tables, desktops, servers, cloud hosts, cloud guests, supercomputer clusters, you name it, and trusty will be the Go-To solution.
<pianogmx> sarnold, i saw that... pretty familiar with the LTS, but I love sticking with the 6 month releases...  each one gives my intel HD 3000 an extra boost...
<sarnold> pianogmx: so the server team is polishing it for cloud hosting, cloud guest, traditional server tasks, etc. the desktop team is working on making it the best desktop operating system. The phone and tablet stuff has far enoug ht ogo that 14.10 will probably be the "go-to" release in a year's time, but trusty will be a very important step.
<pianogmx> awesome.
<pianogmx> will the ubuntu phone OS be CDMA compatible?
<pianogmx> im going to setup that quid package... sounds awesome... but I was addressing http downloads being slow from particular websites...
<pianogmx> oh... but i only have one machine with ubuntu.
<sarnold> pianogmx: you might wis hto pick a different mirror for ubuntu; mirror.anl.gov is roughly ten times faster than archive.ubuntu.com
<pianogmx> one thing that got me hooked on ubuntu a while back in high school was thinking that is mostly done by volunteers that don't work for a salary...
<pianogmx> i found that impressive
<ScottK> lfaraone: Please update the quassel packaging branch too.
<pianogmx> reading about axel... wouldn't axel theoretically overload an http server if too many people used axel on the same server?
<pianogmx> however, i am not complaining... it does download faster
<sarnold> pianogmx: normally a single TCP session will saturate the available bandwidth between a specific client and server; multiple connections really only helps if a server rate-limits on connection rather than rate limiting by IP or something similar.
<sarnold> pianogmx: multiple connections help a bit more when there are multiple smaller downloads to retrieve, it's more likely that one or the other will always be sending data rather than waiting in a latency-bound state (which is why most web browsers open two connections to web servers..)
<pianogmx> yeah, but i remember seeing when I setup a webserver on a max connections it can handle.
<pianogmx> so like, lets say axel opens 20.... and multiple people do that... it can theoretically hit that max connections open limit
<pitti> Godo morning
<sarnold> morning pitti :)
<sarnold> pianogmx: yeah; some server admins go to the effort of rate-limiting by IP or by network instead.
<pianogmx> yep... i setup a server or two a while back... one windows server , one ubuntu based... more to see how it works.
<pianogmx> i cant wait to see if there is any gpu performances in trusty tahr :)
<pitti> doko, infinity: python-imaging job removed from public jenkins, someone already did that for the public jenkins
<pitti> jibel, xnox: I have /var/log/syslog in my desktop's run-adt-test VM, but indeed not on wazn's; not sure why
<pitti> xnox, jibel: there are other log files like /var/log/udev or cloud-init.log, but apparently none from rsyslog
<pitti> rsyslog start/running, process 843
<jibel> pitti, it is not only wazn but all the test VMs
<pitti> *.*;auth,authpriv.none          -/var/log/syslog
<pitti> that's in /etc/rsyslog.d/50-default.conf in the test VM
<pitti> jibel: I wonder what makes the ones in the DC special; they ought to look exactly like a "prepare-testbed amd64" one created locally
<jibel> pitti, yes, they should be exactly the same
<dholbach> good morning
<jibel> pitti, I don't have /var/log/syslog on a local VM created with prepare-testbed either, and syslog is running
<pitti> jibel: ok, so perhaps mine is special then..
<pitti> jibel: ah, mine is some two days old, hang on; building a fresh one
<jibel> pitti, from rsyslogd in debug mode
<jibel> 3558.255026043:7f23687e2700: file '/var/log/syslog' opened as #-1 with mode 416
<jibel> 3558.255029594:7f23687e2700: strm 0x7f2360000b70: open error 13, file '/var/log/syslog': Permission denied
<jibel> pitti, I'll workaround the problem with a touch/chown/restart until I understand what is going on. It started yesterday so it is something that changed 2 days ago
 * Mirv is excited at his first upload to archives
<jibel> pitti, xnox same problem on a fresh server install with latest trusty images
<pianogmx> someone said that in order to find a way to contribute to contact a project on launchpad.net.... well there are so many options I don't know which to click :(
<pianogmx> i just want to know that if I start out with basic knowledge of programming, if there is anyone online that needs a volunteer to do something to help them....
<pianogmx> Mirv, what you uploading?
<jibel> pitti, http://paste.ubuntu.com/6518563/ it should be enough until logs are rotated which shouldn't happen during a test.
<Mirv> pianogmx: I uploaded qtdeclarative-opensource-src
<pitti> jibel: ouch; that seems to be new behaviour from rsyslog?
<pianogmx> cool Mirv
<pianogmx> wish i knew more stuff... then I could do the things on harvest (bug fixes)... most of the easy ones tend to get done to quick...
<jibel> pitti, yes, it seems to have started with 7.4.4
<pitti> jibel: that sounds like a regression
<jibel> pitti, xnox bug 1257633
<ubottu> bug 1257633 in rsyslog (Ubuntu) "/var/log/syslog doesn't exist on fresh installation of Trusty." [Undecided,New] https://launchpad.net/bugs/1257633
<pitti> jibel: merci
<jibel> I pushed the workaround to unblock tests
<jibel> squid3 is green, and I restarted apport which failed for the same reason
<pitti> jibel: thanks; did these tests explicitly check for /var/log/syslog? I don't remember doing that in apport
<pitti> and it woudl be bad, as people can configure that to their liking
<jibel> pitti, test_recent_logfile fails on a tail /var/log/syslog apparently, but I haven't checked the code to know what it does exactly.
<pitti> jibel: ah indeed, thanks
<pitti> I'll fix that
<pitti> jibel: or rather, it's not the test, it's the hookutils' "recent_syslog()" which assumes that /var/log/syslog exists
<pitti> jibel: so again an actual regression which slipped in ;/
<brendand> is anyone else here accutely aware of the vast performance gulf between SSD and HDD in terms of the dash (opening/searching etc)?
<brendand> i've just made the transition and it feels like we couldn't be doing any user testing on HDD systems or else we would have noticed that performance isn't adequate there
<MacSlow> pitti, seb128: where do I need to push a notify-osd-icons branch to in order to make it a MR for lp:ubuntu/notify-osd-icons ? Just trying to push it to e.g. lp:~macslow/ubuntu/notify-osd-icons-0-8 doesn't work.
<pitti> MacSlow: try lp:~macslow/ubuntu/trusty/notify-osd-icons/foobarize
<pitti> (pick a more adequate branch name, of course)
<MacSlow> pitti, ah... ok thanks
<seb128> pitti, is https://code.launchpad.net/~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu the packaging branch?
<pitti> seb128: ah, yes accordign to Vcs-Bzr
<pitti> MacSlow: so, you don't actually want the UDD branch
<seb128> MacSlow, ^ you might want to target that, not lp:ubuntu/notify-osd-icons
<pitti> MacSlow: s/might want to /must/
<pitti> unless we want to give up on the ~ubuntu-art-pkg team and that branch
<MacSlow> seb128, pitti: it's to add new icons from https://bugs.launchpad.net/ubuntu/+source/notify-osd-icons/+bug/1253591 for precise
<ubottu> Ubuntu bug 1253591 in notify-osd-icons (Ubuntu Precise) "Display switch and Radio enable/disable hotkey icons" [Undecided,New]
<seb128> MacSlow, you need them added to trusty first, before SRUing, in any case that package didn't change since precise, so they should be the same content, just different changelog version/target
<MacSlow> pitti, seb128: so right now I've pushed them to lp:~macslow/ubuntu/precise/notify-osd-icons/fix-1253591
<MacSlow> seb128, ah... will do that
<seb128> thanks
<cjwatson> xnox_: cc doko: don't use DEB_AUTO_UPDATE_*, use autoreconf.mk from dh-autoreconf instead - it's better-designed for clean handling and such
<MacSlow> pitti, seb128: When you got a moment... https://code.launchpad.net/~macslow/ubuntu/trusty/notify-osd-icons/fix-1253591/+merge/197670
<MacSlow> pitti, seb128: Can I delete my lp:~macslow/ubuntu/precise/notify-osd-icons/fix-1253591 branch now? I assume SRUing the trusty branch works differently,right?
<pitti> MacSlow: yes, we can't use UDD for (the first) SRU, and we don't use UDD in general for that package
<pitti> MacSlow: also, that MP is against UDD; it can still be applied (with manually downloading and applying the patch), but not formally merged
<MacSlow> pitti, so what's the next step to get it in precise once it was merge to trusty?
<pitti> MacSlow: you prepare the bug for SRU justification, and the sponsor just reuploads the very same package with a ~precise version suffix (and an adjusted changelog)
<pitti> MacSlow: you aren't in ~ubuntu-art-pkg? If you are, you can just commit to the actual branch
<MacSlow> pitti, no I'm not in that team
<MacSlow> pitti, didrocks is afaik
<MacSlow> didrocks, could you look at https://code.launchpad.net/~macslow/ubuntu/trusty/notify-osd-icons/fix-1253591/+merge/197670 when you have a moment? thanks in advance!
<pitti> MacSlow: if you want to avoid the manual pain for the reviewer, perhaps you can reapply your changes on the real branch, and re-do the MP
<didrocks> MacSlow: yeah, better to do it in the real branch
<didrocks> then, we can add it to daily-release because we don't AFAIK. I'll ask robru to do it
<MacSlow> didrocks, d'accord
<didrocks> MacSlow: merci! :)
<pitti> didrocks: I guess we can't run autopkgtests in CI yet, can we?
<pitti> didrocks: I mean s/CI/daily autolanding/
<MacSlow> pitti, didrocks: the "real" branch is ~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu then I assume
<didrocks> pitti: unfortunately, not
<didrocks> MacSlow: we should create a project for it
<pitti> didrocks: ack, thanks (once we can, I'd like to add apport and the sponsoring queue at large into it)
<didrocks> MacSlow: please, merge it there, I'll ask robru to fix all this :)
<didrocks> pitti: yeah, I think it's one of the priority for the CI AFAIK
<didrocks> team*
<MacSlow> didrocks, push my changes based on this directly there?!
<MacSlow> didrocks, no MR?
<pitti> didrocks: FWIW, notify-osd-icons hasn't changed in years, probably not worth spending much time on
<pitti> MacSlow: nah, you'll need an MR if you aren't in ~ubuntu-art-pkg; but I'm happy to review/merge
<didrocks> MacSlow: I think nobody can review it, so please do (seems safe icon changes)
<didrocks> pitti: well, better to have the same process for all our components
<didrocks> with proper projects settings and so on
<didrocks> this is only a 10 minutes process
<pitti> didrocks: right, but it sounds like this shoudl be an "icons" branch under lp.net/notify-osd, not a separate project
<didrocks> pitti: well, the thing is that the bzr repo are mixed then, it's not really git, and so, we force for consistency having source package name <-> lp:branch name
<pitti> didrocks: ah, ok
<seb128> didrocks, pitti: we need that uploaded to trusty and SRUed to precise, I think oem want those changes in the coming lts point release
<seb128> didrocks, pitti: e.g would be nice to get upload now and not delay too much on infra changes
<MacSlow> didrocks, pitti: ok... pushed changes to lp:~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu now... next step is SRU-ing this?
<pitti> MacSlow: ah, so you can push after all, nice
<seb128> MacSlow, yes, SRU just needs a bug report with the SRU info (https://wiki.ubuntu.com/StableReleaseUpdates)
<didrocks> seb128: I think MacSlow can prepare the SRUing while we do the daily release part, it's a 10 minutes thing. If it's that just that we need it know, I think sil2100 is free for it
<didrocks> seb128: even if I would have prefer robru to train on that one :)
 * MacSlow reads...
<seb128> didrocks, well, they want the stuff to land this week in trusty/precise SRU
<seb128> didrocks, so whatever, as long as you are sure he's going to follow up and not screw it
<didrocks> seb128: yeah, it will land that week, I'll backup tomorrow if it's not done tonight
<pitti> MacSlow: thanks; (note that I changed the changelog from trusty to UNRELEASED as it's not uploaded yet; the uploader will do it)
<seb128> didrocks, thanks
<seb128> didrocks, are you going to do the SRU landing as well?
<MacSlow> pitti, ah... didn't know that... thanks
<didrocks> seb128: not that one, I vary changing things for older release, so if you want to handle it
<pitti> MacSlow: yes, no big deal, just for the records in case you wonder
<pitti> MacSlow: thanks for keeping up with the bureaucracy and the UDD complications
<seb128> didrocks, ok
<pitti> MacSlow: deleted your trusty UDD MP
<MacSlow> pitti, I have not dealt with this for 18 months... so I'm expecting to be a bit rusted on the process details :)
<MacSlow> pitti, ah good... was about to do that too
<seb128> pitti, do you want to sponsor the SRU or should I?
<pitti> seb128: can do, but I understand we need to wait for landing this in trusty first?
<pitti> seb128: after that, it's a simple apt-get source, meddle changelog, upload
<seb128> pitti, well, that's usual SRU rules, but didrocks said he's going to make autolanding happen in the next day, so we can already put it in the SRU queue
<seb128> pitti, well, my guess is that they are going to do packaging changes to have it aligned with the other components (dh9, install fail-missing, etc)
<didrocks> yeah, I doubt the queue is going to be reviewed in a day from past experience :)
<seb128> so it's not going to be the same upload for the SRU
<pitti> seb128: ah, ok; I'll upload it now, then.
<seb128> we can as well dput what MacSlow just got up
<seb128> pitti, danke
<MacSlow> pitti, seb128, didrocks: The SRU-info is actually part of LP: #404658 and LP: #1253591 (icons) is just "part" of the fix.
<ubottu> Launchpad bug 404658 in OEM Priority Project precise "notification summary doesn't change for synchronous messages" [Critical,In progress] https://launchpad.net/bugs/404658
<ubottu> Launchpad bug 1253591 in notify-osd-icons (Ubuntu Precise) "Display switch and Radio enable/disable hotkey icons" [Undecided,New] https://launchpad.net/bugs/1253591
<pitti> seb128, MacSlow: precise SRU uploaded (but SRU team will not consider it before it lands in trusty)
<seb128> pitti, there is a bug reference in the changelog right?
<MacSlow> pitti: ok
<MacSlow> seb128, yes... and I used --fixes in bzr commit
<seb128> great
<seb128> MacSlow, danke
<pitti> xnox_, slangasek: I adjusted bug 1257633; apparently rsyslog is now completely unable to create  any of its logs?
<ubottu> bug 1257633 in rsyslog (Ubuntu Trusty) "/var/log/syslog and others don't exist on fresh installation of Trusty." [Critical,Confirmed] https://launchpad.net/bugs/1257633
<cjwatson> pitti: I'm investigating that at the moment, bug 1256695
<ubottu> bug 1256695 in rsyslog (Ubuntu) "Trusty desktop Installation logs are not copied to /var/log/installer/" [Undecided,Confirmed] https://launchpad.net/bugs/1256695
<cjwatson> pitti: it seems to be to do with a rearrangement of how privilege-dropping works
<pitti> cjwatson: ah, thank you
<cjwatson> +- bugfix: do not open files with full privileges, if privs will be dropped
<cjwatson> +  This make the privilege drop code more bulletproof, but breaks Ubuntu's
<cjwatson> +  work-around for log files created by external programs with the wrong
<cjwatson> +  user and/or group. Note that it was long said that this "functionality"
<cjwatson> +  would break once we go for serious privilege drop code, so hopefully
<cjwatson> +  nobody still depends on it (and, if so, they lost...).
<cjwatson> e.g.
<cjwatson> so, uh, oh dear
<pitti> cjwatson: ah, that's because /var/log is root:root 755?
<cjwatson> Yeah, it might be as simple as changing that
<cjwatson> I see that rsyslog-controlled files there were already syslog:adm
<pitti> rsyslog runs as syslog:syslog, so we could just make it root:syslog 775?
<cjwatson> that's certainly sufficient to make it work
<cjwatson> I can't immediately think of a reason not to do that
<cjwatson> what do other distros do?
<cjwatson> it's not clear to me that Fedora drops privileges, looking only at its rsyslog packaging
<pitti> cjwatson: do they even use rsyslog still? it's not all journald now?
<pitti> I understand you can still install it, but it's not by default
<cjwatson> Nor Gentoo
<cjwatson> pitti: could be
<cjwatson> pitti: however, there's a further difficulty
<cjwatson> pitti: if I just change the /var/log perms, then it appears to work, but /var/log/syslog is created syslog:syslog not syslog:adm, so the ability for users in group adm to read logs has been broken
<cjwatson> (and mode 640)
<cjwatson> pitti: this is related to bug 484336
<ubottu> bug 484336 in rsyslog (Ubuntu) "/etc/rsyslog.conf permissions incorrect/missing for creation of dynamic files" [Undecided,Confirmed] https://launchpad.net/bugs/484336
<pitti> cjwatson: ah, so we'd need to put user "syslog" into "adm", or perhaps even make that its primary group?
<pitti> (that's ugly to do on upgrades, though)
<cjwatson> or run rsyslogd as group adm
<cjwatson> I don't know which is worse
<cjwatson> we have to do one of those if rsyslogd is no longer willing to use raised privileges to open files, though ...
<cjwatson> it wouldn't need to be syslog's primary group
<cjwatson> syslog is a dynamic user owned by the rsyslog package, so it's not necessarily horrible to change its supplementary groups
<cjwatson> hmm, that doesn't fix the ownership though
<pitti> right, with a non-primary groupd it'd need a source patch
<cjwatson> oh, because rsyslogd doesn't setgroups when it drops privileges?
<cjwatson> or rather it does but only to deliberately drop supplementary groups
<pitti> cjwatson: no, I meant if it creates a new file, it would need to explicitly set their group to "adm", unless that's its primary group?
<cjwatson> it's already configured with FileGroup to do that
<pitti> ah, of course; sorry
<cjwatson> but the problem is that it can only do the chown() if it did the appropriate setgroups at privdrop
<cjwatson> http://kb.monitorware.com/feature-request-privdroptogroup-setgroups-initgroups-t11491.html
<pitti> $PrivDropToGroup syslog
<pitti> so that's what's not keeping the aux groups
<xnox_> doko: cjwatson: yeah, noticed for 1 of the 2 packages that autoreconf.mk snippet is available. Ended up using dh-autoreconf in both. DEB_AUTO_UPDATE_* seems to fail updating libtool, whilst autoreconf works.
<pitti> xnox_: <jedi wave> DEB_AUTO_* is not the tool you are looking for, it comes from the dark side
<cjwatson> right.  now the questions would be (a) would changing that to adm expose rsyslog to any malice by users in group adm? (b) might there be systems right now that are relying on rsyslog being able to open files in group syslog?
<pitti> I don't see an immediate case for (a) as "adm" is pretty much only a "get read privs" group, but (b) certainly might happen
<xnox_> pitti: =))))))
<cjwatson> the link above has an example of situations where you want rsyslogd to be able to set different log files to be owned by different groups
<pitti> cjwatson: TBH it seems safer to me to change the code to not drop the aux groups
<cjwatson> dropping the aux groups is required to drop the root group, but it could call initgroups afterwards
<cjwatson> pitti: Considering something like http://paste.ubuntu.com/6519272/
<pitti> cjwatson: I'm a bit rusty on the order of the various set* calls; does initgroups() come before or after setgid()?
<pitti> cjwatson: AFAIR, you have to setgid(), then initgroups(), then setuid(), right?
<cjwatson> pitti: rsyslog calls doDropPrivGid then doDropPrivUid
<pitti> the patch looks like initgroups() would come after set[ug]id?
<pitti> ah, so these two hunks are not from one functino
<cjwatson> pitti: doDropPrivGid already calls setgroups before setgid to discard the previously-held supplementary groups
<cjwatson> pitti: they are
<pitti> cjwatson: ack; LGTM then, thank you!
<cjwatson> pitti: the important bit is that you have to drop the old groups before you lose the ability to do so
<pitti> cjwatson: but this is still missing a chgrp syslog /var/log, isn't it?
<cjwatson> pitti: I think initgroups is fine after setuid
<cjwatson> pitti: oh yes good point
<pitti> cjwatson: after setuid> that's surprising; that sounds like increasing privileges after you dropped them and shouldn't be able to get them any more?
<cjwatson> I think you can gain your own supplementary groups ... but wait, something just occurred to me
<pitti> cjwatson: (and chmod 775)
<cjwatson> /var/log must not be owned by group adm
<cjwatson> because if we do that then users in group adm will be able to add files to it
<cjwatson> which is not expected
<pitti> no, adm group members must nto be able to write there
<pitti> that's why I thought root:syslog would be better
<cjwatson> oh, right, yeah, too many pieces
<pitti> so that rsyslog can write into it, but no real users
 * pitti adds to this TODO list to create an autopkgtest for rsyslog to cover new logs, log rotation, etc.
<cjwatson> http://paste.ubuntu.com/6519302/ then
<pitti> cjwatson: chmod g+w /var/log ?
<cjwatson> added
<cjwatson> pitti: hm, you were right earlier, setgroups (called by initgroups) requires the CAP_SETGID capability
<cjwatson> so I'll move that before the setuid
<pitti> ok, that's relieving (would be weird otherwise)
<pitti> tseliot: do you know a way to install the broadcom wl driver on current precise (12.04.3)? when installing it (kernel 3.8) the module fails to build
<tseliot> pitti: does it? I thought I had fixed that. Let me check
 * pitti tries the current trusty package
<tseliot> pitti: 6.20.155.1+bdcom-0ubuntu0.0.2 should fix that (precise-updates)
<pitti> tseliot: ah, that's not yet on the 12.04.3 image
<pitti> tseliot: I installed the trusty pacakge, that works
<tseliot> pitti: ok, let me know if there's anything I can do to help
<pitti> tseliot: if you already fixed it, that's fine; it'll be in 12.04.4
<tseliot> pitti: good :)
<cjwatson> pitti: OK, so after some fixups this basically works, but there's an amusing complication
<cjwatson> pitti: On upgrade, we restart rsyslog in postinst rather than stop in prerm / start in postinst, for generally obvious reasons
<cjwatson> pitti: But this means that when it restarts it tries to log one final message to say it's shutting down (and others might racily be logged, of course)
<cjwatson> pitti: And on a system without /var/log/syslog, that last message now gets successfully written (since we just adjusted permissions) but /var/log/syslog ends up as syslog:syslog (since we hadn't yet completed the restart with supplementary groups)
<brainwash> can anyone confirm that the software-center crashes after launch (trusty)?
<brainwash> bug 1256929
<ubottu> bug 1256929 in software-center (Ubuntu) "software-center crashed with signal 5 in cairo_surface_flush()" [Undecided,New] https://launchpad.net/bugs/1256929
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.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 lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<cjwatson> pitti: So, I don't know; I suppose we could choose to not care because it's only been a problem for five days or so and it would go away at the next logrotate
<cjwatson> pitti: wdyt?
<pitti> cjwatson: re (sorry, lunch)
<pitti> cjwatson: TBH I'd go with the "don't care" approach, as it didn't affect any stables
<pitti> cjwatson: and in trusty, logs are already broken anyway
<pitti> cjwatson: i. e. the fully "correct" solution would be to create the file in preinst with the correct permissions on upgrade?
<cjwatson> pitti: well, except that the race case could involve log messages going to any log file
<cjwatson> I'm cool with "don't care" if you are :-)
<pitti> I am
<pitti> the main conclusion I draw from this is "this needs an autopkgtest" :)
<MacSlow> seb128, taking a look at #1257717
<cjwatson> pitti: yes, quite - are you working on that?
<cjwatson> pitti: https://code.launchpad.net/~cjwatson/ubuntu/trusty/rsyslog/repair-groups/+merge/197705
<pitti> cjwatson: I added it to my TODO list
<cjwatson> thanks
<seb128> MacSlow, thanks
<MacSlow> seb128, odd still... as I didn't run into this when I tested a branch larsu did for nosd
<seb128> MacSlow, do you use trusty? as written on the bug, only the new glib is warning about those
<MacSlow> seb128, yes... I'm on trusty.
<pitti> cjwatson: do you want to wait for slangasek for another review, or just upload?
<MacSlow> seb128, did you do anything special to trigger that glib-warning?
<pitti> (approved the branch)
<cjwatson> pitti: slangasek's on holiday until tomorrow
<MacSlow> seb128, or just ran into it right away?
<cjwatson> pitti: so I think I'll just upload, thanks
<pitti> cjwatson: agreed, thanks
<seb128> MacSlow, just wait for a bubble to vanish
<seb128> MacSlow, sync or async (e.g sound ones, or just simple "notify-send hey")
<MacSlow> seb128, ok... I'll see where I get with this.
<seb128> MacSlow, danke
<MacSlow> pitti, seb128: With https://code.launchpad.net/~larsu/notify-osd/update-sync/+merge/194364 being merged... what's the expected time to hit trusty-archives?
<MacSlow> pitti, seb128: It's purely an automatic process from now on right?
<seb128> MacSlow, you need to ask for a landing to didrocks&co
<MacSlow> seb128, ah ok...
<seb128> notify-osd is not used on touch
<seb128> should be easy enough then
<didrocks> yep, just get it in the landing spreadsheet and we'll do it right away
<MacSlow> didrocks, ehm... "landing spreadsheet" that's something new to me... on google-docs?
<didrocks> MacSlow: yeah, maybe ask your manager or tech lead? He should know about it I'm sure :)
<MacSlow> didrocks, ok
<MacSlow> Saviq, https://code.launchpad.net/~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu
<MacSlow> pitti: robru does not seem to be online so if you have a free slot some review-eyes would be nice on https://code.launchpad.net/~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu/+merge/197720 thanks in advance!
<dholbach> didrocks, seb128: saw http://packaging.ubuntu.com/fr/html/ already? :)
<seb128> dholbach, fr \o/
<dholbach> :)
<dholbach> seb128, and it's a complete translation :)
<seb128> dholbach, tu vois, les traducteurs franÃ§ais travaillent !
<didrocks> excellent!
<didrocks> (the french word ^)
<dholbach> :-)
<zul> mterry: ping im looking at the python-librabbitmq MIR and it needs a running rabbitmq-server to test against
<MacSlow> seb128, Put a fix for LP: #1257717 up as MR -> https://code.launchpad.net/~macslow/notify-osd/fix-1257717/+merge/197728
<ubottu> Launchpad bug 1257717 in notify-osd (Ubuntu) "Invalid g_source_remove use" [Low,In progress] https://launchpad.net/bugs/1257717
<seb128> MacSlow, thanks!
<mterry> zul, hi
<mterry> zul, bummer.  :-/  I don't suppose it's easy to setup and do in a dep8?
<zul> mterry: not exactly
<zul> mterry:  i spent some time on it this morning and was unsusccessful
<mterry> zul, alright no worries
 * mterry finds that MIR
<zul> mterry: cool thanks
<jamespage> infinity, hey - remember that fix you did for openvswitch on powerpc? (adding -latomic to one of the test cases)
<jamespage> can you explain why that was required on just a single architecture? I need to backport that package to 12.04 and I'm struggling with that patch on all archs
<MacSlow> Saviq, the nosd-icon branch lives here lp:~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu
<utlemming> anyone know where the code branch for building the live-cd lives?
<cjwatson> utlemming: the squashfs part or the iso9660 wrapper part?
<utlemming> cjwaston: I'm actually looking for the code that generates the boot loader portion
<cjwatson> utlemming: that'd be in lp:~ubuntu-cdimage/debian-cd/ubuntu
<cjwatson> tools/boot/$series/boot-$arch
<utlemming> cjwaston: awesome, thank you kindly
<cjwatson> nature of the beast is that some of the *real* code lives in the boot loader packages themselves and/or in debian-installer though
<cjwatson> so "it depends"
<MacSlow> Saviq, notify-osd-icons needs a release from lp:~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu (fixing 1253591), notify-osd needs a release from lp:notify-osd (fixing 404658)
<utlemming> cjwatson: understood...I was looking to it for hints on UEFI
<cjwatson> yeah, you'll find that's partly in debian-installer/build/util/efi-image and partly (esp. due to secure boot) in grub2 itself
<cjwatson> debian/build-efi-images
<utlemming> ack, and thank you for the hints :)
<kentb> mdeslaur: on that ledmon package, how were you able to tell that it was synced already?  I'd like to know so I don't file an unneccessary bug in the future
<mdeslaur> kentb: i got synced about 30 seconds before I wrote that comment :)
<mdeslaur> kentb: I saw it on the trusty-changes list
<kentb> mdeslaur: ah ok cool
<brainwash> bug 1163886 happens in trusty without adding the gnome3 ppa, should the importance level be raised?
<ubottu> bug 1163886 in webkit (Ubuntu) "software-center crashed with signal 5 with WebKit 2.0+" [Critical,Confirmed] https://launchpad.net/bugs/1163886
<brainwash> oh my bad, already set to "critical" (webkit)
<seanz> Good day, humans. Is there anyone here maintaining a Debian package that contains a Java .war file?
<seanz> I'm looking to obtain information on building a package that will automatically create the .war file, so I wanted to ask questions about how those sorts of packages are officially maintained.
<robru> MacSlow, I'm here now, still need that review?
<MacSlow> robru, oh ... no... the upload-machinery is already working... I actually did a bit too much initially... you can savely ignore me initial request
<robru> MacSlow, ok
<infinity> jamespage: Some arches offload some atomic bits to -latomic, and some don't, we only happen to (currently) ship one such arch.  But with --as-needed, it shouldn't matter to link it on all arches anyway.
<infinity> jamespage: What problem are you seeing?  Do you have a PPA with source and build logs?
<jamespage> infinity, for 12.04 I see a built failure when linking the test-atomic binary - fails to find -latomic
<jamespage> lemme dig out a build log
<jamespage> infinity, source package is a straight no-change backport
<rbasak> mdeslaur: sorry, I checked and synced bug 1257790 earlier, but was waiting to see if it all worked before letting syncpackage close the bug as instructed by it.
<ubottu> bug 1257790 in ledmon (Ubuntu) "Sync ledmon 0.79-0.2 (universe) from Debian unstable (main)" [Undecided,Fix released] https://launchpad.net/bugs/1257790
<mdeslaur> rbasak: ah, cool...didn't know if you had seen the bug or not
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.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 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:
<hallyn> stgraber: cgroup-lite in saucy does 'mount (cgroup) || true'.  in precise it doesn't.  Now this was changed so that cases where /sys/fs/cgroup/* was already mounted (i.e. by cgroup-bin), but it happens to also quietly allow cgroup-lite in non-nested profile to be installed
<rbasak> mdeslaur: I didn't think there'd be a conflict in that short time. Next time I'll mark it In Progress.
<hallyn> stgraber: my question is, which is the right behavior?
<jamespage> infinity, log extract - http://paste.ubuntu.com/6520885/
<hallyn> my feeling right now is that if cgrousp can't be mounted, cgroup-lite should fail to install.  else things dependin gon it will just fail later
<hallyn> i don't intend to change it for saucy, but am wondering whether to change it for precise or not
<infinity> jamespage: Oh.  -latomic might be entirely unnecessary on older GCC versions.
<infinity> jamespage: I can do a test build on precise/ppc to see if we're good with just dropping that patch on backport.
<stgraber> hallyn: I'm not sure. I hate for things to blow up at install time but I also don't think letting cgroup-lite start is a good move, so if it can be installed fine but not started (pre-start check and call to stop) then that should be reasonable
<jamespage> infinity, I guess I could write a macro to figure out whether its actually needed
<jamespage> trying to avoid deltas due to the number of packages we have to backport for openstack
<infinity> jamespage: Or if it can be linked at all. :P
<hallyn> stgraber: but things we have now just depend on the cgroup-lite package.  they don't refuse to start if cgroup-lite job is not started
<infinity> jamespage: A simple AC_* (try_compile or link?) would get the job done.
<infinity> Assuming it's an autoconf project.
<jamespage> infinity, yeah - I'll go that route
<jamespage> it is yes
<infinity> jamespage: Well, let me verify quickly that it works fine on precise without (but it should).
<jamespage> thanks
<infinity> If I need a *different* fix for precise, I'd like to know.
<stgraber> hallyn: sure but none of those actually depend on cgroup-lite either. If cgroup-lite fails to start and you have something else mounting the cgroups, LXC should still work. Actually didn't LXC used to work (maybe still does?) without cgroups?
<infinity> jamespage: But yeah, you probably want a proper autoconf check for -latomic, add it to ATOMIC_LIBS if found, and s/-latomic/$(ATOMIC_LIBS)/ in my tests/automake.mk patch.
<jamespage> ack - I'll look at that tomorrow
<jamespage> (bit late in the day for my brain to work right with autoconf checks now)
<hallyn> stgraber: ok.  so i guess we can open a bug against cgroup-lite tofix that in precise.  But I'm nto sure the best way to handle it.
<hallyn> shoudl i just make it '/bin/mount-cgroups || {stop; exit 0}' in pre-start?
<hallyn> (cgroup-lite does everything in pre-start, no start)
<hallyn> i guess i can try and do it more the way saucy does it.
<stgraber> hallyn: yeah, I think that'd be appropriate, that way anything that uses on "start on cgroup-lite" won't get started if cgroup-lite fails
<hallyn> ok, thanks.
<hallyn> heh, currentliy no bugs in cgoup-lite.  hate to change that :)
<xnox> pitti: since the syslogd bug was upon new-installation, all what's needed is an extra installation validation python test added to utah, this way it would be verified on fresh installs against all install types it's executed upon.
<xnox> pitti: i can add it.
<infinity> jamespage: Confirmed that it builds fine on precise with my patch backed out, FWIW, so yeah, a try_link or whatever should do the trick.
<infinity> jamespage: And that would certainly be more upstreamable too.
<seanz> Is this the appropriate channel to ask for info about .deb packages?
<olli> seanz, what's your question
<seanz> olli: My question is about how to properly package a .war file as a Debian package.
<seanz> I wanted to find a maintainer of such a package and get info from said individual. Or multiple individuals, if there are many.
<olli> seanz, this is a good start here, I am not familiar with that though
<seanz> olli: Ah, well thank you for confirming that I'm in the right place.
<tarpman> seanz, might be worth checking with #debian-java
<tarpman> erm. sorry, wrongchan, ignore me
<seanz> tarpman: Oh man, I got pretty excited there for a moment. :) That would have been perfect.
<tarpman> seanz: oh. well, do try it then. it's on irc.debian.org (OFTC)
<tarpman> seanz: I was reading your messages thinking we were in #debian-devel
<seanz> tarpman: haha - I couldn't get into debian-devel because it is invite only.
<tarpman> seanz: on freenode it is, because all the debian channels are on oftc
<seanz> I don't know anyone in the Debian circles.
<tarpman> seanz: the real #debian-devel, the OFTC one, is public
<seanz> tarpman: Which one is the "real" one?
<seanz> OFTC or freenode?
<tarpman> OFTC
<tarpman> see https://wiki.debian.org/IRC
<seanz> tarpman: Ah, most excellent.
<tarpman> seanz: have to run. good luck
<seanz> tarpman: Thanks. Have a good day.
<seb128> bdmurray, thanks for SRUing mvo's aptdaemon fix, do you plan to upload to trusty as well?
<seb128> bdmurray, infinity: could you review the wpa SRU in the saucy queue this week? That's one of the most reported e.u.c errors for saucy, would be nice to get in
<seb128> cyphermox, thanks for uploading that ;-)
<bdmurray> seb128: I hadn't thought about trusty yet
<bdmurray> seb128: I'll look at wpa
<seb128> bdmurray, ok, not sure how picky the SRU reviewers are about having stuff fixed in $unstable before accepting SRUs nowadays
<seb128> bdmurray, thanks
<lifeless> barry: hey, do you know the situation vis-a-vis paramiko and Python3 ?
<lifeless> barry: upstream, that is.
<barry> lifeless: i get emails about the open ticket all the time.  let me see if i can dig up something recent
<barry> lifeless: https://github.com/paramiko/paramiko/issues/16
<barry> issue is still not closed (currently they are debating python 3.2 support)
<lifeless> thanks
<lifeless> do you think more hands would help?
<barry> lifeless: sounds like they could use additional validation so they'll feel more confident releasing something
<zyga> barry: does this ring any python bug bells:  https://plus.google.com/116315264177593873442/posts/aMYRMCW9rgc
<zyga> barry: 3.2 seems to mangle memory when certain metaclass operations are used, 3.3 does not
<zyga> (mangle as in overwrite somewhere)
<barry> zyga: it doesn't but let me poke around
<zyga> barry: thanks!
<zyga> barry: I tried several alternatives (constructing another dict from namespace, etc) but only actually iterating over the namespace dict triggers that bug), manifestations are also different, I just realised I saw this bug in some of my older code, where it borked __mro__ instead of repr
<zyga> barry: also, works on i386 but does not work on amd64 (sadly arches are also coupled with different OSes and python releases/builds in my environment). I'm setting up tests on i386 debian py3.2 builds
<barry> zyga: looks like it's still broken in py32 hg head
<zyga> barry: yeah, it's broken on all builds of 3.2 that I can find
<barry> zyga: that's a truly strange one.  if you replace the for-loop with just list(namespace.items()) it works.  that means iterating by itself isn't the problem.
<zyga> yeah
<zyga> I know
<zyga> I'm going to build 3.2 and check if I can make heads/tails of what that operation may trigger in __new__
<zyga> barry: also, might be bisectable between 3.3
<zyga> barry: but that would take a while to run
<zyga> barry: shall I report it upstream?
<barry> zyga: i was just scanning bugs.python.org to see if it was already reported.   i'm happy to report it if i don't find something (unless you want to do it)
<zyga> barry: I could do it, seems like a genuine bug and I can learn something in the process
<barry> zyga: go for it.  i can't find anything in my tracker searches.  it's definitely a weird corner case. :)  paste me the bug number so i can subscribe to it
<zyga> sure
<barry> zyga: fun!
<zyga> barry: http://bugs.python.org/issue19888
 * zyga checks 2.7
<zyga> barry: also affects 2.7
<barry> zyga: with different syntax of course
<zyga> right
 * barry checks 2.7 hg head
<zyga> barry: can I link that to python in ubuntu somehow?
<barry> zyga: link it to the source packages for python3.2 and python2.7.  of course, we'll probably ignore it for 3.2 unless it's worth sru'ing into older ubuntoids
<zyga> barry: ok, I'll try
<zyga> barry: curious, it seems to pick up first, not too short, symbol defind in the object
<zyga> barry: I tried with methods, variables, etc
<zyga> barry: but short, one-letter variables didn't work
<zyga> barry: 'problem = 1' works (reproduces the problem) though
<barry> zyga: fun
<barry> zyga: is this a critical problem to fix?  iow, does it break something critical for you?
<zyga> barry: no, just breaks some tests that I've disabled
<zyga> barry: it's not happeninng if you construct the new class before iterating over namespace
<barry> zyga: ack
<zyga> oohhh
<zyga> barry: it's so silly
<zyga> barry: it is not a bug :)
<zyga> barry: name spills out of the for loop
 * zyga is such a woos
<zyga> barry: did 3.3 change anything in that behavior?
<barry> d'oh
 * zyga is so stupid now :)
<zyga> barry: why did it work on 3.3 though? sheer accident?
<zyga> barry: or does 3.3 change scoping rules?
<barry> zyga: yes it did.  for-loop variable scopes
<zyga> aaah
<zyga> right
<zyga> didn't know that
<zyga> :D
<zyga> that was silly, thanks, I'll fix my code
<zyga> sorry for taking your time with my mistakes
<zyga> barry: I cannot find any trace of that new for loop behavior, I've read http://docs.python.org/dev/whatsnew/3.3.html and looked for PEPs, is there document/discussion that describes that feature?
<barry> zyga: hmm, i don't see one either
<zyga> barry: are you sure it's that though, this is not a bug, just hard-to-find feature?
<barry> zyga: you could just be getting (un)lucky.   it might be related to iteration order
<lifeless> zyga: got a small reproduction of the problem?
<zyga> lifeless: yeah
<zyga> http://bugs.python.org/issue19888 see two attached files
<zyga> barry: but namespace doesn't include __name__, it cannot be luck
<zyga> barry: so we cannot get lucky ordering that would result in the the binding to name being right
<lifeless> zyga: scary
 * zyga writes another test case for 3.3 magic feature
<barry> zyga: it's as if type.__new__() is ignoring 'name' for repr purposes
<lifeless> zyga: but your code is clearly broken
<lifeless> zyga: since you're rebinding name
<barry> lifeless: right
<barry> lifeless: but it doesn't matter :)
<lifeless> barry: right, corrupt is corrupt
<zyga> lifeless: yeah, my code was broken but something else seems to be broken as well
<zyga> barry: I cannot reproduce 3.3 for-loop scoping
<barry> zyga, lifeless forget loops.  http://paste.ubuntu.com/6522270/
<barry> run that under 3.2 and 3.3
<zyga> barry: o_O
<zyga> something is indeed broken
<zyga> barry: would you like to reopen it with the extra bits of information?
<barry> zyga, lifeless at best it's an undocumented change in behavior afaict
<lifeless> barry: <class '__main__.foo'>
<barry> zyga: what makes you think it's a memory corruption?
<barry> lifeless: right
<zyga> barry: well, it's clearly not memory corruption, the bug can be renamed
<zyga> barry: but it's a bug (your case shows that clearly)
<zyga> barry: or we can have a new one
<lifeless> oh
<lifeless> the class name is being honoured
<lifeless> in 3.2 and ignored in 3.3
<lifeless> 3.3 regression?
<barry> lifeless: could be
<zyga> no 3.4 builds anywhere?
<barry> zyga: i'm building it from hg now
<barry> not in ubuntu yet.  i think doko has a 3.4 build in experimental
 * zyga looks
<zyga> barry: also present in 3.4 from experimental
<barry> zyga: yes, and hg head
 * zyga dives into cpython
<zyga> barry: I think I found it
<zyga> barry: just let me build to check
<zyga> barry: how do I checkout master ahain /o\
<doko> barry, you should run trusty
<barry> doko: i do!
<barry> zyga: http://docs.python.org/devguide/
<doko> https://launchpad.net/ubuntu/+source/python3.4/3.4~b1-0ubuntu2
<barry> doko: ah, right :)
<zyga> barry: I mean after I've swithched to 2.7 to compare?
<zyga> barry: hg checkout default?
<barry> zyga: yeah
<zyga> thx
<barry> doko: ah, it's only in proposed
<zyga> barry: nope, wrong idea, still searching (for the bug, not for hg manual)
<barry> zyga: ack.  it's nearly dinner time here, so i'll be afk in a bit.  i'll check scrollback later
 * zyga wonders what to say, it's 1:16 AM 
<zyga> ah, 0:19 AM, my vms got borkish timezones and unsynced clocks
<barry> zyga: i guess i can't say it's time for a midnight snack :)
<zyga> haha
 * zyga added import math; math.sin(0) to break on the sin symbol in C and learn how python object construction works
<zyga> any gdb macros to poke python objects?
<barry> zyga: checkout Misc/gdbinit
 * zyga learned how to look at tuples with some ugly casting
<zyga> ah, thanks
<zyga> barry: that's super useful, thanks
<zyga> ok, I see the wrong value being passed, let me just figure out where it came from
<zyga> smells like broken builtin___build_class__
<zyga> barry: any reason I get 'No symbol "_PyUnicode_AsString" in current context' when using most of the macros?
<jtaylor> barry: Misc/gdbinit seems less feature full that the stuff that comes with python-dbg
<jtaylor> or is it just extra stuff?
<jtaylor> zyga: you should get gdb python object resolving automatically if you install pythonX.Y-dbg, (but its broken in saucy)
<zyga> jtaylor: my mirror doesn't include -dbg packages, hold on
<zyga> jtaylor: will it break if I rebuild python locally with debugging (different layout?)
<jtaylor> probably not
<jtaylor> so far I know its pure python implementation
<jtaylor> and its awesome :)
<jtaylor> http://docs.python.org/devguide/gdb.html
<zyga> jtaylor: i'm a bit tired, I need to figure out how to break on a given condition that involves a python unicode object
<zyga> I guess I need to just stop debugging stuff at 1AM
 * zyga mirrors -dbg packages related to python
#ubuntu-devel 2013-12-05
<jtaylor> zyga: if you are dealing with memory corruption valgrind --db-attach=yes is useful
<jtaylor> after attaching py-list and see what line of python code caused it
<jtaylor> but unfortunately you need a large amount of suppressions as python is very valgrind noise
<jtaylor> < offline
<geofft> kees: ping?
<pitti> Good morning
<pitti> xnox: syslog> I'd rather add it as an autopkgtest so that it blocks regressions in -proposed, rather than seeing them in the install smoketests once the damage is already done; but can't hurt to test it in both places, of course
<dholbach> good morning
<penghuan> cjwatsonï¼i have updated my merge proposal about https://code.launchpad.net/~penghuanmail/ubiquity/lp.1197220/+merge/195712ï¼ hope you can take some time have a look at itï¼ thanksï¼
<BrotherBrick> morning
<pitti> doko_, barry: FTR, haveged didn't help after all, py2.7/3.3 still fail the UUID tests very often
<pitti> doko_, barry: so it's not missing entropy, but some other assumption that UUID makes; 23 collisions (i. e. identical UUID) out of 1000 is quite much indeed
<pitti> doko_, barry: so I'm not sure whether this is a design problem of UUID1, or the Python test which assumes that it can generate 1000 time-based UUID1s at the same time and not get any collisions
<pitti> but if it is, it might perhaps make sense to xfail/disable that test in autopkgtest? can this be done easily, or would that require patching?
<pitti> doko_, barry: note that the documentation says it's going to use a 14 bit random sequence number, which is 16384 possible starting values
<pitti> doko_, barry: so one would expect 61 collisions amongst 1.000 UUIDs if it was only that; the actual number is lower as it also takes the current time into account, but in the VM we might not have the microsecond precision that this test assumes
<pitti> jibel: ^
<jibel> pitti, IIRC you can exclude tests for autopkgtest only directly from debian/tests/<testscript>
<pitti> err, probably not 61 (birthday paradoxon); too lazy to do the exact calculations, but one certainly can't expect no collisions at all for 1000 out of 16384
<pitti> jibel: yes, that's what we should do; I meant, if there's some easy "$SKIP_TESTS" or if it needs some seddery
<jibel> doko_, BTW, python3.4 autopkgtest explicitly calls python3.3
<doko> pitti, jibel: fixed for the next uploads
<pitti> doko: you mean skipping the tests?
<doko> yes. just wondering why they don't fail on the buildds :-/
<pitti> doko: they aren't VMs; I guess they have a higher clock resolution there?
<doko> yes, no vm's
<jibel> doko, did you fix python3.3 -> 3.4 in debian/tests/* too ?
<doko> jibel, yes
<jibel> doko, thanks
<doko> jibel, however this one didn't reach trusty for arm64 yet ...
<pitti> didrocks: sorry, I got a bit confused about notify-osd vs. the new -icons; why are these on manual landing?
<pitti> didrocks: I thought we defaulted to auto-landing for stuff which isn't critical on the phone, to avoid too much manual work?
<didrocks> pitti: hey, cu2d wasn't done for having this manual landing forever
<didrocks> that was forced upon us
<didrocks> so it would mean dividing the stacks between desktop-only and the rest
<didrocks> (so that the desktop-only stacks can land automatically)
<didrocks> and TBH, don't really have the time to recreate the views and so on
<didrocks> hence the landing spreadsheet, so that we can force the publication on those (if tests pass)
<didrocks> in addition, that won't help us much, because most of the indicators or hud are both desktop and touch
<didrocks> so we can't land unity7 automatically, because it was built and tests against a version in the ppa which won't be released
<didrocks> and so, we can have unseen ABI breakages and so on
<didrocks> (cu2d for that put the stack in manual mode automatically, but it would mean that in the end, it will always be manual as the hud and indicators are in manual mode)
 * cjwatson fixes auto-sync rashing
<cjwatson> *crashing
<apachelogger> ev: how do whoopsie-preferences' crashes and autoreportcrashes setting relate to whoopsie and apport ... i.e. when does whoopsie actually send the reports and when does apport and when does neither?
<apachelogger> also, whoopsie is supposed to get adopted in kubuntu this cycle; finally ^^
<pitti> apachelogger: note we still have this bug where whoopsie doesn't pick up the newly created *.upload stamps in /var/crash; "sudo restart whoopsie" usually helps
<pitti> so at least for me, whoopsie seldomly actually uploads something :/
<apachelogger> it seemed to me it always uploads on start, but yeah I noticed the issue
<pitti> apachelogger: at the moment, apport doesn't send crashes to Launchpad, only to whoopsie (we'll turn that back on soon, though, for the dev release)
<pitti> apachelogger: whoopsie is supposed to upload as soon as you click "yes, report" in the apport UI, i. e. when the *.upload stamp is created
<pitti> (always, also in stable releases)
<apachelogger> hm, I'll likely have to patch some KDE stuff then, since we do not use apport but KDE's tool
<apachelogger> Riddell: ^
<pitti> apachelogger: ah, you don't use apport-kde any more? so we could drop this?
<pitti> (it keeps causing issues from time to time, when the sip API changes again)
<pitti> ABI
<apachelogger> pitti: I have yet to figure out a plan because it's actually unmaintained from our side
<pitti> and it pullls in a gazillion build deps
<pitti> apachelogger: it's covered by tests, so it should generally work; it's not a high cost to keep it, but if you say you don't and won't use it any more, I'd rather mothball it
<pitti> apachelogger: i. e. you just don't use apport-kde, or not apport at all?
<apachelogger> pitti: it's complicated ;)
<pitti> apachelogger: without the apport libs it's probably quite some effort to craft the input files for whoopsie?
<pitti> apachelogger: heh, it always is :)
<apachelogger> in dev releases we are supposed to use apport & apport-kde
<apachelogger> in stable releases we use upstream's tool which has absolutely no ties to apport at this point
<pitti> apachelogger: ah, ok; so I suppose you'd use whoopsie in dev releases, but not stables, too
<apachelogger> pitti: actually we'd want whoopsie regardless, for the metrics
<apachelogger> so it seems we need to tie the kde tool to whoopsie/apport such that it can tell whoopsie to send a report
<pitti> apachelogger: it will need to create a /var/crash/...*.crash with the expected format, and then create the .upload stamp
<pitti> apachelogger: whoopsie only has a relatively small and fixed set of keys it looks at, so most of the extra apport fields (from hooks, etc.) aren't necessray
<pitti> apachelogger: it's mainly Executable, Package, Dependencies, Signal, Stacktrace, StacktraceAddressSignature (and perhaps a few other easy ones)
<pitti> apachelogger: ah, it doesn't need Stacktrace, but CoreDump
<pitti> it mainly uses StacktraceAddressSignature for the bucketing
<pitti> (perhaps you do want to consider using python3-apport for generating those..)
<apachelogger> yeah, was thinking that just now
<pitti> it only needs python3-apt and the lightweight python3-problem-report, so its deps shouldn't be too heavy
<ev> pitti, apachelogger: acceptable fields: http://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/whoopsie.c#L93
<pitti> ev: cheers
<apachelogger> thx
<pitti> so, StacktraceAddressSignature and Package/Dependencies (with all the "modified" checks) are certainly the most complicated ones
<apachelogger> we definitely don't want to reinvent the wheel, so using python3-apport seems certainly most sensible
<apachelogger> pitti: I also put down a todo to check where we want to go with apport-kde
<diwic> pitti, hi, do you have a moment for two questions?
<pitti> diwic: hey, how are you? shoot
<diwic> pitti, hi, sprinting in Taipei actually :-) how are you?
<pitti> diwic: and thanks for not treating me like an IP socket by saying "ping" :-P (SCNR)
<pitti> diwic: learning the "joys" *cough* of C++.. but quite well
<diwic> pitti, so first question was if you were planning to SRU the xdg_runtime_dir fix in systemd to saucy or not
<pitti> diwic: ah, it fell off my radar for a bit; upstream committed a different patch, but that might take some time to backport, so we might just as well go with our current one
<diwic> pitti, aha, so Lennart actually ended up fixing it?
<pitti> diwic: preparing SRUs shouldn't be blocked on me personally, but if noone else wants to touch it I can add it to my TODO
<pitti> diwic: yes (I thought I tossed you the commit the other day)
<diwic> pitti, nice. Can't find any email from you about it if you sent one, but glad it's fixed anyhow. So let's just see who prepares the SRU first of you and me then. But you'd still have to sponsor/SRU it I presume
<diwic> pitti, second question. So my boss wants me to deliver a feature in OSP2, which we ship in preinstalls. OSP2 is based on 12.04.4. The feature needs a backend module in PulseAudio, but the pulseaudio won't be loaded unless you run OSP2, so the regression risk is minimal for standard Ubuntu.
<pitti> diwic: http://cgit.freedesktop.org/systemd/systemd/commit/?id=954449b82df7f FYI
<pitti> diwic: sounds ok to me, but as I'm not in ~ubuntu-sru I can't give a formal approval
<diwic> pitti, really? I was sure you were. :-)
<pitti> I had been for a long time, yes
 * pitti adds ffox tab for bug 1197395 as a reminder
<ubottu> bug 1197395 in systemd (Ubuntu Saucy) "/run/user/$ID/pulse owned by root and not by the user" [Undecided,Confirmed] https://launchpad.net/bugs/1197395
<diwic> pitti, ok, so maybe I should ask one of the 10 ubuntu-sru members instead, any special one you'd recommend? :-)
<pitti> diwic: TBH I'd just prepare the bug (testing, regression info), upload it, and see who bites :)
<pitti> we don't seem to have a "primary" SRU team member these days
<diwic> RAOF, hi, want to discuss an SRU before I prepare so I know I'm doing things the right way?
<tseliot> pitti: can you approve bug #1255583 please? I'd like to upload a new nvidia-prime that depends on bbswitch
<ubottu> bug 1255583 in bbswitch (Ubuntu) " [MIR] Main inclusion request for bbswitch" [Medium,Triaged] https://launchpad.net/bugs/1255583
<pitti> tseliot: I'm not in ~ubuntu-mir
<tseliot> oh
<tseliot> didrocks: please ^
<dholbach> could somebody please approved my mail in u-d-a?
<pitti> dholbach: done
<didrocks> tseliot: hum, module-assistant is recommended by in universe
<dholbach> pitti, gracias!
<tseliot> didrocks: but m-a is in main
<didrocks> tseliot:  module-assistant | 0.11.6        | trusty/universe  | source, all
<didrocks> is it?
<pitti> we really don't want to put that on users
<pitti> we should stick to DKMS IMHO
<tseliot> didrocks: oh, right
<didrocks> pitti: agreed :)
<tseliot> shall I disable the module-assistant bit?
<didrocks> yep
<didrocks> tseliot: FYI, the MIR team is small enough to normally not treat urgent issues like that. So ensure first that the MIR really match requirements please :)
<tseliot> the debian maintainer probably won't be pleased
<didrocks> tseliot: check-mir is a good one for that
<tseliot> didrocks: the point I'm going to upload the same thing in Precise for 12.04.4 for HWE
<didrocks> tseliot: yeah, that's why I'm treating that now, but we have a huge list and a very small team, so preparing that in advance would help to not sidetrack the team (and ensuring if it's urgent that the basic checks pass ;))
<didrocks> tseliot: I'm continuing the review meanwhile, fortunately enough, it's a simple one
<tseliot> didrocks: right, I understand. I was pretty sure module-assistant was in main, I don't know why. Sorry about that
<didrocks> tseliot: check-mir FTW! :)
<didrocks> (in ubuntu-dev-tools)
<tseliot> didrocks: from now on I'll use that, thanks :)
<didrocks> yw!
<didrocks> (quite impressive the amount of override we have to make in dh_auto_install for dkms modules and that dh_dkms doesn't do it for us)
<RAOF> diwic: Sure, what are you after? My bandwidth might be limited though.
<diwic> RAOF, well, my boss wants me to deliver a feature for OSP2, which we ship on preinstalls and based on 12.04.4.
<diwic> RAOF, the feature includes a backend written as a pulseaudio module. So PulseAudio needs to be SRUed, but the module won't be loaded for normal Ubuntu users, so minimal regression risk.
<ogra_> diwic, hmm, did pulse recently change in precise ? i cant use my BT headset anymore since the last upgrade
<diwic> ogra_, when did you upgrade? The last upgrade only concerned 3.5 mm headset jacks IIRC.
<ogra_> some time last week
<diwic> RAOF, so; the easiest way for me right now would be to sidestep SRU rules and just put something into 12.04.4 without caring about future releases
<diwic> ogra_, unless someone else has SRUed PulseAudio - the 15.4 upgrade was several weeks ago if not months
<diwic> ogra_, maybe kernel regression?
<ogra_> well, i surely didnt upgrade for a month or so
<ogra_> yeah, probably
<ogra_> A2DP still works fine ...
<diwic> ogra_, pulseaudio ...15.4 was released into -updates 2013-10-03
<ogra_> ah, yeah, i surely upgraded that before then
<diwic> and that's the latest
<diwic> RAOF, but I'm not sure that's something the SRU team would agree on. I'm not sure what the solution for 14.04 would be at this point; my deadline is for 12.04.4 and upstream has kind of said no to my current way of doing the backend.
<RAOF> diwic: Does the core pulseaudio *code* change?
<RAOF> diwic: Or are you just adding an additional module without any other changes?
<RAOF> Also, what sort of guarantees do we have that the module isn't going to be loaded.
<diwic> RAOF, not core pulseaudio code. Only code changes in the module (which isn't loaded).
<diwic> RAOF, the guarantee is "the module isn't listed in /etc/default.pa".
<diwic> RAOF, the module would still ship in the Pulseaudio package though. Or possibly in a new binary package, if you prefer.
<RAOF> No, that's fine.
<RAOF> As long as it's not loaded by default that seems fine.
<diwic> RAOF, ok, thanks - would it be okay to shoot you an email when I've uploaded the SRU (which would then contain the new unused module), to have you releasing it into -updates?
<mlankhorst> RAOF: hey do you have some time next week?
<mlankhorst> I want to prepare lts-saucy
<RAOF> mlankhorst: Yeah, after Monday I'll be back not-sprinting.
<mlankhorst> perfect, I'll prepare everything for upload then
<RAOF> diwic: Wait - I can release it into -proposed; do you want to skip -proposed entirely?
<diwic> RAOF, sure, I can do -proposed verification, if somebody after that releases it into -updates
<RAOF> diwic: Right, that's fine.
<diwic> RAOF, is that you as well? I don't know the details of the shepherding here, I mostly know that I have a deadline ;-)
<RAOF> diwic: Yeah, that's fine.
<diwic> RAOF, ok, thanks a lot! Hopefully I'll finish the SRU some time next week
<didrocks> tseliot: everything is good otherwise, just tell me once the fixed version is in the release pocket
<tseliot> didrocks: sure, thanks. I've sent a message to the maintainer to let him know (trying not upset anybody)
<didrocks> thanks
<mardy> Mirv: hi! So, it looks like we'll have to cherry-pick the fix for https://bugreports.qt-project.org/browse/QTBUG-35233 into Qt 5.2.0
<mardy> seb128: FYI ^
<seb128> mardy, thanks
<seb128> does anyone knows in which condition apt lists packages with no "candidate"?
<tedg> cjwatson, Looking at upstart-app-launch's usage of click.  It seems like we need two values, the package directory and the path to the manifest.  Would it be reasonable to have a "libclick" that did those?
<tedg> cjwatson, i.e., still keep the logic in the click package, but just duplicate it in C.
<cjwatson> tedg: I plan to rewrite click in C, hopefully this cycle
<cjwatson> tedg: until then let's not duplicate
<tedg> cjwatson, Okay, perhaps a fallback if you find time running short.
<josepht> stgraber: is there a preferred way to install a set of packages when creating a container?
<pitti> I'd appreciate if some SRU team member could process bug 1257211 today; they fix a data loss bug in postgresql; usual MRE/no packaging changes/upstream+distro tests pass story
<ubottu> bug 1257211 in postgresql-9.1 (Ubuntu Trusty) "New upstream microreleases 9.1.11, 8.4.19" [High,In progress] https://launchpad.net/bugs/1257211
<stgraber> josepht: not really. The next upstream release (1.0 beta1) will introduce a new --packages parameter to the Ubuntu template but until then you're on your own
<josepht> stgraber: okay, I added a --packages parameter to the ubuntu template :)
<jdstrand_> cjwatson: hey, I just filed this-- not sure you are aware: bug #1258202
<ubottu> bug 1258202 in logrotate (Ubuntu) "recent group permissions change on /var/log cause logrotate errors" [Undecided,New] https://launchpad.net/bugs/1258202
<kees> geofft: hola? what's up?
<kees> !-ubottu
<ubottu> ubottu is <alias> ubotu - added by Pici on 2008-05-08 16:09:51 - last edited by Pici on 2008-05-08 16:09:57
<kees> !-ubotu
<ubottu> ubotu aliases: yourself, bot, usage, factoid, brain, add, help me, syntax, factoids, everything, me, ubottu, bots, fact, triggers, trigger - added by Seveas on 2006-06-19 12:15:56 - last edited by tsimpson on 2010-09-18 20:14:50
<xnox> barry: Jenkins Notification <devnull@canonical.com>
<cjwatson> jdstrand: no, perhaps slangasek can pick this up again since he uploaded the original regression? ;-)
<xnox> barry: that's the emails I used to get jenkins notifications from.
 * barry searches his folders
<pitti> barry: FYI, we used to have notifications for failed autopkgtests, but they've been broken since the DC move
<pitti> barry: (jibel knows details)
<cjwatson> aha!
<jdstrand> cjwatson: ah :)
<jdstrand> slangasek: fyi, bug #1258202
<ubottu> bug 1258202 in logrotate (Ubuntu) "recent group permissions change on /var/log cause logrotate errors" [Undecided,New] https://launchpad.net/bugs/1258202
<slangasek> jdstrand, cjwatson: doh.  How did that merge actually cause the regression, anyway?  We clearly had rsyslog configured to run as non-root before in the Ubuntu delta
<barry> pitti: ah, okay!  it's a shallow bug then :)
<pitti> barry: yeah, AFAIK stuck somewhere between firewalling and mail whitelisting
<barry> pitti, jibel cool.  at least it's on the radar.  thanks
<cjwatson> slangasek: upstream rearranged how privilege-dropping worked, so it now irrevocably set[ug]ids near the start and can't retrieve privileges when creating new log files
<jdstrand> slangasek: don't know. I see that 13.10 livecd has:
<jdstrand> /var/log                                                 drwxr-xr-x root root
<cjwatson> slangasek: I really didn't fancy undoing all that
<geofft> kees: good morning! I'd like to use LD_AUDIT on a setuid binary :-)
<geofft> kees: It looks like the disable-ld_audit patch in eglibc is not specifically a CVE fix, but just (worthwhile) paranoia/hardening while upstream got its act together about patching it right?
<geofft> Is it possible to drop that patch at this point, or is that totally unreasonable?
<bdmurray> Sweetshark: are there any plans to update libreoffice in Trusty? the package version in saucy-proposed is greater than the one in trusty.
<Sweetshark> bdmurray: its complicated
<Sweetshark> ;)
<Sweetshark> bdmurray: some toolchain updates (likely the usual suspect gcc) made LO 4.1 FTBFS on trusty, so one cant simply bump that. OTOH LibreOffice 4.2 (which we want to have in trusty anyway, but which is still in beta) builds just fine in trusty.
<Sweetshark> bdmurray: so I gotta find a way to get 4.1 to build in trusty without wasting too much time on it as nobody will care for that in two weeks anyway. Unfortunately, the breaker seems to be of the nasty kind (its in an external package we build internally in LO, so patching it would mean patching a patch into the build)
<Sweetshark> bdmurray: Ill check if we can update mdds to a version building in trusty, and then build LO 4.1 against it (thus not using an internal copy anymore). Using external mdds is would be a good thing anyway (and be worthwhile beyond 4.1) ....
<Sweetshark> seb128: ^^ FYI
<bdmurray> Sweetshark: sounds good, thanks
<bdmurray> tseliot: the bug number reference in the gnome-desktop3 changelog in the saucy proposed queue is incorrectly formatted which will negatively affect a few things in the SRU process
<tseliot> bdmurray: feel free to reject the upload, and I'll re-upload tomorrow
<hallyn> slangasek: stgraber: ok, i'm at wits end trying to get dbus across user namespaces to work.  it could be a simple issue, i don't know.  but my question is:  what is an actual advantage to using dbus versus plain unix sockets?
<hallyn> (to offset (1) 2-4x slowdown, (2) easy threading at the server, and (3) extra dependencies)
<stgraber> the main advantage I was after was the easy availability of client libraries and using something people tend to be familiar with. Suppport for things like introspection and a well defined set of types, method signatures, ...
<stgraber> though I'm certainly not against going with our own protocol if DBus simply doesn't cover our needs. As I mentioned, for me backward compatibility is the most important thing, so unfortunately even if DBus could add the features we need, getting that to work on 12.04 will be a pain...
<stgraber> so I'm personaly fine if we were to go with our own protocol over a raw unix socket. I'd just request that this be a plain text protocol with API versioning support so we don't get into the same kind of problems we had with the lxc monitor protocol (struct mismatch and breakage on upgrades)
<stgraber> but it was slangasek who suggested going with DBus, so he may have a few more important reasons :)
<hallyn> stgraber: ok, thanks.  yeah it'll be plaintext and i'll add av ersion #.  plaintext - except the scm cred of course
<rbasak> hallyn: in general, dbus is nice because it's really easy to map high level APIs down to it. You don't have to do much to get bindings.
<hallyn> rbasak: i got enough koolaid from the tutorial :)
<hallyn> rbasak: as stgraber mentioned, high level bindings will take some upstream work bc we need to send scm_crednetials
<bdmurray> tseliot: I went ahead and reuploaded them myself
<charlie> I want to start developing for ubuntu, but was wondering if its okay/suggested to develop in 14.04 daily build installation?
<charlie> I plan to start all my dev activities on a virtual box having 14.04 daily builds so that my base ubuntu 13.10 stays safe
<charlie> any ideas/suggesstions?
<hallyn> i think severalppl are using 14.04 daily already
<hallyn> i will be soon
<charlie> cool...thanks
<charlie> once installed, am i supposed to update/zsync daily?
<slangasek> hallyn: the fact that dbus is a structured IPC protocol that the rest of the stack is standardizing on... I think doing your own protocol on top of the socket is going to be harder to sell to the wider community
<slangasek> hallyn: can you give me details on the problems you're seeing with scm_credentials?  is it because the dbus library is hating on the extra packets?
<tseliot> bdmurray: excellent, thanks a lot :)
<chilicuil> charlie: you can, however if not developing ubuntu itself, I'll recommend you to update once a week on wednesday, or to avoid weekends, canonical employes rest on weekends and you don't want to keep a broken system if you upgrade on saturday or sunday
<hallyn> slangasek: scm-credentials aren't my problem.  I simply can't get a client in a child user namespace to connect to a parent socket in another userns
<slangasek> ah
<hallyn> i haven't figured out why yet,
<hallyn> all I know is that we get just past the AGREE_UNIX_FD,
<slangasek> and that works with a raw socket?
<hallyn> client sends BEGIN, server sends some data, then everyone hangs up
<hallyn> that's nih-dbus
<slangasek> hmm
<slangasek> could you show me the code?
<hallyn> well for simplicity i was using github.com/stgraber/cgmanager,
<hallyn> but the problem is'nt there, it's in either nih_main_loop or in dbus_connection somewhere
<hallyn> i tried steppig through the whole process in gdb, all that did was waste 2 hours
<hallyn> ltrace doesn't get finegrained enough
<hallyn> slangasek: iiuc the main point of dbus is that it integrates with idiotic junk^W^Wfeatures like policykit
<hallyn> which we explicitly don't want.
<slangasek> no, the main point is to provide a generic IPC mechanism that doesn't require reinventing the wheel
<slangasek> if you're talking about dbus-daemon, then policykit is an interesting feature; but you shouldn't be talking over dbus-daemon in this context
<hallyn> 'the wheel' is just listen+accept+fire off a thread.  it'll be shorter code than with dbus.
<hallyn> true
<hallyn> no bus is involved
<hallyn> do you know the authentication process well enough to know what should happen next after the AGREE_UNIX_FD?
 * hallyn looks back at the 'specification'
<slangasek> you still have to design your wire encoding for whatever messages you're passing, which is normally busywork
<slangasek> no, I'm not familiar with AGREE_UNIX_FD at all
<hallyn> well I guess it's right after http://dbus.freedesktop.org/doc/dbus-specification.html#auth-command-begin
<slangasek> hallyn: github.com/stgraber/cgmanager seems to only include the server half of the code... what do you have on the client side?  And can you give me a recipe to set up a userns for testing?
<stgraber> slangasek: my branch contains a "client" in its Makefile, basically just a simple call to dbus-send
<slangasek> stgraber: ah, ok
<hallyn> slangasek: i also did need to dbus_connection_set_unix_user_function(conn, allow_user, NULL, NULL); where allow_user always returns 0.
<hallyn> setting up a new vm since last one blew up
<hallyn> stgraber: bug 1258304 looks like your bag :)
<ubottu> bug 1258304 in lxc (Ubuntu) "lxc-create fails on IPv6 address" [Undecided,New] https://launchpad.net/bugs/1258304
<stgraber> hallyn: yeah, I saw it in my e-mails... I'll take a look once I'm done with my current tests
<xnox> hallyn: stgraber: libnih API docs http://libnih.la/   so far just the "nih" lib, will update with "nih-dbus" and "nih-dbus-tool"
<slangasek> hallyn, stgraber: so, trying this same dbus-send command against upstart gives me the same failure; and we know initctl works
<hallyn> xnox: thx
<slangasek> I think the dbus-send invocation is wrong, though I don't know exactly how
<hallyn> xnox: i'll look at those in awhile when i wanna clean up the code
<xnox> hallyn: there still might be mistakes and formatting errors, but most of the things are documented already. + there is libnih tutorial in the upstart cookbook.
<stgraber> slangasek: against upstart it's probably because we reject from uid > 0. hallyn is actually using a slightly modified version of my branch which allows all uids.
<stgraber> slangasek: it then works fine as long as you're in the same userns
<slangasek> hmm
<stgraber> xnox: yay!
<slangasek> right, upstart does reject non-root requests on its private socket
<slangasek> trying to figure out what I'm seeing here, then
<hallyn> lemme push a branch real quick that works for testing,
<hallyn> hm, how do i do that :)
<hallyn> slangasek: i'm testing effectively with github.com/hallyn/cgmanager branch usernstest
<hallyn> i can run the dbus-send as random users, but not from another user ns.
<hallyn> the credentials during auth phase all come through ok -
<slangasek> hmm, ok
<hallyn> all right i've got dbgsym packages installed, and gdb is showing me line numbers, but i'd like it to show me code as well so i don't have to keep tabbing back to the vim windows.
<slangasek> hallyn: 'directory /path/to/source'?
<hallyn> slangasek: and for dbus packages, waht does the path look like?
<slangasek> hallyn: wherever you have the source unpacked locally :)
<hallyn> slangasek: oh, i thought the dbg packages used to do some magic so i didn'thave to do that
<hallyn> ok, thanks
#ubuntu-devel 2013-12-06
<sveinse> Is there a (dpkg/dh_*) tool for listing a debian/control file's dependencies for a specific architecture? (The control file at hand contains [arch] and '|' conditions, and I'd rather avoid having to make my own parser if I can)
<geofft> sveinse: Deps, or build-deps? (Deps generally also involve ${misc:Depends} etc. which isn't really knowable without doing the build)
<geofft> For build-deps, /usr/lib/pbuilder/pbuilder-satisfydepends in some form might be useful
<sveinse> geofft: Deps. If I can get a list where ${misc:Depends} is one of them, I would be happy. It's the arch specific constraints I need to filter out
<sveinse> geofft: OOI and slightly OT, what is ${misc:Depends} replaced by normally? I always use it, but I've never asked why
<sveinse> well, for the latter, Google is a friend, so forget it
<geofft> also grep misc:Depends /usr/bin/dh_* :)
<geofft> hm, looks like last time I wanted this, I used the Dpkg::Deps perl module, which gives me a deps_parse function
<geofft> http://web.mit.edu/geofft/debathena/dh-ifexists/dh_ifexists
<geofft> (note that that command is a slightly terrible idea, I'm only posting it as sample code)
<sveinse> Do I understand things correctly that dh_* never actually parses Deps, only put it into the pkg's control file? So a dep of "pkg1[armel] | pkg2[armhf] | pkg3" is never actually parsed by dh_*
<sveinse> hmm. Seems like a custom parser is unavoidable :(
<infinity> sveinse: That has nothing to do with debhelper at all, it's dpkg-gencontrol.  But if what you want to say is "if I'm on armel, I want pkg1, if I'm on armhf, I want pkg2, else I want pkg3", you want "pkg1 [armel], pkg2 [armhf], pkg3 [!armel !armhf]" and dpkg-gencontrol filters the right ones for the right arch builds.
<sveinse> infinity: Ah, so you can put more than one constraint (e.g. [!armel !armhf]). I was looking for that in the policy manual, but could not find any about that
<psusi> xnox, just saw your comment about installing grub on fakeraid arrays.. it will need some work to keep that going with the mdadm transition... looking for that thread I started on it a while back now
<pitti> Good morning
<pitti> infinity: can I talk you into accepting the SRUs for bug 1257211? (fairly mechanical; all upstream/distro tested, no packaging changes, has MRE); it's a relatively important data loss fix this time
<ubottu> bug 1257211 in postgresql-9.1 (Ubuntu Saucy) "New upstream microreleases 9.1.11, 8.4.19" [High,In progress] https://launchpad.net/bugs/1257211
<infinity> pitti: Let me have a quick look.
<infinity> pitti: 6 of them?  Okay, a slightly less quick look.
<pitti> infinity: yeah, I'm afraid so :/ they all look the same though
<infinity> pitti: The 0 changes to debian/* is comforting.  Do the orig tarballs come directly from upstream, or get repacked in annoying ways?
<pitti> infinity: nope, straight from upstream
<pitti> shared between upstream, debian, ubuntu, and apt.postgresql.org
<infinity> Oh, heh, found one with a change to debian. :)
<infinity> (Just the update-maintainer flip)
<pitti> ah yes, first SRU to saucy
<infinity> Indeed.
<infinity> So, I think I'll just verify hashes on the upstream tarballs and call it good enough, due to the MRE.
<pitti> dpkg-buildpackage would otherwise barf at me, so update-maintainer is less annoying than always rebuilding with DEBEMAIL=
<infinity> pitti: Yeah, I always listen to dpkg-buildpackage about that too.
<infinity> pitti: Which is good, since that was the point of the policy. :P
<infinity> pitti: Right, those all match, thanks for making my life easy.
<pitti> infinity: fortunately the days when we had an upstream tar.bz wrapped in a custom debian orig.tar.gz are over with hardy being EOL
<infinity> pitti: Yeah.  I maintain packages that need to dfsg cleansing business, so it's nice to run into ones that don't. :P
<infinity> s/to/the/
<pitti> infinity: yeah, it's really quite mechanical, but always better to have four eyes on it (and cross-check that I put in the right bug number, etc.)
<pitti> of course I did *not* (no, no!) rebuild the sources ever because I accidentally put in the one for the previous SRU *cough*
<infinity> ;)
<infinity> pitti: I assume we're moving to 9.2 for trusty?
<pitti> infinity: 9.3
<infinity> Ooo, or that.  Shiny.
<pitti> infinity: I have it on my list to weed out the remaining 9.1 rdeps, and reduce p-9.1 to -plperl
<pitti> we need that for upgrades due to libperl non-coinstallability
<pitti> (similar to what I do in unstable for wheezy)
<infinity> It never ceases to amaze me that people implementing a decades-old spec keep finding new ways to add features and pump out new versions.
<lifeless> infinity: postgresql?
<lifeless> infinity: or perl?
<infinity> lifeless: psql.
<lifeless> infinity: I think they could be there another few decades; sql was a very theoretical spec, so there's huge sets of optimisations folk are only just touching on
<infinity> (That wonderment is a bit ironic, given that my largest upstream involvement is in a project implementing POSIX/SUS C)
<infinity> pitti: Alright, I think that's all of 'em.
<pitti> infinity: cheers
<pitti> I'll treat them with my p-common test torture for verification once they are built/published
<tjaalton> is there a way to add an apport hook for a project?
<tjaalton> aiui it's possible to file bugs against source/binary packages
<tjaalton> but dunno if the same is true for projects
<lifeless> pretty sure you can
<tjaalton> mainly for attaching bug logs
<pitti> tjaalton: you can add an apport hook to a package which makes bugs go to the project
<pitti> (common for e. g. PPA packages)
<tjaalton> pitti: how about private projects then?
<pitti> tjaalton: the hook can also check easily if the package is from ubuntu or not
<pitti> tjaalton: if you put it into a PPA which only people can access that can also file bugs to that private project, sure
<tjaalton> ahh, yeah that works then
<tjaalton> tammy: ^ :)
<tjaalton> pitti: thanks
<dholbach> good morning
<jibel> barry, pitti I fixed adt notifications. LP credentials had not been migrated from previous server. It is now saved in a non-default launchpadlib_dir that will make migration easier just in case this service had to move again.
<pitti> sarnold, roaksoax: is maas heavily dependent on the psql version 9.1? (I just filed bug 1258442)
<ubottu> bug 1258442 in maas (Ubuntu) "Move to postgresql-9.3" [Undecided,New] https://launchpad.net/bugs/1258442
<pitti> if it isn't very version sensitive, then I'd recommend the versionless metapackage as an alternative; if you'd rather only allow explicitly tested psql versions, then just "-9.3" will do for now (but prevent usage with newer psqls)
<tseliot> pitti: is even suggesting a package from universe prohibited for packages in main?
<pitti> tseliot: no, that's fine; suggests aren't installed by default
<tseliot> pitti: so that could work for bug #1255583, couldn't it?
<ubottu> bug 1255583 in bbswitch (Ubuntu) " [MIR] Main inclusion request for bbswitch" [Medium,Incomplete] https://launchpad.net/bugs/1255583
<pitti> tseliot: well, not really; we really want such stuff to use dkms, not m-a
<tseliot> ok, I'll tell the maintainer
<Riddell> pitti, ev: apport is off for releases right? which makes whoopsie off too?
<ev> Riddell: no
<Riddell> ev: no to which?
<ev> apport doesn't report to Launchpad post-release
<ev> but it still reports to daisy.ubuntu.com (via whoopsie)
<Riddell> ev: ah hah
<ev> sorry for the terseness there
<pitti> Riddell: more precisely, we stop sending crash reports to LP post-release; "ubuntu-bug" (i. e. no-crash manual bug reports) still works
<pitti> Riddell: I was talking to apachelogger about apport/KDE yesterday, did you see this in scrollback? (to avoid duplicate work/discussions)
<Riddell> pitti: I'm working with him now, seems apport has been broken in kubuntu for the last couple of releases and we didn't notice (because it's not used for kde apps)
<rbasak> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.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 lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: rbasak
 * dholbach hugs rbasak
<rbasak> o/
<mpt> mvo, hi, whatâs the simplest way you can think of to produce a package that Synaptic will label as âBrokenâ? :-)
<mpt> (e.g. by messing with an existing package)
<seb128> mpt, you can probably dpkg -r a depends of an installed package
<seb128> mpt, e.g sudo dpkg -r --force-depends evince-common
<mvo> mpt: indeed, what seb128 said - sudo apt-get install 4g8; sudo dpkg -r --force-depends libnet1
<seb128> that should make evince unhappy
 * mvo hugs seb128
<mpt> I think Iâll try with 4g8 rather than my favorite PDF viewer 3-)
<mvo> mpt: why do you care about synaptic?
<mpt> thanks
 * seb128 hugs mvo back ;-)
<mpt> mvo, just folloing up on an old bug report
<rbasak> Will arm64 build failures block proposed migration for unseeded packages? I'm wondering if I can upload a merge that has never worked on arm64 without fixing it.
<Laney> rbasak: They will, but only if it has built there before (same as for all architectures: https://wiki.ubuntu.com/ProposedMigration point 1.)
<xnox> rbasak: "it must not regress" in architecture list where it does succeed to be built/installable.
<rbasak> Laney, xnox: aha. Thank you!
<barry> jibel: cool, thanks
<smoser> is there any options to apt to get it to log timestamps during apt-get dist-upgrade ?
<smoser> i'd like to time an apt-get dist-upgrade and have some info on where the time goes
<hloeung> smoser: does running it using annotate-output help?
<smoser> hloeung, i was unaware of that program. i hacked something similar just now.
<smoser> thanks.
<smoser> i think log data from apt would probably be more correct. but this might suffice.
<psusi> xnox: ddf and imsm aren't quite the same... iirc, there was a check in the grub-install script to see if you were trying to install to a /dev/mapper device that was managed by dmraid, aand allow it to procee, and the grub device iterator code assigned a grub device to the array assuming it was bios accessible
<xnox> psusi: can you give me pointers in grub code?
<psusi> xnox: iirc, it was in a file named deviter.c
<psusi> xnox: and of course, the grub-install script
<psusi> xnox: I had a discussion on the mailing lists back in 2010 and I wanted a way to ask mdadm what kind of raid it is and if it is recognizable to the bios... not sure if it was ever added to mdadm
<xnox> psusi: there is now, --detail-platform or somesuch, which will print / notify if there are bios recognisable raid devices (that is ddf/ISW controllers that are recognised on boot)
<xnox> psusi: subsequently one can start that controller as "container" and see which raid arrays are defined within it, and thus confirm that those raid arrays will be available on boot.
<psusi> xnox: the idea is that if you run grub-install /dev/md0 and mdadm says it's a bios recognizable array, then go ahead with installing, and assume it's (hd0) or some other number
<psusi> ohh, and there was some logic somewhere to figure out whether grub needs the raid module.. it doesn't if it's a fakeraid
<psusi> that was based on where /boot is.. if /boot is on a software raid, it needs the raid module, fakeraid, it doesn't...
<xnox> psusi: i've tried grubinstall patch from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699434 but it didn't work for me on an ISW/RAID0
<ubottu> Debian bug 699434 in grub-installer "grub-installer: support for Intel Matrix Raid" [Normal,Open]
<xnox> psusi: i see. that patch added a dummy echo "(md/0)	$md_bootdev" >> $ROOT/boot/grub/device.map
<xnox> which imho is fragile, given that i can have multiple raid devices regornised on boot.
<psusi> things are a bit muddied by the fact that Ubuntu is still carrying patches to auto assign grub devices and not use device.map
<xnox> (e.g. one for windows and one for debian/ubuntu)
<cjwatson> device.map is deprecated, please don't add new stuff relying on it
<cjwatson> psusi: that statement is exactly the opposite of reality ...
<psusi> it is?
<xnox> cjwatson: right. what should be used instead of device.map? and how can i make it recognise "fakeraid ISW and DDF" properly?
<cjwatson> psusi: upstream removed grub-mkdevicemap altogether; Ubuntu is carrying patches to put it back because we needed it for some packaging-level code
<xnox> (or verify that it does / doesn't)
<pkern> Hey. Ubuntu Trusty uses :powerpc specifiers in dependency fields. Is there a spec for that? (Allowing cross-arch deps.)
<psusi> I thuoght last time I asked about why I couldn't find deviter.c upstream you said it was ubuntu specific?
<cjwatson> psusi: the use of device.map is deprecated
<xnox> pkern: :arch are not allowed, where is that? one is allowed to use :any in the Depends:
<cjwatson> psusi: indeed, but its purpose is not as you describe.  the purpose of deviceiter.c is to help generate device.map - i.e. it's part of grub-mkdevicemap
<xnox> pkern: and :any is allowed in Debian as well.
<pkern> That's not my question.
<psusi> cjwatson: I thought it was also used to generate the temporary in memory map so that grub-install could figure out what device is what
<cjwatson> psusi: no
<pkern> xnox: crossbuild-essential-powerpc
<pkern> Depends: libc6-dev:powerpc
<psusi> then how does grub-install decide what grub device to reference?
<psusi> I could have sworn that was from deviceiter.c assigning an (hdX) to each disk and an (mdX) to each raid array, etc...
<cjwatson> xnox,psusi: ok, so.  there are two cases.  for the userspace tools, mostly all we need to be able to do is check whether two devices are the same.  for that, it's sufficient to just have an arbitrary sequence that's stable within the run of a given tool.
<xnox> pkern: right, that package is a bit special (no wonder it gets stuck in britney proposed migration). The spec is https://wiki.ubuntu.com/MultiarchSpec but at the moment officially supported/endorsed suffixes are ":any" in Depends: in both ubuntu & debian.
<pkern> xnox: We're parsing dependencies and our mirroring of trusty is stuck, too.
<pkern> It makes sense to me but if you didn't intend to allow it...
<xnox> pkern: the fact that :$arch works is nice, but it relies on one adding foreign-arch and have archives available for it.
<pkern> Doesn't it "just work" if you have ppc in your cache?
<pkern> Yeah, I know that.
<cjwatson> xnox,psusi: the other case is for generating config files (i.e. things that will be used at boot time).  for that, we actually don't care whether we know what the GRUB device names are; we generate some in a best effort kind of way, but what we actually depend on in reality is "search --fs-uuid".
<psusi> cjwatson: right... and deviceiter.c generates that arbitrary sequence... but without that, then there would be no (hd0) unless you have a device.map wouldn't there?
<pkern> People didn't like that for the qemu case.
<xnox> pkern: well, we rely on it to enable cross-compilation with multiarch enabled.
<cjwatson> psusi: that's not true, the grub userspace tools will synthesise an arbitrary sequence if you don't have a device.map
<cjwatson> psusi: and in practice this will all be fine
<xnox> pkern: in the cross-build-depends package only as it seems at the moment. no other packages should be doing it...
<psusi> cjwatson: I thoguht they did that using the code in deviceiter.c
<xnox> pkern: i wonder if wine started doing it as well or not.
<cjwatson> psusi: nope
<pkern> xnox: I don't have a problem with cross-amd64-i386 stuff, because we enable both. :P
<cjwatson> psusi: deviceiter.c is essentially a doomed effort to guess what order devices will be iterated in at boot time; we try rather hard to avoid actually relying on it for anything important.  it's basically stub code
<psusi> I'm confused.... "synesis an arbitrary sequence if you don't have a device.map" is what deviceiter.c does, isn't it?
<xnox> pkern: for parsing, it is save to strip ":*" from the package name, to get the package name only.
<xnox> pkern: the ":*" is arch qualifier in dpkg.
<pkern> I know. This is about validation.
<cjwatson> psusi: no, deviceiter.c walks through all the devices it can think of on your system and assigns a sequence that way.  what I'm talking about is basically just a simple counter incremented each time a tool notices a device it hasn't seen yet.
<pkern> We don't want to accept stuff which might break later. And the dev argues with me that I should find out if that presence is not a bug.
<cjwatson> psusi: except in grub-mkdevicemap, we no longer try to go and aggressively discover all block devices on your system, which is what deviceiter.c was trying to do.
<cjwatson> (in userspace, that is)
<pkern> xnox: So if it's going to stay and not a mistake and cjwatson fixes up britney, I shall communicate that. :P
<pkern> (This is not a question with Debian background, fwiw.)
<cjwatson> pkern: I gave up on fixing it properly in britney, I just fauxpkged it
<cjwatson> or something similar
<psusi> cjwatson: so for fakeraid, somewhere it needs to decide whether the device /boot is on should be designated (mdX) or (hdX)... where is that?
<cjwatson> psusi: grub_util_get_grub_dev I believe
<xnox> pkern: it is here to stay. in fact all packages can be refered to with :$arch suffix, dpkg inplicitely uses native-arch or any it can find when not specified.
<psusi> xnox: there you go
<xnox> psusi: let me catch up on the grub conversation.
<psusi> xnox: just the last bit that was important... sounds like it's grub_util_get_grub_dev you'll need to modify
<cjwatson> there's already an IMSM test nearby
<cjwatson> to avoids tagging it as the RAID abstraction if it finds IMSM
<psusi> cjwatson: ahh, I thought the existing code looked for dmraid ( /dev/mapper ) and would need modified for the mdadm switch
<cjwatson> which would have the effect of making it be (hdX)
<pkern> cjwatson, xnox: Thanks.
<cjwatson> psusi: you're in part describing old code, I think
<psusi> figures ;)
<cjwatson> psusi: there's certainly some mdadm code in here already
<psusi> last time I was looking at this was apparently 2010
<cjwatson> xnox: if you're looking at this, please look at git master, not our current packaging; I'll be switching to a snapshot soon
<cjwatson> and there's better support for grabbing stuff from subprocesses in master anyway
<cjwatson> http://git.savannah.gnu.org/gitweb/?p=grub.git
<xnox> cjwatson: right, and grub-installer patches are against wheezy. I'll just shelf installing onto IMSM patches for now, until snapshot arrives.
<xnox> cjwatson: grub are rebels =) not using the GNU DVCS ? =)
<cjwatson> switched away recently
<psusi> very few gnu projects use it ;)
<cjwatson> I think emacs is the main big one left
<xnox> psusi: the only important one does.... yeap emacs.
<pkern> Just use vi.
<xnox> pkern: M-x viper-mode
<xnox> latest Microsoft ergonomic keyboard is sooo emacs friendly =)
<pkern> I tried that. I was not convinced. And apparently it's despised by many.
<psusi> I couldn't be chatting with you on irc while running two shells, editing code, and have my git commit log entries pop up in a window with vi ;)
<ogra_> pkern, huh ? shouldnt you promote gobby ?
<xnox> pkern: the new one? sculpt?
<pkern> vi with youcompleteme \o/
<pkern> ogra_: If gtksourceview had vi keybindings.
<ogra_> :)
<pkern> Also apparently the market decided that web apps are better than desktop apps.
 * psusi goes back to reading IEEE 802.3
<cjwatson> youcompleteme> interesting
<xnox> cjwatson: grub.git looks very sane will try it out. thanks a lot.
<xnox> jcastro: can you please reopen http://askubuntu.com/questions/59475/how-to-correctly-add-a-fake-raid-entry-to-fstab for me?
<xnox> jcastro: i'll provide a proper answer in a second.
<jcastro> on it
<jcastro> xnox, done
<rbasak> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.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 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:
<bdmurray> slangasek: I've tested a change to update-manager to support an upgrade from Q to T per some discussion at vUDS.  Basically, upgrader only wants to upgrade from Q to R so I could hard code something to have it allow upgrades from Q to T and only put that in update-manager in raring-proposed.  Or maybe do something smart with a switch for update-manager.
<seb128> could somebody review aptdaemon in the trusty SRU queue? it should fix the most report e.u.c error on the daily view
<bdmurray> seb128: saucy?
<seb128> ups, yes, sorry
<seb128> bdmurray, you uploaded so I guess you can't review
<bdmurray> seb128: yeah, I'd prefer not to review it
<seb128> slangasek, isn't friday your SRU day? ;-) that's an easy few liner of python changes
<seb128> bdmurray, slangasek: btw not sure if you saw, but I would appreciate a review from you on https://code.launchpad.net/~seb128/apturl/dont-decode-str/+merge/197804 (you wrote that code/changed it)
<bdmurray> seb128: I'll have a look at it today
<seb128> bdmurray, thanks
<jamesh> no godoc in the new golang packages :(
<stgraber> cjwatson, slangasek, mdeslaur, hallyn_: hey, so I'm playing with unprivileged containers and I currently can't ssh in because pam_loginuid is failing (/proc/self/loginuid isn't writable in a userns). How bad would it be to change that specific plugin from required to optional?
<cjwatson> Apart from things just not generally working as well, the main effect I can think of which could cause problems would be that getlogin() would return "root"
<cjwatson> Of course if /proc/self/loginuid isn't writable it's not clear what we could do about that
<ersi> Kind announcement: Today is the last day to do the FLOSS survey 2013: http://floss2013.libresoft.es/
<ersi> (In particulary aimed at FLOSS contributors)
<hallyn_> getlogin uses loginuid?  what did it do before loginuid existed?
<cjwatson> dunno, I'm just going by bug 1067779
<ubottu> bug 1067779 in shadow (Ubuntu) "missing pam_loginuid.so breaks getlogin()" [High,Confirmed] https://launchpad.net/bugs/1067779
<stgraber> http://paste.ubuntu.com/6530814/
 * stgraber goes to look at that bug report
<stgraber> hmm, I can't seem to reproduce what the reporter describes with my test...
<hallyn_> stgraber: cjwatson: well I guess say the word if http://lkml.org/lkml/2013/12/4/156 becomes more important
<hallyn_> but loginuid had a purpose, and letting a contaienr set it seems wrong
<hallyn_> i've not looked closely at the patchset though
<hallyn_> yet :)
<stgraber> hallyn_: so I'd definitely prefer it if we could get a kernel fix instead of having to patch userspace (I'd love to save myself all the backports ;)). It doesn't seem entirely unreasonable to let uid 0 in a userns set loginuid as confusing as that may be when looked at from the outside.
<hallyn_> stgraber: slangasek: so, sorry, i finally realized that dbus from a userns is getting a REJECTED EXTERNAL DBUS_COOKIE_SH<...>  where in same userns it gets OK there
<hallyn_> stgraber: it's nto about being confusing,
<hallyn_> it's about knowing the uid which "owns" the tasks
<hallyn_> but ok, i'll aim to take a look in a bit.  though i really have to spend some time on qemu soon
<stgraber> hallyn_: the whole concept of owernship becomes blurry once your user owns a few thousands uids ;)
<stgraber> ownership too
<hallyn_> not my pirate ship though
<mdeslaur> stgraber: would this help any? https://git.fedorahosted.org/cgit/linux-pam.git/commit/?id=45cdd2489e68465c2d2202370c350069d2a391b8
<hallyn_> stgraber: so my uneducated guess is that the sha1 cookie which the dbus client sends hashes up its uid!
<hallyn_> stgraber: rsince client's uid is not the uid that the server end sees, that fails
<hallyn_> mdeslaur: you an expert on dbus auth?
<mdeslaur> hallyn_: nope, sorry
<hallyn_> mdeslaur: know anyone who is?
<mdeslaur> tyhicks: do you know how that works? ^
<stgraber> mdeslaur: I doubt it... in our case, loginuid is already set to -1 (well, 4294967295) as the actual uid can't be mapped to the userns. So even with that change, pam_loginuid will still attempt to set it to the right value (1000 in my case) and fail with permision denied
<tyhicks> mdeslaur: nope, I haven't looked at that before
<hallyn_> ok thanks - i'll read over http://dbus.freedesktop.org/doc/dbus-specification.html again
<mdeslaur> stgraber: ah, ok
<hallyn_> "Thus the security of DBUS_COOKIE_SHA1 depends on a secure home directory"  <--  not good
<stgraber> mdeslaur: if it's too hard to fix in the kernel and can't be done for 14.04, then I think the fallback will be to patch pam_loginuid to ignore (just log) failures to write to loginuid, then SRU that change to all releases.
<stgraber> that'll still prevent anyone from running non-Ubuntu containers in a userns though, so I'd love to avoid that...
<hallyn_> slangasek: ^ unless there's another auth mech i can use, this may mean that dbus can't be used for the cgmanager (^)
<hallyn_> stgraber: i'll look at the patchset this afternoon.
<stgraber> hallyn_: I guess you'll need to talk to the kernel team too because with the 3.13 merge window closed, it's doubtful we'll get that change in our kernel from upstream, so we'll need to apply that set ourselves and/or cherry-pick once that's upstream
<mdeslaur> stgraber: would that be pretty much the equivalent of setting it as optional? or is there a way for you to only the failure only in an unprivileged container?
<slangasek> bdmurray: wouldn't you want the behavior change SRUed into Q rather than into R?
<hallyn_> or maybe i can disable auth?
<stgraber> mdeslaur: it'd be similar to setting it as optional but with the benefit of not having to patch all packages that ship their own pam profile
<slangasek> seb128: yep, SRU day for me today
<bdmurray> slangasek: right, my mistype
<mdeslaur> stgraber: I suppose ignoring the error only if it's not writable is better than setting it as optional, now that I think about it
<stgraber> mdeslaur: yeah, that was my thought too. The only case you'd get a permission denied in is userns or if another MAC is preventing writes to the path, in all those cases, it's fine to ignore I think.
<slangasek> stgraber: I don't think changing loginuid to optional is reasonable; anyone who wants loginuid expects it to work reliably, and you don't want all errors to be silently ignored
<seb128> slangasek, hey, great ;-)
<hallyn_> +1
<slangasek> hallyn_: auth mech> hum, ok then. :/
<slangasek> bdmurray: right - so I think that's a reasonable strategy
<stgraber> slangasek: how about only ignoring permission denied (with a suitable log message)? (only discussing this as a fallback if hallyn_ can't get us to ship the audit userns kernel patch)
<slangasek> stgraber: if loginuid is failing with a permissions error, and it's wrong to change the kernel to allow the operation, then I think pam_loginuid needs to be changed to not fail under those circumstances
<cjwatson> Yeah, I think it would be a design error to do that in all the services
<bdmurray> slangasek: Just having a version of update-manager that supports Q to T upgrades hanging out in -proposed? or also requiring a command-line option for that to work?
<stgraber> slangasek: ok. I think the implementation would be something like "ignore permission denied when writing loginuid if loginuid doesn't belong to the owner of the process" which should be specific enough to only match the userns case in reality.
<stgraber> gah no, won't work... I was vaguely hoping uid -1 would own loginuid but that's not the case... it appears as owned by the process owner but just isn't writable...
<slangasek> bdmurray: hmm, do we want it to go straight from Q->T, or should it be Q->S?
<stgraber> anyway, will only spend more time thinking about the workaround if hallyn_ doesn't manage to get us the kernel fix
<slangasek> bdmurray: since R goes EOL before Q, but S does not
<slangasek> (I'm asking because I don't remember what we discussed)
<slangasek> stgraber: ok, sounds good
<bdmurray> I believe we discussed to T because Q was closer to P the last lts
<stgraber> slangasek: from what i remember of the upgrade testing vUDS session, we said P -> T and Q -> T
<slangasek> ok.  I thought maybe we did it because Q->S only buys you 3 more months of support before you have to upgrade again
<slangasek> 12.10 (Q) EOLs in 14.04, 13.04 (R) EOLs in 14.01, 13.10 (S) EOLs in 14.07
<slangasek> so we can't offer Q users to upgrade to T until T releases
<slangasek> right?
<slangasek> which means it's already EOL at that point
<slangasek> so I think we actually need to do Q->S instead
<bdmurray> don't we control the day 12.10 goes EOL?
<stgraber> if it's just a matter of days, it'd be better to postpone the 12.10 EOL a bit than have to SRU every single LTS to LTS fixes to S...
<slangasek> bdmurray: yes, but we don't want users of 12.10 to be /stuck/ on 12.10 from January to April
<slangasek> which is what they'll be after 13.04 goes EOL
<bdmurray> ah, got it.  okay from Q to S then, but the requiring a command line option still remains.
<slangasek> yeah, I think we shouldn't require a commandline option
<slangasek> we should just flip the switch when R goes EOL
<bdmurray> slangasek: and does move the package from -proposed to -updates count as "flipping the switch"?  The potential issue is people unexpectedly upgrading from Q to S instead of R if they use the version of update-manager from -proposed.  I guess it is rather close to R's EOL though.
<slangasek> bdmurray: yeah, I would count -proposed->-updates as flipping the switch, and think it's ok to have users who have -proposed enabled and who upgrade wind up skipping R
<hallyn_> slangasek: so in a userns the client gets http://paste.ubuntu.com/6531031/ - whereas not in a userns, in place of the first REJECTED msg it gets an OK.  I note the client DOES seem to get past auth, as it gets AGREE_UNIX_FD.  <shrug>
<bdmurray> slangasek: oh, that'll mean an SRU for the saucy release upgrader too
<slangasek> hallyn_: so... the cookie is rejected, but the auth succeeds?  hmm.
<slangasek> hallyn_: at this point I'd say we need the dbus upstream mailing list
<slangasek> bdmurray: right, I figured that would be the case
<hallyn_> grrr
<hallyn_> hm, and now i get Failed to open connection to "session" message bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
<hallyn_> oh, nm, user error
<hallyn_> slangasek: ah, going by http://lists.freedesktop.org/archives/dbus/2008-May/009761.html and http://lists.freedesktop.org/archives/dbus/2008-May/009831.html it seems I'm "walking on experimental ground"
<hallyn_> but yeah i guess i may have to mail upstream to get their "Why tf would you want to do that"
<slangasek> hallyn_: long-running experiment, what is this, CERN? :)
<slangasek> or the dbus pitch drop
<sarnold> hahaha
<hallyn_> new insight - the first step done by both is to attempt AUTH EXTERNAL.  But the working one sends AUTH EXTERNAL 31303030, while the broken one sends AUTH EXTERNAL 30
 * sarnold idly wonders how many free software projects have been started _and_ stopped in the time between two pitch drop events...
<slangasek> sarnold: all of them!
<slangasek> (well, all the defunct ones anyway :)
<sarnold> slangasek: that's gotta say something about our attention span!
<sarnold> poor poor multics.
<sarnold> at least fortran and cobol are going strong :)
<hallyn_> and now my laptop shut itself down (thermal) during release-upgrade to trusty.  nwo drops me at grub-rescue
<hallyn_> maybe it's time to get a chromebook
<zer0def> why hello there! any fglrx package maintainers here by any chance? ;)
<zer0def> eh, i'll just mail the proper person - at least then i can count for getting sh...tuff done
<zer0def> ok, so apparently i should mail the core dev list, which i'm not going to do, so i'll just leave it here: any fglrx packages providing drivers (be it fglrx or fglrx-updates) provides virtual packages opencl-icd and libopencl1 - would be kind if someone handled this in a timely manner; would definitely save future users some torn hair, despite this issue sitting in limbo for 2+ years
<tarpman> zer0def: I think you might be looking for tseliot, but he seems afk
<zer0def> eh, i don't care, i've already moved on from ubuntu a long time ago
<zer0def> just trying to prevent others from violating their heads too much
<zer0def> especially since there's no good reason for denying people the ability to dev opencl using amd cards on ubuntu
<zer0def> well, at least those who rather stick to repository packages rather than do their thing.
<zer0def> anyway, message delivered; cheers
<hallyn_> stgraber: slangasek: http://lists.freedesktop.org/archives/dbus/2013-December/015867.html
<Noskcaj> Is a faster build really enough to not sync sdcc from debian? This issue is now partially fixed anyway
<Noskcaj> BenC, Can you check if sra-sdk is syncable? I didn't really understand why you made it x86 only
<infinity> Noskcaj: https://buildd.debian.org/status/package.php?p=sra-sdk <-- Should make it obvious why it's x86-only.
<Noskcaj> thanks
<infinity> Noskcaj: Also, no point in syncing it when it's FTBFS even on i386. :P
<hallyn_> stgraber: regarding loginuid in userns,
<hallyn_> hm, hold on
<hallyn_> well, yeah.  so (1) everywhere I am, it seems to be unset, and (2) once it is set it should not be re-setable;  so
<hallyn_> if it's so crucial thaqt it be set, then it should be set on all my logins;  and in that case, starting a container would m ean all those tasks would have my loginuid,
<hallyn_> so the conatiner wouldn't be able to set it anyway
<hallyn_> so i'm confused
<infinity> Noskcaj: That said, once the i386 FTBFS is fixed, it could be synced and just fail on !x86, I'm fine with that.  I think Ben was probably just on a crusade to remove the red from the FTBFS list. :P
<Noskcaj> ok
<Noskcaj> Is anyone around willing to give me a testimonial for MOTU? https://wiki.ubuntu.com/Noskcaj#MOTU
<hallyn_> hm, how does this 'loginuid_immutable' kernel 'feature' work?  boot cmdline?
<stgraber> hallyn_: yeah, it seems like it's only getting set for ssh sessions at the moment and soon for jobs started by at
<stgraber> hallyn_: /proc/self/loginuid sure seems to be writable here...
<stgraber> hallyn_: oh but indeed write once
<stgraber> hallyn_: I'm just surprised that as a regular user I can echo any value in there though ;)
<hallyn_> even ssh isn't doing it for me
<hallyn_> (that's precise though)
<stgraber> it sure does here (on precise)
<stgraber> stgraber@shell01:~$ cat /proc/self/loginuid
<hallyn_> wonder what the difference is
<stgraber> 201105
<hallyn_> serge@ac100:~$ ssh hetzner.hallyn.com cat /proc/self/loginuid
<hallyn_> 4294967295serge@ac100:~$
<hallyn_> now,
<hallyn_> ok yeah in ubuntu we don't set the immutable flag - so root can clear out your loginuid.
<hallyn_> if that were set, then even root could not
<hallyn_> all in all, this has a use case - but to us, the way things are set up, it's useless
<hallyn_> so i think we should simply go with the workaround you and mdeslaur were talking about
<hallyn_> the 20 patch audit patchset doesn't even include a fix for loginuid!
<hallyn_> just prep work :)
<stgraber> hmm, ok
<stgraber> the main issue with the workaround is the need to apply it to all Ubuntu releases and to any other distro we wish to run in a userns
<stgraber> hallyn_: is there an easy check I can do to detect whether we are in a userns or not? ideally I'd like to avoid ignoring all EPERM and only ignore them when in a userns
<hallyn_> well you can compare /proc/$$/ns/user stat.st_ino, or just check for '0 0' in uid_map
<hallyn_> (0 0 4294967295)
<stgraber> hallyn_: I guess I'll have to parse uid_map, I can't find a good way to determine whether I'm in the host namespace or not based on stat.st_ino of ns/user
<hallyn_> hm, yeah, i was thinking of a server in init_user_ns (bc that's my mindset this week :)
<stgraber> anyway, it's not too difficult, check if the file exists, if it does, open it and read the first 3 char, if that's '0 0', we're in the host namespace
<hallyn_> well i think someone *could* mess with you and create an ns with 0 mapped to 0, but only 1 uid :)
<hallyn_> but i don't think you care about them.
<stgraber> well, if 0 is mapped to 0, then we're still actual root so should try to write loginuid
<hallyn_> they'll fail
<hallyn_> !init_user_ns so no capable(CAP_SYS_AUDIT).  (it's not ns_capable(ns, CAP_SYS_AUDIT))
<ubottu> hallyn_: I am only a bot, please don't think I'm intelligent :)
<hallyn_> \sorry ubottu
<stgraber> hallyn_: fine, I'll specifically look for '         0          0 4294967295' then, that should do it :)
<stgraber> hallyn_: uid_t is guranteed to always be uint32 right?
<hallyn_> stgraber: well there is uid16 support somewhere...
<hallyn_> no that's just legacy syscalls
<hallyn_> shouldn't affect /proc
<stgraber> hallyn_: good, so I don't need to care about it and can hardcode 4294967295 :)
<charlie> first timer.. cannot bzr init-repo.... getting Permission Denied (Public Key) error..help
<hallyn_> charlie: usually when i get that it means i've not added my launchpad ssh key ito my ssh-agent keychain
<charlie> how i do that?
<charlie> nvm...got it ...thanks
<charlie> :( am still getting the permission denied error, even after adding the ssh key
<hallyn_> sorry, don't know then.  you've done a bzr lp-login?
<Noskcaj> Can someone please rebuild ceilometer, it failed because a dependency was building
<charlie> ya
<infinity> Noskcaj: The verb you want is "retry", not "rebuild".  The latter implies someone reuploading it.
<Noskcaj> infinity, oh, ok. Thanks
<hallyn_> infinity: so the arm64 patchset needs some work.  i'll likely drop it altogether from 1.7 until i get the set under control, since it appears to be introducing regressions in other arches
<infinity> hallyn_: Ahh, that's a shame.  I guess I can abuse that PPA build for now if I need it.
<bdmurray> stgraber: is looking for "debconf (developer)" in ubiquity debug logs a reasonable way to see if ubiquity was run in debug mode
<stgraber> bdmurray: I'm not sure, I haven't seen one of those logs in a while, but if that's a string that appears whenever we see a debconf transaction that'd be good
<stgraber> hallyn_, slangasek: that patch appears to do the trick for me, opinions? http://paste.ubuntu.com/6532325/
<bdmurray> stgraber: bug 986550 (reported by you) looks to me like it was run in debug mode
<ubottu> bug 986550 in ubiquity (Ubuntu) "Ubiquity crashes with "Illegal instruction" right after starting the slideshow" [Medium,Confirmed] https://launchpad.net/bugs/986550
<stgraber> bdmurray: yeah, that was in debug mode, so yes, looking for "debconf (developer)" should work
<bdmurray> stgraber: okay, thanks!
<hallyn_> stgraber: I would change it just a hair - skip the access() check, and do check return value of open()
<hallyn_> otherwise looks good - thanks
<slangasek> stgraber: you seem to have some extra unused variable declarations (fd_uid, count_uid).  Also, please get upstream eyeballs on this, I don't want to change the behavior of such a core security-sensitive module out of sync with upstream
<stgraber> slangasek: oops, nice catch, I meant to use those...
<stgraber> hallyn_: hmm, good point, will do
<slangasek> stgraber: well, I think they're unneeded so better to drop them :)
<stgraber> slangasek: no, they are needed as I don't want to override the existing ones.
<slangasek> stgraber: you don't need two 'fd's, this code path is only used when fd < 0
<stgraber> slangasek: doh, yeah, you're right and count is also unused in that path, so yeah, I can just reuse them
<hallyn_> slangasek: pshaw, if loginuid was so critical then something other than ssh shoudl be setting it :)
<hallyn_> (but i'm curious to hear upstream response)
<slangasek> hallyn_: well, we aren't heavy users of auditd out of the box in Ubuntu, but there are those who do feel strongly about it :)
<sarnold> lol
<slangasek> and while stgraber's change looks correct to me, messing this up would give us quite the black eye ;)
<hallyn_> yup i'm curious to hear the response
<Noskcaj> Is there a way to test if glew 1.10 is safe to merge?
#ubuntu-devel 2013-12-07
<slangasek> Noskcaj: test all of its reverse-dependencies for buildability and usability? :)
<Noskcaj> i'll take that as a "Someone will do it eventually"
<stgraber> hallyn_, slangasek: updated version: http://paste.ubuntu.com/6532431/
 * stgraber prepares an email to upstream
<hallyn_> stgraber: one more thing though, the %m may be misleading in your error msg
<hallyn_> you say 'unable to open /proc/self/loginuid' but the errno is for uid_map open
<stgraber> hallyn_: hmm, yeah, I should probably just hardcode "Permission denied" in there instead
<sarnold> stgraber: what happens if the uid_map file contains e.g. "         0          0 4" (no newline)
<hallyn_> sarnold: well if it's a count of 4 then you're in a non-init userns
<hallyn_> the procfile always gives you a newline
<stgraber> sarnold: so that value isn't supposed to be possible since the \n is guaranteed by the kernel if the file exists, but if for some weird reason that were to happen, the pam plugin will fail and prevent the session from opening
<sarnold> hallyn_,stgraber, thanks :)
<slangasek> stgraber: note the inconsistent style of checking fd < 0 in one place, fd != -1 in another; suggest making the second one fd >= 0
<slangasek> stgraber: otherwise LGTM
<stgraber> slangasek: ok, did that change and sent the e-mail upstream. I tried to subscribe to their list but I apparently need approbation for that, so it may be a few days before my e-mail actually hits the list...
<xnox> tarpman: .... and we do provide opencl-icd / libopencl1 packages already..... (with most dependencies correct these days, there might be some left)
<tarpman> xnox: no idea about his particular issue... just trying to be helpful. bug 763457 still shows fglrx as affected, maybe it's out of date.
<ubottu> bug 763457 in nvidia-graphics-drivers (Ubuntu) "please provide opencl-icd virtual package" [Medium,Confirmed] https://launchpad.net/bugs/763457
<hallyn_> infinity: oh goodie, pmaydell thinks the amd64 patchset should be upstream in a month or two (and suggests waiting for that)
<infinity> hallyn_: arm64, surely. ;)
<Noskcaj> Can someone take a look at lp:~noskcaj/ubuntu/trusty/php5/merge and tell me what i'm doing wrong?
<Noskcaj> please
<hallyn_> infinity: lol, yes.
<hallyn_> technically aarch64, as that's what the binary will be called apparently
<infinity> hallyn_: Bah.  Fine. :P
<hallyn_> hey - less chance of me mis-typing amd64 :)
<cjwatson> slangasek: http://lists.debian.org/debian-dak/2013/12/msg00003.html FYI
<slangasek> cjwatson: \o/
<voldyman> hey guys, where can i get in touch with indicator applet developers ?
<ekarlso> what is a good practice for packaging up java stuff ?
<brainwash> voldyman: try #ubuntu-desktop
<voldyman> thanks brainwash
<Noskcaj> I'm trying to merge php5, can someone tell me what i've done to cause http://paste.ubuntu.com/6536413/ ?
<infinity> Noskcaj: Did you talk to rbasak before trying to merge it?  He's been maintaining and merging it in Ubuntu.
<Noskcaj> infinity, xnox has said "please take" on MoM, i'll leave it for rbasak if he wants to
<infinity> Noskcaj: I've said it before, but I'll point it out again.  Submitting complex merges for review/sponsorship is a bit of a waste of time, as your sponsor needs to do the work all over again just to verify it was done correctly.
<Noskcaj> ok
<Noskcaj> I don't think i've ever heard that, makes sense though
<slangasek> stgraber: so the other day, you said that cgmanager would mount /sys/fs/cgroup.  Why is that?  We already mount it today via mountall
<stgraber> slangasek: cgmanager will potentially start before mountall (our only dependencies are /proc, /sys and /etc), besides we need to care about distros that don't have mountall (android being the one I have to care about with my LXC upstream hat on).
<stgraber> it's certainly reasonable to check if it's already writable though, so if something beats us to mounting a tmpfs on it, we'd just use that
<Noskcaj> because of bug 76983 can we drop add-apt-key from the archives?
<ubottu> bug 76983 in gnupg (Ubuntu) "Doesn't create settings correctly on first start" [Medium,Fix released] https://launchpad.net/bugs/76983
<sveinse> I'm working on testing some embedded debootstrapped image (in qemu). What is the minimal packages needed for i386/amd64 to boot?  grub2 + kernel?
<slangasek> stgraber: why should cgmanager /need/ to start before virtual-filesystem?
<stgraber> slangasek: it doesn't have to start before virtual-filesystem but it could since its requirements are the same as upstart's own requirements (and therefore it doesn't need anything mountall mounts). So given that, why not have it start before mountall, therefore allowing very early boot jobs to use cgroups too?
<slangasek> stgraber: because we said that upstart would handle queuing cgroup-using jobs until cgmanager was available... so there's no reason to worry about starting cgmanager any earlier than virtual-filesystem
<slangasek> there are no early boot jobs earlier than mountall
<stgraber> slangasek: did we actually agree on doing the queueing? I thought we agreed that this would come with a ton of problems and that we agreed to just block all jobs until cgmanager is ready (unless upstart isn't built with cgroup support or is started with --no-cgroup)
<slangasek> blocking all cgroup-using jobs
<slangasek> but the only job that needs to start is mountall
<slangasek> which won't use cgroups
<slangasek> so your order is upstart->mountall->virtual-filesystem->cgmanager->everything else
<stgraber> anyway, that's nitpick and I don't particularly care. In the end, cgmanager will always attempt to mount /sys/fs/cgroup as a tmpfs if it's not writable as we need that for other distros. Whether Ubuntu uses that specific code path or not isn't very important.
<slangasek> and I would much prefer this over adding mount handling to other jobs
<slangasek> ok
<slangasek> right, it's fine for cgmanager to /have/ mount support, but it's important that the mount handling in Ubuntu not be spread out in difficult-to-diagnose ways
<stgraber> the cgroupfs mounts themselves will be done by cgmanager in any case, so there'll always be a bit of difficult-to-diagnose with cgmanager, but yeah, I don't really care who ends up mounting /sys/fs/cgroup itself
<Noskcaj> asac, Can you update ModemManager in debian to 1.0.0
<hallyn_> slangasek: stgraber good news, I think I've got userns cnonectiosn over dbus working.
<hallyn_> (going afk again now - ttyl)
<slangasek> whoo :)
<slangasek> hallyn_: right, and the reason adding it to your message bus .conf doesn't help is because you're not using the bus :)
<hallyn_> slangasek: right :)
#ubuntu-devel 2013-12-08
<asac> cyphermox:
<asac> 21:44 < Noskcaj> asac, Can you update ModemManager in debian to 1.0.0
<asac> :)
<cpg> hi, is there some sort of generator to build a skeleton of a deb?
<infinity> cpg: dh-make
<manchicken> Is there a better way of getting a debug build of libapt-pkg other than building the source package for libapt with debugs on and installing it?
<manchicken> I can't find a -dbg
<infinity> manchicken: http://ddebs.ubuntu.com/pool/main/a/apt/
<cpg> infinity: great. looks like the actual program is dh_make
<xnox> manchicken: https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages =)
 * manchicken is RTFM'ed. Thanks.
<manchicken> The first link works.
<manchicken> Didn't think to append the version string for some reason.
<xnox> infinity: i tend to point people at ddebs documentation, rather than to the pool ;-)
<infinity> xnox: I would too, but I suck at searching wikis. ;)
<infinity> xnox: As davidm always used to say, wikis are were information goes to die.
<xnox> lol =) yeah, i'd rather say "wikis suck at searching" i don't think human search skills are at all at fault here =)
<manchicken> All this time I thought public libraries in the US was where information went to die.
<xnox> manchicken: I LOVE US PUBLIC LIBRARIES! they actually have stuff there, unlike libraries here in the UK
 * manchicken has no experience with public libraries in the UK.
<xnox> (maybe it's because i'm not cambridge alumni, and don't have their library pass)
<manchicken> I know I lived in central Illinois, and during the hearings to approve funds to move our library out of the 1980's Radio Shack building into its own new building people kept on saying "why do we need libraries when we have Kindle?"
<alkisg> pkexec refuses to launch processes if PPID=1 (line 705 in http://cgit.freedesktop.org/polkit/tree/src/programs/pkexec.c), so e.g. `pkexec gparted` runs fine from gnome-terminal but not from the Alt+F2 run dialog which uses PPID=1...
<alkisg> Anyone knows why is that, or, more importantly, any way to work around it without using a parent wrapper process like /usr/bin/gparted-pkexec?
<AnAnt> doko_: Hello, I was wondering why you added this patch to harfbuzz packaging: Build using dh-autoreconf ?
<doko> AnAnt, new targets, this time not only config.* updates are needed, but some libtool updates too
<AnAnt> doko: is build-dep on autotools-dev still needed ?
<doko> no, dh-autoreconf depends on it
<AnAnt> nope
<doko> ohh?
<AnAnt> can't see it here: http://packages.debian.org/sid/dh-autoreconf
<doko> yeah, well in most cases it replaces the config.* files itself. but there are a few cases where it does not
<AnAnt> I wonder if it is probably a best practice to use dh_autoreconf by default
<lksdjf> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/
<lksdjf> how do i install this?
<lksdjf> i downloaded the appropriate header and image
<lksdjf> and the all
<lksdjf> then i did: sudo dpkg -i *all* and i figured that would install both the header and the image
<lksdjf> i dtest
<lksdjf> installing *headers* and *image* nd reboting
<lksdjf> hmm, can see anything
<lksdjf> hope nobody is responding to me right now
<cyphermox> asac: will do on Monday
<asac> :)
#ubuntu-devel 2014-12-01
<pitti> doko_: lintian is fixed now, binutils is a valid candidate nwo
<pitti> mvo: thanks for fixing software-properties!
 * pitti fixes the aptdaemon failure
<mvo> pitti: sure, yw
<Mirv> @pilot in
* udevbot 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 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: Mirv
<LocutusOfBorg1> morning developers
<LocutusOfBorg1> hi Mirv do you patch pilot today?
<LocutusOfBorg1> quick question, can you see bug 1397558 ?
<ubottu> Error: Launchpad bug 1397558 could not be found
<LocutusOfBorg1> it is a security issue, a merge from debian
<Mirv> LocutusOfBorg1: for a bit at least, yes! no, I don't see that issue either unfortunately :( maybe it's then security team only.
<LocutusOfBorg1> ok unmark
<LocutusOfBorg1> can you please try again?
<LocutusOfBorg1> bug 1397558
<ubottu> bug 1397558 in tcpdump (Ubuntu) "please merge tcpdump from debian" [Undecided,New] https://launchpad.net/bugs/1397558
<Mirv> LocutusOfBorg1: now it works
<LocutusOfBorg1> wonderful :)
<LocutusOfBorg1> I'm the previous uploader, trivial merge
<Mirv> LocutusOfBorg1: I've to disappoint though by being a mere MOTU, not core-dev :(
<LocutusOfBorg1> no problem, next sponsor will maybe have a look :)
<Mirv> I'd guess so, yes
<LocutusOfBorg1> I was wondering if it was showing up on the queue
<Mirv> I think it should now, after the next refresh
<LocutusOfBorg1> yep, thanks
<dholbach> good morning
<tkamppeter> mvo, hi
<mvo> tkamppeter: hi till, sorry, haven't goten to your mail yet, working on backlog this morning though
<tkamppeter> mvo, after some investigations the problem has chenged, now it is bug 1397750.
<ubottu> bug 1397750 in aptdaemon (Ubuntu) "Not able to install packages using the PackageKit D-Bus API" [High,New] https://launchpad.net/bugs/1397750
<tkamppeter> mvo, the original problem is solved as the system had accidentally PackageKit instead of aptdaemon installed. After fixing that, the original problem points are solved. Now the problem is that the package ID does not get correctly interpreted when the actual installation of the package happens.
<mvo> tkamppeter: aha, thanks
<tkamppeter> mvo, and other functions, like the one to list the package's files understand the package ID.
<Mirv> would any core-dev be willing to sponsor frafu's bug fix which I made a branch of? lp:~timo-jyrinki/ubuntu/vivid/onboard/onboard_fix1378739_1376764
<Mirv> bug links etc at https://code.launchpad.net/~timo-jyrinki/ubuntu/vivid/onboard/onboard_fix1378739_1376764/+merge/243259
<mvo> tkamppeter: oh, so its just install that does not?
<tkamppeter> mvo, yes, only this pk.installPackage().
<seb128> Mirv, hey, I can do that
<Mirv> seb128: thanks!
<Mirv> pitti: could you take a look at https://code.launchpad.net/~yuningdodo/ubuntu/trusty/usb-creator/usb-creator.lp1361474+lp1300361-recreate-udisks-client/+merge/232852 ? I've built and tested it with various cases on 14.04 now as explained in the comment.
<Mirv> LocutusOfBorg1: yes the tcpdump security bug now is visible in the sponsoring page. meanwhile, I'll take a look/test at your earlier ettercap SRU as that's in universe.
<LocutusOfBorg1> Mirv, honestly I would like to see an SRU of everything is now in vivid and testing...
<Mirv> LocutusOfBorg1: I know, but unless each of the new version's commits can fulfill the SRU criteria, it's a bit tough to sell for the SRU process.
<LocutusOfBorg1> it has been two ettercap releases that are almost completely bug fixes
<LocutusOfBorg1> when we have new features we usually disable them with cmake parameters, and being both debian and upstream maintainer gives me the power to be sure about it :)
<pitti> ricotz: stable patch queue> just didn't get to that yet, but will do now
<cousteau> what's the channel for package maintenance?  I want to ask why moonlight is not in repositories anymore
<ricotz> pitti, hi, alright, thanks
<pitti> ricotz: or I would if I would find an effective git invocation that does that :)
<rbasak> cousteau: it was left unmaintained: see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638565 and https://launchpad.net/ubuntu/+source/moon/+publishinghistory under Oneiric.
<ubottu> Debian bug 638565 in ftp.debian.org "RM: moon -- RoQA; outdated, NPOASR, outdated" [Normal,Open]
<cousteau> I see
<cousteau> I think I'll better find other alternatives to Silverlight rather than trying to install an unmaintained program
<cousteau> rbasak, thanks!
<pitti> ricotz: meh no, that's broken
<pitti> ricotz: current v217-stable doesn't even build -- I'll rather wait for 218 then
<ricotz> pitti, oh, really, i just noticed the 216 and 217 tags are not pushed to the stable repo
<ricotz> iirc there is a small script mentioned in the changelog to fetch the queue
<pitti> ricotz: I did fetch the patches, but they cause build errors; apparently undeclared patch dependencies
<ricotz> hmm, i see :\
<ricotz> doesnt count for a good maintenance over there
<pitti> ricotz: I take that back, this is due to another patch; I fix that first, and then try the stable series again
<pitti> ricotz: anyway, last commit to v217-stable was on Nov 11, quite old already
<ricotz> pitti, ok, although there are 50 patches on top of the release
<shadeslayer> it's a mess I tells ya
<shadeslayer> brr
<mardy> jdstrand: hi! About confinement of account plugins: I didn't think about using the aa_* functions, and I went for ubuntu-app-launch2 instead (because I was looking at PayUI, and that's how they do it)
<mardy> jdstrand: do you think I should change to use aa_change_profile() instead, and go back the previous implementation (using just QProcess)? It would be a rather quick change, so I wonder if you would recommend one method over the other
<Mirv> @pilot out
* udevbot 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 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:
<LocutusOfBorg1> sorry cjwatson you were mentioned on the changelog https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1266492 Indeed wasn't your code, but the previous one
<ubottu> Launchpad bug 1266492 in evolution-data-server (Ubuntu Trusty) "ld:i386 crashes with -static -fPIE -pie" [Critical,Confirmed]
 * LocutusOfBorg1 thinks that monday shouldn't be a workday
<LocutusOfBorg1> sorry again
<balloons> mvo, ping again :-) I keep missing you. I'm curious about a couple things. 1) Multi-arch support for the click, so click build can automagically target multiple arches (using schroots?) 2) This bug seems to prevent us from being able to install from the store on x86 https://bugs.launchpad.net/ubuntu/+source/click/+bug/1396611
<ubottu> Launchpad bug 1396611 in click (Ubuntu) "Can't install click packages with pkcon" [Undecided,Confirmed]
<brainwash> pitti: I've encountered https://bugzilla.redhat.com/show_bug.cgi?id=1159117 while testing systemd 217 from proposed (backported to utopic)
<ubottu> bugzilla.redhat.com bug 1159117 in systemd "systemd 217 show dependency loop and won't start gdm" [Urgent,Closed: rawhide]
<pitti> brainwash: that shoudl be fixed in -2 (just uploaded to experimental) and -2ubuntu1 (just preparing for vivid)
<pitti> brainwash: it's part of the v217-stable fixes
<pitti> brainwash: backport from -proposed> livin' on the edge, eh? :-)
<brainwash> pitti: great, I will test it later
<brainwash> https://launchpad.net/~unit193/+archive/ubuntu/systemd from Unit193
<brainwash> systemd is pretty stable, so I'm not that worried about using the latest release
<didrocks> barry: hey, how are you?
<barry> didrocks: hi, good!  and you?  i'm in a meeting atm
<didrocks> barry: I'm good as well, thanks! feel free to answer when your meeting ends then, there is no hurry :)
<didrocks> barry: we did have an interesting session at last UOS about "preventing people to shoot in their feet by sudo pip install" (same for rubygem) where aquarius argued heavily we should avoid those behaviors
<didrocks> barry: to not be too intrusive (especially with sysadmins having their scripts I guess), I have in my mind the following suggestions:
<didrocks> barry: having the ubuntu developer tools setting an environment variable like PROTECT_DEVS_USE_LOCAL, and then patching pip/rubygem to bails out by default if this env variable is set (and linking to a wiki page so that they understand exactly why and how to fix this)
<didrocks> barry: another patch would be that "pip install" (without sudo) doesn't try to install by /usr/local by default and give a better error, I can do this as well
<didrocks> just wanted your thoughts on this :)
<pitti> stgraber, jodh: I believe I captured most of the work in https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration as WI now; please double-check, though
<didrocks> pitti: add grub entry to boot with upstart -> done locally at least ;) I might add some btw, like the fallback X session if you don't mind
<pitti> didrocks: please do
<mvo> balloons: hi, sorry, super busy, let me look at your question
<pitti> zul: can you please look into http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-taskflow ?
<pitti> zul: it's uninstallable (missing python-ordereddict)
<pitti> apw: ^ FYI
<zul> pitti:  yep
<apw> pitti, ack thanks
<pitti> zul: thanks
<pitti> doko_: btw, binutils still didn't propagate -- http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt has some uninstallabilities?
<mvo> balloons: could you file a bug about the multi-arch clicks ? do you want to generate multiple clicks? or a single "fat click"?
<balloons> mvo, yes a single fat click. I was successful in manually building one, and it goes into the store, installs across devices all fine. But click itself can't build it
<barry> didrocks: my understanding is that in some (not too distant) future, pip --user will be the default outside of virtualenvs.  imo, that's the right way to go, i.e. no --user *inside* venv by default, but --user *outside* venv by default.  that should go a long way to making pip sane on ubuntu
<barry> didrocks: i'd be very happy to consider making --user the default now-ish in debuntu
<didrocks> barry: oh, that sounds really nice! do you want a patch for this?
<sergiusens> balloons: building fat clicks has been possible for a while, and 'click build' works fine if you gve it the right layout
<balloons> sergiusens, I'm happy to be informed. I didn't file a bug on it because I'm not sure how it's supposed to be happening now, or if it's not yet built, etc
<barry> didrocks: yes!  also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725848
<ubottu> Debian bug 725848 in python-pip "python-pip: default install method for non-root users should be --user" [Normal,Open]
<didrocks> barry: opened, will send you something your way for debian tomorrow I guess :)
<barry> didrocks: sounds great, thanks
<didrocks> barry: thanks for the feedback :)
<sergiusens> balloons: I did this really quick for the ci engine as a base template sort of thing: http://bazaar.launchpad.net/~sergiusens/uci-engine/click/view/head:/click-builder/click_builder/clickbuilder.py
<sergiusens> balloons: feel free to use as inspiration
<barry> didrocks: note dstufft's comment, there does need to be a way to turn off --user and actually, outside of a venv, i'd be happy if that mythical --no-user complained and exited if uid != 0
<balloons> sergiusens, awesome thanks. I'll have a look at it after my call
<barry> didrocks: there's also code in python-pip's quilt patches to determine whether your inside or outside a venv.  it should work for both python-virtualenv (py2 and py3) and pyvenv (py3)
<barry> *you're
<barry> it's been a while since i caught up on that github thread
<balloons> so sergiusens the idea is you have chroots for each arch and this cobbles them together?
<didrocks> barry: agreed on --no-user + complain if uid != 0 :) (and ack on the virtualenv one)
<sergiusens> balloons: that was what I was going for; but you can't get too much into 'click' itself without breaking the concept of simple packaging
<balloons> so I guess my question for mvo is what sort of support will be built in to click itself for this?
<doko_> pitti, yep, known. will care about it later today
<balloons> mvo, and when you have a moment again, I'm curious about the store bug as it's stopping installation of packages from x86 installs. Want to make sure it's filed in the proper place, etc.
<pitti> doko_: no hurry, just wanted to keep up updated
<bdmurray> seb128: did you find that unity-settings-daemon segfault?
<seb128> bdmurray, we found/fixed it, but I'm concerned that e.u.c didn't register it when it was impacting every single laptop user and that we know a good number of people reported it
<dobey> balloons: that's not an issue with the store. it's an issue with click/pkcon integration. so filing it under click is the right place i think
<bdmurray> seb128: do you have an OOPS ID for any of those reports?
<seb128> pitti, ^ do you have the oops id for the report you did about the usd/upower issue?
<seb128> bdmurray, it looks like https://errors.ubuntu.com/problem/7689f87da805c668a249ff41702cf7706a046e37
<seb128> bdmurray, I wonder if those just took a while to get retraced
<seb128> though e.g pitti's one is not in that bucket it seems
<bdmurray> seb128: there is a backlog for amd64 (a week) but we are on top of i386 (for the most part)
<seb128> k
<seb128> so that probably explains it
<bdmurray> seb128: I'm submitting an RT to dump the amd64 queue again and we are moving to scaling stack for the retracers real soon now.
<pitti> hm, do we really just have i386 traces there?
<pitti> ah
<seb128> do you know if the backlog is a temporary issue?
<seb128> k
<bdmurray> seb128: yes, temporary we haven't added any new amd64 retracers for a while.
<bdmurray> pitti: any luck with bug 1370230 yet?
<ubottu> bug 1370230 in Apport "apport-retrace has become slower" [High,Triaged] https://launchpad.net/bugs/1370230
<pitti> still swamped :(
<mvo> balloons: would you mind filing a bug about the click build for multi-arch? just so that its tracked ?
<pitti> and TBH with all the snappy stuff now being thrown my way it's not going to get better anytime soon, so anyone who wants to have a go at this please do
<mvo> balloons: the install bug seems to be a issue with the packagekit backend  - it appears it tires to install the click as a deb instad of as a click
<mvo> balloons: so thats a click-bug
<bdmurray> pitti: alright, I'll have a look then. What about bug 1394798 for which I added a patch?
<ubottu> bug 1394798 in Apport "Contents.gz files exist multiple times in sandboxes" [Undecided,Confirmed] https://launchpad.net/bugs/1394798
<balloons> mvo, yes I will file a bug for multi-arch. Thanks for confirming the bug is in the right spot
<mvo> balloons: something similar was reported some days ago
<didrocks> shadeslayer: hey, so, we do have the transitions ppa with bluez5 (working as checked with pulseaudio) done, mind uploading bluedevil (I can sponsor you if you can't upload) there? https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/transitions
<shadeslayer> didrocks: ok, I can put it on my todo for tomorrow, is that alright?
<shadeslayer> I didn'
<shadeslayer> I didn't realize that the transition work had been done so quickly :)
<didrocks> shadeslayer: that's perfect, thanks! (Not everything is in yet TBH, but we did validate the base is working :))
<ogra_> shadeslayer, just as yourself "could it be on a phone install ?" ... if the answer is yes, then you can be sure the transition is done in no time ;)
<ogra_> *ask
<shadeslayer> :D
<seb128> apw, hey, dunno if you noticed bug 1377378, it seems it started with your upload on https://launchpad.net/ubuntu/+source/plymouth/0.9.0-0ubuntu7
<ubottu> bug 1377378 in plymouth (Ubuntu) "plymouthd crashed with SIGSEGV in ply_renderer_get_buffer_for_head()" [Medium,New] https://launchpad.net/bugs/1377378
<didrocks> ogra_: this is more desktop-centric for now than phonish TBH. Testing on the phone would be next step ;)
<didrocks> (of course, before pushing to -proposed)
<pitti> bdmurray: queued, I'll have a look tomorrow morning at this; you just need this in trunk, right?
<smoser> when would i expect that http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/installer-amd64/current/images/ would have a 'utopic-netboot' entry like at http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/
<bdmurray> pitti: correct. it likely doesn't make a huge difference, but every little bit helps.
<smoser> i'd expect it since linux-generic-lts-utopic and friends are available in trusty (https://launchpad.net/ubuntu/+source/linux-meta-lts-utopic)
<smoser> normally i ping infinity by name for such queries. ;)
<jdstrand> mardy: hi! I'm going to point you at tyhicks on the recommendation. ual *should* be doing the right thing, but tyhicks may have more insight
<mardy> jdstrand: OK, thanks
<apw> seb128, hmmm nope not noticed that one
<seb128> apw, ok, now you did I guess ;-)
<apw> yep now i did
<tyhicks> mardy: sorry but I'm not very familiar with how the account plugins are being confined
<tyhicks> mardy: I'll take a look at the code and will get back to you
<mardy> tyhicks: the code is here: https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/click-plugins/+merge/243296
<seb128> wgrant, hey, did you enable langpacks exports for vivid (dpm mentioned he usually pings you to enabled those)? (looking to https://translations.launchpad.net/ubuntu/vivid/+language-packs suggest it's not on yet?)
<seb128> bdmurray, I got an email about https://errors.ubuntu.com/problem/e43c6a36473bb0fa132807674f9dff8bc5bbcf8e being a possible sru regression in "nautilus version 1:3.10.1-0ubuntu9.4 to trusty", but it has reports for 0ubuntu8 ... can you clear that off the list and let the update be rolled out?
<seb128> bdmurray, do you know why the email was generated since 0ubuntu8 has reports and it's < 0ubuntu9.4?
<bdmurray> seb128: likely because it was never reported about 9.3
<seb128> bdmurray, k, I guess it's just random enough that that didn't happen yet
<seb128> but it's not a regression from the change for sure
<bdmurray> seb128: okay, I'll override it then
<bdmurray> seb128: actually there were multiple emails about nautilus, I'll review all of them
<seb128> bdmurray, thanks, let me know if you need more info/testing
<tyhicks> mardy: hey - I got a chance to look at all the components involved
<tyhicks> mardy: I think you're doing it the best way already by using ual
<tyhicks> mardy: if you were actually spawning the process yourself then you'd need to use aa_change_profile but you're already trusting ual for so much that you might as well trust it for setting up proper confinement, too
<tyhicks> mardy: also, if you called aa_change_profile(), then the plugin's profile would need to allow all of the stuff that libubuntu-app-launch does behind ubuntu_app_launch_start_multiple_helper()
<tyhicks> that wouldn't be ideal
<rharper> arges: I'm trying to test out the updated qemu package for bug 1370199,  I've got trusty-proposed enabled, when I try a apt-get install qemu/trusty-proposed it shows the right package, but doesn't actually start the install ... what am I messing up?
<ubottu> bug 1370199 in qemu (Ubuntu Trusty) "qemu upstart job should create /dev/kvm in a container" [Undecided,Fix committed] https://launchpad.net/bugs/1370199
<arges> rharper: i'm not sure, can you pastebin the output?
<rharper> http://paste.ubuntu.com/9333888/
<rharper> arges: ^^
<arges> rharper: how did you setup apt for enabling -proposed?
<rharper> added the line from the wiki page
<rharper> http://paste.ubuntu.com/9334116/
<arges> rharper: i just did this today and the only difference was that I added the apt/preferences to change the pin priority
<rharper> odd
<rharper> ok, well, lemme try the apt/prefs
<arges> rharper: can you try teh same with qemu-kvm instead?
<rharper> yeah
<arges> (not that i think that would make a different)
<rharper> that worked
<arges> perhaps its something to do with how qemu is packaged? maybe hallyn would have a better idea
<rharper> arges: yeah.  thanks for the tip, testing out this now in a trusty container to see if the /dev/kvm gets created
<rharper> thanks!
<mardy> tyhicks: thanks a lot, that's good to know!
<cyphermox> mterry: I was wondering if you could have another quick look at the three MIRs I submitted; the packages will be looked after by the desktop team
<mterry> cyphermox, done
<cyphermox> thanks
<wgrant> seb128: I see two langpacks on that page.
<seb128> wgrant, what page?
<wgrant> seb128: The langpack page you linked.
<seb128> wgrant, is that an issue? I've not clue what needs to be done, dpm just hinted me that the export needs to be enabled
<wgrant>  Full language pack: 2014-12-02 02:03:16 EST download icon
<wgrant> The export *is* enabled, and there are langpacks there.
<seb128> great
<arges> rharper: so i believe bug 1292234 is an upstream issue, however the only variable that seems to cause it is using ext3 vs ext4 as the host filesystem. So this could be some obscure ext3 bug only triggered by qcow2 snapshotting...
<ubottu> bug 1292234 in qemu (Ubuntu) "qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)" [High,Confirmed] https://launchpad.net/bugs/1292234
<rharper> arges: I saw your update ... that's quite interesting...
<rharper> arges: it still feels someone related to extent mapping, but i'm outta my depth w.r.t ext3 vs ext4 internals
<arges> rharper: would there be ext3 features I could tweak to isolate that?
<rharper> I don't think those are exposed
<rharper> ext4 allowed for delayed extent allocation (hence the feature bit)
<rharper> which allowed for more contiguous allocations by applications
<rharper> we're using which cache mode?
<rharper> default?  writeback ?
<rharper> writethrough is default (aka O_DSYNC)
<arges> rharper: writethrough
<rharper> I wonder if playing with the mode there matters much ... eaiser to play with if we have a reasonable reproducer -- will kick that off sometime today ; need to create an ext3 filesystem to play with though
<arges> rharper: i also tested with latest and greatest qemu/linux and it still reproduces. so afaik this is an upstream issue somewhere
<rharper> arges: but older qemu works ok?
<rharper> aka, qemu-kvm 1.0 or whatever was packaged in precise ?
<arges> rharper: i should check that out... could reverse bisect
<rharper> right, I suspect it's related to IO flushing....
<rharper> arges: if the recreate ever gets really reliable, there is a block io system trace which might prove interesting to compare between versions
<arges> rharper: it seems fairly reliable... we could just set it in a loop to retry like 5 times
<rharper> i'd be really surprised if it was an actual ext3 bug
<arges> me too
<rharper> more likely an application error with flushing data .. it's not like the fs is corrupt
<rharper> rather data within the file is
<rharper> arges: so something with trying is to use cache=directsync (aka OSYNC|ODSYNC)
<rharper> err, ODSYNC and ODIRECT -- sync writes and no host page-caching
<arges> rharper: i'll give that a shot
<arges> rharper: cache=directsync still shows the failure
<rharper> arges: interesting ...
<rharper> very confusing why this is a ext3 only issue...
#ubuntu-devel 2014-12-02
<pitti> Good morning
<Unit193> Howdy.
<pitti> hey Unit193, how are you? I see you eagerly backport systemd :)
<Unit193> pitti: Heh, yeah.  Started doing that in trusty, did a couple Debian merges, not fun with systemd. :P
<pitti> Unit193: tell me about it :)
<Unit193> Though, looks as if the new cryptsetup added much better support for it!
<pitti> Unit193: but with our current workflow (shared git with Debian, rebasing ubuntu on top of master/experimental) it actually works reasonably well
<Unit193> Awesome!  Saw you got added as uploader, congrats.  Great to see you work "upstream" too. :)
<pitti> Unit193: so with 172-2ubuntu1 in vivid you should now have a reasonably current version?
<pitti> (it includes the v217-stable patches, too)
<Unit193> pitti: Yep!  Just rebooted into it (only slight hickups.)
<pitti> Unit193: I'm not aware of any regressions, so bug reports appreciated
<Unit193> pitti: Heh, only upon reboot the clock was off a few hours.
<pitti> zul: python-taskflow is still failing its tests, so it doesn't propagate
<dholbach> good morning
<highvoltage> good morning!
<pitti> dpm: good morning
<pitti> dpm: can you please set up http://people.canonical.com/~dpm/data/ubuntu-l10n/ for vivid?
<pitti> dpm: I'm building the first set of vivid packages now, but I had to fall back to utopic there ^
<dpm> pitti, morning. Ok, let me file the RT
<LocutusOfBorg1> hi dholbach :)
<dholbach> hi LocutusOfBorg1
<seb128> slangasek, hey, I can trigger bug #1372193 by updating systemd (like if I dpkg -i the old version and use update-manager I seem to consistently hit it), let me know if you need debug info
<ubottu> bug 1372193 in pam (Ubuntu) "package libpam-systemd:amd64 208-8ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 128 in pam-auth-update" [Undecided,Confirmed] https://launchpad.net/bugs/1372193
<pitti> seb128, dpm: ubuntu vivid langpacks uploaded and updates cron'ed
<seb128> pitti, great!
<dpm> thanks pitti
<xnox> cjwatson: infinity: was it intentional for 14.04 core tarballs to stop enabling i386 foreign arch?
<cjwatson> I don't remember that coming up
<cjwatson> Of course core is meant to be minimal and it's trivial to enable.
<xnox> cjwatson: it looks like previous cores used to have it, and e.g. it affects docker images - as since 14.04 they stopped having i386 support out of the box. Maybe it should be just enabled on the docker side, but I wanted to check first that this not an accidental regression
<xnox> (e.g. dpkg postinst refactoring, moving builds to launchpad, et.al)
<xnox> but rather intentional choice / change.
<cjwatson> Build location has nothing to do with it.
<cjwatson> We might have decided we didn't need to carry the dpkg delta any more because apt-setup handles it in most cases, I suppose.
<cjwatson> Although it seems to be still there in vivid.
<cjwatson> Anyway, I think it's fine to say that you need to do "dpkg --add-architecture i386" before "apt-get update" if you want multiarch, and you probably wanted to run "apt-get update" anyway.
<rsalveti> pitti: added https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1337200 as a duplicate of the other one because this bug is hardware specific
<ubottu> Launchpad bug 1337200 in upower (Ubuntu RTM) "High CPU due to excessive device changed signals from upower" [High,Confirmed]
<rsalveti> and the other project is to cover basically hardware specific bugs
<pitti> rsalveti: ok, then let's track those as two independent bugs then; making a public bug a dupe of a private one is rather unfriendly
<rsalveti> pitti: I agree it's unfriendly, but having 2 bugs opened at the same time is not ideal either =\
<pitti> rsalveti: I still don't understand this then; #1337200 covers teh general case for all hardware, why would a bug for specific platform now become the master bug?
<pitti> well, *shrug*, I don't care enough to fight over this
<rsalveti> pitti: because the problem is the kernel sending way too much uevents related with power
<rsalveti> which makes upower to be quite a bit verbose, and dbus as well
<pitti> rsalveti: that's then not really a duplicate
<pitti> rsalveti: #1337200 is about queueing up d-bus signals while a process is sleeping, and then flushing them on wakeup
<pitti> rsalveti: if on that other platform the kernel is sending too many events, that's a separate cause
<rsalveti> pitti: just because the comments from ken vandine are all covering the issue described by the other bug
<rsalveti> but yeah, let's keep both of them opened then
<rsalveti> thanks
<brainwash> pitti: the new upload of systemd 217 works fine here. I did not encounter any problems so far :)
<brainwash> pitti: thanks
<pitti> brainwash: cheers
<stgraber> xnox: Edubuntu actually ships with two DEs, just saying :)
<xnox> stgraber: shh, i knew that when typing it out. Dito e.g. mythbuntu ships in a way two DEs - boot to xfce & boot to mythtv-frontend.
<stgraber> :)
<tgm4883> xnox: no, mythbuntu just has xfce start mythfrontend
<pitti> apw: do you happen to know how in-kernel firmware loading works these days, or who to talk about it?
<apw> pitti, i know an amount, what do you need
<pitti> apw: latest udev removed the userspace helper for this, but it seems on seb128's laptop the kernel can't load the iwlwifi firmware (works on mine)
<pitti> bug 1398458
<ubottu> bug 1398458 in systemd (Ubuntu) "kernel fails to load iwlwifi firmware" [Undecided,New] https://launchpad.net/bugs/1398458
<pitti> apw: i. e. my first question would be, is there some way to squeeze some more verbosity out of the kernel? right now it just says
<pitti> [ 6.586593] iwlwifi 0000:02:00.0: Direct firmware load failed with error -2
<seb128> laptop is a latitude e6410 i5
<pitti> [ 6.586598] iwlwifi 0000:02:00.0: Falling back to user helper
<pitti> apw: I suggested to boot with "debug log_buf_len=1M" as a first step, but I wonder if there's something more specific that we should try?
<pitti> apw: i. e. I can certainly put back the userspace helper, but I thought the intention was that the kernel does fw loading by iself now since 3.7
<pitti> apw: and it seems to work just perfectly on my centrino Advanced-N 6205 (almost the same model as seb128's)
<apw> pitti, well, it may depend on which kernel he has, as i assume the direct loader cannot handle the firmware in non-standard places
<apw> seb128, are you using an lts backport kernel perhaps
<pitti> apw: I assume bog standard vivid with the distro kernel, much like I have
<Sarvatt> pitti: http://web.archiveorange.com/archive/v/wmeLD6rhIrHWG2dyJEUG looks like its because iwlwifi tries to load 3 different firmwares since it supports it, but -4 is the only released one
<pitti> except seb128 is using i386, I'm amd64
<seb128> apw, no, vivid with 3.16.0-26-generic on i386
<apw> seb128, the fimware it fails to load, do you know where it is on disk ?
<seb128> apw, no, but I only have 1 partition
<seb128> no separate /usr or anything like that
<pitti> seb128: ah thanks, that looks very similar
<pitti> apw: how can I tell which file it loaded on my system?
<pitti> [    2.898239] iwlwifi 0000:03:00.0: loaded firmware version 18.168.6.1 op_mode iwldvm
<pitti> apw: ^ that's not saying much?
<pitti> /sys/class/firmware/ only has a single "timeout" file here
<Sarvatt> yours is 6000g2a
<Sarvatt> going by http://wireless.kernel.org/en/users/Drivers/iwlwifi
<Sarvatt> iwlwifi-6000g2a-6.ucode exists, it tries to load the -6 abi then -5 abi then -4 abi and -4 is the only one released for the 6200/6300
<pitti> well, the firmware is obviously somewhere, as udev 215 can load it with the userspace helper
<apw> pitti, seb128, so that error is saying ENOENT, that the file was not found anywhere
<apw> add_uevent_var(env, "FIRMWARE=%s", fw_priv->buf->fw_id)
<apw> it uses that as the filename, so seb128 can you see that in your udev logs anywhere?
<pitti> E: FIRMWARE=iwlwifi-6000-5.ucode
<pitti> apw: ^
<apw> pitti, was that yours or his
<pitti> apw: his
<pitti> apw: I can't see it in my udev db, as the fw loading happens very early at boot, so it's not anywhere
<pitti> /lib/firmware/iwlwifi-6000-4.ucode
<pitti> that's what we ship in linux-firmware
<pitti> so it seems the udev userspace helper is trying various fallbacks, while the in-kernel loader doesn't?
<apw> cirtainly the kernel is correctly saying it cannot find that as it is not on disk
<apw>  quite what udev thinks it is doing loading somethign completely different, is suspcious at best
<pitti> seb128: wait, does it eventually initialize?
<pitti> seb128: i. e. if the kernel doesn't find that after 60 seconds (/sys/class/firmware/timeout is 60 here), does it try another file name?
<pitti> seb128: that would correspond with "Need to wait 2 minutes before wireless connects" on the suse bug
<apw> normally we step backwards through the versions in the dirver
<pitti> apw: modinfo iwlwifi shows various "firmware:" bits, in particular iwlwifi-6000-4.ucode
<apw> though i don't see why it would timeout either, as the ENOENT is a hard failure
<pitti> apw: that's what the udev loader uses
<pitti> apw: interestingly, modinfo iwlwifi does *not* show -5
<pitti> apw: yeah
<pitti> apw: so I'm a bit puzzled where the -5 comes from, if the module advertises -4 only
<pitti> apw: anyway, I suppose in the short term I need to put back the udev userspace loader, but I suppose at some point the kernel shoudl be able to load by itself?
<pitti> apw: so we need to figure out where the 6000-5 comes from; i. e. in-kernel loader loads something different than what the module advertises through "firmware:"
<seb128> pitti, sorry, was away a few minutes
<seb128> pitti, it eventually works, because after boot if I turn network off and on using nm-applet or the laptop switch it manages to connect
<seb128> it just don't do it or boot or not by itself if I wait
<pitti> seb128: interesting; after you do that, can you attach dmesg again? somethign needs to load that firmware after all, so it seems the kernel can find it eventually
<apw> pitti, so the minimum firmware U will accept for that device is -5 according to the dirver
<seb128> pitti, that should be in my syslog from previous boots right?
<pitti> seb128: yeah, I guess so; grep for "firmware"?
<seb128> pitti, Dec  2 11:37:08 localhost kernel: [  127.133185] iwlwifi 0000:02:00.0: loaded firmware version 9.221.4.1 build 25532 op_mode iwldvm
<pitti> apw: and that's 6000, not 6000g2a?
<seb128> I think
<pitti> yep
<apw> pitti, and it iterates through the firmare versions via the firmware ABI highest accepted to lowest
<pitti> seb128: It would be a real mystery if manually enabling wifi would magically load the firmware; it rather seems the firmware gets loaded automatically, but NM doesn't notice this, so you can manually enable only after that happened?
<seb128> pitti, you mean "manually enable"?
<pitti> seb128: can you reboot, keep the network as-is, "sudo dmesg -c | grep firmware"
<seb128> if I don't turn network off/on, nm-applet doesn't list any aps
<seb128> pitti, sure
<pitti> seb128: then wait for two minutes, and "dmesg | grep firmw" again? I strongly suspect this will turn up eventually by itself
<pitti> seb128: yes, I suspect NM doesn't "see" when the fw gets loaded and the card becomes ready
<seb128> k
<pitti> apw: so we mostly need to update linux-firmware to have -5?
<seb128> let me try, back in a few minutes
<pitti> apw: I still wonder why modinfo iwlwifi says -4 then
<pitti> if it wants >= -5
<apw> pitti, maybe, though what is being loaded by the usermode helper, as the versions which are valid are not there
<apw> pitti, well frankly it cannot be accurate, as the versions acceptable per chipset differ
<apw> but presumably the modinfo is wrong at best
<pitti> hm, the latest firmware on http://wireless.kernel.org/en/users/Drivers/iwlwifi also only has 6000-4
<pitti> apw: "loaded firmware version 9.221.4.1" (on seb128's machine) correlates with the 6200 on http://wireless.kernel.org/en/users/Drivers/iwlwifi, and that has 6000-4
<apw> pitti, you said you got rid of the usermode helper, but the kernel still calls it right ?
<pitti> apw: yes, if it can't load it by itself
<apw> and if you have removed it, that will timeout
<pitti> CONFIG_FW_LOADER=y
<pitti> CONFIG_FW_LOADER_USER_HELPER=y
<apw> as nothing is responding
<pitti> apw: oh!
<pitti> apw: so you figure it goes like this:
<pitti> - try -5
<pitti> - in-kernel loader: ENOENT
<pitti> - try userspace helper
<pitti> - time out
<pitti> - try -4
<pitti> - in-kernel loader: success
<apw> so ... i think that that means, we try  ... yes that
<pitti> now, that makes perfect sense
<pitti> apw: if seb128 comes back and confirm that the fw gets loaded automatically after 2 mins or so, we solved it
<pitti> apw: so that means we need to disable CONFIG_FW_LOADER_USER_HELPER=y first, and then disable the udev helper
<seb128> pitti, ok, I was wrong
<apw> pitti, and yes that is what the code is doing, iwlwifi is looking -5 -4 -3 stylee, and then each is tries direct load, usermode, iterate
<seb128> pitti, the firwmware loads after 126 seconds
<seb128> and nm sees it, connects
<pitti> seb128: it loads automatically? (pleeease say that)
<apw> pitti, _or_ you make the firmware loader in userspace a stub we can turn off
<pitti> yay!
<seb128> pitti, I just never waiting a full 120 seconds
<seb128> waited
<seb128> it feels ages :p
<pitti> seb128: then we completely solved the mystery
<apw> pitti, make it report failed for the load
<pitti> apw: which always fails with an error immediately? sure, taht works too
<apw> then we can make it something "you and i" can turn on to test etc until we are happy the kernel one is working
<seb128> pitti, why does it take so long?
<pitti> apw: I guess eventually we shoudl still disable CONFIG_FW_LOADER_USER_HELPER, but at least that removes the lockstep
<pitti> apw: many thanks for your help!
<apw> pitti, right, we can test, then default it off in userspace for a bit
<apw> then turn it off in the kernel, and be happy
<apw> pitti, as in some sense we want the helper there and available and _on_ in userspace in case someone has a non-standard kernel
<pitti> seb128, apw: I followed up to the bug with the explanation
<pitti> apw: right, but even wit the stub we don't support kernels without CONFIG_FW_LOADER=y
<pitti> seb128: (that also explains the two minutse)
<seb128> pitti, reading
<seb128> pitti, thanks a lot for looking at the issue!
<pitti> seb128: I'll work on a stub now, and will ask you to test it
<seb128> pitti, ok, I'm happy to do testing ;-)
<pitti> seb128: can you create an /etc/udev/rules.d/50-firmware.rules with
<pitti> SUBSYSTEM=="firmware", ACTION=="add", RUN="/bin/false"
<pitti> seb128: then reboot, and see whether that fixes it?
<pitti> seb128: there's still some tweaking to be done (I think we should put that into initramfs too), but for a first test that should do
<didrocks> pitti: just curious (while seb is testing) what is the communication protocol? There is no way for the kernel to detect there is no available helper?
<pitti> didrocks: yeah, I'm wondering about that
<pitti> apw: ^ do you know what the kernel expects as a response? in particular for a failure?
<pitti> not sure if it notices that the uevent was processed, that would be magic
<pitti> oh, I think the helper needs to write -1 into <syspath>/loading
<apw> pitti, there is a loading, which you shove a 0 in to say you are loading, a 1 in to say you did it ok, -1 to say it broke
<pitti> apw: that would be e. g. /sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/net/wlan0/loading for seb128's case?
<seb128> pitti, that files doesn't work (e.g still the 2 minutes delay) and it feels like it made boot slower
<pitti> seb128: yeah, we just figured that out
<apw> hmmm, isn't a firmware thing somewhere else like /sys/class/firmware/
<seb128> but the boot slower might be a wrong impression
<apw> what does the udev rule use
<pitti> -        strscpyl(loadpath, sizeof(loadpath), udev_device_get_syspath(dev), "/loading", NULL);
<pitti> +E: DEVPATH=/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/firmware/iwlwifi-6000-5.ucode
<pitti> so probably that plus /loading
<apw> pitti, can't we just read the loader?  is a c prog right?
<pitti> apw: yes, that 's the line above (with strscpyl)
<pitti> seb128: can you try this:
<pitti> SUBSYSTEM=="firmware", ACTION=="add", ATTR{loading}="-1"
<apw> that looks like that sort of thing
<pitti> apw: yeah, that would be nice and efficient, and avoid calling out to shell or building a dummy program
<seb128> pitti, that one works :-)
<pitti> !
<didrocks> sweet!
 * pitti ^5s seb128 and apw
 * seb128 ^5s pitti back
<apw> ok great :)
<apw> pitti, what was the bug# for that
<pitti> seb128: ok, I'll prettify this (including initramfs)
<ogra_> hey, you could just include that rule from ubuntu touch, we use it as default there ;)
<ogra_> convergence !!
<pitti> apw: bug 1398458, I kept track of the discussion there
<ubottu> bug 1398458 in systemd (Ubuntu) "kernel fails to load iwlwifi firmware - disable CONFIG_FW_LOADER_USER_HELPER" [Medium,In progress] https://launchpad.net/bugs/1398458
<pitti> ogra_: and you only tell me now, after an hour of debugging :)
<ogra_> pitti, i didnt see the conversation til now
<pitti> apw: so we can use that to track the disabling of that kernel config, in the meantime I'll add that rule
<pitti> ogra_: (see the smiley)
 * ogra_ is wrangling with a broken heating since last night ... i'm afk on and off 
<ogra_> ;)
<pitti> ogra_: quick, write an udev rule for it!
<ogra_> haha
<ogra_> that will surelyy fix my pumps
<pitti> SUBSYSTEM=="heating", ATTR{state}=="autodestruct}, ATTR{power}="0"
<pitti> seb128: 217-3ubuntu1 uploaded, with that fix
<seb128> pitti, \o/
<seb128> pitti, I can delete the file you asked me to add then?
<pitti> seb128: yes, you should (unless you need to reboot again until it hits vivid)
<seb128> pitti, no, I'm fine, deleting it, thanks
<seb128> (worth case I need to wait for the timeouts)
<Noskcaj> Could we re-add the libusb-1.0 package? libusbx has been RMed in debian, and is outdated in ubuntu
<Noskcaj> libusb and libusbx were merged
<Noskcaj> (upstream)
<Noskcaj> cjwatson, looks like you did the RM, can you take a look?
<cjwatson> Noskcaj: Not at this time; send me mail?
<Noskcaj> ok
<cjwatson> Noskcaj: also, while we're both at least sort of here:
<cjwatson> 2014-10-30.log:10:48 <cjwatson> Noskcaj: you uploaded a new upstream release of gnuhealth a while back, which is now causing a bunch of other stuff to be stuck in -proposed due to strict dependencies on tryton-*; since then, gnuhealth has been removed from Debian.  are you actually interested in maintaining this package permanently in Ubuntu or can I remove it from Ubuntu to match Debian?
<Noskcaj> I have no use for the package or reason to maintain it. I just did the new release so utopic had a fuctional version
<cjwatson> Noskcaj: righto, I'll remove that then, thanks
<Noskcaj> ok
<cjwatson> and yeah, libusb* has been nagging at me to sort out for a while ...
<cjwatson> will have a look tomorrow morning if reminded by mail
<Ice-x> 6 Please buy this game http://www.desura.com/games/WipeGround-Wpx =
<mterry> doko, you around?   I wanted to ask about python:any in build-deps
<doko> mterry, yep?
<mterry> doko, I think I figured it out, I was just curious about the practice of using python:any in build-deps, but I guess it's for crossbuilding, eh?
<doko> mterry, yes, exactly. that's the only reason. have a look at zope.interface
<berz3rk> Hey
<berz3rk> Can you help on this bug #1355698
<ubottu> bug 1355698 in elementary OS "Unable to boot via UEFI into installed freya system [$500]" [High,Confirmed] https://launchpad.net/bugs/1355698
<berz3rk> somehow there are big issues with uefi
<ScottK> Shouldn't you be asking the elementary devs?
<teward> I was about to say the same thing
<teward> berz3rk: that's something you should bring up with the Elementary OS devs, not here, I believe.
<berz3rk> well yes
#ubuntu-devel 2014-12-03
<ari-tczew> slangasek: could you take a look on merge bug 1396381 please?
<ubottu> bug 1396381 in gnu-efi (Ubuntu) "Merge gnu-efi 3.0v-5 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1396381
<pitti> Good morning
<ari-tczew> morning
<dholbach> good morning
<pitti> xnox, cjwatson: ubiquity's upstart job emits "starting-dm", but I don't see anythign which would actually listen to that (I grepped the entire live system); I guess that's just obsolete now?
<pitti> lightdm also doesn't emit this event
<xnox> pitti: one sec.
<xnox> pitti: it used to be in the plymouth package, keybuk removed starting-dm event dependency in 5 years and 1 day ago.
<loucura> Hi! Could someone check this bug in oneconf: https://bugs.launchpad.net/ubuntu/+source/oneconf/+bug/1165104 ? It prevents the Software Center package sync from working. The bug has a merge request waiting for review for some time now, and it seems that fix still works.
<ubottu> Launchpad bug 1165104 in oneconf (Ubuntu) "oneconf is only showing the pc you are on in raring and isn't sharing to other machines" [High,Triaged]
<xnox> pitti: plymouth boot splash used to stop upon "starting-dm" screen, this from before DMs would talk to plymouth and stop it themself.
<xnox> s/screen/event/
<LocutusOfBorg1> hi developerz
<LocutusOfBorg1> have a good bug hunting day :)
<diwic> LocutusOfBorg1, thanks, I just hunted one down :-)
<LocutusOfBorg1> well done :)
<LocutusOfBorg1> I prepared right now the virtualbox upload on debian experimental
<cjwatson> xnox: oh well found, I'd been failing to dig that up
<LocutusOfBorg1> and next I'll ask probably a sync from there :)
<brainwash> xnox: there seems to be no real progress re 1375893 . could xubuntu maybe opt-in for a simple solution (e.g. feh) instead of depending on xfdesktop4 to draw the background?
<brainwash> bug 1375893
<ubottu> bug 1375893 in xfdesktop4 (Ubuntu) "Black background to Try/Install Dialogue" [Medium,Confirmed] https://launchpad.net/bugs/1375893
<pitti> tseliot: do you have a machine which needs gpu-manager?
<pitti> tseliot: I'll add a systemd unit to ubuntu-drivers-common, and I'll verify that it starts properly, but it would be good to have a final test where some failure is "visible"
<tseliot> pitti: sure
<tseliot> pitti: it should always start on first boot. I can tell you how to simulate first boot, then you can check the log
<pitti> tseliot: oh, your latest upload didn't build on arm64
 * pitti retries the build
<tseliot> pitti: but yes, if you have some packages, I'll test it here (I need to upgrade to vivid first)
<xnox> brainwash: it's not just the background that's a problem. xfce4settings daemon ends up defunct.
<xnox> brainwash: whilst background is the most visible thing, other little things have also stopped working under ubiquity.
<xnox> brainwash: a regression in xfce4settings should be found, or things identified what makes it go boom - e.g. some environment or service missing etc.
<brainwash> xnox: it should be quite easy to find something in the commit/package history, something like this does not happen out of nowhere.. or? :)
<brainwash> I'll try to do some research
<brainwash> xnox: can you maybe revert the importance of this bug back to "high"?
<brainwash> xfsettingsd should not fail
<brainwash> and I guess that we should change xfdesktop4 -> xfce4-settings
<pitti> tseliot: oh, I know, I've seen this "calling: hwdb" before -- apparently the buildd has "debug" in its /proc/cmdline which switches udevadm to debug mode and prints that
<pitti> debian bug 769228
<ubottu> Debian bug 769228 in udev "udevadm shows debug messages by default on ARM" [Minor,Open] http://bugs.debian.org/769228
<pitti> tseliot: ok, I pushed the FTBFS fix
<pitti> tseliot: do you mind if I stop writing /var/log/gpu-manager.log? I just let it output to stdout/err, which will land in the journal
<pitti> tseliot: so that you see it with "sudo systemctl status gpu-manager" (or in journalctl of course)
<pitti> tseliot: I added the unit in https://github.com/tseliot/ubuntu-drivers-common/commit/c365141a7b4, works fine here
<pitti> tseliot: 0.2.98.6 uploaded, this should also fix the FTBFS
<cjwatson> doko_: could somebody have a quick look over bug 1398807, please?
<ubottu> bug 1398807 in google-apputils-python (Ubuntu) "[MIR] google-apputils-python" [Undecided,New] https://launchpad.net/bugs/1398807
<mvo> StevenK: hi, are you on archive admin duty today or is https://wiki.ubuntu.com/ArchiveAdministration outdated? NEW for ubuntu-sdk-libs-tools would be cool
<_ruben> I'm trying to backport rrdtool 1.4.8 (or 1.4.9 for that matter) for 14.04. But debuild -S is failing for me, is this the proper place ask?
<didrocks> mvo: I guess nobody is really following the AA duty anymore, binNEWed
<mvo> didrocks: \o/
<ScottK> I think the schedule is dead, but people do still look at New.
<teward> _ruben: I think you should start by providing what 'error' you're seeing, there's here and #ubuntu-packaging as example places you can ask about having issues with building packages...
<_ruben> teward: let me pastebin what I get
<_ruben> teward: http://paste.ubuntu.com/9354611/
<tseliot> pitti: is there any way we can collect the log from apport?
<cjwatson> _ruben: "debuild -S -nc" will let you build the source package without having to have build-dependencies installed; but I don't understand the sequence of commands you're running, what's the point in all that?
<cjwatson> _ruben: to extract the source package, just use "dpkg-source -x rrdtool_1.4.8-1.1ubuntu1.dsc", don't mess about with applying the diff by hand
<cjwatson> _ruben: and you would only need to use "debuild -S" after actually making some change to the source package, which there's no sign of in that transcript
<_ruben> cjwatson: pretty much the only additional step I'd add after this would work would be using 'dch' to have it point to 'trusty' instead of 'utopic' (as I haven't found a way to fool mini-dinstall without that)
<cjwatson> _ruben: that seems thoroughly unnecessary
<doko_> cjwatson, done. although if it's cloud related, maybe the cloud team could subscribe as well
<_ruben> cjwatson: primary goal: backport from utopic to trusty or even from upstream
<cjwatson> _ruben: sbuild -d trusty will put "Distribution: trusty" in the resulting binary .changes file, which is all you'll need
<_ruben> cjwatson: these steps are based on ancient research, and have worked fine thusfar ;) wouldn't surprise if there's other/better ways to deal with this
<cjwatson> _ruben: well, your "apply diff by hand" thing is totally wrong, don't do it :)
<cjwatson> that will break with many modern packages
<_ruben> cjwatson: that one's on my todo list, as in: i noticed certain (newer?) package doing this automatically after dget'ing the source
<cjwatson> _ruben: like I say, the One True Correct Way to unpack a source package is dpkg-source -x foo.dsc
<cjwatson> anything else is bad and wrong
<_ruben> cjwatson: will keep that in mind
<cjwatson> (apt-get source, pull-debian-source, pull-lp-source, etc. all wrap dpkg-source -x at various points)
<cjwatson> doko_: thanks
<cjwatson> smoser: could some appropriate cloud team subscribe to google-apputils-python, perhaps?  cf. bug 1398807
<ubottu> bug 1398807 in google-apputils-python (Ubuntu) "[MIR] google-apputils-python" [Undecided,Fix released] https://launchpad.net/bugs/1398807
<cjwatson> and discussion above
<cjwatson> _ruben: you might also look into the backportpackage tool
<_ruben> (and I need to look into why dch refuses to use the info in ~/.devscripts some day)
<_ruben> cjwatson: interesting, even includes the dput part. will definately look into that one
<smoser> cjwatson, "i've subscribed foundations-bugs" you also want server subscribed ? that is fine, but just clarifying.
<cjwatson> smoser: I'm just following up on 13:26 <doko_> cjwatson, done. although if it's cloud related, maybe the cloud team could subscribe as well
<cjwatson> smoser: without knowing exactly which team is appropriate on your end
<smoser> k. done.
<smoser> ubuntu-server is subscribed
<cjwatson> thanks!
<cjwatson> hopefully this will let us start the protobuf transition.  (and clear another thing from "grep-merges cjwatson", which is my actual motivation ...)
<mlankhorst> how do I start a full ubuntu desktop without lightdm?
<pitti> hallyn: do you plan to merge samba soon? there is a new ldb in -proposed which samba-libs conflicts to, thus causing a lot of uninstallability
<pitti> otherwise I can do a no-change upload, but I don't want to earn the samba merge with that
<tseliot> pitti: does "sudo systemctl status gpu-manager" dump the log into a file? I need logs to be easy to attach to bug reports
<pitti> tseliot: no, that shows the gpu-manager related bits from the journal
<mardy> jdstrand: is there a way to check the profile label of a running PID, from the command line?
<tseliot> pitti: then, if there's no alternative, we should keep writing the log to a file
<pitti> tseliot: ah sorry, missed your question above
<pitti> tseliot: ok; indeed you currently can't access the journal as user
<tseliot> ok
<pitti> tseliot: pushed/uploaded
<tseliot> pitti: thanks
<jdstrand> mardy: yes, ps -Z
<jdstrand> mardy: or cat /proc/<pid>/attr/current
<mardy> jdstrand: cooool!!
<jdstrand> I find 'ps auxwwZ' handy
<cjwatson> pitti: I notice you aborted the gutenprint autopkgtest - was it hanging or something?
<pitti> cjwatson: on armhf/ppc64el; yes, they always hang there, and I needed to do some admin/reboot on these devcies
<cjwatson> pitti: oh, it's always failed.  but I wonder if that's why it still shows as "test in progress" on excuses
<pitti> cjwatson: did I kill an x86 one by accident?
<cjwatson> pitti: looks like on x86 too
<pitti> cjwatson: ah sorry, rerunning
<cjwatson> thanks
<cjwatson> doko_: re google-apputils-python, I mentioned in the MIR that it requires python-gflags which used to be in main but was moved to universe.  do you agree with my assessment that we can move it back to main based on the previous MIR?
<mardy> jdstrand: FYI, I added some comments here and added apparmor-easyprof to the bug: bug 1219644
<ubottu> bug 1219644 in Online Accounts setup for Ubuntu Touch "Account plugins should be made confinable by apparmor" [Medium,In progress] https://launchpad.net/bugs/1219644
<zul> doko_:  ping
<jdstrand> mardy: thanks. I'll also add a click-reviewers-tools task
<pitti> sforshee: bug 1398458> yeah, not at all urgent any more, with the userland stub
<ubottu> bug 1398458 in linux (Ubuntu) "kernel fails to load iwlwifi firmware - disable CONFIG_FW_LOADER_USER_HELPER" [Low,In progress] https://launchpad.net/bugs/1398458
<pitti> mostly a cleanup thing for the futuer
<sforshee> pitti: sure, but better to get it fixed before I forget about it ;-)
<doko_> jdstrand, yes, always handled this way
<doko_> now promoted
<doko_> zul, here
<zul> doko_:  have you seen this? bug 1348954, or bug 1367907 and bug 1382607
<ubottu> bug 1348954 in python3.4 (Ubuntu) "update Python3 for trusty" [Undecided,Confirmed] https://launchpad.net/bugs/1348954
<ubottu> bug 1367907 in python3.4 (Ubuntu Trusty) "Segfault in gc with cyclic trash" [Undecided,Triaged] https://launchpad.net/bugs/1367907
<ubottu> bug 1382607 in python3.4 (Ubuntu Trusty) "[SRU] Backport python3.4 logging module backward incompatibility fix." [High,Triaged] https://launchpad.net/bugs/1382607
<cjwatson> doko_: thanks
<doko_> zul, yes, I filed at least the first one
<bdmurray> hallyn: I'm unable to start a domain in virtual machine manager due to not being able to find kvm-spice. Any ideas?
<zul> doko_:  any eta?
<doko_> I still hope this year ... although time is running out for me with planned vacations
<shadeslayer> pitti: autopkgtest question for you, how can I parallelize the build that's run by adt
<cjwatson> mdeslaur,jdstrand: do you have any opinions on following Debian in /dev/fuse permissions, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733312 ?  We seem to have addressed a similar problem by making fusermount root:root 4775 instead, but I'm wondering whether we need to keep that delta
<ubottu> Debian bug 733312 in fuse "fuse: Please reconsider the permissions on /dev/fuse and /bin/fusermount" [Normal,Fixed]
<infinity> shadeslayer: You mean the automated build from a "build-needed" test?
<shadeslayer> infinity: yes
<infinity> shadeslayer: That should parallelise the same as a regular package build via DEB_BUILD_OPTIONS="parallel=" and if it's not, either pitti's runners don't have multiple cores or he's not exporting the variable, but it's entirely on his end, not yours.
<shadeslayer> infinity: well, I'm writing my own tooling to run some autopkgtests on debian, and wanted to parallelize the build
<shadeslayer> so yeah
<infinity> shadeslayer: If you mean running adt locally, yeah, maybe it needs a fix to export the variable. ;)
<shadeslayer> yep
<shadeslayer> infinity: so something like export DEB_BUILD_OPTIONS="parallel=8" would work right
<infinity> shadeslayer: The simplest solution is just "export DEB_BUILD_OPTIONS="parallel=$(nproc)"" somewhere before the build happens.
<shadeslayer> roger
<shadeslayer> works, thx
<mdeslaur> cjwatson: the fuse device basically allows people to become root, having fusermount be 4775 is the right approach I believe
<cjwatson> mkay, possibly somebody with more time should clue up the Debian maintainer :)
<mdeslaur> cjwatson: I haven't look in a long time, but I don't currently have time to spend on refamiliarizing myself with all the changes
<mdeslaur> cjwatson: It's probably best to leave it as-is for now if you don't mind
<cjwatson> sure
<cjwatson> just trying to get my merge list as far down as I can before switching to LP :)
<shadeslayer> which reminds me
<shadeslayer> cjwatson: who will I go to for all my live build issues now :(
<cjwatson> I'm sure somebody can be found on #ubuntu-release
<shadeslayer> ^_^
<cjwatson> or here for that matter
<infinity> shadeslayer: I suspect you'll find that stgraber and I end up fielding most of those questions initially, but do ask openly on #-release, rather than privately, so we can try to smear the ex-Colin tasks (and knowledge) around a bit.
<shadeslayer> roger :)
 * shadeslayer has a decent bit of lb knowledge now
<shadeslayer> which usually comes down to "The documentation lies, read the code"
<infinity> There's documentation?
<shadeslayer> xD
<infinity> I've only ever hacked lb using grep. :P
<shadeslayer> http://live.debian.net/manual/unstable/
<infinity> Anything else seems like a lost cause.
<shadeslayer> infinity: hehe
<shadeslayer> infinity: by documentation I meant how to use lb
<shadeslayer> not code documentation
<infinity> shadeslayer: Oh, sure.  Even "how to use" is something I deal with using grep, though. ;)
<shadeslayer> hah
<shadeslayer> infinity: yeah, best to keep doing it that way
<infinity> shadeslayer: "I kinda want to do this weird thing we don't do, let's grep for possible things that might sort of do that and see."
<shadeslayer> yep
<shadeslayer> I actually have to figure out efi madness with lb sometime
<shadeslayer> that'll be fun
<infinity> shadeslayer: I still have this master plan (which I think it's clear I don't have time for *sigh*) to make lb produce images that are nearly identical to our debian-cd-wrapped infrastructure (minus the package pools, initially, but at least the same boot magic).
<shadeslayer> oh, that would be so awesome :3
#ubuntu-devel 2014-12-04
<bdmurray> slangasek: Does the RetraceFailure information make sense? https://errors.staging.ubuntu.com/oops/205498dc-7b4b-11e4-9ba5-fa163e1893a8
<slangasek> bdmurray: it's a surprising failure, but it makes sense
<bdmurray> slangasek: I guess I really meant are those new field useful
<slangasek> bdmurray: yep - that's how I understood the question :) yes I think it's useful
<pitti> Good morning
<pitti> shadeslayer: can you please file a bug about this? I think adt-run should detect the number of available cores and use that as a default for parallel=N; we might also have a new option for this
<pitti> shadeslayer: note that on ci.debian.net there is only one core, but for ubuntu there are two (or four for "big" packages)
<pitti> hallyn: samba is breaking heaps of stuff, I'm uploading a no-change rebuild now; but it would still be good to merge (and I earned enough merges by cleaning up -proposed by now, I'm not going to do that one, too)
<dholbach> good morning
<mwhudson> is there any thing (service?) that checks whether two packages in the archive attempt to install a file to the same path?
<mwhudson> (unless the packages conflict: each other or anything like that)
<mwhudson> ah https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=edos-file-overwrite;users=treinen@debian.org
<mwhudson> does anyone run that for ubuntu?
<cjwatson> mwhudson: There used to be http://conflictchecker.ubuntu.com/possible-conflicts/, but as you can see from the index it's been unmaintained for some time
<cjwatson> I forget who maintained that ...
<cjwatson> Might be worth replacing it with something based on edos-file-overwrite nowadays, indeed
<caribou> xnox: around ?
<xnox> caribou: yeap
<caribou> xnox: I saw your note on uploading makedumpfile latest to experimental
<caribou> xnox: what's the benefit : being able to sync from there into Ubuntu ?
<xnox> caribou: yes. and removing it from ubuntu's blacklist.
<xnox> caribou: generally around freeze time one should switch sid -> experimental for all new uploads. That leaves room to continue using sid for release team unblocks.
<xnox> caribou: or did a too new upstream version migrate to jessie and then was decided to be reverted by debian's release team? hence the mandatory epoch?
<caribou> xnox: no, an old version stalled in jessie because of a grave bug that got fixed but not closed
<caribou> xnox: and the newest version, which would be required for sid 3.16 kernel also got blocked
<xnox> caribou: ah =/ right, then the fix up could have gone into testing-proposed-updates with no epoch-bump in sid for downgrade in version number....
<xnox> meh, too late now.
<caribou> xnox: the release team was not too enthusiastic about sending it direct to testing-proposed-updates
<xnox> caribou: =))))))) release team are such sceptical people. i guess it's for the better.
<caribou> xnox: carryin the epoch is no big deal. But I wasn't aware of the experimental usage around freeze
<caribou> xnox: all that happened soon after I became officially DM so I missed a few things here & there. Will be better next time
<xnox> caribou: =)))) yeah, no worries.
<caribou> xnox: I want to 'fix' the latest version to work with systemd; then I'll upload 1:1.5.7-4 with it to experimental
<caribou> xnox: the one in sid does
<xnox> caribou: sounds good =)
<mwhudson> cjwatson: cool, doesn't seem like it would be thaaaaaat hard
<cjwatson> famous last words
<mwhudson> cjwatson: heh, not promising anything in any way whatsoever
<doko> Laney, seb128: any idea about https://jenkins.qa.ubuntu.com/job/vivid-adt-glib2.0/21/ARCH=amd64,label=adt/  ?
<doko> ScottK, Riddell: some new autopkg test failures for k* packages (triggered by gcc-4.9). any idea?
<pitti> doko, ScottK, Riddell: already retried, the testbed machines are once again overloaded
<doko> ahh, ok
<pitti> doko: I'm watching the failures and press the buttons
<seb128> doko, not sure, Laney was looking at the glib issue
<shadeslayer> pitti: will do
<didrocks> shadeslayer: hey! I see nothing in the transition ppa for bluez5, do you need any help?
<shadeslayer> didrocks: I got a release out of the bluedevil team yesterday, but still no libbluedevil, so I'm waiting for them to release the lib
<shadeslayer> pitti: https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1399177
<ubottu> Launchpad bug 1399177 in autopkgtest (Ubuntu) "adt-run should parallelize builds as necessary by default" [Undecided,New]
<didrocks> shadeslayer: do you think this will come in a matter of days? I would love starting a call for testing start of next week
<shadeslayer> didrocks: let me ask the maintainer
<didrocks> shadeslayer: thanks :)
<shadeslayer> didrocks: yes, probably today/tomorrow
<didrocks> shadeslayer: keep me posted!
<shadeslayer> didrocks: will do :)
<shadeslayer> let me check if I can upload things
<didrocks> shadeslayer: core-devs should be able, but yeah, better to double-check :)
<shadeslayer> nope, I'm not a core-dev
<shadeslayer> so can't upload
<shadeslayer> didrocks: I'll upload it to one of my PPA's and then someone can copy it over
<didrocks> shadeslayer: sounds good!
<shadeslayer> cool :)
<didrocks> thanks again ;)
<shadeslayer> yw :)
<shadeslayer> sitter: ^^ I reckon we can CI bluedevil too
<shadeslayer> assuming it's ported to KF5
<sitter> as with everything alex does there is an unreleased frameworks port :P
<sitter> though to be fair I think he didn't do the port
<sitter> shadeslayer: having red the backlog I guess bluez5 wirst needs to transition to the archive. once it is in CIing it only depends on someone pinning a relase date/schedule/scope on the frameworks port
<sitter> s/wirst/first
<shadeslayer> sitter: roger
<pitti> shadeslayer: thanks
<shadeslayer> cheers
<shadeslayer> didrocks: so, libbluedevil uploaded to https://launchpad.net/~rohangarg/+archive/ubuntu/kde-extra/+packages
<shadeslayer> didrocks: could you copy it once it's built
<didrocks> shadeslayer: excellent! this is the only one needed?
<shadeslayer> didrocks: no, once libbluedevil is built, I need to upload the bluedevil
<shadeslayer> the bluedevil xD
<didrocks> heh ;)
<didrocks> ok, will ping you once I copied and it's built there
<shadeslayer> okie
<shadeslayer> didrocks: bluedevil might take some time, I have to deal with this vodoo patch http://paste.ubuntu.com/9367508/
<didrocks> shadeslayer: oh, RPATH fun! "enjoy" :p
<shadeslayer> didrocks: yeah, not really sure if it makes sense to have that patch, since we have RPATH enabled on kdelibs and it should be propogating upwards to all of the things
<dgadomski> hey cjwatson, did you manage to take a look at the 2 ubiquity bugs we discussed in DC? bugs #1386131 #1386153
<ubottu> bug 1386131 in ubiquity (Ubuntu) "Preseeding encrypted lvm fails instead of asking for password" [Undecided,New] https://launchpad.net/bugs/1386131
<GunnarHj> Hi pitti!
<pitti> hey GunnarHj, how are you?
<GunnarHj> pitti: Fine, thanks. You?
<GunnarHj> pitti: If you have time: Anything you would like to say at http://askubuntu.com/questions/435954 or bug #1394929?
<ubottu> bug 1394929 in glibc (Ubuntu) "Please provide 'locales-all' as in Debian" [Undecided,Confirmed] https://launchpad.net/bugs/1394929
<cjwatson> dgadomski: I committed the fix for one of them; I think one of my successors is going to have to pick up the other though
<pitti> GunnarHj: ah, I talked about that with infinity a while ago; the intention is to bury langpack-locales and move them back to glibc, as the idea of maintianing locales on launchpad never took off (and probably isn't such a good idea in the first place)
<cjwatson> dgadomski: actually that was a third one, bug 1386113
<ubottu> bug 1386113 in ubiquity (Ubuntu) "Preseeding encrypted lvm fails with "An error occurred while creating the keyfile"" [High,Fix released] https://launchpad.net/bugs/1386113
<pitti> GunnarHj: I think infinity has that planned, but I don't know when
<GunnarHj> pitti: Aha, I see. Would it mean that locales-all would be available in Ubuntu?
<pitti> GunnarHj: yes
<dgadomski> cjwatson: exactly, the third one is fixed and tested by the user
<GunnarHj> pitti: Ok, thanks.
<dgadomski> cjwatson: do you have any particular names in mind to handle the other two?
<cjwatson> dgadomski: hopefully slangasek can give you a name; I have seven working days left before moving to another position
<dgadomski> cjwatson: oh, didn't know you are moving, thank you!
<cjwatson> dgadomski: (still within Canonical, but I won't be doing installer work any more)
<dgadomski> cjwatson: thanks and good luck with the new position
<brainwash> slangasek: the xfce4 meta package is synced from debian and recommends "desktop-base" which installs debian wallpapers, a debian grub background and so on
<brainwash> slangasek: would it be ok to drop it to suggests?
<brainwash> bug 1080865
<ubottu> bug 1080865 in xfce4 (Ubuntu) "Debian instead of Ubuntu grub splash" [Low,Triaged] https://launchpad.net/bugs/1080865
<shadeslayer> didrocks: bluedevil uploaded as well
<Raydiation> hi, can i run sysvinit scripts in 14.04?
<Raydiation> i would like to limit avoid upstart
<Raydiation> -limit
<Raydiation> and just support systemd + sysvinit
<shadeslayer> Raydiation: yep
<shadeslayer> Raydiation: see /etc/init.d/README
<shadeslayer> Raydiation: note that systemd is not fully supported on 14.04
<shadeslayer> Raydiation: /etc/init.d/skeleton is a example init file
<Raydiation> ty
<Raydiation> shadeslayer: yep unfortunately :P
<Raydiation> the one init system to rule them all will make things sooo much easier
<Raydiation> :D
<Raydiation> at least for packaging cross distro software
<Raydiation> Is the next release planned to include systemd?
<Raydiation> as in 15.04?
<cjwatson> Raydiation: It's likely to.
<Raydiation> ty
<bdmurray> seb128: fyi retrace failure reasons now appear on individual OOPS reports for recent retracings on errors.
<pitti> infinity, ScottK: any chance to accept postgresql-9.4 in the utopic queue? it's been there for two weeks now
<pitti> (as per MRE)
<infinity> pitti: What's it worth to you?
<seb128> bdmurray, hey, nice, thanks for that
<bdmurray> seb128: I plan on having information about the failures in the bucket real soon too
<bdmurray> pitti: I'm on duty today and will have a look
<seb128> cool
<bdmurray> pitti: and the 25th is a bit short of two weeks
<arges> xnox: hey, i see you're looking at intel/HLE errata fallout bugs. fyi I'm working on bug 1398975 to patch glibc
<ubottu> bug 1398975 in glibc (Ubuntu Utopic) "hardware-assisted lock elision hazardous on x86" [Medium,In progress] https://launchpad.net/bugs/1398975
<xnox> arges: yeah, what's up?
<xnox> arges: if need / want testing, you can subscribe ~intel-team there are a few qa folks there.
<arges> xnox: just letting you know since it seems like there are alot of various updates to do... intel-microcode, glibc, and I think you were looking at that new package... ucode something
<xnox> arges: they generally test from -proposed though.
<arges> xnox: awesome may do that
<xnox> arges: i'm looking into making microcode to be installed by default. I'm not working on doing glibc updates, however. So thanks for doing that ;-)
<arges> xnox: np. so trying to figure out what needs to be done for bug 1388889 since i was assigned it. does something need to be SRUed? or since you did the sync I assume the intel-microcode task is done?
<ubottu> bug 1388889 in iucode-tool (Ubuntu) "[MIR] intel-microcode & iucode-tool (multiverse -> restricted)" [Undecided,Incomplete] https://launchpad.net/bugs/1388889
<xnox> arges: i'm not sure, are you archive admin? in that case it needs promotion from multiverse->restricted..... if the mir report is complete.
<arges> xnox: ah that makes sense, i'll bug infinity about it then : )
<xnox> arges: i'm not sure why tim assigned it to you though.
<xnox> arges: i didn't think he is on the mir team to approve such things.
<xnox> arges: i'll remove assignee from you.
<arges> yea not really sure : ) regardless seems like something an AA can do
<xnox> mterry: should look at the bug again =) everything is fixed up in vivid as per review comments now.
<xnox> when he has time that is.
<mterry> xnox, the intel mir?
<xnox> mterry: yeah.
<mterry> xnox, can you subscribe the teams to the packages?
<xnox> mterry: let me check.
 * pitti hands some yummy Stollen to infinity
<pitti> bdmurray: ah great, thanks!
<xnox> mterry: no, i can't. =(
<xnox> arges: are you admin for kernel team?
<mterry> xnox, I don't think you need to be admin, just a member
<xnox> or I guess, ogasawara, could you please subscribe ~intel-team and ~canonical-kernel to  intel-microcode & iucode-tool packages ?
<arges> xnox: yea just for kernel stuff
<xnox> Bug mail recipient
<xnox>  Yourself
<xnox>  One of the teams you administer
<xnox> mterry: ^ and in the dropdown i don't see intel-team =(
<mterry> ah
<cjwatson> Yes, you need to be an admin
<arges> xnox: ok another one is bug 1370352. so intel-microcode had microcode-20140913.dat reverted. I'm thinking we un-revert it once fixes are in place for glibc, plus if there are fixes needed to SRU from latest intel-microcode
<ubottu> bug 1370352 in intel-microcode (Ubuntu Trusty) "[Feature] Intel new CPU microcode 20140913 " [Undecided,In progress] https://launchpad.net/bugs/1370352
<xnox> arges: in vivid everything is fine - that is microcode is loaded extra early, /proc/cpuinfo never says that there is txt and everything works like a charm....
<xnox> arges: the sync in vivid overwrote ubuntu's changes.
<xnox> arges: as they are not needed anymore.
<arges> xnox: ok so at this point anything needed to be SRUed
<xnox> arges: with respect to SRU you probably only want to sru back glibc change
<xnox> arges: without changing / sruing intel-microcode at all.
<arges> xnox: that makes sense too
<xnox> arges: if glibc doesn't use txt, even if present / no microcode updated everything is good.
<xnox> arges: simply sruing the new intel-microcode will not help, as that is not installed by default. hence one must sru glibc, and that is sufficient for stable release.
<arges> xnox: well i think the trend is the new microcodes are usually SRUed as updates even to stable releases
<arges> but in that bugs case we hit the microcode update which blacklisted HLE instructions which were used by glibc which caused illegal opcodes.
<ogasawara> xnox: fyi, I've added ~intel-team as a subscriber to both the intel-microcode and iucode-tools packages
<xnox> ogasawara: thanks. mterry ^
<ogasawara> xnox: I left off subscribing ckt since we're members of the intel-team
<mterry> xnox, ogasawara: thanks, will look at MIR again today
<xnox> ogasawara: ack.
<bdmurray> ChrisTownsend: Could you add some information about how you verified bug 1363959?
<ubottu> bug 1363959 in Nux trusty "compiz crashed with SIGSEGV in nux::WindowCompositor::DndEventCycle()" [High,In progress] https://launchpad.net/bugs/1363959
<bdmurray> Laney, mvo: Where is vte2.91? https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/revision/2842
<bdmurray> arges: bug 1398975 is missing a trusty task
<ubottu> bug 1398975 in glibc (Ubuntu Utopic) "hardware-assisted lock elision hazardous on x86" [Medium,In progress] https://launchpad.net/bugs/1398975
<bdmurray> arges: oh, I see it now
<ChrisTownsend> bdmurray: Well, there is no real repro case, so my verification is that it's been in Utopic for some time (and Vivid) and I've been running this nux since it was in the ci-train PPA (and -proposed after that).
<ChrisTownsend> bdmurray: I wasn't sure how to put that in the verification note.
<bdmurray> ChrisTownsend: just saying that would have helped
<ChrisTownsend> bdmurray: Ok, I can still add it for completeness.
<bdmurray> ChrisTownsend: okay, thanks
<ChrisTownsend> bdmurray: No problem.  Sorry about the confusion.
<kkirsche> hey everyone, I'm trying to get started with, what I think, should be the easiest of packaging tasks ââ which is that I would like to take a the NodeJS package (v 0.10.25) and update it to the source found at http://nodejs.org (v. 0.10.33). I have gotten the source using bzr branch ubuntu:nodejs nodejs.dev, then gotten the upstream tarball (bzr get-orig-source). From here, cd.., then bzr branch nodejs.d
<kkirsche> ev bug-1103044. I then update the files in bug-1103044 with the files from Node's source. dch -i and say it's an "Vendor update (LP: #1103044)" (no other changes made) and do bzr commit. I then use dpkg-source --commit so that dpkg is happy with the new changes. I then try bzr builddeb -S within the bug-1103044 branch, I get: "dpkg-source: fuzz is not allowed when applying patches." I tried quilt refresh an
<kkirsche> d that spit out a bunch of warnings regarding trailing whitespace in their files but no errors that I could see. At this point I'm feeling a bit lost as to how to submit what I thought would be a simple vendor update. Any help would be appreciated. Thanks for your time and for reading this.
<ubottu> Launchpad bug 1103044 in nodejs (Ubuntu) "outdated version of nodejs (ubuntu 12.04 / 12.10 / 13.04 / 14.04)" [Wishlist,Triaged] https://launchpad.net/bugs/1103044
<bdmurray> Laney: Oh, its because I was using the dist-upgrader on utopic which doesn't have vte2.91.
<rharper> arges: on the qemu 2.0 package I tested, I updated bug 1370199 -- I don't think it quite fixes the issue since it requires an extra (manual) step of doing an upstart job stop, start.  Any idea how to have the packaging trigger an upstart job stop, then job start ?
<ubottu> bug 1370199 in qemu (Ubuntu Trusty) "qemu upstart job should create /dev/kvm in a container" [Undecided,Fix committed] https://launchpad.net/bugs/1370199
<arges> rharper: might be something you can do in postinst. but not sure if there is a better way
<arges> rharper: debian/<binary-package-name>.postinst is most likely teh place for it
<rharper> arges: ok -- my deb packaging fu is quite low;  but if postinst is just shell script, then I think it could be hooked (unless dpkg already does something with
<rharper> the upstart jobs
<rharper> arges: ok, lemme see what (if any is in .postinst in qemu packaging)
<arges> rharper: https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html highlight postinst
<rharper> thanks for the pointer
<arges> cool good luck
<rharper> looks like a winner
 * rharper shall see about a patch 
<xnox> slangasek: unlike fancy steak, RTs should be _well done_ not raw / uncooked.
<slangasek> xnox: um?
<xnox> slangasek: RE: your conversation with evan on RT and pictures of food. =)
<slangasek> xnox: sounds like ev is grossly misrepresenting the situation, this wasn't in RT ;)
<ev> I represented nothing
<infinity> Typical.
<ev> ly awesome
<xnox> slangasek: i think his irc is just that fancy looking, I mistook it for actual RT website snippet.
<kees> doko: do you know if https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 is fixed in Trusty's gcc 4.8.2?
<ubottu> gcc bug 58854 in target "[4.8 regression] "sub sp, fp, #40" hoisted above frame accesses" [Normal,Resolved: fixed]
<ev> xnox: I use irccloud. My beard does not extend into the neck.
 * xnox likes how all the cool people are still around.
<infinity> xnox: You have a warped definition of "cool".
<kees> doko: context is git.kernel.org/linus/7fc150543c73de71859631c8a6b17e3067fe7617
<TheMuso> off
<doko> kees, according to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854#c8 it should be, commited in 2013-11
<ubottu> gcc bug 58854 in target "[4.8 regression] "sub sp, fp, #40" hoisted above frame accesses" [Normal,Resolved: fixed]
 * xnox has a rude beard comment i should keep to myself
<TheMuso> ugh
<TheMuso> Damn workspaces bug in vivid, keyboard focus not always switching over...
<kees> doko: when is that, compared to the 4.8.2 release and Ubuntu's 4.8.2 compiler?
<slangasek> wait, so ev posted a picture of our conversation about him posting pictures of food?
<ev> captioned meta. I then contemplated getting the picture put on the quotes page, then posting that to facebook
<xnox> slangasek: yes on instragram that got syndicated on my facebook news feed
<infinity> kees: It was fixed in r204665, and trusty's at r209122
<infinity> kees: So, unless it was later reverted (or reverted locally), it should be fixed.
<doko> gcc-4.8 (4.8.2-19) unstable; urgency=medium
<doko>   * Update to SVN 20140404 (r209122) from the gcc-4_8-branch.
<doko> kees, ^^^
<kees> infinity, doko: ah-ha, okay, thanks! the bug id to svn revision to ubuntu svn revision was making my head hurt :)
<xnox> kees: generally gcc uploads in ubuntu update from release + all changes in the stable branch. Thus it's always way ahead the point number.
<kees> xnox: yeah, that's what I figured, but I just wanted to be sure.
<xnox> =)
<kees> it means upstream ARM kernel builds will blow up on Trusty now, though, thanks to the commit id I pasted...
<kees> well, "it" doesn't mean it, Ubuntu's gcc is fine, so it's a false build failure.
<infinity> Yeah, I think we knew about this.
<kees> okay, cool. looks like I didn't build an ARM kernel since this landed in October :)
<doko> yes, still have my 4.8.4 backport for trusty pending ...
<infinity> It's an irritatingly heavy-handed commit on rmk's part.
<kees> yawp
<kees> especially since it's detectable.
<infinity> Honestly, I'm just so happy that Russell is using tools from this century, it's hard to be mad.
<kees> lol
<sarnold> lol
<ari-tczew> xnox: could you take a look on bug 1291827 please? I made a merge from Debian, would be nice to get it sponsored.
<ubottu> bug 1291827 in ntfs-3g (Ubuntu) "STABLE Version 2014.2.15 " [High,Confirmed] https://launchpad.net/bugs/1291827
<xnox> ari-tczew: i ponder if this is finally time to drop that patch and just do a sync from debian though.
<xnox> cjwatson: so in 2011 s/syncio/sync was done in wubi, is ok to finally retire the syncio patch in ntfs-3g given the support levels of wubi these days?!
#ubuntu-devel 2014-12-05
<menace> hi, i packaged a firefox-addon, but  i cannot add it to reprepro because of the Error: 'unmht_7.3.0.1-0ubuntu1.debian.tar.gz' has the wrong architecture to add it to trusty! any idea, what's wrong with my package? (package is here located is http://yac1912x.gbks.net/misc/)
<menace> lintian does not really give me hints...
<xnox> menace: debian.tar.gz is not a package, but one component of a debian source package....
<xnox> menace: do you have "source" architecture enabled in the config?
<xnox> menace: no probably want to add a .dsc or .debs or .changes (that reference a set of .dsc/.debian.tar.gz/.debs) into reprepro
<slangasek> brainwash: hi, so you asked me about the xfce4 meta package... that seems like a reasonable change to me, but I'm not sure why you asked me in particular :)
<menace> xnox: what does source architecture mean?
<menace> i did try to add the changes file and so the dsc and deb file with that changes file
<xnox> menace: .dsc is a debian source package - which is just metadata pointing to upstream tarball + debian packaging tarballs, those can be compiled (e.g. with dpkg-buildpackage) to create .debs. debs can be different architectures e.g. _all.deb / _i386.deb / _amd64.deb
<menace> my distributions file seems normal: http://yac1912x.gbks.net/misc/distributions
<menace> xnox: yes, im aware of that. but the debian.tar.gz file is part of the source files afaik?
<xnox> menace: in practice repositories can publish one or more things typically refered to as source / all / i386 / amd64 etc. architectures.
<xnox> menace: yes and no. by itself it's meaningless. only .dsc & .deb have meaning.
<xnox> menace: one cannot publish a single ".debian.tar.gz" or attempt to do so.
<xnox> menace: the distributions file is odd - it is allowed to only publish _amd64.deb and no other type of files.
<xnox> and _all.deb (as that's implied)
<xnox> menace: you should change that to Architectures: amd64 source, if you wish to publishes sources (one may have to do that depending on the license of software you are publishing)
<menace> ah
<menace> hm
<menace> it works with amd64 source
<menace> hrm
<menace> thanks! :-)
<Bobby___> Hello all. I am trying to get sound playback working on an Intel Bay Trail tablet. I do not get a sound device with any firmware except for with 5339.B in the Intel ChromiumOS repo. With this firmware I only get static or no sound at all though. I have played with all the alsamixer settings and tried the ASUS t100 state file that is commonly used still with no sound.  What can I do to fix this?
<developerpenguin> he guys
<developerpenguin> can someone please help me ? :)
<Noskcaj> jtaylor, Could you please check if we can sync statsmodels now? debian has had a number of test fixes
<pitti> Good morning
<Unit193> Herro.
<jtaylor> Noskcaj: probably not but I was planning on just syncing it and see
<dholbach> good morning
<LocutusOfBorg1> hi dholbach !
<dholbach> hi LocutusOfBorg1
<tjaalton> huh, cron is not running the jobs in /etc/cron.d/ on vivid?
<pitti> stgraber: is there a trick to get sudo to work in a per-user container?
<tseliot> pitti: hey, does your systemd service for gpu-manager also start when the display manager is shut down?
<pitti> tseliot: you mean "does not start at all", or "gets shut down'?
<pitti> tseliot: if it doesn't start at all, neither will gpu-manager
<pitti> tseliot: the upstart script didn't do that, and it seems rather pointless to do that, no?
<tseliot> pitti: the old upstart job would also launch gpu-manager on shutdown
<pitti> tseliot: oh, how so?
<pitti> it just has "start on starting lightdm or ..."
<tseliot> pitti: or maybe lightdm took care of that, let me check
<pitti> not that I can see
<pitti> tseliot: i. e. it shoudl exactly mirror the upstart job right now
<tseliot> pitti: ok, then it's a non issue, sorry for the noise
<pitti> tseliot: no worries at all, thanks for double-checking!
<tseliot> pitti: BTW are we going to have systemd by default in 15.04?
<pitti> tseliot: that's the idea anyway; it now depends on how fast we can do the migration, and how fast the server team can migrate their upstart-only packages
<pitti> tseliot: the idea was to have a virtual mini-sprint in January to convert the remaining bits
<tseliot> pitti: ok, so for now I'll have to install it manually in Vivid
<pitti> http://people.canonical.com/~jhunt/systemd/packages-to-convert/
<pitti> tseliot: yes, either boot with init=/bin/systemd (no package changes) for an one-time test, or instlal systemd-sysv to boot with it by default
<pitti> tseliot: in the latter case, init=/sbin/upstart will boot with upstart again
<pitti> jodh: btw, it seems http://people.canonical.com/~jhunt/systemd/packages-to-convert/ doesn't update
<pitti> jodh: I added systemd units to ubuntu-drivers-common two days ago; pollinate did disappear now (also from two days ago)
<tseliot> pitti: do you mean init=... as a boot parameter?
<pitti> tseliot: yes, in the kernel line in grub
<Unit193> Or in /etc/default/grub if you're too lazy to install -sysv.
<tseliot> pitti: I can see that nvidia-prime needs porting too
<tseliot> yes, I know how to customise grub ;)
<jodh> pitti: hmm, really? It's reading from the internal archive and the script auto-updates from bzr?
<pitti> /lib/systemd/system/gpu-manager.service
<pitti> /etc/init/gpu-manager.conf
<pitti> jodh: that should match, no?
<jodh> pitti: should do.
<pitti> jodh: ok, let's check tomorrow then; yesterday pollinate was still in, so maybe something is just lagging
<jodh> pitti: cron is now running hourly - I just re-ran manually so hopefully it now reflects your expectation.
<pitti> jodh: oh, daily is certainly more than enough; I suppose it's not exactly cheap
<pitti> jodh: vivid main package admin/ubuntu-drivers-common requires systemd migration (sysv=False, upstart=True, systemd=False)
<pitti> jodh: hm, no, this should be systemd=True, and thus disappear entirely
<pitti> jodh: unless there is some problem with having upstart+systemd but not sysvinit?
<pitti> jodh: this only checks per-package, right? e. g. systemd is shipping /lib/systemd/system/hostname.service to shadow the one from the "hostname" package
<cjwatson> xnox: syncio> if you want; my care levels about wubi are pretty low now :)
<pitti> xnox: oh nice, that's our only remaining patch -- so we can sync again?
<pitti> xnox: I did a (local) merge two days ago to test somethign (was fairly trivial, so not much work lost really), but didn't talk to you yet
<jodh> pitti: can't debug right now I'm afraid. Here's the code: lp:~ubuntu-foundations-team/+junk/migration-to-systemd. You can run the shell script directly on people.c.c.
<pitti> jodh: ah, thanks
<brainwash> slangasek: I've asked you, because you are subscribed to the linked bug report :)
<brainwash> slangasek: and my last comment in the report did not get any response so far
<brainwash> bug 1080865
<ubottu> bug 1080865 in xfce4 (Ubuntu) "Debian instead of Ubuntu grub splash" [Low,Triaged] https://launchpad.net/bugs/1080865
<pitti> GunnarHj: should I build utopic langpacks now? or are there still some -docs to land?
<GunnarHj> pitti: No, ubuntu-docs was built (in utopic-proposed) a few days ago. All set.
<pitti> GunnarHj: ah right, https://launchpad.net/ubuntu/+source/ubuntu-docs/14.10.5; so off we go!
<pitti> GunnarHj: .. or not -- we didn't get an export yet :( https://translations.launchpad.net/ubuntu/utopic/+language-packs
<pitti> wgrant: ^ is something stuck, or just taking longer?
<pitti> probably taking longer because of the full export
<pitti> GunnarHj: ok, I'll try and build them on Monday then, but I won't have much time for testing
<GunnarHj> pitti: Ok.. I don't know how all that works. Thought the build was what's needed.
<pitti> GunnarHj: yes, but we should also have an up to date translation export
<GunnarHj> pitti: I'm slowly understanding the nature of the problem. ;)
<GunnarHj> pitti: It's LP which is slow, right?
<pitti> GunnarHj: a full export just takes quite a bit longer, yes
<cjwatson> It *looks* like it's still running (in that the log doesn't end in a crash of some kind), but it does seem to be taking unusually long
<cjwatson> Normally seems to take in the general vicinity of an hour, and it's been running for nearly four now
<shadeslayer> didrocks: can you retry bluedevil?
<shadeslayer> didrocks: in the transitions PPA
<didrocks> shadeslayer: sure, doing
<shadeslayer> though I messed up and the build dep version should have be bumped
<didrocks> shadeslayer: well, now we should have a publication cycle (so for next update ;))
 * cjwatson wonders if it counts as patch piloting when he just spent five hours cleaning up after inscrutable test failures caused by a sponsorship request
<stgraber> pitti: hmm, no, it should just work. Unless somebody regressed something recently.
<pitti> 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?
<pitti> stgraber: that's what I get; it might of course be an artifact of running under systemd
<pitti> stgraber: err *blush* sorry, my /home/.ecryptfs/martin/.Private is indeed nosuid
<stgraber> pitti: right, ecryptfs does that :)
<pitti> stgraber: yeah, quite plausible to have /home on nosuid, I figure
<pitti> so, sorry for the noise
<GunnarHj> pitti: Looks like it's there now. https://translations.launchpad.net/ubuntu/utopic/+language-packs
<pitti> GunnarHj: ah, good!
<cjwatson> Oh yes, it just took 4h39m for some reason.
<sladen> `.
<shadeslayer> question, what would be the value of uppderdir will be when using overlayfs such that any changes that are made are discarded
<bdmurray> mvo_: Could you have a look at bug 1399455?
<ubottu> bug 1399455 in ubuntu-release-upgrader (Ubuntu Vivid) "distribution upgrade from utopic uses DistUpgradeViewText" [High,Triaged] https://launchpad.net/bugs/1399455
<pitti> GunnarHj: I started the build, but that'll take a while, I can't test them today any more; I'll see to test/upload them on Monday then
<GunnarHj> pitti: Ok, thanks for letting me know. Have a nice weekend!
<slangasek> brainwash: I am?  I have no idea why I'm subscribed to such a bug report ;)  (bug #?)
<tjaalton> is it possible to get sbuild work with a non-local (ldap) user? looks like it needs the user in the chroot passwd/group
<brainwash> slangasek: bug 1080865
<ubottu> bug 1080865 in xfce4 (Ubuntu) "Debian instead of Ubuntu grub splash" [Low,Triaged] https://launchpad.net/bugs/1080865
<slangasek> brainwash: oh, indeed - yeah, that proposed solution seems fine, I was only involved in triaging that bug out of grub :-)
<brainwash> slangasek: can you apply the solution? if no, I'm not sure who I could bother with this
<slangasek> brainwash: it seems to me this should be done by the xubuntu devs?
<brainwash> slangasek: maybe. the package is not actually part of xubuntu
<brainwash> slangasek: it's just there to install the normal Xfce desktop environment, synced directly from debian
<brainwash> slangasek: easiest solution would be to ignore the debian-ization caused by desktop-base and don't add a ubuntu delta -> won't fix
<brainwash> it's only a recommended package after all, but it is pulled in by default unless you add --no-install-recommends
<mark999> so what happens if I accidentally upload a package to upload.ubuntu.com? will it just get deleted if the package isn't signed?
<infinity> brainwash: If xfce4 isn't pulled in by xubuntu (and it doesn't seem to be), I'd say it's a WontFix.  Rebranding every package we sync from Debian in case someone might install it and complain is probably a waste of time.
<mark999> dput uploaded a package to my private repo... and then decided to also ftp it to upload.ubuntu.com
<infinity> mark999: If it's unsigned, it just goes to /dev/null, yes.
<mark999> whew!
<mark999> its contents were somewhat sensitive, so I'm glad
<mark999> should the default dput config upload to ubuntu? I was expecting it to do nothing by default, and didn't look at /etc/dput.cf
<infinity> mark999: Is it a graphical frontend to your diary from puberty?  Cause man, I wouldn't want that out there.
<mark999> shhhhhh
<infinity> mark999: Default in Debian is to ftp-master and default in Ubuntu is to ubuntu, yes.  Feel free to remove the default (many do) to avoid shooting yourself in any feet, though.
<mark999> I will! should it _really_ be the default, though?
<infinity> mark999: I don't think you'll ever get a straight answer on that.
<mark999> heh
<infinity> mark999: People like me, who upload 99% of our uploads to Ubuntu or Debian tend to appreciate (and assume there should be) a default.
<infinity> mark999: In Ubuntu, one could make the argument that dput's used more often for PPAs than for the archive, and maybe we shouldn't have a default.  Dunno.
<infinity> mark999: The private repo argument likely doesn't factor at all, as almost no one runs such infrastructure, compared to people uploading to an official archive or ppa.lp.net
<mark999> well, if unsigned stuff gets deleted by default, no harm done.
<mark999> ah yea
<mark999> my company is doing something similar to google's goobuntu
<infinity> mark999: Well, unsigned stuff gets rejected (obviously), but no reject mail is sent, cause we don't have a way to validate who it came from.  So, effectively, it's like it never existed.  This is true for both launchpad and DAK.
<mark999> cool
<infinity> mark999: It does, however, sit around in a rejected/ directory for a while until a cron job or a human gets around to cleaning it out.  If it's super-sensitive to the point where you don't even want it sitting in a trash bin on a Canonical server, you could ask us nicely to go in and delete it without looking at it. :P
<infinity> mark999: Probably not worth the effort, though.  The people with access to that machine is a tiny list, and not the sort that go reading random rejected upload for funsies.
<infinity> mark999: (Again, true for an accidental upload to either Ubuntu or Debian... Different lists of people, different liabilities, but same general theory that none of them really care about reading it)
<brainwash> infinity: can you please mark the report as won't fix?
<mark999> infinity: thanks. not really *that* sensitive
<cjwatson> mark999: it can be nuked easily enough if you like, see your /query from me
<slangasek> brainwash: ah.  another option then would be to remove the package from Ubuntu altogether, if it's not the right experience on Ubuntu?
<brainwash> slangasek: but it's needed to install the normal Xfce desktop environment (not the Xubuntu session)
<infinity> slangasek: Ahh, indeed, xfce4 has no rdeps, blacklisting it would work too.
<infinity> brainwash: Is this a valuable thing to do?
<brainwash> some people prefer the normal Xfce experience, especially those who install ubuntu in the first place and then install Xfce on top of it
<brainwash> so they just run "sudo apt-get install xfce4"
<brainwash> and this pulls in desktop-base by default
<infinity> Well, I commented on and closed the bug, per your request. :P
<cjwatson> mark999: requested removal from sysadmin so it should happen soon; I can't wait around for it right now, but consider it done
<brainwash> infinity: thanks you :)
<infinity> I think if you actually expect Ubuntu users to intentionally install xfce4 (rather than accidentally), you might want to fix this.
<brainwash> thank
<mark999> I appreciate it!
<infinity> But I have no strong opinion on the matter.
<brainwash> infinity: the uproar is very small, so I guess that these users manage to remove the desktop-base package manually or prevent the installation in the first place
<brainwash> IF they don't like the debianization
<infinity> brainwash: Or that most people aren't installing "xfce4" :)
<brainwash> we get quite few reports from users which are running ubuntu + xfce4 (not xubuntu)
<brainwash> it's the obvious package choice if you've installed ubuntu first and then want to test a different DE like Xfce
<brainwash> or "gnome" for the gnome DE
<Unit193> Hello.  Is there a chance someone with super cow powers can sync gcalcli from experimental?  API changes fix, old version is unusable.
<Noskcaj> Unit193, requestsync ?
<Noskcaj> Can someone please check why banshee-community-extensions won't migrate?
<infinity> Noskcaj: It makes banshee-extension-lyrics uninstallable.
<infinity> Ahh.
<infinity> Noskcaj:  banshee : Breaks: banshee-extension-lyrics (< 2.4.0-3~) but 2.4.0-2ubuntu1 is to be installed
<infinity> Noskcaj: It needs a merge to the latest Debian version.
<Noskcaj> hyperair, Should banshee go back to dbus# 2 now the LTS has been released?
#ubuntu-devel 2014-12-06
<hyperair> Noskcaj: yeah it should
<hyperair> well, actually we might as well wait for upstream on this =\
<imastupidguest> does anyone know how to get ahold of bobweaver
<imastupidguest> ?
<imastupidguest> I'm not sure this is a very good place to ask this but it's the only channel I could think of. Is it standard practice to have some kind of version specification document in software development? If so, is there a name for this or could point me to some information on it?
<tumbleweed> use semver.org?
<imastupidguest> tumbleweed: Thanks, I look at it
<m4t> hey, i've got debian-keyring installed and i'm trying to verify an ubuntu dsc against /usr/share/keyrings/debian-keyring.gpg but i get signature not found
<m4t> is there another keyring package i should be looking at?
<brainwash> m4t: ubuntu-keyring?
<m4t> yeah i've got it
<brainwash> no clue then :)
<m4t> that's just like the archive keys i think
<m4t> debian-keyring has all the maintainers
<m4t> gpgv: Signature made Fri 10 Oct 2014 09:53:40 AM EDT using RSA key ID A744BE93
<cjwatson> m4t: we don't have a keyring package with all Ubuntu uploaders
<cjwatson> Launchpad verifies stuff a bit more dynamically than that on upload
<cjwatson> it makes more sense to just verify the trust path through Sources and Release to Release.gpg, really, which "apt-get source" should do for you
<teward> is it still early enough in the dev cycle that I can submit another merge debdiff for consideration in Vivid without being yelled at?
<cjwatson> yes
<m4t> thanks cjwatson
<teward> cjwatson: thanks, I wanted to make sure I didn't miss any announcements of any freezes or such.  Just gonna wait until the sponsors see it
<chris_> \join #ubuntu-meeting
<chris_> sorry about the wrong \
<Noskcaj> xnox, Do we need to keep our r34461.patch in abiword or can we use debian's one (slightly different, from fedora)
<Noskcaj> xnox, also, encfs can robably be synced, as arm64 is building in debian without our autoreconf delta
<brainwash> xnox: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/lightdm-gtk-greeter/vivid/view/head:/src/lightdm-gtk-greeter.c#L675
#ubuntu-devel 2015-11-30
<pitti> Good morning
<lpotter> hmmmm
<dholbach> good morning
<seb128> hey dholbach
<dholbach> hi seb128
<seb128> dholbach, congrats for the Cc election ;-)
<dholbach> thanks :)
<zequence> I've uploaded a package (ubuntustudio-meta), but it doesn't seem to be building. Where can I see errors for things like that?
<sladen> zequence: https://launchpad.net/ubuntu/+source/ubuntustudio-meta  there was an upload 48 hours ago; is there a newer one aswell?
<zequence> sladen: The source is there, but no binaries
<sladen> zequence: (if) it is the 0.143, buildlog will be here  https://launchpad.net/ubuntu/+source/ubuntustudio-meta/0.143/+build/8352681
<sladen> zequence: but it claims to have built; in which case perhaps you need an archive admin to look into it
<zequence> sladen: Right. Thanks!
<Mirv> porters: bos01-ppc64el-027 hanged on build (https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+build/8357535), will cancel and retry
<Mirv> hmm, I didn't notice it in the snippet but looks like it was ppc64el ICE actually that then didn't really fail (the build status remained building)? https://launchpadlibrarian.net/227978020/buildlog_ubuntu-xenial-ppc64el.qtscript-opensource-src_5.5.1%2Bdfsg-2build1_CANCELLING.txt.gz < doko
<doko> The bug is not reproducible, so it is likely a hardware or OS problem.
<doko> just retry
<Mirv> right, so it says
<cjwatson> zequence: it's in NEW, awaiting review
<cjwatson> or was
<cjwatson> zequence: appears to have been accepted not long before you asked about it
<ginggs> didrocks (or anyone else willing to sponsor): suitesparse ready for transition, please remove fop from -proposed, LP: #1518985
<ubottu> Launchpad bug 1518985 in suitesparse (Ubuntu) "Please merge suitesparse 1:4.4.5-2 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1518985
<didrocks> ginggs: good, removing fop then, one sec
<didrocks> ginggs: done, just wait for a publisher cycle to show up
<ginggs> didrocks: thanks, are you sponsoring my suitesparse merge as well?
<didrocks> ginggs: yeah, I'll have a look shortly
<ginggs> didrocks: cool, thanks again!
<didrocks> ginggs: thanks to *you*! :)
<pitti> cjwatson: is there a LP redirect that would get me the latest .dsc for a given package?
<lamont> pitti: you'd have to define "latest" (highest version? most recently uplaoded? published? etc) -- I too would be interested in the answer, but I suspect it's "no, you have to use the api"
<pitti> lamont: highest version, yes
<pitti> well, it's not too hard for me to figure out the version, but if there was some kind of /+latest.dsc redirect I wouldn't have to
<xnox> why is $ pull-debian-source -> not working at all?! =(
<xnox> pitti, don't think so, the thing that is shown as "latest" is any latest upload in the ui, rather than highest.
 * xnox looks at stuff.
<xnox> pitti, i think there was a magic url, into which one could plugin e.g. hello_1.2-3.dsc and it would download it, obviously one would have to know the full filename on wants to fetch.
<pitti> xnox: ok, thanks; nevermind, it's fine
<pitti> chdist --data-dir data/chdist grep-dctrl-sources xenial-amd64 -n -s Package,Version -F Testsuite autopkgtest|paste -sd '  \n' | sed 's/ [0-9]\+:/ /'
<pitti> that pretty much gives me what I want -- a list of all sources and their versions which have a test
<pitti> and with the version I can use https://launchpad.net/ubuntu/+archive/primary/+files/$src_$ver.dsc
<xnox> aha https://github.com/xnox/apt-mirror/blob/master/apt-mirror-librarian 'https://launchpad.net/ubuntu/+archive/primary/+files/' + debfile but yeah, that's to actually download any .dsc from librarian. (possibly pre publish into the apt archive, but not sure)
<xnox> yeap.
<xnox> that's the url i was thinking about.
<juliank> I can't reach launchpad.net (91.189.89.222)  - am I the only one?
<JanC> works for me
<juliank> Seems I have issues here
<JanC> wait, I'm on .223
<JanC> https://91.189.89.222/ gives me an error page from the reverse proxy
<JanC> (for obvious reasons)
<xnox> mardy, would the bug #1521226 be of interest to you?
<ubottu> bug 1521226 in libaccounts-glib (Ubuntu) "FTBFS on all arches in xenial" [High,Confirmed] https://launchpad.net/bugs/1521226
<xnox> =)
<mardy> xnox: vaguely ;-)
 * mardy tries to hide
<xnox> mardy, it fails on -Wall -Werror stuff with something rather, new glib, gibberish =)
<xnox> error: 'g_simple_async_result_propagate_error' is deprecated et.al.
<xnox> maybe disabling -werror would be enough for now. or maybe you are up for porting things to the "new" apis.
<mardy> xnox: ah, I can't tell you how much I love GLib deprecation policies :-)
<seb128> mardy, what an idea to build with Werror
<seb128> mardy, at least use -Wno-error=deprecated-declarations ;-)
<mardy> seb128: actually, you are right, better get rid of Werror in the first place
<mardy> seb128: and I'll add G_GNUC_BEGIN_IGNORE_DEPRECATIONS in the right places
<Mirv> xnox: if you don't mind, ignore your fcitx-qt5 sync's problems and let me upload a no-changes rebuild as part of the Qt 5.5 landing this week
<xnox> Mirv, i've synced it for very much different reasons. The sync is successful, the failures on power with respect to libxkbcommon are odd, given that libxkbcommon did not change since wily.
<xnox> Mirv, that new version has corrected symbols for extra architectures.
<Mirv> xnox: yes, I know the problem and that's why it wouldn't need now any changes after I land a synced Qt 5.5 in. it will need a rebuild however since it uses private symbols. the rebuild is already building at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+packages
<Mirv> xnox: it's nice it has the symbol updates since I had the older version manually patched before your upload in that PPA
<xnox> Mirv, ah cool, thanks for explaining.
<juliank> mvo: 1.1.3 is visible on Launchpad now
<mvo> juliank: lots go then
<juliank> The APT 1.1 Ubuntu party starts :)
<juliank> Thanks to pitti for already merging the goplay nmu
<pitti> juliank: it wasn't actually a real merge; I synced, then found that weird gcc error, then uploaded a workaround
<juliank> pitti: Right, thanks anyway :)
<juliank> ppc64el is a strange beast
<juliank> We have an even more crazy gcc workaround in apt: http://anonscm.debian.org/cgit/apt/apt.git/commit/?id=0300f0077af832e87beb290f26b13404cab81fd3
<pitti> hah
<mvo> juliank: apt and libept are synced now, weeeeeeee
<juliank> mvo: Great. python-apt can be synced  as well
<mvo> juliank: done, woah
<mvo> juliank: I'm so excited!
<Laney> apt is synced?
<Laney> nice!
<ricotz> better don't break the world ;P
<davmor2> just the rest of the universe ;)
<ogra_> who needs apt ... its a snappy future !
 * davmor2 snaps his fingers....computer is just sat there doing nothing. /me thinks ogra_ lies
<jamespage> cjwatson, should have your ubuntu-repository-cache MP landed shortly - the tests where failing due to changes in Juju and the testing framework for the charms
<shadeslayer> doko: ping
<shadeslayer> doko: Is packagekit being finally updated in Xenial?
<juliank> shadeslayer: PackageKit definitely needs to be merged soon for the APT transition at least.
<juliank> The first PackageKit to support APT 1.1 is 1.0.11
<dobey> pitti: ping. you around? need a manual ack on some autopkgtest issues
<zequence> cjwatson: Didn't realize the packages go through review at this stage in development. They usually get published so quickly.
<seb128> juliank, packagekit 1.0 was merged and got deleted since we need somebody to port aptdaemon for the api changes first, and somebody to update click to not use the packagekit plugin api since that was removed
<seb128> mvo started on the click work but he seems to busy to land it and nobody else knows click enough/has slots for it
<shadeslayer> juliank: I see
<shadeslayer> juliank: I need it for muon in the next Kubuntu release too
<smoser> hey. barry can you verify or suggest work around?  it seems that: http_proxy=http://.... pip install something
<smoser> on trusty will just not work
<smoser> http://paste.ubuntu.com/13581190/
<smoser> i think its related to https://github.com/shazow/urllib3/issues/422
<barry> smoser: does it work in xenial?
<smoser> yes. and vivid
<smoser> i'm just kind of surprised such a thing has lasted so long.
<barry> smoser: i can't remember what the state of backports/srus are for the pip stack :/
<barry> smoser: this seems familiar, but i don't remember the details
<smoser> tox uses pip from the system ?
<barry> smoser: i think it may depend on whether sitepackages=true in your tox.ini
<barry> well, maybe not
<barry> tox probably uses the system virtualenv, which uses the system pip
 * barry can't understand why https://www.google.com gives an ssl connection error, but only on one fully up-to-date xenial machine
<barry> all other https sites seem to work too
<sladen> SHA256?
<smoser> barry, ok. so it getting python-virtualenv from vivid (python-virtualenv_1.11.6+ds-1_all.deb) fixes it for me.
<smoser> i guess virtualenv has an embedded pip that it uses
<smoser> hm.. or  maybe not as i dont see it.
<juliank> mvo: What's the plan with PackageKit and APT 1.1? That needs 1.0.11 or a backport.  seb12 8 wrote "we need somebody to port aptdaemon for the api changes first, and somebody to update click to not use the packagekit plugin api since that was removed"
<infinity> mvo: I may be late to the party here, but what was wrong with parsing /etc/lsb-release?
<juliank> infinity: You're really late ;)
<infinity> juliank: Figured. :P
<infinity> juliank: I'm assuming (well, hoping) there was also discussion about formalizing CODENAME in the os-release spec, so we're not using a distro-specific extention forever?
<juliank> Will the auto-dep-wait stuff automatically be "un"waited? apt 1.1.3 has been built and is pending publications, and python-apt and libept are in dep-wait waiting for it
<infinity> juliank: Yeah, it'll unwait once the deps are available.  apt's still in NEW, unless someone accepted it when I wasn't looking.
<juliank> I at least don't find any mention of NEW on launchpad
<infinity> https://launchpad.net/ubuntu/+source/apt/1.1.3
<infinity> I do. :P
<juliank> Oh yeah, on the right side
<juliank> Annoyingly, once libept is built, it will also be NEW again
<juliank> s/ again//
<infinity> Not a big deal.
<infinity> I'll give libaptwhatever a quick once-over and get the ball rolling.
<infinity> Thanks for proper build-deps, BTW.
<infinity> Since I'm doing an out-of-archive bootstrap right now, it's much appreciated.
<juliank> Which proper build deps ?
<infinity> As in, you're dep-waiting on the new apt, rather than counting on upload timing to get it right.
<infinity> So I can't build in the wrong order by accident.
<juliank> Yeah
<juliank> infinity: I bootstrapped that in Debian experimental, so the deps were needed otherwise the packages would have built with unstable APT :)
<smoser> anyone else see this, or is it just lucky me
<smoser>  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1521302
<ubottu> Launchpad bug 1521302 in unity (Ubuntu) "gnome-terminal maximize than un-maximize behaves odd" [Undecided,New]
<stgraber> bdmurray: hmm, how comes that as a coredev working for Canonical I don't have access to crash reports on errors.ubuntu.com?
<stgraber> bdmurray: I'm being told I'm not in the right group when I go to https://errors.ubuntu.com/problem/9d8b1bc865eba0604b89ca1f7a24f0a1a0186290 and after I do SSO auth
<dobey> stgraber: are you in ~ubuntu-bug-control?
<stgraber> pretty sure I am, yes
<dobey> yeah, that's not it
<dobey> i can see that link, so it's some group i'm in, at least :)
<dobey> and looking at my teams list, i have no idea which one it'd be
<yofel> dobey, stgraber: AFAIK you need to be in https://launchpad.net/~error-tracker-access
<dobey> yofel: that doesn't exist
<yofel> dobey: huh? The team does exist, I vaguely remember there being an email that you should apply for that to get access when the tracker was initially set up
<dobey> yofel: well launchpad gives a 404, and i can't possibly be a member of it, and not be able to see it
<yofel> good point..
<Unit193> https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035321.html Heh.
<bdmurray> stgraber: it doesn't look like you are in error-tracker-access
<stgraber> bdmurray: can you add me? I sure used to have access to that stuff back in the days ;)
<bdmurray> stgraber: fixed now
<stgraber> thanks
<dobey> so confused
<stgraber> dobey: no idea why you have access though :)
<dobey> or why trying to view that team gives me a 404
<stgraber> it's a private team
<stgraber> so that part's normal
<stgraber> (and you're not a member of it, just checked)
<dobey> private private then i guess
<mvo> infinity: lsb-release> ogra_ is unhappy about that python dependency there. and yes, a upstream key would be ideal, but I failed to send a upstream bugreport :/ sorry for that
<cjwatson> jamespage: great, thanks
<cjwatson> zequence: new package names (source or binary) cause manual review no matter what stage of development we're at
<rxcomm> Can anyone point me to documentation on how to use the hashsum.mod module in grub2?
#ubuntu-devel 2015-12-01
<pitti> Good morning
<pitti> dobey: hey, how are you?
<pitti> dobey: autopkgtest issues> you mean overriding regressions? which package(s)?
<dholbach> good morning
<zequence> cjwatson: Ah, of course. Thanks.
<caribou> Is it possible to request a build in a PPA for another arch than i386 or amd64 ?
<seb128> caribou, you need a special ppa for that
<seb128> the standard virtualized ones only have the restricted set
<caribou> seb128: special in what sense ?
<Unit193> seb128: Not anymore, check the settings page of the PPA.
<caribou> Unit193: great, thanks!
<Unit193> Sure.
<seb128> Unit193, I was unsure, thanks for correcting what I said ;-)
<caribou> Unit193: well, ppc64-el is available but powerpc is not, I suppose that I need some specific access for that
<Unit193> seb128: Heh, it's pretty new, but I don't remember from when exactly.  Still have yet to try it personally, don't have a technical need so no point wasting resources.
<cjwatson> caribou: https://answers.launchpad.net/launchpad if you need anything other than amd64/i386/ppc64el
<caribou> cjwatson: thanks!
<happyaron> what's the mapping relationship from contrib (debian) to Ubuntu? is it universe or multiverse?
<sladen> happyaron: it depends!
<happyaron> well well
<sladen> happyaron: https://help.ubuntu.com/community/Repositories/Ubuntu#What_are_Repositories.3F
<sladen> happyaron: it's a 2x2 matrix.  Supported vs. Unsupported.  Libre vs. non-Libre
<happyaron> I know that description, and my package is not going to be supported (at least as of now)
<happyaron> it's in Debian contrib
<sladen> happyaron: what is the package?
<happyaron> sladen: zfs-linux
<happyaron> :)
<sladen> happyaron: sabdfl has been saying happy ZFS things in connection to Juju, so it might well become supported
<happyaron> sladen: well I'm the maintainer
<cjwatson> happyaron: multiverse by default
<cjwatson> but overridable
<happyaron> cjwatson: thanks, :)
<doko> cjwatson, I saw you building a qemu. did you address the libseccomp issue already?
<cjwatson> doko: in the PPA I built it in; not in the archive
<cjwatson> doko: http://paste.ubuntu.com/13596021/ (the libtool bit was just for the backport)
<seb128> pitti, do you know why we didn't get a xenial langpack yesterday? are those supposed to be weekly or bi-weekly?
<pitti> seb128: because I'm getting old and forgot to enable the cronjob; done now, and running manually
<seb128> pitti, danke (and you are not that old yet!)
<pitti> seb128: so what do I blame it on then?
<seb128> pitti, too much to do!
<seb128> or maybe not enough stollen :-)
<pitti> +1!
<seb128> doko, do you plan to merge gettext? seems like something that would be nice to get early in the cycle rather than late, in case it creates build issues and such
<doko> seb128, please take it, won't be this week
<seb128> doko, ok
<Mirv> ok Qt 5.5.1 is being published, hold on tight and if you see anything to be fixed to get it migrated in the upcoming 12 hours, feel free to fix
<Mirv> it will take several hours before the autopkgtests are in shape for studying if something needs to be done
<mterry> barry, btw, I uploaded a version of deja-dup that drops duplicity to a Suggests over the weekend
<mterry> barry, so that should be one package off the image (though we really should port it at some future point)
<pitti> mterry: does it have some session-installer integration? i. e. it installs duplicity when you want to use it?
<mterry> pitti, yeah using packagekit before you can set up the first backup or restore
<mterry> pitti, not ideal, but I didn't have time to port duplicity to py3 this cycle
<seb128> barry, mterry, pitti: I'm unsure how those changes help though, we are doing tricks to pull python2 on the system for users after install rather than in front, it's sort of cheating and doesn't make us use less python2, just be less honest about it
<kdub> how can I make a xenial schroot with mk-sbuild from wily?
<mterry> seb128, but it does make us use less python2 -- not every Ubuntu install is a deja-dup desktop
<pitti> yeah; the main difference is that people who don't use deja-dup won't have it installed, but it's still as supported as before
<seb128> we could also have unseeded deja-dup
<seb128> and tell users who want it to get it from software-center
<seb128> that would have the same result, just less weird
<mterry> seb128, that's another solution -- I'm fine with that -- less bugs :)  But I had assumed this was better
<mterry> seb128, it's not exactly the same result
<seb128> one advertize the feature a bit more
<mterry> seb128, this way we are giving users more of a nudge to make backups
<seb128> but it advertize a feature that is incomplete and prompt you to install things when you try to use it
<seb128> which is somewhat not a great user experience
<mterry> seb128, tell that to landscape :)
<mterry> seb128, which isn't a good excuse to do it on deja-dup granted
<seb128> mterry, we removed that icon in xenial ;-)
<mterry> seb128, oh hah!  I didn't know
<seb128> the landscape one
<seb128> is that to keep a balance in the force?
<seb128> remove one, add one :p
<mterry> seb128, I personally don't see what's wrong with a feature that needs to hit the network to be fully ready.  But if you folks don't like it, I'm 100% on board with dropping deja-dup from the default image
<seb128> mterry, I don't think it's wrong
<seb128> I just think the "no more python2" is a lie
<seb128> it's just "python2 on demand"
<seb128> but, oh well
<mterry> seb128, for some of our users  :)
<mterry> seb128, I agree I'd rather port it to python3
<mterry> seb128, but I don't really get work time for deja-dup anymore
<seb128> right
<seb128> it was not against you
<mterry> seb128, at worst, what we are buying is image space -- which didrocks has great language plans for :)
<seb128> oh well, I said what I hd to say on the topic
<seb128> haha
<seb128> right
<seb128> let's see if we actually manage to drop python2 from the iso
<mterry> seb128, if we don't..  we can always seed duplicity back in
<seb128> :-)
<didrocks> mterry: :p I'm still puzzled about the solution though, you will notice ;)
<didrocks> mterry: but I hope you will be as indulgent as I were reviewing your branch for this proposal :)
<mterry> didrocks, the language solution?
<didrocks> mterry: the duplicity dropped to suggests
<didrocks> mterry: what we discussed last week
<didrocks> (basically, I share seb128's point of view, but understand the constraints of course)
<mterry> didrocks, right -- again I'm sorta on your side, just not bothered as much.  The other two ways are porting duplicity or dropping deja-dup, both of which I'm happy to see happen, but can't do either
<didrocks> mterry: yeah, no ideal solution (apart from the portâ¦ whichâ¦ we already discussed and without upstream traction, will be really hard)
<mterry> didrocks, or...  4th way: get a python2-compatibility mode added to upstream python3.  ;)  brilliant!
<dobey> pitti: hey. how are you? i was confused about the excuses output, and my issue isn't with autopkgtests. so no need to do anything :)
<didrocks> mterry: ahah, of course, we can do it, make a version free for FLOSS software only, and make billions!
<didrocks> and then, using that money to port duplicity to py3
<pitti> dobey: heh, good :)
<rbasak> cpaelzer: looks like pitti beat you to the nis merge.
<rbasak> I thought we checked with pitti first?
<pitti> cpaelzer: oh, did you want to do it?
<rbasak> pitti: we discovered an upgrade path issue, BTW.
<pitti> MoM had it pinned on me
<pitti> but please feel free to grab it -- I have zero attachment to nis
<rbasak> pitti: previously the Ubuntu delta was accidentally shipping /etc/default/nis but not as a conffile.
<rbasak> pitti: that causes it to get clobbered.
<pitti> argh
<pitti> the nis packaging is hilariously bad
<pitti> every time I have to touch it I want to bite into my table
<pitti> it's outright evil
<rbasak> cpaelzer has a merge for me to review, but it's based on pre-Xenial.
<pitti> </rant>, sorry
<rbasak> pitti: and we drop the Upstart delta (which revealed the upgrade path issue)
<rbasak> pitti: so I might ignore your uploads and review and upload cpaelzer's over it, if that's OK with you?
<pitti> ah, you want to drop it because we don't care on the phone about nis, and other flavors are systemd?
<pitti> rbasak: sure, go ahead
<rbasak> Right. Thanks.
<pitti> I'm glad I stop being TIL :)
<rbasak> With this plan, IIRC, we need to fix the upgrade path in a delta in Xenial, but can drop the delta entirely in Xenial+1.
<rbasak> Then we can all stop caring about it.
<pitti> oh, good
<cpaelzer> rbasak: just coming here - yes we checked with pitte before starting
<barry> mterry: yes, thanks for that!  seb128 it does help because at least it will make our images smaller when we don't have to place two python stacks on them.  but yes, we should still be porting everything we can to python3
<rbasak> cpaelzer: we'll ignore pitti's merge, since we went further to drop the delta saving ourselves from future work.
<cpaelzer> pitti: it is totally satisfying that your table seems to look like mine due to nis packaging
 * pitti spits out some splinters
<rbasak> cpaelzer: "git diff logical/3.17-32ubuntu7 reconstruct/3.17-32ubuntu7" shows up a difference in ypbind-mt-1.20.1/src/Makefile.in that I'm not expecting. I'm looking into it.
<cpaelzer> rbasak: IIRC that file was the FTBFS from dannf
<rbasak> cpaelzer: dannf's change did make the Makefile.in delta unnecessary, but he didn't remove it.
<rbasak> cpaelzer: so I'd expect logical/3.17-32ubuntu7 to still include it
<rbasak> cpaelzer: because otherwise my check of "reconstruct should match logical except changelog and update-maintainer" fails.
<cpaelzer> rbasak: that is still the stuff we made wrong together - but you are right that needs to be corrected to match the way we want to handle it
<cpaelzer> I'm in hangout now - do you want me to upload a tree with that fixed somewhen the next few days?
<rbasak> cpaelzer: yeah fair enough. I thought this might have come from our week together.
<rbasak> cpaelzer: no, don't worry about it. It's not important for this merge. As long as we understand the process so we can avoid confusion next time, which I think we do.
<bdmurray> mvo: Do you still plan on backporting the fix for bug 1267059? Could it be an SRU?
<ubottu> bug 1267059 in unattended-upgrades (Ubuntu Trusty) ""Unattended-Upgrade::Remove-Unused-Dependencies" does not work " [High,Triaged] https://launchpad.net/bugs/1267059
<caribou> what's the best way to merge packages : bzr merge, grab-merge, other ?
<caribou> rbasak: I know you use git, got your blog post
<rbasak> caribou: I happily use grab-merge for very trivial merges that it doesn't break on.
<seb128> bdmurray, hey, could you get the glib wily SRU out of the queue? it fixes an important nautilus segfault and has been stucked in the queue since earlier novembre
<rbasak> The moment they get complex I fall back to git though.
<bdmurray> seb128: there are 2 in the queue - should I look at the latest one?
<caribou> rbasak: thanks
<seb128> bdmurray, I guess so, apparently the previous one had a changelog issue or something that you pointed out to Laney?
<bdmurray> seb128: oh right, no LaunchpadBugsFixed
<bdmurray> seb128: okay, I'll look at it shortly
<seb128> bdmurray, thanks
<Laney> I did ping when I reuploaded it
<seb128> Laney, yeah, but it's still waiting so I pinged again, there are some unhappy users with the nautilus segfaults
<Laney> I know, thanks for doing that
<Laney> just saying that I tried at the time :P
 * didrocks just looked at plymouth last merge and cries
<seb128> didrocks, :-(
<didrocks> yeah, wasn't merge in 3 years despite multiple upstream releases in both ubuntu and debian :p
<caribou> in the previous rsyslog pkg, we distributed the default rules in /etc/rsyslog.d/50-default.conf
<caribou> in the newest debian package, most of these are now in /etc/rsyslog.conf : should we keep the delta as it is or adapt upstream's rsyslog to our use ?
<seb128> bdmurray, thanks!
<bdmurray> seb128: no problem
<infinity> cjwatson: Did you do the last subversion merge because you actually wanted TIL, or was it a frustration thing blocking some other transition you were doing? :P
<TJ-> With Apache2 are there plans to add libapache2-mod-http2 (HTTP/2) for 16.04 (./configure needs "--enable-http2" )?
<jrwren> TJ-: I don't know, but I do know it is in upstream debian and its available via PPA
<jrwren> 2.4.17
<jrwren> TJ-: that wasn't added until 2.4.17 and wily shipped with a version less than 2.4.17
<TJ-> I'm on about for 16.04 XX, currently has the Debian 2.4.17 but HTTP/2 isn't built
<jrwren> TJ-: oh really? that is a bummer.
<TJ-> yeah, I'm concerned it doesn't slip through the net for the LTS release
<TJ-> But there could be a reason why it isn't enabled at this point, but there may be plans to enable it later in the cycle
<mdeslaur> TJ-, jrwren: AFAIK, it's still considered "experimental", not something we want to support for an LTS release
 * juliank thought the others above talked about an old kernel 2.4.17
<TJ-> mdeslaur: I'd have thought with the extended period over which 16.04 is going to be available, with sites moving to use HTTP/2, it's one of the things we would want
<mdeslaur> TJ-: yes, once it works properly
<mdeslaur> feel free to bug the server team about it
<TJ-> what's the definition of "works properly" for this?
<mdeslaur> once the module isn't marked as experimental and the options get formalized to that upgrades won't break users?
<mdeslaur> and once libhttp2 goes through the MIR process
<TJ-> so in all likelyhood HTTP/2 for apache2 will only get into 16.04 via backports then, assuming upstream take their time on the module?
<mdeslaur> no, I'd say it's something that would be appropriate to update and turn back on in an SRU once upstream declares it production ready
<mdeslaur> but, ultimately it's the server team's decision if they want to turn it on and support it as-is
<mdeslaur> TJ-: file a bug and ask about it in #ubuntu-server perhaps?
<TJ-> will do. I'm not particularly worried about it but was just developing an upgrade plan and realised it wasn't available in the archive, and as we already have the nginx HTTP/2 support it seeme strange it wasn't in XX
<cjwatson> infinity: It was one of the relatively easy ones on my list that didn't take too long; I originally ended up with TIL due to a Perl transition.  I have no problem with you stealing it though.
<infinity> cjwatson: I don't *want* to steal it, but it's currently FTBFS until a merge, so someone has to.  I suppose it'll be me. :P
<ben___> What is the proper way to handle dh_auto_clean on an unconfigured repo? http://paste.debian.net/340388/
<fshp> Hi. I will fix bug in unity-settings-daemon. But I'm confused. Associated with the media keys. Can anyone help with advice?
<Logan> cyphermox: are you planning on merging pytsk?
<Logan> ben___: maybe do something like http://paste.ubuntu.com/13608786/
#ubuntu-devel 2015-12-02
<cyphermox> Logan: I don't know anything special about pytsk, feel free to take it.
<dupingping> Hello everybody.
<dupingping> http://askubuntu.com/questions/704868/ubuntu-source-package-dependency-tree
<dupingping> Please help me.
<RAOF> dupingping: You're essentially asking about: https://wiki.debian.org/Teams/ReleaseTeam/Transitions
<dupingping> RAOF: yes, thank you.
<RAOF> So the answer is roughly âYes, there's some infrastructure for it, but it runs on Debian serversâ
<Logan> cyphermox: cool thanks!
<pitti> Godo morning
<goddard> when i plug in an xbox one controller my entire system crashes
<goddard> or rather locks up
<Mirv> 18h after publishing, this will take a while.. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src (plus the problems with some of the kde tests)
<pitti> Mirv: yeah, it's "this triggered > 1.000 tests" plus one of our clouds got broken again, so still some backlog
<Mirv> pitti: ok
<dholbach> good morning
<pitti> Mirv: if you are interested, you can follow the queues at http://autopkgtest.ubuntu.com/running.shtml
<Mirv> thanks, bookmarking!
<pitti> Mirv: I'll also adjust excuses.html to point to that for the "in progress" ones
<Mirv> the more inter-linking the better
<pitti> stgraber: hm, I put proxy info into /etc/environment, but "lxd-images import ubuntu --alias ubuntu" still can't talk to http://cloud-images.ubuntu.com apparenlty (same issue with images.linuxcontainers.org); is there some config option to make it use a proxy?
<pitti> stgraber: I also tried addinv these as "env" to /etc/init/lxd.conf (now the lxd process does have them), but no luck
<pitti> stgraber: ah, nevermind, it's apparently our proxy itself
<pitti> no, still the same issue now; wget works, lxd import says "Failed to retrieve the GPG key"
<zaytsev> doko: hi i don't know if you hear this often enough, but just to let you know that your toolchain work (gcc packages for ubuntu lts) is highly appreciated
<dupingping> hi everybody.
<dupingping> what is the NMU?
<dupingping> https://wiki.debian.org/Teams/ReleaseTeam/Transitions
<ginggs> i need help with autopkgtest please, julia passed once and not again http://autopkgtest.ubuntu.com/packages/j/julia/xenial/amd64/
<ginggs> it seems like it in running out of memory, do try using fewer and fewer cores until it works?
<zaytsev> dupingping: non maintainer upload
<dupingping> zaytsev: yes, thank you very much.
<pitti> Laney, apw: yes, precise VMs now suddenly only have main and universe, no restricted any more; so tests for restricted packages fail
<Laney> pitti: I was looking, yeah
<Laney> https://launchpadlibrarian.net/224624242/cloud-init_0.6.3-0ubuntu1.22_0.6.3-0ubuntu1.23.diff.gz seems very likely
<pitti> Laney: ah!
<pitti> Laney: we didn't get a new precise cloud image with that yet
<pitti> Laney: but I had to update the nova setup script for the fact that in all other releases restricted and multiverse now get enabled by default, adn stop adding them a second time
<pitti> Laney: so, we need to take that old precise image, dist-upgrade it (this will also speed up tests), and save it back
<Laney> and it looks like it's *adding* restricted/multiverse anyway
<pitti> Laney: do you want to do that for getting the exercise, or want me to?
<pitti> Laney: you can even use the existing create-nova-image-new-release script, it's doing exactly that
<pitti> Laney: warning, image-create is a bit brittle on lcy01 (surprise!), could take a retry or two
<Laney> pitti: I'm not sure which old image you mean
<pitti> ubuntu/ubuntu-precise-12.04-i386-server-20151117-disk1.img
<Laney> because this is before this cloud-init?
<pitti> oh wait, that's after that RU
<pitti> SRU
<Laney>  Published on 2015-11-12
<Laney> it looks like create-nova-image-new-release is overwriting sources.list anyway though?
 * Laney is missing something
<pitti> Laney: yes it is, but we only use that for xenial
<pitti> Laney: for the others we use the normal cloud images, and just a setup script to clean them up
<pitti> WTH
<Laney> that> c-n-i-n-r?
<pitti> Laney: ah, indeed! so the precise cloud image does not have these apt sources
<pitti> cloud-init 0.6.3-0ubuntu1.22
<ginggs> didrocks: hi, i think the last remaining items for suitesparse transition, LP: #1518985, are no-change rebuilds of gegl and lp-solve in main
<ubottu> Launchpad bug 1518985 in suitesparse (Ubuntu) "Please merge suitesparse 1:4.4.5-2 (main) from Debian unstable (main)" [Wishlist,Fix committed] https://launchpad.net/bugs/1518985
<didrocks> ginggs: let's see if the patch pilots will get it, otherwise, I'll handle it in my next shift :)
<seb128> I can have a look later
<seb128> I'm probably going to pilot this afternoon (or tomorrow)
<ginggs> didrocks, seb128: thanks!
<didrocks> doko: seems like your twisted sync creates some dist-upgrade issues
<cjwatson> didrocks: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806167
<ubottu> Debian bug 806167 in python-twisted "python-twisted fails to upgrade because of missing/incorrect replaces/breaks" [Grave,Open]
<didrocks> yeah, corresponding ubuntu one: bug #1521616
<ubottu> bug 1521616 in twisted (Ubuntu) "package python-twisted-core 15.5.0-1 failed to install/upgrade: trying to overwrite '/usr/share/man/man1/conchftp.1.gz', which is also in package python-twisted-conch 1:15.2.1-1ubuntu2" [High,Triaged] https://launchpad.net/bugs/1521616
<didrocks> Tue, 24 Nov 2015  starting to get hold
<didrocks> old*Ã¹
<cjwatson> didrocks: Well, it was closed in between there, but reopened yesterday
<didrocks> Replaces: python-twisted-conch (<< 15.4.0-1),
<didrocks> yeah, it should be at least 15.2 (if not before)
<cjwatson> didrocks: no, see the end of the Debian bug, it's a missing epoch
<didrocks> cjwatson: ah, indeed :)
<didrocks> doko: are you on this? I would prefer to not upload a fix to ubuntu only (but can do this and attach a patch to the bug report if you prefer)
<didrocks> thanks cjwatson
<caribou> Should rsyslog still bother about /dev/xconsole ?
<caribou> it has been disabled & put as an example in upstream debian newest package
<doko> didrocks, is this with -2 as well? -3 is still in NEW
<didrocks> doko: yeah. Ah good, the fix is in NEW, just waiting then :)
<caribou> When removing specific packages during a merge (i.e. packages that depends on Universe), should the related files (README.blah, etc) be removed from the package or just left there ?
<rbasak> caribou: it's fine to leave things in the package's source. For an Ubuntu delta, the smaller the delta the easier it is to manage, so I'd advocate leaving it there.
<rbasak> caribou: in the source that is.
<caribou> rbasak: thought so, I just wanted to confirm
<rbasak> Not sure about leaving things in binary packages since that could be confusing for users.
<caribou> rbasak: understood
<cpaelzer> rbasak: smb: I need some advise - look at LP Bug 1521289
<ubottu> Launchpad bug 1521289 in dpdk (Ubuntu) "DPDK with Xen" [Medium,Triaged] https://launchpad.net/bugs/1521289
<cpaelzer> rbasak: smb: XEN_PMD builds fine after my fix in amd64, but not in i386
<cpaelzer> rbasak: smb: I can't spend the effort to fix all othe XEN code in DPDK
<cpaelzer> rbasak: smb: so my question qhat would usually be done - dropping XEN_PMD or would it be ok to only build it in amd64
<cpaelzer> rbasak: smb: and by that create a functional difference betweeni386 and amd64?
<rbasak> I wonder if it is an upstream bug that stops XEN_PMD working on i386 altogether, or is it our combined library choice that makes that happen?
<cpaelzer> rbasak: upstream issue
<cpaelzer> rbasak: I fixed the "failing with combined library" two hours ago
<smb> cpaelzer, Without much time to read about this I would tend to not make things different
<rbasak> Good job!
<rbasak> I'd want upstream to fix the issue or make the build conditional automatically, rather than us.
<rbasak> If that's not possible or wouldn't be in time, then I'd be OK with carrying a delta to do it in packaging, but as always I don't like us to be carrying deltas so only if it's really important to Ubuntu.
<cpaelzer> rbasak: so you'd suggest another upstream patch that makes it conditional in dpdk upstream instead of our packaging
<rbasak> As we're primarily KVM-focused, I'd say it's not important enough.
<cpaelzer> rbasak: yeah that part of "not important" is why I don't want to fix the code for 32bit
<rbasak> cpaelzer: I suggest that if upstream are willing to carry that patch then we'll use it by default, so I'd be fine with that with my Ubuntu hat on. I'm not sure if upstream want that or just want it fixed though.
<rbasak> If upstream say that they want the bug fixed rather than worked around then that's perfectly reasonable. If I were upstream I'd probably say that, unless there's something fundamental about the feature that'll mean that it will never work or is obtuse on i386.
<cpaelzer> rbasak: lets see if there is a simple makefile fix to disable it on i386 in upstream dpdk and let them discuss it on that
<smb> cpaelzer, Would be helpful if you had any log about the failure with i386 _in_ the bug
<cpaelzer> smb: "cast from pointer to integer of different size" we all have seen that way too often
<cpaelzer> smb: I didn't want to fill the bug with only related info
<smb> cpaelzer, So more or less the whole thing not well written. There is another thing I was wondering and that is whether this is really still required with newer dpdk where we also do not need other kernel modules (at least the dom0 part)
<cpaelzer> smb: I already refused to include the kernel module for the dom0 part
<smb> Might be something to ask upstream
<cpaelzer> smb: this is about the XEN_PMD
<smb> Yeah, but I don't know for sure anything about that either. And I could not promise to have time to figure it out
<smb> cpaelzer, Most likely that part is only needed for Xen PV guests (other than dom0). Dom0 itself has access (usually) to pci device (that part I did check).
<smb> So there uio-pci-generic should in theory be an option
<sil2100> cyphermox: hey! Just reminding about https://code.launchpad.net/~sil2100/network-manager-applet/merge_1.0.6_debian/+merge/279012 once you have a free moment ;)
<sil2100> cyphermox: since I don't see robert_ancell around
<cyphermox> oh, of course, thanks!
<cyphermox> sil2100: approved. do you want to do the honours? ;)
<sil2100> cyphermox: \o/ Sure, thanks :)
 * cyphermox is totally not giving you TIL this way ;)
 * sil2100 prepares upload and hopes nothing explodes
<cyphermox> sil2100: are you merging the branch too or should I do it?
<sil2100> cyphermox: I'll merge it after I dput :)
<cyphermox> oh ok :)
<seb128> cyphermox, sil2100, current version is 1.0.8 and did you see that robert_ancell had branches on bug #1467267 ?
<ubottu> bug 1467267 in network-manager-pptp (Ubuntu) "Please sync to 1.0.6 from Debian (main)" [Wishlist,Triaged] https://launchpad.net/bugs/1467267
<sil2100> seb128: I don't see a network-manager-applet branch for 1.0.6 there
<cyphermox> mdeslaur: hey
<mdeslaur> hi cyphermox
<cyphermox> such a crowd here this morning...
<mdeslaur> yeah, oddly quiet
<kirkland> didrocks: hi
<didrocks> hey kirkland!
<kirkland> didrocks: howdy
<kirkland> didrocks: so I'm looking at this desktop icon problem
<didrocks> kirkland: good good, yourself? :)
<didrocks> yep, I guess
<kirkland> didrocks: fine thanks
<kirkland> didrocks: so I've cloned your source from git
<didrocks> did you see my answer on the Exec=
<kirkland> didrocks: I don't see your desktop file in there
<kirkland> didrocks: yes, just trying that now
<didrocks> kirkland: oh, I didn't push it, that was more a "we should try this"
<kirkland> didrocks: it's not ideal, as I was previously supporting any terminal that someone wanted to run
<kirkland> -Exec=env TERM=xterm-256color byobu
<kirkland> +Exec=gnome-terminal --app-id us.kirkland.Terminals.byobu -e byobu
<didrocks> kirkland: yeah, the gnome-terminal -> gnome-terminal-server changed impacted quite a bunch
<kirkland> didrocks: so that someone could easily use konsole, xterm, uxvt, or whatever
<kirkland> didrocks: so you have the same problem with weechat, then?
<didrocks> hum, larsu had a look at gnome-terminal-server when the issue started to happened
<didrocks> kirkland: yeah, I'm bound to gnome-terminal (it's a local desktop file)
<didrocks> maybe larsu would have an idea to have this more generic ^
<didrocks> kirkland: and yeah for g-t to not support backward compatibility :/
<didrocks> (the wrapper is Laney's work, thanks to him!)
<kirkland> didrocks: is this really a g-t problem?
<kirkland> didrocks: I thought someone said it might be in bamf
<didrocks> kirkland: yeah, they separate client and server
<didrocks> so basically all client goes to one server if you don't specify anything
<didrocks> so you only have one instance to match against
<didrocks> (what bamf is doingâ¦)
<kirkland> didrocks: hrm
<didrocks> if I'm correct, --app-id enables on the backend to have another g-t-s session
<didrocks> and so another process to match, which has a different name
<kirkland> didrocks: okay, so I can use anything in --app-id?
<kirkland> didrocks: I tried to match your format
<kirkland> didrocks: how does that link up with the right icon, then?
<kirkland> didrocks: and, is that going to work, if someone uses my package backported in a ppa to, say, trusty?
<didrocks> kirkland: that's a good question, we did this for backward compatibility (IIRC, it's not supported upstream anymore of something along that)
<didrocks> kirkland: I'm afraid the trusty version doesn't have g-t-s support
<didrocks> TBH, there is another way
<didrocks> like shipping a .desktop and a service-like file
<didrocks> (still bound to g-t)
<kirkland> didrocks: I'm game for trying that
<didrocks> but I would let the gnome guys to answer on this ^
<kirkland> didrocks: can you point me to another example?
<didrocks> I didn't look at this closely myself
<didrocks> kirkland: looking for some if I can find any (or old discussion)
<didrocks> but desrt and larsu would be way better ref than I
<didrocks> kirkland: I'm still unsure how you would be able to ship a solution that isn't term-specificâ¦
<kirkland> didrocks: right
<didrocks> (which isn't ideal)
<kirkland> didrocks: well, I'm willing to do that if I have to, I guess
<kirkland> didrocks: to be honest, trying to support konsole and other terminals is kind of a pain in the ass
<kirkland> didrocks: when 99% of people just use the default terminal
<didrocks> ah? you have other special cases on them?
<didrocks> yeahâ¦
<kirkland> didrocks: no, just weird bugs that come up
<didrocks> tmux bugs?
<didrocks> or konsole ones?
<kirkland> didrocks: people complaining about fonts or characters or colors that don't look good in some esoteric terminal application
<didrocks> oh yeah, I can see that, or people changing profilesâ¦ :)
<kirkland> didrocks: anyway, I had every intention on reverting that wmclass setting, as I clearly understood that wasn't the right fix
<didrocks> kirkland: argh, desrt's pastebin expiredâ¦
<kirkland> didrocks: but, I was trying to draw some attention to the real bug at the heart of this
<larsu> haha
<didrocks> kirkland: yeah, hence my "sorry" on the bug report, but that wasn't really liveable on xenial :)
<larsu> didrocks: what's the exact question?
<didrocks> larsu: g-t-s oh my g-t-s :p
<didrocks> larsu: kirkland wants to match byobu when byobu is running in his terminal
<kirkland> didrocks: and the fact that I think it's a major bug that ANY application's .desktop file can override gnome-terminal's icon
<didrocks> the interesting part is:
<larsu> Laney wrote a wrapper that makes the new g-t work like the old one (as seen fro mthe command line)
<didrocks> byobu can run multiple terminals
<didrocks> (like konsole, g-tâ¦)
<didrocks> so, I was going to point him to the --app-id to match correctly only byobu instances
<didrocks> (with Laney's wrapper)
<didrocks> is there anything better?
<kirkland> didrocks: I could see a malicious application putting a potentially offensive image in your launcher :-o
<larsu> make a profile, install a .desktop and .service file
<larsu> you know the drill, no?
<didrocks> kirkland: really agreed
<didrocks> larsu: yeah, is there any example for this?
<larsu> kirkland: it can do that without gnome-terminal as well, no?
<didrocks> last one for desrt's pastebin
<didrocks> it expired
<didrocks> was*
<larsu> oh ok, let me paste my irssi
<kirkland> larsu: didrocks: can you show me how to create a .service file?
<didrocks> kirkland: but yeah, agreed on a fundamental issue there :/
<larsu> kirkland: http://paste.ubuntu.com/13625283/
<larsu> I think you need to restart your session to make this work, but I'm unsure
<kirkland> larsu: so, where would I install that .service file, at the system level?
<kirkland> larsu: I see in your pastebin it's in your .local
<larsu> kirkland: /usr/share/dbus-1/services
<bdmurray> mvo: Can the fix for bug 1267059 be SRU'ed or does it need to be a backport?
<ubottu> bug 1267059 in unattended-upgrades (Ubuntu Trusty) ""Unattended-Upgrade::Remove-Unused-Dependencies" does not work " [High,Triaged] https://launchpad.net/bugs/1267059
<mvo> bdmurray: hello, sorry, I think you asked me before and I failed to reply :/ I thnk its fine to sru it, a backport is probably slightly less work as it should just build/work on 14.04
<bdmurray> mvo: looking at the git commit log I had a hard time sorting out which commit ids are important. Do you happen to know?
<mvo> bdmurray: I can probably find out which ones are the important ones
<mvo> bdmurray: I can look over them after dinner
<bdmurray> mvo: that'd be great
<kirkland> larsu: okay, I need a little help getting the .service working
<kirkland> larsu: I made the changes, built a package, installed, but not quite working
<kirkland> larsu: http://paste.ubuntu.com/13625646/ <--- that's what I have so far
<larsu> kirkland: what's the problem? The server process doesn't get started at all?
<larsu> please use reverse domain names ;)
<seb128> mardy, hey
<seb128> when trying to add a google account to uoa (unity7, xenial) in a guest session I get that warning
<seb128> (evolution-source-registry:15044): module-ubuntu-online-accounts-WARNING **: ubuntu_online_accounts_got_userinfo_cb: Failed to create ESource collection for AgAccount
<seb128> is that a known issue?
<kirkland> larsu: ugh, those are so ugly :-)
<larsu> heh
<kirkland> larsu: okay, so I have it working in 15.10/16.04, but byobu.desktop no longer works in 14.04
<kirkland> larsu: it's the Terminal=True that's the problem
<mardy> seb128: no, that's not a known issue, at least to me :-)
<juliank> I'm wondering: Is "debian/patches/gcc46-compatibility: don't break with old compilers and -DGNU_EFI_USE_MS_ABI." for gnu-efi still needed in xenial, or could that be synced now?
<juliank> If it cannot be dropped, what is still using gcc 4.6 and why?
<juliank> slangasek: You wrote the patch, what's your opinion?
<slangasek> juliank: it's carried because we have SRUed newer versions of gnu-efi to older releases to ensure that the shim binary we ship there is rebuildable in the target distribution (for policy reasons, even though we do a binary copy)
<slangasek> juliank: so e.g. precise has 3.0i, but precise-updates has 3.0u; and while we haven't SRUed any later version farther back than vivid yet, we did SRU 3.0.2 to vivid-updates on top of 3.0u in vivid release
<juliank> So, if I see that correctly, the patch will be needed until precise EOL in late 2017?
<juliank> (precise being the only distro with gcc older than 4.7)
<juliank> I could merge the patch upstream though, so we do not have to keep a delta and could have gnu-efi automatically synced
<juliank> (putting it into ubuntu.series, as we have no actual use for that in Debian)
<juliank> Oh hi mvo, do you have a progress update on the apt transition?
<mvo> juliank: hi, not yet unfortunately
<juliank> :(
<mvo> juliank: there is code that calculcated the expected entires from a Release file and uses that to try to give a smooth progress but â¦
<mvo> juliank: I will look tomorrow, its not worse than the old one I think
<mvo> but a bit annoying as I was really sure it would be (much) better :/
<juliank> mvo: I meant about the apt 1.1 transition in Ubuntu, not about the update progress issue :)
<mvo> anyway, tomorrow
<mvo> juliank: ohhh, sorry
<mvo> juliank: its looking really good I think, I need to double check, PK is missing obviously but the rest should be in
<juliank> OK
<dobey> hmm, is there some command i can run to list all the individuals whom have rights to upload a specific package?
<cjwatson> dobey: edit-acl in lp:ubuntu-archive-tools can answer this kind of question, except you have to expand teams yourself.  edit-acl -s <source package> query
<dobey> ah, and that's not packaged i guess. thanks
<slangasek> juliank: precise EOL is in early 2017, but yes
<slangasek> juliank: ftr I find per-distro patch files counterproductive; it just means that there's code in the Debian repo that not only hasn't been build-tested, it hasn't even been unpack-tested
<juliank> Well, the latter part could be checked by running patch --dry-run
<slangasek> juliank: but unless you make that check part of your testing process, having the package in sync with Debian isn't really beneficial to Ubuntu
<slangasek> also I find it distasteful that dpkg-source -x would have different behavior on different distros
<juliank> I can also apply it generally, there's no gcc 4.6 in Debian anymore, so it won't hurt there, and we'd all build the same code
<slangasek> that would be fine with me, of course
<juliank> I'll do that then after the current upload migrated to testing, together with disabling x32 support which does not build at all.
#ubuntu-devel 2015-12-03
<hallyn> if a package hasn't made it through -proposed on version $v, should the package be build with debuild -v$(v-1), or not?
<hallyn> stgraber: ^
<xnox> hallyn, yes, you should build with version from -release, when e.g. uploading into -proposed for devel.
<xnox> hallyn, or e.g. -v$updates when uploading into -v$proposed SRU.
<hallyn> xnox: thanks
<xnox> and so on.
<hallyn> finally got it to pass in adt-run so i'll assume i'm good.  finally
<cjwatson> I don't think -v actually matters very much in practice for that situation.
<cjwatson> It's a bit more important for SRUs because of how the tracking page works.
<xnox> ... once we have dgit, it will do -v things automatically
<cjwatson> I got dgit clone working against LP today
<xnox> \o/
<cjwatson> push will take quite a bit longer :)
<xnox> i am happy to be a test monkey
 * xnox will be happy with clone alone too, cause i have been abusing and finding all sorts of buts i've reported to ian over the years about it.
<cjwatson> dgit clone is relatively boring, it's just making the right LP API calls and having all the config variables hooked up properly
<Unit193> I presume you'll need access so it won't work like the MPs of the bzr branches?
<cjwatson> push involves a bunch of thought about policy enforcement in turnip
<xnox> cjwatson, well. still nice. given that bzr branch lp:ubuntu/foo doesn't work, I do pull-lp-source, git init, git add -A ., git commit -a -m 'init', then start working.....
<cjwatson> Unit193: rough plan is that official dgit-maintained repositories will live in git.launchpad.net/ubuntu/+source/blah, personal branches will live in git.launchpad.net/~user/ubuntu/+source/blah
<cjwatson> so anyone with an LP account can make branches and propose merges
<Unit193> Awesome.  AFAIK currently it's only for DDs, so I've been ignoring it and just going with gbp.
<xnox> well, dgit assumes that things will get stuck, or may get stuck in new-queue, get rejected, et.al. but all that history that dind't make it, is shared with all dgit users. So we can open all repos to all ~ubuntu-dev, even if they don't have upload rights. Cause then sponsoring will become: dgit pull, dgit push =) (from those that are at least ~ubuntu-dev)
<cjwatson> not ~ubuntu-dev, but linked with upload permissions
<cjwatson> which is not the same
<cjwatson> (plus perhaps some thought about new packages)
<Unit193> xnox: Yeah I only have a simple packageset, I need motu at some point (though I do like people reviewing my stuff, personally.)
<xnox> Unit193, i think this has been progressing to be changed. cause e.g. there is a new dgit machine now, which does DD-privileges-less queries to dak as to how things should operate.
<xnox> e.g. dgit clone, in debian, should be operation for non-DDs today.
<cjwatson> it's a bit better, but alioth's structure does make it fundamentally hard.
<xnox> not using alioth anymore as far as i understand, it's a separate machine now - or is it just vhost?!
<cjwatson> once we get it going, LP is in some ways a better fit.
<xnox> cool.
<xnox> we are not gonna share debian's dgit repos though, right ?! aka things in dgit.debian.org.
<xnox> well, i guess one is free to merge anything, cause it's dgit.
<cjwatson> haven't thought through all the details there.
<cjwatson> I was expecting to probably at least run an importer over everything accessible from every SPPH in LP.
<cjwatson> well, in the primary archive anyway.
<xnox> stand-alone will be good enough for now. cause we want our upload history and sequencing, and graft/force-merge debian if wanted or needed, or working on merge. But hey, this is git, it doesn't even need a merged history to merge things =)
<xnox> cause it's good at smashing things.
 * xnox aliases $ git smash, to git pull
<cjwatson> sure, but better to have good history from the start IMO
<cjwatson> it's on the list
<pitti> Good morning
<Bluefoxicy> man I am watching an update as it apt-get autoremove --purge on a machine with like 48 installed kernels.
<Bluefoxicy> found [47 kernels], added to grub
<Bluefoxicy> removing [kernel]
<Bluefoxicy> rebuilding [kernel].initrd
<Bluefoxicy> found [46 kernels], added to grub
<Bluefoxicy> removing [kernel]
<Bluefoxicy> rebuilding [kernel].initrd
<nikow> auto-remove is removing kernels for u?
<Bluefoxicy> yes
<nikow> I always doing it manualyâ¦
<nikow> I was*
<Bluefoxicy> more to the point, if you have multiple kernels installed, any updates will likely rebuild those kernels's initrds multiple times
<Bluefoxicy> I'm really getting tired of watching initrds rebuild 4 times for the same kernel in one update
<nikow> I can not have more than 3 kernels at the time.
<Bluefoxicy> "You have to upgrade 400 packages.  The download will take about 31 seconds on your connection."
<dholbach> good morning
<ginggs> morning pitti, what can be done about autopkgtest for julia ? it normally fails, but somehow managed to pass the tests once http://autopkgtest.ubuntu.com/packages/j/julia/xenial/amd64/ - it passes the tests in debian  https://ci.debian.net/packages/j/julia/unstable/amd64/
<pitti> ginggs: hm, "MemoryError" -- do you happen to know about this package?
<pitti> i. e. would it help to give it a larger VM with more than 1.5 GB RAM?
<ginggs> pitti, yeah i think so
<pitti> ginggs: I can also just lobotomize the one passed result and then it'll be "always failed"
<pitti> depending on how much you care
<ginggs> if you could give it more ram, that would be great
<pitti> ginggs: ok, updated the config and requested a re-run
<Bluefoxicy> and apparently 14.10 -> 15.04 gets you a broken, non-booting system
 * Bluefoxicy runs do-release-upgrade from the recovery console to get out of that mess.
<ginggs> pitti, thanks!
<pitti> ginggs: will take a bit though, the queues are moderately full (http://autopkgtest.ubuntu.com/running.shtml)
<ginggs> pitti: need moar rams :(
<pitti> --flavor autopkgtest
<pitti> hm, no, that didn't work yet
<pitti> should have been m1.large
<pitti> ginggs: meh, my bad -- forgot to git pull before restarting the workers
<pitti> done, and re-queued
<seb128> mardy, hey
<mardy> seb128: hi!
<seb128> mardy, do you have hints to debug uoa/e-d-s no working in xenial?
<seb128> if you add a google account the corresponding calendar/gmail are not available in evo
<seb128> also if I add a google account it's immediatly flagged as desactivated in u-c-c
<seb128> like I get a notify-osd about it and it has a red sign
<seb128> need to click to reactivate it
<mardy> seb128: not really, I'm not familiar with that code
<mardy> seb128: but to debug the notification: please do "echo 'LoggingLevel=2' > ~/.config/signond.conf", then kill signond, try again, and you should get some info in the syslog
<mardy> seb128: and to get even more info: kill signon-ui, and run this on a terminal: SSOUI_LOGGING_LEVEL=2 SSOUI_DAEMON_TIMEOUT=9999 signon-ui
<mardy> seb128: if then you could share these logs with me, it could help (make sure to replace any tokens with XXXXX)
<seb128> ok
<didrocks> slangasek: in http://launchpadlibrarian.net/185122127/plymouth_0.9.0-0ubuntu3_0.9.0-0ubuntu4.diff.gz, you say that you replaced fonts-dejavu-core by ttf-ubuntu-font-family to avoid depending on both fonts in the changelog. However, the diff (and current packages) shows that we still depend on both, was it a typo and a missing | ?
<pitti> more like forgot to actually drop the "fonts-dejavu-core" line?
<didrocks> pitti: seems so, just want a confirmation (doing that on the merge for now)
<ginggs> pitti: \o/ julia passed! - is this config change permanent now?
<pitti> ginggs: yes, it is
<pitti> --flavor m1.large
<pitti> ginggs: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=d1aeff45 FYI
<ginggs> pitti: nice, thanks
<Laney> seb128: you doing that signon stuff?
 * Laney can reproduce on an iso
<seb128> Laney, yes, talking to mardy in a query
<Laney> ok
 * Laney keeps the logs in case
<seb128> but it looks like an e-d-s issue, going to report to them
<seb128> my log has " ubuntu_online_accounts_got_userinfo_cb: Failed to create ESource collection for AgAccount "
<seb128> do you have that as well?
<Laney> hang on
<Laney> need to get it out of the vm
<seb128> it's in syslog after doing the echo that mardy recommended before
<Laney> yes I have that there
<seb128> good
<larsu> kirkland: why do you need that? gnome-terminal -e should do what you want, no?
<zaytsev> laney: since you happened to help me out with my last trusty bugfix, maybe you could advise me on the new situation? so i have software that needs scons to build. i have discovered, however, that scons in trusty is broken with python 2.7 in a way that all sconf checks simply fail
<zaytsev> laney: so i found the patch upstream that fixes this problem. it was included in scons 2.3.2
<zaytsev> laney: trusty only ships scons 2.3.0 however
<Laney> seb128: is that also why we have to re-confirm after adding it? or a separate issue?
<seb128> separate issue
<Laney> zaytsev: If the patch applies cleanly and fixes the problem then we could include it in a stable update
<Laney> zaytsev: check that and then file a bug with the patch attached, subscribe "ubuntu-sponsors"
<seb128> Laney, the re-confirm is not new and a sucking UI, apps need to allow access the first time they want to use the online account, and since e-d-s has no UI they decided to make you go through the settings to activate it
<Laney> oh
<zaytsev> laney: right, so that's the question: 2.3.2 was never shipped in ubuntu. willy ships 2.3.6 that has this bugfix and more, and xenial 2.4.1 which is the newer available with even more fixes. now the question is whether i should backport the patch as you suggest, or one can simply take the packae from the next version into backports?
<zaytsev> laney: if the policy is such that backporting an isolated patch is preferred, then i'll go down this way. just need some direction.
<Laney> backports isn't meant to sidestep fixing bugs in the release
<Laney> fixing it a SRU would be preferred
<zaytsev> laney: okay then i will invest some time in preparing a clean backport and makign the bug as last time, i'll try to follow the guidelines. many thanks for your help! it's very much appreciated
<Laney> thanks zaytsev!
<Laney> lemme know if you need any more help
<Saviq> didrocks, hey, think you could have a look at https://code.launchpad.net/~saviq/unity8/in-train-pot-update/+merge/279100 please?
<didrocks> Saviq: I guess that ./po/update-unity-pot is the scrope updating the pot file :)
<didrocks> Saviq: so yeah, +1, even if I think that this feature should be in the train itself
<Saviq> didrocks, bug #1359667 :)
<ubottu> bug 1359667 in CI Train [cu2d] "There should be a hook mechanism available" [Undecided,Incomplete] https://launchpad.net/bugs/1359667
<didrocks> Saviq: hum, I would maybe rather override_dh_auto_clean
<Saviq> didrocks, ah, right
 * Saviq fixes
<didrocks> Saviq: commented with this
<Laney> didrocks: Saviq: is that going to work?
<Laney> does train run debian/rules clean itself?
<Saviq> Laney, it does
<didrocks> Saviq: as in my comment, I would still readd a dh_auto_clean call then
 * didrocks goes for a run, bbl
<Saviq> didrocks, yeah, fixing
<Saviq> but ssh broke in xenial, so delay
<didrocks> Saviq: argh :p once done, just consider it a +1 for me
<Laney> in that case why can't it run some random script for you instead of doing weird gymastics in debian/rules?
<didrocks> Laney: see the referenced bug report above ^
<didrocks> Laney: and my suggestion on that very channel as well :)
<Laney> which part of it?
<didrocks> https://launchpad.net/bugs/1359667
<ubottu> Launchpad bug 1359667 in CI Train [cu2d] "There should be a hook mechanism available" [Undecided,Incomplete]
<didrocks> (so yeah, we all agree here, but seems like CI Train maintainer doesn't agree)
<Laney> going to comment
<didrocks> please do, I've already done it once on IRC IIRC
<Laney> done
<Saviq> Mirv, hey, how's Qt 5.5 migration going?
<Mirv> Saviq: hey, it's looking pretty good - http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src - I don't see currently anything that'd be broken "for real", and I was thinking if I could be at a point of poking pitti of glancing over it. the regressing non-overridden things to seem to have either passed occasionally after the landing or failing already be
<Mirv> fore the landing.
<Saviq> Mirv, ack, nice :)
<pitti> Mirv: look at the bottom, a few failures are already overridden; but there are indeed a few new ones, like marble
<Mirv> pitti: yeah, I checked those. marble has had a success yesterday on at least amd64 and i386 so seems flaky.
<pitti> yeah, but it used to be very stable until yesterday
<Mirv> others remaining are kdelibs4support amd64/ppc64el and kwayland ppc64el but those seem have been failing before
<Mirv> pitti: right, it might the marble is the most deserving of attention, I'll try if I can figure anything out.
<cjwatson> pitti: what normally creates things like /srv/ddebs.ubuntu.com/www/dists/xenial-updates/main/binary-s390x/Packages*?  I see that its siblings for other arches exist, empty, which I think is all that's required to shut up the cronspam
<cjwatson> pitti: But it seems odd to create them by hand
<mardy> Laney: hi! I've got someone complaining that the cdimage link from https://wiki.ubuntu.com/Unity8DesktopIso is no longer working
<Laney> mardy: delete that wiki page, it's gone
<mardy> Laney: do I understand correctly, that since wily+unit8 offers the same as that?
<Laney> I think you're meant to use the -desktop-session packages
<pitti> cjwatson: ah, that's a bit of a hack; as we don't have -updates during the devel series I usually hack the code temporarily to make it think that xenial-updates changed, and generate that
<cjwatson> pitti: ok, if you're familiar with that could you do it for xenial-updates/s390x?
<pitti> yep, doing
<cjwatson> thanks
<pitti> cjwatson: http://paste.ubuntu.com/13643501/ shoudl do, I'll check after the next run
<cjwatson> pitti: cool, thanks
<pitti> cjwatson: hm, but actually, it complains about the *input* archive, not the output archive
<pitti> (it's correct to create empty xenial-updates ddeb indexes, though
<pitti> http://ports.ubuntu.com/dists/xenial-updates/main/binary-s390x/Packages.gz exists, though
<cjwatson> pitti: no, it must be complaining about the output archive because there's no suffix on the Packages files it lists
<cjwatson> pitti: confusing warning message though!
<cjwatson> pitti: it's from the second archive_map() call
<pitti> oh right, it's building an archive map for the ddebs archive, with mirror pointing to itself
<pitti> so, this run indeed should solve that
<pitti> cjwatson: ok: http://ddebs.ubuntu.com/dists/xenial-updates/main/binary-s390x/
<cjwatson> thanks
<tjaalton> anyone else having issues with a sid schroot unable to run 'apt update' since a few days? it just gets stuck here, other schroots work fine..
<Laney> there was a bug in apt 1.1, you need to manually upgrade it
<tjaalton> ah
<Laney> I suppose a re-create will work too
<tsimonq2> I had that same issue with the apt PPA in Xenial
<tsimonq2> it's easy to fix
<tjaalton> yeah, upgrading apt fixed it
<tjaalton> thanks
<cpaelzer_> It might just be outdated - but I found something about packaging .debs and ldconfig here https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-ldconfig
<cpaelzer_> I wonder why I canÃt find any lib actually doing that ldconfig in maitainerscripts - is that these days automatically covered?
<cpaelzer_> or do I just check bad examples when picking libs to see what they are doing?
<cjwatson> $ grep ldconfig /var/lib/dpkg/info/libpipeline1\:amd64.postinst
<cjwatson>         ldconfig
<cjwatson> but as of relatively recently this is normally handled by triggers instead
<cjwatson> which has (almost) the same effect as what policy says but not quite the same implementation
<cjwatson> anyway, you should just let dh_makeshlibs handle this for you
<cjwatson> policy should probably be updated for the ldconfig triggers work
<cpaelzer_> cjwatson: thanks - I see that some even have it twice automatically added by dh_makeshlibs
<cjwatson> there is no doubt the odd bug
<pitti> Mirv: I'll hint kdelibs4support, that's been broken before
<pitti> Mirv: kwin and marble do seem to relate to the new Qt, though
<Mirv> pitti: I've been staring at marble. it's been failing (but not always) with 5.4 too in parsing the same Tour.kml Google maps file that fails with 5.5. the other 25 .kml files don't have issues  with either 5.4 or 5.5.
<Mirv> pitti: kwin amd64 last 4 failing ones are 3 times 5.4.2 and 1 times 5.5.1
<Mirv> (Qt version, kwin 5.4.3 always)
<Mirv> pitti: ah I'm probably reading it wrong, just checking the first libqt5core5a installation mentioned
<Mirv> I've adt-run done on marble but I'm none wise since I don't find how to output the whole parsed xml to find where there's a difference. but I guess the kwin might be the real deal.
<Mirv> (sorry, yes marble is a real problem too)
<pitti> Mirv: perhaps you can run it under gdb and break at the assertion?
<pitti> (not sure how these look like)
<kirkland> didrocks: http://bazaar.launchpad.net/~kirkland/byobu/trunk/revision/2450
<kirkland> didrocks: in case that's useful to you with weechat
<kirkland> didrocks: note the postinst, which links the right .desktop file
<didrocks> kirkland: oh nice, so, you confirm that you forced to use a fqdn? (that was the issue yesterday?)
<kirkland> didrocks: I had to work through a few things
<kirkland> didrocks: it did seem like I needed to have a much more complex service name to work
<kirkland> didrocks: I also had to remove the Terminal=true line
<didrocks> yeah, I'm surprised about that one
<didrocks> (the Terminal= to remove)
<Mirv> pitti: ok, managed to add some qDebug finally (gdb break:ing didn't really work out). there's a rounding error of the read xml value with Qt 5.5.1, "4.2" becomes "4.2000000000000002"
<pitti> Mirv: eek, does that test compare floats for equality? or is that a string comparison and it's formatted wrongly?
<Mirv> pitti: no it compares XML data in eg https://github.com/KDE/marble/blob/master/tests/data/Tour.kml after having gone through some parsing in marble https://github.com/KDE/marble/blob/master/tests/TestGeoDataWriter.cpp
<Mirv> pitti: the kwin issue is probably this without xrandr issue https://github.com/KDE/kwin/commit/eda4f6103707bc425dec884c3fe4dac1077b21a7 - probably could cherry-pick (kwin, as the Qt upstream commit not approved yet)
<pitti> Mirv: ah, thanks for the research there!
<Mirv> pitti: mgraesslin confirms that the kwin issue is probably exactly that
<Mirv> pitti: ah, https://github.com/KDE/marble/commit/05df36b674db4b150835ceecc53021d61b51f27e - marble upstream has fixed it, although I'm not sure if it's a fix or workaround. but I could include that + the kwin fix.
<Mirv> states it's a bad comparison of double values
<pitti> Mirv: that looks more like a workaround
<pitti> Mirv: well, "4" can be represented exactly in a float, 4.2 can't; but that just hides the fact of the bad equality comparison
<pitti> Mirv: but anyway, this is way beyond what you should be doing there -- going with the upstream fix sounds fine
<Mirv> pitti: ok, no-one told me this'd be beyond in any way but at least it has been informative :) I can upload both fixes.
<pitti> Mirv: well, I meant "should" in the "can reasonably be expected from you position" side, not "wouldn't be welcome" of course
<pitti> Mirv: great, so these two should turn green, the overrides should take care of others, then the large swath should promote
<smb> doko, Not sure you saw already but that qemu merge does not seem to be really happy on many (if not all) the other arches
<gQuigs> is there anything else I should be doing for SRU https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1505328 ?
<ubottu> Launchpad bug 1505328 in cups (Ubuntu Trusty) "Cups SSL is vulernable to POODLE" [High,Triaged]
<rbasak> tdaitx, slangasek: how's that squid3 merge going?
<tdaitx> rbasak, sorry, no updates so far, I was back from vacation yesterday. Anyway I do plan to get started at most on Monday
<mvo> bdmurray: hi, sorry that it took forever. I followed up with patch  for bug #1267059
<ubottu> bug 1267059 in unattended-upgrades (Ubuntu Trusty) ""Unattended-Upgrade::Remove-Unused-Dependencies" does not work " [High,Triaged] https://launchpad.net/bugs/1267059
<mvo> bdmurray: I also asked for a unattended-upgrades backport
<bdmurray> mvo: Thanks! I'll have a look at the SRU today then.
<mvo> bdmurray: cool, extra testing would be great, I poked at it in various way and I thnk its good but the diff was not trivial to extract unfortunately
<bdmurray> mvo: I think there are plenty of people interested in testing it.
<chiluk> mterry can I get an upload for coreutils trusty again https://launchpad.net/bugs/1432871
<ubottu> Launchpad bug 1432871 in coreutils (Ubuntu Trusty) "`df` shows bind mounts instead of real mounts." [Low,Fix committed]
<mterry> chiluk, yes... but not today from me anyway.  could do tomorrow
<chiluk> ok I'll check elsewhere.
<chiluk> cyphermox: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871
<slangasek> didrocks: plymouth> your analysis seems plausible, it's likely to have been a typo - though I think I meant to drop the fonts-dejavu-core dependency entirely instead of |
<cyphermox> chiluk: yeah, it's just a broken test
<chiluk> cyphermox: kind of..
<cyphermox> not just kind of
<cyphermox> it expects the local fs that you run df on to not be nfs, which can't always be true
<chiluk> our fix really should be to update the testcase.
<cyphermox> the assumption is bad
<chiluk> however... "df --local -t nfs --total '.'  "
<chiluk> should never succeed.
<cyphermox> why not?
<chiluk> local and -t nfs should be mutually exclusive
<cyphermox> heh
<chiluk> and it does when run anywhere but on our buildds.
<chiluk> however, upstream df still behaves this way.
<cyphermox> well then we've found a bug in df or in the kernel
<chiluk> right there is still an upstream bug in df.
<chiluk> but it's not worth the effort to resolve..
<cyphermox> did you report it?
<chiluk> I'm just trying to give full disclosure here.
<cyphermox> oh, I'm all fine with your fix, as long as we report the fact that --local fails to exclude nfs.
<chiluk> basically part of the issue is that upstream  has determined that nfs can be a local filesystem on some OS's..
<cyphermox> ok
<chiluk> and that was the reason they changed the behavior of the testcase.
<chiluk> because they also had to change the behavior of df.
<cyphermox> fair enough
<chiluk> it's definitely better than just skipping the testcases altogether... like was being done before *(because df was failing inside the buildds).
<chiluk> it's definitely an improvement.
<cyphermox> chiluk: uploaded.
<chiluk> thanks cyphermox.. I'll start bribing arges... I think I have some hardware he wants.
<chiluk> arges https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871
<ubottu> Launchpad bug 1432871 in coreutils (Ubuntu Trusty) "`df` shows bind mounts instead of real mounts." [Low,Fix committed]
<Odd_Bloke> doko: barry_: I've just discovered that https://bugs.launchpad.net/ubuntu/+source/python-virtualenv/+bug/1500768 is present in the vendored version of urllib3 in python-virtualenv, and hasn't been fixed.
<ubottu> Launchpad bug 1500768 in python-virtualenv (Ubuntu Trusty) "python3.4.3 SRU break requests" [Undecided,New]
<Odd_Bloke> I've added it as an 'Also affects', but after I'd filed https://bugs.launchpad.net/ubuntu/+source/python-virtualenv/+bug/1522500.
<ubottu> Launchpad bug 1522500 in python-virtualenv (Ubuntu) "pip in Python 3.4 virtualenvs cannot install using a proxy " [Undecided,New]
<Odd_Bloke> Shall I mark the latter as a duplicate of the former?
<barry_> Odd_Bloke: yes, i think they're the same bug.  doko uploaded 1.7.1-1ubutu4 to trusty-updates. does that not fix the problem?
<xnox> doko, smoser: can we simply move onto 2.5 rc? it's meant to go final on the 12th, and i would like new qemu due to things it will support.
<xnox> and i guess we will target 2.5 or better in xenial.
<doko> xnox, meh, I don't care, I only did the merge because I messed up the package
<xnox> doko, ack. and what about the FTBFS?
<cjwatson> doko: that FTBFS is just what I warned about before - control-in needs to be in sync with configure in terms of which arches support seccomp
<cjwatson> why not revert all the seccomp-related changes back to just amd64/i386, on the grounds that the other path is clearly entirely untested?
<doko> cjwatson, yes, have it fixed locally, will upload
 * xnox was also going to mock with that package and make an -s390 package
<Odd_Bloke> barry: So the problem is (I think) that virtualenv installs pip from /usr/share/python-virtualenv/pip-1.5debian1-py2.py3-none-any.whl which doesn't have the patch.
<Odd_Bloke> barry: Yeah, and that has a _vendor/requests/packages/urllib3 in it.
<hallyn> stgraber: infinity: gah!  bad push.  can you intercept a qemu for xenial push with ppa1 in the name?
<hallyn> (otoh it might fix the xenial build :)  but shouldn't be there as is)
 * hallyn goes to brew a pot of coffee.  this is turning out to be a week of ondays
<stgraber> xenial uploads don't get held in the queue so there's not much we can do about it
<stgraber> you can prevent it from moving out of proposed though, not that this would necessarily help, you'll still need to upload one with a non-ppa version that's higher than the one you just uploaded
<hallyn> prevent it from moving out of proposed - how?
<hallyn> yeah i'l upload a new version as soon as i get it to pass in ppa. it's nto a bad package, just bad changelog
<stgraber> there's a bug tag you can use IIRC, trying to remember what it is
<hallyn> oh nm i'll see if it passes :)  thx
<stgraber> hallyn: you can file a bug against the source package and tag it with block-proposed
<hallyn> ok thx
<hallyn> and just drop that tag after i push the newer version?
<stgraber> yeah or close that bug
<hallyn> thx done
<ben___> is there an easy way to mount /sys within a pbuilder chroot?
<robert_ancell> bdmurray, can you get lightdm 1.14.4 out of vivid unapproved queue? It fixes bug 1516831 which was in the previous SRU
<ubottu> bug 1516831 in lightdm (Ubuntu Wily) "XDMCP Request packet with no addresses crashes LightDM" [Critical,Fix committed] https://launchpad.net/bugs/1516831
<bdmurray> robert_ancell: yeah, I was gonna ask about that
<knome> slangasek, hello, another ping about the xubuntu core -related merges; what's up? :)
<tdaitx> doko, I would like to get your opinion on https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1518741
<ubottu> Launchpad bug 1518741 in openjdk-7 (Ubuntu) "A pkg-config file is need for OpenJDK distributions" [Undecided,New]
<tmartins> hey guys, I'm experimenting Xenial already, just received libvirt-1.2.21 and it doesn't depends on libxen-4.5 anymore... Is this expected?
<tmartins> I'm planning to use Xenial for my Xen project
<xnox> arges, ^
<xnox> barry, is this the right way to submit fixes? https://code.launchpad.net/~xnox/click/lp1522608/+merge/279521
<barry> xnox: i guess that's a cjwatson question?  i don't touch click
<xnox> well, i can in the end of the day, just do "ubuntu" community upload.
<cjwatson> xnox: lp:click/devel as the merge target please
<cjwatson> (and therefore rebranch from that too)
<cjwatson> xnox: but you probably want mvo to actually shepherd it through; there are a few other worthwhile improvements in lp:click/devel that I'd like to be part of the next landing
<xnox> cjwatson, should Vcs-Bzr nad Vcs-Browser point to the lp:click/devel then? cause that's where i looked.... or are those fields used for other magic elsewhere?!
<cjwatson> xnox: very probably yes
<xnox> currently points to stale https://code.launchpad.net/~ubuntu-managed-branches/click/click
<cjwatson> it's not exactly stale, it just only updates on each landing
<cjwatson> oh maybe it is
<cjwatson> right, +branch/click is different
<cjwatson> will fix when bored, or you can include it in your MP
<arges> tmartins: yes
<arges> libvirt 1.2.21 and libxen-4.6 are still in xenial-proposed
<tmartins> Oh, cool! Thanks arges!
<tmartins> arges, I have enabled proposed but, I received new libvirt-1.2.12 but no libxen-4.6
<tmartins> will try again tomorrow
<tmartins> sorry, new libvirt 1.2.21
<tmartins> never mind, I have libxen-4.6  lol
<tmartins> sorry about the buzz
<tmartins> BTW, Xen adopted 6 months release cycle but, not close to Ubuntu cycle...   :-/
<tmartins> Xen 4.7 will be ready two months after Xenial...
#ubuntu-devel 2015-12-04
<xnox> .... one must not run -proposed on development release....
 * xnox is not ssure where tmartins went.
<ThiagoCMC> xnox, why not enable proposed on development branch ? Everything is fine here, it was my confusion...   =)
<xnox> ThiagoCMC, humans should not run -proposed on the devel release.
<xnox> ThiagoCMC, it's not meant for end user consumption, and only for automated systems. it has all abi transitions in progress, and shall be used by buildds only, and automated testing. once things are good, things migrate to release pocket. Hence for "rolling" release one should run devel release only, without -proposed enabled. -proposed has like 700 broken packages at the moment. Whereas devel without -proposed should be entirely installable.
<xnox> and we remove things from -proposed when we realise we uploaded really broken things, that fail testing.
<xnox> (e.g. autopackage tests, and britney transitions, arch skew etc.)
<ThiagoCMC> got it
<ThiagoCMC> thank you!
<xnox> ThiagoCMC, in practice, without -proposed one gets shiny stuff, daily, with a small delay, and never broken things. Or so is the effort =)
<ThiagoCMC> sounds cool
<goddard> why doesn't the resolution get set on tty and lightdm when inside unity?
<goddard> i have a 2k laptop screen, but i run in 1080p because it saves battery and is more readable, but my tty and lightdm screens are 1440p
<goddard> why don't they just read what Unity has set?
<infinity> pitti: Hrm.
<infinity> pitti: What will trigger libselinux to retry against the new glibc?
<Mirv> pitti: I guess autopkgtest infra is still struggling and there's a new glibc too. anyway, updated kwin + marble were copied from a landing PPA 12h ago so for now I just wait
<pitti> Mirv: right, see http://autopkgtest.ubuntu.com/running.shtml -- I suppose at some point we need to cut off the triggered tests for glibc, they won't ever all succeed anyway; but we should give it some time so that we get enough results to be confident
<pitti> infinity: at the moment this needs to be done manually; there's a bug report against britney to do it automatically
<pitti> infinity: I re-ran selinux now
<Saviq> Mirv, morning, I've been havnig trouble with xenial proposed unfortunately, upgrading to it made unity8 crash-loop :/, trying from scratch again, but another thing is that apt reported additional 24MB of disk space used, we should make certain what's happening there...
<Mirv> Saviq: did you remove QML cache?
<Saviq> Mirv, d'oh
<Mirv> :)
<Saviq> Mirv, any case, the "additional 24MB" is scary
<Saviq> Mirv, but yeah, removing QML cache helped :)
<Mirv> Saviq: right, do you have scrollback of the upgrade? I remember some new dep was being installed, but I thought it was small. I wonder what has then bloated and how much.
<Mirv> Saviq: yes, I was at some point apport-retrace:ing and seeing "wow, crashing inside v4!" until I remebered that right... this feels familiar
<Saviq> Mirv, no, scrolled off I'm afraid, but I'll try from scratch anyway
<Mirv> Saviq: ok, let's check the newly installed packages first and then consider comparing the package sizes of themselves
<Mirv> Saviq: there seems to be also new poppler and apt libraries in proposed that when upgrading are installed alongside the old ones, those make up >4MB already
<Saviq> Mirv, right, might try going the silo route instead
<dholbach> good morning
<Saviq> moi
<Saviq> n
<Mirv> Saviq: FYI necessary packages are spread to two silos 012 + 059 so that'd mean manual configuring and pinning of both
<Saviq> Mirv, ack
<zzarr> hello! is there a way to install a 16.04 framework (kit) in Qt (Ubuntu SDK)?
<Unit193> cjwatson: Dang you are on top of it then, just saw your comment in the twisted bug about switching to Pyca.  Nice!
<Odd_Bloke> doko: Did you get a chance to look at the new comment on bug 1500768?  It looks like we still have a problem with the urllib3 that's bundled in python-virtualenv.
<ubottu> bug 1500768 in python-virtualenv (Ubuntu Trusty) "python3.4.3 SRU break requests" [Undecided,New] https://launchpad.net/bugs/1500768
<snkt> hiii
<snkt> Can anyone help me how to customize Live ubuntu ISO to autologin with root
<caribou> Anything obvious could explain the fact that, on one node, rsyslog exits with a SEGV when started by upstart but works fine if started from a shell ?
<cjwatson> Unit193: Well, that was only in passing really, I'm not actually working on the Twisted->PyCA thing
<Unit193> Didn't look like you were, just looked like you were watching it.
<cjwatson> Unit193: The really horrible archaisms (SHA-1 only) are out of the way now, but it'd certainly be nice to be able to add ECC and whatnot.
<Unit193> cjwatson: Indeed, personally I'm waiting for Ed25519 support.  I'm trying to use it everywhere, even though the router's dropbear sshd won't get it anytime (soon.)  Already was crazy enough to cross build putty for PA.c.  Anywho, no need to be taking up your time here with this.
<cjwatson> doko: Mind if I merge ncurses?
<pete-woods> pitti: it's that time again! (https://github.com/martinpitt/python-dbusmock/pull/17)
<doko> cjwatson, please do
<cjwatson> doko: ok, thanks
<davidsha> Quick question, is pciutils supposed to support libkmod on Ubuntu? I've seen it's supported on fedora and I'm just curious.
<cjwatson> davidsha: you seem to have filed a bug, which I think is the appropriate thing to do.  I'll forward it to Debian though.
<davidsha> cjwatson: thanks, sorry for bugging you guys about it!
<cjwatson> davidsha: forwarded, and linked the LP bug
<cjwatson> (https://bugs.launchpad.net/bugs/1516095)
<ubottu> Launchpad bug 1516095 in pciutils (Ubuntu) "pciutils built without libkmod support" [Wishlist,Triaged]
<davidsha> cjwatson: thanks!
<ubiquity> how to create official ISO from ubuntu source?
<highvoltage> you can't create official ISOs
<highvoltage> (well afaik)
<sladen> ubiquity: google for Ubuntu ISO customisation
<xnox> doko, it is ok to upgrade to new cython point release? =)
 * xnox uploaded it...
<ubiquity> livecd customization can create the same iso as the official one?
<doko> xnox, why do you ask then? ;p
<xnox> ubiquity, if it ends up the same, why customize. if it's different, it's not official anymore now is it =) only ubuntu publishes official images ;-)
<xnox> ubiquity, it will boot and it will install. but if you use packages or sources not from the archive, you will have to support it yourself.
<ubiquity> i want to know the process to create the official ISO
<doko> xnox, fyi, https://launchpadlibrarian.net/228711711/buildlog_ubuntu-xenial-s390x.gcc-5_5.3.1-0ubuntu1_BUILDING.txt.gz
<xnox> doko, >infinity ^
<smoser> xnox, was away yesterday. wrt qemu, talk to hallyn
<xnox> smoser, cool, thanks.
<xnox> hallyn, i'd like to have qemu 2.5 sooner, rather than later. Can we start working on packaging rc release? and are we targetting to ship with 2.5? Should we package them in ubuntu proper, or ppa?
<xnox> stgraber, i see you mark procps as please take, on MoM. I shall take it, as I need fixes from the merge.
<xnox> ... unless doko do you want to merge procps? =)
<doko> xnox, go ahead
<stevenm_> Hey, anyone here familiar with the ubiquity installer?  i'm looking at the bottom of the ubiquity/plugins/ubi-prepare.py file
<roaksoax> pitti: howdy! is there a way to force an app to use a newer postgress in packaging? ie. upgrading from trusty to xenial would mean a change of postgres versions
<roaksoax> pitti: how can I ensure that my app uses the latest postgresq ?
<roaksoax> pitti: specially when the packaging is using dbconfig-common
<hallyn> xnox: mjt has started packaging 2.5 for debian.  are you on oftc#debian-qemu?  that's where we generally discuss that
<hallyn> think you used to sit there... if memory serves :)
<pitti> roaksoax: you can of course depend on postgresql (>= 9.4) or so
<pitti> roaksoax: or perhaps better postgresql-9.4 | postgresql (>= 9.4), in case someone doesn't want the metapackage
<roaksoax> pitti: will that ensure than the DB is migrated to use postgresql-9.4 from 9.3 ?
<roaksoax> pitti: and all handled by dbconfig-common ?
<pitti> roaksoax: no, you can't, that needs to be done by the admin after the upgrade
<smoser> infinity, hey. i know that you have more than a few things that you take care of...
<smoser> but just pinging on presense of 'wily-netboot' at http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/installer-amd64/current/images/
<smoser> https://bugs.launchpad.net/maas-images/+bug/1511497
<ubottu> Launchpad bug 1511497 in maas-images "No hwe-w kernel for 14.04" [Medium,Confirmed]
<roaksoax> pitti: ok, so is this something we can do in packaging ?
<roaksoax> pitti: rather than have the admin do it?
<pitti> roaksoax: no, we can't do programmatic DB upgrades
<roaksoax> pitti: ok, cool! So then I guess we need to cry out load that users upgrade from trusty -> xenial will need to upgrade their DB's
<cjwatson> That's always been the case anyway
<pitti> roaksoax: that sohuld alreayd happen via debconf
<cjwatson> Launchpad would be very sad if you tried to do it automatically ;-)
<roaksoax> pitti: ok cool
<pitti> the package used to try in-place upgrades until 2005, it was all really brittle and sorry, so we stopped that
<didrocks> tseliot: apw: is the video framebuffer still part of the kernel or of any use? I'm looking at our custom vga16fb for plymouth and wonder if we shouldn't drop it?
<tseliot> didrocks: we should be able to drop it soon enough
<tseliot> didrocks: fglrx and nvidia are still the reason why we have that in place
<didrocks> tseliot: yeah, so, it's still a valid thing for xenial and plymouth should support it?
<tseliot> didrocks: yes
<didrocks> tseliot: I hope you have hardware to test the merge once done (thanks for volunteering btw :p) ;)
<tseliot> didrocks: yes, assuming I'm not on holiday by the time you do it ;)
<didrocks> tseliot: around next week? I hope to be done "soon" :)
<tseliot> didrocks: yep, except for Tuesday
<didrocks> oh, sounds excellent then! Will bother you ;) Thanks!
<tseliot> :)
<pitti> wow -- the s390x builders rock
<pitti> they went through 8 hours of buildd backlog in < 1 hour!
<cjwatson> it is nice to have fast and pretty stable builders for a new arch, for once
<cjwatson> only one kernel problem so far
<TJ-> could someone take a look at this affecting Vivid>Wily upgrades  'dpkg --configure' returns 10 - looks like someone forgot the .postinst runs with 'set -x' but needs confirming that's the correct fix: bug 1495302
<ubottu> bug 1495302 in openssl (Ubuntu) "subprocess installed post-installation script returned error exit status 10" [High,Triaged] https://launchpad.net/bugs/1495302
<ogra_> can you still call it a 8h backlog then ?
<cjwatson> ogra_: buildd queue lengths are a guesstimate based on package sizes estimated on 2010 x86 hardware
<ogra_> ah, a metric then :) (despite an old one)
<cjwatson> ogra_: at least in the case where we have no historic build data, as with a new arch
<ogra_> yeah
<cjwatson> the fallback estimate is: if we know the package size, then 6KB/second plus a minute for general overhead; if we don't, then five minutes
<cjwatson> we prefer the duration of the most recent successful build, though
<ogra_> wow, so there is actual math behind it
<cjwatson> it's not *complete* lies
<cjwatson> just frequently
<ogra_> :)
<cjwatson> anyway, they are definitely very nice builders, they've built 2/3 of their backlog and 27/28 of them have only been operational for about a day
<cjwatson> bodes well for generally keeping out of people's way
<ThiagoCMC> hey guys! Any plans to upgrade InfluxDB to 0.9.5 for Xenial ?
<ThiagoCMC> I'm planning to build a InfluxDB Cluster with it, when ready...
<botato> is there something for ubuntu that will make sure someone who has access to your machine won't have access to certain files. and when they try to access those certain files, a prompt will show up that will ask for a special password whcih isn't the same as the password they used to ssh into the machine?
<infinity> smoser: Soon.  I've been on vacation most of the week (and still am), only popping in for s390x bootstrapping.
<infinity> doko: Oops.  Will fix.
<doko> infinity, take -0ubuntu2
<infinity> doko: Should be happier now.
<dobey> botato: samba, vsftp, or something else, that only allows access via some other protocol. bug #ubuntu is the place to ask ubuntu support questions like that
<botato> ok thanks
<chiluk> pitti: I think it was you who was thinking about helping out by syncing findutils from debian-unstable to xenial.. so I checked and debian has 4.5.14, which does contain the fix for https://bugs.launchpad.net/ubuntu/+source/findutils/+bug/1347788
<ubottu> Launchpad bug 1347788 in findutils (Ubuntu Xenial) "find crashed when current working directory is not readable and -exec or -execdir used" [Low,Confirmed]
<ancaemanuel> Hi devs
<ancaemanuel> I sent an email to ubuntu-devel but is waiting for moderation
<dobey> ok
<ancaemanuel> My comment is about the current algorithm for the builders
<dobey> your question is about PPAs?
<ancaemanuel> I will post it here
<ancaemanuel> The current algorithm for building 12000 packages for an new architecture is:
<ancaemanuel> For a* to z* try build.
<ancaemanuel> Of course you will need lib* and *dev first, and you will waste a lot
<dobey> i doubt it
<ancaemanuel> of time trying to compile things.
<ancaemanuel> My proposal: try to find an algorithm for dependencies.
<dobey> new architectures don't get added often
<ancaemanuel> If package A depends on package B to be build, B gets an +1 for priority.
<ancaemanuel> there is mips ...
<dobey> ubuntu supports mips again?
<dobey> or you're talking about debian?
<ancaemanuel> No, jut an ideea
<ancaemanuel> just
<dobey> well there are lots of architecutres that ubuntu doesn't support
<ancaemanuel> am Im talkinh about https://launchpad.net/ubuntu/xenial/+builds?build_text=&build_state=built&arch_tag=s390x
<dobey> eh, the s390x hardware is incredibly fast
<stgraber> ancaemanuel: the problem is that to know what a package needs to be built, you need to unpack the source and run it through the package resolver in a chroot of the right architecture
<dobey> exactly
<stgraber> which is why we can't resolve and prioritize the right build ordering ahead of time, well, we could, but it'd be just as painful as just trying to build the damn thing
<stgraber> so instead we add build records for everything, typically starting with main which we know can be built in a self-contained manner and is typically what's used for the rest of the packages
<ancaemanuel> And when you build it, you can record the dependencies
<ancaemanuel> save for later
<stgraber> when something fails to build, Launchpad figures out why it failed to build (parses that from sbuild) and makes the package depwait
<stgraber> then attempts to build again once that package the depwait package is published
<stgraber> no you can't because we've got that thing called alternatives, a package may depend or build-depend on one out of a set of packages, the final one being picked depending on avaibility (whether it's built and available in an allowed component), the ordering matters there, the first being favored, so when bootstrapping an arch, less favored ones may be picked, but on a rebuild, you'd want the first to be picked
<stgraber> anyway, the effort of even trying to encode all of the resolver logic outside of the chroot, parsing all source packages at upload, ... would far exceed the average cost of just retrying a build
<stgraber> yes, a new arch bootstrap is a bit of a special case as the first packages to build have a high chance of failing to build, but we usually have done some manual bootstrapping outside of LP first so already know what the bootstrap stages are
<stgraber> so those build records can be created in the right order and then we can throw the rest at the buildds and wait a couple of days
<stgraber> which is never a real issue since we usually start building the distro way before anyone has hardware they can use it on, so nobody is actually waiting on those packages as they're still busy getting access to hardware to do their bits (most important one being setting up image builds)
<ancaemanuel> I am talking about dumb trying to build from a* to z* packages without *dev first
<dobey> that is your opinion, yes
<JanC> I guess stuff like glibc gets uploaded first anyway  :)
<stgraber> I know, I'm just saying that even with that, the cost of adding the logic to figure out those things without throwing them at a buildd far exceeds that of just throwing them at a buildd
<dobey> and it's not simply a-z. it's first-queued
<stgraber> In average that is. If we were to bootstrap a new architecture every week, that'd be different
<dobey> bootstrapping is hard (TM)
<dobey> let's go to pub
<stgraber> dobey: well, when we add a new arch, it's effectively what is done, we just create new build records for everything that exists in the archive. Except that we already have a minimal functional chroot that was pre-built by hand ahead of time (so the very low level stuff already exists) and that main builds before universe so we take care of a ton of libs that way.
<Unit193> s/hard/fun/
<dobey> stgraber: exactly. that was my point :)
<dobey> not like you can build a compiler without a compiler to compile it, either
<JanC> <stgraber> so those build records can be created in the right order and then we can throw the rest at the buildds and wait a couple of days | <dobey> let's go to pub â so that's what you do after starting the build? :P
<stgraber> JanC: pretty much
<dobey> JanC: you're assuming we're not in the pub when we start the build :)
<JanC> and that's why you don't want it to go too fast...
<stgraber> this time around, it'd be a question for cjwatson, wgrant and infinity :)
<ben___> any advice on debugging these "dpkg-shlibs: warning ... contains an unresolvable reference to symbol" issues? http://paste.ubuntu.com/13681422/
#ubuntu-devel 2015-12-05
<ben___> should dpkg-shlibs via dh_shlibdeps be run on shared library files? Or just executable binaries?
<dobey> ben___: yes, why wouldn't it be run on .so files?
<ben___> dobey, just flailing here. i think i've got it figured now.
<dobey> that is a normal message to see for dso plug-ins though, when they use symbols that are only satisfied after they are loaded into the executable
<cjwatson> pitti: Why is clamav/armhf listed as in progress on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ncurses ?  It's not listed on http://autopkgtest.ubuntu.com/running.shtml, and the last run on http://autopkgtest.ubuntu.com/packages/c/clamav/xenial/armhf/ was ages ago
<cjwatson> pitti: In general several of the test indicators there seem to be out of date
<Mirv> pitti: hmm, I'd be inclined to force kwin for now. the workaround to the screen edge tests when running under xvfb, adding XCB::RANDR to the test config among else, makes a xrandr test fail (which passed earlier). I'd rather include the real Qt fix for the screen-edges-test-under-xvfb from upstream, after upstream has approved and merged it.
<Mirv> (but it has not yet done so)
<Mirv> pitti: I can file a bug about the now failing test (with kwin ubuntu3) so that it gets tracked
<TJ-> anyone know how d-i/ubiquity (14.04.3 i386) determines the location when there's no network? We've got a user in Iran, getting a broken dialog with just "????" on the "Where are you" page of ubiquity, and cannot progress, and we're trying to figure out how the installer knows its Iran when the English language was chosen at startup.
<pcpratts> how do I link a bug with the ftbfs page?
#ubuntu-devel 2015-12-06
<denza242> any packagers online?
<denza242> guess not
<Logan> smb: are you planning on merging dahdi-tools?
<Logan> wow, this package gives a complete history of Ubuntu architectures: https://launchpad.net/ubuntu/+source/empire-hub/1.0.2.1
<mwhudson> i think as far as i can see https://launchpad.net/ubuntu/+source/subversion/1.8.13-1ubuntu3/+build/8382232 is basically a missing dependency, can someone retry it?
<lpotter> hmm
<cjwatson> mwhudson: Done, but made no difference.  On investigation (it's not at all clear from the build log), it's not going to get anywhere until qtbase-opensource-src has built.
<mwhudson> cjwatson: heh thanks
<mwhudson> cjwatson: and you're right that that was not clear from the build log :-)
<cjwatson> appears to be a load of failures in tst_QLogging
#ubuntu-devel 2016-12-05
<dbb> thx thats a good starting point..
<tsimonq2> yofel? :)
<nacc> caribou: so given the updates in debian, does it make sense for us to re-merge with at least 0.99.2+dfsg-4 ? to drop llvm-3.6 out of main? If we merge with -5, we could pick up the dep on llvm-3.9, i think, which is already in main?
<nacc> caribou: wasn't sure if that was already in your plans
<pitti> Good morning
<caribou> nacc: the -4 merge is ready but I would rather re-merge -5 to get LLVM back if you can import it
<nacc> caribou: running it now
<mitya57> Hi, I (still) need an archive team member to unblock the gnome-panel transition. Can someone please process bug 1646867 and decruft gnome-panel?
<ubottu> bug 1646867 in command-runner-applet (Ubuntu) "Please remove command-runner-applet from Zesty" [Undecided,New] https://launchpad.net/bugs/1646867
<nacc> caribou: should be done
<caribou> nacc: thanks!
<nacc> caribou: np!
<caribou> pitti: opened LP: #1647178 over the weekend
<ubottu> Launchpad bug 1647178 in systemd (Ubuntu) "systemd-resolved unable to resolve certain subdomains" [Undecided,New] https://launchpad.net/bugs/1647178
<caribou> pitti: still not sure if the problem is on my end, will try to update as I find time to test
<nacc> caribou: i also reassigned the second blueprint entry for clamav (specific to llvm) to you and marked it as INPROGRESS
<nacc> pitti: is there a script i can run to request that an autopkgtest of a packge using deps from proposed? specifically, I am looking to request imagemagick and php-imagick run from -proposed, so that imagemagick can transition (you can see that php-imagick in -proposed does work against the version of imagemagick in -proposed)
<pitti> nacc: if you have the retry link from excuses.html, just append &all-proposed=1
<nacc> pitti: ah ok! thanks!
<nacc> pitti: worked like a charm, thanks again!
<nacc> with imagemagick, there is no longer an imagemagick-dbg and libmagick++-6.q16-5v5 in the z-p version. Do I need a release team member to help that transition along (based upon the excuses output)
<nacc> it looks like ilohamail has been deleted from debian unstable. Should we go ahead and delete it from 17.04?
<Laney> doko: could you do rebuilds for double-conversion please?
<Laney> (except qtdeclarative, handling that)
<Laney> urgh
<Laney> its build-deps aren't installable
<dmj_s76> sforshee: Thanks for the quick turnaround on the linux-firmware issue!  That was just in the nick of time for us with the new kernel update.
<sforshee> dmj_s76: happy to help
<juliank> Can someone please go ahead with approving the apt xenial SRU for -proposed now or tell me if something else is missing? There's some trouble ahead, and I'd really like to get this in first.
<juliank> infinity: Around?
<infinity> juliank: Sort of, but not really.  About to pass out after a long day.
<juliank> hmm, okay
<juliank> Maybe sarnold is a bit more awake?
<sarnold> hey juliank; sorry, I don't think I have the necessary privileges to move along the apt package :(
<juliank> Ah not that.
#ubuntu-devel 2016-12-06
<hikiko> hello
<noam> Hi! Where is the script that produces the ubuntu ISO images?
<seb128> doko, hey, re your reply on the list about the sponsoring item, see +activity on the log, somebody sponsored the item yesterday and unsubscribed sponsors when doing so, so they were subscribed... it's just that we don't have much active sponsors :-/
<doko> seb128: ahh, I see
<alkisg> The version of nbd-client in xenial doesn't really support systemd, see for example https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1487679
<alkisg> The version of nbd-client in debian stretch does support systemd.
<alkisg> How easy would it be to have an SRU for syncing with the new version, instead of targetting individual bug fixes, which I think is quite hard wrt the code changes?
<ubottu> Launchpad bug 1487679 in nbd (Ubuntu) "Breaking ordering cycle by deleting job nbd-client.service/start" [Undecided,Triaged]
<seb128> bdmurray, hey, the +activy package does show when the team was unsubscribed on that sponsoring bug, where are you looking?
<seb128> alkisg, hey, depending of the complexity of the changes and how good the package testsuite (or manual testing) is, you basically need to convince the SRU team that the update is not going to create new issues for users who had it working
<seb128> alkisg, if the previous version can't work for anyone it should be pretty easy to argument for an update, if it's not that obvious then you need to convince of the pros&cons
<alkisg> seb128: ty; I'll file a bug report and make a few arguments there
<seb128> alkisg, thanks
<ricotz> helloW: APT had planned for dpkg to do more than it reported back (4 vs 6).
<ricotz>    Affected packages: base-files:amd64
<ricotz> oops, was about to ask if this was reported somewhen in the past
<ricotz> "apt-get install --reinstall base-files" doesn't resolve it
<ricotz> juliank, hi, ^
<juliank> ricotz: oh, a bug there, nice. I sometimes wish DonKult was here, he wrote that stuff ...
<juliank> ricotz: That's in yakkety?
<juliank> or zesty?
<juliank> or where?
<ricotz> juliank, no idea, what this is about ;), on zesty
<juliank> OK.
<ricotz> I assume this package is in this state for a while
<juliank> ricotz: It's a disagreement how many steps dpkg will execute.
<juliank> ricotz: Does that actually break anything?
<ricotz> so far I dont see any side-effect, the package was configured too
 * juliank has no idea, that's fairly new stuff - DonKult recently made apt not queue each dpkg request in detail but allowed dpkg to act a bit more on its own. This obviously means that our view of what dpkg will do should match what dpkg does.
<juliank> I told DonKult about it, but it's probably a good idea to open a bug for that
<ricotz> (but it is marked as not completely installed)
<ricotz> iW  base-files                                                       9.6ubuntu8                                           amd64
<juliank> Open a bug in LP, and add all your details there :)
<juliank> I don't want to play proxy between #ubuntu-devel here on #debian-apt on OFTC
<Laney> but you do it so efficiently
<juliank> and a bug is more persistent and we can actually mark it as solved :)
<Laney> almost no dropped packets
<juliank> Laney: How do you know?
<Laney> the N in laney stands for NSA
<juliank> Oh. I always thought Laney means LA, ney - a misspelling of LA, nay.
<Laney> La NSA 'ears you
<juliank> Actually, it appears ney is used as well
<mmmm> Would my computer be able to run ubuntu? https://postimg.org/image/yqfdsljtb/
<juliank> but it's an instrument
<juliank> A type of end-blown flute.
<sladen> mmmm: the hardware would be more than capable for installing Debian or Ubuntu, yes
<mmmm> Trying to get the secure boot disabled has been the hardest part
<bdmurray> seb128: In the wrong column on the activity log. :-|
<seb128> bdmurray, k
<bdmurray> seb128: feel free to follow up
<seb128> bdmurray, somebody else did
<sladen> mmmm: yes, the difficulties will be things like changing the boot order/boot setup to get either Debian or Ubuntu installed
<mitya57> pitti, hi, can you please help me a bit using your archive team powers?
<mitya57> I need a package removal (bug 1646867) and decruft of gnome-panel (rm old binaries)
<ubottu> bug 1646867 in command-runner-applet (Ubuntu) "Please remove command-runner-applet from Zesty" [Undecided,New] https://launchpad.net/bugs/1646867
 * mitya57 did a general ping two times here, but nobody responded :(
<rharper> pitti: thanks for the sanity check, I was able to get things working with just adding a +Before=systemd-networkd.service to resolvconf.service
<rharper> pitti: since that file is part of the resolvconf package I'll update bug 1636912 with the details;  should I mark that verification-failed and link to a resolvconf change? or leave it -needed, and wait till we also have a resolvconf update ?
<ubottu> bug 1636912 in cloud-init (Ubuntu) "systemd-networkd runs too late for cloud-init.service (net)" [High,Triaged] https://launchpad.net/bugs/1636912
<infinity> mitya57: Removal done, though LP is timing out on me trying to close the bug. :P
<mitya57> infinity, thanks a lot!
<infinity> mitya57: Not sure what "decrufting" you're looking for for gnome-panel.
<mitya57> infinity, I meant removing old libpanel-applet0{,-dbgsym} and gir1.2-panelapplet-5.0 binaries to that the new version can migrate
<mitya57> (which changed to libpanel-applet2 and no gir bindings)
<infinity> mitya57: It'll migrate fine without doing that.
<infinity> mitya57: We remove NBS packages *after* migration, not before.
<infinity> (doing it before would break the archive)
<mitya57> OK, I was probably confusing with Debian then. Thanks again!
<mitya57> pitti, unping :)
<infinity> mitya57: http://paste.ubuntu.com/23587930/ shows that the only issue is command-runner-applet, which will clear up after the next publisher run.
<mitya57> OK, I do check that page, but not always sure that I parse it correctly.
<pitti> mitya57: good; sorry, sprint week, negligible IRC bandwidth
<mitya57> Thanks anyway and sorry for the noise!
<slashd> cyphermox, xnox, I have a critical bug here LP: #1579609 for os-prober, there is a patch proposed in debian, I test the patch with different users experiencing the issue, and they claimed it solve the situation, since the patch is not yet merge in debian and that this is a CRITICAL bug as it may cause some FS corruption, do you think we can go ahead with the SRU anyway or better wait the merge in debian ?
<ubottu> Launchpad bug 1579609 in os-prober (Ubuntu Xenial) "os-prober bug resulting in possible FS corruption" [Critical,In progress] https://launchpad.net/bugs/1579609
<juliank> mdeslaur: Feel free to query ...
<cyphermox> slashd: we can land it in a SRU, it's not a problem if the patch is sane.
<slashd> cyphermox, it is, and has been tested by different users
<cyphermox> well, I'll be the judge of that ;)
<slashd> cyphermox, sure
<cyphermox> slashd: seems to me like it probably should just drop the else part
<slashd> cyphermox, agree
<slashd> cyphermox, if I understand properply you are good with it (minus the else part) ? or you need more time to check ?
<cyphermox> slashd: I think I'd be more ok if it was just changing the else part of that if, rather than changing both branches
<slashd> like this ? https://pastebin.canonical.com/172868/
<slashd> cyphermox ^
<cyphermox> right, but the error message is probably wrong too in this case
<slashd> cyphermox, any suggestion ?
<cyphermox> "failed to probe for filesystem type" or something like that?
<slashd> Yeah, I like that
<slashd> cyphermox, ok will proposed a debdiff today, tks, do you think you'll have time to sponsor it this week ?
<slashd> cyphermox, enjoy Seville chanceux ;)
<xnox> pitti, i do not understand the libseccomp NMU
<xnox> it seems weird. What does Build-Depends-Package in .symbols do?
<pitti> xnox: it makes sure that the generated shlibs depends is never lower than the version of the specified package in that flag
<pitti> xnox: see dpkg-shlibdeps(1)
<pitti> xnox: "version" as in "installed during package build", that is
<xnox> pitti, interesting
<juliank> Someone remind me to actually try to SRU ndiswrapper everywhere with newer kernels - all these build failure reports are somewhat annoying...
<juliank> s/build failure/dkms failure/
<juliank> It certainly would be nicer if we also did ndiswrapper uploads that work with new kernels when new kernels enter LTS releases
<doko> wgrant: because you fixed xdelta3 to run the tests ... is the desktop team really the correct bug subscriber?
<doko> I mean, they were for trusty, but now?
<pitti> cpaelzer: https://launchpad.net/ubuntu/+source/postgresql-9.5/9.5.4-3
<slashd> cyphermox, I have attach the debdiffs to LP: #1579609
<ubottu> Launchpad bug 1579609 in os-prober (Ubuntu Xenial) "os-prober bug resulting in possible FS corruption" [Critical,In progress] https://launchpad.net/bugs/1579609
<seb128> @pilot in
<chiluk> sarnold: mind if you upload https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/1634304 for me?
<ubottu> Launchpad bug 1634304 in virt-manager (Ubuntu) "Unable to complete install: 'Couldn't find hvm kernel for Ubuntu tree" [Undecided,Confirmed]
<chiluk> seb128:  ^^
<sarnold> chiluk: sorry, I don't have sufficient privileges :(
<chiluk> ah.. I figured you did considering your earlier review of that bug.
<chiluk> or were you just a concerned user of virtinst?
<chiluk> sarnold ^
<sarnold> chiluk: pff, worse than that, I just can't help myself. I read every patch just because it's there. I should try to just a group therapy for it or something but no one else is wlling to publicly admit they suffer from the same condition
<chiluk> sarnold: you are definitely in the minority within the minority.
<sarnold> chiluk: aye.
<sarnold> at least regular obsessed people climb mountains or something.
<chiluk> sarnold: we give free operating systems to underprivileged kids in third world countries.
<chiluk> I think that's pretty respectful.
<sarnold> chiluk: thanks for being my ennabler :)
<chiluk> any time.
<chiluk> now go find me a sponsor.
 * chiluk works on motu application.
<wgrant> doko: I'm not sure who owns the snappy packages for main purposes. Will poke around.
<wgrant> doko: Do you have any other concerns about the MIR so far?
<maqifrnswa> Hello again - when someone gets a chance, can you re-trigger autopkgtest for python-qtconsole against ipython? https://autopkgtest.ubuntu.com/request.cgi?release=zesty&arch=amd64&package=ipython&trigger=python-qtconsole%2F4.2.1-3
<maqifrnswa> There might be a circular dependency problem preventnig ipython, glueviz, and python-qtconsole from migrating
<maqifrnswa> (from proposed). ipython used to have a bug in autopkgtest, so it would fail and never migrate. python-qtconsole autopkgtest saw that ipython couldn't migrate, so it wouldn't. glueviz sees python-qtconsle can't automigrate, so it won't - but it also requires the newest version of ipython (which is also stuck)
<maqifrnswa> migrating ipython is prevented because it will break the old version of glueviz, but the new version of glueviz requires the new version of ipython
<maqifrnswa> thank you!
#ubuntu-devel 2016-12-07
<pitti> buenos dÃ­as amigos!
<bdmurray> mvo: there are many snapd uploads in the yakkety queue, which ones can I reject?
<ginggs> morning pitti!
<smoser> pitti, you have a minute ?
<slangasek> smoser: he's scratching his head at lp apis at the moment
<pitti> smoser: sure, where are you?
<mvo> bdmurray: hi, thanks for looking at the snapd yakkety queue. please reject all of them except for 2.17.1+16.10ubuntu1 (from 2016-12-06)
<Laney> pitti: do you know if basic_reject()ing an item puts it back in the queue in the order of rejection?
 * Laney is wondering about a script to move some requests to the front ...
<pitti> Laney: did you see the bug I filed this morning? I discussed prioritization of "slow" packages like glibc or perl with infinity yesterday
<Laney> not yet
<pitti> bug 1647948
<ubottu> bug 1647948 in britney "Better prioritization for packages with lots of tests" [Wishlist,New] https://launchpad.net/bugs/1647948
<pitti> Laney: I *believe* rejecting an item doesn't fundamentally change its order in the queue
<pitti> Laney: also, you break the transactional handling with that (reject and putting it back)
<pitti> (but if that's a manual script that's probably not much of a concern)
<Laney> oh FFS offlineimap
<Laney> if I suspend while it's running it just hangs forever
<Laney> -> no new emalis
<nacc> is the autopkgtest queue length expected right now? maybe that was the glibc discussion earlier?
<pitti> nacc: yep, glibc triggers three metric tons of tests (basically all of them)
<pitti> nacc: you can see the contents of the queue on /running
<nacc> pitti: yeah, i was looking at it now, thanks!
<Laney> From RabbitMQ release 2.7.0, messages are always held in the queue in publication order, even in the presence of requeueing or channel closure
<pitti> Laney: hm, I still see some lopsiding towards i386
<pitti> anyway, lunch :)
<Laney> pitti: a bit of skew is to be expected with random
<shadeslayer> chrisccoulson: hey, could you please update http://bazaar.launchpad.net/~mozillateam/firefox/firefox.yakkety/view/head:/debian/changelog with update to yakkety?
<shadeslayer> seems to be lagging behind what's in the archive
<shadeslayer> chrisccoulson: and perhaps drop hardening-wrapper from thunderbird too like it was done for firefo
<shadeslayer> *firefox
<zobel> who is maintaining https://cloud-images.ubuntu.com/locator/ ?
<Odd_Bloke> zobel: o/
<Odd_Bloke> zobel: In case I don't respond (I'm at a sprint ATM), bugs for it are tracked at https://bugs.launchpad.net/cloud-images/+filebug :)
<cyphermox> pitti: https://code.launchpad.net/~netplan-developers/netplan/+git/netplan/+merge/312682
<cyphermox> and https://code.launchpad.net/~netplan-developers/netplan/+git/netplan/+merge/312683
<xnox> infinity, the day has come, when i need to rebuild upstart.... and it fails its tests.....
<xnox> like you told me so
<infinity> xnox: I sure did.
<infinity> xnox: Enjoy.
<infinity> xnox: The best part is that when you fix it, it'll be fixed on s390x too, and we can undo all the hacks and removals that I told people they shouldn't do. :P
<infinity> *cough*slangasek*cough*
<doko> and libnih?
<infinity> nih was never a problem.
<xnox> tedg, what's left to port ubuntu-app-launch to systemd?
<xnox> and does that need upstart/systemd to launch legacy apps at all?
<tedg> xnox: tests and code reviews
<tedg> xnox: Yes, it launches legacy apps under systemd as well
<doko> infinity: http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20161202-zesty.html ftbfs everywhere
<infinity> doko: I assume that uses a test toolchain?
<doko> infinity: no, regular archive test rebuild
<infinity> doko: Oh, no.  Derp.  Just doesn't have the ppc build fix in that version of glibc.  Brain fart.  Ignore me.
<doko> and we removed the one in yakkety-proposed, because it failed to build
<shadeslayer> chrisccoulson: oh and thunderbird doesn't seem to have a zesty branch
<infinity> So many new pep8 failures...
<dims> xnox : ping about https://bugs.launchpad.net/lazr.authentication/+bug/1609128 we had to pin some stuff in openstack as well since latest pkgs are not on pypi. Do you know who can help?
<ubottu> Launchpad bug 1609128 in lazr.authentication "PyPI metadata is wrong" [Undecided,New]
<dims> cjwatson : perhaps you may know?
<xnox> dims, i do not believe i can release that on pypi. Maybe barry or cjwatson or wgrant
<dims> ah thanks xnox . cjwatson wgrant pretty please :)
<xnox> tedg, where is it?
<xnox> tedg, i like want to upload it into zesty right now.
<xnox> tedg, and purge src:upstart from zesty asap
<xnox> tedg, or i'm pondering to kick off unity8 session off desktop images
<tedg> xnox: It's a secret :-P
<tedg> xnox: It doesn't drop Upstart yet, it has both and chooses systemd if available.
<tedg> xnox: Wanted to land that first, let it settle and then remove Upstart.
<xnox> aha.
<xnox> no.
<tedg> xnox: Oh, it doesn't build on Zesty right now, need to fix the Google Mock stuff :-(
 * tedg waves fist at Google Mock
<xnox> tedg, i think you want to wave fist at cmake-extras, and thus have your own copy of google mock in tree. no?
<tedg> xnox: I think that cmake-extras has been updated and I just need to match. A TODO more than a problem.
<xnox> tedg, there are branch conflicts
<tedg> xnox: Did you get all the branches? https://bileto.ubuntu.com/#/ticket/2105
 * tedg rebuilds that silo
<xnox> right
<xnox> tedg, why do you target xenial?
<xnox> tedg, you should land this in zesty now, continue to iterate, and land in xenial once the kinks are ironed out.
<xnox> tedg, you totally should be using per-series branches here, and diverge zesty from xenial for now.
<tedg> xnox: We're doing this work for the U8 session snap as well, that needs it. That snap is built from Xenial.
<xnox> tedg, time and priority wise, not so much.
<xnox> tedg, zesty should not have src:upstart yesterday. xenial will have upstart forever.
<tedg> xnox: Heh, well, depends on how you look at it :-) Priority for me is the U8 snap.
<xnox> tedg, shall i drop u8 session from zesty-desktop-amd64.iso then?
<tedg> And zesty will still have Upstart, just not on the iso.
<xnox> tedg, no.
<xnox> tedg, it will not have src:upstart
<tedg> xnox: I'm skeptical but would love to see you accomplish that.
<xnox> $ cat debian/upstart-xsessions
<xnox> # xsessions listed below are run inside an Upstart user session.
<xnox> unity8-x11
<xnox> unity8-mir
<xnox> in zesty
<xnox> all other sessions moved off upstart.
<tedg> xnox: Upstart is used by the greeters and some of the other flavors that start indicators.
<xnox> there are no clicks pre-installed, and those don't make sense on desktop u8 anyway.
<seb128> tedg, I think pitti fixed the greeter
<pitti> the branch landed, but it's stuck on ubuntu-greeter having broken tests due to some HiDPI changes
<xnox> tedg, other flavours did not have upstart seeded, thus they reverted back to non-upstart session long time ago.
<pitti> robert was looking into this
<tedg> Clicks don't have any relation to Upstart.
<pitti> tedg: ubuntu-app-launch?
<pitti> (link of clicks to upstart)
<tedg> The UAL that runs systemd will run Clicks under systemd
<xnox> tedg, well, my point is that on u8 desktop session today, only apps ubuntu-app-launch is used is to launch legacy apps, and from my point of view, it can just exec those directly =)
<tedg> But I imagine that'll be the next backend to get dropped.
<xnox> tedg, i hope to not have src:click in zesty either.
<xnox> tedg, all of bileto will have to have separate branches for xesty-overlay vs zesty.
 * tedg giggles at xesty overlay
<tedg> xnox: You're welcome to fight that battle, I am not.
<xnox> tedg, i don't need to find anything =) i will just break zesty seeds, and be done with it.
<xnox> *fight
<slangasek> "<infinity> nih was never a problem." <-- heh.
<dobey> xnox, tedg: i'm not sure how much work it is, but it's probably feasible to get rid of click from zesty, and also thusly get rid of click support in xenial+overlay for the unity8 snap too
<petn-randall> Hi, were would I find the packaging VCS to rng-tools? I plan on introducing rng-tools5 to Debian again, and I'd like to inherit the VCS history to retain the contributions of the Ubuntu maintainers.
<tyhicks> @pilot in
<lutostag> anybody know how I would install golang-1.7 in 16.10 and get a 'go' executable?
<tianon> either via src:golang-defaults (ie, "golang"/"golang-go") or via PATH
<tianon> export PATH=/usr/lib/go-1.7/bin:$PATH
<lutostag> tianon: perfect, thanks!
<tianon> :)
<chiluk> nacc can you sponsor https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/1634304  ?
<ubottu> Launchpad bug 1634304 in virt-manager (Ubuntu Zesty) "Unable to complete install: 'Couldn't find hvm kernel for Ubuntu tree" [Undecided,Confirmed]
<chiluk> actually can anyone sponsor https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/1634304 for me please?
<loladiro> I vaguely remember a discussion somewhere about the graphics drivers dynamically linking LLVM on Ubuntu. I keep seeing applications be bitten by this, so I wanted to add my strong support to undoing that and linking LLVM statically again. Unfortunately, I havenât been able to find that issue. Anybody have a hunch where that would have been?
<tyhicks> chiluk: I'll have a look (I'm patch piloting right now)
<chiluk> thanks tyhicks.
<chiluk> tyhicks: what's the process when a package sources are the same accross two releases?
<chiluk> do you just end up uploading the newest one and sync back to the older one?
<chiluk> tyhicks in this case zesty and yakkety are the same source base and both need the change.
<chiluk> I really don't want to fork the versioning for yakkety.
<tyhicks> chiluk: you'd apply the same debdiff to both except that yakkety's version would be 1:1.3.2-3ubuntu3.1 and zesty's would be 1:1.3.2-3ubuntu4
<chiluk> tyhicks: see that seems strange to me.
<tyhicks> chiluk: how come?
<chiluk> tyhicks because now you have the same sources with two different versions.
<tyhicks> chiluk: but the resulting binary packages are built against different build-depends
<chiluk> true..
<chiluk> so there's no way to keep the versions the same accross the two releases?
<tyhicks> chiluk: no because you want a machine upgrading from yakkety to zesty to upgrade to the zesty version that was built against zesty build-depends
<tyhicks> (or maybe zesty enables some better compiler hardening options)
<chiluk> yeah I get your point.
<chiluk> didn't think about the upgrades possibly being an issue with the same versioning.
<tyhicks> chiluk: mind if I adjust the versioning myself in the zesty+yakkety debdiff as I upload to zesty and yakkety?
<tyhicks> (there's no sense in having you attach new debdiffs for that)
<tyhicks> chiluk: your debdiffs look great but I have one question about the upstream patch
<chiluk> shoot
<tyhicks> chiluk: have any idea why the added comment says "default to amd64" but then it defaults to i386? https://github.com/virt-manager/virt-manager/blob/master/virtinst/urlfetcher.py#L1110
<chiluk> yeah tyhicks have at the versioning change.. there's no sense in uploading a new debdiffaltogether
<chiluk> tyhicks I'm really not sure.
<chiluk> I found that peculiar as well.
<chiluk> what I do know though is I tested the fix on yakkety as well as xenial
<chiluk> and it fixed things in both cases.
<chiluk> this was pretty much a straight cherry-pick
<tyhicks> chiluk: ok, I left a question in the upstream PR but will proceed with sponsoring
<tyhicks> chiluk: nice debdiffs!
<chiluk> tyhicks: since I have you in the mood https://wiki.ubuntu.com/chiluk/CoreDevApplication
<chiluk> ;)
<tyhicks> chiluk: I mean cmon... they aren't THAT nice
<chiluk> ouch.
<tyhicks> chiluk: just kidding, I'm happy to leave a nice comment :)
<chiluk> tyhicks you mean endorsement
<tyhicks> yes
<chiluk> I'm going to try to get through the process before too long.
<tyhicks> you shouldn't have any problems
<tyhicks> chiluk: done (uploads sponsored) and done (coredev endorsement)!
<chiluk> thanks tyhicks.. now to find an sru sponsor.
#ubuntu-devel 2016-12-08
<mwhudson> heh the autopkgtest queue for zesty/amd64 looks a bit crazy
<tyhicks> @pilot out
<tyhicks> sponsored virt-manager (LP: #1634304) and will be security-sponsoring mariadb-{5.5,10.0} (LP: #1638125) and proftpd-dfsg (LP: #1462311) after they finish building in the security PPA
<ubottu> Launchpad bug 1634304 in virt-manager (Ubuntu Zesty) "Unable to complete install: 'Couldn't find hvm kernel for Ubuntu tree" [Undecided,Fix committed] https://launchpad.net/bugs/1634304
<ubottu> Launchpad bug 1638125 in mariadb-10.0 (Ubuntu Xenial) "USN-3109-1: MySQL vulnerabilities partially applies to MariaDB too" [High,Confirmed] https://launchpad.net/bugs/1638125
<ubottu> Launchpad bug 1462311 in proftpd-dfsg (Ubuntu Trusty) "proftpd mod_copy issue (CVE-2015-3306)" [Medium,In progress] https://launchpad.net/bugs/1462311
<tsimonq2> Hey guys, how would I go about having a comment added here? https://merges.ubuntu.com/universe.html
<tsimonq2> As in a comment on a package
<tumbleweed> type and press enter
<tsimonq2> ...?
<tsimonq2> I can't do that...
<tumbleweed> yes you can
<tsimonq2> How?
<tumbleweed> click in a comment field, type, e...
<tsimonq2> OH
<tsimonq2> HAH
<tsimonq2> Thank you
<tumbleweed> :)
<sarnold> cool :)
<pitti> Good morning
<nacc> doko: fyi, upstream libwebp is going to have the full fix for the neon detection bits in 0.5.2, we can drop the delta once it's packaged: https://bugs.chromium.org/p/webp/issues/detail?id=313
<bdmurray> seb128: This crash seems to only affect the SRU'ed version of libreoffice - https://errors.ubuntu.com/problem/3f5546617f0b197529d734bee9ae770fb485b92d
<doko> nacc: looks ok if it's arm64 only. we can't assume neon on armhf
<nacc> doko: ack, I'll make sure to test that (0.5.2 isn't packaged yet in debian, not sure it's actually released upstream yet, that patch is just queued for it)
<smoser> pitti, systemctl status home.mount
<smoser>    Loaded: loaded (/etc/fstab; bad; vendor preset: enabled)
<smoser> why 'bad' ?
<pitti> smoser: not sure, my laptop says "loaded (/etc/fstab; generated"
<pitti> smoser: any journal errors about that?
<smoser> interesting. do you have a home.mount ?
<pitti> smoser: not on disk, just from the fstab generator in /run
<pitti> UUID=deadbeef /home           btrfs   defaults,subvol=@home 0       2
<pitti> i. e. nothing surprising
<pitti> smoser: do you have a drop-in for this or an on-disk unit?
<stgraber>    Loaded: loaded (/proc/self/mountinfo)
<stgraber>    Active: active (mounted) since Wed 2016-12-07 14:43:31 CET; 19h ago
<smoser> pitti, i've not done anything.
<seb128> bdmurray, hum, thanks, let's see what Bjoern has to say about it but I expect that he's going to say that the number of reports is too low and it's in statistical errors not relevant
<smoser> on zesty another sytsem, i see http://paste.ubuntu.com/23597482/
<pitti> smoser: so, anything about home.mount in journal?
<smoser> seemingly more normal
<smoser> not much
<pitti> smoser: yep, that's how it looks like here too
<smoser> http://paste.ubuntu.com/23597483/
<bdmurray> seb128: okay, than that I'm happy with fully phasing it
<seb128> bdmurray, ok, great, thanks for reviewing those and for unblock the snapd-glib one!
<seb128> unblocking
<pitti> smoser: any errors in systemd-analyze verify /run/systemd/generator/home.mount other than the "unit is bound to inactive..."?
<smoser> pitti, systemd-analyze verify shows nothing at all
<smoser> http://paste.ubuntu.com/23597499/
<smoser> pitti, if you want to come and look i can let you
<pitti> smoser: which room?
<smoser> but i'm not terribly fussed on it at this point
<smoser> server room.
<pitti> rharper: resolvconf updated in x/y/z
<rharper> pitti: thanks!
<nacc> rbasak: https://en.wikipedia.org/wiki/Chemical_file_format
<nacc> slangasek: is it correct to assert that a 'patches-applied' version of a srcpkg only makes sense for 3.0 (quilt)
<petn-randall> Hi, were would I find the VCS used for packaging for rng-tools? I plan on introducing rng-tools5 to Debian again, and I'd like to inherit the VCS history to retain the contributions of the Ubuntu maintainers.
<nacc> petn-randall: afaict, no vcs was used; it might have been bzr, but the last update was in vivid (15.04)
<nacc> petn-randall: or at least, i'm not sure there's a gurantee there was
<petn-randall> nacc: Is there some implicit scheme where I could expect to find the bzr repo?
<nacc> petn-randall: this seems to be 'current': https://code.launchpad.net/~ubuntu-branches/ubuntu/vivid/rng-tools/vivid
<nacc> petn-randall: or more accurately (historical branches): https://code.launchpad.net/ubuntu/+source/rng-tools
<nacc> petn-randall: if you want to look at the same sort of thing, but from git, I could import it for you on the side (or you could run that import locally), to at least keep the history. It won't match the VCS exactly (in that it doesn't know about bzr), but will have the fully history of the srcpkg in ubuntu
<petn-randall> nacc: I'd only import the master/current branch, not all branches, since I only want to retain the contributions of Ubuntu devs, and not retain all releases of all Ubuntu releases (this is of limited use for Debian). The bzr repo already helped me out a lot, thanks.
<slangasek> nacc: if you mean "does patches-applied make sense for a package with debian/patches that's format 1.0?", yes it's correct that this does not make sense
<nacc> slangasek: ack, thanks!
<nacc> petn-randall: np!
<nacc> slangasek: and one step further, is '3.0 (quilt)' the only format for which it makes sense to have a difference between patches-unapplied and patches-applied
<slangasek> nacc: yes, because it's the only format for which dpkg-source applies packages
<slangasek> patches
<slangasek> nacc: a 1.0 package may have bits in the diff.gz that are unpacked to locations outside of debian/; but there is no equivalent "patches-unapplied" in that case
<smoser> pitti, so i think yesterday you were saying i could dropin to be After=cloudinit-local.service
<smoser> for systemd-fsck@dev.service
<smoser> that is what looks right.
<smoser> can you do a 'Before=systemd-fsck@dev.service' ? or is that not possible or desireable due to the @
<pitti> smoser: that's possible; if you have a template unit already, you have %I, so you can do Before=systemd-fsck@%I.service
<pitti> and otherwise, if you know the device already, put that in
<smoser> well, ic an't know the device until i run
<smoser> and at that point its too late.
<smoser> so i think dropin seems maybe the only thing i can do
<pitti> smoser: that seems fine
<smoser> pitti, so the path then is:
<smoser>  /lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
<pitti> *nod*
<smoser> the @ i ddin't know for sure. thanks
<pitti> smoser: I'm not sure if you can literally do "Before=bar@.service" and it would automatically apply to the same instance as the unit it came from
<pitti> I think that won't work, but feel free to give it a try of course
<smoser> i think it wont work also
<pitti> rharper: ah, Thomas already responded (I think you did test in sid, right?)
<rharper> pitti: yes
<rharper> but ifupdown/networking  only
<rharper> I'll reply
<rharper> I've not tested networkd in debian
<pitti> that should be enough to ensure it doesn't regress
<rharper> I think so too
<rharper> but I want to double check
<rharper> before I say yes
<pitti> smb: /proc/sys/net/core/rmem_default
<pitti> smb: udevadm info --export-db|grep -c ^P:
<nacc> cpaelzer: LP: #1593024
<ubottu> Launchpad bug 1593024 in zend-framework (Ubuntu) "Unblacklist and sync zendframework 1.12.18+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1593024
<nacc> cpaelzer: c#16 (some bullets in c#14 for context)
<nacc> cpaelzer: https://wiki.canonical.com/ServerTeam/ServerReleaseHandling
<caribou> rbasak: looks like the 'broken' samba package we rolled back is still present in xenial-proposed :
<caribou> samba | 2:4.3.11+dfsg-0ubuntu0.16.04.2 | xenial-proposed
<caribou> rbasak: shoudn't it be removed from there also ?
<Laney> apw: doko: do you know what's up with linux/amd64 and linux/ppc64el autopkgtests on zesty?
<Laney> are they being skipped?
<doko> Laney: no idea, and apw is on paternity leave
<Laney> hmm
<Laney> doko: it's blocking your gcc-6 and binutils :-)
<doko> sure, I know that
<infinity> Eh.  Why was that run with --all-proposed?
<Laney> that?
<infinity> 4.9.0 isn't in release yet.
<Laney> Don't know, but 4.8 wasn't any better
<infinity> So, someone from the kernel team should look at them and tell us if it looks like the toolchain broke them or if their tests just suck.
<infinity> bjf: ^
<bjf> infinity, can you tell rtg what the issue is and what you need him to look into?
<infinity> rtg: Your autopkgtests are failing in zesty for the new gcc and binutils uploads, can you look into the logs and decide who to blame?
<rtg> infinity, can do
<Laney> There's already a badtest for linux
<infinity> Oh, is there a current one?
<infinity> Well, maybe that's just the way to go for now, but that's getting really old.
<Laney> Nope
<infinity> A testsuite that almost never passes is pretty useless.
<Laney> Maybe there's some history there though
<rbasak> caribou: yes, but I'm told it needs an AA to do a v-f removal.
<rbasak> We should get better at this though. If people are volunteering to test -proposed for us, the least we could do is remove known broken stuff, IMHO.
<caribou> ah, ok. Someone just reported the issue on the Trusty bug
<rbasak> slangasek: bug 1644428: please could you delete samba from xenial-proposed? ^
<ubottu> bug 1644428 in samba (Ubuntu Trusty) "Unable to log in with AD account after update" [High,Fix released] https://launchpad.net/bugs/1644428
<doko> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845690 was kernel related, but that one is fixed
<ubottu> Debian bug 845690 in binutils "binutils: creates unbootable kernel on x86-64" [Important,Fixed]
<rbasak> Strictly speaking it's bug 1584485 I think actually. That's where the v-f is.
<ubottu> bug 1584485 in samba (Ubuntu Trusty) "Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS" [High,In progress] https://launchpad.net/bugs/1584485
<rbasak> slangasek: and, to add to our discussion the other day, perhaps v-f removals should be a routine AA task to add to the list?
<mwhudson> are autopkgtests actually running?
<nacc> mwhudson: i think the queue lengths are still huge at least for amd64/i386
<mwhudson> nacc: yeah, they are suspiciously similar to the queue lengths when i went to bed
<nacc> mwhudson: iiuc, there might be some issues with one of the infra pieces, but i'm honestly not sure
<ginggs> the amd64 is moving, earlier it was on the libs, now it's  down to open-vm-tools, openafs, etc.
<ginggs> ^ queue
<ginggs> that's still on the tests triggered by glibc
<mwhudson> ginggs: oh ok, i guess i'll just be patient then :)
#ubuntu-devel 2016-12-09
<ophuk> Where can I find information on the automated tests Ubuntu runs on a kernel?
<sarnold> ophuk: http://autopkgtest.ubuntu.com/packages/linux
<sarnold> ophuk: https://git.launchpad.net/qa-regression-testing/tree/scripts  kernel*
<ophuk> sarnold, thanks
<ophuk> I might have a few more questions if you guys don't mind
<ophuk> Is there a way to run these tests locally?
<sarnold> ophuk: you're welcome :)
<sarnold> ophuk: the kernel's special, so.. "maybe"? :) here's the wiki on how to use adt-run to run the autopkgtests by hand http://packaging.ubuntu.com/html/auto-pkg-test.html
<sarnold> here's the description of how the automated thing is hooked up https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure (way more work)
<ophuk> sarnold, lol. Yes it is. Unfortunately at work we have this old kernel with some third party thing and we had to manually patch for dirty cow:(
<sarnold> the qa-regression-testing there is .. potentially entangled with a bunch of other things. _probably_ you can just run "cd scripts ; ./make-test-tarball kernel " then follow the directions... copy it to a vm, unpack, and probably ./install-packages ./script-kernel or something like that...
<sarnold> ophuk: ouch
<ophuk> hmmm, possibly
<sarnold> ophuk: be sure to patch for this thing too, it's got a one-shot-run exploit as well https://www.ubuntu.com/usn/usn-3151-1/
<ophuk> yeah. We're working on upgrading to a newer version but who knows when that will be
<tsimonq2> Debian bug 791040
<ubottu> Debian bug 791040 in src:freehdl "freehdl: library transition may be needed when GCC 5 is the default" [Important,Open] http://bugs.debian.org/791040
<tsimonq2> Hmmmmmmmmm
<tsimonq2> slangasek: Thanks many for feedback regarding freehdl, that's why I think it's a good idea to subscribe the last uploader in Ubuntu to these sort of bugs! :)
<sarnold> xnox: does the archive re-org mean 'cppunit' (in universe in newer releases) can be run during the build for packages in main? :)
<tsimonq2> pitti: Having problems with systemd-resolvd. I ended up having to manually change my DNS nameserver in /etc/resolv.conf to be able to access major things like Tweetdeck and the CSS for GitHub...
<tsimonq2> pitti: Pinging because I *never* had this problem before, and it's a DNS one...
<sarnold> note that systemd-resolved has an insanely confusing relationship with /etc/resolv.conf -- in one mode systemd-resolved is a consumer, and in the other mode, systemd-resolved populates it for other things with their own resolvers to consume
<tsimonq2> ... /o\
<tsimonq2> sarnold: Looks like the former of which Failed Miserably.
<tsimonq2> sarnold: Because I had to do it's job... :P
<tjaalton> sheesh, the tests can take an eternity to run.. or is there an issue with the CI?
<pitti> tjaalton: the "issue" is that it's still catching up with glibc and there was a whole new KDE upload too
<pitti> see the queues on /running
<pitti> tsimonq2: mind filing a bug with the details? (server/NM, journal, contents of resolv.conf, your network config)
<pitti> tsimonq2: with that level of detail I'm afraid I can't help
<tjaalton> pitti: hah, ok.. i'll check again next week :P
<xnox> sarnold, yes
<xnox> sarnold, it also means that header only boost libraries leak into main abi =)
<xnox> tedg, /usr/bin/ld: cannot find -lpthreads
<xnox> fun
<sarnold> xnox: I'm going to pretend I didn't hear that bit :) and leave it to do ko to cope...
<Unit193> pull-lp-source is boarked.
<infinity> Unit193: Works for me.
<Unit193> infinity: Yes sorry, I did a thing that made it hit dde.debian. :3
<Unit193> Basically, stupid user thought another service disappeared.
<Unit193> (FWIW: pull-lp-source: Error: Unable to retrieve package information from DDE: http://dde.debian.net/dde/q/udd/dist/d:ubuntu/r:zesty/p:certbot/?t=json (<urlopen error [Errno -2] Name or service not known>)  )
<nacc> any AA able to help process icingaweb2 and zendframework in the new queue? context is LP: #1593024
<ubottu> Launchpad bug 1593024 in zend-framework (Ubuntu) "Unblacklist and sync zendframework 1.12.18+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1593024
<Saviq> pitti, hey, have you heard of issues with resolved and go programs? http://rclone.org/ errors out with http://pastebin.ubuntu.com/23602655/ when 127.0.0.53 is in resolv.conf - it's fine when I replace it with my real NS
<pitti> Saviq: no, haven't heard; does dig @127.0.0.53:53 drive.amazonaws.com do the same?
<pitti> err, without the :53 of course
<Saviq> pitti, no, that works fine, I wonder if it's because how it was compiled (building my own now to see)
<pitti> Saviq: AFAIK our go compiler uses NSS, but upstream's doesn't, so it should just use straight DNS on resolv.conf
<pitti> i. e. dig @127.0.0.53 should be pretty much equivalent
<Saviq> pitti, FWIW, rebuilding my own made it work, I'll report the issue upstream
<pitti> Saviq: so that might actually be Ubuntu vs. upstream Go compiler behaviour (NSS or not)?
<Saviq> pitti, yeah sounds like it
<Saviq> depends on what rclone uses to build their bins
<pitti> Saviq: so it seems their way of a DNS query looks slightly different to glibc's or dig's, and that and resolved don't understand each other
<Saviq> pitti, the error msg actually suggests it couldn't even find 127.0.0.53
<pitti> Saviq: hm, that's not how I interpret that error message
<Saviq> pitti, yeah, could be interpreted both ways...
<Saviq> should probably ask resolved to log requests to see if it even gets asked
<pitti> Saviq: you can, start it in verbose mode
<pitti> Saviq: this should then also tell you what it's trying to query/forward and where things go haywire
<pitti> Saviq: sudo systemctl stop systemd-resolved
<pitti> Saviq: sudo SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-resolved
<Saviq> pitti, yup, already looking at the log
<Saviq> pitti, huh Â¿? http://pastebin.ubuntu.com/23602749/
<Saviq> so it says it replied, wonder if the CNAME/DNAME resolution makes the difference?
<pitti> dannf: manual test run worked \o/
<dannf> pitti:  :)
<pitti> Laney: ^ arm64 autopkgtest run on bos01
<dannf> pitti: shall i try one myself?
<pitti> we don't have custom images yet, so test runs will be slow, but that's fine for testing and manual requests
<pitti> dannf: not yet, setting up the worker now; this was just a manual "call autopkgtest on the infra" run
<dannf> *nod*
<pitti> dannf: (still having something else half-committed in the pipe, let me finish that first)
<Laney> pitti: nice!
<Laney> what changed?
<pitti> Laney: nothing really -- the reboot problem already got fixed a while ago, and I just re-verified that everything is okay
<pitti> Laney: dannf and I just had a quick meeting about the roadmap
<pitti> Laney: so the idea was to start one arm64 worker now but not enable the arch in britney yet
<pitti> Laney: so that we can issue manual test requests, but only enable it in p-m once we have the capacity
<pitti> Laney: actuall, the existing bos01 workers will take care of it, just adding to "architectures ="
<slangasek> rbasak: samba removed from xenial-proposed
<Laney> pitti: right - is there more capacity planned?
<smoser> pitti, https://blueprints.launchpad.net/ubuntu/+spec/boot-time-optimization
<pitti> Laney: yes, it is (that was dannf's side)
<smoser>  [pitti] Builds a cloud image and injects package: DONE
<Laney> neat
<smoser> ^ ? where can i learn more info on that ?
<pitti> smoser: see the whiteboard, it points to the script
<dannf> Laney: yeah - i think i know what hw to purchase, will try to get it approved. i'll keep you in the loop
<Laney> okay!
<smoser> pitti, so you "Determining which binaries of source %(src)s are installed and have a new version...'"
<smoser> but then what do you do with that info ?
<smoser> seems like you should exit if its empty ? ie, you're basically only updating the image if that is inside, right ?
<pitti> smoser: see line 77, it then installs these binaries
<smoser> but if its empty
<pitti> smoser: right, good point; "apt-get install -y" succeeds and does nothing, I had expected it to error out with something like "missing package arg"
<smoser> i guess apt does "right" thing
<pitti> no, there's little point in succeeding then
<smoser> well, it depends on what you want.
<smoser> if its not already inside, then essentially you are just adding -proposed
<smoser> which i thought maybe you were desiring
<pitti> smoser: well, in theory this Should Not Happenâ¢ as we would only practically call it for packages that actually are in -proposed
<pitti> but there could be some corner cases
<pitti> like, binaries are only available on one architecture
<pitti> then the test would run in vain
<pitti> it also should not fail as that update doesn't regress boot speed
<pitti> but would be nice to succeed fast
<smoser> right. yeah, maybe exit SOME_NON_ZERO if not present
<smoser> and handle that
 * smoser is happy you used mount-image-callback :)
<pitti> smoser: handling exit code is not actually all that simple as this all just gets written into m-i-c's stdin
<smoser> well, sure it is
<smoser> it will exit with whever you told it to in the python popen
<pitti> and I want its stdout to stay on the real stdout instead of capturing it
<pitti> smoser: ah, good
<pitti> smoser: so [ empty ] && exit 99 will reflect in img_shell.wait()
<pitti> ?
<smoser> i think so , yeah.
<pitti> and I can then pass through m-i-c's exit code to the caller of that script
<smoser> i mean popen stuff asside. moujnt-image-callaback will exit with the program's return code
<pitti> nice
<pitti> ok, I'll add that
<pitti> smoser: so I'll define a "magic" exit code that means "nothing to do", like "10"
<rbasak> slangasek: thank you!
<pitti> smoser: and then it would not upload the image either
<tsimonq2> pitti: Will do a bit later.
<nacc> stgraber: do you mind approving the zendframework binaries now that they are built? it's showing in https://launchpad.net/ubuntu/zesty/+queue
<nacc> tjaalton: is dogtag-pki's autopkgtest issues on your plate? it's holding tomcat8 in -proposed, afaict
<tjaalton> nacc: tomcat 8.5 broke tomcatjss & dogtag
<nacc> tjaalton: ok, it did start failing before 8.5
<nacc> tjaalton: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/s390x/d/dogtag-pki/20161109_055803_e3940@/log.gz
<nacc> taken from: http://autopkgtest.ubuntu.com/packages/d/dogtag-pki/zesty/s390x
<pitti> dannf, Laney:
<pitti> http://autopkgtest.ubuntu.com/packages/gzip/zesty/arm64
<dannf> pitti: :)
<pitti> dannf: 10min 9s overhead, 1s actual test
<Laney> nice, but also eek
<dannf> pitti: yeah - is that container creation / other I/O?
<pitti> Laney: instances take a while to boot, but most of that overhead really is due to not having an autopkgtest specific iage
<pitti> thus this needs to install the full -generic kernel, purge cruft, dist-upgrade and so on
<pitti> actually no, I did't call this with setup-testbed
<pitti> nevermind, I did
<pitti> setup-testbed took 5 mins
<pitti> dannf: no, this isn't container, it's full nova instance
<dannf> ah, i see
<tjaalton> nacc: can't check, but did amd64 pass before
<tjaalton> ?
<pitti> dannf: Laney is planning some optimization to run tests in lxd containers (on all arches) that don't need a full VM (i. e. 99% of our tests)
<pitti> but that's independent
<nacc> tjaalton: yes, also a regression there too, i think
<nacc> tjaalton: http://autopkgtest.ubuntu.com/packages/d/dogtag-pki/zesty/amd64
<Laney> pitti: you making an adt image?
<pitti> Laney: not worth the trouble yet; hang on
<nacc> passed with 10.3.5-5, started regressing with java-atk-wrapper/0.33.3-11 maybe?
<tjaalton> nacc: hmm ok
<tjaalton> my browser is frozen atm, I'll check later :)
<nacc> tjaalton: thanks -- was just noticing the tomcat8 gating in z-p
<tjaalton> anyway, dogtag upstream is finally looking into it, but most likely won't get it fixed before xmas which would be the deadline for stretch (plus 10day migration delay)
<tjaalton> so apart from removing tomcatjss & dogtag I don't see a way to unblock tomcat8
<tjaalton> oh and freeipa too
<nacc> tjaalton: ok, i guess it's not a huge deal, as the SRUs i need to do are all fixed in the version in of tomcat8 that made it into the archive before the dogtag regression
<nacc> tjaalton: just sort of odd to see :)
<pitti> dannf, Laney: bug 1648810
<ubottu> bug 1648810 in britney "Enable arm64 autopkgtesting" [Undecided,New] https://launchpad.net/bugs/1648810
<tjaalton> nacc: yeah that was a bad timing to push 8.5 to debian without checking that rdeps would still build..
<nacc> tjaalton: ack, np -- thanks for confirming!
<shadeslayer> Hey, does anyone know how long it takes for the supported seed to get updated and where I can check the current list that launchpad knows ?
<cjwatson> shadeslayer: the supported seed is in revision control and developer-managed, so I suspect you must be asking about something related but different
<cjwatson> shadeslayer: but I don't know exactly what, so can you rephrase your question?
<shadeslayer> cjwatson: is there a way to check if the changes we made were deployed ?
<shadeslayer> cjwatson: would seeded-in-ubuntu work for the supported seed?
<shadeslayer> cjwatson: oh ok it does work
<shadeslayer> hm there was a thing to check if you had upload privs to a package too
<shadeslayer> ubuntu-upload-permission!
<shadeslayer> cjwatson: ref http://bazaar.launchpad.net/~kubuntu-dev/ubuntu-seeds/kubuntu.zesty/revision/1349 , ubuntu-upload-permission -t breeze-plymouth  does not list the kubuntu team
<cjwatson> shadeslayer: OK, so you're asking about upload permissions
<shadeslayer> yep
<cjwatson> shadeslayer: I didn't know about ubuntu-upload-permission; edit-acl in lp:ubuntu-archive-tools is the thing I use, though they're probably equivalent for this purpose
<shadeslayer> :D
<cjwatson> shadeslayer: anyway, translating seeds into upload permissions is a manually-gated process controlled by ~developer-membership-board
<shadeslayer> aha
<shadeslayer> clivejo: ^^
<cjwatson> I already told clivejo the same thing
<shadeslayer> oh I wasn't aware
<shadeslayer> well there you go, someone needs offer chocolates to the dmb
<shadeslayer> ;)
<shadeslayer> cjwatson: thanks for the clarification <3
 * shadeslayer goes back into his hole to swear at binutils and dpkg-dev some more
<acheronuk> shadeslayer: yes, we are still waiting for that seed change to get translated to our packageset by the DMB
<shadeslayer> ack
<acheronuk> + you won't see the source name in there, just the 1st listed binary that it produces
<acheronuk> I had the SAME confusion very recently ;)
<ricotz> pitti, hi, is there another network-manager upload planned?
<ricotz> (it could use a rebuild against valac 0.34.4)
<pitti> ricotz: not from my side; feel free to just do a no-change upload, although autopkgtest queues won't let this land anytime soon anyway
<ricotz> pitti, I see, although I can't upload things ;)
<pitti> Laney: I landed the "huge queues" britney part now; should be reasonably safe
<pitti> Laney: I'll have a look at it this evening just in case, though
<pitti> but I'm off for a bit, sprint just ended and socializing/fresh air and such
<Laney> pitti: nice, happy airing
<pitti> Laney: will cd ~ tomorrow, so still Sevilla tonight
<pitti> it's not like I desperately crave to move from warm Sevilla to icy Augsburg :)
<Laney> pitti: I just moved things to -huge
<Laney> let's see if that works
<Laney> they seem to be bytes instead of strings
<Laney> hope that doesn't matter Â¬_Â¬
<Laney> it did matter, and I accidently broke huge/amd64 while trying to recover it :P
 * Laney tries again to get those back
<Laney> a protip is: don't put things in a queue while you're looping over it ...
<Laney> should be recovering now
<pitti> Laney: ah, nice -- how did you do this, delete all jobs and the britney pending cache?
<pitti> Laney: or direct AMQP surgery?
<wxl> um, anyone know where i can find the iconv library? we seem to have derivatives of it (e.g. libiconv-hook) but no iconv itself?
<tsimonq2> pitti: I believe this is it: https://github.com/systemd/systemd/issues/3826
<tsimonq2> !info libiconv
<ubottu> Package libiconv does not exist in wily
<tsimonq2> !info libiconv-dev zesty
<ubottu> Package libiconv-dev does not exist in zesty
<wxl> if you think i haven't searched you got another thing coming. i'm just surprised
<wxl> https://www.gnu.org/software/libiconv/
<tsimonq2> !info iconv wily
<ubottu> Package iconv does not exist in wily
<tsimonq2> O__o
<wxl> oh heh maybe it's in gnulib
#ubuntu-devel 2016-12-10
<cjwatson> wxl: libiconv is typically only needed on non-glibc systems; iconv() is built into glibc
<cjwatson> no point in an external library when the base C library has it
<Laney> pitti: amqpification, copied the requests from one queue to another
<Laney> deleting would have been easier
<mapreri> we (src:diffoscope devs) would like diffoscope autopkgtest to run every time one of its optional dependencies (aka "Recommends") are updated too, as they affects some parts of testsuite as well.  Do you think manually messing with the Testsuite-Triggers field can be accepted?
<mapreri> pitti: opinions on â ?
<tsimonq2> pitti: Here's a relevant Launchpad bug. :) bug 1647031
<ubottu> bug 1647031 in systemd (Ubuntu) "systemd-resolvedâs 127.0.0.53 server does not follow CNAME records" [Undecided,Confirmed] https://launchpad.net/bugs/1647031
#ubuntu-devel 2016-12-11
<Bluefoxicy> Chromium browser is providing a Certificate Failed error for amazon.com and penfed.org due to certificate transparency failure.  Firefox isn't.  Confirm?
<dobey> Bluefoxicy: works fine here. there was a bug in one update, but has since been fixed
<Bluefoxicy> dobey:  nod.  Something about extended validation?
<Bluefoxicy> dobey:  i don't have any updates and restarting chrome doesn't fix it on yakkety.  Maybe my update channel is behind.
<tzero> hello, I'm trying to package a python3-based utility, following https://wiki.debian.org/Python/Pybuild#debian.2Frules, that should consist of a python library, some launcher scripts in $PATH, and miscellaneous files. Does PYBUILD_NAME correspond to the python module name? The resultant packages from `pdebuild` only contain things installed to /usr/share/doc
<ScottK> It does.
<dobey> Bluefoxicy: don't know about chrome. was fixed in chromium, at least the version that's in the archive on 16.04
<dobey> Bluefoxicy: google chrome itself might not be fixed. it's because some certs aren't complying with a transparency requirement
<Bluefoxicy> dobey: 'Version 53.0.2785.143 Built on Ubuntu , running on Ubuntu 16.10 (64-bit)'
<Bluefoxicy> current ubuntu 16.10 repo version
<Bluefoxicy> <ducasse> ikonia: i get the same thing with amazon in chromium
<Bluefoxicy> confirmed in #ubuntu for 1 user, but that channel is 1600 idlers
<Bluefoxicy> <ducasse> tomreyn Bluefoxicy seems this bug has cropped up again, there are several comments on that bug report from within the last few hours
<Bluefoxicy>  https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1641380
<ubottu> Launchpad bug 1641380 in chromium-browser (Ubuntu) "chromium-browser: ERR_CERTIFICATE_TRANSPARENCY_REQUIRED for Symantec certs" [Critical,Fix released]
<Bluefoxicy> so much for FIXRELEASED
<dobey> 53.0.2785.143-0ubuntu0.16.04.1.1257 <- is what i have
<dobey> weird, since it's same version
<dobey> Bluefoxicy: anyway, don't know. ask in #ubuntu-desktop perhaps
<Bluefoxicy> dobey:  the general consensus is the bug is not fixed
#ubuntu-devel 2017-12-04
<doko> jamespage: alembic is stuck in -proposed due to component mismatch
<jamespage> doko: ah - yes - noted last week on my list to raise a mir/review that for a delta
<jamespage> doko: just had some pxc security updates to clear first (now ready for security team review)
<jamespage> doko: managed to drop a bit of required delta - fixing that right now
<cpaelzer> when run in autopkgtest I see a set of "tr: write error: Broken pipe" but when logging into the very same guest and runnign again it does not show up
<cpaelzer> does the autopkgtest execution have soemthing that comes to your mind that could cause this?
<cpaelzer> my login is ssh as reported by autopkgtest on --shel--fail
<cpaelzer> I'm trying to debug the tests atm, but lacking a way to reproduce this is hard, so if this might be a known issue to anybody let me know
<cpaelzer> if anybody wondered about my question above - I have the solution - shell fragments like the following are the reason
<cpaelzer> tr -dc "[:alpha:]" < /dev/urandom | head -c 6
<cpaelzer> common at least on search engine hits (https://gist.github.com/paulomcnally/7209bad52c724d19bdd029b4a6631265) and were used in a packages test
<cpaelzer> but the tl;dr the first read is more or less unlimited, which might eventually cause the issue
<cpaelzer> something like "head -c 100 /dev/urandom | tr -dc '[:alpha:]' | head -c 6" works better
<sarnold> cpaelzer: the downside to the second one is that there's a (very small) chance that it won't succeed once in a while
<cpaelzer> sarnold: it might be shorter
<sarnold> right
<cpaelzer> sarnold: but I doubt it will be zero
<cpaelzer> shorter is fine for me
<sarnold> oh okay
<sarnold> sometimes shorter is catastrophic :)
<cpaelzer> and one can increase the first number to be "more safe"
<cpaelzer> hehe
<sil2100> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, jbicha, micahg, rbasak, sil2100: DMB ping.
<kirkland> doko: thanks;  I've merged your debian/control fixes upstream
#ubuntu-devel 2017-12-05
<doko> LocutusOfBorg: what an upload to trigger som hunderd unnecessary autopkg tests ... http://launchpadlibrarian.net/348100722/python-numpy_1%3A1.13.3-1ubuntu1_1%3A1.13.3-1ubuntu2.diff.gz
<FourDollars> Hi, does anyone know how to make http://archive.ubuntu.com/ubuntu/dists/xenial-proposed/main/installer-amd64/current/images/cdrom/debian-cd_info.tar.gz manually?
<cjwatson> FourDollars: It's one of the many outputs of building the debian-installer source package (in the correct context, i.e. with the right things in /etc/apt/sources.list)
<FourDollars> cjwatson: Is there any guide for building the debian-installer source package?
<FourDollars> cjwatson: I am verifying some grub patch for https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1734278 so I need to make grubx64.efi for the USB stick.
<ubottu> Launchpad bug 1734278 in grub2 (Ubuntu Bionic) "Grub2 cannot boot up when 8254 time function disable" [Critical,Triaged]
<FourDollars> cjwatson: I found the grubx64.efi in grub2_2.02~beta2-36ubuntu3.14_amd64.tar.gz doesn't boot into the GRUB menu.
<FourDollars> cjwatson: It just showed grub prompt.
<cjwatson> FourDollars: It's a source package - you build it ...
<cjwatson> E.g. sbuild
<FourDollars> cjwatson: OK. Got it. Let me try to build debian-installer. Thx.
<cjwatson> (Though it's probably better to unpack it, make sure you're in a chroot with sources.list matching what you want to end up in the installer images, satisfy build-deps, and then use the make targets in build/ directly - if you just run 'make' there you'll get a list of possible targets)
<cjwatson> (otherwise you end up building half the world that you don't care about)
<FourDollars> OK
<FourDollars> Failed to obtain signed grub image, despite $SIGNED_IMAGE being set.
<FourDollars> config/x86.cfg:40: recipe for target 'x86_grub_efi' failed
<cjwatson> I don't remember the details - you'll need todig
<cjwatson> *to dig
<FourDollars> OK
<Unit193> LocutusOfBorg: Speaking of, did you see my link the other day?  https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/8538825/+listing-archive-extra
<LocutusOfBorg> Unit193, nope
<LocutusOfBorg> looking now
<LocutusOfBorg> do you want an upload?
<Unit193> If it looks right, sure do!
<LocutusOfBorg> .
<Unit193> Danke.
 * LocutusOfBorg renews his whyyounocoredev?
<Unit193> LocutusOfBorg: I need to file the MOTU application, have to find a meeting that works timewise.
<LocutusOfBorg> oh you still no motu?
<Unit193> Right, silly meetings. :/
<Unit193> They're all scheduled pretty early.
<FourDollars> cjwatson: Thx a lot. I have generated debian-installer-images_20101020ubuntu451.17_amd64.tar.gz successfully.
<cjwatson> FourDollars: good stuff
<sil2100> sergiusens: hey! Wanted to know if there's any progress on the artful classic snaps issue in snapcraft?
<sergiusens> sil2100 we are building the infra for it; it should be soon; might go faster once snapcraft 2.35 is accepted and gains some miles in the archive as it is our baseline to know if things aren't going to break bad :-)
<sil2100> sergiusens: hah, ok, I see it's ready for -updates, probably no one pushed it through yet because of the ADT regressions, but from a quick look I see those are the always-failing tests anyway
<sil2100> sergiusens: let me pick it up after I'm done with landscape
<sergiusens> sil2100 oh, 2.35 in xenial is what we care about for the base; 2.35 for artful and bionic fail still due to the exact thing you want fixed ;-)
<jamespage> doko: I dropped a load of python-* bits from the server seeds; they where mostly openstack related, and should have been left as depends of other seeded packages rather than being directly included
<sergiusens> it wouldn't hurt to get them in the archive, it won't be any less broken; I am just battling reruns of snapcraft adt for armhf due to DNS timeouts, it has been almost 10 days of clicking "rerun"
<jamespage> doko: however you won't get any demotion candidates for now
<jamespage> doko: I've left moin and tickcount for other general review/opionion
<doko> jamespage: ta!
<ventrical> can anyone help us with this - But I am talking about ubuntu-unity-desktop and ubuntu-settings package from ppa. How can we move those to universe? Usually we need to go through MOTU where we need to find a member of Motu who can upload to archive, but in this case can we ping Martin? He can review it and has upload access to archive.
<ventrical> we need to move ubuntu-unity-desktop and ubuntu-setting from the ppa: https://launchpad.net/~unity7maintainers/+archive/ubuntu/unity7-desktop
<ventrical> and put them in universe.. but I do not have upload privy.
<ventrical> oh yes.. goodmorning all from Canada :)
<sil2100> sergiusens: released xenial and zesty, looking into the artful story - let me see if the only failures are as per the current artful+ breakage and then maybe release
<ypwong> cyphermox, i want to follow up bug 1734278, is it possible to update the file mentioned in #4 as well?
<ubottu> bug 1734278 in grub2 (Ubuntu Bionic) "Grub2 cannot boot up when 8254 time function disable" [Critical,Triaged] https://launchpad.net/bugs/1734278
<cyphermox> ok
<jbicha> ventrical: file a bug and subscribe ~ubuntu-sponsors see https://wiki.ubuntu.com/SponsorshipProcess
<ventrical> my mistake then. I though that we went through this or that it was taken care of.
<ventrical> uh.. I had left a message with WillCooke and he was to talk with seb so I will wait till after TB but study the link in the meantime.
<ventrical> jeremy .. btw .. could you look at this - https://code.launchpad.net/~dale-f-beaudoin/unity-control-center/update_distro_series/+merge/334637
<ventrical> please and thankyou
<juliank> ventrical: "ventrical <ventrical@ventrical-MS-7798>  Sat, 02 Dec 2017 21:03:28 -0500" - that's not a world-routable email address (nor is it a real name, I think that does not look good, but meh)
<juliank> Not to mention the version change in there
<ypwong> cyphermox, thanks for replying. Wonder if you have a schedule in mind when the fixed package can be uploaded?
<cjwatson> I think consistent pseudonyms can be OK if that's actually what you want to achieve, but definitely needs a proper email address
<juliank> Indeed
<ventrical> ahhh.. thanks..
<ventrical> i entered in a comment. So I can't edit the diffs in launchpad eh?
<jbicha> I think the email issue is a problem with your bzr and devscripts config
<ventrical> the pseudonym was generated by ssh
<ventrical> jbicah  I could not find that file!
<ventrical> you had emailed me about that .. couldn't find  it..
<juliank> You'd edit your branch and push it
<jbicha> maybe someone else can help you, I remember trying once but maybe I wasn't able to explain things well or maybe I didn't understand the problem well enough
<juliank> YOu just need to set the DEBEMAIL environment variable I guess
<ventrical> i appreciate all your help jbicha .. it is most lilely my misunderstanding
<jbicha> because you have two problems, the changelog entry and the bzr commit itself doesn't have the right email address format
<juliank> for example, I have DEBEMAIL=juliank@ubuntu.com EMAIL="Julian Andres Klode <juliank@ubuntu.com>"
<juliank> (exported in my .profile or my .bashrc)
<ventrical> yes . jeremey .. we went through that .. could not find ~devscripts I think I sent you a kite about it..
<ventrical> so do I have to delete that branch and try again?
<jbicha> no, you can use bzr push --overwrite
<jbicha> well the overwrite might be unnecessary, depends on how you are fixing the problem
<ventrical> just to  get my email right
<cyphermox> ypwong: today, hopefully. it's what I'm working on
<juliank> ventrical: Also get the version number right
<juliank> While you're already at it anyway
<juliank> 15.04.0+17.10.20170930-0ubuntu2 should stay that and not get a 3 at the end
<jbicha> juliank: have you ever used bileto?
<ventrical> :) .. I hope you guys don't hold it against me at the TB :)
<juliank> jbicha: No.
<ventrical> jermey mentioned bileto - i decided to learn bzr first... looks like I am not doing to well with it :)
<jbicha> before April, all the Unity stuff (that was set up for it) used bileto for merges and publishing to Ubuntu, but it's all optional now
<doko> jamespage: https://bugs.launchpad.net/ubuntu/+source/python-libvirt/+bug/1735393 is still seeded
<ubottu> Launchpad bug 1735393 in python-libvirt (Ubuntu) "server seed seeds Python2 module python-libvirt" [Undecided,New]
<ventrical> ok.. so what command  do I enter into terminal to get this e-mail identifier probem fixed?
<jbicha> juliank: I'll let you handle review
<jbicha> â¦and merge for this unity-control-center proposal if you want
<juliank> jbicha: I don't really have any interest in that, I just did the review because it jumped at me :)
<ventrical> juliank  what file is this in  <juliank> for example, I have DEBEMAIL=juliank@ubuntu.com EMAIL="Julian Andres Klode <juliank@ubuntu.com>"
<juliank> that = merging
<jbicha> well I didn't know if merging and uploading might jump out at you too :)
<juliank> I don't have a local branch of it :)
<juliank> I'm just doing some distractions between writing
<ventrical> hey guys .. I 'll try another method
<cjwatson> ventrical: people keep their default environment variables in various places, but ~/.pam_environment and ~/.bashrc are common
<juliank> ventrical: I just have export DEBEMAIL=... and export EMAIL=... lines in my .profile, but depending on setup, it might also be .bashrc
<juliank> and then source the file or log out and back in again
<ventrical> bashrc ..ok .. lemme see if I can track that one down :)
<cjwatson> (I use DEBFULLNAME='Colin Watson' and DEBEMAIL=cjwatson@ubuntu.com - I wouldn't have expected setting EMAIL to 'name <address>' to work consistently everywhere)
<cjwatson> oh although I see that form is specifically documented in dch(1).  anyway I find my approach clearer :)
<ventrical> what directory do I find bashrc?
<juliank> I don't know, it just works
<cjwatson> ventrical: your home directory.
<cjwatson> and it's .bashrc, not bashrc
<cjwatson> you will have a bad time if you forget punctuation
<juliank> cjwatson: I had various combinations of EMAIL variables, but ultimately landed at this one as it seems to work fine
<juliank> With stuff I had before, some tools had no name
<juliank> or something
<ventrical> .bashrc  ... yes . I have it .. and where do I enter the required data
<juliank> long time ago, and mostly guesswork
<juliank> ventrical: somewhere
<juliank> I have it at the end
<TJ-> ventrical: you should read the "Getting Set Up" section of http://packaging.ubuntu.com/singlehtml/index.html#document-ubuntu-packaging-guide/getting-set-up
<ventrical> im confused .. it si a binary
<ventrical> ok
<juliank> it's not a binary, it's a shell script
<TJ-> ventrical: specifically, the last few sentences entitled "Configure your shell"
<ventrical> uh.. I went through that with seb and dirocks
<ventrical> ok.. configure your shell .. looking at it..
<ventrical> Hey .. 15 years of straight malware removal has affected me eh :)
<ventrical> yes .. a c shell script - "Configure your Shell" in this link  http://packaging.ubuntu.com/singlehtml/index.html#document-ubuntu-packaging-guide/getting-set-up cant seem top find it
<cjwatson> it's there, try searching.
<cjwatson> it is not a "c shell" script, because that would be csh rather than bash
<juliank> csh is hell
<ventrical> ok.. well I am being schooled very well here... :) oh  yes .. found it - config shell script..
<ventrical> ok.. so that wasn't so painful :)
<ventrical> ok.. going to push a new branch then and try it out..
<ventrical> brb
<ventrical> changed to my real name but not my e-mail... <ventrical@ventrical-MS-7798>
<ventrical> ok... going to try my ubuntu member account. sure wish I could solve this. will try a reboot..
<cjwatson> May also be worth checking ~/.bazaar/bazaar.conf
<cjwatson> "bzr config email"
<cjwatson> you can change that with (e.g. in my case):  bzr config email='Colin Watson <cjwatson@ubuntu.com>'
<cjwatson> err sorry, not that
<cjwatson> bzr whoami 'Colin Watson <cjwatson@ubuntu.com>'
<cjwatson> ah well I guess that was useless
<juliank> It's been some time since I last used bzr. But at least I'm approaching git wizard levels :)
<ventrical> reboot didn't work- still have the same message and no e-mail... so i will try my UbuntuMember account
<jbicha> ventrical: see the recent comments at https://irclogs.ubuntu.com/2017/12/05/%23ubuntu-devel.html
<ventrical> yes .. checking that now..
<ventrical> ventrical@ventrical-MS-7798:~$ bzr config email dale_f_beaudoin dale_f_beaudoin@hotmail.com ventrical@ventrical-MS-7798:~$
<ventrical> so it is set right  ..uh .. I'll try dch -i again
<juliank> bzr email setting != dch email setting
<ventrical> dch -i
<ventrical> nope .. it's not working..
<juliank> ventrical: How about you paste your .bashrc on paste.ubuntu.com or similar?
<ventrical> I keep getting ventrical@ventrical-MS-7798:~ in the changelog
<juliank> well no
<ventrical> ok.. well yes... see if I have access..
<juliank> Surely that's your shell prompt
<juliank> your email address does not have :~
<cjwatson> env | grep ^DEB
<TJ-> it's using $USER@$HOST since DEBEMAIL and DEBFULLNAME aren't set
<cjwatson> right, but it won't be putting :~ on the end
<TJ-> ventrical: are you actually using bash ?
<juliank> TJ-: We know that since an hour
<ventrical> just a sec..
<TJ-> juliank: makes me wonder though, if $HOME/.bashrc has the exports in it
<cjwatson> it probably doesn't, but let's see
<juliank> TJ-: That's what I'm trying to figure out .)
<ventrical> I did exactly what the link told me to do -  export DEBFULLNAME="Dale Beaudoin" export DEBMAIL="dale_f_beaudoin@hotmail.com"
<ventrical> appended that to .bashrc
<juliank> ventrical: In two lines?
<ventrical> yes!
<Nafallo> ehrm. DEBEMAIL="Nafallo BjÃ¤levik <nafallo@ubuntu.com>"
<Nafallo> ^-- that works
<juliank> Nafallo: the other one works too
<Nafallo> just the e-mail refused to work for me on 16.04.3 at least :-)
<TJ-> ventrical: answer cjwatson's question re what "env | grep ^DEB" shows
<juliank> ventrical: As I said before, best to paste the .bashrc and the env output (or export output) somewhere.
<ventrical> ok..sec.
<cjwatson> you've also typoed DEBEMAIL as DEBMAIL, judging from the above.  it is really really really important to type things accurately.
<jbicha> ventrical: also your bzr config email is definitely *not* right
<cjwatson> if you consistently make small typos in this sort of thing then you're going to have a lot of problems.
<jbicha> I assume you want something like "Dale Beaudoin <dale_f_feaudoin@hotmail.com>" instead of what you pasted
<ventrical> juliank  ventrical@ventrical-MS-7798:~$ env | grep ^DEB DEBMAIL=dale_f_beaudoin@hotmail.com DEBFULLNAME=Dale Beaudoin ventrical@ventrical-MS-7798:~$
<cjwatson> please don't collapse multiple lines onto one
<cjwatson> if your IRC client insists on doing so then use paste.ubuntu.com instead
<ventrical> cj .. ok  apologies..
<cjwatson> otherwise other people are left trying to work out where the significant line breaks are supposed to go
<juliank> OK, well fix the wrong DEBMAIL -> DEBEMAIL typo and run . ~/.bashrc again :D
<ventrical> my apologies .. please forgive me :)
<ventrical> did I do that ? :)
<cjwatson> juliank: though I don't think it's just that, because we aren't seeing DEBFULLNAME taking effect
<juliank> cjwatson: I think it's not picking that up because DEBEMAIL is not set
<juliank> but I might be wrong
<Nafallo> so if we're talking about devscripts regardless, CHANGELOG=changelog refuse to work. it's still trying debian/changelog :-)
<ventrical> ok .. lemme try that
<Nafallo> any ideas?
<cjwatson> juliank: I don't think so, but maybe
<juliank> Nafallo: pass -c changelog?
<juliank> cjwatson: You seem right
<Nafallo> juliank: that's my workaround ;-)
<ventrical> do I edit in DEBEMAIL on both lines?
<cjwatson> ventrical: please show us the current state of the file first
<juliank> both lines? there should only be one
<ventrical> export DEBFULLNAME="Dale Beaudoin"
<ventrical> export DEBMAIL="dale_f_beaudoin@hotmail.com"
<cjwatson> just the second of those
<ventrical> ok.. gottchya :)
<cjwatson> ventrical: also, does 'env | grep EMAIL' show anything?
<ventrical> sec
<sdeziel> ventrical: you missed the E in DEBEMAIL
<cjwatson> sdeziel: we've sorted that, see above
<juliank> I don't think this channel has been that active in a long time
<sdeziel> hehe
<ventrical> cj shows nothing now
<Nafallo> I don't think DEBEMAIL is sorted yet, fwiw ;-)
<juliank> ventrical: Did you reload the ~/.bashrc with source ~/.bashrc?
 * ogra_ sniffs on Nafallo to see if he is real 
<juliank> or just . ~/.bashrc
<Nafallo> hi ogra_ :-)
<ogra_> \o/
<ogra_> awesome to have oyu back here !
<ogra_> *you
<Nafallo> it was time :-)
<ogra_> :)
<ventrical> bash: /home/ventrical/.bashrc: Permission denied
<cjwatson> you made another typo
<cjwatson> I am nearly certain that you typed simply '~/.bashrc' rather than '. ~/.bashrc'
<ventrical> cj ..ok I entered it your suggest and it did nothing
<ventrical> so I will try again?
<cjwatson> ventrical: yep
<cjwatson> ventrical: in the same shell as the one where you ran that last command
<ventrical> ok
<ventrical> The backup file debian/changelog.dch already exists --
<ventrical> please move it before trying again
<cjwatson> perhaps you already have an editor open in another window
<ventrical> no I do not .. but I can delete the directory and start over again.
<cjwatson> just delete that one file
<ventrical> k , done .. trying again..
<ventrical> whoops .. thats debain/changelog :)
<mdeslaur> doko: I'm stealing your samba merge
<ventrical> dch -i give me a blank nano screen .. so I have to redo this ?
<cjwatson> weren't you working in a bzr branch?
<cjwatson> if so, you should be able to do 'bzr revert debian/changelog' and you'll recover the last committed version
<ventrical> nope ... ok.. I am ging to delete directory unity-control-center and start over .. it's good pratice .. thats for sticking this out with me all of you..
<ventrical> brb
<cjwatson> ok, this is exactly the sort of mistake that revision control is good at helping recover from, so it would be good to use it next time
<ventrical> I agree with you.. I got to learn that .. downloading now ..
<ventrical> ok .. it worked real e-mail is in .. whew.. I'm going to try and finish this up ... thanks so much eh..
<cjwatson> excellent, finally :)
<jbicha> ventrical: what's the output of  bzr whoami
<ventrical> I am right in the process of commit n push  brb
<jbicha> yeah but you need to fix bzr before committingâ¦
<ventrical> ok . sec
<ventrical> jbicha bzr whoami => dale_f_beaudoin dale_f_beaudoin@hotmail.com
<ventrical> is that still busted
<juliank> seems like it
<jbicha> yes your email address should be in <> and you probably want to use a real name at the beginning
<juliank> Should be Normal Name <my@email.address>
<ventrical> thats the way it comes up in the diff - ok .. so i am going to push a new branch on this
<juliank> ventrical: in the diff is your changelog email, not your bzr email
<jbicha> ventrical: try running a command like this:
<jbicha> bzr whoami "Dale Beaudoin <dale_f_beaudoin@hotmail.com>"
<ventrical> ok
<ventrical> nothing happened
<jbicha> good, now run bzr whoami to make sure it's correct
<ventrical> oh .. here  it worked..  https://code.launchpad.net/~dale-f-beaudoin/unity-control-center/version_change/+merge/334774
<ventrical> bzr whoami Dale Beaudoin <dale_f_beaudoin@hotmail.com>
<jbicha> good, bzr is fixed now
<ventrical> ok.. thanks jbicha .. i see your point now..
<jbicha> you fixed the changelog but did you want to change the version to add LTS?
<jbicha> you don't need to submit new merge proposals, just push to the same branch
<ventrical> uh .. ? so a new thin now  :) yes.. an dso how to?
<jbicha> what is dso?
<ventrical> and so.. how to? :)
<ventrical> typos
<ventrical> how to change the version to LTS
<ventrical> to ass LTS
<ventrical> geesh ..
<jbicha> the same way you changed it to 18.04, just add some extra letters ;)
<ventrical> to ADD LTS
<ventrical> now you tell me .. bwhahahaha...
<ventrical> lunch
<jbicha> well we did mention it earlier ;) https://code.launchpad.net/~dale-f-beaudoin/unity-control-center/update_distro_series/+merge/334637
<ventrical>  i was just kidding ..  :) yes. my bad , of course..
<ventrical> big thanks!! to all who helped me out with bzr e-mail problem
<mdeslaur> infinity, kees: meeting now
<Nafallo> stgraber: would there be an ubuntu channel about container stuff somewhere? I bet you'd be the best person to have clue :-)
<stgraber> Nafallo: not really, there are knowledgable people in #ubuntu-server, otherwise for LXC/LXD we also hangout in #lxcontainers (which is not Ubuntu specific but the general LXC/LXD support channel)
<jbicha> infinity: this looks like a fun team: https://launchpad.net/~disgusting-and-terrible-development
<slangasek> "There are no branches related to Disgusting and terrible, but there doesn't seem to be a better way in Launchpad today."
<juliank> oh oh what are they up too?
<slangasek> juliank: warez
<slangasek> does that word still have meaning? or am I dating myself by using it
<juliank> slangasek: can we find some teen to ask?
<juliank> I heard of it back in the last decade
<Unit193> slangasek: People still join IRC and say 'Ciao\n!list'
<Unit193> !list
<ubottu> Unit193: No warez here! This is not a file sharing channel (or network); read the channel topic. If you're looking for information about me, type Â« /msg ubottu !bot Â». If you're looking for a channel, see Â« /msg ubottu !alis Â».
<cyphermox> ubottu's turn to date himself.
<ubottu> cyphermox: I am only a bot, please don't think I'm intelligent :)
<Unit193> It's very strange, but people still seek it over IRC..
<juliank> Back in the mid ~2000s people were downloading stuff on IRC
<juliank> I think they all switched to usenet?
<juliank> And then bittorrent or whatever?
<juliank> Since the late 2007s, people are doing a lot of streaming of videos on dubious sites
<juliank> um, 2000s
<juliank> I think video via Kodi is the latest hype?
<Unit193> Is there a socially acceptable way to upload something to Ubuntu, where the next Debian upload will autosync?  Eg, I'd normally do -0ubuntu1, but I'd like the added benefit of an autosync (and -0build1 seems socially unacceptable and not what 'build' is for.)
<Unit193> 0fakesync1 comes tomind, buut..
<slangasek> Unit193: either -0build1 or -1~build1 should have the autosync behavior
<juliank> but technically it's not a rebuild
<slangasek> Unit193: you should certainly make sure you have a matching orig.tar.gz if you do this
<juliank> Not that there is a better solution :)
<Unit193> slangasek: Indeed, the tarballs will certainly match, and the delta otherwise is http://paste.openstack.org/show/PTajaBLuv168daE2P33d/
<juliank> just typo it as -0buntu1?
<juliank> ;)
<slangasek> how do you know they will certainly match if it's not yet uploaded to Debian? :)
<Unit193> juliank: Ahaha!!  Great solution!
<Unit193> slangasek: Release tarballs since it has autotools, upstream doesn't re-release, Debian maintainer is sane, I'm part of the packaging team.
<slangasek> ok
<juliank> Unit193: Are you uploading in Debian too?
<Unit193> juliank: No.
<juliank> OK, otherwise I'd have suggested uploading to exp and syncing that
<Unit193> VCS has it targetting unstable.
<Unit193> juliank: Remember, I'm not a DD, so have to wait on sponsorship.  I have done all the work in Debian so the Ubuntu delta is literally d/changelog: "* Pull from Debian unreleased vcs."
<juliank> Unit193: Maybe you should be a DD? :)
<Unit193> juliank: Well yes, that's a goal.  Pretty fresh DM, and have to get the signed key thing figured out. :)
<juliank> Oh well, signing key with a pseudonym is probably not eas<y
<juliank> Given the focus on ids
<Unit193> juliank: I've got 2 DD sigs, but as such Debian keyring maint restrictions are higher (I had to have the 2 for DM alone.)
<juliank> Well, for pseudonyms, my policy would be meeting in at least two different occasions where the pseudonym is the same and knowledge of previous online discussions :)
<juliank> How do others handle that?
<juliank> It's basically the "hey, I've seen you at a previous debconf" debconf check :D
<Unit193> (Not really sure I should derail #ubuntu-devel with this, but nevertheless.)  So far what I've done is scanned my driver's license, gpg detach signed it, then shown the DD mine in person as well as have him compare to the scanned version.
<juliank> interesting
<Unit193> I've never been to debconf, this last one was likely the closest it'll ever be.  Someone happened to be in my state for some reason so we met up, then at OLF I met nhandler.   Outside of those two meetups, I've never met another DD.
<slangasek> DAM requirement for pseudonymous DDs is that the DAM has your real name on file
<slangasek> no burning the project and burning your pseudonym with it ;)
<Unit193> Pretty sure I wouldn't want to, I use it everywhere.
<slangasek> like any good foreign agent would
<Unit193> paultag already explained that if I was a gov agent, I'd have a bullet proof identity. ;)
<slangasek> of course! because government agents know that anything less is insufficient for infiltrating Debian
<Unit193> Only reason I'd hesitate about letting DAM know is that I know how much my name is worth to me, it's pretty worthless to them so "letting it slip" hardly matters.
<Unit193> slangasek: Thanks for the discussion.
<slangasek> :)
<tsimonq2> slangasek: Catching up on backlog from above, I remember the term "warez" coming up when I was in either elementary or middle school in one of those "hip" 90s infomercials the guidance counselors showed us about the "dangers of the internet" and the "takeaway" was "don't talk to strangers online because they're automatically pedophiles and rapists"
<tsimonq2> I really hated those :/
<tsimonq2> Anyways, hi, back on topic :P
<slangasek> I... what?
 * teward is confused
<tsimonq2> Warez, you guys were talking about warez, and I had flashbacks to the horrible videos they showed in middle school :P
 * tsimonq2 knows that probably came out jumbled ;P
<sarnold> did they subject you to this one? https://www.youtube.com/watch?v=up863eQKGUI
<cjwatson> Unit193: how much my name is worth> aha, got it, you're an occult magician and names are power :-)
<slangasek> there were 90s videos about this?
<cjwatson> awesome.
<slangasek> cjwatson: ahaha
<sarnold> cjwatson: lol
<Unit193> cjwatson: Ahaha!  You made me chuckle, sir.
<tsimonq2> sarnold: Actually they had one very similar but with CDs
<tsimonq2> Not joking
<cjwatson> (good, I was hoping that attempt at humour wouldn't misfire on people with different tastes in fiction)
<Unit193> Doctor Who had an episode that contained that, X-Files too perhaps.
<tsimonq2> Unit193: ahahahahaha
<tsimonq2> slangasek: Oh yeah, these videos they showed us HAD to be made in the late 90s. CRT monitors, modems, the whole nine yards.
<slangasek> sarnold: how did someone overlook including this video in Jake Gyllenhaal's imdb filmography?
<sarnold> slangasek: perhaps the EU "right to be forgotten" played a role? :)
<slangasek> sarnold: they claim it's not him but http://www.imdb.com/name/nm7772175/ but I know the truth
#ubuntu-devel 2017-12-06
<mwhudson> cjwatson: Unit193 is really called ged?
 * Unit193 looks at mwhudson a little funny.
<rbasak> ahasenack: FWIW, it's a bit frustrating to review the iproute2 SRU when the same quilt patch has a different name in the different uploads.
<rbasak> I realise that you're just following the Debian maintainer's convention of numbering in the filenames.
<rbasak> So I don't really have a strong opinion on which is right.
<rbasak> But the quilt series file makes that numbering redundant IMHO, and I thought I'd give you some feedback on how it's annoying :)
<ahasenack> yes, I was cherry picking to begin with, then I noticed the numbering
<ahasenack> I wasn't sure how picky the maintainer was wrt to that
<ahasenack> imagine how annoying it was for me to fix the filename, commit message and d/changelog entry :)
<rbasak> The Debian maintainer will never see the SRUs though I don't think?
<ahasenack> I don't remember if I checked if debian was affected
<ahasenack> I should have
<rbasak> Even if Debian is affected, the patch to Debian could follow the convention even if the SRUs don't.
<rbasak> You could just call them "ubuntu-sru-ip-maddr..." in the SRUs for example.
<ahasenack> if they add the same patches, then the numbering would be correct, and our delta would be zero
<ahasenack> in that regard
<rbasak> Right at the end of series
<rbasak> We don't care about the delta for stable series though
<ahasenack> hm, didn't know that
<ahasenack> had I not renumbered the patches, I imagined myself having a very similar conversation with a reviewer where he would argue "why these numbers? Why did you skip?" :)
<rbasak> I agree :)
<ahasenack> the response would be to make cherry-picking possible
 * rbasak wonders if iproute2 upstream have a ban on code comments or something
<rbasak> "Let's fix this surprising behaviour bug with fixup code with no associated explanation"
<ahasenack> sounds like you are entering a rabbit hole :)
<ahasenack> good that we are handing it off to another team, heh? :)
<doko> cjwatson: just because that came up on -dektop with demoting gtk2: did you find out about a new system-config-kickstart version?
<jbicha> RAOF: since we're reducing the number of stuff in main depending on gtk2, what do you think of Debian bug 883334?
<ubottu> Debian bug 883334 in src:colord-gtk "colord-gtk: Please drop the gtk2 library" [Normal,Open] http://bugs.debian.org/883334
<seb128> cjwatson, also how likely is it to see debconf ported to gtk3 this cycle?
<cjwatson> doko: I haven't had time yet, still on my list
<cjwatson> seb128: quite likely
<seb128> cjwatson, that's good news, thanks!
<cjwatson> seb128: (i.e. it's mostly done, I just need to debug a couple of things)
 * infinity wonder what part of his desktop install has suddenly decided to pull in apache...
<infinity> Ahh, gnome-user-share
<jbicha> infinity: gnome-user-share was demoted to universe pending LP: #1731065
<ubottu> Launchpad bug 1731065 in mod-dnssd (Ubuntu) "[MIR] mod-dnssd" [Undecided,New] https://launchpad.net/bugs/1731065
<infinity> How lovely.
<infinity> jbicha: Unfortunately, "demoted to universe" doesn't magically remove it from my system. :P
<jbicha> but it's not a bad part of Apache, is it?
<jbicha> well, we're proposing moving it back to the default install this cycle
<infinity> apach2-bin and deps, so no, I assume it won't run on startup, but still bloaty mcbloaterson.
 * infinity shrugs.
<jbicha> gnome-user-share has been broken in Ubuntu for many years, those deps actually fix it :|
<infinity> Fair enough.  Upgrade ahoy.
<jbicha> âDisgusting and terrible, but there doesn't seem to be a better wayâ, right?
<mdeslaur> oh gawd, sharing local directories over the network and over bluetooth?
<mdeslaur> how about we just remove it completely ;)
<mdeslaur> not sure why having that at all would be a good idea
<jbicha> it's turned off by default, but the MIR is open for feedback â¦
<rbasak> "bloaty mcbloaterson"
<rbasak> Surely that should be "bloaty mcbloatface"?
<rbasak> Or is that just a UK thing? :)
<rbasak> ahasenack: also where that list appears incomplete, you can ask the DMB to add to it.
<rbasak> Since it's autogenerated from the seed, it isn't perfect when multiple flavours seed a package.
<Nafallo> rbasak: Sweden has done better by now I believe. We have Trainy McTrainface and Paley McPaleface :-)
<jbicha> http://www.bbc.com/news/uk-england-south-yorkshire-42026485
<sarnold> nice
<dpb1> hey all -- what's the next step to get attention on https://bugs.launchpad.net/xenial-backports/+bug/1717040, subscribe ubuntu-backporters?  ping someone specfically?
<ubottu> Launchpad bug 1717040 in Xenial Backports "Please backport libzstd 1.3.1+dfsg-1 (universe) from artful" [Undecided,Confirmed]
<sarnold> dpb1: just between you and me, I suspect -backports is entirely the wrong place to handle that (a) backports seems dead (b) not many people use it (c) it sounds like something that ought to be addressed for all users
<dpb1> sarnold: ya, I was thinking an SRU for somethign like there, where a package is simply not usable
<dpb1> since the current version likely isn't anyone cares about
<dpb1> (in xenial)
<sarnold> dpb1: but of course, one runs the risk of utterly breaking existing users :(
<dpb1> well, not just a risk even, it appears the contract from what is in xenial to 1.0.0 has changed
<dpb1> hm
<ahasenack> sarnold: the soname changed at least
<ahasenack> which brings another problem then: the lib is a new package
<ahasenack> I wonder how many sru rules this would bend
<sarnold> heh
<ahasenack> dpb1: the build (of the new pkg) runs a ton of tests
<dpb1> ahasenack: that's good
<infinity> ahasenack: Well, the good news is that it has no rdeps in xenial (has a few in bionic)
<jbicha> new packages are allowed as SRUs but in my experience, you have to bring a much larger bribe than usual to the SRU Team ;)
<infinity> The only rdep of libzstd0 in xenial is zstd itself.
<ahasenack> what would happen with libzstd0?
<infinity> "real-time compression scenarios at zlib-level compression ratio"
<infinity> Like... zlib?
<ahasenack> we leave it there, and make the -dev package conflict?
<infinity> ahasenack: What would need to "conflict"?
<infinity> ahasenack: Assuming this was done as an SRU, anything built against -updates would get the new -dev and link to libzstd1.  Anything built before that (or against the release pocket) would depend on libzstd0
<ahasenack> infinity: so if this is sru'ed, nothing will produce libzstd0 anymore
<ahasenack> people will just have it lingering in their systems? If they had it installed
<infinity> ahasenack: Yeahp.  But it would still be in the archive, obviously.
<ahasenack> ah, in release
<ahasenack> updates would have 1
 * infinity nods.
<ahasenack> ok
<infinity> SOVER bumps are not things I'd normally condone in an SRU, but there can be exceptions.
<infinity> And in this case, "complete leaf package, no rdeps in the archive, and (presumably) good argument about why the old version is a steaming heap" would likely do it.
<infinity> Also doesn't hurt that we'd be backporting a version from LTS+1, not some whacky interim version that no one will care about.
<infinity> (And I think "follow-up with another SRU to match the bionic release version, and keep them in sync until xenial dies" might be a condition of accepting such a thing)
<infinity> Though, I guess it's only in universe, so maybe I could relax on the last point.
<infinity> Would be an easier sell if someone backported *and* renamed it to libzstd1-dev/zstd1 and then added transitional packages to bionic to pull people back to the unversioned versions.
<infinity> Though, that might be counter to the intent.
#ubuntu-devel 2017-12-07
<cpaelzer> pitti: the apparmor fix you asked will be in 3.10 for everyone
<cpaelzer> I updated the bug
<pitti> cpaelzer: ah nice, thanks!
<cpaelzer> I'll update the debian bug as well
<cpaelzer> with aping to the upstream commit
<cpaelzer> not sure when guido will merge 3.10, but then it will be resolved on Debian as well
<cpaelzer> pitti: I see on autopkgtest you have a test against what seems a personal ppa
<cpaelzer> pitti: Ppas:	['pitti/systemd-semaphore']
<cpaelzer> for the un-enlightened like me is there somewhere a howto to do so?
<cpaelzer> I used bileto but that recently lets me down considering everything as "always failed"
<cpaelzer> and sometimes testing "on" the infra is just what you need
<pitti> cpaelzer: ah, yes! these are upstream tests, set up like https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Integration_with_GitHub_and_GitLab_pull.2Fmerge_requests
<pitti> cpaelzer: the underlying mechanics is just adding a ppa= to the test request, like in https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Test_request_format
<pitti> cpaelzer: you can use the run-autopkgtest CLI for convenience (https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests)
<pitti> actually no, this script is horribly out of date; I don't think it's being used any more
<pitti> it's that script actually: https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/tree/run-autopkgtest
<pitti> (same name, but using the CGI API instead of ssh to snakefruit)
<pitti> argh, it's been too long - so that script isn't useful for you, it's indeed the one that directly talks to AMQP and thus you can't access it
<pitti> you can trigger them through request.cgi, but ATM you have to build the URL manually; bileto did that, not sure if there's some CLI for that by now
<cpaelzer> thanks pitti
<sil2100> Does anyone know if it's possible to run armhf autopkgtests on an amd64 host?
<sil2100> I tried using autopkgtest-buildvm-ubuntu-cloud with -a armhf but I guess it's using qemu-system-x86_64 by default, tried switching it to qemu-system-arm but then it fails as the script seems to hard-code some params
<sil2100> Is there any guide somewhere for that?
<cpaelzer> ahasenack: didn't you try that just days ago - any success?
<ahasenack> sil2100: I had to tell it to use a wrapper script for qemu
<ahasenack> I had it like this
<ahasenack> options=$(echo "$@" | sed "s%-enable-kvm%%")
<ahasenack> options="$options -M virt"
<ahasenack> echo "options: $options"
<ahasenack> that just got me a bit further, but it still didn't work
<ahasenack> I don't remember exactly what now, but I think it just didn't boot
<ahasenack> autopkgtest-buildvm-ubuntu-cloud -r bionic -m http://br.archive.ubuntu.com/ubuntu/  -p http://10.0.100.2:3128/ -o ~/adt-qemu-images -a armhf -q /home/andreas/bin/qemu-arm.sh --cloud-image-url http://cloud-images.ubuntu.com
<ahasenack> was my command line
<ahasenack> the -q bit specified the wrapper
<ahasenack> and I used --cloud-image-url so my proxy would cache the image (as opposed to https)
<cpaelzer> pitti: you are usually the last resort on autopkgtest magic - ideas for the above?
<sil2100> eh, and I can't even create an armhf schroot right now, debootstrap is dying presumably on bash
<ogra_> sil2100, you want qemu-debootstrap
<sil2100> I'd assume mk-sbuild knows what it should use
<persia> Take care with such assumptions.  Code changes, and needs patches.  When code doesn't work, it is worth looking at why, and maybe fixing it.
<sil2100> What I wanted to say by that: mk-sbuild uses what it should, it's not the problem here, qemu-debootstrap is just a wrapper and mk-sbuild is made to create different chroots of different architecture
<sil2100> It was working fine always and the problem lies somewhere else
<sil2100> eh, I'll try creating an artful schroot and just hope I can reproduce the issue I'm chasing in there
<ogra_> well, qemu-debootstrap is actually only a "cp" :)
<ogra_> but that one cp call is what makes qemu-user-static work :)
<ogra_> else you get an exec format error on bash ;)
<sil2100> It's a bit more than a cp but anyway, mk-sbuild uses that for non-native archs anyway
<ogra_> well, it used to be cp when i wrote it ...
<ogra_> not sure how it has grown sicne
<pitti> sil2100: autopkgtest-buildvm-ubuntu-cloud uses qemu-system-`uname -m` by default indeed, but you can specify a different one with -q
<sil2100> pitti: yeah, tried that, did a wrapper even to get the -machine specified but it then failed further
<sil2100> pitti: ahasenack went further with his hacks but still didn't get it working AFAIK
<pitti> sil2100: ah, autopkgtest-virt-qemu has an option for specifying additional qemu args, but not buildvm-ubuntu-cloud
<coreycb> hello sru team, i just uploaded a new version of neutron to the zesty unapproved queue that has a fix for bug 1731595
<ubottu> bug 1731595 in neutron (Ubuntu Zesty) "L3 HA: multiple agents are active at the same time" [High,Triaged] https://launchpad.net/bugs/1731595
<sforshee> LocutusOfBorg: we have a 4.14 kernel in bionic-proposed now but the vbox dkms drivers still fail to build with it. When will we have those fixes?
<LocutusOfBorg> meh sforshee I can do it then
<sforshee> thanks
<LocutusOfBorg> I was waiting for test results on excuses page... can you please link them to me?
<LocutusOfBorg> got them
<LocutusOfBorg> sforshee, the kernel module builds correctly with 4.14
<LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/v/virtualbox/20171207_024001_8610a@/log.gz
<LocutusOfBorg> if you mean this error, just ask apw to override it
<LocutusOfBorg> it means that the same module is already built so there is no need to dkms it
<LocutusOfBorg> autopkgtest for virtualbox/5.2.2-dfsg-2: amd64: Always failed, arm64: Always failed, armhf: Always failed, i386: Always failed, ppc64el: Always failed, s390x: Always failed
<LocutusOfBorg> seems already done... so I don't know what is missing
<sforshee> huh, my bad. I thought I saw a module build error in the log, maybe I was looking at the wrong one
<sforshee> so nm. Thanks LocutusOfBorg!
<LocutusOfBorg> :)
<LocutusOfBorg> please close the bugs in case
<LocutusOfBorg> we have a patch for 4.15, but I don't care to upload it right now
<sforshee> that's fine, I'm behind on 4.15 anyhow, still haven't finished the initial rebase
<sforshee> too many balls in the air right now :-(
<LocutusOfBorg> 5.1.4 will be out before you upload the kernel, but in case... just grab it from vbox-dev mail list if you care
<LocutusOfBorg> https://www.virtualbox.org/pipermail/vbox-dev/2017-December/014885.html
<LocutusOfBorg> BTW with 4.15 you should really start using the mainline vboxvideo instead of the hacky copy-pasta one
<sforshee> LocutusOfBorg: with 4.14 I've already disabled the one from vboxguests in favor of the staging driver
<sforshee> we don't even build it
<LocutusOfBorg> oh sad news
<LocutusOfBorg> please make sure you cherry-picked this commit ce10d7b4e8e3574b9616e54a09d64521b9aeb8b6
<LocutusOfBorg> and upload the fix asap in case :p
<sforshee> we already got that fix from stable
<LocutusOfBorg> <3
<LocutusOfBorg> thanks!
<LocutusOfBorg> let me know if you do some vm testing then :)
 * LocutusOfBorg grabs a bionic from http://cdimage.ubuntu.com/ubuntu/daily-live/20171207/
<ahasenack> can someone please click on the retry button in the s390x failed firejail test for iproute2 on http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html? It's failing because thunderbird is not available in s390x, and the test has been "force-badtested" already so I think it just needs another try
<Laney> You don't need a retry for that
<ahasenack> I need the failure to be ignored so the package can migrate
<ahasenack> or "always failed"
<ahasenack> not sure what the state will be after this change
<Laney> ok, for artful you need an SRU team member to apply hints, I can't do it
<ahasenack> Laney: oh, you did the force-badtest thing for bionic?
<Laney> ya
<ahasenack> it's wrong there, the test works in bionic
<ahasenack> ooop
<ahasenack> ps
<ahasenack> wait
<rbasak> Would someone like to through an MP at me?
<ahasenack> it's firejail
<rbasak> Uh
<rbasak> Throw
<ahasenack> Laney: n/m me
<ahasenack> is there something going on with setting up ppc64el autopkg tests in excuses? I have 3 different packages failing there with the same error
<ahasenack> grub-probe: error: not a directory.
<ahasenack> run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
<ahasenack> in trusty
<ahasenack> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty/trusty/ppc64el/a/autopkgtest/20171207_002904_c5112@/log.gz is one of them
#ubuntu-devel 2017-12-08
<ventrical> test
<ventrical> can anyone send me some links to C++ files for outstading bugs with unity7 DE like compiz or otherwise? thanks
<ventrical> k.. i gotta get some rest so just leave an answer and I'll try to stumble upon it a little later..
<doko> cpaelzer: nghttp2 needs a MIR (apache2), or apache2 needs to be changed
<cpaelzer> doko: there is a mir and it was already moved by infinity
<cpaelzer> doko: bug 1687454
<ubottu> bug 1687454 in curl (Ubuntu) "[MIR] nghttp2" [Undecided,Triaged] https://launchpad.net/bugs/1687454
<doko> ahh, yes I see it now
<ventrical> Hi all, I have someone who knows C++, joined the unity7 maintainers team, will work 10 hous a week and want sto get going on code right away.!!Hannibal Lecter. do you have  some links to code/bugs her can work on?
<ventrical> goodmorning all?
<ventrical> slangasek: you there
<ventrical> willcooke: you there
<ventrical> ok.. got it fixed. thanks
<doko> jbicha: are you going to do the poppler merge? just seeing because other packages are in dep-wait because of the version mismatch with Debian
<ahasenack> hi, I have a dep8 test failing for firejail in s390x (http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html#iproute2), that's because there is no thunderbird package in s390
<ahasenack> I think maybe someone already did something about it, but it's still red, maybe just a retry is needed and it will pick up whatever was changed in the test infra?
<ahasenack> should this be requested in #ubuntu-release perhaps?
<ahasenack> as it's an sru
<rbasak> firejail only passes on armhf?
<rbasak> That's...interesting.
<rbasak> IMHO, that dep8 test is less than worthless and so I'd ignore it for SRU purposes.
<rbasak> worthless> in its current state for Ubuntu at least, because it's apparently completely broken.
<ahasenack> that test log is, I don't know
<ahasenack> it's still downloading
<ahasenack> and there seem to be infra problems (checking the amd64 failure) RESP BODY: {"forbidden": {"message": "Quota exceeded for ram: Requested 1536, but already used 50176 of 51200 ram", "code": 403}}
<Laney> No
<Laney> It retried and ran.
<Laney> It just backs off for a while if the quota is full
<jbicha> doko: I'm not working on poppler today, maybe someone else will get to it first
<seb128> doko, jbicha, I can have a look to poppler maybe but why is it needed? do we have packages that require a newer version?
<jbicha> texlive-bin is in depwait
<jbicha> https://people.canonical.com/~ubuntu-archive/transitions/html/poppler.html
<jbicha> LocutusOfBorg: is your vbox 5.2.2-dfsg-3 the fix for the gdm login screen not redrawing correctly?
<jbicha> I haven't seen that recently but I think it affects 16.04 too
<jrnieder> Hi. https://bugs.launchpad.net/ubuntu/+source/sbuild/+bug/1734339/comments/4 says you are the folks to ask to push a message through the ubuntu-devel moderation queue
<ubottu> Launchpad bug 1734339 in sbuild (Ubuntu) "Add an Ubuntu build profile" [Undecided,New]
<cjwatson> jrnieder: moderated
<jrnieder> thanks
<LocutusOfBorg> jbicha, fixes the gdm login non starting up
<LocutusOfBorg> please test it too, it works really nice here
<jbicha> works really nice compared to what?
<LocutusOfBorg> install ubuntu 17.10 or ubuntu 18.04 in a vm
<LocutusOfBorg> install virtualbox-guest-x11
<LocutusOfBorg> nothing starts up
<jbicha> oh
<jbicha> I just used whatever guest driver Ubuntu included by default
<LocutusOfBorg> jbicha, the problem is described here https://www.virtualbox.org/browser/vbox/trunk/src/VBox/GuestHost/OpenGL/util/vboxhgcm.c?rev=69989
<LocutusOfBorg> jbicha, with the driver in the kernel, the vboxvideo, you don't have 3d acceleration
<LocutusOfBorg> the x11 package is providing an alternative *GL implementation
<jbicha> is the Ubuntu kernel going to try to re-enable the new video driver for 4.14?
#ubuntu-devel 2017-12-09
<LocutusOfBorg> jbicha, already done
<Veganna> hi
#ubuntu-devel 2017-12-10
<gbs-ufam> Hi, i've setup a ubuntu mirror, and it is oficial now. But it's not listed in the package https://packages.ubuntu.com/xenial/python-apt-common what i need to do now to get it listed there?
<jbicha> doko: since you like removing old libraries from Ubuntu, could you take a look at LP: #1728038 ?
<ubottu> Launchpad bug 1728038 in oolite (Ubuntu) "Remove ancient mozjs from bionic" [Undecided,New] https://launchpad.net/bugs/1728038
#ubuntu-devel 2018-12-03
<rbasak> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<rbasak> Meeting in two minutes
 * rbasak tries to preempt fifteen minutes of waiting about
<slashd> rbasak, I'm here
#ubuntu-devel 2018-12-04
<ahasenack> tjaalton: hi, around?
<ahasenack> tjaalton: I saw that the freeipa dep8 tests errors are ignored now, in the test itself. I guess the intention is to not have it block other packages
<tjaalton> ahasenack: yes
<ahasenack> tjaalton: I'm working on fixing the samba+winbind startup issue, for now I'm trying to remove winbind from the test as it's not used, but I saw in catalina.out what looks like another problem:
<ahasenack> Caused by: java.lang.UnsupportedClassVersionError: org/mozilla/jss/ssl/SSLSocketListener has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
<ahasenack> does that ring a bell?
<tjaalton> where's this from?
<ahasenack> tjaalton: /var/log/pki/pki-tomcat/catalina.out
<tjaalton> ah, you have the fresh libjss-java?
<ahasenack> tjaalton: the test run fails like this: https://pastebin.ubuntu.com/p/gs26bM4F8Y/
<tjaalton> which builds with jdk11 now
<ahasenack> tjaalton: it's disco, I might
<tjaalton> 4.5.1-1
<ahasenack> yes, that one
<tjaalton> dogtag itself needs to be fixed, it'll take a while until new resteasy3.0 with jackson2 provider is available (just uploaded it)
<tjaalton> after that dogtag 10.6.8 should be fine, and I've fixed it to build with jdk11
<tjaalton> now checking resteasy 3.6.2 if it can replace src:resteasy3.0..
<ahasenack> tjaalton: as a workaround for the samba+winbind issue, my intention was to replace the test depends on "@" to a list of packages that excludes freeipa-server-trust-ad, which is what pulls winbind in
<ahasenack> but I can't verify that the freeipa tests still run correctly because of the issue I pointed out above
<tjaalton> the freeipa test isn't blocking samba, if that's what you're after
<ahasenack> it is becuse samba's postinst fails when winbind is running
<tjaalton> oh right
<ahasenack> it's a samba bug
<tjaalton> meh
<ahasenack> https://pastebin.ubuntu.com/p/Yc4WPKxQXd/ is what I have, that doesn't trigger the samba bug
<tjaalton> yeah that's fine, the ad stuff isn't used there anyway
<ahasenack> that installs these packages: https://pastebin.ubuntu.com/p/8GTNNYjVnQ/
<ahasenack> we don't get freeipa-tests
<tjaalton> that's fine
<ahasenack> ok
<tjaalton> it's purpose is somewhat unclear to me anyway :)
<tjaalton> upstream doesn't use it either
<tjaalton> so might just as well drop it, maybe
<ahasenack> tjaalton: I'll proposed this: https://pastebin.ubuntu.com/p/vnntfcNWwV/
<tjaalton> upload away
<ahasenack> I got some comments from ab@samba.org (Alexander) on that issue, but no changes yet
<tjaalton> ok
<ahasenack> there is a lot of confusion, people see "winbind is running, this must be security = ad or = domain"
<doko> didrocks: MIR team meeting
<doko> tjaalton: dogtag-pki autopkg tests timing out on amd64, triggered by openjdk-8. could you have a look?
<tjaalton> doko: it's WIP, migrating to jdk11
<tjaalton> jss migrated, that's causing the timeout
<doko> ta
<ddstreet> xnox for systemd uploads, do you prefer to check patches into your ubuntu-core-dev systemd repo before a systemd patched pkg is uploaded to the queue?  or do you keep the systemd git up to date after the systemd pkg is sent to -updates?
<ddstreet> also thnx for updating disco for the systemd dns bug
<xnox> ddstreet, by the time it lands -updates, it's useless, as sru team need access to git repository to review the diff before accepting from unaprooved.
<xnox> ddstreet, i'm not sure what your actual question is, but i suspect is that what you really want to know is that no actions are currently needed from you.
<ddstreet> xnox i'm asking for future systemd sru uploads, should i instead bug you (or some other core dev) to push the patch into your git before I upload the systemd sru pkg
<xnox> ddstreet, as there is a new systemd upload in cosmic unapproved queue with your edns patch; among 6 other bugs
<xnox> ddstreet, and bionic is currently blocked on validating snapd specific changes, thus i'm not uploading anything there.
<ddstreet> yep thnx for that - this was a question for future systemd sru uploads
<xnox> ddstreet, it depends.
<xnox> ddstreet, single-patch small srus can go in, however. the larger multi-bug srus have been "hard to review" by the sru team, thus I'm trying to present/show my work in one change per git commit linear format.
<ddstreet> ah that makes sense sure
<ddstreet> thanks
<xnox> ddstreet, for non-urgent things, or staging things whilst there is an existing upload in proposed, git works great for that.
<xnox> ddstreet, in general =) i'm very happy about anyone doing systemd work ;-) as long as it gets done from start to finish, and not like leave autopkgtest regressions in security uploads and the like ;-)
<xnox> (and however they like)
<xnox> and i try to minimize the amount of "boring" stuff they might need to do, after the hard part of figuring out what to fix is done.
<ddstreet> xnox much thnx for all your systemd fixing and especially for helping me (and others on my team) apply fixes :)
<brainwash> doko: please look into this packaging issue bug 1805197
<ubottu> bug 1805197 in xfce4-settings "cannot switching keyboard layout with xfce4-keyboard-settings" [Medium,Confirmed] https://launchpad.net/bugs/1805197
<brainwash> doko: comment #7
<dijuremo> Hi, where would be the best place to get some help with Ubuntu 18.04 and grub problems. Seems like the grub package released with 18.04 does *not* have built-in XFS support.
<nacc> dijuremo: you want #ubuntu, afaict (support, not development)
<TJ-> dijuremo: are your referring to the UEFI signed version?
<nacc> dijuremo: if so, it's LP: #1652822
<ubottu> Launchpad bug 1652822 in grub2 (Ubuntu) "grub efi doesn't install fs module needed to access root" [High,Triaged] https://launchpad.net/bugs/1652822
<dijuremo> #ubuntu was not helpful at all... :(
<dijuremo> Yep, so pretty much I had found that bug, but is there a workaround? I am not so knowledgeable of grub
<nacc> dijuremo: that bug lists some workarounds
<nacc> cyphermox: --^ do yo uknow?
<dijuremo> Do note that bug was opened 2016-12-27, so nothing really has happened in a long time...
<dijuremo> The workarounds are *not* permanent, after any kernel install they require manual intervention
<nacc> dijuremo: i never said they were?
<dijuremo> nacc: I wanted to stick to XFS over ext4, guess this bug and stupid Dropbox are forcing me to change.
<nacc> dijuremo: i mean you can do the workaround until the bug is fixed. It looks like Debian has fixed it
<cyphermox> xfs is indeed not in the prebuilt grub uefi image
<nacc> cyphermox: thanks for confirming
<cjwatson> dijuremo: When you say "nothing has happened", I fixed that bug in Debian a bit over a month ago.  Just needs merging (although of course updating a stable release requires more care)
<cyphermox> cjwatson: yup, will do soonish
<cjwatson> Yep, not a nag :)
<nacc> cjwatson: cyphermox: thanks!
<cyphermox> :)
<dijuremo> nacc: Cannot really do the workaround to deploy hudnreds of machine and risk an update breaking them all...
<gQuigs> ubuntu minimal c loud images have grown a lot in cosmic/disco (http://cloud-images.ubuntu.com/minimal/daily/disco/20181129/) - seems to be the inclusion of snap:core/snap:lxd..   is that an intentional change?
<rbasak> fginther: ^
<nacc> dijuremo: understood
<ahasenack> gQuigs: oldest one is http://cloud-images.ubuntu.com/minimal/daily/disco/20181129/ and shows 289M, do you know what the size was before?
<gQuigs> ahasenack: just look at bionic - http://cloud-images.ubuntu.com/minimal/daily/bionic/current/
<ahasenack> ok, so it's a comparison between distros, I thought initially it was a bump during the development cycle of disco
<gQuigs> I think it may have happened during cosmic
<gQuigs> dev
<Odd_Bloke> gQuigs: rbasak: ahasenack: The increase in minimal image size is due to lxd migrating from a deb to a snap, which did indeed happen during the cosmic development cycle.
<gQuigs> can we drop lxd from the minimal image?  it's not really minimal with it...   (report a bug here: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/ ?)
<Odd_Bloke> gQuigs: Please do report a bug, against the cloud-images project.
<Odd_Bloke> gQuigs: https://bugs.launchpad.net/cloud-images/+filebug
<gQuigs> will do, ty
<gQuigs> reported -https://bugs.launchpad.net/cloud-images/+bug/1806752
<ubottu> Launchpad bug 1806752 in cloud-images "Consider not including LXD on Minimal Cloud Images" [Undecided,New]
#ubuntu-devel 2018-12-05
<RAOF> Damnit! I want -dbgsrc packages!
 * RAOF clones debhelper to mess with dh_strip
<oSoMoN> doko, I'm tracking the LO FTBFS in bug #1806847 , and I've made some progress, would appreciate your thoughts
<ubottu> bug 1806847 in libreoffice (Ubuntu) "FTBFS in disco-proposed" [Critical,In progress] https://launchpad.net/bugs/1806847
<doko> oSoMoN: I don't get the connection between the proposed fix and the no-change rebuild of libodfgen. but maybe it's good anyway to rebuild all these splitted-out dependencies with GCC 8, before going on. Are there anymore still built with GCC 7?
<oSoMoN> I don't know, but that one seems to be the only one triggering  a crash in LO
<doko> RAOF: please can you address the yaml-cpp MIR?  this will block again with the next bigger transition
<nacc> changelogs.ubuntu.com down for anyone else?
<ginggs> nacc: yes
<nacc> ginggs: thanks for confirming :)
<ginggs> https://downforeveryoneorjustme.com/changelogs.ubuntu.com
<nacc> ginggs: fair enough ;)
<mdeslaur> hah, nice domain :)
<ginggs> i use it a lot. where i am, we tend to fall off the internet quite often
<bdmurray> seb128: Is bug 1804673 In Progress because someone is working on it?
<ubottu> bug 1804673 in gnutls28 (Ubuntu) "gnutls causes gnome-music segmentation fault" [High,In progress] https://launchpad.net/bugs/1804673
<seb128> bdmurray, no, sorry, that was probably a click error, I put it back to confirmed
<seb128> bdmurray, it's gnutls28 so technical foundations
<bdmurray> seb128: right, we'll talk about tomorrow I just wanted to make sure we weren't duplicating work
<seb128> k, thx for checking
#ubuntu-devel 2018-12-06
<dupondje> ahasenack: If you would have some additional questions on https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1806421 , you can poke me here also :D
<ubottu> Launchpad bug 1806421 in net-snmp (Ubuntu) "perl_bulk_gets patch breaks some scripts" [Undecided,New]
<brainwash> can bug 1801629 be fixed somewhere central, or does every flavour need to add those packages to their dependency list?
<ubottu> bug 1801629 in xubuntu-meta (Ubuntu) "xubuntu-core needs to depend on cryptsetup and lvm2 or 'apt autoremove' will make a LUKS+LVM encrypted root partition non-bootable" [Undecided,Confirmed] https://launchpad.net/bugs/1801629
<brainwash> there was some change in 18.10 apparently
<cpaelzer> juliank: can apt_pkg.TagFile directly read a buildlog (as it includes RFC822 headers for the built packages) or does one need to pre-process the buildlog
<cpaelzer> and if one needs to strip it, maybe there is some example I could shamelessly steal from?
<juliank> cpaelzer: you probably want to grep for :?
<cpaelzer> yeah, I can create my own strip function for sure - just wanted to know if it is needed or soem prior art
<juliank> they are also indented a bit
<juliank> and it might not recognize the blocks because they don't start with rfc822 data
<juliank> cpaelzer: So I guess the answer is I don't know for existing stuff; but you probably want to get all lines starting at a Package: line until you hit an empty line
<juliank> I think it's easy to write that in awk
<cpaelzer> I actually have almost that in awk from an older script
<cpaelzer> I can modify it to my needs, thanks
<ernstp> I'm trying to build a kernel debian package (for ppa), but it's failing on headers_install
<ernstp> Some mandatory headers (poll.h) are missing in arch/x86/include/uapi/asm.
<ernstp> I'm using debian and debian.master directories from the mainline kernel repository
<nacc> ernstp: building locally or in a ppa? If in a ppa, link to the build log. But it's not really relevant to this channel.
<nacc> ernstp: this is for development of ubuntu itself, not for arbitrary upstream packages
<ernstp> nacc: both with local buildpackage and in the ppa, but not if just running make header_install
<ernstp> https://launchpadlibrarian.net/400403424/buildlog_ubuntu-bionic-amd64.linux_4.20.0-994.20181206.2c486cc~drmnext421_BUILDING.txt.gz
<nacc> ernstp: not sure, i guess compare to the ubuntu one, see if it also happens there, and then diff.
#ubuntu-devel 2018-12-07
<RAOF> tjaalton: To save you a later reject from NEW, did you intend to include
<RAOF> tjaalton: I'm pretty sure you didn't intent to include .git in your orig.tar.xz âº
<RAOF> s/intent/intend/g
<tjaalton> RAOF: huh? buggy gentarball target template, sounds like :p
<tjaalton> RAOF: which package is this?
<RAOF> egl-wayland
<tjaalton> right, it's there.. no idea why, same debuild used
<tjaalton> upstream tarball
<tjaalton> no it isn't
<tjaalton> oh well, new upstream version available
<tjaalton> RAOF: thanks for the heads up, I'm not sure what created that tarball
<kreyren> disclaimer: i'm crazy i know that i can brick the system im doing that on my own free will blah blah...... Is there any list of requirements for ubuntu kernel configuration that are mandatory? I would like to make custom kernel
<kreyren> i was told there is something like "SAUCE" can you provide more info to what that is?
<kreyren> anyone here?
<cjwatson> #ubuntu-kernel is more likely to know
<kreyren> thanks!
<cjwatson> also IRC is asynchronous, you can't generally expect immediate answers
<kreyren> i know.. i just hate waiting >.>
<Bluefoxicy> so uh.
<Bluefoxicy> update-initramfs: Generating /boot/initrd.img-4.15.0-42-generic
<Bluefoxicy> I: The initramfs will attempt to resume from /dev/zram3
<Bluefoxicy> This is PROBABLY not something anybody wants to do.  XD
<juliank> Bluefoxicy: that's fun
<Bluefoxicy> juliank: yeah, I have a modified version of zram-config that makes the zram device 2xRAM divided by the number of CPUs, then limits the total memory usage to 50% of RAM
<Bluefoxicy> the performance impacts are in practice negligible, if they even exist (for odd reasons, the penalty can be zero), so I squeeze out near-double RAM for free
<Bluefoxicy> but uh.  It doesn't survive a reboot if you hibernate to it XD
#ubuntu-devel 2018-12-08
<pifreak> How do I get my game into the official Ubuntu software center? IS there a guide or blog about it? Thanks! I bet it's hard, but I hope I can do it some day. It's a free open source C++ game.
<valorie> pifreak: the easiest way is to get it into the debian archive
<valorie> then it is simply a matter of syncing it over to the Ubuntu archive
<valorie> well, a few other paperwork things
<pifreak> :)
<valorie> debian channels in general aren't here on freenode; they are on OFTC
<pifreak> But you think to get into the Ubuntu software center / apt-get Ubuntu repositories, it's doable as long as my software is stable? :D I for some reason assumed it's pretty regulated and they'd never take my software because I'm a noob
<pifreak> Thanks valorie! I will look into some debain guides and find a debian-specific IRC if I need further help with creating packages and such. I appreciate the advice!
<valorie> great!
<sgs> Hi all. I've been maintaining my own repo building software containing some of my own patches and modification. I have been following the "Debian New Maintainers' Guide" https://www.debian.org/doc/manuals/maint-guide/index.en.html. Since Ubuntu 18.04 I started experiencing some problems while building packages:
<sgs> I am basically unpacking my archive, cd <package> && dh_make -f ../<archive>
<sgs> then in the debian directory modifying control, changelog (sometimes rules) and finally running: dpkg-buildpackage <some options> .... what started happening is that the configure scripts started failing (after 18.04)... if I run the build manually ./configure && make ... everything works fine.
<sgs> My question is: Is there any updated tutorial for building .deb packages (not interested in src. packages)? Any other hints and advice are more than welcome.
<cjwatson> sgs: I think people are probably going to need to see a full transcript of exactly what you're doing and the failures in order to be able to help.  The fundamentals of how to build binary packages haven't changed.
<cjwatson> sgs: So it's probably something like missing build-dependencies or some kind of mistake in debian/rules or similar.
<sgs> cjwatson: OK... In a nutshell I am building my own version of the sylpheed client. After running dh_make -f ... in debian/rules I have:
<sgs> override_dh_auto_configure:
<sgs>     dh_auto_configure -- --prefix=/usr --disable-updatecheck --disable-updatecheckplugin
<sgs> After 18.04 build fails with:
<sgs> dh_auto_configure: ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu --libexecdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr
<sgs> --disable-updatecheck --disable-updatecheckplugin returned exit code 2
<sgs> make[1]: *** [debian/rules:24: override_dh_auto_configure] Error 2
<sgs> As far as I can see, the "new arrival" is: --runstatedir=/run
<cjwatson> sgs: Can you post the whole build log on paste.ubuntu.com?
<cjwatson> It's true that debhelper in 18.04 passes --runstatedir=/run, but only in compat level 11; you would have had to specifically opt into this.
<sgs> cjwatson: https://paste.ubuntu.com/p/rSJCCSXTVz/
<cjwatson> --runstatedir is not the problem here.
<sgs> cjwatson: I don't understand what do you mean by compat level 11. I am sorry, but I am quite new into Debian/Ubuntu pkg.
<cjwatson> The thing in debian/compat, which is documented in "man debhelper".
<cjwatson> This is the actual problem:
<cjwatson> ./configure: line 13484: syntax error near unexpected token `ac'
<cjwatson> ./configure: line 13484: `SYLPHEED_ACLOCAL_INCLUDE(ac)'
<sgs> cjwatson: When I build sylpheed manually ./configure ...etc --runstatedir=/run is the only option it doesn't recognize.
<cjwatson> Translating: your debian/rules runs autoreconf (because debhelper does that automatically as of compat level 10), but you don't have the right build-dependencies for it to be able to regenerate the build system.
<cjwatson> Irrelevant, you're changing too many variables there so that's not a valid test.
<cjwatson> (Specifically you evidently didn't run autoreconf first ...)
<cjwatson> Let's see, just investigating
<cjwatson> To fix this particular bug I think you need to add this to debian/rules, to make sure that autoreconf picks up sylpheed's local autoconf bits:
<cjwatson> override_dh_autoreconf:
<cjwatson>         dh_autoreconf ./autogen.sh
<cjwatson> Note that the second line should begin with a hard tab character, not eight spaces, since debian/rules is a Makefile
<cjwatson> You may of course run into some other problem later.  Is there some reason you aren't sticking with the presumably tried-and-tested packaging in the sylpheed source package, even if you need to change some bit of it?
<sgs> OK...
<cjwatson> If you aren't familiar with packaging, then trying to do it all yourself isn't a recipe for success.
<cjwatson> Or at least is a recipe for having to read a lot of documentation.
<cjwatson> dh_make is for when you need to package something that nobody else has packaged before, not for when you need to make some relatively minor tweak to an existing package.
<cjwatson> In other words, while we can probably help to fix the specific things you're running into, it sounds like you're going about the whole thing the wrong way.
<sgs> cjwatson: The problem is that Ubuntu / Debian are still packaging 3.5.1 which is quite old.
<cjwatson> Sure, but you really do not have to completely redo the packaging from scratch in order to upgrade to a new upstream version.
<cjwatson> And in fact you should not.
<cjwatson> Running dh_make is saying "there is absolutely nothing of value in the existing packaging and I know better".
<cjwatson> But in fact you don't know better since you said you're new to this :-)
<cjwatson> You'd be better off transplanting the packaging parts (i.e. debian/*) from the existing source package, and massaging them as necessary for the new upstream version.
<cjwatson> You might have to e.g. adjust and/or drop some of the patches a bit.  But still better than entirely throwing away the existing packaging.
<sgs> cjwatson: Sure. I'll do that.
<sgs> dh_autoreconf ./autogen.sh
<sgs> ./autogen.sh: 6: ./autogen.sh: aclocal-1.14: not found
<sgs> dh_autoreconf: ./autogen.sh returned exit code 127
<cjwatson> Ah right, I guess maybe "dh_autoreconf autoreconf -- -fi -I ac" would work better in that case.
<cjwatson> But I still think this is the wrong approach.
<cjwatson> (Upstream's autogen.sh hardcodes a particular version of Automake that was superseded in 2014, for some reason.)
<sgs> cjwatson: It worked :) Thank you so much for your time. :)
<cjwatson> np
#ubuntu-devel 2019-12-02
<oSoMoN> sil2100, hey, thunderbird 60.9.1 is FTBFS in {xenial,disco}-proposed because of a cargo bug (bug #1841191), I'm wondering if there's a way to do an express SRU for cargo with https://github.com/ehuss/cargo/commit/e46e185e4d007daa1a73f3e99e051d9ad039f5a6 ?
<ubottu> bug 1841191 in cargo (Ubuntu Disco) ""error: failed to acquire package cache lock" in sbuild" [Undecided,Fix committed] https://launchpad.net/bugs/1841191
<Odd_Bloke> mwhudson: https://bugs.launchpad.net/ubuntu/+source/distro-info/+bug/1727751
<ubottu> Launchpad bug 1727751 in distro-info (Ubuntu) "ubuntu-distro-info shows the current development series as "latest development" and "supported stable version" at the same time" [Undecided,New]
<kanashiro> hi didrocks, I've been working on runc MIR and I'd like to do a similar thing you did in zsys MIR to identify a small set of deps embedded in the generated binary: https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271/comments/11
<ubottu> Launchpad bug 1839271 in zsys (Ubuntu) "[MIR] zsys" [Undecided,New]
<kanashiro> however, I am not able to reproduce what you did with zsys, to run 'go version -m zsysd' and get that output do I need to build it differently? or just use the binary shipped inside the .deb package should work?
<kanashiro> I am using golang from focal-proposed (1.13)
<didrocks> kanashiro: I didn't look yet with the package produced binary, but yeah, I know that the module versions are stripped out (probably some linker's flag). The result I'm showing is just running "go build" to build the binary directly
<sil2100> oSoMoN: so, those thunderbird uploads - those are to go to -security as the others?
<kanashiro> didrocks, sorry for the lack of golang knowledge but what is the exact command you use to build it? just "go build" from the root of the project directory is not generating the binary for me here
<ahasenack> rbasak: haproxy is a sync, and we don't want to go beyond the 2.0.x line we are in now, as that is upstream's LTS line
<ahasenack> rbasak: do you know how to put a block in place, if that's possible?
<didrocks> kanashiro: go build in the binary directory you want to build should be enough. You can try to build all binaries in your project by go build ./... (if ofc, the project can be built directly, without a makefile doing magic)
<kanashiro> didrocks, thanks, after entering the zsysd directory worked now :)
<kanashiro> I got the same output you reported
<didrocks> ;)
<ddstreet> connor_k yep i opened lp #1850267 for that
<ubottu> Launchpad bug 1850267 in network-manager (Ubuntu Bionic) "autopkgtest 'nm' fails because it can't find dnsmasq" [Low,In progress] https://launchpad.net/bugs/1850267
<oSoMoN> sil2100, no, those are normal SRUs, there's nothing qualifying them as a security update
<connor_k> ddstreet, thank you!
<ddstreet> connor_k do you have a n-m upload in progess you can attach the nm test fix to?  if not i can upload just the fix and add the 'block-proposed-bionic' tag to the bug
<connor_k> ddstreet, no, I'm just interested in tracking that fix in particular for kernel autopkgtests since we try running n-m
<ddstreet> ack, i'll go ahead and put it in the bionic upload queue then, thnx
<infinity> oSoMoN, sil2100: Seems like a bit of a moot point when they don't build anyway?
<rbasak> ahasenack: you mean in case Debian upload 2.1 to unstable?
<rbasak> I'm not sure of a good mechanism :-/
<ahasenack> rbasak: exactly
<ahasenack> rbasak: because 2.1 is "stable" upstream, but is not an lts stable
<rbasak> There is an autosync blacklist
<rbasak> Or you could use "ubuntu" in the version number of an upload that is a fakesync
<rbasak> Maybe fakesync is the wrong term
<rbasak> I mean an upload that is identical to Debian but with an ubuntu1 changelog entry. That would stop an autosync and would have it appear in our merge report etc.
<ahasenack> is that the usual? And who would know about the autosync blacklist mechanism?
<ahasenack> the usual suspects? :)
<rbasak> https://bazaar.launchpad.net/~ubuntu-archive/+junk/sync-blacklist/view/head:/sync-blacklist.txt is the sync blacklist
<rbasak> I'm not sure there is a "usual"
<rbasak> It's a reasonable enough thing to want though
<rbasak> (freezing a specific package in advance of DebianImportFreeze)
<rbasak> Given that we already do a merge report with analysis, maybe the sync blacklist is appropriate. We can always manually sync, and we won't miss new versions since our report will tell us.
<ahasenack> I would want a new update of the 2.0.x series if it comes from debian, though
<ahasenack> let me email ubuntu-devel
<rbasak> We'd stop that in the merge report and manually sync it
<rbasak> spot
<sil2100> oSoMoN: I would say it should be possible to do that, i.e. the cargo SRU, but only of that small change and it would have to be linked in  the bug - and possibly with a separate cargo test-case if possible
<oSoMoN> sil2100, that sounds good, I'll prepare the cargo SRUs first thing tomorrow morning then
<sil2100> oSoMoN: thanks! Give me a ping once those are uploaded, I might find the cycles to get them in
#ubuntu-devel 2019-12-03
<vicamo> bdmurray: https://code.launchpad.net/~vicamo/ubuntu/eoan/apport/bug-1847967/+merge/374263 , do you have some time to review this or maybe suggest another reviewer?
<seb128> vorlon, hey. I'm a bit confused on what should be done with e.g cockpit, it's blocked in focal-proposed because its autopkgtests are failing on i386 but the version in proposed didn't even built for that arch... what are we supposed to do in those cases?
<didrocks> bdmurray: can we get foundation team being subscribed to golang-1.13 package so that I can promote it and unblock golang-defaults?
<seb128> vorlon, same for firefox, firejail/i386 fails because it tries to install firefox which doesn't exist anymore on that arch
<oSoMoN> sil2100, good morning! IÂ attached debdiffs to bug #1841191 for the cargo SRU, IÂ am going to update the bug description now
<ubottu> bug 1841191 in cargo (Ubuntu Disco) ""error: failed to acquire package cache lock" in sbuild" [Undecided,In progress] https://launchpad.net/bugs/1841191
<sil2100> oSoMoN: thanks! Once you update the description, I could sponsor that into ubuntu - but then I think I wouldn't be able to accept it into -proposed
<sil2100> oSoMoN: also, looking at the debdiff I think it might also be a good thing to include LP: #1850651 in the changelog, so that we know one shouldn't go without the other
<ubottu> Launchpad bug 1850651 in thunderbird (Ubuntu Eoan) "[SRU] Authentication constantly re-requested for Google" [High,Fix committed] https://launchpad.net/bugs/1850651
<sil2100> But I can do that before sponsoring
<oSoMoN> sil2100, ack, would it be better if IÂ found someone else to sponsor, so you could accept it in -proposed?
<oSoMoN> I'll update the debdiffs to include LP:Â #1850651
<oSoMoN> seb128, could you maybe sponsor my cargo uploads (xenial and disco) that are attached as debdiffs to bug #1841191
<ubottu> bug 1841191 in cargo (Ubuntu Disco) ""error: failed to acquire package cache lock" in sbuild" [Undecided,In progress] https://launchpad.net/bugs/1841191
<oSoMoN> (for context this is needed for the thunderbird 60.9.1+build1 SRU, which is accepted in {xenial,disco}-proposed, but is FTBFS because of that cargo bug)
<seb128> oSoMoN, I'm joining a meeting now but trying to have a look
<oSoMoN> thanks!
<mwhudson> oSoMoN: finally got rustc and cargo all done... must be time for the next update nearly
<oSoMoN> mwhudson, thanks!
<rbasak> kanashiro: did you make any progress with rrdtool please? I got an email about it still being stuck in proposed.
<kanashiro> rbasak, sorry I forgot to follow up, I have this MP but it is still waiting for review: https://code.launchpad.net/~lucaskanashiro/ubuntu-seeds/+git/ubuntu/+merge/376068
<rbasak> kanashiro: ah - subscribe ~canonical-server to that please, so it appears in our team's review queue.
<rbasak> I'll take a look later if I get a chance
<kanashiro> rbasak, ack, thanks in advance :)
<rbasak> Note: src:rrdtool is in main, as well as some binary packages, so isn't quite correct to say "rrdtool, not in main"
<rbasak> kanashiro: ^
<kanashiro> rbasak, ok, I'll check this out and fix the comment
<santa_> vorlon: good morning. if you have some time I would like to ask you a few questions about network-manager packaging
<kanashiro> rbasak, FWIW the rrdtool MP should be fixed now
<kanashiro> rbasak, we also have an autopkgtest failure in slurm-llnl due to rrdtool proposed update, could you please trigger it again since we have this failure only in ppc64?
<vicamo> bdmurray: ping
<seb128> kanashiro, rbasak, I demoted python3-rrdtool-dbg earlier which was blocking migration because it depends on python3-rrdtool which is universe, I don't know if that's enough to get it migrated but that should help at least
<kanashiro> thanks seb128 , I think the problem now is just those autopkgtest failures then (munin in armhf and slurm-llnl in ppc64)
<seb128> kanashiro, indeed, looks like it
<seb128> kanashiro, those look flaky ones, I did give them a retry
<kanashiro> seb128, thanks again :) since I don't have permission yet I need to ask people to do it for me
<seb128> np!
<rbasak> ogra: I already addressed what you said in the post you replied to, in the second paragraph. It's not a limitation of what we're doing; what you're asking for would be an entirely separate project.
<rbasak> (with its own upstream code!)
<rbasak> It's not anything certbot can do today.
<oSoMoN> seb128, have you had a chance to look at those cargo debdiffs?
<seb128> oSoMoN, I didn't since I was unsure if mwhudson comment meant he was looking at it, seems he did not, I'm looking now, thx for the reminder!
<oSoMoN> seb128, sorry for the confusion, mw_hudson meant that he had finished packaging the next version of cargo and rustc (which contains the patch I'm trying to SRU), but it's still desirable to have that SRU for timing reasons
<seb128> oSoMoN, right, I though he might be sponsoring those fixes while he was at it, wishful thinking :)
<ahasenack> Skuggen: hi, do you know if a mysql-8 test result file can contain wildcards, when checking matches?
<ahasenack> Skuggen: I have a silly bug in./mysql-test/t/mysqlpump_basic_lz4.test where it outputs the lz4 version and that gets added to the log file, but is not present in the results one
<seb128> kanashiro, rbasak, retries worked, rrdtool migrated to focal now
<kanashiro> \o/
<seb128> oSoMoN, done, they are in the queues
<oSoMoN> seb128, thanks!
<seb128> oSoMoN, np!
<oSoMoN> sil2100, can you please accept the cargo SRUs in {xenial,disco}-proposed ?
<Skuggen> ahasenack: Hi. The bug was discussed some time back, but lost track of it, sorry
<Skuggen> ahasenack: We have a fix for it upstream. The issue is that lz4 has moved some output from stderr to stdout, so the old redirect the test does to hide it no longer works. The fix just fixes the redirect
<ahasenack> Skuggen: why not redirect to /dev/null?
<ahasenack> or is that what the fix does?
<ahasenack> ah, the log file it redirects to is not what is used to compare with the result?
<Skuggen> The problem is that it redirects stderr
<Skuggen> But the extra output is sent to stdout as of the last lz4 version
<ahasenack> I got that
<Skuggen> Right, it uses a log file to hide the output (just in case there are some actual problems that need to be investigated later)
<ahasenack> I just didn't understand why it was redirected to the lz4 log file
<ahasenack> we have a patch to redirect both streams to the log file, but the failure still happens
<ahasenack> I'm troubleshooting that now
<ahasenack> we do this:   --exec lz4 -V > $LZ4_EXEC_LOG 2>&1
<Skuggen> Is that patch somewhere I can look at it?
<ahasenack> Skuggen: https://git.launchpad.net/~usd-import-team/ubuntu/+source/mysql-8.0/tree/debian/patches/new_lz4_compat.patch
<ahasenack> in 0ubuntu3, and https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#lz4 still shows a failure on amd64
<Skuggen> Hm, that looks like the same fix we have
<Skuggen> That's a different test failing, it seems
<Skuggen> main.mysql_client_test
<ahasenack> ah, you are right
<Skuggen> Which didn't test with the previous try. Could be an unstable test. Could you retry it?
<Skuggen> didn't fail*
<ahasenack> weird, in arm64 it was the lz4 one
<ahasenack> ah, but 8.0.17-ubuntu3
<ahasenack> not 8.0.18-ubuntu3
<ahasenack> this was retried once already, according to http://autopkgtest.ubuntu.com/packages/m/mysql-8.0/focal/amd64
<ahasenack> I'll do a local run see if I get more logs
<Skuggen> I see we have some recent fixes to that test (mysql_client_test) to make it more stable, so my guess is that it's that, since it didn't fail with ubuntu2
<ahasenack> ok
<ahasenack> I'll do one more retry, while I try manually in parallel
<Skuggen> Yeah, thanks
<Skuggen> Actually, I see that those changes where in 8.0.18 as well, hmm
<Skuggen> But if you look at the glibc update on the excuses page, 8.0.18-0ubuntu3 is green
<ahasenack> ok
<didrocks> doko: golang-1.13 promoted, thanks for subcribing your team.
<seb128> didrocks, thx for chassing people down and doing the promotion!
<didrocks> yw
<ahasenack> Skuggen: passed locally on the first attempt
<ahasenack> let's see how the retry goes
<ahasenack> is the excuses report stuck, or just slow? "Generated: 2019.12.03 13:38:28 +0000"
<ahasenack> that's about 2h30 ago
<vorlon> seb128: the process there is to unconditionally add badtest overrides for all the failing i386 tests, and yearn for a future where this bug in britney's calculation of what tests to run is fixed (this is a longstanding nuisance, made more obvious now by the large number of package removals)
<seb128> vorlon, hey, so what's the process ... badtest is limited to ubuntu-release right? it's quite a bottleneck for uploads to be able to get moving
<seb128> do we just need to mp and chase down r-t members?
<seb128> (Laney is off this week which is a bit unfortunate for us in desktop)
<vorlon> seb128: broadly, yes; at the moment I'm batch-overriding all the ones I find in excuses that we should be ignoring
<seb128> vorlon, can you add firejail/i386 if you are already editing things?
<seb128> I will mp the next ones I cross
<vorlon> seb128: yeah, part of the batch of 29 badtests I just added
<seb128> vorlon, great, thanks!
<vorlon> santa_: 4am is not really my morning; and I am not likely to be the right person for you to ask questions of about network-manager packaging, but go ahead :)
<santa_> vorlon: ah, sorry for some reason I tought you were in some european time zone
<seb128> vorlon, is http://autopkgtest.ubuntu.com/packages/p/plinth/focal/i386 on your list as well?
<vorlon> ahasenack: fwiw after you asked, a new report has appeared, timestamped 16:07:40
<vorlon> seb128: yeah, I just added that one too
<seb128> thx
<santa_> vorlon: the thing is, I have been digging into a couple of VPN DNS leaking bugs of n-m, and you mentioned in one of them in ubuntu we have now n-m using systemd-resolved instead of dnsmasq
<ahasenack> vorlon: ah, thanks
<vorlon> santa_: sure
<ahasenack> Skuggen: all green now: autopkgtest for mysql-8.0/8.0.18-0ubuntu3: amd64: Pass, arm64: Pass, armhf: Always failed, i386: Pass, ppc64el: Always failed, s390x: Always failed
<santa_> vorlon: so is there any public explanation of why it was changed?
<ahasenack> Skuggen: oh, wait, that's the run for another package, not lz4
<santa_> I found an old mail @ ubuntu-devel which just mentions the decision but not the reasons
<ahasenack> the lz4 run hasn't updated yet, it's stil from november
<santa_> I also tried to find something in the package changelog, but no luck
<santa_> https://lists.ubuntu.com/archives/ubuntu-devel/2017-August/039954.html
<santa_> â the only interesting mail I could find that mentions systemd-resolved
<vorlon> santa_: because resolved is already on the system via systemd; we had evaluated it for use on server to address various longstanding issues caused by not having a local resolver; that evaluation included determining if it was a suitable replacement for dnsmasq on the desktop so that desktop and server would be using the same implementation
<santa_> vorlon: hmm, do you remember any of this issues? I got hit by one issue with systemd-resolved which doesn't happen in dnsmasq
<vorlon> santa_: please file a bug on the systemd package
<santa_> that's what I planned to do. it's that it doesn't support AXFR queries
<vorlon> ok, I'm not sure what an AXFR has to do with the operations of a local resolver
<vorlon> but please file a bug so it can be discussed there
<santa_> ack just a couple of things and I'm done:
<santa_> is configuring network-manager with dnsmasq still supported? i.e. if I find an VPN DNS leaking bug with that configuration and I provide a patch, would be possible get it into the official package?
<santa_> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1854976
<ubottu> Launchpad bug 1854976 in systemd (Ubuntu) "systemd-resolved doesn't work with "host -l" / AXFR queries" [Undecided,New]
<santa_> vorlon: â and I won't bother you more :P
<vorlon> santa_: cheers, I'll flag that for the team to look at
<santa_> thanks for your time
<vorlon> santa_: regarding your other questions: I don't think configuring network-manager with dnsmasq is still supported, I think we've disabled that plugin for sanity (but I could be wrong).  And VPN DNS leaking bugs are definitely bugs we care about.
<santa_> vorlon: it can be configured like that + disable systemd-resolved
<vorlon> ok
<oSoMoN> sil2100, any chance you can review the cargo uploads in the xenial and disco unapproved queues? sorry if IÂ sound insistent, I'm eager to get those thunderbird SRUs building
<sil2100> oSoMoN: ah, sure! Again I seem to have had some notification malfunction
<oSoMoN> no worries, IÂ appreciate that you must be getting pinged left and right all the time
<sil2100> grrr, LP of course didn't generate a correct diff, at least not against what was in -updates, need to diff manually
<oSoMoN> sil2100, yeah, IÂ saw thatâ¦ the debdiffs are attached to the bug report, if that helps
<sil2100> oSoMoN: no, that's fine
<sil2100> Although LP times out like crazy right now
<oSoMoN> sil2100, thanks!
<Skuggen> ahasenack: I think it's green now?
<ahasenack> Skuggen: it is!
<Skuggen> Maybe need to disable the test and report it upstream (I'll find out if anything more has been done to make it more stable, first)
<vorlon> infinity, stgraber, kees: TB meeting? (mdeslaur sent regrets)
<seb128> rbalint, hey, do you plan to forward your newpid fix to Debian?
#ubuntu-devel 2019-12-04
<cpaelzer> it seems on d/t/control you can't restrict the @ wildcard with architectures like  Depends: @ [amd64 s390x], @builddeps@, ethtool
<cpaelzer> all I want is to only run it on those two and not on any other arches
<cpaelzer> it feels like this must be easy and common, but I haven't seen a great and easy "tag for architectures that it should run" yet
<cpaelzer> I might have been missing it all the years, hints welcome :-)
<infinity> cpaelzer__: Why shouldn't it run for all arches?  If it's known to fail on others, then it'll fail, so what?
<cpaelzer> infinity: yes it is known to fail on other arches
<cpaelzer> infinity: the package has many tests and just one would have that "fails on some arches"
<infinity> cpaelzer: Right, we don't generally want to hide problems by skipping testsuites where they fail.
<cpaelzer> I'd want to have the coverage of the other tests that work well on all arches
<cpaelzer> and these extra tests that have limited arches run only on those known to work
<infinity> cpaelzer: Ahh, if the goal is to run all the "good" tests, just wrap the bad one in a dpkg-architecture check?
<cpaelzer> yes
<cpaelzer> I have doen so years ago for DPDK, but I wondered if there is anything new
<cpaelzer> better than if dpkd --print-architecture ...
<infinity> From my POV, I wouldn't want arch-restriction semantics in debian/tests/control, cause it would encourage its use for evil. :P
<infinity> But that's just my opinion.
<cpaelzer> hehe, maybe that is the reason it isn't there
<cpaelzer> will do a less comfortable semi-manual arch check for this special case then ...
<cpaelzer> thanks for the talk infinity, now I feel less like "there must be a tag for arch-restrictions, but I'm the only one not knowing it"
<infinity> cpaelzer: Nah, it really doesn't exist.  And while I can see an argument that it could be useful, I think what would be more useful is work on debci/autopkgtest to record granular test results and britney integration to use those.
<infinity> cpaelzer: Cause it's valuable information to know that 5/6 pass, and 1/6 is an xfail, cause it's never passed.  Ignoring that 1/6 by arch-restricting is just a bandaid.
<cpaelzer> ack to that as a vision for autopkgtest.u.c
<seb128> vorlon, hey, do you still plan to do the regular i386 removals to unblock things? there is a stack of 3 days old blocked item on the proposed-migration summary
<ricotz> seb128, hi :), is there a list of packages which will keep their i386 builds?
<seb128> ricotz, hey, yes, https://people.canonical.com/~ubuntu-archive/packagesets/focal/i386-whitelist
<ricotz> thanks!
<seb128> ricotz, it's built according to the feedback given in https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility/12598
<seb128> ricotz, np!
<ricotz> seb128, looks like this whilelist doesn't apply to PPAs?
<cjwatson> The whitelist applies to PPAs
<infinity> cjwatson: It does?  Without a toggle?
<ricotz> cjwatson, ok, I see "vala" is in the list, but https://launchpad.net/~vala-team/+archive/ubuntu/daily/+packages
<cjwatson> There is currently no toggle available.  There probably should be
<infinity> cjwatson: Cause a common use-case of PPAs is to build stuff that doesn't exist in PRIMARY, which the whitelist wouldn't allow.
<cjwatson> Somebody who needs such a toggle should file a bug please
<infinity> ricotz: vala != vala-git.
<ricotz> sorry, the is vala-git for some convenient reasons
<cjwatson> ricotz: But there is no ... that
<infinity> ricotz: The whitelist is source package.
<infinity> cjwatson: Filing.
<cjwatson> Ta
<infinity> cjwatson: UI might be interesting.  From a "what other options does it look like" perspective, it clearly fits well next to the "use same components as PRIMARY" toggle, but that page is called "Edit Dependencies" not "influence build record creation".
<infinity> Maybe under the arch selection makes as much sense, though.,
<infinity> cjwatson: LP: #1855069
<ubottu> Launchpad bug 1855069 in Launchpad itself "PPAs should be able to toggle using PRIMARY's arch-{white,black}lists" [Undecided,New] https://launchpad.net/bugs/1855069
<rbalint> seb128, already did https://github.com/df7cb/newpid/pull/2
<seb128> rbalint, hey, that's upstream and not Debian right? well, I guess if upstream is active that's going to flow back to Debian and then us...
<rbalint> seb128, this is the repo listed in Vcs-Git
<seb128> rbalint, ah ok, perfect then, thanks!
<seb128> tjaalton, hey, do you think you could look at the silx autopkgtest (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/silx/20191130_223733_29186@/log.gz), I tried to unblock xorg-server proposed-migration and I think that's the remaining problem but I don't understand the openCL error there
<tjaalton> seb128: me neither
<seb128> tjaalton, do you know who would know? we need that sorted out one way or another
<tjaalton> no..
<tjaalton> same pocl used on both focal and debian
<tjaalton> failed on debian too but because of something else
<ahasenack> hello, could an archive admin please take a look at the haproxy i386 failure in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#haproxy ?
<ahasenack> is this a case where the i386 package has to be removed, as per vorlon's email to ubuntu-devel a few days ago?
<ahasenack> oh, that email said to use #ubuntu-release
<coreycb> doko: 20.04 won't have python 3.6 will it? I don't think so but figured I'd check.
<cjwatson> Even 19.10 didn't have Python 3.6.
<cjwatson> Indeed it was removed in 19.04.
<doko> coreycb: ^^^
<coreycb> doko: cjwatson: yeah sorry not thinking
<doko> coreycb: and we are trying to drop 3.7 in 20.04
<doko> coreycb, jamespage: I'm now proposing to update 2.7 to 2.7.17 in bionic. I have no regressions found in main (builds). is there anything you want to check for openstack?
<coreycb> doko: so 20.04 will be 3.8 only?
<doko> and likely 2.7
<coreycb> doko: ok
<coreycb> doko: thanks. we could run regression with 2.7.17 in -proposed if needed.
<doko> coreycb: ok, packages are currently in ubuntu-toolchain-r/ppa PPA. then I'll go ahead with the uploads to proposed, and wait for checks. it's not urgent
<coreycb> doko: thanks i'll keep an eye out for it in proposed
<seb128> tsimonq2, hey, just as a FYI, I removed https://bugs.launchpad.net/ubuntu/+source/indicator-multiload/0.4+git20170224-0ubuntu1 since it was buggy/not building/removing translations
<ubottu> Error: launchpad bug 0 not found
<vorlon> seb128: the three-day-old blocked packages are the ones that have non-trivial revdeps that I haven't unwound.  do you have specific ones you want me to look at?
<seb128> vorlon, liborcus would be nice, it's one of the blocker for glibc and others
<vorlon> for glibc?
<vorlon> I'll look at liborcus
<seb128> vorlon, according to https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages yes
<seb128>  liborcus blocking glibc (2.30-0ubuntu2 to 2.30-0ubuntu3) for 4 days
<seb128> (the test issue is fixed in -3 which isn't mgirating because of i386)
<vorlon> seb128: blocking via autopkgtest failure; if the test is broken in -3 we should be badtesting that?
<vorlon> in -2, sorry
<seb128> well it's fixed in -3 so I guess we could also retry with that added to the trigger= list
<seb128> but ideally the fixed version would just migrate
<vorlon> that ideal is the slow path in general for unblocking packages
<seb128> vorlon, right, I'll just retry with the trigger for now, going through the rdepends list indeed doesn't seem trivial :-/
<seb128> vorlon, oh, also, can you make dbus migrate? the only remaining blocker is http://autopkgtest.ubuntu.com/packages/s/systemd/focal/i386
<seb128>  dbus : Depends: libdbus-1-3 (= 1.12.16-2ubuntu1) but 1.12.14-1ubuntu2 is to be installed
<seb128> that doesn't seem like it has to do with the dbus update right?
<vorlon> seb128: that should be fixable with an --all-proposed retry; we saw that last week and it has to do with our pins not doing :amd64 on the i386 runners
<seb128> vorlon, k, let me try that, thx
#ubuntu-devel 2019-12-05
<seb128> vorlon, hey, was there any reason you did file bug #1853646 without doing the actual removals?
<ubottu> bug 1853646 in zope.lifecycleevent (Ubuntu) "RM: zope.lifecycleevent, lazr.lifecycle: python2-only, Ubuntu-specific, build-depends on removed van.pydeb, no other reverse-dependencies" [Undecided,New] https://launchpad.net/bugs/1853646
<RikMills> anyone want to port code-of-conduct-signing-assistant to PyQt5 so it can be kept?
<RikMills> it fails to start anyway since bionic, where Qt4Webkit went away
<RikMills> LP: #1855255
<ubottu> Launchpad bug 1855255 in code-of-conduct-signing-assistant (Ubuntu) "Port to python3/pyqt5 or remove from focal archive" [Undecided,New] https://launchpad.net/bugs/1855255
<coreycb> cjwatson: have you seen by any chance when attempting to push a new git repo to launchpad? "fatal: remote error: Path translation timed out."
<cjwatson> coreycb: Yes, it's a known problem when the parent repository has lots of refs.  I have an MP in review to (probably) fix this, but we can work around it if you tell us the repo you're trying to push
<coreycb> cjwatson: great, thanks. I'd like to create lp:~ubuntu-server-dev/ubuntu/+source/migrate and lp:~ubuntu-server-dev/ubuntu/+source/python-cryptography if possible.
<vorlon> seb128: LP: #1853646> mostly because there were a bunch more to file and I left one open so I could find it again and use it as a template :)
<ubottu> Launchpad bug 1853646 in zope.lifecycleevent (Ubuntu) "RM: zope.lifecycleevent, lazr.lifecycle: python2-only, Ubuntu-specific, build-depends on removed van.pydeb, no other reverse-dependencies" [Undecided,Fix released] https://launchpad.net/bugs/1853646
<cjwatson> coreycb: There's no sysadmin vanguard around right now, so might have to wait a bit ...
<coreycb> cjwatson: ok
<cjwatson> I'll ask when I next spot one, and let you know
<coreycb> thanks
<Odd_Bloke> bryce: o/ I have a simplestreams upload prepared that I need sponsorship for, and powersj pointed me in your direction.  The debdiff is https://paste.ubuntu.com/p/J35wNpBDwQ/.  Is there a better way for me to communicate this to you (git-ubuntu &c.)?
<rbasak> kanashiro: https://lists.ubuntu.com/archives/ubuntu-devel/2019-April/040622.html is the background I was referring to on Rails issues in proposed migration
<bryce> Odd_Bloke, good morning!  yes I'll help with sponsorship
<Odd_Bloke> Thanks!
<bryce> Odd_Bloke, we do usually use git ubuntu for stuff but I can work with debdiffs.  Unless you want to learn git ubuntu I can just take care of that end of things
<Odd_Bloke> bryce: I'd be happy to learn git-ubuntu.
<rbasak> I suggest that you take it incrementally. For a start, if you already have a debdiff, you can just clone the 'ubuntu/devel' branch from https://code.launchpad.net/ubuntu/+source/simplestreams, apply your changes, and then submit those back as a merge proposal.
<rbasak> There is currently no good solution for supplying the upstream tarball - you'll need to get that to your sponsor out of band (same as the situation with a debdiff)
<kanashiro> rbasak, thanks for the link, fair points you raised there
<bryce> Odd_Bloke, ok let's dig into that post team meeting.  I'm reading through the debdiff presently.
<Odd_Bloke> bryce: rbasak: What's the appropriate commit message format?
<rbasak> We don't have any specific rule, but we usually use the same format as what would go into debian/changelog since then we can use a tool called reconstruct-changelog to write debian/changelog for us
<rbasak> But nothing is mandated
<bryce> Odd_Bloke, what you're written looks fine, the trick is to have it as its own git commit
<Odd_Bloke> bryce: So my single git commit message would be "* New upstream snapshot.\n  - tools/j2signed: ...\n  - ..."?
<bryce> Odd_Bloke, essentially, but indent it 2 spaces on the left, just like you cut and paste from the d/changelog
<Odd_Bloke> bryce: https://code.launchpad.net/~daniel-thewatkins/ubuntu/+source/simplestreams/+git/simplestreams/+merge/376423 <-- how's that?
<bryce> Odd_Bloke, sorry distracted by the meeting :-)
<bryce> Odd_Bloke, ok so the main thing is to make the changelog a separate commit from the rest of the changes
<rbasak> bryce: I think we should be clear that making the changelog a separate commit is a convention we've established in our squad and isn't a git-ubuntu requirement.
<bryce> so "git commit debian/changelog -m 'changelog'; git commit -a "  * New upstream snapshot\n..."
<bryce> rbasak, er, I thought it was a requirement
<rbasak> It's not :)
<bryce> rbasak, in any case, for teaching purposes best to give just one "right" way to do it
<rbasak> bryce: I'm torn. I appreciate that point in general, but my intention for git-ubuntu is for all Ubuntu developers to be able to use it regardless of their specific preferences and workflows. I don't want to put people off by adding things they have to do.
<rbasak> So I want to be liberal in what we accept.
<rbasak> If it follows usual git conventions and results in a functional upload, I think we should accept it.
<Odd_Bloke> FWIW, if I'm coming to you for guidance, being told that there are many ways I can do it is more offputting than having specific instructions.  (_I_ understand you're having a more general conversation, but bear in mind that most people _wouldn't_ know that. :p)
<Odd_Bloke> bryce: Updated the MP, how does it look now?
<bryce> Odd_Bloke, yes looks great
<Odd_Bloke> Cool. :)
<bryce> next, for the review process, I download your branch to my local checkout of simplestreams, in an lxc container, run the autopkgtests, and if all looks good I will approve and upload
<Odd_Bloke> bryce: https://people.canonical.com/~dwatkins/simplestreams_0.1.0-30-g3cc8988a.orig.tar.gz <-- that's my orig tarball if you need it
<Odd_Bloke> I'm not attached to it though, so feel free to generate your own. :p
<bryce> Odd_Bloke, there's some optional steps that people sometimes do, like stick it in a PPA to verify it builds, or add it to Bileto to demonstrate the autopkgtests will pass.  But these are just to help reviewers, and are separate from git ubuntu itself.
<rbasak> Odd_Bloke: what, you're saying upstream didn't even release a tarball? :-P
<Odd_Bloke> rbasak: You're saying it isn't obvious that people should fetch it from my people.canonical.com account?? ^_^
<bryce> heh
<bryce> Odd_Bloke, so yeah this would probably be a case where setting up a PPA for the reviewer would be super helpful, but I'll work from that tarball
<Odd_Bloke> bryce: I'm absolutely happy to do what you would generally expect, to develop "muscle" memory.
<Odd_Bloke> bryce: To which end, I've just uploaded to https://launchpad.net/~daniel-thewatkins/+archive/ubuntu/streams
<bryce> Odd_Bloke, ok, so the next step in that case would be to run 'git ubuntu build-source' which should spit out a .changes file you can dput into a ppa
<bryce> there is also a 'git ubuntu build' which will locally build the binaries, assuming you have needed dependencies installed
<bryce> I usually run git ubuntu build first as a sanity check, then git ubuntu build-source
<bryce> ppa looks good
<Odd_Bloke> I hit a couple of different errors when using `build-source`: https://paste.ubuntu.com/p/bCtsPgxzBH/
<bryce> yep it's complaining about the lack of a tarball
<Odd_Bloke> (The source package I uploaded to the PPA is the one that our uss-tableflip tooling produces.)
<bryce> and then complaining that a debian directory is already inside the tarball
<rbasak> bug 1734657
<ubottu> bug 1734657 in usd-importer "collision with debian dir on build-source - FileExistsError: [Errno 17] File exists: 'debian'" [High,Triaged] https://launchpad.net/bugs/1734657
<bryce> I think there's a couple ways to work around that, but easiest if you're generating the snapshot yourself is to just exclude it from the tarball
<rbasak> I guess that's maybe OK for simplestreams, but in general we shouldn't be modifying the orig tarball like that
<bryce> rbasak, thus my caveat "if you're generating the snapshot yourself"
<rbasak> Even then though I don't think it's OK unless you _are_ upstream.
<rbasak> Because you'd be uploading an orig tarball that isn't actually a snapshot of what it claims to be
<Odd_Bloke> bryce: OK, in lieu of working out how to modify our snapshot script (or repacking the tarball manually), is the PPA as-is sufficient?
<bryce> Odd_Bloke, I think so, yes
<Odd_Bloke> OK, cool.
<bryce> I've repro'd the debian dir issue here locally
<bryce> it occurs for me on the master branch too
<rbasak> bryce: see the bug I linked above
<bryce> rbasak, so what's the workaround?
<rbasak> bryce: to not use git ubuntu build-source - it's fundamentally broken in this edge case and needs fixing.
<rbasak> I'm sorry to say that's my general opinion of build and build-source - they are broken in too many edge cases for me to recommend anyone try using them.
<rbasak> (right now)
<rbasak> I'm hoping this can all be fixed soon :)
<rbasak> So I guess in answer to your question: arrange the orig tarball manually and use dpkg-buildpackage -S
<rbasak> The first error Odd_Bloke found is expected behaviour but could defeinitely do with a more helpful error message.
<rbasak> (no possible way to get an orig tarball -> no source package build possible)
<bryce> ok...  so "exclude debian from the tarball"
<rbasak> No, because that results in an incorrect tarball. You don't want to upload that.
<rbasak> If upstream put a debian directory in their release tarball, it should be present in the orig tarball in the Debian/Ubuntu upload.
<rbasak> dpkg can deal with it
<rbasak> The upload shouldn't be compromised because of a git-ubuntu bug.
<bryce> I'm getting called for breakfast.  rbasak feel free to carry it from here else I'll continue in a bit.
<rbalint> bdmurray, i'm about to migrate ubuntu-release-upgrader to git
<rbalint> bdmurray, could you please review https://code.launchpad.net/~rbalint/ubuntu-release-upgrader/ubuntu-release-upgrader/+merge/376424 before the switch?
<bdmurray> rbalint: Is there anything about the dist-upgrader tarball creation we need to be concerned about?
<kanashiro> rbasak, who should I get in touch to fix mysql 8 related issues?
<bryce> Odd_Bloke, package sponsored, sorry for the delay.
<rbasak> kanashiro: can you pastebin the error in here? Ping me or Skuggen here.
<teward> cjwatson: around to let me pick your brain?
<Odd_Bloke> bryce: Thanks!
<kanashiro> rbasak, sphinxsearch implements mysql support so you can connect to it using a client like you do with a regular mysql database. The problem is that I can't connect to it using ruby-mysql2 (ruby-riddle tries to do it) after mysql 8, there is no error log
<kanashiro> according to upstream notes this bug was fixed in v3.1.1 (http://sphinxsearch.com/docs/sphinx3.html#version-3.1.1-17-oct-2018) and we have 2.2.11 in the archive
<kanashiro> manticore is a sphinx fork and they fixed this issue in this commit: https://github.com/manticoresoftware/manticoresearch/commit/ed98fdd7230c1d7298e1000fd10812338c6ba698
<kanashiro> since this is a fork the solution might be similar (or not), need to check
<Odd_Bloke> rbasak: If I wanted to request the addition of a package (simplestreams) to a packageset (ubuntu-cloud), how would I go about doing so?  An email to devel-permissions@l.u.c?  (And would you consider that a reasonable request?)
<bryce> Odd_Bloke, do you mean add a package to the cloud-image Ubuntu seeds?
<bryce> if it is, part of the process may involve creating a branch of https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ and doing a MP.  Robie would know the actual procedure better than me though.
<Odd_Bloke> bryce: I mean a packageset change so that ubuntu-cloud uploaders (such as myself :) could upload simplestreams: https://people.canonical.com/~ubuntu-archive/packagesets/focal/ubuntu-cloud
<bryce> Odd_Bloke, gotcha, sorry
<Odd_Bloke> bryce: :)
<rbalint> bdmurray, related to the git conversion?
<rbasak> Odd_Bloke: yes, email devel-permissions@ please. I haven't thought about in detail but superficially that sounds fine.
<Odd_Bloke> Ack, thanks!
#ubuntu-devel 2019-12-06
<alkisg> Hi, I'm upstream and Debian maintainer for the "ltsp" package. A rewritten version of it has just landed in Debian testing, and it'd be best if focal got it too.
<alkisg> Question, will this be done automatically or do I need to do some action? https://launchpad.net/ubuntu/+source/ltsp lists it in "proposed".
<rbasak> alkisg: hi! Thank you for looking out for your package in Ubuntu!
<rbasak> The reason something gets "stuck on proposed" is much the same as migration to testing in Debian
<rbasak> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ltsp has the details
<rbasak> Is there some kind of rearrangement in the binary packages produced?
<alkisg> Thanks, reading.. :)
<alkisg> Yes, many binary packages were removed
<alkisg> There's only one "ltsp" binary package now
<alkisg> And it's "arch: all", interpreted
<rbasak> I'm somewhat puzzled why this hasn't happened automatically.
<alkisg> The migration to debian testing only happened yesterday
<alkisg> Maybe it just needs some time?
<rbasak> No Ubuntu doesn't have a mandatory delay like testing
<rbasak> And the excuses file is clear that it's blocked
<rbasak> I think deletion of the binaries in the release pocket would work, but I'm not sure that's definitely the right thing to do.
<rbasak> We need to ask an archive admin (equivalent of an ftpmaster) to take a look.
<rbasak> Unless there's something I'm missing here
<alkisg> We did have to ping ftp master for the debian migration to testing
<alkisg> Maybe something similar is needed here
<rbasak> What happens if a user has the old binary packages installed?
<rbasak> I don't see an upgrade path?
<alkisg> It should remain installed, and it should be possible to get autoremoved with apt
<alkisg> It was possible to have the old and the new ltsp coexist for some time, that's why this was preferred
<alkisg> Also the other debian developer said that way it would avoid the New queue for debian ;)
<alkisg> (vagrantc is DD, I'm just DM, so I defer to him for such issues :))
<rbasak> Could you file a bug against ltsp in Ubuntu please, and subscribe ~ubuntu-archive to it?
<alkisg> Sure, thank you
<rbasak> I don't want to go into the technical detail myself because I'm not confident I understand the nuances here and I don't want to take you down a path that's wrong.
<rbasak> And I don't have the authority to resolve it in the archive anyway.
<alkisg> Hopefully I got the correct list subscribed: https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/1855422
<ubottu> Launchpad bug 1855422 in ltsp (Ubuntu) "New ltsp package stuck in focal proposed" [Undecided,New]
<rbasak> akelling: thanks! Yes, that subscription is correct.
<alkisg> Ty. alkisg :)
<rbasak> The archive admins tend to process things in batches though so the bug may not get attention quickly.
<rbasak> Ah, sorry!
<alkisg> There's no hurry, just making sure it requires no other action from my part
<rbasak> You were right to ask in here.
<rbasak> And feel free to ask again if it doesn't get attention in a while.
<alkisg> Great, thank you
<rbasak> I don't see any European archive admins in here right now
<rbasak> Ah, seb128 maybe? ^
<seb128> rbasak, hey, sorry had to change wifi, I'm around now ... what's up?
<rbasak> seb128: are you an active archive admin?
<seb128> yes
<rbasak> alkisg has an issue with ltsp migrating. I think it needs some binary deletions but am not sure. On my advice he just filed bug 1855422 but then I saw you were online :)
<ubottu> bug 1855422 in ltsp (Ubuntu) "New ltsp package stuck in focal proposed" [Undecided,New] https://launchpad.net/bugs/1855422
<seb128> looking
<alkisg> Ty, I'm here if feedback's needed
<seb128> alkisg, rbasak, seems like the old binaries have no rdepends and just need to be deleted
<alkisg> Nice
<cjwatson> coreycb: those two pushes of yours should work now
<cjwatson> teward: wasn't around then.  what do you need?
<rbasak> seb128: thank you!
<seb128> rbasak, np!
<kanashiro> rbasak, did you see my message yesterday about the sphinxsearch issue? ruby-riddle regression is the only thing avoiding ruby-defaults migration atm
<rbasak> kanashiro: yes. That research looks good. Did you have a question for me?
<kanashiro> rbasak, there was no question, I thought I was handing it over to someone else :p but that's fine, I can try to find the fix by myself
<kanashiro> if I have any question I'll ping you
<rbasak> kanashiro: oh, sorry for the confusion!
<kanashiro> np :)
<coreycb> cjwatson: thanks
<ahasenack> cpaelzer: how does one build manual test-retrigger urls again? I'm trying to do it for one package specifically before going the all-proposed=1 route (learning experience)
<ahasenack> https://autopkgtest.ubuntu.com/request.cgi?release=focal&arch=amd64&package=samba&trigger=ldb%2F2.0.7-4 <-- failed with
<ahasenack> You submitted an invalid request: ldb/2.0.7-4 is not published in focal
<ahasenack> which is correct, as ldb 2.0.7-4 is in focal-proposed
<ahasenack> I want to run the samba test under https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ldb
<ahasenack> but with the samba package from focal-proposed
<ahasenack> test is green as is
<ahasenack> or, to use a real case that is read
<ahasenack> samba under https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#talloc
<ahasenack> I need it to run with samba from focal-proposed
<ahasenack> and didn't want to pass all-proposed=1
 * ahasenack reads https://wiki.ubuntu.com/ProposedMigration in the mean time
 * ahasenack adds samba itself as a trigger
 * ahasenack feels smart
 * ahasenack waits for the outcome
<ahasenack> Unpacking samba-libs:amd64 (2:4.11.1+dfsg-3ubuntu1) ...
<ahasenack> yay, seems to have picked up the correct version
<ahasenack> nice
<seb128> ddstreet, hey, please commit your network-manager changes to the packaging vcs
<seb128> alkisg, rbasak, the ltsp update is in focal now
<rbasak> Thank you!
<alkisg> Great seb128, thank you, thanks to rbasak too
<seb128> yw!
<Odd_Bloke> rbasak: Thanks!
<rbasak> yw!
<ddstreet> seb128 done, sorry
<seb128> ddstreet, np, thanks!
<ddstreet> vorlon will i386 autopkgtests on focal get properly tweaked somehow so they pull the right arch deps (I see you did some work for build-essential already), or will they all just get marked ignore?
<ddstreet> i'm assuming for now, at least, i386 tests on focal can be ignored
<doko> seb128: python-pceclib: please don't depend on python, use python2 instead
<seb128> doko, ack
<vorlon> ddstreet: many autopkgtests will need adjusted individually to have correct cross-capable definitions; I've started working on uploading a number of these and will be posting to ubuntu-devel with some guidance on how to do this.  In the meantime, it's correct to mark any that are failing "ignore" since they have regressed in the release pocket
<santa_> so ... i386 packages started to "dissapear", correct?
<santa_> from focal I mean
<santa_> ah, indeed
 * santa_ reads ubuntu-devel ML
<santa_> yep, time to ditch my kde test rebuilds for i386 I guess
<vorlon> for focal, very much so ;)
<LocutusOfBorg> fossfreedom, is it ok to sync nautilus-dropbox?
<LocutusOfBorg> the new release is fine with budgie or not?
<LocutusOfBorg> speaking wrt https://bugs.launchpad.net/ubuntu/+source/nautilus-dropbox/+bug/1683051
<ubottu> Launchpad bug 1683051 in nautilus-dropbox (Ubuntu) "Ubuntu Budgie: Bad integration with Dropbox" [Medium,Fix released]
<LocutusOfBorg> merged it
<LocutusOfBorg> kanashiro, hello, any idea for this failure? I tried to sync ruby-riddle but failed https://launchpad.net/ubuntu/+source/ruby-riddle/2.3.1-2ubuntu1
<LocutusOfBorg> looks like the current version in focal is not even working with a no-change rebuild
#ubuntu-devel 2019-12-07
<HokarPokar> Hey guys. I have been trying to get my ubuntu 18.04 LTS to detect a second display. I had been using that display for about 2 months now but just 2 days ago, it stopped detecting the display. I know this is developer's channel. I was wondering if anyone can help me or point me to the right resources. If anyone is willign to help me out, I can share
<HokarPokar> information about my graphics card and drivers/
<HokarPokar> I'm asking politely without trying to spam the channel
<alkisg> Hi, the following Ubuntu-specific packages should be removed from the archive for Focal: ltsp-cluster-*, python-ltsp
<alkisg> They've been unmaintained and not runnable for ages, and now with the new LTSP19 in Focal they're completely irrelevant.
<alkisg> Question, where would I report that? Should I file a bug in launchpad against each one of those 9 packages?
<rbasak> alkisg: file a single bug, add a bug task for each source package that needs removing, and subscribe ~ubuntu-archive please.
<alkisg> rbasak: file the bug under which package?
<rbasak> alkisg: any one of the source packages involved
<alkisg> Thank you
<rbasak> alkisg: then add tasks for the other source packages
<rbasak> Binaries not built from any source will be batch detected and removed by archive admins as part of the release process
<alkisg> rbasak: I'm not sure I have enough rights to create "bug tasks", is putting them to the "affects list" similar? https://bugs.launchpad.net/ubuntu/+source/ltsp-cluster-accountmanager/+bug/1855525
<ubottu> Launchpad bug 1855525 in ltsp-cluster-control (Ubuntu) "Remove unmaintained ltsp-cluster-* packages" [Undecided,New]
<rbasak> alkisg: yes that's correct - we call those bug tasks
<alkisg> OK ty continuing then :)
 * rbasak disappears
<alekblank> I was thinking. Has it ever been brought up, maybe instead of using the phone as the desktop entirely, just combining the apps, and data on to an already running computer? Then later on trying to work on stand alone solutions.
<alekblank> So all the apps and data you have on the phone would apear and be runnable on the desktop
<kanashiro> LocutusOfBorg, ruby-riddle fails because of a sphinxsearch bug, the current version does not support MySQL 8 clients
<kanashiro> I have patches to fix them and I am looking for sponsors :)
<kanashiro> https://bugs.launchpad.net/ubuntu/+source/ruby-riddle/+bug/1855475
<ubottu> Launchpad bug 1855475 in ruby-riddle (Ubuntu) "autopkgtest regression triggered by ruby-defaults/1:2.5.2" [Undecided,New]
<kanashiro> https://bugs.launchpad.net/ubuntu/+source/sphinxsearch/+bug/1855468
<ubottu> Launchpad bug 1855468 in sphinxsearch (Ubuntu) "Version 2.2.11 does not support MySQL 8 clients" [Undecided,New]
<kanashiro> in Debian ruby-riddle works fine because the default mysql server is mariadb
<kanashiro> ah since you synced my upload from Debian I need to update my ruby-riddle patch
<LocutusOfBorg> kanashiro, wrt sphinxsearch, please open a bug with patch in debian...
<kanashiro> LocutusOfBorg, in debian is not needed, it just works fine
<LocutusOfBorg> ok, but Debian might also use mysql8 if they wants
<LocutusOfBorg> an user might change the backend and recompile on his own machine
<kanashiro> ok, fair enough, I'll file a bug report
<LocutusOfBorg> your patch against ruby-riddle doesn't apply anymore, lets try to merge it
<kanashiro> I am uploading an updated debdiff
<kanashiro> done
<LocutusOfBorg> ack thanks
<LocutusOfBorg> btw, I don't think this is usually worth an upload, because meh, it just needs a no-change rebuild
<LocutusOfBorg> but wilco
<LocutusOfBorg> btw, if you want to provide me a sphinxsearch updated Debian package, with your patch and the other bugs with patches fixed (e.g. watch file, cross-builds and so on) I can upload in Debian as NMU
<kanashiro> yeah, I added that version constraint just to make sure it is built agains the right sphinxsearch version
<kanashiro> thanks for the offering LocutusOfBorg, I might prepare something but I don't need to bother you this time because I have upload rights in Debian
<kanashiro> but I should work on sphinxsearch in the Debian side on Monday (no more time today and might not have it tomorrow)
<kanashiro> and thanks LocutusOfBorg for sponsoring those patches, it will let ruby-defaults migrate to the release pocket
<LocutusOfBorg> thanks to you for the nice work!
